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

[Lohmann Carsten (INST/ECS4)]

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.


> 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?

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