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

[Burton, Ross]

On 5 September 2013 05:39, Bruce Ashfield bruce.ashfi...@gmail.com wrote:
 The meta-virt recipe had the same _1.0.bb extension, and it's SRCREV lines up
 with the openflow-1.0.0 tag in the repository:

 

 commit 5ccca75a69f99791659bcfbcf35353ab1921320a
 Author: Glen Gibb g...@stanford.edu
 Date:   Thu Dec 31 16:00:53 2009 -0800

 docs: Update ChangeLog to include 1.0.0 information

 :100644 100644 2f13dd7... aa0e92e... M  ChangeLog

 ---

 So it's definitely an option to keep that recipe around as the tagged 1.0, and
 create a _git that tracks newer changes (where newer is relative, 2011 is
 the latest commit in that repo).

FWIW, I massively prefer releases that are taken from git like this
(where its a git fetch on a hash that is the tag of the releases) to
be versioned correctly like _1.0.bb instead of _git.bb for clarity and
future alternatives such as true git snapshot or multiple versions.

Ross
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

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

[Laszlo Papp]

On Thu, Sep 5, 2013 at 10:01 AM, Burton, Ross ross.bur...@intel.com wrote:

 On 5 September 2013 05:39, Bruce Ashfield bruce.ashfi...@gmail.com
 wrote:
  The meta-virt recipe had the same _1.0.bb extension, and it's SRCREV
 lines up
  with the openflow-1.0.0 tag in the repository:
 
  
 
  commit 5ccca75a69f99791659bcfbcf35353ab1921320a
  Author: Glen Gibb g...@stanford.edu
  Date:   Thu Dec 31 16:00:53 2009 -0800
 
  docs: Update ChangeLog to include 1.0.0 information
 
  :100644 100644 2f13dd7... aa0e92e... M  ChangeLog
 
  ---
 
  So it's definitely an option to keep that recipe around as the tagged
 1.0, and
  create a _git that tracks newer changes (where newer is relative, 2011
 is
  the latest commit in that repo).

 FWIW, I massively prefer releases that are taken from git like this
 (where its a git fetch on a hash that is the tag of the releases) to
 be versioned correctly like _1.0.bb instead of _git.bb for clarity and
 future alternatives such as true git snapshot or multiple versions.


... and I massively prefer released not to be taken from git. So if 1.0
has to be *really* supported which I do not think so, it should get the
release tarball.

Moreover, there have not been new git commits for about two years now
because the standard was taken over by a different organization which seems
to work behind the scenes. Too bad, they have not released the latest
before that change. Hopefully, this will not mislead anyone that this
software is still actively developed in public.

That is another very reason IMHO which it would not fit the core layer at
all.

-- Laszlo



 Ross
 ___
 Openembedded-devel mailing list
 Openembedded-devel@lists.openembedded.org
 http://lists.openembedded.org/mailman/listinfo/openembedded-devel

___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

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

[Joe MacDonald]

[Re: [oe] [meta-networking][PATCH] openflow: Add latest from git] On 13.09.05 
(Thu 00:39) Bruce Ashfield wrote:

 On Wed, Sep 4, 2013 at 5:14 PM, Joe MacDonald j...@deserted.net wrote:
  Actually, after all of that, I do have a couple of additional requests
  (beyond just the tweak to the commit log).
 
 Explicitly cc:ing Bruce here since I'm intentionally not adding
 meta-virt@.  I've gotten bounced from it in the past as I'm not a
 subscriber and it's subscriber-only.
 
 :) I can't blame you for that, I share the pain (after bouncing off of 
 oe-devel
 just a few days ago myself). Thanks for the cc.

*sigh*  I mean well.  I need to be a little less quick on sending an
email to ensure I've actually done (eg. added a cc) what I've claimed in
it.

  [[oe] [meta-networking][PATCH] openflow: Add latest from git] On 13.09.02 
  (Mon 09:20) Laszlo Papp wrote:
 
  1) The version in meta-virtualization is quite old. It is basically from 
  2009,
  and a lot of things has changed since then.
 
  2) More importantly, this software is more like for networking rather than
  virtualization, so I think it was misplaced.
 
  SOB please?
 
  ---
   .../recipes-support/openflow/openflow_1.0.bb   | 32 
  ++
 
  Is this actually based on an OpenFlow 1.0 release, or has it always been
  1.0+git?  I don't have a copy of meta-virt around to check myself.  If
  there was a real 1.0 recipe around, can we keep it as is and make this
  openflow_git.bb, more in line with the other +git... recipes?
 
 The meta-virt recipe had the same _1.0.bb extension, and it's SRCREV lines up
 with the openflow-1.0.0 tag in the repository:

I didn't know that.  In that case, the recipe naming makes sense to me.
I'm ambivalent when it comes to source tarballs versus git repos and
tags.  What I'm looking at makes sense though.  Thanks for the
clarification.

