| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-11-12 | |||
| 12:04:04 | sean-k-mooney | you mean with the chron job | |
| 12:04:08 | stephenfin | yes | |
| 12:04:28 | sean-k-mooney | for osp at least that only deletes things older then 30 days | |
| 12:04:42 | stephenfin | Right, but its config specific. HTTP 404 isn't, by comparison | |
| 12:05:14 | stephenfin | and it works for multiple different services, so I think that's still the correct approach to use | |
| 12:05:18 | sean-k-mooney | ya anyway if you want to keep but its fine it just really felt like needless code duplication | |
| 12:05:48 | stephenfin | It probably is, but I think it's worth the cost compared to the complexity de-duplication would bring | |
| 12:06:07 | stephenfin | We could probably have an inner function not exposed to users. I'll take a look at that later | |
| 12:18:54 | openstackgerrit | Brin Zhang proposed openstack/nova master: [Trivial] Rename host/node to hostname/nodename in conductor manager https://review.opendev.org/762499 | |
| 12:41:19 | openstackgerrit | Daniel de Oliveira Pereira proposed openstack/nova master: [WIP] Avoid getting transport_url from config file when updating Cell0 https://review.opendev.org/762433 | |
| 12:55:18 | openstackgerrit | Brin Zhang proposed openstack/nova master: Cyborg shelve/unshelve support https://review.opendev.org/729563 | |
| 13:18:53 | zigo | sean-k-mooney: This will need a fix in puppet-openstack and OSA, that's my concern... | |
| 13:19:15 | openstackgerrit | Wenping Song proposed openstack/nova master: Change host to hostname https://review.opendev.org/762518 | |
| 13:19:22 | zigo | Which is why I'm insisting to say we should all go on the same direction (ie: all distro and config management), otherwise it's going to be a mess. | |
| 13:20:35 | sean-k-mooney | zigo: OSA does not need a fix | |
| 13:20:48 | sean-k-mooney | it already does the right thing and does not include the db creds | |
| 13:20:58 | zigo | sean-k-mooney: It depends how you see it, the version that uses packages does. | |
| 13:21:20 | sean-k-mooney | the version that uses package does not use the config form the packages | |
| 13:21:26 | sean-k-mooney | it still generate its own | |
| 13:21:27 | zigo | And anyways, it'd be nice if it was doing the same thing. | |
| 13:21:35 | zigo | Oh ... Ok. | |
| 13:22:08 | sean-k-mooney | i think that is fairly common practice | |
| 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 | |