Description
Implement a CLI Command, which creates an example blueprint and component descriptor and the necessary directory structure locally, and additionally allows to push artefacts to an OCI Registry, using the component-cli.
It could work somehow similar to a helm create

Done Criteria

• All Features implemented
• Code has been reviewed by other team members
• Unit Tests created for new code
• Integration Test Suite updated (if applicable)
• Internal technical Documentation updated
• Enduser Documentation updated (if applicable)
• Successful demonstration in Review

Description
Some colleagues in the team still need to spend time to get confident with the Landscaper and Landscaper-CLI. This task here should reserve some time to

• Go through the landscaper and landscaper cli documentation
• Execute the examples as described in the documentation
• Provide feedback on the documentation and the examples

What is the problem:

We are using landscapercli in a GitHub workflow to generate component-descriptor, blueprint, and deployitems based on helm charts.
The helm charts are local and blobs are generated.
When we try to upload the artifacts using actions/upload-artifacts we get an error:

Error: Artifact path is not valid: /blobs/sha256:2bd6ba29e8317150032676053759ed56cb26a56db023f2531f7be9a4b7920109. Contains character: ":". Invalid characters include: ",:,<,>,|,*,?.

What you expected to happen:

Successfully uploaded artifacts in GitHub workflow. File names do not contain characters that do not work on most operating systems. See more here

How to reproduce it (as minimally and precisely as possible):

Greate repository containing a file with ":" in its name, use the https://github.com/actions/upload-artifact to upload it to workflow

What happened:
Specifying a path to a chart directory with slash at the end of path leads to error:
"the parent of the chart-directory does not contain only the chart-directory"

Example:
You have a local helm chart directory with the following directory structure:
/home/jason/test/lscli/helm_test
└── mychart
├── Chart.yaml
├── charts
├── templates
│ ├── NOTES.txt
│ ├── _helpers.tpl
│ ├── deployment.yaml
│ ├── hpa.yaml
│ ├── ingress.yaml
│ ├── service.yaml
│ ├── serviceaccount.yaml
│ └── tests
│ └── test-connection.yaml
└── values.yaml

The chart is located in the directory /mychart/, the partent of /mychart/ is /helm_test/.

Then call the landscaper-cli as follows:

landscaper-cli component add helm-ls deployitem testitem --component-directory ./first/ --chart-directory /home/jason/test/lscli/helm_test/mychart/ --cluster-param target-cluster --resource-version v0.2.0 --target-ns-param test-namespace

This will result in the following error:
the parent of the chart-directory does not contain only the chart-directory

It works, if one would pass the path like this /home/jason/test/lscli/helm_test/mychart, without the slash at the end. However, this is probably not was is expected as parameter, even using auto-completion would add the / at the end of the path.

The code which produces this error message is in the source file add_helm_ls_deployitem.go
.
.
parentPath := filepath.Dir(o.chartDirectoryPath)
files, _ := ioutil.ReadDir(parentPath)
if len(files) > 1 {
return fmt.Errorf("the parent of the chart-directory does not contain only the chart-directory")
}

If you pass a directory path with a slash at end (like /home/jason/test/lscli/helm_test/mychart/), the Go utility function .Dir lists the contents of /home/jason/test/lscli/helm_test/mychart/ and not as assumed /home/jason/test/lscli/helm_test/.

See Go function Dir for reference https://pkg.go.dev/path/filepath#Dir

I stumbled across this, because I specified the path for the chart directory by using the auto completion feature of Bash. If one would just copy and the paste the tutorial (which I also did), you would not immediately run into the issue, since the path is specified in the tutorial without the slash at the end:
https://github.com/gardener/landscapercli/blob/master/docs/commands/create_component/create.md

landscaper-cli component add helm-ls deployitem echo
--component-directory $LS_COMPONENT_DIR/demo-component
--chart-directory $LS_ROOT_DIR/docs/commands/create_component/resources/charts/echo-server
--resource-version v0.3.0
--cluster-param target-cluster
--target-ns-param echo-server-namespace

