Giters

gardener / landscapercli

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Build Landscaper Components for a first minimum initial set of Gardener Components

In-Ko opened this issue · comments

commented

Description
We need to start modelling first Landscaper-based Components (blueprints, component descriptors) for an initial set of existing Gardener Components. The "initial set" has been discussed in a meeting:

  • dns + garden (virtual, but not system-components/nginx; becomes virtual garden cluster; a start was made by Rafael, see here: https://github.com/gardener/virtual-garden

  • gardener-extensions (just dns-external)

  • gardener-extensions (just networking-calico)

  • gardener-extensions (just os-gardenlinux)

  • gardener-extensions (just provider-aws; a beginning was made in https://github.com/gardener/gardener-extension-provider-aws/tree/master/.landscaper)

  • gardenlet (below gardener). This is already worked on by Daniel.

  • gardener (everything but gardenlet below gardener)

  • For each of these components, a dedicated task will be created and referenced in this epic. Those tasks will also include the work that has to be done in 'landscape-setup' (e.g. using the new landscaper-components there), possibly followed later by adopting this in the 'garden-setup'

  • This initial set has to fulfil the requirement to enable full testing within the Gardener test-machinery whenever a new PR is created for a new Gardener-Version. We will also try to clarify this in the mentioned meeting. Also this work will then be further detailed out in a dedicated task, linked to this epic.

Done Criteria for this Epic:

  • The initial set of Gardener Components has been modelled consistently in terms of Landscaper Artefacts like blueprints and component descriptors
  • This set of new Landscaper Components has been added to 'landscape-setup' and the relevant old parts for those components have been deleted from 'landscape-setup', so that only the landscaper artefacts (in the end installation.yamls) are used to deploy those Gardener components.
  • Integration of these new Landscaper Components into the test-machinery has been done, enabling testability / validation of new PRs for new Gardener-Versions.

SubTasks

commented

@In-Ko The main goal is indeed PR validation using these new components/blueprints and then also integration into the current landscape installation, but that's actually landscape-setup (this one drives our landscapes) and not garden-setup (this ones drives/is the community installer), but that can be a follow-up goal to also make the first step towards a new community installer. Then the team should take over/get involved to migrate the remaining components for both setups.

commented

I have changed the description in the Epic accordingly, thanks for the hint.

commented

@In-Ko You have mentioned internal references in the public. Please check.

commented

@enrico-kaack-comp and me worked on the following components:

  • dns-external

current status: the PRs are open in the component repositories and require review

  • aws-extension: PR is merged, final tests and checks if something changed in the meantime missing
  • networking-calico
  • os-gardenlinux
  • virtual-gardener:
    • implementation for component finished
    • integration tests started but still not finished
    • preparation pull request for another secret open (in landscape setup)
    • deploy script in landscape setup open
commented

@jschicktanz , @enrico-kaack-comp, @robertgraeff , @achimweigel : Can you guys please also update the initial task description above in terms of ticking off what has been finished. I believe setting up the landscaper instances on the various landscapes is by done, same for the copying of local resources ? Also the two extensions are ready, right ? ...

commented

As discussed in our internal Workshop, the goal to enable Gardener pre-release validation with Landscaper Components is not regarded as main goal anymore. Still, the "landscaperification" of Gardener Components is needed due to the alignment of the internal and external Gardener deployment machinery, possibly merging both deployments into a single one, eliminating double maintenance.

commented

@In-Ko should we close this?

commented

Yes.