[08:19] <frankban> morning rogpeppe: how are you doing?
[08:19] <rogpeppe> frankban: hiya
[08:19] <rogpeppe> frankban: not too bad
[08:19] <rogpeppe> frankban: just reading the leader election thread
[08:20] <frankban> rogpeppe: are you migrating filetesting?
[08:20] <rogpeppe> frankban: yes, i have a LGTM and can merge it
[08:20] <rogpeppe> frankban: i'll do that now
[08:21] <frankban> rogpeppe: ok I moved the card in coding and assigned to you, please put it in daily accomp. when done.
[08:22] <frankban> rogpeppe: do you have notes on the migration steps?
[08:22] <rogpeppe> frankban: hmm, i thought i had a card
[08:22] <rogpeppe> frankban: i haven't made the notes yet, but i've got all the shell history :-)
[08:23] <frankban> rogpeppe: cool, could you please share it? you have a card for utils, I believe you switched to filetesting because some packages in utils depend on it, correct?
[08:23] <rogpeppe> frankban: yup
[08:24] <rogpeppe> frankban: zip/zip_test.go
[08:24] <rogpeppe> frankban: that seems to be the only one
[08:26] <frankban> rogpeppe: cool, I guess I am going to migrate schema
[08:27] <rogpeppe> frankban: that should probably go inside utils, i think
[08:27] <rogpeppe> frankban: i don't really think it justifies its own repo
[08:28] <rogpeppe> frankban: then again, i don't mind much
[08:28] <rogpeppe> frankban: if you think otherwise
[08:29] <frankban> rogpeppe: I proposed the same last week and David said: "Yes to migrating it, no to renaming it. Schema is useful as a top
[08:29] <frankban> level project, rather than buried in an amorphous utils repo."
[08:30] <rogpeppe> frankban: ok, fair enough
[08:34] <frankban> rogpeppe: ugm. it seems I don't have permission to create a repo in juju :-/
[08:42] <frankban> rogpeppe: when you can, could you please 1) create a juju/schema repo (I don't have permission) and 2) send me the commands you used to split filetesting?
[08:45] <rogpeppe> frankban: 1) is now done
[08:45] <rogpeppe> frankban: for 2) you won't need the more complex commands that i used
[08:46] <rogpeppe> frankban: because you're not merging into an existing repo
[08:46] <rogpeppe> frankban: and you don't need to rewrite pathjs
[09:01] <frankban> rogpeppe: 1) thanks
[09:01] <frankban> rogpeppe: github says https://github.com/juju/schema is empty and I cannot fork it
[09:02] <rogpeppe> frankban: utils is now factored out; here's a trivial PR that adds README.md and LICENSE: https://github.com/juju/utils/pull/1
[09:02] <rogpeppe> frankban: you'll need to push directly to it initially
[09:05] <frankban> rogpeppe: ah, so initial push with an empty repo or with the actual repo generated by "git filter-branch"?
[09:05] <frankban> rogpeppe: LGTM
[09:06] <rogpeppe> frankban: the latter
[09:18] <frankban> rogpeppe: ERROR: Permission to juju/schema.git denied to frankban.
[09:40] <frankban> rogpeppe: any idea?
[09:41] <rogpeppe> frankban: sorry, missed your earlier comment
[09:41] <rogpeppe> frankban: looking
[09:41] <frankban> thanks
[09:42] <rogpeppe> frankban: what command did you use?
[09:42] <frankban> git remote add upstream git@github.com:juju/schema.git
[09:43] <frankban> git push upstream master
[09:43] <frankban> rogpeppe: ^^
[09:44] <frankban> rogpeppe: in https://github.com/juju/schema I only see:
[09:44] <frankban> This repository is empty.
[09:44] <frankban> Care to check out the GitHub Channel on YouTube while you wait?
[09:44] <rogpeppe> frankban: does it behave differently if you do: git remote remove upstream; git remote add upstream https://github.com/juju/schema.git ?
[09:45] <frankban> rogpeppe: it asks for user and password and then exits with: fatal: unable to access 'https://github.com/juju/schema.git/': The requested URL returned error: 403
[09:46] <rogpeppe> frankban: hmm, weird
[09:46] <rogpeppe> frankban: i'll try pushing a branch to it
[09:48] <frankban> rogpeppe: https://github.com/juju/schema/settings/collaboration ?
[09:49] <frankban> rogpeppe: now I see your branch but I cannot fork
[09:49] <rogpeppe> frankban: ah, i hadn't seen the collaboration settings
[09:49] <rogpeppe> frankban: you should be able to push now
[09:50] <frankban> rogpeppe: done, could you please remove the testing branch?
[09:50] <rogpeppe> frankban: yeah, just trying to work out how to do that
[09:52] <rogpeppe> frankban: hmm, it's not obvious...
[09:53] <frankban> rogpeppe: I did it
[09:53] <frankban> rogpeppe: git push upstream :testing
[09:53] <rogpeppe> frankban: ah yes, i'd forgotten that idiom
[09:57] <frankban> rogpeppe: https://github.com/juju/schema/pull/1
[09:58] <rogpeppe> frankban: LGTM
[09:59] <frankban> thanks
[10:28] <frankban> rogpeppe: could you please create a juju/names repo and give me write permission?
[10:28] <rogpeppe> frankban: yup
[10:31] <frankban> thanks
[10:34] <rogpeppe> frankban: done
[10:37] <frankban> rogpeppe: thanks
[10:37] <frankban> rogpeppe: could you please review https://github.com/juju/juju/pull/25 ?
[10:38] <rogpeppe> frankban: LGTM
[10:38] <frankban> rogpeppe: do you know if in the new git world dependencies.tsv changes are handled by the bot?
[10:39] <rogpeppe> frankban: i don't - best ask on #juju-dev
[10:39] <frankban> rogpeppe: yeah, already done
[10:39] <frankban> rogpeppe: thanks for the review, I guess I'll try to $$merge$$ it
[10:41] <rogpeppe> frankban: good plan
[10:42] <frankban> rogpeppe: and now names
[10:42] <frankban> rogpeppe: FWIW, these are the notes I've taken while migrating schema: http://pastebin.ubuntu.com/7593938/
[10:45] <rogpeppe> frankban: BTW your "fix import paths" step can be done automatically by running "govers -m github.com/juju/juju/schema github.com/juju/schema" in the schema directory
[10:46] <rogpeppe> frankban: what's the difference between an https remote and a git@github remote?
[10:46] <frankban> rogpeppe: https vs ssh
[10:47] <rogpeppe> frankban: is one preferred over the other?
[10:47] <frankban> rogpeppe: not sure, I prefer ssh because https asks me credentials
[10:48] <frankban> rogpeppe: ssh uses the ssh key
[10:49] <rogpeppe> frankban: hmm, i guess i can tell github about my ssh key
[10:50] <frankban> rogpeppe: https://help.github.com/articles/generating-ssh-keys
[11:27] <rogpeppe> jeeze my network is stupidly slow today
[11:47] <rick_h_> ssh is faster and uses the key vs password. 
[12:08] <frankban> rogpeppe: trivial https://github.com/juju/names/pull/1
[12:09] <rogpeppe> frankban: LGTM
[12:10] <frankban> rogpeppe: thanks
[12:50] <frankban> rogpeppe: could you please take a look at https://github.com/juju/juju/pull/27 ? (mechanical)
[12:52] <rogpeppe> frankban: did that previous branch merge ok?
[12:52] <frankban> rogpeppe: yes
[12:52] <rogpeppe> frankban: or did you have to do something manually to update the deps?
[12:53] <frankban> rogpeppe: no it seems they are handled automatically now
[12:53] <rogpeppe> frankban: great!
[12:53] <frankban> yeah
[12:53] <rogpeppe> frankban: LGTM
[12:54] <frankban> rogpeppe: great thanks
[13:03] <bac> hi rick_h_ -- i got an email from the LocalCharmGuy asking how to ingest local bundles.  afaik we've not tried that before but it should be similar.  shall i finish my current task and then help him?
[13:06] <kadams54> morning all
[13:09] <jcsackett> morning kadams54.
[13:10] <kadams54> rick_h_: you around?
[13:12] <redir> morining
[13:12] <redir> I have to go get a blood test.
[13:12] <redir> bbiab
[13:21] <rick_h_> kadams54: kinda what's up?
[13:23] <kadams54> rick_h_: Just wondering what needs working on next. I could start tackling all the feedback from design or I could move into the cards for MV. Very hesitant to start in on an IL card until hatch is in, to make sure we aren't setting up painful merge conflicts.
[13:27] <rick_h_> kadams54: yea, any MV card, especially that was part of our planning poker for this sprint is good
[13:27] <rick_h_> kadams54: there's some wire cards that might work out
[13:28] <rick_h_> kadams54: did you move all the cards you had created in there? 
[13:28] <kadams54> Yeah, going to start in on the one for choosing constraints
[13:28] <rick_h_> ah cool, thanks for moving those to the pool. I think on deck would be good as well
[13:28] <kadams54> rick_h_: I moved them into the Pool for Project 1, per hatch's suggestion yesterday.
[13:28] <rick_h_> but nice to split out back down to our planned work for the sprint
[13:28] <rick_h_> +1
[13:28] <kadams54> Also setup a metatask card for the design feedback
[13:28] <rick_h_> I'll be doing card gardening today/tomorrow
[13:28] <kadams54> I did real gardening yesterday.
[13:29] <kadams54> I suspect you'll end up with fewer mosquito bites.
[13:29] <rick_h_> awesome, had enough of those to last me a while this week :)
[13:29] <kadams54> Though I suppose that depends on where you're camping :-)
[13:29] <kadams54> I have NEVER seen mosquitos this bad
[13:30] <rick_h_> did you see my pics?
[13:30] <kadams54> No, where at?
[13:30] <bac> hey frankban, we've also got to do a quickstart release to get the OS X support...my brew recipe works but it installs 1.3.2 and then promptly fails b/c it doesn't have the new work.  i'll be glad to start on the QA, do the release, whatever.
[13:30] <bac> rick_h_: your pics were good.  liking the new camera?
[13:31] <rick_h_> bac: <3 I upgraded from the kit lense yesterday and got a tripod so looking forward to playing with it some more
[13:31] <rick_h_> kadams54: https://www.flickr.com/photos/7508761@N03/14300218662/ and https://www.flickr.com/photos/7508761@N03/14115492088/
[13:31] <kadams54> moving up from a kit lens is such a *huge* improvement
[13:31] <bac> rick_h_: which tripod? there some cool, lightweight travel ones out now
[13:32] <frankban> bac: ok, I'll make the deb packages in quickstart beta, then I'd appreciate your help for QA
[13:32] <rick_h_> bac: mefoto one, the middle one
[13:32] <rick_h_> bac: it'll do a monopod as well which I liked for travel
[13:32] <bac> rick_h_: yeah that's one of the ones i was thinking of
[13:33] <kadams54> rick_h_: Yeah, that's about right. The only thing I've ever seen that's even close is the swarm of mosquitoes above the latrine at Minnesota camp sites in the Boundary Waters.
[13:33] <bac> frankban: great!
[13:33] <rick_h_> ok, car is ready...out for a bit
[13:34] <kadams54> Have fun!
[13:34] <bac> rick_h_: i hope you got the purple
[13:38] <frankban> rogpeppe: is juju/utils usable?
[13:39] <rogpeppe> frankban: it should be
[13:39] <frankban> rogpeppe: ok thanks
[13:39] <frankban> rogpeppe: I'll tackle the FakeHomeSuite next
[13:40] <rogpeppe> frankban: i'll change charm so that it doesn't use environs/config
[13:40] <frankban> rogpeppe: sounds good
[13:41] <frankban> rogpeppe: don't we need to remove some packages from utils in core?
[13:41] <rogpeppe> frankban: ah yes, and most of utils itself
[13:42] <rogpeppe> frankban: i'll do that too
[13:42] <rogpeppe> frankban: along with making juju use utils
[13:42] <frankban> rogpeppe: yeah thanks, so that you can move your current card to done
[13:43] <frankban> rogpeppe: names removal landed in core
[13:53] <frankban> bac: quickstart packages pending
[13:53] <frankban> bac: https://code.launchpad.net/~juju-gui-charmers/+recipe/juju-quickstart-daily
[14:06] <bac> frankban: so we will qualify the .deb, then release to pypi, and then i can qualify on os x, and try to get the brew formula accepted.  sound about right?
[14:06] <frankban> bac: sounds good
[14:09] <frankban> bac: do you have a saucy vm?
[14:09]  * bac looks
[14:10] <bac> frankban: i do.  i collect them like baseball cards
[14:10] <frankban> bac: heh
[14:10] <bac> lucid, quantal, raring, saucy, trusty ... and some from lesser OSes
[14:12] <frankban> bac: so QA can be something like: verify lxc envs work, verify ec2, verify idempotence, check bundle deployments work.
[14:12] <frankban> bac: the above on trusty and saucy, and that should be enough
[14:13] <bac> frankban: how is the idempotence step done?  you mean uses existing bootstrapped env?
[14:13] <frankban> bac: quickstart must be installed from the PPA, and the machine should not have juju-core installed (so that we can also verify juju installation)
[14:14] <frankban> bac: yeah, running on an existing environment, perhaps also running on an existing environment without the GUI deployed
[14:15] <rick_h_> bac: red :P
[14:19] <rick_h_> bac: frankban a doc of qa for a release like that would be useful as things get more complex. I'm not sure how to look into automating test/qa across OS and systems like that now. 
[14:19] <bac> rick_h_: i'm starting a QA doc.
[14:20] <rick_h_> bac: rock on! 
[14:20] <bac> will do google doc for now and we can move it to the tree if we want
[14:20] <rick_h_> yea, in tree ftw so it's easy to update it as required as the code changes
[14:20] <rick_h_> and easier to hand off next ccyle
[14:20] <rick_h_> cycle
[14:21] <bac> rick_h_: even though you are not here, did you see my question regarding local bundle ingestion?
[14:21] <frankban> rick_h_, bac: +1 on a doc that will be merged into HACKING, but I'd really love if quickstart had functional tests which can be run by the juju CI against current and devel juju releases
[14:21] <rick_h_> bac: no, I didn't see it sorry
[14:22] <rick_h_> frankban: yea, definitely +1 on working with QA on that. Not sure how much OSX QA they can setup but maybe there's others around we can ask about these sorts of issues. 
[14:22] <bac> our friend has local charm ingestion working.  he'd now like to do local bundles.  i've never tried it so i'd have to get it to work then document.
[14:22] <rick_h_> what is a 'local bundle'?
[14:22] <rick_h_> ah, a bundle with local charms...not going to happen right now. 
[14:23] <bac> he wants his bundles to show up in the sidebar of juju gui
[14:23] <rick_h_> yea, that's not currently supported. 
[14:24] <bac> well...if he's running his own charmworld (he is) and has ingested local charms as he has, then ingesting bundles should just work, for some amount of config/poking.
[14:24] <bac> unless i'm missing a failure point regarding the charm store or something
[14:25] <rick_h_> well we'll have to walk him through getting those bundles ingested as he doesn't want to submit them to lp charms/bundles
[14:25] <rick_h_> and honestly we've got a really nice chunk of time sunk into this 
[14:28] <hatch> now that core has switched to GH and is getting an email per comment......holy smokes lots of emails hah!
[14:40] <redir> rogpeppe: frankban am I missing something here? http://juju-ci.vapour.ws:8080/job/github-merge-juju/23/console
[14:40] <redir> how can there be panics and FAILs and pass?
[14:42] <frankban> redir: uhm, it seems tests run a first time and failed, and then a second time successfully
[14:43] <redir> mmm yes I missed the + go test -p 2 ./...
[14:44] <frankban> redir: so the first time they failed using all the cpu cores. subsequently the lander switches to using 2 cores
[14:46] <redir> -p is cores? and not -cpu?
[14:50] <redir> jujugui standup in 10
[14:52] <frankban> redir: the number of builds that can be run in parallel
[14:53] <frankban> redir: from "go help build"
[14:53] <Makyo> hatch, ping
[14:54] <hatch> yesm
[14:55] <Makyo> Just curious if our branches are going to collide.  Is the solution you're working towards the fact that there are two div.left-breakout elements and the fillSlot code is not grabbing the right one?
[14:56] <hatch> Makyo yes ish - I'm still trying to determine the right approach
[14:57] <hatch> there are left-breakouts which aren't used
[14:57] <hatch> then there is the bws-data elements which are
[14:57] <hatch> but they are using the wrong ones
[14:57] <hatch> this stuff is really borked
[14:57] <hatch> chat after the standup?
[14:57] <Makyo> hatch, yep, that sums it up nicely.  We'll talk then.
[14:58] <Makyo> jujugui call in 2
[15:09] <bac> jcsackett: i'll be glad to look at your charmworldlib MP
[15:10] <jcsackett> bac: oh, it's coming. but it'll have to be slack.
[15:12] <bac> jcsackett: ok.
[15:16]  * rogpeppe wishes that you could see the comment that was being replied to in git code review comments.
[15:23] <hatch> rogpeppe you can
[15:23] <rogpeppe> hatch: ... by going to the web page, right?
[15:23] <hatch> yeah - unless they rebased it away
[15:23] <hatch> then it only has the few lines surrounding it
[15:24] <hatch> rogpeppe it could be worse, it could be LP which doesn't even give you a link to the repo in it's emails lol
[15:29] <redir> change is hard
[15:43] <kadams54> hatch: you available to chat?
[15:43] <hatch> just feeding the dogs, 2 mins
[15:44] <kadams54> redir: Yeah, that's why I decided to be a programmer. A nice, comfy career secluded from change. ;-)
[15:44] <redir> :)
[15:44] <redir> kadams54: at least for several minutes at a time
[15:46] <hatch> kadams54 ok - standup room should be empty
[15:48] <hatch> blah it dropped
[15:48] <hatch> one sec kadams54 
[15:49] <kadams54> maybe I'm not the one with bandwidth/lag issues ;-)
[16:18] <frankban> bac: quickstart packages are ready
[16:23] <redir> rogpeppe: is there a command to create the juju lxc container templates ?
[16:23] <rogpeppe> redir: no AFAIK. i think they should be created automatically by juju.
[16:24] <redir> rogpeppe: I mean without deploying something
[16:25] <rogpeppe> redir: what are you trying to do?
[16:25] <redir> I am trying to get consistent test  passage
[16:26] <redir> I have 2 machines with lxc containers that have nothing but juju core on them 
[16:26] <redir> one passes all tests with -p 2 flag and the other fails lxc-test 
[16:28] <redir> oh well. 
[16:28] <redir> it works on one, I'll work on that machine:)
[16:28] <hatch> kadams54 ok review done - feel free to take a look and lemme know where you want to go from here
[16:28] <kadams54> ok
[16:29] <frankban> bac: resulting package is broken, missing "python-websocket-client". I'll try to fix that.
[16:36] <frankban> bac: re-building...
[17:01] <frankban> bac: packages should be ready in ~30mins. I am not sure about "websocket-client" in saucy and precise (maybe we will need to create backports) BTW if they install correctly feel free to proceed with QAing and release. Releasing involves steps in http://bazaar.launchpad.net/~juju-gui/juju-quickstart/trunk/view/head:/HACKING.rst#L101
[17:22] <hatch> kadams54 so thoughts on my comments?
[17:22] <kadams54> hatch: oh yeah, sorry, they look good, working on implementing right now
[17:23] <hatch> ok great - you'll need to close Huw's and re-PR unfortunately
[17:23] <hatch> I wish people could do coop PR's
[17:52] <rogpeppe> i'm done for the day
[17:52] <rogpeppe> g'night all
[18:04]  * bac misses having LP super powers to bump up build farm priority...
[18:33] <hatch> bac haha, I thought you had those up until recently
[18:33] <hatch> when did they get taken away?
[19:27] <Makyo> YES
[19:27] <Makyo> Got it.
[19:27] <Makyo> Finally.
[19:28] <Makyo> There are so many tiny little parts to the viewlets system.
[19:30] <Makyo> It's pretty cool when it works right, though!
[19:39] <hatch> Makyo YAY! 
[19:39] <hatch> Makyo I would be interested in hearing ways to make it easier to follow 
[19:39] <Makyo> Probably could've used some RTFM on my part :)
[19:39] <hatch> lol
[19:40] <hatch> I'm also pretty pumped about this cache system
[19:40] <hatch> little concerned noone else will be though haha
[19:43] <Makyo> I promise I will be sufficiently pumped.
[19:44] <rick_h_> :) why would no one else be pumped hatch?
[19:44] <hatch> rick_h_ because it's magical!
[19:44]  * rick_h_ raises eyebrows at the word 'magic' in the area of coding
[19:45] <rick_h_> as long as it's not so magical that only a wizard can figure it out later after years of additional study :P
[19:47] <hatch> haha
[19:49] <hatch> https://github.com/hatched/juju-gui/blob/caching-charmbrowser/app/utils/cache.js
[19:49] <hatch> ^ rick_h_  Makyo 
[19:50] <Makyo> TWO underscores! That really is magic.
[19:50] <kadams54> That's python-agical.
[19:50] <kadams54> Dunder here we come!
[19:52] <hatch> lol - the more underscores is the importance of the dev not using it directly
[19:52] <hatch> at two you BETTER know what you're doing :P
[19:52] <hatch> three...well three....wow
[19:52] <hatch> just no
[19:55] <hatch> just FYI that code doesn't run, I had a bug in there :)
[19:56] <rick_h_> huh? one public method, no tests to follow expected working/use :P
[19:57] <hatch> I'm writing the rest of the tests now
[20:03] <Makyo> JDD - Jeff Driven Development.
[20:07] <hatch> lol
[20:07] <hatch> WWJD
[20:07] <hatch> What Would Jeff Do
Is probably not what you want to do</sub>
[20:07] <hatch> lol
[20:17] <hatch> so our linter gets confused by functions in comment blocks
[20:17] <hatch> yay....
[20:17] <hatch> lol
[20:20] <hatch> jujugui looking for a review of the new cache object https://github.com/juju/juju-gui/pull/368
[20:21] <redir> If I knew JS I would look at it and say __LGTM__, alas the joke falls flat
[20:22] <bac> hatch: i'm not sure when my wonder-powers were removed.  probably when they noticed all of my PPAs hogging the build farm. :)
[20:22] <hatch> redir lol
[20:23] <hatch> bac haha
[20:47] <hatch> so.......anyone able to do that review? jujugui.......beuler? 
[20:53] <jcsackett> hatch: sure.
[20:53] <redir> hatch: __UNQUALIFIED__ :)
[20:54] <hatch> jcsackett sweet thx
[20:54] <jcsackett> hatch: no tests?
[20:54] <hatch> umm
[20:55] <hatch> crap
[20:55] <hatch> one sec
[20:55] <jcsackett> k.
[20:55] <hatch> ok tests :)
[20:55] <hatch> man I'm fast at writing tests eh? :P
[21:00] <jcsackett> superfast. :p
[21:15] <jcsackett> hatch: this is really hard to review absent its use; two things stand out to me: why are we bothering with supplying special setters/getters? is there a use case already?
[21:15] <hatch> jcsackett interesting and search
[21:15] <hatch> well search*n for each search query
[21:15] <hatch> it's a highly generic cache layer which allows you to do with it what you want
[21:16] <jcsackett> hatch: yeah, i'm just saying it seems overly generic. but that's not a big deal.
[21:16] <hatch> correct it is
[21:16] <jcsackett> my bigger question is also a comment in the PR. that whole autogenerating setters/getters thing.
[21:17] <jcsackett> i don't see how that's desireable--i would much rather cache.set(key, data) than cache['get'+key](data) if i'm doing caching of arbitrary objects, which seems likely.
[21:18] <hatch> sure, replying
[21:18] <jcsackett> hatch: ok. wasn't sure if you preferred here or in github, given the long convo in the other channel we had earlier. :)
[21:18] <jcsackett> but i guess that was more python questions than code review.
[21:19] <hatch> oh haha yeah that was mostly pythony related
[21:19] <hatch> ok replied
[21:20] <rick_h_> replied :)
[21:20] <jcsackett> he emerges, from the deeps.
[21:21] <rick_h_> builder just got through telling me my $30k screened porch should be a $90k+ addition :/
[21:21] <rick_h_> so disclaimers and all that 
[21:21]  * jcsackett laughs
[21:21] <hatch> rick_h_ did you tell them that they can do whatever they want as long as it's $30k? lol
[21:21] <rick_h_> heh
[21:22] <jcsackett> hatch: assuming i'm swayed on the custom getter/setter thing, i think i can be convinced this is all lovely if you make the "getnameofthing" functions "_getnameofthing" and give me a get(key, data) function that grabs the goofy name and calls that.
[21:22] <jcsackett> but that's a workaround if i'm swayed on the custom bit.
[21:23] <hatch> jcsackett if we want it to be super basic we can just use a global object and call it a day
[21:23] <hatch> then if you want a custom getter/setter hang it off the object
[21:24] <hatch> this was an attempt to formalize access of the cache
[21:25] <jcsackett> i mean, i'm pro a uniform cache for everything; and i like a wrapper protecting access to an internal __storage object that deep copies.
[21:26] <rick_h_> hatch: so the requirements are a shared object with a single modellist for all cached charm models + a flexible list of defined/named modellists (interesting, search_term1_term2) or the like?
[21:26] <jcsackett> hatch: i'll be back to continue looking at this soon--have to make an emergency run to the store.
[21:27] <hatch> rick_h_ replied to your request for the use case
[21:27] <rick_h_> hatch: ty
[21:27] <rick_h_> reviewing more thoroughly now
[21:30] <hatch> jcsackett I think I might agree with your get('nameofthing') to _getnameofthing() conversion
[21:30] <hatch> thinking through it 
[21:31] <rick_h_> hatch: replied and reviewed
[21:31] <jcsackett> hatch: cool. 
[21:31] <hatch> it makes it cleaner to interact with, I see no down side to it
[21:32] <hatch> back from the store already?
[21:32] <hatch> wow
[21:32] <jcsackett> On my phone. It beeped as I was getting in my car. 
[21:33] <hatch> oh :)
[21:34] <jcsackett> Call my name and I shall appear. Assuming my IRC notifications aren't all hacked up. :p
[21:35] <rick_h_> beatlejuice beatlejuice jcsackett 
[21:35]  * rick_h_ checks if it worked 
[21:36] <jcsackett> Oh, to do that it has to be in a mirror in the dark. 
[21:36] <jcsackett> Hatch: with the change to the customs being _ and a get/set db that looks up the customs, my chief complaint is addressed. 
[21:37] <jcsackett> rick_h_ clearly has several that I think are valid. 
[21:37] <hatch> rick_h_ lol!!
[21:37] <hatch> rick_h_ replied to the long thread again :)
[21:38] <hatch> replying to the rest now
[21:43] <rick_h_> hatch: ok, replied back one more time. I've got to run at the moment sorry. 
[21:47] <Makyo> jujugui https://github.com/juju/juju-gui/pull/369 databinding for unit details + viewing charm details PR for review and QA
[22:01] <hatch> Makyo sure I'll hop on that
[22:02] <hatch> Makyo heh it's such a good idea that we didn't work on this at the same time - there was so many conflicts haha
[22:06] <Makyo> Right? :P
[22:10] <hatch> Makyo your branch also fixes the charm details panel fyi
[22:11] <Makyo> hatch, yep, that was the goal.
[22:11] <Makyo> Just poorly named.
[22:12] <hatch> dun and dun
[22:13] <Makyo> Cool, replied and prepping for another push.
[22:13] <Makyo> Should be landable, though
[22:15] <hatch> rick_h_ jcsackett  ok I'm not entirely sure where to take the caching branch - do I remove the functionality and just go for a 'dumb' key/value object store or add the generic get('key') like methods and leave the advanced functionality?
[22:15] <rick_h_> hatch: I think it's worth this discussion. I see your idea about the database, but I feel like that's the wrong place (thus the cache) since the db can be modified by env and such
[22:15] <rick_h_> hatch: the results form charmworld are static, unchanging, pure cache
[22:16] <hatch> right - but I am trying to figure out where removing the functionality makes it a better tool
[22:16] <rick_h_> not live models for modifying/etc. They get copied on deploy, and I agree we should not re-request them, but we should be copying them from the cache into the db via that code I think
[22:17] <rick_h_> I'm for a lighter cache to get started and adding complexity as required by use cases. I think that helps keeps this from being that big chunk of work as well for now. 
[22:17] <rick_h_> but that's how my head works, interative development
[22:17] <hatch> I'm not sure I agree with you on that cache to db stuff :) 
[22:17] <hatch> right, but it's already written
[22:17] <rick_h_> and I'm just not sold on the bigger picture cases so far.
[22:17] <hatch> so removing the functionality is actually more work :)
[22:17] <rick_h_> hatch: yea, but it's overhead. long term maint. overhead
[22:17] <rick_h_> every time someone tries to figure out 'how does this work' overhead
[22:18] <rick_h_> it's 10x the 'let's clear it up now' work levels
[22:18] <hatch> ok then all of this is simply WAY to good, might as well just create an instance of Y.Attribute and call it a day
[22:18] <rick_h_> lol
[22:18] <rick_h_> well I think we can chat on the db point, that seems to be the heart of this. You've got a use case I'm not following yet
[22:19] <hatch> but really, then it has getters and setters, and it's an object store
[22:19] <hatch> the app.js can just go this.cache = new Y.Attribute() and it's done
[22:19] <hatch> lol
[22:19] <rick_h_> well I don't even know getter/setters are required. What do they get us? We're not waching/eventing on this
[22:20] <rick_h_> hatch: heh, except we want to pass the object instance around down to views/etc. and I think it might belond on state tbh
[22:20] <hatch> so then we don't need a new class at all
[22:20] <rick_h_> kind of like that one bit of state that's out of band already, /me tries to recall it
[22:20] <hatch> just create an object
[22:20] <rick_h_> hatch: maybe not, the main goal was to get it out of browser.js
[22:20] <rick_h_> so that it's not so smart and center of the world with stuff so it can be shared better
[22:21] <rick_h_> what use case does an object on state fall apart at?
[22:21]  * rick_h_ is trying to think this through 
[22:21] <hatch> I wouldn't put it in state because I think it's bringing stuff along with it that is unnecessary, I'd definitely keep it separate
[22:21] <rick_h_> ok 
[22:22] <hatch> so now the question is....why won't a dumb object work
[22:22] <hatch> it's not a very 'clean' approach 
[22:22] <rick_h_> so for the use case of charm/bundle models it seems sensible. a dumb object of model lists
[22:23] <hatch> impossible to test
[22:23] <hatch> there isn't anything 'to' test
[22:23] <rick_h_> ok, so a simple get/set api on top of a dumb object makes it a cleaner api?
[22:23] <hatch> it does, because then you can see 'ok here we have a cache' 
[22:24] <rick_h_> hatch: well, that's kind of the nice thing. You test things that are cache-enabled. And make sure they read from the cache data without making a new request, or that they update the cache data 
[22:24] <hatch> right but there is no 'cache' it's just an object
[22:24] <rick_h_> ok, so I can +1 a get/set but without the magic method per cache key
[22:24] <hatch> there is no implicit.... I am a cache, hear me roar
[22:24] <rick_h_> hatch: right, but that's what makes it easy to test :) 
[22:24] <hatch> (i'm just talking it out btw)
[22:25] <hatch> get and set without any bonus kind of feels like a waste 
[22:25] <rick_h_> so maybe calling it a cache is a bad word? Is there a better way of calling it "hey view, here's some existing useful data to help speed things up for you"
[22:25] <hatch> (which is a cache) :P
[22:26] <rick_h_> well you're saying an object is no cache, that it's ugly without an api, so I'm trying to figure out how to do it in a light weight way that provides and api and 'feels' cachy (aside from the name of the argument being cache or modelCache)
[22:26] <hatch> an object will work just fine as long as nobody touches it
[22:26] <jcsackett> i mean, caches frequently are dumb, so a protected storage thingy with get and set and ensurance that we're deep copying doesn't sound like a waste to me.
[22:26] <hatch> when you wrap it inside an instance it's much harder to touch
[22:27] <hatch> you have to be explicit about accessing it
[22:27] <rick_h_> hatch: ok, so then the thing to figure out is how to update teh cache
[22:27] <rick_h_> in the old system the Views fired a cacheUpdate event with the new data to cache
[22:27] <hatch> I think the cache should be passed in
[22:27] <hatch> but then everyone can access the object
[22:27] <hatch> without going through a setter/getter
[22:28] <hatch> they could accidentally empty it too
[22:28] <hatch> so that's the issue with a basic object
[22:28] <hatch> no protection at all
[22:28] <rick_h_> well, I think we can unblock ourselves with a simple object for now and move forward towards release. And keep in mind the tools available if a more complex use case presents itself. However, we don't currently have those to drive the decisions on what to implemnt
[22:28] <rick_h_> and if it's simpler now, it's less to update/replace down the road when a real use case does jump out and hit us
[22:29] <hatch> ok I'll scrap this branch
[22:29] <hatch> the cache will live in the browser though
[22:29] <hatch> I don't think this cache needs to be passed from the app
[22:30] <hatch> at least for now
[22:30] <rick_h_> why in the browser? How does that work with the inspector and other use cases? 
[22:30] <hatch> like browser.js 
[22:30] <rick_h_> that's been a limitation of the last work. If the inspector loads up a charm details it can add it to the cache
[22:30] <hatch> it should be adding that to the db
[22:30] <hatch> not to the cache
[22:31] <hatch> it's a fully populated model then
[22:31] <huwshimi> Morning
[22:31] <hatch> that's where grabbing keys for the search/interesting makes more sense
[22:31] <rick_h_> ok, but before it's added to the db is can get an initial default values/etc from the cache
[22:31] <hatch> morning huwshimi 
[22:31] <huwshimi> hatch: Hey
[22:32] <hatch> lol I really don't agree
[22:32] <rick_h_> but it needs access to that, I guess the inspector is in the browser at this point but it feels like it's not the right place to keep it out
[22:32] <hatch> ok I think I got something
[22:32] <hatch> put the cache in the db
[22:32] <rick_h_> hatch: call?
[22:32] <hatch> everything has access to the db already
[22:32] <hatch> sure
[22:32] <hatch> I think it's aus call time too
[22:32] <rick_h_> but the browser never ever touches the db, now all that code needs a db instance passed down which allows it to touch a bunch of stuff it never should need to
[22:33] <hatch> im in the aus room
[22:33] <rick_h_> huh? the charmresults has db access currently?
[22:33] <hatch> no browser.js does
[23:03] <hatch> kadams54 did you end up re-proposing huwshimi  branch?
[23:06] <hatch> huwshimi so kadams54 took over your branch (the one he closed) to apply the changes from my comments. I don't see anything in his fork about that so maybe you want to take those comments and run with them today?
[23:06] <hatch> huwshimi this is the PR in question https://github.com/juju/juju-gui/pull/366
[23:06] <huwshimi> hatch: OK, was there a reason he needed to pick it up (was it blocking something)?
[23:07] <hatch> huwshimi he was going to take it, fix the comments, then add the functionality to the container as well
[23:07] <huwshimi> Ah I see
[23:07] <hatch> so yeah...if you're blocked on that not landing then maybe you can continue on your own branch
[23:07] <hatch> sucks to be duplicating work but I'm not sure where it's at
[23:12] <huwshimi> hatch: Do you know if he started working on the container constraints?
[23:12] <hatch> huwshimi no idea, sorry
[23:30] <hatch> huwshimi maybe you can ping kadams54  periodically over the next few hours :P
[23:30] <huwshimi> :)
[23:30] <kadams54> actually i'm here now
[23:31] <hatch> it worked!
[23:31] <kadams54> for about 5 seconds :-)
[23:31] <hatch> :P
[23:31] <kadams54> location change
[23:31] <hatch> kadams54 where are you with huwshimi's branch?
[23:31] <kadams54> and then we can talk more
[23:31] <hatch> oh ok
[23:47] <kadams54> hatch, huwshimi: back. Here's the update: I'm fixing tests that broke in refactoring. My plan was to push once those tests were fixed.
[23:48] <kadams54> Unfortunately I won't be able to resume work on them for another 45 minutes. So hopefully it's not blocking?
[23:48] <huwshimi> kadams54: That's fine, not blocking me!
[23:49] <kadams54> huwshimi: great.
[23:49] <kadams54> huwshimi: your branch implemented about half of the card I picked up, which is how I ended up on it in the first place :-)
[23:50] <huwshimi> kadams54: Ah yeah, are planning on re-using that view and using it in the containers column?
[23:50] <kadams54> Yes
[23:51] <huwshimi> kadams54: Great, I assume you'll do the container type card at the same time?
[23:52] <kadams54> huwshimi: "wire deployed unit token UI for choosing container type" - that card?
[23:52] <kadams54> I was planning on tackling that next :-)
[23:52] <huwshimi> kadams54: Yeah
[23:53] <huwshimi> kadams54: Well, it's the step before the constraints are show...
[23:53] <huwshimi> *shown
[23:53] <huwshimi> kadams54: Might make sense to do them at the same time, or do the container type card first (if it can be broken out)
[23:55] <kadams54> I was going to do it after the constraints work because that was already in progress on your branch.
[23:55] <kadams54> So the plan was to wrap up your branch, get it landed, and then start on container types.
[23:55] <kadams54> That said, we'll see how things go once I get the kids settled in bed ;-)
[23:57] <huwshimi> kadams54: OK, well, whichever way make sense, I guess either way you need to do a bit of refactoring.