Add channels support to the Habitat type

[nhlfr]

Habitat applications can exist in the different "channels" - like "staging", "production", "unstable" etc. Those names can be configured by the user.

Those channels will be expressed as labels in Kubernetes.

This idea requires adding the additional field in Habibat type - Channel string

[zeenix]

likely a noob question but how does channels apply to a running habitat app instance?

[nhlfr]

@zeenix Channel will we just an information what kind of instance that will be. Probably nothing more.

[nhlfr]

We had a bigger discussion about the whole architecture today. I'm writing down here the things we agreed about.

Basic idea

The idea is to have multiple channels for applications, i.e. production, staging etc. One habitat applications can use many channels and each of that channel instance can be deployed multiple times.

Main problem

Kubernetes allows to create only one object with the same name. There is no way to bypass name uniqueness.

Solution

The solution is to add a random string on the suffix of Habitat object name, i.e. example-standalone-habitat-d5zp2. That will need to be done in kubernetes exporter in Habitat.

Promoting applications

Habitat object in habitat-operator is going to have one more field called channel (type string).

habitat-operator is going to have an another type of object, called HabitatPromote, which will have the following format:

apiVersion: habitat.sh/v1
kind: HabitatPromote
metadata:
  name: example-standalone-habitat
spec:
  habitatName: example-standalone-habitat
  oldChannel: staging
  newChannel: production
  replace: false

After consuming that object, operator is going to look for the Habitat object with appropriate labels (habitat name and channel being equal to oldChannel). Then it's going to update channel field of the found Habitat object. That will automatically trigger the update of deployments and pods.

[asymmetric]

Closing this for now. We will revisit this if needed.