sigs.k8s.io/cluster-api-provider-aws@v1.5.5/docs/proposal/20180821-machine-config.md (about)

     1  # AWS Provider Machine Configuration and Status
     2  
     3  ## Overview
     4  This proposal aims to provide an initial API for AWS machine configuration and status for the AWS machine actuator.
     5  Cluster configuration for the AWS provider is out of scope for this proposal.
     6  
     7  ## AWSMachineProviderConfig
     8  Defines the spec portion of a Machine specific to AWS. It is meant to be embedded in the
     9  Machine.Spec.ProviderConfig field of a cluster API Machine.
    10  
    11  Following are design decisions around this type:
    12  
    13  - No AWS SDK types are included. For the following reasons:
    14    - Clients would also need to have the AWS SDK vendored.
    15    - The type would be tied to a specific AWS client version.
    16  
    17  - The machine ProviderConfig includes all the configuration needed to create a Machine.
    18    Until we resolve issues related to linking a cluster and machine, it is not clear
    19    whether the machine controller should be required to pass a Cluster resource to the actuator:
    20    - https://github.com/kubernetes-sigs/cluster-api/issues/41
    21    - https://github.com/kubernetes-sigs/cluster-api/issues/145
    22    - https://github.com/kubernetes-sigs/cluster-api/issues/177
    23  
    24  - Secrets are referenced for UserData and Account credentials, but are optional.
    25    If the secrets are not present, then no user data is set on the instance, and if no
    26    account credentials are present, it is assumed the IAMRole of the machine where the
    27    actuator is running has enough permission to create a new instance.
    28  
    29  - The list of ELBs that should be associated with a machine are set explicitly in the config
    30    and are attached when the instance is created.
    31  
    32  ## AWSMachineProviderStatus
    33  Defines the status portion of a Machine specific to AWS. It is meant to be embedded in the
    34  Machine.Status.ProviderStatus field of a cluster API Machine.
    35  
    36  Design decisions for this type:
    37  
    38  - Conditions are used to report on problems creating an instance, or attaching ELBs.
    39    Reference: https://github.com/kubernetes/kubernetes/issues/7856
    40    Although the issue seems to imply that we want to get rid of conditions, Brian Grant's
    41    [conclusion](https://github.com/kubernetes/kubernetes/issues/7856#issuecomment-335687733)
    42    states that conditions should be kept to report extended status. Knowing why we failed
    43    to create an instance or whether attaching an ELB did not succeed is still very valuable
    44    information.
    45  
    46  ## Open Issues
    47  
    48  ### Load Balancer Management
    49  - Currently we include a set of IDs for ELBs to attach to the machine on creation. However, what happens if the ELB
    50    doesn't exist, or if after the machine is created the ELB fails to attach? Should this be handled by a separate
    51    controller?
    52  
    53  ### BlockDevice Mapping
    54  - The RunInstances EC2 call allows specifying a BlockDeviceMapping to allow changing volume size or type from what
    55    is specified in the AMI. Is this something that we need? or is it enough to say that if you want something different
    56    to simply create a different AMI?
    57  
    58  ### Extensibility
    59  - If the current types don't meet all the needs for different providers, do we allow some kind of extension mechanism
    60    to the types? How do we extend the actuator itself? Or should we simply allow the base implementation to be vendored
    61    into an implementation that can augment it. What hooks would we provide to allow this?