-J.

 
 
 
 commit 5ccca75a69f99791659bcfbcf35353ab1921320a
 Author: Glen Gibb g...@stanford.edu
 Date:   Thu Dec 31 16:00:53 2009 -0800
 
 docs: Update ChangeLog to include 1.0.0 information
 
 :100644 100644 2f13dd7... aa0e92e... M  ChangeLog
 
 ---
 
 So it's definitely an option to keep that recipe around as the tagged 1.0, and
 create a _git that tracks newer changes (where newer is relative, 2011 is
 the latest commit in that repo).
 
 Maybe someday, we'll get a working 1.x openflow to play with! :)
 
 Thanks for holding on this briefly, it did help.
 
 Bruce
 
 
   1 file changed, 32 insertions(+)
   create mode 100644 
  meta-networking/recipes-support/openflow/openflow_1.0.bb
 
  diff --git a/meta-networking/recipes-support/openflow/openflow_1.0.bb 
  b/meta-networking/recipes-support/openflow/openflow_1.0.bb
  new file mode 100644
  index 000..eb7770e
  --- /dev/null
  +++ b/meta-networking/recipes-support/openflow/openflow_1.0.bb
  @@ -0,0 +1,32 @@
  +SUMMARY = OpenFlow
  +DESCRIPTION = Open standard that enables researchers to run experimental 
  protocols in the campus networks
  +HOMEPAGE = http://www.openflow.org;
  +SECTION = networking
  +LICENSE = GPLv2
  +
  +LIC_FILES_CHKSUM = file://COPYING;md5=e870c934e2c3d6ccf085fd7cf0a1e2e2
  +
  +SRCREV = c84f33f09d5dbcfc9b489f64cb30475bf36f653a
  +PV = 1.0+git${SRCPV}
  +SRC_URI = git://gitosis.stanford.edu/openflow.git;protocol=git
  +
  +DEPENDS = virtual/libc
  +
  +EXTRA_OECONF += KARCH=${TARGET_ARCH}
  +
  +PACKAGECONFIG ??= libssl
  +PACKAGECONFIG[libssl] = --enable-ssl,--disable-ssl, openssl, libssl
  +
  +S = ${WORKDIR}/git
  +
  +inherit autotools
  +
  +do_configure() {
  +./boot.sh
  +oe_runconf
  +}
  +
  +do_install_append() {
  + # Remove /var/run as it is created on startup
  +rm -rf ${D}${localstatedir}/run
  +}
 
  And while we're in the neighbourhood, can we also clean up the
  inconsistent spacing?
 
  Thanks.
 
  --
  -Joe MacDonald.
  :wq
 
  ___
  Openembedded-devel mailing list
  Openembedded-devel@lists.openembedded.org
  http://lists.openembedded.org/mailman/listinfo/openembedded-devel
 
 
 
 
-- 
-Joe MacDonald.
:wq


signature.asc
Description: Digital signature
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

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

[Joe MacDonald]

[Re: [oe] [meta-networking][PATCH] openflow: Add latest from git] On 13.09.05 
(Thu 10:01) Burton, Ross wrote:

 On 5 September 2013 05:39, Bruce Ashfield bruce.ashfi...@gmail.com wrote:
  The meta-virt recipe had the same _1.0.bb extension, and it's SRCREV lines 
  up
  with the openflow-1.0.0 tag in the repository:
 
  
 
  commit 5ccca75a69f99791659bcfbcf35353ab1921320a
  Author: Glen Gibb g...@stanford.edu
  Date:   Thu Dec 31 16:00:53 2009 -0800
 
  docs: Update ChangeLog to include 1.0.0 information
 
  :100644 100644 2f13dd7... aa0e92e... M  ChangeLog
 
  ---
 
  So it's definitely an option to keep that recipe around as the tagged 1.0, 
  and
  create a _git that tracks newer changes (where newer is relative, 2011 is
  the latest commit in that repo).
 
 FWIW, I massively prefer releases that are taken from git like this
 (where its a git fetch on a hash that is the tag of the releases) to
 be versioned correctly like _1.0.bb instead of _git.bb for clarity and
 future alternatives such as true git snapshot or multiple versions.

Yeah, since the SRCREV in the _1.0.bb recipe actually corresponds to the
1.0 release tag, I'm in agreement.  The proposed update from Laszlo also
now seems to justify having a _git.bb version, since it's pointing at a
(relatively) newer version of the recipe.

-- 
-Joe MacDonald.
:wq


signature.asc
Description: Digital signature
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

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

[Laszlo Papp]

I still do not follow why you are not waiting patiently for an update. I
have already written that I would send one soon (this thread demoralized me
and motivated though for a bit of delay).

All the discussion would have been spared in here, as the issues were
addressed before I even sent the wrong version.

How about reviewing other pending changes for weeks like stunnel?


