Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2021-03-19
09:57:04 gibi OK I can accept the reasoning that the end user should know if the cloud support @ in the name and the way to publis that informatin is via the /version endpoint telling the max supported microversion
09:57:18 Corwin a script should always work on one microversion regardless of the service provider
09:58:06 bauzas gibi: I guess we unique index the keynames ?
09:58:21 bauzas (I'm lazy and you already opened the code :p )
09:58:31 gibi name="uniq_key_pairs0user_id0name0deleted"),
09:58:31 gibi schema.UniqueConstraint("user_id", "name", "deleted",
09:58:31 gibi __table_args__ = (
09:58:34 gibi )
09:58:46 bauzas that will be fun
09:58:47 gibi so yes
09:58:48 gibi per user
09:59:04 bauzas "I don't understand why Nova isn't accepting my keyname, boo"
09:59:13 gibi bauzas: it is already like that
09:59:17 bauzas I know
09:59:23 gibi we dont change the uniqueness constraint
09:59:26 bauzas but users had to name it explicitely
09:59:37 Corwin that doesn't change
09:59:46 bauzas here, we will open a way to automatically use the comment for creating the keypair
09:59:56 bauzas but, heh
10:00:14 Corwin that's a issue for the service provider, not nova
10:00:14 gibi we allow more flexibility yes, but not ultimate flexibility
10:00:30 bauzas sure
10:01:11 bauzas provided we don't have some folks asking to automatically create the keypair by looking up the public key :)
10:01:33 gibi that would be a separate bp :)
10:01:42 bauzas oh sure and my -1 to it
10:02:01 bauzas either way, looks like we're in violent agreement
10:02:08 gibi nautik: so based on the above discussion your change will need a new API microversion
10:02:20 gibi nautik: let me link to some documentation about it
10:02:37 gibi nautik: and that also means you need to file a small specification document in the nova-specs repo
10:03:28 gibi bauzas: Corwin: thanks!
10:03:28 nautik gibi: ok sure
10:04:20 gibi name="uniq_key_pairs0user_id0name0deleted"),
10:04:20 gibi schema.UniqueConstraint("user_id", "name", "deleted",
10:04:20 gibi nautik: __table_args__ = (
10:04:23 gibi )
10:04:26 gibi sorry
10:04:38 gibi nautik: https://docs.openstack.org/nova/latest/contributor/blueprints.html
10:04:54 bauzas gibi: this could have been getting way worst :p
10:05:03 gibi bauzas: yeah I know
10:05:59 gibi nautik: https://opendev.org/openstack/nova-specs/src/branch/master/specs/wallaby-template.rst
10:06:02 gibi this is the spec template
10:07:18 gibi bauzas: could you hit this patch creating the xena spec directory and template? https://review.opendev.org/c/openstack/nova-specs/+/772878
10:07:44 gibi nautik: after ^^ merges, there will be a directory for the xena specs
10:08:50 gibi nautik: this helps about how to add a new microversion to nova https://docs.openstack.org/nova/latest/contributor/microversions.html
10:09:03 bauzas gibi: /me clicks
10:09:41 nautik gibi: thank you, will check this asap :)
10:10:15 gibi nautik: if you get stuck with the spec template or hte implementation just ask here and we will help
10:10:38 gibi once the spec is up on review you can ping me and bauzas to take a look
10:11:09 nautik will do
10:11:15 bauzas yup
10:20:29 openstackgerrit Merged openstack/nova-specs master: Create specs directory for Xena https://review.opendev.org/c/openstack/nova-specs/+/772878
10:30:29 lyarwood gibi: sorry ssh dropped without me noticing, I don't think there was anything else, tbh my reason for chatting with you was to ensure you were still okay pushing it through ahead of rc
10:31:33 gibi lyarwood: if I get the time to fix up the thing then yes
10:31:42 gibi lyarwood: it is a bit risk change though
10:31:59 gibi lyarwood: so I could also accept if we wait until after the release
10:39:06 lyarwood gibi: yeah it's really your call as author and PTL, we could backport it in the future once proven to work in X I guess?
10:40:14 gibi lyarwood: how risky this change looks from your perspective?
10:41:52 lyarwood gibi: on the face of it, not very risky but then we are so close to rc that I'm not sure it's worth any risk at the moment
10:42:26 lyarwood gibi: given the alternative to wait until Xena opens up and we then have ~6 months to verify things
10:43:33 gibi I think the backport from early Xena to W will be easy, backporting further could be harder
10:43:39 lyarwood it's tough, I really want this rework but at the same time I don't want us to bork things just before the release
10:44:11 lyarwood with my downstream hat on an upstream backport just to Wallaby would be awesome
10:44:35 lyarwood additional backports would also be nice but that's something I can take on
10:44:47 lyarwood if it's even possible obviously
10:45:05 gibi OK, lets see if I can have time for finishing up the series today
10:46:40 lyarwood gibi: sorry I thought we had talked ourselves into delaying until X
10:47:16 lyarwood gibi: but I guess if you have time now we can get it ready ahead of that, but don't burn yourself with it if you have other more pressing work.
10:48:47 gibi lyarwood: I lean towards delaying but if I have time I will make progress
11:43:42 openstackgerrit Lee Yarwood proposed openstack/nova master: compute: Reject requests to commit intermediary snapshot of an inactive instance https://review.opendev.org/c/openstack/nova/+/781138
13:55:51 gmann gibi: bauzas stephenfin yes, this is changing 400->200 which break interopability and cross cloud migration., hence need microversion bump.
14:11:54 kashyap Gerrit bot is down?
14:12:21 kashyap stephenfin: For later, since you asked so nicely on the original review: https://review.opendev.org/c/openstack/nova/+/781725
14:12:33 stephenfin ack
14:14:04 gibi gmann: ack
14:23:28 stephenfin Oh, this is fun https://review.opendev.org/c/openstack/nova/+/781210
14:23:37 stephenfin So we broke the Aarch64 CI, but I have no idea how
14:23:52 stephenfin Hopefully ricolin will get back to us on that
14:24:21 stephenfin I suspect the metadata files are missing for some reason
14:24:27 stephenfin kashyap: FYI ^
14:25:37 kashyap stephenfin: Yeah, I don't have an AArch64 box; but 'hrw' (not here on IRC right now) did talk about AArch64 failures
14:25:48 kashyap So I hope indeed ricolin gets back w/ more precise details of the nature of the failure
14:28:28 kashyap stephenfin: BTW, aside: upstream libvirt began implementing your RFE. I was reviewing bits of this series: https://listman.redhat.com/archives/libvir-list/2021-March/msg00922.html
14:28:33 kashyap (About firmware auto-selection)
14:28:42 stephenfin aha, very good
14:29:10 stephenfin if you're following that, some WIP patches for nova that implement the libvirt feature would be helpful to make sure we don't forget
14:29:49 kashyap stephenfin: Yeah, but it still needs some more review. And I noticed a potential confusion in my review earlier today: https://listman.redhat.com/archives/libvir-list/2021-March/msg00982.html
14:29:58 jkulik Any idea why `osc-placement` doesn't include versions after 1.28?
14:30:04 kashyap stephenfin: But I agree
14:30:12 stephenfin jkulik: Is there a version after 1.28
14:30:13 stephenfin ?
14:30:20 stephenfin Genuine question :)
14:30:27 stephenfin If there is, I suspect we simply haven't added it
14:31:21 jkulik 1.28 was added for ussuri. 1.29 is supported in rocky ... O.o
14:31:29 jkulik https://github.com/openstack/osc-placement/blob/master/osc_placement/version.py#L41
14:32:20 jkulik I cannot run "os --os-placement-api-version 1.30 allocation candidate list" because it only knows how to do versions 1.28 and below ...
14:32:32 jkulik placement version 1.30 is not in supported versions: 1.0, 1.1, 1.2, 1.3, 1.4, 1.5, 1.6, 1.7, 1.8, 1.9, 1.10, 1.11, 1.12, 1.13, 1.14, 1.15, 1.16, 1.17, 1.18, 1.19, 1.20, 1.21, 1.22, 1.28, 1.29
14:33:16 stephenfin In that case, I assume it's just a case that people haven't done it
14:33:17 jkulik so no allocation requests with providers in trees with osc-placement
14:33:30 stephenfin Due to lack of impetus
14:33:48 jkulik hm ... makes sense. no real reason, then :D

Earlier   Later