[Bug 1798891] Re: [SRU] octavia-api won't start by default
Corey Bryant
corey.bryant at canonical.com
Fri Oct 19 19:49:51 UTC 2018
** Description changed:
[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]
- Low. This is just allowing use of the default or configured port from octavia's config file.
+ 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.
** Description changed:
[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.
+ 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.
** Description changed:
[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.
+ 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.
** Description changed:
[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
+ 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.
** Description changed:
[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.
+ 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.
--
You received this bug notification because you are a member of Ubuntu
OpenStack, which is subscribed to Ubuntu Cloud Archive.
https://bugs.launchpad.net/bugs/1798891
Title:
[SRU] octavia-api won't start by default
Status in Ubuntu Cloud Archive:
Triaged
Status in Ubuntu Cloud Archive rocky series:
Triaged
Status in octavia package in Ubuntu:
Triaged
Status in octavia source package in Cosmic:
Triaged
Status in octavia source package in DD-Series:
Triaged
Bug 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]
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.
To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-archive/+bug/1798891/+subscriptions
More information about the Ubuntu-openstack-bugs
mailing list