Joe, I'd imagine an API like this would be pretty useful for some of these config tools - so I'd imagine they might well be consumers of this API.
Henry On 15 Jul 2014, at 13:10, Joe Gordon <[email protected]> wrote: > > > > 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
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
