[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [Rdo-list] Integration of MidoNet into RDO Manager



On Thu, Jul 30, 2015 at 10:47 PM,  <Arkady_Kanevsky dell com> 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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]