On Mon, Aug 4, 2014 at 10:11 AM, Ramon de la Fuente <[email protected]>
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 **
> 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)
>
Yep, I'm basically wanting to see this doable with a module, not a role, to
make it more adaptable by users that want different variations, and less
boilerplate to hop through when they do.
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.
>
> All-in-all I think we went with your mantra when people start suggesting
> deploy modules: “It sounds like a role to me”
>
Yeah here I'm thinking there's enough of a pattern that we can get
something to smooth this out in core.
It also gives a good place to hang a common example.
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/base
register: 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
register
This is just me going through it really quick so I suspect we can come up
with cleaner argument names and workflow.
> > you, but failing forward is a better approach. The guide on test strategy
> > may also be instructive.
> >
> > (B) The symlink pattern thing I'd like to make more idiomatic, though I
> > don't think it's hard now. This might just be a docs example, but it
> > might be a mini-module that has a couple of modes, one that makes a
> > timestamp and another that moves the symlink or something. I don't know.
> > Example may be sufficient.
> >
> > (C) Yes, adding key=value arguments to existing commands must now be
> > intercepted for security reasons. In particular this part, which I don't
> > really understand what it's doing in the playbook, can't be a thing:
> >
> > action: "{{ item.module }} {{ item.parameters }}"
> >
> >
> >
> > In all though, the topic I want to concentrate on the most is (B). If we
> > were to make a module or two to make the "timestamp'd symlink thing" more
> > idiomatic, what might the syntax look like, etc?
> >
> > One of the major goals of Ansible is to not need another deployment tool
> on
> > top, like Cap. In most cases, people are already able to drop Fabric/Cap
> -
> > I'd say it's significantly more common for people to adopt ansible for
> > application deployment needs initially - and especially with regard to
> load
> > balancing and such it was designed for the purpose.
> >
> > So the question is, how do we make that even easier?
> >
> >
> >
> >
> >
> >
> > On Fri, Aug 1, 2014 at 8:31 AM, wrote:
> >
> > > 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 reasons, so I post here to discuss other options, and
> > > deploying with Ansible in general.
> > >
> > > Here is the role on ansible-galaxy:
> > > https://galaxy.ansible.com/list#/roles/732
> > >
> > > I'd like to point to the "deploy" module specifically:
> > >
> https://github.com/f500/ansible-project_deploy/blob/master/library/deploy
> > > - it creates a folder structure
> > > - it generates a timestamp
> > > - it generates facts (including the generated timestamp)
> > > - it can remove *n* releases
> > >
> > > Perhaps that does some work that makes life easier for deploys?
> > >
> > > --
> > > 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/c0234581-5a8d-4797-b35f-fd8756d721e3%40googlegroups.com
> > >
> > > .
> > > 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%2BnsWgyrUSK0cqCi8Y_3VBXj%2BaGM%3DhZ5HTb6vt_Ej%2Bs9Agu8LQ%40mail.gmail.com
> .
> > 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.53df94a0.79e2a9e3.1519%40fzzbook.lan
> .
> 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%2BnsWgxz_%3DT%2BWR0AGub8Nie-HAz0Jt1cE-pqpbj-H-fuprp7%3DQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
