Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-02-01
21:46:39 edleafe jaypipes: ok, I can work on it
21:55:39 mriedem edleafe: jaypipes: to be clear, barring some miracle, i think that one is probably too risky at this point given the size and complexity https://review.openstack.org/#/c/404472/
21:55:44 mriedem and we're <24 hours to rc1
21:56:12 jaypipes mriedem: yes, understood.
21:56:16 mriedem ok
21:56:26 mriedem just didn't want any surprises come tomorrow
21:56:33 jaypipes yeah, it's my fault anyway.
21:56:43 mriedem which i realize sucks given everything that already went in to get here
21:57:05 mriedem jaypipes: i'm not placing blame or anything - you've done a shitload of work to get to this point
21:57:31 jaypipes mriedem: it's cool, man
21:57:59 edleafe mriedem: jaypipes:should have a revision within the hour
21:58:04 openstackgerrit Matt Riedemann proposed openstack/nova: Collected release notes for Ocata CellsV2 https://review.openstack.org/424737
21:58:05 openstackgerrit Matt Riedemann proposed openstack/nova: Add release note for nova-status upgrade check CLI https://review.openstack.org/426911
21:58:05 openstackgerrit Matt Riedemann proposed openstack/nova: Add prelude section for Ocata https://review.openstack.org/426864
21:58:08 mriedem melwitt: sfinucan: bauzas: dansmith: i've rev'ed the renos for the prelude ^
21:58:28 bauzas mriedem: kewl
21:59:44 edleafe jaypipes: if you could give me a quick answer to my question on https://review.openstack.org/#/c/404472/29/nova/compute/resource_tracker.py@81
22:00:07 bauzas mriedem: jaypipes: given https://review.openstack.org/#/c/404472/ would not be Ocata, maybe we should think on how it could be a problem for scheduling Ironic RCs in Pike
22:00:24 bauzas because I think we could then only check those by Queens
22:00:34 mriedem bauzas: i didn't say it was'nt going to happen,
22:00:42 mriedem but i'm saying it's very close and tight at this point
22:01:21 mriedem i don't really follow the issue you're bringing up though either,
22:01:27 mriedem but we always have service versions..
22:01:35 bauzas honestly, I think it could be a bit difficult to have it merged by tomorow
22:01:39 mriedem i do too
22:01:46 mriedem which is why i said that
22:01:53 mriedem but i'm not following the queens comment
22:02:13 bauzas I wonder if we should then maybe add a service version for ^
22:02:28 bauzas so we could be knowing if the compute is providing Ironic versions
22:02:39 mriedem bauzas: well, we could do that in pike couldn't we?
22:02:49 bauzas yeah probably
22:02:49 mriedem what checks the service versions? the scheduler?
22:02:54 bauzas yup
22:03:04 mriedem then it's the same as we did in your change
22:03:28 bauzas the other problem is that we could only have ironic RCs if the Ironic API is happy with that
22:03:40 mriedem we're not sure about scheduling with these yet are we? i remember something something extra specs, but
22:04:00 mriedem we're already past the point of minimum ironic API for supporting node.resource_class
22:04:07 bauzas sorry, it's late so that's possibly why I'm a bit confusing people
22:04:22 mriedem http://docs.openstack.org/developer/ironic/dev/webapi-version-history.html
22:04:26 mriedem 1.21 added node.resource_class
22:04:32 mriedem we require 1.29 or something right now of ironic
22:04:32 bauzas I'm trying to think how to know if this RP is providing new custom RCs
22:04:44 mriedem well, i guess ocata compute requires ironic >=1.29
22:05:26 mriedem gd i have like a 15 minute deep purple live in tokyo organ solo in my ears right now
22:05:30 mriedem i can't think straight either
22:05:52 bauzas tbc, if we don't find custom RCs, does that mean - either the RP (compute) is not yet having the new Ironic resources , - or, that Ironic doesn't provide new RCs
22:06:19 mriedem the node doesn't have to have a resource_class set,
22:06:28 mriedem regardless of whether or not we support that level of the ironic api in the ironic driver
22:06:54 mriedem btw, newton compute supports the minimum ironic api that supports resource classes https://github.com/openstack/nova/blob/stable/newton/nova/virt/ironic/client_wrapper.py#L37
22:07:10 bauzas cool then
22:07:17 mriedem anyway, the scheduler won't use placement until computes are ocata or newer,
22:07:23 mriedem which supports high enough ironic api
22:07:45 mriedem i thought the thing was, the flavor extra spec would have the resource class in it, and if it's there, then we filter on ironic RPs using that resource class
22:08:02 mriedem jroll: i just need you to appreciate my live in tokyo reference
22:08:06 jroll +1
22:08:09 mriedem because dansmith failed to do so
22:09:03 mriedem jroll: we're just talking about what the implications are for our ability to do things in pike if https://review.openstack.org/#/c/404472/ doesn't make ocata
22:09:06 bauzas alright
22:09:09 jroll mriedem: so we need to be putting inventory (based on resource class) in the placement API a cycle before we can filter on it
22:09:11 jroll I think
22:09:29 mriedem jroll: well, we can use nova-compute service versions to flag that i think
22:09:38 mriedem i.e. https://review.openstack.org/#/c/404472/ bumps the compute service version
22:09:46 jroll maybe I shouldn't try to think this through on irc for the fifth time and just hang out with y'all for a while at ptg
22:09:50 mriedem so once all of your computes are at that level, then we support filter on resource class in the scheduler
22:10:15 dansmith mriedem: I failed to do what?
22:10:29 jroll mriedem: where does that bump the version?
22:10:35 mriedem jroll: that patch doesn't today
22:10:43 jroll ah
22:10:45 mriedem we're saying if it doesn't land until pike, we do it in pike
22:10:49 jroll that explains everything
22:11:09 mriedem jroll: e.g. https://review.openstack.org/#/c/425806/
22:11:38 bauzas I'm just trying to find the implications
22:11:43 mriedem then we used that here https://review.openstack.org/#/c/417961/41/nova/scheduler/filter_scheduler.py@174
22:11:51 bauzas and how if we don't merge it by Ocata, how to flag that
22:12:04 mriedem so with service version 16, your nova-compute won't start unless configured for placement,
22:12:17 jroll aha
22:12:20 mriedem and then the scheduler checks if the minimum nova-compute in the deployment is at least 16, and if so, it goes hog wild on placement
22:12:36 mriedem i'm saying we do the same for ironic resource classes if we need to in pike
22:12:43 bauzas so the scheduler could possibly know whether it could verify new-way
22:12:46 mriedem so if you have ocata computes, then you don't get that function yet
22:12:55 mriedem but once you're computes are upgraded to pike, you get it
22:12:58 mriedem *your
22:13:01 bauzas exactly
22:13:11 jroll and then we'll have... if 'extra_spec:custom_foo' in request_spec.flavor AND service_version > the_one_with_resource_classes: placement_client.find_nodes_with_class('custom_foo')
22:13:16 jroll or whatever
22:13:24 jroll else do the old crap
22:13:30 mriedem yeah basically
22:13:48 bauzas something like that indeed
22:14:01 jroll and in queens we make the extra spec thing mandatory and maybe even fix flavor to not need that
22:14:28 mriedem maybe
22:14:33 mriedem i can't think n+2
22:14:39 jroll fair
22:14:42 jroll s/queens/future
22:14:59 mriedem by at least pike-eol :)
22:15:04 jroll regardless, pike looks like progress
22:15:06 jroll heh
22:15:13 jroll sounds good to me, thanks
22:15:27 mriedem solid progress either way i think
22:45:40 mriedem this is wrong right? https://review.openstack.org/#/c/408571/41/nova/api/openstack/compute/schemas/servers.py@277
22:45:45 mriedem should be terminated_at?

Earlier   Later