Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2020-11-12
13:22:42 zigo So, I should generate the db config file with only --namespace oslo.db --namespace oslo.db.concurrency, right?
13:22:46 sean-k-mooney they all tend to generat there own based on the layer tehy provide in ther own tuning files
13:22:55 zigo Or should I just extract it from the existing nova.conf stuff?
13:23:52 sean-k-mooney zigo: what we were suggeting to do for the rpms was have an update script that copied the nova.conf to nova-compute.conf adn then use sed or curidini to remove the db sections
13:24:14 sean-k-mooney but if we go with the seperate files for db
13:24:31 sean-k-mooney then both would work generating only really works for new installs
13:24:46 zigo sean-k-mooney: I'm generating the files when building the package...
13:24:49 sean-k-mooney for upgrades of the package you kind of need to extract
13:25:11 sean-k-mooney generating the files is fine but only on a fresh install right
13:25:21 sean-k-mooney you dont want an apt udpate to nuke your files
13:25:39 zigo https://salsa.debian.org/openstack-team/services/nova/-/blob/debian/victoria/debian/rules#L75
13:26:26 zigo The packages don't take care of the upgrades (yet). So it will simply do nothing to the existing nova.conf file when upgrading.
13:26:27 sean-k-mooney oh right but thats just the copy in /usr/share
13:26:31 sean-k-mooney not the /etc/ ones
13:26:43 zigo Yeap, but postinst writes in /etc/nova if the file isn't there.
13:27:03 sean-k-mooney yep i was refing to a postinst script
13:27:06 zigo I'm doing like that to avoid the file being a CONFFILE and getting annoying config file update prompts at upgrade time.
13:27:18 sean-k-mooney for the /usr/shar just generating the db config would be fine
13:27:49 sean-k-mooney ah ya the do you want to accpet the package mainters version one?
13:49:40 Luzi Hi I have a question concerning the SHELVED state: When I try to shelve two instances (one image-based the other volume-based) only the image-based goes into the SHELVED state. The volume based instance is offloaded despite having set the config option shelved_offload_time to 3000
13:50:37 Luzi why do they behave different?
13:54:12 sean-k-mooney likely because teh bfv instance does not have state on the host
13:54:24 sean-k-mooney so its more or less free to resume
13:54:49 sean-k-mooney the intermite shelved state is really just an optimisation for instance with local disks
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 Luzi it makes sense to directly go into the offloaded state, so imho it would just need some fixed documentation.
14:08:26 sean-k-mooney basically move that first if into shelve
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 openstackgerrit Ghanshyam Mann proposed openstack/nova master: [WIP] Migrate nova-grenade-multinode job to zuulv3 native https://review.opendev.org/742056
14:42:15 mgariepy any nova core avalaible to review: https://review.opendev.org/#/c/758760/ ?
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

Earlier   Later