[chef] Re: Re: Re: Re: Re: Re: deleting objects from the chef server when deleted from git repo

["steve ." < >]

We've built a system around Jenkins that attempts to shore up trust in the Git repo.  It uses a volatile Chef server for testing purposes -- one testing assumption is that only the latest and greatest versions of everything will be tested, so version constraints are ignored.

I'm now looking at refactoring this system to use Librarian, but the biggest hurdle I see is determining when and what changed in one of the dependent Git repositories as a Jenkins build trigger.  I'm pretty sure this is going to end with me writing a Jenkins build trigger plugin and I have the feeling I am going to find that very unpleasant.

If this does, in fact, come to pass, I'll see about open-sourcing the build trigger.  (Sorry, I don't think I can offer up the entire system at present ... test-kitchen offers a subset of this functionality, though!)

On Tue, Nov 20, 2012 at 11:54 AM, Torben Knerr < " target="_blank"> > wrote:

Awesome, thanks for sharing!

Am 20.11.2012 20:32 schrieb "O. T. Suarez" < " target="_blank"> >:

Hi,
I wrote this post-receive hook trying to achieve the same goal:
https://gist.github.com/4075735#file_post_receive
To deploy a new server, you create a databag json file, commit and
push the file. Same for cookbooks, roles, etc. The hook uploads data
to the chef server and takes care of executing scripts, reporting
everything to an irc channel.
For the audit trail part, the knife execution is done by rundeck, the
url for the output is available on the irc channel.
The workflow is detailed on this blog post (sry, link in spanish,
english version coming up soon)
http://www.devops.com.ar/blog/2012/11/20/instalando-servidores-con-un-commit/
regards,
osvaldo


On Tue, Nov 20, 2012 at 4:19 PM, Torben Knerr < " target="_blank"> > wrote:
> Many times I thought of having only the git repo as the single source of
> truth, but since there seems to be no out-of-the-box solution for it kept
> just a thought.
>
> For one thing I want the single source of truth in a git repository. If I
> can't have that,  I'd like to have an audit trail at least...
>
> @Peter, Wes: would you mind sharing your scripts?
>
> Cheers, Torben
>
> Am 14.11.2012 23:31 schrieb "Wes Morgan" < " target="_blank"> >:
>
>>
>> On Nov 14, 2012, at 3:14 PM, Peter Donald < " target="_blank"> > wrote:
>>
>> > Hi,
>> >
>> > On Thu, Nov 15, 2012 at 8:11 AM, Wes Morgan < " target="_blank"> >
>> > wrote:
>> >> I finally got around to setting up a Jenkins job to upload changes to
>> >> the Chef server when I push them to the git repo. So far it's *great* having
>> >> one source of truth for my Chef data.
>> >>
>> >> However, the one remaining hole is deleting things from the Chef server
>> >> when they're deleted from the git repo. Is anyone already doing that in an
>> >> automated fashion? If so, what is your favorite approach?
>> >
>> > We actually use a fancy bit of ruby script using the spice gem that
>> > does uploads, deletes and runs a bunch of auditing and validation
>> > functions on the chef server. I have heard people have also done
>> > something similar with jclouds but never looked into it.
>>
>> >
>> > However a quick and dirty script may work just as well. Something like
>> >
>> > knife cookbook list | awk '{print $1}' | sort > server.txt
>> > ls cookbooks | sort > local.txt
>> > diff server.txt local.txt | grep '<' | awk '{print $2}' | xargs
>> > --verbose knife cookbook delete -y
>>
>> Brilliant, thanks.
>>
>> Running this made me remember that cookbooks aren't segregated by
>> organization in hosted Chef, so this would delete things that I don't want
>> to delete. Hmm, maybe this needs some more thought. I think deletes would
>> have to be triggered via git log parsing to get around that.
>>
>> >
>> >
>> > --
>> > Cheers,
>> >
>> > Peter Donald
>>
>