| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-01-11 | |||
| 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 | gmann | and yes we need spec for that | |
| 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: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 | |
| 09:21:06 | sean-k-mooney | EugenMayer: the primay uage of lock is to prevent normal users starting or stoping a vm | |
| 09:21:19 | sean-k-mooney | admins can always bypass it as you have found | |
| 11:12:26 | opendevreview | Ilya Popov proposed openstack/nova master: Fix to implement 'pack' or 'spread' VM's NUMA cells https://review.opendev.org/c/openstack/nova/+/805649 | |
| 12:25:19 | opendevreview | Merged openstack/nova-specs master: libvirt: Allow Manila shares to be directly attached to instances https://review.opendev.org/c/openstack/nova-specs/+/813180 | |
| 13:28:23 | opendevreview | Merged openstack/os-traits master: Updating python testing classifier as per Yoga testing runtime https://review.opendev.org/c/openstack/os-traits/+/819205 | |
| 14:13:51 | opendevreview | Jonathan Race proposed openstack/os-traits master: Adds Pick guest CPU architecture based on host arch in libvirt driver support https://review.opendev.org/c/openstack/os-traits/+/824050 | |
| 14:20:12 | opendevreview | Jonathan Race proposed openstack/nova master: Adds Pick guest CPU architecture based on host arch in libvirt driver support https://review.opendev.org/c/openstack/nova/+/822053 | |
| 14:36:31 | opendevreview | yuval proposed openstack/nova-specs master: lightos volume driver spec https://review.opendev.org/c/openstack/nova-specs/+/824191 | |
| 14:40:36 | opendevreview | Jonathan Race proposed openstack/os-traits master: Adds Pick guest CPU architecture based on host arch in libvirt driver support https://review.opendev.org/c/openstack/os-traits/+/824050 | |
| 14:40:59 | opendevreview | Jonathan Race proposed openstack/nova master: Adds Pick guest CPU architecture based on host arch in libvirt driver support https://review.opendev.org/c/openstack/nova/+/822053 | |
| 15:14:23 | bauzas | reminder: nova meeting starts in 45 mins here at #openstack-nova | |
| 15:18:38 | gibi | melwitt: Hi! Happy New Year! if you have time, could you look at this placement spec please https://review.opendev.org/q/topic:any-traits-support ? | |
| 15:20:24 | sean-k-mooney | gibi i tought that was approved? | |
| 15:20:56 | sean-k-mooney | oh its not ok | |
| 15:21:42 | sean-k-mooney | then yes it woudl be useful for the emulation feature too | |
| 15:22:38 | sean-k-mooney | so we can say give me a host with HW_ARCH_X86_64 or COMPUTE_ARCH_X86_64 | |
| 15:23:16 | bauzas | gibi: I need to get my car back, in case I'm not there on time, could you start the meeting ? | |
| 15:23:27 | bauzas | gibi: I wrote the agenda | |
| 15:28:49 | gibi | bauzas: sure | |
| 15:28:51 | gibi | no worries | |
| 15:29:58 | gibi | sean-k-mooney: yeah I saw the discussion around the emulation and I agree that needs OR relationship for traits | |
| 15:39:53 | yuval | Hey, the nova meeting, on which channel is it? | |
| 15:41:22 | gibi | yuval: it will be here in this channel from the top of the hour | |
| 15:41:38 | yuval | ok thanks | |
| 15:51:57 | gibi | gmann: if you have time could you look at the qos tempest tests https://review.opendev.org/c/openstack/tempest/+/806257 ? | |
| 15:55:05 | gmann | gibi: sure, I started it yesterday but could not finish. let me review today | |
| 15:55:17 | gibi | gmann: thanks a lot! | |
| 15:58:57 | bauzas | I'm here | |
| 15:59:05 | bauzas | nova meeting starting in 1 min | |
| 15:59:27 | Uggla | \o/ | |
| 16:00:00 | opendevmeet | The meeting name has been set to 'nova' | |
| 16:00:00 | opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | |
| 16:00:00 | opendevmeet | Meeting started Tue Jan 11 16:00:00 2022 UTC and is due to finish in 60 minutes. The chair is bauzas. Information about MeetBot at http://wiki.debian.org/MeetBot. | |
| 16:00:00 | bauzas | #startmeeting nova | |
| 16:00:09 | gibi | \o | |