| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-11-17 | |||
| 17:13:20 | lyarwood | sean-k-mooney: why? Wouldn't that be covered by LM | |
| 17:13:34 | sean-k-mooney | yes kind of | |
| 17:13:59 | sean-k-mooney | it more we want to pin the new host to the old verion untill the rolling upgrade is complete | |
| 17:14:00 | sean-k-mooney | i think | |
| 17:14:19 | sean-k-mooney | so that we can technically migrate form new to old if we need too eventhough we say dont do that | |
| 17:14:39 | sean-k-mooney | changing the machine_type is ment to be a post upgrade step | |
| 17:14:49 | lyarwood | well you could still technically do that with FFU | |
| 17:15:12 | lyarwood | actually no you couldn't ignore me | |
| 17:15:28 | lyarwood | and agreed with post upgrade for changing default machine types | |
| 17:16:11 | kashyap | A factor to consider: if you track the unversioned 'pc' or 'q35', it always aliases to the latest available versioned machine type on the box. | |
| 17:16:29 | sean-k-mooney | from a donwstream point of view what we said was new installs should use the new default, existing installs should be upgrade with the old default then the default shoudl be changed as a post upgrade action | |
| 17:17:26 | sean-k-mooney | kashyap: yes but if you have not express an opipion in the image and the config is either unset or set to the aliase i think that is the right thing to track anyway | |
| 17:17:45 | kashyap | sean-k-mooney: Yep, that I agree with. | |
| 17:17:55 | sean-k-mooney | the edge case is if you have a versioned machine type in the config | |
| 17:18:06 | sean-k-mooney | i was suggesting recodign that | |
| 17:18:18 | sean-k-mooney | but then we cant really allow it to change on hard reboot | |
| 17:18:30 | lyarwood | it wouldn't | |
| 17:18:33 | sean-k-mooney | it would have to be resize or rebuld only | |
| 17:18:54 | sean-k-mooney | maintain the machine type on cold or live migate | |
| 17:18:55 | lyarwood | if a versioned machine type is recorded the only way to change it would be with a rebuild | |
| 17:19:14 | sean-k-mooney | lyarwood: only rebuild or rebuild/resize | |
| 17:19:26 | lyarwood | sean-k-mooney: rebuild/resize sorry | |
| 17:19:37 | sean-k-mooney | so the elephant in the room | |
| 17:19:41 | sean-k-mooney | what about evacuate | |
| 17:19:41 | lyarwood | sean-k-mooney: actually can you proivide the machine type via a flavor | |
| 17:19:49 | sean-k-mooney | lyarwood: no | |
| 17:19:54 | sean-k-mooney | but we could | |
| 17:19:57 | lyarwood | sean-k-mooney: then just rebuild | |
| 17:20:05 | sean-k-mooney | that does not work then | |
| 17:20:09 | sean-k-mooney | rebuild is distructive | |
| 17:20:09 | lyarwood | sean-k-mooney: and evacuate uses rebuild | |
| 17:20:21 | sean-k-mooney | and for secuity reason we do need a way to change this | |
| 17:20:34 | sean-k-mooney | which is one of the reason i had recreate | |
| 17:20:40 | lyarwood | well that's no different to the situation we are in today | |
| 17:21:01 | sean-k-mooney | no today you jsut change the config option and hardreboot | |
| 17:21:13 | lyarwood | that a user has no access to | |
| 17:21:21 | sean-k-mooney | or if its using the aliase just package update and reboot | |
| 17:21:25 | lyarwood | that's basically the same as a db update | |
| 17:21:35 | sean-k-mooney | it is yes | |
| 17:21:42 | sean-k-mooney | we need a way for an admin to update it | |
| 17:21:46 | sean-k-mooney | that is not a db update | |
| 17:21:47 | lyarwood | if you're using an alias it's just a hard reboot with the new approach still | |
| 17:21:50 | sean-k-mooney | we dont need a way for a user | |
| 17:22:04 | sean-k-mooney | lyarwood: yep which is why i like aliasis amoung other things | |
| 17:22:12 | sean-k-mooney | lyarwood: what about a nova manage command | |
| 17:22:26 | lyarwood | sean-k-mooney: yup that could work | |
| 17:22:33 | sean-k-mooney | to update the machine type in a suppotable way | |
| 17:23:11 | sean-k-mooney | ideally support either the instance uuid/uuids or a host | |
| 17:23:35 | lyarwood | but it still looks like we can't enumerate all of the possible machine types so I'm back to using a StringField | |
| 17:23:42 | lyarwood | gah | |
| 17:23:50 | sean-k-mooney | well ya its a sting filed | |
| 17:23:56 | sean-k-mooney | they are different per disto | |
| 17:24:02 | lyarwood | yup | |
| 17:24:05 | sean-k-mooney | and you can add your own by just adding a file | |
| 17:24:35 | lyarwood | I indeeed, right need to help with childcare and then I'll update the spec | |
| 17:24:37 | sean-k-mooney | i know some people have done that to work around some default in the past realted to >2TB vms | |
| 17:24:48 | lyarwood | thanks stephenfin, kashyap, sean-k-mooney! | |
| 17:36:32 | ralonsoh | sean-k-mooney, just a heads-up: https://review.opendev.org/740067 | |
| 17:36:50 | sean-k-mooney | oh nice | |
| 17:37:02 | sean-k-mooney | so now just the nova bit | |
| 17:37:08 | sean-k-mooney | thanks | |
| 17:37:37 | sean-k-mooney | ralonsoh: ill respin https://review.opendev.org/#/c/760047/ this week hopefully too | |
| 17:37:55 | ralonsoh | sean-k-mooney, perfect! | |
| 17:42:20 | gibi | o/ | |
| 17:58:33 | stephenfin | dansmith: Is there any way to identify what images have been cached for an aggregate? | |
| 17:58:40 | stephenfin | Assuming such a request even makes sense? | |
| 17:59:09 | dansmith | stephenfin: no, the caching thing is all point-in-time requests, akin to asking for boots that don't end up spawning actual instances | |
| 17:59:16 | dansmith | so no accounting or recording | |
| 18:00:27 | stephenfin | okay, so not displaying anything in response to an 'openstack aggregate cache image' call makes sense? | |
| 18:00:52 | stephenfin | e.g. there's no point showing the aggregate since nothings has "changed" | |
| 18:01:10 | dansmith | like a table of data or something? no, nothing to display. obviously if it returns 404 because there's no aggregate or something an error makes sense | |
| 18:01:19 | dansmith | right, no point in showing the image or aggregate, IMHO | |
| 18:01:46 | stephenfin | dansmith++ great, thanks :) | |
| 18:02:10 | dansmith | from context it sounds like you're ...cool | |
| 18:02:34 | dansmith | stephenfin: in case you hadn't seen it, I had good intentions: https://review.opendev.org/#/c/688960/ | |
| 18:02:37 | dansmith | but never followed through because I suck | |
| 18:07:19 | stephenfin | thankfully gtema is a machine 🤗 | |
| 23:18:58 | rm_work | hey, what config does nova-manage pull the db connection stuff from by default? is it /etc/nova.conf? | |
| 23:19:04 | rm_work | err, /etc/nova/nova.conf | |
| 23:19:17 | rm_work | it seems to not be respecting all of the sql connection config | |
| 23:19:47 | rm_work | we use x509 auth for our sql connection, which is in the connection string in nova.conf as &ssl_cert=...&ssl_key=... | |
| 23:20:08 | rm_work | which works for the actual service, but the nova-manage db stuff doesn't seem to use it correctly | |
| 23:23:30 | rm_work | yeah, verified even with the config explicitly set, it's not respecting the x509 args, so the db migration scripts fail on the sql connection | |
| 23:28:20 | rm_work | hmmm, well that was my assumption, but maybe it's actually that it is missing some other sql permission? trying to dig in deeper, I just know I get this error when it tries to run `_get_marker_for_migrate_instances` | |
| 23:28:56 | rm_work | `(pymysql.err.OperationalError) (1045, "Access denied for user 'nova'@'sqlhost' (using password: YES)")` | |
| 23:29:29 | rm_work | but it does seem to be able to get SOME data, as it printed some numbers about the migration counts correctly | |
| #openstack-nova - 2020-11-18 | |||
| 00:10:52 | rm_work | ahh figured it out | |
| 00:11:15 | rm_work | the nova_api DB stores cell connection strings that need to be updated if the connection string changes at all | |
| 00:11:29 | rm_work | this seems a little awkward? but I assume it is necessary for some reason to cache this data here | |
| 00:13:50 | artom | rm_work, if you're familiar with why and how cells v2 came about, it makes sense | |
| 00:15:13 | rm_work | yeah so if we cycle the DB password, or the certs move, we need to make sure to update the cells first via `nova-manage cells_v2 update_cell` | |
| 00:19:07 | artom | rm_work, yep | |
| 03:12:44 | openstackgerrit | Brin Zhang proposed openstack/nova master: Cyborg shelve/unshelve support https://review.opendev.org/729563 | |
| 04:33:40 | openstackgerrit | Brin Zhang proposed openstack/nova-specs master: Remove tenant_id https://review.opendev.org/737241 | |
| 07:20:41 | openstackgerrit | Xinran WANG proposed openstack/nova-specs master: SRIOV Enabled Nic Support Specification https://review.opendev.org/742785 | |
| 08:04:33 | bauzas | good morning Nova | |
| 08:13:34 | tacco | Morning * | |
| 08:19:38 | gibi | o/ | |
| 08:32:20 | openstackgerrit | Balazs Gibizer proposed openstack/nova stable/victoria: Add upgrade check about old computes https://review.opendev.org/761924 | |
| 08:32:27 | openstackgerrit | Balazs Gibizer proposed openstack/nova stable/victoria: Improve error handling during service level check https://review.opendev.org/762471 | |