Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-11-25
16:58:17 stephenfin lyarwood, mriedem: looks like we do funky stuff in nova/volume/cinder.py via '_untranslate_volume_summary_view'
16:58:19 mriedem ah
16:58:20 stephenfin nice
17:05:13 openstackgerrit Merged openstack/nova master: api-guide: flesh out flavor extra specs and image properties https://review.opendev.org/695776
17:05:19 openstackgerrit Merged openstack/nova master: api-guide: flesh out networking concepts https://review.opendev.org/695777
17:05:25 openstackgerrit Merged openstack/nova master: api-guide: flesh out todos in user doc https://review.opendev.org/695778
17:06:08 mriedem lyarwood: some questions in there
17:06:44 lyarwood mriedem: looking
17:07:24 mriedem so volume_type on volume create is optional and if not specified the cinder scheduler picks one (and there is a default backend),
17:07:44 mriedem the api-ref talks a bit about when volume_type is required but doesn't mention for encrypted volumes built from snapshots, which volume_type is clearly required due to the bug
17:08:05 mriedem i'm just wondering if we should only pass the volume_type if the original volume was encrypted=True
17:09:16 mriedem i might have answered my own question though,
17:09:25 mriedem i don't think you can delete a volume type in cinder while there are volumes using it,
17:09:32 mriedem and i don't think you can delete a volume that has snapshots
17:09:34 mriedem smcginnis: ^?
17:09:34 lyarwood yeah you can't I was just checking that
17:09:49 lyarwood and again yes AFAIK you can't remove volumes with snapshots
17:10:09 lyarwood so copying over volume_type from the original if one isn't provided should be safe
17:10:17 mriedem so maybe this is fine and if it turns out there is some weird problem later we fix that as necessary
17:10:45 mriedem i'm guessing you'll want to backport this too so hopefully we're all good
17:11:51 lyarwood yup indeed, I tried to keep it as self contained as possible
17:18:03 smcginnis mriedem: Correct.
17:18:16 smcginnis Don't have the full context here, but the plan described sounds good to me.
17:30:18 openstackgerrit Ghanshyam Mann proposed openstack/nova master: Add test coverage of existing os-services policies https://review.opendev.org/669181
17:32:33 openstackgerrit Merged openstack/nova stable/stein: Use admin neutron client to see if instance has qos ports https://review.opendev.org/694668
17:40:44 mriedem stephenfin: you should fix this in your series somewhere https://review.opendev.org/#/c/686816/12/doc/source/install/get-started-compute.rst@28
17:45:37 openstackgerrit Ghanshyam Mann proposed openstack/nova master: Introduce scope_types in os-services https://review.opendev.org/645427
17:52:05 gmann johnthetubaguy: did not get this comment. we can re-use the check_str itself - https://review.opendev.org/#/c/645452/14/nova/policies/base.py@69
17:53:34 johnthetubaguy gmann: the use case I was thinking about is having a nova specific read only role, its nice if that only needs one rule changing
17:57:39 openstackgerrit John Garbutt proposed openstack/nova master: WIP: Enforce unified limits using oslo.limit https://review.opendev.org/615180
17:59:39 gmann johnthetubaguy: and the currently defined check_str like SYSTEM_READER use those rule instead of direct check_str ?
18:04:18 gmann johnthetubaguy: got it. i did not think the override case.
18:05:09 johnthetubaguy gmann: no worries, we could in theory add it later, but probably good to add it from the start
18:05:52 gmann yeah.
18:29:18 openstackgerrit Ghanshyam Mann proposed openstack/nova master: Add new default rules and mapping in policy base class https://review.opendev.org/645452
18:43:23 openstackgerrit Ghanshyam Mann proposed openstack/nova master: Suppress policy deprecated warnings in tests https://review.opendev.org/676670
19:00:41 gmann johnthetubaguy: for new policy rule added due to granularity, new name should be fine right? we decided not to change name for any existing policy - https://review.opendev.org/#/c/648480/18/nova/policies/services.py@22
19:07:38 efried kashyap: Forgive me if you've already had this argument^Wdiscussion with stephenfin, but why are we not squashing at least the three "remove MIN_*" patches into the bump patch?
19:08:23 efried to me, "do X and get rid of dead code that was made obsolete by X" counts as "one logical change".
19:10:23 efried "I did it separately as it cleanly highlights that we consciously picked those versions based on distro research. If we squash it in, the intention just gets buried in this noise." meh meh meh
19:17:10 openstackgerrit Lee Yarwood proposed openstack/nova master: compute: Remove stale BDMs on reserve_block_device_name failure https://review.opendev.org/682594
19:50:22 openstackgerrit Merged openstack/nova stable/queens: Don't delete compute node, when deleting service other than nova-compute https://review.opendev.org/695383
19:50:28 openstackgerrit Merged openstack/nova stable/rocky: Add functional regression test for bug 1849409 https://review.opendev.org/690720
19:50:28 openstack bug 1849409 in OpenStack Compute (nova) rocky "openstack server list --deleted --limit -1 hangs" [High,In progress] https://launchpad.net/bugs/1849409 - Assigned to Matt Riedemann (mriedem)
20:33:03 dansmith artom: when I pay you to just agree with all my review comments, you're supposed to make it look non-obvious
20:37:41 artom dansmith, ok, 0. You don't pay nearly enough. 1. I only agreed on one thing. 2. I disagreed on the big thing.
20:38:42 dansmith artom: each comment was like "I agree with Dan and his bribe money, ...." :P
20:39:20 artom dansmith, either I misunderstood you, or you misunderstood me.
20:39:42 artom I thought you were saying you don't want the workaround conf option approach. I'm saying the "real" fix isn't backportable, so OK.
20:51:58 dansmith artom: no, I know
20:54:52 artom dansmith, but seriously, "subtlety" is only available in the Premium package, you need to upgrade
20:55:56 dansmith I'm calling my credit card company
20:56:58 artom *snerk*
20:57:07 artom "I'd like to charge back these bribes I made"
20:57:29 artom "Turns out corruption isn't the panacea I was hoping for."
21:00:26 dansmith sounds legit to me, I'm sure they've got my back
21:00:43 dansmith just like reporting that your dealer to the cops when he stiffed you on the dime bag
21:17:25 artom Hey man, get with the advanced countries, my dealer's *the government*
21:22:40 mriedem artom: dansmith: i've tl;dr'ed the patch, i need someone to ack on the path forward because i'm getting mixed messages on the nova changes and the os-traits change from efried
21:22:58 mriedem if it's more work than it's worth i'll just abandon all of it and let the bugs continue to get opened
21:24:00 efried what are we talking about?
21:24:48 artom mriedem, I obviously don't have +/-2 powers, but seems like a simple enough patch, so if it fixes some people's issues, don't see why not
21:25:04 artom Sure, it's not the prettiest thing I've ever seen, but... frankly, neither is most of Nova :P
21:27:12 mriedem efried: https://review.opendev.org/#/q/topic:bug/1748697+(status:open+OR+status:merged)
21:28:17 mriedem artom: as for pretty, you try having hundreds (thousands?) of random people put their dirty fingers all over you for 10 years and see how pretty you are
21:29:04 artom mriedem, oh, I fully understand *why*
21:29:17 mriedem (apparently 989 contributors according to github)
21:30:53 mriedem i've long advocated for py black pre-commit hooks but just no one else wants it :)
21:40:35 artom Oh this is weird...
21:40:48 artom I'm triaging a downstream bug related to external events
21:41:07 openstackgerrit Matt Riedemann proposed openstack/nova stable/queens: Add functional regression test for bug 1849409 https://review.opendev.org/690724
21:41:07 openstack bug 1849409 in OpenStack Compute (nova) rocky "openstack server list --deleted --limit -1 hangs" [High,In progress] https://launchpad.net/bugs/1849409 - Assigned to Matt Riedemann (mriedem)
21:41:07 openstackgerrit Matt Riedemann proposed openstack/nova stable/queens: Fix listing deleted servers with a marker https://review.opendev.org/690725
21:41:25 artom 17:34:14.868 No waiting events found dispatching network-vif-plugged-3dccb72d-c922-4032-8f34-d7421fe2cff6
21:41:34 openstackgerrit Dan Smith proposed openstack/nova master: Add a way to exit early from a wait_for_instance_event() https://review.opendev.org/695985
21:41:36 dansmith efried: ^
21:41:40 artom 17:33:48.037
21:41:42 efried dansmith: ack
21:41:49 artom 17:33:48.037 Preparing to wait for external event network-vif-plugged-3dccb72d-c922-4032-8f34-d7421fe2cff6
21:42:10 artom So I guess something is consuming those events before?
21:42:15 artom Sorry for rubber-ducking y'all
21:43:00 dansmith artom: mriedem: remember the race-to-wait-for-event stuff with neutron and migration?
21:43:13 dansmith the patch I just pushed up would probably have helped us
21:43:13 mriedem how could i forget
21:43:15 artom dansmith, I do, but this isn't it. It's boot.
21:43:31 dansmith artom: yep, talking about that other thing
21:43:38 artom dansmith, ack, yeah
21:43:41 artom Looking
21:43:43 dansmith lots of event'n going on today
21:46:07 dansmith I don't remember the exact details of the neutron thing, but if we could have checked with one poll to see if a thing was done, we could have used this to safely be graceful about when the events show up and not lose our race-proof-ness
21:46:56 dansmith I think it was coming early for some backends, which is what this is about
21:47:00 artom dansmith, I haven't grokked your patch fully, but I'm not sure about that. We were getting the events *before* we even started waiting for them
21:47:08 dansmith right, that's what this is for
21:47:35 dansmith we're about to have a situation where for cyborg, an event could come before we're ready to wait for it
21:47:52 dansmith and we want to be able to handle that good situation (work is done before we have to stop and wait) without losing our race-proof-ness
21:51:18 artom Oh, that's your second para in the commit message
21:51:29 mriedem artom: we were getting them before we were waiting b/c the compute manager updating the port binding which trigggered the event before the driver's finish_revert_migration or whatever registered the event listener
21:51:52 mriedem so, we do control what was triggering the event
21:52:20 artom mriedem, yep
21:52:37 dansmith mriedem: I thought there was some component of it where we weren't use based on vif type if it came early or late? but maybe I'm remembering one of the reverted attempts?

Earlier   Later