15:01:19 <bcoca> #startmeeting ansible core irc public meeting
15:01:19 <zodbot> Meeting started Thu Mar 28 15:01:19 2019 UTC.
15:01:19 <zodbot> This meeting is logged and archived in a public location.
15:01:19 <zodbot> The chair is bcoca. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:01:19 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:01:19 <zodbot> The meeting name has been set to 'ansible_core_irc_public_meeting'
15:01:26 <bcoca> #topic open floor
15:03:40 <cyberpear> https://github.com/ansible/ansible/pull/53367
15:03:48 <cyberpear> I know bcoca is against.  Any other opinions?
15:04:14 <bcoca> #topic https://github.com/ansible/ansible/pull/53367
15:04:42 <bcoca> cyberpear: did you get feedback from any of the OS folks?
15:04:53 <cyberpear> nope
15:05:14 <cyberpear> mentioned it on irc, but got no response... perhaps I should ping them on the ticket?
15:06:04 <sdoran> I'd be surprised if the OS folks are ok with no extension. They tend to favor `yaml`, which is the polar opposite of nothing. :)
15:06:38 * cyberpear is a fan of user choice
15:07:12 <cyberpear> I'd allow arbitrary filenames everywhere, but I've gathered that won't fly here, due to past issues.
15:07:30 <agaffney> I'm against it for consistency reasons
15:07:52 <agaffney> and it doesn't seem to actually gain anything
15:07:54 <cyberpear> agaffney: would you like to have the same change in all inventory plugins?
15:08:54 <agaffney> I'm -0.5 because it doesn't really gain anything, so I'd be generally against changing it for all inventory plugins, but I would prefer all or nothing
15:09:04 <cyberpear> I'd like to see a policy of "name your (yaml-based) inventory with .yml or use the '---' header" even though the '---' header is optional for yaml.
15:09:34 <agaffney> what's the actual use case for dropping the .yml extension?
15:09:38 <bcoca> except 'stuff'  <= is both valid yaml and ini and toml
15:10:03 <cyberpear> yes, but "stuff" would only be picked up if the file starts with "---\n"
15:10:22 <bcoca> cyberpear: so to eliminate a restriction you dont like you want to impose another restriction on others, which you dont seem to mind?
15:10:40 <cyberpear> it's a relaxing of the existing restrictions
15:10:55 <bcoca> not if you require --- on all yaml ones
15:11:05 <cyberpear> folks can do as today w/o the "---\n" header with the .yml extension, or drop the extennsion and add the header
15:11:10 <agaffney> cyberpear: what is actually gained by this change? "user choice" isn't good enough here, imo
15:11:50 <bcoca> user choice also includes 'keep your own version of teh plugin' for things they enfatically disagree with the project defaults
15:12:14 <bcoca> ^ main reason why i added inventory plugins, it even allows you to control the 'inline host list' i.e -i host1,host2
15:12:27 <bcoca> see 'advanced_host_list'
15:13:18 <cyberpear> here's another proposal:
15:13:50 <cyberpear> drop the openstack part, but keep the 'auto' part so I can auto-load my own inventories using my own plugins without having to provide my own auto?
15:14:14 <agaffney> if you wanted to rework it a bit so that it's a global config flag that relaxes the restrictions across all inventory plugins for people that want that behavior, I'd be less opposed to that
15:14:32 <agaffney> but that also seems like a bit of overkill
15:14:35 <bcoca> except now its a requirement for all plugins to add the flag?
15:16:06 <agaffney> until I hear a good reason for making this change, I'm -0.5
15:17:08 <cyberpear> agaffney: what about a change just to 'auto'?
15:17:27 <agaffney> but *why* ?
15:18:00 <bcoca> cyberpear: i dont think you are going to get much support for this w/o a compelling use case other than 'i like files w/o extensions'
15:18:44 <bcoca> ^ cause i like em too, i think extensions are a bad way of dealing with file type ... but we are a minority on this
15:18:54 <bcoca> and ends up being a lot of trouble
15:19:30 <cyberpear> okay, I'll think it over...
15:19:48 <jagadeeshnv> https://github.com/ansible/ansible/pull/53509 there was a ask to remove prefix 'dellemc_' from the module name, have done the same
15:19:56 <cyberpear> the change to only 'auto' would allow plugin writers to accept arbitrary filenames for their plugins.
15:20:55 <jagadeeshnv> can anyone pick it?
15:21:31 <bcoca> its on my list, but i have long list, if anyone else can get to it sooner ++
15:22:11 <jagadeeshnv> ok thanks @bcoca
15:22:14 <Sajna-Shetty> @bcoca even waiting reviewer for https://github.com/ansible/ansible/pull/53438
15:23:14 <bcoca> same as above
15:23:33 <Sajna-Shetty> thank u
15:23:48 <jagadeeshnv> for my PR, the needs_revision label is active again. any reasons?
15:24:56 <jagadeeshnv> @bcoca , this one https://github.com/ansible/ansible/pull/53509?
15:27:06 <bcoca> that one was not on my radar
15:27:16 <rajeevarakkal> hi
15:28:15 <rajeevarakkal> there was an ask to rename 'idrac_pwd' to 'password' in https://github.com/ansible/ansible/pull/53509
15:28:27 <jagadeeshnv> idrac_password
15:28:49 <rajeevarakkal> by @jamescassell
15:29:25 * cyberpear waves
15:30:06 <cyberpear> I made the suggestion to help with consistently-named options throughout ansible
15:30:27 <rajeevarakkal> idrac_pwd is consistent earlier idrac_firmware module
15:31:11 <rajeevarakkal> *idrac_pwd is consistent with earlier idrac_firmware module
15:32:20 <bcoca> just to set expectations, i can probalby review 1 or 2 of those, but if you keep adding to the stack ....
15:32:32 <bcoca> i cannot even promise i'll get to those
15:32:46 <agaffney> bcoca hasn't yet perfected his cloning methods
15:34:14 <bcoca> well, i have, the problem is the maturation and knowledge implants
15:34:15 <cyberpear> I'd also suggest changing the earlier module... and if there's not a separate existing arg called 'password', I might suggest naming it just 'password', but I may be getting ahead of myself with the prospect of auth plugins https://github.com/ansible/proposals/issues/24
15:34:38 <bcoca> cyberpear: no, i need to kill that
15:34:48 <cyberpear> see also: https://github.com/ansible/ansible/pull/51776
15:35:06 <cyberpear> bcoca: is the idea instead to use module_deafults: group/*
15:35:12 <cyberpear> L
15:35:31 <cyberpear> ?
15:35:44 <bcoca> partially
15:36:08 <cyberpear> or just use a connection plugin?
15:36:16 <bcoca> its more complex, we get into 'deffered connection from controller to module' 'persistence as a connecitno property' 'auth persistence vs full session persistence'
15:37:12 <cyberpear> 'auth persistence' would be part of the mitogen sudo caching behavior?
15:37:35 <agaffney> this meeting seems to have turned into "bcoca vs. the world"
15:37:38 * cyberpear looks forward to the day ansible caches sudo auth
15:38:06 <bcoca> agaffney: i think that is the 'internet' in general
15:38:10 <sivel> oopes, I forgot to check in here after I got back
15:42:39 <cyberpear> Here's the proposed change to only the 'auto' plugin: https://github.com/ansible/ansible/pull/54533
15:43:14 <bcoca> still -1
15:44:24 <sivel> I think I am -1 too, based on my initial look
15:45:15 * cyberpear knows sivel is a fan of being more explicit
15:45:29 <sivel> :)
15:45:31 * cyberpear thinks '---' is explicit
15:45:46 <sivel> I'd say it is fragile, and doesn't necessarily indicate a YAML file
15:45:49 <agaffney> except it's not a requirement for YAML itself
15:46:10 <cyberpear> agaffney: indeed, which is what makes it more explicit
15:46:21 <bcoca> and you just have to make me bring up the guy using --- as a host in his ini file?
15:46:45 <agaffney> I don't think you're going to convince me :)
15:47:07 <cyberpear> yeah... I'm a fan of giving folks enough rope...
15:47:21 <bcoca> me too, until they start using it to HANG ME
15:47:47 <bcoca> and this is a case that has burnt us with a flood of support until we enforced strict matching on file naem for plugins
15:48:20 <bcoca> there is a balance between giving a user power and using a power tool to dismember a user
15:48:28 <cyberpear> lol
15:48:39 <bcoca> proficient enough users can have their own version of the plugin, the others can use the default
15:49:05 <cyberpear> the auto-only change would only affect folks who write their own plugins...
15:49:12 <bcoca> so you already have the rope, you just have to be 'this tall' to use it
15:49:23 <cyberpear> I assume there's nothing special about the 'auto' plugin and I can just have my own called auto?
15:49:33 <bcoca> yep
15:49:42 <bcoca> ALL plugins can be overriden
15:50:22 <bcoca> also why 2.8 will have become_plugins so people stop trying to tweak the 'common' PE string construction
15:50:26 <cyberpear> fair enough... but then there's the extra task to keeping it up to date w/ latest upstream + patches
15:50:36 <cyberpear> PE string?
15:50:47 <bcoca> privilege escalation, not physical education
15:50:53 <cyberpear> ah
15:51:44 <cyberpear> yeah, been overriding ansible_su_exe and ansible_su_args to hackishly use 'dzdo + sudo + su' because of stupid local security policies
15:51:49 <cyberpear> become_plugins are a win
15:52:15 * bcoca expects a sudo_su plugin
15:52:35 <bcoca> ^ even just handling sudo su - combinations would create several hundred 'special cases'
15:52:37 <cyberpear> for sure, again because some stupid security policies are out there
15:52:50 <bcoca> basic misunderstanding on what sudo and su are and how they work
15:52:57 <cyberpear> and internal IT/infosec bureaucracy can be very bad
15:52:58 <bcoca> there is never a need to combine them
15:53:29 <bcoca> its copypaste from something a guy that barely knew sudo and su did .. now making it 'enteprise policy'
15:53:39 <bcoca> /endrant
15:54:06 <cyberpear> except when you have a policy of something like '%wheel ALL=(root) su'
15:54:13 <bcoca> k, meeting has gotten off rails, (expected when no agenda) ... so im going to close in 2mins unless new actual business is presented
15:54:53 <cyberpear> for "this" proposal, is the only thing blocking it the name?
15:54:57 <cyberpear> https://github.com/ansible/proposals/issues/74
15:55:00 <cyberpear> that was my read of it
15:55:13 <maxamillion> to the best of my knowledge, yes
15:55:14 <cyberpear> except sivel is opposed on principle
15:55:30 <maxamillion> gotta bikeshed that beast ;)
15:55:35 <bcoca> actually, he convinced me, also -1 on concept
15:55:42 <maxamillion> bcoca: oh?
15:55:49 <bcoca> too much magic, register is not that big of an onus
15:55:52 <maxamillion> I might have to revisit that one and see if I might have missed something
15:56:48 <bcoca> when you have to explain a feature with local ref vs global ref in a system that does not really have either ....
15:56:49 <maxamillion> is it really that much magic? standard unix tools have been providing a return code since the dawn of time ... this feels very analogous to that concept, or am I missing something?
15:57:12 <bcoca> maxamillion:  and we have a way to deal with the 'return code', its called register:
15:57:27 <bcoca> or do you want ansible users to know about $? and $0
15:57:41 <bcoca> remember, not all our users a programmers
15:57:55 <bcoca> and one of the main features of ansible is 'auditability' .. magic is oppposed to audits
15:58:07 <maxamillion> bcoca: I don't consider shell scripting programming ... but maybe that's an unfair classification since it's a Turing Complete language
15:58:14 <bcoca> one of reasons i was against module_defaults ... it hides from reader
15:58:27 <bcoca> maxamillion: 'turing complete' is too low a bar
15:58:43 <bcoca> ansible is also programming language by most metrics
15:58:46 <maxamillion> anyhoo... it's not that I want Ansible users to have to know about $? and $0, but that it's kind of a standard thing to be able to check the status of "the last thing executed" ... so I feel like that concept isn't a far fetch for Ansible to just carry on
15:59:04 <maxamillion> bcoca: fair
15:59:06 <sivel> I once pushed for and got approved an implicit feature, and in many cases I wish I hadn't.  It's nice, but often confusing and can be difficult to explain
15:59:12 <cyberpear> this doesn't allow checking of 'last thing' but just 'current thing' before returning
15:59:13 <sivel> (implicit localhost)
15:59:15 <agaffney> I'm on the fence on this one. it's a handy feature, but 'register: this' is not difficult
15:59:29 <bcoca> @maxamillion not for you, you are familiar with systems and programming, when building a tool wih a much lower barrier to entry, you cannot raise hurdles midway w/o careful considreation
15:59:34 <bcoca> why not add closures?
15:59:51 <bcoca> goto/gosub has been probposed
16:00:02 <maxamillion> cyberpear: wait, then I don't follow ... I thought it was automagic register of return value from the previous task run and it will be overridden when the next task executes
16:00:17 <bcoca> maxamillion: no, for 'current task'
16:00:31 <bcoca> 'this' on subsequent tasks would be confusing, it always refers to 'current task'
16:00:32 <cyberpear> maxamillion: "this" is only available only in the current task, for use in 'failed_when' or 'changed_when' attributes, tec
16:00:40 <bcoca> prev_this ?
16:00:52 * bcoca starts shovel selection
16:00:57 <maxamillion> bcoca: that's fair, need to not assume prior knowledge/experience because that forms a slippery slope to something that's not useful for most people
16:00:58 <cyberpear> -1 to prev_this
16:01:30 <maxamillion> hrmmm
16:01:32 <bcoca> maxamillion: its a blance that is hard to strike, you want to give experts power but not in a way that makes it impossible for others to follow, i.e Perl
16:01:53 <bcoca> python itself has had issues with that balance, i would argue its one of the 'better' ones in that respect
16:02:02 <maxamillion> bcoca: you mentioned "register is not that big of an onus" so I think I contextually went elsewhere in my in mind (incorrectly so)
16:02:14 <maxamillion> bcoca: agreed
16:02:28 <bcoca> while 'expert' Perl programmers .. should also add 'auto encryption' to their resumes
16:03:01 * bcoca actually likes Perl
16:03:37 <maxamillion> I'm pretty indifferent to perl, but it's an easy target to criticism and I think it's an apt analogy in this situation
16:03:58 <maxamillion> yeah, alright .... I think I'm convinced also
16:04:00 <bcoca> agreed, just dont want to pile on it
16:04:02 <maxamillion> -1 to `this`
16:04:27 <cyberpear> `apply: {register: this}`?
16:04:29 <bcoca> plenty of other languages do horrible things, with perl its mostly a developer preference, you CAN write very clear and readable perl
16:04:50 <maxamillion> bcoca: true
16:04:57 <agaffney> cyberpear: ewwwwwwwww
16:04:58 <bcoca> cyberpear: i dont know if that works, interesting to try
16:05:10 <agaffney> I would hope that it doesn't work, but I'm afraid that it does
16:05:58 * agaffney wonders if block/register would work the same way
16:06:12 <bcoca> k, i think that is enough for todays meeting , we can continue speculative design in #ansible-devel
16:06:15 <bcoca> #endmeeting