[EnMasse] Adapting the EnMasse deployment

[Ulf Lilleengen]

On 16. juni 2017 12:08, Lohmann Carsten (INST/ECS4) wrote:
> Hi Ulf,
> 
>>  Out of curiosity, what is it that you wish to modify in this config?
> 
> We want to use a config similar to the one used in Hono:
> 
> https://github.com/eclipse/hono/blob/master/dispatchrouter/qpid/qdrouterd-with-broker.json
>  > I.e. with our sslProfile / certificates and vhost definitions.
> 

One thing to look out for there is that the enmasse router config is 
created dynamically from a static fixed template + configuration from 
the router agent (address config for instance).

To make it work properly in EnMasse, you have to merge that config with 
the static enmasse router config:

https://github.com/EnMasseProject/dockerfiles/blob/master/qdrouterd/qdrouterd.conf.template


>  > […] and the single instance variant would have everything as 
> top-level YAML structures like you propose.
> 
>  > Assuming that you're mainly interested in the single-tenant 
> deployment, is that something that would seem useful?
> 
> Yes, that would be useful. And I guess that for now, we will only use a 
> single-tenant deployment.
> 

Ok, created https://github.com/EnMasseProject/enmasse/issues/40 for that.

> Best regards
> 
> *Carsten Lohmann
> *
> (INST/ECS4)
> Bosch Software Innovations GmbH | Schöneberger Ufer 89-91 | 10785 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
> Geschäftsführung: Dr.-Ing. Rainer Kallenbach, Michael Hahn
> 
> 
> 
> *Von:*Ulf Lilleengen [mailto:ulilleen at redhat.com]
> *Gesendet:* Mittwoch, 14. Juni 2017 17:41
> *An:* Lohmann Carsten (INST/ECS4) <Carsten.Lohmann at bosch-si.com>
> *Cc:* enmasse at redhat.com
> *Betreff:* Re: [EnMasse] Adapting the EnMasse deployment
> 
> On Wed, Jun 14, 2017 at 10:16 AM, Lohmann Carsten (INST/ECS4) 
> <Carsten.Lohmann at bosch-si.com <mailto:Carsten.Lohmann at bosch-si.com>> wrote:
> 
>     Hi,
> 
>     we want to use EnMasse in connection with Eclipse Hono on
>     Kubernetes. For that, we want to set a special config to be used by
>     the dispatch router (i.e. qdrouterd.json).
> 
>     However, with the current structure of the EnMasse deployment yml,
>     this looks not so straightforward, as the nested JSONs in
>     enmasse.yaml are not really readable
> 
>     and that makes it hard to find the places where the structure can be
>     adapted. It basically means changes have to be done in the jsonnet
>     source files of the enmasse repo, re-creating the enmasse.yaml there.
> 
>     It would look much easier to me, having an enmasse.yaml where there
>     are top-level YAML structures instead of the nested JSON fragments.
>     This would allow for changes directly in that file.
> 
>     What were the motivations for using that nested structure and would
>     it be feasible to change it to a non-nested structure that is easy
>     to read and adapt?
> 
> Hi Carsten,
> 
> Out of curiosity, what is it that you wish to modify in this config?
> 
> The reason that the JSON is nested is for creating multiple instances of 
> EnMasse (router network and everything. You can turn this on setting 
> MULTIINSTANCE=true in the address controller deployment config). The way 
> it works is that the address controller processes that nested JSON 
> template for each instance that is created. The reason for nesting it as 
> JSON is that kubernetes does not support templates natively like in 
> OpenShift, and embedding it as JSON in a ConfigMap is our only way of 
> making it available for the address controller in a kubernetes setup.
> 
> However, after experiencing the same pain of modifying that JSON blob 
> even for single-instance deployments, I'd like to propose that we split 
> the kubernetes enmasse.yaml into a multi-instance and single-instance 
> variant, where the multi instance variant would look like the current 
> one, and the single instance variant would have everything as top-level 
> YAML structures like you propose. Assuming that you're mainly interested 
> in the single-tenant deployment, is that something that would seem useful?
> 
> -- 
> 
> Ulf
> 
> 
> 
> _______________________________________________
> enmasse mailing list
> enmasse at redhat.com
> https://www.redhat.com/mailman/listinfo/enmasse
> 

-- 
Ulf