Thanks! As for tests, definitely not - integration tests submitted with modules are great to have.
On Mon, Nov 17, 2014 at 4:38 PM, Ramon de la Fuente <[email protected]> wrote: > All clear. It was a bit presumptuous to make a guide but I felt the amount > of explanation needed for the module’s concepts where out of place in the > module itself (not being actual parameters or examples). I’ll reformat and > remove the guide. > > Would the tests also fall under the strange precedent category? > > > -- > Ramon de la Fuente > Future500 B.V. > @f_u_e_n_t_e > > Goudstraat 99a, 2718RD ZOETERMEER > tel: +31 (0) 85 8773879 > web: future500.nl > > On 17 Nov 2014 at 21:48:12, Michael DeHaan ([email protected]) wrote: > > Thanks for this! > > My first thought is try to clean up the examples section so there's no > "..." ... make something real world in there, and seperate it out by use > case. > > I would not like to see a seperate guide for this module as it sets a bit > of a strange precedent, so it would be better to just show a basic set of > playbooks in the examples. > > We can take a look further at implementation/usage once those get fleshed > out a bit, so we can tell how to run them. > > Thanks! > > > > > On Sun, Nov 16, 2014 at 5:55 PM, Ramon de la Fuente <[email protected]> > wrote: > >> 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 >> >> And optionally, tests for the module: >> https://github.com/ansible/ansible/pull/9567 >> >> I split the manual and the tests up into separate pull requests, because >> I’m not sure if you guys want them or not… >> >> I hope you like it, let me know what you think. >> >> >> -- >> Ramon de la Fuente >> Future500 B.V. >> @f_u_e_n_t_e >> >> Goudstraat 99a, 2718RD ZOETERMEER >> tel: +31 (0) 85 8773879 >> web: future500.nl >> >> On 4 Nov 2014 at 21:48:40, Michael DeHaan ([email protected]) wrote: >> >> 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 <[email protected]> >> wrote: >> >>> 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 shared folder. >>> >>> root/releases/1/sessions -> root/shared/sessions >>> root/releases/1/uploads -> root/shared/uploads >>> >>> root/releases/2/sessions -> root/shared/sessions >>> root/releases/2/uploads -> root/shared/uploads >>> >>> Our deploy role takes care of creating and linking to the subfolders >>> of /shared, but creation of the shared folder itself *could* be part of the >>> role. Not really that big of a deal though, it saves just one task - and >>> maybe adds some confusion as to what it is and what it should do. >>> >>> Kind regards, >>> >>> >>> Ramon >>> >>> >>> On 3 Nov 2014 at 15:23:23, Michael DeHaan ([email protected]) wrote: >>> >>> >>> >>>> >>>> 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) >>>> >>> >>> >>> This looks really good to me. >>> >>> I much prefer the idea of a mostly self-contained module as it makes the >>> amount of work everyone has to do to use the above much more condensed. >>> >>> If 2000 people use it, we might have saved the world 20,000 minutes or >>> more, etc :) >>> >>> >>> >>>> >>>> Looking at the options required, the module might take on this >>>> signature: >>>> >>>> deploy_helper parameters: >>>> required: >>>> path= /path/to/project-root >>>> >>>> not 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) >>>> >>> >>> >> I may be a little unclear on what the "shared path" is. Can you >>> remind me? >>> >>> >>> >>>> 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? >>>> >>> >>> >> "web infrastructure" seems ideal for now. We may decide to >>> reorganize the categories in the near future. >>> >>> >>>> 2: Should the (optional) creation of a shared folder be part of a >>>> deploy module? >>>> >>> >>> >> see my question above as I'm not quite remembering what a shared >>> folder is right now :) >>> >>> >>>> 3: Should we even be duplicating code like creation of the symlink? >>>> The file module already does that... >>>> >>> >>> >> There should be common code for this in module_utils. If not, we can >>> move the file code there and make it use that, >>> to avoid duplication. >>> >>> I do believe it's important to represent the "idea" (atomic deploys with >>> timestamps) versus the "how", and saving as many steps as possible. >>> >>> >>>> >>>> Thanks for any feedback, kind regards, >>>> >>>> >>> Thanks a ton for building this! >>> >>> >>> >>>> Ramon >>>> @f_u_e_n_t_e >>>> >>>> >>>> Op donderdag 30 oktober 2014 18:17:28 UTC+1 schreef Michael DeHaan: >>>>> >>>>> 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, <[email protected]> wrote: >>>>> >>>>>> 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) fixed folder >>>>>> structure - and one where we're only interested in the symlink and >>>>>> cleanup. >>>>>> >>>>>> If anyone has had thoughts about it since august, feel free to add >>>>>> them - I'll be working on this next week. >>>>>> >>>>>> Kind regards, >>>>>> >>>>>> >>>>>> Ramon >>>>>> >>>>>> >>>>>> Op donderdag 14 augustus 2014 14:34:10 UTC+2 schreef Michael DeHaan: >>>>>>> >>>>>>> " >>>>>>> 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 hostname >>>>>>> >>>>>>> "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." >>>>>>> >>>>>>> This doesn't seem related. >>>>>>> >>>>>>> I'd just do host_vars/<hostname> for this, and that's a different >>>>>>> concept, but does not interfere with --limit. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Thu, Aug 14, 2014 at 8:27 AM, Dan Vaida <[email protected]> >>>>>>> wrote: >>>>>>> >>>>>>>> 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 <[email protected]> >>>>>>>>> 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 ( >>>>>>>>>>> [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/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 [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/6020a5d1-7e19-4e90-859b-8c28136648d3%40googlegroups.com >>>>>>>> <https://groups.google.com/d/msgid/ansible-project/6020a5d1-7e19-4e90-859b-8c28136648d3%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 [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/0b5ecc2c-befc-459c-a260-fc4e6b09f4c9%40googlegroups.com >>>>>> <https://groups.google.com/d/msgid/ansible-project/0b5ecc2c-befc-459c-a260-fc4e6b09f4c9%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 [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/d7e4efab-9bac-4204-a5cb-c32a9902d395%40googlegroups.com >>>> <https://groups.google.com/d/msgid/ansible-project/d7e4efab-9bac-4204-a5cb-c32a9902d395%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 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 >>> [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/CA%2BnsWgzRvoLQ_H%3DPV4yFkaNWdDdROhXY-KxKoDUwMEK3XuDLmQ%40mail.gmail.com >>> <https://groups.google.com/d/msgid/ansible-project/CA%2BnsWgzRvoLQ_H%3DPV4yFkaNWdDdROhXY-KxKoDUwMEK3XuDLmQ%40mail.gmail.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 [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.5457f2df.6b8b4567.c680%40FzzBook.fritz.box >>> <https://groups.google.com/d/msgid/ansible-project/etPan.5457f2df.6b8b4567.c680%40FzzBook.fritz.box?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 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 >> [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/CA%2BnsWgxPaNi5Gjz_qHmnihKk8CVtRqrJg-2SXOfUZAkktJCT6g%40mail.gmail.com >> <https://groups.google.com/d/msgid/ansible-project/CA%2BnsWgxPaNi5Gjz_qHmnihKk8CVtRqrJg-2SXOfUZAkktJCT6g%40mail.gmail.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 [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/CA%2BnsWgxoUg%3DUC1UTCEDTzG%3Dr79Yfg%2B6LWHVsw3dZN8BSVzWNaA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
