Closed justinsb closed 5 years ago
I was thinking of this exact kind of thing for having well known flags to label the cluster. For example you could have something like:
This could help in the analysis of the data to partition out various use cases.
@viglesiasce Yeah this is a great value -- otherwise, your data may include lots of small, nondurable clusters mixed in with large, battle-tested clusters.
I suggest adding "prototype" to the list of environments, identifying a cluster that's likely small and temporary. Many minikubes will otherwise skew the data.
And I suggest breaking "install mechanism" into three pieces:
Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale
.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close
.
Send feedback to sig-testing, kubernetes/test-infra and/or fejta. /lifecycle stale
Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten
.
Rotten issues close after an additional 30d of inactivity.
If this issue is safe to close now please do so with /close
.
Send feedback to sig-testing, kubernetes/test-infra and/or fejta. /lifecycle rotten
Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen
.
Mark the issue as fresh with /remove-lifecycle rotten
.
Send feedback to sig-testing, kubernetes/test-infra and/or fejta. /close
@fejta-bot: Closing this issue.
So that we can easily upgrade the deployment, maybe we could put the flags outside of the container?
I am thinking of a componentconfig-style typed object, that lives either in a ConfigMap or simply a well known annotation on the kube-system namespace.
In addition, we could then provide additional metadata... for example the installation tool could include a set of tags ("aws kops")