Re: [openstack-dev] [midonet] Split up python-midonetclient

[Jaume Devesa]

No. I'm saying that I prefer python-os-midonetclient to be a project by its
own
instead of being merged inside the neutron plugin repo.

On 14 December 2015 at 18:43, Antoni Segura Puimedon <
toni+openstac...@midokura.com> wrote:

>
>
> On Mon, Dec 14, 2015 at 6:07 PM, Jaume Devesa  wrote:
>
>> +1
>>
>> I think it is good compromise. Thanks Ryu!
>>
>> I understand the CLI will belong to the external part. I much prefer to
>> have
>> it in a separate project rather than into the plugin. Even if the code is
>> tiny.
>>
>
> Let me summarize it:
>
> python-midonetclient: Low level API that lives and breathes in
> midonet/midonet.
> Has the current cli.
> python-os-midonetclient: High level API that is in
> openstack/python-midonetclient
>  (can be packaged with a different
> name).
>
> Are you asking for python-os-midonetclient not to include the cli tool?
>
> I would prefer to keep with the OpenStack practice [1] of having it
> together. I don't
> think developing a python cli client for the new python-os-midonetclient
> that is
> on par with the neutron cli tool would be that big of a task and I think
> it would
> make operation nicer. It could even find the midonet-api from the zookeeper
> registry like the other tools do.
>
> [1]
> https://github.com/openstack/python-neutronclient/blob/master/setup.cfg
>
>>
>> If you will want to just do midonet calls for debugging or check the
>> MidoNet
>> virtual infrastructure, it will be cleaner to install it without
>> dependencies than
>> dragging the whole neutron project (networking-midonet depends on
>> neutron).
>>
>> Regards,
>>
>> On 14 December 2015 at 17:32, Ryu Ishimoto  wrote:
>>
>>> On Tue, Dec 15, 2015 at 1:00 AM, Sandro Mathys 
>>> wrote:
>>> > On Tue, Dec 15, 2015 at 12:02 AM, Ryu Ishimoto 
>>> wrote:
>>> >
>>> > So if I understand you correctly, you suggest:
>>> > 1) the (midonet/internal) low level API stays where it is and will
>>> > still be called python-midonetclient.
>>> > 2) the (neutron/external) high level API is moved into it's own
>>> > project and will be called something like python-os-midonetclient.
>>> >
>>> > Sounds like a good compromise which addresses the most important
>>> > points, thanks Ryu! I wasn't aware that these parts of the
>>> > python-midonetclient are so clearly distinguishable/separable but if
>>> > so, this makes perfect sense. Not perfectly happy with the naming, but
>>> > I figure it's the way to go.
>>>
>>> Thanks for the endorsement.  Yes, it is trivial to separate them (less
>>> than a day of work) because they are pretty much already separated.
>>>
>>> As for the naming, I think it's better to take a non-disruptive
>>> approach so that it's transparent to those currently developing the
>>> low level midonet client.  To your question, however, I have another
>>> suggestion, which is that for the high level client code, it may also
>>> make sense to just include that as part of the plugin.  It's such
>>> small code that it might not make sense to separate, and also likely
>>> to be used only by the plugin in the future.  Which basically means
>>> that the plugin need not depend on any python client library at all.
>>> I think this will simplify even further.  It should also be ok to be
>>> tied to the plugin release cycles as well assuming that's the only
>>> place the client is needed.
>>>
>>> Cheers,
>>> Ryu
>>>
>>>
>>>
>>> >
>>> > -- Sandro
>>>
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>>
>>
>> --
>> Jaume Devesa
>> Software Engineer at Midokura
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Jaume Devesa
Software Engineer at Midokura
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [midonet] Split up python-midonetclient

[Dan Mihai Dumitriu]

Just leave it as is. This whole thread is a waste of time.
On Dec 15, 2015 18:52, "Jaume Devesa"  wrote:

> No. I'm saying that I prefer python-os-midonetclient to be a project by
> its own
> instead of being merged inside the neutron plugin repo.
>
> On 14 December 2015 at 18:43, Antoni Segura Puimedon <
> toni+openstac...@midokura.com> wrote:
>
>>
>>
>> On Mon, Dec 14, 2015 at 6:07 PM, Jaume Devesa  wrote:
>>
>>> +1
>>>
>>> I think it is good compromise. Thanks Ryu!
>>>
>>> I understand the CLI will belong to the external part. I much prefer to
>>> have
>>> it in a separate project rather than into the plugin. Even if the code
>>> is tiny.
>>>
>>
>> Let me summarize it:
>>
>> python-midonetclient: Low level API that lives and breathes in
>> midonet/midonet.
>> Has the current cli.
>> python-os-midonetclient: High level API that is in
>> openstack/python-midonetclient
>>  (can be packaged with a
>> different name).
>>
>> Are you asking for python-os-midonetclient not to include the cli tool?
>>
>> I would prefer to keep with the OpenStack practice [1] of having it
>> together. I don't
>> think developing a python cli client for the new python-os-midonetclient
>> that is
>> on par with the neutron cli tool would be that big of a task and I think
>> it would
>> make operation nicer. It could even find the midonet-api from the
>> zookeeper
>> registry like the other tools do.
>>
>> [1]
>> https://github.com/openstack/python-neutronclient/blob/master/setup.cfg
>>
>>>
>>> If you will want to just do midonet calls for debugging or check the
>>> MidoNet
>>> virtual infrastructure, it will be cleaner to install it without
>>> dependencies than
>>> dragging the whole neutron project (networking-midonet depends on
>>> neutron).
>>>
>>> Regards,
>>>
>>> On 14 December 2015 at 17:32, Ryu Ishimoto  wrote:
>>>
 On Tue, Dec 15, 2015 at 1:00 AM, Sandro Mathys 
 wrote:
 > On Tue, Dec 15, 2015 at 12:02 AM, Ryu Ishimoto 
 wrote:
 >
 > So if I understand you correctly, you suggest:
 > 1) the (midonet/internal) low level API stays where it is and will
 > still be called python-midonetclient.
 > 2) the (neutron/external) high level API is moved into it's own
 > project and will be called something like python-os-midonetclient.
 >
 > Sounds like a good compromise which addresses the most important
 > points, thanks Ryu! I wasn't aware that these parts of the
 > python-midonetclient are so clearly distinguishable/separable but if
 > so, this makes perfect sense. Not perfectly happy with the naming, but
 > I figure it's the way to go.

 Thanks for the endorsement.  Yes, it is trivial to separate them (less
 than a day of work) because they are pretty much already separated.

 As for the naming, I think it's better to take a non-disruptive
 approach so that it's transparent to those currently developing the
 low level midonet client.  To your question, however, I have another
 suggestion, which is that for the high level client code, it may also
 make sense to just include that as part of the plugin.  It's such
 small code that it might not make sense to separate, and also likely
 to be used only by the plugin in the future.  Which basically means
 that the plugin need not depend on any python client library at all.
 I think this will simplify even further.  It should also be ok to be
 tied to the plugin release cycles as well assuming that's the only
 place the client is needed.

 Cheers,
 Ryu



 >
 > -- Sandro


 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe:
 openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

