we use the ruby DSL for defining our environments, and berks to apply
versions locks to them.
so after modifying an environment ruby file we do this:
knife environment from file environments/myenvironment.rb
berks apply myenvironment
this all works great. however as i execute these commands there is a small
window in which the new environment is on the chef server without the
version locks. if any box where to run chef-client in this window it would
run with the latest versions of the cookbooks on the chef server, with
potentially disastrous results.
so my question is:
how do i avoid this?
i could download the json environment from the chef server (which includes
the version locks) to make modifications, but that is rather unsatisfying.
we use the ruby dsl to avoid managing endless repetitive json data
structures (which would be error prone to edit). for example the list of
hadoop slave servers is needed in a few different places in the
environment, and in the ruby dsl we define it once as a variable and re-use
it.
thanks! koert
Have you seen berksflow and the tool “blo”? That might help.
-Matt
On Apr 4, 2015, at 9:51 PM, Koert Kuipers koert@tresata.com wrote:
we use the ruby DSL for defining our environments, and berks to apply versions locks to them.
so after modifying an environment ruby file we do this:
$ knife environment from file environments/myenvironment.rb
$ berks apply myenvironment
this all works great. however as i execute these commands there is a small window in which the new environment is on the chef server without the version locks. if any box where to run chef-client in this window it would run with the latest versions of the cookbooks on the chef server, with potentially disastrous results.
so my question is:
how do i avoid this?
i could download the json environment from the chef server (which includes the version locks) to make modifications, but that is rather unsatisfying. we use the ruby dsl to avoid managing endless repetitive json data structures (which would be error prone to edit). for example the list of hadoop slave servers is needed in a few different places in the environment, and in the ruby dsl we define it once as a variable and re-use it.
thanks! koert
thanks. i have seen berksflow, and it looks very interesting, but it i am
not sure how it would solve my issue.
On Sun, Apr 5, 2015 at 11:13 AM, Matt Juszczak matt@atopia.net wrote:
Have you seen berksflow and the tool “blo”? That might help.
-Matt
On Apr 4, 2015, at 9:51 PM, Koert Kuipers koert@tresata.com wrote:
we use the ruby DSL for defining our environments, and berks to apply
versions locks to them.
so after modifying an environment ruby file we do this:
$ knife environment from file environments/myenvironment.rb
$ berks apply myenvironment
this all works great. however as i execute these commands there is a
small window in which the new environment is on the chef server without the
version locks. if any box where to run chef-client in this window it would
run with the latest versions of the cookbooks on the chef server, with
potentially disastrous results.
so my question is:
how do i avoid this?
i could download the json environment from the chef server (which
includes the version locks) to make modifications, but that is rather
unsatisfying. we use the ruby dsl to avoid managing endless repetitive json
data structures (which would be error prone to edit). for example the list
of hadoop slave servers is needed in a few different places in the
environment, and in the ruby dsl we define it once as a variable and re-use
it.
thanks! koert
I actually wrote this plugin[1] to help with that. It loads a
Berksfile.lock in an ruby Environment file.
[1] - GitHub - bbaugher/chef-berksfile-env: A Chef plugin to lock down your Chef Environment with a Berksfile
On Sun, Apr 5, 2015 at 3:34 PM Koert Kuipers koert@tresata.com wrote:
thanks. i have seen berksflow, and it looks very interesting, but it i am
not sure how it would solve my issue.
On Sun, Apr 5, 2015 at 11:13 AM, Matt Juszczak matt@atopia.net wrote:
Have you seen berksflow and the tool “blo”? That might help.
-Matt
On Apr 4, 2015, at 9:51 PM, Koert Kuipers koert@tresata.com wrote:
we use the ruby DSL for defining our environments, and berks to apply
versions locks to them.
so after modifying an environment ruby file we do this:
$ knife environment from file environments/myenvironment.rb
$ berks apply myenvironment
this all works great. however as i execute these commands there is a
small window in which the new environment is on the chef server without the
version locks. if any box where to run chef-client in this window it would
run with the latest versions of the cookbooks on the chef server, with
potentially disastrous results.
so my question is:
how do i avoid this?
i could download the json environment from the chef server (which
includes the version locks) to make modifications, but that is rather
unsatisfying. we use the ruby dsl to avoid managing endless repetitive json
data structures (which would be error prone to edit). for example the list
of hadoop slave servers is needed in a few different places in the
environment, and in the ruby dsl we define it once as a variable and re-use
it.
thanks! koert
sounds like it's exactly what i am looking for. great! i will give it a spin
On Mon, Apr 6, 2015 at 9:46 AM, Bryan Baugher bjbq4d@gmail.com wrote:
I actually wrote this plugin[1] to help with that. It loads a
Berksfile.lock in an ruby Environment file.
[1] - GitHub - bbaugher/chef-berksfile-env: A Chef plugin to lock down your Chef Environment with a Berksfile
On Sun, Apr 5, 2015 at 3:34 PM Koert Kuipers koert@tresata.com wrote:
thanks. i have seen berksflow, and it looks very interesting, but it i am
not sure how it would solve my issue.
On Sun, Apr 5, 2015 at 11:13 AM, Matt Juszczak matt@atopia.net wrote:
Have you seen berksflow and the tool “blo”? That might help.
-Matt
On Apr 4, 2015, at 9:51 PM, Koert Kuipers koert@tresata.com wrote:
we use the ruby DSL for defining our environments, and berks to apply
versions locks to them.
so after modifying an environment ruby file we do this:
$ knife environment from file environments/myenvironment.rb
$ berks apply myenvironment
this all works great. however as i execute these commands there is a
small window in which the new environment is on the chef server without the
version locks. if any box where to run chef-client in this window it would
run with the latest versions of the cookbooks on the chef server, with
potentially disastrous results.
so my question is:
how do i avoid this?
i could download the json environment from the chef server (which
includes the version locks) to make modifications, but that is rather
unsatisfying. we use the ruby dsl to avoid managing endless repetitive json
data structures (which would be error prone to edit). for example the list
of hadoop slave servers is needed in a few different places in the
environment, and in the ruby dsl we define it once as a variable and re-use
it.
thanks! koert
worked on the first try. thanks bryan
On Mon, Apr 6, 2015 at 10:09 AM, Koert Kuipers koert@tresata.com wrote:
sounds like it's exactly what i am looking for. great! i will give it a
spin
On Mon, Apr 6, 2015 at 9:46 AM, Bryan Baugher bjbq4d@gmail.com wrote:
I actually wrote this plugin[1] to help with that. It loads a
Berksfile.lock in an ruby Environment file.
[1] - GitHub - bbaugher/chef-berksfile-env: A Chef plugin to lock down your Chef Environment with a Berksfile
On Sun, Apr 5, 2015 at 3:34 PM Koert Kuipers koert@tresata.com wrote:
thanks. i have seen berksflow, and it looks very interesting, but it i
am not sure how it would solve my issue.
On Sun, Apr 5, 2015 at 11:13 AM, Matt Juszczak matt@atopia.net wrote:
Have you seen berksflow and the tool “blo”? That might help.
-Matt
On Apr 4, 2015, at 9:51 PM, Koert Kuipers koert@tresata.com wrote:
we use the ruby DSL for defining our environments, and berks to apply
versions locks to them.
so after modifying an environment ruby file we do this:
$ knife environment from file environments/myenvironment.rb
$ berks apply myenvironment
this all works great. however as i execute these commands there is a
small window in which the new environment is on the chef server without the
version locks. if any box where to run chef-client in this window it would
run with the latest versions of the cookbooks on the chef server, with
potentially disastrous results.
so my question is:
how do i avoid this?
i could download the json environment from the chef server (which
includes the version locks) to make modifications, but that is rather
unsatisfying. we use the ruby dsl to avoid managing endless repetitive json
data structures (which would be error prone to edit). for example the list
of hadoop slave servers is needed in a few different places in the
environment, and in the ruby dsl we define it once as a variable and re-use
it.
thanks! koert