module

Krikri::PluginHelpers::Ec2Key

Decision logic for amazon.aws.ec2_key - manage an EC2 SSH key pair (create a new key pair, import an existing public key, delete).

The plan functions take the module params plus the ALREADY-FETCHED DescribeKeyPairs result and return the exact sequence of mutating EC2 API calls to make (as Ec2Api::Step records) plus the changed flag and message. Keeping the wire calls out is what lets specs exercise every decision branch against canned XML with no network.

Behavior mirrors the real module's key_pair module_utils:

  • state=present, no key_material: create a new key pair unless one with the same name exists (or force=true, which deletes and recreates). The CreateKeyPair response's private key is the only chance to capture it - EC2 never returns it again.
  • state=present with key_material: import the public key unless the name already exists (or force=true).
  • state=absent: delete if it exists, no-op otherwise.

Class methods

describe_filter(name : String) : Array(Tuple(String, String))

Filter.1.Name=key-name pairs for the name lookup the plugin performs before planning.

Source
parse_key_pairs(root : XML::Node) : Array(KeyPair)

DescribeKeyPairsResponse -> key list. The response wraps each key in keyPairsSet/item (the older anon-2011 spelling was keyPairs/item; both seen in the wild, so accept both).

Source
plan_absent(name : String, existing : Array(KeyPair)) : Plan
Source
plan_present(name : String, key_material : String | Nil, force : Bool, existing : Array(KeyPair)) : Plan
Source
run(params : Hash(String, String)) : Krikri::PluginResult

Full module run: params in (the same string-hash the plugin binary receives), result out. The plugin binary is a one-line wrapper around this; specs drive it through the Ec2Api transport seam instead of the real network.

Source

Nested types