>>>
>>>
>>>
>>> --
>>> Jaume Devesa
>>> Software Engineer at Midokura
>>>
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
> --
> Jaume Devesa
> Software Engineer at Midokura
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 

Re: [openstack-dev] [midonet] Split up python-midonetclient

[Sandro Mathys]

On Tue, Dec 15, 2015 at 12:02 AM, Ryu Ishimoto  wrote:
> On Mon, Dec 14, 2015 at 6:34 PM, Sandro Mathys  wrote:
>> On Thu, Dec 10, 2015 at 4:46 PM, Galo Navarro  wrote:
>>>
>> Honestly, I don't think this discussion is leading anywhere.
>> Therefore, I'd like to request a decision by the MidoNet PTL as per
>> [1].
>
> I apologize for jumping in a bit late.  Clearly, we have those feeling
> passionate about both solutions, with good points made on both sides,
> so let me try to do the impossible task of making everyone happy (or
> at least, not completely ticked off!).
>
> I believe what we need is to come up with a solution that minimizes
> inconvenience to the developers and packagers alike, and not a
> one-sided solution.  MidoNet client is currently a mix of the low
> level MidoNet API client and high level (Neutron) API client, and they
> are mutually exclusive, and the code can be cleanly separated easily.
> I propose that we extract the high level API client code and make it
> it's own project, and leave the low level MidoNet API client code as
> is.
>
> My reasons are as follows:
>
> * We should try our best to follow the conventions of the OSt model as
> much as possible.  Without embracing their model, we are distancing
> ourselves further from becoming part of the Big Tent.   So let's move
> the client code that the Neutron plugin depends on to a separate
> project (python-os-midonetclient?) so that it follows the convention,
> and will simplify things for OSt packagers.  From OSt's point of view,
> python-midonetclient should be completely forgotten.
> * We should not cause inconvenience to the current developers of the
> low level MidoNet API, who develop python-midonetclient and
> midonet-cli for testing purposes (MDTS, for example).  Because the
> testing framework is part of midonet, moving python-midonetclient out
> of midonet will cause awkward development process for the midonet
> developers who will need to go back and forth between the projects.
> Also, by keeping them inside midonet, no change is required for
> packaging of python-midonetclient.  There are still users of the low
> level midonet API, so we will have to keep releasing the
> python-midonetclient package as we do now, but it does not necessarily
> have to be published for the OSt distributors.
>
> We have a clear separation of preferences among those that are from
> the OpenStack background and those that are not.  Thus, it makes the
> most sense to separate the projects the same way so that each party is
> responsible for the part that they consume.
>
> I hope this achieves the right balance.  Let me know if there are
> strong objections against this proposal.

So if I understand you correctly, you suggest:
1) the (midonet/internal) low level API stays where it is and will
still be called python-midonetclient.
2) the (neutron/external) high level API is moved into it's own
project and will be called something like python-os-midonetclient.

Sounds like a good compromise which addresses the most important
points, thanks Ryu! I wasn't aware that these parts of the
python-midonetclient are so clearly distinguishable/separable but if
so, this makes perfect sense. Not perfectly happy with the naming, but
I figure it's the way to go.

-- Sandro

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [midonet] Split up python-midonetclient

[Ryu Ishimoto]

On Mon, Dec 14, 2015 at 6:34 PM, Sandro Mathys  wrote:
> On Thu, Dec 10, 2015 at 4:46 PM, Galo Navarro  wrote:
>>
> Honestly, I don't think this discussion is leading anywhere.
> Therefore, I'd like to request a decision by the MidoNet PTL as per
> [1].

I apologize for jumping in a bit late.  Clearly, we have those feeling
passionate about both solutions, with good points made on both sides,
so let me try to do the impossible task of making everyone happy (or
at least, not completely ticked off!).

I believe what we need is to come up with a solution that minimizes
inconvenience to the developers and packagers alike, and not a
one-sided solution.  MidoNet client is currently a mix of the low
level MidoNet API client and high level (Neutron) API client, and they
are mutually exclusive, and the code can be cleanly separated easily.
I propose that we extract the high level API client code and make it
it's own project, and leave the low level MidoNet API client code as
is.

My reasons are as follows:

