Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2020-11-12
13:55:02 Luzi ok thank you sean-k-mooney
13:55:05 sean-k-mooney because its expensive to snapshot and restore them due to the data copy
13:55:41 sean-k-mooney it proably shoudl be consistent but that would be the most likely reason its not
13:57:12 Luzi it sounds reasonable, but i did not find the reason documented, even though i found the code lines, where they paths begin to differ
13:57:52 sean-k-mooney ya i think different peopel have different expectaions for shelve we had a conversation about it yesterday
13:57:53 Luzi its definitely confusing :D
13:58:29 sean-k-mooney i expect that all shelved instance shoudl eventually end up in shelve offloaded not shelved but that based on the defaults and how i use it
13:59:06 sean-k-mooney in the bfv case basically there is no data too offload since its not on the host to begin with
13:59:20 sean-k-mooney the docs could proably be improved however
14:00:01 Luzi from what i have experienced today, it would be nice to state it at least in the config example documentation
14:00:33 Luzi a hint, that volume based server will always go directly into the offloaded state
14:00:53 sean-k-mooney ya we could proably just add a sleep(conf.shelve_offload_time) in the bfv path befor ecalling offload
14:01:13 sean-k-mooney its likely not going dirctly but just ignoring the time out
14:01:51 sean-k-mooney do you have a reference to the code i have not look at it that closely in a while
14:03:28 Luzi https://github.com/openstack/nova/blob/master/nova/compute/api.py#L4185
14:04:50 sean-k-mooney ah its calling shelve offload directly
14:04:54 Luzi yes
14:05:15 Luzi and the config option is used here: https://github.com/openstack/nova/blob/eb279e9a5676f4142cce4700c3097ecc14161895/nova/compute/manager.py#L6363
14:06:59 sean-k-mooney ya so we could call shelve directrly i think but how we do the snapshot would have to be conditional on the instance type
14:07:01 sean-k-mooney https://github.com/openstack/nova/blob/master/nova/compute/manager.py#L6396
14:08:26 sean-k-mooney basically move that first if into shelve
14:08:26 Luzi it makes sense to directly go into the offloaded state, so imho it would just need some fixed documentation.
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

Earlier   Later