| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-03-05 | |||
| 17:47:58 | dansmith | cfriesen: I think yes | |
| 17:48:07 | bauzas | cfriesen: yes please | |
| 17:48:13 | cfriesen | it's confusing, there's something related to cell types in here | |
| 17:48:41 | melwitt | cfriesen: I think yes too | |
| 17:49:03 | bauzas | cfriesen: the problem is that we put too many things in extra sepcs | |
| 17:49:15 | sean-k-mooney | is there any reason we dont allow you to set extraspec when creating a flavor so we can make the whole thing readonly | |
| 17:49:19 | bauzas | we should at least validate those specs before calling the scheduler | |
| 17:49:56 | cfriesen | I'm looking at https://github.com/openstack/nova/blob/master/nova/compute/api.py#L3541 which seems to indicate that you're not supposed to resize to the same flavor, but there's an exception for a "compute" cell type | |
| 17:49:57 | sean-k-mooney | i guess maybe because resize is a cold migration? | |
| 17:50:16 | openstackgerrit | Merged openstack/nova master: Stub out port binding create/delete in NeutronFixture https://review.openstack.org/636413 | |
| 17:50:42 | mdbooth | lyarwood: Would you also be able to pontificate upon https://review.openstack.org/#/c/613039/ ? | |
| 17:51:12 | openstackgerrit | Merged openstack/python-novaclient master: Microversion 2.71 - show server group https://review.openstack.org/640657 | |
| 17:51:16 | mdbooth | lyarwood: FWIW I'll be +1 on that assuming the tests are good, but I don't have time to look now. | |
| 17:52:06 | cfriesen | sean-k-mooney: yeah, but the comments say that for migration "flavor_id" is None. | |
| 17:53:32 | sean-k-mooney | cfriesen: right well resize and colde migrate are the same thing in nova except resize change the flavor and migrate does not | |
| 17:53:59 | stephenfin | gibi: Sorry for the delay. +2'd now :) | |
| 17:54:24 | cfriesen | sean-k-mooney: yeah, but there's some cells complication apparently: https://bugs.launchpad.net/nova/+bug/1243816 | |
| 17:54:26 | openstack | Launchpad bug 1243816 in OpenStack Compute (nova) "migrate fails with cells" [Undecided,Fix released] - Assigned to Chris Behrens (cbehrens) | |
| 17:54:30 | sean-k-mooney | cfriesen: so resize to the same flavor whould be expected to do the same thing as migrate however migrate uses the embeded fravor | |
| 17:55:42 | sean-k-mooney | yes well for cells v1 the flavor may not have been the same or replicated across cell. cross cell resize for cellsv2 is something mriedem is working on currently | |
| 18:00:45 | cfriesen | Looks like normally you cannot resize to the same flavor, so my concern is unfounded. | |
| 18:01:20 | openstackgerrit | Stephen Finucane proposed openstack/nova master: docs: Fix nits in remote console guide https://review.openstack.org/641098 | |
| 18:01:20 | openstackgerrit | Stephen Finucane proposed openstack/nova master: docs: Rework all things metadata'y https://review.openstack.org/640730 | |
| 18:02:06 | stephenfin | efried: You'd probably be interested in those come Friday ^ | |
| 18:03:56 | efried | ack | |
| 18:04:08 | efried | Friday because... after freeze? | |
| 18:05:26 | openstackgerrit | Chris Friesen proposed openstack/nova master: Flavor extra spec and image properties validation from API https://review.openstack.org/620706 | |
| 18:22:04 | openstackgerrit | Chris Friesen proposed openstack/nova master: Improve libvirt image and snapshot handling https://review.openstack.org/616692 | |
| 18:22:35 | cfriesen | any chance of getting some core eyes on this? ^ It's a host filesystem cache optimization patch, has a +1 from mdbooth. (And if you say it's simply not going into S then I'll shut up about it till next week.) | |
| 18:27:55 | openstackgerrit | Merged openstack/nova master: libvirt: implement reshaper for vgpu https://review.openstack.org/599208 | |
| 18:28:03 | openstackgerrit | Merged openstack/nova master: Add functional test for libvirt vgpu reshape https://review.openstack.org/631559 | |
| 18:28:11 | openstackgerrit | Merged openstack/nova master: FUP: docs nit https://review.openstack.org/639647 | |
| 18:28:56 | dansmith | cfriesen: you mean host buffer cache optimization yeah/ | |
| 18:29:25 | dansmith | that looks like a nice win and might be why my toy all-in-one openstack at home completely destroys performance while taking snapshots | |
| 18:41:56 | melwitt | dansmith: if something tries to reference unset user_id field, "NotImplementedError: Cannot load 'user_id' in the base class" happens. do you think we need to log a message in addition to that? | |
| 18:43:23 | dansmith | melwitt: I dunno, that ends up in a lot of places where we have an implementation error, so it's nice to log something about why (i.e. mappings haven't been migrated) but it's also a failing on our part, since it shouldn't be used anywhere anyway | |
| 18:43:46 | dansmith | melwitt: so you decide I guess.. but exploding is the right thing regardless of the, uh, type of explosion It hink | |
| 18:44:56 | melwitt | dansmith: ok, yeah, that makes sense. just log and reraise | |
| 18:54:08 | mriedem | mdbooth: btw, i hope you've seen office space: https://photos.app.goo.gl/HgzGk3aR2yGHWMv69 | |
| 19:04:06 | melwitt | lol | |
| 19:06:02 | openstackgerrit | sean mooney proposed openstack/nova master: libvirt: delegate ovs plug to os-vif https://review.openstack.org/602432 | |
| 19:06:54 | melwitt | cfriesen: from the commit message, "so that cache option can be set properly". that makes it sound like it's a bug without that change. is it a bug or no? | |
| 19:06:58 | mriedem | cfriesen: approved your validation change and i'm assuming you're still working on a patch to check get_pci_requests_from_flavor from resize? | |
| 19:08:28 | dansmith | ah dangit, I was just going through that | |
| 19:08:42 | dansmith | melwitt: it's a feature | |
| 19:09:01 | melwitt | oh k | |
| 19:09:09 | dansmith | melwitt: it's not a bug because it's not wrong, but setting the cache properly avoids trashing the host's page cache while doing it, improving performance for everything running while the snapshot is happening | |
| 19:09:21 | melwitt | ah, thanks | |
| 19:09:32 | cfriesen | melwitt: what he said. :) | |
| 19:09:42 | dansmith | aside from the consistency gain of not calling the same external binary manually in multiple places | |
| 19:10:04 | cfriesen | mriedem: yes, just working on tests | |
| 19:10:11 | melwitt | ok, kewl | |
| 19:14:05 | efried | whoops, guess I should have been paying attention here before I +A'd that sucker. | |
| 19:16:31 | melwitt | it's np | |
| 19:16:50 | efried | okay, can pull it if necessary. | |
| 19:17:26 | melwitt | nah, it's ok. looking at it further, it would take me longer to understand all the qemu-img stuff anyway | |
| 19:28:51 | artom | sean-k-mooney, around? I need your Neutron and/or os-vif expertise | |
| 19:32:00 | mriedem | efried: edmondsw: i'm assuming this is ok for powervm since the parameter is just ignored https://review.openstack.org/#/c/613039/4/nova/virt/powervm/driver.py | |
| 19:32:08 | mriedem | maybe could help optimize something with powervm volume extend though | |
| 19:32:34 | efried | mriedem: powervm oot will need to do the same, so thanks for alerting edmondsw | |
| 19:33:10 | efried | generally I like to see a ML post when we change things like the ComputeDriver interface, since OOT drivers will need to conform. | |
| 19:34:07 | mriedem | ooo as will hyperv http://git.openstack.org/cgit/openstack/compute-hyperv/tree/compute_hyperv/nova/driver.py#n224 | |
| 19:34:20 | efried | mriedem: but yeah, the change itself should be harmless. | |
| 19:37:40 | efried | And I don't see how powervm could take advantage of it to help anything. | |
| 19:39:37 | mriedem | yeah me neither | |
| 19:41:13 | artom | Is the "plug" verb overloaded in Neutron and os-vif? | |
| 19:42:18 | artom | Looking at https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L5653-L5656, I could be forgiven for thinking that our call to plug_vifs() is what causes the network-vif-plugged event to eventually reach | |
| 19:42:27 | artom | But that's incorrect... right? | |
| 19:42:47 | artom | Way earlier we call Neutron via setup_networks_on_host(), and *that's* how we get the event | |
| 19:43:14 | artom | Because Neutron plugs the port | |
| 19:43:58 | artom | ... is that the distinction? Neutron plugs *ports* on the host (ie, sets up host networking) | |
| 19:44:18 | artom | And then Nova plugs the *VIF* to whatever interface Neutron has made for us... | |
| 19:45:11 | artom | ... except the event we get from Neutron is vif-plugged, not port-plugged | |
| 19:46:16 | mriedem | i don't think that's accurate | |
| 19:46:36 | mriedem | because we may or may not get a network-vif-plugged event during hard reboot where the port binding host doesn't change | |
| 19:46:46 | mriedem | but only certain networking backends in neutron will send the event in that case | |
| 19:46:59 | mriedem | it led to a whole messy situation with dealing with that and reboots for things like opendaylight | |
| 19:47:46 | dansmith | artom: neutron sends us vif-plugged when it sees an appropriately-named interface show up on the system, | |
| 19:47:48 | mriedem | lemme dig up a ghost for you | |
| 19:48:00 | dansmith | which is usually because we have created it as part of starting a vm | |
| 19:48:11 | mriedem | artom: have fun with this https://review.openstack.org/#/c/553035/ | |
| 19:48:26 | dansmith | artom: there's also some plug terminology around hooking that interface up to a bridge | |
| 19:48:40 | dansmith | and some around the work nova does to create an interface in the first place like during spawn | |
| 19:48:42 | artom | dansmith, ok, that answers my "ulterior motive" questions, which was - can we wait for vif-plugged in the compute manager. The answer being: no. Because the VM needs to start. | |
| 19:48:50 | aspiers | mriedem: Yes that's correct, there are more changes by my colleague breton which build on https://review.openstack.org/#/c/638680/ and modify the guest config to activate SEV functionality. Actually they aren't far from code complete but I think still need a bit of polish here and there. 2 or 3 are already in Gerrit and there are maybe 2 or 3 to come after that. | |
| 19:49:07 | dansmith | artom: in the spawn case, that's correct | |
| 19:49:45 | dansmith | artom: which is why we start the instance paused, wait for the interface to show up, neutron to notice, notify us, and then we unpause the guest | |
| 19:49:48 | dansmith | artom: before, we would start the instance right away, and it might time out waiting for dhcp before all that happened | |
| 19:49:53 | openstackgerrit | melanie witt proposed openstack/nova master: Populate InstanceMapping.user_id during migrations and schedules https://review.openstack.org/638574 | |
| 19:49:53 | openstackgerrit | melanie witt proposed openstack/nova master: Add user_id field to InstanceMapping https://review.openstack.org/633350 | |
| 19:49:54 | openstackgerrit | melanie witt proposed openstack/nova master: Add get_counts() to InstanceMappingList https://review.openstack.org/638072 | |
| 19:49:54 | openstackgerrit | melanie witt proposed openstack/nova master: Add online data migration for populating user_id https://review.openstack.org/633351 | |
| 19:49:55 | openstackgerrit | melanie witt proposed openstack/nova master: Use instance mappings to count server group members https://review.openstack.org/638324 | |
| 19:49:55 | openstackgerrit | melanie witt proposed openstack/nova master: Count instances from mappings and cores/ram from placement https://review.openstack.org/638073 | |
| 19:49:57 | dansmith | which was the initial point of these events | |
| 19:50:32 | artom | dansmith, hrmm, so I've understood the problem wrong then | |
| 19:50:50 | aspiers | mriedem: We've been mostly pushing them in a linear sequence, but there has been a bit of parallelism on the base work not specific to SEV, to avoid superfluous dependencies slowing things down. | |
| 19:50:56 | artom | It's not just that we're not listening for the event when it arrives | |
| 19:51:26 | aspiers | mriedem: I'm more than happy to draw a dependency graph summarising all patches if that helps? | |
| 19:51:46 | dansmith | artom: the initial problem was that some not-insignificant amount of time, we would start the instance (which created the vif) and the instance would be stillborn without networking, because it got to the OS part of the boot that waits for DHCP before neutron noticed, wired us up, setup dhcp for us etc | |