As we’re working on splitting Shipper itself into two separate
components (#272), an obvious first step is to split the shipper command
into two. I’m going with shipper-mgmt and shipper-app, because that's
how we described it in the epic.
In this first step, we just moved controllers around and not changed
behavior, as changes to the binaries, CI pipeline and k8s Deployments
are a fair amount of code churn by themselves.
shipper-mgmt now runs the following controllers:
Application, as this should be the source of truth where most things
will be derived from
Release, for the same reasons as above. This is user generated data
that can’t be reconstructed, so it’s the source of truth as well
Rollout Block, as it prevents Applications and Releases from moving
forward in the presence of rollout blocks.
Webhook, as it guards against bad changes mostly to Applications and
Releases. We could split it in two, as it also checks that the target
objects are at least well-formed, but I'm skipping it for now, as people
usually don't touch those objects directly, and hopefully k8s 1.16
validations will cover this anyway.
shipper-app now runs the following controllers:
Installation, as maintaining installations should be local to the
application clusters
Capacity, as above
Traffic, as above
Janitor, as it’s responsible for cleaning up after removed
InstallationTargets. This is likely to change in the very near future
though (see #278).
Also, as we’d need shipper-state-metrics to be deployed to every application
cluster as well as the management cluster, having two separate
Deployments becomes a bit bothersome. Also, most of the application
cluster bits are not exactly in use, I'm dropping those in favor of
keeping these metrics only in shipper-mgmgt
As we’re working on splitting Shipper itself into two separate components (#272), an obvious first step is to split the shipper command into two. I’m going with shipper-mgmt and shipper-app, because that's how we described it in the epic.
In this first step, we just moved controllers around and not changed behavior, as changes to the binaries, CI pipeline and k8s Deployments are a fair amount of code churn by themselves.
shipper-mgmt now runs the following controllers:
shipper-app now runs the following controllers:
Also, as we’d need
shipper-state-metricsto be deployed to every application cluster as well as the management cluster, having two separate Deployments becomes a bit bothersome. Also, most of the application cluster bits are not exactly in use, I'm dropping those in favor of keeping these metrics only inshipper-mgmgtCloses #273, #195.