WIP: Introduce labels to stevedore context

[jskswamy]

Currently stevedore only supports predefined labels type, environmentType and environment, some of the labels like, environment, environmentType causes confusion to the consumer.

To avoid these confusion, this PR which fixes #1 as well proposes a changes which removes these predefined labels and add them as flexible labels which user themself can define when adding stevedore context, rest of the matches everything works the same way.

current

contexts:
- name: minikube
  kubernetesContext: minikube
  kubeConfigFile: ""
  type: local
  environment: local
  environmentType: dev
current: minikube

proposed

contexts:
- name: minikube
  kubernetesContext: minikube
  kubeConfigFile: ""
  labels:
    type: local
    environment: local
    environmentType: dev
current: minikube

The only feature which this feature couldn't match with the original implementation is the predefined weight assigned to the labels since label is a map[string]string, each and every time the label is read, order could be very different and result in non consistent value getting applied.

To avoid this I'm thinking of sorting the labels in alphabetical order all the time, if we do this we will have the feature parity with the current way of working.

Let me know your thoughts before making such changes.

[dineshba]

Can we have labels section in context file which defines the label's weight?

labels:
- name: context
  weight: 4
- name: environment
  weight: 2
- name: environmentType
  weight: 1

contexts:
- name: staging-1
  kubernetesContext: staging-1
  kubeConfigFile: ""
  labels:
    environment: staging-1
    environmentType: staging
- name: production-1
  kubernetesContext: production-1
  kubeConfigFile: ""
  labels:
    environment: production-1
    environmentType: production
current: staging-1

[jskswamy]

What will be the weight if the label is not defined? I can think of two possible solution

1. Go back to alphabetical order, this could cause more confusion
2. Ignore the labels which are not defined or automatically update labels section based when the context is added / modified / removed, even in this scenarios what will happen if the user manually removes the entries from the config file then what will be the behavior?

we will be end up adding more code to support this feature. to solve the problem simply why no throw some kind of warning when condition multiple matches

[prabhu43]

I feel alphabetical sorting of labels does not fulfil the consumer need, it might cause more confusions

I agree with @dineshba. Adding labels section defined in stevedore config helps to avoid confusions.
And also we can make the weight field mandatory for labels.

If we feel this might take lot of effort and time, we can do first release with alphabetical sorting of labels and will create an issue to implement labels section with weights in stevedore config

[prabhu43]

Another thought: environment should be mandatory in stevedore context, it should not be optional in labels

If there is no different env, no need of going for stevedore. helm is enough

[dineshba]

Stevedore prefers configuration over conventions upto some extend. So I feel alphabetical sorting of labels is more of convention and I would like to defer from it.

So first version: Can we go ahead with just three dimensions ?
context, environment, environmentType

Logically, weight will be environmentType < environment < context

Also, I assume code change will be minimal.

[arunvelsriram]

Agree with @dineshba on going ahead with only three dimensions initially.

Also for flexible dimensions, how about just specifying the list of labels and weight will be assigned using our existing implementation:

stevedore/pkg/stevedore/conditions.go

Line 32 in b28eb1a

defaultConditionWeights = NewWeights(knownCriteria)

stevedore/pkg/stevedore/weights.go

Line 25 in b28eb1a

values[cr] = int(math.Pow(2, float64(index)))

Example:

labels:
  - environment # weight is 2^0 = 1
  - context # weight is 2^1 = 2

contexts:
- name: minikube
  kubernetesContext: minikube
  kubeConfigFile: ""
  labels:
    environment: dev
    context: minikube
current: minikube

[jskswamy]

Looks good to me @arunvelsriram @dineshba, will go ahead and implement it

[dineshba]

I have rebased with latest master @jskswamy ... I can pick up some tasks if there is some in this PR