Helm & Service Catalog?

[jbenton....@gmail.com]

Helm-folk,

Apologies if this is documented somewhere, I have looked and not found- 

Are there plans on the helm/tiller roadmap to hook into something like Service Catalog to support a provisioning workflow for service dependencies that are not in-cluster/wholly described by their own charts?

Cheers,

Jonah

[Paul Morie]

Hi Jonah-

You can already use helm to create service-catalog resources.  Does that answer your question, or were you looking for a deeper integration?

P

--
You received this message because you are subscribed to the Google Groups "kubernetes-sig-apps" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-apps+unsub...@googlegroups.com.
To post to this group, send email to kubernetes-sig-apps@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-apps/a9bc7ed0-daf4-45a0-b436-5657cf136cc3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[jbenton....@gmail.com]

Thanks Paul, maybe it does- IOW, using the workflow described in:

https://github.com/kubernetes-incubator/service-catalog/blob/master/docs/design.md

as a reference, given a cluster populated with a tiller and the incubator catalog, which has received the registration of an appropriate broker, if helm deploys a chart with resources:

* instance.yaml

* binding.yaml

to, for instance, bring up a database proxy, the coordinates and credentials of which another application has to consume (via PodInjectionPolicy), the provisioning and binding magic is expected to just work?

Jonah

On Monday, November 13, 2017 at 12:57:25 PM UTC-5, Paul Morie wrote:

Hi Jonah-

You can already use helm to create service-catalog resources.  Does that answer your question, or were you looking for a deeper integration?

P

On Mon, Nov 13, 2017 at 12:40 PM, <jbenton....@gmail.com> wrote:

Helm-folk,

Apologies if this is documented somewhere, I have looked and not found- 

Are there plans on the helm/tiller roadmap to hook into something like Service Catalog to support a provisioning workflow for service dependencies that are not in-cluster/wholly described by their own charts?

Cheers,

Jonah

--
You received this message because you are subscribed to the Google Groups "kubernetes-sig-apps" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-apps+unsub...@googlegroups.com.

To post to this group, send email to kubernete...@googlegroups.com.

[Aaron Schlesinger]

Hey Jonah,

We just reference the binding credentials in our PodSpec by referencing the secret that the ServiceBinding outputs. There are some charts at https://github.com/Azure/helm-charts that do this (disclosure: I work for MS and specifically on the team (in Azure) that built those charts).

For example:

• The binding: https://github.com/Azure/helm-charts/blob/master/wordpress/templates/mysql-binding.yaml
• The deployment that references the secret: https://github.com/Azure/helm-charts/blob/master/wordpress/templates/deployment.yaml

I hope that helps answer your question?

- Aaron

[Paul Morie]

Jonah-

Generally, yes.  If you create a ServiceInstance and ServiceBinding at the same time, the catalog will handle coordinating the provisioning first - once the service instance is provisioned, the catalog will do the binding.  The missing piece at this point is that PodPreset (what PIP was eventually renamed to) is in a transition state where it's being moved from kubernetes/kubernetes into the service-catalog incubator repo.  The integration of that concept with service-catalog hasn't been implemented yet, so you would ultimately just get a secret that you would have to modify your application to consume.

Does that answer your question?

P

To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-apps+unsubscribe...@googlegroups.com.

To post to this group, send email to kubernete...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-apps/a9bc7ed0-daf4-45a0-b436-5657cf136cc3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "kubernetes-sig-apps" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-apps+unsub...@googlegroups.com.

To post to this group, send email to kubernetes-sig-apps@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-apps/a605ca3d-1f30-4764-8285-9f3b09af9a57%40googlegroups.com.

[Jonah Benton]

Thank you both very much, very helpful. 

I see from Aaron's example that the use of PodPreset (formerly PIP) is not necessary just for the consumption of secrets/coordinates- they can be referred to directly via the convention in place for naming a Secret generated by a Binding. Makes sense, and obvious in retrospect. 

That said, as someone who is only periodically dipping into the firehose that is k8s, Paul's point that PodPreset is moving into ServiceCatalog seems potentially significant in terms of semantics for both, so digging in google I see:

https://github.com/kubernetes-incubator/service-catalog/issues/1041

and offshoots.

I infer the intent is:

* strengthen the distinction between policy (which would be the job of admission controllers) and mechanism (lots of ways that compliant pod specs should be produced, how they are produced should not be magical)

* tighten up ownership of lifecycle- use, e.g. helm or ksonnet or whatever client side if you are going to go the templating route for k8s resources out of cluster, but if you need any kind of generic late binding or decision-making in-cluster, use service catalog.

Maybe that's not right- but in any event, I'll follow that trail along a little further. 

Thanks again Aaron and Paul, very helpful.

Cheers,

Jonah

To post to this group, send email to kubernetes-sig-apps@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-apps/a605ca3d-1f30-4764-8285-9f3b09af9a57%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "kubernetes-sig-apps" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-apps+unsub...@googlegroups.com.
To post to this group, send email to kubernetes-sig-apps@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-apps/CACNw8moo83u4mCgZCnvojDfANpC2yAXatWojTgPHWKDwuSoAeQ%40mail.gmail.com.