Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-08-08
15:18:05 dansmith no problem, glad to hear that it works as we expect though :)
15:21:35 openstackgerrit Takashi NATSUME proposed openstack/nova master: [placement] api-ref: add description for 1.29 https://review.openstack.org/589407
15:29:23 openstackgerrit Chris Dent proposed openstack/nova master: [placement] Avoid rp.get_by_uuid in allocation_candidates https://review.openstack.org/589941
15:35:26 openstackgerrit Liam Young proposed openstack/nova master: Remove Neutron MetaAPIProxy from cellsv2-layout https://review.openstack.org/588525
15:35:40 openstackgerrit Sergii Golovatiuk proposed openstack/nova master: libvirt: Always escape IPv6 addresses when used in migration URI https://review.openstack.org/589548
15:36:58 gnuoy dansmith, melwitt, fwiw I've had a go at updating the nova metadata verbage https://review.openstack.org/588525
15:39:21 melwitt cool, thanks
15:42:27 openstackgerrit Jay Pipes proposed openstack/nova master: get provider IDs once when building summaries https://review.openstack.org/589945
15:43:45 kosamara efried: Since yaml seems a better way forward, the spec I would propose would include most of the points of your spec. The larger differences I see so far mostly amount to device discovery and no auto-generated traits (following jaypipes' comment). Also, I would focus on generating the RPs and split the interactions with instances to a follow-up spec.
15:45:42 efried kosamara: Sounds good to me. As you're doing your writeup, it would be nice if you're careful to distinguish the responsibilities of the virt driver versus the compute manager. So for instance, the decision about whether to generate traits could/should (IMO) be left up to the individual driver.
15:46:23 mdbooth Is zuul grumpy about something?
15:46:37 mdbooth "Tenant openstack isn't ready"
15:48:21 kosamara efried: OK. Thanks! I also left you some questions on your spec.
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?

Earlier   Later