[MidoNet-dev] The naming of packages and vendor media types

Ishimoto, Ryu ryu at midokura.com
Fri Feb 1 00:39:52 UTC 2013


On Fri, Feb 1, 2013 at 1:44 AM, Pino de Candia <gdecandia at midokura.com>wrote:

> On Thursday, January 31, 2013 at 5:33 PM, Guillermo Ontañón wrote:
>
> Sounds good to me. I'll take care of all the renames, since I did the
> previous ones
>
> Thanks for taking care of this!


> Just one comment, because this code is meant for submission to Quantum, I
> understand there's no need to create a transitional debian package to ease
> the transition (we don't want to submit something that depends on
> midolmanj-mgmt even if it's a dummy package). Please let me know if such a
> package is needed.
>
>
The code that is going to be submitted to Quantum is our Python Quantum
plugin code, and this has no dependency on any midolmanj-* packages.  So I
don't see any need for having a transitional Debian package.

One last point: I think the new vendor media type should look like
'vnd.midonet.org.router+json' (for routers) as this seems to be the most
commonly used format, and it is a lot shorter than the current one, which
should clean up the design a bit.

Thanks,
Ryu



> --Pino
>
>
> Regards
>
>
> On Thu, Jan 31, 2013 at 5:00 PM, Pino de Candia <gdecandia at midokura.com>wrote:
>
>  Ryu and I just chatted over Skype. Here's the summary of our
> conversation:
>
> - Ryu and Tomoe already tried to integrate Chamicuro/Folsom. In fact, the
> midonet-openstack repository's mainline is now dedicated to
> Chamicuro/Folsom and the Caddo/Folsom code has been put in a branch named
> 'caddo/folsom'. They said the integration was easy, they verified basic
> functionality after hacking for about an hour.
>
> - Ryu pointed out that we want to put our integration code in the Quantum
> plugins repository. To make the cut for Grizzly, we have to submit the code
> by Feb. 12, afterwards only bug-fixes are allowed. The plugin code we
> submit should depend on Chamicuro since that's the OSS version (keep in
> mind that we'll be working on the full Grizzly integration in parallel with
> that).
>
> - We agreed that it would be good for the OSS version to be properly
> cleaned up ASAP. This means fixing the vendor media types, changing some
> artifact names, and removing the occurrence of 'Midokura' everywhere in the
> intended-for-OSS code (replace with Midonet). We'll try to finish that by
> Tuesday at the latest so that Tomoe can make the necessary changes to
> midonet-openstack/master and midonet-deployment to keep Chamicuro/Folsom
> running and installable, and then we'll deprecate Caddo/Folsom.
>
> - We're going to freeze changes to Caddo after today (even most bug
> fixes). The default answer will be "let's fix that in Chamicuro and
> Diyari". We'll fix something in Caddo only when we think it will affect one
> of the current PoC's and there's no work around.
>
> - I'll open a ticket in GH where we can track the exact changes we want to
> make to midonet/chamicuro branch to finalize its OSS-readiness.
>
> Feedback is appreciated.
>
> Pino
>
>
>
> --
> Pino de Candia
> Software Engineer, Midokura.com
>
> On Wednesday, January 30, 2013 at 5:33 PM, Ishimoto, Ryu wrote:
>
> Hey Pino,
>
> Thanks for your input.
>
> On Wed, Jan 30, 2013 at 8:16 PM, Pino de Candia <gdecandia at midokura.com>wrote:
>
> On Wednesday, January 30, 2013 at 10:19 AM, Ishimoto, Ryu wrote:
>
> 1. Make it easy for core-dev to develop/bugfix/maintain 3 branches (C, Ch
> and D). There are still a lot of bug fixes going into Caddo, so my hope was
> to avoid making changes that make it hard to merge a bug-fix written for C
> into Ch and D (or vice versa). From that point of view, I was hoping C
> could be deprecated as soon as Ch (and the integration with Ch) was ready.
> And that's why I wanted to make that as easy as possible.
>
>
> This helps me understand where you're coming from.  The current
> uncertainty of when Caddo can be deprecated is definitely a valid concern.
>  To minimize the window in which the Chamicuro code diverges from the Caddo
> code, how about if we do the integration of Folsom/Chamicuro first and then
> do the rename afterwards?  The integration work required for
> Chamicuro/Folsom is only in python midonet client, and is very minimal.
>  The only major change is the port unlink method.
>
>
>
> 2. Make sure that when we announce MidoNet OSS project, the OpenStack
> integration code (Folsom/Chamicuro?) is part of that announcement. I
> assumed that if the integration changes from C to Ch were significant, it
> would endanger that. This begs the question: when should we freeze Ch and
> when can we aim to have the Ch integration finished?
>
>
>
> Freezing Ch when the OpenStack integration is completed sounds like a good
> idea.  I am very confident that the amount of work required to do
> Folsom/Chamicuro is very small.  In fact, Tomoe was nice enough to quickly
> check this;  He changed a few lines of code and tested Chamicuro/Folsom
> integration on his PC and inter-VM pings over two networks worked, as did
> security groups.  We'll test more but we are fairly confident that this is
> trivial.  We will provide more formal, concrete estimates tomorrow.
>
>
> Now, thinking about your points a little more, you're right that C will be
> used by the PoC customers and Ch will be picked up by partners and anyone
> interested after the OSS announcement. It's true that those are different
> customer groups. If you focus on the Ch customers and want them to have an
> easy time upgrading to D, that's fine - but can we do so in a way that
> satisfies my points 1 and 2?
>
>
> I hope my answers satisfied your points 1 and 2?  Let me know if I still
> failed to be convincing :-)
>
> Ryu
>
>
>
>
>
>
>
> --
> -- Guillermo Ontañón
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.midonet.org/pipermail/midonet-dev/attachments/20130201/10c15484/attachment.html>


More information about the MidoNet-dev mailing list