Earlier  
Posted Nick Remark
#openstack-nova - 2017-02-10
16:41:23 mriedem your general comment on anything libvirt version related is "but that version was released 2 years ago?!"
16:42:06 kashyap mriedem: No, please don't be so harsh that I don't care about operators who don't care about bleeding edge.
16:42:40 kashyap mriedem: If you saw, I was careful to not mention any newer release on the response :-)
16:42:49 mriedem heh
16:43:00 mriedem so you mean bump to 1.2.9 and mark 1.3.1 as 'next'?
16:43:01 kashyap I know you'd chide me for that. Learnt from the burnt.
16:43:24 kashyap Yeah.
16:43:27 mriedem it sounded like sgordon was ok with going to 1.2.9
16:44:01 mriedem 1.3.1 would be nice since we have lots of checks we could drop after that i think
16:44:10 mriedem but that's queens at the earliest
16:44:25 kashyap Okay, maybe we need hard data here: to evaluate pros & cons w.r.t. features / critical bug fixes with 1.3.1 compared to 1.2.9
16:44:36 mriedem it's less about that,
16:44:39 mriedem and more about distro support
16:45:12 sgordon mriedem, from an RDO and RHOSP pov we always recommend folks use the latest RHEL anyway
16:45:15 kashyap Me nods. I am not ignoring the support matrix
16:45:31 sgordon mriedem, so right now while we still support OSP all the way back to icehouse, the recommended host OS for that is RHEL 7.3
16:45:48 sgordon mriedem, and that is the combination we currently (re)validate
16:46:07 mriedem which is libvirt 2.0
16:46:09 mriedem ballsy
16:46:13 sgordon correct
16:46:19 cfriesen mriedem: which distros do we care about
16:46:21 kashyap For upstream, we should also see what is available in Debian, too
16:46:33 sgordon (and of course anyone still on icehouse, isnt impacted by us changing the minimum for ocata anyway)
16:46:51 mriedem cfriesen: https://wiki.openstack.org/wiki/LibvirtDistroSupportMatrix
16:48:04 mriedem so rhel would be ok with 1.3.1
16:48:10 mriedem i'm less sure about debian and sles/suse
16:48:54 mriedem maybe i should ask ajaeger
16:49:23 kashyap Yeah, if we can get the data from Debian and SUSE folks, we can settle on 1.3.1 -- as the cross-distro supported version, for upstream
16:49:58 mriedem zigo would know about debian
16:50:43 kashyap Yeah, would be better if they responded on the list, so the record is archived
16:51:22 mriedem i'll follow up with those guys
16:51:48 kashyap Thanks.
16:52:32 mordred debian stable has 1.2.9 - debian testing has 3.0.0
16:52:38 AJaeger hi nova team
16:52:47 cfriesen do we only care about LTS versions of Ubuntu?
16:53:06 mordred cfriesen: yah
16:53:16 AJaeger mriedem: what's up?
16:53:43 kashyap AJaeger: See the mailing list post:
16:53:49 mriedem AJaeger: see -infra now :)
16:53:54 AJaeger ;)
16:54:06 kashyap AJaeger: http://lists.openstack.org/pipermail/openstack-dev/2017-February/111902.html
16:54:06 mordred cfriesen: or, rather, we must care about at least the latest LTS- and we only test the latest LTS in the gate. our policy _technically_ is to target the latest ubuntu unless doing so would make backporting to latest lts unreasonably difficult ... but since in practice we gate on latest LTS ...
16:54:41 johnthetubaguy mriedem: superdan: is there anyone looking at the mod-wsgi service version break thing already? sneti has been working on a related bug when using the eventlet stack
16:55:40 AJaeger mriedem: libvirt 2.0.0 should be new enough, isn't it?
16:55:41 mriedem johnthetubaguy: for pike
16:56:00 superdan johnthetubaguy: I was planning to do it but haven't started yet
16:56:18 superdan johnthetubaguy: figured we probably want to discuss plans at the ptg at least
16:56:19 mriedem AJaeger: 2.0.0 would mean nova in pike wouldn't work with xenial
16:56:21 cfriesen would there be any interest in being able to specify a vif_model as part of the neutron port creation, then have nova use that vif_model when booting/attaching with that port?
16:56:25 johnthetubaguy mriedem: yeah, I was thinking both in terms of the devstack changes and the service reporting
16:56:52 mriedem AJaeger: we're talking 1.2.9 minimum libvirt for nova in pike, and 1.3.1 libvirt minimum for nova in queens
16:57:35 lascii good morning everyone
16:57:54 dims_ hey lascii !
16:58:18 melwitt lascii o/
16:58:34 johnthetubaguy superdan: OK, yeah, yeah certainly ptg fodder
16:58:47 johnthetubaguy lascii: hello hello
17:00:43 AJaeger mriedem: I let our experts answer on the mailing... AFAIK we have libvirt 2.0.0 version currently and thus a minimum requirement of any 1.x should be fine for SUSE
17:01:09 mriedem AJaeger: ok thanks
17:04:36 AJaeger mriedem: thanks for asking!
17:07:07 openstackgerrit Eric Fried proposed openstack/nova-specs master: PowerVM Driver Integration (Pike) https://review.openstack.org/432387
17:09:12 openstackgerrit Eric Fried proposed openstack/nova-specs master: PowerVM Driver Integration (Pike) https://review.openstack.org/432387
17:10:46 efried mriedem FYI ^^ for continuation of https://blueprints.launchpad.net/nova/+spec/powervm-nova-compute-driver
17:15:56 superdan mriedem: why does the 14.0.1 section talk about 14.0.0 things here? http://docs.openstack.org/releasenotes/nova/newton.html
17:16:12 mriedem it's a bug
17:16:22 mriedem oh, no,
17:16:29 mriedem that's because we didn't get the prelude into 14.0.0
17:16:37 mriedem remember bauzas added that after we released newton
17:16:42 mriedem so it got into 14.0.1
17:16:52 superdan oh
17:27:31 ygl hi all
17:37:36 openstackgerrit Dan Smith proposed openstack/nova master: Remove flavor_* functions from db/api https://review.openstack.org/431752
17:37:37 openstackgerrit Dan Smith proposed openstack/nova master: Remove main_db flavor compatibility https://review.openstack.org/431722
17:39:27 superdan hmm, where can i see the release notes as rendered like they would for a release for the current tree if it were to happen now?
17:39:33 superdan dhellmann: dims_ mriedem_lunch ^ ?
17:42:21 melwitt superdan: you mean this? http://docs.openstack.org/releasenotes/nova/unreleased.html
17:42:37 superdan melwitt: yeah
17:42:52 superdan melwitt: didn't see it in a docs job run, figured it'd be there but thanks
17:44:19 melwitt oh, yeah I dunno where/if it exists in any per patch runs
17:45:12 superdan this is what I want anyway
17:45:13 superdan so thanks
17:58:42 dims_ superdan : y was lunching :) back now
18:15:13 openstackgerrit Ed Leafe proposed openstack/nova master: placement: adds REST API for nested providers https://review.openstack.org/384807
18:15:14 openstackgerrit Ed Leafe proposed openstack/nova master: placement: allow filter providers in tree https://review.openstack.org/377215
18:15:16 openstackgerrit Ed Leafe proposed openstack/nova master: pci: add uuid field to PciDevice object https://review.openstack.org/414768
18:15:16 openstackgerrit Ed Leafe proposed openstack/nova master: placement: integrate ProviderTree to report client https://review.openstack.org/415921
18:15:17 openstackgerrit Ed Leafe proposed openstack/nova master: placement: SRIOV PF devices as child providers https://review.openstack.org/414769
18:15:18 openstackgerrit Ed Leafe proposed openstack/nova master: placement: adds ProviderTree for nested resources https://review.openstack.org/415920
18:15:18 openstackgerrit Ed Leafe proposed openstack/nova master: placement: update client to set parent provider https://review.openstack.org/385693
18:15:19 openstackgerrit Ed Leafe proposed openstack/nova master: placement: add nested resource providers https://review.openstack.org/377138
18:19:44 leakypipes mriedem_lunch, johnthetubaguy, superdan: I think https://review.openstack.org/#/c/404472/ is ready for your eyeballs again now.
18:24:10 superdan leakypipes: I don't think I've reviewed that yet at all, but
18:24:25 superdan leakypipes: does that not seem like a major layering violation? maybe that has already been discussed?
18:25:31 leakypipes superdan: sorry, I'm not quite following you. do you mean that that code is in the wrong place?
18:27:02 superdan leakypipes: the resource tracker having things like "if ironic, do this other thing"
18:27:17 superdan we try not to even do that in compute manager, which directly consumes the compute drivers
18:27:34 superdan and we nak people having tried to do stuff like that in the past
18:28:26 leakypipes superdan: yeah, it's a temporary thing until we can be sure that the request from the user just contains a list of resources to consume as opposed to the existing situation where we need to tell if the instance is a baremetal instance or not and then do something different to track Ironic resources.
18:28:48 leakypipes superdan: the dilemma we have is a chicken and egg one.
18:29:23 superdan I'm not sure what that means, request wise, but I assume that means temporary ... for a while?
18:30:11 mriedem i had made a comment at one point about subclasses the resource tracker for ironic specific resource class massaging

Earlier   Later