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

Wed Sep 4 20:26:03 UTC 2013

[Re: [oe] [meta-networking][PATCH] openflow: Add latest from git] On 13.09.04 (Wed 09:13) Philip Balister wrote:

> On 09/03/2013 11:27 PM, Joe MacDonald wrote:
> > On Tue, Sep 3, 2013 at 6:39 PM, Bruce Ashfield <bruce.ashfield at gmail.com> wrote:
> >>
> >> On Tue, Sep 3, 2013 at 5:08 PM, Joe MacDonald <joe at deserted.net> wrote:
> >>> Little late coming to this party, I guess.  Sorry all.  In my defense
> >>> I'll just say that I was less connected than I expected to be over my
> >>> vacation and there's been considerable catching up to do.
> >>>
> >>> [Re: [oe] [meta-networking][PATCH] openflow: Add latest from git] On 13.09.03 (Tue 09:38) Bruce Ashfield wrote:
> >>>
> >>>> On Tue, Sep 3, 2013 at 9:13 AM, Laszlo Papp <lpapp at kde.org> wrote:
> >>>>> 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?
> >>>>
> >>>> Ah, so I see we won't address the fact that the mailing list should have
> >>>> been consulted and that the goals of the oe-layers should be to reduce
> >>>> duplication and get everyone working together. I promise, I won't mention
> >>>> this again, but it is a key point I want to make.
> >>>>
> >>>> I understand where this is going, and I'll try to engage at a technical
> >>>> level, it's all that I can do.
> >>>>
> >>>>>
> >>>>> 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 don't agree with that characterization, since it is very black and white.
> >>>>
> >>>> Having a binding to the larger meta-oe universe (at least for some recipes),
> >>>> isn't always a good thing, and having self contained layers is also something
> >>>> that is a goal at times. I'm not saying this is the case here, just that what
> >>>> you describe above about networking devices not wanting virtualization,
> >>>> is at times flipped around from other layers when looking at meta-oe.
> >>>
> >>> The archives contain my response to this and I did say I won't be going
> >>> back to this particular topic again, so I'll just say that if you really
> >>> feel that a dis-incentive to contributing something to meta-networking
> >>> (or to using meta-networking in your project) is an implicit dependency
> >>> on the larger meta-oe world, we should talk about that sometime.
> >>
> >> Ha. My bad on this front, I honestly didn't check the archives for what you
> >> had said before, I was just responding to the appearance of the recipe.
> >>
> >> As for the larger meta-oe being required to get at meta-networking, I'm not
> >> sure that you and I can solve that. The concern about being able to get an
> >> updated package from meta-networking, and not other packages from the
> >> other layers, i.e. the granularity of the one big chunk is hard to deal with
> >> if you only want to get a specific layer updated.
> > 
> > That is exactly the topic I was suggesting we can talk about if that's
> > an issue you're trying to work around in meta-virtualization.  This
> > isn't really the place for it, though, and I don't want to confuse
> > anyone or subvert the thread.  Let me say that I'll leave it with you.
> >  I'd be happy to try to understand what the concerns are you have with
> > depending on meta-networking and whether they're inherent in meta-net
> > or if they're due to meta-net being part of the larger meta-oe.
> > 
> > The same applies to anyone else working on a layer with clearly
> > networking components that may be reluctant to incorporate it into
> > meta-net.  I'm welcoming submissions of useful components and I'd be
> > really disappointed if we ended up having the same (or similar)
> > recipes in multiple public layers purely due to reticence and
> > (perceived?) extra dependencies.  I'll be other meta-oe maintainers
> > feel the same, too.  Balkanisation benefits no one.
> > 
> > Back on topic, then.
> 
> I am really late to the game ...
> 
> If you are having trouble figuring out what layer a recipe belongs in
> due to it being needed for several layers, maybe the package in question
> belongs in oe-core.

Yeah, that's definitely a good indicator, there's a number of packages
I'd started to look at for meta-net only to discover them already in
oe-core and that's definitely the right place for them.  We've talked
about suggesting others in meta-net to oe-core, but that's where the
other guiding principle of oe-core comes in, that it should be tight.  I
think in this specific example, openflow is way beyond the scope of what
oe-core would want.

You're right, though, any time a discussion around a recipe becomes
contentious in the sense of it is needed in several different layers,
it's reasonable to ask the question "is the best home for this
oe-core?".

-J.

