<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:x="urn:schemas-microsoft-com:office:excel" xmlns:p="urn:schemas-microsoft-com:office:powerpoint" xmlns:a="urn:schemas-microsoft-com:office:access" xmlns:dt="uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s="uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs="urn:schemas-microsoft-com:rowset" xmlns:z="#RowsetSchema" xmlns:b="urn:schemas-microsoft-com:office:publisher" xmlns:ss="urn:schemas-microsoft-com:office:spreadsheet" xmlns:c="urn:schemas-microsoft-com:office:component:spreadsheet" xmlns:odc="urn:schemas-microsoft-com:office:odc" xmlns:oa="urn:schemas-microsoft-com:office:activation" xmlns:html="http://www.w3.org/TR/REC-html40" xmlns:q="http://schemas.xmlsoap.org/soap/envelope/" xmlns:rtc="http://microsoft.com/officenet/conferencing" xmlns:D="DAV:" xmlns:Repl="http://schemas.microsoft.com/repl/" xmlns:mt="http://schemas.microsoft.com/sharepoint/soap/meetings/" xmlns:x2="http://schemas.microsoft.com/office/excel/2003/xml" xmlns:ppda="http://www.passport.com/NameSpace.xsd" xmlns:ois="http://schemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir="http://schemas.microsoft.com/sharepoint/soap/directory/" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:dsp="http://schemas.microsoft.com/sharepoint/dsp" xmlns:udc="http://schemas.microsoft.com/data/udc" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:sub="http://schemas.microsoft.com/sharepoint/soap/2002/1/alerts/" xmlns:ec="http://www.w3.org/2001/04/xmlenc#" xmlns:sp="http://schemas.microsoft.com/sharepoint/" xmlns:sps="http://schemas.microsoft.com/sharepoint/soap/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:udcs="http://schemas.microsoft.com/data/udc/soap" xmlns:udcxf="http://schemas.microsoft.com/data/udc/xmlfile" xmlns:udcp2p="http://schemas.microsoft.com/data/udc/parttopart" xmlns:wf="http://schemas.microsoft.com/sharepoint/soap/workflow/" xmlns:dsss="http://schemas.microsoft.com/office/2006/digsig-setup" xmlns:dssi="http://schemas.microsoft.com/office/2006/digsig" xmlns:mdssi="http://schemas.openxmlformats.org/package/2006/digital-signature" xmlns:mver="http://schemas.openxmlformats.org/markup-compatibility/2006" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns:mrels="http://schemas.openxmlformats.org/package/2006/relationships" xmlns:spwp="http://microsoft.com/sharepoint/webpartpages" xmlns:ex12t="http://schemas.microsoft.com/exchange/services/2006/types" xmlns:ex12m="http://schemas.microsoft.com/exchange/services/2006/messages" xmlns:pptsl="http://schemas.microsoft.com/sharepoint/soap/SlideLibrary/" xmlns:spsl="http://microsoft.com/webservices/SharePointPortalServer/PublishedLinksService" xmlns:Z="urn:schemas-microsoft-com:" xmlns:st="" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=Content-Type content="text/html; charset=utf-8">
<meta name=Generator content="Microsoft Word 12 (filtered medium)">
<style>
<!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0cm;
margin-right:0cm;
margin-bottom:0cm;
margin-left:36.0pt;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
span.EmailStyle17
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;}
@page Section1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.Section1
{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=EN-GB link=blue vlink=purple>
<div class=Section1>
<p class=MsoNormal>> Try as we might there is still not a real consensus on
high level coding style, for example the Xen-related code is radically
different in shape and style from<o:p></o:p></p>
<p class=MsoNormal>> the libvirt code as is the rackspace api from the ec2
api, and having projects split off only worsens the problem as individual
developers have fewer eyes on them.<o:p></o:p></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>For what it’s worth, I’m not entirely happy with the coding
style in nova.virt.xenapi either, so we might not be as far from consensus as
you think. Some of the “Java-ish” code was allowed through code review for the
sake of expedience, because it was a big improvement over what was there, even
if it wasn’t perfect. I’d like to rework this whenever there’s a sensible time
to do so.<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Also, I’d love for us to be using the same code paths as much as
possible, and whatever help you need getting off KVM and onto a proper
hypervisor, I’m more than happy to help ;-)<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Ewan.<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<div style='border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt'>
<div>
<div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm'>
<p class=MsoNormal><b><span lang=EN-US style='font-size:10.0pt;font-family:
"Tahoma","sans-serif"'>From:</span></b><span lang=EN-US style='font-size:10.0pt;
font-family:"Tahoma","sans-serif"'> Andy Smith [mailto:andyster@gmail.com] <br>
<b>Sent:</b> 28 January 2011 15:40<br>
<b>To:</b> Rick Clark<br>
<b>Cc:</b> Jay Pipes; Ewan Mellor; Søren Hansen; openstack@lists.launchpad.net<br>
<b>Subject:</b> Re: [Openstack] Network Service for L2/L3 Network
Infrastructure blueprint<o:p></o:p></span></p>
</div>
</div>
<p class=MsoNormal><o:p> </o:p></p>
<p class=MsoNormal>I'd second a bit of what Jay says and toss in that I don't
think the code is ready to be splitting services off:<o:p></o:p></p>
<div>
<p class=MsoNormal><o:p> </o:p></p>
</div>
<div>
<p class=MsoNormal>- There have already been significant problems dealing with
glance, the nasa people and the rackspace people have effectively completely
different code paths (nasa: ec2, objectstore, libvirt; rackspace: rackspace,
glance, xenapi) and that needs to be aligned a bit more before we can create
more separations if we want everybody to be working towards the same goals.<o:p></o:p></p>
</div>
<div>
<p class=MsoNormal>- Try as we might there is still not a real consensus on
high level coding style, for example the Xen-related code is radically
different in shape and style from the libvirt code as is the rackspace api from
the ec2 api, and having projects split off only worsens the problem as
individual developers have fewer eyes on them.<o:p></o:p></p>
</div>
<div>
<p class=MsoNormal><o:p> </o:p></p>
</div>
<div>
<p class=MsoNormal>My goal and as far as I can tell most of my team's goals are
to rectify a lot of that situation over the course of the next release by:<o:p></o:p></p>
</div>
<div>
<p class=MsoNormal><o:p> </o:p></p>
</div>
<div>
<p class=MsoNormal>- setting up and working through the rackspace side of the
code paths (as mentioned above) enough that we can start generalizing its
utility for the entire project<o:p></o:p></p>
</div>
<div>
<p class=MsoNormal>- actual deprecation of the majority of objectstore<o:p></o:p></p>
</div>
<div>
<p class=MsoNormal>- more thorough code reviews to ensure that code is meeting
the overall style of the project, and probably a document describing the code
review process<o:p></o:p></p>
</div>
<div>
<p class=MsoNormal><o:p> </o:p></p>
</div>
<div>
<p class=MsoNormal>After Cactus if the idea makes sense to split off then it
can be pursued then, but at the moment it is much too early to consider it.<o:p></o:p></p>
</div>
<div>
<p class=MsoNormal><o:p> </o:p></p>
<div>
<p class=MsoNormal>On Fri, Jan 28, 2011 at 7:06 AM, Rick Clark <<a
href="mailto:rick@openstack.org">rick@openstack.org</a>> wrote:<o:p></o:p></p>
<div>
<p class=MsoNormal>On 01/28/2011 08:55 AM, Jay Pipes wrote:<br>
> On Fri, Jan 28, 2011 at 8:47 AM, Rick Clark <<a
href="mailto:rick@openstack.org">rick@openstack.org</a>> wrote:<o:p></o:p></p>
</div>
<div>
<p class=MsoNormal style='margin-bottom:12.0pt'>> I recognise the desire to
do this for Cactus, but I feel that pulling<br>
> out the network controller (and/or volume controller) into their own<br>
> separate OpenStack subprojects is not a good idea for Cactus.
Looking<br>
> at the (dozens of) blueprints slated for Cactus, doing this kind of<br>
> major rework will mean that most (if not all) of those blueprints will<br>
> have to be delayed while this pulling out of code occurs. This will<br>
> definitely jeopardise the Cactus release.<br>
><br>
> My vote is to delay this at a minimum to the Diablo release.<br>
><br>
> And, for the record, I haven't seen any blueprints for the network as<br>
> a service or volume as a service projects. Can someone point us to<br>
> them?<br>
><br>
> Thanks!<br>
> jay<o:p></o:p></p>
</div>
<p class=MsoNormal style='margin-bottom:12.0pt'>Whew, Jay I thought you were
advocating major changes in Cactus. That<br>
would completely mess up my view of the world :)<br>
<br>
<a href="https://blueprints.launchpad.net/nova/+spec/bexar-network-service"
target="_blank">https://blueprints.launchpad.net/nova/+spec/bexar-network-service</a><br>
<a href="https://blueprints.launchpad.net/nova/+spec/bexar-extend-network-model"
target="_blank">https://blueprints.launchpad.net/nova/+spec/bexar-extend-network-model</a><br>
<a href="https://blueprints.launchpad.net/nova/+spec/bexar-network-service"
target="_blank">https://blueprints.launchpad.net/nova/+spec/bexar-network-service</a><br>
<br>
<br>
It was discussed at ODS, but I have not seen any code or momentum, to date.<br>
<br>
I think it is worth while to have an open discussion about what if any<br>
of this can be safely done in Cactus. I like you, Jay, feel a bit<br>
conservative. I think we lost focus of the reason we chose time based<br>
releases. It is time to focus on nova being a solid trustworthy<br>
platform. Features land when they are of sufficient quality, releases<br>
contain only the features that passed muster.<br>
<br>
I will be sending an email about the focus and theme of Cactus in a<br>
little while.<br>
<span style='color:#888888'><br>
Rick<br>
<br>
<br>
</span><br>
_______________________________________________<br>
Mailing list: <a href="https://launchpad.net/~openstack" target="_blank">https://launchpad.net/~openstack</a><br>
Post to : <a href="mailto:openstack@lists.launchpad.net">openstack@lists.launchpad.net</a><br>
Unsubscribe : <a href="https://launchpad.net/~openstack" target="_blank">https://launchpad.net/~openstack</a><br>
More help : <a href="https://help.launchpad.net/ListHelp" target="_blank">https://help.launchpad.net/ListHelp</a><o:p></o:p></p>
</div>
<p class=MsoNormal><o:p> </o:p></p>
</div>
</div>
</div>
</body>
</html>