module

Krikri::PluginHelpers::AwsModuleArgs

AwsModuleArgs - the argument-validation surface shared by the amazon.aws modules krikri reimplements natively (ec2_key, ec2_ami_info, ec2_instance, ec2_security_group, ec2_vpc_net_info, ec2_vpc_subnet_info, iam_user_info).

Real amazon.aws modules wrap AnsibleModule in AnsibleAWSModule Observed behavior: the AnsibleModule argument-spec validation runs FIRST, then the boto3 check fails any invocation whose args were VALID with "Failed to import the required Python library (botocore and boto3) ...". Every wording below is therefore reachable without any AWS connectivity, and the boto3 gate is the last thing that fires before the module's own logic - which for krikri is the native EC2/IAM Query-API helpers (no boto3 anywhere).

The gate probes the host's python3 the same way the Ansible module's import check would: if boto3+botocore import cleanly the module (and krikri) proceed to the API work; if not, both fail with the same missing-library message shape (hostname and interpreter path included, exactly like missing_required_lib builds it).

Validation order mirrors ansible-core 2.14's ArgumentSpecValidator.validate() (arg_spec.py) + basic.py failing on errors[0] (live-verified against amazon.aws 11.4.0 under ansible-core 2.14 via the podman-diff probe container):

  1. _list_no_log_values: for a dict / elements-dict param WITH an options= sub-spec, a scalar string (or list elements) value is converted through check_type_dict directly, so the bare TypeError wording ("dictionary requested, could not parse JSON or key=value") is errors[0] - the "argument 'x' is of type ..." wrapper from _validate_argument_types never fires (e.g. ec2_instance's image). Dict params WITHOUT options (tags, filters, aws_config) skip this and keep the prefix.
  2. mutually_exclusive
  3. missing required arguments
  4. type conversion failures (merged spec declaration order)
  5. choices failures (merged spec declaration order)
  6. required_one_of / required_if
  7. sub-spec (options=) checks per param
  8. unsupported parameters (top level, then suboption keys)
  9. the boto3 gate

Constants

BASE_ARGS = {"access_key" => Arg.new(aliases: ["aws_access_key_id", "aws_access_key"]), "secret_key" => Arg.new(aliases: ["aws_secret_access_key", "aws_secret_key"]), "session_token" => Arg.new(aliases: ["aws_session_token"]), "profile" => Arg.new(aliases: ["aws_profile"]), "endpoint_url" => Arg.new(aliases: ["aws_endpoint_url"]), "validate_certs" => Arg.new(type: "bool"), "aws_ca_bundle" => Arg.new(type: "path"), "aws_config" => Arg.new(type: "dict"), "debug_botocore_endpoint_logs" => Arg.new(type: "bool"), "region" => Arg.new(aliases: ["aws_region"])}

the Ansible module _aws_common_argument_spec() + region, in declaration order; every module's merged spec is this plus its own params.

Class methods

base_args
Source
bool_type_error(name : String, value : JSON::Any) : Krikri::PluginResult
Source
boto3_gate(params : Hash(String, String)) : Krikri::PluginResult | Nil

The AnsibleAWSModule boto3-check step: with valid args, the module's next act is importing boto3/botocore, and a host without them fails here. krikri probes the interpreter Ansible's discovery would hand the module (python_lib_gate's INTERPRETER_FALLBACK walk - the same probe every other missing-library gate uses): probing a bare python3 instead named the /usr/bin/python3 symlink in the failure message where real named the versioned interpreter it discovered (/usr/bin/python3.10 on the Ubuntu 22.04 target, issue #397), and it probed for the libs under an interpreter the module itself might never run under.

Source
int_type_error(name : String, pyclass : String) : Krikri::PluginResult
Source
type_error(name : String, type : String, raw : String) : Krikri::PluginResult | Nil
Source
validate(spec : Spec, params : Hash(String, String)) : Krikri::PluginResult | Nil

Returns the failed PluginResult for the FIRST argument-spec violation (Ansible fails on errors[0]), or nil when validation passes and the module would move on to the boto3 check.

Source

Nested types