On Thu, Sep 5, 2013 at 2:04 PM, Joe MacDonald j...@deserted.net wrote:

 [Re: [oe] [meta-networking][PATCH] openflow: Add latest from git] On
 13.09.05 (Thu 10:01) Burton, Ross wrote:

  On 5 September 2013 05:39, Bruce Ashfield bruce.ashfi...@gmail.com
 wrote:
   The meta-virt recipe had the same _1.0.bb extension, and it's SRCREV
 lines up
   with the openflow-1.0.0 tag in the repository:
  
   
  
   commit 5ccca75a69f99791659bcfbcf35353ab1921320a
   Author: Glen Gibb g...@stanford.edu
   Date:   Thu Dec 31 16:00:53 2009 -0800
  
   docs: Update ChangeLog to include 1.0.0 information
  
   :100644 100644 2f13dd7... aa0e92e... M  ChangeLog
  
   ---
  
   So it's definitely an option to keep that recipe around as the tagged
 1.0, and
   create a _git that tracks newer changes (where newer is relative,
 2011 is
   the latest commit in that repo).
 
  FWIW, I massively prefer releases that are taken from git like this
  (where its a git fetch on a hash that is the tag of the releases) to
  be versioned correctly like _1.0.bb instead of _git.bb for clarity and
  future alternatives such as true git snapshot or multiple versions.

 Yeah, since the SRCREV in the _1.0.bb recipe actually corresponds to the
 1.0 release tag, I'm in agreement.  The proposed update from Laszlo also
 now seems to justify having a _git.bb version, since it's pointing at a
 (relatively) newer version of the recipe.

 --
 -Joe MacDonald.
 :wq

 ___
 Openembedded-devel mailing list
 Openembedded-devel@lists.openembedded.org
 http://lists.openembedded.org/mailman/listinfo/openembedded-devel


___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

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

[Bruce Ashfield]

On Tue, Sep 3, 2013 at 11:27 PM, Joe MacDonald j...@deserted.net wrote:
 On Tue, Sep 3, 2013 at 6:39 PM, Bruce Ashfield bruce.ashfi...@gmail.com 
 wrote:

 On Tue, Sep 3, 2013 at 5:08 PM, Joe MacDonald j...@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 lp...@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.

I won't go on a tangent either .. but yes, I can't control individual SRCREVs
of the layers, so I'm either cherry picking .. or taking everything. meta-net
causes no pain for me, and I have no complaints at all.


 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

+1. I completely agree, that's why I wanted to get some handshaking
between the layers, and when we agreed on a path, we can delete the
meta-virt variant. I only want one to be around.

 (perceived?) extra dependencies.  I'll be other meta-oe maintainers
 feel the same, too.  Balkanisation benefits no one.

 Back on topic, then.


 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

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

[Philip Balister]

On 09/03/2013 11:27 PM, Joe MacDonald wrote:
 On Tue, Sep 3, 2013 at 6:39 PM, Bruce Ashfield bruce.ashfi...@gmail.com 
 wrote:

 On Tue, Sep 3, 2013 at 5:08 PM, Joe MacDonald j...@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 lp...@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.

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

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

[Laszlo Papp]

On Wed, Sep 4, 2013 at 2:13 PM, Philip Balister phi...@balister.org wrote:

 snip
  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.


You are not just late, but also quite off IMHO ... ;-)

As written already, and if you had taken the time to look into the software
in question, you would have realized that from more than one point of view
that this standard is definitely a domain specific network material. It is
*far* away from being a core component.

Off-topic: I do not understand why meta-virtualization is this messy. That
seems to cause the whole annoyance in here on top of the give me the
credit for a few lines which can only be written in one way other
argument. Anyway, this seems to be an appropriate trigger for
meta-virtualization to get some stabilization. Past mistakes are no excuse
for introducing more, in my book.
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

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

[Joe MacDonald]

[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.ashfi...@gmail.com 
  wrote:
 
  On Tue, Sep 3, 2013 at 5:08 PM, Joe MacDonald j...@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 lp...@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

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

[Joe MacDonald]

[Re: [oe] [meta-networking][PATCH] openflow: Add latest from git] On 13.09.03 
(Tue 17:18) Joe MacDonald wrote:

 [Re: [oe] [meta-networking][PATCH] openflow: Add latest from git] On 13.09.03 
 (Tue 14:47) Laszlo Papp wrote:
 
  On Tue, Sep 3, 2013 at 2:38 PM, Bruce Ashfield bruce.ashfi...@gmail.com
  wrote:
  
  On Tue, Sep 3, 2013 at 9:13 AM, Laszlo Papp lp...@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.
  
  
  Frankly, you have mentioned the credit so strongly in this thread for a few
  lines which is not even copyright'd, I will rewrite this stuff from scratch
  today.
 
 It may be that that's an appropriate approach at this juncture, I don't
 know.  I'd like to see us not lose any work that's already been done and
 would be disappointed if something turns out to be a regression in the
 meta-networking version of openflow from the meta-virtualization version
 purely due to a communications breakdown.  I'll trust you guys to sort
 that out.
 
 My only comment on what I've seen so far is maybe in the commit log
 remove the 2) comment as it borders on editorializing and update the log
 to match more of the style of recipes ported from the world (mostly OE
 Classic, so far, for meta-networking).  See 2cde4a, 8fec90, or 413a9 for
 something I think is a good way to reference history.

