action: "{{ item.module }} {{ item.parameters }}"
--
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.
To post to this group, send email to ansible...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/c0234581-5a8d-4797-b35f-fd8756d721e3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
. Try/except would ease that pain a bit (but it wasn’t painful for us _not_ to have a central rollback at all).
About the “action:” syntax idea:
** never actually used **
It was an idea using (abusing) the old notation of Ansible to allow writing a more flexible role in Galaxy. The point is allowing certain moments where the consumer of the role can add their own actions, without having to copy the role.
— it is understood that this idea will not work.
** currently used in ansible-project_deploy role **
Having a configurable list, that is used “with_items” and the “command” module (could be shell module). The reason is the same, to allow consumers of the role to perform commands that are not part of the deploy role by default.
Answer to (B):
We worked hard to make an easy to re-use role. The only things we found worthy of adding to a module where:
- state=present: the automatic creation of the folder structure. The module will also create a new timestamp and return that in a fact, and delete any folders containing a “BUILD_UNFINISHED” file.
- state=clean: the automatic removal of old releases (which also makes assumptions on the folder structure).
- state=absent: removal of the entire deploy folder (just to be consistent, could be done with the file module already)
All-in-all I think we went with your mantra when people start suggesting deploy modules: “It sounds like a role to me”
To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/etPan.53df94a0.79e2a9e3.1519%40fzzbook.lan.
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 have to be a bypass host loop plugin or something to get a consistent timestamp, but maybe we don't care- deploy_prepare:register: deploy_timestamp
- deploy_helper: timestamp={{ deploy_timestamp.time }} base=/opt/baseregister: where_to
# git checkout to where_to.path
# symlink latest dir into live and remove other symlinks- deploy_helper: timestamp={{ deploy_timestamp.time }} base=/opt/base live=/opt/live clean=yes
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 have to be a bypass host loop plugin or something to get a consistent timestamp, but maybe we don't care- deploy_prepare:register: deploy_timestamp- deploy_helper: timestamp={{ deploy_timestamp.time }} base=/opt/baseregister: where_toFor the deploys we do with our galaxy role, a consistent timestamp is not an issue (small projects, single hosts). But for something in core, I would expect the ability to create a single timestamp for all hosts. I also really like the idea of a separate deploy_helper module that takes in this timestamp - but I remarked in my blogpost that a timestamp isn't really required (I gave 'commit hash' as an example folder name).
Perhaps:- deploy_helper: release_version={{ deploy_timestamp.time }} base=/opt/baseregister: where_toWhich allows for:- deploy_helper: release_version={{ my_own_versioning_implementation }} base=/opt/baseregister: where_to# git checkout to where_to.pathI'm assuming "where_to.path" is the release-path-with-timestamp, and that this line is a placeholder for anything that goes on before the actual release is ready.Question: does the deploy_helper assume a folder structure?So in this case: would the where_to.path point to "/opt/base/releases/{{ timestamp }}" ?
Our role currently places a file called "BUILD_UNFINISHED" in the where_to.path, and uses that file to remove failed builds (any folder containing it will die in the startup of the next deploy). That helped us out also, not having to identify where the "current" symlink is pointing to. Does that sound logical?Param: unfinished_file=BUILD_UNFINISHED (or yes/no, with a fixed value maybe)
# symlink latest dir into live and remove other symlinks- deploy_helper: timestamp={{ deploy_timestamp.time }} base=/opt/base live=/opt/live clean=yesAgain: does this assume a folder structure?So in this case, the symlink would become: /opt/live -> /opt/base/releases/{{ timestamp }} ?And any old releases in /opt/base/releases would be removed?
(sorry for al the questions, I'm trying to map your example to my actual cases)
--
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.
To post to this group, send email to ansible...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/992523ce-aa09-4c34-8137-2b730b258ccb%40googlegroups.com.
--
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.
To post to this group, send email to ansible...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/c2b8e4c7-e5a5-4437-9508-bc9717d5e1a5%40googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/6020a5d1-7e19-4e90-859b-8c28136648d3%40googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/0b5ecc2c-befc-459c-a260-fc4e6b09f4c9%40googlegroups.com.
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, prepare ~~~ (outside of the scope of the module)1. deploy state=finalize- removes build in progress file- creates a symlink- optionally does cleanup-----------------------------------------This could be done in 2 tasks (+1 if we exclude the ‘shared' folder creation from the module)
Looking at the options required, the module might take on this signature:deploy_helper parameters:required:path= /path/to/project-rootnot required:release= (default: timestamp)owner= (default: null)group= (default: null)mode= (default: null)keep_releases= (default: 5)create_shared_folder= (default: true)releases_path= (default: {{ path }}/releases)shared_path= (default: {{ path }}/shared)current_path= (default: {{ path }}/current)unfinished_filename= (default: DEPLOY_UNFINISHED)
state=[ present, absent, clean, finalize, query ] (default: present)Besides your general opinion, I was pondering the following practical questions:1: What category of module would this module be under? File?
2: Should the (optional) creation of a shared folder be part of a deploy module?
3: Should we even be duplicating code like creation of the symlink? The file module already does that...
Thanks for any feedback, kind regards,
To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/d7e4efab-9bac-4204-a5cb-c32a9902d395%40googlegroups.com.
You received this message because you are subscribed to a topic in the Google Groups "Ansible Project" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/ansible-project/R3Kr2uMYUt4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to ansible-proje...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/CA%2BnsWgzRvoLQ_H%3DPV4yFkaNWdDdROhXY-KxKoDUwMEK3XuDLmQ%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/etPan.5457f2df.6b8b4567.c680%40FzzBook.fritz.box.
To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/CA%2BnsWgxPaNi5Gjz_qHmnihKk8CVtRqrJg-2SXOfUZAkktJCT6g%40mail.gmail.com.