| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-08-08 | |||
| 14:25:26 | dansmith | mriedem: I just don't think jumping through a bunch of hoops to collect correct info that doesn't matter efficiently is worth it | |
| 14:25:28 | lyarwood | you only need the workaround if you are using DiskFilter etc | |
| 14:25:36 | dansmith | lyarwood: right, that'd be my preference | |
| 14:30:58 | mriedem | +2 on the bottom change | |
| 14:31:11 | mriedem | did s10 say if that fixes the majority of the perf regression? | |
| 14:31:11 | lyarwood | thanks I'll sort this other mess out now | |
| 14:32:13 | lyarwood | mriedem: just brings the time down by 50%, 20 seconds without this, 10 seconds with this, previously 2 seconds. | |
| 14:32:41 | lyarwood | mriedem: so the workaround should get us back to 2 seconds | |
| 14:33:38 | openstackgerrit | Matthew Booth proposed openstack/nova master: fixtures: Track volume attachments within CinderFixtureNewAttachFlow https://review.openstack.org/587013 | |
| 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 | 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: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: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? | |