Earlier  
Posted Nick Remark
#openstack-nova - 2018-02-21
15:34:21 mriedem the actual demo itself isn't hard to run through
15:34:54 mriedem anyway, this will be my day now..
15:35:43 sean-k-mooney mnaser: so ya back to the force cold migration i agree if the schduler elminated the node it should not be ignored or bad things can happen. the use case was for maintenance however so i dont know why you could not disable the host you wanted to do mantenance on then just migrate there instance to any other nodes
15:35:53 mnaser mriedem: ^ :)
15:36:00 mnaser that's probably for ya
15:39:05 sean-k-mooney mnaser: hehe ya sorry
15:39:48 sean-k-mooney i asked the question in the spec. but i dont think there is a good answer/justificaiton for why you should bypass the schduler.
15:44:46 mriedem dansmith: one nit on that patch, let's throw the volume_id into the warning message, then i'm +2
15:46:06 openstackgerrit Mohammed Naser proposed openstack/nova master: Ensure attachment_id always exists for block device mapping https://review.openstack.org/546398
15:47:37 mnaser there.. that should be it .. for now :>
15:47:37 openstackgerrit Dan Smith proposed openstack/nova master: Avoid exploding if guest refuses to detach a volume https://review.openstack.org/546423
15:47:40 dansmith mriedem: ^
15:51:28 cfriesen mriedem: given your comment about the force flag for evacuate and live migrate...do we want to deprecate that? :) Or is that just a case of it being stuck with it since we'll have to keep the code around until/unless we bump the minimum API version?
15:56:02 mriedem mnaser: ok +2 on that, with some musing comments in there for order of fixes
15:56:17 mriedem cfriesen: the latter
16:00:12 mnaser mriedem: cool, thanks, once this merges ill reorder to get this fix in stable/pike just before yours so functional tests pass for all patches :>
16:03:17 mriedem mnaser: sounds good, and that also takes care of my 'window of failure' worry in there
16:03:48 mnaser mriedem: oh you're right
16:05:47 mriedem so yeah we likely want your fix here before my fix in the series of backports
16:05:54 openstackgerrit Bence Romsics proposed openstack/osc-placement master: WIP skip (v1.13) https://review.openstack.org/546674
16:05:55 openstackgerrit Bence Romsics proposed openstack/osc-placement master: Add nested resource providers (v1.14) https://review.openstack.org/546675
16:21:41 openstackgerrit Surya Seetharaman proposed openstack/nova-specs master: Support disabling a cell https://review.openstack.org/546684
16:36:59 efried_omalley Eric Fried proposed openstack-infra/project-config master: Regex gerritbot notifications: #openstack-nova https://review.openstack.org/546689
16:37:15 mriedem ildikov: think i resolved my audio problems
16:37:34 ildikov mriedem: \o/ :)
16:37:48 ildikov mriedem: I saw your mail, but couldn't get there yet to answer
16:38:18 ildikov I wasn't sure whether that's the mic or the tool that you're using that messed the audio up
16:38:27 mriedem it's the tool,
16:38:35 mriedem i think i used the wrong compression settings
16:38:55 ildikov it really would've been perfect if that's ok... :/
16:39:04 mriedem oh i know
16:39:18 ildikov ;)
16:39:37 ildikov compression settings make sense
16:39:38 mriedem i also realized it chopped of the left side of the screen where some of the command output is, which is not real useful in a demo
16:39:42 mriedem *off
16:40:45 ildikov oh; ok, I admit, I listened to the whole thing, but didn't always watch...
16:42:59 openstackgerrit Eric Berglund proposed openstack/nova master: Add check for redundant import aliases https://review.openstack.org/543995
16:52:23 jaypipes doude: finally reviewed that patch. +2 from me, but question for you on there.
16:52:42 cfriesen has anyone ever seen a problem detaching a volume when shutting down an instance that results in a virDomainDetachDeviceFlags() failure with 'libvirtError: invalid argument: no target device vdd\n'
16:53:02 doude ok jaypipes, thanks for your review. I'll try to answer your question
17:02:01 jaypipes mriedem, dansmith, bauzas, melwitt: are we ready to pull the trigger on efried_omalley's https://review.openstack.org/#/c/540111/ update provider tree spec?
17:03:01 mriedem i'm +1 on it, wouldn't mind more feedback
17:06:42 openstackgerrit Marcin Juszkiewicz proposed openstack/nova master: Allow to configure amount of PCIe ports https://review.openstack.org/545034
17:07:11 hrw jaypipes: thanks for review. all changes done
17:11:43 jaypipes hrw: reviewed again.
17:12:20 hrw ops ;D
17:12:26 jaypipes :)
17:13:05 hrw side effect of working on patches during evening instead of morning
17:13:12 jaypipes heh, understood.
17:13:41 hrw jaypipes: all IntOpt options defaults to 0 - that's why I went that way
17:14:24 hrw jaypipes: as 'to 0 not to None'
17:16:46 jaypipes hrw: but if someone wanted to prevent *any* PCIe ports from being created, how would they indicate to actually create *0* ports?
17:17:19 hrw jaypipes: if you want q35 you need to have pcie ports. if you do not set value then you will get them from libvirt
17:18:04 hrw jaypipes: when you boot pcie machine (x86/q35, aarch64/virt) nowadays Nova adds video/disk/network/balloon/usb and gives it to libvirt. libvirt adds pcie ports and spawns guest.
17:18:29 hrw jaypipes: my patch without num_pcie_ports set keeps current setup
17:19:02 jaypipes hrw: yes, I understand that. but I'm asking how a user might ask for 0 PCIe ports to be created.
17:19:06 hrw jaypipes: if you set it to "2" then resulting VM will probably do not work. if you set to 20 then you will get 10-15 free slots
17:19:21 hrw jaypipes: 0 pcie ports == unbootable machine
17:19:41 hrw unless all you want is uefi shell on serial port
17:20:21 hrw and if you want such setup then nova is at least one layer too high
17:21:10 hrw jaypipes: I probably should expand option's comment
17:33:51 openstack Launchpad bug 1750084 in OpenStack Compute (nova) "Report client associations include non-sharing providers" [Undecided,In progress] - Assigned to Eric Fried (efried)
17:33:51 melwitt mriedem: I added https://bugs.launchpad.net/nova/+bug/1750084 to the rc todos etherpad because it was tagged as queens-rc-potential, fyi
17:35:06 mriedem efried_omalley: why is that rc potential?
17:36:00 efried_omalley mriedem: Because it hits on every update_compute_node, and in situations where you have big aggregates, you'll be wiring and caching a lot of unnecessary data.
17:36:17 efried_omalley mriedem: I suppose if we make the argument that people aren't going to be using aggregates in Q, we don't need it.
17:36:44 efried_omalley But that discussion needed to happen, hence "potential" :)
17:37:07 mriedem the only case i know of where people might use aggregates in placement is routed networks via neutron uses them
17:37:17 efried_omalley How big can those get?
17:37:20 mriedem idk
17:38:11 efried_omalley For each aggregate-associated provider, we get the provider record, its inventory, its traits, and its aggregates (just the UUIDs, not associated providers).
17:38:36 hrw jaypipes: need to do some testing and then will push update to config stuff
17:38:40 openstackgerrit Dan Smith proposed openstack/nova master: Avoid exploding if guest refuses to detach a volume https://review.openstack.org/546423
17:38:49 efried_omalley So that's four unnecessary API calls, and caching the concomitant data, per non-sharing aggregate-associated provider.
17:41:04 mriedem efried_omalley: so if i'm working on my local CN1 and it's shared via aggregate to another provider SSP, it's also going to pull down anything related to SSP?
17:41:24 efried_omalley Yes.
17:41:41 mriedem and anything that is also related to SSP?
17:41:50 mriedem anything else i mean, like if CN2 is also shared with SSP?
17:41:52 efried_omalley Yes, with the bug, it'll also pull down CN2-CN999 if they're in the same aggregate as CN1
17:41:56 openstackgerrit Marcin Juszkiewicz proposed openstack/nova master: Allow to configure amount of PCIe ports https://review.openstack.org/545034
17:41:58 mriedem ffs
17:42:17 mriedem well then i guess it is probably worth doing an RC3
17:42:21 hrw jaypipes: config part left
17:42:42 efried_omalley Did I drop the ball here? Was I supposed to tag it sooner? Or manually alert someone to look at it?
17:43:25 mriedem RC2 was friday so you wouldn't have had time anyway
17:44:37 efried_omalley when did I tag it?
17:44:48 mriedem you created the bug on saturday
17:44:53 mriedem anyway, i'm going to be busy for the next hour or so
17:45:01 mriedem so someone else is going to have to dig into it from the core team
17:50:33 openstackgerrit Jay Pipes proposed openstack/os-traits master: Add compute capabilities traits https://review.openstack.org/546713
17:50:40 jaypipes mriedem: ^
18:03:45 melwitt dansmith: you're familiar with the placement provider tree stuff right? if so, it would be good if you could review this bug fix from efried_omalley https://review.openstack.org/545494
18:06:26 melwitt it's a candidate for rc3
18:07:41 dansmith I'm not really, but I'll try to look in a sec
18:08:51 kukacz hi, what determines where nova instance configdrive is stored? is it tied to image storage backend as set in `images_type` in nova-compute.conf?
18:09:17 melwitt dansmith: noted. thanks
18:10:35 dansmith melwitt: ah, this isn't specifically tree related stuff
18:11:14 melwitt the other rc3 candidate is https://review.openstack.org/#/c/545478 which is a simple one to handle specific multiattach exceptions in compute/api
18:12:33 dansmith melwitt: that one is just to avoid raising InvalidBDMVolume for those cases?
18:12:41 dansmith are those caught in the api layer and handled differently?

Earlier   Later