* We should try our best to follow the conventions of the OSt model as
much as possible.  Without embracing their model, we are distancing
ourselves further from becoming part of the Big Tent.   So let's move
the client code that the Neutron plugin depends on to a separate
project (python-os-midonetclient?) so that it follows the convention,
and will simplify things for OSt packagers.  From OSt's point of view,
python-midonetclient should be completely forgotten.
* We should not cause inconvenience to the current developers of the
low level MidoNet API, who develop python-midonetclient and
midonet-cli for testing purposes (MDTS, for example).  Because the
testing framework is part of midonet, moving python-midonetclient out
of midonet will cause awkward development process for the midonet
developers who will need to go back and forth between the projects.
Also, by keeping them inside midonet, no change is required for
packaging of python-midonetclient.  There are still users of the low
level midonet API, so we will have to keep releasing the
python-midonetclient package as we do now, but it does not necessarily
have to be published for the OSt distributors.

We have a clear separation of preferences among those that are from
the OpenStack background and those that are not.  Thus, it makes the
most sense to separate the projects the same way so that each party is
responsible for the part that they consume.

I hope this achieves the right balance.  Let me know if there are
strong objections against this proposal.

Best,
Ryu

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [midonet] Split up python-midonetclient

[Ryu Ishimoto]

On Tue, Dec 15, 2015 at 1:00 AM, Sandro Mathys  wrote:
> On Tue, Dec 15, 2015 at 12:02 AM, Ryu Ishimoto  wrote:
>
> So if I understand you correctly, you suggest:
> 1) the (midonet/internal) low level API stays where it is and will
> still be called python-midonetclient.
> 2) the (neutron/external) high level API is moved into it's own
> project and will be called something like python-os-midonetclient.
>
> Sounds like a good compromise which addresses the most important
> points, thanks Ryu! I wasn't aware that these parts of the
> python-midonetclient are so clearly distinguishable/separable but if
> so, this makes perfect sense. Not perfectly happy with the naming, but
> I figure it's the way to go.

Thanks for the endorsement.  Yes, it is trivial to separate them (less
than a day of work) because they are pretty much already separated.

As for the naming, I think it's better to take a non-disruptive
approach so that it's transparent to those currently developing the
low level midonet client.  To your question, however, I have another
suggestion, which is that for the high level client code, it may also
make sense to just include that as part of the plugin.  It's such
small code that it might not make sense to separate, and also likely
to be used only by the plugin in the future.  Which basically means
that the plugin need not depend on any python client library at all.
I think this will simplify even further.  It should also be ok to be
tied to the plugin release cycles as well assuming that's the only
place the client is needed.

Cheers,
Ryu



>
> -- Sandro

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [midonet] Split up python-midonetclient

[Jaume Devesa]

+1

I think it is good compromise. Thanks Ryu!

I understand the CLI will belong to the external part. I much prefer to have
it in a separate project rather than into the plugin. Even if the code is
tiny.

If you will want to just do midonet calls for debugging or check the MidoNet
virtual infrastructure, it will be cleaner to install it without
dependencies than
dragging the whole neutron project (networking-midonet depends on neutron).

Regards,

On 14 December 2015 at 17:32, Ryu Ishimoto  wrote:

> On Tue, Dec 15, 2015 at 1:00 AM, Sandro Mathys 
> wrote:
> > On Tue, Dec 15, 2015 at 12:02 AM, Ryu Ishimoto  wrote:
> >
> > So if I understand you correctly, you suggest:
> > 1) the (midonet/internal) low level API stays where it is and will
> > still be called python-midonetclient.
> > 2) the (neutron/external) high level API is moved into it's own
> > project and will be called something like python-os-midonetclient.
> >
> > Sounds like a good compromise which addresses the most important
> > points, thanks Ryu! I wasn't aware that these parts of the
> > python-midonetclient are so clearly distinguishable/separable but if
> > so, this makes perfect sense. Not perfectly happy with the naming, but
> > I figure it's the way to go.
>
> Thanks for the endorsement.  Yes, it is trivial to separate them (less
> than a day of work) because they are pretty much already separated.
>
> As for the naming, I think it's better to take a non-disruptive
> approach so that it's transparent to those currently developing the
> low level midonet client.  To your question, however, I have another
> suggestion, which is that for the high level client code, it may also
> make sense to just include that as part of the plugin.  It's such
> small code that it might not make sense to separate, and also likely
> to be used only by the plugin in the future.  Which basically means
> that the plugin need not depend on any python client library at all.
> I think this will simplify even further.  It should also be ok to be
> tied to the plugin release cycles as well assuming that's the only
> place the client is needed.
>
> Cheers,
> Ryu
>
>
>
> >
> > -- Sandro
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Jaume Devesa
Software Engineer at Midokura
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [midonet] Split up python-midonetclient

[Sandro Mathys]

On Thu, Dec 10, 2015 at 4:46 PM, Galo Navarro  wrote:
>
>
> On 10 December 2015 at 04:35, Sandro Mathys  wrote:
>>
>> On Thu, Dec 10, 2015 at 12:48 AM, Galo Navarro  wrote:
>> > Hi,
>> >
>> >> I think the goal of this split is well explained by Sandro in the first
>> >> mails of the chain:
>> >>
>> >> 1. Downstream packaging
>> >> 2. Tagging the delivery properly as a library
>> >> 3. Adding as a project on pypi
>> >
>> > Not really, because (1) and (2) are *a consequence* of the repo split.
>> > Not a
>> > cause. Please correct me if I'm reading wrong but he's saying:
>> >
>> > - I want tarballs
>> > - To produce tarballs, I want a separate repo, and separate repos have
>> > (1),
>> > (2) as requirements.
>>
>> No, they're all goals, no consequences. Sorry, I didn't notice it
>> could be interpreted differently
>
>
> I beg to disagree. The location of code is not a goal in itself. Producing
> artifacts such as tarballs is.

Really not sure what you're trying to say. You're right, the location
of the code is not a goal in itself and I don't think anyone said
otherwise.

(1), (2) and (3), as well as Takashi's additional point if it applies
to us, all make separate repositories necessary. They're the goals,
and splitting repositories is a "consequence" (I'd rather call it a
requirement or necessity, but I'm not here to discuss the
terminology).

