=== _mup__ is now known as _mup_ [08:19] morning rogpeppe: how are you doing? [08:19] frankban: hiya [08:19] frankban: not too bad [08:19] frankban: just reading the leader election thread [08:20] rogpeppe: are you migrating filetesting? [08:20] frankban: yes, i have a LGTM and can merge it [08:20] frankban: i'll do that now [08:21] rogpeppe: ok I moved the card in coding and assigned to you, please put it in daily accomp. when done. [08:22] rogpeppe: do you have notes on the migration steps? [08:22] frankban: hmm, i thought i had a card [08:22] frankban: i haven't made the notes yet, but i've got all the shell history :-) [08:23] 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] frankban: yup [08:24] frankban: zip/zip_test.go [08:24] frankban: that seems to be the only one [08:26] rogpeppe: cool, I guess I am going to migrate schema [08:27] frankban: that should probably go inside utils, i think [08:27] frankban: i don't really think it justifies its own repo [08:28] frankban: then again, i don't mind much [08:28] frankban: if you think otherwise [08:29] 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] level project, rather than buried in an amorphous utils repo." [08:30] frankban: ok, fair enough [08:34] rogpeppe: ugm. it seems I don't have permission to create a repo in juju :-/ [08:42] 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] frankban: 1) is now done [08:45] frankban: for 2) you won't need the more complex commands that i used [08:46] frankban: because you're not merging into an existing repo [08:46] frankban: and you don't need to rewrite pathjs [09:01] rogpeppe: 1) thanks [09:01] rogpeppe: github says https://github.com/juju/schema is empty and I cannot fork it [09:02] 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] frankban: you'll need to push directly to it initially [09:05] rogpeppe: ah, so initial push with an empty repo or with the actual repo generated by "git filter-branch"? [09:05] rogpeppe: LGTM [09:06] frankban: the latter [09:18] rogpeppe: ERROR: Permission to juju/schema.git denied to frankban. [09:40] rogpeppe: any idea? [09:41] frankban: sorry, missed your earlier comment [09:41] frankban: looking [09:41] thanks [09:42] frankban: what command did you use? [09:42] git remote add upstream git@github.com:juju/schema.git [09:43] git push upstream master [09:43] rogpeppe: ^^ [09:44] rogpeppe: in https://github.com/juju/schema I only see: [09:44] This repository is empty. [09:44] Care to check out the GitHub Channel on YouTube while you wait? [09:44] frankban: does it behave differently if you do: git remote remove upstream; git remote add upstream https://github.com/juju/schema.git ? [09:45] 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] frankban: hmm, weird [09:46] frankban: i'll try pushing a branch to it [09:48] rogpeppe: https://github.com/juju/schema/settings/collaboration ? [09:49] rogpeppe: now I see your branch but I cannot fork [09:49] frankban: ah, i hadn't seen the collaboration settings [09:49] frankban: you should be able to push now [09:50] rogpeppe: done, could you please remove the testing branch? [09:50] frankban: yeah, just trying to work out how to do that [09:52] frankban: hmm, it's not obvious... [09:53] rogpeppe: I did it [09:53] rogpeppe: git push upstream :testing [09:53] frankban: ah yes, i'd forgotten that idiom [09:57] rogpeppe: https://github.com/juju/schema/pull/1 [09:58] frankban: LGTM [09:59] thanks [10:28] rogpeppe: could you please create a juju/names repo and give me write permission? [10:28] frankban: yup [10:31] thanks [10:34] frankban: done [10:37] rogpeppe: thanks [10:37] rogpeppe: could you please review https://github.com/juju/juju/pull/25 ? [10:38] frankban: LGTM [10:38] rogpeppe: do you know if in the new git world dependencies.tsv changes are handled by the bot? [10:39] frankban: i don't - best ask on #juju-dev [10:39] rogpeppe: yeah, already done [10:39] rogpeppe: thanks for the review, I guess I'll try to $$merge$$ it [10:41] frankban: good plan [10:42] rogpeppe: and now names [10:42] rogpeppe: FWIW, these are the notes I've taken while migrating schema: http://pastebin.ubuntu.com/7593938/ [10:45] 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] frankban: what's the difference between an https remote and a git@github remote? [10:46] rogpeppe: https vs ssh [10:47] frankban: is one preferred over the other? [10:47] rogpeppe: not sure, I prefer ssh because https asks me credentials [10:48] rogpeppe: ssh uses the ssh key [10:49] frankban: hmm, i guess i can tell github about my ssh key [10:50] rogpeppe: https://help.github.com/articles/generating-ssh-keys [11:27] jeeze my network is stupidly slow today [11:47] ssh is faster and uses the key vs password. [12:08] rogpeppe: trivial https://github.com/juju/names/pull/1 [12:09] frankban: LGTM [12:10] rogpeppe: thanks [12:50] rogpeppe: could you please take a look at https://github.com/juju/juju/pull/27 ? (mechanical) [12:52] frankban: did that previous branch merge ok? [12:52] rogpeppe: yes [12:52] frankban: or did you have to do something manually to update the deps? [12:53] rogpeppe: no it seems they are handled automatically now [12:53] frankban: great! [12:53] yeah [12:53] frankban: LGTM [12:54] rogpeppe: great thanks [13:03] 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] morning all [13:09] morning kadams54. [13:10] rick_h_: you around? [13:12] morining [13:12] I have to go get a blood test. [13:12] bbiab [13:21] kadams54: kinda what's up? [13:23] 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] kadams54: yea, any MV card, especially that was part of our planning poker for this sprint is good [13:27] kadams54: there's some wire cards that might work out [13:28] kadams54: did you move all the cards you had created in there? [13:28] Yeah, going to start in on the one for choosing constraints [13:28] ah cool, thanks for moving those to the pool. I think on deck would be good as well [13:28] rick_h_: I moved them into the Pool for Project 1, per hatch's suggestion yesterday. [13:28] but nice to split out back down to our planned work for the sprint [13:28] +1 [13:28] Also setup a metatask card for the design feedback [13:28] I'll be doing card gardening today/tomorrow [13:28] I did real gardening yesterday. [13:29] I suspect you'll end up with fewer mosquito bites. [13:29] awesome, had enough of those to last me a while this week :) [13:29] Though I suppose that depends on where you're camping :-) [13:29] I have NEVER seen mosquitos this bad [13:30] did you see my pics? [13:30] No, where at? [13:30] 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] rick_h_: your pics were good. liking the new camera? [13:31] bac: <3 I upgraded from the kit lense yesterday and got a tripod so looking forward to playing with it some more [13:31] kadams54: https://www.flickr.com/photos/7508761@N03/14300218662/ and https://www.flickr.com/photos/7508761@N03/14115492088/ [13:31] moving up from a kit lens is such a *huge* improvement [13:31] rick_h_: which tripod? there some cool, lightweight travel ones out now [13:32] bac: ok, I'll make the deb packages in quickstart beta, then I'd appreciate your help for QA [13:32] bac: mefoto one, the middle one [13:32] bac: it'll do a monopod as well which I liked for travel [13:32] rick_h_: yeah that's one of the ones i was thinking of [13:33] 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] frankban: great! [13:33] ok, car is ready...out for a bit [13:34] Have fun! [13:34] rick_h_: i hope you got the purple [13:38] rogpeppe: is juju/utils usable? [13:39] frankban: it should be [13:39] rogpeppe: ok thanks [13:39] rogpeppe: I'll tackle the FakeHomeSuite next [13:40] frankban: i'll change charm so that it doesn't use environs/config [13:40] rogpeppe: sounds good [13:41] rogpeppe: don't we need to remove some packages from utils in core? [13:41] frankban: ah yes, and most of utils itself [13:42] frankban: i'll do that too [13:42] frankban: along with making juju use utils [13:42] rogpeppe: yeah thanks, so that you can move your current card to done [13:43] rogpeppe: names removal landed in core [13:53] bac: quickstart packages pending [13:53] bac: https://code.launchpad.net/~juju-gui-charmers/+recipe/juju-quickstart-daily [14:06] 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] bac: sounds good [14:09] bac: do you have a saucy vm? [14:09] * bac looks [14:10] frankban: i do. i collect them like baseball cards [14:10] bac: heh [14:10] lucid, quantal, raring, saucy, trusty ... and some from lesser OSes [14:12] bac: so QA can be something like: verify lxc envs work, verify ec2, verify idempotence, check bundle deployments work. [14:12] bac: the above on trusty and saucy, and that should be enough [14:13] frankban: how is the idempotence step done? you mean uses existing bootstrapped env? [14:13] 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] bac: yeah, running on an existing environment, perhaps also running on an existing environment without the GUI deployed [14:15] bac: red :P [14:19] 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] rick_h_: i'm starting a QA doc. [14:20] bac: rock on! [14:20] will do google doc for now and we can move it to the tree if we want [14:20] yea, in tree ftw so it's easy to update it as required as the code changes [14:20] and easier to hand off next ccyle [14:20] cycle [14:21] rick_h_: even though you are not here, did you see my question regarding local bundle ingestion? [14:21] 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] bac: no, I didn't see it sorry [14:22] 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] 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] what is a 'local bundle'? [14:22] ah, a bundle with local charms...not going to happen right now. [14:23] he wants his bundles to show up in the sidebar of juju gui [14:23] yea, that's not currently supported. [14:24] 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] unless i'm missing a failure point regarding the charm store or something [14:25] 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] and honestly we've got a really nice chunk of time sunk into this [14:28] now that core has switched to GH and is getting an email per comment......holy smokes lots of emails hah! [14:40] rogpeppe: frankban am I missing something here? http://juju-ci.vapour.ws:8080/job/github-merge-juju/23/console [14:40] how can there be panics and FAILs and pass? [14:42] redir: uhm, it seems tests run a first time and failed, and then a second time successfully [14:43] mmm yes I missed the + go test -p 2 ./... [14:44] redir: so the first time they failed using all the cpu cores. subsequently the lander switches to using 2 cores [14:46] -p is cores? and not -cpu? [14:50] jujugui standup in 10 [14:52] redir: the number of builds that can be run in parallel [14:53] redir: from "go help build" [14:53] hatch, ping [14:54] yesm [14:55] 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] Makyo yes ish - I'm still trying to determine the right approach [14:57] there are left-breakouts which aren't used [14:57] then there is the bws-data elements which are [14:57] but they are using the wrong ones [14:57] this stuff is really borked [14:57] chat after the standup? [14:57] hatch, yep, that sums it up nicely. We'll talk then. [14:58] jujugui call in 2 [15:09] jcsackett: i'll be glad to look at your charmworldlib MP [15:10] bac: oh, it's coming. but it'll have to be slack. [15:12] jcsackett: ok. [15:16] * rogpeppe wishes that you could see the comment that was being replied to in git code review comments. [15:23] rogpeppe you can [15:23] hatch: ... by going to the web page, right? [15:23] yeah - unless they rebased it away [15:23] then it only has the few lines surrounding it [15:24] 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] change is hard [15:43] hatch: you available to chat? [15:43] just feeding the dogs, 2 mins [15:44] redir: Yeah, that's why I decided to be a programmer. A nice, comfy career secluded from change. ;-) [15:44] :) [15:44] kadams54: at least for several minutes at a time [15:46] kadams54 ok - standup room should be empty [15:48] blah it dropped [15:48] one sec kadams54 [15:49] maybe I'm not the one with bandwidth/lag issues ;-) [16:18] bac: quickstart packages are ready [16:23] rogpeppe: is there a command to create the juju lxc container templates ? [16:23] redir: no AFAIK. i think they should be created automatically by juju. [16:24] rogpeppe: I mean without deploying something [16:25] redir: what are you trying to do? [16:25] I am trying to get consistent test passage [16:26] I have 2 machines with lxc containers that have nothing but juju core on them [16:26] one passes all tests with -p 2 flag and the other fails lxc-test [16:28] oh well. [16:28] it works on one, I'll work on that machine:) [16:28] kadams54 ok review done - feel free to take a look and lemme know where you want to go from here [16:28] ok [16:29] bac: resulting package is broken, missing "python-websocket-client". I'll try to fix that. [16:36] bac: re-building... [17:01] 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] kadams54 so thoughts on my comments? [17:22] hatch: oh yeah, sorry, they look good, working on implementing right now [17:23] ok great - you'll need to close Huw's and re-PR unfortunately [17:23] I wish people could do coop PR's [17:52] i'm done for the day [17:52] g'night all [18:04] * bac misses having LP super powers to bump up build farm priority... [18:33] bac haha, I thought you had those up until recently [18:33] when did they get taken away? [19:27] YES [19:27] Got it. [19:27] Finally. [19:28] There are so many tiny little parts to the viewlets system. [19:30] It's pretty cool when it works right, though! [19:39] Makyo YAY! [19:39] Makyo I would be interested in hearing ways to make it easier to follow [19:39] Probably could've used some RTFM on my part :) [19:39] lol [19:40] I'm also pretty pumped about this cache system [19:40] little concerned noone else will be though haha [19:43] I promise I will be sufficiently pumped. [19:44] :) why would no one else be pumped hatch? [19:44] rick_h_ because it's magical! [19:44] * rick_h_ raises eyebrows at the word 'magic' in the area of coding [19:45] 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] haha [19:49] https://github.com/hatched/juju-gui/blob/caching-charmbrowser/app/utils/cache.js [19:49] ^ rick_h_ Makyo [19:50] TWO underscores! That really is magic. [19:50] That's python-agical. [19:50] Dunder here we come! [19:52] lol - the more underscores is the importance of the dev not using it directly [19:52] at two you BETTER know what you're doing :P [19:52] three...well three....wow [19:52] just no [19:55] just FYI that code doesn't run, I had a bug in there :) [19:56] huh? one public method, no tests to follow expected working/use :P [19:57] I'm writing the rest of the tests now [20:03] JDD - Jeff Driven Development. [20:07] lol [20:07] WWJD [20:07] What Would Jeff Do [20:07] _{Is probably not what you want to do} [20:07] lol [20:17] so our linter gets confused by functions in comment blocks [20:17] yay.... [20:17] lol [20:20] jujugui looking for a review of the new cache object https://github.com/juju/juju-gui/pull/368 [20:21] If I knew JS I would look at it and say __LGTM__, alas the joke falls flat [20:22] 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] redir lol [20:23] bac haha [20:47] so.......anyone able to do that review? jujugui.......beuler? [20:53] hatch: sure. [20:53] hatch: __UNQUALIFIED__ :) [20:54] jcsackett sweet thx [20:54] hatch: no tests? [20:54] umm [20:55] crap [20:55] one sec [20:55] k. [20:55] ok tests :) [20:55] man I'm fast at writing tests eh? :P [21:00] superfast. :p [21:15] 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] jcsackett interesting and search [21:15] well search*n for each search query [21:15] it's a highly generic cache layer which allows you to do with it what you want [21:16] hatch: yeah, i'm just saying it seems overly generic. but that's not a big deal. [21:16] correct it is [21:16] my bigger question is also a comment in the PR. that whole autogenerating setters/getters thing. [21:17] 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] sure, replying [21:18] 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] but i guess that was more python questions than code review. [21:19] oh haha yeah that was mostly pythony related [21:19] ok replied [21:20] replied :) [21:20] he emerges, from the deeps. [21:21] builder just got through telling me my $30k screened porch should be a $90k+ addition :/ [21:21] so disclaimers and all that [21:21] * jcsackett laughs [21:21] rick_h_ did you tell them that they can do whatever they want as long as it's $30k? lol [21:21] heh [21:22] 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] but that's a workaround if i'm swayed on the custom bit. [21:23] jcsackett if we want it to be super basic we can just use a global object and call it a day [21:23] then if you want a custom getter/setter hang it off the object [21:24] this was an attempt to formalize access of the cache [21:25] 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] 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] hatch: i'll be back to continue looking at this soon--have to make an emergency run to the store. [21:27] rick_h_ replied to your request for the use case [21:27] hatch: ty [21:27] reviewing more thoroughly now [21:30] jcsackett I think I might agree with your get('nameofthing') to _getnameofthing() conversion [21:30] thinking through it [21:31] hatch: replied and reviewed [21:31] hatch: cool. [21:31] it makes it cleaner to interact with, I see no down side to it [21:32] back from the store already? [21:32] wow [21:32] On my phone. It beeped as I was getting in my car. [21:33] oh :) [21:34] Call my name and I shall appear. Assuming my IRC notifications aren't all hacked up. :p [21:35] beatlejuice beatlejuice jcsackett [21:35] * rick_h_ checks if it worked [21:36] Oh, to do that it has to be in a mirror in the dark. [21:36] 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] rick_h_ clearly has several that I think are valid. [21:37] rick_h_ lol!! [21:37] rick_h_ replied to the long thread again :) [21:38] replying to the rest now [21:43] hatch: ok, replied back one more time. I've got to run at the moment sorry. [21:47] jujugui https://github.com/juju/juju-gui/pull/369 databinding for unit details + viewing charm details PR for review and QA [22:01] Makyo sure I'll hop on that [22:02] 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] Right? :P [22:10] Makyo your branch also fixes the charm details panel fyi [22:11] hatch, yep, that was the goal. [22:11] Just poorly named. [22:12] dun and dun [22:13] Cool, replied and prepping for another push. [22:13] Should be landable, though [22:15] 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] 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] hatch: the results form charmworld are static, unchanging, pure cache [22:16] right - but I am trying to figure out where removing the functionality makes it a better tool [22:16] 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] 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] but that's how my head works, interative development [22:17] I'm not sure I agree with you on that cache to db stuff :) [22:17] right, but it's already written [22:17] and I'm just not sold on the bigger picture cases so far. [22:17] so removing the functionality is actually more work :) [22:17] hatch: yea, but it's overhead. long term maint. overhead [22:17] every time someone tries to figure out 'how does this work' overhead [22:18] it's 10x the 'let's clear it up now' work levels [22:18] 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] lol [22:18] 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] but really, then it has getters and setters, and it's an object store [22:19] the app.js can just go this.cache = new Y.Attribute() and it's done [22:19] lol [22:19] well I don't even know getter/setters are required. What do they get us? We're not waching/eventing on this [22:20] 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] so then we don't need a new class at all [22:20] kind of like that one bit of state that's out of band already, /me tries to recall it [22:20] just create an object [22:20] hatch: maybe not, the main goal was to get it out of browser.js [22:20] so that it's not so smart and center of the world with stuff so it can be shared better [22:21] what use case does an object on state fall apart at? [22:21] * rick_h_ is trying to think this through [22:21] 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] ok [22:22] so now the question is....why won't a dumb object work [22:22] it's not a very 'clean' approach [22:22] so for the use case of charm/bundle models it seems sensible. a dumb object of model lists [22:23] impossible to test [22:23] there isn't anything 'to' test [22:23] ok, so a simple get/set api on top of a dumb object makes it a cleaner api? [22:23] it does, because then you can see 'ok here we have a cache' [22:24] 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]