Consider supporting flags outside of deployment

kubernetes-retired / spartakus

[EOL] Anonymous Usage Collector

Apache License 2.0

74 stars 30 forks source link

Consider supporting flags outside of deployment #4

Closed justinsb closed 5 years ago

justinsb commented 7 years ago

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")

viglesiasce commented 7 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:

environment: dev, staging, production
install-mechanism: minikube, kubeadm, gke, etc

This could help in the analysis of the data to partition out various use cases.

dasmb commented 7 years ago

@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:

Target datacenter (named public cloud vs. an unnamed private DC)
Hosting type (kubeadm, hyperkube, traditional Hard Way, etc)
Install Manager/Mechanism (gke, kargo, handrolled cluster, kompos8, Stackpoint, Tectonic etc; this gives us a way to shout out the popular installers and identify what techniques are "production proven" vs "fastest to hello world")

fejta-bot commented 5 years ago

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

fejta-bot commented 5 years ago

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

fejta-bot commented 5 years ago

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

k8s-ci-robot commented 5 years ago

@fejta-bot: Closing this issue.

In response to [this](https://github.com/kubernetes-incubator/spartakus/issues/4#issuecomment-503798373): >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](https://github.com/fejta). >/close Instructions for interacting with me using PR comments are available [here](https://git.k8s.io/community/contributors/guide/pull-requests.md). If you have questions or suggestions related to my behavior, please file an issue against the [kubernetes/test-infra](https://github.com/kubernetes/test-infra/issues/new?title=Prow%20issue:) repository.