=== uru-afk is now known as urulama === CyberJacob|Away is now known as CyberJacob === balloons_ is now known as balloons === HankM00dy is now known as thehe === carlas is now known as carlasouzza === carlasouzza is now known as carlasouza === psivaa_ is now known as psivaa [14:42] 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] 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] 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] stub: true, i hadn't thought of that [14:54] 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] 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] stub: yeah, i think covering the (extremely) common case is sufficient [14:57] stub: thanks for your input === scuttle|afk is now known as scuttlemonkey [15:00] 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] cory_fu: i think you're missing the "write your own custom key/val data to Config" aspect [15:04] cory_fu: you can write whatever you want to the object and it'll be saved and available in the next hook === CyberJacob is now known as CyberJacob|Away [15:06] 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] meh [15:07] :) [15:12] tvansteenburgh: stub's concern also raises issues with idempotency when re-executing config-changed hooks during `juju resolved --retry`. [15:13] cory_fu: be more specific? [15:14] 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] cory_fu: yeah, i agree [15:15] "save on success" would be awesome, if it could be consistent [15:15] cory_fu: maybe Config and ArbitraryData should be separate, but right now they are conflated. [15:15] cory_fu: but i already agreed to do the save() in @hook, so that covers that concern right? [15:16] cory_fu: It isn't too late to change that though - the benefit of hiding documentation in docstrings. [15:17] stub: i don't follow re docs? [15:17] tvansteenburgh: What about people who don't use @hook and instead use something superior like the services framework? ;) [15:17] tvansteenburgh: I don't think many people are using this feature, so we could get away with changing behaviour. [15:17] cory_fu: you can call save() explicitly, or work it into your framework [15:18] Or better yet, move your framework to charm-helpers so we can all benefit :-P [15:18] 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] stub: The docstrings are published online [15:18] doh [15:18] stub: Also, the services framework is in charmhelpers now =D [15:19] 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] stub: Actually it's the second result for "charmhelpers" on Google, even. http://pythonhosted.org//charmhelpers/ [15:20] So save will need to be hooked into two places then, since both mechanisms are supported. [15:20] Aww. My doc improvements haven't been merged & published in those. :( [15:21] cory_fu, is there a good place to hook it into the services framework? [15:21] cory_fu, have your new docs been merged yet? if so i can push a new docs release [15:22] lazyPower: failed me [15:22] * stub guesses reconfigure_services in base.py [15:23] tvansteenburgh, stub: Yeah, or manage. [15:23] yer, manage [15:26] 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] cory_fu: sorry, i'm not in Charm Helpers Maintainers [15:29] tvansteenburgh: I guess I should bug marcoceppi instead, then. :) [15:34] I am sad that I don't get automatically notified of updates to MPs that I've commented on [15:41] cory_fu: what are you talking about? [15:41] i merged that days ago :P [15:41] * lazyPower sweeps it under the rug [15:44] "Charles Butler (lazypower) wrote 2 minutes ago" ;) [15:45] must have been stuck in a queue somewhere [15:47] :p [15:48] lazyPower: Any chance you also looked at https://code.launchpad.net/~johnsca/charm-helpers/docker/+merge/231226 ? [15:49] That one's more substantial, though, so "no" is a fair answer. :) [15:49] cory_fu: i skimmed it, but not enough to merge it [15:49] Ok [16:14] marcoceppi: how did mongodb NY meetup go? [16:14] any video by chance? [16:17] 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] but ill let him drop the details :) [16:18] JAZZ HANDS! [16:18] * arosales anticipates the jazz hand update :-) [16:24] tvansteenburgh: Since lazyPower apparently merged my doc changes "ages ago," can you update the published docs? [16:25] haha [16:25] cory_fu: yeah gimme a min [16:25] Thanks. :) [16:34] cory_fu: updated [16:34] Thanks [16:45] arosales: it went really well [16:45] * marcoceppi jazz hands [16:46] marcoceppi: any video of the meetup? [16:47] arosales: unfortunately, no [16:47] marcoceppi: ah ok. [16:47] marcoceppi: Good to hear it went well, and Jazz Hands were included. [16:54] Doc error: https://juju.ubuntu.com/docs/config-vagrant.html has an example for vagrant box add JujuBox that has the URL outside the

 tag.
[16:59]  JoshStrobl: the URL being outside of the code display correct?
[16:59]  looks like how it was rendered, the source looks correct. thanks for pointing this out
[17:00]  lazyPower, yea no problem.
[17:01]  https://github.com/juju/docs/pull/143
[17:01]  jcastro, mbruzek, marcoceppi  ^
[17:01]  dibs!
[17:01]  JoshStrobl: and i stand corrected. vim lied to me. thanks again :)
[17:01]  \o/
=== roadmr is now known as roadmr_afk
[17:02]  jcastro: you gotta click faster than marco next time ^_^
[17:02]  lazyPower, and that is why I don't use Vim :P
[17:02]  Kidding, I just am too lazy to learn its keyboard shortcuts.
[17:02]  :set hidden  was the secret sauce
[17:02]  atom!
[17:02]  there was a carriage return hiding in there that rendered like the line length broke.
=== jrwren_ is now known as jrwren
[17:03]  also
[17:03]  https://juju.ubuntu.com/docs/authors-charm-quality.html
[17:03]  Upstream Friendly is in the list
[17:04]  should be outside the list like "Scalable"
[17:04]  We want that to be the case. Preferred if your charm delivers a mechanism for configureable upgrades, that follow upstream best practices.
[17:04]  OH
[17:04]  you mean teh bullet point
[17:04]  yea
[17:05]  much bullet points, such error
[17:06]  Okay jcastro, here is your chance to be more click happy than marco :P get ready!
[17:07]  https://github.com/juju/docs/pull/144 jcastro
[17:08]  <3
[17:08]  \o/
[17:16]  lazyPower, any idea why there is an unnecessary 4-space "tab" in the juju add-unit -n5 mediawiki 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]  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]  this is all rendered from src/en/*article-name*.md
[17:18]  lazyPower, sure thing
[17:18]  <3 thanks for the contribution/review JoshStrobl
[17:19]  https://github.com/juju/docs/pull/145
[17:21]  man, we are actually making progress on the queue now
[17:21]  Soon, there will be an end to the dark ages
[17:21]  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]  sounds good JoshStrobl
[17:48]  needs a review: https://github.com/juju/docs/pull/146
[17:49]  I went through every page real quick and checked for errors. Nothing too thorough since I'm a tad busy :P
=== roadmr_afk is now known as roadmr
=== mwhudson_ is now known as mwhudson
=== JoshStrobl is now known as JoshStrobl[ZZZ]