>> > This looks more accurate: you're actually not asking for a tarball.
>> > You're
>> > asking for being compatible with a system that produces tarballs off a
>> > repo.
>> > This is very different :)
>> >
>> > So questions: we have a standalone mirror of the repo, that could be
>> > used
>> > for this purpose. Say we move the mirror to OSt infra, would things
>> > work?
>>
>> Good point. Actually, no. The mirror can't go into OSt infra as they
>> don't allow direct pushes to repos - they need to go through reviews.
>> Of course, we could still have a mirror on GitHub in midonet/ but that
>> might cause us a lot of trouble.
>
>
> I don't follow. Where a repo is hosted is orthogonal to how commits are
> added. If commits to the mirror must go via gerrit, this is perfectly
> doable.

Are you serious? You called it cheap in the paragraph just below, and
now you want all python-midonetclient code to be reviewed twice?

>> > But create a lot of other problems in development. With a very important
>> > difference: the pain created by the mirror solution is solved cheaply
>> > with
>> > software (e.g.: as you know, with a script). OTOH, the pain created by
>> > splitting the repo is paid in very costly human resources.
>>
>> Adding the PMC as a submodule should reduce this costs significantly,
>> no? Of course, when working on the PMC, sometimes (or often, even)
>>
>> there will be the need for two instead of one review requests but the
>> content and discussion of those should be nearly identical, so the
>> actual overhead is fairly small. Figure I'm missing a few things here
>> - what other pains would this add?
>
>
> No, it doesn't make things easier. We already tried.
>
> Guillermo explained a few reasons already in his email.
>
>>
>> > I do get this point and it's a major concern, IMO we should split to a
>> > different conversation as it's not related to where PYC lives, but to a
>> > more
>> > general question: do we really need a repo per package?
>>
>> No, we don't. Not per package as you outlined them earlier: agent,
>> cluster, etc.
>>
>> Like Jaume, I know the RPM side much better than the DEB side. So for
>> RPM, one source package (srpm) can create several binary packages
>> (rpm). Therfore, one repo/tarball (there's an expected 1:1 relation
>> between these two) can be used for several packages.
>>
>> But there's different policies for services and clients, e.g. the
>> services are only packaged for servers but the clients both for
>> servers and workstations. Therefore, they are kept in separate srpms.
>>
>> Additionally, it's much easier to maintain java and python code in
>> separate srpms/rpms - mostly due to (build) dependencies.
>
>
> What's your rationale for saying this? Could you point at specific
> maintenance points that are made easier by having different languages in
> separate repos?

Again, it's about packaging, not repos. Packaging gets complicated
easily, and there's a lot of complex things to take care of with every
single language and having both in the same srpm doesn't make this
easier at all. Also, if Java and python code are kept in separate
srpms, only the specific srpm has to be rebuilt if e.g. a Java
vulnerability makes it necessary.

Honestly, I don't think this discussion is leading anywhere.
Therefore, I'd like to request a decision by the MidoNet PTL as per
[1].

-- Sandro

[1] http://governance.openstack.org/reference/charter.html#project-team-leads

__
OpenStack Development Mailing List (not for 

Re: [openstack-dev] [midonet] Split up python-midonetclient

[Antoni Segura Puimedon]

On Mon, Dec 14, 2015 at 6:07 PM, Jaume Devesa  wrote:

> +1
>
> I think it is good compromise. Thanks Ryu!
>
> I understand the CLI will belong to the external part. I much prefer to
> have
> it in a separate project rather than into the plugin. Even if the code is
> tiny.
>

Let me summarize it:

python-midonetclient: Low level API that lives and breathes in
midonet/midonet.
Has the current cli.
python-os-midonetclient: High level API that is in
openstack/python-midonetclient
 (can be packaged with a different
name).

Are you asking for python-os-midonetclient not to include the cli tool?

I would prefer to keep with the OpenStack practice [1] of having it
together. I don't
think developing a python cli client for the new python-os-midonetclient
that is
on par with the neutron cli tool would be that big of a task and I think it
would
make operation nicer. It could even find the midonet-api from the zookeeper
registry like the other tools do.

[1] https://github.com/openstack/python-neutronclient/blob/master/setup.cfg

>
> If you will want to just do midonet calls for debugging or check the
> MidoNet
> virtual infrastructure, it will be cleaner to install it without
> dependencies than
> dragging the whole neutron project (networking-midonet depends on neutron).
>
> Regards,
>
> On 14 December 2015 at 17:32, Ryu Ishimoto  wrote:
>
>> On Tue, Dec 15, 2015 at 1:00 AM, Sandro Mathys 
>> wrote:
>> > On Tue, Dec 15, 2015 at 12:02 AM, Ryu Ishimoto 
>> wrote:
>> >
>> > So if I understand you correctly, you suggest:
>> > 1) the (midonet/internal) low level API stays where it is and will
>> > still be called python-midonetclient.
>> > 2) the (neutron/external) high level API is moved into it's own
>> > project and will be called something like python-os-midonetclient.
>> >
>> > Sounds like a good compromise which addresses the most important
>> > points, thanks Ryu! I wasn't aware that these parts of the
>> > python-midonetclient are so clearly distinguishable/separable but if
>> > so, this makes perfect sense. Not perfectly happy with the naming, but
>> > I figure it's the way to go.
>>
>> Thanks for the endorsement.  Yes, it is trivial to separate them (less
>> than a day of work) because they are pretty much already separated.
>>
>> As for the naming, I think it's better to take a non-disruptive
>> approach so that it's transparent to those currently developing the
>> low level midonet client.  To your question, however, I have another
>> suggestion, which is that for the high level client code, it may also
>> make sense to just include that as part of the plugin.  It's such
>> small code that it might not make sense to separate, and also likely
>> to be used only by the plugin in the future.  Which basically means
>> that the plugin need not depend on any python client library at all.
>> I think this will simplify even further.  It should also be ok to be
>> tied to the plugin release cycles as well assuming that's the only
>> place the client is needed.
>>
>> Cheers,
>> Ryu
>>
>>
>>
>> >
>> > -- Sandro
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
>
> --
> Jaume Devesa
> Software Engineer at Midokura
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [midonet] Split up python-midonetclient

