> On 5 Aug 2015, at 10:53, Paul Han <[email protected]> wrote: > > Hi, Slider Team > > We are using Slider to deploy our multi-tenanted services to Yarn. For each > tenant, I add a new component to Slider cluster. The services are identical > except for the tenant it serve for, which is passed to the component as a > string parameter. > > the appConfig file looks like something below: > { > "global": { > "tenantName": "TO_BE_OVER_WRITTEN_BY_COMPONENT", > }, > "components": { > "comp_a": { > "tenantName": "tenant_a", > }, > "comp_b": { > "tenantName": "tenant_b", > } > } > } > > metainfo.xml > ... > <components> > > <component> > <name>comp_a</name> > <category>MASTER</category> > <compExports>Servers-host_port</compExports> > <commandScript> > <script>scripts/foo-service.py</script> > <scriptType>PYTHON</scriptType> > </commandScript> > </component> > > <component> > <name>comp_b</name> > <category>MASTER</category> > <compExports>Servers-host_port</compExports> > <commandScript> > <script>scripts/foo-service.py</script> > <scriptType>PYTHON</scriptType> > </commandScript> > </component> > > </components> > ... > > I have two questions: > 1. Is this the best I can do? > you can see that to deploy identical services(binary, command scripts are > all same) for multiple tenants, I need to modify metainfo.xml and > appConfig.json to have dup entries with just a param difference. Slider > cluster has to be destroy and recreated. >
right now, yes. > 2. Once this is working, to add a new tenant to the cluster, I have to > modify the those files again and restart Slider cluster. The persistent > state such as app cache for services of existing tenants will be lost and > rebuilt again. That's very expensive operation for us. Is it possible to > add a component dynamically? Saw similar email threads about "Slider flex", > it doesn't do this, right? > We've done a lot of work in 0.80 for live updates of a cluster, in which each container is updated as we go along...this implicitly handles some changes in the files, including the package with the metadata At the same time, I think we left out reload of the entire application configs during flex simply to avoid confusion about what got updates -and what didn't. There's no fundamental reason, however, for flex not to do a reread of the appconf json. Gour -what do you think? How will rolling upgrades react to this? -steve
