| 2018-10-19 19:20:41 |
Corey Bryant |
bug |
|
|
added bug |
| 2018-10-19 19:21:05 |
Corey Bryant |
nominated for series |
|
Ubuntu Dd-series |
|
| 2018-10-19 19:21:05 |
Corey Bryant |
bug task added |
|
octavia (Ubuntu Dd-series) |
|
| 2018-10-19 19:21:05 |
Corey Bryant |
nominated for series |
|
Ubuntu Cosmic |
|
| 2018-10-19 19:21:05 |
Corey Bryant |
bug task added |
|
octavia (Ubuntu Cosmic) |
|
| 2018-10-19 19:21:28 |
Corey Bryant |
bug task added |
|
cloud-archive |
|
| 2018-10-19 19:21:35 |
Corey Bryant |
nominated for series |
|
cloud-archive/rocky |
|
| 2018-10-19 19:21:35 |
Corey Bryant |
bug task added |
|
cloud-archive/rocky |
|
| 2018-10-19 19:21:40 |
Corey Bryant |
cloud-archive/rocky: status |
New |
Triaged |
|
| 2018-10-19 19:21:42 |
Corey Bryant |
cloud-archive/rocky: importance |
Undecided |
Critical |
|
| 2018-10-19 19:21:45 |
Corey Bryant |
cloud-archive/rocky: importance |
Critical |
High |
|
| 2018-10-19 19:21:48 |
Corey Bryant |
octavia (Ubuntu Cosmic): importance |
Undecided |
High |
|
| 2018-10-19 19:21:49 |
Corey Bryant |
octavia (Ubuntu Dd-series): importance |
Undecided |
High |
|
| 2018-10-19 19:21:52 |
Corey Bryant |
octavia (Ubuntu Dd-series): status |
New |
Triaged |
|
| 2018-10-19 19:21:54 |
Corey Bryant |
octavia (Ubuntu Cosmic): status |
New |
Triaged |
|
| 2018-10-19 19:29:17 |
Corey Bryant |
description |
[Impact]
After installing octavia-api the systemd unit file fails to start:
Failed 'systemctl status octavia-api' output shows:
octavia-api from uca/rocky doesn't start, octavia-api: error: unrecognized arguments: --http-socket [::]:9876 --ini /etc/octavia/octavia-api-uwsgi.ini
[Test Case]
1) sudo apt install octavia-api
2) watch systemctl status octavia-api # watch for about 10 seconds and ensure it doesn't fail
3) curl 127.0.0.1:9876 # should return something like [1], not [2]
[1] {"versions": [{"id": "v1", "status": "DEPRECATED", "updated": "2014-12-11T00:00:00Z", "links": [{"href": "http://127.0.0.1:9876/v1", "rel": "self"}]}, {"id": "v2.0", "status": "SUPPORTED", "updated": "2016-12-11T00:00:00Z", "links": [{"href": "http://127.0.0.1:9876/v2", "rel": "self"}]}, {"id": "v2.1", "status": "SUPPORTED", "updated": "2018-04-20T00:00:00Z", "links": [{"href": "http://127.0.0.1:9876/v2", "rel": "self"}]}, {"id": "v2.2", "status": "CURRENT", "updated": "2018-07-31T00:00:00Z", "links": [{"href": "http://127.0.0.1:9876/v2", "rel": "self"}]}]}
[2] curl: (7) Failed to connect to 127.0.0.1 port 9876: Connection refused
[Regression Potential]
Low. This is just allowing use of the default port. |
[Impact]
After installing octavia-api the systemd unit fails to start:
Failed 'systemctl status octavia-api' output shows:
error: unrecognized arguments: --http-socket [::]:9876 --ini /etc/octavia/octavia-api-uwsgi.ini
[Test Case]
1) sudo apt install octavia-api
2) watch systemctl status octavia-api # watch for about 10 seconds and ensure it doesn't fail
3) curl 127.0.0.1:9876 # should return something like [1], not [2]
[1] {"versions": [{"id": "v1", "status": "DEPRECATED", "updated": "2014-12-11T00:00:00Z", "links": [{"href": "http://127.0.0.1:9876/v1", "rel": "self"}]}, {"id": "v2.0", "status": "SUPPORTED", "updated": "2016-12-11T00:00:00Z", "links": [{"href": "http://127.0.0.1:9876/v2", "rel": "self"}]}, {"id": "v2.1", "status": "SUPPORTED", "updated": "2018-04-20T00:00:00Z", "links": [{"href": "http://127.0.0.1:9876/v2", "rel": "self"}]}, {"id": "v2.2", "status": "CURRENT", "updated": "2018-07-31T00:00:00Z", "links": [{"href": "http://127.0.0.1:9876/v2", "rel": "self"}]}]}
[2] curl: (7) Failed to connect to 127.0.0.1 port 9876: Connection refused
[Regression Potential]
Low. This is just allowing use of the default or configured port from octavia's config file. |
|
| 2018-10-19 19:41:17 |
Corey Bryant |
description |
[Impact]
After installing octavia-api the systemd unit fails to start:
Failed 'systemctl status octavia-api' output shows:
error: unrecognized arguments: --http-socket [::]:9876 --ini /etc/octavia/octavia-api-uwsgi.ini
[Test Case]
1) sudo apt install octavia-api
2) watch systemctl status octavia-api # watch for about 10 seconds and ensure it doesn't fail
3) curl 127.0.0.1:9876 # should return something like [1], not [2]
[1] {"versions": [{"id": "v1", "status": "DEPRECATED", "updated": "2014-12-11T00:00:00Z", "links": [{"href": "http://127.0.0.1:9876/v1", "rel": "self"}]}, {"id": "v2.0", "status": "SUPPORTED", "updated": "2016-12-11T00:00:00Z", "links": [{"href": "http://127.0.0.1:9876/v2", "rel": "self"}]}, {"id": "v2.1", "status": "SUPPORTED", "updated": "2018-04-20T00:00:00Z", "links": [{"href": "http://127.0.0.1:9876/v2", "rel": "self"}]}, {"id": "v2.2", "status": "CURRENT", "updated": "2018-07-31T00:00:00Z", "links": [{"href": "http://127.0.0.1:9876/v2", "rel": "self"}]}]}
[2] curl: (7) Failed to connect to 127.0.0.1 port 9876: Connection refused
[Regression Potential]
Low. This is just allowing use of the default or configured port from octavia's config file. |
[Impact]
After installing octavia-api the systemd unit fails to start:
Failed 'systemctl status octavia-api' output shows:
error: unrecognized arguments: --http-socket [::]:9876 --ini /etc/octavia/octavia-api-uwsgi.ini
[Test Case]
1) sudo apt install octavia-api
2) watch systemctl status octavia-api # watch for a bit ensure it doesn't fail
3) curl 127.0.0.1:9876 # should return something like [1], not [2]
[1] {"versions": [{"id": "v1", "status": "DEPRECATED", "updated": "2014-12-11T00:00:00Z", "links": [{"href": "http://127.0.0.1:9876/v1", "rel": "self"}]}, {"id": "v2.0", "status": "SUPPORTED", "updated": "2016-12-11T00:00:00Z", "links": [{"href": "http://127.0.0.1:9876/v2", "rel": "self"}]}, {"id": "v2.1", "status": "SUPPORTED", "updated": "2018-04-20T00:00:00Z", "links": [{"href": "http://127.0.0.1:9876/v2", "rel": "self"}]}, {"id": "v2.2", "status": "CURRENT", "updated": "2018-07-31T00:00:00Z", "links": [{"href": "http://127.0.0.1:9876/v2", "rel": "self"}]}]}
[2] curl: (7) Failed to connect to 127.0.0.1 port 9876: Connection refused
[Regression Potential]
Low. This is just allowing use of the default or configured port from octavia's config file. |
|
| 2018-10-19 19:49:51 |
Corey Bryant |
description |
[Impact]
After installing octavia-api the systemd unit fails to start:
Failed 'systemctl status octavia-api' output shows:
error: unrecognized arguments: --http-socket [::]:9876 --ini /etc/octavia/octavia-api-uwsgi.ini
[Test Case]
1) sudo apt install octavia-api
2) watch systemctl status octavia-api # watch for a bit ensure it doesn't fail
3) curl 127.0.0.1:9876 # should return something like [1], not [2]
[1] {"versions": [{"id": "v1", "status": "DEPRECATED", "updated": "2014-12-11T00:00:00Z", "links": [{"href": "http://127.0.0.1:9876/v1", "rel": "self"}]}, {"id": "v2.0", "status": "SUPPORTED", "updated": "2016-12-11T00:00:00Z", "links": [{"href": "http://127.0.0.1:9876/v2", "rel": "self"}]}, {"id": "v2.1", "status": "SUPPORTED", "updated": "2018-04-20T00:00:00Z", "links": [{"href": "http://127.0.0.1:9876/v2", "rel": "self"}]}, {"id": "v2.2", "status": "CURRENT", "updated": "2018-07-31T00:00:00Z", "links": [{"href": "http://127.0.0.1:9876/v2", "rel": "self"}]}]}
[2] curl: (7) Failed to connect to 127.0.0.1 port 9876: Connection refused
[Regression Potential]
Low. This is just allowing use of the default or configured port from octavia's config file. |
[Impact]
After installing octavia-api the systemd unit fails to start:
Failed 'systemctl status octavia-api' output shows:
error: unrecognized arguments: --http-socket [::]:9876 --ini /etc/octavia/octavia-api-uwsgi.ini
The problem is that init files are configured with UWSGI options but the binary being run is not uwsgi. See full output: https://paste.ubuntu.com/p/WHQk2y2F84/
[Test Case]
1) sudo apt install octavia-api
2) watch systemctl status octavia-api # watch for a bit ensure it doesn't fail
3) curl 127.0.0.1:9876 # should return something like [1], not [2]
[1] {"versions": [{"id": "v1", "status": "DEPRECATED", "updated": "2014-12-11T00:00:00Z", "links": [{"href": "http://127.0.0.1:9876/v1", "rel": "self"}]}, {"id": "v2.0", "status": "SUPPORTED", "updated": "2016-12-11T00:00:00Z", "links": [{"href": "http://127.0.0.1:9876/v2", "rel": "self"}]}, {"id": "v2.1", "status": "SUPPORTED", "updated": "2018-04-20T00:00:00Z", "links": [{"href": "http://127.0.0.1:9876/v2", "rel": "self"}]}, {"id": "v2.2", "status": "CURRENT", "updated": "2018-07-31T00:00:00Z", "links": [{"href": "http://127.0.0.1:9876/v2", "rel": "self"}]}]}
[2] curl: (7) Failed to connect to 127.0.0.1 port 9876: Connection refused
[Regression Potential]
The API service wasn't starting so I don't know if that can be regressed much more. The fix is using the standard approach that OpenStack has historically used to start a service which is to use the service's /usr/bin/<service>-api file which in the case of octavia is using wsgiref.simple_server to host the API WSGI server. Ideally we'd like to run this behind and apache sever but I figured we probably should make that switch in a development cycle rather than stable cycle. |
|
| 2018-10-19 19:51:04 |
Corey Bryant |
description |
[Impact]
After installing octavia-api the systemd unit fails to start:
Failed 'systemctl status octavia-api' output shows:
error: unrecognized arguments: --http-socket [::]:9876 --ini /etc/octavia/octavia-api-uwsgi.ini
The problem is that init files are configured with UWSGI options but the binary being run is not uwsgi. See full output: https://paste.ubuntu.com/p/WHQk2y2F84/
[Test Case]
1) sudo apt install octavia-api
2) watch systemctl status octavia-api # watch for a bit ensure it doesn't fail
3) curl 127.0.0.1:9876 # should return something like [1], not [2]
[1] {"versions": [{"id": "v1", "status": "DEPRECATED", "updated": "2014-12-11T00:00:00Z", "links": [{"href": "http://127.0.0.1:9876/v1", "rel": "self"}]}, {"id": "v2.0", "status": "SUPPORTED", "updated": "2016-12-11T00:00:00Z", "links": [{"href": "http://127.0.0.1:9876/v2", "rel": "self"}]}, {"id": "v2.1", "status": "SUPPORTED", "updated": "2018-04-20T00:00:00Z", "links": [{"href": "http://127.0.0.1:9876/v2", "rel": "self"}]}, {"id": "v2.2", "status": "CURRENT", "updated": "2018-07-31T00:00:00Z", "links": [{"href": "http://127.0.0.1:9876/v2", "rel": "self"}]}]}
[2] curl: (7) Failed to connect to 127.0.0.1 port 9876: Connection refused
[Regression Potential]
The API service wasn't starting so I don't know if that can be regressed much more. The fix is using the standard approach that OpenStack has historically used to start a service which is to use the service's /usr/bin/<service>-api file which in the case of octavia is using wsgiref.simple_server to host the API WSGI server. Ideally we'd like to run this behind and apache sever but I figured we probably should make that switch in a development cycle rather than stable cycle. |
[Impact]
After installing octavia-api the systemd unit fails to start:
Failed 'systemctl status octavia-api' output shows:
error: unrecognized arguments: --http-socket [::]:9876 --ini /etc/octavia/octavia-api-uwsgi.ini
The problem is that init files are configured with UWSGI options but the binary being run is not uwsgi. See full output: https://paste.ubuntu.com/p/WHQk2y2F84/
[Test Case]
1) sudo apt install octavia-api
2) watch systemctl status octavia-api # watch for a bit ensure it doesn't fail
3) curl 127.0.0.1:9876 # should return something like [1], not [2]
[1] {"versions": [{"id": "v1", "status": "DEPRECATED", "updated": "2014-12-11T00:00:00Z", "links": [{"href": "http://127.0.0.1:9876/v1", "rel": "self"}]}, {"id": "v2.0", "status": "SUPPORTED", "updated": "2016-12-11T00:00:00Z", "links": [{"href": "http://127.0.0.1:9876/v2", "rel": "self"}]}, {"id": "v2.1", "status": "SUPPORTED", "updated": "2018-04-20T00:00:00Z", "links": [{"href": "http://127.0.0.1:9876/v2", "rel": "self"}]}, {"id": "v2.2", "status": "CURRENT", "updated": "2018-07-31T00:00:00Z", "links": [{"href": "http://127.0.0.1:9876/v2", "rel": "self"}]}]}
[2] curl: (7) Failed to connect to 127.0.0.1 port 9876: Connection refused
[Regression Potential]
The API service wasn't starting so I don't know if that can be regressed much more. The fix is using the standard approach that OpenStack has historically used to start a service which is to use the service's /usr/bin/<service>-api file which in the case of octavia is using wsgiref.simple_server to host the API WSGI server. Ideally we'd like to run the API under an apache2 server but that switch seems more applicable to a development cycle than a stable cycle. |
|
| 2018-10-19 19:51:23 |
Corey Bryant |
description |
[Impact]
After installing octavia-api the systemd unit fails to start:
Failed 'systemctl status octavia-api' output shows:
error: unrecognized arguments: --http-socket [::]:9876 --ini /etc/octavia/octavia-api-uwsgi.ini
The problem is that init files are configured with UWSGI options but the binary being run is not uwsgi. See full output: https://paste.ubuntu.com/p/WHQk2y2F84/
[Test Case]
1) sudo apt install octavia-api
2) watch systemctl status octavia-api # watch for a bit ensure it doesn't fail
3) curl 127.0.0.1:9876 # should return something like [1], not [2]
[1] {"versions": [{"id": "v1", "status": "DEPRECATED", "updated": "2014-12-11T00:00:00Z", "links": [{"href": "http://127.0.0.1:9876/v1", "rel": "self"}]}, {"id": "v2.0", "status": "SUPPORTED", "updated": "2016-12-11T00:00:00Z", "links": [{"href": "http://127.0.0.1:9876/v2", "rel": "self"}]}, {"id": "v2.1", "status": "SUPPORTED", "updated": "2018-04-20T00:00:00Z", "links": [{"href": "http://127.0.0.1:9876/v2", "rel": "self"}]}, {"id": "v2.2", "status": "CURRENT", "updated": "2018-07-31T00:00:00Z", "links": [{"href": "http://127.0.0.1:9876/v2", "rel": "self"}]}]}
[2] curl: (7) Failed to connect to 127.0.0.1 port 9876: Connection refused
[Regression Potential]
The API service wasn't starting so I don't know if that can be regressed much more. The fix is using the standard approach that OpenStack has historically used to start a service which is to use the service's /usr/bin/<service>-api file which in the case of octavia is using wsgiref.simple_server to host the API WSGI server. Ideally we'd like to run the API under an apache2 server but that switch seems more applicable to a development cycle than a stable cycle. |
[Impact]
After installing octavia-api the systemd unit fails to start:
Failed 'systemctl status octavia-api' output shows:
error: unrecognized arguments: --http-socket [::]:9876 --ini /etc/octavia/octavia-api-uwsgi.ini
The problem is that init files are configured with UWSGI options but the binary being run is not uwsgi. See full output: https://paste.ubuntu.com/p/WHQk2y2F84/
[Test Case]
1) sudo apt install octavia-api
2) watch systemctl status octavia-api # watch for a bit ensure it doesn't fail
3) curl 127.0.0.1:9876 # should return something like [1], not [2]
[1] {"versions": [{"id": "v1", "status": "DEPRECATED", "updated": "2014-12-11T00:00:00Z", "links": [{"href": "http://127.0.0.1:9876/v1", "rel": "self"}]}, {"id": "v2.0", "status": "SUPPORTED", "updated": "2016-12-11T00:00:00Z", "links": [{"href": "http://127.0.0.1:9876/v2", "rel": "self"}]}, {"id": "v2.1", "status": "SUPPORTED", "updated": "2018-04-20T00:00:00Z", "links": [{"href": "http://127.0.0.1:9876/v2", "rel": "self"}]}, {"id": "v2.2", "status": "CURRENT", "updated": "2018-07-31T00:00:00Z", "links": [{"href": "http://127.0.0.1:9876/v2", "rel": "self"}]}]}
[2] curl: (7) Failed to connect to 127.0.0.1 port 9876: Connection refused
[Regression Potential]
The API service wasn't starting so I don't know if that can be regressed much more. The fix is using the standard approach that OpenStack has historically used to start a service which is to use the service's /usr/bin/<service>-api file which in the case of octavia is using wsgiref.simple_server to host the API WSGI server. Ideally we'd like to run the API under an apache2 server but that switch seems more appropriate in a development cycle than a stable cycle. |
|
| 2018-10-19 19:51:45 |
Corey Bryant |
description |
[Impact]
After installing octavia-api the systemd unit fails to start:
Failed 'systemctl status octavia-api' output shows:
error: unrecognized arguments: --http-socket [::]:9876 --ini /etc/octavia/octavia-api-uwsgi.ini
The problem is that init files are configured with UWSGI options but the binary being run is not uwsgi. See full output: https://paste.ubuntu.com/p/WHQk2y2F84/
[Test Case]
1) sudo apt install octavia-api
2) watch systemctl status octavia-api # watch for a bit ensure it doesn't fail
3) curl 127.0.0.1:9876 # should return something like [1], not [2]
[1] {"versions": [{"id": "v1", "status": "DEPRECATED", "updated": "2014-12-11T00:00:00Z", "links": [{"href": "http://127.0.0.1:9876/v1", "rel": "self"}]}, {"id": "v2.0", "status": "SUPPORTED", "updated": "2016-12-11T00:00:00Z", "links": [{"href": "http://127.0.0.1:9876/v2", "rel": "self"}]}, {"id": "v2.1", "status": "SUPPORTED", "updated": "2018-04-20T00:00:00Z", "links": [{"href": "http://127.0.0.1:9876/v2", "rel": "self"}]}, {"id": "v2.2", "status": "CURRENT", "updated": "2018-07-31T00:00:00Z", "links": [{"href": "http://127.0.0.1:9876/v2", "rel": "self"}]}]}
[2] curl: (7) Failed to connect to 127.0.0.1 port 9876: Connection refused
[Regression Potential]
The API service wasn't starting so I don't know if that can be regressed much more. The fix is using the standard approach that OpenStack has historically used to start a service which is to use the service's /usr/bin/<service>-api file which in the case of octavia is using wsgiref.simple_server to host the API WSGI server. Ideally we'd like to run the API under an apache2 server but that switch seems more appropriate in a development cycle than a stable cycle. |
[Impact]
After installing octavia-api the systemd unit fails to start:
Failed 'systemctl status octavia-api' output shows:
error: unrecognized arguments: --http-socket [::]:9876 --ini /etc/octavia/octavia-api-uwsgi.ini
The problem is that init files are configured with UWSGI options but the binary being run is not uwsgi. See full output: https://paste.ubuntu.com/p/WHQk2y2F84/
[Test Case]
1) sudo apt install octavia-api
2) watch systemctl status octavia-api # watch to ensure it doesn't fail
3) curl 127.0.0.1:9876 # should return something like [1], not [2]
[1] {"versions": [{"id": "v1", "status": "DEPRECATED", "updated": "2014-12-11T00:00:00Z", "links": [{"href": "http://127.0.0.1:9876/v1", "rel": "self"}]}, {"id": "v2.0", "status": "SUPPORTED", "updated": "2016-12-11T00:00:00Z", "links": [{"href": "http://127.0.0.1:9876/v2", "rel": "self"}]}, {"id": "v2.1", "status": "SUPPORTED", "updated": "2018-04-20T00:00:00Z", "links": [{"href": "http://127.0.0.1:9876/v2", "rel": "self"}]}, {"id": "v2.2", "status": "CURRENT", "updated": "2018-07-31T00:00:00Z", "links": [{"href": "http://127.0.0.1:9876/v2", "rel": "self"}]}]}
[2] curl: (7) Failed to connect to 127.0.0.1 port 9876: Connection refused
[Regression Potential]
The API service wasn't starting so I don't know if that can be regressed much more. The fix is using the standard approach that OpenStack has historically used to start a service which is to use the service's /usr/bin/<service>-api file which in the case of octavia is using wsgiref.simple_server to host the API WSGI server. Ideally we'd like to run the API under an apache2 server but that switch seems more appropriate in a development cycle than a stable cycle. |
|
| 2018-10-19 19:54:22 |
Corey Bryant |
description |
[Impact]
After installing octavia-api the systemd unit fails to start:
Failed 'systemctl status octavia-api' output shows:
error: unrecognized arguments: --http-socket [::]:9876 --ini /etc/octavia/octavia-api-uwsgi.ini
The problem is that init files are configured with UWSGI options but the binary being run is not uwsgi. See full output: https://paste.ubuntu.com/p/WHQk2y2F84/
[Test Case]
1) sudo apt install octavia-api
2) watch systemctl status octavia-api # watch to ensure it doesn't fail
3) curl 127.0.0.1:9876 # should return something like [1], not [2]
[1] {"versions": [{"id": "v1", "status": "DEPRECATED", "updated": "2014-12-11T00:00:00Z", "links": [{"href": "http://127.0.0.1:9876/v1", "rel": "self"}]}, {"id": "v2.0", "status": "SUPPORTED", "updated": "2016-12-11T00:00:00Z", "links": [{"href": "http://127.0.0.1:9876/v2", "rel": "self"}]}, {"id": "v2.1", "status": "SUPPORTED", "updated": "2018-04-20T00:00:00Z", "links": [{"href": "http://127.0.0.1:9876/v2", "rel": "self"}]}, {"id": "v2.2", "status": "CURRENT", "updated": "2018-07-31T00:00:00Z", "links": [{"href": "http://127.0.0.1:9876/v2", "rel": "self"}]}]}
[2] curl: (7) Failed to connect to 127.0.0.1 port 9876: Connection refused
[Regression Potential]
The API service wasn't starting so I don't know if that can be regressed much more. The fix is using the standard approach that OpenStack has historically used to start a service which is to use the service's /usr/bin/<service>-api file which in the case of octavia is using wsgiref.simple_server to host the API WSGI server. Ideally we'd like to run the API under an apache2 server but that switch seems more appropriate in a development cycle than a stable cycle. |
[Impact]
After installing octavia-api the systemd unit fails to start:
Failed 'systemctl status octavia-api' output shows:
error: unrecognized arguments: --http-socket [::]:9876 --ini /etc/octavia/octavia-api-uwsgi.ini
The problem is that init files are configured with UWSGI options but the binary being run is not uwsgi. See full output: https://paste.ubuntu.com/p/WHQk2y2F84/
[Test Case]
1) sudo apt install octavia-api
2) watch systemctl status octavia-api # watch to ensure it doesn't fail
3) curl 127.0.0.1:9876 # should return something like [1], not [2]
[1] {"versions": [{"id": "v1", "status": "DEPRECATED", "updated": "2014-12-11T00:00:00Z", "links": [{"href": "http://127.0.0.1:9876/v1", "rel": "self"}]}, {"id": "v2.0", "status": "SUPPORTED", "updated": "2016-12-11T00:00:00Z", "links": [{"href": "http://127.0.0.1:9876/v2", "rel": "self"}]}, {"id": "v2.1", "status": "SUPPORTED", "updated": "2018-04-20T00:00:00Z", "links": [{"href": "http://127.0.0.1:9876/v2", "rel": "self"}]}, {"id": "v2.2", "status": "CURRENT", "updated": "2018-07-31T00:00:00Z", "links": [{"href": "http://127.0.0.1:9876/v2", "rel": "self"}]}]}
[2] curl: (7) Failed to connect to 127.0.0.1 port 9876: Connection refused
[Regression Potential]
Low. The provided fix only touches the octavia-api and is using the standard approach that OpenStack has historically used to start a service which is to use the service's /usr/bin/<service>-api file which in the case of octavia is using wsgiref.simple_server to host the API WSGI server. Ideally we'll like to run the API under an apache2 server but that switch seems more appropriate in a development cycle than a stable cycle. |
|
| 2018-10-19 20:17:41 |
Corey Bryant |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2018-10-23 20:47:08 |
Brian Murray |
octavia (Ubuntu Cosmic): status |
Triaged |
Fix Committed |
|
| 2018-10-23 20:47:11 |
Brian Murray |
bug |
|
|
added subscriber SRU Verification |
| 2018-10-23 20:47:14 |
Brian Murray |
tags |
|
verification-needed verification-needed-cosmic |
|
| 2018-10-31 23:48:41 |
Launchpad Janitor |
octavia (Ubuntu Disco): status |
Triaged |
Fix Released |
|
| 2018-11-02 11:54:41 |
Corey Bryant |
cloud-archive: status |
Triaged |
Fix Committed |
|
| 2018-11-02 14:07:22 |
Corey Bryant |
tags |
verification-needed verification-needed-cosmic |
verification-done-cosmic verification-needed |
|
| 2018-11-05 22:13:22 |
Brian Murray |
removed subscriber Ubuntu Stable Release Updates Team |
|
|
|
| 2018-11-05 22:23:24 |
Launchpad Janitor |
octavia (Ubuntu Cosmic): status |
Fix Committed |
Fix Released |
|
| 2018-11-28 12:58:58 |
Corey Bryant |
cloud-archive: status |
Fix Committed |
Fix Released |
|
| 2018-11-28 12:59:01 |
Corey Bryant |
cloud-archive/rocky: status |
Fix Committed |
Fix Released |
|