Description
Create a landscaper-conform model for the "dns-external" Gardener Extension Component. The model should go along with a suitable documentation about how the model is structured, including its integration into the landscape-setup.

Done Criteria

• A model for the "dns-external" Gardener extension has been created
• Documentation about the model has been created
• In landscape-setup, the new model is used

Since we have a homebrew tap (https://github.com/gardener/homebrew-tap), we should add the landscaper CLI to it (unless this causes problems which I'm currently not aware of).
This will make it easier to install and update the CLI.

Description
We have to ensure all documentation and related readme-files are in a good shape. Therefore, we have to go over both repos, check the readme-files regarding their content / links and fix them, if we still find some outdated ones.

• All readme-files have been updated accordingly

What would you like to be added:
Include the setup of the ingress for the OCI registry of "landscaper-cli quickstart install" in the "install" command itself.

Why is this needed:
Currently when using "landscaper-cli quickstart install" to setup a Landscaper instance and an OCI registry in a shoot cluster, an ingress for accessing the registry without port-forwarding via localhost must be manually added via "landscaper-cli quickstart add-oci-endpoint". In reality this turned out to be a somewhat of a hassle (e.g. configuring the Landscaper instance with the correct registry credentials). These manual steps should be included in the "quickstart install" command itself. It should really take only 1 single command to get up and running with component development using the setup provided by the "quickstart" command.

Description
The Landscaper CLI needs to provide an easy way to enable local development scenarios. This command should include the landscaper installation itself (into an already existing cluster, this is a prerequisite), and the installation of a locally running OCI Registry, which should be wired to the landscaper as default OCI Registry.

Done Criteria

• Concept for "landscaper init" created, discussed and agreed
• All needed Features implemented
• Code has been reviewed by other team members
• Unit Tests created for new code
• Integration Test Suite updated (if applicable)
• Internal technical Documentation updated
• Enduser Documentation updated (if applicable)
• Successful demonstration in Review

Gardener informs its stakeholders in its CNCF CII Badge, that static code checks are applied by using Checkmarx. This repository has findings, which have to be assessed by the component owner(s). As required all prio high findings were already been immediately assessed. Please find the maximum processing times until when to assess the remaining prio medium findings in the SAP Security Response Team's Wiki (restricted access). At the time being you can ignore the prio low findings. Please find background information and a link to the Checkmarx project for your repository in the Wiki (restricted access). In the Wiki (restricted access) you will as well find information how to get a Checkmarx user which is required to be able to do your assessment in the Checkmarx Web UI.

Gardener informs its stakeholders in its CNCF CII Badge, that static code checks are applied by using Checkmarx. This repository has findings, which have to be assessed by the component owner(s). As required all prio high findings were already been immediately assessed. Please find the maximum processing times until when to assess the remaining prio medium findings in the SAP Security Response Team's Wiki (restricted access). At the time being you can ignore the prio low findings. Please find background information and a link to the Checkmarx project for your repository in the Wiki (restricted access). In the Wiki (restricted access) you will as well find information how to get a Checkmarx user which is required to be able to do your assessment in the Checkmarx Web UI.

Description
Similar to the existing support of the helm-ls and manifest deployer, the CLI must also support the container deployer. So similar to the other deployers, it should be possible to add a container-based deployment via the CLI to a component.
This is crucial for some of the Gardener-Components.

Done Criteria

• All Features implemented
• Code has been reviewed by other team members
• Unit Tests created for new code
• Integration Test Suite updated (if applicable)
• Internal technical Documentation updated
• Enduser Documentation updated (if applicable)
• Successful demonstration in Review

What would you like to be added:

Currently the render command reads the imported values from a "imports.yaml" and templates the blueprints defined deployExecution.

To be able to also validate the import definitions, the render command should validate the data of the "imports.yaml" against the blueprint defined imports.

Description
The LSSD (Landscape Setup Dependencies) at the moment does not support the copying of local resources. This needs to be added.

What happened:

Installing the landscaper with quickstart command and no values file does not install the deployer helm, container and manifest. This should be changed.

What you expected to happen:

How to reproduce it (as minimally and precisely as possible):

Anything else we need to know:

Environment:

Description
To better share the knowledge of creating Components based on Landscaper and CNUDIE, we should write down all things we learned from our work with the "provider-aws" and "dns-external" components. This "How-To" Guide could then be taken as a first entry point when teams starting to create their own Components based on CNUDIE and Landscaper.

The guide should cover all the steps we had to do in order to properly model such a new component, based on the experiences we had over the last weeks.

• One chapter should focus on the "development" aspect for such a component, e.g. how to do local development => which steps are needed in order to implement a new feature for a component. This chapter should include creating blueprints, focusing on how model the blueprint, and also how to create the component descriptor. Especially for the Component Descriptor, I am not aware of any "enduser-facing" documentation. There is this spec documentation, but this does not really help when starting to develop a new component.
• Another chapter should focus on the the build process: How to correctly build the respective image (what is needed in the build pipeline to have CNUDIE and Landscaper artefacts ready, how to upload them to OCI Registry ...), and finally get it deployed on a shoot cluster in order to test the new feature.
• And another chapter could focus on: How to consistently get a component from DEV to STAGING / CANARY, so how does the staged release process work .

Done Criteria

• "How-To" Guide has been created and reviewed with at least one Colleague of another team who is not that deep into the Landscaper / CNUDIE topic.

Description
In order to improve & simplify the way endusers work with the Landscaper, we need to provide an easy to consume, well documented and stable Command Line Interface for the Landscaper Core.
This Epic gathers the first set of tasks which we have to address, focusing on local usecases.

Scope / Features to be covered by this Epic
In a first meeting, it has been discussed what the CLI should provide short- to midterm:

• Enable easy "jump start" for local development scenarios via some kind of landscaper init command
• Simplify the process of creating a first blueprint and/or component descriptor, based on a template, using a command like landscaper create component
• Provide means to validate local landscaper artefacts

SubTasks

• Move existing Landscaper CLI Code to Potter Repo
• CLI Command "landscaper quickstart"
• CLI Test Suite
• Integrate Component CLI
• CLI Command "create component"
• CLI Command "create installation"
• CLI Commands for debugging
• CLI Command "validate local"

Command (landscaper-cli blueprint add helm-ls value) option [execution name] is not available anymore. It is not updated in the following documentation.

File: https://github.com/gardener/landscapercli/blob/master/docs/drafts/scenarios/01-create-blueprint-with-helm-charts/commands.md#step-3-add-fixed-values-for-helm-templating

Command options from documentation:

Command options from the CLI tool:

Description
Currently, the Landscapers "Helm Deployer" only uses the Helm Templating mechanism, which is sufficient for the Gardener usecase / Helm-based deployments, but not for other Stakeholders of the Landscaper.
So we have to provide another Deployer for the Landscaper, which encapsulates the complete feature-set of the Helm Client. We might not be able to use the Potter Helm-Deployer, but should be able to benefit from our previous knowledge when we have created that deployer for the Potter.

Done Criteria

• All Features implemented
• Code has been reviewed by other team members
• Unit Tests created for new code
• Integration Test Suite updated (if applicable)
• Internal technical Documentation updated
• Enduser Documentation updated (if applicable)
• Successful demonstration in Review

Description
In order to ensure best possible quality for the landscaper cli, we have to update the pipeline in such a way that it runs the CLI Test Suite, and only creates a new Release of the CLI if all Tests run through completely.
If a test fails, the pipeline must report the failing test (as usual, see Potter pipelines ...) in a human readable protocol, so that it is easy to identify the problem.

• also execute "make generate" to update the documentation
• And also update the version.Info (see the task #24 )

Done Criteria

• All Features implemented
• Code has been reviewed by other team members
• Unit Tests created for new code
• Integration Test Suite updated (if applicable)
• Internal technical Documentation updated
• Enduser Documentation updated (if applicable)
• Successful demonstration in Review

What would you like to be added:
With landscaper v0.5 additional values like .blueprint or .cd as described in the docs https://github.com/gardener/landscaper/blob/master/docs/usage/Blueprints.md#deployexecutions

imports: 
  <import-name>: <import value>
cd: <component descriptor>
components: <list of all referenced component descriptors>
blueprint: <blueprint definition> # blueprint definition from the Installation
componentDescriptorDef: <component descriptor definition> # component descriptor definition from the installation

The landcaper-cli render command should include all the available templating values to be able to mock a real landscaper templating.

Description
Create a landscaper-conform model for the Virtual Garden Cluster Component. The model should go along with a suitable documentation about how the model is structured, including its integration into the landscape-setup.

Done Criteria

• A model for the Virtual Garden Cluster has been created
• Documentation about the model has been created
• In landscape-setup, the new model is used

Description
Create a landscaper-conform model for the "provider-aws" Gardener Extension Component. The model should go along with a suitable documentation about how the model is structured, including its integration into the landscape-setup.

Done Criteria

• A model for the "provider-aws" Gardener extension has been created
• Documentation about the model has been created
• In landscape-setup, the new model is used

Description
During the last demo, we faced again the issue of the complexity of the landscaper, including the CLI, which exposes quite some options as part of the individual CLI Commands.
To make usage of the CLI a bit easier, we should enable auto-completion for the CLI as a whole. What I would image is that after typing for example "landscaper-cli component" followed by a TAB, all possible subcommands are listed and can be chosen in the Shell. The same for all other commands, including auto-completion for the various options / flags which we offer in the CLI.

Done Criteria

• Auto-Completion is enabled for all commands
• Auto Completion is enabled for all options / flags for a given subcommand

Description
Especially for the "Landscape Admin" Persona, who needs to deploy a component and therefore has to provide certain import parameters in order to make the installation work, we need to provide an easy way to figure out the overall "interface" of a component.
So a new command like component get parameters should be implemented, taking a component as input and returning a human-readable list of mandatory import parameters of all blueprints (for each blueprint a separated section), which need to be passed to the blueprints contained in the component during deployment. It is crucial that the needed datatype is also shown for each import parameter (as good as possible, even if we only start with STRING and INT, so no structured datatypes, it would be of value for Landscape Admins).

Done Criteria

• All Features implemented
• Code has been reviewed by other team members
• Unit Tests created for new code
• Integration Test Suite updated (if applicable)
• Internal technical Documentation updated
• Enduser Documentation updated (if applicable)
• Successful demonstration in Review

Description
Endusers need to know exactly which versions of Landscaper CLi / Components CLI and Landscaper itself are used.
This is especially needed at the moment due to the fact that a lot of things are changing in all three components, and endusers facing problems need to report to us / landscaper colleagues which versions they have been using when a certain issue occurred.
So we have to update Landscaper CLI version command to display the versions of a) the Landscaper CLI itself, b) the Component-CLI and c) the Landscaper version (e.g. = Helm Chart Version) deployed when the quickstart command is used.