[Antoni Segura Puimedon]

On Tue, Dec 8, 2015 at 1:58 PM, Galo Navarro  wrote:

> Hi Sandro,
>
> >> 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.
>
> This is actually not accurate: there is no such thing as a midonet
> package. The midonet repo produces 4 or 5 separate packages: agent,
> cluster, tools, py client.
>
> I'd like to understand a bit better what exactly you're trying to
> achieve. Is it to produce tarballs? All of them? Just
> python-midonetclient?
>
> Let's examine the concrete requirements before rushing headlong into
> highly disruptive changes like splitting repos. For example, a
> py-midonetclient tarball can be built already without having a
> separate repo.
>
> > 3) In order to put python-midonetclient on PyPI, it's probably
> > required to be in its own repo as well, isn't it? Because that's
> > another requirement [3]
>
> Ditto. We already have a mirror repo of pyc for this purpose
> https://github.com/midonet/python-midonetclient, synced daily.
>

Some of the problems with that is that it does not have any git log history
nor does it feel like a coding project at all.

Allow me to put forward a solution that will allow you keep the development
in the midonet tree while, at the same time, having a proper repository
with identifiable patches in github.com/midonet/python-midonetclient

Look at the repo I created [1] and specially at its commit history [2]

As you can see, it has all the commit history relevant for the
midonet/python-midonetclient (and only that one) is present.

This is generated in the following way. There should be job that does once
in the
midonet repo:

git format-patch -o "${HOME}/patches_current
--relative=python-midonetclient \
7aef7ea7845a2125696303a277d40bd45c9240e2..master

Then, each day it should do:

cd ${JOB_HOME}
git clone https://github.com/celebdor/python-midonetclient.git
git clone https://github.com/midonet/midonet.git

pushd midonet
git format-patch -o "${JOB_HOME}/patches_new"
--relative=python-midonetclient \
7aef7ea7845a2125696303a277d40bd45c9240e2..master
popd
pushd python-midonetclient

for file in `diff <(ls -1a "${HOME}/patches_current") <(ls -1a
"${JOB_HOME}/patches_new") | cut -f2 -d' '`
do
git am < "${JOB_HOME}/patches_new/$file"
done

popd
mv patches_new "${HOME}/patches_current"

It should be quite straightforward to change whichever job you currently
use to
this.

The last remaining issue will be that of tags. github.com/midonet/midonet
is not
tagging all the releases. However, python-midonetclient should, so I would
just
ask that when you make a release you push the tag to python-midonetclient
as well.

[1] https://github.com/celebdor/python-midonetclient/
[2] https://github.com/celebdor/python-midonetclient/commits/master


Regards,

Toni


> g
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [midonet] Split up python-midonetclient

[Jaume Devesa]

Hi Galo,

I think the goal of this split is well explained by Sandro in the first
mails of the chain:

1. Downstream packaging
2. Tagging the delivery properly as a library
3. Adding as a project on pypi

​OpenStack provide us a tarballs web page[1] for each branch of each
project of the infrastructure.
Then, projects like Delorean can allow us to download theses tarball master
branches, create the
packages and host them in a target repository for each one of the rpm-like
distributions[2]. I am pretty sure
that there is something similar for Ubuntu.

Everything is done in a very straightforward and standarized way, because
every repo has its own
deliverable. You can look how they are packaged and you won't see too many
differences between
them. Packaging a python-midonetclient it will be trivial if it is
separated in a single repo. It will be
complicated and we'll have to do tricky things if it is a directory inside
the midonet repo. And I am not
sure if Ubuntu and RDO community will allow us to have weird packaging
metadata repos.

So to me the main reason is

4. Leverage all the infrastructure and procedures that OpenStack offers to
integrate MidoNet
as best as possible with the release process and delivery.


Regards,

[1]: ​http://tarballs.openstack.org/
[2]: http://trunk.rdoproject.org

On 9 December 2015 at 15:52, Antoni Segura Puimedon <t...@midokura.com>
wrote:

>
> -- Forwarded message --
> From: Galo Navarro <g...@midokura.com>
> Date: Wed, Dec 9, 2015 at 2:48 PM
> Subject: Re: [openstack-dev] [midonet] Split up python-midonetclient
> To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> Cc: Jaume Devesa <ja...@midokura.com>
>
>
> >> Ditto. We already have a mirror repo of pyc for this purpose
> >> https://github.com/midonet/python-midonetclient, synced daily.
> >
> > Some of the problems with that is that it does not have any git log
> history
> > nor does it feel like a coding project at all.
>
> Of course, because the goal of this repo is not to provide a
> changelog. It's to provide an independent repo. If you want git log,
> you should do a git log python-midonetclient in the source repo
> (/midonet/midonet).
>
> > Allow me to put forward a solution that will allow you keep the
> development
> > in the midonet tree while, at the same time, having a proper repository
> > with identifiable patches in github.com/midonet/python-midonetclient
>
> Thanks, but I insist: can we please clarify *what* are we trying to
> achieve, before we jump into solutions?
>
> g
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Jaume Devesa
Software Engineer at Midokura
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [midonet] Split up python-midonetclient

[Antoni Segura Puimedon]

On Wed, Dec 9, 2015 at 2:41 PM, Antoni Segura Puimedon <
toni+openstac...@midokura.com> wrote:

