<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:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=iso-8859-1"><meta name=Generator content="Microsoft Word 15 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:SimSun;
panose-1:2 1 6 0 3 1 1 1 1 1;}
@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:"Trebuchet MS";
panose-1:2 11 6 3 2 2 2 2 2 4;}
@font-face
{font-family:"\@SimSun";
panose-1:2 1 6 0 3 1 1 1 1 1;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-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
{mso-style-priority:99;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
span.EmailStyle17
{mso-style-type:personal-compose;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;
font-family:"Calibri",sans-serif;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></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-US link=blue vlink=purple><div class=WordSection1><p><b><span style='font-size:9.0pt;font-family:"Trebuchet MS",sans-serif;color:#AAAAAA'>Dell - Internal Use - Confidential </span></b><o:p></o:p></p><p class=MsoNormal>Correct!<o:p></o:p></p><p>-----Original Message-----<br>From: Sandro Mathys [mailto:sandro@mathys.io] <br>Sent: Thursday, July 30, 2015 10:53 AM<br>To: Kanevsky, Arkady<br>Cc: Hugh O. Brock; Perry Myers; rdo-list@redhat.com; Perryman, Randy<br>Subject: Re: [Rdo-list] Integration of MidoNet into RDO Manager<br><br>On Thu, Jul 30, 2015 at 10:47 PM, wrote:<br>> Agree with Hugh.<br>><br>> We need to be careful how we expose midonet option to user.<br>><br>> Best if we can expose midonet option for neutron under tuscar.<br>><br>> By default midonet will run on controller nodes with agents on each <br>> compute node. There are a few other things that need to be done outside packages.<br>><br>> BGP network will be needed separate from public one. (separation of <br>> external API from floating IP one). Tons of details on dependencies including Java.<br>><br>> Finally midonet manager GUI. But that is the last step that maybe <br>> outside RDO.<br><br>Just one correction (and maybe clarification): MidoNet Manager is non-open and exclusive part of Midokura Enterprise MidoNet (MEM).<br>We're talking about the open-source/"community edition" MidoNet here.<br>-- Sandro<br><br>> Thanks,<br>><br>> Arkady<br>><br>> -----Original Message-----<br>> From: rdo-list-bounces@redhat.com [mailto:rdo-list-bounces@redhat.com] <br>> On Behalf Of Hugh O. Brock<br>> Sent: Thursday, July 30, 2015 6:22 AM<br>> To: Perry Myers<br>> Cc: rdo-list@redhat.com<br>> Subject: Re: [Rdo-list] Integration of MidoNet into RDO Manager<br>><br>> On Thu, Jul 30, 2015 at 07:14:54AM -0400, Perry Myers wrote:<br>>> > It's combined APT and RPM, but you're right, there's currently no <br>>> > source packages for either.<br>>> ><br>>> > Out of curiosity, why do people need to be able to rebuild them (in <br>>> > the scenario we're discussing - integrating MidoNet with RDO Manager)?<br>>><br>>> I don't think they strictly need this ability. Providing packages <br>>> that are rebuildable by the community is a nice thing to do, but it <br>>> shouldn't be a strict requirement in a case like this, I believe.<br>>><br>>> If anything I'd focus on providing a rebuildable RPM for the Neutron <br>>> plugin itself, but perhaps skip that for the SDN solution that is <br>>> paired with it.<br>>><br>>> >>>><br>>> >>>> Are packages hosted on the developer's repositories acceptable <br>>> >>>> for integration into RDO Manager? We need to unbundle a couple <br>>> >>>> of things (or maybe more than just a couple) before we can <br>>> >>>> package them for inclusion into the proper repository.<br>>> >>> Typically, using a COPR is just a transition step to getting <br>>> >>> packages into Fedora; RDO very much follows the Fedora model.<br>>> >>><br>>> >>> The individual packages themselves must be submitted, reviewed, <br>>> >>> and maintained. RDO manager is the last step of the process, and <br>>> >>> will only work with RDOmanaged packages.<br>>> ><br>>> > So all our packages would have to be part of the RDO repository <br>>> > (which I trust follows the EPEL/Fedora Guidelines)?<br>>><br>>> I think having the packages part of a repo available on RDO would <br>>> make the end user experience a lot easier, but I don't think there <br>>> is/should be a strict requirement that anything integrated with RDO <br>>> and RDO Manager _must_ be hosted on the RDO site.<br>>><br>>> We might want to differentiate between (for example) the Neutron <br>>> plugin packages and the SDN solution, for that.<br>>><br>>> I also want to make sure folks understand that I don't think that <br>>> getting packages like this 'into Fedora' should be a requirement.<br>>><br>>> Right now we are tied to getting things into Fedora since we don't <br>>> have another place to host spec files, etc, but we're working on <br>>> decoupling from this so that we can move to a model where we are 'on <br>>> Fedora'<br>>> instead of 'in Fedora'<br>>><br>>> But to the extent that we can, we try to follow Fedora packaging <br>>> guidelines as a best practice, but can/will make exceptions where it <br>>> makes sense.<br>>><br>>> >>>> Speaking of repositories, once we're ready to package them <br>>> >>>> properly for inclusion, which repository would be the (most?) <br>>> >>>> proper one for RDO Manager? RDO? CentOS (wherever Cloud SIG <br>>> >>>> packages go)? EPEL?<br>>> >>> Its usually easiest to start with Fedora for all packaging. Once <br>>> >>> they are accepted into Fedora, figuring out how to get them into <br>>> >>> the appropriate other locations will follow.<br>>> ><br>>> > Well, for our packages, Fedora and EL would be fairly different. <br>>> > The MidoNet core is written in Java/Scala, so much more (tools, <br>>> > deps) is missing from EL, e.g. gradle and of course lots of <br>>> > artifacts. So we should target EPEL, I guess.<br>>><br>>> I wouldn't follow Adam's advice here (starting with Fedora).<br>>> Especially for the SDN solution which is Java based. That would lead <br>>> to a lot of pain and overhead.<br>>><br>>> >>> Thus far, RDO manager has been focused on upstream OpenStack and <br>>> >>> the necessary pieces from the base OS that need to be updated to <br>>> >>> support it. While it should be possible to have an add-on like <br>>> >>> MidoNet, I don't know how the rest of the community would feel <br>>> >>> about it being required to be part of RDO. My thought is that, so <br>>> >>> long as it A) is under a sufficient license and B) provides real <br>>> >>> value beyond what is available from Neutron, it should be <br>>> >>> possible to include, so long as including it does not impact <br>>> >>> people currently developing and deploying RDO.<br>>> >>><br>>> >>><br>>> >>> Is there any move to get MidoNet into upstream OpenStack?<br>>> >><br>>> >> Aren't we talking about the midonet neutron plug-in which was <br>>> >> already part of neutron-proper but as a result of the plug-in <br>>> >> decomposition effort now has it's own repo under the openstack <br>>> >> namespace ( <br>>> >> http://git.openstack.org/cgit/openstack/networking-midonet/ ). I'm <br>>> >> really unclear on what the issue is here versus other RDO-Manager integration efforts - perhaps you can clarify?<br>>> ><br>>> > Yes, that's what we're talking about, thanks for providing the <br>>> > reference :)<br>>> ><br>>> > However, I'm a bit confused now - surely, integration would not <br>>> > just include the plugin but also the SDN solution the plugin is <br>>> > leveraging, right?<br>>><br>>> That's actually a good question. I think typically we've been <br>>> thinking about integration of the plugin only, because that is <br>>> co-located on compute nodes and there might be controller node <br>>> software that needs to be bundled for certain SDN solutions as well.<br>>><br>>> But I can see where deployment of the SDN solution itself by RDO <br>>> Manager could be very useful and would make the end user experience <br>>> much easier.<br>>> But I'd have to defer to folks on that team as to how and if this <br>>> could be done :)<br>><br>> I think we would be anxious to help with this. We want RDO Manager to <br>> be a one-stop shop for all kinds of deployments -- the more <br>> participation we have, the better.<br>><br>>> >> Thanks,<br>>> >><br>>> >> Steve<br>>> >><br>>> ><br>>> > On Wed, Jul 29, 2015 at 3:35 AM, Haïkel wrote:<br>>> >> I don't know much about MidoNet, but in order to get accepted in <br>>> >> RDO<br>>> >><br>>> >> 1. licensing should be compatible with RDO<br>>> ><br>>> > Apache Software License 2.0<br>>> ><br>>> >> 2. it has to be an upstreamed effort<br>>> ><br>>> > Like with most Neutron plugins, the plugin itself is upstream but <br>>> > the rest isn't.<br>>> ><br>>> > Neutron MidoNet Plugin (as shared by Steve above already):<br>>> > http://git.openstack.org/cgit/openstack/networking-midonet/<br>>> ><br>>> > MidoNet:<br>>> > https://github.com/midonet/midonet/<br>>> ><br>>> ><br>>> >> 3. an identified maintainer (RDO Eng. will focus on maintaining "core"<br>>> >> projects, and we won't be maintaining all neutron drivers)<br>>> ><br>>> > That should be no problem. Does this have to be a single person or <br>>> > can it be a team?<br>>><br>>> A single person can be a team :)<br>>><br>>> >> 4. provide packages conforming Fedora guidelines<br>>> ><br>>> > Okay, so - as Adam and Steve already hinted - non-conforming <br>>> > packages (hosted on our own repo) are not acceptable then? Our <br>>> > biggest headache right now (like with any Java software) in terms <br>>> > of the Fedora Packaging Guidelines are tons of bundled jars - so <br>>> > that would be a no-go, right?<br>>><br>>> I think we need to relax the requirements on #4 here. For the Neutron <br>>> plugin, I think we can/should conform to Fedora packaging guidelines, <br>>> and definitely get that package hosted on RDO directly.<br>>><br>>> For the SDN solution in Java, I think we should either allow:<br>>> * Relaxed packaging guidelines, recognizing that this is an SDN <br>>> solution, and we host Midonet RPMs on RDO site (i.e. allow jar <br>>> bundling for this)<br>>> * Or allow RDO Manager to pull packages from your repos, not hosted <br>>> on RDO site<br>>><br>>> I think either path should be acceptable.<br>><br>> Yes, this is exactly right. We want the neutron plugin to be packaged <br>> such that we can build it into the overcloud images, but the SDN <br>> solution can easily be added post-build with virt-customize or <br>> equivalent. I would never recommend anyone go through the full java <br>> un-bundling process without a very, very good reason.<br>><br>>> >> 5. take responsibility for CI<br>>> ><br>>> > Of course.<br>>><br>>> With assistance from the CI team in RDO, of course, to get you started.<br>>><br>>> >> As far as these conditions are respected, there should be no <br>>> >> problems in accepting MidoNet in RDO.<br>>> ><br>>> > Getting all these deps packaged will really be a major effort so if <br>>> > that's required, it will take a while. Otherwise, I see no <br>>> > obstacles<br>>> > :)<br>>> ><br>>> >> In brief, what we require is commitment and taking responsibility <br>>> >> of contributed packages.<br>>> ><br>>> > Sure, that's in our best interest anyway :)<br>>> ><br>>> >> Sandro, we'll both be at Flock in few weeks, so I'll be glad to <br>>> >> discuss with you about it.<br>>> ><br>>> > Sure, let's do that :)<br>>><br>>> Sounds like a plan.<br>>><br>>> Sandro, glad to see you engaging with us in the community here, and <br>>> looking forward to seeing how this integration works!<br>>><br>>> Thanks,<br>>><br>>> Perry<br>><br>> +1 from me, we're really looking forward to getting Midonet into RDO<br>> Manager!<br>><br>> --Hugh<br>><br>> --<br>> == Hugh Brock, hbrock@redhat.com ==<br>> == Senior Engineering Manager, Cloud Engineering == == RDO Manager: <br>> Install, configure, and scale OpenStack == == http://rdoproject.org ==<br>><br>> "I know that you believe you understand what you think I said, but I’m <br>> not sure you realize that what you heard is not what I meant."<br>> --Robert McCloskey<br>><br>> _______________________________________________<br>> Rdo-list mailing list<br>> Rdo-list@redhat.com<br>> https://www.redhat.com/mailman/listinfo/rdo-list<br>><br>> To unsubscribe: rdo-list-unsubscribe@redhat.com<br>><br>><br>> _______________________________________________<br>> Rdo-list mailing list<br>> Rdo-list@redhat.com<br>> https://www.redhat.com/mailman/listinfo/rdo-list<br>><br>> To unsubscribe: rdo-list-unsubscribe@redhat.com<o:p></o:p></p></div></body></html>