| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-02-10 | |||
| 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 | |
| 18:30:21 | mriedem | since there were big conditionals in that patch at one point which were all just for ironic | |
| 18:30:23 | leakypipes | superdan: an OpenStack admin may have set the node.resource_class attribute for some or all of their Ironic baremetal nodes, but a) there may be records in Nova already existing that refer to the consumed resources like VCPU, MEMORY_MB and DISK_GB. We need to continue to track those "resources" like we do now but also track the new node.resource_class consumption. All of that code is basically the "auto-heal" code for Ironic installations in | |
| 18:30:24 | leakypipes | Newton and Ocatra | |
| 18:31:26 | mriedem | fwiw ironic + resource providers is broken in newton anyway i think | |
| 18:31:40 | leakypipes | superdan: yes, that code and those conditionals will not be necessary once the "flavor" for Ironic nodes no longer requests VCPU, MEMORY_MB and the like and instead just requests the custom resource class like "CUSTOM_IRON_SILVER" or whatnot. | |
| 18:31:51 | mriedem | w/o https://review.openstack.org/#/c/416762/ anyway | |
| 18:32:20 | leakypipes | mriedem: ah, yes, but that's a bit of a different thing, right? | |
| 18:32:27 | superdan | mriedem: yeah, I'd like that to be less hacky.. I'd have to think about the best way to do it though | |
| 18:32:28 | mriedem | yeah | |