<div dir="ltr">Thanks Sean for raising the concerns. We don't really fork nova but some parts of the "ABI" of it. For the 2 API surfaces, we have different strategies, please see explanations below:<br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Sep 27, 2017 at 10:34 PM, Sean Dague <span dir="ltr"><<a href="mailto:sean@dague.net" target="_blank">sean@dague.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid"><div class="gmail-HOEnZb"><div class="gmail-h5">On 09/27/2017 09:31 AM, Julia Kreger wrote:<br>
> [...]<br>
>>> The short explanation which clicked for me (granted it's probably an<br>
>>> oversimplification, but still) was this: Ironic provides an admin<br>
>>> API for managing bare metal resources, while Mogan gives you a user<br>
>>> API (suitable for public cloud use cases) to your Ironic backend. I<br>
>>> suppose it could have been implemented in Ironic, but implementing<br>
>>> it separately allows Ironic to be agnostic to multiple user<br>
>>> frontends and also frees the Ironic team up from having to take on<br>
>>> yet more work directly.<br>
>><br>
>><br>
>> ditto!<br>
>><br>
>> I had a similar question at the PTG and this was the answer that convinced<br>
>> be<br>
>> may be worth the effort.<br>
>><br>
>> Flavio<br>
>><br>
><br>
> For Ironic, the question did come at the PTG up of tenant aware<br>
> scheduling of owned hardware, as in Customer A and B are managed by<br>
> the same ironic, only customer A's users should be able to schedule on<br>
> to Customer A's hardware, with API access control restrictions such<br>
> that specific customer can take action on their own hardware.<br>
><br>
> If we go down the path of supporting such views/logic, it could become<br>
> a massive undertaking for Ironic, so there is absolutely a plus to<br>
> something doing much of that for Ironic. Personally, I think Mogan is<br>
> a good direction to continue to explore. That being said, we should<br>
> improve our communication of plans/directions/perceptions between the<br>
> teams so we don't adversely impact each other and see where we can<br>
> help each other moving forward.<br>
<br>
</div></div>My biggest concern with Mogan is that it forks Nova, then starts<br>
changing interfaces. Nova's got 2 really big API surfaces.<br>
<br>
1) The user facing API, which is reasonably well documented, and under<br>
tight control. Mogan has taken key things at 95% similarity and changed<br>
bits. So servers includes things like a partitions parameter.<br>
<a href="https://github.com/openstack/mogan/blob/master/api-ref/source/v1/servers.inc#request-4" target="_blank" rel="noreferrer">https://github.com/openstack/<wbr>mogan/blob/master/api-ref/<wbr>source/v1/servers.inc#request-<wbr>4</a><br>
<br>
This being nearly the same but slightly different ends up being really<br>
weird. Especially as Nova evolves it's code with microversions for<br>
things like embedded flavor info.<br>
<br></blockquote><div><br></div><div>For user facing API, We defined a new set of API instead of following Nova, which is more specific for bare metals. The similarity of key things is because virtual machines and bare metals key attributes are similar naturally. Mogan is relatively new project, with more features introduced, things will become different in future.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid">
2) The guest facing API of metadata/config drive. This is far less<br>
documented or tested, and while we try to be strict about adding in<br>
information here in a versioned way, it's never seen the same attention<br>
as the user API on either documentation or version rigor.<br>
<br>
That's presumably getting changed, going to drift as well, which means<br>
discovering multiple implementations that are nearly, but not exactly<br>
the same that drift.<br>
<br></blockquote><div><br></div><div>About guest facing API, we only support config drive now, which is copied from Nova but we don't want to diverge from it. Regarding this part, we will try to sync with nova periodically or maybe refactoring these files to be a shared library is the best way, we will try to figure out.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid">
<br>
The point of licensing things under and Apache 2 license was to enable<br>
folks to do all kind of experiments like this. And experiments are good.<br>
But part of the point of experiments is to learn lessons to bring back<br>
into the fold. Digging out of the multi year hole of "close but not<br>
exactly the same" API differences between nova-net and neutron really<br>
makes me want to make sure we never intentionally inflict that confusion<br>
on folks again.<br>
<span class="gmail-HOEnZb"><font color="#888888"><br>
        -Sean<br>
<br>
--<br>
Sean Dague<br>
<a href="http://dague.net" target="_blank" rel="noreferrer">http://dague.net</a><br>
</font></span><div class="gmail-HOEnZb"><div class="gmail-h5"><br>
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank" rel="noreferrer">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank" rel="noreferrer">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature"><div dir="ltr"><div>Best Regards,<br></div>Zhenguo Niu<br></div></div>
</div></div>