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

[Sandro Mathys]

On Tue, Dec 15, 2015 at 12:02 AM, Ryu Ishimoto <r...@midokura.com> wrote:
> On Mon, Dec 14, 2015 at 6:34 PM, Sandro Mathys <san...@midokura.com> wrote:
>> On Thu, Dec 10, 2015 at 4:46 PM, Galo Navarro <g...@midokura.com> 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

[Sandro Mathys]

On Thu, Dec 10, 2015 at 4:46 PM, Galo Navarro <g...@midokura.com> wrote:
>
>
> 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.

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 compl

[openstack-dev] [midonet] #midonet now our official channel; OpenStack service bots added

[Sandro Mathys]

As discussed [1] and announced [2], #midonet is now the official
MidoNet development channel.

We've now also got the three OpenStack service bots approved:

1) meetbot (nickname: openstack), in order to have a properly logged
meetings in #midonet. Note that our regular meetings are scheduled to
happen in #openstack-meeting - but in case an irregular / impromptu
meeting is required, this should prove useful.

When starting a meeting, make sure to use either "midonet" or
"networking_midonet" (mind the underscore) as the meeting name. The
logs can then be found at [3] or [4] respectively.

Furthermore, the channel is also constantly being logged to [5].

2) gerritbot (nickname: openstackgerrit), in order to get gerrit
notifications. Unfortunately, only OpenStack gerrit is supported,
meaning that we currently get notifications for networking-midonet
only.

3) statusbot (nickname: openstackstatus), in order to receive
notification from OpenStack infra. They send out status notifications,
e.g. Gerrit is restarted or there's a problem with the gate. See [6]
for past notifications to understand better how they use it.

Furthermore, the "#success " command has recently been added
and can be used by everyone. It's meant to collect small successes in
OpenStack development, and they're collected on a wiki page [7]. I
think "highlights" are also cherry-picked for the OpenStack
newsletter. Figure it would be great to use when reaching development
milestones or publishing new releases, as well as any other success.

Let me know if you have any questions regarding our IRC channel or any
of these bots.

Cheers,
Sandro

[1] http://lists.openstack.org/pipermail/openstack-dev/2015-December/080914.html
[2] http://lists.openstack.org/pipermail/openstack-dev/2015-December/081376.html
[3] http://eavesdrop.openstack.org/meetings/midonet/
[4] http://eavesdrop.openstack.org/meetings/networking_midonet/
[5] http://eavesdrop.openstack.org/irclogs/#midonet/
[6] https://wiki.openstack.org/wiki/Infrastructure_Status
[7] https://wiki.openstack.org/wiki/Successes

__
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

[Sandro Mathys]

On Tue, Dec 8, 2015 at 3:31 PM, Sandro Mathys <san...@midokura.com> 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

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

[Sandro Mathys]

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.

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

Re: [openstack-dev] [midonet] IRC: ditch #midonet-dev?

[Sandro Mathys]

On Wed, Dec 2, 2015 at 5:55 PM, Jan Hilberath <j...@midokura.com> wrote:
> On 2015年12月01日 19:14, Takashi Yamamoto wrote:
>>
>> On Tue, Dec 1, 2015 at 7:08 PM, Antoni Segura Puimedon
>> <toni+openstac...@midokura.com> wrote:
>>>
>>>
>>>
>>> On Tue, Dec 1, 2015 at 10:59 AM, Ivan Kelly <i...@midokura.com> wrote:
>>>>
>>>>
>>>> +1 for #2
>>>
>>>
>>>
>>> PS: Beware of the top-posting! It makes vote counting harder ;-)
>>>
>>>>
>>>>
>>>> On Tue, Dec 1, 2015 at 10:57 AM, Sandro Mathys <san...@midokura.com>
>>>> wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> Our IRC channels have been neglected for a long time, and as a result
>>>>> we lost ownership of #midonet-dev, which is now owner by
>>>>> freenode-staff. In theory, it should be very easy to get ownership
>>>>> back, particularly since we still own #midonet. But in reality, it
>>>>> seems like none of the freenode staff feel responsible for these
>>>>> requests, so we still aren't owners after requesting it for 3 weeks
>>>>> already.
>>>>>
>>>>> Therefore, Toni Segura suggested we just ditch it and move to
>>>>> #openstack-midonet instead.
>>>>>
>>>>> However, several people have also said we don't need two channels,
>>>>> i.e. we should merge #midonet and #midonet-dev.
>>>>>
>>>>> So, here's three proposals:
>>>>>
>>>>> Proposal #1:
>>>>> * keep #midonet
>>>>> * replace #midonet-dev with #openstack-midonet
>>>>>
>>>>> Proposal #2:
>>>>> * keep #midonet
>>>>> * merge #midonet-dev into #midonet
>>>
>>>
>>>
>>> +1
>>
>>
>> +1
>
>
> +1

