[Openstack-operators] Updating oschecks
Melvin Hillsman
mrhillsman at gmail.com
Thu Nov 3 18:48:38 UTC 2016
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
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
--
Kind regards,
--
Melvin Hillsman
Ops Technical Lead
OpenStack Innovation Center
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/4ff318ee/attachment.html>
More information about the OpenStack-operators
mailing list