[EnMasse] using the service broker apis

[Marko Lukša]

On 27. 06. 2017 10:54, Gordon Sim wrote:
> On 27/06/17 09:40, Marko Lukša wrote:
>>
>> On 27. 06. 2017 10:32, Gordon Sim wrote:
>>> I've been experimenting with using the service broker integration 
>>> from address-controller and it all works very nicely. (The first 
>>> address always takes a while as it has to start up all the 
>>> infrastructure which may involve pulling down latest images.)
>>>
>>> One thing that I do think is confusing though is the option to put 
>>> things into a particular project, as the infrastructure is *not* 
>>> actually placed in that chosen project. You even get a notice at the 
>>> end:
>>>
>>>     "enmasse-queue-2ps8x has been added to My Project successfully"
>>>
>>
>> "enmasse-queue-2ps8x" in this case is the service Instance object, 
>> which is indeed added to "My Project",
>
> Ok, that makes sense. Is there a way to view that service instance via 
> CLI tools (oc or kubectl)?
>

You need kubectl version 1.6+ and then configure it to use the service 
catalog API server instead of the main OpenShift API server, like this:

|alias sc="kubectl --server=https://$(oc get route apiserver -n 
service-catalog -o jsonpath=\"{.spec.host}\") --insecure-skip-tls-verify"|

Then you can use /sc/ to list brokers, serviceClasses, instances and 
bindings, as explained here: 
https://github.com/EnMasseProject/enmasse/tree/master/documentation/servicecatalog#provisioning-addresses-through-the-cli

>> but the infrastructure created by the broker is in a different 
>> namespace (could also be in a completely different cluster). The idea 
>> of the Service Catalog is to give users the ability to self-provision 
>> black box services, but a broker could also provision the services in 
>> the same namespace, allowing the user access to the internals of a 
>> service (white box).
>>
>> The namespace in which a service instance is created is now passed to 
>> the broker, so we could create the MaaS infrastructure in that same 
>> namespace. But, do you really want/need that?
>
> Personally I feel it would be a useful option, but that may just be 
> due to my familiarity with the 'old ways' and a general dislike of 
> 'black boxes' :-)
>

The main problem with this is that users would then be able to 
reconfigure the provisioned infrastructure components directly, without 
going through the Service Catalog/Broker mechanism. This shouldn't be 
allowed (the SC expects it is the only one modifying the services).

> Let me think on it some more.
>
> _______________________________________________
> enmasse mailing list
> enmasse at redhat.com
> https://www.redhat.com/mailman/listinfo/enmasse

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/enmasse/attachments/20170627/9c65e9a7/attachment.htm>