Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2020-11-12
14:08:47 sean-k-mooney yep that works too
14:09:24 sean-k-mooney just need to let people know
14:10:29 sean-k-mooney gibi: stephenfin dansmith since most of my insstance are bfv this also expalins why i expect shelve to more or less always got to shelve_offladed pretty quickly
14:10:52 sean-k-mooney given bfv instance skip shleved
14:11:36 gibi sean-k-mooney: I saw the brancing in the code but I don't know the original reason of such branching
14:12:04 sean-k-mooney my specutlation was there is no data too offload so just go strait to offloaded
14:13:20 sean-k-mooney a comment would have been nice but that is my guess. i agree with luzi that there is likely no utility in makeing them waith in shelved until the time out expries and a doc update is proably enough
14:15:17 sean-k-mooney gibi: that said its directly calling the compute to avoid this check today https://github.com/openstack/nova/blob/master/nova/compute/api.py#L4197
14:16:07 sean-k-mooney so we are not recordign the offload in the evnet log
14:39:38 openstackgerrit Marc Gariépy (mgariepy) proposed openstack/nova stable/ussuri: Handle disabled CPU features to fix live migration failures https://review.opendev.org/758761
14:42:15 mgariepy any nova core avalaible to review: https://review.opendev.org/#/c/758760/ ?
14:42:15 openstackgerrit Ghanshyam Mann proposed openstack/nova master: [WIP] Migrate nova-grenade-multinode job to zuulv3 native https://review.opendev.org/742056
14:44:16 dansmith sean-k-mooney: ah yeah bfv doesn't need to offload anything of course
14:54:02 gibi mgariepy: added to my queue which happens to be long these days so other core please don't wait for me
14:57:32 mgariepy thanks gibi
14:58:05 mgariepy also add: https://review.opendev.org/#/c/758761/
14:59:12 gibi mgariepy: ohh, so this is a backport that is already merged on master
14:59:27 gibi then, elod, could you look at it please ^^ ?
14:59:53 gibi mgariepy: sorry, I don't have +2 rights on stable branches, elod has ;)
15:00:24 mgariepy ha no worry
15:20:52 stephenfin sean-k-mooney: We used to have a list of projects that had to be present to call something an OpenStack cloud. What was that program called? Does it still exist?
15:26:03 sean-k-mooney yes its defcore i think there is a branding requirement
15:26:56 stephenfin defcore. That's it
15:27:12 sean-k-mooney just trying to find the repo its in
15:27:26 sean-k-mooney its for the openstack powered trademakrs mainly
15:35:37 gibi nova weekly meeting starts in 25 minutes on #opentack-meeting-3
15:35:50 gibi at the same time as the opentack wallaby community meeting
15:36:29 gibi I will be present on both (the first part of the community meeting is prerecorded)
15:41:06 sean-k-mooney stephenfin: it used to be defiend in https://github.com/openstack-archive/refstack
15:41:49 sean-k-mooney then it move dto https://github.com/openstack-archive/interop i think
15:43:03 sean-k-mooney they are now at https://opendev.org/osf/interop and https://opendev.org/osf/refstack
15:45:35 sean-k-mooney stephenfin: this is the latest definition https://opendev.org/osf/interop/src/commit/5f7a8cf9c43015a27c2ed56cad8501d470807461/2020.06.json
15:46:04 sean-k-mooney https://opendev.org/osf/interop/src/commit/5f7a8cf9c43015a27c2ed56cad8501d470807461/2020.06.json#L80-L86
16:05:36 openstackgerrit Stephen Finucane proposed openstack/nova master: functional: Wait for revert resize to complete https://review.opendev.org/762543
16:05:37 openstackgerrit Stephen Finucane proposed openstack/nova master: functional: Use helpers for cross-cell resize https://review.opendev.org/762544
16:21:46 digvijay trying to attach a GPFS-NFS based cinder volume to vm & getting error in nova-compute.log... (http://paste.openstack.org/show/799964/)
16:21:57 digvijay any idea what might be issue?
16:55:17 stephenfin dansmith: So regarding that virtio tablet discussion. I'd rather introduce 'hw_input_bus' and deprecate 'hw_pointer_model'
16:55:36 stephenfin If the only reason to use mouse is compatibility, then there isn't really any reason to want to keep the latter long-term
16:56:04 bauzas gibi: sorry, I was on a dentist appointment
16:56:14 gibi bauzas: no worries
16:56:21 gibi bauzas: hope it did not hurt
16:56:29 dansmith stephenfin: and what, assume tablet from usb or virtio, and mouse from ps2?
16:56:46 dansmith since it's image metadata, deprecating a thing just means debt forever that we can never get rid of right?
16:56:47 stephenfin yes, assuming we even want to support ps2
16:57:27 bauzas gibi: nope, no worries, it was just a yearly one
16:57:37 gibi :)
16:57:52 stephenfin dansmith: Sort of, but I think this is actually better
16:58:20 bauzas (and I was off the chan today because I was working on https://review.opendev.org/#/c/761452/ )
16:58:25 owalsh dansmith: so I've been thinking about https://review.opendev.org/762176. I'm really not convinced yet but maybe I'm missing something obvious...
16:58:32 stephenfin Actually, no, it makes no difference
16:58:39 stephenfin We can remove the 'hw_pointer_model' image metadata property in a future major version bump
16:58:45 dansmith stephenfin: but it's "better" just in that you like the name of input_bus more than pointer_model right? Just adding virtiotablet to the existing key gives us no infinite debt, keeps the choices small so that it's harder to pick something that will likely work
16:58:48 stephenfin If we do, nova will simply start ignoring it
16:59:00 dansmith stephenfin: then we've broken users
16:59:17 dansmith I think we're pretty much trying to never do that right? have we ever stopped honoring an image meta property?
16:59:35 stephenfin yes, we'd need mitigation which is why I don't think we'd ever do it
17:00:11 stephenfin same reason we'll continue supporting e.g. 'hw_disk_bus=uml'
17:00:15 owalsh dansmith: so based on what sean said most of the deployment frameworks already do the right thing, and I'm sorting out tripleo/puppet-nova ...
17:00:16 stephenfin like, forever
17:01:06 owalsh dansmith: so I think that leave two scenarios where we could have a nova.conf where the compute gets db creds:
17:01:07 stephenfin dansmith: it's much better UX IMO, yes
17:01:12 dansmith stephenfin: well, it just doesn't make any sense to me to deprecate a thing we'll never remove, which is really not that in need of change
17:01:34 owalsh dansmith: 1 - a roll you're own deployment that screws it up (because there are no docs)
17:01:47 stephenfin dansmith: we're going to end up in that situation anyway
17:01:56 stephenfin usbtablet will be meaningless in a Q35 world
17:01:59 dansmith owalsh: I think everyone agrees it needs to be doc'd better
17:02:01 digvijay hi.. facing issue with attaching NFS based cinder volume to VM.. (http://paste.openstack.org/show/799964/).. any ideas
17:02:04 stephenfin and already is on non-x86
17:02:05 owalsh dansmith: 2 - an all-in-one deployment (is that not a valid expection to the rule)
17:02:17 stephenfin given neither support ps2
17:02:54 owalsh dansmith: so we just fix the docs and leave it at that instead of ripping puppet-nova, and the debs, and the rpms and etc.. into pieces...
17:02:58 dansmith stephenfin: that's the same for all of our keys that specify a platform-specific value (like ide, sata, etc).. you're just adding an additional degree of freedom by adding a new key
17:03:23 owalsh dansmith: or maybe we do that, for the sake of elegance, but not a priority in W
17:03:55 dansmith owalsh: well, I meant document it to help with the roll-your-own case and for future deployment tools, but go forward with the startup abort, which requires fixing tripleo
17:04:21 dansmith owalsh: tbh, I'm not the one that really wanted the startup abort, but it does seem like the right thing to do to me
17:04:31 dansmith owalsh: especially since tripleo seems to be one of the only ones not already getting this right
17:05:27 owalsh issue is actually in puppet-nova so tripleo is not to blame here
17:05:54 dansmith owalsh: do any other major deployment tools use puppet-nova besides tripleo?
17:06:02 dansmith they used to, but I didn't think much anymore
17:06:21 dansmith however, tripleo is easier to type, but feel free to apply my comments to the appropriate project :)
17:07:26 owalsh ack, either way take it for granted that the fix is happening and will be backported. Once that is out of the way the hard fail doesn't achieve much IMO, just breaks all-in-one for a lot of people
17:07:55 dansmith devstack is by default an AIO tool and it has been doing it right for years
17:08:20 dansmith but, again, I'm not the only one you need to convince
17:08:40 dansmith IIRC, it was stephenfin that originally thought we should be blocking startup on invalid or insecure configs, and I agree with him
17:08:48 openstackgerrit Ghanshyam Mann proposed openstack/nova master: DNM: Testing system scope in tempest https://review.opendev.org/740124
17:08:55 dansmith and that doesn't happen very often, so it MUST be right :)
17:10:43 owalsh dansmith: well I know where he lives, if it wasn't for this lockdown!
17:10:55 dansmith sudo refuses to run when a sudoers.d file has invalid permissions, even on my single-user laptop because it's a bad idea for everyone
17:10:56 dansmith owalsh: hah
17:12:37 owalsh dansmith: well given this wasn't really documented I don't think it ok land the assert in W. How about warning that is deprecated for now?
17:13:43 dansmith owalsh: that's a gibi call.. so far I've not heard that this was a surprise to anyone, and you know we have known this is wrong downstream for a while. So to me it seems like a valid thing to do aggressively because of the security aspect, but I'll defer to gibi for timing
17:15:24 gibi I see a big pushback on the hard fail, but I also do supprised that all tool that supprots all-in-one today are worked around that hard failure due to upgrade_level 'auto' that is landed cycle ago
17:16:11 gibi if the whole push back is just to get more time to do the fixes then I'm fine to delay the patch even further
17:16:31 dansmith gibi: you _do_ see a big pushback? I didn't see much from the ML, but maybe I'm missing some?
17:16:50 dansmith sounded to me like debian just wanted some agreement on best practices or something
17:17:12 gibi dansmith: I understood from the ML that we are breaking debian, osa, and tripleo as well. Only kolla and devstack are immune
17:18:09 dansmith but OSA says they already try to do the right thing and are willing to change, especially if we do some docs
17:18:31 dansmith anyway, as I said, I defer to you on the timing
17:19:35 gibi yeah, I might mix the amount of broken thing with the amount of pushback. Now that I re-read OSA mail it does not feel like a pushback

Earlier   Later