| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-09-24 | |||
| 11:44:42 | gibi | kashyap: OK this make sense | |
| 11:44:52 | kashyap | (Operators + Dev list) | |
| 11:44:55 | kashyap | Do we have a name for the 'T' release yet? | |
| 11:45:44 | gibi | kashyap: I think we are in the name suggestion phase | |
| 11:45:48 | kashyap | gibi: I just need to spend some tedious time to go through all distros that matter / upstream cares about, and arrive at the new enough version that is supported by all distros.. | |
| 11:46:04 | gibi | kashyap: sounds like fun | |
| 11:46:20 | kashyap | gibi: It is mind-warpingly tedious, but necessary :D | |
| 11:46:38 | gibi | kashyap: OK, that is a better description than "fun" :D | |
| 11:47:35 | kashyap | Heh | |
| 11:56:19 | kashyap | gibi: 'T' will be at the end of 2019, isn't it? | |
| 12:00:12 | gibi | kashyap: autumn 2019 | |
| 12:00:36 | kashyap | Yeah. So I'm writing an email to the list, to see if we even want to pick MIN_ versions so far out (one year ahead) | |
| 12:01:56 | kashyap | There will be 13+ libvirt releases (including maintenance streams), IIRC. And some 4 QEMU releases | |
| 12:02:23 | kashyap | I'll just write the email to the list; MattR will definitely have an opinion. As he also did this work in the past. | |
| 12:06:06 | gibi | kashyap: I agree that it is a good way forward | |
| 12:06:22 | kashyap | gibi: What do you mean? I think you mean "let's write to the list and talk there"? | |
| 12:07:15 | gibi | kashyap: yeah, lets describe the issue as you descibed above (e.g. we need a new NEXT_MIN but there will be still a lot of libvirt release until 2019 autumn) on the ML | |
| 12:08:47 | kashyap | Yeah, almost half-way through the e-mail | |
| 12:08:51 | gibi | cool | |
| 12:27:19 | johnthetubaguy | kashyap: from the wiki page, looks like the question is basically when do we drop Ubuntu 16.04 support? | |
| 12:28:28 | kashyap | johnthetubaguy: Is it just that? | |
| 12:28:48 | kashyap | johnthetubaguy: Or we can just stick to the next LTS release, that is 18.04, Bionic? | |
| 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 | |