That's right, we needed that during installation so the ES properties could be provided/replaced by Ambari. I was also thinking through the implications of splitting out that type of configuration from the rest of the global config. I hate to add yet another configuration file to the mix. But maybe we can let Ambari lay those options down separately if we want it to manage the ES endpoint data.
On Wed, May 3, 2017 at 5:28 PM, David Lyle <[email protected]> wrote: > Ambari has to manage the global configuration at least once or we cannot > deploy. IIRC, last time this came up, we decided to expose it via Ambari > but see if we could turn off the restart. I think we could expose it via an > action. > > I'm pretty happy with any solution that takes that initial deployment into > account. > > Maybe we could figure out a different configuration mix to support a > cleaner separation. > > -D... > On Wed, May 3, 2017 at 16:50 Michael Miklavcic < > [email protected]> > wrote: > > > I think this has been touched on before, but I've been doing some testing > > with the MPack and new REST API and Management UI and there are some > things > > I think we can make better. One of those items is the way we manage the > > global config. > > > > I think it would be beneficial to manage the global config through the > > management UI rather than through Ambari for the following reasons: > > 1. The user has to head to a different UI to configure an option for > their > > topologies > > 2. The user has to view and/or have permissions to use a different UI to > > view the global options that impact their parser topologies. > > 3. In order to deploy the new config, Ambari requires you to restart > > services. This negates one of our major features and benefits through > using > > Zookeeper under the hood for configs, which is not requiring topology > > restarts. > > > > Thoughts? > > > > Best, > > Mike > > >
