| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-11-12 | |||
| 11:23:49 | openstackgerrit | Brin Zhang proposed openstack/nova master: [Trivial] Rename host/node to hostname/nodename in conductor manager https://review.opendev.org/762499 | |
| 11:35:28 | stephenfin | sean-k-mooney1: replied | |
| 11:36:35 | sean-k-mooney1 | oh my nick is wrong on sec | |
| 11:43:19 | openstackgerrit | Brin Zhang proposed openstack/nova master: Cyborg shelve/unshelve support https://review.opendev.org/729563 | |
| 11:58:24 | sean-k-mooney | stephenfin: i have removed the -1 and reviewd the other i can accept adressing the inefficnies in a follow up to keep the inital patch less complex espically since you left the todo | |
| 11:58:35 | stephenfin | great, thanks :) | |
| 11:59:00 | sean-k-mooney | stephenfin: i dont think you need a wait_for_deletes that shoudl just call a more generialsed wait_for_statuses | |
| 11:59:34 | stephenfin | I could probably do that, yeah | |
| 11:59:41 | stephenfin | I'd have to keep wait_for_delete around though | |
| 12:00:11 | sean-k-mooney | is that not just calling wait_for_statuses with a list of 1 | |
| 12:00:24 | stephenfin | no, you need exception handling | |
| 12:00:40 | sean-k-mooney | right but you can add that to wait_for_statuses | |
| 12:00:41 | stephenfin | since a 404 is actually success (the resource has been deleted) | |
| 12:00:53 | sean-k-mooney | just default it to an empty list of allowed excptionts | |
| 12:01:07 | stephenfin | Right, but people are using 'wait_for_delete' in the wild | |
| 12:01:16 | stephenfin | so I'd have to keep the API for some time at least | |
| 12:01:24 | sean-k-mooney | oh ya keep the function | |
| 12:01:29 | sean-k-mooney | just rip out the logic | |
| 12:01:32 | sean-k-mooney | and delegate | |
| 12:01:40 | stephenfin | I think it's clearer as a separate function, tbh | |
| 12:01:44 | stephenfin | deleted isn't a status | |
| 12:01:58 | stephenfin | it's a binary condition | |
| 12:02:08 | sean-k-mooney | it is if you pass the flag to list deleted servers | |
| 12:02:42 | sean-k-mooney | stephenfin: no if you have not done archive and purge | |
| 12:02:51 | sean-k-mooney | you can see deleted servers form the api | |
| 12:03:32 | sean-k-mooney | you just do "openstack server list --deleted" | |
| 12:03:36 | stephenfin | for nova, yes | |
| 12:03:49 | stephenfin | it's racy though | |
| 12:03:52 | stephenfin | even for nova | |
| 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 | 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 | |