> 
> Philip
> 
> > 
> >>
> >> Does anyone else have a good suggestion on how to deal with that ?
> >>
> >>>
> >>>> meta-virt and meta-networking are very similar in age and the group of
> >>>> recipes to start meta-virt were a merging of two existing layers (a good
> >>>> collaboration) and a lot contributed by ENEA, it was a good effort and I
> >>>> don't think it's right to drop all traces of that effort or describe it as a
> >>>> mistake.
> >>>>
> >>>> Again, opinions vary, that's part of the fun.
> >>>>
> >>>>>
> >>>>> 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.
> >>>>
> >>>> Patches would have been accepted :)
> >>>>
> >>>>>
> >>>>> 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.
> >>>>
> >>>> I'll agree to disagree, I've tried to say that we should look at what the two
> >>>> layers need, come up with a plan, keep the credit to the original authors
> >>>> and then decide how to move forward. i.e. if there are multiple users of the
> >>>> recipe, maybe see about getting it into oe-core, etc. But I see that isn't on
> >>>> the menu today.
> >>>>
> >>>> I'll ping Joe and we'll see what we can figure out as timing for a path forward.
> >>>
> >>> At this point I'm inclined to agree that OpenFlow is a reasonable fit
> >>> for meta-networking, it's something I think I may have even referenced
> >>
> >> FWIW, I agree as well.
> >>
> >>> in my original proposal for creating meta-networking.  But if Laszlo is
> >>> going to propose a new recipe for inclusion, I'll wait to see it before
> >>> trying out any of the existing stuff in my tree.  I certainly don't want
> >>> to invalidate or break any of the work in meta-virtualization and I
> >>> appreciate hearing that this is a concern, but hopefully you understand
> >>> that if that did happen, it'd be by accident as I'm not on the
> >>> meta-virtualization list and I don't know what you guys are doing over
> >>> there.
> >>
> >> What about the following:
> >>
> >>   - We at least give reference to the other recipe, either in the git commit
> >>     message or the recipe itself ? Regardless if this was a clean room
> >>     implementation or not .. they are nearly identical (of course that means
> >>     there is one right way to do this), and at least maintaining the paper trail
> >>     if the recipe migrates is valuable.
> > 
> > That was one of my few comments to Laszlo in this thread.  I'd like to see that.
> > 
> >>  - We run some tests against meta-virt and give you the thumbs up when it
> >>    is safe to merge, and the meta-virt copy can be deleted. I definitely don't
> >>    want two of these running around.
> > 
> > I don't mind delaying a merge a bit while waiting for more feedback on
> > testing, provided we're talking about a reasonable timeframe.
> > Otherwise, if the submitted OpenFlow is working well enough in
> > meta-net, I'm inclined to merge it and take patches from you guys if
> > you find issues down the road.  That'll be how it will work anyway in
> > three month's time, for example, when meta-virt has dropped their
> > copy.
> > 
> > How long do you think you'll need on this?
> > 
> >>  - Now that everyone is aware of the specific use case, we can watch and
> >>    coordinate updates in the future ?
> > 
> > Sure, again, provided we're talking a reasonable timeframe.  One of
> > the things on my exceedingly long todo list (and that others have been
> > immensely helpful with) has been to bring forward OE Classic recipes
> > that make sense for meta-net.   Wherever possible I prefer to try to
> > coordinate with the OE Classic recipe maintainers / contributors, but
> > that's not always possible.  I think the same thing would apply here,
> > we'll do our best to coordinate and know that occasionally there may
> > be hiccups like this one.
> > 
> > -J.
> > 
> >>
> >> Would that be acceptable ?
> >>
> >> Cheers,
> >>
> >> Bruce
> >>
> >>>
> >>> That is to say feel free to pipe up on any stuff like this in the
> >>> future and if you have any specific requests on how this merge happens,
> >>> please let me know.
> >>>
> >>> -J.
> >>>
> >>>>
> >>>> Cheers,
> >>>>
> >>>> Bruce
> >>>>
> >>>>>
> >>>>>
> >>>>> 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
> >>>>>>
> >>>>> _______________________________________________
> >>>>> Openembedded-devel mailing list
> >>>>> Openembedded-devel at lists.openembedded.org
> >>>>> http://lists.openembedded.org/mailman/listinfo/openembedded-devel
> >>>>
> >>>>
> >>>>
> >>> --
> >>> -Joe MacDonald.
> >>> :wq
> >>
> >>
> >>
> >> --
> >> "Thou shalt not follow the NULL pointer, for chaos and madness await
> >> thee at its end"
> > 
> > 
> > 
> > 

-- 
-Joe MacDonald.
:wq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.openembedded.org/pipermail/openembedded-devel/attachments/20130904/af0e1c52/attachment-0002.sig>