Open Stack

On 09/27/2017 09:31 AM, Julia Kreger wrote:
> [...]
>>> The short explanation which clicked for me (granted it's probably an
>>> oversimplification, but still) was this: Ironic provides an admin
>>> API for managing bare metal resources, while Mogan gives you a user
>>> API (suitable for public cloud use cases) to your Ironic backend. I
>>> suppose it could have been implemented in Ironic, but implementing
>>> it separately allows Ironic to be agnostic to multiple user
>>> frontends and also frees the Ironic team up from having to take on
>>> yet more work directly.
>>
>>
>> ditto!
>>
>> I had a similar question at the PTG and this was the answer that convinced
>> be
>> may be worth the effort.
>>
>> Flavio
>>
> 
> For Ironic, the question did come at the PTG up of tenant aware
> scheduling of owned hardware, as in Customer A and B are managed by
> the same ironic, only customer A's users should be able to schedule on
> to Customer A's hardware, with API access control restrictions such
> that specific customer can take action on their own hardware.
> 
> If we go down the path of supporting such views/logic, it could become
> a massive undertaking for Ironic, so there is absolutely a plus to
> something doing much of that for Ironic. Personally, I think Mogan is
> a good direction to continue to explore. That being said, we should
> improve our communication of plans/directions/perceptions between the
> teams so we don't adversely impact each other and see where we can
> help each other moving forward.

My biggest concern with Mogan is that it forks Nova, then starts
changing interfaces. Nova's got 2 really big API surfaces.

1) The user facing API, which is reasonably well documented, and under
tight control. Mogan has taken key things at 95% similarity and changed
bits. So servers includes things like a partitions parameter.
https://github.com/openstack/mogan/blob/master/api-ref/source/v1/servers.inc#request-4

This being nearly the same but slightly different ends up being really
weird. Especially as Nova evolves it's code with microversions for
things like embedded flavor info.

2) The guest facing API of metadata/config drive. This is far less
documented or tested, and while we try to be strict about adding in
information here in a versioned way, it's never seen the same attention
as the user API on either documentation or version rigor.

That's presumably getting changed, going to drift as well, which means
discovering multiple implementations that are nearly, but not exactly
the same that drift.


The point of licensing things under and Apache 2 license was to enable
folks to do all kind of experiments like this. And experiments are good.
But part of the point of experiments is to learn lessons to bring back
into the fold. Digging out of the multi year hole of "close but not
exactly the same" API differences between nova-net and neutron really
makes me want to make sure we never intentionally inflict that confusion
on folks again.

	-Sean

-- 
Sean Dague
http://dague.net