Alright, we'll go with #midonet then. I've now configured #midonet-dev
so, that anyone who tries to join it is instead forwarded to #midonet.
I've also set up the same for #openstack-midonet, just in case someone
is looking for us there.

I've also archived all developers' channels on Slack with a note that
we moved to IRC.

Cheers,
Sandro

>>
>>>
>>>>
>>>>>
>>>>> Proposal #3:
>>>>> * replace both #midonet and #midonet-dev with #openstack-midonet
>>>>>
>>>>> I don't have any strong feelings for any of the proposals, but suggest
>>>>> we go with proposal #2. Traffic in both #midonet and #midonet-dev is
>>>>> rather low, so one channel should do - there's way busier OpenStack
>>>>> channels out there. Furthermore, #midonet is shorter than
>>>>> #openstack-midonet and already established. I also think people will
>>>>> rather look in #midonet than #openstack-midonet if they're looking for
>>>>> us.
>>>>>
>>>>> Thoughts?
>>>>>
>>>>> Cheers,
>>>>> 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
>>>>
>>>>
>>>>
>>>> __
>>>> 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
>>
>
> __
> 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] What repos to migrate to OpenStack infrastructure

[Sandro Mathys]

On Wed, Dec 2, 2015 at 4:05 PM, Sandro Mathys <san...@midokura.com> wrote:
> Hi all,
>
> Trying to prepare moving our repos to the OpenStack infrastructure, I
> got reminded just how many repos we have in our GitHub organization
> [1] - and how many of those seem to be deprecated or tangential.
>
> Now, do we still want to migrate them? Pretty sure the answer is "no"
> for the deprecated ones but I wonder about the tangential ones. Well,
> to be honest, I also wonder which are actually deprecated/tangential
> and which are considered "important".
>
> First of all, I think repos that are not set up on GerritHub, don't
> need to be migrated. Partially because they don't seem important
> enough, and partially because migration would force Gerrit upon them
> (i.e. Gerrit is the main repo for a project in OpenStack, the others
> are just mirrors). But the list of midonet repos on GerritHub [2] is
> still very long.
>
> Of those, I figure these are deprecated and shouldn't be migrated:
> * arrakis
> * midostack
>
> Also, I'm only looking at what repos to migrate under the "midonet"
> umbrella. These repos should probably be migrated under a different
> umbrella, if at all:
> * ansible-* (-> ansible-openstack)
> * puppet-* (-> puppet-openstack)
> * zephyr (-> zephyr)
>
> Furthermore, these seem to be forks that should (no longer) see
> downstream commits, right?
> * python-midonetclient
> * python-neutronclient
>
> Last but not least, we have repos that have only a single contributor
> and should probably not be part of the midonet organization anyway -
> and repos with (virtually) no commits:
> * bees
> * docker-openvpn-client
> * docker-zk-web
> * orizuru
> * toscana
> * ubuntu-integration

Looks like ubuntu-integration is an empty repo, so no need to migrate anyway.

> Alright, this leaves us with 11 repos - much better number!
>
> These, I think we should migrate:
> * mdts

This one actually only exists on GerritHub but not GitHub (anymore?),
so we don't need to migrate it.

