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