[Openstack-operators] Updating oschecks
Tobias Urdin
tobias.urdin at crystone.com
Fri Nov 4 09:04:58 UTC 2016
Hello Lars,
This is great, we have been using our own checks previously but having a
great and cleaned up option upstream is gold worth.
This was we can all collaborate on having this as a standard toolbox for
health checks.
Looking forward to see moving forward and would love to contribute, and
in the future roll this out across our companies.
Best regards
On 11/03/2016 07:06 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
>
More information about the OpenStack-operators
mailing list