[14:42] <tvansteenburgh> stub, cory_fu: would appreciate your thoughts on my latest comment here: https://code.launchpad.net/~tvansteenburgh/charm-helpers/config-implicit-save/+merge/224678
[14:51] <stub> tvansteenburgh: I could live with it, but I still think it would be better to hook it into the @hook decorator and save on success.
[14:52] <stub> tvansteenburgh: With implicit save, you won't see what has changed since the last hook but what has changed since a previous piece of code changed a value. It is less useful.
[14:53] <tvansteenburgh> stub: true, i hadn't thought of that
[14:54] <tvansteenburgh> stub: i'm coming around to the idea of saving in decorator. will just have to document that you don't get the auto-save if you're not using the decorators
[14:55] <stub> tvansteenburgh: yes. I think that is better than magic (you could have both modes, with save-on-success being used if a @hook decorator has been entered and save-on-change being used otherwise, but that is probably the worst of all worlds ;) )
[14:56] <tvansteenburgh> stub: yeah, i think covering the (extremely) common case is sufficient
[14:57] <tvansteenburgh> stub: thanks for your input
[15:00] <cory_fu> tvansteenburgh: Sorry, stepped away for a minute.  The problem with "save on success" is that not every charm uses the @hook decorator and so what constitutes "success" varies.  Also, since you can't change config values from within a charm, saving on __del__ is no different (and seems riskier) than saving immediately after reading the previous values.
[15:02] <tvansteenburgh> cory_fu: i think you're missing the "write your own custom key/val data to Config" aspect
[15:04] <tvansteenburgh> cory_fu: you can write whatever you want to the object and it'll be saved and available in the next hook
[15:06] <cory_fu> tvansteenburgh: Hrm.  While that does seem useful, I worry that it implies that you can change the value of config options as visible outside the charm.  I wonder if "store arbitrary data" shouldn't be separated from "easily and detect changes in config"
[15:07] <tvansteenburgh> meh
[15:07] <cory_fu> :)
[15:12] <cory_fu> tvansteenburgh: stub's concern also raises issues with idempotency when re-executing config-changed hooks during `juju resolved --retry`.
[15:13] <tvansteenburgh> cory_fu: be more specific?
[15:14] <cory_fu> tvansteenburgh: Just that, in that corner case, running `resolved --retry` may not get you the same behavior because it will detect a different set of previous config values
[15:15] <tvansteenburgh> cory_fu: yeah, i agree
[15:15] <cory_fu> "save on success" would be awesome, if it could be consistent
[15:15] <stub> cory_fu: maybe Config and ArbitraryData should be separate, but right now they are conflated.
[15:15] <tvansteenburgh> cory_fu: but i already agreed to do the save() in @hook, so that covers that concern right?
[15:16] <stub> cory_fu: It isn't too late to change that though - the benefit of hiding documentation in docstrings.
[15:17] <tvansteenburgh> stub: i don't follow re docs?
[15:17] <cory_fu> tvansteenburgh: What about people who don't use @hook and instead use something superior like the services framework?  ;)
[15:17] <stub> tvansteenburgh: I don't think many people are using this feature, so we could get away with changing behaviour.
[15:17] <tvansteenburgh> cory_fu: you can call save() explicitly, or work it into your framework
[15:18] <stub> Or better yet, move your framework to charm-helpers so we can all benefit :-P
[15:18] <tvansteenburgh> cory_fu: i'm not sure what you're arguing for at this point, is there a better place to do the save?
[15:18] <cory_fu> stub: The docstrings are published online
[15:18] <stub> doh
[15:18] <cory_fu> stub: Also, the services framework is in charmhelpers now  =D
[15:19] <cory_fu> tvansteenburgh: I can't really think of one, no.  I'm just pointing out that the concept of "on success" isn't universal.  But I guess covering some bases is better than covering none
[15:19] <cory_fu> stub: Actually it's the second result for "charmhelpers" on Google, even.  http://pythonhosted.org//charmhelpers/
[15:20] <stub> So save will need to be hooked into two places then, since both mechanisms are supported.
[15:20] <cory_fu> Aww.  My doc improvements haven't been merged & published in those.  :(
[15:21] <tvansteenburgh> cory_fu, is there a good place to hook it into the services framework?
[15:21] <tvansteenburgh> cory_fu, have your new docs been merged yet? if so i can push a new docs release
[15:22] <cory_fu> lazyPower: failed me
[15:22]  * stub guesses reconfigure_services in base.py
[15:23] <cory_fu> tvansteenburgh, stub: Yeah, or manage.
[15:23] <stub> yer, manage
[15:26] <cory_fu> tvansteenburgh: Do you have merge powers in charmhelpers?  I'm sad https://code.launchpad.net/~johnsca/charm-helpers/services-docs/+merge/231235 hasn't been merged yet, despite being (practically) nothing but a doc improvement
[15:27] <tvansteenburgh> cory_fu: sorry, i'm not in Charm Helpers Maintainers
[15:29] <cory_fu> tvansteenburgh: I guess I should bug marcoceppi instead, then.  :)
[15:34] <cory_fu> I am sad that I don't get automatically notified of updates to MPs that I've commented on
[15:41] <lazyPower> cory_fu: what are you talking about?
[15:41] <lazyPower> i merged that days ago :P
[15:41]  * lazyPower sweeps it under the rug
[15:44] <cory_fu> "Charles Butler (lazypower) wrote 2 minutes ago"  ;)
[15:45] <lazyPower> must have been stuck in a queue somewhere
[15:47] <cory_fu> :p
[15:48] <cory_fu> lazyPower: Any chance you also looked at https://code.launchpad.net/~johnsca/charm-helpers/docker/+merge/231226 ?
[15:49] <cory_fu> That one's more substantial, though, so "no" is a fair answer.  :)
[15:49] <lazyPower> cory_fu: i skimmed it, but not enough to merge it
[15:49] <cory_fu> Ok
[16:14] <arosales> marcoceppi: how did mongodb NY meetup go?
[16:14] <arosales> any video by chance?
[16:17] <lazyPower> as a third party comment re: marcoceppi at NY MONGODB - he came to standup with jazz hands with talk about how to refine our presentation process if your audience is hipsters.
[16:17] <lazyPower> but ill let him drop the details :)
[16:18] <jcastro> JAZZ HANDS!
[16:18]  * arosales anticipates the jazz hand update :-)
[16:24] <cory_fu> tvansteenburgh: Since lazyPower apparently merged my doc changes "ages ago," can you update the published docs?
[16:25] <lazyPower> haha
[16:25] <tvansteenburgh> cory_fu: yeah gimme a min
[16:25] <cory_fu> Thanks.  :)
[16:34] <tvansteenburgh> cory_fu: updated
[16:34] <cory_fu> Thanks
[16:45] <marcoceppi> arosales: it went really well
[16:45]  * marcoceppi jazz hands
[16:46] <arosales> marcoceppi: any video of the meetup?
[16:47] <marcoceppi> arosales: unfortunately, no
[16:47] <arosales> marcoceppi: ah ok.
[16:47] <arosales> marcoceppi: Good to hear it went well, and Jazz Hands were included.
[16:54] <JoshStrobl> Doc error: https://juju.ubuntu.com/docs/config-vagrant.html has an example for vagrant box add JujuBox that has the URL outside the <pre> tag.
[16:59] <lazyPower> JoshStrobl: the URL being outside of the code display correct?
[16:59] <lazyPower> looks like how it was rendered, the source looks correct. thanks for pointing this out
[17:00] <JoshStrobl> lazyPower, yea no problem.
[17:01] <lazyPower> https://github.com/juju/docs/pull/143
[17:01] <lazyPower> jcastro, mbruzek, marcoceppi  ^
[17:01] <jcastro> dibs!
[17:01] <lazyPower> JoshStrobl: and i stand corrected. vim lied to me. thanks again :)
[17:01] <JoshStrobl> \o/
[17:02] <lazyPower> jcastro: you gotta click faster than marco next time ^_^
[17:02] <JoshStrobl> lazyPower, and that is why I don't use Vim :P
[17:02] <JoshStrobl> Kidding, I just am too lazy to learn its keyboard shortcuts.
[17:02] <lazyPower> :set hidden  was the secret sauce
[17:02] <jcastro> atom!
[17:02] <lazyPower> there was a carriage return hiding in there that rendered like the line length broke.
[17:03] <JoshStrobl> also
[17:03] <JoshStrobl> https://juju.ubuntu.com/docs/authors-charm-quality.html
[17:03] <JoshStrobl> Upstream Friendly is in the list
[17:04] <JoshStrobl> should be outside the list like "Scalable"
[17:04] <lazyPower> We want that to be the case. Preferred if your charm delivers a mechanism for configureable upgrades, that follow upstream best practices.
[17:04] <lazyPower> OH
[17:04] <lazyPower> you mean teh bullet point
[17:04] <JoshStrobl> yea
[17:05] <JoshStrobl> much bullet points, such error
[17:06] <JoshStrobl> Okay jcastro, here is your chance to be more click happy than marco :P get ready!
[17:07] <lazyPower> https://github.com/juju/docs/pull/144 jcastro
[17:08] <jcastro> <3
[17:08] <JoshStrobl> \o/
[17:16] <JoshStrobl> lazyPower, any idea why there is an unnecessary 4-space "tab" in the <code>juju add-unit -n5 mediawiki</code> section of https://juju.ubuntu.com/docs/charms-scaling.html . I know it is just spacing, just a bit of nitpicking I guess, since there are add-unit calls below that, that aren't spaced that way.
[17:17] <lazyPower> JoshStrobl: probably due to the docs being in a quick rewrite when they were translated to markdown. It was done by a human so it may have some inconsistencies.  If you land a PR we'll review it.
[17:17] <lazyPower> this is all rendered from src/en/*article-name*.md
[17:18] <JoshStrobl> lazyPower, sure thing
[17:18] <lazyPower> <3 thanks for the contribution/review JoshStrobl
[17:19] <JoshStrobl> https://github.com/juju/docs/pull/145
[17:21] <jcastro> man, we are actually making progress on the queue now
[17:21] <jcastro> Soon, there will be an end to the dark ages
[17:21] <JoshStrobl> lazyPower, I'll git pull my fork, if there are a bunch of changes, I'll make them locally, commit them as a group of changes and do a pull request from that so there won't be several pull requests unnecessarily.
[17:32] <lazyPower> sounds good JoshStrobl
[17:48] <JoshStrobl> needs a review: https://github.com/juju/docs/pull/146
[17:49] <JoshStrobl> I went through every page real quick and checked for errors. Nothing too thorough since I'm a tad busy :P