[Rdo-list] Integration of MidoNet into RDO Manager

[Sandro Mathys]

Thanks for your replies.

On Wed, Jul 29, 2015 at 12:27 AM, Steve Gordon <sgordon at redhat.com> wrote:
> ----- Original Message -----
>> From: "Adam Young" <ayoung at redhat.com>
>> To: rdo-list at redhat.com
>>
>> On 07/28/2015 01:49 AM, Sandro Mathys wrote:
>> > Dear all,
>> >
>> > We, the MidoNet Community [0], would like to integrate MidoNet into
>> > RDO Manager. Our resources are limited, so this won't happen over
>> > night - but we have to begin somewhere. Let's start with a few basics
>> > and questions.
>> >
>> > In case you haven't heard yet: MidoNet is a network virtualization
>> > software that plugs into OpenStack Neutron. While OpenStack is
>> > currently our main focus, it's not our only use case - but obviously
>> > the one we'll focus on here. Our packages are currently hosted in our
>> > very own repository [1].
>> Looks like an APT repo;  I see no SRPMS in
>>
>> http://repo.midonet.org/openstack-kilo/RHEL/7/unstable/SRPMS/
>>
>> I don't see sources for the .debs either.    You probably want to get
>> those published;  just linking to the git repo is not sufficient as
>> people need to be able to rebuild the binary packages.

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)?

>> >
>> > 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)?

>> > 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.

>> 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?

> Thanks,
>
> Steve
>
> _______________________________________________
> Rdo-list mailing list
> Rdo-list at redhat.com
> https://www.redhat.com/mailman/listinfo/rdo-list
>
> To unsubscribe: rdo-list-unsubscribe at redhat.com


On Wed, Jul 29, 2015 at 3:35 AM, Haïkel <hguemar at fedoraproject.org> 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?

> 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?

> 5. take responsibility for CI

Of course.

> 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 :)

Cheers,
Sandro

> Regards,
> H.
>
> _______________________________________________
> Rdo-list mailing list
> Rdo-list at redhat.com
> https://www.redhat.com/mailman/listinfo/rdo-list
>
> To unsubscribe: rdo-list-unsubscribe at redhat.com