Open Stack

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.


>
> 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.


>
>
> On 09/19/2013 12:22 PM, Brant L Knudson wrote:
>
> What's different between policy and anything else in oslo-incubator? "If
> a CVS is found in the oslo-incubator code base, we have no clean way of
> deploying a fix."
>
> I'm concerned about anything in oslo-incubator that we wind up pulling
> into Keystone, which is quite a bit of code. I tried adding oslo-incubator
> to my gerrit watch list but then my list got too long, and I spend enough
> time just doing Keystone reviews.
>
> The oslo-incubator projects do have maintainers:
> https://github.com/openstack/oslo-incubator/blob/master/MAINTAINERS
>
> Maybe we could have an extra field in MAINTAINERS with other groups to
> require review of (like keystone-core for policy). Or change the maintainer
> for policy to keystone-core.
>
> Brant Knudson, OpenStack Development - Keystone core member
> Phone:   507-253-8621 T/L:553-8621
>
>
> [image: Inactive hide details for Adam Young ---09/19/2013 10:33:47
> AM---Policy is part of Oslo. But it is a copied into the various p]Adam
> Young ---09/19/2013 10:33:47 AM---Policy is part of Oslo.  But it is a
> copied into the various projects.   If a CVS is found in the po
>
> From: Adam Young <ayoung at redhat.com> <ayoung at redhat.com>
> To: Dolph Mathews <dolph.mathews at gmail.com> <dolph.mathews at gmail.com>,
> "Yee, Guang" <guang.yee at hp.com> <guang.yee at hp.com>, Henry Nash
> <henryn at linux.vnet.ibm.com> <henryn at linux.vnet.ibm.com>, Morgan Fainberg
> <m at metacloud.com> <m at metacloud.com>, Brant L Knudson/Rochester/IBM at IBMUS,
> Morgan Fainberg <m at metacloud.com> <m at metacloud.com>,
> Cc: Jamie Lennox <jamielennox at gmail.com> <jamielennox at gmail.com>
> Date: 09/19/2013 10:33 AM
> Subject: Client and Policy
>  ------------------------------
>
>
>
> Policy is part of Oslo.  But it is a copied into the various projects.
> If a CVS is found in the policy code base, we have no clean way of
> deploying a fix.
>
> There are a couple of alternatives:
>
> 1.  Spin if off into a separate gitrepo and build it as a standalone
> package:  python-oslopolicy  or something.
> 2.  Merge it in with an existing project.  The obvious one would be
> python-keystoneclient.
>
> While the second is the obvious solution, the problem is that is crosses
> project team boundaries.  Policy was originally part of Keystone, but
> was deemd a common component and moved to Oslo.
>
> Both teams have a claim to gatekeeping this code.  Fortunately, it does
> not have to be either/or.
>
> Potential solution #1:  suggest that the policy code move to the
> keystone client, and invite a subset of the Oslo core devs over to
> Keystone as core devs.
>
> The  people that have commits to policy.py in Oslo are:
>
> Author: Andrew Bogott <abogott at wikimedia.org> <abogott at wikimedia.org>
> Author: Ann Kamyshnikova <akamyshnikova at mirantis.com><akamyshnikova at mirantis.com>
> Author: Chuck Short <chuck.short at canonical.com><chuck.short at canonical.com>
> Author: Dina Belova <dbelova at mirantis.com> <dbelova at mirantis.com>
> Author: Eric Windisch <eric at cloudscaling.com> <eric at cloudscaling.com>
> Author: Flaper Fesp <flaper87 at gmail.com> <flaper87 at gmail.com>
> Author: guohliu <guohliu at cn.ibm.com> <guohliu at cn.ibm.com>
> Author: Jenkins <jenkins at review.openstack.org><jenkins at review.openstack.org>
> Author: Kevin L. Mitchell <kevin.mitchell at rackspace.com><kevin.mitchell at rackspace.com>
> Author: Mark McClain <mark.mcclain at dreamhost.com><mark.mcclain at dreamhost.com>
> Author: Mark McLoughlin <markmc at redhat.com> <markmc at redhat.com>
> Author: Monty Taylor <mordred at inaugust.com> <mordred at inaugust.com>
> Author: Sergey Lukjanov <slukjanov at mirantis.com> <slukjanov at mirantis.com>
> Author: Victor Sergeyev <vsergeyev at mirantis.com> <vsergeyev at mirantis.com>
> Author: Vishvananda Ishaya <vishvananda at gmail.com> <vishvananda at gmail.com>
> Author: Zhongyue Luo <zhongyue.nah at intel.com> <zhongyue.nah at intel.com>
>
> Of these, Mark McLoughlin (Oslo PTL) and Andrew Bogott, are active core
> developers.
>
> https://launchpad.net/~oslo-core/+members#active<https://launchpad.net/%7Eoslo-core/+members#active>
>
>
>
> Potential solution#2 is that policy stays in oslo and becomes a stand .
> If this is the case, then none of the Keystone devs have a say over what
> goes in there.  Since POlicy and identity go hand and hand, I think it
> would be better if Keystone devs were more involved than that.  We could
> suggest that a handful of Keystone devs were tapped to be on Oslo core
> with an agreement that they focus on the pieces for policy, crypto and
> other security vital pieces.
>
> Potential Solution #3  we create an openstack-policy team that has the
> core devs from both Keystone and Oslo in it.  The git repo would be
> python-openstackpolicy.
>
> From a deployment standpoint, moving policy into keystoneclient is the
> simplest:  all of the projects currently import Keystone client into
> their servers to get the auth_token middleware.  Once we did a sync of
> the current code from oslo, it would be a matter of updating the package
> paths for those servers.
>
> Wanted to float this past the Keystone core devs before opening it up to
> a larger audience.  I've included Jamie, as this grew out of a
> conversation I had with him.  We can obivously discuss this at the
> Summit, but wanted to get our team's take on it.
>
>
>
>
>
>
>


-- 

-Dolph
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130919/d5ad1144/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130919/d5ad1144/attachment.gif>