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 ([email protected]) 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 [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/ansible-project/etPan.53e1d753.74b0dc51.16593%40malus.nerdsweide.
For more options, visit https://groups.google.com/d/optout.
