Provide the easy-to-remember url addons.k8s.io for applying addons

[luxas]

Given the work we're trying to do in @kubernetes/sig-cluster-lifecycle, and given that we've chosen to use kubectl apply -f as the main addon applier, it would be great to have a easy-to-remember url for applying addons, like this:

kubectl apply -f addon(s).k8s.io/network/flannel.yaml
kubectl apply -f addon(s).k8s.io/network/calico.yaml
kubectl apply -f addon(s).k8s.io/network/weave.yaml

kubectl apply -f addon(s).k8s.io/core/dns.yaml
kubectl apply -f addon(s).k8s.io/core/dashboard.yaml
kubectl apply -f addon(s).k8s.io/core/heapster.yaml
...

or just

kubectl apply -f addon(s).k8s.io/flannel.yaml
kubectl apply -f addon(s).k8s.io/calico.yaml
kubectl apply -f addon(s).k8s.io/weave.yaml

kubectl apply -f addon(s).k8s.io/dns.yaml
kubectl apply -f addon(s).k8s.io/dashboard.yaml
kubectl apply -f addon(s).k8s.io/heapster.yaml
...

This would be very user-friendly, and we should document the possible addons installable this way at the main site.

The more exotic addons could (and should) be kept away from this way of installing the addons, only the most common should be here.

We could just have a redirection file in this repo that points to the source of truth somewhere in the main k8s repo or at other places.

@kubernetes/sig-cluster-lifecycle @thockin @pwittrock

[thockin]

I can do this if it is what people want for the UX and you can tell me what
the destination of the redirect is.

On Tue, Aug 23, 2016 at 1:02 PM, Lucas Käldström [email protected]
wrote:

Given the work we're trying to do in @kubernetes/sig-cluster-lifecycle
https://github.com/orgs/kubernetes/teams/sig-cluster-lifecycle, and
given that we've chosen to use kubectl apply -f as the main addon
applier, it would be great to have a easy-to-remember url for applying
addons, like this:

kubectl apply -f addon(s).k8s.io/network/flannel.yaml
kubectl apply -f addon(s).k8s.io/network/calico.yaml
kubectl apply -f addon(s).k8s.io/network/weave.yaml

kubectl apply -f addon(s).k8s.io/core/dns.yaml
kubectl apply -f addon(s).k8s.io/core/dashboard.yaml
kubectl apply -f addon(s).k8s.io/core/heapster.yaml
...

or just

kubectl apply -f addon(s).k8s.io/flannel.yaml
kubectl apply -f addon(s).k8s.io/calico.yaml
kubectl apply -f addon(s).k8s.io/weave.yaml

kubectl apply -f addon(s).k8s.io/dns.yaml
kubectl apply -f addon(s).k8s.io/dashboard.yaml
kubectl apply -f addon(s).k8s.io/heapster.yaml
...

This would be very user-friendly, and we should document the possible
addons installable this way at the main site.

The more exotic addons could (and should) be kept away from this way of
installing the addons, only the most common should be here.

We could just have a redirection file in this repo that points to the
source of truth somewhere in the main k8s repo or at other places.

@kubernetes/sig-cluster-lifecycle
https://github.com/orgs/kubernetes/teams/sig-cluster-lifecycle @thockin
https://github.com/thockin @pwittrock https://github.com/pwittrock

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#5, or mute the thread
https://github.com/notifications/unsubscribe-auth/AFVgVFWL8iNxDRd2kY-zrbRVh811TJ7uks5qi1G7gaJpZM4JrU8v
.

[mikedanese]

sounds like we could use go.k8s.io/ for this if we get around to hosting a shortener.

[luxas]

go doesn't say much to me personally, but certainly we could go for it if you feel strongly :)

[thockin]

I don't mind adding vanity domains as long as their are not done on a lark

On Tue, Aug 23, 2016 at 1:28 PM, Lucas Käldström [email protected]
wrote:

go doesn't say much to me personally, but certainly we could go for it
if you feel strongly :)

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#5 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFVgVKIEaSe5VaVfV9_nxiu_ZCbkkvqQks5qi1fqgaJpZM4JrU8v
.

[justinsb]

We should definitely have a formal proposal for this, before we create the domain, including how updates will work. We don't want a situation where the more memorable hostname is deprecated, in favor of addonsv2.k8s.io.

For example, I think we will probably want version discovery in there, so the future addon tool can tell users when a new version is available. I don't think we should put yaml in the path. etc

