| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-06-19 | |||
| 18:52:07 | dansmith | jaypipes: either way, I think they should be register_if(False) even if we have to use their full imports | |
| 18:52:19 | mriedem | you could still do: from nova.objects import resource_providers; allocs = resource_providers.AllocationCandidates.get_by_filters() | |
| 18:52:22 | mriedem | which isn't too bad | |
| 18:52:36 | dansmith | jaypipes: sup to you I guess. it's kinda bad to register and them unregister them, although it's only principle | |
| 18:52:50 | dansmith | jaypipes: happy to make the change myself if you want, but dont'want to stomp on your pending changes | |
| 18:53:02 | jaypipes | mriedem, dansmith: k, gimme a few. I'll do that | |
| 18:53:31 | mriedem | otherwise i'm like +10 if that helps | |
| 19:06:39 | openstackgerrit | OpenStack Proposal Bot proposed openstack/os-vif master: Updated from global requirements https://review.openstack.org/467173 | |
| 19:07:40 | openstackgerrit | Jay Pipes proposed openstack/nova master: placement: produce set of allocation candidates https://review.openstack.org/473377 | |
| 19:07:40 | openstackgerrit | Jay Pipes proposed openstack/nova master: placement: support GET /allocation_candidates https://review.openstack.org/475448 | |
| 19:07:46 | jaypipes | mriedem, dansmith: ok dokey. ^ | |
| 19:12:37 | mriedem | has anyone here ever had a hard time figuring out why their api samples test failed w/o an unexpected response code? | |
| 19:12:44 | mriedem | and spent hours figuring it out? | |
| 19:12:55 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Provide error message in MismatchError for api-samples tests https://review.openstack.org/475489 | |
| 19:12:59 | mriedem | *with i should say | |
| 19:13:07 | mriedem | well wonder no more dear friends ^ | |
| 19:14:10 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Provide error message in MismatchError for api-samples tests https://review.openstack.org/475489 | |
| 19:50:40 | melwitt | mriedem: I hoped someone would figure that out and improve it after cfriesen brought it up last week. *two thumbs up* | |
| 19:51:40 | mriedem | i've got another one coming soon | |
| 19:51:50 | melwitt | yess | |
| 19:51:50 | mriedem | generalize_subs is a thing that took me an hour or so to find | |
| 19:52:18 | mriedem | because i kept getting this http://paste.openstack.org/show/613134/ | |
| 19:52:24 | mriedem | but knew my test and template and subs were all good | |
| 19:53:44 | melwitt | mriedem: that's the useless output I've seen on some transient func test failures in the gate! | |
| 19:54:05 | melwitt | or at least I couldn't tell that anything was wrong from it | |
| 19:54:09 | mriedem | well, i was just going to add a reminder in the error message to check if your test needs to override generalize_subs | |
| 19:54:31 | mriedem | because the api samples functional tests are very much an exercise in what you don't know you need to do to make them work | |
| 19:54:35 | mriedem | so the more hints we can provide the better | |
| 19:55:04 | melwitt | yeah, I think hints of any kind are a vast improvement | |
| 19:55:22 | openstackgerrit | Rick Bartra proposed openstack/nova master: Add policy granularity to the Flavors API https://review.openstack.org/449288 | |
| 20:00:52 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Provide a hint when _verify_response fails https://review.openstack.org/475512 | |
| 20:09:27 | melwitt | mriedem: do you happen to know if novaclient or OSC are capable of doing any automatic paging when e.g. number of servers > 1000 for a server list? | |
| 20:10:55 | mriedem | i think novaclient might, not sure about osc | |
| 20:11:14 | melwitt | thanks. I feel like I heard of something like that but memory is hazy | |
| 20:11:42 | mriedem | https://github.com/openstack/python-novaclient/blob/master/novaclient/v2/shell.py#L1424 | |
| 20:11:46 | mriedem | limit of -1 | |
| 20:11:49 | mriedem | makes novaclient page | |
| 20:11:59 | mriedem | i remember diana hitting this with the simple tenant usage paging stuff | |
| 20:12:31 | melwitt | okay, it's still going to just return the api max limit though, won't go ahead and query with the marker for the next hunk etc | |
| 20:12:45 | melwitt | or wait, -1 all servers | |
| 20:13:20 | melwitt | okay, yeah cool | |
| 20:13:41 | mriedem | https://cdn.meme.am/cache/instances/folder766/24025766.jpg | |
| 20:13:53 | melwitt | lol awesome | |
| 20:14:54 | openstackgerrit | Merged openstack/nova master: Use plain routes list for os-quota-classes endpoint instead of stevedore https://review.openstack.org/461641 | |
| 20:15:31 | openstackgerrit | Merged openstack/nova master: Use plain routes list for os-cloudpipe endpoint instead of stevedore https://review.openstack.org/474116 | |
| 20:15:59 | openstackgerrit | Merged openstack/nova master: Use plain routes list for os-tenant-networks instead of stevedore https://review.openstack.org/474475 | |
| 20:22:03 | openstackgerrit | Merged openstack/nova master: Remove multiple create from stevedore https://review.openstack.org/474909 | |
| 20:22:07 | melwitt | I wonder why github doesn't show what tag/release a commit is in if it's a backport to stable | |
| 20:41:12 | openstackgerrit | Matt Riedemann proposed openstack/nova master: WIP: Handle uuids in os-hypervisors API https://review.openstack.org/471899 | |
| 20:48:52 | sdague | mriedem: it looks like if you want to land the mitaka backports you'll need to make the tempest tests non voting | |
| 20:49:29 | sdague | mriedem: keystone drifted in some way and there isn't a great way to exclude those tests | |
| 20:57:53 | mriedem | ok, i'm not sure i care all that much | |
| 20:58:38 | mriedem | dansmith: shouldn't we generally be locking when refreshing the nw info cache? like in https://github.com/openstack/nova/blob/ac41395f11002c09e7cd1c4a26632e73bc1bc952/nova/network/base_api.py#L74 | |
| 20:58:50 | mriedem | i see that when handling external vif deleted events, we don't lock https://github.com/openstack/nova/blob/ac41395f11002c09e7cd1c4a26632e73bc1bc952/nova/compute/manager.py#L6816 | |
| 20:59:15 | dansmith | mriedem: well, it will only lock against things running on the same machine of course, | |
| 20:59:25 | dansmith | mriedem: and we're probably already under the instance lock in compute manager right? | |
| 20:59:42 | mriedem | no | |
| 20:59:43 | mriedem | _process_instance_vif_deleted_event | |
| 20:59:48 | mriedem | https://github.com/openstack/nova/blob/ac41395f11002c09e7cd1c4a26632e73bc1bc952/nova/compute/manager.py#L6834 | |
| 20:59:48 | dansmith | mriedem: the general thinking there is that two threads racing are likely to write the same thing to the db, so it doesn't much matter | |
| 21:00:01 | dansmith | oh, in the event handler, right | |
| 21:00:36 | dansmith | but anyway, if we did, we wouldn't be excluded against another compute doing it too during a migration, or a n-net node, or a conductor (if that happens), etc | |
| 21:01:05 | mriedem | sure, global DLM aside | |
| 21:01:34 | mriedem | i was just commenting on someone's patch that was fiddling with things in there outside the lock | |
| 21:01:37 | mriedem | and got looking around | |
| 21:01:49 | mriedem | there == instance nw info cache | |
| 21:02:01 | dansmith | the lock also isn't going to prevent us from hitting neutron more than once or anything | |
| 21:02:05 | dansmith | it's just going to serialize those operations | |
| 21:03:00 | mriedem | yeah i know | |
| 21:03:06 | mriedem | just not sure if i care about https://review.openstack.org/#/c/419975/14/nova/virt/ironic/driver.py | |
| 21:04:20 | dansmith | yeah I don't think that's going to do anything | |
| 21:04:47 | dansmith | it does seem weird to be updating the cache from inside a driver like that though | |
| 21:08:49 | openstackgerrit | OpenStack Proposal Bot proposed openstack/nova master: Updated from global requirements https://review.openstack.org/475563 | |
| 21:14:09 | dansmith | mriedem: jaypipes apparently none of the placement fixtures have tests? | |
| 21:14:39 | jaypipes | dansmith: not sure what you mean? | |
| 21:15:03 | dansmith | jaypipes: we have unit tests for the normal nova fixtures | |
| 21:15:09 | dansmith | jaypipes: i.e. tests/unit/test_fixtures | |
| 21:15:17 | dansmith | I was going to -1 you for your new untested fixture, | |
| 21:15:25 | dansmith | but it seems that none of the placement fixtures are tested... | |
| 21:15:39 | jaypipes | dansmith: you mean besides the functional API tests that use them? | |
| 21:16:19 | dansmith | jaypipes: yeah, we don't just assume the nova fixtures work because other tests use them... | |
| 21:16:41 | jaypipes | dansmith: ok :) | |
| 21:18:05 | dansmith | jaypipes: I'll defer to mriedem, assuming we're not going to hold you to that here since there aren't tests for the others | |
| 21:18:14 | dansmith | I was just surprised | |
| 21:19:07 | dansmith | jaypipes: I do think we want tests for that normalize helper you pulled out though | |
| 21:19:21 | jaypipes | dansmith: yup, no prob. I can handle that. :) | |
| 21:20:05 | dansmith | jaypipes: I also don't see tests that make sure this doesn't work before microversion 1.8, but I'm not sure if that's convention or not | |
| 21:20:10 | dansmith | I would expect we would just check that we get a 404 | |
| 21:48:04 | mriedem | the more i look at this, the more it hurts https://github.com/openstack/nova/blob/master/nova/network/neutronv2/api.py#L887-L894 | |
| 21:48:24 | mriedem | the note is obviously wrong now, it was added before we tracked neutron preexisting ports https://review.openstack.org/#/c/22610/2/nova/network/quantumv2/api.py | |
| 21:49:10 | mriedem | at this point, isn't what we return going to be all ports for the instance? since created and preexisting is the full set of ports for a given instance, either during server create or interface attach | |
| 21:50:20 | dansmith | heh, yeah because "created_port_ids + preexisting_port_ids" | |
| 21:50:34 | mriedem | or | |
| 21:50:42 | mriedem | https://github.com/openstack/nova/blob/master/nova/network/neutronv2/api.py#L982 | |
| 21:51:01 | mriedem | preexisting_port_ids might not be "all" preexisting ports for the instance, it might be only the ones in the attach request that aren't new | |
| 21:51:21 | mriedem | so if i create my instance with port A, and then attach B, preexisting_port_ids will have B in it but not A, i think | |
| 21:51:23 | dansmith | all that stuff is crap | |
| 21:51:45 | mriedem | i.e. preexisting_ports_for_the_current_request | |
| 21:54:06 | openstackgerrit | melanie witt proposed openstack/nova master: Add FixedIPList.get_count_by_project() https://review.openstack.org/446246 | |
| 21:54:07 | openstackgerrit | melanie witt proposed openstack/nova master: Add FloatingIPList.get_count_by_project() https://review.openstack.org/446247 | |