> * midonet
> * midonet-docs
> * midonet-sandbox
>
> These, we could migrate but they are low priority and might actually
> go away so let's defer:
> * midonethomepage
> * planet-midonet
>
> However, I have no idea about these - are they still needed? Do they
> belong under the midonet umbrella?
> * jmx_exporter
> * midonet-charms

Same as with mdts.

> * midonet-dockerfile
> * tempest-add
> * zktimemachine
>
> Please share your thoughts - did I exclude some that should be
> included in the migration? Should some be included that are not
> currently configured on GerritHub? And what about those 5 repos in the
> last list?
>
> Note, that all repos we want to migrate under the midonet umbrella
> probably need to have a "midonet-" in front, so it would need to be
> added to those who don't have it. (Well, planet-midonet will become
> midonet-planet and midonethomepage gain a dash).
>
> Thanks,
> Sandro
>
> PS. the "when" and "how" will be discussed later - let's focus on the
> "what" in this thread, please.
>
> [1] https://github.com/midonet
> [2] https://review.gerrithub.io/#/admin/projects/?filter=midonet%252F

__
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] [neutron][midonet] networking-midonet weekly irc meeting

[Sandro Mathys]

On Thu, Dec 3, 2015 at 7:25 PM, Thierry Carrez <thie...@openstack.org> wrote:
> Sandro Mathys wrote:
>> On Thu, Dec 3, 2015 at 1:07 PM, Takashi Yamamoto <yamam...@midokura.com> 
>> wrote:
>>> On Mon, Nov 30, 2015 at 12:52 PM, Takashi Yamamoto
>>> <yamam...@midokura.com> wrote:
>>>> hi,
>>>>
>>>> we are going to migrate networking-midonet meeting from slack to irc.
>>>> the plan is to have it 7:00 UTC on every Tuesdays.
>>>> if you are interested but have a different time preference,
>>>> please speak up.
>>>> thank you.
>>>
>>> it will be held from the next week.
>>> http://eavesdrop.openstack.org/#Networking_Midonet_meeting
>>
>> I imported the ICS file, but the only event in it is a "Neutron
>> Distributed Virtual Router Meeting"...?
>
> You must have clicked the wrong one. I just downloaded:
> http://eavesdrop.openstack.org/calendars/networking-midonet.ics
> http://eavesdrop.openstack.org/irc-meetings.ical
>
> and Midonet's meeting appears in both.

Right, seems I did...twice.

Thanks,
Sandro

> Cheers,
>
> --
> Thierry Carrez (ttx)
>
> __
> 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] [neutron][midonet] networking-midonet weekly irc meeting

[Sandro Mathys]

On Thu, Dec 3, 2015 at 1:07 PM, Takashi Yamamoto  wrote:
> On Mon, Nov 30, 2015 at 12:52 PM, Takashi Yamamoto
>  wrote:
>> hi,
>>
>> we are going to migrate networking-midonet meeting from slack to irc.
>> the plan is to have it 7:00 UTC on every Tuesdays.
>> if you are interested but have a different time preference,
>> please speak up.
>> thank you.
>
> it will be held from the next week.
> http://eavesdrop.openstack.org/#Networking_Midonet_meeting

I imported the ICS file, but the only event in it is a "Neutron
Distributed Virtual Router Meeting"...?

__
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-dev] [midonet] What repos to migrate to OpenStack infrastructure

[Sandro Mathys]

Hi all,

Trying to prepare moving our repos to the OpenStack infrastructure, I
got reminded just how many repos we have in our GitHub organization
[1] - and how many of those seem to be deprecated or tangential.

Now, do we still want to migrate them? Pretty sure the answer is "no"
for the deprecated ones but I wonder about the tangential ones. Well,
to be honest, I also wonder which are actually deprecated/tangential
and which are considered "important".

First of all, I think repos that are not set up on GerritHub, don't
need to be migrated. Partially because they don't seem important
enough, and partially because migration would force Gerrit upon them
(i.e. Gerrit is the main repo for a project in OpenStack, the others
are just mirrors). But the list of midonet repos on GerritHub [2] is
still very long.

