I might be wrong, but I sense there is a requirement here, where Slider needs to accept custom application specific config files in it¹s original raw format (like properties, xml, json, yaml, etc.) in addition to appConfig.json. Then it is expected to merge them with appConfig.json and send the complete property bag down to the application containers.
If that is true, or even if I got it all wrong, it would be great if you can file JIRAs for what you are looking for? It is good to have these kind of gaps and ideas captured in JIRAs, so that we can make Slider better. Siyuan, The instance tag feature has been there since 0.60. Check https://issues.apache.org/jira/browse/SLIDER-463. -Gour On 5/11/15, 10:41 PM, "Thomas Weise" <thomas.we...@gmail.com> wrote: >Jean, > >We pulled in your changes and added modifications on top of it. It appears >we agree that we should not force the user to redefine the default values >that ship with server.properties. Please see whether the properties merge >as implemented works on your environment or not. If not, what is the >Python >version? > >We can find an alternative solution to in-place edit of server properties >if and when needed. The file is an argument to the start script, hence we >can do a copy before merge if necessary. > >Thomas > > >On Mon, May 11, 2015 at 3:26 PM, hsy...@gmail.com <hsy...@gmail.com> >wrote: > >> Hi Jean, >> >> Thanks for the change, using instance tag(is it a new feature in the >>latest >> version? I didn't see it in the older slider versions) is a really good >> idea. it might be good for other's to have a template but not for >>kafka. >> Kafka is evolving in quite fast pace. I've seen many property key/val >> change in last several releases. Our method is keep most properties >>default >> and only override the one declared in appConfig.json which is actually >> supported in current python script(maybe need some change for the latest >> slider). >> >> And Kafka broker is bundled with local disk once it's launched so in >>the >> real world there would be at most one instance for each NM. >> >> Best, >> Siyuan >> >> >> >> On Mon, May 11, 2015 at 10:16 AM, Jean-Baptiste Note <jbn...@gmail.com> >> wrote: >> >> > Hi Thomas, >> > >> > According to kafka's documentation: >> > http://kafka.apache.org/07/configuration.html there should be a >>default >> > value for any added property; I would expect the provided >> server.properties >> > file to actually reflect those default values. >> > Therefore, I'd look twice before overconstraining the problem, and >>would >> > just generate the file for those and only those dictionary values that >> have >> > been set in the appConfig (which currently, my code does not, it >> configures >> > too many properties statically, but it can be arranged), relying on >>the >> > default properties for the rest. >> > >> > If there's really a case to have all properties at hand, I could: >> > * parse the properties file provided in the tarball >> > * re-generate the whole conf file with the parsed + overrides >> > >> > This, in order to allow for *added* properties (which the current >> schemes, >> > either mine or yours, does not look to allow) AND ultimately, allow >>for >> the >> > whole tarball installation to be switched to read-only (which could >>allow >> > them to be shared among instances running on the same NM; I don't >>know if >> > slider currently does this kind of optimization). >> > >> > Maybe guidance from people more familiar with slider than us would be >> > needed here :) >> > >> > Kind regards, >> > JB >> > >>
