Implements test for self-hosted upgrades

[fabriziopandini]

As of today in CAPI e2e we are testing the bootstrap-pivot to self-hosting sequence, but we are not testing self-hosting upgrades.

Ideally we should test:

• upgrading a single control plane, self-hosted cluster
• upgrading an HA control plane, self-hosted cluster

/kind feature
/area testing

[vincepri]

/milestone v0.4.0
/priority important-longterm

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[fabriziopandini]

/remove-lifecycle stale

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale

[fabriziopandini]

/lifecycle frozen

[tcordeu]

@fabriziopandini can I work on this one? If so, can you provide some tips on where to start?

[fabriziopandini]

Sure!
Currently in out e2e we are testing pivot a management cluster to a self hosted cluster, see https://github.com/kubernetes-sigs/cluster-api/blob/master/test/e2e/self_hosted.go (*), however, after pivoting, we don't do any operation on the self hosted managed cluster (apart from checking it is reconciling itself).

(*) Note that we cannot pivot the kind management cluster generated by our E2E test suite, because it is shared by many test running in parallel. So during the test we are:

• creating a workload cluster
• turning it into a management cluster (our starting cluster for pivoting)
• using it to create another workload cluster (the target cluster for pivoting)
• doing the pivot:
  • turn this second cluster into a management cluster
  • move the cluster definitions from the starting point to here

This issue is about:

• Extending this test, by adding a final step that upgrades the self hosted cluster (the target cluster after pivot).
• Making required changes so we can run the same test twice, one with 1 cp machines, one with 3 cp machines

/assign @tcordeu
/lifecycle active

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[fabriziopandini]

/lifecycle frozen

[fabriziopandini]

/unassign @tcordeu
/assign @anusha94

[k8s-ci-robot]

@fabriziopandini: GitHub didn't allow me to assign the following users: anusha94.

Note that only kubernetes-sigs members, repo collaborators and people who have commented on this issue/PR can be assigned. Additionally, issues/PRs can only have 10 assignees at the same time.
For more information please see the contributor guide

In response to this:

/unassign @tcordeu
/assign @anusha94

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[anusha94]

/assign @anusha94

[vincepri]

/milestone v1.0

[fabriziopandini]

/triage accepted

[chrischdi]

@anusha94 are you still working at this?

[chrischdi]

Taking this over as there was no response :-)

/unassign @anusha94
/assign