[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