[EnMasse] Adapting the EnMasse deployment

[Ulf Lilleengen]

On Wed, Jun 14, 2017 at 10:16 AM, Lohmann Carsten (INST/ECS4) <
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/enmasse/attachments/20170614/9d59db74/attachment.htm>