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 even defined the host vars
in the 'hosts' file and used those vars as flags for acting or not on some
particular tasks.
To nail it down, I am deploying on 10 nodes and each is having a custom
connection string to its own Redis node. That would be handled via the
/private folder, but I can't see a built-in way for their deployment role
to do this.
Perhaps I'm not looking at it from the right angle.
On Thursday, 14 August 2014 14:00:30 UTC+2, Michael DeHaan wrote:
>
> "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 <vaid...@gmail.com
> <javascript:>> wrote:
>
>> 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 the /shared folder, I have stuff that's being shared
>> between releases but ALSO some mounted nfs shares. I think I will create
>> another directory in deployment root called /mounts for the NFS purposes,
>> to avoid confusion and workarounds.
>> Regardless, I think the host filter feature would come in handy.
>>
>> P.S. for us, it's important to have a simple rollback functionality so
>> you might see a fork/pr soon.
>>
>>
>> On Wednesday, 6 August 2014 15:05:14 UTC+2, Jasper N. Brouwer wrote:
>>
>>> 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 use the same directory layout as Capistrano does:
>>>
>>> /opt/base/current -> /opt/base/releases/{timestamp}
>>> /opt/base/releases/
>>> /opt/base/shared/
>>>
>>> "shared" is used for stuff that needs to survive a deploy (uploads,
>>> etc).
>>>
>>> The main reason we chose this is because it will be familiar to people
>>> who have used Capistrano. Plus we didn't see anything wrong with this
>>> layout, it suits our needs perfectly.
>>>
>>> We could make the exact file/directory names configurable though.
>>>
>>>
>>> - I agree we need something to create a consistent timestamp (or
>>> whatever) to be used on all hosts.
>>>
>>> And this probably doesn't have to be a timestamp. The reason we choose a
>>> timestamp is because it helps determine which releases should be cleaned
>>> up. We can simple order them and keep the latest X.
>>>
>>> I suspect it should be possible to stat those directories for a
>>> creation-date, and use them for the cleanup. The directory name itself can
>>> then be whatever you like (unix timestamp, yyyymmddhhmmss style timestamp,
>>> commit hash, uuid, etc).
>>>
>>>
>>> - Our current role also sets some facts, which are really convenient to
>>> have around:
>>>
>>> base_path: <must be provided through a required option>
>>> current_symlink: <base_path>/current
>>> releases_path: <base_path>/releases
>>> shared_path: <base_path>/shared
>>> current_release: <the release-timestamp/whatever that
>>> current_symlink points to>
>>> current_release_path: <base_path>/releases/<current_release>
>>> new_release: <the given/generated release-timestamp/whatever>
>>> new_release_path: <base_path>/releases/<new_release>
>>> unfinished_file: BUILD_UNFINISHED
>>>
>>> I'd like the core module to have these as well. Any thoughts on
>>> additions or changes are more than welkom!
>>>
>>>
>>> - The cleanup process we use is 2-fold: First we remove any releases
>>> that still contain the BUILD_UNFINISHED file. Next we remove any releases
>>> that exceed a configurable amount (keep 5 releases for example).
>>>
>>> This 2-fold process is very important to us, because we don't want to
>>> accidentally fail 5 releases in a row and have the cleanup process remove
>>> any older releases, therefor be left with only broken releases. The
>>> releases that are kept must be successful ones.
>>>
>>> And, we don't have this yet, but I think the cleanup should never remove
>>> the active release (the one the symlink points to), even if it's considered
>>> old). So it has to safeguard that.
>>>
>>>
>>> --
>>> Jasper N. Brouwer
>>> (@jaspernbrouwer)
>>>
>>>
>>> On 5 August 2014 at 18:29:00, Michael DeHaan (mic...@ansible.com)
>>> wrote:
>>> > Yeah, good point, and may not be an issue anywhere really because of
>>> the
>>> > symlink, if there's good enough cleanup options.
>>> >
>>> > Not requiring that seems like it would be a nice shortcut, provided
>>> that
>>> > the module could be called to register what the "latest" was if you
>>> didn't
>>> > pass too many arguments.
>>> >
>>> > ...
>>> >
>>> > I think it would only assume a timestamp dir in base, but it could
>>> default
>>> > to make a subdir called "releases", sure.
>>> >
>>> > I think as long as we document what it does we could make up a
>>> convention,
>>> > because it's going to change the way you deploy your app a little bit,
>>> and
>>> > you would not have to use unless you wanted...
>>> >
>>> > ...
>>> >
>>> > This sounds pretty cool to me.
>>> >
>>> > ...
>>> >
>>> > I think maybe you might need to pass a parameter to remove the other
>>> ones,
>>> > and it could be optional.
>>> >
>>> > ...
>>> >
>>> > Yeah something like what you have, if not exactly, as a module seems
>>> really
>>> > really cool to me.
>>>
>>>
>>> --
>> You received this message because you are subscribed to the Google Groups
>> "Ansible Project" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to ansible-proje...@googlegroups.com <javascript:>.
>> To post to this group, send email to ansible...@googlegroups.com
>> <javascript:>.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/ansible-project/c2b8e4c7-e5a5-4437-9508-bc9717d5e1a5%40googlegroups.com
>>
>> <https://groups.google.com/d/msgid/ansible-project/c2b8e4c7-e5a5-4437-9508-bc9717d5e1a5%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
--
You received this message because you are subscribed to the Google Groups
"Ansible Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to ansible-project+unsubscr...@googlegroups.com.
To post to this group, send email to ansible-project@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/ansible-project/6020a5d1-7e19-4e90-859b-8c28136648d3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