Of those, I figure these are deprecated and shouldn't be migrated:
* arrakis
* midostack

Also, I'm only looking at what repos to migrate under the "midonet"
umbrella. These repos should probably be migrated under a different
umbrella, if at all:
* ansible-* (-> ansible-openstack)
* puppet-* (-> puppet-openstack)
* zephyr (-> zephyr)

Furthermore, these seem to be forks that should (no longer) see
downstream commits, right?
* python-midonetclient
* python-neutronclient

Last but not least, we have repos that have only a single contributor
and should probably not be part of the midonet organization anyway -
and repos with (virtually) no commits:
* bees
* docker-openvpn-client
* docker-zk-web
* orizuru
* toscana
* ubuntu-integration

Alright, this leaves us with 11 repos - much better number!

These, I think we should migrate:
* mdts
* midonet
* midonet-docs
* midonet-sandbox

These, we could migrate but they are low priority and might actually
go away so let's defer:
* midonethomepage
* planet-midonet

However, I have no idea about these - are they still needed? Do they
belong under the midonet umbrella?
* jmx_exporter
* midonet-charms
* midonet-dockerfile
* tempest-add
* zktimemachine

Please share your thoughts - did I exclude some that should be
included in the migration? Should some be included that are not
currently configured on GerritHub? And what about those 5 repos in the
last list?

Note, that all repos we want to migrate under the midonet umbrella
probably need to have a "midonet-" in front, so it would need to be
added to those who don't have it. (Well, planet-midonet will become
midonet-planet and midonethomepage gain a dash).

Thanks,
Sandro

PS. the "when" and "how" will be discussed later - let's focus on the
"what" in this thread, please.

[1] https://github.com/midonet
[2] https://review.gerrithub.io/#/admin/projects/?filter=midonet%252F

__
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-dev] [midonet] IRC: ditch #midonet-dev?

[Sandro Mathys]

Hi,

Our IRC channels have been neglected for a long time, and as a result
we lost ownership of #midonet-dev, which is now owner by
freenode-staff. In theory, it should be very easy to get ownership
back, particularly since we still own #midonet. But in reality, it
seems like none of the freenode staff feel responsible for these
requests, so we still aren't owners after requesting it for 3 weeks
already.

Therefore, Toni Segura suggested we just ditch it and move to
#openstack-midonet instead.

However, several people have also said we don't need two channels,
i.e. we should merge #midonet and #midonet-dev.

So, here's three proposals:

Proposal #1:
* keep #midonet
* replace #midonet-dev with #openstack-midonet

Proposal #2:
* keep #midonet
* merge #midonet-dev into #midonet

Proposal #3:
* replace both #midonet and #midonet-dev with #openstack-midonet

I don't have any strong feelings for any of the proposals, but suggest
we go with proposal #2. Traffic in both #midonet and #midonet-dev is
rather low, so one channel should do - there's way busier OpenStack
channels out there. Furthermore, #midonet is shorter than
#openstack-midonet and already established. I also think people will
rather look in #midonet than #openstack-midonet if they're looking for
us.

Thoughts?

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

[openstack-dev] [midonet] FYI: Ryu Ishimoto new MidoNet PTL

[Sandro Mathys]

Since we're moving to use this mailing list and other OpenStack
infrastructure soon, I thought I should forward the results of our
recent MidoNet PTL elections to the openstack-dev list.

-- Sandro

-- Forwarded message --
From: Sandro Mathys <san...@midokura.com>
Date: Sat, Nov 21, 2015 at 10:53 AM
Subject: Re: [MidoNet-dev] Electing a MidoNet PTL
To: Ryu Ishimoto <r...@midokura.com>
Cc: midonet-dev <midonet-...@lists.midonet.org>


Alright, the nomination period has ended and there has only been a
single proposal for candidacy. Ryu clearly fulfills all the
requirements, therefore his candidacy is approved.

However, as stated before, there's no point in having an election with
only just one candidate. So please join me in congratulating Ryu to
becoming the first-ever MidoNet PTL, effective immediately!