>
>
> On Tue, Dec 8, 2015 at 1:58 PM, Galo Navarro  wrote:
>
>> Hi Sandro,
>>
>> >> 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.
>>
>> This is actually not accurate: there is no such thing as a midonet
>> package. The midonet repo produces 4 or 5 separate packages: agent,
>> cluster, tools, py client.
>>
>> I'd like to understand a bit better what exactly you're trying to
>> achieve. Is it to produce tarballs? All of them? Just
>> python-midonetclient?
>>
>> Let's examine the concrete requirements before rushing headlong into
>> highly disruptive changes like splitting repos. For example, a
>> py-midonetclient tarball can be built already without having a
>> separate repo.
>>
>> > 3) In order to put python-midonetclient on PyPI, it's probably
>> > required to be in its own repo as well, isn't it? Because that's
>> > another requirement [3]
>>
>> Ditto. We already have a mirror repo of pyc for this purpose
>> https://github.com/midonet/python-midonetclient, synced daily.
>>
>
> Some of the problems with that is that it does not have any git log history
> nor does it feel like a coding project at all.
>
> Allow me to put forward a solution that will allow you keep the development
> in the midonet tree while, at the same time, having a proper repository
> with identifiable patches in github.com/midonet/python-midonetclient
>
> Look at the repo I created [1] and specially at its commit history [2]
>
> As you can see, it has all the commit history relevant for the
> midonet/python-midonetclient (and only that one) is present.
>
> This is generated in the following way. There should be job that does once
> in the
> midonet repo:
>
> git format-patch -o "${HOME}/patches_current
> --relative=python-midonetclient \
> 7aef7ea7845a2125696303a277d40bd45c9240e2..master
>
> Then, each day it should do:
>
> cd ${JOB_HOME}
> git clone https://github.com/celebdor/python-midonetclient.git
> git clone https://github.com/midonet/midonet.git
>
> pushd midonet
> git format-patch -o "${JOB_HOME}/patches_new"
> --relative=python-midonetclient \
> 7aef7ea7845a2125696303a277d40bd45c9240e2..master
> popd
> pushd python-midonetclient
>
> for file in `diff <(ls -1a "${HOME}/patches_current") <(ls -1a
> "${JOB_HOME}/patches_new") | cut -f2 -d' '`
> do
> git am < "${JOB_HOME}/patches_new/$file"
> done
>

Obviously at this point it should do a "git push" :P


> popd
> mv patches_new "${HOME}/patches_current"
>
> It should be quite straightforward to change whichever job you currently
> use to
> this.
>
> The last remaining issue will be that of tags. github.com/midonet/midonet
> is not
> tagging all the releases. However, python-midonetclient should, so I would
> just
> ask that when you make a release you push the tag to python-midonetclient
> as well.
>
> [1] https://github.com/celebdor/python-midonetclient/
> [2] https://github.com/celebdor/python-midonetclient/commits/master
>
>
> Regards,
>
> Toni
>
>
>> g
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [midonet] Split up python-midonetclient

[Galo Navarro]

>> Ditto. We already have a mirror repo of pyc for this purpose
>> https://github.com/midonet/python-midonetclient, synced daily.
>
> Some of the problems with that is that it does not have any git log history
> nor does it feel like a coding project at all.

Of course, because the goal of this repo is not to provide a
changelog. It's to provide an independent repo. If you want git log,
you should do a git log python-midonetclient in the source repo
(/midonet/midonet).

> Allow me to put forward a solution that will allow you keep the development
> in the midonet tree while, at the same time, having a proper repository
> with identifiable patches in github.com/midonet/python-midonetclient

Thanks, but I insist: can we please clarify *what* are we trying to
achieve, before we jump into solutions?

g

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [midonet] Split up python-midonetclient

[Galo Navarro]

Hi,

> I think the goal of this split is well explained by Sandro in the first
> mails of the chain:
>
> 1. Downstream packaging
> 2. Tagging the delivery properly as a library
> 3. Adding as a project on pypi

Not really, because (1) and (2) are *a consequence* of the repo split. Not
a cause. Please correct me if I'm reading wrong but he's saying:

- I want tarballs
- To produce tarballs, I want a separate repo, and separate repos have (1),
(2) as requirements.

So this is where I'm going: producing a tarball of pyc does *not* require a
separate repo. If we don't need a new repo, we don't need to do all the
things that a separate repo requires.

Now:

> OpenStack provide us a tarballs web page[1] for each branch of each
project
> of the infrastructure.
> Then, projects like Delorean can allow us to download theses tarball
master
> branches, create the
> packages and host them in a target repository for each one of the rpm-like
> distributions[2]. I am pretty sure
> that there is something similar for Ubuntu.

This looks more accurate: you're actually not asking for a tarball. You're
asking for being compatible with a system that produces tarballs off a
repo. This is very different :)

So questions: we have a standalone mirror of the repo, that could be used
for this purpose. Say we move the mirror to OSt infra, would things work?

> Everything is done in a very straightforward and standarized way, because
> every repo has its own
> deliverable. You can look how they are packaged and you won't see too many
> differences between
> them. Packaging a python-midonetclient it will be trivial if it is
separated
> in a single repo. It will be

But create a lot of other problems in development. With a very important
difference: the pain created by the mirror solution is solved cheaply with
software (e.g.: as you know, with a script). OTOH, the pain created by
splitting the repo is paid in very costly human resources.

> complicated and we'll have to do tricky things if it is a directory inside
> the midonet repo. And I am not
> sure if Ubuntu and RDO community will allow us to have weird packaging
> metadata repos.

I do get this point and it's a major concern, IMO we should split to a
different conversation as it's not related to where PYC lives, but to a
more general question: do we really need a repo per package?

Like Guillermo and myself said before, the midonet repo generate 4
packages, and this will grow. If having a package per repo is really a
strong requirement, there is *a lot* of work ahead, so we need to start
talking about this now. But like I said, it's orthogonal to the PYC points
above.

g
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [midonet] Split up python-midonetclient

[Sandro Mathys]

