[Rdo-list] Integration of MidoNet into RDO Manager

[Alan Pevec]

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

ACK - I want to emphasize that part: Fedora packaging guidlines
actually do make sense and we want to stick to them even when we'll
have separate review process. Exceptions should be reviewed carefully
and added as written guidelines in RDO packaging documentation.

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

Very good reason for un-bundling is security updates, bundling is like
static linking e.g. security fix in glibc would require distribution
rebuild if it not were a dynamic library...
So before allowing bundling we need to come up with the process to
track all bundled libraries so that we know which packages need to be
rebuilt and how, when CVE fixes come around.
It could be that security response team already has tools for that,
AFAIK golang packages need to be rebuild when there are library
changes?

Cheers,
Alan