Done Criteria

• All Features implemented
• Code has been reviewed by other team members
• Unit Tests created for new code
• Integration Test Suite updated (if applicable)
• Internal technical Documentation updated
• Enduser Documentation updated (if applicable)
• Successful demonstration in Review

What happened:

Rendering a blueprint fails with relative paths.

What you expected to happen:

Rendering a blueprint should work when passing relative paths in command line flags.

How to reproduce it (as minimally and precisely as possible):

This fails:

$ landscaper-cli blueprints render ./blueprint -c component/component-descriptor.yaml -f ./import-values.yaml
unable to read values file './import-values.yaml': file does not exist

This works:

$ landscaper-cli blueprints render ${PWD}/blueprints/virtual-landscaper -c ${PWD}/component/component-descriptor.yaml -f ${PWD}/import-values.yaml

Anything else we need to know:

This seems to be a regression. It was working with landscaper-cli version v0.7.0
After updating to version v0.8.0 it fails.

Environment:

$ landscaper-cli version

Landscaper-CLI Version: v0.8.0-42d97d8e47c1fd15d25541d42eacbc5fb1aeb38d
  GitCommit: 42d97d8e47c1fd15d25541d42eacbc5fb1aeb38d
  GitTreeState: dirty
  GoVersion: go1.16.5
  Compiler: gc
  Platform: darwin/amd64

