Lwrp based on the omnibus configuration DSL?


#1

Some time ago, I created the ark LWRP to handle the unpack, configure,
link, install dance. I was never quite happy with it, primarily because it
conflated two separate concerns that are best handled by diffferent LWRPS,

  1. getting a tarball and 2) configuring its contents along the
    configure-make-symlink lines. I have written a new LWRP for doing the
    download part and I hope I get the chance to open-source it some time soon.
    I really like the Configuration DSL from omnibus
    https://github.com/opscode/omnibus-ruby. Has anyone written an LWRP base on
    the omnibus configuration DSL? I hope someone has saved me the trouble.

#2

Hi,

On Fri, Jul 26, 2013 at 2:29 AM, Bryan Berry bryan.berry@gmail.com wrote:

Some time ago, I created the ark LWRP to handle the unpack, configure, link,
install dance. I was never quite happy with it, primarily because it
conflated two separate concerns that are best handled by diffferent LWRPS,

  1. getting a tarball and 2) configuring its contents along the
    configure-make-symlink lines. I have written a new LWRP for doing the
    download part and I hope I get the chance to open-source it some time soon.

Just as a heads up I started down the same path with [1] and have
started using it fairly extensively on both windows and linux. I did
run into a few issues with regards to symlinks under windows as the
builtin link resource does not work on windows when the target is
updated.

Other than that I am fairly happily using it to do versioned archive
downloads on multiple platforms. On both platforms I tend to have
downstream build steps that use notifications.

One of the pain points was different applications requiring/wanting
different layouts. Although it has yet to be fully merged upstream I
ended up going down the path of having to support multiple strategies
for dealing with different layouts. From memory, some of the
strategies looked like

/usr/local/foo -> /usr/local/foo-2.3

vs

/usr/local/foo/versions/current -> /usr/local/foo/versions/2.3

vs

/usr/local/foo/cur -> /usr/local/foo/2.3

etc

Anyhoo I would e very interested in seeing what you have come up with.
As the work on archive was initially inspired by ark

[1] https://github.com/realityforge/chef-archive

Cheers,

Peter Donald


#3

I’ve started using https://github.com/RiotGames/artifact-cookbook. It
has two LWRPs: artifact_deploy and artifact_file. artifact_deploy does
the whole dance with hooks at several points in the process for doing
extra work. It support Nexus repos, S3, plain old HTTP, and even local
files, and the archives can be zips or tarballs.

Greg

On 07/25/13 11:29, Bryan Berry wrote:

Some time ago, I created the ark LWRP to handle the unpack, configure,
link, install dance. I was never quite happy with it, primarily
because it conflated two separate concerns that are best handled by
diffferent LWRPS, 1) getting a tarball and 2) configuring its contents
along the configure-make-symlink lines. I have written a new LWRP for
doing the download part and I hope I get the chance to open-source it
some time soon. I really like the Configuration DSL from omnibus
https://github.com/opscode/omnibus-ruby. Has anyone written an LWRP
base on the omnibus configuration DSL? I hope someone has saved me the
trouble.


#4

@Peter,

nice work on chef-archive, I hope i can show you my new LWRP some time
soon. It is tentatively called “thunderball” as in a tar ball coming
from the clouds.

@Greg, I am embarrassed to say i hadn’t looked at artifact-cookbook
very closely. It has some awesome features but doesn’t quite handle
what I am looking for. I hate to build yet another LWRP for a similar
task but I am pretty committed to using to using a DSL similar to one
in omnibus

here is a an example of what i have in mind

On Wed, Jul 31, 2013 at 5:15 AM, Greg Symons gsymons@drillinginfo.com wrote:

I’ve started using https://github.com/RiotGames/artifact-cookbook. It has
two LWRPs: artifact_deploy and artifact_file. artifact_deploy does the whole
dance with hooks at several points in the process for doing extra work. It
support Nexus repos, S3, plain old HTTP, and even local files, and the
archives can be zips or tarballs.

Greg

On 07/25/13 11:29, Bryan Berry wrote:

Some time ago, I created the ark LWRP to handle the unpack, configure, link,
install dance. I was never quite happy with it, primarily because it
conflated two separate concerns that are best handled by diffferent LWRPS,

  1. getting a tarball and 2) configuring its contents along the
    configure-make-symlink lines. I have written a new LWRP for doing the
    download part and I hope I get the chance to open-source it some time soon.
    I really like the Configuration DSL from omnibus
    https://github.com/opscode/omnibus-ruby. Has anyone written an LWRP base on
    the omnibus configuration DSL? I hope someone has saved me the trouble.

#5

Not what you were asking about, but why don’t you use omnibus to build
these packages then just install them via chef-client (remote_file +
gdebi/yum)? Maybe with some tooling around omnibus-ruby and vagrant and
you could have a CI pipeline for them as well.

It feels “odd” to be compiling a bunch of stuff at deployment time. Yes, I
admit to doing it, but I’ve never been happy doing it.

Shamelss plug: https://github.com/bakins/omnibus-nginx - patches welcome. A
"directory" of omnibus projects would be helpful to avoid duplicated
effort, or at least to be used as examples.


#6

hey Brian, I sometimes do compile stuff in chef runs, often for developer setups

as for production scenarios, i rarely use ./configure && make && make
install but i do often
do several arbitrary steps after unpacking a tarball, esp. for dynamic
languages like python or ones w/ bytecode interpreters like java

I don’t actually use nginx, i just used it for an example. Most of my
current apps are either ruby, java, or python

On Wed, Jul 31, 2013 at 3:06 PM, Brian Akins brian@akins.org wrote:

Not what you were asking about, but why don’t you use omnibus to build these
packages then just install them via chef-client (remote_file + gdebi/yum)?
Maybe with some tooling around omnibus-ruby and vagrant and you could have a
CI pipeline for them as well.

It feels “odd” to be compiling a bunch of stuff at deployment time. Yes, I
admit to doing it, but I’ve never been happy doing it.

Shamelss plug: https://github.com/bakins/omnibus-nginx - patches welcome. A
"directory" of omnibus projects would be helpful to avoid duplicated effort,
or at least to be used as examples.


#7

On Wed, Jul 31, 2013 at 9:14 AM, Bryan Berry bryan.berry@gmail.com wrote:

i do often
do several arbitrary steps after unpacking a tarball, esp. for dynamic
languages like python or ones w/ bytecode interpreters like java

We’ve got bitten several times when we’ve made deployments “smart.” Maybe
a philosophical discussion but we are trying to move as much as possible
into the build phase.

Not pointed at you or your situation, just an opportunity to vent :wink:

Sorry for the thread-jack :wink: