[EnMasse] Use pre-existing configmap "address-space-default"

Thu Oct 12 10:20:17 UTC 2017

Hi Ulf,

>>> Instead of that, perhaps a better approach would be to create this implicit address space in the deployment script instead.
>> Sounds good. I guess that would mean providing a "default-addressspace.json" in the release zip file and using it in the deployment script (?).
>> That would enable easy changes to the default address space config.
> Agreed.

Ok, good. Can you create a Github Issue for this change so that we can track it?

The main issue we are facing right now, is how to configure EnMasse to use an external authentication service while only using *one* Kubernetes namespace for EnMasse and our application.
Approaches I've tried:

- configuring EnMasse in "singleInstance" mode:
updating the address space doesn't seem possible:
----
POST /v1/addressspaces       (create and append single or multiple (AddressSpace, or AddressSpaceList) or fail if exists)
 - with AddressSpaceList => 500 response, exception in log:
-----
2017-10-12 09:41:18 WARN  DefaultExceptionMapper:32 - Returning server error HTTP status 500
java.lang.NullPointerException
	at io.enmasse.address.model.v1.AddressSpaceV1Deserializer.deserialize(AddressSpaceV1Deserializer.java:56)
	at io.enmasse.address.model.v1.AddressSpaceV1Deserializer.deserialize(AddressSpaceV1Deserializer.java:48)
	at io.enmasse.address.model.v1.AddressSpaceV1Deserializer.deserialize(AddressSpaceV1Deserializer.java:36)
-----
 - with single AddressSpace => 200 response but no change to address space; error in log:
2017-10-12 09:43:04 ERROR ConfigMapAddressSpaceApi:79 - Error createReplace on {name=default,namespace=hono,type=standard,plan=unlimited}
----
PUT  /v1/addressspaces       (replace a single or multiple (AddressSpace, or AddressSpaceList))
 - with AddressSpaceList => 405 Method Not Allowed response
 - with single AddressSpace => 405 Method Not Allowed response
----
PUT  /v1/addressspaces/:name (create or replace)
 - with single AddressSpace => 405 Method Not Allowed response

- configuring EnMasse in "multiInstance" mode:
when creating the address space (configured to use the same namespace as the address controller), there is an exception when the address controller is trying to create the (already existing) namespace.

Do you see another solution to this, using the 0.13 release?

Or do you see a chance to implement this in the short term:
>    The address controller would then attempt to create a namespace for the detected address space only if it does not match the 'global'
> namespace of the address controller.
? 

Best regards

 Carsten Lohmann

-----Ursprüngliche Nachricht-----
Von: Ulf Lilleengen [mailto:lulf at redhat.com] 
Gesendet: Montag, 9. Oktober 2017 14:02
An: Lohmann Carsten (INST/ECS4) <Carsten.Lohmann at bosch-si.com>; enmasse at redhat.com
Betreff: Re: AW: [EnMasse] Use pre-existing configmap "address-space-default"

On 09. okt. 2017 13:46, Lohmann Carsten (INST/ECS4) wrote:
> Hi Ulf,
> 
>> Instead of that, perhaps a better approach would be to create this implicit address space in the deployment script instead.
> Sounds good. I guess that would mean providing a "default-addressspace.json" in the release zip file and using it in the deployment script (?).
> That would enable easy changes to the default address space config.

Agreed.

> 
> 
>> The address controller would then attempt to create a namespace for the detected address space only if it does not match the 'global'
>> namespace of the address controller. If it matches the global namespace, the 'single-tenant' logic would be invoked instead.
> I wasn't aware of the address controller actually creating kubernetes namespaces. Is there a requirement (or recommendation) for each address space to be associated with its own kubernetes namespace?
> 

It does in the multitenant mode, one for each address space. In the address model definition we don't mandate that address spaces are running in their own kubernetes namespace, so I'd argue this is somewhat an implementation detail when looking at the service from the outside.

However, using multiple namespaces provides isolation to prevent one address space from reaching the others.

The downside is of course that we require some more privileges when deployed in a multitenant fashion (at least on OpenShift), but we're working to minimize the stuff that is required there.

In the future, we might end up in a situation where we deploy multiple address spaces within the same namespace, but we might then want to look at leveraging sharing/making more of the address space infrastructure multitenant aware (esp. the router).

Best regards,

Ulf

> Best regards,
> Carsten Lohmann
> 
> -----Ursprüngliche Nachricht-----
> Von: Ulf Lilleengen [mailto:lulf at redhat.com]
> Gesendet: Freitag, 6. Oktober 2017 14:32
> An: Lohmann Carsten (INST/ECS4) <Carsten.Lohmann at bosch-si.com>; 
> enmasse at redhat.com
> Betreff: Re: [EnMasse] Use pre-existing configmap "address-space-default"
> 
> Hi Carsten,
> 
> I would like to explore alternative ways to deploy the single tenant variant as part this feature. Today, the address controller will 'automagically' create a tenant within its namespace unless it is deployed in multitenant mode. To support not deploying the 'single-tenant' address space, we'd have to add another configuration parameter to the address controller. What I don't like about that is that we need to support an extra parameter in the openshift template + we really need 4 different kubernetes templates to support the different options for deploying.
> 
> Instead of that, perhaps a better approach would be to create this implicit address space in the deployment script instead.
> 
>    The address controller would then attempt to create a namespace for the detected address space only if it does not match the 'global'
> namespace of the address controller. If it matches the global namespace, the 'single-tenant' logic would be invoked instead. Your feature request would then be easily implemented as another switch to the deployment script.
> 
> With this approach, we can remove the MULTIINSTANCE/MULTITENANT parameter for the address controller as well and have EnMasse work in multitenant mode on kubernetes without modifications to the template.
> 
> This shouldn't be a lot of work really, but there might be some obstacles that I'm not aware of right now.
> 
> 
> On 06. okt. 2017 13:48, Lohmann Carsten (INST/ECS4) wrote:
>> Hi,
>>
>> we want to use the "default" address space with a non-standard 
>> configuration (using the "external" authenticationService).
>>
>> Instead of using the addressController REST-API to update the "default"
>> address space, it would look easier to me to just create an 
>> "address-space-default" configMap with the adapted configuration
>> **before** deploying EnMasse and have EnMasse use that configMap. 
>> Only if no such configMap exists, EnMasse should create it with the 
>> default config.
>>
>> Would adding support for this in EnMasse be feasible?
>>
>> Best regards
>>
>> *Carsten Lohmann
>> *
>> (INST/ECS4)
>> Bosch Software Innovations GmbH | Ullsteinstr. 128 | 12109 Berlin |
>> GERMANY| www.bosch-si.com <http://www.bosch-si.com>
>> Tel. +49 30 726112-130 | Fax +49 30 726112-100 | 
>> carsten.lohmann at bosch-si.com <mailto:carsten.lohmann at bosch-si.com>
>>
>> Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 
>> B
>> Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten Lücke; Geschäftsführung:
>> Dr.-Ing. Rainer Kallenbach, Michael Hahn
>>
>>
>>
>>
>>
>> _______________________________________________
>> enmasse mailing list
>> enmasse at redhat.com
>> https://www.redhat.com/mailman/listinfo/enmasse
>>
> 

--
Ulf