On Tue, Jul 15, 2014 at 5:00 AM, Henry Nash <[email protected]> wrote:
> Mark, > > Thanks for your comments (as well as remarks on the WIP code-review). > > So clearly gathering and analysing log files is an alternative approach, > perhaps not as immediate as an API call. In general, I believe that the > more capability we provide via easy-to-consume APIs (with appropriate > permissions) the more effective (and innovative) ways of management of > OpenStack we will achieve (easier to build automated management systems). > In terms of multi API servers, obviously each server would respond to the > API with the values it has set, so operators could check any or all of the > servers....and this actually becomes more important as people distribute > config files around to the various servers (since more chance of something > getting out of sync). > Where do you see configuration management tools like chef, puppet, and the os-*-config tools (http://git.openstack.org/cgit) fit in to this? > > Henry > On 15 Jul 2014, at 10:08, Mark McLoughlin <[email protected]> wrote: > > On Tue, 2014-07-15 at 08:54 +0100, Henry Nash wrote: > > HI > > As the number of configuration options increases and OpenStack > installations become more complex, the chances of incorrect > configuration increases. There is no better way of enabling cloud > providers to be able to check the configuration state of an OpenStack > service than providing a direct REST API that allows the current > running values to be inspected. Having an API to provide this > information becomes increasingly important for dev/ops style > operation. > > As part of Keystone we are considering adding such an ability (see: > https://review.openstack.org/#/c/106558/). However, since this is the > sort of thing that might be relevant to and/or affect other projects, > I wanted to get views from the wider dev audience. > > Any such change obviously has to take security in mind - and as the > spec says, just like when we log config options, any options marked as > secret will be obfuscated. In addition, the API will be protected by > the normal policy mechanism and is likely in most installations to be > left as "admin required". And of course, since it is an extension, if > a particular installation does not want to use it, they don't need to > load it. > > Do people think this is a good idea? Useful in other projects? > Concerned about the risks? > > > I would have thought operators would be comfortable gleaning this > information from the log files? > > Also, this is going to tell you how the API service you connected to was > configured. Where there are multiple API servers, what about the others? > How do operators verify all of the API servers behind a load balancer > with this? > > And in the case of something like Nova, what about the many other nodes > behind the API server? > > Mark. > > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
