| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-03-21 | |||
| 16:08:41 | gibi | efried: yeah it is fixing the renos | |
| 16:08:48 | gibi | efried: so I would wait for that | |
| 16:10:20 | mriedem | the release patch can depends-on the known stuff you want to hold up for and then just adjust the hash when they land | |
| 16:11:34 | efried | don't see a lot of value in the depends-on if the content needs to be updated anyway. Just to stop them from automerging it? | |
| 16:11:44 | mriedem | yup | |
| 16:41:37 | openstackgerrit | Merged openstack/nova master: Fix links to neutron QoS minimum bandwidth doc https://review.openstack.org/645084 | |
| 17:01:00 | mdbooth | Could this be a source of random SSH failures in the gate: https://bugzilla.redhat.com/show_bug.cgi?id=1689933 ? | |
| 17:01:02 | openstack | bugzilla.redhat.com bug 1689933 in openstack-nova "[RFE] Add a simple way to enable random number generator on all flavor/image" [Unspecified,New] - Assigned to nova-maint | |
| 17:04:46 | kashyap | bauzas: mdbooth: efried: When you get a minute, please put this one out of its misery: https://review.openstack.org/#/c/641981/ (libvirt: Use 'writeback' QEMU cache mode when 'none' is not viable) | |
| 17:05:08 | efried | kashyap: did you want that in RC1? | |
| 17:05:09 | bauzas | I'm just wrapping my head with devstack atm | |
| 17:05:22 | efried | Cause that's all we're gonna merge today. | |
| 17:05:24 | kashyap | efried: Would certainly be useful to get some initial testing | |
| 17:05:37 | mdbooth | kashyap: That's a no ;) | |
| 17:05:40 | efried | mriedem: RC1 candidate? | |
| 17:05:41 | kashyap | The sooner the better, as we'd be doing a bit of a disservice to the users | |
| 17:05:51 | kashyap | mdbooth: Hehe | |
| 17:06:38 | mdbooth | I think it's a backport candidate, though. We'll almost certainly take it downstream. It's not a regression, though, and it won't cause dataloss or any kind of error. It's just unnecessarily slow. | |
| 17:06:49 | mdbooth | s/I *don't* think/ | |
| 17:06:58 | mdbooth | Erm, I do think. | |
| 17:08:24 | sean-k-mooney | kashyap: that is not a regression so it normally would not qualify for an rc right? | |
| 17:08:28 | kashyap | mdbooth: Thanks for the review so far! Appreciate it | |
| 17:09:12 | kashyap | sean-k-mooney: Not a regression; but why inflict needless slowness? This patch can (positively) impact all new instances | |
| 17:09:23 | sean-k-mooney | kashyap: im also not sure its technically a bug. it sound more like a specless blueprint. | |
| 17:09:50 | sean-k-mooney | kashyap: well you can just set the config option too | |
| 17:11:05 | sean-k-mooney | anyway this just feels like a feature that is filed as a bug which can be worked around via a config already so im not sure if it qualifes for RC incution but i also dont think you will be breaking anything | |
| 17:11:09 | kashyap | This is fixing existing tech debt. The more it is delayed, the more I lose motivation to fix it. | |
| 17:11:41 | sean-k-mooney | sure but when i looked at this earilar i assume this was targeting train not stien | |
| 17:11:50 | kashyap | sean-k-mooney: Also, Huh? This is not a "specless blueprint". This is actually a misuse/bug. | |
| 17:12:07 | sean-k-mooney | everything working but being slow is not a bug | |
| 17:12:20 | kashyap | sean-k-mooney: True. But I won't cry into my pillow if it doesn't make it to Stein, though | |
| 17:12:50 | kashyap | Just that I'd "strongly suggest" to get this in -- also because the "other patch" (for `qemu-img convert` case) merged. | |
| 17:13:13 | sean-k-mooney | kashyap: didnt that merge before feature freeze | |
| 17:13:14 | kashyap | And it's not nice to have these splatter over two releases. | |
| 17:13:18 | kashyap | sean-k-mooney: Yep | |
| 17:13:38 | kashyap | Frankly, I was just so buried in actually digging the issue, that I lost track of all this time. Most deadlines are arbitrary in my mind. | |
| 17:14:20 | kashyap | (As in, wasn't paying attention whether it was merged before or after RC1) | |
| 17:14:38 | mriedem | efried: i do not think that writeback patch is an rc1 candidate no | |
| 17:14:40 | mriedem | it's extremely latent | |
| 17:14:50 | mriedem | damn it where is jaypipes | |
| 17:14:52 | efried | k, swhat I figured. | |
| 17:15:26 | mriedem | dansmith: edleafe: cdent: i've dumped comments on surya's 'locked_reason' spec - specific feedback on (1) the data model changes and (2) rest api payload format would be appreciated https://review.openstack.org/#/c/638629/ | |
| 17:15:37 | sean-k-mooney | kashyap: once rc1 is cut tonight it can be merged tommorow after the stable/stien branch is cut | |
| 17:15:50 | kashyap | mriedem: Yes, it is latent. | |
| 17:16:06 | sean-k-mooney | the real question is is it backportable | |
| 17:16:19 | cdent | mriedem: thanks queued | |
| 17:16:40 | kashyap | I definitely think it is backport-worthy. See mdbooth's comment earlier | |
| 17:17:19 | sean-k-mooney | kashyap: in which case it can be proposed for backport to stable/stien and the other stable branches | |
| 17:17:30 | kashyap | mriedem_grooming: I don't agree with your emphatic "no". But whatever. I have 1000 other things that need my attention | |
| 17:17:30 | sean-k-mooney | so its not really that much of an issue | |
| 17:17:52 | kashyap | sean-k-mooney: Yep, so it's fine, if it's merged tomm. | |
| 17:18:19 | sean-k-mooney | mdbooth: do you consider qemu vert type to be a bug | |
| 17:18:21 | kashyap | sean-k-mooney: But, I'd prefer it to be in Stein. I didn't "plan" this work. | |
| 17:18:45 | sean-k-mooney | mdbooth: you can say yes :) | |
| 17:18:48 | mdbooth | kashyap: I don't think it's worthy of Stein at this stage. | |
| 17:18:55 | kashyap | mdbooth: Okido... | |
| 17:18:56 | mdbooth | kashyap: Focus on the backport. | |
| 17:19:05 | kashyap | I don't know; I'll focus on dinner first | |
| 17:19:11 | mdbooth | kashyap: Good call :) | |
| 17:19:47 | kashyap | sean-k-mooney: mdbooth: But as noted, The two volume drivers patches should _also_ merge at the same time | |
| 17:19:54 | kashyap | For the "minimum possible doc" to make sense. | |
| 17:24:25 | mriedem_grooming | listen guys, i didn't say it wasn't a bug, i sait it wasn't a regression in stein, it's latent, therefore it doesn't need to be held up for rc1 which is already stressful | |
| 17:24:30 | mriedem_grooming | so we'll deal with backports | |
| 17:24:48 | mriedem_grooming | if people don't like my input on it then don't ask | |
| 17:25:45 | kashyap | mriedem_grooming: Hey, I do like your input very much :-) | |
| 17:26:14 | efried | I was content at :14:52 | |
| 17:26:17 | kashyap | mriedem_grooming: But yep, please go ahead with RC1 stuff (after your grooming) | |
| 17:27:08 | sean-k-mooney | efried: what change ad 14:53 | |
| 17:27:13 | sean-k-mooney | * at | |
| 17:27:52 | kashyap | sean-k-mooney: If I have to guess it's the "not an RC1 candidate" remark :-) | |
| 17:27:57 | efried | :14:52, as in 14 mins 52s after whatever hour you're in (Unless you're in one of those bizarre time zones that's off by a half hour) | |
| 17:28:08 | efried | when I said "k, swhat I figured". | |
| 17:28:36 | sean-k-mooney | oh ha i see | |
| 17:29:01 | efried | which was shorthand for, "I was pretty sure this wasn't a candidate for rc1, but I wasn't positive, so I asked mriedem. He voiced a similar opinion. So that is what we shall go with." | |
| 17:29:35 | bauzas | honestly, not a big deal (again) | |
| 17:29:59 | bauzas | we always cut RC1 after things we wanna wait | |
| 17:30:21 | bauzas | the question is : should the bug we discuss be in the waitlist ? obviously not in my mind, period | |
| 17:30:39 | sean-k-mooney | efried: by the way have you looked at the nova ptg etherpad to see what should be moved to placemetn or nova placement cross project stuff | |
| 17:30:57 | efried | sean-k-mooney: Yes, I did that yesterday, but it will need constant mriedem_groominging | |
| 17:31:30 | efried | could have been Tuesday | |
| 17:31:49 | efried | no, yesterday: http://lists.openstack.org/pipermail/openstack-discuss/2019-March/004030.html | |
| 17:32:07 | sean-k-mooney | efried: i originally adde the resource provider yaml but topic but is that something that anyone is going to pursue in train? | |
| 17:32:33 | efried | sean-k-mooney: IMO that's a straight-up Nova topic, as it doesn't ask for any changes to the placement API. | |
| 17:32:52 | sean-k-mooney | oh sorry yes it is | |
| 17:32:55 | efried | I haven't felt a whole lot of excitement behind that effort, so I haven't been pushing it. | |
| 17:33:03 | efried | but if you're excited, I'll get excited with you. | |
| 17:33:11 | efried | since I proposed the thing | |
| 17:33:13 | sean-k-mooney | i partly context switch and was wondering if there was still a desire to discuss it | |
| 17:34:10 | sean-k-mooney | well i think there is a pain point there but im not sure if that is the solution | |
| 17:34:40 | efried | Had this revelation recently when talking about https://etherpad.openstack.org/p/placement-inter-provider-affinity -- would rather do small, simple, easy-to-understand things that have limited scope and power than try to do a super generic one-size-fits-all thing. | |
| 17:34:50 | efried | and that yaml spec leans much more toward the latter. | |
| 17:35:43 | sean-k-mooney | ok. im going to grab lunch too. | |
| 17:37:06 | bauzas | oh man, I'm getting mad at devstack deployments | |
| 17:37:25 | sean-k-mooney | bauzas: something specificlly? | |
| 17:39:04 | bauzas | neutron fails to install | |
| 17:39:10 | bauzas | but meh, I'll fix it | |
| 17:39:17 | sean-k-mooney | ah ok | |
| 17:40:38 | bauzas | yeah, it's a reqs thing | |
| 17:41:43 | bauzas | let's go for a RECLONE=yes | |
| 17:45:01 | NobodyCam | fyi incase anyone ever runs in to this again: issue was bad rabbit ip in nova_api/cell_mappings.transport_url | |