| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-03-15 | |||
| 20:51:15 | tssurya | regarding removal of "service" records, when I guess it makes sense to do when force deleting the cell and host | |
| 20:51:26 | tssurya | mriedem, dansmith : ^^ | |
| 20:51:30 | openstackgerrit | Lance Bragstad proposed openstack/nova master: Add scope_types to server policies https://review.openstack.org/525772 | |
| 20:52:02 | mriedem | this gets quite messy | |
| 20:52:15 | mriedem | because deleting a compute service in the api today also removes the compute host from any aggregates it's in | |
| 20:52:16 | tssurya | yes it will get messy, | |
| 20:53:09 | cfriesen | if you're deleting a cell or a host, doesn't it make sense to delete everything logically associated with that cell/host? | |
| 20:53:30 | mriedem | sure, but, | |
| 20:53:32 | mriedem | where does it end | |
| 20:54:13 | tssurya | I think it does make sense to do it, but to put it all in nova-manage... it gets dirtier and more complex | |
| 20:54:54 | mriedem | if only we had, oh idk, a rest api for managing cells.... | |
| 20:55:11 | tssurya | mriedem: :) | |
| 20:55:44 | dansmith | oh yeah, that'd make it so much better | |
| 20:56:21 | mriedem | it would solve all problems | |
| 20:56:34 | mriedem | cells api could be the new secretary of state | |
| 20:56:41 | mriedem | RIP REX | |
| 20:57:07 | melwitt | nova meeting in 3 minutes | |
| 21:00:06 | dansmith | tssurya: fwiw, my preference is that we not put as much stuff in cmd.manage as we have now, but break things out into modules like all the rest of our code, and make cmd.manage just the cli interface to those things | |
| 21:00:22 | dansmith | cmd.manage grew up over time, getting larger and larger, with people caring less about it because "meh, it's just nova-manage" | |
| 21:00:48 | tssurya | I totally agree that it is getting messier | |
| 21:01:34 | tssurya | (mostly because of me in the recent months) | |
| 21:01:44 | mriedem | let's blame belmiro | |
| 21:01:54 | tssurya | hehe yea! | |
| 21:06:07 | openstackgerrit | Lance Bragstad proposed openstack/nova master: Set scope_types for admin_action policies https://review.openstack.org/553612 | |
| 21:16:36 | openstackgerrit | Lance Bragstad proposed openstack/nova master: Set scope_types for admin password policies https://review.openstack.org/553613 | |
| 21:33:52 | openstackgerrit | Claudiu Belu proposed openstack/nova master: db: Adds live-resize to Migration model migration_type https://review.openstack.org/185961 | |
| 21:59:32 | mriedem | Kevin_Zheng_: you reported the bug related to this https://blueprints.launchpad.net/nova/+spec/add-server-group-remove-member-notifications but for telemetry and searchlight - given the states of those projects, do they actually care about solving this now? | |
| 21:59:40 | mriedem | https://bugs.launchpad.net/nova/+bug/1639152 | |
| 21:59:42 | openstack | Launchpad bug 1639152 in OpenStack Compute (nova) "Send out notification about server group changes when delete instances" [Wishlist,Confirmed] - Assigned to Takashi NATSUME (natsume-takashi) | |
| 22:00:11 | dansmith | mriedem: it requires conf | |
| 22:00:15 | dansmith | so I would kinda expect not | |
| 22:00:36 | dansmith | we will backport it because it's important enough, but I don't know that it fits the usual backport candidate mold | |
| 22:00:39 | mriedem | we can backport bug fixes sometimes as long as the config doesn't change any default behavior | |
| 22:00:51 | dansmith | it should be safe from that regard | |
| 22:01:04 | mriedem | by "we will backport" you mean the royal we? | |
| 22:01:04 | dansmith | it's really a feature used to fix a bug, IMHO, | |
| 22:01:11 | dansmith | so a bp isn't wrong I don't think | |
| 22:01:13 | dansmith | mriedem: we as in redhat | |
| 22:01:20 | mriedem | that's what i meant :) | |
| 22:02:02 | mriedem | alright i guess people that want it in stable can always patch out of tree if we're not going to backport upstream | |
| 22:02:15 | dansmith | I'm not saying we can't or shouldn't | |
| 22:02:16 | mriedem | i heard windriver has already had this for a year | |
| 22:02:23 | dansmith | I would have expected you to say no | |
| 22:02:39 | dansmith | if you think it's legit, then I think it's reasonable | |
| 22:02:42 | mriedem | having a blueprint tag on it makes it more awkward to backport | |
| 22:02:48 | dansmith | well, | |
| 22:02:50 | mriedem | i don't have the context on the thing, | |
| 22:02:51 | dansmith | it's not a bug in nova | |
| 22:02:56 | mriedem | just saw 'meltdown' | |
| 22:03:05 | dansmith | it's a bug in .. I dunno.. the whole arrangement of things | |
| 22:03:17 | mriedem | in computers? | |
| 22:03:22 | mriedem | just say computers | |
| 22:03:31 | dansmith | nova doesn't let you specify a thing that only the operator can know, and is needed to mitigate performance loss after applying the meltdown fixes | |
| 22:03:35 | dansmith | it's completely a nova feature, | |
| 22:03:55 | dansmith | but operators will need it to fix a bug or regressed behavior in lots of other things (kernel, qemu, etc) | |
| 22:04:16 | mriedem | hmm, this reminds me, | |
| 22:04:47 | mriedem | stable/ocata and stable/pike started crapping recently (right before the ptg) because of qemu / libvirt package updates for CVEs related to meltdown and spectre in the UCA | |
| 22:04:49 | dansmith | so I guess I'd leave it as a bp and just call it out in the backport as why we're making an exception | |
| 22:04:58 | mriedem | mnaser: ^ | |
| 22:05:01 | mriedem | you might be interested in that | |
| 22:05:16 | mriedem | https://review.openstack.org/#/c/534384/ | |
| 22:06:14 | mriedem | mnaser had to patch devstack on ocata and pike specifically to wait longer for nova-compute to start up b/c libvirt startup was going from like 10 seconds to a minute | |
| 22:06:18 | mriedem | dansmith: ^ sound like the same issue? | |
| 22:06:36 | dansmith | libvirt startup .. meaning a guest? | |
| 22:06:46 | mriedem | no, libvirtd | |
| 22:06:52 | mriedem | or the connection to libvirt | |
| 22:07:00 | dansmith | mm, I dunno, that's a question for kashyap I think | |
| 22:07:08 | dansmith | maybe if the fixes have been applied on the host, | |
| 22:07:16 | mriedem | https://review.openstack.org/#/c/547676/ | |
| 22:07:16 | dansmith | but pcid isn't passed it makes our guests just super slow for some things | |
| 22:07:18 | dansmith | so it could be | |
| 22:07:29 | mriedem | https://launchpad.net/~ubuntu-cloud-archive/+archive/ubuntu/ocata-staging/+sourcepub/8774271/+listing-archive-extra | |
| 22:07:40 | mriedem | the libvirt cve is i nthere | |
| 22:07:51 | dansmith | I mean, that's what the assertion is about the problem we're trying to solve | |
| 22:07:56 | dansmith | that _some_ things are like 30+% slower after the fixes | |
| 22:08:36 | mnaser | so the reason why it affected ocata and pike was because first of all devstack didnt use pike uca in pike, it used ocata uca | |
| 22:08:48 | mnaser | and the older release of uca didn't have this feature where it could ask qemu what cpu features it supported | |
| 22:09:06 | mnaser | so on libvirt start up with older libvirt instances, it would boot up a very small tiny qemu instance to probe it for things like cpu features etc | |
| 22:09:14 | dansmith | dear god | |
| 22:09:15 | mnaser | which would make the start up super sloooow | |
| 22:09:56 | dansmith | so that's unrelated I believe, unless the need for the new cpu feature discovery was because of the meltdown patch, | |
| 22:10:18 | dansmith | but I expect kashyap's fix won't solve that as it's a qemu-missing-a-thing problem | |
| 22:10:24 | mriedem | ok | |
| 22:21:59 | mriedem | dansmith: if you guys have vgpu people internally besides bauzas that can take a look at this https://bugs.launchpad.net/nova/+bug/1752463 | |
| 22:22:00 | openstack | Launchpad bug 1752463 in OpenStack Compute (nova) "Attaching virtual GPU devices to guests in nova" [Medium,Incomplete] | |
| 22:26:30 | melwitt | mriedem, dansmith: so we're agreed to approve https://blueprints.launchpad.net/nova/+spec/libvirt-cpu-model-extra-flags as a bp and we'll backport it, calling out in the backport why we're making an exception and backporting bp work. is that right? | |
| 22:26:54 | dansmith | melwitt: I'm cool with that yeah | |
| 22:27:51 | dansmith | mriedem: maybe, but that seems pretty low priority and can just wait for him to be back right? | |
| 22:28:24 | mriedem | dansmith: sure | |
| 22:37:01 | melwitt | mriedem: are you cool with the cpu model flags bp and the idea of backporting it? | |
| 22:37:51 | mriedem | i'm not crazy about it being a bp if we know we're going to backport it | |
| 22:38:04 | mriedem | i'd rather pretend it's not and say it's a bug fix | |
| 22:39:19 | mriedem | https://review.openstack.org/#/c/534384/5//COMMIT_MSG@28 definitely makes it sound feature-y too though | |
| 22:39:30 | mriedem | "besides the fix, you can also configure nova for other goodies!" | |
| 22:39:56 | melwitt | heh. yeah. this is definitely an odd case | |
| 22:40:55 | mriedem | now, if pcid as the extra flag is the only thing you'd care about if you only care about the fix, | |
| 22:41:24 | mriedem | then this could be a [workarounds] option with a boolean to set pcid or not, | |
| 22:41:27 | mriedem | and backport that | |
| 22:41:43 | mriedem | then the free-form wild west extra flags thing that is more of a feature could only be master | |
| 22:41:51 | mriedem | and we'd deprecate the workaround in master | |