| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-03-27 | |||
| 15:48:53 | jaypipes | bauzas: yes. and it already does that. | |
| 15:48:57 | SamYaple | mriedem: with the old services not deleted, GETs on instances (nova show's) would fail | |
| 15:48:58 | bauzas | \o/ | |
| 15:49:12 | bauzas | I was out of nested RPs for a while | |
| 15:49:13 | mriedem | SamYaple: ok so before this, the api code just relied on getting the instances from the nova db configured in your nova-api nova.conf [database]/connection field right? | |
| 15:49:20 | gibi | jaypipes: by claiming bandwidth we implicitly select the backend, that is why backend comes into the picture | |
| 15:49:20 | bauzas | but that's a very nice point | |
| 15:49:41 | mriedem | SamYaple: oh are you saying the new 15-level services are fixing the problem for you then? | |
| 15:49:53 | mriedem | but you didn't know about those until you had figured out the problem with the older service versions | |
| 15:49:59 | SamYaple | yes | |
| 15:50:02 | mriedem | ok | |
| 15:50:26 | jaypipes | gibi: but why should the nova scheduler care about that? shouldn't the nova scheduler just claim resources against the provider of network bandwidth for a specific physical network and then leave it to os-vif and the compute node to pick whatever network backend it wants? | |
| 15:50:28 | gibi | jaypipes: we failed to find a RP model that allows claiming bandwidth but not selecting a specific backend that bandwidth belongs to | |
| 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 | SamYaple | mriedem: i think so | |
| 15:52:40 | gibi | jaypipes: could be a problem with our model | |
| 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 | SamYaple | mriedem: https://bugs.launchpad.net/nova/+bug/1759316 | |
| 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: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: Allow scheduling only to enabled cells (Filter Scheduler) https://review.openstack.org/550527 | |
| 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: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 | efried | edleafe: noyce | |
| 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:38 | cdent | edleafe: roger that | |
| 16:42:15 | efried | bauzas: ^ I think you wanted to refer to that from your spec | |