On Thu, Dec 10, 2015 at 12:48 AM, Galo Navarro  wrote:
> Hi,
>
>> I think the goal of this split is well explained by Sandro in the first
>> mails of the chain:
>>
>> 1. Downstream packaging
>> 2. Tagging the delivery properly as a library
>> 3. Adding as a project on pypi
>
> Not really, because (1) and (2) are *a consequence* of the repo split. Not a
> cause. Please correct me if I'm reading wrong but he's saying:
>
> - I want tarballs
> - To produce tarballs, I want a separate repo, and separate repos have (1),
> (2) as requirements.

No, they're all goals, no consequences. Sorry, I didn't notice it
could be interpreted differently

> So this is where I'm going: producing a tarball of pyc does *not* require a
> separate repo. If we don't need a new repo, we don't need to do all the
> things that a separate repo requires.
>
> Now:
>
>> OpenStack provide us a tarballs web page[1] for each branch of each
>> project
>> of the infrastructure.
>> Then, projects like Delorean can allow us to download theses tarball
>> master
>> branches, create the
>> packages and host them in a target repository for each one of the rpm-like
>> distributions[2]. I am pretty sure
>> that there is something similar for Ubuntu.
>
> This looks more accurate: you're actually not asking for a tarball. You're
> asking for being compatible with a system that produces tarballs off a repo.
> This is very different :)
>
> So questions: we have a standalone mirror of the repo, that could be used
> for this purpose. Say we move the mirror to OSt infra, would things work?

Good point. Actually, no. The mirror can't go into OSt infra as they
don't allow direct pushes to repos - they need to go through reviews.
Of course, we could still have a mirror on GitHub in midonet/ but that
might cause us a lot of trouble.

>> Everything is done in a very straightforward and standarized way, because
>> every repo has its own
>> deliverable. You can look how they are packaged and you won't see too many
>> differences between
>> them. Packaging a python-midonetclient it will be trivial if it is
>> separated
>> in a single repo. It will be
>
> But create a lot of other problems in development. With a very important
> difference: the pain created by the mirror solution is solved cheaply with
> software (e.g.: as you know, with a script). OTOH, the pain created by
> splitting the repo is paid in very costly human resources.

Adding the PMC as a submodule should reduce this costs significantly,
no? Of course, when working on the PMC, sometimes (or often, even)
there will be the need for two instead of one review requests but the
content and discussion of those should be nearly identical, so the
actual overhead is fairly small. Figure I'm missing a few things here
- what other pains would this add?

>> complicated and we'll have to do tricky things if it is a directory inside
>> the midonet repo. And I am not
>> sure if Ubuntu and RDO community will allow us to have weird packaging
>> metadata repos.
>
> I do get this point and it's a major concern, IMO we should split to a
> different conversation as it's not related to where PYC lives, but to a more
> general question: do we really need a repo per package?

No, we don't. Not per package as you outlined them earlier: agent, cluster, etc.

Like Jaume, I know the RPM side much better than the DEB side. So for
RPM, one source package (srpm) can create several binary packages
(rpm). Therfore, one repo/tarball (there's an expected 1:1 relation
between these two) can be used for several packages.

But there's different policies for services and clients, e.g. the
services are only packaged for servers but the clients both for
servers and workstations. Therefore, they are kept in separate srpms.

Additionally, it's much easier to maintain java and python code in
separate srpms/rpms - mostly due to (build) dependencies.

> Like Guillermo and myself said before, the midonet repo generate 4 packages,
> and this will grow. If having a package per repo is really a strong
> requirement, there is *a lot* of work ahead, so we need to start talking
> about this now. But like I said, it's orthogonal to the PYC points above.

It really shouldn't be necessary to split up agent, cluster, etc.
Unless maybe if they are _very_ loosely coupled and there's a case
where it makes _a lot_ of sense to operate different versions of each
component together over an extended period of time (e.g. not just to
upgrade one at a time), I guess. Added some emphasis to that sentence,
because just the possibility won't justify this - there must be a real
use case.

-- Sandro

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [midonet] Split up python-midonetclient

[Takashi Yamamoto]

On Thu, Dec 10, 2015 at 12:48 AM, Galo Navarro  wrote:
> Hi,
>
>> I think the goal of this split is well explained by Sandro in the first
>> mails of the chain:
>>
>> 1. Downstream packaging
>> 2. Tagging the delivery properly as a library
>> 3. Adding as a project on pypi
>
> Not really, because (1) and (2) are *a consequence* of the repo split. Not a
> cause. Please correct me if I'm reading wrong but he's saying:
>
> - I want tarballs
> - To produce tarballs, I want a separate repo, and separate repos have (1),
> (2) as requirements.
>
> So this is where I'm going: producing a tarball of pyc does *not* require a
> separate repo. If we don't need a new repo, we don't need to do all the
> things that a separate repo requires.

in openstack, client libraries usually have a separate release schedules
from servers.  see "Final release for client libraries" in
http://docs.openstack.org/releases/schedules/mitaka.html .
in case we want to align to it, a single all-in-one repository doesn't sound
viable to me.

>
> Now:
>
>> OpenStack provide us a tarballs web page[1] for each branch of each
>> project
>> of the infrastructure.
>> Then, projects like Delorean can allow us to download theses tarball
>> master
>> branches, create the
>> packages and host them in a target repository for each one of the rpm-like
>> distributions[2]. I am pretty sure
>> that there is something similar for Ubuntu.
>
> This looks more accurate: you're actually not asking for a tarball. You're
> asking for being compatible with a system that produces tarballs off a repo.
> This is very different :)
>
> So questions: we have a standalone mirror of the repo, that could be used
> for this purpose. Say we move the mirror to OSt infra, would things work?
>
>> Everything is done in a very straightforward and standarized way, because
>> every repo has its own
>> deliverable. You can look how they are packaged and you won't see too many
>> differences between
>> them. Packaging a python-midonetclient it will be trivial if it is
>> separated
>> in a single repo. It will be
>
> But create a lot of other problems in development. With a very important
> difference: the pain created by the mirror solution is solved cheaply with
> software (e.g.: as you know, with a script). OTOH, the pain created by
> splitting the repo is paid in very costly human resources.
>
>> complicated and we'll have to do tricky things if it is a directory inside
>> the midonet repo. And I am not
>> sure if Ubuntu and RDO community will allow us to have weird packaging
>> metadata repos.
>
> I do get this point and it's a major concern, IMO we should split to a
> different conversation as it's not related to where PYC lives, but to a more
> general question: do we really need a repo per package?
>
> Like Guillermo and myself said before, the midonet repo generate 4 packages,
> and this will grow. If having a package per repo is really a strong
> requirement, there is *a lot* of work ahead, so we need to start talking
> about this now. But like I said, it's orthogonal to the PYC points above.
>
> g
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [midonet] Split up python-midonetclient

