Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2021-07-08
21:09:59 opendevreview Rodrigo Barbieri proposed openstack/nova stable/stein: Error anti-affinity violation on migrations https://review.opendev.org/c/openstack/nova/+/800114
21:23:24 opendevreview Merged openstack/nova stable/wallaby: Move 'check-cherry-picks' test to gate, n-v check https://review.opendev.org/c/openstack/nova/+/797039
#openstack-nova - 2021-07-09
03:08:59 opendevreview Merged openstack/nova stable/victoria: Stop leaking ceph df cmd in RBD utils https://review.opendev.org/c/openstack/nova/+/791938
09:53:01 lyarwood melwitt: https://bugs.launchpad.net/nova/+bug/1931707 btw, that's the same issue as downstream right?
09:56:52 stephenfin lyarwood: gibi: With an operator-like hat on, is there any reason to keep the VERSION argument in 'nova-manage db sync [VERSION]' ?
09:56:59 stephenfin given we don't allow downgrades
09:57:10 stephenfin and you can't really run nova without the latest DB schema
09:58:33 sean-k-mooney stephenfin: my only resevation with removing it is if you want to do the migrations in batches
09:58:42 gibi stephenfin: I think stoping at an intermittent version, do some manual checks / fixes inconsistencies, then continue forward might make sense
09:59:00 sean-k-mooney thats basicaly what i was thinking
09:59:13 sean-k-mooney but if we did things correctly that should not be required
09:59:14 gibi yeah, also batching might make sense if there are heavy transformations
09:59:39 gibi if we never have bugs leading to db inconsistencies then yeah :D
09:59:54 sean-k-mooney stephenfin: with a down stream hat on i dont know if there are FFU cases where we would want to stop an an intermidite release
10:00:33 gibi what my empoyer do during Mitaka -> Victoria FFU is to stop at Pike and Train then go to Victoria
10:01:19 gibi sorry, stop at Newton and Pike
10:01:35 stephenfin okay, batching or step by step upgrades makes sense
10:01:45 sean-k-mooney we might want to stop on n+2 before n+3 to run some online migrations
10:02:10 stephenfin alembic allows us to separate migrations into those that expand (can be done online) and those that contract (requires downtime)
10:02:24 sean-k-mooney ya it does
10:02:34 stephenfin so we might be able to look at finally removing a lot of dead tables and columns in contract migrations
10:02:38 sean-k-mooney is it problematic to continue to supprot this
10:02:55 stephenfin is that a question or a statement?
10:03:15 sean-k-mooney a quetion is it difficult to support db sync version?
10:03:33 sean-k-mooney im wondering why you asked
10:03:36 stephenfin no, not at all
10:03:43 stephenfin I was just wondering if it's worth keeping
10:04:04 lyarwood Yeah I think it is, would avoid the need to ship every release for db migrations
10:04:04 sean-k-mooney ok personally i do not know if it really widely used. typically i would not expect it to be
10:04:26 stephenfin Well, it's slightly tricky. I'm not allowing people to select an sqlalchemy-migrate version. Only alembic ones
10:04:27 lyarwood if we kept a few releases in tree at once that is
10:04:30 sean-k-mooney lyarwood: well we dont drop the db migrations
10:04:48 stephenfin So you won't be able to select any of the migrations > Train, < Xena
10:04:59 stephenfin which I think is fine because they're all placeholders rn
10:05:11 lyarwood right the ones you squashed?
10:05:24 stephenfin I squashed everything up to Train
10:05:35 stephenfin we haven't had a real DB migration since then
10:05:58 sean-k-mooney their have been no db changes since train?
10:06:14 sean-k-mooney i was not aware of that.
10:06:21 stephenfin nope
10:06:52 stephenfin No API microversions in Victoria either. Sign of the times
10:06:52 sean-k-mooney so that tecnicaly mean a master api could talk to a train cell db
10:06:59 stephenfin Yup
10:08:00 stephenfin in theory we don't do contractions so a train API could talk to a master DB
10:08:04 stephenfin also
10:08:34 sean-k-mooney is the same true of the api db
10:08:44 stephenfin yes, afaik
10:08:52 sean-k-mooney good to know
10:20:08 lyarwood sean-k-mooney / stephenfin / gibi ; if you have time today could you take a look at these specs I'm trying to get over the line before spec freeze and my sick leave next week? https://review.opendev.org/c/openstack/nova-specs/+/799811 https://review.opendev.org/c/openstack/nova-specs/+/799624 https://review.opendev.org/c/openstack/nova-specs/+/799850
10:22:08 sean-k-mooney you have 3 :)
10:22:27 sean-k-mooney ah
10:22:49 sean-k-mooney yes i rememebr all 3 of them being discussed ill review them today
10:23:06 gibi lyarwood: I will check them out after lunch
10:28:47 lyarwood many thanks
10:30:05 lyarwood https://review.opendev.org/c/openstack/nova/+/799964 - we don't need a minor version bump on o.vo objects when adding new field values right?
10:30:58 lyarwood ^ this updated nova.virt.arch.ALL and caused the hashed version of a few o.vo objects to change
10:31:23 lyarwood but as it's just field values and not adding or removing actual attributes from the object I guess we just update the hash?
10:46:20 sean-k-mooney am we do not bump for compostion
10:46:36 sean-k-mooney so if a contained ovo change we dont need the bump the warping ovo
10:46:57 sean-k-mooney but let me look
10:47:25 sean-k-mooney we do need to backlevel the value in some cases
10:48:12 sean-k-mooney do we support armv6l
10:48:28 gibi lyarwood: yeah I think we need a minor bump for enum value. As the old compute will not handle the new enum value
10:48:29 sean-k-mooney i tought we were going to drop all 32bit arch support
10:48:42 sean-k-mooney gibi: for enuma yes
10:49:31 sean-k-mooney we back level the image proerties object for example anytime we bump an enuma field
10:50:10 gibi there is an Architecture enum that uses very similar values than https://review.opendev.org/c/openstack/nova/+/799964/2/nova/virt/arch.py#17
10:50:58 sean-k-mooney yes there is the current patch is not touching the objects just the virt code
10:51:10 lyarwood gibi: right, I've asked them to update that, it's using the values of nova.virt.arch.ALL that they have updated for the ALL attribute there that caused the test version failures
10:51:14 sean-k-mooney although i thinke we generate one form the ohter
10:51:32 sean-k-mooney lyarwood: well im not sure if wew shoudl be adding this however
10:51:47 lyarwood kk I didn't think it was 32 bit ./me looks
10:54:29 lyarwood hmm does it really matter if libvirt supports it?
10:54:35 sean-k-mooney i mean we can add it but im not sure if that is soemthing we want to support
10:55:15 sean-k-mooney i guess its fine to include if we want to enulate it in the future
10:55:23 sean-k-mooney just not as a host plathform
10:56:55 lyarwood Yeah indeed
10:57:33 sean-k-mooney with that said i did once try to get openstack running in a rasberry pi
10:58:02 sean-k-mooney proably quite doable now with the pi4
11:13:41 gibi lyarwood: if you add a sentence about locking / unlocking the instance during the connection update then I'm +2 on https://review.opendev.org/c/openstack/nova-specs/+/799624
11:20:00 gibi lyarwood: I left two questions in https://review.opendev.org/c/openstack/nova-specs/+/799850
11:24:52 gibi lyarwood: and I'm +2 with a micro nit on https://review.opendev.org/c/openstack/nova-specs/+/799811
11:25:18 gibi I can get back to these specs still today if you bump them
11:27:00 sean-k-mooney lyarwood: by the way this is still pending we shoudl proably implemaet that soone rather then later ill see if i can get back to that while your away
11:27:07 sean-k-mooney https://review.opendev.org/c/openstack/nova/+/774044
11:37:53 lyarwood gibi: ack looking
11:38:01 lyarwood sean-k-mooney: ack kk
11:39:03 sean-k-mooney am i would prefer if we made https://review.opendev.org/c/openstack/nova-specs/+/799811 more general
11:39:09 sean-k-mooney ill push my comments shortly
11:42:14 lyarwood sean-k-mooney: two issues with making it general, we'd have to work out the defaults for all of the image props if they aren't provided
11:42:51 lyarwood sean-k-mooney: and it's a load of work to validate all of the input compared to just targeting what we need at the moment
11:42:58 sean-k-mooney we dont need to recorod all of them but i want to allow updating all excptin the ones we know will break things
11:43:41 lyarwood tbh that's a seperate spec and thing to this
11:43:42 sean-k-mooney lyarwood: there are only 4 addtional ones i think we should be recordeing
11:44:43 opendevreview Lee Yarwood proposed openstack/nova-specs master: Add nova-manage commands to show and refresh connection_info https://review.opendev.org/c/openstack/nova-specs/+/799624
11:48:48 lyarwood gibi: re https://review.opendev.org/c/openstack/nova-specs/+/799850 - I thought policy was more for overall access to an API but if we can use it to also control the contents of the response then I don't see why we couldn't use it here as well.
11:51:47 gibi lyarwood: e.g. os_compute_api:os-instance-actions:events:details controls the detials of the actions and it is system reader by default
11:53:21 sean-k-mooney we also have a polciy to control if the extra specs of a flavor are show to normal users
11:55:17 lyarwood cool okay I'll copy that pattern then
11:57:38 sean-k-mooney lyarwood: comments pushed on https://review.opendev.org/c/openstack/nova-specs/+/799811

Earlier   Later