| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-10-24 | |||
| 13:33:10 | dansmith | if he's going to switch in pike, then that should be okay | |
| 13:33:20 | mriedem | because scheduler in cell1 could pick a compute node in cell2? | |
| 13:33:26 | bauzas | dansmith: wait | |
| 13:33:33 | dansmith | wait, ocata did placement-based selection actually didn't it? | |
| 13:33:36 | dansmith | just no claims | |
| 13:33:40 | mriedem | correct | |
| 13:33:47 | dansmith | right, damn, I forgot about that | |
| 13:33:50 | bauzas | dansmith: if he still runs cells-scheduler (v1), he will end up in a nova_api service which is a single cell | |
| 13:33:55 | mriedem | belmoreira: you're using the FilterScheduler in the child cells right? | |
| 13:34:16 | belmoreira | mriedem: yes | |
| 13:34:25 | bauzas | dansmith: so, maybe I see where he's going, multiple placement APIs, each of them per cellv1 ? | |
| 13:34:31 | dansmith | bauzas: right | |
| 13:34:46 | belmoreira | bauzas: That's my point | |
| 13:34:49 | bauzas | that would be the easiest I feel | |
| 13:35:10 | dansmith | so if he has a global placement, ocata scheduler will get back hosts from all cells, and then try to do a ComputeNode lookup of those in the cell and only find some of them | |
| 13:35:36 | bauzas | sure, that won't work, hence placement per cell | |
| 13:35:43 | mriedem | it will work, | |
| 13:35:43 | bauzas | sorry about the original confusion | |
| 13:35:47 | mriedem | because as dan just said, | |
| 13:35:52 | dansmith | it'll be massively inefficient though | |
| 13:35:55 | mriedem | the db is only going to return compute nodes with uuids in some list | |
| 13:36:12 | bauzas | ah yeah correct, we lookup per cell | |
| 13:36:56 | dansmith | belmoreira: what is your preference? would you rather some inefficiencies for a while to keep a global placement so you can easily switch, | |
| 13:37:07 | dansmith | or would you prefer separate placements and avoid committing right away, | |
| 13:37:13 | dansmith | then merge those data sets later with some downtime? | |
| 13:38:02 | belmoreira | dansmith: yes that is my preference | |
| 13:38:13 | dansmith | belmoreira: which? :) | |
| 13:38:38 | belmoreira | sorry "would you prefer separate placements and avoid committing right away" :) | |
| 13:38:46 | mriedem | also note that the filter scheduler in ocata won't use placement until all of the computes are upgraded to ocata https://docs.openstack.org/nova/pike/user/placement.html#ocata-15-0-0 | |
| 13:39:16 | dansmith | belmoreira: okay, so that should work | |
| 13:39:22 | mriedem | heh, see the last bullet there ^ | |
| 13:39:23 | mriedem | "Users of CellsV1 will need to deploy a placement per cell, matching the scope and cardinality of the regular nova-scheduler process." | |
| 13:39:32 | mriedem | apparently we already thought about this | |
| 13:39:34 | dansmith | yeah, I think I wrote that, | |
| 13:39:38 | dansmith | assuming they would | |
| 13:40:16 | belmoreira | my plan is to have a placement per cell which will require a nova_api + keystone per cell | |
| 13:40:30 | mriedem | why keystone? | |
| 13:40:42 | mriedem | nova_api i understand now because that has the placement schema in it | |
| 13:40:50 | dansmith | oh, is it because of catalog lookups of placement? | |
| 13:41:08 | belmoreira | because we only have auth_url and then is the endpoint discovery | |
| 13:41:20 | belmoreira | can I do this in a different way? | |
| 13:41:28 | mriedem | belmoreira: is cinder per-cell? | |
| 13:41:30 | mriedem | or global? | |
| 13:41:34 | dansmith | is there some way in keystone to override the endpoints that a user sees? | |
| 13:41:37 | belmoreira | cinder is global | |
| 13:41:39 | mriedem | or is cinder per cell but you use the endpoint_override option? | |
| 13:41:40 | mriedem | oh | |
| 13:42:16 | belmoreira | all the services that we have are global | |
| 13:42:53 | dansmith | belmoreira: I would check with keystone people to see if there's a way you can avoid having to deploy a new keystone everywhere | |
| 13:42:57 | belmoreira | dansmith: good point... maybe I can do something with endpoint filtering | |
| 13:43:09 | dansmith | also, you could do some DNS hackery to make the same url be "different" for each cell | |
| 13:43:18 | dansmith | if keystone can't help | |
| 13:43:58 | mriedem | could you do a placement endpoint per region and make a region per cell? | |
| 13:44:47 | mriedem | but just for the placement service | |
| 13:45:11 | belmoreira | mriedem: I see your point. That may work. thanks | |
| 13:45:21 | mriedem | so everything talks to cinder/neutron/glance on RegionOne, | |
| 13:45:30 | mriedem | and nova-compute in cell1 talks to PlacementRegionCell1 or something | |
| 13:46:10 | dansmith | yeah | |
| 13:46:18 | belmoreira | mriedem: makes sense. That may be the easiest solution. thanks | |
| 13:46:26 | dansmith | belmoreira: basically we're saying, we hope you don't have to deploy more keystone ;P | |
| 13:46:40 | belmoreira | :) | |
| 13:46:41 | sdague | mriedem: yeh, let me figure out why the tests aren't passing | |
| 13:46:54 | mriedem | sdague: one was cellsv1 random failure as usual, | |
| 13:47:01 | mriedem | other was zuulv3 reno job | |
| 13:47:04 | mriedem | but logs are gone | |
| 13:47:18 | mriedem | belmoreira: and i hope you're taking notes so you can post a blog on all of this when it's done | |
| 13:47:23 | mriedem | that would be awesome | |
| 13:47:58 | sdague | mriedem: ok, I just rechecked on pike, once that is in, I'll approve ocata, just don't want them to go in in the wrong order | |
| 13:48:14 | mriedem | yup, thanks | |
| 13:48:16 | belmoreira | yeah. are you aware of any cellV1 to V2 migration already? | |
| 13:48:33 | mriedem | belmoreira: i haven't heard of any | |
| 13:48:47 | mriedem | spamaps at godaddy said they were talking about just standing up a new pike cells v2 deployment | |
| 13:48:48 | mriedem | rather than migrate | |
| 13:49:19 | belmoreira | lucky ones | |
| 13:49:20 | dansmith | not sure that's because migration is hard so much as a chance to start fresh? | |
| 13:49:36 | mriedem | he mentioned while talking about their normal upgrade pain of carrying patches forward | |
| 13:49:43 | mriedem | so it could just be a chance to start fresh yeah | |
| 13:49:48 | sdague | stephenfin: https://review.openstack.org/#/c/495541 would land another 3 privsep patches | |
| 13:50:16 | mriedem | i haven't heard from nectar | |
| 13:50:18 | mriedem | but never really do | |
| 13:50:24 | mriedem | mgagne: you're cellsv1 aren't you? | |
| 13:51:29 | belmoreira | also, in newton there's the placement_database group in the configuration. And it's advised to use it. I don't see any reference of it now in master | |
| 13:51:32 | stephenfin | sdague: done and done | |
| 13:51:46 | mriedem | belmoreira: that's a mistake, don't use that | |
| 13:52:10 | mriedem | i thought we cleaned that all out actually | |
| 13:52:53 | mriedem | ah we didn't revert that from newton https://github.com/openstack/nova/commit/1b5f9f8203c90fe447d33c89f238104026052d1e | |
| 13:52:59 | stephenfin | sdague: Regarding https://review.openstack.org/#/c/500354/, any reason you think we were using 'discard_warnings' before? | |
| 13:53:18 | stephenfin | i.e. what's the chances we'd regress on something by dropping it | |
| 13:53:42 | mriedem | newton isn't eol yet, i could still revert that before eol... | |
| 13:54:10 | mriedem | yeah we removed in ocata https://review.openstack.org/#/c/442762/ | |
| 13:54:16 | belmoreira | mriedem: ok | |
| 13:55:38 | mriedem | this was the revert https://review.openstack.org/#/c/360638/ | |
| 13:55:58 | mriedem | ah yeah so the revert removed the reno and code, but missed the config options, | |
| 13:56:04 | mriedem | which is what my change removed | |
| 13:56:12 | mriedem | so we should consider backporting that too newton also before the eol | |
| 13:57:42 | stephenfin | dansmith: Got a sec to discuss https://review.openstack.org/#/c/509107/ ? | |
| 13:57:47 | belmoreira | thanks for all the suggestions | |
| 13:58:06 | belmoreira | after moving to Ocata with this configuration (means that I still keep cellsV1 schedule behaviour) then for Pike the plan is to remove all these placements and move the existing cellsV1 to cellsV2 (point everything to the global nova_api and do the mappings) | |
| 13:58:15 | dansmith | stephenfin: yup | |
| 13:58:20 | stephenfin | I was the one that actually told ralonsoh to drop the versioning code in a dependent patch because I didn't think it was necessary | |