Open Stack

On Tue, Dec 8, 2015 at 9:54 PM, Guillermo Ontañón
<guillermo at midokura.com> wrote:
> Hi Sandro,
>
> On Tue, Dec 8, 2015 at 7:31 AM, Sandro Mathys <sandro at midokura.com> wrote:
>> Hi,
>>
>> As Takashi Yamamoto raised in another thread [0], python-midonetclient
>> should be split out into its own repo
>
>
> I'm strongly against on this one. Stuff in the midonet/ repo is
> developed in sync with python-midonetclient (and much more so today
> that it's an internal api), and even depends on it, all the tests/

do you mean that the rest api used between python-midonetclient and
midonet-cluster is an internal api?

> directory in midonet/ depends on python-midonetclient. A split would
> make a lot of workflows costlier / inconvenient / impossible (for
> instance, it becomes impossible to gate properly when a patch
> introduces changes to the rest api).
>
>>  There's two major reasons for
>> this:
>>
>> 1) (Downstream) packaging: midonet and python-midonetclient are two
>> distinct packages, and therefore should have distinct upstream
>> tarballs - which are compiled on a per repo basis.
>
> It is fairly common for a single source tarball to produce multiple
> binary packages. In fact, midonet produces 4 binary packages, are you
> proposing that we split out midonet-tools and midonet-cluster too?
>
>
>> 2) When adding repositories to OpenStack, they need to be tagged.
>> There's a bunch of tags, and one category is the "type": library [1]
>> or service [2]. Now midonet is a service, but python-midonetclient is
>> a library so they need to be separate repositories.
>
> I find it hard to buy this argument, the midonet repository includes
> several other internal libraries and we are not splitting those out.
>
> Regards,
> G
>
>>
>> Thoughts?
>>
>> Cheers,
>> Sandro
>>
>> [0] http://lists.openstack.org/pipermail/openstack-dev/2015-December/081216.html
>> [1] http://governance.openstack.org/reference/tags/type_library.html
>> [2] http://governance.openstack.org/reference/tags/type_service.html
>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev