| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-10-24 | |||
| 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 | |
| 13:58:37 | belmoreira | is there any know blocker that I'm missing or this should work then? | |
| 13:58:39 | stephenfin | as we don't store that in a database nor do we send it between services | |
| 13:58:39 | dansmith | belmoreira: cool | |
| 13:58:41 | mriedem | tonyb: what's the status on newton eol? because i think i've got another worthwhile change for newton before eol | |
| 13:59:10 | mriedem | belmoreira: honestly we probably won't know much about cellsv1 issues here as none of us are running it | |
| 13:59:23 | dansmith | stephenfin: if we register it then we really shouldn't be breaking the rules because if someone were to send us a 1.0 version of that we couldn't even deserialize it | |
| 13:59:43 | dansmith | stephenfin: if we feel it's overly onerous to break the rules, then we might as well not even bump the version because we *can't* honor the old one | |
| 13:59:53 | dansmith | overly onerous to *not* break the rules Imean | |
| 14:01:12 | stephenfin | dansmith: Yeah, that makes sense. I guess we might want to revert part of https://review.openstack.org/#/c/508498/ too, in that case | |
| 14:01:27 | belmoreira | mriedem: dansmith: ok. thanks, I will go through these steps and I will let you know this goes | |
| 14:01:34 | stephenfin | (that's the one where I said not to do this versioning against ralonsoh's better instincts :)) | |
| 14:02:05 | dansmith | stephenfin: eesh | |
| 14:03:25 | dansmith | stephenfin: well, it's done now, so maybe just reset the versions to 1.0, admit fault, and try to be clean going forward | |
| 14:03:40 | dansmith | reverting an unsupportable object version isn't particularly helpful either | |
| 14:03:55 | dansmith | we clearly need a little more oversight on those objects I think | |
| 14:04:52 | dansmith | if we start taking those over the REST API we have to be even more squeaky clean than we are with our RPC APIs, since we don't control all the sending and receiving code together | |
| 14:05:10 | stephenfin | dansmith: For my own clarification, do you need to register objects if you do not want to send them over the wire? | |
| 14:06:03 | dansmith | stephenfin: you need to register them in order to receive them through the automatic deserializer, so it knows where to find an object implementation to use to deserialize a primitive | |
| 14:06:10 | sahid | dansmith: we are goin gto start that at a particular version, right? i'm interested to know what is the "someone" who is going to send a version 1.0? | |
| 14:06:28 | dansmith | stephenfin: if you don't need to do that, you still need to build the object, but not register it | |
| 14:07:30 | dansmith | sahid: I understand that there is no code that should be sending the object at the earlier version with that field set right now. That doesn't mean we just make tons of random changes with versions we can't support until some arbitrary point at which we say things are now stable. That version history will confuse people and provide counterexamples they may copy. | |