[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