Hashicorp serf and go-crypto: which layer(s)?

Hashicorp serf and go-crypto: which layer(s)?

[Tim Orling]

I have a recipe for Hashicorp serf (latest release 0.8.5) which requires go-crypto. I’m currently planning to add go-crypto to meta-virtualization, but serf makes sense next to consul in meta-cloud-services. Currently, the README of m-c-s says its only layer dependency is oe-core.

What is the consensus? Should I add recipes-devtools/go/go-crypto_git.bb to m-c-s and keep serf next to consul, or should I add recipes-connectivity/serf/hashicorp-serf_0.8.5.bb to meta-virtualizaton and keep go-crypto with the other go source only packages?

Also, devtool picked up all the licenses from vendor/, so I am adding a vendor-licenses.inc file to help keep the serf bb file shorter. Other recipes in meta-virtualization, such as kubernetes, would also have a lot of vendor code…has anybody been concerned about licenses from vendor/ ?

Cheers,

—Tim

Re: [meta-virtualization] Hashicorp serf and go-crypto: which layer(s)?

[Bruce Ashfield]

On Tue, Dec 10, 2019 at 9:18 PM Tim Orling
<timothy.t.orling@linux.intel.com> wrote:
>
> I have a recipe for Hashicorp serf (latest release 0.8.5) which requires go-crypto. I’m currently planning to add go-crypto to meta-virtualization, but serf makes sense next to consul in meta-cloud-services. Currently, the README of m-c-s says its only layer dependency is oe-core.
>

heh. The m-c-s readme is wrong on that point ..

> What is the consensus? Should I add recipes-devtools/go/go-crypto_git.bb to m-c-s and keep serf next to consul, or should I add recipes-connectivity/serf/hashicorp-serf_0.8.5.bb to meta-virtualizaton and keep go-crypto with the other go source only packages?
>

I'd say the 2nd option is the right one. Add serf along side consul,
and go-crypto into meta-virt (and we can update the README for m-c-s
along the way).

> Also, devtool picked up all the licenses from vendor/, so I am adding a vendor-licenses.inc file to help keep the serf bb file shorter. Other recipes in meta-virtualization, such as kubernetes, would also have a lot of vendor code…has anybody been concerned about licenses from vendor/ ?
>

We've talked about this in the past, and yes, to be complete we really
need the vendored licenses along with the main package license. So I
think you are talking the right approach.

Bruce

> Cheers,
>
> —Tim-=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
>
> View/Reply Online (#4858): https://lists.yoctoproject.org/g/meta-virtualization/message/4858
> Mute This Topic: https://lists.yoctoproject.org/mt/68034443/1050810
> Group Owner: meta-virtualization+owner@lists.yoctoproject.org
> Unsubscribe: https://lists.yoctoproject.org/g/meta-virtualization/unsub  [bruce.ashfield@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-



-- 
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II

Re: [meta-virtualization] Hashicorp serf and go-crypto: which layer(s)?

[Tim Orling]

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

On Tue, Dec 10, 2019 at 11:20 PM Bruce Ashfield <bruce.ashfield@gmail.com>
wrote:

> On Tue, Dec 10, 2019 at 9:18 PM Tim Orling
> <timothy.t.orling@linux.intel.com> wrote:
> >
> > I have a recipe for Hashicorp serf (latest release 0.8.5) which requires
> go-crypto. I’m currently planning to add go-crypto to meta-virtualization,
> but serf makes sense next to consul in meta-cloud-services. Currently, the
> README of m-c-s says its only layer dependency is oe-core.
> >
>
> heh. The m-c-s readme is wrong on that point ..
>
> > What is the consensus? Should I add recipes-devtools/go/go-crypto_git.bb
> to m-c-s and keep serf next to consul, or should I add
> recipes-connectivity/serf/hashicorp-serf_0.8.5.bb to meta-virtualizaton
> and keep go-crypto with the other go source only packages?
> >
>
> I'd say the 2nd option is the right one. Add serf along side consul,
> and go-crypto into meta-virt (and we can update the README for m-c-s
> along the way).
>

Turns out I missed upstream serf change. They are now “vendoring” the part
of go-crypt that is needed. The dependency on external “source only”
go-crypt is therefore eliminated. Much easier!


> > Also, devtool picked up all the licenses from vendor/, so I am adding a
> vendor-licenses.inc file to help keep the serf bb file shorter. Other
> recipes in meta-virtualization, such as kubernetes, would also have a lot
> of vendor code…has anybody been concerned about licenses from vendor/ ?
> >
>
> We've talked about this in the past, and yes, to be complete we really
> need the vendored licenses along with the main package license. So I
> think you are talking the right approach.
>

Great. Patch inbound shortly.

Thank you for the sounding board guidance.


> Bruce
>
> > Cheers,
> >
> > —Tim-=-=-=-=-=-=-=-=-=-=-=-
> > Links: You receive all messages sent to this group.
> >
> > View/Reply Online (#4858):
> https://lists.yoctoproject.org/g/meta-virtualization/message/4858
> > Mute This Topic: https://lists.yoctoproject.org/mt/68034443/1050810
> > Group Owner: meta-virtualization+owner@lists.yoctoproject.org
> > Unsubscribe: https://lists.yoctoproject.org/g/meta-virtualization/unsub
> [bruce.ashfield@gmail.com]
> > -=-=-=-=-=-=-=-=-=-=-=-
>
>
>
> --
> - Thou shalt not follow the NULL pointer, for chaos and madness await
> thee at its end
> - "Use the force Harry" - Gandalf, Star Trek II
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
>
> View/Reply Online (#4874):
> https://lists.yoctoproject.org/g/meta-virtualization/message/4874
> Mute This Topic: https://lists.yoctoproject.org/mt/68034443/924729
> Group Owner: meta-virtualization+owner@lists.yoctoproject.org
> Unsubscribe: https://lists.yoctoproject.org/g/meta-virtualization/unsub  [
> ticotimo@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>

[-- Attachment #2: Type: text/html, Size: 4862 bytes --]