Compatible Landscaper Version: v0.11.2
Compatible and included Component-Cli Version: v0.28.0

Description
We need to verify the documentation regarding the Container Deployer in both the landscaper-cli and landscaper repositories. In order to do this, we also need to execute the corresponding examples.
Feedback reg. the documentations and the examples should be gathered and presented to the team, so that we can update the documentation / examples accordingly.
This task is also very helpful to onboard colleagues to the overal landscaper / landscaper-cli topic.

Done Criteria

• Container Deployer Documentation verified
• Feedback gathered and presented to the team(s)
• Documentation updated accordingly

We need to check the content of the examples folder and integrate it into the rest of the documentation: https://github.com/gardener/landscapercli/tree/master/docs/examples

What would you like to be added:

We need some automatic doc generation from the command implementations.

An example (for what exactly?) could be found here:

• Script: https://github.com/gardener/component-cli/blob/main/hack/generate-docs/main.go
• Generated Reference: https://github.com/gardener/component-cli/blob/main/docs/reference/components-cli.md

I have followed the docs here: https://github.com/gardener/landscapercli/blob/master/docs/commands/create_component/create.md#22-add-an-application-provided-as-local-helm-chart

What happened:
After executing:

landscaper-cli components-cli component-archive resources add \
   $LS_COMPONENT_DIR/demo-component \
   -r $LS_COMPONENT_DIR/demo-component/resources.yaml

