On Thu, Sep 19, 2013 at 2:59 PM, Adam Young <[email protected]> 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 <[email protected]> <[email protected]> > To: Dolph Mathews <[email protected]> <[email protected]>, > "Yee, Guang" <[email protected]> <[email protected]>, Henry Nash > <[email protected]> <[email protected]>, Morgan Fainberg > <[email protected]> <[email protected]>, Brant L > Knudson/Rochester/IBM@IBMUS, > Morgan Fainberg <[email protected]> <[email protected]>, > Cc: Jamie Lennox <[email protected]> <[email protected]> > 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 <[email protected]> <[email protected]> > Author: Ann Kamyshnikova > <[email protected]><[email protected]> > Author: Chuck Short <[email protected]><[email protected]> > Author: Dina Belova <[email protected]> <[email protected]> > Author: Eric Windisch <[email protected]> <[email protected]> > Author: Flaper Fesp <[email protected]> <[email protected]> > Author: guohliu <[email protected]> <[email protected]> > Author: Jenkins <[email protected]><[email protected]> > Author: Kevin L. Mitchell > <[email protected]><[email protected]> > Author: Mark McClain <[email protected]><[email protected]> > Author: Mark McLoughlin <[email protected]> <[email protected]> > Author: Monty Taylor <[email protected]> <[email protected]> > Author: Sergey Lukjanov <[email protected]> <[email protected]> > Author: Victor Sergeyev <[email protected]> <[email protected]> > Author: Vishvananda Ishaya <[email protected]> <[email protected]> > Author: Zhongyue Luo <[email protected]> <[email protected]> > > 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 [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
