** 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 Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1798891 Title: [SRU] octavia-api won't start by default To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-archive/+bug/1798891/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
