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 >
