<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jun 14, 2017 at 10:16 AM, Lohmann Carsten (INST/ECS4) <span dir="ltr"><<a href="mailto:Carsten.Lohmann@bosch-si.com" target="_blank">Carsten.Lohmann@bosch-si.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">





<div lang="EN-US">
<div class="gmail-m_1163987406778737916WordSection1">
<p class="MsoNormal"><span style="font-size:10pt;font-family:Arial,sans-serif">Hi,<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:10pt;font-family:Arial,sans-serif"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:10pt;font-family:Arial,sans-serif">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).<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:10pt;font-family:Arial,sans-serif"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:10pt;font-family:Arial,sans-serif">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
<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:10pt;font-family:Arial,sans-serif">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.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:10pt;font-family:Arial,sans-serif"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:10pt;font-family:Arial,sans-serif">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.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:10pt;font-family:Arial,sans-serif">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?<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:10pt;font-family:Arial,sans-serif"><u></u> </span></p></div></div></blockquote><div><br></div><div>Hi Carsten,</div><div><br></div><div>Out of curiosity, what is it that you wish to modify in this config? </div><div><br></div><div>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.</div><div><br></div><div>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?</div><div><br></div><div>-- </div><div>Ulf</div><div><br></div><div><br></div></div><br></div></div>