Good point, David. The mentioned libray is really only useful if you have a chef server setup somewhere, as most code is related to the chef rest api.
Thx, Adrian On Aug 29, 2011 8:42 AM, "David Alves" <[email protected]> wrote: > Hi Adrian > > We could/should probably try and figure out a common provisioning abstraction. > Regarding your suggestion, the clouds lib for automated bootstrap would be nice, but am I wrong in assuming it is designed to work with a chef-server instance (from what i gather from the quick start page)? > For now at least, I (we?) probably don't need a full fledged chef deployment, the "service" I implemented manages with chef-solo, i.e. it is not actually a service as there is no daemon running. It just bootstraps ruby and chef, downloads central repo cookbooks and allows to execute recipes from cookbooks provided by url. > For long lived services and in cases where configuration must be changed during the life time of a service using chef-server would be a better option and we could do a deployment similar to ganglia's (one server all others are clients). > > -david > > On Aug 29, 2011, at 4:14 PM, Adrian Cole wrote: > >> Hi, David. >> >> Thanks for looking into this and also thinking about puppet impl. >> There's a lot of common ground between these things, so definitely the >> issues should at least be linked with your commentary. >> >> An aside, which is related. jclouds has a chef library that handles >> things like cookbook queries and automated bootstrap. This is under >> continuous integration at CloudBees, but I'm not positive it is being >> published to sonatype/central, yet. >> >> Another thing is I'm not sure it has been updated to Chef 10, yet. >> >> Here's some code that might be interesting (note this uses the word >> "tag" which should be "group"): >> >> if (any(cookbookVersions, containsRecipe(recipe))) { >> List<String> runList = new RunListBuilder().addRecipe(recipe).build(); >> chefContext.getChefService().updateRunListForTag(runList, tag); >> } >> >> bootstrap = >> chefContext.getChefService().createClientAndBootstrapScriptForTag(tag); >> >> nodes = computeContext.getComputeService().createNodesInGroup(tag, >> 1, runScript(bootstrap)); >> >> Here's a few links in case you are interested: >> >> https://github.com/jclouds/jclouds-chef/wiki/Quick-Start >> https://github.com/jclouds/jclouds-chef/wiki/Compute-Integration >> https://github.com/jclouds/jclouds-chef/blob/master/compute/src/test/java/org/jclouds/chef/compute/ChefComputeServiceLiveTest.java >> >> If you are interested in this, I can help dust it off a bit. >> -Adrian >> >> On Fri, Aug 26, 2011 at 10:05 AM, David Alves <[email protected]> wrote: >>> Hi All >>> >>> I implemented a chef service. >>> The service itself installs ruby and chef-solo and it provides easy to use classes to run recipes on the cluster that could be used by other services. >>> >>> I still has some limitations as I only tested in rackspace, the implementation for RHEL based distros is still partly missing, and it only accepts cookbooks by url (does not fetch them from the central repo yet). Nonetheless it might be interesting to someone else. >>> >>> My question is: >>> - I got a sense from the puppet issue that another direction was decided in terms of provisioning (e.g., not making chef or puppet common services but part of a provisioning abstraction). Did I misunderstand? is it still worth attaching the patch to the chef issue? >>> >>> Cheers >>> David Alves >>> >
