| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-09-24 | |||
| 12:30:00 | kashyap | johnthetubaguy: But I like your phrasing, which gives a much simplified view of the problem :-) | |
| 12:30:21 | johnthetubaguy | kashyap: yeah, I just reading through the wiki page | |
| 12:30:59 | kashyap | johnthetubaguy: Based on that, I think we can simply just go with 'Bionic'. | |
| 12:31:11 | kashyap | I'll double-check all the other distros, too | |
| 12:33:13 | johnthetubaguy | so, I think we said 3.0.0 and 2.8.0 which is Debian Stretch being the lower bound next, so its jump from Ubuntu Xenial to Debian Stretch as the lowest (including dropping SUSE leap 42.2) | |
| 12:33:33 | johnthetubaguy | https://wiki.openstack.org/wiki/LibvirtDistroSupportMatrix | |
| 12:33:35 | mdbooth | Just debugging a functional test where I'm trying to force an instance to a particular host. I'm getting NoValidHost. It seems we always ask placement for candidates even if we're forcing a specific host, is that correct? | |
| 12:33:43 | johnthetubaguy | kashyap: I just updated that for Rocky | |
| 12:34:47 | kashyap | johnthetubaguy: Ah, thanks! | |
| 12:34:49 | johnthetubaguy | kashyap: hmm, KVM for IBM Z... that seems to be a problem | |
| 12:35:15 | kashyap | johnthetubaguy: Hmm, so we can't settle with Bionic | |
| 12:35:37 | johnthetubaguy | well, unless they updated or we don't care about them | |
| 12:36:56 | kashyap | johnthetubaguy: Yeah. I'll ask on the list about what their plan is | |
| 12:42:00 | kashyap | johnthetubaguy: For Stein we are yet to bump to the advertized versions, as you may have noticed. | |
| 12:45:07 | johnthetubaguy | kashyap: so we often do that every other cycle, historically | |
| 12:45:39 | kashyap | johnthetubaguy: Yeah. I was just trying to stick to what we said in this commit: | |
| 12:45:47 | kashyap | http://git.openstack.org/cgit/openstack/nova/commit/?h=master&id=28d337b ("Pick next minimum libvirt / QEMU versions for "Stein"") | |
| 12:57:51 | johnthetubaguy | kashyap: I found this: https://www-01.ibm.com/common/ssi/cgi-bin/ssialias?infotype=OC&subtype=NA&htmlfid=897/ENUS5648-KVM&appname=totalstorage#lifecycl | |
| 12:59:05 | kashyap | johnthetubaguy: It doesn't tell us version info of QEMU and libvirt, does it? | |
| 12:59:27 | johnthetubaguy | kashyap: seems to suggest it is discontinued, and no longer supported though | |
| 13:01:06 | kashyap | johnthetubaguy: Oh, yeah. | |
| 13:01:26 | kashyap | For completeness' sake I'll ask the open question for KVM for IBM folks. | |
| 13:01:43 | kashyap | If there's no response, we can pick with a version that aligns with the rest of all the distros. | |
| 13:02:19 | johnthetubaguy | kashyap: http://kvmonz.blogspot.com/2017/03/kvm-for-ibm-z-withdrawal.html | |
| 13:02:42 | kashyap | Ah, it's the blurb | |
| 13:02:46 | johnthetubaguy | kashyap: I think we can ignore it now, basically its all upstream, use a regular distro, appears to be the message | |
| 13:03:00 | kashyap | Okay, then. We're good. | |
| 13:03:03 | kashyap | Thanks for digging! | |
| 13:03:09 | johnthetubaguy | I was curious what it was | |
| 13:06:31 | johnthetubaguy | kashyap: next question is specify the next next, if you get me, seems like Oracle and SLES need a dig | |
| 13:07:01 | kashyap | johnthetubaguy: Right, I'll ask the SLES and Oracle folks to comment | |
| 13:07:14 | kashyap | johnthetubaguy: I'm pretty damn sure they'll also align, if I see their historical releases | |
| 13:07:37 | kashyap | The community edition, openSUSE, already ships the desired "Bionic" versions. | |
| 13:11:27 | kashyap | Thanks for helping me dig! | |
| 13:22:27 | bauzas | mriedem: quick question, when calling update_provider_tree_for_vgpus() we pass a mutable dict of allocations, and then we modify the allocations directly | |
| 13:22:55 | bauzas | mriedem: that means that we will call the placement API with the allocations dict once we call it ? | |
| 13:23:11 | bauzas | I mean, it means that the method will have to modify directly the allocations dict | |
| 13:23:12 | bauzas | ? | |
| 13:23:18 | kashyap | johnthetubaguy: gibi: As promised: http://lists.openstack.org/pipermail/openstack-operators/2018-September/015929.html | |
| 13:23:48 | bauzas | mriedem: so we expect to have the allocations dict to be modified ? | |
| 13:24:38 | mriedem | bauzas: yes https://github.com/openstack/nova/blob/master/nova/compute/resource_tracker.py#L943 | |
| 13:24:44 | bauzas | mriedem: cool | |
| 13:29:14 | openstackgerrit | Merged openstack/nova master: nova-status - don't count deleted compute_nodes https://review.openstack.org/604495 | |
| 13:29:27 | openstackgerrit | Merged openstack/nova master: Imported Translations from Zanata https://review.openstack.org/604577 | |
| 13:30:42 | mriedem | imacdonn: you want to backport https://review.openstack.org/#/c/604495/ as well? | |
| 13:48:17 | openstackgerrit | Vlad Gusev proposed openstack/nova stable/rocky: nova-status - don't count deleted compute_nodes https://review.openstack.org/604785 | |
| 13:48:28 | openstackgerrit | Vlad Gusev proposed openstack/nova stable/queens: nova-status - don't count deleted compute_nodes https://review.openstack.org/604786 | |
| 13:50:52 | mriedem | s10: thanks | |
| 13:53:26 | dansmith | mriedem: no test on this? https://review.openstack.org/#/c/554380/ | |
| 13:54:19 | openstackgerrit | Vlad Gusev proposed openstack/nova stable/pike: nova-status - don't count deleted compute_nodes https://review.openstack.org/604788 | |
| 13:55:00 | bauzas | mriedem: just another point, you reshape first and then you only update the child inventories after that | |
| 13:55:04 | mriedem | i guess not? i wrote it in march. | |
| 13:55:15 | dansmith | ...and march is the month of no tests? :D | |
| 13:55:22 | bauzas | mriedem: is this because you don't want to have a child inventory in case the reshape provides an exception ? | |
| 13:55:23 | mriedem | that's what we agreed in dublin | |
| 13:55:37 | dansmith | I didn't realize it was a backport so was about to -1 it out of existence | |
| 13:55:49 | efried | n-sch/placement meeting in 5 minutes in #openstack-meeting-alt | |
| 13:56:54 | openstackgerrit | Merged openstack/nova master: Transform libvirt.error notification https://review.openstack.org/484851 | |
| 13:59:44 | mriedem | dansmith: before you are gone for the rest of the week, we should probably figure out what we expect users to pass for the bdm volume_type value in the compute API, | |
| 13:59:55 | mriedem | because cinder's volume create API allows passing the volume type name or ID | |
| 14:00:05 | mriedem | i was thinking the compute API would just take volume type name | |
| 14:00:07 | dansmith | it would suck to not take either | |
| 14:00:13 | dansmith | just name? | |
| 14:00:24 | mriedem | i didn't realize the volume create API took either | |
| 14:00:27 | mriedem | until 30 seconds ago | |
| 14:00:36 | dansmith | why is it hard for us to take either? | |
| 14:00:39 | mriedem | it's not | |
| 14:01:05 | mriedem | it came up while reviewing the db model changes for nova b/c he had originally restricted the volume_type column to 36 characters for volume type id | |
| 14:01:13 | mriedem | i got him to change it to 255 to allow name | |
| 14:01:16 | dansmith | ah | |
| 14:01:31 | mriedem | anyway, i asked the question on https://review.openstack.org/#/c/604687/ | |
| 14:01:33 | dansmith | and that's their name restriction? | |
| 14:01:42 | mriedem | yes | |
| 14:01:44 | dansmith | that _is_ the downside of proxy apis I suppose, but .. :) | |
| 14:01:45 | dansmith | okay | |
| 14:02:11 | dansmith | surely we're not merging that until the rest of the patches are stacked on top right? | |
| 14:02:21 | mriedem | yes he split this out b/c i asked him to | |
| 14:02:30 | mriedem | and i asked him to rebase the rest back on top | |
| 14:02:36 | dansmith | okay cool | |
| 14:07:15 | mriedem | the other thing is if nova-api is going to validate that the requested volume type exists, we'll need to know if it's an id or a name, which kind of sucks | |
| 14:07:49 | mriedem | we can do is_uuid_like for that, but ... | |
| 14:09:12 | s10 | mriedem: can I ask to add volume_name in https://review.openstack.org/#/c/604687/ or it would be too much? | |
| 14:10:20 | mriedem | s10: and eventually description and az and hints and metadata... | |
| 14:15:29 | mriedem | s10: if people are going to want to also pass volume name for the next several years, i'd rather us just add that now in the same microversion, | |
| 14:15:33 | mriedem | dansmith: ^ what do you think? | |
| 14:15:53 | mriedem | this is the definition of the slippery slope with these proxy apis | |
| 14:16:13 | dansmith | I think I said name+volume already right? | |
| 14:16:17 | dansmith | did I miss other discussion? | |
| 14:16:47 | dansmith | oh | |
| 14:16:49 | dansmith | volume name? | |
| 14:16:50 | mriedem | name + volume_type? | |
| 14:16:56 | mriedem | yes, he's asking that we also proxy a volume name, | |
| 14:17:11 | dansmith | ffs | |
| 14:17:13 | mriedem | today nova-compute doesn't give name/description to any volumes it creates | |
| 14:17:32 | s10 | mriedem: that's what we are doing :( we have our patch for volume name since 2014 and volume type since 2015. I will be happy to drop it and make our OpenStack more close to the upstream... | |
| 14:17:32 | mriedem | ftersin had a patch to at least name the volumes that nova created | |
| 14:18:09 | openstackgerrit | Stephen Finucane proposed openstack/python-novaclient master: docs: Add redirects https://review.openstack.org/604796 | |
| 14:18:10 | dansmith | and we have to handle the multi-create case where they can't be the same name yeah? | |
| 14:18:35 | mriedem | depends on what cinder allows, checking the cinder db model | |
| 14:18:38 | dansmith | presumably that means we have to have all the handling for races even against volumes we didn't reate | |