One more try on the ops list as it turns out I wasn't subscribed... :(
// jim
> On Oct 14, 2015, at 17:39, Jim Rollenhagen wrote:
>
> Cross posting to the ops list for visibility.
>
> To follow up on this, we decided not to fix this after all. Besides
> Ramesh's (very valid) points below, we
Cross posting to the ops list for visibility.
To follow up on this, we decided not to fix this after all. Besides
Ramesh's (very valid) points below, we realized that fixing this for out
of tree drivers that depended on Kilo behavior would break out of tree
drivers that implemented their own boot
On Wed, Oct 07, 2015 at 12:41:55PM -0700, Devananda van der Veen wrote:
> Ramesh,
>
> I thought about your points over night, and then looked at our in-tree
> driver code from stable/kilo and asked myself, "what if this driver was out
> of tree?" They'd all have broken -- for very similar reasons
Ramesh,
I thought about your points over night, and then looked at our in-tree
driver code from stable/kilo and asked myself, "what if this driver was out
of tree?" They'd all have broken -- for very similar reasons as what I
encountered with my demo driver.
When we split the boot and deploy inte
Well it's nice to fix, but I really don't know if we should be fixing it.
As discussed in one of the Ironic meetings before, we might need to define
what is our driver API or SDK or DDK or whatever we choose to call it .
Please see inline for my thoughts.
On Tue, Oct 6, 2015 at 5:54 AM, Devananda
tldr; the boot / deploy interface split we did broke an out of tree driver.
I've proposed a patch. We should get a fix into stable/liberty too.
Longer version...
I was rebasing my AMTTool driver [0] on top of master because the in-tree
one still does not work for me, only to discover that my driv