Hey Laszlo,

Just to close on this, if Bruce (or someone working with
meta-virtualization) is nearing completion of testing with the recipe
you've already submitted, is that the one you want me to consider for
merging, or are you going to have a v2 coming out soon?

FYI:  I expect to be done merging your other patch (the stunnel one)
later on today.  It didn't get lost, I just didn't get to merge it
yesterday.

-J.

 
 Thanks,
 -J.
 
  I am sad to see this discussion is going into credit debate rather
  than technical stuff.
  
  Actually, I even had a recipe before looking into virtualization, but that
  probably does not matter for you...
  
  
   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.
  
  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.
  
  
  The problem is not that opinions matter, but *your* opinion about black 
  being
  white IMHO. Did you even bother to read what the openflow standard is for? 
  It
  is for networking devices, come on, and you still think it is not a
  meta-networking material?
  
  Please come up with a *rebruttal* and bother substantiating it.
   
  
   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 :)
  
  
  Here is the patch, so what is your argument again? That it should remain in
  your beloved meta-virtualization while disregarding the fact it is a 
  networking
  standard?
  
  I do not seem to have pushed the latest version of the change though. 
  
  
   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

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

[Joe MacDonald]

Actually, after all of that, I do have a couple of additional requests
(beyond just the tweak to the commit log).

   Explicitly cc:ing Bruce here since I'm intentionally not adding
   meta-virt@.  I've gotten bounced from it in the past as I'm not a
   subscriber and it's subscriber-only.

[[oe] [meta-networking][PATCH] openflow: Add latest from git] On 13.09.02 (Mon 
09:20) Laszlo Papp wrote:

 1) The version in meta-virtualization is quite old. It is basically from 2009,
 and a lot of things has changed since then.
 
 2) More importantly, this software is more like for networking rather than
 virtualization, so I think it was misplaced.

SOB please?

 ---
  .../recipes-support/openflow/openflow_1.0.bb   | 32 
 ++

Is this actually based on an OpenFlow 1.0 release, or has it always been
1.0+git?  I don't have a copy of meta-virt around to check myself.  If
there was a real 1.0 recipe around, can we keep it as is and make this
openflow_git.bb, more in line with the other +git... recipes?

  1 file changed, 32 insertions(+)
  create mode 100644 meta-networking/recipes-support/openflow/openflow_1.0.bb
 
 diff --git a/meta-networking/recipes-support/openflow/openflow_1.0.bb 
 b/meta-networking/recipes-support/openflow/openflow_1.0.bb
 new file mode 100644
 index 000..eb7770e
 --- /dev/null
 +++ b/meta-networking/recipes-support/openflow/openflow_1.0.bb
 @@ -0,0 +1,32 @@
 +SUMMARY = OpenFlow
 +DESCRIPTION = Open standard that enables researchers to run experimental 
 protocols in the campus networks
 +HOMEPAGE = http://www.openflow.org;
 +SECTION = networking
 +LICENSE = GPLv2
 +
 +LIC_FILES_CHKSUM = file://COPYING;md5=e870c934e2c3d6ccf085fd7cf0a1e2e2
 +
 +SRCREV = c84f33f09d5dbcfc9b489f64cb30475bf36f653a
 +PV = 1.0+git${SRCPV}
 +SRC_URI = git://gitosis.stanford.edu/openflow.git;protocol=git
 +
 +DEPENDS = virtual/libc
 +
 +EXTRA_OECONF += KARCH=${TARGET_ARCH}
 +
 +PACKAGECONFIG ??= libssl
 +PACKAGECONFIG[libssl] = --enable-ssl,--disable-ssl, openssl, libssl
 +
 +S = ${WORKDIR}/git
 +
 +inherit autotools
 +
 +do_configure() {
 +./boot.sh
 +oe_runconf
 +}
 +
 +do_install_append() {
 + # Remove /var/run as it is created on startup
 +rm -rf ${D}${localstatedir}/run
 +}

And while we're in the neighbourhood, can we also clean up the
inconsistent spacing?

Thanks.

-- 
-Joe MacDonald.
:wq


signature.asc
Description: Digital signature
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

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

[Joe MacDonald]

