| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-01-11 | |||
| 00:27:39 | sean-k-mooney[m] | then must have small disk footprint then must not really be any slower then cirros | |
| 00:27:41 | clarkb | as of version 2020.79 | |
| 00:27:46 | sean-k-mooney[m] | yep | |
| 00:27:56 | sean-k-mooney[m] | the version in the cirros image is just too old | |
| 00:27:59 | clarkb | I think frickler mentioned that a new cirros is in the works though | |
| 00:28:06 | sean-k-mooney[m] | so alpine with dropbear would be nice | |
| 00:28:51 | sean-k-mooney[m] | i mean thats also an option buy if frikler does i hope they also update the kernel to something form this decade | |
| 00:29:27 | sean-k-mooney[m] | i think cirros is still using a ubuntu 18.04 kernel | |
| 00:30:02 | sean-k-mooney[m] | it might be from 20.04 but its several years out of date in anycase | |
| 00:30:11 | clarkb | I'm not super familiar with cirros build tooling but I think last I looked you get an entirely new user space when you update busybox to get a new dropbear | |
| 00:30:18 | clarkb | and when you do that chances of needing an ew kernel are much higher too | |
| 00:30:44 | clarkb | I would be surprised if it wasn't a comprehensive update. But also if not updating the kernel as a subsequent step is probably not terrible | |
| 00:30:49 | clarkb | one step at a time and all that | |
| 00:31:06 | sean-k-mooney[m] | the current one has a bug that we ocationally hit | |
| 00:31:33 | sean-k-mooney[m] | its patched in later version of that kernel in ubuntu but not in the specific point release they have imported | |
| 00:32:09 | sean-k-mooney[m] | ya they skip updating the kernel the last time they rebuilt for somethign we needed so hopefully they will do it this time | |
| 00:33:13 | sean-k-mooney[m] | clarkb i just generally like the idea of using something more mainstream but on the other hand its worked well for us for a long time so i dont dislike cirros just its update cadence | |
| 00:33:34 | clarkb | ya, but also frickler seems to be working on solving those problems so I'm happy to defer to epople doing the work :) | |
| 00:33:46 | clarkb | the good thing about cirros is its a proven system that works while still being tiny | |
| 00:34:02 | clarkb | whittling something else down could be significant work and as far as I know no one is doing that work (unlike with frickler and cirros) | |
| 00:34:12 | sean-k-mooney[m] | so one option i think woudl be more viable would be to update nova ssh keygen to use ecrsa unconditioanlly | |
| 00:35:15 | clarkb | There is a problem with that: ecdsa isn't considered secure by many beacuse it relies on magic from NIST | |
| 00:35:25 | sean-k-mooney[m] | clarkb well alpine because of its embeded and contaienr focus is the only thing that comes close form off the shelf solutions | |
| 00:35:39 | sean-k-mooney[m] | clarkb well that depend on the curve | |
| 00:35:40 | clarkb | FIPS is on board with it, but you might notice there is a conflict of interest between the people making FIPS and NIST :) | |
| 00:35:54 | sean-k-mooney[m] | no one should use the nist curve | |
| 00:36:41 | clarkb | I don't think there is another kind that ssh-keygen emits? | |
| 00:36:51 | clarkb | ecsda as supported by fips is the curve that nist magic'd | |
| 00:37:02 | clarkb | (there are other eliptic curve algorithms but fips doesn't support them) | |
| 00:37:21 | sean-k-mooney[m] | Ed25519 is not allowed? | |
| 00:37:24 | clarkb | it is not | |
| 00:38:11 | sean-k-mooney[m] | oh well personally im not really comfrotable with default to the nist curve so ignorem my previous suggestion | |
| 00:38:34 | sean-k-mooney[m] | i was assuming we would only enable Ed25519 | |
| 00:39:45 | ade_lee | ed25519 is in proposed fips standard but hasn't been accepted yet, so it wont work for fips now | |
| 00:39:46 | fungi | not allowed by current fips standards, but slated for inclusion in the "near" future (for usa gubment definitions thereof) | |
| 00:39:56 | fungi | yeah, what ade_lee said | |
| 00:40:45 | sean-k-mooney[m] | ack | |
| 00:40:50 | fungi | it may be prudent, tinfoil hat on, to assume that means the nsa has only recently figure out how to break ed25519 ;) | |
| 00:42:03 | sean-k-mooney[m] | rsa 4096 with sha2 i think is till the best generally compatible ssh key you can generate today | |
| 00:42:21 | sean-k-mooney[m] | which i still need to do later this week actully | |
| 00:42:45 | fungi | agreed, except for all those half-baked sshds that serve up rsa host keys with sha-1 signatures (to the case in point) | |
| 00:42:54 | clarkb | the sha1/sha2 stuff is handled during protocol negotiation and not key generation time fwiw | |
| 00:43:28 | clarkb | I really really wish that the clients whould just force sha2 for those sshds that can sha2 but don't advertise it | |
| 00:43:32 | clarkb | like gerrit | |
| 00:43:45 | sean-k-mooney[m] | yep | |
| 00:44:05 | sean-k-mooney[m] | i tried doing that in my ssh config but could not get it to work | |
| 00:44:38 | sean-k-mooney[m] | well forcing sha2 and enabling sha 1 but just failed | |
| 00:44:51 | sean-k-mooney[m] | i could proably get it to work but was not worht the time | |
| 00:46:08 | clarkb | ya I converted to ed25519 and called it a day | |
| 00:46:49 | sean-k-mooney[m] | i was actully reading https://blog.peterruppel.de/ed25519-for-ssh/ earlier today | |
| 00:48:07 | ade_lee | so -- for fips testing, then, it sounds like - unless we can update or change cirros - the best short term solution is allowing ecdsa - and we'd prefer to generate the key in tempest? | |
| 00:49:13 | sean-k-mooney[m] | yes that would be my preference | |
| 00:49:30 | ade_lee | gmann, ^^ | |
| 00:49:44 | sean-k-mooney[m] | generating in tempest would also be useful for downstream osp 17 testing based on wallaby | |
| 00:49:58 | sean-k-mooney[m] | ade_lee we would not backport the nova ssh key generation downstream | |
| 00:50:13 | sean-k-mooney[m] | we never backport api changes downstream | |
| 00:50:40 | ade_lee | ack, then the tempest change would be preferable for sure | |
| 00:54:17 | fungi | ideally, we'd generate the ssh-rsa keys in tempest too, and nova would slap a big red "deprecated" on its server-side key generation api | |
| 00:56:34 | sean-k-mooney[m] | gmann deprecation is not an api change right from a micorversion point of view | |
| 00:56:57 | sean-k-mooney[m] | so we could just propos a patch to update the docs to do that ? | |
| 00:57:25 | sean-k-mooney[m] | the removal would be an api change | |
| 00:57:38 | sean-k-mooney[m] | so that would need a spec | |
| 00:58:43 | sean-k-mooney[m] | honestly i would be ok with doing the deprecation and removing in a later microversion but keeping the code to support the older micro verions | |
| 00:59:26 | sean-k-mooney[m] | you should not really use it but it cost use very little to leave the code there for backwards compatiblity | |
| 01:37:54 | fungi | with my vmt/security wonk hat firmly affixed, i'd be fine deprecating it and never getting around to removing it. just so long as its use is discouraged | |
| 01:40:53 | gmann | ade_lee: yeah generating in tempest and testing is always ok/more coverage irrespective of nova auto generate or not | |
| 01:43:44 | gmann | sean-k-mooney[m]: no, we have to do with microversion. | |
| 01:44:27 | gmann | it will be like <=2.xx microversion it will work as it is and >2.xx this will return 404, 400 or something | |
| 01:44:45 | gmann | removing is not possible until we bump the minimum microversion | |
| 01:45:04 | gmann | that is how we deprecate the API in nova | |
| 01:45:27 | sean-k-mooney[m] | we have to have the microversion for the removal os generating the key yes but to deprecate it with out any other change we dont | |
| 01:45:27 | gmann | and yes we need spec for that | |
| 01:45:35 | sean-k-mooney[m] | e.g. just a docs update | |
| 01:46:09 | gmann | ohk you mean just auto generation part | |
| 01:46:23 | gmann | in that case, removal is possible yes and with microversion | |
| 01:46:38 | sean-k-mooney[m] | and ya since we still woud have the code for < 2.x a 400 would be correct | |
| 01:46:44 | gmann | but deprecation is again I will say need microversion for notification at least | |
| 01:46:49 | sean-k-mooney[m] | the same endpoint is used for create and import too | |
| 01:47:03 | sean-k-mooney[m] | so we would still support import in the new verion just not create | |
| 01:47:13 | sean-k-mooney[m] | its a http post in both cases i belive | |
| 01:47:26 | sean-k-mooney[m] | with differnt body for create vs import | |
| 01:47:35 | gmann | we cannot return 400 directly without version bump as it will break users who are curently getting 200 success case and then will get 400 | |
| 01:48:02 | gmann | it is behavior change not just about return code | |
| 01:48:43 | sean-k-mooney[m] | yep im not suggesting returnnign a 400 without a new microversion | |
| 01:48:48 | gmann | so we can directly remove the auto generation of key in microversion and keep supporting for old microversion | |
| 01:48:56 | sean-k-mooney[m] | yep | |
| 01:48:59 | gmann | no need for deprecation | |
| 01:49:25 | sean-k-mooney[m] | i spoke of deprecation becasue i dont know if we will get arount to it this cycle | |
| 01:49:49 | sean-k-mooney[m] | so more a reminder to us and warning to users that we might remove it next cycle | |
| 01:50:08 | sean-k-mooney[m] | but we could also just add it to your api cleanup etherpad | |
| 01:50:44 | gmann | sure, putting something in api-ref like 'this is not recommended to use' and later with microversion can amend that with 'not supported >2.xx' | |
| 01:50:53 | gmann | +1 | |
| 01:51:45 | sean-k-mooney[m] | ok i really should try and go to sleep so ill chat to ye tomorrow o/ | |
| 01:52:49 | gmann | sean-k-mooney[m]: done. | |
| 01:52:58 | gmann | sean-k-mooney[m]: yeah, me too. GN | |
| 01:53:49 | opendevreview | Merged openstack/nova stable/victoria: Ensure MAC addresses characters are in the same case https://review.opendev.org/c/openstack/nova/+/816927 | |
| 07:00:21 | EugenMayer | Hello, experimenting with the "lock" feature. It seems that lock does not protect against deletion, against what does it protect then? Is there anything like a protected flag in openstack which protects particular instances form deletion? | |
| 07:01:34 | EugenMayer | Ah i see https://platform9.com/kb/openstack/can-i-lock-preserve-instance-from-deletion - admins can always delete. So i need somewhat of a different user, interesting | |
| 09:11:26 | lyarwood | EugenMayer: yeah see https://docs.openstack.org/api-ref/compute/?expanded=lock-server-lock-action-detail#lock-server-lock-action for more details | |
| 09:11:44 | lyarwood | and https://docs.openstack.org/api-guide/compute/server_concepts.html#server-actions | |