Earlier  
Posted Nick Remark
#openstack-nova - 2018-03-27
15:50:45 mriedem SamYaple: did you just upgrade to newton? or ocata/pike?
15:51:22 SamYaple mriedem: newton -> ocata
15:51:40 mriedem ok and now you have a cell1 mapping for the nova db
15:51:47 SamYaple oh yea its all working now
15:51:49 mriedem so you're pulling instances from https://github.com/openstack/nova/blob/ed55dcad83d5db2fa7e43fc3d5465df1550b554c/nova/compute/api.py#L2271
15:51:59 mriedem ok
15:52:26 mriedem at this point i'm not sure what the nova-status version check would look for, nova-osapi_compute services with version < 15 across all cells?
15:52:32 mriedem and then backport that to queens, pike and ocata?
15:52:40 gibi jaypipes: could be a problem with our model
15:52:40 SamYaple mriedem: i think so
15:52:51 SamYaple there are no logs indicating any issues
15:53:04 SamYaple mriedem: i had to walk to code and db (which im not super familiar with) to findthis
15:53:11 mriedem SamYaple: yeah like i said at this point that should be a warning, but a warning in rocky doesn't help you in ocata
15:53:22 mriedem SamYaple: can you report a bug and i can bring it up in the cells meeting?
15:53:29 SamYaple im looking to the future :)
15:53:32 SamYaple sure will do
15:53:47 mriedem whatever we do can at least help the next poor soul that runs into this
15:53:52 SamYaple exactly
15:53:55 mriedem thanks
15:54:43 SamYaple nova uses launchpad still, right?
15:54:51 mriedem hell yeah
15:55:02 SamYaple :)
15:55:41 Spaz-Home Trade me plz.
15:56:02 jaypipes gibi, mlavalle: please move convo to https://etherpad.openstack.org/p/X0RboWOe7C
15:56:08 gibi jaypipes: ack
16:05:03 openstack Launchpad bug 1759316 in OpenStack Compute (nova) "pre-cells_v2 nova-osapi_compute service in database breaks instance lookup" [Undecided,New]
16:05:03 SamYaple mriedem: https://bugs.launchpad.net/nova/+bug/1759316
16:06:24 jaypipes mlavalle: are you light green on etherpad?
16:06:30 openstackgerrit Surya Seetharaman proposed openstack/nova master: Scheduling Optimization: Remove cell0 from the list of candidates https://review.openstack.org/556821
16:06:31 openstackgerrit Surya Seetharaman proposed openstack/nova master: Add --enable and --disable options to nova-manage update_cell https://review.openstack.org/555416
16:06:31 openstackgerrit Surya Seetharaman proposed openstack/nova master: Allow scheduling only to enabled cells (Filter Scheduler) https://review.openstack.org/550527
16:06:32 openstackgerrit Surya Seetharaman proposed openstack/nova master: Update the cells FAQs and scheduler maintenance docs. https://review.openstack.org/556459
16:06:44 mlavalle jaypipes: I am green
16:07:03 jaypipes mlavalle: cool, thx :)
16:08:42 sahid gibi: i responded to your comments on the emulthreads spec, if you can let me know your rhinking on how to handle that specific point
16:11:34 kashyap mriedem: Just to note, after last 30 mins of looking around, I've updated min versions for libvirt / QEMU / libguestfs for Debian, Fedora and RHEL: https://wiki.openstack.org/wiki/LibvirtDistroSupportMatrix#Distro_minimum_versions
16:11:38 mriedem SamYaple: ack
16:12:29 kashyap Once I do for openSUSE & SLES, then it gives a somewhat representative sample to update the code & remove backward compat cruft.
16:12:39 mriedem kashyap: ok. you could maybe get imacdonn or stvnoyes1 to help out with the oracle linux entry, and AJaeger or toabctl to help out with suse
16:13:12 mriedem kashyap: well, the proposed 'next' version is generally communicated on the ops mailing list for feedback
16:13:18 kashyap Thanks; I was just looking up things myself for the past bit. And for Debian at least I got double-checked w/ a Debian person
16:13:31 kashyap mriedem: Yes, that too, how could I forget that :-)
16:13:44 kashyap (I myself added a note about mail to Operators in the wiki. Won't miss that.)
16:13:53 kashyap s/Wiki/PTG Etherpad/
16:16:47 sahid btw mriedem or perhaps dansmith, i know that your are not so interested about the emulator threads things but if one of you can have a look at https://review.openstack.org/#/c/511188/
16:17:51 sahid jay pipes looks to be also the one to review it but at some point i will need to have an other core
16:18:06 openstackgerrit Artom Lifshitz proposed openstack/nova-specs master: NUMA-aware live migration https://review.openstack.org/552722
16:19:03 sahid thanks in advance
16:19:19 mriedem sahid: that is wayyyy outside of my wheelhouse
16:20:08 bauzas mriedem: mmmm, we approved https://blueprints.launchpad.net/nova/+spec/vgpu-rocky but I discussed with jaypipes about how we would support multiple VGPU types by using a new conf opt and we agreed to provide a spec for that
16:20:16 bauzas mriedem: fine if I'm still using that blueprint ?
16:20:24 mriedem bauzas: ask melwitt
16:20:30 sahid yes yes no worries
16:20:32 bauzas melwitt: arouuuuund ?
16:20:41 toabctl kashyap, mriedem the (open)SUSE entries seems to be ok. the upcoming versions are not yet there but SLES12SP3 is the version that we need support for imo
16:21:13 mriedem toabctl: as the next min version you mean?
16:21:16 bauzas sahid: https://review.openstack.org/#/c/511188/ is on my list
16:21:19 mriedem for rocky, we already have the next min versions in plae
16:21:21 mriedem *plcae
16:21:23 mriedem damn it
16:21:27 bauzas place FTW
16:21:40 sahid bauzas: ah cool, thanks
16:21:45 mriedem https://github.com/openstack/nova/blob/ed55dcad83d5db2fa7e43fc3d5465df1550b554c/nova/virt/libvirt/driver.py#L207
16:21:47 mriedem toabctl: ^
16:22:41 mriedem kashyap: andreas_s is the person to ask for zkvm
16:22:52 toabctl mriedem, I'm saying the versions are up-to-date. so Rocky seems to be fine
16:23:11 mriedem yeah, we're talking about what the next min versions should be in S
16:24:47 toabctl mriedem, so do you plan to use a higher version than currently supported on SLES/openSUSE? looks like most other distros have lower versions currently
16:25:14 toabctl mriedem, but there will be SLES15 and openSUSE Leap 15 soon. both will have newer versions. let me check these
16:25:29 mriedem toabctl: likely not no, the next min version should be compatible with what the various distros can support in S
16:25:40 mriedem the point of the next min version isn't to be the bleeding edge
16:25:49 mriedem it's to raise the bar, but still be a minimum that can be supported across distros
16:26:30 imacdonn mriedem kashyap toabctl Do keep stvnoyes1 and I in the loop, please .... QEMU/KVM version for Oracle Linux could be a bit tricky ... I think somenew newer is in the works there, but I can't make any public statements at the moment
16:26:40 imacdonn something* newer
16:27:03 openstackgerrit Merged openstack/nova master: add check before adding cpus to cpuset_reserved https://review.openstack.org/539865
16:27:12 openstackgerrit Merged openstack/nova master: Docs: modernise links https://review.openstack.org/556024
16:29:25 gibi sahid: responded in https://review.openstack.org/#/c/511188/13
16:29:57 cfriesen kashyap: just added a comment to your cpu feature flag review, but might make sense to discuss it here....seems like libvirt does allow you to set additional features when using host-model, do we want to artificially restrict that?
16:36:39 jaypipes gibi, mlavalle: gotta love etherpad conversations. even better than IRC conversations... ;)
16:37:00 mlavalle jaypipes: it was a good idea
16:37:23 mlavalle if there is a lot to discuss, it seems more orderly
16:39:06 openstackgerrit Ed Leafe proposed openstack/nova-specs master: Add Generation to Consumers https://review.openstack.org/556971
16:39:22 edleafe cdent: jaypipes: efried: ^^
16:39:34 openstackgerrit Matt Riedemann proposed openstack/nova-specs master: Few correction in the server filter/sort spec https://review.openstack.org/527019
16:39:34 efried edleafe: noyce
16:39:38 cdent edleafe: roger that
16:42:15 efried bauzas: ^ I think you wanted to refer to that from your spec
16:42:31 efried bauzas: Add Generation to Consumers https://review.openstack.org/556971 that is
16:42:41 bauzas mmm ?
16:42:50 bauzas it's 18:42 here and my brain dropped
16:43:04 bauzas and I still have to write a spec :p
16:50:18 dansmith bauzas: on this: https://review.openstack.org/#/c/554134/3
16:50:50 dansmith bauzas: I get the desire for consistency, but it seems to me that on POST, extra_specs would always be empty, and on PUT you can't modify them anyway (right?)
16:51:21 dansmith I guess maybe that's a reason to do it for PUT, but POST seems completely trivial
16:52:31 bauzas dansmith: sec, verifying
16:52:43 bauzas dansmith: because IIRC, you can *create* a flavor and passing a spec
16:52:53 dansmith bauzas: see the comments in the spec that say no
16:52:56 bauzas in the same novaclient call
16:53:18 dansmith maybe, but not on the actual POST of /flavors
16:53:28 dansmith confirmed in flavor_manage

Earlier   Later