[Re: [oe] [meta-networking][PATCH] openflow: Add latest from git] On 13.09.04 
(Wed 08:22) Bruce Ashfield wrote:

 On Tue, Sep 3, 2013 at 11:27 PM, Joe MacDonald j...@deserted.net wrote:
  On Tue, Sep 3, 2013 at 6:39 PM, Bruce Ashfield bruce.ashfi...@gmail.com 
  wrote:
 
...
   - 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?
 
 I can test the new SRCREV and recipe by the end of the day, assuming
 that you have the slightly edited version by the time I'm done, there
 shouldn't be any incurred delay.

Great, thanks.  Let me know how it goes.

-- 
-Joe MacDonald.
:wq


signature.asc
Description: Digital signature
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

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

[Bruce Ashfield]

On Wed, Sep 4, 2013 at 5:04 PM, Joe MacDonald j...@deserted.net wrote:
 [Re: [oe] [meta-networking][PATCH] openflow: Add latest from git] On 13.09.04 
 (Wed 08:22) Bruce Ashfield wrote:

 On Tue, Sep 3, 2013 at 11:27 PM, Joe MacDonald j...@deserted.net wrote:
  On Tue, Sep 3, 2013 at 6:39 PM, Bruce Ashfield bruce.ashfi...@gmail.com 
  wrote:
 
 ...
   - 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?

 I can test the new SRCREV and recipe by the end of the day, assuming
 that you have the slightly edited version by the time I'm done, there
 shouldn't be any incurred delay.

 Great, thanks.  Let me know how it goes.

My cherry-picked version of the patch looks sane, the newer hash worked ok in
my tests. Which isn't surprising, since the number of changes between the old
and new SRCREV isn't that big.

So from that front, we are fine to keep chugging along.

Bruce


 --
 -Joe MacDonald.
 :wq



-- 
Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

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

[Bruce Ashfield]

On Wed, Sep 4, 2013 at 5:14 PM, Joe MacDonald j...@deserted.net wrote:
 Actually, after all of that, I do have a couple of additional requests
 (beyond just the tweak to the commit log).

Explicitly cc:ing Bruce here since I'm intentionally not adding
meta-virt@.  I've gotten bounced from it in the past as I'm not a
subscriber and it's subscriber-only.

:) I can't blame you for that, I share the pain (after bouncing off of oe-devel
just a few days ago myself). Thanks for the cc.


 [[oe] [meta-networking][PATCH] openflow: Add latest from git] On 13.09.02 
 (Mon 09:20) Laszlo Papp wrote:

 1) The version in meta-virtualization is quite old. It is basically from 
 2009,
 and a lot of things has changed since then.

 2) More importantly, this software is more like for networking rather than
 virtualization, so I think it was misplaced.

 SOB please?

 ---
  .../recipes-support/openflow/openflow_1.0.bb   | 32 
 ++

 Is this actually based on an OpenFlow 1.0 release, or has it always been
 1.0+git?  I don't have a copy of meta-virt around to check myself.  If
 there was a real 1.0 recipe around, can we keep it as is and make this
 openflow_git.bb, more in line with the other +git... recipes?

The meta-virt recipe had the same _1.0.bb extension, and it's SRCREV lines up
with the openflow-1.0.0 tag in the repository:



commit 5ccca75a69f99791659bcfbcf35353ab1921320a
Author: Glen Gibb g...@stanford.edu
Date:   Thu Dec 31 16:00:53 2009 -0800

docs: Update ChangeLog to include 1.0.0 information

:100644 100644 2f13dd7... aa0e92e... M  ChangeLog

---

So it's definitely an option to keep that recipe around as the tagged 1.0, and
create a _git that tracks newer changes (where newer is relative, 2011 is
the latest commit in that repo).

Maybe someday, we'll get a working 1.x openflow to play with! :)

Thanks for holding on this briefly, it did help.

Bruce


  1 file changed, 32 insertions(+)
  create mode 100644 meta-networking/recipes-support/openflow/openflow_1.0.bb

 diff --git a/meta-networking/recipes-support/openflow/openflow_1.0.bb 
 b/meta-networking/recipes-support/openflow/openflow_1.0.bb
 new file mode 100644
 index 000..eb7770e
 --- /dev/null
 +++ b/meta-networking/recipes-support/openflow/openflow_1.0.bb
 @@ -0,0 +1,32 @@
 +SUMMARY = OpenFlow
 +DESCRIPTION = Open standard that enables researchers to run experimental 
 protocols in the campus networks
 +HOMEPAGE = http://www.openflow.org;
 +SECTION = networking
 +LICENSE = GPLv2
 +
 +LIC_FILES_CHKSUM = file://COPYING;md5=e870c934e2c3d6ccf085fd7cf0a1e2e2
 +
 +SRCREV = c84f33f09d5dbcfc9b489f64cb30475bf36f653a
 +PV = 1.0+git${SRCPV}
 +SRC_URI = git://gitosis.stanford.edu/openflow.git;protocol=git
 +
 +DEPENDS = virtual/libc
 +
 +EXTRA_OECONF += KARCH=${TARGET_ARCH}
 +
 +PACKAGECONFIG ??= libssl
 +PACKAGECONFIG[libssl] = --enable-ssl,--disable-ssl, openssl, libssl
 +
 +S = ${WORKDIR}/git
 +
 +inherit autotools
 +
 +do_configure() {
 +./boot.sh
 +oe_runconf
 +}
 +
 +do_install_append() {
 + # Remove /var/run as it is created on startup
 +rm -rf ${D}${localstatedir}/run
 +}

 And while we're in the neighbourhood, can we also clean up the
 inconsistent spacing?

 Thanks.

 --
 -Joe MacDonald.
 :wq

 ___
 Openembedded-devel mailing list
 Openembedded-devel@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@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

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

