Re: [openstack-dev] [Keystone] stabilizing internal APIs
On Tue, Oct 15, 2013 at 6:05 PM, Morgan Fainberg m...@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. With a more stringent end goal in mind (release - 1), I think functional documentation would be a great step in the right direction, and an easy ask for developers reviewers. The two most important capabilities are to provide warnings for when something may be completely removed (release +1 or +2) and to point to the new method/function (where possible). The immediate use case for this patch is to deprecate v2.0 controllers, but there's no reason why it couldn't be adapted to driver interfaces, etc: https://review.openstack.org/#/c/50486/ 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. Cheers, Morgan Fainberg IRC: morganfainberg ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- -Dolph ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Keystone] stabilizing internal APIs
On Tue, Oct 15, 2013 at 7:05 PM, Morgan Fainberg m...@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@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Keystone] stabilizing internal APIs
On Tue, Oct 15, 2013 at 5:05 PM, Doug Hellmann doug.hellm...@dreamhost.comwrote: 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. Agreed, the ABC changes that are slowing making their way in will most assuredly help some. 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? I do not believe there is currently a session slated for anything like this. You could propose a session for this (or I could); obviously we would need enough interest to make it worth committing a whole session to. Maybe piggy-back this one onto another session already proposed? Maybe this should be a broader-than-keystone-only topic? --Morgan ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Keystone] stabilizing internal APIs
I think everyone will have opinions :). I suggest proving it in keystone and then bringing in a larger audience; we've had discussions about graceful evolution for some time now but little concrete action - I think because we're too ambitious, and the costs that result are perceived to be too high. +1 for doing it! -Rob On 16 October 2013 14:00, Morgan Fainberg m...@metacloud.com wrote: On Tue, Oct 15, 2013 at 5:05 PM, Doug Hellmann doug.hellm...@dreamhost.com wrote: 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. Agreed, the ABC changes that are slowing making their way in will most assuredly help some. 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? I do not believe there is currently a session slated for anything like this. You could propose a session for this (or I could); obviously we would need enough interest to make it worth committing a whole session to. Maybe piggy-back this one onto another session already proposed? Maybe this should be a broader-than-keystone-only topic? --Morgan ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Converged Cloud ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