[Takashi Yamamoto]

On Tue, Dec 8, 2015 at 9:54 PM, Guillermo Ontañón
 wrote:
> Hi Sandro,
>
> On Tue, Dec 8, 2015 at 7:31 AM, Sandro Mathys  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-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [midonet] Split up python-midonetclient

[Galo Navarro]

On 10 December 2015 at 04:35, Sandro Mathys  wrote:

> On Thu, Dec 10, 2015 at 12:48 AM, Galo Navarro  wrote:
> > Hi,
> >
> >> I think the goal of this split is well explained by Sandro in the first
> >> mails of the chain:
> >>
> >> 1. Downstream packaging
> >> 2. Tagging the delivery properly as a library
> >> 3. Adding as a project on pypi
> >
> > Not really, because (1) and (2) are *a consequence* of the repo split.
> Not a
> > cause. Please correct me if I'm reading wrong but he's saying:
> >
> > - I want tarballs
> > - To produce tarballs, I want a separate repo, and separate repos have
> (1),
> > (2) as requirements.
>
> No, they're all goals, no consequences. Sorry, I didn't notice it
> could be interpreted differently
>

I beg to disagree. The location of code is not a goal in itself. Producing
artifacts such as tarballs is.



> > This looks more accurate: you're actually not asking for a tarball.
> You're
> > asking for being compatible with a system that produces tarballs off a
> repo.
> > This is very different :)
> >
> > So questions: we have a standalone mirror of the repo, that could be used
> > for this purpose. Say we move the mirror to OSt infra, would things work?
>
> Good point. Actually, no. The mirror can't go into OSt infra as they
> don't allow direct pushes to repos - they need to go through reviews.
> Of course, we could still have a mirror on GitHub in midonet/ but that
> might cause us a lot of trouble.
>

I don't follow. Where a repo is hosted is orthogonal to how commits are
added. If commits to the mirror must go via gerrit, this is perfectly
doable.


> > But create a lot of other problems in development. With a very important
> > difference: the pain created by the mirror solution is solved cheaply
> with
> > software (e.g.: as you know, with a script). OTOH, the pain created by
> > splitting the repo is paid in very costly human resources.
>
> Adding the PMC as a submodule should reduce this costs significantly,
> no? Of course, when working on the PMC, sometimes (or often, even)
>
there will be the need for two instead of one review requests but the
> content and discussion of those should be nearly identical, so the
> actual overhead is fairly small. Figure I'm missing a few things here
> - what other pains would this add?
>

No, it doesn't make things easier. We already tried.

Guillermo explained a few reasons already in his email.


> > I do get this point and it's a major concern, IMO we should split to a
> > different conversation as it's not related to where PYC lives, but to a
> more
> > general question: do we really need a repo per package?
>
> No, we don't. Not per package as you outlined them earlier: agent,
> cluster, etc.
>
> Like Jaume, I know the RPM side much better than the DEB side. So for
> RPM, one source package (srpm) can create several binary packages
> (rpm). Therfore, one repo/tarball (there's an expected 1:1 relation
> between these two) can be used for several packages.
>
> But there's different policies for services and clients, e.g. the
> services are only packaged for servers but the clients both for
> servers and workstations. Therefore, they are kept in separate srpms.
>
> Additionally, it's much easier to maintain java and python code in
> separate srpms/rpms - mostly due to (build) dependencies.
>

What's your rationale for saying this? Could you point at specific
maintenance points that are made easier by having different languages in
separate repos?

g
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [midonet] Split up python-midonetclient

[Sandro Mathys]

On Tue, Dec 8, 2015 at 3:31 PM, Sandro Mathys  wrote:
> Hi,
>
> As Takashi Yamamoto raised in another thread [0], python-midonetclient
> should be split out into its own repo. 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.
>
> 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.
>

3) In order to put python-midonetclient on PyPI, it's probably
required to be in its own repo as well, isn't it? Because that's
another requirement [3]

> 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
[3] 
http://docs.openstack.org/infra/manual/creators.html#give-openstack-permission-to-publish-releases

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [midonet] Split up python-midonetclient

[Guillermo Ontañón]

Hi Sandro,

On Tue, Dec 8, 2015 at 7:31 AM, Sandro Mathys  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/
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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [midonet] Split up python-midonetclient

[Galo Navarro]

Hi Sandro,

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

This is actually not accurate: there is no such thing as a midonet
package. The midonet repo produces 4 or 5 separate packages: agent,
cluster, tools, py client.

I'd like to understand a bit better what exactly you're trying to
achieve. Is it to produce tarballs? All of them? Just
python-midonetclient?

Let's examine the concrete requirements before rushing headlong into
highly disruptive changes like splitting repos. For example, a
py-midonetclient tarball can be built already without having a
separate repo.

> 3) In order to put python-midonetclient on PyPI, it's probably
> required to be in its own repo as well, isn't it? Because that's
> another requirement [3]

Ditto. We already have a mirror repo of pyc for this purpose
https://github.com/midonet/python-midonetclient, synced daily.

g

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev