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

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

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

[Bruce Ashfield]

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

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

[Laszlo Papp]

On Tue, Sep 3, 2013 at 2:56 AM, Bruce Ashfield <bruce.ashfield@gmail.com>wrote:

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

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

[Bruce Ashfield]

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

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

[Laszlo Papp]

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

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

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

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


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

> On Mon, Sep 2, 2013 at 11:55 PM, Laszlo Papp <lpapp@kde.org> wrote:
> > On Tue, Sep 3, 2013 at 2:56 AM, Bruce Ashfield <bruce.ashfield@gmail.com
> >wrote:
> >
> >> On Mon, Sep 2, 2013 at 4:20 AM, Laszlo Papp <lpapp@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: [meta-networking][PATCH] openflow: Add latest from git

[Bruce Ashfield]

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

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

[Laszlo Papp]

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

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

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

[Joe MacDonald]

[-- Attachment #1: Type: text/plain, Size: 5320 bytes --]

[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.ashfield@gmail.com>
> wrote:
> 
>     On Tue, Sep 3, 2013 at 9:13 AM, Laszlo Papp <lpapp@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 the scenes in private.
> The more eyes, the better.

-- 
-Joe MacDonald.
:wq

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]

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

[Joe MacDonald]

[-- Attachment #1: Type: text/plain, Size: 6115 bytes --]

[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.ashfield@gmail.com>
> > wrote:
> > 
> >     On Tue, Sep 3, 2013 at 9:13 AM, Laszlo Papp <lpapp@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 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.
> 
-- 
-Joe MacDonald.
:wq

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]

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

[Joe MacDonald]

[-- Attachment #1: Type: text/plain, Size: 10223 bytes --]

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@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.ashfield@gmail.com>wrote:
> >
> >> On Mon, Sep 2, 2013 at 11:55 PM, Laszlo Papp <lpapp@kde.org> wrote:
> >> > On Tue, Sep 3, 2013 at 2:56 AM, Bruce Ashfield <bruce.ashfield@gmail.com
> >> >wrote:
> >> >
> >> >> On Mon, Sep 2, 2013 at 4:20 AM, Laszlo Papp <lpapp@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
> >>
> > _______________________________________________
> > Openembedded-devel mailing list
> > Openembedded-devel@lists.openembedded.org
> > http://lists.openembedded.org/mailman/listinfo/openembedded-devel
> 
> 
> 
-- 
-Joe MacDonald.
:wq

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]

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

[Bruce Ashfield]

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

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

 - Now that everyone is aware of the specific use case, we can watch and
   coordinate updates in the future ?

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@gmail.com>wrote:
>> >
>> >> On Mon, Sep 2, 2013 at 11:55 PM, Laszlo Papp <lpapp@kde.org> wrote:
>> >> > On Tue, Sep 3, 2013 at 2:56 AM, Bruce Ashfield <bruce.ashfield@gmail.com
>> >> >wrote:
>> >> >
>> >> >> On Mon, Sep 2, 2013 at 4:20 AM, Laszlo Papp <lpapp@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
>> >>
>> > _______________________________________________
>> > Openembedded-devel mailing list
>> > Openembedded-devel@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"

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

[Joe MacDonald]

On Tue, Sep 3, 2013 at 6:39 PM, Bruce Ashfield <bruce.ashfield@gmail.com> wrote:
>
> On Tue, Sep 3, 2013 at 5:08 PM, Joe MacDonald <joe@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@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 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@gmail.com>wrote:
> >> >
> >> >> On Mon, Sep 2, 2013 at 11:55 PM, Laszlo Papp <lpapp@kde.org> wrote:
> >> >> > On Tue, Sep 3, 2013 at 2:56 AM, Bruce Ashfield <bruce.ashfield@gmail.com
> >> >> >wrote:
> >> >> >
> >> >> >> On Mon, Sep 2, 2013 at 4:20 AM, Laszlo Papp <lpapp@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
> >> >>
> >> > _______________________________________________
> >> > Openembedded-devel mailing list
> >> > Openembedded-devel@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

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

[Bruce Ashfield]

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

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.

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

Agreed. Stuff happens, we are aware and we'll do our best.

Cheers,

Bruce

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



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"

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

[Joe MacDonald]

[-- Attachment #1: Type: text/plain, Size: 1254 bytes --]

[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 <joe@deserted.net> wrote:
> > On Tue, Sep 3, 2013 at 6:39 PM, Bruce Ashfield <bruce.ashfield@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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]

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

[Bruce Ashfield]

On Wed, Sep 4, 2013 at 5:04 PM, Joe MacDonald <joe@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 <joe@deserted.net> wrote:
>> > On Tue, Sep 3, 2013 at 6:39 PM, Bruce Ashfield <bruce.ashfield@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"

Re: [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.ashfield@gmail.com> wrote:
>>
>> On Tue, Sep 3, 2013 at 5:08 PM, Joe MacDonald <joe@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@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 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@gmail.com>wrote:
>>>>>
>>>>>> On Mon, Sep 2, 2013 at 11:55 PM, Laszlo Papp <lpapp@kde.org> wrote:
>>>>>>> On Tue, Sep 3, 2013 at 2:56 AM, Bruce Ashfield <bruce.ashfield@gmail.com
>>>>>>> wrote:
>>>>>>>
>>>>>>>> On Mon, Sep 2, 2013 at 4:20 AM, Laszlo Papp <lpapp@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
>>>>>>
>>>>> _______________________________________________
>>>>> Openembedded-devel mailing list
>>>>> Openembedded-devel@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"
> 
> 
> 
> 

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

[Laszlo Papp]

On Wed, Sep 4, 2013 at 2:13 PM, Philip Balister <philip@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.

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

[Joe MacDonald]

[-- Attachment #1: Type: text/plain, Size: 16409 bytes --]

[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@gmail.com> wrote:
> >>
> >> On Tue, Sep 3, 2013 at 5:08 PM, Joe MacDonald <joe@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@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@gmail.com>wrote:
> >>>>>
> >>>>>> On Mon, Sep 2, 2013 at 11:55 PM, Laszlo Papp <lpapp@kde.org> wrote:
> >>>>>>> On Tue, Sep 3, 2013 at 2:56 AM, Bruce Ashfield <bruce.ashfield@gmail.com
> >>>>>>> wrote:
> >>>>>>>
> >>>>>>>> On Mon, Sep 2, 2013 at 4:20 AM, Laszlo Papp <lpapp@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
> >>>>>>
> >>>>> _______________________________________________
> >>>>> Openembedded-devel mailing list
> >>>>> Openembedded-devel@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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]

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

[Joe MacDonald]

[-- Attachment #1: Type: text/plain, Size: 2505 bytes --]

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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]

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

[Bruce Ashfield]

On Wed, Sep 4, 2013 at 5:14 PM, Joe MacDonald <joe@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 <grg@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 0000000..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"

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

[Burton, Ross]

On 5 September 2013 05:39, Bruce Ashfield <bruce.ashfield@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 <grg@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

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

[Laszlo Papp]

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

> On 5 September 2013 05:39, Bruce Ashfield <bruce.ashfield@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 <grg@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
>

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

[Joe MacDonald]

[-- Attachment #1: Type: text/plain, Size: 1431 bytes --]

[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.ashfield@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 <grg@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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]

Re: [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 <joe@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.ashfield@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 <grg@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
>
>

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

[Joe MacDonald]

[-- Attachment #1: Type: text/plain, Size: 4484 bytes --]

[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 <joe@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 <grg@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 0000000..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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]

Re: [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 <joe@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 0000000..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
>