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 >