I get warnings and errors:

Flag --resource has been deprecated, the flag r is deprecated use command args instead
unable to parse component archive from /repo/test/demo-component: unable to parse component descriptor read from component-descriptor.yaml: component.name: Does not match pattern '^[a-z0-9.\-]+[.][a-z]{2,4}/[-a-z0-9/_.]*$'

What you expected to happen:

1. In the docs to have a command with the right argument (as -r is deprecated)
2. The name of my component descriptor is: github.com/DenisDuev/landscaper-manifest-action/test which the regex ^[a-z0-9.\-]+[.][a-z]{2,4}/[-a-z0-9/_.]*$ do not match. The capital letters in the username are problematic. Is this mandatory or missed regex expression?

How to reproduce it (as minimally and precisely as possible):
have a name of the component-descriptor containing capital letters, follow the docs.

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

• Knowledge Build-up 'Gardener Components'
• Knowledge Build-up 'landscape-setup'
• Setup of central Landscaper Instances
• Enable Copying of local resources to LSSD
• Create Landscaper Component for "dns-external" gardener-extension
• Create Landscaper Component for "provider-aws" gardener-extension
• Create Landscaper Component for "Virtual Garden Cluster"
• How-To Guide "Initial Modelling and Dev-Workflow for Landscaper Components"

Description
In order to test the installations/deployments of new Gardener Landscaper/CNUDIE Components, central Landscaper Instances are needed per Landscape (DEV, STAGING, ...). For now focus on the existing Landscapes, mainly to test the new Gardener Components and integrate them into the test machinery, later we also need to think about how to do the initial deployment of a landscaper for new landscapes.
Such central landscaper instances are also valuable for (upcoming) stakeholders of the landscaper.

Done Criteria

• A Landscaper is running on the Gardener DEV Landscape
• A Landscaper is running on the Gardener STAGING Landscape
• A Landscaper is running on the Gardener CANARY Landscape
• A Landscaper is running on the Gardener LIVE Landscape

Description
After using the "installations set-import-parameters" command to set a value for a specific import parameter, it is not possible to change this value again using the same command. This should be improved, so that a user can perform the same command again but with a different value.
Note that this is a nonessential minor issue, as it is always possible to go to the installation.yaml file directly and edit the value there.

Done Criteria

• All Features implemented
• Code has been reviewed by other team members
• Unit Tests created for new code
• Integration Test Suite updated (if applicable)
• Internal technical Documentation updated
• Enduser Documentation updated (if applicable)
• Successful demonstration in Review

