| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-08-08 | |||
| 16:15:56 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Add the guideline to write API reference https://review.openstack.org/569058 | |
| 16:16:00 | gibi | mriedem: besides that we communicate the deprecation and help answering questions | |
| 16:16:01 | mriedem | we probably won't | |
| 16:16:10 | mriedem | searchlight is in maintenance mode | |
| 16:16:16 | mriedem | designate has like 2 active contributors | |
| 16:16:22 | mriedem | telemetry is in the same boat? | |
| 16:16:26 | mriedem | not sure about mistral | |
| 16:16:54 | mriedem | there are likely other projects consuming nova's notifications that i'm not thinking of, maybe blazar and masakari? | |
| 16:17:26 | mriedem | i wonder if we could write some kind of conversion middleware | |
| 16:17:28 | gibi | maybe watcher too but yeah | |
| 16:17:31 | melwitt | have we sent a dev ML mail before about it? to find out who might be interested in switching over? | |
| 16:17:36 | mriedem | for projects as a crutch until they can consume versioned notifications natively | |
| 16:17:52 | mriedem | gibi had an etherpad at one point | |
| 16:18:04 | mriedem | no other project has talked about switching over as far as i know, | |
| 16:18:15 | mriedem | because as noted, they are short-staffed projects and doing that switch would be very low priority for them | |
| 16:18:30 | melwitt | yeah. I wasn't sure if they knew about the new stuff or not | |
| 16:18:44 | gibi | melwitt: there was couple of mails on the ML about the fact that we are woring on such transformation and I got positive response from telemetery at least | |
| 16:19:06 | melwitt | a-ha, cool | |
| 16:20:27 | gibi | melwitt: but I'm totally agree to repeate the mail about the new interface, asking for current willingness to transform | |
| 16:21:27 | melwitt | gibi: yeah, I know you've been sending the regular mails about notification work but I wasn't sure how much that translated to other projects realizing there are new features available that they might be interested in using. just a thought | |
| 16:22:33 | gibi | melwitt: yeah. So I can write a mail to the bigger audience (even tagging the project mriedem listed about in the subject) about the current state of the work and asking them about the willingnes to transition to the new interface | |
| 16:22:48 | melwitt | might be moot since as was said, the projects we can think of that consume notifications are really short-staffed at this point. other than maybe telemetry | |
| 16:23:42 | melwitt | gibi: cool, might be worth a shot | |
| 16:24:01 | gibi | melwitt: I made a note on my desk, I will do the mail tomorrow. | |
| 16:24:20 | melwitt | k | |
| 16:31:20 | melwitt | mriedem: should I close out the notifications and mox blueprints now? when do you usually close them? | |
| 16:39:55 | mriedem | at FF | |
| 16:41:44 | melwitt | ok | |
| 16:45:39 | melwitt | versioned notifications bp from queens was closed at RC1, so I was following that https://blueprints.launchpad.net/nova/queens | |
| 16:45:44 | melwitt | next time I'll do FF | |
| 16:47:27 | melwitt | mox and versioned notifications bps are now closed for rocky | |
| 17:07:56 | melwitt | dansmith: I think we're a go for the RPC version aliases since we're not anticipating a RC2 | |
| 17:08:14 | dansmith | alright | |
| 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, | |