[Yahoo-eng-team] [Bug 1860021] [NEW] nova-live-migration fails 100% with "mysql: command not found" on subnode
Public bug reported: Since [1] nova-live-migration failures can be seen in devstack-subnodes- early.txt.gz like + ./stack.sh:main:1158 : is_glance_enabled + lib/glance:is_glance_enabled:90 : [[ , =~ ,glance ]] + lib/glance:is_glance_enabled:91 : [[ ,c-bak,c-vol,dstat,g-api,n-cpu,peakmem_tracker,placement-client,q-agt =~ ,g- ]] + lib/glance:is_glance_enabled:91 : return 0 + ./stack.sh:main:1159 : echo_summary 'Configuring Glance' + ./stack.sh:echo_summary:452 : [[ -t 3 ]] + ./stack.sh:echo_summary:458 : echo -e Configuring Glance + ./stack.sh:main:1160 : init_glance + lib/glance:init_glance:276 : rm -rf /opt/stack/data/glance/images + lib/glance:init_glance:277 : mkdir -p /opt/stack/data/glance/images + lib/glance:init_glance:280 : recreate_database glance + lib/database:recreate_database:110 : local db=glance + lib/database:recreate_database:111 : recreate_database_mysql glance + lib/databases/mysql:recreate_database_mysql:63 : local db=glance + lib/databases/mysql:recreate_database_mysql:64 : mysql -uroot -psecretmysql -h127.0.0.1 -e 'DROP DATABASE IF EXISTS glance;' /opt/stack/new/devstack/lib/databases/mysql: line 64: mysql: command not found + lib/databases/mysql:recreate_database_mysql:1 : exit_trap [1] https://review.opendev.org/#/c/702707/ ** Affects: nova Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1860021 Title: nova-live-migration fails 100% with "mysql: command not found" on subnode Status in OpenStack Compute (nova): New Bug description: Since [1] nova-live-migration failures can be seen in devstack- subnodes-early.txt.gz like + ./stack.sh:main:1158 : is_glance_enabled + lib/glance:is_glance_enabled:90 : [[ , =~ ,glance ]] + lib/glance:is_glance_enabled:91 : [[ ,c-bak,c-vol,dstat,g-api,n-cpu,peakmem_tracker,placement-client,q-agt =~ ,g- ]] + lib/glance:is_glance_enabled:91 : return 0 + ./stack.sh:main:1159 : echo_summary 'Configuring Glance' + ./stack.sh:echo_summary:452 : [[ -t 3 ]] + ./stack.sh:echo_summary:458 : echo -e Configuring Glance + ./stack.sh:main:1160 : init_glance + lib/glance:init_glance:276 : rm -rf /opt/stack/data/glance/images + lib/glance:init_glance:277 : mkdir -p /opt/stack/data/glance/images + lib/glance:init_glance:280 : recreate_database glance + lib/database:recreate_database:110 : local db=glance + lib/database:recreate_database:111 : recreate_database_mysql glance + lib/databases/mysql:recreate_database_mysql:63 : local db=glance + lib/databases/mysql:recreate_database_mysql:64 : mysql -uroot -psecretmysql -h127.0.0.1 -e 'DROP DATABASE IF EXISTS glance;' /opt/stack/new/devstack/lib/databases/mysql: line 64: mysql: command not found + lib/databases/mysql:recreate_database_mysql:1 : exit_trap [1] https://review.opendev.org/#/c/702707/ To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1860021/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1858877] Re: Silent wasted storage with multiple RBD backends
** Changed in: nova Status: Confirmed => Invalid -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1858877 Title: Silent wasted storage with multiple RBD backends Status in OpenStack Compute (nova): Invalid Bug description: Nova does not currently support multiple rbd backends. However, Glance does and an operator may point Nova at a Glance with access to multiple RBD clusters. If this happens, Nova will silently download the image from Glance, flatten it, and upload it to the local RBD cluster named privately to the image. If another instance is booted from the same image, this will happen again, using more network resources and duplicating the image on ceph for the second and subsequent instances. When configuring Nova and Glance for shared RBD, the expectation is that instances are fast-cloned from Glance base images, so this silent behavior of using a lot of storage would be highly undesirable and unexpected. Since operators control the backend config, but users upload images (and currently only to one backend), it is the users that would trigger this additional consumption of storage. This isn't really a bug in Nova per se, since Nova does not claim to support multiple backends and is download/uploading the image in the same way it would if the image was located on any other not-the-same- as-my-RBD-cluster location. It is, however, unexpected and undesirable behavior. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1858877/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1839009] Re: os-server-external-events does not behave correctly for failed single events
*** This bug is a duplicate of bug 1855752 *** https://bugs.launchpad.net/bugs/1855752 Sorry, I didn't know about this bug when we opened 1855752. The issue has been fixed under that bug. ** This bug has been marked a duplicate of bug 1855752 Inappropriate HTTP error status from os-server-external-events -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1839009 Title: os-server-external-events does not behave correctly for failed single events Status in OpenStack Compute (nova): New Bug description: The "os-server-external-events" API does not behave correctly when the request body contains a list of one event and if that event ends up in a non-200 state, i.e if the event ends up in either 400 or 404 or 422 states, the function executes all the way to L147 (https://github.com/openstack/nova/blob/433b1662e48db57aaa42e11756fa4a6d8722b386/nova/api/openstack/compute/server_external_events.py#L147) and overall returns a 404 HTTP response without any body. This is wrong since as per the documentation it should return the respective codes (422/404/400) to the client. Infact correctly speaking, if out of the list of provided events, if at least one of them doesn't get into the "accepted_events" list, rest of them are discarded without returning the correct response against each event. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1839009/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1855015] Re: Intermittent fails in nova-next job with "Multiple possible networks found, use a Network ID to be more specific."
*** This bug is a duplicate of bug 1844568 *** https://bugs.launchpad.net/bugs/1844568 I clearly don't know how to make logstash links properly, but I had that query open for the past 10 days and saw hits on many different jobs across multiple projects, including sdk, cinder, and various networking-*s. The largest proportion of hits were in nova & neutron though (possibly simply due to volume of patches in those projects). Anyway, I talked to -neutron and they've identified [1] as a probable dup, so I'll mark this as such. [1] https://launchpad.net/bugs/1844568 ** Changed in: nova Status: Invalid => New ** This bug has been marked a duplicate of bug 1844568 [compute] "create_test_server" if networks is undefined and more than one network is present -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1855015 Title: Intermittent fails in nova-next job with "Multiple possible networks found, use a Network ID to be more specific." Status in OpenStack Compute (nova): New Bug description: There was something similar before [1] but it was 100% and in one job. This is intermittent and in multiple jobs across multiple projects. http://logstash.openstack.org/#/dashboard/file/logstash.json?query=message:%5C%22Multiple%20possible%20networks%20found,%20use%20a%20Network%20ID%20to%20be%20more%20specific%5C%22 [1] https://bugs.launchpad.net/nova/+bug/1822605 To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1855015/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1855015] [NEW] Intermittent fails since 11/23 with "Multiple possible networks found, use a Network ID to be more specific."
Public bug reported: There was something similar before [1] but it was 100% and in one job. This is intermittent and in multiple jobs across multiple projects. http://logstash.openstack.org/#/dashboard/file/logstash.json?query=message:%5C%22Multiple%20possible%20networks%20found,%20use%20a%20Network%20ID%20to%20be%20more%20specific%5C%22 [1] https://bugs.launchpad.net/nova/+bug/1822605 ** Affects: neutron Importance: Undecided Status: New ** Affects: nova Importance: Undecided Status: New ** Also affects: neutron Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1855015 Title: Intermittent fails since 11/23 with "Multiple possible networks found, use a Network ID to be more specific." Status in neutron: New Status in OpenStack Compute (nova): New Bug description: There was something similar before [1] but it was 100% and in one job. This is intermittent and in multiple jobs across multiple projects. http://logstash.openstack.org/#/dashboard/file/logstash.json?query=message:%5C%22Multiple%20possible%20networks%20found,%20use%20a%20Network%20ID%20to%20be%20more%20specific%5C%22 [1] https://bugs.launchpad.net/nova/+bug/1822605 To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1855015/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1854993] [NEW] QoS bandwidth tempest test no longer running
Public bug reported: In [1] the tempest-slow-py3 job was dropped and non-redundant bits folded into the nova-next job. Except we forgot to move over some of the config necessary to make this QoS bandwidth test [2] work, so it gets skipped: setUpClass (tempest.scenario.test_minbw_allocation_placement.MinBwAllocationPlacementTest) ... SKIPPED: Skipped as no physnet is available in config for placement based QoS allocation. We think we just need to get the nova-next job synced up with the config like what was done for tempest-slow here [3]. [1] https://review.opendev.org/#/c/683988/ [2] https://github.com/openstack/tempest/blob/3eb3c29e979fd3f13c205d62119748952d63054a/tempest/scenario/test_minbw_allocation_placement.py#L142 [3] https://github.com/openstack/tempest/commit/c87a06b3c29427dc8f2513047c804e0410b4b99c ** Affects: nova Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1854993 Title: QoS bandwidth tempest test no longer running Status in OpenStack Compute (nova): New Bug description: In [1] the tempest-slow-py3 job was dropped and non-redundant bits folded into the nova-next job. Except we forgot to move over some of the config necessary to make this QoS bandwidth test [2] work, so it gets skipped: setUpClass (tempest.scenario.test_minbw_allocation_placement.MinBwAllocationPlacementTest) ... SKIPPED: Skipped as no physnet is available in config for placement based QoS allocation. We think we just need to get the nova-next job synced up with the config like what was done for tempest-slow here [3]. [1] https://review.opendev.org/#/c/683988/ [2] https://github.com/openstack/tempest/blob/3eb3c29e979fd3f13c205d62119748952d63054a/tempest/scenario/test_minbw_allocation_placement.py#L142 [3] https://github.com/openstack/tempest/commit/c87a06b3c29427dc8f2513047c804e0410b4b99c To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1854993/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1709118] Re: _ContextAuthPlugin needs a refresh
> It's possible https://review.openstack.org/#/c/500956/ will help with this. It did. I still think we could stand to figure out how to get rid of _ContextAuthPlugin, but it's not breaking anything anymore, so closing this bug out for the time being. ** Changed in: nova Status: Confirmed => Invalid -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1709118 Title: _ContextAuthPlugin needs a refresh Status in OpenStack Compute (nova): Invalid Bug description: nova.context._ContextAuthPlugin is (sometimes) being used as the basis for keystoneauth1 endpoint discovery. With the advent of ksa 3.1.0, there are some new methods consumers are expecting to be able to run on an auth via a ksa Session or Adapter. (Note that they were added to BaseIdentityPlugin without being added as abstract methods to BaseAuthPlugin - this is probably a ksa bug.) An example of such a method is get_endpoint_data(). Now, it appears from the docstring that the only reason _ContextAuthPlugin exists is that the auths we get from keystone middleware are not serializable. This may have changed since that docstring was written in 2014. So: we should either update _ContextAuthPlugin to provide the methods ksa expects (perhaps in response to a fixup in ksa's BaseAuthPlugin abc that mandates those methods be implemented); or (better) figure out a way to get rid of _ContextAuthPlugin entirely and just use what keystone provides. A manifestation of this problem can be seen in the work for bp use- service-catalog-for-endpoints. This change [1] is in response to ksa Adapter.get_endpoint_data() raising AttributeError because Adapter.get_endpoint_data eventually filters down to Adapter.auth.get_endpoint_data; which breaks when the auth is a _ContextAuthPlugin. [1] https://review.openstack.org/#/c/490057/3..4/nova/image/glance.py To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1709118/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1845530] [NEW] Versioned discovery endpoint should not require authentication
Public bug reported:
stack@nucle:/opt/stack/cyborg$ openstack endpoint list
+--+---+--++-+---+-+
| ID | Region| Service Name | Service Type
| Enabled | Interface | URL |
+--+---+--++-+---+-+
| 9d483c8a6162422282514191683751cb | RegionOne | nova | compute
| True| public| http://192.168.218.28/compute/v2.1 |
+--+---+--++-+---+-+
stack@nucle:/opt/stack/cyborg$ curl http://192.168.218.28/compute/v2.1
{"error": {"message": "The request you have made requires authentication.",
"code": 401, "title": "Unauthorized"}}
Discovery endpoints should not require authentication.
(I'm still looking for the doc that contains this edict; but ask mordred
or anyone on the api-sig.)
** Affects: nova
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1845530
Title:
Versioned discovery endpoint should not require authentication
Status in OpenStack Compute (nova):
New
Bug description:
stack@nucle:/opt/stack/cyborg$ openstack endpoint list
+--+---+--++-+---+-+
| ID | Region| Service Name | Service Type
| Enabled | Interface | URL |
+--+---+--++-+---+-+
| 9d483c8a6162422282514191683751cb | RegionOne | nova | compute
| True| public| http://192.168.218.28/compute/v2.1 |
+--+---+--++-+---+-+
stack@nucle:/opt/stack/cyborg$ curl http://192.168.218.28/compute/v2.1
{"error": {"message": "The request you have made requires authentication.",
"code": 401, "title": "Unauthorized"}}
Discovery endpoints should not require authentication.
(I'm still looking for the doc that contains this edict; but ask
mordred or anyone on the api-sig.)
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1845530/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1844174] [NEW] test_fail_set_az fails intermittently with "AssertionError: OpenStackApiException not raised by _set_az_aggregate"
Public bug reported: Since 20190910 we've hit this 10x: 8x in functional and 2x in functional-py36 http://logstash.openstack.org/#dashboard/file/logstash.json?query=message%3A%5C%22OpenStackApiException%20not%20raised%20by%20_set_az_aggregate%5C%22 It looks to be a NoValidHosts caused by 2019-09-16 15:10:21,389 INFO [nova.filters] Filter AvailabilityZoneFilter returned 0 hosts 2019-09-16 15:10:21,390 INFO [nova.filters] Filtering removed all hosts for the request with instance ID 'e1ae6109-2bc2-4a40-9249-3dee7d5e80b5'. Filter results: ['AvailabilityZoneFilter: (start: 2, end: 0)'] Here's one example: https://14cb8680ad7e2d5893c2-a0a2161f988b6356e48326da15450ffb.ssl.cf1.rackcdn.com/671800/36/check /nova-tox-functional-py36/abc690a/testr_results.html.gz or pasted here for when ^ expires: http://paste.openstack.org/raw/776821/ ** Affects: nova Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1844174 Title: test_fail_set_az fails intermittently with "AssertionError: OpenStackApiException not raised by _set_az_aggregate" Status in OpenStack Compute (nova): New Bug description: Since 20190910 we've hit this 10x: 8x in functional and 2x in functional-py36 http://logstash.openstack.org/#dashboard/file/logstash.json?query=message%3A%5C%22OpenStackApiException%20not%20raised%20by%20_set_az_aggregate%5C%22 It looks to be a NoValidHosts caused by 2019-09-16 15:10:21,389 INFO [nova.filters] Filter AvailabilityZoneFilter returned 0 hosts 2019-09-16 15:10:21,390 INFO [nova.filters] Filtering removed all hosts for the request with instance ID 'e1ae6109-2bc2-4a40-9249-3dee7d5e80b5'. Filter results: ['AvailabilityZoneFilter: (start: 2, end: 0)'] Here's one example: https://14cb8680ad7e2d5893c2-a0a2161f988b6356e48326da15450ffb.ssl.cf1.rackcdn.com/671800/36/check /nova-tox-functional-py36/abc690a/testr_results.html.gz or pasted here for when ^ expires: http://paste.openstack.org/raw/776821/ To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1844174/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1843439] [NEW] doc: Rebuild vs. Evacuate (and other move-ish ops)
Public bug reported: Following discussion on IRC [1], it would be nice to have a contributor document describing the differences among the various move-ish operations -- for purposes of this bug, just rebuild and evacuate -- in terms of what happens to their allocations, images, UUIDs (instance vs migration), hosts (dest same/different from src), etc. [1] http://eavesdrop.openstack.org/irclogs/%23openstack-nova /%23openstack-nova.2019-09-10.log.html#t2019-09-10T13:31:17 ** Affects: nova Importance: Low Assignee: Matt Riedemann (mriedem) Status: Confirmed ** Tags: doc evacuate rebuild -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1843439 Title: doc: Rebuild vs. Evacuate (and other move-ish ops) Status in OpenStack Compute (nova): Confirmed Bug description: Following discussion on IRC [1], it would be nice to have a contributor document describing the differences among the various move-ish operations -- for purposes of this bug, just rebuild and evacuate -- in terms of what happens to their allocations, images, UUIDs (instance vs migration), hosts (dest same/different from src), etc. [1] http://eavesdrop.openstack.org/irclogs/%23openstack-nova /%23openstack-nova.2019-09-10.log.html#t2019-09-10T13:31:17 To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1843439/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1840551] Re: Kombu 4.6.4 is breaking with python 3.7
https://review.opendev.org/#/c/677070/ is merged to blacklist kombu 4.6.4 https://review.opendev.org/#/c/677071/ ought to prevent similar snafus in future ** Changed in: nova Status: In Progress => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1840551 Title: Kombu 4.6.4 is breaking with python 3.7 Status in OpenStack Compute (nova): Fix Released Bug description: Since [0], nova's openstack-tox-py37 job is failing this many: Status: Pass 97 Failure 17112 Skip 20 with this error: TypeError: open: path should be string, bytes or os.PathLike, not _NormalAccessor See this ML thread [1] for root cause analysis. Proposed [2] against requirements to blacklist kombu 4.6.4. [0] https://review.opendev.org/#/c/675816/ [1] http://lists.openstack.org/pipermail/openstack-discuss/2019-August/008553.html [2] https://review.opendev.org/#/c/677070/ To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1840551/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1840551] [NEW] Kombu 4.6.4 is breaking with python 3.7
Public bug reported: Since [0], nova's openstack-tox-py37 job is failing this many: Status: Pass 97 Failure 17112 Skip 20 with this error: TypeError: open: path should be string, bytes or os.PathLike, not _NormalAccessor See this ML thread [1] for root cause analysis. Proposed [2] against requirements to blacklist kombu 4.6.4. [0] https://review.opendev.org/#/c/675816/ [1] http://lists.openstack.org/pipermail/openstack-discuss/2019-August/008553.html [2] https://review.opendev.org/#/c/677070/ ** Affects: nova Importance: Critical Assignee: Eric Fried (efried) Status: In Progress -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1840551 Title: Kombu 4.6.4 is breaking with python 3.7 Status in OpenStack Compute (nova): In Progress Bug description: Since [0], nova's openstack-tox-py37 job is failing this many: Status: Pass 97 Failure 17112 Skip 20 with this error: TypeError: open: path should be string, bytes or os.PathLike, not _NormalAccessor See this ML thread [1] for root cause analysis. Proposed [2] against requirements to blacklist kombu 4.6.4. [0] https://review.opendev.org/#/c/675816/ [1] http://lists.openstack.org/pipermail/openstack-discuss/2019-August/008553.html [2] https://review.opendev.org/#/c/677070/ To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1840551/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1836263] [NEW] doc: PUT /ports/{port_id} updates selectively
Public bug reported:
Based on noted usage in Nova [1], it appears as though PUT
/v2/ports/{port_id} [2] with a payload like
{ "port":
"foo": ...,
}
will update only port.foo on the server, leaving all the other contents
of the port untouched.
That is, you can GET-extract-PUT rather than GET-modify-PUT.
I assume (but am not certain) this is restricted to the top-level keys
listed in the table in the API reference. So for example, if the port
previously looked like
{ "port":
...,
"dns_assignment": {
"hostname": "myport",
"ip_address": "20.20.0.4",
"fqdn": "myport.my-domain.org"
},
...,
}
and I PUT /v2/ports/{port_id} with
{ "port":
"dns_assignment": {
"ip_address": "10.10.0.4",
},
}
I will wind up with no "hostname" or "fqdn" in my port.dns_assignment.
I'm also not certain what happens if I send a `null`
{ "port":
"binding:profile": null
}
Do I wind up with port.binding:profile == {}, null, or absent?
===
This bug is to request that the API reference documentation be enhanced
to include this information for PUT /v2/ports/{port_id}.
(It's possible that similar principles apply to PUTting other resources
as well -- I didn't check -- in which case it may make sense to write a
section in the front matter explaining the principle and linking to it
from the various operations.)
[1]
http://codesearch.openstack.org/?q=%5C.update_port%5C(=nope==openstack/nova
[2]
https://developer.openstack.org/api-ref/network/v2/?expanded=update-port-detail#update-port
** Affects: neutron
Importance: Undecided
Status: New
** Tags: doc
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1836263
Title:
doc: PUT /ports/{port_id} updates selectively
Status in neutron:
New
Bug description:
Based on noted usage in Nova [1], it appears as though PUT
/v2/ports/{port_id} [2] with a payload like
{ "port":
"foo": ...,
}
will update only port.foo on the server, leaving all the other
contents of the port untouched.
That is, you can GET-extract-PUT rather than GET-modify-PUT.
I assume (but am not certain) this is restricted to the top-level keys
listed in the table in the API reference. So for example, if the port
previously looked like
{ "port":
...,
"dns_assignment": {
"hostname": "myport",
"ip_address": "20.20.0.4",
"fqdn": "myport.my-domain.org"
},
...,
}
and I PUT /v2/ports/{port_id} with
{ "port":
"dns_assignment": {
"ip_address": "10.10.0.4",
},
}
I will wind up with no "hostname" or "fqdn" in my port.dns_assignment.
I'm also not certain what happens if I send a `null`
{ "port":
"binding:profile": null
}
Do I wind up with port.binding:profile == {}, null, or absent?
===
This bug is to request that the API reference documentation be
enhanced to include this information for PUT /v2/ports/{port_id}.
(It's possible that similar principles apply to PUTting other
resources as well -- I didn't check -- in which case it may make sense
to write a section in the front matter explaining the principle and
linking to it from the various operations.)
[1]
http://codesearch.openstack.org/?q=%5C.update_port%5C(=nope==openstack/nova
[2]
https://developer.openstack.org/api-ref/network/v2/?expanded=update-port-detail#update-port
To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1836263/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1822605] [NEW] nova-live-migration fails 100% with "Multiple possible networks found, use a Network ID to be more specific"
Public bug reported: Over the weekend (so since about 3/29) the nova-live-migration job has been failing 100% with the message: "Multiple possible networks found, use a Network ID to be more specific" Example: http://logs.openstack.org/12/648912/1/check/nova-live- migration/48932a5/job-output.txt.gz#_2019-04-01_08_27_07_901239 Matt identified this as a suspect: https://review.openstack.org/#/c/601433/ ...since it causes us now to create multiple networks. In tempest a network is always explicitly given, but in the nova-live-migration job it's not. ** Affects: nova Importance: Critical Status: Triaged ** Tags: gate-failure -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1822605 Title: nova-live-migration fails 100% with "Multiple possible networks found, use a Network ID to be more specific" Status in OpenStack Compute (nova): Triaged Bug description: Over the weekend (so since about 3/29) the nova-live-migration job has been failing 100% with the message: "Multiple possible networks found, use a Network ID to be more specific" Example: http://logs.openstack.org/12/648912/1/check/nova-live- migration/48932a5/job-output.txt.gz#_2019-04-01_08_27_07_901239 Matt identified this as a suspect: https://review.openstack.org/#/c/601433/ ...since it causes us now to create multiple networks. In tempest a network is always explicitly given, but in the nova-live-migration job it's not. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1822605/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1811726] [NEW] Deleting compute service only deletes "first" ironic node from placement
Public bug reported: NB: This comes from code inspection, not observed behavior. When the compute service is deleted, we attempt to delete from placement the resource provider associated with the compute node associated with the service [1]. But ironic deployments can have multiple compute nodes. In this case, the compute node associated with the service is the "first" such node [2]. What happens then is the compute node records are deleted, leaving the remaining N-1 nodes' provider records orphaned. Those get cleaned up (I think?) by update_available_resource when the service is recreated [3]. So we're deleting and recreating the ironic node resource providers, but in a weird order. We should probably either fix the code at [1] to delete all of them, or none of them (and let the orphan handling code do all the work). [1] https://github.com/openstack/nova/blob/da98f4ba4554139b3901103aa0d26876b11e1d9a/nova/api/openstack/compute/services.py#L244-L247 [2] https://github.com/openstack/nova/blob/da98f4ba4554139b3901103aa0d26876b11e1d9a/nova/objects/service.py#L308-L311 [3] https://github.com/openstack/nova/blob/da98f4ba4554139b3901103aa0d26876b11e1d9a/nova/compute/manager.py#L7757-L7771 ** Affects: nova Importance: Undecided Status: New ** Tags: api compute ironic placement -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1811726 Title: Deleting compute service only deletes "first" ironic node from placement Status in OpenStack Compute (nova): New Bug description: NB: This comes from code inspection, not observed behavior. When the compute service is deleted, we attempt to delete from placement the resource provider associated with the compute node associated with the service [1]. But ironic deployments can have multiple compute nodes. In this case, the compute node associated with the service is the "first" such node [2]. What happens then is the compute node records are deleted, leaving the remaining N-1 nodes' provider records orphaned. Those get cleaned up (I think?) by update_available_resource when the service is recreated [3]. So we're deleting and recreating the ironic node resource providers, but in a weird order. We should probably either fix the code at [1] to delete all of them, or none of them (and let the orphan handling code do all the work). [1] https://github.com/openstack/nova/blob/da98f4ba4554139b3901103aa0d26876b11e1d9a/nova/api/openstack/compute/services.py#L244-L247 [2] https://github.com/openstack/nova/blob/da98f4ba4554139b3901103aa0d26876b11e1d9a/nova/objects/service.py#L308-L311 [3] https://github.com/openstack/nova/blob/da98f4ba4554139b3901103aa0d26876b11e1d9a/nova/compute/manager.py#L7757-L7771 To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1811726/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1789654] Re: placement allocation_ratio initialized with 0.0
This was fixed by https://review.openstack.org/#/c/598365/ ** Changed in: nova Status: In Progress => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1789654 Title: placement allocation_ratio initialized with 0.0 Status in OpenStack Compute (nova): Fix Released Status in OpenStack Compute (nova) rocky series: In Progress Bug description: After I just finished packaging Rocky, I wanted to test it with puppet-openstack. Then I couldn't boot VMs after the puppet run, because allocation_ration in placement is set to 0.0 by default: # openstack resource provider list +--+---++ | uuid | name | generation | +--+---++ | f9716941-356f-4a2e-b5ea-31c3c1630892 | poi.infomaniak.ch | 2 | +--+---++ # openstack resource provider show f9716941-356f-4a2e-b5ea-31c3c1630892 ++--+ | Field | Value| ++--+ | uuid | f9716941-356f-4a2e-b5ea-31c3c1630892 | | name | poi.infomaniak.ch| | generation | 2| ++--+ # openstack resource provider inventory list f9716941-356f-4a2e-b5ea-31c3c1630892 ++--+---+--+---+--+--+ | resource_class | reserved | step_size | allocation_ratio | total | min_unit | max_unit | ++--+---+--+---+--+--+ | VCPU |0 | 1 | 0.0 | 4 |1 |4 | | DISK_GB|0 | 1 | 0.0 |19 |1 | 19 | | MEMORY_MB | 512 | 1 | 0.0 | 7987 |1 | 7987 | ++--+---+--+---+--+--+ Later on, setting-up correct allocation_ratio fixed the problem: # openstack resource provider inventory class set --allocation_ratio 16.0 --total 4 f9716941-356f-4a2e-b5ea-31c3c1630892 VCPU +--++ | Field| Value | +--++ | max_unit | 2147483647 | | min_unit | 1 | | step_size| 1 | | reserved | 0 | | allocation_ratio | 16.0 | | total| 4 | +--++ # openstack resource provider inventory list f9716941-356f-4a2e-b5ea-31c3c1630892 ++--+--++---+--+---+ | resource_class | allocation_ratio | reserved | max_unit | step_size | min_unit | total | ++--+--++---+--+---+ | DISK_GB| 0.0 |0 | 19 | 1 | 1 |19 | | MEMORY_MB | 0.0 | 512 | 7987 | 1 | 1 | 7987 | | VCPU | 16.0 |0 | 2147483647 | 1 | 1 | 4 | ++--+--++---+--+---+ so, after this, I could boot VMs normally. Though clearly, allocation_ratio should not be zero by default. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1789654/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1777491] Re: Avoid redundant compute node update
*** This bug is a duplicate of bug 1729621 *** https://bugs.launchpad.net/bugs/1729621 ** This bug has been marked a duplicate of bug 1729621 Inconsistent value for vcpu_used -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1777491 Title: Avoid redundant compute node update Status in OpenStack Compute (nova): In Progress Bug description: _update_available_resource() in nova/compute/resource_tracker.py invokes _init_compute_node() which internally calls _update() and once again _update() is invoked at the end of _update_available_resource(). https://github.com/openstack/nova/blob/master/nova/compute/resource_tracker.py#L762 This triggers update_provider_tree() or get_inventory() on the virt driver, scanning all resources twice within same method. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1777491/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1737711] Re: nova boot failed when use the chinese metadata key and value
More core team discussion [1] concluded that, if we're going to do this,
it's going to need a blueprint/spec and most likely a microversion. If
you wish to pursue it, you may register a blueprint here [2] and submit
a spec to the nova-specs repository. More information on this process
can be found at [3].
Thanks!
[1]
http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2018-07-30.log.html#t2018-07-30T18:32:33
[2] https://blueprints.launchpad.net/nova/+addspec
[3] https://docs.openstack.org/nova/latest/contributor/blueprints.html
** Changed in: nova
Importance: Undecided => Wishlist
** Changed in: nova
Status: In Progress => Invalid
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1737711
Title:
nova boot failed when use the chinese metadata key and value
Status in OpenStack Compute (nova):
Invalid
Bug description:
I get the wrong msg like bellow:
Invalid input for field/attribute metadata. Value:
{u'\\u4e2d\\u6587\\u5143\\u6570\\u636e':
u'\u963f\u65af\u987f\u53d1\u751f'}. Additional properties are not
allowed (u'\\u4e2d\\u6587\\u5143\\u6570\\u636e' was unexpected) (HTTP
400) (Request-ID: req-3e9ea1d0-8384-41e9-8b00-36e6740262e4)
I think it't better to support the chinese key.
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1737711/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1781439] [NEW] Test & document 1.28 (consumer gen) changes for /resource_providers/{u}/allocations
Public bug reported:
I978fdea51f2d6c2572498ef80640c92ab38afe65 /
https://review.openstack.org/#/c/565604/ added placement microversion
1.28, which made various API operations consumer generation-aware. One
of the affected routes was /resource_providers/{u}/allocations - but
this route wasn't covered in the gabbi tests or the API reference
documentation.
** Affects: nova
Importance: Undecided
Status: New
** Tags: placement
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1781439
Title:
Test & document 1.28 (consumer gen) changes for
/resource_providers/{u}/allocations
Status in OpenStack Compute (nova):
New
Bug description:
I978fdea51f2d6c2572498ef80640c92ab38afe65 /
https://review.openstack.org/#/c/565604/ added placement microversion
1.28, which made various API operations consumer generation-aware. One
of the affected routes was /resource_providers/{u}/allocations - but
this route wasn't covered in the gabbi tests or the API reference
documentation.
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1781439/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1781008] [NEW] Possible race updating consumer's proj/user
Public bug reported: This is to track [1] so we don't lose sight of it. We first need to figure out a way to test this scenario to see if this is an issue at all. [1] https://review.openstack.org/#/c/581139/3/nova/api/openstack/placement/util.py@650 ** Affects: nova Importance: Undecided Assignee: Jay Pipes (jaypipes) Status: New ** Tags: placement -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1781008 Title: Possible race updating consumer's proj/user Status in OpenStack Compute (nova): New Bug description: This is to track [1] so we don't lose sight of it. We first need to figure out a way to test this scenario to see if this is an issue at all. [1] https://review.openstack.org/#/c/581139/3/nova/api/openstack/placement/util.py@650 To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1781008/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1778591] Re: GET /allocations/{uuid} on a consumer with no allocations provides no generation
This bug is still relevant. Excerpt from
https://review.openstack.org/#/c/579163/:
The current behavior
status: 200
{
"allocations": {}
}
is wrong because the response payload doesn't conform to the expected
format, which would contain a consumer_generation, project_id, and
user_id. That those fields don't make sense in a context where there's
no consumer is another motivator for making this a 4xx failure.
** Changed in: nova
Status: Won't Fix => Triaged
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1778591
Title:
GET /allocations/{uuid} on a consumer with no allocations provides no
generation
Status in OpenStack Compute (nova):
In Progress
Bug description:
If we write some allocations with PUT /allocations/{uuid} at modern
microversions, a consumer record is created for {uuid} and a
generation is created for that consumer. Each subsequent attempt to
PUT /allocations/{uuid} must include a matching consumer generation.
If the allocations for a consumer are cleared (either DELETE, or PUT
/allocations/{uuid} with an empty dict of allocations) two things go
awry:
* the consumer record, with a generation, stays around
* GET /allocations/{uuid} returns the following:
{u'allocations': {}}
That is, no generation is provided, and we have no way figure one out
other than inspecting the details of the error response.
Some options to address this:
* Return the generation in that response
* When the allocations for a consumer go empty, remove the consumer
* Something else?
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1778591/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1778576] Re: making new allocations for one consumer against multiple resource providers fails with 409
This is fixed as part of https://review.openstack.org/#/c/579921/ ** Changed in: nova Status: In Progress => Fix Released ** Changed in: nova Assignee: Chris Dent (cdent) => Jay Pipes (jaypipes) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1778576 Title: making new allocations for one consumer against multiple resource providers fails with 409 Status in OpenStack Compute (nova): Fix Released Bug description: If you PUT some allocations for a new consumer (thus no generation), and those allocations are against more than one resource provider, a 409 failure will happen with: consumer generation conflict - expected 0 but got None This because in _new_allocations in handlers/allocation.py we always use the generation provided in the incoming data when we call util.ensure_consumer. This works for the first resource provider but then on the second one the consumer exists, so our generation has to be different now. One possible fix (already in progress) is to use the generation from new_allocations[0].consumer.generation in subsequent trips round the loop calling _new_allocations. I guess we must have missed some test cases. I'll make sure to add some when working on this. I found the problem with my placecat stuff. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1778576/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1779931] [NEW] Provider update race between host aggregate sync and resource tracker
Public bug reported:
The resource tracker (in n-cpu) used to be the only place we were
pushing changes to placement, all funneled through a single mutex
(COMPUTE_RESOURCE_SEMAPHORE) to prevent conflicts.
When we started mirroring host aggregates as placement aggregates [1],
which happens in the n-api process, we introduced races with the
resource tracker e.g. as follows:
n-api: aggregate_add_host => _get_provider_by_name [2]
n-cpu: get_provider_tree_and_ensure_root [3]
n-api: set_aggregates_for_provider [4]
n-cpu: update_from_provider_tree [5] => set_aggregates_for_provider [6]
(similar for aggregate_remove_host)
Whoever gets to set_aggregates_for_provider first will push their view
of the aggregates to placement. Until we start checking for generation
conflicts in set_aggregates_for_provider, whoever gets there second will
simply blow away the first one. Therefore it won't cause failures and
we wouldn't notice.
Once we do start checking for generation conflicts in
set_aggregates_for_provider [7], we start seeing actual failures, like:
tempest.api.compute.admin.test_aggregates.AggregatesAdminTestJSON.test_aggregate_add_host_get_details[id-eeef473c-7c52-494d-9f09-2ed7fc8fc036]
--
Captured traceback-1:
~
Traceback (most recent call last):
File "tempest/lib/common/utils/test_utils.py", line 84, in
call_and_ignore_notfound_exc
return func(*args, **kwargs)
File "tempest/lib/services/compute/aggregates_client.py", line 70, in
delete_aggregate
resp, body = self.delete("os-aggregates/%s" % aggregate_id)
File "tempest/lib/common/rest_client.py", line 310, in delete
return self.request('DELETE', url, extra_headers, headers, body)
File "tempest/lib/services/compute/base_compute_client.py", line 48, in
request
method, url, extra_headers, headers, body, chunked)
File "tempest/lib/common/rest_client.py", line 668, in request
self._error_checker(resp, resp_body)
File "tempest/lib/common/rest_client.py", line 779, in _error_checker
raise exceptions.BadRequest(resp_body, resp=resp)
tempest.lib.exceptions.BadRequest: Bad request
Details: {u'code': 400, u'message': u'Cannot remove host from aggregate 2.
Reason: Host aggregate is not empty.'}
...
Captured traceback:
~~~
Traceback (most recent call last):
File "tempest/api/compute/admin/test_aggregates.py", line 193, in
test_aggregate_add_host_get_details
self.client.add_host(aggregate['id'], host=self.host)
File "tempest/lib/services/compute/aggregates_client.py", line 95, in
add_host
post_body)
File "tempest/lib/common/rest_client.py", line 279, in post
return self.request('POST', url, extra_headers, headers, body, chunked)
File "tempest/lib/services/compute/base_compute_client.py", line 48, in
request
method, url, extra_headers, headers, body, chunked)
File "tempest/lib/common/rest_client.py", line 668, in request
self._error_checker(resp, resp_body)
File "tempest/lib/common/rest_client.py", line 845, in _error_checker
message=message)
tempest.lib.exceptions.ServerFault: Got server fault
Details: Unexpected API Error. Please report this at
http://bugs.launchpad.net/nova/ and attach the Nova API log if possible.
[1] https://review.openstack.org/#/c/553597/
[2]
https://github.com/openstack/nova/blob/df5c253b58f82dcca7f59ac34fc8b8b51e824ca4/nova/scheduler/client/report.py#L1935
[3]
https://github.com/openstack/nova/blob/ee7c39e4416e215d5bf5fbf07c0a8a4301828248/nova/compute/resource_tracker.py#L883
[4]
https://github.com/openstack/nova/blob/df5c253b58f82dcca7f59ac34fc8b8b51e824ca4/nova/scheduler/client/report.py#L1956
[5]
https://github.com/openstack/nova/blob/ee7c39e4416e215d5bf5fbf07c0a8a4301828248/nova/compute/resource_tracker.py#L897
[6]
https://github.com/openstack/nova/blob/df5c253b58f82dcca7f59ac34fc8b8b51e824ca4/nova/scheduler/client/report.py#L1454
[7] https://review.openstack.org/#/c/556669/
** Affects: nova
Importance: Undecided
Status: New
** Tags: placement
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1779931
Title:
Provider update race between host aggregate sync and resource tracker
Status in OpenStack Compute (nova):
New
Bug description:
The resource tracker (in n-cpu) used to be the only place we were
pushing changes to placement, all funneled through a single mutex
(COMPUTE_RESOURCE_SEMAPHORE) to prevent conflicts.
When we started mirroring host aggregates as placement aggregates [1],
which happens in the n-api process, we introduced races with the
resource tracker
[Yahoo-eng-team] [Bug 1778498] Re: cannot launch instance
This appears to be a user error: 'htpp://' is misspelled, should be 'http://'. This URL comes from nova.conf or the service catalog. ** Changed in: nova Status: New => Invalid -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1778498 Title: cannot launch instance Status in OpenStack Compute (nova): Invalid Bug description: i have problem while to launch the instance, i'm using ubuntu 18.04 LTS and openstack Queen. And when i want to launch instance i got this error "Unexpected API Error. Please report this at http://bugs.launchpad.net/nova/ and attach the Nova API log if possible. (HTTP 500) (Request-ID: req-7302d9ed-0485-4714-9e57-c15d21a66dbd" and this is the compute service (nova-api) log : "2018-06-25 10:53:01.724 2634 ERROR nova.api.openstack.wsgi return self.session.request(url, method, **kwargs) 2018-06-25 10:53:01.724 2634 ERROR nova.api.openstack.wsgi File "/usr/lib/python2.7/dist-packages/keystoneauth1/session.py", line 698, in request 2018-06-25 10:53:01.724 2634 ERROR nova.api.openstack.wsgi resp = send(**kwargs) 2018-06-25 10:53:01.724 2634 ERROR nova.api.openstack.wsgi File "/usr/lib/python2.7/dist-packages/keystoneauth1/session.py", line 776, in _send_request 2018-06-25 10:53:01.724 2634 ERROR nova.api.openstack.wsgi raise exceptions.UnknownConnectionError(msg, e) 2018-06-25 10:53:01.724 2634 ERROR nova.api.openstack.wsgi UnknownConnectionError: Unexpected exception for htpp://controller:9696/v2.0/security-groups?fields=id=adf0b87b-28d0-4295-a6dd-222ed065ffc2: No connection adapters were found for 'htpp://controller:9696/v2.0/security-groups?fields=id=adf0b87b-28d0-4295-a6dd-222ed065ffc2' 2018-06-25 10:53:01.724 2634 ERROR nova.api.openstack.wsgi 2018-06-25 10:53:01.729 2634 INFO nova.api.openstack.wsgi [req-5bfdf750-70c1-470b-b849-895a60c4deb0 - - - - -] HTTP exception thrown: Unexpected API Error. Please report this at http://bugs.launchpad.net/nova/ and attach the Nova API log if possible. 2018-06-25 10:53:01.737 2634 INFO nova.osapi_compute.wsgi.server [req-5bfdf750-70c1-470b-b849-895a60c4deb0 - - - - -] 20.20.20.10 "POST /v2.1/servers HTTP/1.1" status: 500 len: 665 time: 0.8935342" To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1778498/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1778763] [NEW] Consumers never get deleted
Public bug reported: We don't have an API to delete a consumer. It gets created implicitly when allocations are created against it, but it doesn't get deleted when the consumer's last allocation is removed. In some uses of placement, such as nova's, there is a high rate of turnover of consumers (instances, in nova) so this leakage has the potential to be problematic. (Note that we have the same issue for aggregates, but don't currently have a known use case with a lot of aggregate turnover, so it is less likely to be a problem soon.) Possible solutions: - Delete a consumer record automatically when its last allocation goes away. This is nice and symmetrical, but a behavior change for the guy *recreating* a consumer (today he has to use the current generation; with this change he would have to use ``null``). - Provide an operation for deleting consumers. This is an extra step for callers (which is okay). But do we also provide an explicit (redundant) operation for creating them, just for the sake of symmetry? - Your idea here. ** Affects: nova Importance: Undecided Status: New ** Tags: placement -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1778763 Title: Consumers never get deleted Status in OpenStack Compute (nova): New Bug description: We don't have an API to delete a consumer. It gets created implicitly when allocations are created against it, but it doesn't get deleted when the consumer's last allocation is removed. In some uses of placement, such as nova's, there is a high rate of turnover of consumers (instances, in nova) so this leakage has the potential to be problematic. (Note that we have the same issue for aggregates, but don't currently have a known use case with a lot of aggregate turnover, so it is less likely to be a problem soon.) Possible solutions: - Delete a consumer record automatically when its last allocation goes away. This is nice and symmetrical, but a behavior change for the guy *recreating* a consumer (today he has to use the current generation; with this change he would have to use ``null``). - Provide an operation for deleting consumers. This is an extra step for callers (which is okay). But do we also provide an explicit (redundant) operation for creating them, just for the sake of symmetry? - Your idea here. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1778763/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1770549] Re: Set instance's description failed
This is invalid for the reason you state in comment #1. More specifically: when you call the API with versions <2.19, you get the name as the description; when you call with >=2.19, you get the user- supplied description or None. We can't change that behavior, per the rules of API versioning. So really the "problem" is that whereas novaclient negotiates the highest mutually supported version with the server, openstackclient defaults to the earliest. But that version can be overridden via option or env, and that's the correct "solution". Now, if you're saying that openstack client doesn't yet have support for user-settable descriptions... that's a bug against openstackclient which would need to be solved there. ** Changed in: nova Status: In Progress => Invalid -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1770549 Title: Set instance's description failed Status in OpenStack Compute (nova): Invalid Bug description: Create an instance, using novaclient and openstackclient will get different value for the description. novaclient: description is None. openstackclient: description is instance's name. Using novaclient the API request version is 2.53, but the openstackclient is 2.1. If we wants to add description using openstackclient(not implement yet), the instance's description will get the instance's name forever. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1770549/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1769854] Re: Local disk without enough capacity appears in allocation candidates
This was fixed incidentally via 9af073384cca305565e741c1dfbb359c1e562a4e See related fix. ** Changed in: nova Status: Confirmed => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1769854 Title: Local disk without enough capacity appears in allocation candidates Status in OpenStack Compute (nova): Fix Released Bug description: How to reproduce - In placement, 1. Setup a compute node resource provider with inventories of - 24 VCPU - 2048 MEMORY_MB - 1600 DISK_GB 2. Setup a shared storage resource provider with "MISC_SHARES_VIA_AGGREGATE" tag with - 2000 DISK_GB inventory 3. Set them both in a same aggregate 4. Get allocation candidates requesting - 1 VCPU - 64 MEMORY_MB - 1800 DISK_GB inventory. Expected - Get one allocation request where DISK inventory is provided by the shared storage Actual -- Get two allocation request, in one of which DISK inventory is provided by the compute node To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1769854/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1766692] [NEW] instance.uuid no longer being a str breaks powervm scsi disconnect
Public bug reported: Long-standing code in pypowervm [1] used isinstance(..., str) to help identify whether an input was a UUID or an integer short ID. This is used with to find SCSI mappings [2] with Instance.uuid [3] when disconnecting a disk during destroy [4]. Then this change in oslo.versionedobjects happened [5], resulting in instance.uuid no longer being a str. So the check at [1] fails, and we try to int() a UUID string, resulting in [6], pasted here in case that link expires: PowerVM error destroying instance.: ValueError: invalid literal for int() with base 10: '4E27E1E6-6A24-4F0A-8E7B-2BBE7B4A28BA' Traceback (most recent call last): File "/opt/stack/nova-powervm/nova_powervm/virt/powervm/driver.py", line 672, in _destroy _setup_flow_and_run() File "/opt/stack/nova-powervm/nova_powervm/virt/powervm/driver.py", line 668, in _setup_flow_and_run tf_base.run(flow, instance=instance) File "/opt/stack/nova-powervm/nova_powervm/virt/powervm/tasks/base.py", line 40, in run return eng.run() File "/usr/local/lib/python2.7/dist-packages/taskflow/engines/action_engine/engine.py", line 247, in run for _state in self.run_iter(timeout=timeout): File "/usr/local/lib/python2.7/dist-packages/taskflow/engines/action_engine/engine.py", line 340, in run_iter failure.Failure.reraise_if_any(er_failures) File "/usr/local/lib/python2.7/dist-packages/taskflow/types/failure.py", line 336, in reraise_if_any failures[0].reraise() File "/usr/local/lib/python2.7/dist-packages/taskflow/types/failure.py", line 343, in reraise six.reraise(*self._exc_info) File "/usr/local/lib/python2.7/dist-packages/taskflow/engines/action_engine/executor.py", line 53, in _execute_task result = task.execute(**arguments) File "/opt/stack/nova-powervm/nova_powervm/virt/powervm/tasks/storage.py", line 452, in execute self.instance, stg_ftsk=self.stg_ftsk, disk_type=self.disk_type) File "/opt/stack/nova-powervm/nova_powervm/virt/powervm/disk/ssp.py", line 174, in disconnect_disk match_func=match_func) File "/usr/local/lib/python2.7/dist-packages/pypowervm/tasks/scsi_mapper.py", line 503, in find_maps is_uuid, client_id = uuid.id_or_uuid(client_lpar_id) File "/usr/local/lib/python2.7/dist-packages/pypowervm/utils/uuid.py", line 55, in id_or_uuid ret_id = int(an_id) ValueError: invalid literal for int() with base 10: '4E27E1E6-6A24-4F0A-8E7B-2BBE7B4A28BA' (Okay, our bad for using str at all - though to be fair, it's possible that code predates the very existence of py3.) The right fix is for [1] to use is_uuid_like from oslo.utils. This shall be done. However, since [5] was backported to queens and pike, unless we can get away with backporting requirements changes, we may have to do something backportable in nova-powervm and nova as well. [1] https://github.com/powervm/pypowervm/blob/release/1.1.14/pypowervm/utils/uuid.py#L50 [2] https://github.com/powervm/pypowervm/blob/release/1.1.14/pypowervm/tasks/scsi_mapper.py#L503 [3] https://github.com/openstack/nova/blob/1605391084d6a1f57384ef48bad8ca2185cf6fa7/nova/virt/powervm/disk/ssp.py#L128 [4] https://github.com/openstack/nova/blob/1605391084d6a1f57384ef48bad8ca2185cf6fa7/nova/virt/powervm/driver.py#L272 [5] https://review.openstack.org/#/q/Ic6b6308fb1960ec40407e6efde30137b64543e72 [6] http://184.172.12.213/58/557958/10/check/nova-out-of-tree-pvm/c1d7e99/logs/n-cpu.txt.gz?#_Apr_20_08_51_16_452651 ** Affects: nova Importance: Undecided Status: New ** Affects: nova-powervm Importance: Undecided Status: New ** Affects: pypowervm Importance: Undecided Status: New ** Also affects: nova Importance: Undecided Status: New ** Also affects: pypowervm Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1766692 Title: instance.uuid no longer being a str breaks powervm scsi disconnect Status in OpenStack Compute (nova): New Status in nova-powervm: New Status in pypowervm: New Bug description: Long-standing code in pypowervm [1] used isinstance(..., str) to help identify whether an input was a UUID or an integer short ID. This is used with to find SCSI mappings [2] with Instance.uuid [3] when disconnecting a disk during destroy [4]. Then this change in oslo.versionedobjects happened [5], resulting in instance.uuid no longer being a str. So the check at [1] fails, and we try to int() a UUID string, resulting in [6], pasted here in case that link expires: PowerVM error destroying instance.: ValueError: invalid literal for int() with base 10: '4E27E1E6-6A24-4F0A-8E7B-2BBE7B4A28BA' Traceback (most recent call last): File "/opt/stack/nova-powervm/nova_powervm/virt/powervm/driver.py", line 672, in _destroy
[Yahoo-eng-team] [Bug 1762789] [NEW] ResourceClass.normalize_name produces different results for py2 vs. py3
Public bug reported:
Due to a py3 quirk (read: bug they decided not to fix) [1], .upper()
works differently in py2 vs. py3 for the sharp S ('ß'). In py2, it
stays the same (like all other characters not in the a-z range); in py3
it becomes the two-character string 'SS'. This means that, as written,
ResourceClass.normalize_name('ß') will yield 'CUSTOM__' in py2, but
'CUSTOM_SS' in py3.
[1] https://bugs.python.org/issue4610
** Affects: nova
Importance: Undecided
Assignee: Eric Fried (efried)
Status: In Progress
** Tags: placement
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1762789
Title:
ResourceClass.normalize_name produces different results for py2 vs.
py3
Status in OpenStack Compute (nova):
In Progress
Bug description:
Due to a py3 quirk (read: bug they decided not to fix) [1], .upper()
works differently in py2 vs. py3 for the sharp S ('ß'). In py2, it
stays the same (like all other characters not in the a-z range); in
py3 it becomes the two-character string 'SS'. This means that, as
written, ResourceClass.normalize_name('ß') will yield 'CUSTOM__' in
py2, but 'CUSTOM_SS' in py3.
[1] https://bugs.python.org/issue4610
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1762789/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1760322] [NEW] Traits not synced if first retrieval fails
Public bug reported: If the first trait you try to retrieve from placement doesn't exist, traits are not synced from os_traits into the database, so it winds up empty. try: rp_obj.Trait.get_by_name(self.ctx, 'CUSTOM_GOLD') except exception.TraitNotFound: pass rp_obj.Trait.get_by_name(self.ctx, os_traits.HW_CPU_X86_AVX2) # <== raises TraitNotFound I *think* what's happening is this: 1@staticmethod 2@db_api.api_context_manager.writer # trait sync can cause a write 3def _get_by_name_from_db(context, name): 4_ensure_trait_sync(context) 5result = context.session.query(models.Trait).filter_by( 6name=name).first() 7if not result: 8raise exception.TraitNotFound(names=name) 9return result Line 4 "succeeds" and sets _TRAITS_SYNCED = True. But because line 8 raises, the transaction is rolled back. Database stays empty. Subsequent retrieval attempts see _TRAITS_SYNCED == True so don't try to resync. ** Affects: nova Importance: Undecided Status: New ** Tags: placement -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1760322 Title: Traits not synced if first retrieval fails Status in OpenStack Compute (nova): New Bug description: If the first trait you try to retrieve from placement doesn't exist, traits are not synced from os_traits into the database, so it winds up empty. try: rp_obj.Trait.get_by_name(self.ctx, 'CUSTOM_GOLD') except exception.TraitNotFound: pass rp_obj.Trait.get_by_name(self.ctx, os_traits.HW_CPU_X86_AVX2) # <== raises TraitNotFound I *think* what's happening is this: 1@staticmethod 2@db_api.api_context_manager.writer # trait sync can cause a write 3def _get_by_name_from_db(context, name): 4_ensure_trait_sync(context) 5result = context.session.query(models.Trait).filter_by( 6name=name).first() 7if not result: 8raise exception.TraitNotFound(names=name) 9return result Line 4 "succeeds" and sets _TRAITS_SYNCED = True. But because line 8 raises, the transaction is rolled back. Database stays empty. Subsequent retrieval attempts see _TRAITS_SYNCED == True so don't try to resync. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1760322/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1750084] [NEW] Report client associations include non-sharing providers
Public bug reported: It was discussed and decided [1] that we only want to be pulling down, caching, and passing to update_provider_tree providers associated via aggregate with the compute node's provider tree if they are sharing providers. Otherwise we'll get e.g. all the *other* compute nodes which are also associated with a sharing provider. [1] https://review.openstack.org/#/c/540111/4/specs/rocky/approved /update-provider-tree.rst@48 ** Affects: nova Importance: Undecided Assignee: Eric Fried (efried) Status: In Progress ** Tags: placement queens-rc-potential -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1750084 Title: Report client associations include non-sharing providers Status in OpenStack Compute (nova): In Progress Bug description: It was discussed and decided [1] that we only want to be pulling down, caching, and passing to update_provider_tree providers associated via aggregate with the compute node's provider tree if they are sharing providers. Otherwise we'll get e.g. all the *other* compute nodes which are also associated with a sharing provider. [1] https://review.openstack.org/#/c/540111/4/specs/rocky/approved /update-provider-tree.rst@48 To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1750084/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1747095] [NEW] doc: placement API ref for resource classes points to os-traits
Public bug reported: The placement API reference documentation for POST /resource_classes [1] says: The new class must be a custom resource class, prefixed with CUSTOM_ and distinct from the _standard_ resource classes. ...where _standard_ is a link to os-traits documentation [2]. Since we don't have os-resource-classes (yet), the linkitude should just be removed. [1] https://developer.openstack.org/api-ref/placement/#create-resource-class [2] https://docs.openstack.org/os-traits/latest/ ** Affects: nova Importance: Undecided Assignee: Eric Fried (efried) Status: In Progress ** Tags: placement -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1747095 Title: doc: placement API ref for resource classes points to os-traits Status in OpenStack Compute (nova): In Progress Bug description: The placement API reference documentation for POST /resource_classes [1] says: The new class must be a custom resource class, prefixed with CUSTOM_ and distinct from the _standard_ resource classes. ...where _standard_ is a link to os-traits documentation [2]. Since we don't have os-resource-classes (yet), the linkitude should just be removed. [1] https://developer.openstack.org/api-ref/placement/#create-resource-class [2] https://docs.openstack.org/os-traits/latest/ To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1747095/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1746615] [NEW] Report client can try to ensure a standard resource class
Public bug reported: SchedulerReportClient.set_inventory_for_provider uses this logic [1] to pre-create custom resource classes found in the input inventory. list(map(self._ensure_resource_class, (rc_name for rc_name in inv_data if rc_name not in fields.ResourceClass.STANDARD))) The problem is that this relies on the local system's notion of the set of standard resource classes. If the placement service is running newer code, standard resource classes may have been added that the compute service doesn't know about yet. If a consumer attempts to use such a resource class, the above block will attempt to _ensure_resource_class on it, which attempts to create it in placement, which results in a 400 (because the schema requires it to begin with CUSTOM_), which results in InvalidResourceClass exception, and the consumer can't use that resource class. We should never be relying on placement code directly on the compute node. (This includes introspecting os-traits.) We should always be asking the placement service. [1] https://github.com/openstack/nova/blob/894dd5b87674d396c7221f9d1bca3a9a983dfeb8/nova/scheduler/client/report.py#L983-L985 ** Affects: nova Importance: Undecided Status: New ** Tags: placement -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1746615 Title: Report client can try to ensure a standard resource class Status in OpenStack Compute (nova): New Bug description: SchedulerReportClient.set_inventory_for_provider uses this logic [1] to pre-create custom resource classes found in the input inventory. list(map(self._ensure_resource_class, (rc_name for rc_name in inv_data if rc_name not in fields.ResourceClass.STANDARD))) The problem is that this relies on the local system's notion of the set of standard resource classes. If the placement service is running newer code, standard resource classes may have been added that the compute service doesn't know about yet. If a consumer attempts to use such a resource class, the above block will attempt to _ensure_resource_class on it, which attempts to create it in placement, which results in a 400 (because the schema requires it to begin with CUSTOM_), which results in InvalidResourceClass exception, and the consumer can't use that resource class. We should never be relying on placement code directly on the compute node. (This includes introspecting os-traits.) We should always be asking the placement service. [1] https://github.com/openstack/nova/blob/894dd5b87674d396c7221f9d1bca3a9a983dfeb8/nova/scheduler/client/report.py#L983-L985 To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1746615/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1746373] [NEW] Placement APIs with missing conflict detection
Public bug reported:
Placement has a few APIs which affect resource provider generation, but
which do not accept the current resource provider generation and
therefore cannot ensure consistency. They are as follows:
DELETE /resource_providers/{u}/inventories
DELETE /resource_providers/{u}/traits
POST /allocations
PUT /allocations/{c}
DELETE /allocations/{c}
As an example of how this is broken:
- X wants to remove all of provider {u}'s inventory in resource class VGPU. He
GETs inventory at generation 1, which happens to contain *only* VGPU.
- Y wants to add some SRIOV_NET_VF inventory to {u}. He GETs inventory at
generation 1, adds the SRIOV_NET_VF inventory, and PUTs it back. The server
increments the generation to 2, and the provider now has both VGPU and
SRIOV_NET_VF inventory.
- X, thinking the provider only has VGPU resource, invokes DELETE
/resource_providers/{u}/inventories, which succeeds, thereby blowing away the
SRIOV_NET_VF inventory.
Note that in the case of DELETE /resource_providers/{u}/inventories and
.../traits, there is an alternative, PUT , which *does* accept
the provider generation.
For the allocations APIs, there is no alternative. Though it could be
argued that it should not be necessary to send generation with the
allocations APIs.
** Affects: nova
Importance: Undecided
Status: New
** Tags: placement
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1746373
Title:
Placement APIs with missing conflict detection
Status in OpenStack Compute (nova):
New
Bug description:
Placement has a few APIs which affect resource provider generation,
but which do not accept the current resource provider generation and
therefore cannot ensure consistency. They are as follows:
DELETE /resource_providers/{u}/inventories
DELETE /resource_providers/{u}/traits
POST /allocations
PUT /allocations/{c}
DELETE /allocations/{c}
As an example of how this is broken:
- X wants to remove all of provider {u}'s inventory in resource class VGPU.
He GETs inventory at generation 1, which happens to contain *only* VGPU.
- Y wants to add some SRIOV_NET_VF inventory to {u}. He GETs inventory at
generation 1, adds the SRIOV_NET_VF inventory, and PUTs it back. The server
increments the generation to 2, and the provider now has both VGPU and
SRIOV_NET_VF inventory.
- X, thinking the provider only has VGPU resource, invokes DELETE
/resource_providers/{u}/inventories, which succeeds, thereby blowing away the
SRIOV_NET_VF inventory.
Note that in the case of DELETE /resource_providers/{u}/inventories
and .../traits, there is an alternative, PUT , which *does*
accept the provider generation.
For the allocations APIs, there is no alternative. Though it could be
argued that it should not be necessary to send generation with the
allocations APIs.
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1746373/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1746374] [NEW] Report client _delete_inventory violates generation consistency
Public bug reported:
SchedulerReportClient._delete_inventory uses the DELETE
/resource_providers/{u}/inventories API, which does not provide a way to
send the generation down (see related bug [1]), and is therefore subject
to concurrency errors.
Until/unless an alternative becomes available, we should be using PUT
/resource_providers/{u}/inventories with an empty 'inventories' dict,
because that API *does* take the generation in the payload. (If we do
this, we also make moot part of related bug [2].)
Related bugs:
[1] https://bugs.launchpad.net/nova/+bug/1746075
[2] https://bugs.launchpad.net/nova/+bug/1746373
** Affects: nova
Importance: Undecided
Status: New
** Tags: placement
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1746374
Title:
Report client _delete_inventory violates generation consistency
Status in OpenStack Compute (nova):
New
Bug description:
SchedulerReportClient._delete_inventory uses the DELETE
/resource_providers/{u}/inventories API, which does not provide a way
to send the generation down (see related bug [1]), and is therefore
subject to concurrency errors.
Until/unless an alternative becomes available, we should be using PUT
/resource_providers/{u}/inventories with an empty 'inventories' dict,
because that API *does* take the generation in the payload. (If we do
this, we also make moot part of related bug [2].)
Related bugs:
[1] https://bugs.launchpad.net/nova/+bug/1746075
[2] https://bugs.launchpad.net/nova/+bug/1746373
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1746374/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1746075] [NEW] Report client placement cache consistency is broken
Public bug reported: Today the report client makes assumptions about how resource provider generation is calculated by the placement service. Specifically, that it starts at zero [1], and that it increases by 1 when the provider's inventory is deleted [2]. While these assumptions happen to be true today [3], they are not a documented part of the placement API. Which either means we need to document this behavior; or clients should not be relying on it. [1] https://github.com/openstack/nova/blob/b214dfc41928d9e05199263301f8e5b23555c170/nova/scheduler/client/report.py#L552 [2] https://github.com/openstack/nova/blob/b214dfc41928d9e05199263301f8e5b23555c170/nova/scheduler/client/report.py#L927 [3] The latter more broadly stated as "increases by 1 when anything about the provider changes" - except we have a known hole for aggregates (see https://blueprints.launchpad.net/nova/+spec/placement-aggregate-generation) ** Affects: nova Importance: Undecided Status: New ** Tags: placement -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1746075 Title: Report client placement cache consistency is broken Status in OpenStack Compute (nova): New Bug description: Today the report client makes assumptions about how resource provider generation is calculated by the placement service. Specifically, that it starts at zero [1], and that it increases by 1 when the provider's inventory is deleted [2]. While these assumptions happen to be true today [3], they are not a documented part of the placement API. Which either means we need to document this behavior; or clients should not be relying on it. [1] https://github.com/openstack/nova/blob/b214dfc41928d9e05199263301f8e5b23555c170/nova/scheduler/client/report.py#L552 [2] https://github.com/openstack/nova/blob/b214dfc41928d9e05199263301f8e5b23555c170/nova/scheduler/client/report.py#L927 [3] The latter more broadly stated as "increases by 1 when anything about the provider changes" - except we have a known hole for aggregates (see https://blueprints.launchpad.net/nova/+spec/placement-aggregate-generation) To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1746075/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1744786] [NEW] SchedulerReportClient.put with empty (not None) payload errors 415
Public bug reported:
https://github.com/openstack/nova/blob/f0d830d56d20c7f34372cd3c68d13a94bdf645a6/nova/scheduler/client/report.py#L295-L302
295 def put(self, url, data, version=None):
296 # NOTE(sdague): using json= instead of data= sets the
297 # media type to application/json for us. Placement API is
298 # more sensitive to this than other APIs in the OpenStack
299 # ecosystem.
300 kwargs = {'microversion': version}
301 if data:
302 kwargs['json'] = data
On line 301, if data is a False value other than None, we won't set the
json kwarg, so Session won't set the content type to application/json,
and we'll run afoul of:
415 Unsupported Media Type
415 Unsupported Media Type
The request media type None is not supported by this server.
The media type None is not supported, use application/json
A normal "workaround" - which is being used for e.g. inventories - is
for the caller to check for "empty" and hit the DELETE API instead.
But we don't have a DELETE API for resource provider aggregates
(/resource_providers/{u}/aggregates).
** Affects: nova
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1744786
Title:
SchedulerReportClient.put with empty (not None) payload errors 415
Status in OpenStack Compute (nova):
New
Bug description:
https://github.com/openstack/nova/blob/f0d830d56d20c7f34372cd3c68d13a94bdf645a6/nova/scheduler/client/report.py#L295-L302
295 def put(self, url, data, version=None):
296 # NOTE(sdague): using json= instead of data= sets the
297 # media type to application/json for us. Placement API is
298 # more sensitive to this than other APIs in the OpenStack
299 # ecosystem.
300 kwargs = {'microversion': version}
301 if data:
302 kwargs['json'] = data
On line 301, if data is a False value other than None, we won't set
the json kwarg, so Session won't set the content type to
application/json, and we'll run afoul of:
415 Unsupported Media Type
415 Unsupported Media Type
The request media type None is not supported by this server.
The media type None is not supported, use application/json
A normal "workaround" - which is being used for e.g. inventories - is
for the caller to check for "empty" and hit the DELETE API instead.
But we don't have a DELETE API for resource provider aggregates
(/resource_providers/{u}/aggregates).
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1744786/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1742311] [NEW] AttributeError in report client error path
Public bug reported:
This [1] is clearly wrong.
elif not result:
placement_req_id = get_placement_request_id(result)
LOG.warning('[%(placement_req_id)s] Failed to update inventory '
'for resource provider %(uuid)s: %(status)i %(text)s',
{'placement_req_id': placement_req_id,
'uuid': rp_uuid,
'status': result.status_code,
'text': result.text})
It triggers if `result` evaluates to False, then tries to access
result.status_code and result.text.
[1]
https://github.com/openstack/nova/blob/90a92d33edaea2b7411a5fd528f3159a486e1fd0/nova/scheduler/client/report.py#L756-L763
** Affects: nova
Importance: Undecided
Status: New
** Tags: placement
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1742311
Title:
AttributeError in report client error path
Status in OpenStack Compute (nova):
New
Bug description:
This [1] is clearly wrong.
elif not result:
placement_req_id = get_placement_request_id(result)
LOG.warning('[%(placement_req_id)s] Failed to update inventory '
'for resource provider %(uuid)s: %(status)i %(text)s',
{'placement_req_id': placement_req_id,
'uuid': rp_uuid,
'status': result.status_code,
'text': result.text})
It triggers if `result` evaluates to False, then tries to access
result.status_code and result.text.
[1]
https://github.com/openstack/nova/blob/90a92d33edaea2b7411a5fd528f3159a486e1fd0/nova/scheduler/client/report.py#L756-L763
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1742311/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1735430] [NEW] Report client doesn't handle RP create conflict (409) properly
Public bug reported:
POST /resource_providers can fail with conflict (HTTP status 409) for
(at least) two reasons: A provider with the specified UUID exists; *or*
a provider with the specified *name* already exists.
In SchedulerReportClient, _ensure_resource_provider uses helper method
_create_resource_provider, whose logic goes like this:
POST /resource_provider { 'uuid': , 'name': }
if 201:
cool, return the result
if 409:
LOG("Another thread created a provider with this *UUID*")
GET /resource_provider/
if 200:
cool, return the result
if 404 or any other error:
return None
if any other error:
return None
PROBLEM: If a provider exists with the desired *name* (but a different
UUID), this code will always return None (via that 404 path).
PROBLEM: Nobody up the stack is checking the return for None.
What this effectively means is that _ensure_resource_provider...
doesn't.
IMO we should raise an exception in these error paths, forcing consuming
code to handle them explicitly. But at the very least, any code
consumuing _ensure_resource_provider needs to validate that it succeeds.
** Affects: nova
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1735430
Title:
Report client doesn't handle RP create conflict (409) properly
Status in OpenStack Compute (nova):
New
Bug description:
POST /resource_providers can fail with conflict (HTTP status 409) for
(at least) two reasons: A provider with the specified UUID exists;
*or* a provider with the specified *name* already exists.
In SchedulerReportClient, _ensure_resource_provider uses helper method
_create_resource_provider, whose logic goes like this:
POST /resource_provider { 'uuid': , 'name': }
if 201:
cool, return the result
if 409:
LOG("Another thread created a provider with this *UUID*")
GET /resource_provider/
if 200:
cool, return the result
if 404 or any other error:
return None
if any other error:
return None
PROBLEM: If a provider exists with the desired *name* (but a different
UUID), this code will always return None (via that 404 path).
PROBLEM: Nobody up the stack is checking the return for None.
What this effectively means is that _ensure_resource_provider...
doesn't.
IMO we should raise an exception in these error paths, forcing
consuming code to handle them explicitly. But at the very least, any
code consumuing _ensure_resource_provider needs to validate that it
succeeds.
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1735430/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1702420] Re: The AllocationCandidates.get_by_filters returned wrong combination of AllocationRequests
This got fixed somewhere along the way in The Big Refactor series (starting https://review.openstack.org/#/c/516778/) ** Changed in: nova Status: In Progress => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1702420 Title: The AllocationCandidates.get_by_filters returned wrong combination of AllocationRequests Status in OpenStack Compute (nova): Fix Released Bug description: The case is: compute node1 associated with shared storage pool1 compute node2 associated with shared storage pool2 The expected AllocationRequests returned as the combinations: cn1 and ss1 cn2 and ss2 But the current implementation returned: cn1, ss1 and ss2 cn2, ss1 and ss2 To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1702420/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1733630] [NEW] placement: Version discovery URI should not require authentication
Public bug reported:
The placement API GET / returns the version document:
{
"versions": [
{
"min_version": "1.0",
"max_version": "1.10",
"id": "v1.0"
}
]
}
However, it requires authentication:
# curl http://9.1.2.3/placement/
{"error": {"message": "The request you have made requires authentication.",
"code": 401, "title": "Unauthorized"}}
It shouldn't. Right now I can't find the doc that says so, but Monty
confirms:
http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-
nova.2017-11-21.log.html#t2017-11-21T15:35:08
** Affects: nova
Importance: Undecided
Status: New
** Tags: placement
** Tags removed: pla
** Tags added: placement
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1733630
Title:
placement: Version discovery URI should not require authentication
Status in OpenStack Compute (nova):
New
Bug description:
The placement API GET / returns the version document:
{
"versions": [
{
"min_version": "1.0",
"max_version": "1.10",
"id": "v1.0"
}
]
}
However, it requires authentication:
# curl http://9.1.2.3/placement/
{"error": {"message": "The request you have made requires authentication.",
"code": 401, "title": "Unauthorized"}}
It shouldn't. Right now I can't find the doc that says so, but Monty
confirms:
http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-
nova.2017-11-21.log.html#t2017-11-21T15:35:08
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1733630/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1733030] [NEW] GET /resource_providers?member_of misdocumented for lists
Public bug reported:
The documentation for the member_of query parameter for GET
/resource_providers [1] claims that it accepts a "comma-separated list
of strings representing aggregate uuids". But attempting this with more
than one aggregate UUID results in a 400 error claiming:
Invalid uuid value: 1ceb128e-a714-4e4a-8eec-0d0a45c7039a,4a10858c-253e-
4df5-8ada-c5dbe5744462,7cb20f93-8789-434f-bbe4-76ea1d485c32
Turns out the code [2] is expecting a single UUID unless the prefix
'in:' is specified.
I see three possible solutions:
a) Remove the prefix check or make it accepted but ignored. Don't tell
anyone. After all, nobody could have been using it unless they had read
the source code.
b) Document the in: prefix.
c) Publish a new placement microversion X with the prefix check removed.
Document the in: prefix as being required up to microversion X-1 and
forbidden (or perhaps ignored?) at microversion X and beyond.
Personally, I think the prefix is superfluous and would rather see it
removed. And the code change is trivial - one_uuid.split(',') will
happily return [one_uuid] if there's no commas in there. Surely we
don't need a new microversion if we make it accepted but ignored??
[1] https://developer.openstack.org/api-ref/placement/#resource-providers
[2]
https://github.com/openstack/nova/blob/57728836f25e9201ddec1e7790b552cfa840d572/nova/api/openstack/placement/handlers/resource_provider.py#L229-L233
** Affects: nova
Importance: Undecided
Assignee: Eric Fried (efried)
Status: In Progress
** Tags: placement
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1733030
Title:
GET /resource_providers?member_of misdocumented for lists
Status in OpenStack Compute (nova):
In Progress
Bug description:
The documentation for the member_of query parameter for GET
/resource_providers [1] claims that it accepts a "comma-separated list
of strings representing aggregate uuids". But attempting this with
more than one aggregate UUID results in a 400 error claiming:
Invalid uuid value: 1ceb128e-a714-4e4a-8eec-0d0a45c7039a,4a10858c-
253e-4df5-8ada-c5dbe5744462,7cb20f93-8789-434f-bbe4-76ea1d485c32
Turns out the code [2] is expecting a single UUID unless the prefix
'in:' is specified.
I see three possible solutions:
a) Remove the prefix check or make it accepted but ignored. Don't
tell anyone. After all, nobody could have been using it unless they
had read the source code.
b) Document the in: prefix.
c) Publish a new placement microversion X with the prefix check
removed. Document the in: prefix as being required up to microversion
X-1 and forbidden (or perhaps ignored?) at microversion X and beyond.
Personally, I think the prefix is superfluous and would rather see it
removed. And the code change is trivial - one_uuid.split(',') will
happily return [one_uuid] if there's no commas in there. Surely we
don't need a new microversion if we make it accepted but ignored??
[1] https://developer.openstack.org/api-ref/placement/#resource-providers
[2]
https://github.com/openstack/nova/blob/57728836f25e9201ddec1e7790b552cfa840d572/nova/api/openstack/placement/handlers/resource_provider.py#L229-L233
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1733030/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1724613] Re: AllocationCandidates.get_by_filters ignores shared RPs when the RC exists in both places
Per hangout, we decided this bug is valid - that we would like to get
extra candidates involving shared RPs when those satisfy the request.
** Changed in: nova
Status: Invalid => Confirmed
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1724613
Title:
AllocationCandidates.get_by_filters ignores shared RPs when the RC
exists in both places
Status in OpenStack Compute (nova):
Confirmed
Bug description:
When both the compute node resource provider and the shared resource
provider have inventory in the same resource class,
AllocationCandidates.get_by_filters will not return an
AllocationRequest including the shared resource provider.
Example:
cnrp { VCPU: 24,
MEMORY_MB: 2048,
DISK_GB: 16 }
ssrp { DISK_GB: 32 }
AllocationCandidates.get_by_filters(
resources={ VCPU: 1,
MEMORY_MB: 512,
DISK_GB: 2 } )
Expected:
allocation_requests: [
{ cnrp: { VCPU: 1,
MEMORY_MB: 512,
DISK_GB: 2 } },
{ cnrp: { VCPU: 1,
MEMORY_MB: 512 }
ssrp: { DISK_GB: 2 } },
]
Actual:
allocation_requests: [
{ cnrp: { VCPU: 1,
MEMORY_MB: 512,
DISK_GB: 2 } }
]
I will post a review shortly that demonstrates this.
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1724613/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1731072] [NEW] AllocationCandidates.get_by_filters returns garbage with multiple aggregates
Public bug reported: I set up a test scenario with multiple providers (sharing and non), across multiple aggregates. Requesting allocation candidates gives some candidates as expected, but some are garbled. Bad behaviors include: (1) When inventory in a given RC is provided both by a non-sharing and a sharing RP in an aggregate, the sharing RP is ignored in the results (this is tracked via https://bugs.launchpad.net/nova/+bug/1724613) (2) When inventory in a given RC is provided solely by a sharing RP, I don't get the expected candidate where that sharing RP provides that inventory and the rest comes from the non-sharing RP. (3) The above applies when there are multiple sharing RPs in the same aggregate providing that same shared resource. (4) ...and also when the sharing RPs provide different resources. And we get a couple of unexpected candidates that are really garbled: (5) Where there are multiple sharing RPs with different resources, one candidate has the expected resources from the non-sharing RP and one of the sharing RPs, but is missing the third requested resource entirely. (6) With that same setup, we get another candidate that has the expected resource from the non-sharing RP; but duplicated resources spread across multiple sharing RPs from *different* *aggregates*. This one is also missing one of the requested resources entirely. I will post a commit shortly that demonstrates this behavior. ** Affects: nova Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1731072 Title: AllocationCandidates.get_by_filters returns garbage with multiple aggregates Status in OpenStack Compute (nova): New Bug description: I set up a test scenario with multiple providers (sharing and non), across multiple aggregates. Requesting allocation candidates gives some candidates as expected, but some are garbled. Bad behaviors include: (1) When inventory in a given RC is provided both by a non-sharing and a sharing RP in an aggregate, the sharing RP is ignored in the results (this is tracked via https://bugs.launchpad.net/nova/+bug/1724613) (2) When inventory in a given RC is provided solely by a sharing RP, I don't get the expected candidate where that sharing RP provides that inventory and the rest comes from the non-sharing RP. (3) The above applies when there are multiple sharing RPs in the same aggregate providing that same shared resource. (4) ...and also when the sharing RPs provide different resources. And we get a couple of unexpected candidates that are really garbled: (5) Where there are multiple sharing RPs with different resources, one candidate has the expected resources from the non-sharing RP and one of the sharing RPs, but is missing the third requested resource entirely. (6) With that same setup, we get another candidate that has the expected resource from the non-sharing RP; but duplicated resources spread across multiple sharing RPs from *different* *aggregates*. This one is also missing one of the requested resources entirely. I will post a commit shortly that demonstrates this behavior. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1731072/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1730730] [NEW] AllocationCandidates.get_by_filters returns garbage with only sharing providers
Public bug reported: If my placement database is set up with only sharing providers (no "compute nodes"), the results are broken. Steps to reproduce == Here's one example: SS1 has inventory in IPV4_ADDRESS, SRIOV_NET_VF, and DISK_GB. SS2 has inventory in just DISK_GB. Both are associated with the same aggregate; both have the MISC_SHARES_VIA_AGGREGATE trait. I make a request for resources in all three classes (in amounts that can be satisfied by those inventories). Expected result === It is unclear what the expected result is. There is a school of thought that we are only dealing with compute hosts right now, so we should never get back a candidate that doesn't include a compute host. In that case, this scenario should yield *zero* candidates. On the other hand, in the long-term vision of placement, there should be no reason not to support scenarios where allocations are made *only* against sharing providers (as long as they're in the same aggregate for a given candidate). In that case, this scenario should yield two candidates: One that gets all its resources from SS1; One that gets DISK_GB from SS2, and IPV4_ADDRESS and SRIOV_NET_VF from SS1. Actual result = The actual result is three candidates: One that gets all its resources from SS1 (cool); One that gets DISK_GB from SS2 and IPV4_ADDRESS from SS1 (not cool - SRIOV_NET_VF isn't in here!) One that gets DISK_GB from SS2 and SRIOV_NET_VF from SS1 (not cool - IPV4_ADDRESS isn't in here!) I will post a functional test to demonstrate this. ** Affects: nova Importance: Undecided Status: New ** Tags: placement -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1730730 Title: AllocationCandidates.get_by_filters returns garbage with only sharing providers Status in OpenStack Compute (nova): New Bug description: If my placement database is set up with only sharing providers (no "compute nodes"), the results are broken. Steps to reproduce == Here's one example: SS1 has inventory in IPV4_ADDRESS, SRIOV_NET_VF, and DISK_GB. SS2 has inventory in just DISK_GB. Both are associated with the same aggregate; both have the MISC_SHARES_VIA_AGGREGATE trait. I make a request for resources in all three classes (in amounts that can be satisfied by those inventories). Expected result === It is unclear what the expected result is. There is a school of thought that we are only dealing with compute hosts right now, so we should never get back a candidate that doesn't include a compute host. In that case, this scenario should yield *zero* candidates. On the other hand, in the long-term vision of placement, there should be no reason not to support scenarios where allocations are made *only* against sharing providers (as long as they're in the same aggregate for a given candidate). In that case, this scenario should yield two candidates: One that gets all its resources from SS1; One that gets DISK_GB from SS2, and IPV4_ADDRESS and SRIOV_NET_VF from SS1. Actual result = The actual result is three candidates: One that gets all its resources from SS1 (cool); One that gets DISK_GB from SS2 and IPV4_ADDRESS from SS1 (not cool - SRIOV_NET_VF isn't in here!) One that gets DISK_GB from SS2 and SRIOV_NET_VF from SS1 (not cool - IPV4_ADDRESS isn't in here!) I will post a functional test to demonstrate this. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1730730/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1724689] [NEW] Usability: Service user token requested with no auth raises cryptic exception
Public bug reported: If [service_user]send_service_user_token is requested, but no auth information is provided in the [service_user] section, the resulting error is cryptic [1] and doesn't help the user understand what went wrong. Note that today this only happens if the conf section is missing the auth_type option. But this is a pretty good first indicator that the admin forgot to populate auth options in general. [1] http://paste.openstack.org/show/623721/ ** Affects: nova Importance: Undecided Assignee: Eric Fried (efried) Status: In Progress -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1724689 Title: Usability: Service user token requested with no auth raises cryptic exception Status in OpenStack Compute (nova): In Progress Bug description: If [service_user]send_service_user_token is requested, but no auth information is provided in the [service_user] section, the resulting error is cryptic [1] and doesn't help the user understand what went wrong. Note that today this only happens if the conf section is missing the auth_type option. But this is a pretty good first indicator that the admin forgot to populate auth options in general. [1] http://paste.openstack.org/show/623721/ To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1724689/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1724633] [NEW] AllocationCandidates.get_by_filters hits incorrectly when traits are split across the main RP and aggregates
Public bug reported:
When requesting multiple resources with multiple traits, placement
doesn't know that a particular trait needs to be associated with a
particular resource. As currently conceived, it will return allocation
candidates from the main RP plus shared RPs such that all traits are
satisfied This is bad, particularly when the main RP and shared RPs
provide inventory from the same resource class.
For example, consider a compute node that has local SSD storage, which
is associated with a shared storage RP with a RAID5 array:
cnrp { VCPU: 24,
MEMORY_MB: 2048,
DISK_GB: 16,
traits: [HW_CPU_X86_SSE,
STORAGE_DISK_SSD] }
ssrp { DISK_GB: 32,
traits: [STORAGE_DISK_RAID5] }
A request for SSD + RAID5 disk should *not* return any results from the
above setup, because there's not actually any disk with both of those
characteristics.
AllocationCandidates.get_by_filters(
resources={ VCPU: 1,
MEMORY_MB: 512,
DISK_GB: 2 },
traits= [HW_CPU_X86_SSE,
STORAGE_DISK_SSD,
STORAGE_DISK_RAID5])
Expected:
allocation_requests: []
Actual:
allocation_requests: [
{ cnrp: { VCPU: 1,
MEMORY_MB: 512 }
ssrp: { DISK_GB: 2 } },
]
I will post a review shortly with a test case that demonstrates this.
Note, however, that the test will spuriously pass until
https://bugs.launchpad.net/nova/+bug/1724613 is fixed.
** Affects: nova
Importance: Undecided
Status: New
** Tags: placement
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1724633
Title:
AllocationCandidates.get_by_filters hits incorrectly when traits are
split across the main RP and aggregates
Status in OpenStack Compute (nova):
New
Bug description:
When requesting multiple resources with multiple traits, placement
doesn't know that a particular trait needs to be associated with a
particular resource. As currently conceived, it will return
allocation candidates from the main RP plus shared RPs such that all
traits are satisfied This is bad, particularly when the main RP and
shared RPs provide inventory from the same resource class.
For example, consider a compute node that has local SSD storage, which
is associated with a shared storage RP with a RAID5 array:
cnrp { VCPU: 24,
MEMORY_MB: 2048,
DISK_GB: 16,
traits: [HW_CPU_X86_SSE,
STORAGE_DISK_SSD] }
ssrp { DISK_GB: 32,
traits: [STORAGE_DISK_RAID5] }
A request for SSD + RAID5 disk should *not* return any results from
the above setup, because there's not actually any disk with both of
those characteristics.
AllocationCandidates.get_by_filters(
resources={ VCPU: 1,
MEMORY_MB: 512,
DISK_GB: 2 },
traits= [HW_CPU_X86_SSE,
STORAGE_DISK_SSD,
STORAGE_DISK_RAID5])
Expected:
allocation_requests: []
Actual:
allocation_requests: [
{ cnrp: { VCPU: 1,
MEMORY_MB: 512 }
ssrp: { DISK_GB: 2 } },
]
I will post a review shortly with a test case that demonstrates this.
Note, however, that the test will spuriously pass until
https://bugs.launchpad.net/nova/+bug/1724613 is fixed.
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1724633/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1724613] [NEW] AllocationCandidates.get_by_filters ignores shared RPs when the RC exists in both places
Public bug reported:
When both the compute node resource provider and the shared resource
provider have inventory in the same resource class,
AllocationCandidates.get_by_filters will not return an AllocationRequest
including the shared resource provider.
Example:
cnrp { VCPU: 24,
MEMORY_MB: 2048,
DISK_GB: 16 }
ssrp { DISK_GB: 32 }
AllocationCandidates.get_by_filters(
resources={ VCPU: 1,
MEMORY_MB: 512,
DISK_GB: 2 } )
Expected:
allocation_requests: [
{ cnrp: { VCPU: 1,
MEMORY_MB: 512,
DISK_GB: 2 } },
{ cnrp: { VCPU: 1,
MEMORY_MB: 512 }
ssrp: { DISK_GB: 2 } },
]
Actual:
allocation_requests: [
{ cnrp: { VCPU: 1,
MEMORY_MB: 512,
DISK_GB: 2 } }
]
I will post a review shortly that demonstrates this.
** Affects: nova
Importance: Undecided
Status: New
** Tags: placement
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1724613
Title:
AllocationCandidates.get_by_filters ignores shared RPs when the RC
exists in both places
Status in OpenStack Compute (nova):
New
Bug description:
When both the compute node resource provider and the shared resource
provider have inventory in the same resource class,
AllocationCandidates.get_by_filters will not return an
AllocationRequest including the shared resource provider.
Example:
cnrp { VCPU: 24,
MEMORY_MB: 2048,
DISK_GB: 16 }
ssrp { DISK_GB: 32 }
AllocationCandidates.get_by_filters(
resources={ VCPU: 1,
MEMORY_MB: 512,
DISK_GB: 2 } )
Expected:
allocation_requests: [
{ cnrp: { VCPU: 1,
MEMORY_MB: 512,
DISK_GB: 2 } },
{ cnrp: { VCPU: 1,
MEMORY_MB: 512 }
ssrp: { DISK_GB: 2 } },
]
Actual:
allocation_requests: [
{ cnrp: { VCPU: 1,
MEMORY_MB: 512,
DISK_GB: 2 } }
]
I will post a review shortly that demonstrates this.
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1724613/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1718545] Re: [vnc]vncserver_proxyclient_address and [vnc]vncserver_listen removed without deprecation
** Changed in: nova-powervm Importance: Undecided => High ** Changed in: nova-powervm Status: New => Fix Released ** Changed in: nova-powervm Assignee: (unassigned) => Eric Fried (efried) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1718545 Title: [vnc]vncserver_proxyclient_address and [vnc]vncserver_listen removed without deprecation Status in OpenStack Compute (nova): Fix Released Status in nova-powervm: Fix Released Bug description: [0] removed options [vnc]vncserver_proxyclient_address and [vnc]vncserver_listen without a deprecation period. Lemme splain: Take for example vncserver_proxyclient_address. It was originally [DEFAULT]vncserver_proxyclient_address. That was moved to [vnc]vncserver_proxyclient_address via [1]. We've had a nice long deprecation period (~18mo) during which either of those would work. So it would be reasonable at this time to remove support for [DEFAULT]vncserver_proxyclient_address. But by renaming the option without changing its deprecated_group to `vnc`, we've instead *left* support for [DEFAULT]vncserver_proxyclient_address while *removing* support for the newer [vnc]vncserver_proxyclient_address without a deprecation period. I noticed this when running tox against nova-powervm with the latest nova. nova-powervm paid attention to the deprecation and switched over to [vnc]vncserver_proxyclient_address. Now it fails a test with: Captured traceback: ~~~ Traceback (most recent call last): File "/home/efried/Neo/nova-powervm/.tox/py27/local/lib/python2.7/site-packages/mock/mock.py", line 1305, in patched return func(*args, **keywargs) File "nova_powervm/tests/virt/powervm/test_driver.py", line 1666, in test_get_vnc_console resp = self.drv.get_vnc_console(mock.ANY, self.inst) File "nova_powervm/virt/powervm/driver.py", line 1727, in get_vnc_console host = CONF.vnc.vncserver_proxyclient_address File "/home/efried/Neo/nova-powervm/.tox/py27/local/lib/python2.7/site-packages/oslo_config/cfg.py", line 3363, in __getattr__ return self._conf._get(name, self._group) File "/home/efried/Neo/nova-powervm/.tox/py27/local/lib/python2.7/site-packages/oslo_config/cfg.py", line 2925, in _get value = self._do_get(name, group, namespace) File "/home/efried/Neo/nova-powervm/.tox/py27/local/lib/python2.7/site-packages/oslo_config/cfg.py", line 2942, in _do_get info = self._get_opt_info(name, group) File "/home/efried/Neo/nova-powervm/.tox/py27/local/lib/python2.7/site-packages/oslo_config/cfg.py", line 3099, in _get_opt_info raise NoSuchOptError(opt_name, group) oslo_config.cfg.NoSuchOptError: no such option vncserver_proxyclient_address in group [vnc] But anyone should be able to repro by spinning up compute with [vnc]vncserver_proxyclient_address and trying to open a console. [0] https://review.openstack.org/#/c/498387/ [1] https://review.openstack.org/#/c/263763/ To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1718545/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1718545] Re: [vnc]vncserver_proxyclient_address and [vnc]vncserver_listen removed without deprecation
** Also affects: nova-powervm Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1718545 Title: [vnc]vncserver_proxyclient_address and [vnc]vncserver_listen removed without deprecation Status in OpenStack Compute (nova): In Progress Status in nova-powervm: New Bug description: [0] removed options [vnc]vncserver_proxyclient_address and [vnc]vncserver_listen without a deprecation period. Lemme splain: Take for example vncserver_proxyclient_address. It was originally [DEFAULT]vncserver_proxyclient_address. That was moved to [vnc]vncserver_proxyclient_address via [1]. We've had a nice long deprecation period (~18mo) during which either of those would work. So it would be reasonable at this time to remove support for [DEFAULT]vncserver_proxyclient_address. But by renaming the option without changing its deprecated_group to `vnc`, we've instead *left* support for [DEFAULT]vncserver_proxyclient_address while *removing* support for the newer [vnc]vncserver_proxyclient_address without a deprecation period. I noticed this when running tox against nova-powervm with the latest nova. nova-powervm paid attention to the deprecation and switched over to [vnc]vncserver_proxyclient_address. Now it fails a test with: Captured traceback: ~~~ Traceback (most recent call last): File "/home/efried/Neo/nova-powervm/.tox/py27/local/lib/python2.7/site-packages/mock/mock.py", line 1305, in patched return func(*args, **keywargs) File "nova_powervm/tests/virt/powervm/test_driver.py", line 1666, in test_get_vnc_console resp = self.drv.get_vnc_console(mock.ANY, self.inst) File "nova_powervm/virt/powervm/driver.py", line 1727, in get_vnc_console host = CONF.vnc.vncserver_proxyclient_address File "/home/efried/Neo/nova-powervm/.tox/py27/local/lib/python2.7/site-packages/oslo_config/cfg.py", line 3363, in __getattr__ return self._conf._get(name, self._group) File "/home/efried/Neo/nova-powervm/.tox/py27/local/lib/python2.7/site-packages/oslo_config/cfg.py", line 2925, in _get value = self._do_get(name, group, namespace) File "/home/efried/Neo/nova-powervm/.tox/py27/local/lib/python2.7/site-packages/oslo_config/cfg.py", line 2942, in _do_get info = self._get_opt_info(name, group) File "/home/efried/Neo/nova-powervm/.tox/py27/local/lib/python2.7/site-packages/oslo_config/cfg.py", line 3099, in _get_opt_info raise NoSuchOptError(opt_name, group) oslo_config.cfg.NoSuchOptError: no such option vncserver_proxyclient_address in group [vnc] But anyone should be able to repro by spinning up compute with [vnc]vncserver_proxyclient_address and trying to open a console. [0] https://review.openstack.org/#/c/498387/ [1] https://review.openstack.org/#/c/263763/ To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1718545/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1718545] [NEW] [vnc]vncserver_proxyclient_address and [vnc]vncserver_listen removed without deprecation
Public bug reported: [0] removed options [vnc]vncserver_proxyclient_address and [vnc]vncserver_listen without a deprecation period. Lemme splain: Take for example vncserver_proxyclient_address. It was originally [DEFAULT]vncserver_proxyclient_address. That was moved to [vnc]vncserver_proxyclient_address via [1]. We've had a nice long deprecation period (~18mo) during which either of those would work. So it would be reasonable at this time to remove support for [DEFAULT]vncserver_proxyclient_address. But by renaming the option without changing its deprecated_group to `vnc`, we've instead *left* support for [DEFAULT]vncserver_proxyclient_address while *removing* support for the newer [vnc]vncserver_proxyclient_address without a deprecation period. I noticed this when running tox against nova-powervm with the latest nova. nova-powervm paid attention to the deprecation and switched over to [vnc]vncserver_proxyclient_address. Now it fails a test with: Captured traceback: ~~~ Traceback (most recent call last): File "/home/efried/Neo/nova-powervm/.tox/py27/local/lib/python2.7/site-packages/mock/mock.py", line 1305, in patched return func(*args, **keywargs) File "nova_powervm/tests/virt/powervm/test_driver.py", line 1666, in test_get_vnc_console resp = self.drv.get_vnc_console(mock.ANY, self.inst) File "nova_powervm/virt/powervm/driver.py", line 1727, in get_vnc_console host = CONF.vnc.vncserver_proxyclient_address File "/home/efried/Neo/nova-powervm/.tox/py27/local/lib/python2.7/site-packages/oslo_config/cfg.py", line 3363, in __getattr__ return self._conf._get(name, self._group) File "/home/efried/Neo/nova-powervm/.tox/py27/local/lib/python2.7/site-packages/oslo_config/cfg.py", line 2925, in _get value = self._do_get(name, group, namespace) File "/home/efried/Neo/nova-powervm/.tox/py27/local/lib/python2.7/site-packages/oslo_config/cfg.py", line 2942, in _do_get info = self._get_opt_info(name, group) File "/home/efried/Neo/nova-powervm/.tox/py27/local/lib/python2.7/site-packages/oslo_config/cfg.py", line 3099, in _get_opt_info raise NoSuchOptError(opt_name, group) oslo_config.cfg.NoSuchOptError: no such option vncserver_proxyclient_address in group [vnc] But anyone should be able to repro by spinning up compute with [vnc]vncserver_proxyclient_address and trying to open a console. [0] https://review.openstack.org/#/c/498387/ [1] https://review.openstack.org/#/c/263763/ ** Affects: nova Importance: High Status: Triaged ** Tags: config -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1718545 Title: [vnc]vncserver_proxyclient_address and [vnc]vncserver_listen removed without deprecation Status in OpenStack Compute (nova): Triaged Bug description: [0] removed options [vnc]vncserver_proxyclient_address and [vnc]vncserver_listen without a deprecation period. Lemme splain: Take for example vncserver_proxyclient_address. It was originally [DEFAULT]vncserver_proxyclient_address. That was moved to [vnc]vncserver_proxyclient_address via [1]. We've had a nice long deprecation period (~18mo) during which either of those would work. So it would be reasonable at this time to remove support for [DEFAULT]vncserver_proxyclient_address. But by renaming the option without changing its deprecated_group to `vnc`, we've instead *left* support for [DEFAULT]vncserver_proxyclient_address while *removing* support for the newer [vnc]vncserver_proxyclient_address without a deprecation period. I noticed this when running tox against nova-powervm with the latest nova. nova-powervm paid attention to the deprecation and switched over to [vnc]vncserver_proxyclient_address. Now it fails a test with: Captured traceback: ~~~ Traceback (most recent call last): File "/home/efried/Neo/nova-powervm/.tox/py27/local/lib/python2.7/site-packages/mock/mock.py", line 1305, in patched return func(*args, **keywargs) File "nova_powervm/tests/virt/powervm/test_driver.py", line 1666, in test_get_vnc_console resp = self.drv.get_vnc_console(mock.ANY, self.inst) File "nova_powervm/virt/powervm/driver.py", line 1727, in get_vnc_console host = CONF.vnc.vncserver_proxyclient_address File "/home/efried/Neo/nova-powervm/.tox/py27/local/lib/python2.7/site-packages/oslo_config/cfg.py", line 3363, in __getattr__ return self._conf._get(name, self._group) File "/home/efried/Neo/nova-powervm/.tox/py27/local/lib/python2.7/site-packages/oslo_config/cfg.py", line 2925, in _get value = self._do_get(name, group, namespace) File
[Yahoo-eng-team] [Bug 1714284] Re: Placement user doc: add link to API reference
** Changed in: nova Status: In Progress => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1714284 Title: Placement user doc: add link to API reference Status in OpenStack Compute (nova): Fix Released Bug description: The Placement API user doc [1] says: API Reference A full API reference is forthcoming, but until then ... That reference has since been published [2]. [1] https://docs.openstack.org/nova/pike/user/placement.html#api-reference [2] https://developer.openstack.org/api-ref/placement/ To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1714284/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1714283] Re: Placement API reference: GET /traits query parameter starts_with should be startswith
Meh, since I opened it, might as well use it. ** Changed in: nova Status: Invalid => New ** Changed in: nova Assignee: (unassigned) => Eric Fried (efried) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1714283 Title: Placement API reference: GET /traits query parameter starts_with should be startswith Status in OpenStack Compute (nova): In Progress Bug description: In the Placement API reference, the GET /traits [1] query parameter 'name' says it accepts a key called 'starts_with'. The actual API accepts 'startswith' (no underscore). [1] https://developer.openstack.org/api-ref/placement/#list-traits To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1714283/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1714283] Re: Placement API reference: GET /traits query parameter starts_with should be startswith
Sorry, opened the wrong bug. ** Changed in: nova Status: New => Invalid -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1714283 Title: Placement API reference: GET /traits query parameter starts_with should be startswith Status in OpenStack Compute (nova): In Progress Bug description: In the Placement API reference, the GET /traits [1] query parameter 'name' says it accepts a key called 'starts_with'. The actual API accepts 'startswith' (no underscore). [1] https://developer.openstack.org/api-ref/placement/#list-traits To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1714283/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1714283] [NEW] Placement API reference: GET /traits query parameter starts_with should be startswith
Public bug reported: In the Placement API reference, the GET /traits [1] query parameter 'name' says it accepts a key called 'starts_with'. The actual API accepts 'startswith' (no underscore). [1] https://developer.openstack.org/api-ref/placement/#list-traits ** Affects: nova Importance: Undecided Assignee: Eric Fried (efried) Status: In Progress -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1714283 Title: Placement API reference: GET /traits query parameter starts_with should be startswith Status in OpenStack Compute (nova): In Progress Bug description: In the Placement API reference, the GET /traits [1] query parameter 'name' says it accepts a key called 'starts_with'. The actual API accepts 'startswith' (no underscore). [1] https://developer.openstack.org/api-ref/placement/#list-traits To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1714283/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1714284] [NEW] Placement user doc: add link to API reference
Public bug reported: The Placement API user doc [1] says: API Reference A full API reference is forthcoming, but until then ... That reference has since been published [2]. [1] https://docs.openstack.org/nova/pike/user/placement.html#api-reference [2] https://developer.openstack.org/api-ref/placement/ ** Affects: nova Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1714284 Title: Placement user doc: add link to API reference Status in OpenStack Compute (nova): New Bug description: The Placement API user doc [1] says: API Reference A full API reference is forthcoming, but until then ... That reference has since been published [2]. [1] https://docs.openstack.org/nova/pike/user/placement.html#api-reference [2] https://developer.openstack.org/api-ref/placement/ To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1714284/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1714275] [NEW] GET /resource_providers: "links" doesn't include "allocations"
Public bug reported:
GET /resource_providers returns:
{
"resource_providers": [
{
"generation": 39,
"uuid": "213fd7f8-1e9f-466b-87bf-0902b0b3bc13",
"links": [
{
"href":
"/placement/resource_providers/213fd7f8-1e9f-466b-87bf-0902b0b3bc13",
"rel": "self"
},
{
"href":
"/placement/resource_providers/213fd7f8-1e9f-466b-87bf-0902b0b3bc13/inventories",
"rel": "inventories"
},
{
"href":
"/placement/resource_providers/213fd7f8-1e9f-466b-87bf-0902b0b3bc13/usages",
"rel": "usages"
},
{
"href":
"/placement/resource_providers/213fd7f8-1e9f-466b-87bf-0902b0b3bc13/aggregates",
"rel": "aggregates"
},
{
"href":
"/placement/resource_providers/213fd7f8-1e9f-466b-87bf-0902b0b3bc13/traits",
"rel": "traits"
}
],
"name": "p8-100-neo"
}
]
}
The link for "/resource_providers/213fd7f8-1e9f-466b-87bf-
0902b0b3bc13/allocations" is missing.
For reference: https://review.openstack.org/#/c/366789/ added the
/resource_providers//allocations target; and
https://review.openstack.org/#/c/468923/ did the per-microversion
splitup of which links were reported. They were dropped in that order,
by the same author (cdent), so maybe there's a reason for this...
Placement microversion 1.10
Devstack on PowerVM
Nova master branch at commit 4579d2e5573ae1bbabb51ee46ef26598d9410b15
(Aug 11)
** Affects: nova
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1714275
Title:
GET /resource_providers: "links" doesn't include "allocations"
Status in OpenStack Compute (nova):
New
Bug description:
GET /resource_providers returns:
{
"resource_providers": [
{
"generation": 39,
"uuid": "213fd7f8-1e9f-466b-87bf-0902b0b3bc13",
"links": [
{
"href":
"/placement/resource_providers/213fd7f8-1e9f-466b-87bf-0902b0b3bc13",
"rel": "self"
},
{
"href":
"/placement/resource_providers/213fd7f8-1e9f-466b-87bf-0902b0b3bc13/inventories",
"rel": "inventories"
},
{
"href":
"/placement/resource_providers/213fd7f8-1e9f-466b-87bf-0902b0b3bc13/usages",
"rel": "usages"
},
{
"href":
"/placement/resource_providers/213fd7f8-1e9f-466b-87bf-0902b0b3bc13/aggregates",
"rel": "aggregates"
},
{
"href":
"/placement/resource_providers/213fd7f8-1e9f-466b-87bf-0902b0b3bc13/traits",
"rel": "traits"
}
],
"name": "p8-100-neo"
}
]
}
The link for "/resource_providers/213fd7f8-1e9f-466b-87bf-
0902b0b3bc13/allocations" is missing.
For reference: https://review.openstack.org/#/c/366789/ added the
/resource_providers//allocations target; and
https://review.openstack.org/#/c/468923/ did the per-microversion
splitup of which links were reported. They were dropped in that
order, by the same author (cdent), so maybe there's a reason for
this...
Placement microversion 1.10
Devstack on PowerVM
Nova master branch at commit 4579d2e5573ae1bbabb51ee46ef26598d9410b15
(Aug 11)
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1714275/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1713502] Re: PCI passthrough documentation needs updating since options moved to [pci] section
https://review.openstack.org/#/c/498461 (master branch fix) merged on 8/28. Bot didn't auto-update the status, so I did it. ** Changed in: nova Status: In Progress => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1713502 Title: PCI passthrough documentation needs updating since options moved to [pci] section Status in OpenStack Compute (nova): Fix Released Bug description: The ``pci_passthrough_whitelist`` and ``pci_alias`` options in the ``[DEFAULT]`` section were deprecated and replaced by ``passthrough_whitelist`` and ``alias`` in the ``[pci]`` section, respectively, in ocata via [1]. However, the PCI passthrough documentation [2] was missed. [1] https://review.openstack.org/#/c/356604/ [2] https://docs.openstack.org/nova/pike/admin/pci-passthrough.html To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1713502/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1713502] [NEW] PCI passthrough documentation needs updating since options moved to [pci] section
Public bug reported: The ``pci_passthrough_whitelist`` and ``pci_alias`` options in the ``[DEFAULT]`` section were deprecated and replaced by ``passthrough_whitelist`` and ``alias`` in the ``[pci]`` section, respectively, in ocata via [1]. However, the PCI passthrough documentation [2] was missed. [1] https://review.openstack.org/#/c/356604/ [2] https://docs.openstack.org/nova/pike/admin/pci-passthrough.html ** Affects: nova Importance: Undecided Assignee: Eric Fried (efried) Status: In Progress -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1713502 Title: PCI passthrough documentation needs updating since options moved to [pci] section Status in OpenStack Compute (nova): In Progress Bug description: The ``pci_passthrough_whitelist`` and ``pci_alias`` options in the ``[DEFAULT]`` section were deprecated and replaced by ``passthrough_whitelist`` and ``alias`` in the ``[pci]`` section, respectively, in ocata via [1]. However, the PCI passthrough documentation [2] was missed. [1] https://review.openstack.org/#/c/356604/ [2] https://docs.openstack.org/nova/pike/admin/pci-passthrough.html To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1713502/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1709118] [NEW] _ContextAuthPlugin needs a refresh
Public bug reported: nova.context._ContextAuthPlugin is (sometimes) being used as the basis for keystoneauth1 endpoint discovery. With the advent of ksa 3.1.0, there are some new methods consumers are expecting to be able to run on an auth via a ksa Session or Adapter. (Note that they were added to BaseIdentityPlugin without being added as abstract methods to BaseAuthPlugin - this is probably a ksa bug.) An example of such a method is get_endpoint_data(). Now, it appears from the docstring that the only reason _ContextAuthPlugin exists is that the auths we get from keystone middleware are not serializable. This may have changed since that docstring was written in 2014. So: we should either update _ContextAuthPlugin to provide the methods ksa expects (perhaps in response to a fixup in ksa's BaseAuthPlugin abc that mandates those methods be implemented); or (better) figure out a way to get rid of _ContextAuthPlugin entirely and just use what keystone provides. A manifestation of this problem can be seen in the work for bp use- service-catalog-for-endpoints. This change [1] is in response to ksa Adapter.get_endpoint_data() raising AttributeError because Adapter.get_endpoint_data eventually filters down to Adapter.auth.get_endpoint_data; which breaks when the auth is a _ContextAuthPlugin. [1] https://review.openstack.org/#/c/490057/3..4/nova/image/glance.py ** Affects: nova Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1709118 Title: _ContextAuthPlugin needs a refresh Status in OpenStack Compute (nova): New Bug description: nova.context._ContextAuthPlugin is (sometimes) being used as the basis for keystoneauth1 endpoint discovery. With the advent of ksa 3.1.0, there are some new methods consumers are expecting to be able to run on an auth via a ksa Session or Adapter. (Note that they were added to BaseIdentityPlugin without being added as abstract methods to BaseAuthPlugin - this is probably a ksa bug.) An example of such a method is get_endpoint_data(). Now, it appears from the docstring that the only reason _ContextAuthPlugin exists is that the auths we get from keystone middleware are not serializable. This may have changed since that docstring was written in 2014. So: we should either update _ContextAuthPlugin to provide the methods ksa expects (perhaps in response to a fixup in ksa's BaseAuthPlugin abc that mandates those methods be implemented); or (better) figure out a way to get rid of _ContextAuthPlugin entirely and just use what keystone provides. A manifestation of this problem can be seen in the work for bp use- service-catalog-for-endpoints. This change [1] is in response to ksa Adapter.get_endpoint_data() raising AttributeError because Adapter.get_endpoint_data eventually filters down to Adapter.auth.get_endpoint_data; which breaks when the auth is a _ContextAuthPlugin. [1] https://review.openstack.org/#/c/490057/3..4/nova/image/glance.py To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1709118/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1682087] Re:
Likely same root cause as https://bugs.launchpad.net/nova/+bug/1682195
This is more of a support request than a bug. Please ask for help on
IRC in #openstack.
** This bug is no longer a duplicate of bug 1678493
oslo_messaging.exceptions.MessagingTimeout
** Changed in: nova
Status: New => Invalid
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1682087
Title:
Status in OpenStack Compute (nova):
Invalid
Bug description:
I installed openstack Newton in Ubuntu 16.04.
When I try to launch an instance I get an error Unexpected API Error.
Please report this at http://bugs.launchpad.net/nova/ and attach the
Nova API log if possible. (HTTP 500) (Request-ID:
req-ff1f37e8-a875-4375-b036-de514a908e07)
I checked the log files and I found errors
the /var/log/nova/nova-api.log :
2017-04-12 12:41:34.607 28635 ERROR nova.api.openstack.extensions result
= self._waiter.wait(msg_id, timeout)
2017-04-12 12:41:34.607 28635 ERROR nova.api.openstack.extensions File
"/usr/lib/python2.7/dist-packages/oslo_messaging/_drivers/amqpdriver.py", line
336, in wait
2017-04-12 12:41:34.607 28635 ERROR nova.api.openstack.extensions message
= self.waiters.get(msg_id, timeout=timeout)
2017-04-12 12:41:34.607 28635 ERROR nova.api.openstack.extensions File
"/usr/lib/python2.7/dist-packages/oslo_messaging/_drivers/amqpdriver.py", line
238, in get
2017-04-12 12:41:34.607 28635 ERROR nova.api.openstack.extensions 'to
message ID %s' % msg_id)
2017-04-12 12:41:34.607 28635 ERROR nova.api.openstack.extensions
MessagingTimeout: Timed out waiting for a reply to message ID
8538246dba7348d3b52eb0fbd0a60a03
2017-04-12 12:41:34.607 28635 ERROR nova.api.openstack.extensions
2017-04-12 12:41:34.609 28635 INFO nova.api.openstack.wsgi
[req-ff1f37e8-a875-4375-b036-de514a908e07 1fdf459e4f694fde85818b178e1e9199
da7d418c8b414fc3b236800183794125 - default default] HTTP exception thrown:
Unexpected API Error. Please report this at http://bugs.launchpad.net/nova/ and
attach the Nova API log if possible.
2017-04-12 12:41:34.610 28635 INFO nova.osapi_compute.wsgi.server
[req-ff1f37e8-a875-4375-b036-de514a908e07 1fdf459e4f694fde85818b178e1e9199
da7d418c8b414fc3b236800183794125 - default default] 127.0.0.1 "POST
/v2.1/da7d418c8b414fc3b236800183794125/servers HTTP/1.1" status: 500 len: 583
time: 60.7773261
the /var/log/neutron/neutron-server.log :
2017-04-12 12:43:10.527 27006 ERROR neutron.plugins.ml2.managers
[req-2ee46e05-f015-4fe2-beca-7cbe3e01e48e - - - - -] Failed to bind port
bfa09754-f961-4c81-8b52-256e2028f1e1 on host controller-HP-Z210-Workstation for
vnic_type normal using segments [{'segmentation_id': 20, 'physical_network':
None, 'id': u'3aa7bf2f-9223-4e94-801b-aee4b4975951', 'network_type': u'vxlan'}]
2017-04-12 12:43:10.539 27006 WARNING neutron.plugins.ml2.drivers.mech_agent
[req-b86fae66-1171-41c9-ba6a-ebdd24c656ed - - - - -] Refusing to bind port
115144de-8215-4e9c-b6d3-d44c40b9a191 to dead agent: {'binary':
u'neutron-linuxbridge-agent', 'description': None, 'admin_state_up': True,
'heartbeat_timestamp': datetime.datetime(2017, 4, 11, 8, 5),
'availability_zone': None, 'alive': False, 'topic': u'N/A', 'host':
u'controller-HP-Z210-Workstation', 'agent_type': u'Linux bridge agent',
'resource_versions': {u'SubPort': u'1.0', u'QosPolicy': u'1.3', u'Trunk':
u'1.0'}, 'created_at': datetime.datetime(2017, 4, 7, 13, 55, 26), 'started_at':
datetime.datetime(2017, 4, 10, 14, 26, 58), 'id':
u'65694cc5-f8bf-473f-95d2-550438f52885', 'configurations': {u'tunneling_ip':
u'192.168.3.202', u'devices': 3, u'interface_mappings': {u'provider': u'eno1'},
u'extensions': [], u'l2_population': True, u'tunnel_types': [u'vxlan'],
u'bridge_mappings': {}}}
2017-04-12 12:43:10.540 27006 ERROR neutron.plugins.ml2.managers
[req-b86fae66-1171-41c9-ba6a-ebdd24c656ed - - - - -] Failed to bind port
115144de-8215-4e9c-b6d3-d44c40b9a191 on host controller-HP-Z210-Workstation for
vnic_type normal using segments [{'segmentation_id': 65, 'physical_network':
None, 'id': u'7cdbfc98-0f8e-4104-987b-3be70a8a36fa', 'network_type': u'vxlan'}]
I didn't find a solution to this problem
Please help.
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1682087/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1682088] Re:
Likely same root cause as https://bugs.launchpad.net/nova/+bug/1682195
This is more of a support request than a bug. Please ask for help on
IRC in #openstack.
** This bug is no longer a duplicate of bug 1678493
oslo_messaging.exceptions.MessagingTimeout
** Changed in: nova
Status: New => Invalid
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1682088
Title:
Status in OpenStack Compute (nova):
Invalid
Bug description:
I installed openstack Newton in Ubuntu 16.04.
When I try to launch an instance I get an error Unexpected API Error.
Please report this at http://bugs.launchpad.net/nova/ and attach the
Nova API log if possible. (HTTP 500) (Request-ID:
req-ff1f37e8-a875-4375-b036-de514a908e07)
I checked the log files and I found errors
the /var/log/nova/nova-api.log :
2017-04-12 12:41:34.607 28635 ERROR nova.api.openstack.extensions result
= self._waiter.wait(msg_id, timeout)
2017-04-12 12:41:34.607 28635 ERROR nova.api.openstack.extensions File
"/usr/lib/python2.7/dist-packages/oslo_messaging/_drivers/amqpdriver.py", line
336, in wait
2017-04-12 12:41:34.607 28635 ERROR nova.api.openstack.extensions message
= self.waiters.get(msg_id, timeout=timeout)
2017-04-12 12:41:34.607 28635 ERROR nova.api.openstack.extensions File
"/usr/lib/python2.7/dist-packages/oslo_messaging/_drivers/amqpdriver.py", line
238, in get
2017-04-12 12:41:34.607 28635 ERROR nova.api.openstack.extensions 'to
message ID %s' % msg_id)
2017-04-12 12:41:34.607 28635 ERROR nova.api.openstack.extensions
MessagingTimeout: Timed out waiting for a reply to message ID
8538246dba7348d3b52eb0fbd0a60a03
2017-04-12 12:41:34.607 28635 ERROR nova.api.openstack.extensions
2017-04-12 12:41:34.609 28635 INFO nova.api.openstack.wsgi
[req-ff1f37e8-a875-4375-b036-de514a908e07 1fdf459e4f694fde85818b178e1e9199
da7d418c8b414fc3b236800183794125 - default default] HTTP exception thrown:
Unexpected API Error. Please report this at http://bugs.launchpad.net/nova/ and
attach the Nova API log if possible.
2017-04-12 12:41:34.610 28635 INFO nova.osapi_compute.wsgi.server
[req-ff1f37e8-a875-4375-b036-de514a908e07 1fdf459e4f694fde85818b178e1e9199
da7d418c8b414fc3b236800183794125 - default default] 127.0.0.1 "POST
/v2.1/da7d418c8b414fc3b236800183794125/servers HTTP/1.1" status: 500 len: 583
time: 60.7773261
the /var/log/neutron/neutron-server.log :
2017-04-12 12:43:10.527 27006 ERROR neutron.plugins.ml2.managers
[req-2ee46e05-f015-4fe2-beca-7cbe3e01e48e - - - - -] Failed to bind port
bfa09754-f961-4c81-8b52-256e2028f1e1 on host controller-HP-Z210-Workstation for
vnic_type normal using segments [{'segmentation_id': 20, 'physical_network':
None, 'id': u'3aa7bf2f-9223-4e94-801b-aee4b4975951', 'network_type': u'vxlan'}]
2017-04-12 12:43:10.539 27006 WARNING neutron.plugins.ml2.drivers.mech_agent
[req-b86fae66-1171-41c9-ba6a-ebdd24c656ed - - - - -] Refusing to bind port
115144de-8215-4e9c-b6d3-d44c40b9a191 to dead agent: {'binary':
u'neutron-linuxbridge-agent', 'description': None, 'admin_state_up': True,
'heartbeat_timestamp': datetime.datetime(2017, 4, 11, 8, 5),
'availability_zone': None, 'alive': False, 'topic': u'N/A', 'host':
u'controller-HP-Z210-Workstation', 'agent_type': u'Linux bridge agent',
'resource_versions': {u'SubPort': u'1.0', u'QosPolicy': u'1.3', u'Trunk':
u'1.0'}, 'created_at': datetime.datetime(2017, 4, 7, 13, 55, 26), 'started_at':
datetime.datetime(2017, 4, 10, 14, 26, 58), 'id':
u'65694cc5-f8bf-473f-95d2-550438f52885', 'configurations': {u'tunneling_ip':
u'192.168.3.202', u'devices': 3, u'interface_mappings': {u'provider': u'eno1'},
u'extensions': [], u'l2_population': True, u'tunnel_types': [u'vxlan'],
u'bridge_mappings': {}}}
2017-04-12 12:43:10.540 27006 ERROR neutron.plugins.ml2.managers
[req-b86fae66-1171-41c9-ba6a-ebdd24c656ed - - - - -] Failed to bind port
115144de-8215-4e9c-b6d3-d44c40b9a191 on host controller-HP-Z210-Workstation for
vnic_type normal using segments [{'segmentation_id': 65, 'physical_network':
None, 'id': u'7cdbfc98-0f8e-4104-987b-3be70a8a36fa', 'network_type': u'vxlan'}]
I didn't find a solution to this problem
Please help.
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1682088/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1677047] [NEW] glance download fsync raises EINVAL for FIFOs
Public bug reported: Description === The nova.image.glance.GlanceImageServiceV2.download method recently added fsync [1][2] before closing the download file. Some hypervisors don't use regular files for download. For example, PowerVM uses a FIFO pipe, the other end of which is read by a service that offloads the image data to a remote node. fsync on a pipe, FIFO, or socket errors with EINVAL [3]. [1] https://review.openstack.org/#/c/441246/ [2] https://review.openstack.org/#/c/443583/ [3] http://man7.org/linux/man-pages/man2/fsync.2.html#ERRORS Steps to reproduce == Invoke nova.image.glance.GlanceImageServiceV2.download with data=None, dst_path=path where path represents a FIFO or socket. Expected result === Successful transfer of data through the FIFO/socket. Actual result = An exception similar to the following: File "/usr/local/lib/python2.7/dist-packages/pypowervm/internal_utils/thread_utils.py", line 34, in future_func return func(*args, **kwargs) File "/opt/stack/nova/nova/virt/powervm/disk/ssp.py", line 161, in upload IMAGE_API.download(context, image_meta.id, dest_path=path) File "/opt/stack/nova/nova/image/api.py", line 184, in download dst_path=dest_path) File "/opt/stack/nova/nova/image/glance.py", line 387, in download os.fsync(data.fileno()) OSError: [Errno 22] Invalid argument Immutable reference to the offending fsync call: https://github.com/openstack/nova/blob/640b152004fe3d9c43c26538809c3ac796f20eba/nova/image/glance.py#L375 Environment === devstack, pike, with the nova tree at this in-flight patch set: https://review.openstack.org/#/c/443189/15 Ubuntu 16.04.1 LTS running on PowerVM NovaLink, using Shared Storage Pools through a single VIOS. No networking. Logs & Configs == Available on request if needed. This is a snap to reproduce. ** Affects: nova Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1677047 Title: glance download fsync raises EINVAL for FIFOs Status in OpenStack Compute (nova): New Bug description: Description === The nova.image.glance.GlanceImageServiceV2.download method recently added fsync [1][2] before closing the download file. Some hypervisors don't use regular files for download. For example, PowerVM uses a FIFO pipe, the other end of which is read by a service that offloads the image data to a remote node. fsync on a pipe, FIFO, or socket errors with EINVAL [3]. [1] https://review.openstack.org/#/c/441246/ [2] https://review.openstack.org/#/c/443583/ [3] http://man7.org/linux/man-pages/man2/fsync.2.html#ERRORS Steps to reproduce == Invoke nova.image.glance.GlanceImageServiceV2.download with data=None, dst_path=path where path represents a FIFO or socket. Expected result === Successful transfer of data through the FIFO/socket. Actual result = An exception similar to the following: File "/usr/local/lib/python2.7/dist-packages/pypowervm/internal_utils/thread_utils.py", line 34, in future_func return func(*args, **kwargs) File "/opt/stack/nova/nova/virt/powervm/disk/ssp.py", line 161, in upload IMAGE_API.download(context, image_meta.id, dest_path=path) File "/opt/stack/nova/nova/image/api.py", line 184, in download dst_path=dest_path) File "/opt/stack/nova/nova/image/glance.py", line 387, in download os.fsync(data.fileno()) OSError: [Errno 22] Invalid argument Immutable reference to the offending fsync call: https://github.com/openstack/nova/blob/640b152004fe3d9c43c26538809c3ac796f20eba/nova/image/glance.py#L375 Environment === devstack, pike, with the nova tree at this in-flight patch set: https://review.openstack.org/#/c/443189/15 Ubuntu 16.04.1 LTS running on PowerVM NovaLink, using Shared Storage Pools through a single VIOS. No networking. Logs & Configs == Available on request if needed. This is a snap to reproduce. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1677047/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1673305] Re: No host-to-cell mapping found for selected host packstack. Setup is incomplete.
Not sure if adding "affects nova" is entirely appropriate, but we encountered this when testing this patch with the PowerVM driver: https://review.openstack.org/443189 which is currently based on commit 80af8a9dacf6fbd853b5b0e07ffb8bffac3aa8fa of the nova tree. After I ran the nova-manage command suggested by amoralej in comment #2, I was able to proceed. ** Also affects: nova Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1673305 Title: No host-to-cell mapping found for selected host packstack. Setup is incomplete. Status in OpenStack Compute (nova): New Status in Packstack: New Bug description: CentOS Packstack installation. nova-conductor.log 2017-03-15 21:27:59.521 4664 WARNING oslo_reports.guru_meditation_report [-] Guru meditation now registers SIGUSR1 and SIGUSR2 by default for backward compatibility. SIGUSR1 will no longer be registered in a future release, so please use SIGUSR2 to generate reports. 2017-03-15 21:27:59.532 4664 WARNING oslo_config.cfg [req-50f24c2c-b031-4a5b-8a64-c057b2dbb56e - - - - -] Option "use_neutron" from group "DEFAULT" is deprecated for removal. Its value may be silently ignored in the future. 2017-03-15 21:27:59.545 4664 INFO oslo_service.service [req-50f24c2c-b031-4a5b-8a64-c057b2dbb56e - - - - -] Starting 4 workers 2017-03-15 21:27:59.561 4683 INFO nova.service [-] Starting conductor node (version 15.0.0-1.el7) 2017-03-15 21:27:59.566 4684 INFO nova.service [-] Starting conductor node (version 15.0.0-1.el7) 2017-03-15 21:27:59.581 4686 INFO nova.service [-] Starting conductor node (version 15.0.0-1.el7) 2017-03-15 21:27:59.588 4664 WARNING oslo_config.cfg [req-50f24c2c-b031-4a5b-8a64-c057b2dbb56e - - - - -] Option "dhcp_domain" from group "DEFAULT" is deprecated for removal. Its value may be silently ignored in the future. 2017-03-15 21:27:59.590 4664 WARNING oslo_config.cfg [req-50f24c2c-b031-4a5b-8a64-c057b2dbb56e - - - - -] Option "force_dhcp_release" from group "DEFAULT" is deprecated for removal. Its value may be silently ignored in the future. 2017-03-15 21:27:59.593 4664 WARNING oslo_config.cfg [req-50f24c2c-b031-4a5b-8a64-c057b2dbb56e - - - - -] Option "rpc_backend" from group "DEFAULT" is deprecated for removal. Its value may be silently ignored in the future. 2017-03-15 21:27:59.576 4685 INFO nova.service [-] Starting conductor node (version 15.0.0-1.el7) 2017-03-15 21:55:14.655 4686 ERROR nova.conductor.manager [req-1b40d2a2-e633-469c-93da-dd4912101ce2 - - - - -] No host-to-cell mapping found for selected host packstack. Setup is incomplete. 2017-03-15 21:55:15.018 4686 WARNING nova.scheduler.utils [req-1b40d2a2-e633-469c-93da-dd4912101ce2 - - - - -] Failed to compute_task_build_instances: Host 'packstack' is not mapped to any cell 2017-03-15 21:55:15.019 4686 WARNING nova.scheduler.utils [req-1b40d2a2-e633-469c-93da-dd4912101ce2 - - - - -] [instance: a23d692f-0280-4c15-948a-e4b17686fd2b] Setting instance to ERROR state.sudo yum install -y centos-release-openstack-ocata Everything is working fine. I can access dashboard i can create networks and routers but i cant start an instance. Every time in error state with this error. Tried to install with sudo yum install -y centos-release-openstack-ocata version and then clean installed againt with newton and it is the same problem. answers.txt is in the attachment To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1673305/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1638339] [NEW] mitaka docs build breaks on vine.five
Public bug reported: In attempting to track down build failures in an out-of-tree project, I submitted a change set to try out the nova gate in mitaka. It failed the docs build on the vine.five switch in kombu. The change set is here: https://review.openstack.org/#/c/392200/ The failure log is here: http://logs.openstack.org/00/392200/1/check/gate-nova-docs-ubuntu-trusty/55fb272/console.html#_2016-11-01_15_22_32_787002 (Does the docs build not honor the upper constraints set in the generic [testenv]?) ** Affects: nova Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1638339 Title: mitaka docs build breaks on vine.five Status in OpenStack Compute (nova): New Bug description: In attempting to track down build failures in an out-of-tree project, I submitted a change set to try out the nova gate in mitaka. It failed the docs build on the vine.five switch in kombu. The change set is here: https://review.openstack.org/#/c/392200/ The failure log is here: http://logs.openstack.org/00/392200/1/check/gate-nova-docs-ubuntu-trusty/55fb272/console.html#_2016-11-01_15_22_32_787002 (Does the docs build not honor the upper constraints set in the generic [testenv]?) To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1638339/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1615128] [NEW] Custom binding:profile values not coming through
Public bug reported:
1) Create a port with custom binding:profile values, e.g.:
$ neutron port-create --vnic-type direct ab85306c-0861-4ef0-b127-1bedc8fc94f3
-- --binding:profile type=dict vnic_required_vfs=3,capacity=0.06
Created a new port:
+---++
| Field | Value
|
+---++
| admin_state_up| True
|
| allowed_address_pairs |
|
| binding:host_id |
|
| binding:profile | {"vnic_required_vfs": "3", "capacity": "0.06"}
|
| binding:vif_details | {}
|
| binding:vif_type | unbound
|
| binding:vnic_type | direct
|
| created_at| 2016-08-19T17:04:01
|
| description |
|
| device_id |
|
| device_owner |
|
| extra_dhcp_opts |
|
| fixed_ips | {"subnet_id": "47171599-7a0d-480a-82c7-adf8f58ecf52",
"ip_address": "172.24.4.12"} |
| | {"subnet_id": "ddc562b9-65c3-48fe-8b3e-20ac98630375",
"ip_address": "2001:db8::d"} |
| id| ff17dcab-bbf7-44f4-8f65-0e7dc32b611b
|
| mac_address | fa:16:3e:4f:4b:d0
|
| name |
|
| network_id| ab85306c-0861-4ef0-b127-1bedc8fc94f3
|
| port_security_enabled | True
|
| revision | 5
|
| security_groups | 98413527-6c85-4c16-8fe9-da0f3fdcaa97
|
| status| DOWN
|
| tenant_id | aac7c974992c44b7aaf4ecf6049c2165
|
| updated_at| 2016-08-19T17:06:17
|
+---++
2) Boot an instance with that port, e.g.
$ nova boot --flavor 1 --image 58bc4e42-0189-4f4b-bdff-dfe7fcabf414
efried1 --nic port-id=ff17dcab-bbf7-44f4-8f65-0e7dc32b611b
3) The mechanism driver, accessing the binding:profile via:
profile = context.current.get(portbindings.PROFILE, {})
...cannot see the custom values.
==
I believe the reason lies here:
https://github.com/openstack/neutron/blob/master/neutron/plugins/ml2/plugin.py#L310-L319
310if attrs and portbindings.PROFILE in attrs:
311profile = attrs.get(portbindings.PROFILE) or {}
312
313if profile not in (None, const.ATTR_NOT_SPECIFIED,
314 self._get_profile(binding)):
315binding.profile = jsonutils.dumps(profile)
316if len(binding.profile) > models.BINDING_PROFILE_LEN:
317msg = _("binding:profile value too large")
318raise exc.InvalidInput(error_message=msg)
319changes = True
Stepping through the mech driver, binding.profile contains the custom
values:
(Pdb) pp binding.profile
u'{"vnic_required_vfs": "3", "capacity": "0.06"}'
But attrs does not:
(Pdb) pp attrs['binding:profile']
{u'pci_slot': u'*:*:*.*',
u'pci_vendor_info': u'*:*',
u'physical_network': u'default'}
At this point, the condition on lines 313-4 succeds, and binding.profile
is overwritten with the contents of attrs['binding:profile']
=
Proposal is to *combine* the two dicts in this scenario, so the
resulting binding.profile will in fact contain:
{u'pci_slot': u'*:*:*.*',
[Yahoo-eng-team] [Bug 1609848] Re: Un-ignore PEP8 rules in tox
Seems that all of the rules are being ignored for good (or at least agreed-upon) reasons. See https://review.openstack.org/#/c/351253/ ** Changed in: nova Status: New => Invalid -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1609848 Title: Un-ignore PEP8 rules in tox Status in OpenStack Compute (nova): Invalid Bug description: tox.ini contains a number of entries in the 'ignore' list for flake8, allowing developers to kick certain minor infractions down the road, resulting in creeping technical debt. Wherever feasible, these ignore entries should be weeded out and their respective issues resolved in the codebase. To work this bug: 0) Pull the latest code. This will minimize painful rebasing. 1) Edit tox.ini. Remove one or more tokens from the 'ignore' definition under the [flake8] section. 2) Run tox -e pep8 3) Resolve all of the errors 4) Propose up your change, referencing this bug report's ID with the Partial-Bug tag. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1609848/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1609848] [NEW] Un-ignore PEP8 rules in tox
Public bug reported: tox.ini contains a number of entries in the 'ignore' list for flake8, allowing developers to kick certain minor infractions down the road, resulting in creeping technical debt. Wherever feasible, these ignore entries should be weeded out and their respective issues resolved in the codebase. To work this bug: 0) Pull the latest code. This will minimize painful rebasing. 1) Edit tox.ini. Remove one or more tokens from the 'ignore' definition under the [flake8] section. 2) Run tox -e pep8 3) Resolve all of the errors 4) Propose up your change, referencing this bug report's ID with the Partial-Bug tag. ** Affects: nova Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1609848 Title: Un-ignore PEP8 rules in tox Status in OpenStack Compute (nova): New Bug description: tox.ini contains a number of entries in the 'ignore' list for flake8, allowing developers to kick certain minor infractions down the road, resulting in creeping technical debt. Wherever feasible, these ignore entries should be weeded out and their respective issues resolved in the codebase. To work this bug: 0) Pull the latest code. This will minimize painful rebasing. 1) Edit tox.ini. Remove one or more tokens from the 'ignore' definition under the [flake8] section. 2) Run tox -e pep8 3) Resolve all of the errors 4) Propose up your change, referencing this bug report's ID with the Partial-Bug tag. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1609848/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1570748] Re: Bug: resize instance after edit flavor with horizon
** Changed in: nova-powervm Status: Fix Released => Fix Committed ** Changed in: nova-powervm Assignee: (unassigned) => Drew Thorstensen (thorst) ** Changed in: nova-powervm Importance: Undecided => Medium -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1570748 Title: Bug: resize instance after edit flavor with horizon Status in OpenStack Compute (nova): Fix Released Status in OpenStack Compute (nova) kilo series: Fix Committed Status in OpenStack Compute (nova) liberty series: Fix Committed Status in OpenStack Compute (nova) mitaka series: Fix Committed Status in nova-powervm: Fix Committed Status in tempest: Fix Released Bug description: Error occured when resize instance after edit flavor with horizon (and also delete flavor used by instance) Reproduce step : 1. create flavor A 2. boot instance using flavor A 3. edit flavor with horizon (or delete flavor A) -> the result is same to edit or to delelet flavor because edit flavor means delete/recreate flavor) 4. resize or migrate instance 5. Error occured Log : nova-compute.log File "/opt/openstack/src/nova/nova/conductor/manager.py", line 422, in _object_dispatch return getattr(target, method)(*args, **kwargs) File "/opt/openstack/src/nova/nova/objects/base.py", line 163, in wrapper result = fn(cls, context, *args, **kwargs) File "/opt/openstack/src/nova/nova/objects/flavor.py", line 132, in get_by_id db_flavor = db.flavor_get(context, id) File "/opt/openstack/src/nova/nova/db/api.py", line 1479, in flavor_get return IMPL.flavor_get(context, id) File "/opt/openstack/src/nova/nova/db/sqlalchemy/api.py", line 233, in wrapper return f(*args, **kwargs) File "/opt/openstack/src/nova/nova/db/sqlalchemy/api.py", line 4732, in flavor_get raise exception.FlavorNotFound(flavor_id=id) FlavorNotFound: Flavor 7 could not be found. This Error is occured because of below code: /opt/openstack/src/nova/nova/compute/manager.py def resize_instance(self, context, instance, image, reservations, migration, instance_type, clean_shutdown=True): if (not instance_type or not isinstance(instance_type, objects.Flavor)): instance_type = objects.Flavor.get_by_id( context, migration['new_instance_type_id']) I think that deleted flavor should be taken when resize instance. I tested this in stable/kilo, but I think stable/liberty and stable/mitaka has same bug because source code is not changed. thanks. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1570748/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1575335] Re: nova-powervm no longer loading from out of tree
** Also affects: nova Importance: Undecided Status: New ** Summary changed: - nova-powervm no longer loading from out of tree + Out-of-tree compute drivers no longer loading -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1575335 Title: Out-of-tree compute drivers no longer loading Status in OpenStack Compute (nova): New Status in nova-powervm: New Bug description: Commit https://github.com/openstack/nova/commit/8eb03de1eb83a6cd2d4d41804e1b8253f94e5400 removed the mechanism by which nova-powervm was loading its Compute driver from out of tree, resulting in the following failure to start up n-cpu: 2016-04-25 23:53:46.581 32459 INFO nova.virt.driver [-] Loading compute driver 'nova_powervm.virt.powervm.driver.PowerVMDriver' 2016-04-25 23:53:46.582 32459 ERROR nova.virt.driver [-] Unable to load the virtualization driver 2016-04-25 23:53:46.582 32459 ERROR nova.virt.driver Traceback (most recent call last): 2016-04-25 23:53:46.582 32459 ERROR nova.virt.driver File "/opt/stack/nova/nova/virt/driver.py", line 1623, in load_compute_driver 2016-04-25 23:53:46.582 32459 ERROR nova.virt.driver virtapi) 2016-04-25 23:53:46.582 32459 ERROR nova.virt.driver File "/usr/local/lib/python2.7/dist-packages/oslo_utils/importutils.py", line 44, in import_object 2016-04-25 23:53:46.582 32459 ERROR nova.virt.driver return import_class(import_str)(*args, **kwargs) 2016-04-25 23:53:46.582 32459 ERROR nova.virt.driver File "/usr/local/lib/python2.7/dist-packages/oslo_utils/importutils.py", line 30, in import_class 2016-04-25 23:53:46.582 32459 ERROR nova.virt.driver __import__(mod_str) 2016-04-25 23:53:46.582 32459 ERROR nova.virt.driver ImportError: No module named nova_powervm.virt.powervm.driver 2016-04-25 23:53:46.582 32459 ERROR nova.virt.driver n-cpu failed to start To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1575335/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
