19:03:10 <jillr> #startmeeting  Ansible Core Public IRC Meeting
19:03:10 <zodbot> Meeting started Tue Dec 10 19:03:10 2019 UTC.
19:03:10 <zodbot> This meeting is logged and archived in a public location.
19:03:10 <zodbot> The chair is jillr. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:03:10 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
19:03:10 <zodbot> The meeting name has been set to 'ansible_core_public_irc_meeting'
19:03:42 <jillr> looks like nothing new on the agenda so,
19:03:46 <jillr> #topic open floor
19:04:56 <shertel> o/
19:05:21 * felixfontein waves
19:05:37 <jillr> hey y'all o/
19:06:21 <felixfontein> I'd like to come back to the openssh_keypair discussion from last week
19:07:07 <jillr> #topic https://github.com/ansible/ansible/pull/64436 - openssh_keypair
19:07:08 <felixfontein> I'm not exactly sure how the behavior of that module (and openssl_privatekey) should be
19:07:41 <felixfontein> is it expected that once the keyfile(s) exist, *no* change is made to them (except if force=yes or something else like "I really want changes" is specified)?
19:08:00 * jillr reading logs from last week's meeting
19:08:18 <felixfontein> right now, if you apply the module to a key and you specify a different bitsize, key type, ..., the key will be regenerated
19:08:41 <felixfontein> (as I would expect from a configuration management system :) )
19:10:05 <felixfontein> also: if the behavior is changed (by adding such an option), should that be backported?
19:11:46 <jillr> would this tl;dr be correct (I'm reading quite quickly here): if a passphrase exists at all the module will regenerate the key
19:12:18 <shertel> nitzmahone, we're looking at the openssh_keypair PR we discussed last week in case you have an opinion on the solution
19:12:25 <felixfontein> for openssh_keypair: right now, it will regenerate it (https://github.com/ansible/ansible/pull/65638 will change that once merged)
19:12:37 <jillr> well that's terrifying.
19:12:56 <felixfontein> for openssl_privatekey: the module knows about passphrases, and regenerates the key if it has the wrong passphrase (or has no passphrase if the user expects one, or has a passphrase and the user didn't specify one)
19:13:08 <felixfontein> that depends
19:13:22 * nitzmahone in another meeting, will try to take a look in a bit
19:13:23 <felixfontein> also if  you specify a different keysize than the key has, it will regenerate it (and delete the old one)
19:13:46 <felixfontein> I don't see that much a difference between "has wrong passphrase" and "has different type" or "has different keysize"
19:14:06 <jillr> that feels like it needs a confirm 'yes blow away my key' switch
19:15:06 <jillr> ah, which 65638 says will be in a future PR.
19:15:08 <shertel> that was the consensus from last meeting.... a `force` option seems fine to me.
19:15:43 <felixfontein> there should also be something inbetween, which ensures that the key satisfies the condition without regenerating it every time. force will always regenerate it.
19:16:04 * shertel looking at the module
19:16:05 <jillr> so the immediate question is about backporting 64436?
19:16:26 <felixfontein> that won't be backported
19:16:30 * jillr still reading all the comments on the 2 PRs
19:16:35 <jillr> ok, thx
19:17:01 <felixfontein> it's mainly about how the module should look like, from the core team's perspective
19:17:45 <felixfontein> the crypto team discussed this earlier (this year I think) and we decided for the current behavior, because that's what we would expect from a configuration management system
19:18:50 <jillr> k I think I'm on the same page now, reading your actual change..
19:19:13 <felixfontein> https://github.com/ansible/ansible/pull/65638 is a stop-gap to fix the current problem
19:19:32 <felixfontein> I started a discussion issue for a longer-term solution in https://github.com/ansible/ansible/issues/65639, but so far nobody commented
19:19:58 <jillr> #topic https://github.com/ansible/ansible/pull/65638 - openssh_keypair intermediate solution
19:19:59 <shertel> Sam is on PTO, btw
19:20:12 <felixfontein> I think it would be best if there is a way to tell the module which behavior is acceptable / wanted
19:20:15 <felixfontein> ah
19:20:26 <felixfontein> with a default value which makes the core team happy :)
19:23:52 <jillr> I'm in favor of failing by default unless the user opts-in. it breaks backwards compatibility, but is the safer action.
19:24:36 <felixfontein> i.e. if some option doesn't match, fail, unless the user specifies whatever option it will be that controls behavior
19:24:47 <jillr> yep
19:25:59 <felixfontein> what do the others think? +1 for that? or something else? :)
19:26:18 <jillr> I suspect there aren't enough of us around for consensus though and we should get more feedback
19:26:57 <jillr> I'll leave a comment on your PR since the Thur meeting is too early for my day
19:27:18 <felixfontein> ok. I won't be there by then either, but I can write something in the agenda
19:27:27 <shertel> I'm in favor of that
19:27:29 <jillr> awesome, thanks felixfontein
19:27:43 <felixfontein> btw, what do you think, should that solution be backported (i.e. also break compatibility in 2.9.x or even 2.8.x)?
19:28:04 <jillr> that's a much harder sell for me, I'd defer to the RM on that
19:28:23 <felixfontein> I don't like backporting that, since it will definitely break playbooks
19:28:27 <jillr> yeah
19:28:50 <felixfontein> if nobody wants it backported, I'm happy :)
19:29:15 <jillr> #topic open floor
19:29:49 <felixfontein> another question: how would a similar PR to 65638 (i.e. change behavior w.r.t. password-protected private keys) for openssl_privatekey look? would it be backported?
19:30:23 <felixfontein> if not, I'd not work on that until it is clear how the new control mechanism should look like. but if that behavior change should be backported, I'd work on a PR specifically for that
19:31:29 <shertel> I think we'd really need a quorum to vote on backporting  changes that break playbooks.
19:31:48 <jillr> +1
19:32:09 <felixfontein> I know, I mainly want to get a rough idea how that quorum could end up as :)
19:32:29 <shertel> I'm -1
19:32:35 <shertel> (I think)
19:32:41 <felixfontein> if it is very likely that it will be backported, I'd create a PR for that behavior, so that it can be discussed as well. if not, then I won't
19:32:56 <jillr> I'd want to actively discuss it before deciding, I can see good cases for both options but neither is great. I think I lean -1?
19:33:25 <felixfontein> ok, in that case no PR. thanks! :)
19:34:07 <jillr> any other opens?
19:37:04 <jillr> thanks folks!
19:37:07 <jillr> #endmeeting