Re: [openstack-dev] [MidoNet] Fwd: [MidoNet-Dev] Sync virtual topology data from neutron DB to Zookeeper?

[Galo Navarro]

Hi Li,

Sorry for the late reply. Unrelated point: please note that we've
moved the mailing lists to Openstack infra
(openstack-dev@lists.openstack.org  - I'm ccing the list here).

At the moment we don't support syncing the full Neutron DB, there has
been work done for this that would allow this use case, but it's still
not complete or released.

@Ryu may be able to provide recommendations to do this following a
manual process.

Cheers,
g



On 4 December 2015 at 09:27, Li Ma  wrote:
> Hi midoers,
>
> I have an OpenStack cloud with neutron ML2+OVS. I'd like to switch
> from OVS to MidoNet in that cloud.
>
> Actually the neutron DB stores all the existing virtual topology. I
> wonder if there's some guides or ops tools for MidoNet to sync data
> from the neutron DB to Zookeeper.
>
> Thanks a lot,
> --
>
> Li Ma (Nick)
> Email: skywalker.n...@gmail.com
> ___
> MidoNet mailing list
> mido...@lists.midonet.org
> http://lists.midonet.org/listinfo/midonet

__
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

[Galo Navarro]

On 10 December 2015 at 04:35, Sandro Mathys <san...@midokura.com> wrote:

> On Thu, Dec 10, 2015 at 12:48 AM, Galo Navarro <g...@midokura.com> 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

[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