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

Ulf Lilleengen lulf at redhat.com
Mon Oct 9 12:01:36 UTC 2017


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




More information about the enmasse mailing list