10:36 a.m.
The current AHC workflow[1] requires us to send the already introspected
nodes back to ironic-discoverd, if we change the matching rules after
the initial introspection step.
This is problematic, because if we want to match on the benchmark data,
the benchmarks will need to be re-run. Currently, the edeploy plugin[2]
to ironic-discoverd is doing the matching, and it only deals with data
posted by the discovery ramdisk. Running the benchmarks can be very time
consuming on a typical production server, and we already store the
results in the ironic db. The benchmarks should not vary much between
runs, so this time is wasted in future runs.
One solution would be to add a feature to the benchmark analysis tool,
ironic-cardiff,[3] to do the subsequent rounds of matching. This would
be straight forward as this tool already gets an ironic client, and
already requires the hardware library which has the matching logic.
I would like to gather feedback on whether this approach seems
reasonable, or if there are any better suggestions to solve this problem.
[1]
https://repos.fedorapeople.org/repos/openstack-m/instack-undercloud/html/...
[2]
https://github.com/stackforge/ironic-discoverd/blob/master/ironic_discove...
[3]
https://github.com/rdo-management/rdo-ramdisk-tools/blob/master/rdo_ramdi...
11:49 a.m.
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/
5:50 a.m.
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.
_______________________________________________
Rdo-list mailing list
Rdo-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/rdo-list
To unsubscribe: rdo-list-unsubscribe(a)redhat.com
6:43 a.m.
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.
7:22 a.m.
On 04/24/2015 01:43 PM, John Trowbridge wrote:
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?
We had a quick chat off-channel, and I kind of changed my mind. People
are not found of calling something "rdo-ramdisk-tools", but I realized
that nothing prevents me from putting the ramdisk script into
ironic-discoverd upstream repo.
This way ironic-discoverd will be more feature-complete: we already have
plugins there, but we don't have ramdisk implementation, only generic
one in the ramdisk. Once we start adopting IPA, this code may be of a
lot of help. Maybe we'll transform it into an IPA module.
So it's up to you now how to call/where to put AHC code :)
[1] I was thinking of using an `openstack health` namespace.
_______________________________________________
Rdo-list mailing list
Rdo-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/rdo-list
To unsubscribe: rdo-list-unsubscribe(a)redhat.com
3501
days inactive
3504
days old
4 comments
2 participants
participants (2)
-
Dmitry Tantsur -
John Trowbridge