Ok, Michael, and everyone else of course,
I’ve proposed the new module in a pull-request.
The module can be found here:
https://github.com/ansible/ansible-modules-extras/pull/110
The documentation (I chose to make an additional guide in the manual):
https://github.com/ansible/ansible/pull/9566
I see yeah, the symlink for the shared folder could be part of the module,
but could be outside it too.
I'm fine with it being there if that's an example.
On Mon, Nov 3, 2014 at 4:25 PM, Ramon de la Fuente
wrote:
> Hey Michael,
>
> Quick reply regarding the “shared folder”
>
> With most proje
Hey Michael,
Quick reply regarding the “shared folder”
With most projects there’s some form of state kept between releases. With web
projects this usually means server-side session files, but possibly also
user-generated content like uploaded files and such. All our projects have at
least one
>
>
> When we take a “deploy_helper" module into account, it could look like
> this:
>
> 1. deploy state=present path=/path/to/root
> - creates project root folder
> - returns a timestamp
> - creates the releases folder
> - creates the shared folder (optional)
> ~~~ clone, build, p
Hey Michael (and anyone else interested),
I’ve been working on the deploy_helper module, but it’s not ready for a
pull-request just yet.
>From the perspective of a consumer, I think a common deploy role looks
something like this (following along the lines of a deploy procedure that
uses releas
Nice, very much looking forward to this.
If you have a PR ready maybe reply to the list so you can make sure to get
our attention on it.
Thanks!!!
On Sat, Oct 25, 2014 at 5:02 PM, wrote:
> Hey All,
>
> Sorry about the radio silence on this thread, I kind of dropped the ball
> on this one :-
Hey All,
Sorry about the radio silence on this thread, I kind of dropped the ball on
this one :-(
I'm picking up where I left off, I'll work out the options for the module
to move this thing forward. I think my last ideas revolved around two
options for the module, one where we have a (semi)
"
Basically, I'm trying to use their deployment role as a whole, to perform
certain operations only on certain hosts, while leaving all the
hosts/groups, listed in the the main 'hosts' directive."
This is there too :)
ansible-playbook foo.yml --limit groupname
ansible-playbook foo.yml --limit hos
That's right. But I was referring to another thing.
Basically, I'm trying to use their deployment role as a whole, to perform
certain operations only on certain hosts, while leaving all the
hosts/groups, listed in the the main 'hosts' directive.
In my other roles, I've been using host_vars or e
"With capistrano, it is possible to run some of the tasks only on specific
hosts. Any plans for such a feature?"
This has been a feature in Ansible since day 1.
- hosts: hostnames
- hosts: otherhostnames
Etc
On Thu, Aug 14, 2014 at 7:42 AM, Dan Vaida wrote:
> Hello,
>
> Again, a very BIG t
Hello,
Again, a very BIG thank you for your efforts on the deploy module.
I would like to share my suggestion, perhaps as an idea to generate a
future pull request:
With capistrano, it is possible to run some of the tasks only on specific
hosts. Any plans for such a feature?
Problem is that in
Hi all!
A little introduction for context: I'm a college/employee of Ramon de la
Fuente, and we both maintain the f500.* roles in Galaxy. So when I refer to
"our module", that's the same module as the one Ramon refers to.
I'd like to sum up my thoughts on the discussion so far:
- We choose to
On Mon, Aug 4, 2014 at 5:43 PM, wrote:
>
>
> Having a module that has a couple of modes, one might be via action plugin
>> to register a consistent symlink timestamp, and another via standard module
>> to make one "the one", and to clean out older timestamps, seems to make a
>> lot of sense.
>>
>
Just wanted to add; this is almost exactly how we deploy PHP-based apps
(with a bunch of bash scripts currently :/) at my current workplace, and
having a built-in way to tidy up the process would be awesome.
On Monday, August 4, 2014 4:43:19 PM UTC-5, ra...@future500.nl wrote:
>
>
>
> Having a m
Having a module that has a couple of modes, one might be via action plugin
> to register a consistent symlink timestamp, and another via standard module
> to make one "the one", and to clean out older timestamps, seems to make a
> lot of sense.
>
> Maybe down the right track:
>
> # this would
On Mon, Aug 4, 2014 at 10:11 AM, Ramon de la Fuente
wrote:
> . Try/except would ease that pain a bit (but it wasn’t painful for us
> _not_ to have a central rollback at all).
>
Got it - yeah I want to have something for this in 1.8
>
> About the “action:” syntax idea:
> ** never actually used
I’ll try to get some things out of the way before responding to your (B).
About the "rollback”:
The point wasn't really about wether Capistrano does rollbacks or not (I’ll
accept that they’re not - I’m no expert on the subject), but more about how
complex things can become if you’re trying to im
So several things I wanted to comment on.
(A) What Cap calls rollbacks aren't - it would be a rollback if it
magically understood how to undo every action. That being said, some sort
of try/except facility is intended for 1.8. "Rollback" logic is up to
you, but failing forward is a better appr
Hey All,
I posted some thoughts on deploying with Ansible, specifically some
problems we tried to solve converting from Capistrano:
http://www.future500.nl/articles/2014/07/thoughts-on-deploying-with-ansible/
Michael de Haan pointed out that some of our "solutions" are deprecated for
security
19 matches
Mail list logo
