Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-09-24
10:09:25 johnthetubaguy gibi: I had thoughts on this one, but really close to approve, what do you think, if you have time to take a peak at that? https://review.openstack.org/#/c/476459/29
10:11:15 ondrejme egonzales: thats what I did, and I managed to deploy as well with successful instance launch, that instance is up and running just fine, I was just wondering if you know of any functions that will not work that way
10:23:53 gibi johnthetubaguy: looking
10:34:33 openstackgerrit Rodolfo Alonso Hernandez proposed openstack/os-vif master: Add native implementation OVSDB API https://review.openstack.org/482226
10:41:57 gibi johnthetubaguy: responeded inline. I think you raised the same issue melwitt raised in PS21 then had some back and forth and ended up passing delete_type instead on NotificationAction
10:57:36 johnthetubaguy gibi: cool, I was struggling to work out all the context in the previous revisions
10:58:00 johnthetubaguy gibi: I am OK with add the host param, but wasn't sure what you thought, can be a follow up patch
10:58:59 gibi johnthetubaguy: yeah I can do a followup right away
10:59:31 johnthetubaguy gibi: sounds good, I wasn't 100% if my reading of that was correct
10:59:46 gibi johnthetubaguy: I double checked and I think you are correct
10:59:56 johnthetubaguy gibi: given its been cooking since jun17, lets just merge where we are now!
11:00:04 gibi johnthetubaguy: I totally agree
11:00:13 johnthetubaguy cool
11:11:24 openstackgerrit Balazs Gibizer proposed openstack/nova master: Follow up for Ib6f95c22ffd3ea235b60db4da32094d49c2efa2a https://review.openstack.org/604743
11:11:38 gibi johnthetubaguy: thanks for the reviews, here is the followup ^
11:36:56 kashyap gibi: Thanks for the review here: https://review.openstack.org/#/c/562313/3
11:37:51 gibi kashyap: don't worry, it is easy to mix those variables
11:38:08 kashyap So two things there: (a) first bump the version for Stein, as advertized in commit: 28d337b (Pick next minimum libvirt / QEMU versions for "Stein")
11:38:26 openstackgerrit Vladyslav Drok proposed openstack/nova stable/pike: Fix resize_instance rpcapi call https://review.openstack.org/603439
11:39:41 kashyap gibi: ... (b) Need to pick version for the 'T' release.
11:39:52 kashyap gibi: Can't bump without first picking the future MIN versions for the 'T' release.
11:39:57 kashyap johnthetubaguy: ^ You have a comment here?
11:43:10 gibi kashyap: so you will propose a patch that set MIN based on NEXT_MIN but for that we have to figure out what will be the new value of NEXT_MIN
11:44:09 kashyap gibi: Yes. First we need to pick NEXT_MIN_* versions
11:44:17 kashyap gibi: Like I sent out an email to 'operators' list in the past: http://lists.openstack.org/pipermail/openstack-operators/2018-April/015089.html
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

Earlier   Later