Posted	Nick	Remark
#openstack-nova - 2021-03-19
09:49:15	bauzas	so users don't know the hosts
09:49:24	bauzas	this is irrelevant from this perspective
09:49:27	bauzas	hence the string
09:50:03	bauzas	and my ssh keynames don't have an arobase :)
09:50:25	Corwin	what I'm saying is that a lot of users will generate keypairs and name those after the comment in the public key
09:50:31	Corwin	or at least would want to
09:51:14	gibi	like when I upload my key to gerrit it also names after the comment
09:51:28	Corwin	github does this too
09:51:33	bauzas	for knowing where you created the key ?
09:51:40	bauzas	and from which user ?
09:52:01	Corwin	yes, it's the default behavior of a lot of services to pre-fill the name from the comment
09:52:38	bauzas	this comment comes from the fact ssh-keygen stupidely writes who created the key and where
09:52:51	bauzas	but that's stale information
09:53:02	bauzas	as you can create the key elsewhere and just use it for other things
09:53:12	Corwin	I know, but it doesn't really matter
09:53:42	bauzas	Corwin: you recognize that identifying a public key doesn't rely on matching the comment ?
09:53:54	Corwin	there is no reason to disable those characters though
09:53:57	bauzas	but rather on matching the key itself
09:54:06	Corwin	bauzas: I know how ssh works thanks
09:54:09	bauzas	as I could have N keys created with the same comment
09:54:15	gibi	bauzas: the machine protocol use the key itself but humans are bad at matching long strings by eye
09:54:31	bauzas	Corwin: sure, I'm just pointing that you could end up having multiple keys in Nova that would share the same name
09:54:35	bauzas	which doesn't help
09:55:21	Corwin	that would happen also without authorizing those 2 characters, it's still user input
09:55:36	bauzas	either way, we're digressing, I agree
09:55:41	bauzas	the question is not about the use case
09:55:52	bauzas	but whether this sounds interoperable
09:56:02	bauzas	and my guts tell me it's not so we need a microversion
09:56:20	Corwin	yep I think it would be better with a new microversion
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?

Earlier   Later