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 <mrhills...@gmail.com> Organization: OpenStack Innovation Center Reply-To: "mrhills...@gmail.com" <mrhills...@gmail.com> Date: Thursday, November 3, 2016 at 12:48 PM To: Lars Kellogg-Stedman <l...@redhat.com>, OpenStack Operators <openstack-operators@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@lists.openstack.org<mailto:OpenStack-operators@lists.openstack.org> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators -- Kind regards, -- Melvin Hillsman Ops Technical Lead OpenStack Innovation Center mrhills...@gmail.com<mailto:mrhills...@gmail.com> mobile: (210) 413-1659 office: (210) 312-1267 Learner | Ideation | Belief | Responsibility | Command http://osic.org
_______________________________________________ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
