| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-01-21 | |||
| 10:24:43 | stephenfin | well, that would explain things :-D | |
| 10:25:25 | bauzas | stephenfin: you need to be in https://launchpad.net/~nova-bugs | |
| 10:26:57 | stephenfin | perfect. thanks | |
| 10:29:02 | bauzas | and +2 | |
| 10:29:22 | bauzas | stephenfin: but I said we should wait a little bit for the CI to return first | |
| 10:30:10 | stephenfin | Coolness | |
| 10:31:55 | kashyap | To those using Bash ... here's something useful (and fun): | |
| 10:32:11 | kashyap | To intelligently prepend an env. variable: | |
| 10:32:14 | kashyap | export LD_LIBRARY_PATH=/mypath${LD_LIBRARY_PATH:+:$LD_LIBRARY_PATH} | |
| 10:32:25 | kashyap | [ Source: http://stackoverflow.com/a/9631350 ] | |
| 10:32:39 | kashyap | [And: https://www.gnu.org/savannah-checkouts/gnu/bash/manual/bash.html#Shell-Parameter-Expansion] | |
| 10:34:17 | kashyap | It's yet another obscure/magical-yet-useful combination of characters in Bash :D | |
| 11:27:01 | gibi | stephenfin: does the flavor ids in conflict within a test case or in between test cases running in the same test executor worker? | |
| 11:33:23 | stephenfin | gibi: It appears to be the latter, although I'm not sure if the DB fixture is supposed to prevent that or not | |
| 11:33:33 | stephenfin | i.e. if we tear down the DB after every test | |
| 11:33:53 | gibi | stephenfin: I think we should tear down the db after each step | |
| 11:34:10 | gibi | stephenfin: but there could be some global state that leaks | |
| 11:37:18 | gibi | stephenfin: your fix is still OK, I'm just wondering if we have a bigger problem somewhere deep | |
| 11:47:54 | stephenfin | gibi: I wonder where we'd start. Probably examine the SQLite DB after N tests | |
| 11:53:35 | gibi | yeah something like that | |
| 11:53:47 | gibi | but don't spend too much time on this | |
| 12:17:59 | openstackgerrit | sean mooney proposed openstack/nova master: Revert "Skip cpu comparison on AArch64" https://review.opendev.org/703596 | |
| 13:18:57 | sean-k-mooney | stephenfin: the db fixture should be createing and delete the sqlite db for each test | |
| 13:19:46 | sean-k-mooney | tox will execute the test in effectivly a random order so we cannot have an ordering depencies in how the tests are run so all the tests must use a clean copy | |
| 13:37:40 | stephenfin | sean-k-mooney: Yeah, that's what we're thinking. Just seems unlikely that you'd have a randint conflict in the scope of one test | |
| 13:37:49 | stephenfin | But I guess not | |
| 13:39:25 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Func test for failed and aborted live migration https://review.opendev.org/699065 | |
| 13:41:20 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Use common server create function for qos func tests https://review.opendev.org/701353 | |
| 13:41:20 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Remove extra instance.save() calls related to qos SRIOV ports https://review.opendev.org/702261 | |
| 13:45:03 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Enable live migration with qos ports https://review.opendev.org/699066 | |
| 14:11:55 | openstackgerrit | Alexandre arents proposed openstack/nova master: Avoid allocation leak when deleting instance stuck in BUILD https://review.opendev.org/702368 | |
| 14:56:00 | openstackgerrit | Kashyap Chamarthy proposed openstack/nova master: libvirt: Add a default VirtIO-RNG device to guests https://review.opendev.org/616603 | |
| 14:56:09 | kashyap | gibi: Thanks for the review; hope the above looks better. | |
| 15:03:42 | efried_pto | stephenfin: I'm trying to find out who the admins of lp nova-drivers are... | |
| 15:04:48 | sean-k-mooney | its owned by openstack adminstrators | |
| 15:04:50 | sean-k-mooney | https://launchpad.net/~nova-drivers | |
| 15:05:12 | sean-k-mooney | efried_pto: https://launchpad.net/~nova-drivers/+members#active | |
| 15:05:25 | sean-k-mooney | but melwitt is an admin | |
| 15:05:35 | sean-k-mooney | so she can make you one if you need it | |
| 15:06:05 | efried | oh, why didn't I see that status column before? | |
| 15:06:27 | sean-k-mooney | the openstack amdinstartor group is https://launchpad.net/~openstack-admins/+members#active by the way | |
| 15:06:28 | efried | yeah, melwitt probably a good idea to give yourself a backup who's actually still on the core team. | |
| 15:06:35 | sean-k-mooney | in case you need them to change something | |
| 15:06:42 | efried | me or dansmith | |
| 15:06:43 | efried | thanks sean-k-mooney | |
| 15:07:21 | sean-k-mooney | no worries | |
| 15:08:06 | efried | We should do the same for nova-bugs, if we can raise mriedem or mikal... | |
| 15:09:50 | sean-k-mooney | if you cant then corvus can fix it for us | |
| 15:11:28 | sean-k-mooney | actully anyone in the openstack administratros group should be able to do it | |
| 15:14:58 | johnthetubaguy | efried: I can take a look | |
| 15:15:10 | johnthetubaguy | I should have been removed from some of these mind! | |
| 15:15:41 | bauzas | we no longer really need nova-drivers FWIW | |
| 15:15:58 | bauzas | it was for blueprints IIRC | |
| 15:16:16 | johnthetubaguy | bauzas: yeah, its mostly permissions around blueprints, from my memory | |
| 15:16:28 | sean-k-mooney | yes the drivers group are teh one that can apporve blueprints i thin | |
| 15:16:29 | bauzas | just to set 'Accepted' | |
| 15:16:32 | johnthetubaguy | looks like efried got added in nova-drivers now | |
| 15:18:31 | sean-k-mooney | i think its also used to create series and milestones too | |
| 15:24:02 | openstackgerrit | Merged openstack/nova master: functional: Stop setting Flavor.id https://review.opendev.org/703568 | |
| 15:24:34 | gibi | kashyap: did you forget to publish your answer to https://review.opendev.org/#/c/616603/12..13/nova/virt/libvirt/driver.py@a5116 ? | |
| 15:24:56 | kashyap | gibi: Whoops, indeed | |
| 15:25:05 | kashyap | Let me hit 'submit' | |
| 15:25:13 | gibi | :) | |
| 15:25:28 | kashyap | Done. Sorry :-) | |
| 15:25:34 | gibi | no problem | |
| 15:25:47 | kashyap | gibi: In short, although good catch on the negation, we'd need the 'and' there. | |
| 15:26:21 | efried | johnthetubaguy: thanks, I appear to be admin-y now. | |
| 15:26:25 | gibi | if this is intentional then I'm OK with it. let me read your answer :) | |
| 15:26:35 | kashyap | gibi: Unrelated to this change: /me has a TODO to allow two more possible values for 'hw_rng_model', besides "virtio". Hence we need to retain that extra spec | |
| 15:26:40 | johnthetubaguy | efried: cool | |
| 15:26:43 | efried | ...on -drivers. johnthetubaguy do you have power in nova-bugs? | |
| 15:26:55 | kashyap | gibi: Yes, it is intentional; but of course your observation was correct | |
| 15:26:59 | johnthetubaguy | efried: it seems not sadly | |
| 15:27:43 | kashyap | gibi: And I noticed that you didn't frame it as "this is wrong", but rather "thinking it out loud; is this intentional" :-) | |
| 15:31:32 | gibi | kashyap: I'm still confused. If the user sets hw_rng:allowed = False but but does not set anything to hw_rng_model then he gets no rng device, but then if he sets anything to hw_rng_model the he will get an rng device even if hw_rng:allowed is still false | |
| 15:35:01 | kashyap | gibi: 'hw_rng_model' will have no effect if 'hw_rng:allowed' is not set to True | |
| 15:36:02 | kashyap | gibi: And the only currently allowable value for 'hw_rng_model' is "virtio" | |
| 15:36:12 | gibi | kashyap: I guess that "no effect" is outside fo Hi Balazs, | |
| 15:36:34 | gibi | kashyap: I guess that "no effect" is outside of _add_rng_device | |
| 15:37:49 | gibi | because in _add_rng_device if hw_rng:allowed is False but hw_rng_model is not empty then we are adding a device | |
| 15:37:56 | kashyap | gibi: Yeah | |
| 15:38:27 | sean-k-mooney | well if hw_rng:allowed=False we shoudl nto add a RNG device | |
| 15:38:43 | sean-k-mooney | regardless of what the hw_rng_model is set to | |
| 15:40:51 | kashyap | - if not rng_is_virtio and not rng_allowed: | |
| 15:40:51 | kashyap | gibi: sean-k-mooney: Yes: | |
| 15:40:52 | kashyap | + if not rng_allowed: | |
| 15:42:01 | kashyap | Then 'hw_rng_model' will be "useless" (but we want to enhance the prop to allow two more values), as it isn't used outside this method. | |
| 15:43:20 | gibi | kashyap: if the value of hw_rng_model is not need to decide to add the device that is fine. As soon as we (you) add support the new model values then such change will make hw_rng_model used again, in the device parameters (I guess) | |
| 15:44:34 | kashyap | gibi: Yes, I'll go with the above 'diff' and document the TODO the image props to extend it for new values | |
| 15:44:56 | kashyap | gibi: Sounds okay? | |
| 15:45:37 | gibi | kashyap: yes, sounds good | |
| 15:45:39 | kashyap | (The extended two values will also be virtio variants.) | |
| 15:45:42 | sean-k-mooney | we have not added new values in several cycle and like will not in the future | |
| 15:45:50 | sean-k-mooney | so we might just want to deprecate the model | |
| 15:46:03 | sean-k-mooney | is there support in qemu for other RNGs? | |
| 15:46:04 | gibi | sean-k-mooney: I guess kashyap disagrees ^^ | |
| 15:46:34 | kashyap | sean-k-mooney: Wait: how do you know "not in the future"? The new values were added to fix certain bugs with guest compat with old operating systems | |
| 15:46:39 | kashyap | As I mentioned on the change. | |
| 15:46:41 | sean-k-mooney | well im just asking is can it have other value form a qemu point of view | |
| 15:47:22 | kashyap | sean-k-mooney: Yes: | |