Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-02-01
20:30:25 johnsom I have opened a bug for the os_vif issue I am seeing: https://bugs.launchpad.net/nova/+bug/1661086
20:30:59 johnsom Ha, everything is melting down...
20:31:24 bauzas mriedem: I mean, if the operator modifies nova.conf for all computes but forgets to do so for n-sch, and then upgrades all their computes, then we have the scheduler calling Placement, righT?
20:31:25 mriedem bauzas: oh i see this https://github.com/openstack/nova/blob/master/nova/scheduler/filter_scheduler.py#L184
20:31:38 bauzas mriedem: exactly
20:32:00 bauzas that's what I call an hard failure
20:32:23 bauzas *a* hard failure even
20:32:39 bauzas oh man, why English people not doing the liaison ?
20:33:10 mriedem hmm, so your point is good, and makes the earlier part of that bullet not completely accurate
20:33:18 mriedem in Ocata, if you deploy the Placement service `after` you upgrade the
20:33:18 mriedem "While the FilterScheduler technically depends on the Placement service
20:33:19 mriedem ``nova-scheduler`` service to Ocata and restart it, things will still work."
20:33:29 bauzas you still could
20:33:45 bauzas because n-sch won't call placement until all computes are new
20:33:46 mriedem if your computes are all upgraded, then we'll try placement and if it's not there, or n-sch isn't configured, we'll fail with NoValidHost
20:33:56 mriedem yeah i'm saying when all computes are good
20:34:07 bauzas so you can possibly run placement *after* n-sch
20:34:09 mriedem but either you (1) haven't deployed placement or (2) haven't configured n-sch for placement and restarted it
20:34:24 bauzas but not aftre you're done with all your computes, that's it
20:34:32 mriedem there was a whole hullabaloo about this in the ML about the order of when placement gets deployed, before or after n-sch
20:34:39 bauzas yeah
20:34:43 bauzas but we're still good
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..

Earlier   Later