[fabianofranz]

Proposes how kubectl will interact with the API for the Service Catalog.

Trying to cover all described use-cases, some by the use of existing commands and some by the introduction of new commands. TBD if new ones are going to be part of the main binary, or plugins.

@kubernetes/sig-cli-proposals @smarterclayton @pmorie @jwforres looking for feedback.

[davidopp]

Sorry for the drive-by question, but I was wondering: do service instances run in the cluster belonging to the application that is consuming the service, or in a cluster belonging to the service provider (broker)?

[jwforres]

@davidopp short answer: yes to both, it depends on the broker.

The ServiceInstance object is a namespaced resource that tells the service catalog to talk to a particular broker to provision a service. That broker may then choose to create things in that same namespace, in a different namespace, in a different cluster, or may not actually be creating any k8s resources at all (e.g. provision just creates an account/space for you with some third party SaaS provider)

The Binding object is what then makes the ServiceInstance consumable by your application by providing the connection info / credentials / etc.

More info here https://github.com/kubernetes-incubator/service-catalog#introduction

[deads2k]

I don't think we start allowing our "favorite" non-core projects into kubectl. A binary-plugin seems more appropriate.

[philips]

I just want to echo the sentiment that this proposal should only consider a binary plugin not making it built-in.

[fabianofranz]

Makes sense to me, we'll have V0 for plugins pretty soon so this looks like a great first use of it.

[pmorie]

@deads2k since binary plugins shouldn't be able to change the meaning of primitives like 'get' and 'describe', do you have in mind that we will have separate subcommands for these, like:

kubectl service-catalog get
kubectl service-catalog describe

I would strongly prefer to avoid doing this, and just make get and describe driven off of openapi/swagger so that we would get basic functionality for free in any API server that serves swagger/openapi.

cc @fabianofranz

[liggitt]

three initial categories of additions make sense to me:

• get/describe for custom objects accomplished server-side - Proposal: Server-side kubectl get #363
• generators for object-specific creation nested under kubectl create <mykind> that support all the conventions of the other kubectl create generators (--dry-run, different --output formats, etc). This seems like it should a really structured plugin (plugin can be interrogated for args/flags/usage/help info, user invokes kubectl, kubectl invokes plugin with args/flags, plugin outputs yaml or json that kubectl can transform/create/output in all the standard ways)
• completely independent commands that nest within kubectl

[jbeda]

One comment -- it might be useful for everyone to build a CLI for the service broker outside of kubectl as a way to iterate on the UX. This can then be converted to a plug-in as that becomes available. That way if the plug-in mechanism doesn't work there is something that works here. While not 100% the same, both kubeadm and kubefed are separate CLIs for this reason.

[pmorie]

@jbeda

CLI for the service broker

A service broker is something that offers a set of services that the catalog consumes. We want to build a CLI for the catalog, not a broker.

[pmorie]

I think this should be moved to the service-catalog incubator repo, and discussed there. Since we have kubectl extensions now, we can package it as a product of that repository. There's a lot of interest in this in service catalog SIG.

[pwittrock]

Why do we need servicecatalog get? Can't we use extension mechanisms to get what we need? Same question for describe.

[pmorie]

I have a feeling that this proposal is somewhat outdated, as the generic resource support has improved a lot in kubectl. Perhaps I'm wrong.

[fabianofranz]

I have a feeling that this proposal is somewhat outdated

Definitely, I'll work on a review and moving this to the appropriate repo and having in mind the WIP implementation.

[pmorie]

@fabianofranz awesome, thanks a million

[pmorie]

should we close this for now?

[fabianofranz]

BTW, I'm having some trouble finding a way to expose the API to plugins that finds wide acceptance by other groups. The proposal originally (PR here) wanted to expose it through a proxy (by using the underlying kubectl proxy mechanism) but it's not being well accepted due to security concerns.

So most likely, at least for now plugins will be responsible to access the API by themselves (using one of the Kube clients), or by invoking the kubectl binary.

I'll open a PR to the WIP implementation reflecting that.