Description
After a user has used landscaper quickstart , followed by landscaper component create ... , there needs to be a command which creates a working skeleton for an installation.yaml, which could then be applied to a cluster using kubectl apply.
Main task here to be solved is how the import parameters as defined in a blueprint can be fulfilled as automated as possible. The same is true for the export parameters, so that the user can make sure that the exports are filled with data as defined in the blueprint.

Done Criteria

• All Features implemented
• Code has been reviewed by other team members
• Unit Tests created for new code
• Integration Test Suite updated (if applicable)
• Internal technical Documentation updated
• Enduser Documentation updated (if applicable)
• Successful demonstration in Review

Description
We have to invest into building up knowledge in the team around the Gardener Components.
Good starting points should be:

• https://gardener.cloud/documentation/concepts/architecture/ and
• https://gardener.cloud/documentation/concepts/core-components/

This is relevant in general to get up-to-speed with the core concepts of the Gardener, and especially if we want to start building landscaper-components for those Gardener Components.

Description
The Potter has a controller dealing with Kapp-Deployments.
We need to provide the Potter Kapp-Deployer as Landscaper-conform Deployer. It must be possible to easily add this new Deployer to an existing Landscaper, so that the Landscaper can perform Kapp-based deployments.

Done Criteria

• All Features implemented
• Code has been reviewed by other team members
• Unit Tests created for new code
• Integration Test Suite updated (if applicable)
• Internal technical Documentation updated
• Enduser Documentation updated (if applicable)
• Successful demonstration in Review

Description
The current work on the Landscaper CLI should be moved into a dedicated Repo.
It is still a bit unclear where to put the dedicated "component-cli", please check and find a suitable Repo, possibly we could just keep it where it is, as it is in its own repo already.

Done Criteria

• Code has been moved

What happened:

Edit: Seems to be an issue in the Landscaper chart. If chart is installed into a different namespace than "ls-system" (and the namespace ls-system does not exist) the Landscaper pod is broken with the message "service account could not be created in a namespace ls-system, which does not exist" in the logs.

Installing landscaper with the quickstart command fails into a new cluster if no namespace is provided with the error "that a service account could not be created in a namespace ls-system, which does not exist".

What you expected to happen:

How to reproduce it (as minimally and precisely as possible):

Anything else we need to know:

Environment:

We should add the binaries for linux and darwin to a release.

An example could be found here: https://github.com/gardener/component-cli/blob/main/.ci/update_release.py

Description
Implement a set of CLI Commands which help endusers to debug issues / find errors within a set of data objects / targets and sub installations. Those commands should be able to identify (and output) erroneous objects within a deployment, e.g. it should display the failing deploy item, including the complete path to this deploy item.
This should especially work for scenarios where component B depends on some exported data object from a deployment of component A (where component A is not owned by component B owner). At least the error should indicate that deployment B does not work because the data object to be imported is not available / in error state.
Additionally, there should be a command which visualises a complete dependency tree of a deployment.

Done Criteria

• All Features implemented
• Code has been reviewed by other team members
• Unit Tests created for new code
• Integration Test Suite updated (if applicable)
• Internal technical Documentation updated
• Enduser Documentation updated (if applicable)
• Successful demonstration in Review

Description
Implement a new CLI Command, which is able to validate local blueprints and component descriptors. It should also be possible to render blueprints locally, where the expected outputs are all deploy items & sub installations, which would be created in the cluster by the blueprint / component descriptor. This should enable endusers of the CLI to verify/check their locally developed component(s) whether they are consistent and at the same time directly see which objects would be created by the landscaper on the cluster.

Done Criteria

• All Features implemented
• Code has been reviewed by other team members
• Unit Tests created for new code
• Integration Test Suite updated (if applicable)
• Internal technical Documentation updated
• Enduser Documentation updated (if applicable)
• Successful demonstration in Review

What would you like to be added:

Currently the quickstart does install the raw landscaper chart with the provided values.
For a quickstart it would be good to default some values that help for local/dev scenarios like enable all deployers by default.

