Open Stack

(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 <ayoung at 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 <flavio at 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 at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev