| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-02-01 | |||
| 19:59:26 | mriedem | dansmith: is 0 positive? | |
| 19:59:37 | mriedem | dansmith: or did you not want to distinguish between <0 for the periodic? | |
| 19:59:40 | mriedem | since 0 will make it run | |
| 19:59:48 | dansmith | mriedem: zero is positive | |
| 20:01:11 | mriedem | sfinucan: https://review.openstack.org/#/c/426826/7 | |
| 20:01:18 | mriedem | sfinucan: latest adds a release note | |
| 20:03:08 | mriedem | dansmith: if you have butterflies about that nova-status + grenade thing, then https://review.openstack.org/#/c/427499/ is up your alley | |
| 20:03:29 | mriedem | https://review.openstack.org/#/c/426926/ was the grenade change testing it | |
| 20:10:10 | openstackgerrit | Matt Riedemann proposed openstack/nova: doc: refer to the cell_v2 man pages from the cells v2 doc https://review.openstack.org/427459 | |
| 20:10:10 | openstackgerrit | Matt Riedemann proposed openstack/nova: doc: add some detail to the map_cell0 man page https://review.openstack.org/427450 | |
| 20:10:11 | openstackgerrit | Matt Riedemann proposed openstack/nova: doc: update the man page entry for nova-manage db sync https://review.openstack.org/427460 | |
| 20:10:52 | ildikov | mriedem: sdague: thanks, I added the patch and a note to the etherpad | |
| 20:21:19 | artom | http://logs.openstack.org/59/424759/12/gate/gate-nova-releasenotes/d0bf975/console.html#_2017-02-01_19_58_38_712633 | |
| 20:21:21 | artom | *stab* | |
| 20:21:30 | artom | *stab stab stab stab* | |
| 20:21:51 | artom | (Unrelated to any important currently ongoing issues) | |
| 20:22:15 | mriedem | artom: oh that sucks | |
| 20:22:17 | mriedem | 3 in the gate | |
| 20:23:32 | artom | The gate is Kanye'ing me | |
| 20:23:53 | artom | "Your patch is nice and imma let in finish - but this guy - this guy has the best patch of all time!" | |
| 20:25:17 | openstackgerrit | Dan Smith proposed openstack/nova: Allow scheduler to run cell host discovery periodically https://review.openstack.org/426826 | |
| 20:25:18 | openstackgerrit | Dan Smith proposed openstack/nova: Add ComputeNode.mapped field https://review.openstack.org/427901 | |
| 20:25:18 | openstackgerrit | Dan Smith proposed openstack/nova: Reserve migration placeholders for Ocata backports https://review.openstack.org/427900 | |
| 20:25:19 | openstackgerrit | Dan Smith proposed openstack/nova: Make discover_hosts only query for unmapped ComputeNode records https://review.openstack.org/427903 | |
| 20:25:19 | openstackgerrit | Dan Smith proposed openstack/nova: Add ability to query for ComputeNodes by their mapped value https://review.openstack.org/427902 | |
| 20:26:06 | mriedem | bauzas: replied to your comments in https://review.openstack.org/#/c/427367/ but i didn't see anything that i needed to change | |
| 20:26:13 | mriedem | i might be misunderstanding your points though | |
| 20:26:23 | dansmith | mriedem: ^ is what I'm thinking, sans any tests or testing | |
| 20:26:43 | mriedem | tests i can do without, but not testing | |
| 20:26:44 | mriedem | :) | |
| 20:27:08 | dansmith | yeah, well, eventually, I just wanted it out there | |
| 20:27:21 | dansmith | in case I stab a fork in my eye between now and pike | |
| 20:27:22 | dansmith | also, the migration backports are in that stack | |
| 20:27:27 | dansmith | placeholders I mean | |
| 20:27:34 | bauzas | mriedem: sorry, I meant in https://review.openstack.org/#/c/427367/2/doc/source/placement.rst@175 that a scheduler hard failure could also happen once you upgrade all your computes, not only in Pike | |
| 20:28:14 | mriedem | bauzas: oh i see | |
| 20:29:09 | bauzas | mriedem: and about the bullet good place, I meant that since operators need to modify their nova.conf for adding the placement section, it could be nice to let them know quite close that they also need to update ratios | |
| 20:29:17 | bauzas | but that's a nit | |
| 20:29:23 | mriedem | bauzas: even if n-sch can't talk to placement after you've upgraded your computes, | |
| 20:29:35 | mriedem | we'll fallback to querying the compute_nodes table | |
| 20:29:42 | mriedem | so it's not the same kind of hard failure | |
| 20:29:44 | bauzas | mriedem: not exactly | |
| 20:30:01 | bauzas | mriedem: because if you don't update the n-sch nova.conf, then it would return NoValidHosts | |
| 20:30:02 | mriedem | none of the compute services would be running, which would be a different kind of failure | |
| 20:30:25 | openstack | johnsom: Error: Could not gather data from Launchpad for bug #1661086 (https://launchpad.net/bugs/1661086). The error has been logged | |
| 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 | |