Thanks for stepping up Ryu! Looking forward on collaborating with you
to reach your high-level goals for our team!

-- Sandro

On Fri, Nov 20, 2015 at 12:46 PM, Ryu Ishimoto <r...@midokura.com> wrote:
>
> I would like to propose my candidacy for the MidoNet PTL.
>
> I have been a MidoNet and Neutron contributor for 5 years, basically from
> the start of both projects.  Because of my lengthy and close involvement in
> both projects, including the integration work, I believe I have the
> appropriate knowledge to steer the MidoNet project in the right direction.
>
> If I were to be chosen for PTL, my high level goals for the next 6 months
> will be:
>
> * Improve stability:  While we have made strides in improving quality of the
> software with the release of v5.0, it is clear that we still have a lot of
> room for improvement.  We must continuously keep fixing bugs until it gets
> to a manageable number.
> * Improve feature development:  This includes better specs, better test
> coverage, better documentation, and other factors that must be considered to
> really 'complete' the feature (ready to be used in production).
> * Improve developer collaboration: MidoNet is made up of different
> components that handle separate concerns; API, Cluster, and Agent, with
> developers with specific expertise scattered among these components.  For
> MidoNet to succeed, developers with different expertise must work together
> effectively.
> * Increase the community size: MidoNet is new to open source and still not
> getting enough contributors.  I will put a lot of effort to change this.
>
> Thanks!
> Ryu Ishimoto (GitHub ID: ryu25ish)
>
>
> On Sat, Nov 14, 2015 at 1:37 AM, Sandro Mathys <san...@midokura.com> wrote:
>>
>> Dear Midos,
>>
>> It's about time we get a proper PTL, and it's also in line with our
>> planned / ongoing adoption of the OpenStack ways [1].
>>
>> "PTL means Project Team Lead. Each OpenStack official project team
>> elects a leader who has final say over all things in that specific
>> project team (and all the code repositories within it)." For more
>> information, see [2].
>>
>> PTLs usually get to serve for ~6 months, but we're a tad late to the
>> PTL election party so the first PTL term will be shorter. We'll try to
>> do the next PTL election at the same time as OpenStack next spring, so
>> the first PTL term will rather be 4-5 months long.
>>
>> Everyone who contributed to any of the repos in the MidoNet
>> organization [3] on GitHub will:
>> 1) be eligible for candidacy
>> 2) get a single vote in the election
>>
>> To propose your candidacy, simply send your self-nomination to this
>> thread. Your proposal must include your full name, your GitHub ID and
>> optionally your candidacy statement. I will then verify your
>> eligibility and add you to the list of candidates.
>>
>> If there's only a single candidate at the end of the nomination
>> period, that person will automatically become PTL. Otherwise, we'll
>> organize an election, using the CIVS [4] and a Condorcet algorithm
>> (Schulze/Beatpath/CSSD variant). In case of a tie, we'll use
>> OpenStack's way of breaking the tie [5].
>>
>> The nomination period starts right now, and ends on Friday, 2015-11-20
>> at 23:59 UTC. The election period will start shortly after (no later
>> than Sunday, 2015-11-22 at 23:59 UTC) and end on Sunday, 2015-11-29 at
>> 23:59 UTC (or a bit later, since ending the election is a manual
>> process).
>>
>> Let me know if there's any questions or concerns. Otherwise, looking
>> forward to your candidacy proposals!
>>
>> Cheers,
>> Sandro
>>
>> [1] https://lists.midonet.org/pipermail/midonet/2015-November/000315.html
>> [2] https://wiki.openstack.org/wiki/PTL_Guide
>> [3] https://g

[openstack-dev] [midonet] Announcing new mailing list topic: MidoNet

[Sandro Mathys]

Hello everyone,

This is just a heads up that Thierry Carrez was so kind as to add a
new topic to the openstack-dev mailing list for the MidoNet dev team.
We currently use our own mailing list [1] but plan to move our
discussions here rather sooner than later.

Last chance to adjust your filters! ;)

Cheers,
Sandro

[1] https://lists.midonet.org/listinfo/midonet-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