Earlier  
Posted Nick Remark
#openstack-nova - 2017-11-29
18:39:47 jaypipes cdent: efried_rollin is currently rebasing./
18:40:12 jaypipes cdent: ooh, hold up, he may have pushed a fresh series.
18:45:54 mriedem gdi, that moment when you rebase a series and forget git add / git rebase --continue on the last change, and did git commit -a --amend instead, thus squashing the last change and ruining everything
18:47:38 mriedem INeedaUUID: no you can't specify the uuid that gets used with the vm
18:47:49 INeedaUUID mriedem: Is there not a workaround at all?
18:47:52 mriedem no
18:48:03 INeedaUUID What about modifying from virsh?
18:48:18 mriedem let me guess, you're doing some kind of instance HA
18:48:44 INeedaUUID actually, no. It's to do with a 3rd party application and the VERY stupid way it licences.
18:48:49 mriedem anything you do to a vm via virsh out of band from nova will likely break nova's ability to do things with that vm
18:49:31 INeedaUUID I thought that. But I will need to try. :-(
18:49:35 mriedem pass metadata through to the guest and have the 3rd party app pull from that
18:50:06 dansmith presumably the app is unchangeable
18:50:11 dansmith getting the uuid from smbios,
18:50:16 dansmith so metadata won't help even if hacked
18:50:36 INeedaUUID dansmith: is correct. Unchangable.
18:51:18 dansmith your options are:
18:51:28 INeedaUUID It's crap, I know it is. But... It's essential.
18:51:30 dansmith 1. lots of scary nova db surgery. don't even tell us about it
18:51:40 dansmith 2. wrap your application in something that fools it
18:51:43 dansmith 3. Get a new application
18:52:05 dansmith I suggest 3, I would do 2, please don't do 1
18:53:31 INeedaUUID The requirements suggest exactly the opposite of the numbers you propose. But I apprieciate the honesty. It is what it is.
18:53:55 INeedaUUID 3. not an option (don't ask why)
18:53:57 dansmith not an accident :)
18:54:04 dansmith I'm sure
18:54:11 INeedaUUID 2. Not sure if I can do this. Can I have the system uuid somehow I wonder?
18:54:20 dansmith windows or linux guest?
18:54:29 INeedaUUID 1. I'm too stupid, but given the lack of options, it's a few sleepless nights.
18:54:50 INeedaUUID linux
18:55:10 dansmith LD_PRELOAD
18:56:02 INeedaUUID If this is an option, I will make this work! :-D
18:56:46 cdent dansmith: you’re potentially a freakin’ genius
18:56:58 dansmith o.O
18:57:35 jaypipes INeedaUUID: is this a telco VNF vendor by any chance?
18:59:24 dansmith gawd jaypipes, there _are_ other closed-source stupid-licensed industries out there
18:59:36 dansmith why you always pickin' on those lovable telco people?
18:59:48 jaypipes dansmith: just a wild guess. ;)
18:59:48 dansmith (just kidding, I'm _sure_ that's what this is)
19:00:16 mriedem that reminds me,
19:00:33 mriedem jaypipes: did i tell you how 2 different groups of people approached me about their worries about deprecating the ability to do file injection?
19:00:34 openstackgerrit Matt Riedemann proposed openstack/nova master: Get original image_id from volume for volume-backed instance rebuild https://review.openstack.org/521391
19:00:34 openstackgerrit Matt Riedemann proposed openstack/nova master: Add regression test for rebuilding a volume-backed server https://review.openstack.org/521200
19:00:35 openstackgerrit Matt Riedemann proposed openstack/nova master: Fail fast if changing image on a volume-backed server rebuild https://review.openstack.org/520660
19:00:39 mriedem at the summit
19:00:47 mriedem verizon and ericsson
19:00:50 dansmith only two?
19:00:56 jaypipes mriedem: yeah, only two?
19:01:02 INeedaUUID jaypipes: I could tell you. But then i'd have to murder you.
19:01:04 dansmith two seems like a mandate to me
19:01:06 mriedem well, most people only say things 3 years after the change is merged
19:01:44 mriedem mikal told the verizon guys that their vnf vendor was "shit" in his aussy words and that they should talk to him
19:01:48 jaypipes mriedem: also, it's probably all rooted in the same dependency on a specific particular vendor VNF or MANO system that requires file injection (and stuff like multi-attach boot-from-volume
19:02:36 mriedem multiattach bfv is the bees knees
19:02:49 mriedem i wonder how rebuild is going to handle that...
19:03:02 dansmith probably as well as it handles everything else
19:03:12 dansmith by opening security holes, leaking resource accounting, and destroying data
19:03:22 jaypipes luckily that shotgun I ordered through the mail should be here by the time multi-attach bfv rolls into Nova.
19:03:33 dansmith jaypipes: you're welcome, from america
19:03:39 jaypipes murka
19:03:50 mriedem dansmith: ok i did the deeds in https://review.openstack.org/#/c/521391/3/nova/compute/api.py
19:04:02 mriedem if i can't find a root bdm and image_ref is '', i just log an error and keep trucking
19:04:45 mriedem i don't know if that case is some scary pre-bdmv1 stuff or what, it predates me
19:05:45 dansmith I don't understand where that's ever going to happen
19:06:10 openstackgerrit Matt Riedemann proposed openstack/nova master: Fail fast if changing image on a volume-backed server rebuild https://review.openstack.org/520660
19:06:11 mriedem i don't either
19:06:18 mriedem which is why i just log an error and punt
19:06:34 dansmith but you don't punt,
19:06:50 dansmith you set it to None, which causes the need for that extra else and then kick the can to the next thing in line
19:06:56 dansmith why not just dump ass right there and stop?
19:07:30 mriedem we could, but what do we raise? it's a 500 if we raise i think
19:07:53 dansmith is that less right than logging an error and saying "this is just going to break in the next service down" ?
19:08:08 mriedem at this point it would run through the scheduler with the provided image
19:08:24 mriedem which is basically what this was trying to fix - not doing that if the image doesn't change
19:08:42 mriedem the final patch in that series will fail though
19:08:56 mriedem i'm cool with a 500 if there isn't a root_bdm
19:09:45 dansmith if we run the scheduler and instance.image_ref is falsey it'll be happy?
19:10:50 mriedem we'd run the scheduler on the new image provided to rebuild
19:10:57 mriedem well, new or the same as the original
19:11:08 dansmith oh, I see
19:11:11 dansmith still, I dunno
19:11:13 dansmith seems dumb to me
19:11:16 mriedem there is this no_device flag on the bdmv1 stuff, i don't know what that does
19:11:39 dansmith heh
19:11:40 mriedem like, i don't know if there is a way to tell the api not to create you any bdms but still give you a volume-backed instance
19:50:57 openstackgerrit Brianna Poulos proposed openstack/nova master: Add trusted_certs object https://review.openstack.org/489408
19:55:41 openstackgerrit Merged openstack/nova master: placement: add nested resource providers https://review.openstack.org/377138
19:55:54 edleafe ^^ woo hoo!
20:01:23 openstackgerrit Matt Riedemann proposed openstack/nova master: Raise specific exception when swapping migration allocations fails https://review.openstack.org/517004
20:05:27 openstackgerrit Merged openstack/nova master: Remove deprecated TrustedFilter https://review.openstack.org/506864
20:05:40 openstackgerrit Merged openstack/nova master: libvirt: do unicode conversion for error messages. https://review.openstack.org/517555
20:07:11 efried_rollin cdent jaypipes I'm not rebasing nrp at the moment. I just peeled out one of the changes. Since the first one merged, the bottom three should currently be clean and reviewable. I wouldn't go above that.
20:09:35 openstackgerrit melanie witt proposed openstack/nova master: qemu-img do not use cache=none if no O_DIRECT support https://review.openstack.org/523554
20:18:11 openstackgerrit Eric Berglund proposed openstack/nova master: Add PowerVM to compute_driver options https://review.openstack.org/523978
20:26:15 cdent efried: thanks for the info. will try to get some reviewing in before I stop today
20:35:27 mriedem anyone else noticing a spike in cellsv1 job failures?
20:35:28 mriedem http://logs.openstack.org/10/523910/1/check/legacy-tempest-dsvm-cells/76a0551/logs/screen-n-sch.txt.gz#_Nov_29_16_05_42_186316
20:37:34 dansmith that filter isn't on by default, right? are we forcing it on?
20:37:41 mriedem it's enabled in devstack
20:38:04 dansmith oh

Earlier   Later