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. > > 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 <ayo...@redhat.com> <ayo...@redhat.com> > To: Dolph Mathews <dolph.math...@gmail.com> <dolph.math...@gmail.com>, > "Yee, Guang" <guang....@hp.com> <guang....@hp.com>, Henry Nash > <hen...@linux.vnet.ibm.com> <hen...@linux.vnet.ibm.com>, Morgan Fainberg > <m...@metacloud.com> <m...@metacloud.com>, Brant L > Knudson/Rochester/IBM@IBMUS, > Morgan Fainberg <m...@metacloud.com> <m...@metacloud.com>, > Cc: Jamie Lennox <jamielen...@gmail.com> <jamielen...@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 <abog...@wikimedia.org> <abog...@wikimedia.org> > Author: Ann Kamyshnikova > <akamyshnik...@mirantis.com><akamyshnik...@mirantis.com> > Author: Chuck Short <chuck.sh...@canonical.com><chuck.sh...@canonical.com> > Author: Dina Belova <dbel...@mirantis.com> <dbel...@mirantis.com> > Author: Eric Windisch <e...@cloudscaling.com> <e...@cloudscaling.com> > Author: Flaper Fesp <flape...@gmail.com> <flape...@gmail.com> > Author: guohliu <guoh...@cn.ibm.com> <guoh...@cn.ibm.com> > Author: Jenkins <jenk...@review.openstack.org><jenk...@review.openstack.org> > Author: Kevin L. Mitchell > <kevin.mitch...@rackspace.com><kevin.mitch...@rackspace.com> > Author: Mark McClain <mark.mccl...@dreamhost.com><mark.mccl...@dreamhost.com> > Author: Mark McLoughlin <mar...@redhat.com> <mar...@redhat.com> > Author: Monty Taylor <mord...@inaugust.com> <mord...@inaugust.com> > Author: Sergey Lukjanov <slukja...@mirantis.com> <slukja...@mirantis.com> > Author: Victor Sergeyev <vserge...@mirantis.com> <vserge...@mirantis.com> > Author: Vishvananda Ishaya <vishvana...@gmail.com> <vishvana...@gmail.com> > Author: Zhongyue Luo <zhongyue....@intel.com> <zhongyue....@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
<<image/gif>>
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
