Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[RFE] CAPI should link infrastructure objects to their originating template #3020

Closed
sethp-nr opened this issue May 6, 2020 · 2 comments · Fixed by #3181
Closed

[RFE] CAPI should link infrastructure objects to their originating template #3020

sethp-nr opened this issue May 6, 2020 · 2 comments · Fixed by #3181
Assignees
Labels
kind/feature Categorizes issue or PR as related to a new feature. lifecycle/active Indicates that an issue or PR is actively being worked on by a contributor.
Milestone

Comments

@sethp-nr
Copy link
Contributor

sethp-nr commented May 6, 2020

User Story

As a provider developer I would like to be able to identify which infrastructure resources were created from a template directly.

Detailed Description

CAPA has a few mutable fields on AWSMachine objects (specifically: security groups and tags) that, as users of CAPA, we would like to be mutable at the "template" level.

The path to the provider being able to reconcile those changes is laid out here: kubernetes-sigs/cluster-api-provider-aws#1711

It is possible for the provider to walk back from the specific infrastructure object (the AWSMachine) to the Machine, and from there to the MachineSet where we have an immutable reference to the originating template.

The trouble comes in with KubeadmControlPlanes (and possibly MachinePools?): even if we teach the provider the specific chain of responsibility, that reference is mutable. There's not a guarantee that the current object at the other end of that pointer is the same as the one that produced any given Machine.

It would make the first case much simpler, and the latter case more reliable, if CAPI would note which Template was used at the time of instantiation.

Anything else you would like to add:

It's a small amount of work to add an object reference of some kind when we instantiate the template, but the question is where:

  1. Into a well-known field on the provider-specific object, as either an annotation or some mandatory field?
  2. Into the Machine object? At least in CAPA, there's already a dependency on the parent Machine for things like bootstrap and Kubernetes version.

/kind feature

@k8s-ci-robot k8s-ci-robot added the kind/feature Categorizes issue or PR as related to a new feature. label May 6, 2020
@vincepri
Copy link
Member

/milestone v0.3.x

@vincepri
Copy link
Member

/assign @sedefsavas
/milestone v0.3.7

@k8s-ci-robot k8s-ci-robot modified the milestones: v0.3.x, v0.3.7 Jun 10, 2020
@vincepri vincepri added the lifecycle/active Indicates that an issue or PR is actively being worked on by a contributor. label Jun 23, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/feature Categorizes issue or PR as related to a new feature. lifecycle/active Indicates that an issue or PR is actively being worked on by a contributor.
Projects
None yet
4 participants