The Puppet Labs Issue Tracker has Moved: https://tickets.puppetlabs.com
node _aws list should be more aware of keypairs
|Branch:||Affected PE version:|
Ticket tracking is now hosted in JIRA: https://tickets.puppetlabs.com
This ticket may be automatically exported to the ENTERPRISE project on JIRA using the button below:
The list of returned nodes should also specify the keypair associated with a machine instance. This allows you to filter see which instances out of the list were created with your keypair (and presumably by you)
—keypair should also be an accepted option for list, so that you can filter to only return the instances associated with your keypair
#1 Updated by Nigel Kersten over 2 years ago
- Status changed from Needs Decision to Accepted
- Assignee deleted (
It should definitely be an optional filter.
What do we do with machines that aren’t associated with a keypair? How do you specify those? Or don’t we?
Are there other filters we should be considering too? region? type ?
#2 Updated by Dan Bode over 2 years ago
I recommend the following:
accept an optional option called keypair
if its specified, just list the instances created using that keypair.
If its ommitted, list all of the visible instances, but show keypair as one of the listed attributes.
I am not too sure about the other possible filters.
#3 Updated by Nigel Kersten over 2 years ago
I’m a little concerned about having
--keypair mean different things in different contexts, and I’m not sure if that’s a good thing or not.
When you’re creating an instance, it assigns that keypair to the instance.
When you’re listing them, it filters by that keypair.
Is that good or bad UX?
/me adds Randall as watcher.
#5 Updated by Randall Hansen over 2 years ago
If I understand it,
keypair is being used as an identifier, like
title. I don’t think there’d be any problem there, using an id both to create and find a node. As long as there’s another differentiator, like a verb, to make it clear what
keypair should be doing, I think this is fine.