[oe] [meta-networking][PATCH] openflow: Add latest from git

[Laszlo Papp]

IMO, most of this email is red herring, and the main topic is a networking
specification should be in meta-networking. Why would I (or anyone for that
matter) need *any* virtualization layer when I am working on a network
device?

I am sorry for your historical misplacement, but it is not an excuse for
future mistakes IMHO. If your virtualization depends on network stuff, you
should *not* force others for virtualization whatever that is. If you need
that, build on top of networking or use own recipes maintained by you.

I fail to see how it is a problem. Even more, the recipe was completely
broken like virtual/libc, *ancient* version, wrong rm'f stuff, bad
description IMHO, etc for meta-networking.

I do not personally mind if you keep your clone because it is your
business, but surely, networking devices should use a network layer, and
that is exactly the point of meta-networking.


On Tue, Sep 3, 2013 at 2:04 PM, Bruce Ashfield <bruce.ashfield at gmail.com>wrote:

> On Mon, Sep 2, 2013 at 11:55 PM, Laszlo Papp <lpapp at kde.org> wrote:
> > On Tue, Sep 3, 2013 at 2:56 AM, Bruce Ashfield <bruce.ashfield at gmail.com
> >wrote:
> >
> >> On Mon, Sep 2, 2013 at 4:20 AM, Laszlo Papp <lpapp at kde.org> wrote:
> >> > 1) The version in meta-virtualization is quite old. It is basically
> from
> >> 2009,
> >> > and a lot of things has changed since then.
> >>
> >> And that was on purpose, there are some tight bindings to SDN and hence
> why
> >> it is in meta-virtualization, and not a valid reason to not contact the
> >> layer
> >> maintainers directly, have a discussion and not set the update to the
> >> current
> >> layer.
> >>
> >
> > I do not understand why I would need to contact a foo layer maintainer
> when
> > I think a recipe has not much to do with foo.
>
> really ? I honestly don't know what to say about that logic.
>
> There's a recipe in another public layer, that is being updated, and was
> put there for a reason. You grab a copy, send it to another layer and
> don't even bother to cc' the originating layer's mailing list ?
>
> You don't think the right thing to do would be to ask a few questions,
> and agree to the path forward ?
>
> >
> >
> >> If you would have asked, you would have been told that updates are
> pending
> >> with bindings that need to stay in lock step with other parts of
> meta-virt.
> >>
> >
> > Sorry, but how is this relevant? It is an extremely old recipe, and
> should
> > not be used. Moreover, this should not block the non-ancient users at
> all,
> > which is probably the majority.
>
> The only difference between your recipe is a new SRCREV, of which there
> was one already pending. And perhaps, if you asked, you would have found
> out that there were dependent other layers and recipes on some particular
> SRCREV.
>
> In such a situation, we could have updated the recipe to create a new one
> and kept the old revision around.
>
> Instead, you copied it, updated the SRCREV with no reference to the
> original
> layer, the authors and their contributions. So we have two copies in the
> ecosystem.
>
> >
> >
> >> > 2) More importantly, this software is more like for networking rather
> >> than
> >> > virtualization, so I think it was misplaced.
> >>
> >> I disagree, so for now meta-virt is going to keep it's variants of the
> >> recipes and
> >> we need to have an actual discussion to figure out the best way forward.
> >>
> >
> > ,,, and I disagree with you. Read the specification for openflow,
> please. I
>
> I've read the specification, but I don't understand why I'm being talked
> down
> to here.
>
> See above, there's enough reason to have a discussion or at least
> follow some etiquette.
>
> > fail to understand how it has anything to do with virtualization.
> > Seriously, this is a software for networking devices. That is, exactly
> the
> > main purpose what meta-networking is trying to achieve: aiding the
> > development for networking devices. As for me, it is totally
> > non-comprehensive why a networking specification and the relevant
> > implementation would be in meta-virtualization rather than
> meta-networking.
>
> There are different opinions on many things, that's the way things work.
> I don't think branding those alternate opinions as invalid and "non
> comprehensive"
> is productive .. do you ?
>
> openflow has control channels to openvswitch, openvswitch is tightly
> coupled
> to the cloud and infrastructure work that happens in meta-virt.
> OpenDayLight
> also has bindings to openvswitch, virtualization and more SDN components.
> Having them all move in lockstep and not introduce incompatible SRCREVs
> as they all update has proven tricky in the past, and will do so. Spreading
> out across multiple layers will only make it more difficult.
>
> I'm not arguing that openflow isn't networking, that wouldn't be logical.
> I'm
> saying that it is where it is for a reason, there are multiple uses and we
> can't
> simply wave a wand and invalidate those other uses because we don't agree
> with them.
>
> >
> > Not to mention, I do not understand why you are trying to set a straw man
> > in here. The discussion you are "requesting" is exactly what this thread
> is
> > meant to be. So, I think you are simply incorrect IMHO. :-)
>
> You didn't cc' the meta-vitualization mailing list. I happen to be on
> both, and
> by chance this is happening, and shouldn't replace a more reasonable
> workflow.
>
> Cheers,
>
> Bruce
>
> >
> > Cheers,
> > Laszlo
> > _______________________________________________
> > Openembedded-devel mailing list
> > Openembedded-devel at lists.openembedded.org
> > http://lists.openembedded.org/mailman/listinfo/openembedded-devel
>
>
>
> --
> "Thou shalt not follow the NULL pointer, for chaos and madness await
> thee at its end"
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel at lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-devel
>