Skip to content
This repository has been archived by the owner on Apr 22, 2020. It is now read-only.

Deal with non-landscaper-managed conflicting components in a more elegant way #22

Open
rollulus opened this issue Jan 23, 2017 · 3 comments

Comments

@rollulus
Copy link
Collaborator

In a more descriptive, less mysterious fashion

@rollulus rollulus changed the title Deal with non-landscaper-managed components in a more elegant way Deal with non-landscaper-managed conflicting components in a more elegant way Jan 23, 2017
@rollulus
Copy link
Collaborator Author

i.e. improve this scenario: helm release is created manually. landscaper is instructed to create it. landscaper ignores existing non-landscaper component. create will fail since it already exists.

@Kyrremann
Copy link

Not sure if this is the correct place to ask questions/help. Anywho, is this the reason for landscaper having trouble upgrading components if you have also used helm upgrade manually on your cluster?

When I use helm upgrade to quickly test some new features on a component, and I later release it via our "proper" channels, I end up with landscaper failing with the following error message:

CreateComponent failed" error="cannot re-use a name that is still in use"

@rajiteh
Copy link

rajiteh commented May 4, 2018

We have statefulsets which are non trivial to completely purge and recreate therefore is not feasible to be used in landscaper because of this issue. If landscaper can "migrate" these releases, may be out of band as a one off command even, it would make things much easier for adoption of this tool.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants