Open Stack

On Tue, Jul 15, 2014 at 6:57 AM, Henry Nash <henryn at 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.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
>
>
>
> _______________________________________________
> 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/ce6fe226/attachment.html>