On 04/24/2015 06:50 AM, Dmitry Tantsur wrote:
On 04/22/2015 06:49 PM, John Trowbridge wrote:
> On 04/21/2015 11:36 AM, John Trowbridge wrote:
>>
>> I would like to gather feedback on whether this approach seems
>> reasonable, or if there are any better suggestions to solve this
>> problem.
>>
> I put up a POC patch for this here:
>
https://review.gerrithub.io/#/c/230849/
As we discusses already, I'm somewhat worried that we put too much
non-ramdisk code into something called rdo-ramdisk-tools :D Probably
it's my fault: I didn't realize what you're planning to do. If we keep
it that way, we might want to rename the package. Or even more both
things to some existing common package - not sure.
I think that benchmark analysis and matching could stand alone as a
package. I would like to include an openstack client plugin,[1] and it
would also make sense for the distributed benchmark tools to be in this
package when we get to that point.
The only place I could see this fitting currently is in the
enovance/hardware library, as it is doing all of the heavy lifting in
the current implementation. However, I would eventually like to decouple
this operator tooling from the backend logic. I think this would be a
cool idea to present to Ironic, and I see having a hard dependence on
the hardware library as a deal breaker for that.
That said, the python ramdisk work that you are working on is really
about benchmark collection. So it would make sense to include in the
same package as the other operator tooling focused on benchmarks.
What are your thoughts wrt just changing the package name?
[1] I was thinking of using an `openstack health` namespace.