Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2020-01-21
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 gibi: sean-k-mooney: Yes:
15:40:51 kashyap - if not rng_is_virtio and not rng_allowed:
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:
15:47:25 kashyap https://libvirt.org/formatdomain.html#elementsVirtioTransitional
15:47:54 sean-k-mooney the model has noting to do with tanstional devices
15:48:09 kashyap sean-k-mooney: Hang on.
15:48:31 kashyap sean-k-mooney: 'virtio-transitional' is another possible value, instead of 'virtio'
15:48:48 kashyap Please take two minutes to read what the page is saying.
15:48:57 sean-k-mooney oh i see they aded that in 5.2
15:49:07 kashyap I also quoted *specific* bits in the Gerrit change!
15:49:29 sean-k-mooney so im not sure we should be exposing that to end users
15:50:02 kashyap So you haven't read the comment that clearly explains it here: https://review.opendev.org/#/c/616603/10/nova/virt/libvirt/driver.py@5114
15:50:35 kashyap In short: we should _not_ deprecate it.
15:50:43 kashyap (Where "it" == hw_rng_model)
15:51:26 kashyap sean-k-mooney: I'm sure we should expose them as possible values for the user
15:51:27 sean-k-mooney im wondering if nova can just make the chioce itself without exposeing it to the user
15:51:37 kashyap Hmm, I don't think we have enough info about it.
15:51:46 sean-k-mooney sure we do
15:52:23 sean-k-mooney if qemu/libvirt support the virtio-non-transitional version shoudl we not always use it
15:52:57 kashyap I'm of course not saying we should unconditionally enable anything what QEMU/libvirt support.
15:53:24 kashyap Anyway, we're going into the weeds here. The point being: we should not be in a hurry to deprecate that prop
15:53:36 sean-k-mooney ok
15:53:45 sean-k-mooney we also shoudl not be in a hurry to extend it
15:53:55 sean-k-mooney that is not relevent to your patch however
15:54:10 kashyap Yes, I'm not hurrying to extend it; I wanted to keep it a potential option.
15:54:30 sean-k-mooney i guess we might need to expose it for legacy os support
15:54:55 kashyap sean-k-mooney: gibi: To conclude the discussion: my previous comment still stands: will go with the `diff` noted earlier w/ a TODO in code
15:54:57 sean-k-mooney but they could jsut disbael the RNG
15:55:04 kashyap sean-k-mooney: Yeah, indeed on the legacy OS
15:55:19 sean-k-mooney ya the diff is fine with me
15:55:23 kashyap Okido
15:55:33 kashyap Thanks for bearing with me
15:56:40 kashyap Completely unrelated: I can't even do Ctrl-c in Grrrrrit-- anymore. Is it just me?
15:57:25 sean-k-mooney i got it working but i know other have had issues
15:57:41 sean-k-mooney its a browser thing i think
15:57:52 sean-k-mooney i dont think our gerrit was updated
16:00:38 kashyap sean-k-mooney: I tried it in both FF and Chromium :-(
16:00:49 kashyap (To no effect)
16:12:48 sean-k-mooney kashyap: so in chrome i has the "webkit-user-select: none" css property applied
16:12:56 sean-k-mooney to the comment
16:14:33 sean-k-mooney in firfox 67 it does not
16:14:57 kashyap sean-k-mooney: I see, will fiddle. Thank you for the tip
16:15:30 kashyap sean-k-mooney: Unrelated: do we have any examples of this:
16:15:33 kashyap "* Some properties recognized by Nova may have no effect unless a corresponding property is enabled in the server flavor."
16:16:19 kashyap (The 'hw_rng_model' / 'hw_rng:allowed' used to be one; but now we're changing it.)
16:16:25 kashyap I quoted it from Glance docs; as I'm updating them

Earlier   Later