[Laszlo Papp]

As I wrote, I have not uploaded the newest revision, so please do not
review the old.

Anyway, Bruce managed to demotivate me to contribute. I am currently not in
a mood after all this for sending the update.


On Wed, Sep 4, 2013 at 10:14 PM, Joe MacDonald j...@deserted.net wrote:

 Actually, after all of that, I do have a couple of additional requests
 (beyond just the tweak to the commit log).

Explicitly cc:ing Bruce here since I'm intentionally not adding
meta-virt@.  I've gotten bounced from it in the past as I'm not a
subscriber and it's subscriber-only.

 [[oe] [meta-networking][PATCH] openflow: Add latest from git] On 13.09.02
 (Mon 09:20) Laszlo Papp wrote:

  1) The version in meta-virtualization is quite old. It is basically from
 2009,
  and a lot of things has changed since then.
 
  2) More importantly, this software is more like for networking rather
 than
  virtualization, so I think it was misplaced.

 SOB please?

  ---
   .../recipes-support/openflow/openflow_1.0.bb   | 32
 ++

 Is this actually based on an OpenFlow 1.0 release, or has it always been
 1.0+git?  I don't have a copy of meta-virt around to check myself.  If
 there was a real 1.0 recipe around, can we keep it as is and make this
 openflow_git.bb, more in line with the other +git... recipes?

   1 file changed, 32 insertions(+)
   create mode 100644 meta-networking/recipes-support/openflow/
 openflow_1.0.bb
 
  diff --git 
  a/meta-networking/recipes-support/openflow/openflow_1.0.bbb/meta-networking/recipes-support/openflow/
 openflow_1.0.bb
  new file mode 100644
  index 000..eb7770e
  --- /dev/null
  +++ b/meta-networking/recipes-support/openflow/openflow_1.0.bb
  @@ -0,0 +1,32 @@
  +SUMMARY = OpenFlow
  +DESCRIPTION = Open standard that enables researchers to run
 experimental protocols in the campus networks
  +HOMEPAGE = http://www.openflow.org;
  +SECTION = networking
  +LICENSE = GPLv2
  +
  +LIC_FILES_CHKSUM = file://COPYING;md5=e870c934e2c3d6ccf085fd7cf0a1e2e2
  +
  +SRCREV = c84f33f09d5dbcfc9b489f64cb30475bf36f653a
  +PV = 1.0+git${SRCPV}
  +SRC_URI = git://gitosis.stanford.edu/openflow.git;protocol=git
  +
  +DEPENDS = virtual/libc
  +
  +EXTRA_OECONF += KARCH=${TARGET_ARCH}
  +
  +PACKAGECONFIG ??= libssl
  +PACKAGECONFIG[libssl] = --enable-ssl,--disable-ssl, openssl, libssl
  +
  +S = ${WORKDIR}/git
  +
  +inherit autotools
  +
  +do_configure() {
  +./boot.sh
  +oe_runconf
  +}
  +
  +do_install_append() {
  + # Remove /var/run as it is created on startup
  +rm -rf ${D}${localstatedir}/run
  +}

 And while we're in the neighbourhood, can we also clean up the
 inconsistent spacing?

 Thanks.

 --
 -Joe MacDonald.
 :wq

___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

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

[Bruce Ashfield]

