Earlier  
Posted Nick Remark
#openstack-nova - 2018-08-08
14:33:39 openstackgerrit Matthew Booth proposed openstack/nova master: fixtures: Fail deleting non-existent attachment in CinderFixtureNewAttachFlow https://review.openstack.org/589900
14:33:47 mdbooth lyarwood: Attempt 2 ^^^
14:34:25 mdbooth Nothing architectural: just a couple of external tests asserting a variable I'd deleted
14:36:24 efried mriedem: o process guru, what do you think about swapping bug numbers here: https://review.openstack.org/#/c/401009/14//COMMIT_MSG@16
14:55:40 mriedem efried: yeah i noticed that as well when i looked at that bug,
14:55:54 mriedem https://review.openstack.org/#/c/447355/ marked it as closing the bug but it didn't really, it should have been partial
14:55:55 efried mriedem: If you agree, I'll flip it and fast approve
14:56:07 efried mriedem: Either that or mark the second bug as a dup
14:56:20 mriedem let me look at what changed since i last +2ed it
14:59:00 melwitt .
15:01:00 mriedem efried: commented
15:01:05 efried ack
15:02:17 openstackgerrit Eric Fried proposed openstack/nova master: Fix host validity check for live-migration https://review.openstack.org/401009
15:02:46 efried mriedem: Done and +A
15:05:57 openstackgerrit Matthew Booth proposed openstack/nova master: fixtures: Track volume attachments within CinderFixtureNewAttachFlow https://review.openstack.org/587013
15:05:58 openstackgerrit Matthew Booth proposed openstack/nova master: fixtures: Fail deleting non-existent attachment in CinderFixtureNewAttachFlow https://review.openstack.org/589900
15:06:07 mdbooth lyarwood: Attempt 3: I feel good about this one
15:11:42 openstack Launchpad bug 1785235 in OpenStack Compute (nova) "metadata retrieval fails when using a global nova-api-metadata service" [Undecided,Incomplete] - Assigned to Liam Young (gnuoy)
15:11:42 melwitt dansmith: there are more updates to this bug from gnuoy, having to do with the redirection api being used https://bugs.launchpad.net/nova/+bug/1785235
15:13:02 dansmith melwitt: okay never heard back from him here that he moved to the non-allinone metadata service
15:13:23 melwitt looking back at the IRC log from 2018-08-03, it looks like you said to run the metadata service with "the regular api server, and just not enable the osapi api if you want to only run metadata"
15:13:56 dansmith right
15:14:14 melwitt it seems like they haven't done that and I don't know how to tell him to do that, like what command and conf to use
15:14:23 gnuoy hi there
15:14:56 gnuoy I have tried moving away from a standalone server and that does work for me.
15:15:21 gnuoy However, I was hoping to get to the bottom of the issue with the standalone service
15:16:00 melwitt I thought we explained why that doesn't work, the database connection and message queue settings are intentionally not sent over RPC
15:16:05 dansmith gnuoy: the standalone service is really just for running on compute nodes in multihost n-net mode, which doesn't make sense for a neutron and multi-cell environment
15:16:21 dansmith which is why I said this is a doc bug if the regular api works for you
15:17:16 gnuoy ok, then thats a misunderstanding on my part. I didn't appreciate the situation was explicit as: not expected to work with neutron and cells
15:17:45 gnuoy in that case I'll update the bug saying that the central api service works for me.
15:17:53 gnuoy sorry for the noise.
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

Earlier   Later