| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-08-08 | |||
| 17:09:44 | dansmith | wow, zero compute rpc changes in rocky | |
| 17:11:34 | dansmith | and we haven't updated the non-compute aliases in a while | |
| 17:12:34 | openstackgerrit | Dan Smith proposed openstack/nova master: Update compute rpc version alias for rocky https://review.openstack.org/589972 | |
| 17:13:15 | melwitt | are we supposed to update them every release? | |
| 17:13:42 | melwitt | yeah, I see conductor last one was ocata | |
| 17:13:45 | dansmith | well, our docs say that you can use release names in the [upgrade_levels] things, | |
| 17:13:55 | dansmith | but we don't really support anything other than compute being backlevel, so.. | |
| 17:14:05 | melwitt | oh, ok | |
| 17:14:28 | dansmith | also, we have't had rpc bumps in the other services in a long time, | |
| 17:14:48 | dansmith | which also means that once you're a couple versions into the unchanged-ness, there's nothing really needing to be pinned to an old version | |
| 17:14:55 | dansmith | so, all that is to say.. meh I guess? | |
| 17:15:09 | melwitt | hey, it helps me understand it :) | |
| 17:26:29 | melwitt | any major rpc version bumps we want to do? https://wiki.openstack.org/wiki/RpcMajorVersionUpdates | |
| 17:26:44 | melwitt | looking through https://wiki.openstack.org/wiki/Nova/ReleaseChecklist | |
| 17:27:08 | melwitt | "Merge latest translations" what does that mean? | |
| 17:29:02 | dansmith | translation patches which we don't have anymore I think | |
| 17:29:19 | melwitt | ah, ok | |
| 17:29:26 | dansmith | I think we already discussed the major bumps.. I looked around and none seem particularly fruitful at the moment, | |
| 17:29:31 | dansmith | and compute hasn't changed all cycle | |
| 17:30:01 | melwitt | okay, thanks. I must not have connected the dots to this checklist | |
| 17:32:05 | mriedem | the only thing i mentioned to dan earlier (a week or two ago) was scheduler rpcapi, | |
| 17:32:11 | mriedem | there are some "drop in 5.x" stuff in there | |
| 17:32:15 | mriedem | but nothing critical | |
| 17:32:28 | dansmith | yeah, but I looked at it, I don't think it's worth the trouble | |
| 17:33:04 | mriedem | this is also gross https://github.com/openstack/nova/blob/master/nova/scheduler/utils.py#L325 | |
| 17:33:05 | mriedem | but meh | |
| 17:33:24 | mriedem | that code probably dies in stein when i can drop the legacy reqspec compat stuff | |
| 17:33:41 | melwitt | heh | |
| 17:40:39 | openstackgerrit | Merged openstack/nova master: conf: Deprecate 'network_manager' https://review.openstack.org/530923 | |
| 18:00:12 | openstackgerrit | Merged openstack/python-novaclient master: Use uuidutils of oslo.utils https://review.openstack.org/589717 | |
| 18:19:23 | cdent | my stats thank you mriedem | |
| 18:23:35 | openstackgerrit | melanie witt proposed openstack/nova master: Add functional test for affinity with multiple cells https://review.openstack.org/585073 | |
| 18:23:36 | openstackgerrit | melanie witt proposed openstack/nova master: Make scheduler.utils.setup_instance_group query all cells https://review.openstack.org/540258 | |
| 18:28:52 | mriedem | cdent: heh because i approved 2 changes in 2 days? | |
| 18:35:18 | openstackgerrit | melanie witt proposed openstack/nova master: Use TLSv1.2 for secure VNC access https://review.openstack.org/589992 | |
| 18:46:52 | cdent | mriedem: no for assigning that ancient bug t me | |
| 18:47:48 | mriedem | oh heh | |
| 18:47:54 | mriedem | yeah doing some late summer cleaning | |
| 19:08:48 | dansmith | mriedem: melwitt assuming no cells meeting today | |
| 19:09:15 | openstackgerrit | Matt Riedemann proposed openstack/nova master: FakeDriver: adding and removing instances on live migration. https://review.openstack.org/243613 | |
| 19:09:16 | mriedem | i don't think i have any major developments since last week, | |
| 19:09:44 | mriedem | as of yesterday, it sounds like tssurya's handling a down cell spec will need to also account for doing server group calculations where members are in a down cell | |
| 19:09:48 | mriedem | and what we do in that case | |
| 19:10:41 | melwitt | yeah, that. and the multi-cell affinity bug fix of mine is finally ready for review again, I got a decent functional test working with it https://review.openstack.org/540258 | |
| 19:11:03 | dansmith | ack, since FF I've been assuming we'll pick that up after things open up | |
| 19:11:04 | dansmith | melwitt: yeah but not until after rc1 at least right? | |
| 19:11:10 | melwitt | and got rid of the unit test malarkey | |
| 19:11:48 | melwitt | dansmith: yeah. given the timing and the latentness + multi-cell-only nature, wait until after rc1 | |
| 19:13:04 | melwitt | was just bringing it up for celly info | |
| 19:14:00 | mriedem | in cells related news, i pushed up a fix for this over the weekend https://review.openstack.org/#/c/588943/ | |
| 19:14:16 | mriedem | follows the same pattern as cleaning up instance mappings and reqspecs for archived instances | |
| 19:14:59 | dansmith | ah yeah | |
| 19:17:51 | melwitt | for the multi-cell affinity, I could also see it being, wait for stein and backport to rocky, queens, pike. whatever you all think is best | |
| 19:29:38 | mriedem | you already said that was the plan above yeah? | |
| 19:29:51 | mriedem | "yeah. given the timing and the latentness + multi-cell-only nature, wait until after rc1" | |
| 19:30:01 | mriedem | maybe you meant rc2? | |
| 19:30:13 | mriedem | tbc, we generally shouldn't assume/expect an rc2 | |
| 19:30:18 | mriedem | otherwise we failed at rc1 | |
| 19:30:19 | dansmith | I don't think we should do an rc2 for that | |
| 19:30:55 | mriedem | i remember loving explaining how we did rc's upstream to our downstream PMs at ibm since i tried to model the same release process | |
| 19:31:00 | mriedem | "ok so when do we do rc2 and rc3?" | |
| 19:31:09 | mriedem | "we don't, get your fixes into rc1 or don't cut rc1" | |
| 19:31:12 | mriedem | "BUT!!!" | |
| 19:31:25 | dansmith | well, we did have those couple of cycles where we always had an rc2 for translations on the things we got into rc1 | |
| 19:31:44 | mriedem | right, but the PMs at ibm planned for multiple candidates because they knew we had a backlog of bugs | |
| 19:31:48 | mriedem | total waterfall | |
| 19:31:53 | dansmith | heh yeah, and, | |
| 19:32:01 | dansmith | why call it rc1 if there's no rc2 amirite/ | |
| 19:32:10 | mriedem | that's deep | |
| 19:32:21 | dansmith | it's like an outline with one bullet.. no larger sin. | |
| 19:32:24 | melwitt | yeah, sorry, I meant rc2 vs wait until stein, that I was asking of you both | |
| 19:32:38 | mriedem | i'd say stein | |
| 19:32:43 | dansmith | for sure | |
| 19:32:47 | melwitt | k, cool | |
| 19:32:48 | mriedem | make sure there is no immediate regression, | |
| 19:32:49 | mriedem | then backports | |
| 19:32:53 | sean-k-mooney | mriedem: nova is pretty waterfall too in general that said the runways has made nova mor agile this cycle | |
| 19:33:09 | mriedem | hey man | |
| 19:33:10 | melwitt | so what about the placement perf thing? just try to land it for RC1 and not wait for RC2? | |
| 19:33:25 | mriedem | melwitt: my understanding on that is there are 2 fixes | |
| 19:33:41 | mriedem | cdent's is the more important of the two and is already approved | |
| 19:33:50 | melwitt | that's correct. one is approved, other is up for review | |
| 19:33:51 | mriedem | i.e. cdent's drops the perf by 50% | |
| 19:33:57 | mriedem | jay's drops that another 50% | |
| 19:34:14 | sean-k-mooney | dansmith: :) most of intel liked that word but followed water-scurm-fall developemnt instead | |
| 19:34:37 | mriedem | i'm pretty sure my first 10 years at ibm the dev model was really code-and-fix | |
| 19:34:56 | mriedem | the bestest of models | |
| 19:35:35 | mriedem | melwitt: i'll defer to efried and cdent and the placement boyz on how comfortable they are on jay's fix for rc2 | |
| 19:35:39 | sean-k-mooney | mriedem: by drops the perf by 50% do you mean makes it better or worse | |
| 19:35:50 | mriedem | improves perf by 50% | |
| 19:35:58 | sean-k-mooney | :) | |
| 19:36:03 | mriedem | it's the dpdk of patches | |
| 19:36:27 | sean-k-mooney | mriedem: really fast and imposible to debug | |
| 19:36:49 | mriedem | heh that's a pretty good analogy for placement | |
| 19:37:05 | melwitt | mriedem: okay, sounds fair. efried and cdent, let me know what you think of it once you've reviewed | |
| 19:38:19 | openstack | Launchpad bug 1746863 in OpenStack Compute (nova) "scheduler affinity doesn't work with multiple cells" [High,In progress] - Assigned to melanie witt (melwitt) | |
| 19:38:19 | jaypipes | melwitt: re: https://bugs.launchpad.net/nova/+bug/1746863, I thought we'd always said server groups were restricted to a single cell. is that not the case? | |
| 19:38:31 | cdent | melwitt, mriedem : I'm happy to see them both go in | |
| 19:39:14 | melwitt | what is your assessment of the risk of the change somehow making the final release worse? | |
| 19:39:57 | mriedem | jaypipes: it's totally possible to have server group members wind up unintentionally in separate cells | |