18:59:27 #startmeeting Ansible Core Public Meeting 18:59:27 Meeting started Tue Nov 8 18:59:27 2016 UTC. The chair is abadger1999. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:59:27 Useful Commands: #action #agreed #halp #info #idea #link #topic. 18:59:27 The meeting name has been set to 'ansible_core_public_meeting' 18:59:36 #topic Roll Call 18:59:41 Who all is here? 18:59:49 * Qalthos waves 18:59:58 * skuznets raises hand 19:00:27 Quite the crows 19:00:31 Crowd** 19:01:05 * jimi|ansible here 19:01:11 * bcoca waves 19:01:17 #chair Qalthos skuznets jimi|ansible bcoca jlk 19:01:17 Current chairs: Qalthos abadger1999 bcoca jimi|ansible jlk skuznets 19:01:31 oh, I get a chair? 19:01:35 * jlk sits 19:01:40 * bcoca wants sofa 19:01:51 jlk: you get a stationary bike 19:01:58 YASSS 19:02:08 :) 19:02:10 * bcoca will settle for cheslon 19:02:13 #topic discuss publishing versioned documentation -- skuznets 19:02:22 hi 19:02:30 * bcoca waves 19:02:51 Last time we passed on this as we were missing the dev who was implementing it --- but I can't remember who that was. Are they here now? 19:03:09 we asked him to join 19:03:15 dharmabumstead -- I've jsut pinged him to see if he'll drop in. 19:04:29 is he on irc at all? don't see him in any channel (unless he's using a nick i can't guess) 19:06:02 weird :0 19:06:09 Well, if not -- the reason I brought this up was that I had run into some situations where the documentation on the publically-facing domain was misleading since it was generated from devel. 19:06:22 He can get on (was on for the docsprint) but he hasn't been joining the #ansible channels. 19:06:28 regularly. 19:06:31 Last I understood there is an undertaking to publish versioned documentation from release tags 19:06:49 I recall such a conversation 19:06:55 I'm not sure there's a huge amount to talk about, unless there is uncertainty re: implementation 19:06:55 skuznets: i proposed a while ago a simple division /devel and teh default being current stable 19:07:05 ^ having every version becomes a maintenance nightmare 19:07:05 bcoca: that seems perfectly reasonable 19:07:18 bcoca: due to drift in the generation scripts? 19:07:35 all features have version_Added (if not, its a bug) 19:07:36 due to drift in text, having to backport fixes, etc. 19:07:51 skuznets: no, cause a fix to a fundamental doc then needs to be cherry picked to 20 versions/branches 19:07:51 bcoca: Are the pages static? If so, won't the version of the doc generation script at the checkout you use generate a stable static content for the docs domain> 19:08:01 bcoca: aaah ack 19:08:08 dharmabumstead started making some proposals at our last internal meeting (earlier today). He does have versioned docs on there but not much information. 19:08:09 bcoca: they do have version added, however that's not very clear to new folks 19:08:10 Challenges: 19:08:10 - Versioned docs? 19:08:16 they don't expect to have to look at it 19:08:24 it doesn't have to be that crazy, we can say X number of previous versions are updated 19:08:33 I mean, ideally the commit that brings in a change to some core functionality also contains the doc changes there ,right? 19:08:41 * resmo waves 19:08:47 skuznets: sometimes, not always 19:08:49 Since you're cherry-picking that fix commit, you then also get the docs for free? 19:08:52 #chair resmo 19:08:52 Current chairs: Qalthos abadger1999 bcoca jimi|ansible jlk resmo skuznets 19:08:54 bcoca: seems easy to enforce 19:09:09 skuznets: consider someone reorganizing developer docs for 2.3 - are we backporting that major revision in the docs to 2.2 and 2.1 docs too? 19:09:09 skuznets: not always, specially with 3 repos 19:09:14 will be easier when 1 repo 19:09:35 skuznets: Looking at some of the other things that dharmabumstead wants to do... it may be easier for docs to be separate PRs from code changes. 19:09:54 skuznets: also sometimes we 'backport a fix' but dont release it, cause it is 'nice to have' but not important enought to merrit a release (it is there jic we do release due to something else) 19:09:57 abadger1999: will they continue to be inline doc in the module? or in a separate repo? 19:10:15 He wants docs review of documentation changes.... We could figure some compromise there, though... 19:10:18 ^ i REALLY dont want separate repos 19:10:19 skuznets: Oh god, no. 19:10:25 no separate repos 19:10:37 but maybe different files - instead of having module docs be a docstring in the module 19:10:38 Please no. 19:10:42 jimi|ansible, abadger1999 please comment on the doc, as that is one thing that is prposed 19:10:45 (to separate repos) 19:10:50 Maintenance cost of many versions is clear -- maybe devel, last two stable releases? What's the support statement for old releases? 19:10:52 bcoca: yeah. 19:11:20 what doc ? 19:11:39 skuznets: then there is also google ... 19:11:51 #chair dminca 19:11:51 Current chairs: Qalthos abadger1999 bcoca dminca jimi|ansible jlk resmo skuznets 19:11:52 bcoca: sorry, could you be more clear? 19:12:04 aww thx man 19:12:05 when we change/move things (which having limited versions would require) we loose "searchability" 19:12:25 * dminca finally sits on chair 19:12:29 dminca: He asked internally for feedback... it should get posted externally in the next few weeks as well. 19:13:03 I can't promise exactly when... just that "it's coming" :-) 19:13:17 I see 19:13:45 bcoca: I don't quite understand the searchability issue 19:14:12 Oh hey! 19:14:15 #chair dharmabumstead 19:14:15 Current chairs: Qalthos abadger1999 bcoca dharmabumstead dminca jimi|ansible jlk resmo skuznets 19:14:23 Someone rang? 19:14:30 bcoca: you mean if there isn't a stable URL for i.e. the "file" module? 19:14:31 dharmabumstead: Meet skuznets and dminca. 19:14:38 Hi! 19:14:40 * skuznets waves 19:14:47 skuznets: that is only part of it, we update plenty of docs per version outside modules 19:15:10 * bcoca moves to table the tabling 19:15:14 dharmabumstead: skuznets added versioned docs to this week's agenda. 19:15:23 I see. 19:15:25 * dminca wave 19:16:06 That's something we need to figure out. 19:16:40 versioned docs as in auto-generated from git repo releases ? 19:16:55 Yes 19:17:03 that could be interesting 19:17:09 i proposed alternate / <= stable and /devel 19:17:27 as maintaining backwards versions can be very cumbersome 19:17:37 To be specific, the issues that I ran into that lead to this topic were API incompatibilities between what was listed on the docs domain (since it is from devel) and what I had installed on my machine 19:17:37 why not keep `master` as stable 19:17:39 +1 (though I know we'll get pushback) 19:17:42 Do we keep older / historical versions of Ansible around? 19:18:02 dharmabumstead: technically, all of them ... its git 19:18:04 dminca: that's not the way Ansible itself works 19:18:05 dharmabumstead: The tarballs remain on releases.ansible.com and the releases are tagged in git 19:18:08 ^^ do you guys have explicit support statements for your GA releases? 19:18:17 dharmabumstead: we don't push people to using older releases, though. 19:18:18 skuznets: we're getting there 19:18:26 nitzmahone it's the way git works :) 19:18:28 dminca: we dont have master branch, we have stable-X.y 19:18:40 ^ at one point we only have tags 19:18:44 dminca: only if that's your workflow. It's not ours 19:18:46 nitzmahone: Once official support statements hit I would expect the versioned docs for those releases that are currently supported to exist and be kept up to date, yes? 19:18:50 bcoca I thought that's why Releases are for 19:18:52 We might want to start archiving the HTML docs 19:18:58 dminca: nope 19:19:20 nitzmahone not arguing, just saying 19:19:32 dminca: master is convention in git, you can use any branch as master, github deals with relases, but not git, which is why we use branches + tags 19:19:33 The problem is that maintaining multiple versions of the docs is not practical 19:19:54 dharmabumstead: three is no archiving as we dont currently have dupes, but we have 'history' 19:19:59 ^ its what VCS does 19:20:00 From a workload perspective. 19:20:04 bcoca I understand now 19:20:24 What are the pros/cons of requiring for example core module changes to be accompanied with doc updates (either in the PR or in the commit), so when the cherry-pick happens for older release branches, a nightly rebuild of the static docs for that release can occur and pick the changes up? 19:20:29 I'd be more supportive of "static archive" and "maintained current stable + devel" 19:20:41 dharmabumstead multiple versions of docs = multiple versions of old software available => backwards compatbility required 19:20:41 I know for module docs we've got some version added and deprecated indicators. 19:20:52 I'm also not _super_ knowlegeable here -- how much of the documentation isn't auto-generated? 19:21:03 Rarely should updates to released versions require doc changes, since we don't backport features, just bugfixes. 19:21:23 skuznets: docsites/rst has most of the 'static' docs 19:21:28 Sure. Archiving the old docs versions with their corresponding software is not a huge deal. Actively maintaining that stuff is. 19:21:30 docsite/rst 19:21:47 don't be like docker 19:21:47 s/archiving/deleting from site/ 19:21:53 * resmo likes to have versioned module web docs (all modules in version ansible 2.1, 2.2), but keeping other docsite pages as is 19:22:01 update & throw old versions away 19:22:15 dharmabumstead: People don't find those (deprecated/version_added) to be sufficient. I'm not sure precisely why. Can someone say what makes separate versions better than the tags? 19:22:24 resmo: you sorta get that for free as-is with ansible-dolc 19:22:28 s/doic/doc 19:22:40 nitzmahone: speaking about web 19:22:44 abadger1999: diff way of not reading 19:23:22 abadger1999: almost reintroduced 'marquee' tag to docs to show version added 19:23:34 abadger: Usually what I've seen with those kinds of things is a big stripe across the top on archived versions of docs saying "this is not the most current, nor maintained version of these docs" with a link to the current version. 19:23:49 While I agree that trying to maintain non-generated documentation for multiple versions has a higher cost than not doing it ... how can that be avoided when there are multiple live versions that have active support statements? 19:23:57 * gundalow waves, Boarding flight in a bit 19:24:08 #chair gundalow nitzmahone 19:24:08 Current chairs: Qalthos abadger1999 bcoca dharmabumstead dminca gundalow jimi|ansible jlk nitzmahone resmo skuznets 19:24:12 * dminca waves to gundalow 19:24:14 skuznets: this is where ansible-doc is consistent with what is hsipped 19:24:16 shipped 19:24:18 skuznets: The support statements thing is still WIP 19:24:26 have a good flight 19:24:48 bcoca: ansible-doc? 19:24:51 * bcoca would be happy to remove most docs from website ... but suspects huge resistance 19:24:56 oh 19:24:57 you guys want to separate docs from code? 19:24:59 skuznets: when you install ansbile, you get ansible-doc 19:25:03 * nitzmahone reiterates that docs changes to released versions should be a very rare (if ever) occurrence 19:25:08 ansible-doc modulename <= docs for the moudle YOU HAVE 19:25:12 Yeah I don't think that's going to be the first place most people look for documentation 19:25:15 ansible-doc -l <= lists modules YOU HAVE 19:25:38 * dharmabumstead agrees fervently with @nitzmahome 19:25:43 nitzmahone: our history disagrees with you 19:25:45 man for ansible (sans all the cruft that man has) 19:26:01 bcoca: it does? 19:26:15 dharmabumstead: sadly we correct 'old docs' all the time, since a lot of them were made ... w/o much quality control 19:26:19 nitzmahone: Currently, we only make docs changes to the modules. But that's mostly because bugfixes to the module docs actually show up via ansible-doc. If we had versioned docs we probably would push a few changes to docsite back to previous versions too. 19:26:41 We should also try to differentiate between module docs and docsite/rst docs 19:26:45 maintaining versioned docs is really not complicated either. I have a 22 line script that does it currently. although I forgot to tell it to start making stable-2.2 currently 19:26:48 last 2 months i've stopped making many doc changes, but before that i've corrected a LOT of stuff 19:26:49 In this discussion 19:26:57 we even had docs for features we never had/added 19:27:03 ^ those are fun 19:27:08 Yeah. That's a windmill I am still tilting at 19:27:10 But I don't see us really ever pushing docsite-only changes to more than last stable + devel. 19:27:12 bcoca: ansible-doc ; thanks, never knew about that 19:27:24 abadger1999: that's what I was getting at 19:27:30 19:27:32 abadger1999: and i'm fine with that, i just dont want 1.3 docs 19:27:51 there is stable/devel, which i think is reasonable, then there is 'every version' 19:27:53 What sort of changes are both large enough to require changes to the core docsite pages and also be small enough to be backports? 19:28:11 Why not just version the documentation that _is_ generated from a specific version of the code? 19:28:21 bcoca: Generally I'd agree, but keeping static archived versions of those docs around once a new stable exists is fairly trivial. 19:28:28 ^^ 19:28:39 skuznets: that is what I am doing at https://ansible.sivel.net/docs/ 19:28:40 Yeah. Archiving is easy. Active maintenance is not. 19:28:57 sivel: So build script-wise, it should be simple, yeah... I think people are thinking of it in terms of correcting docs for older versions. 19:29:17 worry about that later 19:29:18 Adding a version tag to a set of generated docs is trivial. 19:29:25 Right, I guess the argument is that something that is large enough to impact something in the core docsite/rst docs is not also something that's going to get cherry-picked into older releases 19:29:33 Ergo, the _actual_ maintenance cost will be small 19:29:34 nitzmahone: my point is that those might be wrong and that when you update latest you'll still get complaints aobut the old ones 19:29:36 I am meh on correcting it. from my POV stable and devel are the only places I would care to target 19:29:46 "If we support the code with bugfixes, do we also have to support the docs with bugfixes?" I think we're saying that they can have two different support cycles. 19:29:47 bcoca: I see what you mean 19:29:51 Im not thinking/asking for maintained docs for old versions 19:29:56 Ok 19:29:57 sivel++ 19:30:10 all I want is the default docs to be of the current stable version, and an option to view docs for devel 19:30:17 yes 19:30:19 jlk ++ 19:30:22 ++ 19:30:23 That seems reasonable 19:30:26 jlk: i agree with that one, its the 'more versions' im against 19:30:38 and it makes sense to 'maintain stable' docs also 19:31:00 Would it make sense to _only_ have versioned docs for auto-genned thigns? 19:31:00 That'd be my ideal as well, just saying I'm sure we'll get pushback (we are in here already) about not keeping static archives. 19:31:17 skuznets: I don't think so 19:31:28 +1 to stable & devel only 19:31:30 skuznets: not really as many features are version dependant and 'statically' added, like lookup plugins 19:31:35 There are a lot of missing/incomplete/outdated docs 19:31:39 +1 stable and devel 19:31:43 bcoca: I see 19:31:52 old versions should get archived as well. If it's too hard, we'll stop. 19:31:54 I have no problem with taking a docset and setting it in amber and throwing it in an archive somewhere 19:31:57 nitzmahone: not static, we should generate / and /devel same way, jsut diff branch 19:32:10 The only issue I would have with stable+devel is when Ansible (inc?) is officially supporting more than one stable release ... 19:32:13 stable + devel solves the biggest problem ("why doesn't feature X added in devel work on stable?") 19:32:15 #info the high value here is docs for latest stable and devel with a way to switch between them. 19:32:16 ^ current deploy script needs very little to affect this change 19:32:17 +1 stable and devel, we can always expand on that later if there's enough demand and resources to support it 19:32:21 I don't see stable+devel flying in that situation 19:32:37 we just need to add a way to navigate stable <=> devel 19:32:37 especially if docs.ansible.com defaults to stable 19:32:38 oldstable? sound like debian :) 19:32:44 nitzmahone: agreed 19:32:48 This is how we handled it at eucalyptus: https://docs.eucalyptus.com/eucalyptus/4.3.0/#shared/doc_archive.html 19:33:32 dharmabumstead: and errors that were present in 3.2 but fixed in 4.3 do not percolate back? 19:33:49 https://robpol86.github.io/sphinxcontrib-versioning/ 19:34:27 Static warning/switcher example: https://msdn.microsoft.com/en-us/library/system.diagnostics.process(v=vs.100).aspx 19:34:37 @bcoca: no. 19:35:00 dharmabumstead: which is a big painpoint when you 'older' docs are very inaccurate sometimes 19:35:14 Yep. I believe we put a disclaimer header at the top 19:35:18 From the Microsoft website: "" 19:35:20 This documentation is archived and is not being maintained"" 19:35:24 Yep, the euca docs had a (smallish) header. 19:35:26 Seems perfect 19:35:28 alikins: we had user try to implement that once, iirc we had to rewrite our docs to accomodate the versioning 19:36:14 At Euca we had a current branch and an equivalent of a devel branch for work on upcoming releases 19:36:24 we currently have labels about which version something was added, people dont read those either 19:36:49 bcoca: only sometimes** 19:36:54 TBF. those are also much less noticeable in the sea of text than a big yellow banner. 19:37:00 bold/italic The version_added fields may be a simple improvement 19:37:22 gundalow: i raised it to be biggest font outside headers 19:37:31 also moved in options to under option name 19:37:39 I also feel like keeping all the version_added stuff in the current doc (and pruning that as the versions get old) seems like a lot more work ... 19:37:43 ^ tempted to add marquee tag back ... 19:37:58 (Apologies for delayed responses - tending to another sick kid home from school today. Little Petri dishes) 19:37:58 skuznets: we dont prune, script does it 19:38:00 blink tag FTW 19:38:10 we keep the version_added info in docs indefinetly 19:38:14 bcoca: ack 19:38:18 dharmabumstead: Hopefully you aren't the petri dish ;-) 19:38:28 skuznets: its just a setting we change in the generator 19:38:32 version_added for modules in particular (which is the most problematic) are enforced by CI 19:38:37 'ignore < 1.7' 19:38:54 In any case while some of these are clearly contentious ... getting the default page to be from stable and not devel, and at least having those two clearly delineated would be a 1000x improvement 19:38:55 Ha! Nope. I'm thinking of stocking up on surgical scrubs to wear around them though. 19:39:04 Module PRs that are missing version_added will bomb 19:39:07 agreed on 'stable' by default 19:39:13 ^ i think we are all fine with that 19:39:28 skuznets: that seems reasonable to me 19:39:42 having devel is even optional at that point 19:39:51 ^ though i like having it for 'preview' 19:40:02 devel.docs.ansible.com 19:40:04 and since plugins are mostly downloadable, allows people to use them right away 19:40:27 #info Make default page latest stable with the ability to switch to the devel version. 19:40:28 nitzmahone: might need docs.ansible.com/ansible/devel as we share with tower 19:41:10 Yeah, so long as those also get the "prerelease docs, may describe things you can't do yet, go HERE for released stuff" 19:41:54 Okay, I've tagged to ideas from this that seem to be broadly agreed upon. Are there other things that we want to agree on here today? 19:42:09 *tagged two ideas 19:42:17 "We're happy the US election is almost over and done with" 19:42:29 * dharmabumstead applauds 19:42:32 * bcoca moves to spain no matter what the outcome 19:43:34 * dharmabumstead might have to marry his Scottish girlfriend so he can move. 19:43:44 dharmabumstead: as for euca did not see the 'important archive not updated' till i backtracked, its only clear if you follow specific path 19:43:47 0.0 19:44:10 skuznets: Anything else you need from this discussion? 19:44:17 people that land on a page from google ... dont see that disclaimer 19:44:29 * skuznets is satisfied 19:44:32 Cool. 19:44:34 * gundalow -> offline 19:44:34 I've been gone from Euca for a while and I'm old, so I forgot exactly what we did 19:44:43 abadger1999: so 1) stable becomes default for docs and 2)? 19:44:54 the high value here is docs for latest stable and devel with a way to switch between them. 19:45:16 ah, so 2) add devel and navigation between them 19:46:04 Let's do a header at the top 19:46:06 yep. don't worry about archival copies of any further back than that for now.... there's not a pain point for older versions. 19:46:31 dharmabumstead: Sounds good -- for devel? Or for latest stable? 19:46:31 yeah (similar to how django docs do it) 19:46:42 "You're looking at the most current stable release of the documentation. To see the devel version, click here" 19:46:50 gotcha 19:46:51 And vice versa 19:47:04 Sound workable? 19:47:04 oh...they moved their selector to the footer. Same idea 19:47:09 #info banner on docs pages to point people from devel to latest stable and vice versa 19:47:31 you are in click to go to 19:47:37 We can do header & footer if we want. As long as it's easy to find 19:47:41 Yeah, you gotta banner at least devel (thanks, Google). Bannering stable might be counterproductive 19:47:51 (people get used to seeing the banner and don't actually read it) 19:48:12 +1 to banner devel, -1 to stable 19:48:22 shaps: are you here? 19:48:39 nitzmahone: change colors on banner 19:48:47 Guessing 99+% of visitors to docs.ansible.com don't care about devel. 19:48:49 devel is red, stable is black 19:49:00 ^-- that might be ok 19:49:14 nitzmahone: except when they search for specific module that only exists in devel, which is when we hear complaints 19:49:19 (or not colored at all, just text on normal background for stable) 19:49:25 *cough*bikeshed. *cough* 19:49:36 almost NEVER we hear the complaint for 'feature x in the docs', its 99% time for a module 19:49:38 touche 19:50:02 ok, not colored, but they should have green/red glow 19:50:04 I actually have a list of very specific fonts I would like to see this banner written in 19:50:07 Is that possible? 19:50:23 I'm thinking Comic Sans, Windings, you know 19:50:25 skuznets: you can specify the list, but as with all OSS, depends on who implements it 19:50:25 ;) 19:50:36 bcoca: I'm ribbing the bike-shedding comment you made 19:50:56 skuznets: sorry, noto sans for all content ever going forward. ;) 19:50:58 Okay, moving on. 19:51:08 I think gundalow needs to be present for the file discussion. 19:51:48 Good discussion. Thanks! 19:51:50 ControlPath directory from shaps was merged already 19:52:10 dharmabumstead: Thanks for being here to contribute! Made this productive :-) 19:52:24 :) 19:52:59 Jmainguy evaluated the mysql issue... We can revisit that one again next week if he and the reporter look into it more. 19:53:16 #topic Open floor 19:53:16 tis true 19:53:20 once split we might want to add note to 'devel' side "these are things in flight,b ut you might be able to use if you really need them if you download the plugin " 19:53:32 Discussion around how to more correctly use the Ansible `Display` 19:53:51 #topic Using ansible Display - skuznets 19:53:58 Go ahead skuznets 19:54:00 Source here: https://github.com/ansible/community/issues/132#issuecomment-257011653 19:54:10 Basically, the current way of getting a global singleton is a little hackey 19:54:23 The __main__ namespace won't be around for py3 anyway 19:54:40 'little'? .... i thought it was VERY 19:54:48 And futhermore the `try: from __main__ import display` blocks that exist at the top of every file are completely and utterly broken 19:55:03 Like as in they try to get a global singleton but if one doesn't exist .. they jsut all make a copy local to the file 19:55:11 skuznets: that had to do with changes of the forking, most shoudl be irrelevant now 19:55:18 I'm consuming Ansible through the API, not through your ABI 19:55:30 ah .. then that will hurt you 19:55:31 Which means I am playing __init__.py cold war with you guys 19:55:38 And trying to shove a display into __main__ before you look for it 19:55:40 This sucks 19:55:52 skuznets: I haven't seen any problems with using __main__ in python3. 19:55:53 https://github.com/bcoca/ansible/tree/top_lvl_callback <= my vision of future, currently relying on display global 19:56:26 abadger1999: PyCharm tells me __main__ as a namespace is gone in 3.5 19:56:42 im fine with removing the hackey import, just need to make display a global 19:56:42 Hmm... I just updated to py3.5 I'll take a look at that. 19:57:10 So this also couples with my other point 19:57:33 In the CLI it's basically broken into a couple steps -- one to gather options, then one to validate them, then one to use them to run something 19:57:49 Unfortunately for whatever reason we've decided to change things like the display verbosity in the __first__ step 19:58:20 Which means for an API consumer (of which there are few today but will be more soon) ... there's no action if I construct an options structure and pass it in 19:58:38 Since an API consumer enters the workflow _after_ the CLI options would have been parsed 19:58:40 We use a Singleton metaclass for declaring singletons in an app, instead of globals 19:58:51 something like https://gist.github.com/sivel/469ea4fc3629179b1bec0a78a09a2a93 19:58:53 Singleton is easier in py3 as well 19:58:58 sivel: 2.6 friendly? 19:59:12 bcoca: we do all this in 2.7, I would assume that metaclass would work in 2.6 19:59:25 but I haven't explicitly tried it 19:59:43 ^ i remember someone brought up issues with that ... just cannot remember what they were 19:59:46 and we just set `__metaclass__ = Singleton` on the class we want to be a singleton 20:00:52 Why do we want a singleton so bad? 20:00:53 it calls itself as super? 20:01:18 There's one pretty clear flow of data from cli ---> executor, right? 20:01:18 skuznets: avoid multple forks trying to output with diff settings 20:01:32 Where does the fork occur? 20:01:40 cli -> executor, yes, results-> cli ... not as much 20:01:56 skuznets: task_queue_manager 20:02:04 Well if CLI --> TQM/executor ... and the only display changes happen at cli option parse-time... 20:02:06 which also emits most output events 20:02:24 How is the TQM mutating the display state? 20:02:29 skuznets: if diff objects, then you have to pass options everywhere 20:02:40 bcoca: sorry, unclear 20:02:45 callback plugins 20:02:57 sorry, still not following 20:02:59 also, nothing prevents custom plugins from doing so 20:03:07 Something should :) 20:03:20 I would not be happy if a plugin changed the verbosity level that I as a user asked for 20:03:22 not having plugins? once you execute code in process .... 20:03:23 Seems silly 20:03:35 I think you've lost me 20:04:05 What you're saying is some Display object that encapsulates display options will be mutated after being passed to a plugin? 20:04:11 So, this may not be a popular comment, but why are we spending this much time talking about this? Seeing as though for one, we don't encourage or support the use of the internal API? 20:04:12 And this is why we want a global singleton? 20:04:21 no, meant about display in general, but that can ALSO happen 20:04:33 sivel: I see it as a health of the code-base sort of thing 20:04:41 Mutable global singletons don't usually lead to anything nice 20:04:44 sure, but it works as is 20:04:58 I mean 20:04:59 Sure 20:05:18 But poor code health impedes refactors and feature generation down the road 20:05:28 https://github.com/bcoca/ansible/tree/top_lvl_callback <= planning changes here to filter more things through callbacks, relying on current display/main, i'm open to better way 20:05:44 bcoca: I'll take a look at your diff there 20:06:08 Let's table this for now with the understanding that the current impl is a massive hack and would be nice if we could improve it 20:06:10 WIP, early draft of intentions 20:06:16 bcoca: ack 20:06:16 I do however agree, that callbacks should be how things get displayed, and my pref would be that all output does happen only via callbacks 20:06:23 sivel: ++ 20:06:29 sivel: look at my branch 20:06:50 I'd modify that a tiny bit -- all display to stdout should go through callbacks. 20:07:00 ^ moving display to be the 'callback holder' and from cli, then we can move all output to filter through that 20:07:06 abadger1999: yeah, I'd be fine with that 20:07:10 I think there's room to output errors to stderr still. 20:07:25 ideally, only MainProcess/MainThread would be writing to stderr/stdout directly, mp workers etc would queue to it so main can output it via a display callback plugin 20:07:28 errors alrady go to stderr 20:07:59 Yeah, we had some of this conversation last week 20:08:09 Seems like we haven't much changed our minds since then :) 20:08:26 alikins: that is currently the case (except for -v or debug), the issue is prefork proccesses that emit messages before callbacks are loaded 20:09:10 ^ my branch loads callbacks 'early' so now we can change those to send_callback() and avoid using display directly 20:10:03 biggest issue is 'loading' new callbacks as plays/roles introduce them, need to figure that out 20:11:01 bcoca: I guess I'm more meaning... callbacks output to stdout and everything else goes to stderr (including debug and verbosity output from outside of callbacks). 20:11:33