[Openstack-operators] Updating oschecks
Mike Dorman
mdorman at godaddy.com
Thu Nov 3 22:00:31 UTC 2016
Absolutely agree. The osops repos started as (and frankly, still are) mostly dumping grounds for tools folks had built and were running locally. This was meant to be a first step at sharing and collaboration. The kind of improvements you’re talking about is exactly the direction we want to take this stuff.
Thanks!!
Mike
From: Melvin Hillsman <mrhillsman at gmail.com>
Organization: OpenStack Innovation Center
Reply-To: "mrhillsman at gmail.com" <mrhillsman at gmail.com>
Date: Thursday, November 3, 2016 at 12:48 PM
To: Lars Kellogg-Stedman <lars at redhat.com>, OpenStack Operators <openstack-operators at lists.openstack.org>
Subject: Re: [Openstack-operators] Updating oschecks
Hey Lars,
I think the needs you have are relevant to anyone who would use this tooling and think you should definitely move forward with implementing what you have prototyped. I personally believe any improvements to the tools in osops repos are welcome. Bringing modularity to this as well is great from my perspective.
On 11/03/2016 01:03 PM, Lars Kellogg-Stedman wrote:
I've recently started working with the oscheck scripts in the
osops-tools-monitoring project [1], and I found that in their current
form they didn't quite meet my needs. In particular:
- They don't share a common set of authentication options
- They can't read credentials from files
- Many of them require a priori configuration of the openstack
environment, which means they can't be used to health check a new
deployment
I've spent a little time recently prototyping a new set of health
check scripts, available here:
https://github.com/larsks/oschecks
I'd like to emphasize that these *are not* currently meant as a usable
replacement for the existing checks; they were to prototype (a) the
way I'd like the user interface to work and (b) the way I'd like
things like credentials to work.
This project offers the following features:
- They use os_client_config for managing credentials, so they can be
configured from a clouds.yaml file, or the environment, or the
command line, and it all Just Works.
- Authentication is handled in just one place in the code for all the
checks.
- The checks are extensible (using the cliff framework), which means
that checks with different sets of requirements can be
packaged/installed separately. See, for example:
https://github.com/larsks/oschecks_systemd
- For every supported service there is a simple "can I make an
authenticated request to the API successfully" check that does not
require any pre-existing resources to be created.
- They are (hopefully) structured such that it is relatively easy to
write new checks the follow the same syntax and behavior of the
other checks.
If people think this is a useful way of implementing these health
checks, I would be happy to do the work necessary to make them a mostly
drop-in replacement for the existing checks (adding checks that are
currently missing, and adding appropriate console-script entrypoints to
match the existing names, etc).
I would appreciate any feedback. Sorry for the long message, and thanks
for taking the time to read this far!
[1]: https://github.com/openstack/osops-tools-monitoring/tree/master/monitoring-for-openstack/oschecks
_______________________________________________
OpenStack-operators mailing list
OpenStack-operators at lists.openstack.org<mailto:OpenStack-operators at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
--
Kind regards,
--
Melvin Hillsman
Ops Technical Lead
OpenStack Innovation Center
mrhillsman at gmail.com<mailto:mrhillsman at gmail.com>
mobile: (210) 413-1659
office: (210) 312-1267
Learner | Ideation | Belief | Responsibility | Command
http://osic.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20161103/81d43686/attachment.html>
More information about the OpenStack-operators
mailing list