| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-02-01 | |||
| 18:11:16 | hrw | jaypipes: helped me learning project code a lot ;D | |
| 18:11:39 | hrw | jaypipes: that nova patch is first time I used tests in openstack | |
| 18:11:55 | hrw | in my previous nova patches Kevin_Zheng wrote tests | |
| 18:12:09 | jaypipes | ah | |
| 18:12:35 | jaypipes | hrw: just be glad you didn't need to touch the functional API tests... | |
| 18:13:39 | hrw | jaypipes: not my area of expertize | |
| 18:24:39 | hrw | see you Monday (or FOSDEM) | |
| 19:28:43 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Migrate "launch instance" user guide docs https://review.openstack.org/540048 | |
| 19:37:10 | smcginnis | mriedem: Can you confirm: https://review.openstack.org/#/c/540105/1/upper-constraints.txt | |
| 19:37:14 | smcginnis | Line 185 | |
| 19:38:01 | mriedem | smcginnis: yeah we don't, and i thought we actually couldn't do that w/o fixing horizon? | |
| 19:38:15 | mriedem | https://review.openstack.org/#/c/538472/ | |
| 19:38:22 | mriedem | i think the horizon tests will fail if you don't have that | |
| 19:38:48 | smcginnis | mriedem: I don't have all the details, just wanted to make sure there wasn't at least a major bump. | |
| 19:38:57 | smcginnis | mriedem: Makes sense, thanks for checking on it. | |
| 19:39:08 | mriedem | np | |
| 19:42:33 | mriedem | mmedvede: some ppc64 assertions being made in https://review.openstack.org/#/c/538003/ | |
| 19:44:14 | mmedvede | mriedem: thanks, taking a look | |
| 19:47:37 | openstackgerrit | Eric Fried proposed openstack/nova-specs master: Update Provider Tree https://review.openstack.org/540111 | |
| 19:47:58 | efried | jaypipes, mriedem: ^ | |
| 19:48:24 | efried | This is a Rocky spec for the work that's basically already been done. Figured we should have something written down. | |
| 19:49:59 | cdent | efried: good idea | |
| 19:50:52 | hrw | mriedem: thanks for review. will take care next week | |
| 19:52:24 | efried | jaypipes: I should really put your name on it somewhere, since the actual design was mostly your brainchild. | |
| 19:55:31 | openstackgerrit | Chris Dent proposed openstack/nova master: Optional separate database for placement API https://review.openstack.org/362766 | |
| 19:57:50 | jaypipes | efried: lol, I don't care about that :) as long as we make forward progress, I'm happy. | |
| 19:58:20 | efried | jaypipes: People in the know, know. | |
| 19:59:33 | efried | ya know? | |
| 20:00:15 | jaypipes | heh | |
| 20:14:34 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Cleanup launch instance and manage IPs docs https://review.openstack.org/540121 | |
| 20:17:05 | mriedem | this needs another +2 https://review.openstack.org/#/c/531517/ | |
| 20:29:49 | dansmith | yes, yes it does | |
| 20:44:13 | openstackgerrit | Eric Fried proposed openstack/nova-specs master: Update Provider Tree https://review.openstack.org/540111 | |
| 20:47:04 | melwitt | mriedem: do you know what causes neutron to send events? is it reacting to os-vif calls or? | |
| 20:47:24 | melwitt | I updated the bug with my latest findings on the timeout waiting for network-vif-plugged | |
| 20:47:32 | dansmith | melwitt: it's when neutron does things | |
| 20:47:36 | mriedem | melwitt: the neutron agent sends info to the server via rpc | |
| 20:47:45 | mriedem | the neutron agent is polling for changes, as far as i understand | |
| 20:48:00 | melwitt | okay, that makes sense. I'm looking in the agent logs trying to piece things together | |
| 20:48:01 | mriedem | the server then gets the rpc message from the agent(s) and turns those into rest api calls (server external events) to nova | |
| 20:48:31 | dansmith | mriedem: I dunno that it's polly, | |
| 20:48:34 | dansmith | er, polling | |
| 20:48:37 | melwitt | because what's happening is, when we start the reboot, while we're tearing down the libvirt domain, BEFORE we unplug the vif, we are getting a network-vif-plugged event from neutron | |
| 20:48:51 | melwitt | and it's not from the initial boot because we have one from that too, earlier in the log | |
| 20:48:54 | dansmith | I think it's like when you ask it to do a vif plug, it does it, and then sends an RPC to neutron server to send it out | |
| 20:49:30 | melwitt | and I'm wondering, why is it sending us network-vif-plugged if we haven't even tried to plug anything yet | |
| 20:49:31 | dansmith | melwitt: network-changed comes a lot, are you sure it was vif-pluged? | |
| 20:49:36 | melwitt | I'm sure | |
| 20:49:54 | melwitt | we do get network-changed FIRST though, right before we initiate the reboot in compute | |
| 20:50:02 | melwitt | then we get network-vif-plugged | |
| 20:50:06 | dansmith | well, it might be that they do it any time they refresh a vif into a bridge and thus send it sometimes when we're not asking for it | |
| 20:50:07 | melwitt | which makes no sense | |
| 20:50:27 | dansmith | like not always just in response to our asking for it | |
| 20:50:45 | melwitt | vif-plugged you mean? | |
| 20:51:22 | melwitt | yeah, I figured there might be some reasons it sends it randomly. but, it's also not sending us one after we plug the vif after the reboot | |
| 20:52:06 | melwitt | I was thinking the next step is to learn how it decides to send them and find what's missing there | |
| 20:52:25 | dansmith | did we unplug first? | |
| 20:52:40 | melwitt | yes. we unplugged but did not wait for an unplug event | |
| 20:52:46 | melwitt | which I wonder if that's a problem | |
| 20:53:56 | dansmith | well, no, not waiting for the event shouldn't make it not send the corresponding plug | |
| 20:54:03 | dansmith | because unless it's for an instance that doesn't exist, the api doesn't tell the person sending the event that we weren't waiting for it | |
| 20:54:29 | melwitt | yeah. agreed, just that's the only thing I could think of as a potential reason why | |
| 20:54:51 | melwitt | you know what though, looking at this again | |
| 20:55:02 | melwitt | the vif shows up as active=False for both the unplug and the plug | |
| 20:55:43 | melwitt | I wonder if that's a problem | |
| 20:56:03 | melwitt | well, actually it's *supposed* to be active=False before we plug | |
| 20:56:09 | melwitt | based on our event waiting logic | |
| 20:56:27 | melwitt | *our plug event waiting logic | |
| 20:56:45 | melwitt | we only register to wait for vifs that have active=False. so that checks out | |
| 20:58:17 | melwitt | active=True when the reboot begain, then it changed to active=False somewhere between the libvirt destroy and the unplug | |
| 20:58:27 | melwitt | *began | |
| 21:00:01 | mriedem | nova meeting time | |
| 21:00:09 | melwitt | ah thanks | |
| 21:05:51 | openstackgerrit | Merged openstack/nova master: SchedulerReportClient._delete_provider https://review.openstack.org/535463 | |
| 21:18:52 | openstackgerrit | Merged openstack/nova master: ProviderTree.get_provider_uuids: Top-down ordering https://review.openstack.org/536624 | |
| 21:19:02 | openstackgerrit | Merged openstack/nova master: set_{aggregates|traits}_for_provider: tolerate set https://review.openstack.org/536625 | |
| 21:22:16 | mriedem | efried: there all your things are merged | |
| 21:25:48 | openstackgerrit | Merged openstack/nova master: Fix nits in support traits changes https://review.openstack.org/537351 | |
| 21:25:58 | openstackgerrit | Merged openstack/nova master: Mention required traits in the flavors user docs https://review.openstack.org/539300 | |
| 21:26:02 | mriedem | sdague: if you're around, this is a simple docs migration that we missed in pike https://review.openstack.org/#/c/540048/ - content is unchanged except for fixing links; the patch on top cleans up some of the content to modernize it | |
| 21:26:13 | openstackgerrit | Merged openstack/nova master: add "--until-complete" option for nova-manage db archive_deleted_rows. https://review.openstack.org/539654 | |
| 21:26:16 | edleafe | efried: I told you to bribe the people in infra! | |
| 21:26:25 | openstackgerrit | Merged openstack/nova master: Use util.validate_query_params in list_traits https://review.openstack.org/539407 | |
| 21:26:38 | openstackgerrit | Merged openstack/nova master: Deduplicate aggregate notification samples https://review.openstack.org/531162 | |
| 21:26:51 | openstackgerrit | Merged openstack/nova master: Deduplicate service status notification samples https://review.openstack.org/534335 | |
| 21:27:17 | openstackgerrit | Merged openstack/nova master: Log options at debug when starting API services under wsgi https://review.openstack.org/519462 | |
| 21:28:13 | openstackgerrit | Matt Riedemann proposed openstack/nova stable/ocata: Regenerate context during targeting https://review.openstack.org/540145 | |
| 21:31:44 | traskat | hey, i have a question about nova and ceph. how can cinder volume gets resized to the flavor disk size if the VM image gets cloned by cinder? | |
| 21:31:51 | sdague | mriedem: done | |
| 21:34:30 | mriedem | sdague: cool thanks | |
| 21:34:43 | mriedem | wow this is a super latent bug, and goes to show no one uses the IsolatedHostsFilter https://bugs.launchpad.net/nova/+bug/1746483 | |
| 21:34:44 | openstackgerrit | Sylvain Bauza proposed openstack/nova master: Provide support matrix and doc for VGPU https://review.openstack.org/539266 | |
| 21:34:44 | openstack | Launchpad bug 1746483 in OpenStack Compute (nova) "Not able to boot from Volume / Volume snapshot when using isolated_images" [Medium,Triaged] | |
| 21:35:12 | mriedem | the IsolatedHostsFilter assumes the request spec has a valid image id in it, which isn't the case for boot from volume when you don't provide an image id | |
| 21:38:18 | openstackgerrit | Merged openstack/nova master: De-duplicate _numa_get_flavor_XXX_map_list https://review.openstack.org/385074 | |
| 21:38:35 | openstackgerrit | Merged openstack/nova stable/pike: Add 'delete_host' command in 'nova-manage cell_v2' https://review.openstack.org/513717 | |
| 21:54:45 | tssurya | mriedem: regarding the scatter_cells bug thanks for backporting it to pike, we have upgraded to ocata today, so far so good (will keep you posted if we find anything major/interesting) | |
| 21:57:11 | mriedem | tssurya: which one? | |
| 21:57:12 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Ensure the JSON-Schema covers the legacy v2 API https://review.openstack.org/540154 | |
| 21:57:51 | tssurya | mriedem : https://bugs.launchpad.net/nova/+bug/1746509 | |