<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Oct 15, 2013 at 7:05 PM, Morgan Fainberg <span dir="ltr"><<a href="mailto:m@metacloud.com" target="_blank">m@metacloud.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi Fellow Developers (and those who interface with keystone at the code level),<div><br></div><div>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).</div>



<div><br></div><div>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.</div>



<div><br></div><div>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.</div>



<div><br></div><div>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.</div><div><br></div><div>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.</div>
</div></blockquote><div><br></div><div>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.</div>
<div><br></div><div>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?</div><div><br></div><div>Doug</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">


<div><br></div><div>Cheers,</div><div>Morgan Fainberg</div><div><br></div><div>IRC: morganfainberg</div></div>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div></div>