Open Stack

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140715/3ac7e594/attachment.html>