| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-03-19 | |||
| 09:46:15 | gibi | bauzas: good question about the db | |
| 09:46:17 | gibi | looking | |
| 09:46:36 | gibi | name = Column(String(255), nullable=False) | |
| 09:46:40 | gibi | db will accept it | |
| 09:47:05 | bauzas | so it's purely an API restriction ? | |
| 09:47:20 | gibi | the thing that will not work is a script that relies on this proposed change using @ in the names, towards a cloud that does not have this change | |
| 09:47:30 | bauzas | what this blueprint is trying to fix ? | |
| 09:47:39 | bauzas | ah I see | |
| 09:47:43 | bauzas | the arobase case | |
| 09:47:46 | bauzas | and the dot one | |
| 09:48:12 | gibi | it is common to have an email address or a domain name in the keypair name | |
| 09:48:16 | bauzas | I see people wanting to use email adresses as keypair names :p | |
| 09:48:40 | bauzas | that, after the instance name... | |
| 09:48:44 | Corwin | bauzas: usually a public key will have a comment in the form of user@hostname | |
| 09:49:00 | Corwin | and hostname can be a fqdn, with dots in it | |
| 09:49:08 | bauzas | Corwin: you're working on clouds | |
| 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 | __table_args__ = ( | |
| 09:58:31 | gibi | schema.UniqueConstraint("user_id", "name", "deleted", | |
| 09:58:31 | gibi | name="uniq_key_pairs0user_id0name0deleted"), | |
| 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 | gibi | we allow more flexibility yes, but not ultimate flexibility | |
| 10:00:14 | Corwin | that's a issue for the service provider, not nova | |
| 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 | nautik | gibi: ok sure | |
| 10:03:28 | gibi | bauzas: Corwin: thanks! | |
| 10:04:20 | gibi | nautik: __table_args__ = ( | |
| 10:04:20 | gibi | schema.UniqueConstraint("user_id", "name", "deleted", | |
| 10:04:20 | gibi | name="uniq_key_pairs0user_id0name0deleted"), | |
| 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 | |