| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-11-29 | |||
| 17:41:19 | dansmith | hmm, not sure how you could do that for periodics that run later | |
| 17:42:27 | mriedem | still fails | |
| 17:42:46 | melwitt | dansmith: I think periodics are run by the service, so I did this https://review.openstack.org/#/c/508432/9/nova/test.py to target them to the associated cell | |
| 17:42:54 | dansmith | oh you patch periodic_tasks | |
| 17:43:13 | dansmith | not sure that's enough necessarily, | |
| 17:43:27 | dansmith | because anything that stores a context somewhere might not actually make that call in that path | |
| 17:43:49 | melwitt | it's better than what we have :P but yeah, I have been wanting people to review it to see what gaps could be addressed | |
| 17:44:11 | dansmith | well, it's not if we end up with spurious failures when we get unlucky and run a periodic in the middle of a slow test run | |
| 17:44:46 | mriedem | i left comments on the fixture patch | |
| 17:44:49 | melwitt | dansmith: what do you mean by "anything that stores a context somewhere"? the periodics in the compute service all use an anonymous admin context | |
| 17:45:16 | dansmith | melwitt: well, if something like RT has a context stored somewhere | |
| 17:46:07 | melwitt | dansmith: sure. I couldn't think of if/how it could be bullet-proofed | |
| 17:46:29 | dansmith | I think the thing we really should be doing is just make the compute manager grab a context on service start, | |
| 17:46:48 | dansmith | and wipe through compute/* and make sure nothing ever calls get_admin_context() or context.RequestContext() in there | |
| 17:46:53 | dansmith | sort of how we banned db access | |
| 17:47:18 | melwitt | yeah, that would be nicer | |
| 17:47:24 | dansmith | I think that also, | |
| 17:47:36 | melwitt | still, that doesn't stop anyone from doing something else, which is what you were pointing out | |
| 17:47:44 | dansmith | someone with "security" in their title would like to see that we can't just call foo.get_admin_credentials() anywhere | |
| 17:48:02 | mriedem | i think mikal is now head of security at aptira | |
| 17:48:13 | mriedem | securinaut or something | |
| 17:48:13 | dansmith | melwitt: well, it does if we actually clean that up to the point of making sure it won't work, like the db stuff | |
| 17:48:56 | melwitt | one thing I realized just now is, a context is handed off when the periodic tasks are kicked off once, and it reuses that. it's just that in the service code it uses get_admin_context for that | |
| 17:50:00 | melwitt | periodic_tasks is called once during service.start | |
| 17:50:02 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Fix ValueError when loading old pci device record https://review.openstack.org/523914 | |
| 17:50:02 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Remove vestigial extra_info update in PciDevice.save() https://review.openstack.org/523919 | |
| 17:50:37 | dansmith | yeah, but your wrapping of it ensures that anyway | |
| 17:51:07 | melwitt | but I thought you were saying "what if compute manager uses a different context" and it can't | |
| 17:51:08 | openstackgerrit | Chris Dent proposed openstack/nova master: [placement] Enable limiting GET /allocation_candidates https://review.openstack.org/513526 | |
| 17:51:10 | melwitt | https://github.com/openstack/nova/blob/master/nova/service.py#L294-L295 | |
| 17:51:35 | dansmith | melwitt: I'm saying if we have another context we got from not the periodic one we were handed, not in the scope of the periodic itself | |
| 17:51:44 | dansmith | we have contexts everywhere, on every object, etc | |
| 17:51:56 | dansmith | I thought we actually stored on in the RT too but I don't think we do | |
| 17:52:07 | melwitt | okay, yeah I thought you were talking only about periodics | |
| 17:52:25 | dansmith | ah in the claim we do, that's probably what I'm thinking of | |
| 17:52:43 | dansmith | melwitt: I mean a periodic that accesses one created outside the scope of the periodic, like claim for example | |
| 17:52:54 | melwitt | oh, I see | |
| 17:52:57 | melwitt | yeah | |
| 17:57:52 | melwitt | mriedem: I think you might have to not do your own _setup_compute_service | |
| 17:58:38 | cdent | jaypipes, efried_rollin : is n-r-p stack clean and reviewable? Last I checked last night might rebase was in progress. | |
| 18:07:20 | openstackgerrit | melanie witt proposed openstack/nova master: qemu-img do not use cache=none if no O_DIRECT support https://review.openstack.org/523554 | |
| 18:12:15 | dansmith | stephenfin: https://review.openstack.org/#/c/523914 | |
| 18:13:45 | melwitt | mriedem: I pulled down your patch to see if I can find anything | |
| 18:15:53 | mriedem | dansmith: that root_bdm thing with using compute_utils.is_volume_backed opens up some funny doors | |
| 18:16:06 | mriedem | probably nothing we'd ever hit in real life | |
| 18:16:06 | dansmith | mriedem: yeah? | |
| 18:16:24 | mriedem | is_volume_backed_instance returns True if there is no root bdm but the image_ref is '' | |
| 18:16:36 | mriedem | so "volume_id = root_bdm.volume_id" could result in a NoneType | |
| 18:17:05 | mriedem | nova.tests.unit.compute.test_compute.ComputeAPITestCase.test_rebuild_no_image apparently tickles that path | |
| 18:17:58 | mriedem | in that case i guess i just log an error or something, not sure | |
| 18:18:02 | mriedem | shouldn't really happen | |
| 18:29:21 | openstackgerrit | Lee Yarwood proposed openstack/nova master: libvirt: Refactor encryptor attach and detach calls https://review.openstack.org/460243 | |
| 18:29:21 | openstackgerrit | Lee Yarwood proposed openstack/nova master: libvirt: Introduce disk encryption config classes https://review.openstack.org/464008 | |
| 18:29:22 | openstackgerrit | Lee Yarwood proposed openstack/nova master: WIP libvirt: Use QEMU's native LUKS support https://review.openstack.org/523958 | |
| 18:37:53 | openstackgerrit | Merged openstack/nova master: Updated from global requirements https://review.openstack.org/523765 | |
| 18:38:58 | INeedaUUID | Hi everyone. Can anyone tell me how best to modify a systems' uuid using openstack methods? | |
| 18:39:03 | INeedaUUID | Does openstack support this? (I know it's a stupid request, but an application depends on them being set) | |
| 18:39:11 | INeedaUUID | Ocata/KVM | |
| 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 | dansmith | (just kidding, I'm _sure_ that's what this is) | |
| 18:59:48 | jaypipes | dansmith: just a wild guess. ;) | |
| 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: Add regression test for rebuilding a volume-backed server https://review.openstack.org/521200 | |