Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2020-11-12
13:22:24 sean-k-mooney not to use the disto config if you are using a intall tool
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

Earlier   Later