Earlier  
Posted Nick Remark
#openstack-nova - 2018-08-08
15:48:44 efried kosamara: Okay, nice, thank you. I'll get to them this afternoon.
16:07:18 mriedem melwitt: were you planning on closing out https://blueprints.launchpad.net/nova/+spec/versioned-notification-transformation-rocky since we're past FF?
16:07:27 mriedem i assumed we'd close that out and pick up with a stein bp
16:07:45 gibi mriedem, melwitt: I agree. I can create a new bp for stein
16:08:25 melwitt mriedem: I was planning to close them tomorrow on RC day. are they supposed to be closed sooner than that usually?
16:08:35 melwitt the notification one and the mox one
16:08:53 dansmith melwitt: did you see my comment about rpc aliases on the rc1 pad?
16:09:40 melwitt dansmith: I saw a comment yes, saying rc2 if we have one, else just before rc1
16:09:47 dansmith yup
16:10:06 melwitt I don't think we're anticipating a rc2, are we mriedem?
16:11:25 dansmith in the past we had an obligatory rc2 for translations or something, but not sure that happens anymore
16:11:27 dansmith which is why I said that
16:11:35 melwitt oh, I see
16:11:52 melwitt I didn't know about that
16:12:18 mriedem we shouldn't have an rc2 unless something gets reported as a major regression at the last minute
16:12:52 mriedem things have actually been too quiet compared to what kind of stuff we'd had between FF and RC1 in previous relases (like ocata and pike)
16:13:11 mriedem gibi: i added an item to the ptg etherpad about legacy notification deprecation
16:13:42 gibi mriedem: thanks. I thought about that too as we have a good chance to finish the transformation in Stein
16:14:04 mriedem unfortunately getting the projects consuming nova's notifications switched over to versioned would likely rest on our shoulders
16:15:02 gibi mriedem: yeah, I understand. I don't know how will we have time for such work
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

Earlier   Later