On Tue, Jul 15, 2014 at 6:57 AM, Henry Nash <hen...@linux.vnet.ibm.com> wrote:
> 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. > This may solve the OpenStack case, but something like this wouldn't solve the general issue of configuration management (config options for mysql, rabbit, apache, load balancers etc.) > > Henry > > On 15 Jul 2014, at 13:10, Joe Gordon <joe.gord...@gmail.com> wrote: > > > > > On Tue, Jul 15, 2014 at 5:00 AM, Henry Nash <hen...@linux.vnet.ibm.com> > 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 <mar...@redhat.com> 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 >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> >> >> _______________________________________________ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
