Open Stack

Akihiro,

If we go with the empty extension you proposed in the patch will that be
acceptable?

We've got to stop killing new functionality on the very last day like this
. It just kills progress.  This proposal isn't new.

Carl
On Mar 30, 2015 11:37 AM, "Akihiro Motoki" <amotoki at gmail.com> wrote:

> Hi Neutron folks
> (API folks may be interested on this)
>
> We have another discussion on Core vs extension in the subnet pool
> feature reivew
> https://review.openstack.org/#/c/157597/.
> We did the similar discussion on VLAN transparency and MTU for a
> network model last week.
> I would like to share my concerns on changing the core API directly.
> I hope this help us make the discussion productive.
> Note that I don't want to discuss the micro-versioning because it
> mainly focues on Kilo FFE BP.
>
> I would like to discuss this topic in today's neutron meeting,
> but I am not so confident I can get up in time, I would like to send this
> mail.
>
>
> The extension mechanism in Neutron provides two points for extensibility:
> - (a) visibility of features in API (users can know which features are
> available through the API)
> - (b) opt-in mechanism in plugins (plugin maintainers can decide to
> support some feature after checking the detail)
>
> My concerns mainly comes from the first point (a).
> If we have no way to detect it, users (including Horizon) need to do a
> dirty work around
> to determine whether some feature is available. I believe this is one
> important point in API.
>
> On the second point, my only concern (not so important) is that we are
> making the core
> API change at this moment of the release. Some plugins do not consume
> db_base_plugin and
> such plugins need to investigate the impact from now on.
> On the other hand, if we use the extension mechanism all plugins need to
> update
> their extension list in the last moment :-(
>
>
> My vote at this moment is still to use an extension, but an extension
> layer can be a shim.
> The idea is to that all implementation can be as-is and we just add an
> extension module
> so that the new feature is visible thru the extension list.
> It is not perfect but I think it is a good compromise regarding the first
> point.
>
>
> I know there was a suggestion to change this into the core API in the
> spec review
> and I didn't notice it at that time, but I would like to raise this
> before releasing it.
>
> For longer term (and Liberty cycle),  we need to define more clear
> guideline
> on "Core vs extension vs micro-versioning" in spec reviews.
>
> Thanks,
> Akihiro
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150330/ccdadff6/attachment.html>