Thank you @Andrew for working on this! I tested the image today on the monitoring project and I'm happy to report that it works as advertised!

Here's what I did:

• Launch a new instance as usual via horizon
• Pick the debian-12.0-nopuppet image above
• Create a new key pair in the launch instance modal, in this case I asked for a brand new key pair to be generated and I've saved the private part locally
• Wait for the instance to be up and running (~70s) by looking at the console log
• Access as usual with ssh -l debian -i <private key file> <hostname>, verify the debian user has passwordless sudo

I'll also list wishlist items, which might be in the works already, below:

• Currently there's no way to delete key pairs or otherwise "manage" key pairs ? I was looking for an option e.g. under "compute" or "access" and couldn't find it
• From the console log (https://phabricator.wikimedia.org/P55800) I could see the following things that might need adjustment:
  • https://phabricator.wikimedia.org/P55800$996 it seems rake is installed (or one of the packages listed, I'm not sure) even though it shouldn't be needed now and would shave off ~10s
  • https://phabricator.wikimedia.org/P55800$647 cloud-init schema warning, I don't know if this is related to nopuppet images or not though

HTH!

Change #1017955 had a related patch set uploaded (by Andrew Bogott; author: Andrew Bogott):

[operations/puppet@production] vendordata/cloud-init: remove disk and fs entries

https://gerrit.wikimedia.org/r/1017955

Change #1017956 had a related patch set uploaded (by Andrew Bogott; author: Andrew Bogott):

[operations/puppet@production] vendordata/cloud-init: remove ruby-sorted-set package request

https://gerrit.wikimedia.org/r/1017956

Change #1017955 merged by Andrew Bogott:

[operations/puppet@production] vendordata/cloud-init: remove disk and fs entries

https://gerrit.wikimedia.org/r/1017955

Change #1017956 merged by Andrew Bogott:

[operations/puppet@production] vendordata/cloud-init: remove ruby-sorted-set package request

https://gerrit.wikimedia.org/r/1017956

<long pause> Thanks for the feedback!

I'll also list wishlist items, which might be in the works already, below:

• Currently there's no way to delete key pairs or otherwise "manage" key pairs ? I was looking for an option e.g. under "compute" or "access" and couldn't find it

I agree that there seems to be no way to delete existing keypairs from the UI. Building a new UI for managing them will be a bit of a project... am I correct in assuming that the lack of this feature is only really a clutter issue, or do you have security or other concerns?

• From the console log (https://phabricator.wikimedia.org/P55800) I could see the following things that might need adjustment:
  • https://phabricator.wikimedia.org/P55800$996 it seems rake is installed (or one of the packages listed, I'm not sure) even though it shouldn't be needed now and would shave off ~10s
  • https://phabricator.wikimedia.org/P55800$647 cloud-init schema warning, I don't know if this is related to nopuppet images or not though

I'm not sure where 'rake' is coming from but I did remove a ruby package from cloud-init which is likely responsible. As for the schema error -- it was harmless but I think I've now cleaned it up.

In T355963#9699633, @Andrew wrote:

<long pause> Thanks for the feedback!

Of course, thank you for working on this!

I'll also list wishlist items, which might be in the works already, below:

• Currently there's no way to delete key pairs or otherwise "manage" key pairs ? I was looking for an option e.g. under "compute" or "access" and couldn't find it

I agree that there seems to be no way to delete existing keypairs from the UI. Building a new UI for managing them will be a bit of a project... am I correct in assuming that the lack of this feature is only really a clutter issue, or do you have security or other concerns?

That's correct yeah, I don't think there are security implications. What I'm after is the possibility to upload/config a keypair once and reuse that across instances launch, which at the time I couldn't find a way to do. Perhaps the underlying APIs do support it: once a named keypair has been used once then it can be reused for subsequent launches? That'd be enough for me

• From the console log (https://phabricator.wikimedia.org/P55800) I could see the following things that might need adjustment:
  • https://phabricator.wikimedia.org/P55800$996 it seems rake is installed (or one of the packages listed, I'm not sure) even though it shouldn't be needed now and would shave off ~10s
  • https://phabricator.wikimedia.org/P55800$647 cloud-init schema warning, I don't know if this is related to nopuppet images or not though

I'm not sure where 'rake' is coming from but I did remove a ruby package from cloud-init which is likely responsible. As for the schema error -- it was harmless but I think I've now cleaned it up.

Thank you!

That's correct yeah, I don't think there are security implications. What I'm after is the possibility to upload/config a keypair once and reuse that across instances launch, which at the time I couldn't find a way to do. Perhaps the underlying APIs do support it: once a named keypair has been used once then it can be reused for subsequent launches? That'd be enough for me

Huh, I think I'm having the opposite problem: once I create a keypair and launch a VM with it that keypair is forever associated with my account and installed by default in all future VMs. That sounds like what you want, is that not what you're seeing?

In T355963#9700818, @Andrew wrote:

That's correct yeah, I don't think there are security implications. What I'm after is the possibility to upload/config a keypair once and reuse that across instances launch, which at the time I couldn't find a way to do. Perhaps the underlying APIs do support it: once a named keypair has been used once then it can be reused for subsequent launches? That'd be enough for me

Huh, I think I'm having the opposite problem: once I create a keypair and launch a VM with it that keypair is forever associated with my account and installed by default in all future VMs. That sounds like what you want, is that not what you're seeing?

Interesting, I didn't realize that was the case! Yeah that's probably fine for my use case