Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-02-01
20:37:08 bauzas so yeah, we could say what terrible thing could happen to them
20:37:17 mriedem i'll say, "However, once all computes are upgraded, the scheduler not being able to make requests to Placement will result in **NoValidHost** errors"
20:37:24 bauzas fine by me
20:37:32 bauzas just update it quick and I'll +2
20:37:44 bauzas that's docs
20:37:49 bauzas and we can refine that later
20:37:52 bauzas hence my +1
20:38:16 bauzas I personnally even think we could fast-approve doc things - but I'm nuts :)
20:40:25 openstackgerrit Matt Riedemann proposed openstack/nova: doc: add upgrade notes to the placement devref https://review.openstack.org/427367
20:40:27 mriedem bauzas: done ^
20:41:31 bauzas mriedem: I had two comments about things you haven't added, so I could amend that too in a follow-up
20:42:10 mriedem oh i totally missed the first 2 comments
20:42:54 bauzas no worries, that's unrelated to your chnage
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

Earlier   Later