| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-02-04 | |||
| 16:32:20 | sean-k-mooney | artom: ya that makes sense | |
| 16:32:35 | artom | sean-k-mooney, hrmm, yeah, maybe I'll rephrase it as "create claims" or something | |
| 16:32:44 | artom | Since as you correctly pointed out, they're not actually used | |
| 16:33:05 | openstackgerrit | Matt Riedemann proposed openstack/nova master: doc: update the security groups admin doc https://review.openstack.org/634735 | |
| 16:33:28 | sean-k-mooney | ya i spend about 10-15 mins looking to see if they were actully used idrectly some how then my vpn dropped and i got tea | |
| 16:34:05 | artom | So British (yes, I know you're Irish) | |
| 16:34:22 | sean-k-mooney | those be fighting words :P | |
| 16:34:33 | artom | There's no "UK" adjective! | |
| 16:34:45 | sean-k-mooney | ireland is not in the uk | |
| 16:34:52 | artom | *facepalm* | |
| 16:34:57 | artom | You're right, of course. | |
| 16:35:04 | kashyap | mriedem: If I spend this week on this https://review.openstack.org/#/c/632507/ ([WIP] libvirt: Bump MIN_{LIBVIRT,QEMU}_VERSION for "Stein"), and related clean-ups -- worth getting in before M3? | |
| 16:35:51 | artom | There's no adjective for "those tea-guzzling bastids" then :D | |
| 16:36:07 | sean-k-mooney | hehe :) | |
| 16:37:32 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Change nova-next job to run with python3 https://review.openstack.org/634739 | |
| 16:39:00 | mriedem | kashyap: idk, i generally like to raise minimums at the beginning of the cycle | |
| 16:39:08 | mriedem | if we're going to raise minimums | |
| 16:40:24 | mriedem | an operator that was upgrading recently asked me if the last time we raised minimums (in queens i think) was because of any functional reason or just code cleanup since it meant they had a harder upgrade (new centos versions and such on their compute nodes) | |
| 16:41:25 | mriedem | they were also upgrading from mitaka though i think so likely going to have some of that (OS upgrades etc) | |
| 16:42:26 | kashyap | mriedem: Yeah, you're totally right -- I completely forgot at the beginning of the cycle about this :-( | |
| 16:42:27 | stephenfin | mriedem, sean-k-mooney: This feels like something that would warrant a reno given the change in behavior. Thoughts? https://review.openstack.org/#/c/626381 | |
| 16:42:59 | mriedem | "fyi nova-compute will no longer corrupt your database you're welcome' | |
| 16:43:13 | mriedem | stephenfin: the behavior was shit | |
| 16:43:22 | mriedem | so if we have a reno, i'd make it a 'fixes' reno to explain the bug being fixed | |
| 16:43:41 | stephenfin | That it was. And I guess it's not something anyone would have been relying on | |
| 16:43:59 | mriedem | i.e. if you had allocated pci devices in your whitelist configuration, and then changed your config to remove those whitelisted devices, nova will no longer delete those records from the db since it corrupts the resource tracking for the allocated device | |
| 16:44:26 | mriedem | but i'm not sure ^ is worth explaining in a release note | |
| 16:44:33 | mriedem | it might just cause more confusion/concern than necessary | |
| 16:44:45 | stephenfin | Sweet. If you're happy, so am I | |
| 16:45:10 | mriedem | i'm not unhappy :) | |
| 16:45:20 | mriedem | and as you say, i hope no one was relying on this | |
| 16:45:46 | stephenfin | So do I. I'd ask moshele if he was around but alas, he is not | |
| 16:45:57 | mriedem | cfriesen might have an opinion | |
| 16:46:00 | mriedem | but also not around right now | |
| 16:46:01 | sean-k-mooney | so no new reno? i can add one but i agree with mriedem that it would be in fixes as the old bevahior was not a feature | |
| 16:46:16 | stephenfin | sean-k-mooney: Nah, mriedem makes a good point. It was rather broken before | |
| 16:47:48 | stephenfin | sean-k-mooney: I've just held off on the +W in case cfriesen gets a chance to wade in before tomorrow | |
| 16:48:05 | sean-k-mooney | ok cool thanks | |
| 16:51:35 | stephenfin | mriedem: I must have misunderstood something but weren't we planning to deprecate this option entirely, relying on alternatives for instance-host mapping use case? https://review.openstack.org/#/c/619953/10/nova/conf/libvirt.py | |
| 16:52:05 | sean-k-mooney | stephenfin: dan asked that we dont | |
| 16:52:10 | mriedem | stephenfin: see dansmith's comments in an earlier PS | |
| 16:52:21 | stephenfin | ack | |
| 16:57:53 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Follow up for per-instance serial number change https://review.openstack.org/634743 | |
| 17:29:37 | stephenfin | mriedem: Fancy checking this nit fix? https://review.openstack.org/#/c/626930/ | |
| 17:29:41 | stephenfin | *nit doc fix | |
| 17:31:53 | mriedem | done | |
| 17:32:34 | stephenfin | ta | |
| 17:33:23 | mriedem | stephenfin: a couple of nits in the one on top of that | |
| 17:34:11 | stephenfin | I can fix those now or in a follow-up. Your call | |
| 17:34:20 | mriedem | do it now and i'll re-approve | |
| 17:36:14 | openstackgerrit | Stephen Finucane proposed openstack/nova master: doc: Add solution to live migration ssh issues https://review.openstack.org/626931 | |
| 17:36:19 | stephenfin | mriedem: done ^ | |
| 17:49:09 | efried | artom jaypipes cdent sean-k-mooney | |
| 17:49:09 | efried | Is that still on ice? Has bp/numa-aware-live-migration brought it back into play? Or are we still doing that bp with the old style NUMA modeling? | |
| 17:49:09 | efried | Hey folks, where are we with NUMA modeling in placement? | |
| 17:50:00 | sean-k-mooney | the numa aware migration is entirely done via the resource tracker | |
| 17:50:13 | sean-k-mooney | efried: so its still on ice until train | |
| 17:50:37 | sean-k-mooney | efried: the RT changes will still be needed in eitehr case | |
| 17:51:05 | efried | So would it be appropriate to start proposing spec content for train around NUMA modeling in placement? (Again) | |
| 17:51:20 | sean-k-mooney | bauzas: ^ | |
| 17:51:50 | efried | i.e. using nested providers to represent NUMA nodes, figuring out a way to represent subtree affinity, etc. | |
| 17:51:52 | sean-k-mooney | efried: i guess but it would be good to take a more holistic aproach i think | |
| 17:52:01 | efried | holistic in what sense? | |
| 17:53:03 | sean-k-mooney | well there are a number of feature in the libvirt driver (pinning,hugepages,reatime,emulator threads,numn) all the nfv stuff that are not really placement friendly | |
| 17:53:54 | sean-k-mooney | efried: i have been wondering for a while if we shoudl create a parallel implmentation of new feature that are placment aware to replace teh existing ones with | |
| 17:54:13 | efried | not sure how we'll ever get there if we don't. | |
| 17:54:36 | cdent | yeah, I suspect a parallel leapfrog is the way to go | |
| 17:55:20 | sean-k-mooney | well my idea was to take the cellsv2 approcah and freeze/keep the exisiting feature set as is and work on a replacement in paralel and then swtich in U | |
| 17:55:32 | openstackgerrit | Merged openstack/nova master: Reject migrate with port having resource request https://review.openstack.org/630723 | |
| 17:56:41 | sean-k-mooney | it realy has become a problem lately that we have 2 seperate code patchs. 1 for numa awre guess and anotehr for non numa guests and i just feel like have one code path that works for all guesst in a common way might be the way to go | |
| 17:57:10 | sean-k-mooney | efried: anyway that is slightly different then the question you asked | |
| 17:57:48 | cdent | sean-k-mooney: I sometimes wonder the opposite: we should have two diferent paths: one for simple vms that normal people use, anothe for the crazy path :) | |
| 17:58:13 | sean-k-mooney | cdent: the issue is we also have 2 sets of config options and flavor atributes | |
| 17:58:22 | sean-k-mooney | cdent: and people mix and match them | |
| 17:59:06 | sean-k-mooney | i think we can all agree that there should only be one way of modeling the resocues in placement | |
| 17:59:23 | efried | s/resources in placement/resources: in placement/ | |
| 17:59:55 | sean-k-mooney | efried: placement does not do assignment | |
| 18:00:15 | sean-k-mooney | efried: so assignable resouces need to be tracked in the ResocueTracker also | |
| 18:00:16 | efried | at the RP level, not at the resource level, right. | |
| 18:00:29 | efried | Well, arguably they need to be tracked by the virt driver. | |
| 18:00:39 | sean-k-mooney | yes | |
| 18:01:01 | efried | I'm not sure there's a need for the resource tracker if all resources are tracked by the virt driver + placement. | |
| 18:01:25 | sean-k-mooney | well kind of. in the libvirt case the Resouce track is running in the compute aganet and is populated byt the virtdriver. | |
| 18:02:08 | cdent | efried: don't duck on that, fly that flag | |
| 18:02:18 | sean-k-mooney | efried: the virtdriver do not get there own db tables to track things so they have to use the resouce tracker to persist there tracked resources | |
| 18:03:37 | efried | sean-k-mooney: Oh, see, I disagree with that. The virt driver knows about its resources by looking at the VM. There shouldn't be a need to duplicate that information in an OpenStack database. | |
| 18:04:02 | sean-k-mooney | efried: the vm xml is not persisted acroudn vm reboots | |
| 18:04:19 | efried | oh, right, that stupid thing. We should fix *that* instead. | |
| 18:04:46 | sean-k-mooney | it could be maintianed in memory but im not sure that would work aross agent restarts | |
| 18:05:14 | sean-k-mooney | efried: well you just moving the state form the db to libvirt/xml or ram | |
| 18:05:48 | efried | Let me put it this way: Do any other virt drivers have this silly ephemeralness? | |
| 18:05:55 | efried | PowerVM doesn't. cdent, does VMWare? | |
| 18:06:12 | efried | If you reboot an ironic node, does it forget how much memory it had? | |
| 18:06:33 | sean-k-mooney | efried: all that info is stored in ironics db | |
| 18:06:47 | cdent | efried: vmware keeps track of itself, yes | |
| 18:06:52 | sean-k-mooney | libvirt db is the filesystem. | |
| 18:07:04 | efried | right, so why should the xml go away when you reboot it? | |
| 18:07:11 | efried | it's just a file in the file system, nah? | |
| 18:07:38 | sean-k-mooney | if the hsot is rebooted it does not | |
| 18:07:41 | efried | I may be tilting at windmills here, but that just seems goofy to me. | |