| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-11-12 | |||
| 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 | |
| 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 | |