On Mon, Sep 2, 2013 at 11:55 PM, Laszlo Papp lp...@kde.org wrote:
 On Tue, Sep 3, 2013 at 2:56 AM, Bruce Ashfield 
 bruce.ashfi...@gmail.comwrote:

 On Mon, Sep 2, 2013 at 4:20 AM, Laszlo Papp lp...@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@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@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [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.ashfi...@gmail.comwrote:

 On Mon, Sep 2, 2013 at 11:55 PM, Laszlo Papp lp...@kde.org wrote:
  On Tue, Sep 3, 2013 at 2:56 AM, Bruce Ashfield bruce.ashfi...@gmail.com
 wrote:
 
  On Mon, Sep 2, 2013 at 4:20 AM, Laszlo Papp lp...@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. 

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

[Bruce Ashfield]

On Tue, Sep 3, 2013 at 9:13 AM, Laszlo Papp lp...@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.

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.

Cheers,

Bruce



 On Tue, Sep 3, 2013 at 2:04 PM, Bruce Ashfield 
 bruce.ashfi...@gmail.comwrote:

 On Mon, Sep 2, 2013 at 11:55 PM, Laszlo Papp lp...@kde.org wrote:
  On Tue, Sep 3, 2013 at 2:56 AM, Bruce Ashfield bruce.ashfi...@gmail.com
 wrote:
 
  On Mon, Sep 2, 2013 at 4:20 AM, Laszlo Papp lp...@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 

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

[Laszlo Papp]

On Tue, Sep 3, 2013 at 2:38 PM, Bruce Ashfield bruce.ashfi...@gmail.comwrote:

 On Tue, Sep 3, 2013 at 9:13 AM, Laszlo Papp lp...@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.


Frankly, you have mentioned the credit so strongly in this thread for a few
lines which is not even copyright'd, I will rewrite this stuff from scratch
today. I am sad to see this discussion is going into credit debate rather
than technical stuff.

Actually, I even had a recipe before looking into virtualization, but that
probably does not matter for you...

 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.

 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.


The problem is not that opinions matter, but *your* opinion about black
being white IMHO. Did you even bother to read what the openflow standard is
for? It is for networking devices, come on, and you still think it is not a
meta-networking material?

Please come up with a *rebruttal* and bother substantiating it.


  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 :)


Here is the patch, so what is your argument again? That it should remain in
your beloved meta-virtualization while disregarding the fact it is a
networking standard?

I do not seem to have pushed the latest version of the change though.

 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.


oe-core would not make sense for this. It is *far* from being that core
component. It is actually a very domain specific networking  component.


 I'll ping Joe and we'll see what we can figure out as timing for a path
 forward.


There is no *any* need to ping him. This change was sent to the mailing
list as instructed by the meta-networking layer manual, hence he will see
it. Please keep this ping in public, and do not hide this behind the
scenes in private. The more eyes, the better.
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

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

[Joe MacDonald]

[Re: [oe] [meta-networking][PATCH] openflow: Add latest from git] On 13.09.03 
(Tue 14:47) Laszlo Papp wrote:

 On Tue, Sep 3, 2013 at 2:38 PM, Bruce Ashfield bruce.ashfi...@gmail.com
 wrote:
 
 On Tue, Sep 3, 2013 at 9:13 AM, Laszlo Papp lp...@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.
 
 
 Frankly, you have mentioned the credit so strongly in this thread for a few
 lines which is not even copyright'd, I will rewrite this stuff from scratch
 today.

It may be that that's an appropriate approach at this juncture, I don't
know.  I'd like to see us not lose any work that's already been done and
would be disappointed if something turns out to be a regression in the
meta-networking version of openflow from the meta-virtualization version
purely due to a communications breakdown.  I'll trust you guys to sort
that out.

My only comment on what I've seen so far is maybe in the commit log
remove the 2) comment as it borders on editorializing and update the log
to match more of the style of recipes ported from the world (mostly OE
Classic, so far, for meta-networking).  See 2cde4a, 8fec90, or 413a9 for
something I think is a good way to reference history.

Thanks,
-J.

 I am sad to see this discussion is going into credit debate rather
 than technical stuff.
 
 Actually, I even had a recipe before looking into virtualization, but that
 probably does not matter for you...
 
 
  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.
 
 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.
 
 
 The problem is not that opinions matter, but *your* opinion about black being
 white IMHO. Did you even bother to read what the openflow standard is for? It
 is for networking devices, come on, and you still think it is not a
 meta-networking material?
 
 Please come up with a *rebruttal* and bother substantiating it.
  
 
  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 :)
 
 
 Here is the patch, so what is your argument again? That it should remain in
 your beloved meta-virtualization while disregarding the fact it is a 
 networking
 standard?
 
 I do not seem to have pushed the latest version of the change though. 
 
 
  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.
 
 
 oe-core would not make sense for this. It is *far* from being that core
 component. It is actually a very domain specific networking  component.
  
 
 I'll ping Joe and we'll see what we can figure out as timing for a path
 forward.
 
 
 There is no *any* need to ping him. This change was sent to the mailing list 
 as
 instructed by the meta-networking layer manual, hence he will see it. Please
 keep this ping in public, and do not hide this behind

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

[Joe MacDonald]

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 lp...@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.

 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
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.

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.ashfi...@gmail.comwrote:
 
  On Mon, Sep 2, 2013 at 11:55 PM, Laszlo Papp lp...@kde.org wrote:
   On Tue, Sep 3, 2013 at 2:56 AM, Bruce Ashfield bruce.ashfi...@gmail.com
  wrote:
  
   On Mon, Sep 2, 2013 at 4:20 AM, Laszlo Papp lp...@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

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

