From: "Adam Young" <ayoung(a)redhat.com&gt; To: rdo-list(a)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. > > 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. > > 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. 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?

----- Original Message ----- > From: "Adam Young" <ayoung(a)redhat.com&gt; > To: rdo-list(a)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.

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

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

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

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

I don't know much about MidoNet, but in order to get accepted in RDO 1. licensing should be compatible with RDO

2. it has to be an upstreamed effort

3. an identified maintainer (RDO Eng. will focus on maintaining "core" projects, and we won't be maintaining all neutron drivers)

4. provide packages conforming Fedora guidelines

5. take responsibility for CI

As far as these conditions are respected, there should be no problems in accepting MidoNet in RDO.

In brief, what we require is commitment and taking responsibility of contributed packages.

Sandro, we'll both be at Flock in few weeks, so I'll be glad to discuss with you about it.

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

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 > On Wed, Jul 29, 2015 at 3:35 AM, Haïkel <hguemar(a)fedoraproject.org&gt; 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 :)

>> 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 :) Well, one of our main differences e.g. from the default plugin/SDN solution (ovs) is, that we don't have a central network node but instead an agent on all compute nodes. So I'm not sure I would fully agree with that.

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

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

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

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.

Thanks, Arkady -----Original Message----- From: rdo-list-bounces(a)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(a)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(a)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(a)redhat.com https://www.redhat.com/mailman/listinfo/rdo-list To unsubscribe: rdo-list-unsubscribe(a)redhat.com _______________________________________________ Rdo-list mailing list Rdo-list(a)redhat.com https://www.redhat.com/mailman/listinfo/rdo-list To unsubscribe: rdo-list-unsubscribe(a)redhat.com

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

On 07/30/2015 07:14 AM, Perry Myers wrote: >> >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. > Heh...I still stand by it. But, to be clear: make sure the parts that you want to ship with RDO are build able on Fedora; We want to be able to test against as far upstream as possible. I tend to develop on Fedora and then test against Centos and RHEL.

For the Java stuff....yeah, it can be a lot of work, but ultimately is worth the effort.

We went through a lot of packaging pain for Dogtag, whcih is part of Barbican...Dogtag was, I think, the first Tomcat Application that got into Fedora. WIth JPackage etc, getting RPMs for the Software you have is manageable. But all that is is beyond the string need for the Neutron Plugin. SO, it depends on how far you want to go. If you only care about getting the plugin into RDO, yeah, you don't need to package the Java code. If you want to participate in the RDO and Fedora communities, I'd recommend getting the packages done correctly, but that can be done over time.

I'd recommend looking into hosting COPR for the components you want to build. You can start with the easy ones. The Fedora Java team has done a lot of work on getting Maven builds to be able to select only packages that are themselves part of Fedora. You might be surprised at how much packaging you don't actually have to write today. As an added benefit, you get code that will help you installing the rest of MidoNet on a RHEL system.

FWIW, I'm a long-standing (8+ years) Fedora contributor myself and I've hold many roles during that time, including that of a Fedora Packager - and most of the software I packages was written in Java and built using ant or maven. So I do understand all these points, etc. But for the MidoNet community, Fedora is not currently a priority. Let's focus on RDO only here, alright? :)