[LRUG] Idempotency vs the cloud

[Sam Phillips]

Another new option I don't think has been mentioned yet is orca:

https://github.com/andykent/orca

Which might be of interest.

In terms of the value of configuration management, we're (Shutl) a chef
shop and we're getting a great deal of value from it. But, it is a learning
curve and full of idiosyncrasies (nomenclature has already been
mentioned!). We're now at the point where we quickly delete and re-create
nodes and whole setups, and because of this we can be assured that our
software does not rely on state. And, because we run chef directly from a
OS-only AWS AMI, we're not investing time in hand-crafting AMIs that are
essentially black box masterpieces which are impossible to specify. This
also breaks our reliance on AWS :)

In terms of value, I think that it's important to remember that these are
different tools and frameworks to those than many developers are used to,
and that when it comes to learning these for the first time, you are a
beginner. This might sound like a tautology, but I think it's often
forgotten - you have to learn these tools in order for them to be useful to
you. They're not like a ruby gem that you just drop into your code.

Sam





On 17 July 2013 14:12, David Burrows <david at designsuperbuild.com> wrote:

> I think part of my similar fear of Chef/Puppet is that it's overkill for a
> lot of things I want to do, but I still want more than a bash script.
>
> Ansible [0] seems to be a better fit for small-to-medium size setups,
> although I've yet to use it in anger, anyone have any production experience
> of it?
>
> [0] http://ansibleworks.com/docs/gettingstarted.html
>
> --
> David Burrows
> 079 1234 2125
> @dburrows
>
> http://www.designsuperbuild.com/ | @dsgnsprbld
>
>
> On Wed, Jul 17, 2013 at 1:57 PM, David Salgado <david at digitalronin.com>wrote:
>
>> RDS also has the major (for some people) problem that you can't replicate
>> into or out of it without using separate tools. So, if you really need some
>> of your data local to your nodes, e.g. for performance reasons, RDS isn't
>> really an option.
>>
>>
>>
>> On 17 July 2013 13:48, Paul Battley <pbattley at gmail.com> wrote:
>>
>>> On 17 July 2013 12:55, Paul Robinson <paul at 32moves.com> wrote:
>>> > On this point I think right now you have a choice:
>>> >
>>> > 1. I'm too busy to think about this, I'll just pay for RDS from AWS
>>> and let them figure it out for me
>>> >
>>> > 2. I really care about this and not too busy, so I'll figure it out
>>> myself and get really annoyed when I realise MySQL's clustering is
>>> something my niece could have designed better and Postgres is not much
>>> better...
>>>
>>> If your problem fits (in terms of scale and capabilities required)
>>> into RDS, you'll probably be happy with that, especially since it's
>>> very easy to provision, duplicate, and maintain. However, I wouldn't
>>> pretend that it's a universal solution to data persistence. MySQL vs
>>> Postgres is hardly an exhaustive list of options!
>>>
>>> Paul.
>>> _______________________________________________
>>> Chat mailing list
>>> Chat at lists.lrug.org
>>> http://lists.lrug.org/listinfo.cgi/chat-lrug.org
>>>
>>
>>
>> _______________________________________________
>> Chat mailing list
>> Chat at lists.lrug.org
>> http://lists.lrug.org/listinfo.cgi/chat-lrug.org
>>
>>
>
> _______________________________________________
> Chat mailing list
> Chat at lists.lrug.org
> http://lists.lrug.org/listinfo.cgi/chat-lrug.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lrug.org/pipermail/chat-lrug.org/attachments/20130717/bd236e35/attachment-0003.html>