Skip to content

Conversation

meiserloh
Copy link
Contributor

No description provided.

…pply-blueprint-continuously

# Conflicts:
#	pkg/application/blueprintSpecChangeUseCase.go
#	pkg/bootstrap.go
this way, whe use cases don't need to load
the blueprint everytime. If there is an
concurrent update, we handle the conflicts
when we try to update the blueprint ourselves.

If we use the same blueprint the whole time
we don't need to recalculate the state diff.
We only have to do this, if we need to
reconcile the CR again, e.g. for
non-blocking health checks.
Otherwise, we would publish dozens of this
events because we will validate the blueprint
as every reconciliation now
We have a condition instead.
We also want to prevent event duplication over
multiple reconciles.
We show the effective blueprint in status.
There could be thousands of this event if
we recalculate the effective blueprint
on every reconciliation.
add condition for healthy ecosystem
We removed the maintenance mode. Therefore,
the only thing this use case still did,
was to check the dry run flag.
In previous versions, the state diff was
calculated once and then got persisted in
the blueprint CR. Therefore, we had to write
all fields there.

Now we calculate the state diff at every
reconciliation. Because of that we can now
decide which fields we want to publish in the
blueprint CR.
If the ecosytem is unhealthy, an error is thrown and
another reconciliation gets triggered.
This way, we repeat the health check until everything
is healthy.
If the ecosystem is healthy afterward,
the post-processing will always run.
We need this later to skip some steps
while applying the blueprint.
We now throw an error to trigger a
reconciliation.
It is also now safe to just retry.
We can now see the exact state of
the self-upgrade via the new generated
state diff and the component CR install
versions.
…ntinuously' into feature/121.3-remove-components

# Conflicts:
#	pkg/adapter/kubernetes/blueprintcr/v2/blueprintSpecCRRepository_test.go
#	pkg/domain/blueprintSpec.go
#	pkg/domain/blueprintSpec_test.go
#	pkg/domain/ecosystem/ecosystemHealth.go
#	pkg/domain/ecosystem/ecosystemHealth_test.go
#	pkg/domain/events.go
#	pkg/domain/events_test.go
…ntinuously' into feature/121.3-remove-components

# Conflicts:
#	pkg/application/blueprintSpecChangeUseCase_test.go
#	pkg/domain/events_test.go
…ntinuously' into feature/121.3-remove-components
…ntinuously' into feature/121.3-remove-components
…ntinuously' into feature/121.3-remove-components
…ntinuously' into feature/121.3-remove-components

# Conflicts:
#	pkg/domain/events.go
…ntinuously' into feature/121.3-remove-components
…ntinuously' into feature/121.3-remove-components

# Conflicts:
#	pkg/application/blueprintSpecChangeUseCase_test.go
…ntinuously' into feature/121.3-remove-components
…ntinuously' into feature/121.3-remove-components
…ntinuously' into feature/121.3-remove-components
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants