Earlier  
Posted Nick Remark
#openstack-nova - 2017-02-01
20:35:04 bauzas because now, TripleO and Puppet folks can just upgrade in the order they want
20:35:13 bauzas except they need to upgrade computes last
20:35:24 bauzas which is the exact sequence we already have
20:35:35 bauzas so nothing is changing for them
20:36:19 mriedem result in a hard failure in the 16.0.0 Pike release."
20:36:19 mriedem maybe i should just remove this entirely: "However, the scheduler not being able to make requests to Placement will
20:36:28 bauzas possibly
20:36:51 bauzas the thing is, nova.conf has to be updated for all services in Ocata, period
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

Earlier   Later