<div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote">On Thu, Sep 19, 2013 at 2:59 PM, Adam Young <span dir="ltr"><<a href="mailto:ayoung@redhat.com" target="_blank">ayoung@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<div>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:<br>
<br>
<br>
Title: Extracting Shared Libraries from incubator<br>
<br>
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.<br></div></div></blockquote><div><br></div><div>I believe the goal of oslo-incubator IS to spin out common code into standalone libraries in the long run, as appropriate.</div><div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF"><div>
<br>
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.</div></div></blockquote><div><br></div><div>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.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF"><div><div class="im"><br>
<br>
<br>
On 09/19/2013 12:22 PM, Brant L Knudson wrote:<br>
</div></div><div><div class="h5">
<blockquote type="cite">
<p><font face="sans-serif">What's different between
policy and anything else in oslo-incubator? "</font><tt><font>If a CVS is found in the oslo-incubator code base,
we have no clean way of deploying a fix.</font></tt><font face="sans-serif">"</font><br>
<br>
<font face="sans-serif">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.</font><br>
<br>
<font face="sans-serif">The oslo-incubator projects do
have maintainers: <a href="https://github.com/openstack/oslo-incubator/blob/master/MAINTAINERS" target="_blank">https://github.com/openstack/oslo-incubator/blob/master/MAINTAINERS</a></font><br>
<br>
<font face="sans-serif">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.</font><br>
<font face="sans-serif"><br>
Brant Knudson, OpenStack Development - Keystone core member<br>
Phone: <a href="tel:507-253-8621" value="+15072538621" target="_blank">507-253-8621</a> T/L:553-8621<br>
</font><br>
<br>
<img src="cid:part2.08010307.06050602@redhat.com" alt="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" height="16" width="16" border="0"><font color="#424282" face="sans-serif">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</font><br>
<br>
<font size="1" color="#5F5F5F" face="sans-serif">From: </font><font size="1" face="sans-serif">Adam Young
<a href="mailto:ayoung@redhat.com" target="_blank"><ayoung@redhat.com></a></font><br>
<font size="1" color="#5F5F5F" face="sans-serif">To: </font><font size="1" face="sans-serif">Dolph Mathews
<a href="mailto:dolph.mathews@gmail.com" target="_blank"><dolph.mathews@gmail.com></a>, "Yee, Guang"
<a href="mailto:guang.yee@hp.com" target="_blank"><guang.yee@hp.com></a>, Henry Nash
<a href="mailto:henryn@linux.vnet.ibm.com" target="_blank"><henryn@linux.vnet.ibm.com></a>, Morgan Fainberg
<a href="mailto:m@metacloud.com" target="_blank"><m@metacloud.com></a>, Brant L Knudson/Rochester/IBM@IBMUS,
Morgan Fainberg <a href="mailto:m@metacloud.com" target="_blank"><m@metacloud.com></a>, </font><br>
<font size="1" color="#5F5F5F" face="sans-serif">Cc: </font><font size="1" face="sans-serif">Jamie Lennox
<a href="mailto:jamielennox@gmail.com" target="_blank"><jamielennox@gmail.com></a></font><br>
<font size="1" color="#5F5F5F" face="sans-serif">Date: </font><font size="1" face="sans-serif">09/19/2013 10:33 AM</font><br>
<font size="1" color="#5F5F5F" face="sans-serif">Subject: </font><font size="1" face="sans-serif">Client and Policy</font><br>
</p>
<hr style="color:#8091a5" noshade size="2" width="100%" align="left"><br>
<br>
<br>
<tt><font>Policy is part of Oslo. But it is a copied
into the various projects. <br>
If a CVS is found in the policy code base, we have no clean
way of <br>
deploying a fix.<br>
<br>
There are a couple of alternatives:<br>
<br>
1. Spin if off into a separate gitrepo and build it as a
standalone <br>
package: python-oslopolicy or something.<br>
2. Merge it in with an existing project. The obvious one
would be <br>
python-keystoneclient.<br>
<br>
While the second is the obvious solution, the problem is that
is crosses <br>
project team boundaries. Policy was originally part of
Keystone, but <br>
was deemd a common component and moved to Oslo.<br>
<br>
Both teams have a claim to gatekeeping this code.
Fortunately, it does <br>
not have to be either/or.<br>
<br>
Potential solution #1: suggest that the policy code move to
the <br>
keystone client, and invite a subset of the Oslo core devs
over to <br>
Keystone as core devs.<br>
<br>
The people that have commits to policy.py in Oslo are:<br>
<br>
Author: Andrew Bogott <a href="mailto:abogott@wikimedia.org" target="_blank"><abogott@wikimedia.org></a><br>
Author: Ann Kamyshnikova <a href="mailto:akamyshnikova@mirantis.com" target="_blank"><akamyshnikova@mirantis.com></a><br>
Author: Chuck Short <a href="mailto:chuck.short@canonical.com" target="_blank"><chuck.short@canonical.com></a><br>
Author: Dina Belova <a href="mailto:dbelova@mirantis.com" target="_blank"><dbelova@mirantis.com></a><br>
Author: Eric Windisch <a href="mailto:eric@cloudscaling.com" target="_blank"><eric@cloudscaling.com></a><br>
Author: Flaper Fesp <a href="mailto:flaper87@gmail.com" target="_blank"><flaper87@gmail.com></a><br>
Author: guohliu <a href="mailto:guohliu@cn.ibm.com" target="_blank"><guohliu@cn.ibm.com></a><br>
Author: Jenkins <a href="mailto:jenkins@review.openstack.org" target="_blank"><jenkins@review.openstack.org></a><br>
Author: Kevin L. Mitchell <a href="mailto:kevin.mitchell@rackspace.com" target="_blank"><kevin.mitchell@rackspace.com></a><br>
Author: Mark McClain <a href="mailto:mark.mcclain@dreamhost.com" target="_blank"><mark.mcclain@dreamhost.com></a><br>
Author: Mark McLoughlin <a href="mailto:markmc@redhat.com" target="_blank"><markmc@redhat.com></a><br>
Author: Monty Taylor <a href="mailto:mordred@inaugust.com" target="_blank"><mordred@inaugust.com></a><br>
Author: Sergey Lukjanov <a href="mailto:slukjanov@mirantis.com" target="_blank"><slukjanov@mirantis.com></a><br>
Author: Victor Sergeyev <a href="mailto:vsergeyev@mirantis.com" target="_blank"><vsergeyev@mirantis.com></a><br>
Author: Vishvananda Ishaya <a href="mailto:vishvananda@gmail.com" target="_blank"><vishvananda@gmail.com></a><br>
Author: Zhongyue Luo <a href="mailto:zhongyue.nah@intel.com" target="_blank"><zhongyue.nah@intel.com></a><br>
<br>
Of these, Mark McLoughlin (Oslo PTL) and Andrew Bogott, are
active core <br>
developers.<br>
<br>
</font></tt><tt><font><a href="https://launchpad.net/%7Eoslo-core/+members#active" target="_blank">https://launchpad.net/~oslo-core/+members#active</a></font></tt><tt><font><br>
<br>
<br>
<br>
Potential solution#2 is that policy stays in oslo and becomes
a stand . <br>
If this is the case, then none of the Keystone devs have a say
over what <br>
goes in there. Since POlicy and identity go hand and hand, I
think it <br>
would be better if Keystone devs were more involved than that.
We could <br>
suggest that a handful of Keystone devs were tapped to be on
Oslo core <br>
with an agreement that they focus on the pieces for policy,
crypto and <br>
other security vital pieces.<br>
<br>
Potential Solution #3 we create an openstack-policy team that
has the <br>
core devs from both Keystone and Oslo in it. The git repo
would be <br>
python-openstackpolicy.<br>
<br>
From a deployment standpoint, moving policy into
keystoneclient is the <br>
simplest: all of the projects currently import Keystone
client into <br>
their servers to get the auth_token middleware. Once we did a
sync of <br>
the current code from oslo, it would be a matter of updating
the package <br>
paths for those servers.<br>
<br>
Wanted to float this past the Keystone core devs before
opening it up to <br>
a larger audience. I've included Jamie, as this grew out of a
<br>
conversation I had with him. We can obivously discuss this at
the <br>
Summit, but wanted to get our team's take on it.<br>
<br>
<br>
<br>
<br>
</font></tt><br>
</blockquote>
<br>
</div></div></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div><br></div>-Dolph
</div></div>