15:02:51 <bcoca> #startmeeting core community meeting
15:02:51 <zodbot> Meeting started Thu Aug 17 15:02:51 2017 UTC.  The chair is bcoca. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:02:51 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:02:51 <zodbot> The meeting name has been set to 'core_community_meeting'
15:04:20 <bcoca> #topic changing names for set_facts and include_vars
15:04:32 <bcoca> #url https://github.com/ansible/community/issues/220#issuecomment-322432419
15:04:41 <bcoca> kustodian ?
15:05:55 <jtanner> that feels "proposal" like to me
15:06:23 <bcoca> its a rename .. not sure i agree on it requriing proposal
15:06:37 <jtanner> rename without alias?
15:06:40 <bcoca> and not a 'general rename' like plural/singular
15:06:48 <bcoca> jtanner: we dont allow those afaik
15:07:12 * mikedlr waves hello.
15:07:13 <bcoca> there should be deprecation periods like with previous renames, we've used this process several times before
15:07:39 <shertel> Hi
15:07:42 * bcoca waves
15:08:16 <jhawkesworth_> is changing set_facts to set_host_vars actually any clearer?  I may be wrong but I tend to think of host_vars as being 'host_constants'.
15:08:30 <jtanner> well, one counterpoint to the rename might be that later down the road if we decide that not all vars have to be squished in to hosts, "set_host_vars" may not be totally accurate
15:08:56 <jtanner> bcoca: chair me please
15:09:08 <bcoca> #chair jtanner shertel
15:09:08 <zodbot> Current chairs: bcoca jtanner shertel
15:09:15 <jtanner> #chair mikedlr andriusb
15:09:15 <zodbot> Current chairs: andriusb bcoca jtanner mikedlr shertel
15:09:26 <jtanner> #chair jhawkesworth_
15:09:26 <zodbot> Current chairs: andriusb bcoca jhawkesworth_ jtanner mikedlr shertel
15:09:31 <bcoca> jtanner set_fact would have same issue
15:09:55 <bcoca> and i dont see a path on changing how vars are currently structured  w/o major engine rewrite
15:10:15 <jtanner> yep, way down the road if ever
15:10:23 <bcoca> anible 5.0?
15:10:23 <shertel> #chair alikins
15:10:23 <zodbot> Current chairs: alikins andriusb bcoca jhawkesworth_ jtanner mikedlr shertel
15:11:06 <bcoca> +0 from me, fine with getting a 'better name' ... really dont want to discuss what 'better name' looks like ... current and proposed all have problems and infer slightly incorrect meanings
15:11:36 <jtanner> if +0 is indifference, that is my vote also
15:11:40 <bcoca> and set_host_vars_but_unrelated_to_host_vars_dir ... is a bit long
15:11:49 <jtanner> i wasn't aware that the terms were confusing to people
15:12:11 <bcoca> hostvars vs host_vars vs facts vs ansible_facts vs set_fact vs include_vars actually setting facts ...
15:12:36 <bcoca> alikins: did we add cacheable to include vars?
15:13:06 <alikins> tend to agree. set_host_vars etc is better and more accurate name, but hard to change names. If it works as an alias though, +1, +0 if not
15:13:39 <bcoca> alikins: any and all renames work as an alias, with at least a deprecation period (currntly 4 versions)
15:13:43 <alikins> bcoca: re cacheable, I don't think so
15:13:57 <bcoca> alikins: might want to add it jsut for parity, not a priority though
15:15:09 <bcoca> soo .. this seems to have little support but also no opposition
15:15:35 <bcoca> not sure what to do now .. open to survey on 'best name'?
15:15:50 <jtanner> i thought that was something the proposal process was supposed to help with
15:16:26 <alikins> sorta starts to become set_fact_for_playbook / include_vars_for_playbook  (and/or, set_fact_for_invocation, don't remember off hand if cacheable persist across multiple playbooks.)
15:16:30 <jhawkesworth_> I am -1 on set_fact -> set_host_vars.  although 'facts' is wrong it hints that these vars are immutable.
15:16:39 <bcoca> proposals normally big design elements and/or impact, i think this does not qualify, but if others insist, fine
15:17:11 <jtanner> i don't insist, only suggest
15:17:21 <bcoca> alikins: multiple plays , playbooks also, if in same run
15:17:48 <bcoca> jhawkesworth_: most vars ARE immutable ... just 'overridable' .. not really overwritable
15:18:30 <alikins> it would be nice to have a general solution for setting a var for some specific context/scope/lifetime
15:18:48 <bcoca> debug
15:19:07 <shertel> +0 I don't think the aliases make it particularly more clear.
15:19:36 <dag> o/
15:19:42 <bcoca> ok, so im going to table this as 'not opposed, but need better names'
15:19:45 <bcoca> ^ agreed?
15:19:46 <jtanner> #chair dag
15:19:46 <zodbot> Current chairs: alikins andriusb bcoca dag jhawkesworth_ jtanner mikedlr shertel
15:20:00 <jhawkesworth_> +1 to better names.  but that may be can of worms.
15:20:02 <jtanner> bcoca: yep
15:20:14 <bcoca> jhawkesworth_: its  a barrel of cans of worms
15:20:15 * dag needs to look up the discussion with Michael wrt. this, because I know it was contentious back then
15:20:27 <bcoca> dag: i already did, set_local!
15:20:29 <jtanner> barrel of canned monkey worms
15:20:31 <dag> right :-)
15:20:38 <alikins> I don't think it's ever been clear what scope/context/lifetime a 'fact' applies to
15:20:53 <bcoca> dag: look at minutes from prev meeting, i even got the ticket in which this was added
15:21:03 <dag> bcoca: cool !
15:21:06 <dag> will do
15:21:37 <bcoca> alikins: which type of fact? there are 2, but in any case their scope is 'associated to host' which is 'global to run' once defined
15:22:20 <bcoca> the problem with vars is that we really don't 'just have scope' ... we have scopes with vars: <= 'for this object and those contained by it'
15:22:39 <bcoca> but things like roles and set_fact and extra vars and inventory ... dont have real scopes nor interactions
15:23:04 <bcoca> they have precedence and availability ... which are not really related to scope
15:23:24 <bcoca> i.e host related variables are always available once defined .. just via hostvars[hostname][varname]
15:23:38 <bcoca> vs directly available hosts: hostname .. then u can use varname
15:24:11 <bcoca> context is more important than scope with our vars (or semi constants ...) which is not what most programmers would expect
15:24:42 <bcoca> it helps if you think of plays as 'for loop on hosts that locallizes vars by dumping hostvars into locals()'
15:24:53 <bcoca> ^ if that makes sense
15:25:50 * bcoca suspects everyone is now in a corner sobbing ...
15:25:56 <dag> :-)
15:26:22 <jhawkesworth_> can make the names 'truer' to what they actually are, but may not actually benefit understanding.
15:27:27 <jtanner> it's a study in psychology and linguistics
15:27:39 <bcoca> i should make a presentation 'understanding ansible vars ... straight jackets in the back for when you are ready'
15:27:45 <jhawkesworth_> :-)
15:27:56 <shertel> heh
15:28:55 <dag> the only reason people are still here is because they want to discuss my next topic, I am sure
15:29:02 <dag> :-P
15:29:03 <jtanner> dag: always
15:29:10 <bcoca> /endmeeting
15:29:15 <dag> haha
15:29:43 <bcoca> ok, updating ticket .. need to figure out naming .. letting future meetings loose time on that
15:29:52 <bcoca> #topic sleep action
15:29:54 <mikedlr> +1 on naming waits to see who is still sane after bcoca's presentation
15:30:02 <bcoca> #url https://github.com/ansible/ansible/pull/26889
15:30:11 <bcoca> mikedlr: pretty much have to be insane going in
15:30:53 <bcoca> took me rewriting var manager to get grasp on how vars really work internally , i had more or less figured out functionally ... but did not know why
15:30:53 <dag> so we need to have a variable sleep per target
15:31:06 <dag> pause is not a solution
15:31:19 <bcoca> its one solution, just does not apply 'per target'
15:31:28 <bcoca> wait_for is the one that does
15:31:35 <dag> other solutions were proposed, but I still prefer a 'sleep' module
15:31:57 <dag> bcoca: why doesn't sleep apply per target ?
15:32:01 <bcoca> i find it redundant with wait_for (and others like loops/until/etc which also have  pauses)
15:32:17 <bcoca> dag: refered to pause
15:32:29 <dag> ok
15:32:56 <bcoca> ^ i actually like my with_sequence as it shows a countdown ...
15:32:59 <dag> well, there is a second use-case for sleep, since pause is run only once (for the first target) there is no guarantee the playbook actually will pause
15:33:15 <dag> if that first host happens to skip that task, pause is skipped as well
15:33:24 <dag> (to me that is a huge mistake in the design)
15:33:45 <dag> at least sleep can prevent this
15:33:52 <bcoca> dag:  agreed that pause does not solve all cases, but neither does sleep, yet we solve all cases currently with examples given in ticket, specifically wait_for: timeout=10
15:34:22 <dag> bcoca: wait_for to me is band-aid for the simple reason that the timeout is an error-condition
15:34:24 <bcoca> pause was meant as a sync point, does it's job
15:34:30 <dag> normally when the timeout is reached, the tasks fails
15:34:48 <bcoca> dag: no, timeout is only error when in conjuntion with other conditions, otherwise its a sleep (designed specificaly that way)
15:34:52 <dag> for some strange reason this is exceptional behaviour and would not come to mind
15:34:58 <dag> bcoca: right, exceptional
15:35:10 <bcoca> so wait_for: port=22 timeout=10 <= its error  when timeout reached
15:35:17 <bcoca> wiat_for: timeout=10 <= not an error
15:35:30 <bcoca> ^ well, spelling error
15:35:37 <dag> the documentation does not even describe that behaviour
15:35:46 <dag> or that it is an exception
15:35:54 <bcoca> well, that is easy to fix
15:36:07 <jhawkesworth_> 'wait_for: timeout=10 'is a bit harder to read than sleep: seconds=10
15:37:03 <bcoca> i dont dispute that , but i find it redundant .. would like to minimize redundancy
15:37:08 <jhawkesworth_> so I like sleep for the syntatic sugar.  But figuring out which of sleep, pause and wait_for to use is more head scratching
15:37:17 <bcoca> if this can be fixed with doc line vs new module ... i go doc
15:37:30 <dag> jhawkesworth_: yes, I would prefer not having to have the distinction between sleep and pause to be honest
15:37:40 <dag> but they both work at a different level
15:37:54 <dag> I don't mind renaming sleep if there's a better name
15:38:51 <bcoca> i would prefer making sleep a alias for wait_for ... which is really 'sleep_until: ...'
15:40:34 <bcoca> wait_for docs: " You can wait for a set amount of time C(timeout), this is the default if nothing is specified"
15:40:55 <bcoca> should be a bit clearer and include a  'sleep example' .. but its documented
15:41:10 <dag> bcoca: but the timeout is the error condition, that's the part that is not documented
15:41:28 <bcoca> its not by itself
15:41:34 <dag> in all uses it causes an error, which is what I assumed
15:41:37 <bcoca> which is badly implied in that phrase above
15:41:41 <dag> right
15:41:45 <bcoca> im fixing that now
15:42:10 <dag> I don't mind if that is fixed, but I still think using wait_for is band-aid
15:42:34 <dag> if nobody is weighing in, I guess we'll have to use seniority to make a decision
15:42:37 <dag> :P
15:43:45 <jhawkesworth_> pause wait sleep - all similar ideas - would be nice to have 1 module that can do all with aliases.
15:43:49 <dag> *yawn*
15:44:01 <jhawkesworth_> but not looked at the code so maybe that's daft
15:44:14 * jhawkesworth_ gotta go. later all
15:44:37 <dag> jhawkesworth_: wait_for runs remotely per target, sleep runs locally per target, pause runs at the playbook level (once for all targets if you're lucky)
15:44:39 <bcoca> well, wait_for + run_once can emulate the pause behavioru on waiting .. but pause was created for prompting
15:45:08 <dag> so in fact, in my case it's not just: wait_for: timeout=10, you actually have to add: delegated_to: localhost
15:45:14 <bcoca> if we add 'prompt' to wait_for .. pause then becomes obsolete
15:45:30 <dag> because the target does not exist
15:45:38 <bcoca> or local_action ... yes
15:45:38 <dag> that's why I think sleep should exist
15:45:48 <dag> local_action should die
15:45:49 <bcoca> to avoid 1 keyword ....
15:46:00 <dag> if we killed `action:` we should get away with local_action IMO
15:46:08 <bcoca> action still lives
15:46:16 <dag> you avoid local_action, and introduce `module`
15:46:20 <dag> so you don't gain a thing
15:46:27 <bcoca> you lost me
15:46:43 <dag> ansible -- automate in a language that approaches plain English
15:47:01 <dag> bcoca: with local_action you have to add the module in a second key
15:47:19 <dag> local_action:
15:47:19 <dag> module: wait_for
15:47:19 <dag> timeout: 10
15:47:22 <alikins> a handler attached to a sleep could be interesting , more or less a timer event  (more or so if handlers are configed to run 'immediately')
15:47:24 <dag> sleep:
15:47:25 <dag> seconds: 10
15:47:25 <bcoca> same with action:
15:47:43 <dag> wait_for:
15:47:43 <dag> timeout: 10
15:47:43 <dag> delegate_to: localhost
15:48:03 <dag> did the indentation wrong
15:48:15 <alikins> (albeit, a blocking timer event)
15:48:31 <dag> so yes, I prefer the more natural english
15:48:54 <dag> ansible -- automate in a language that approaches plain English
15:49:13 <dag> yes, when you want to sleep you have to delegate that to your localhost
15:49:18 <dag> makes no sense to me
15:49:34 <dag> I understand where that comes from, but it's band-aid
15:49:39 <bcoca> for me wait_for makes more sense .. since no one is naping
15:50:14 <dag> but it shouldn't matter where you're waiting
15:50:28 <dag> waiting for time to pass on a remote target is silly at best
15:50:36 <bcoca> if 'only' waiting, i agree, but that is easy to fix w/o new module
15:50:37 <dag> it's an unneeded round-trip
15:51:01 <alikins> but either, 'sleep' is a portable thing, it's simple, and intuitively named and findable, and otherwise harmless. +1 from me.
15:51:18 <bcoca> -1 as redundant
15:51:46 <jtanner> +1 ... i find it similar to reboot
15:52:06 <bcoca> reboot?
15:52:18 <dag> which reminds me to finish the reboot module :-/
15:52:30 <bcoca> i know of win_reboot .. but not reboot
15:52:43 <jtanner> yes, there are ways to accomplish it with existing language, but the behavior is not tested and all the examples out there are wrong
15:52:43 <dag> bcoca: it's a platform-agnostic reboot module
15:53:01 <bcoca> jtanner: there is good role for linux reboot
15:53:17 <bcoca> ^ you can add win_reboot to it .. cause windoez is 'special' and pretty hard to do
15:53:28 * bcoca needs to find it
15:53:42 <bcoca> was mostly using command: reboot + wait_for
15:53:43 <jtanner> sorry, it's a tangent
15:53:52 <dag> bcoca: hmm, I never made a PR for it: https://github.com/dagwieers/ansible/tree/reboot-module
15:53:55 <bcoca> jtanner: not sure how it is same as this case
15:53:57 <jtanner> only using it as an example
15:54:05 <alikins> could sleep be considered a meta action for influencing strategy behavior?  (not this particular implementation, but the general idea)
15:54:08 <bcoca> no redundant module
15:54:30 <bcoca> yes, it can be done in a few tasks on linux side .. but many OSs make this much harder
15:54:32 <jtanner> it's the same in the sense that without a clear module to do the function, people come up with 50 different suggestions on how to do it and most of them are wrong in some way
15:55:13 <bcoca> which is more a question of good docs than creating a module for every possible combo ... you want to maintain more modules which do almost same thing?
15:55:29 <jtanner> your loop control examples look odd to me for  simple sleep ... i would have just done shell: sleep 10
15:55:50 <bcoca> wait_for shoudl be the norm, that was just to show 'counter'
15:56:04 <bcoca> wait_for: timeout=10
15:56:11 <jtanner> it's only my opinion
15:56:14 <bcoca> ^ would be almost same as your shell: sleep 10
15:56:15 <jtanner> it doesn't mean you are wrong
15:56:24 <dag> jtanner: right, but I need to delegate that to localhost as well (as the target needs to be created)
15:56:33 <bcoca> jtanner: that was one of many examples of ways to do same thing
15:56:41 <dag> here is the issue ticket for the reboot action plugin: https://github.com/ansible/ansible/issues/16186
15:56:43 <bcoca> until/retry/pause <= another 'sleep'
15:57:24 <dag> so somehow I was fearing this would be one of those topics that go on forever
15:57:33 <dag> I am sorry to have caused another one of those :-/
15:57:53 <dag> productivity goes down the drain
15:58:17 <jtanner> bad dag.
15:58:38 <dag> yeah, ansible development halted for an hour because of me, again !
15:58:58 <bcoca> dag: im not saying that your interface lacks merit, i just want to not maintain more code in main repo than rwe really need
15:59:13 <dag> so you guys figure it out, it's there for the taking, or leaving :)
15:59:19 <bcoca> if wait_for can do same .. .really hard to justify more of same code
15:59:35 <dag> bcoca: to be honest, this is easier to maintain than an exception in wait_for with an action plugin
15:59:38 <bcoca> as for reboot, i fail to see the similarity
15:59:43 <dag> that's more complexity IMO
15:59:59 <bcoca> dag: if it were either/or .. but this is AND
16:00:16 <bcoca> we are maintaining that code already, this will not eliminate that code
16:00:23 <dag> bcoca: read that ticket, you'll see a plethora of solutions for doing reboots but none looks really the right way
16:00:30 <dag> bcoca: a reboot should just be that
16:00:36 <dag> like a sleep should just be that
16:00:46 <dag> and not delegated_to: localhost
16:00:50 <bcoca> dag: i fail to see the connection
16:01:01 <dag> or using a timeout that by default is an error condition
16:01:12 <bcoca> dag: no, by default it is not
16:01:17 <bcoca> its actually the opposite
16:01:29 <dag> I spelled it out, maybe you don't want to see it ;-)
16:01:31 <bcoca> it was made an error condition when other conditions were applied
16:01:57 <dag> bcoca: ok, if you have 10 use-cases, and in 1 it acts differently, that to me is the exception
16:02:05 <alikins> how do wait_for: or sleep: handle being ran with async: ?
16:02:13 <dag> but I don't want to discuss semantics about exceptional here
16:02:25 <dag> alikins: sleep is an action plugin
16:02:27 <bcoca> alikins: wait_for runs with async, sleep does not
16:02:45 <dag> if you want to sleep asynchronously, then I think you need to see a docter :-)
16:02:47 <abadger1999> Would the idea of documenting wait_for be to document it in the pause module?
16:02:48 <bcoca> but async basically defeats the purpose of this feature
16:03:07 <bcoca> abadger1999: i can add that, already have PR documenting wait_for as a 'sleep'
16:03:14 <dag> abadger1999: still, delegating your sleep to localhost feels so wrong
16:03:19 <abadger1999> "pause is not what you want if _____. Use the wait_for: timeout=SECONDS if you need that.
16:03:31 <bcoca> dag: you dont NEED to , but it is saner to do so
16:03:50 <dag> bcoca: YES, i NEED to because the target still has to be created
16:04:01 <bcoca> well, depends on what you are doing
16:04:13 <dag> well, there is firmly disagree with you
16:04:22 <dag> there is no real use-case for sleeping remotely
16:04:52 <dag> so no, if we are talking about sleeping, there is no "depends what you are doing"
16:05:02 <bcoca> no, but it also does not break in many cases, i.e restarting tomcat and waiting cause service script lies to you and you know it takes 200s to be ready
16:05:12 <dag> you shouldn't be making a connection
16:05:17 <bcoca> ^ my actual first usage of wait_for: timeout=250
16:06:13 <dag> it should be as simple as: sleep: seconds=10 in EVERY use-case
16:06:42 <dag> the only problem I have is the sleep vs pause discussion, which is something we cannot fix
16:07:16 <dag> and we probably ought to make a note in both module docs to explain the difference
16:07:43 <bcoca> already done
16:08:00 <dag> can't be done, unless you also merged my sleep PR :)
16:08:18 <bcoca> we disagree on that
16:08:32 <dag> you disagree with me, jctanner and alikins
16:08:40 <dag> but yes "we" disagree on that too :)
16:09:13 <dag> so let's discuss next week again
16:09:21 <dag> and continue the meeting
16:09:25 <dag> because I cannot call it a day
16:11:51 <abadger1999> bcoca: next topic?
16:12:01 <bcoca> none left
16:12:35 <abadger1999> Okay open floor then
16:12:41 <bcoca> #topic open floor
16:13:05 <bcoca> though we are over, so if noone has anything closing in 5
16:13:07 <abadger1999> Ansiblefest SF is coming up
16:13:28 <abadger1999> And there will be a contributor summit on 2 days this time, one the day before and one the day after (Wed and Fri)
16:13:35 <abadger1999> Feel free to sign up to attend
16:13:39 <abadger1999> Or join on video.
16:13:48 <abadger1999> We're getting input on agenda items here: https://public.etherpad-mozilla.org/p/ansible-summit-september-2017
16:13:54 <dag> abadger1999: 2 days, do we plan something like a sprint ?
16:13:55 <abadger1999> So feel free to add items or to vote.
16:14:14 <abadger1999> dag: Not yet but feel free to put it on the list.
16:14:18 <abadger1999> I'll be there both days.
16:14:22 <mikedlr> Still looking for people interested in testing cloud modules.  AWS team has limited resources and will be in conferences and stuff
16:14:33 <dag> I had already booked my flight, need to reschedule it if I still can
16:14:37 <abadger1999> i think nitzmahone and several others might be leaving partway through friday.
16:15:08 <abadger1999> i'd be happy to help but I'm not much help on either windows or cloud.
16:15:24 <abadger1999> gregdek:  You around?
16:15:36 <abadger1999> gregdek: dag wa swondering if we're planning sprints.
16:15:42 <mikedlr> Anyone who wants to do manual testing / learn about setting up serverless systems should drop by #ansible-aws
16:16:00 <dag> abadger1999: I'll put it on etherpad, no problem
16:16:04 <abadger1999> dag: Cool.
16:16:08 <dag> don't need to wake up gregdek for this :p
16:16:12 <abadger1999> That's all from me on this topic
16:16:25 <dag> let me quickly see if I have anything still in queue
16:17:17 <dag> nope, I only got module-related PRs open
16:17:36 <dag> sleep was the only think standing out because of bcoca's remarks
16:17:42 <dag> thing
16:18:01 <abadger1999> Cool.
16:19:12 <bcoca> #endmeeting