[Bruce Ashfield]

On Tue, Sep 3, 2013 at 5:08 PM, Joe MacDonald j...@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 lp...@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.

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

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

[Joe MacDonald]

On Tue, Sep 3, 2013 at 6:39 PM, Bruce Ashfield bruce.ashfi...@gmail.com wrote:

 On Tue, Sep 3, 2013 at 5:08 PM, Joe MacDonald j...@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 lp...@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.


 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

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

[Laszlo Papp]

1) The version in meta-virtualization is quite old. It is basically from 2009,
and a lot of things has changed since then.

2) More importantly, this software is more like for networking rather than
virtualization, so I think it was misplaced.
---
 .../recipes-support/openflow/openflow_1.0.bb   | 32 ++
 1 file changed, 32 insertions(+)
 create mode 100644 meta-networking/recipes-support/openflow/openflow_1.0.bb

diff --git a/meta-networking/recipes-support/openflow/openflow_1.0.bb 
b/meta-networking/recipes-support/openflow/openflow_1.0.bb
new file mode 100644
index 000..eb7770e
--- /dev/null
+++ b/meta-networking/recipes-support/openflow/openflow_1.0.bb
@@ -0,0 +1,32 @@
+SUMMARY = OpenFlow
+DESCRIPTION = Open standard that enables researchers to run experimental 
protocols in the campus networks
+HOMEPAGE = http://www.openflow.org;
+SECTION = networking
+LICENSE = GPLv2
+
+LIC_FILES_CHKSUM = file://COPYING;md5=e870c934e2c3d6ccf085fd7cf0a1e2e2
+
+SRCREV = c84f33f09d5dbcfc9b489f64cb30475bf36f653a
+PV = 1.0+git${SRCPV}
+SRC_URI = git://gitosis.stanford.edu/openflow.git;protocol=git
+
+DEPENDS = virtual/libc
+
+EXTRA_OECONF += KARCH=${TARGET_ARCH}
+
+PACKAGECONFIG ??= libssl
+PACKAGECONFIG[libssl] = --enable-ssl,--disable-ssl, openssl, libssl
+
+S = ${WORKDIR}/git
+
+inherit autotools
+
+do_configure() {
+./boot.sh
+oe_runconf
+}
+
+do_install_append() {
+   # Remove /var/run as it is created on startup
+rm -rf ${D}${localstatedir}/run
+}
-- 
1.8.4

___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

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

[Bruce Ashfield]

On Mon, Sep 2, 2013 at 4:20 AM, Laszlo Papp lp...@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.

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.


 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.

Cheers,

Bruce

 ---
  .../recipes-support/openflow/openflow_1.0.bb   | 32 
 ++
  1 file changed, 32 insertions(+)
  create mode 100644 meta-networking/recipes-support/openflow/openflow_1.0.bb

 diff --git a/meta-networking/recipes-support/openflow/openflow_1.0.bb 
 b/meta-networking/recipes-support/openflow/openflow_1.0.bb
 new file mode 100644
 index 000..eb7770e
 --- /dev/null
 +++ b/meta-networking/recipes-support/openflow/openflow_1.0.bb
 @@ -0,0 +1,32 @@
 +SUMMARY = OpenFlow
 +DESCRIPTION = Open standard that enables researchers to run experimental 
 protocols in the campus networks
 +HOMEPAGE = http://www.openflow.org;
 +SECTION = networking
 +LICENSE = GPLv2
 +
 +LIC_FILES_CHKSUM = file://COPYING;md5=e870c934e2c3d6ccf085fd7cf0a1e2e2
 +
 +SRCREV = c84f33f09d5dbcfc9b489f64cb30475bf36f653a
 +PV = 1.0+git${SRCPV}
 +SRC_URI = git://gitosis.stanford.edu/openflow.git;protocol=git
 +
 +DEPENDS = virtual/libc
 +
 +EXTRA_OECONF += KARCH=${TARGET_ARCH}
 +
 +PACKAGECONFIG ??= libssl
 +PACKAGECONFIG[libssl] = --enable-ssl,--disable-ssl, openssl, libssl
 +
 +S = ${WORKDIR}/git
 +
 +inherit autotools
 +
 +do_configure() {
 +./boot.sh
 +oe_runconf
 +}
 +
 +do_install_append() {
 +   # Remove /var/run as it is created on startup
 +rm -rf ${D}${localstatedir}/run
 +}
 --
 1.8.4

 ___
 Openembedded-devel mailing list
 Openembedded-devel@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@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

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

[Laszlo Papp]

On Tue, Sep 3, 2013 at 2:56 AM, Bruce Ashfield bruce.ashfi...@gmail.comwrote:

 On Mon, Sep 2, 2013 at 4:20 AM, Laszlo Papp lp...@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.


 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.


  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
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.

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. :-)

Cheers,
Laszlo
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel