(Resend this as i realize it didn't get to the list)
I just want to clarify where some of this discussion came from. I actually think that oslo does a great job at keeping so many project up to date with common code without the restrictions that going to a library straight away. The problem is I don't think it will work for code that should exist client side. The most obvious example we have of this is the currently in oslo apiclient/exceptions.py. This is a really good set of exceptions however if novaclient imports exceptions to novaclient.openstack.common.apiclient.exceptions and keystoneclient does it to keystoneclient.openstack.common.apiclient.exceptions then there are NOT the same objects. It will be a fairly common situation where someone is using a number of clients together and so this is a bad situation. So for client side code we may not be able to go through the standard oslo process to achieve a common base library. This brought up the issue of auth_token and whether it should eventually live in keystoneclient. The problem with having it live in keystoneclient is that if there is a CVE in auth_token, or for example we wish to push the recent changes to allow CA validation on HTTPS connections in auth_token - the only way to do this is to push the most cutting edge version of keystoneclient into the global requirements.txt and pushed throughout OpenStack. Now I'm still confident that this wouldn't cause any API issues regarding the use of keystoneclient however the vast majority of keystoneclient does not need to be on this schedule and i'm sure it would be a problem for packagers. Policy is not my main focus here - though i agree it should be more related to keystone, but we should be able to affect these changes in OSLO. The thought was if we were to spin auth_token out of keystoneclient into a new package (and i haven't really heard a name for it i like yet - i'll call it python-openstackauth) then this package would make a good resting place for oslo policy. This would also become a good place for the auth_plugins that are currently in nova and we are trying to push through to other clients. So splitting two libraries out of OSLO/keystoneclient, baseclient and openstackauth, openstackauth would depend on baseclient, keystoneclient would depend on baseclient, openstackauth may require a dependency on keystoneclient for populating auth_token fields. Jamie On Thu, 2013-09-19 at 13:30 -0700, Mark McLoughlin wrote: > On Thu, 2013-09-19 at 15:22 -0500, Dolph Mathews wrote: > > > > On Thu, Sep 19, 2013 at 2:59 PM, Adam Young <ayo...@redhat.com> wrote: > > I can submit a summit proposal. I was thinking of making it > > more general than just the Policy piece. Here is my proposed > > session. Let me know if it rings true: > > > > > > Title: Extracting Shared Libraries from incubator > > > > Some of the security-sensitive code in OpenStack is coped into > > various projects from Oslo-Incubator. If there is a CVE > > identified in one of these pieces, there is no rapid way to > > update them short of syncing code to all projects. This > > meeting is to identify the pieces of Oslo-incubator that > > should be extracted into stand alone libraries. > > > > > > > > I believe the goal of oslo-incubator IS to spin out common code into > > standalone libraries in the long run, as appropriate. > > Indeed. > > https://wiki.openstack.org/wiki/Oslo > > Mission Statement: > > To produce a set of python libraries containing code shared by > OpenStack projects > > https://wiki.openstack.org/wiki/Oslo#Incubation > > Incubation shouldn't be seen as a long term option for any API - it > is merely a stepping stone to inclusion into a published Oslo > library. > > > Some of the code would be best reviewed by members of other > > projects: Network specific code by Neutron, Policy by > > Keystone, and so forth. As part of the discussion, we will > > identify a code review process that gets the right reviewers > > for those subprojects. > > > > > > It sounds like the real goal is "how do we get relevant/interested > > reviewers in front of oslo reviews without overloading them with > > noise?" I'm sure that's a topic that Mark already has an opinion on, > > so I've opened this thread this to openstack-dev. > > To take the specific example of the policy API, if someone actively > wanted to help the process of moving it into a standalone library should > volunteer to help Flavio out as a maintainer: > > https://git.openstack.org/cgit/openstack/oslo-incubator/tree/MAINTAINERS > > == policy == > > M: Flavio Percoco <fla...@redhat.com> > S: Maintained > F: policy.py > > > Another aspect is how someone would go about helping do reviews on a > specific API in oslo-incubator. That's a common need - e.g. for > maintainers of virt drivers in Nova - and AIUI, these folks just > subscribe to all gerrit notifications for the module and then use mail > filters to make sure they see changes to the files they're interested > in. > > Thanks, > Mark. > > > > _______________________________________________ > 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