Which would be then also good to disable that behavior via flag .e.g --disable-internal-deployers

In the future we could also think of deploying the deployers as separate controllers with their own charts

Description
Before we can build good landscaper-components for existing Gardener components, we need to have a good understanding of the currently used 'landscape-setup'.

Description

The render blueprint command fails when the blueprint contains a reference to a json schema stored in the local component descriptor. Similar problems will occur if other local resources of the component descriptor are referenced.

Done Criteria

• All Features implemented
• Code has been reviewed by other team members
• Unit Tests created for new code
• Integration Test Suite updated (if applicable)
• Internal technical Documentation updated
• Enduser Documentation updated (if applicable)
• Successful demonstration in Review

I'm using Harbor as an OCI repository, I've added my user, password, registry under these env vars: ${OCI_USER}, ${OCI_PASS} and ${OCI_REPO}. ${REPO} is a harbor project that I've created for artefacts. I have done docker login -u ${OCI_USER} -p ${OCI_PASS} ${OCI_REPO}.

Both blueprint and component push produce authentication errors. I'm using the OSX keyring

landscaper-cli blueprints push
${OCI_REPO}/${REPO}/blueprints/<blueprint name>:${VERSION} blueprints/service-a

I get error: authentication for ${REPO} cannot be found :

Level(-10) ociKeyring added authentication for "${REPO}" from default docker config
Level(-10) ociKeyring added authentication for "https://index.docker.io/v1/" from default docker config
authentication for ${REPO} cannot be found

landscaper-cli components-cli component-archive remote push
components/service-a

Level(-10) added authentication for "${REPO}" from default docker config
Level(-10) added authentication for "https://index.docker.io/v1/" from default docker config
authentication for $REPO cannot be found

I've debugged a bit - the structure from dockerconfig is empty.

Commands of the component-cli should be integrated. This includes the removal and redirection of component-cli commands now implemented there.

Done Criteria

• All Features implemented
• Code has been reviewed by other team members
• Unit Tests created for new code
• Integration Test Suite updated (if applicable)
• Internal technical Documentation updated
• Enduser Documentation updated (if applicable)
• Successful demonstration in Review

Description
For the CLI, there needs to be a Test Suite, which should cover all CLI-related integration tests. We need to come up with a test setup / framework, which can easily be enhanced with all CLI-Tests that are needed in the future.

Done Criteria

• Concept for a "Framework" for a CLI Test Suite discussed and agreed
• "Framework" implemented and set-up as per the concept
• Code has been reviewed by other team members
• Internal technical Documentation created for the framework
• Successful demonstration in Review

What would you like to be added:

For a local helm chart resource of type dir, the option preserveDir is set to false by default.
For this to work, the helm chart directory has to be placed in an otherwise parent directory.
If the option preserveDir is not set to true explicitly, this parent directory has to be entered as the value of parameter path.
If this is not applied correctly, the landscaper cli will accept the local resource but the deployment in the landscaper will fail with a rather cryptic error message.

Example:

├── chart
│   └── ingress-nginx

This will fail

type: helm
name: ingress-nginx-chart
version: v0.1.0
relation: external
input:
  type: "dir"
  path: ./chart/ingress-nginx

This will succeed

type: helm
name: ingress-nginx-chart
version: v0.1.0
relation: external
input:
  type: "dir"
  path: ./chart/ingress-nginx
  preserveDir: true

For the user it would be helpful if the landscaper cli issues a warning or even an error when trying to add a helm chart resource with the bottommost directory without setting option preserveDir to true.

Why is this needed:

Catching this error on the cli level will result in a more readable/understandable error message.
It also helps the user to immediately take action upon this error instead inspecting the landscaper error logs.

What would you like to be added:

I a blueprint has complex import or export data it might be useful to render these automatically from golang types. An example implementation could be found here: gardener/gardener#5276.

In a first step the json schema are created and provided in go function. In the next step, the import section of the blueprint is created and the json schema files added to the blueprint as local files.

Why is this needed: