All of
 help / color / mirror / Atom feed
From: "Bruce Ashfield" <>
To: "Robert P. J. Day" <>
Subject: Re: [meta-virtualization] what is the state of meta-cloud-services, re: chef/puppet/ruby recipes?
Date: Sun, 27 Dec 2020 14:20:41 -0500	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Sat, Dec 26, 2020 at 1:28 PM Robert P. J. Day <> wrote:
>   followup to earlier post of mine on main yocto mailing list, now
> that i realize this is the right place.
>   using gatesgarth version of layers, i want to test build puppet,
> chef and a number of ruby recipes, then dig into how to extend/create
> my own ruby recipes, but i want to first verify what shape the
> meta-cloud-services layer is in.
>   if i use "qemux86-64" as my target, i started off with "bitbake
> puppet" and that seemed to work (it didn't in earlier versions, but i
> see no point rehashing that here).
>   i then moved on to "bitbake chef", hoping to verify that an
> absolutely generic build would work -- customization would come
> later. now, even though chef doesn't need "yard", it does depend on
> yard-native, and i have other needs for "yard" later so i tried:
>   $ bitbake yard
> and got:
> ERROR: yard- do_fetch: Fetcher failure: Unable to find
> revision d83194e1a09098ec5be28b616cde3b9a15380873 in branch master
> even from upstream
> ERROR: yard- do_fetch: Fetcher failure for URL:
> 'git://'. Unable to fetch URL from any
> source.
> ERROR: Logfile of failure stored in:
> /home/rpjday/oe/builds/puppet/build/tmp/work/core2-64-poky-linux/yard/
> ERROR: Task
> (/home/rpjday/oe/dist/layers/meta-cloud-services/meta-openstack/recipes-devtools/ruby/
> failed with exit code '1'
> well, there's an obvious reason for that -- yard is one of the many
> recipes that succumbed to political correctness and renamed "master"
> to "main", so a quick patch:
>    SRC_URI = " \
>   -    git:// \
>   +    git://;branch=main \
>        "
> resolved that issue and i got a build for yard, but that's a bit
> worrisome -- that seems like a really blatant error in that it clearly
> won't even allow yard to build. obviously, i can submit a patch, but
> it makes me wonder what other trivial gotchas are waiting for me.
>   with that patch in place, i figured i'd try the following, which i
> would need for chef, anyway:
>   $ bitbake yard-native
> ERROR: yard-native- do_compile: Execution of
> '/home/rpjday/oe/builds/puppet/build/tmp/work/x86_64-linux/yard-native/'
> failed with exit code 1:
> ERROR:  Gemspec file not found: yard-native.gemspec.gemspec
>   i'm still digging into gemspec files, but it looks really weird that
> the file suffix is ".gemspec.gemspec", as if the code somewhere is
> accidentally adding one of the suffixes, not realizing something else
> will be adding it a second time.
>   am i investing my time wisely? has anyone else got a working
> puppet/chef/general ruby build environment up and running? sorry for
> not being more specific, but i don't want to spend hours only to find
> that no one is looking after this layer.

meta-cloud-services itself is maintained, but it doesn't go through
global builds or extensive system level testing.

We are keeping the recipes that different users care about, up to
date, and building against the specified yocto release. But other
layers (like meta-openstack) are in a state of waiting for interest
and contributors to become fully functional again.

I'm also migrating some parts of meta-cloud-services to meta-virt
(i.e. I just pulled cloud-init over), when they get broader interest
or have a more generic use case.

As for the chef/puppet parts, the original implementation was
problematic, so I had to undo parts of its recipe changes, and we
haven't had a call for using it as a deployment method since. So the
base support is still around, but as for using it to deploy an image,
that work is custom and typically (if at all) done in other layers.
Just like other parts, I'd spruce it up (or move recipes around to
other layers), if we get more interest.

No one has done much with the ruby support in quite some time, so it
would need work as well. I thought there was a meta-ruby floating
around, but I couldn't find it on the layerindex, so it looks like
just oe-core + some work would be required.


> rday

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

  reply	other threads:[~2020-12-27 19:20 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-26 18:28 what is the state of meta-cloud-services, re: chef/puppet/ruby recipes? Robert P. J. Day
2020-12-27 19:20 ` Bruce Ashfield [this message]
2021-01-02 14:20   ` [meta-virtualization] " Robert P. J. Day
2021-01-05 21:27     ` Bruce Ashfield
2021-01-02 20:07   ` Robert P. J. Day
2021-01-05 21:31     ` Bruce Ashfield

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='' \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.