[errordeveloper]

For Weave Scope we have implemented a simple template rendering based on
parameters that include version, mode of installation and other parameters.
See the documentation for details (
https://www.weave.works/documentation/scope-latest-installing/).

One of the things we do is provide current release tag set by default,
based on periodic polling of Github API.

Regarding installation mode, user has to options: pass a token and use
Weave Cloud or not pass one and use it in standalone mode. With Weave Cloud
they will only need to run a DaemonSet, and UI component is our SaaS.
However, in standalone mode they also need to run an ReplicaSet for the
UI... So the point is that when they install it, they don't need to think
in terms of Kubernetes abstractions, they just look at features of Weave
Scope they care about.

I think this approach may be of interest here.

On Tue, 23 Aug 2016, 22:09 Justin Santa Barbara, [email protected]
wrote:

We should definitely have a formal proposal for this, before we create the
domain, including how updates will work. We don't want a situation where
the more memorable hostname is deprecated, in favor of addonsv2.k8s.io.

For example, I think we will probably want version discovery in there, so
the future addon tool can tell users when a new version is available. I
don't think we should put yaml in the path. etc

—
You are receiving this because you are on a team that was mentioned.
Reply to this email directly, view it on GitHub
#5 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAPWS2_QGVmbb9VnN9Yjvi7A4EUStRDTks5qi2GEgaJpZM4JrU8v
.

[erictune]

There are some addons that won't need any template-substitution and some
that will.

The addons added by kube-up are in
https://github.com/kubernetes/kubernetes/tree/master/cluster/addons

There are 11 addons, namely:

calico-policy-controller
cluster-loadbalancing
cluster-monitoring
dashboard
dns
fluentd-elasticsearch
fluentd-gcp
gci
node-problem-detector
podsecuritypolicies
registry

Of those, 3 use some kind of template substitution, namely:
cluster-monitoring
dns
registry

I'd expect some of those that don't have templating to gain it in the
future, but maybe not all.

So, if we do the addons.k8s.io thing, we'd have to divide those into the
two categories, and decide what to do for the
ones that are templates, and have some process for moving stuff between the
two categories.

For things that are templates, would it make sense to use Helm? Actually,
for all of them, would it make sense to use helm?

On Tue, Aug 23, 2016 at 3:25 PM, Ilya Dmitrichenko <[email protected]

wrote:

For Weave Scope we have implemented a simple template rendering based on
parameters that include version, mode of installation and other parameters.
See the documentation for details (
https://www.weave.works/documentation/scope-latest-installing/).

One of the things we do is provide current release tag set by default,
based on periodic polling of Github API.

Regarding installation mode, user has to options: pass a token and use
Weave Cloud or not pass one and use it in standalone mode. With Weave Cloud
they will only need to run a DaemonSet, and UI component is our SaaS.
However, in standalone mode they also need to run an ReplicaSet for the
UI... So the point is that when they install it, they don't need to think
in terms of Kubernetes abstractions, they just look at features of Weave
Scope they care about.

I think this approach may be of interest here.

On Tue, 23 Aug 2016, 22:09 Justin Santa Barbara, <[email protected]

wrote:

We should definitely have a formal proposal for this, before we create
the
domain, including how updates will work. We don't want a situation where
the more memorable hostname is deprecated, in favor of addonsv2.k8s.io.

For example, I think we will probably want version discovery in there, so
the future addon tool can tell users when a new version is available. I
don't think we should put yaml in the path. etc

—
You are receiving this because you are on a team that was mentioned.
Reply to this email directly, view it on GitHub
#5 (comment),
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAPWS2_
QGVmbb9VnN9Yjvi7A4EUStRDTks5qi2GEgaJpZM4JrU8v>
.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#5 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AHuudnssQtDfsiVWJ2nXIBT4ce5zUdJzks5qi3NkgaJpZM4JrU8v
.

[errordeveloper]

Helm could work, and I believe Helm team would love to help us. However, I hear that some folks believe that Helm is a dependency they don't wish to see just to make addons work, which I understand, but I am neutral to this. What we did for Scope renders manifests server-side, and uses query params, I'd be happy to collaborate on something similar that would be more general.

[fejta-bot]

Issues go stale after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

Prevent issues from auto-closing with an /lifecycle frozen comment.

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

[luxas]

I'm gonna close this one per the discussions during the Developer Summit in Austin; this is not relevant anymore. SIG Cluster Lifecycle will probably discuss addon management early 2018.