<p dir="ltr">Hi John,</p>
<p dir="ltr">Thanks for the excellent summary! I found it very helpful to get caught up. I'd like to make sure I understand the direction ahc is going. A couple questions...</p>
<p dir="ltr">I see that ahc is storing its information in swift. That's clever, but if Ironic provided a blob store for each node, would that be better?</p>
<p dir="ltr">We discussed adding a search API to Ironic at the Vancouver summit, though no work has been done on that yet, afaik. If ahc is going to grow a REST API for searching for nodes based on specific criteria that it discovered, could/should we combine these within Ironic's API?</p>
<p dir="ltr">From a service coupling perspective, I like the approach that ahc is optional, and also that Ironic-inspector is optional, because this keeps the simple use-case for Ironic, well, simple! That said, this seems more like a configuration setting (should inspector do extra things?) than an entirely separate service, and separating them might be unnecessarily complicated.</p>
<p dir="ltr">It sounds like this is the direction you'd like to go, and you took the current approach for expediency. If so, I'd like us to discuss a path to merge the functionality as it matures, and decide whether a separate repository is the right way to go long term.<br></p>
<p dir="ltr">Thanks much,<br>
Devananda</p>
<br><div class="gmail_quote"><div dir="ltr">On Mon, Jun 22, 2015, 05:40 John Trowbridge <<a href="mailto:trown@redhat.com">trown@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">This is a proposal to add a new repository governed by the ironic<br>
inspector subteam. The current repository is named ahc-tools[1], however<br>
there is no attachment to this name. "ironic-inspector-extra" would seem<br>
to fit if this is moved under the Ironic umbrella.<br>
<br>
What is AHC?<br>
------------<br>
* AHC as a term comes from the enovance edeploy installation method[2].<br>
* The general concept is that we want to have a very granular picture of<br>
the physical hardware being used in a deployment in order to be able to<br>
match specific hardware to specific roles, as well as the ability to<br>
find poor performing outliers before we attempt to deploy.<br>
* For example: As a cloud operator, I want to make sure all logical<br>
disks have random read IOPs within 15% variance of each other.<br>
* The huge benefit of this tooling over current inspection is the number<br>
of facts collected (~1000 depending on the hardware), all of which can<br>
be used for matching.<br>
* Another example: As an end user, I would like to request a bare metal<br>
machine with a specific model GPU.<br>
<br>
What is ahc-tools?<br>
------------------<br>
* We first tried to place all of this logic into a plugin in<br>
inspector[3] (discoverd at the time). [4]<br>
* This worked fine for just collecting some of the simple facts, however<br>
we now had a coupling between booting a ramdisk, and matching against<br>
the collected data.<br>
* ahc-tools started as a way to uncouple these two steps[5].<br>
* We also added a wrapper around the enovance report tooling[6], as it<br>
already had the ability to generate reports based on the collected data,<br>
but was designed to read in the data from the filesystem.<br>
* The report tool has two functions.<br>
* First, it can group the systems by category (NICs, Firmware,<br>
Processors, etc.).<br>
* Second, it can use statistical analysis to find performance outliers.<br>
<br>
Why is ahc-tools useful to Ironic?<br>
----------------------------------<br>
* If we run benchmarks on hardware whenever it is turned back in by a<br>
tenant, we can easily put nodes into maintenance if the hardware is<br>
performing below some set threshold. This would allow us to have better<br>
certainty that the end user is getting what we promised them.<br>
* The advanced matching could also prove very useful. For VMs, I think<br>
the pets vs cattle analogy holds up very well, however many use cases<br>
for having cloud based bare metal involve access to specific hardware<br>
capabilities. I think advanced matching could help bridge this gap.<br>
<br>
Why not just put this code directly into inspector?<br>
---------------------------------------------------<br>
* Clearly this code is 100% dependent on inspector. However, inspector<br>
is quite stable, and works great without any of this extra tooling.<br>
* ahc-tools is very immature, and will need many breaking changes to get<br>
to the same stability level of inspector.<br>
<br>
Why aren't you following the downstream->stackforge->openstack path?<br>
--------------------------------------------------------------------<br>
* This was the initial plan[7], however we were told that under the new<br>
"big tent", that the openstack namespace is no longer meant to signify<br>
maturity of a project.<br>
* Instead, we were told we should propose the project directly to<br>
Ironic, or make a new separate project.<br>
<br>
What is the plan to make ahc-tools better?<br>
------------------------------------------<br>
* The first major overhaul we would like to do is to put the reporting<br>
and matching functionality behind a REST API.<br>
* Reporting in particular will require significant work, as the current<br>
wrapper script wraps code that was never designed to be a library (Its<br>
output is just a series of print statements). One option is to improve<br>
the library[8] to be more library like, and the other is to reimplement<br>
the logic itself. Personally, while reimplementing the library is a<br>
large amount of work, I think it is probably worth the effort.<br>
* We would also like to add an API endpoint to coordinate distributed<br>
checks. For instance, if we want to confirm that there is physical<br>
network connectivity between a set of nodes, or if we would like to<br>
confirm the bandwidth of those connections.<br>
* The distributed checks and REST API will hopefully be completed in the<br>
Liberty timeframe.<br>
* Overhaul of the reporting will likely be an M target, unless there is<br>
interest from new contributors in working on this feature.<br>
* We are planning a talk for Tokyo on inspector that will also include<br>
details about this project.<br>
<br>
Thank you very much for your consideration.<br>
<br>
Respectfully,<br>
John Trowbridge<br>
<br>
[1] <a href="https://github.com/rdo-management/ahc-tools" rel="noreferrer" target="_blank">https://github.com/rdo-management/ahc-tools</a><br>
[2] <a href="https://github.com/enovance/edeploy/blob/master/docs/AHC.rst" rel="noreferrer" target="_blank">https://github.com/enovance/edeploy/blob/master/docs/AHC.rst</a><br>
[3]<br>
<a href="https://github.com/openstack/ironic-inspector/commit/22a0e24efbef149377ea1e020f2d81968c10b58c" rel="noreferrer" target="_blank">https://github.com/openstack/ironic-inspector/commit/22a0e24efbef149377ea1e020f2d81968c10b58c</a><br>
[4] We can have out-of-tree plugins for the inspector, so some of this<br>
code might become a plugin again, but within the new repository tree.<br>
[5]<br>
<a href="https://github.com/openstack/ironic-inspector/commit/eaad7e09b99ab498e080e6e0ab71e69d00275422" rel="noreferrer" target="_blank">https://github.com/openstack/ironic-inspector/commit/eaad7e09b99ab498e080e6e0ab71e69d00275422</a><br>
[6]<br>
<a href="https://github.com/rdo-management/ahc-tools/blob/master/ahc_tools/report.py" rel="noreferrer" target="_blank">https://github.com/rdo-management/ahc-tools/blob/master/ahc_tools/report.py</a><br>
[7] <a href="https://review.openstack.org/#/c/193392/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/193392/</a><br>
[8] <a href="https://github.com/enovance/hardware" rel="noreferrer" target="_blank">https://github.com/enovance/hardware</a><br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div>