Open Stack

On Tue, Oct 15, 2013 at 7:05 PM, Morgan Fainberg <m at metacloud.com> wrote:

> Hi Fellow Developers (and those who interface with keystone at the code
> level),
>
> I wanted to reach out to the ML and see what the opinions were about
> starting to stabilize the internal APIs (wherever possible) for the
> keystone project (I would also like to see similar work done in the other
> fully integrated projects, but I am starting with a smaller audience).
>
> I believe that (especially in the case of things like identity_api ->
> assignment_api) we should start supporting the concept of Release -1
> (current release, and previous release) of a given internal API.  While
> this isn't feasible everywhere, if we can't maintain at least an exception
> being raised that indicates what "should" be called would be ideal for the
> release the change occurred in.
>
> This will significantly help any developers who have custom code that
> relies on these APIs to find the locations of our new internal APIs.
>  Perhaps the "stub" function/method replacement that simply raises a "go
> used this new method/function" type exception would be sufficient and make
> porting code easier.
>
> This would require at the start of each release a "cleanup" patchset that
> removed the stub or old methods/functions that are now fully deprecated.
>
> So with that, lets talk about this more in depth see where it lands.  I
> want to weed out any potential pitfalls before a concept like this makes it
> anywhere beyond some neural misfires that came up in a passing discussion.
>  It may just not be feasible/worth the effort in the grand scheme of things.
>

Making updates easier would be nice, and the abstract base class work
should help with that. On the other hand, as a deployer who has had to
rewrite our custom integration a few times in the past 6 months or so, I
would also welcome some stability in the plugin APIs. I understand the need
to provide flexibility and updated features for new REST APIs, but I hope
we can find a way to migrate more smoothly or make newer features optional
in the plugins themselves.

DreamHost will have several developers at the summit; is there a session to
talk about approaches for this that we should make sure to attend?

Doug


>
> Cheers,
> Morgan Fainberg
>
> IRC: morganfainberg
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> 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/20131015/f9f2dfb2/attachment.html>