Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-02-01
20:43:02 bauzas but I was reading the HTML directly
20:43:15 bauzas so when I saw that, I thought it would be good to change that too
20:43:55 mriedem i replied,
20:44:14 mriedem basically, i think they are still ok statements given we want to be a bit forceful about people enabling this stuff before upgrading to ocata
20:44:26 mriedem even though we have some fallback stuff in place in ocata to soften the blow if they don't get it all done
20:44:55 mriedem the ocata upgrade notes section gives the specific details on stuff you must have done before upgrading
20:45:07 bauzas mriedem: fine, I'm not opiniated
20:45:18 mriedem are you sure about that? :P
20:45:57 bauzas I'm not opiniated *by the docs*
20:45:59 bauzas :p
20:46:04 mriedem oh ok
20:46:53 bauzas I mean, it's fine to be a bit forceful, like you said
20:59:16 mriedem bauzas: melwitt: +2 on https://review.openstack.org/#/c/427782/ now
20:59:21 mriedem ci is happy
21:00:09 bauzas mriedem: dansmith: Wipped
21:01:44 mriedem easy +W https://review.openstack.org/#/c/426810/
21:08:49 openstackgerrit Sylvain Bauza proposed openstack/nova: Add a status check for enabled filters https://review.openstack.org/427200
21:09:56 bauzas mriedem: looking
21:11:17 openstackgerrit Sylvain Bauza proposed openstack/nova: reno for notification-transformation-ocata https://review.openstack.org/426810
21:12:03 bauzas mriedem: please +W ^
21:12:09 bauzas I just fixed a typo
21:12:59 mriedem nice catch
21:13:01 dansmith bauzas: please, not in public!
21:14:09 bauzas what ?
21:14:19 bauzas talking about some guy ?
21:15:09 dansmith bauzas: about "whipping" :)
21:15:44 bauzas that's where my English vocabulary epic fails
21:16:11 bauzas hah
21:22:05 openstackgerrit Vasyl Saienko proposed openstack/nova: testing https://review.openstack.org/427930
21:34:17 jaypipes edleafe: really sorry, I haven't had a chance to do the work on the ironic patch :( my day just got consumed with meetings. :( any chance you can pick it up?
21:38:42 jroll jaypipes: edleafe: cdelatte (assume this is cdent): mriedem: fyi, once this merges in, the experimental job for nova that has "resource-class" in the name will exercise that ironic resource tracker patch
21:38:52 jroll oh, link would be good https://review.openstack.org/#/c/407651/
21:40:33 mriedem that patch is looking pretty high risk atm
21:40:44 mriedem says a guy that hasn't looked at it since last week
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 prelude section for Ocata https://review.openstack.org/426864
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: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 mriedem what checks the service versions? the scheduler?
22:02:49 bauzas yeah probably
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 bauzas I'm trying to think how to know if this RP is providing new custom RCs
22:04:32 mriedem we require 1.29 or something right now of ironic
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?

Earlier   Later