Open Stack

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 <joe.gordon0 at gmail.com> wrote:

> 
> 
> 
> On Tue, Jul 15, 2014 at 5:00 AM, Henry Nash <henryn at 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 <markmc at 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 at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140715/7f070583/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140715/7f070583/attachment.pgp>