[00:00] hi rick_h_. otp, but what's up? [00:01] fyi, I talked to arosales about quickstart and it's not going anywhere for this cycle [00:01] six month cycle? [00:01] bac: we'll work on introducing it to the guys on eco some, arosales would like to setup a meet sometime to run them through the basics [00:01] bac: but we won't hand anything off until Oct [00:01] bac: rgr [00:01] rt [00:01] 14.10 cycle kind of thing [00:02] so we want to get the idea on the table, but not actually move for now. So just a heads up that we can continue our current plans as they are [00:24] rick_h_, bac, I am going to talk to a few guys on my team to check interest in transitioning. I'll get back to you guys once I have done so, and perhaps we an do some knowledge transfer [00:26] bac, rick_h_ apologies we won't be able to dedicate time to dev on it this cycle. Perhaps some items will move faster than we think (I guess that happens sometimes right :-) [06:14] huwshimi: you around? [06:15] kadams54: Hey! [06:16] I ran into a potential bug earlier today and Jeff said you might be working on a fix… [06:17] Here's how to reproduce on comingsoon.jujucharms.com: [06:18] 1) Deploy the Mediawiki bundle, then drag-n-drop a second mysql charm. It also gets the name "mysql" which means it will fail when you try to deploy it. [06:18] But if you try to rename it, there isn't a button anymore to save the changes to the ghosted charm's config. [06:19] If there's a fix in progress for that, great. If not, I'll create a bug report. [06:19] kadams54: Oh yeah, I'm not working on a fix, but we discussed in a call this morning and Rick said that the inspector needs be updated to auto-save those config changes. [06:20] kadams54: There are some broader changes on the ghost inspector, maybe it'll be done as part of that. [06:20] Ah, excellent. [06:20] kadams54: I guess a bug report at this stage would be prudent. [06:20] Yeah, will do. [06:20] Don't want to lose visibility [06:21] kadams54: Just so we don't release mv without fixing it. [06:21] yeah [06:21] Thanks [06:21] kadams54: But yes, that is my fault :) [06:22] Meh, we all knew the button in the inspector was going away. [06:26] Alright, with that, I'm off to bed :-) [06:27] Have a good rest of the day! [07:17] mornin' all [07:21] Morning [08:21] morning rogpeppe: I'll start migrating filetesting to github.com/juju/testing/filetesting [08:21] frankban: cool. [08:21] frankban: i could work concurrently on other related stuff if you feel it would speed things up [08:25] rogpeppe: sure, I guess the next thing is handling juju/osenv, e.g. decoupling utils from juju/osenv [08:26] rogpeppe: the goal is to have a github.com/juju/utils project [08:26] frankban: a lot of osenv looks quite core-specific [08:27] frankban: the only thing that isn't is the proxy stuff, i think [08:29] rogpeppe: ok, so I guess it makes sense to have utils/zip and utils/set outside juju-core [08:31] rogpeppe: charm depends on both, and also on utils itself, but AFAICT only for stuff like ReadSHA256, ReadFileSHA256 and ReplaceFile. Perhaps a good path is to move juju-core unrelated stuff to github and change charm to only depend on the github project [08:31] frankban: i think there are (at least) two splits that should happen [08:32] frankban: utils/osenv should split out the juju home stuff [08:32] frankban: (or perhaps split out the proxy stuff) [08:33] frankban: and utils itself should be split into coherent packages containing related functionality, rather than being a grab-bag of stuff [08:34] frankban: i'll try and come up with a coherent scheme for that [08:35] rogpeppe: great, thanks [08:55] rogpeppe: uhm, it seems juju is not using the latest revision of github.com/juju/testing. this is the missing change: https://github.com/juju/testing/commit/83bf0cdc931b7556c93e8d496978b3f010d50ab5 . Do you think it's safe to include that? [08:56] frankban: yeah, i do [08:56] cool [08:57] frankban: i'd propose a CL with a single change to the dependencies.tsv file to update that [08:57] rogpeppe: yeah, that's what I was thinking [08:58] rogpeppe: ah, feel free to create a kanban card in Project A for what you are working on [09:36] rogpeppe: I need a review for https://codereview.appspot.com/100740044 (trivial) [09:37] frankban: LGTM [09:37] thanks [09:54] rogpeppe: have you ever seen this? fatal: reference is not a tree: a99ca0f5b8d5b7ad608fd7214e8ba3d7b6279f63. [09:54] frankban: i think i might have - was that printed by git? [09:55] I think so, godeps in tarmac reports this error from git I guess [09:55] rogpeppe: do we need to pull from github/juju/testing in tarmac? [09:56] frankban: i *thought* it pulled automatically [09:58] frankban: am asking in juju-core - someone might know [09:58] thanks [10:06] rogpeppe: unrelated: in the process of updating testing, I'd like to go get my fork in a separate GOPATH, and run the tests/verify dependencies. Is it possible to go get a github named branch? I guess no. So maybe this can be done with 1) export GOPATH=... 2) go get github.com/frankban/testing 3) checkout the branch with the updates and 4) go get -u ./... [10:06] correct> [10:06] ? [10:46] rogpeppe: at this point I'd be inclined not to start the filetesting migration, and tackle that on Monday. I can start working on breaking utils/set, what do you think? [10:47] frankban: seems ok to me. i'm currently factoring out apt from utils. [10:48] rogpeppe: so juju-core/utils/set -> juju-core/set, how does it sound? [10:48] frankban: that seems a bit odd to me [10:48] frankban: why move it? [10:49] frankban: i thought it should probably go to github.com/utils/set [10:49] frankban: oops [10:49] frankban: i mean github.com/juju/utils/set [10:51] rogpeppe: IC, right, so 1) we move the juju-core related stuff from utils to their own packages and 2) we migrate utils to github, correct? [10:51] frankban: yeah [10:51] frankban: i don't think we have to migrate all of utils to github - i think juju-core can probably still keep its own utils dir [10:53] rogpeppe: yeah that's reasonable [11:06] rogpeppe: so, after you split apt, the remaining osenv stuff in utils is file (osenv.Home, osenv.SetHome). Those functions in osenv/vars_* seem to be generic. We can either 1) move vars_* into utils (or perhaps utils/os), or 2) break the file stuff in into a separate pkg [11:06] pwd [11:10] frankban: i think all the proxy-related stuff should move out of osenv and into utils/proxy (httpproxy?) [11:10] frankban: i think osenv.Home() should move out of osenv too [11:10] frankban: and SetHome too [11:10] frankban: which would leave osenv with just juju-related stuff [11:12] rogpeppe: yeah, ok so I'll start with osenv home stuff. What do you thing about osenv.(Set)Home --> utils/os.(Set)Home? [11:13] frankban: tbh they're trivial enough that perhaps they could go into utils itself [11:13] frankban: utils already depends on os and has os-specific files [11:15] rogpeppe: ok so just osenv.(Set)Home --> utils.(Set)Home, correct? and later osenv.Proxy* -> utils/proxy.Proxy*, correct? [11:15] frankban: sgtm [11:16] rogpeppe: cool, thanks, I'll start with the first one [11:20] morning all [11:27] morning rogpeppe can you add a card to the board for the apt refactoring you mentioned please? We've got a card in the ready to code lane for "migrate juju utils package" but sounds like we're doing parts of that so maybe just a new card? [11:28] rick_h_: will do. that occurred to me earlier but didn't make it as far as motor action :-) [11:28] rogpeppe: hah, TGIF [11:30] redir: when you get settled this morning can we catch up on where we're at for the demo prep stuff? [11:54] rogpeppe: moving Home to "utils" causes an import loop, it seems I am blocked on your apt change, unless I use a submodule e.g. utils/env [11:55] frankban: i've proposed my apt change: https://codereview.appspot.com/100730044 [11:58] rogpeppe: cool I'll take a look after lunch [11:58] frankban: it's just been LGTM'd [11:58] rogpeppe: even better [11:58] frankban: i'm about to approve it - it should hopefully have landed by the time you've finished lunch [11:59] rogpeppe: sounds good [11:59] * frankban lunches [12:20] frankban: it's now merged [12:32] thanks for the review frankban. good suggestions. [12:34] frankban: as an aside, i notice the quickstart tests have a failure if JUJU_HOME is set. [12:41] bac: yw [12:41] bac: confirmed, the expected error in test_no_admin_secret_found should use settings.JUJU_HOME [12:42] frankban: ah, that's a simple way to fix it. you want me to roll it into my branch? [12:42] bac: yes please [12:42] thanks [12:42] gladly [12:43] really freaked me out last night when lbox failed b/c i'd inadvertantly run it in another terminal... [12:54] * rogpeppe goes for lunch [13:01] rick_h_: sure [13:01] settled [13:01] redir: cool, how goes? It looked like you had mongodb conflict between the state server and mongodb for charmworld yesterday? [13:01] and rick_h_ I don't know that it is a conflict [13:02] ok, but we suspect? [13:02] I can't start it with service but can by calling the command from the service config as the correct user [13:02] so I don't know what is preventing it. [13:02] redir: I was going to suggest can we test it out on two machine then? put the gui on the bootstrap node, but all of charmworld on a second [13:02] redir: to clarify if the dual mongos is the issue? [13:03] so quickstart and then deploy CW to a separate instance? [13:03] this makes using AMIs more difficult [13:03] but not impossible [13:03] and I would like to know why it isn't starting [13:04] bac did you have a chance to look? [13:04] redir: i did not [13:04] redir: well, let's get the process and the ami thing might not work out [13:05] frankban: i did a 'make clean' in quickstart and now unrelated websocket tests fail, even in trunk. have you seen that before? [13:05] redir: i'm about to wrap up this task and then can help [13:06] bac: no, trying [13:06] frankban: http://paste.ubuntu.com/7505527/ [13:06] bac: confirmed and weird [13:07] frankban: so some package shifted beneath us? [13:08] bac: we specify the version for each requirement, looking at the test [13:10] bac: but not for the websocket client, which is a dependency of python-jujuclient [13:13] frankban: websocket's connect is never called in that test. self.sock remains None. [13:14] bac: jujuclient 0.17.5 has install_requires=["websocket-client"], without the version :-/ [13:15] bac: and a new version of the websocket client has been released recently [13:15] ah [13:15] bac: newer versions of jujuclient fix it, but we must depend on 0.17.5 which is the trusty release [13:16] uh-oh [13:16] frankban: they 'fix it' by specifying the websocket version or a code work-around? [13:17] bac: install_requires=["websocket-client==0.12.0"], [13:17] bac: which is correct, 0.12.0 is the trusty release [13:17] frankban: can we add that to quickstart? [13:18] bac: so, the easy fix is to add websocket-client as a dependency in requirements.pip, even if it's not a direct dependency [13:19] bac: setup.py automatically adds the requirements listed in requirements.pip [13:20] frankban: verified that works [13:20] bac: cool [13:20] frankban: i'll XXX to remove it when we go to a newer version of jujuclient [13:21] bac: sounds good thanks [13:27] frankban getting some <3 in the comments http://hackingdistributed.com/2014/05/22/hyperdex-on-aws/ [13:28] frankban: created new module quickstart/platform_support.py . it is a little unwieldy but i could not shadow the stdlib platform module. [13:28] rick_h_, jcastro: cool! [13:29] there's no juju noop command is there? [13:29] one that prints what it would do but doesn't actually do it? [13:32] bac: platform_support sounds ok, I suggested platforms but I agree is too similar to the stdlib one. from PEP8: "Underscores can be used in the module name if it improves readability.". I think this is the case [13:32] redir: I am not aware of any dry run mode [13:43] frankban: tx [13:44] frankban: requested changes made and ready for review at https://codereview.appspot.com/99410054/ [13:45] bac: looking [13:46] frankban: tx [13:46] echo [13:46] redir: yw yw [13:50] rick_h_: standup shouldn't go long today, should it? [13:50] bac: nope [13:50] bac: just normal run through and we've got two weekly review [13:50] good. going to tour CG cutter at 11:45 [13:50] gotcha [13:51] bac: will try to move fast today [13:55] I'd like to find a way to fail faster:/ [13:57] bac: done [14:02] what does: An error occurred while deploying the bundle: error() takes exactly 2 arguments (4 given) mean [14:03] in jujugui [14:03] redir: it means something didn't go according to plan. I bet the deployer doesn't like some error handling code [14:04] redir: want to hangout and see what's up? [14:04] hmm [14:05] just started different bundle... but I htink I can reproduce [14:05] redir: i'm available now to help. [14:05] I prolly have something wrong in some bundle [14:05] I am here [14:05] redir: yea, but we probably have something wrong is surfacing that error to the user behind the gui [14:06] ok gimme about 10 minutes to see if this deploy succeeds [14:06] k [14:06] redir, found it [14:07] redir, the bundle had an invalid placement fwiw [14:08] redir, can you pastebin the bundle [14:11] hazmat: sure [14:15] hazmat: [14:16] http://paste.ubuntu.com/7505780/ [14:16] redir, so for placement onto another service.. you have to specify for each unit the remote service unit. [14:17] hmm [14:17] your syntax looks sane though [14:18] redir, try with to: [mongodb] [14:18] hazmat: I have modified it about 100 times [14:18] redir, you mean you've already tried that suggestion? [14:18] so rerunning to verify [14:18] hazmat: I believe so [14:18] redir, like 10 and 19 [14:19] http://paste.ubuntu.com/7505793/ [14:19] redir, that works [14:19] hazmat: that one works to put all services on one machine "0" if previously bootstrapped [14:20] but mongo doesn't start [14:20] redir, and the log says? [14:20] for mongo that is [14:20] so I am now trying to deploy the 3 services in the bundle to 1 other machine [14:20] mongo the log says nothing no log created in /v/l/m/m.log [14:20] redir, also check /var/log/upstart/mongodb.log [14:21] doesn't start using service ... start either [14:21] hazmat: doh, forgot about that other log location:/ [14:23] the whole charm world deploy and ingest world to support the gui is kinda of bogus [14:23] hazmat sadly that time the bundle didn't get the error [14:23] redir, why so glum chum ;-) [14:23] sledgehammer to cut cheese.. style [14:24] you've pointed me at that upstart log dir before and I forgot about it [14:25] An error occurred while deploying the bundle: read tcp 127.0.0.1:37017: i/o timeout [14:25] doesn't look ideal [14:26] rogpeppe: are you available for reviewing https://codereview.appspot.com/98510043 ? [14:26] frankban: looking [14:26] rogpeppe: thanks [14:34] redir, its juju state server on the fritz, it comes back. but the deploy needs to be reattempted [14:34] redir, your running two mongodbs, juju state server, charmworld trying to ingest the universe.. its quite a heavy workload for a single machine [14:35] oh.. and java elasticsearch [14:35] hazmat: on that deploy there are two machines [14:35] redir, to=0 ? [14:36] the one with the 37017 i/o fail is on m0 and es/cw/mongo are on m1 [14:36] but es failed to show up on that one [14:36] hazmat: bac I'd be glad for eyes on these two envs I have running [14:36] redir, are you using canonistack? [14:37] hazmat: uh probably not [14:37] ec2 [14:37] redir, cool [14:38] hazmat: bac invites sent if you are free [14:38] https://plus.google.com/hangouts/_/gyagopwm6fdrxuvnl6oaqdjhoya?authuser=3&hl=en [14:50] jujugui call in 10 [14:50] redir, sorry stepped away.. no one was there [14:58] jujugui call in 2 kanban and such please [15:01] frankban: rogpeppe Makyo ^ [15:06] jujugui Review/QA: https://github.com/juju/juju-gui/pull/340 [15:10] redir: i'm running an experiment on ec2 to see if i can manually deploy mongo to machine 0 [15:21] another week almost down....man these weeks fly by [15:22] yea, no kidding [15:23] hatch: its seems Y.merge is shallow and clone is deep copy: http://yuilibrary.com/yui/docs/api/classes/YUI.html#method_clone [15:24] doh! [15:24] sorry everyone! [15:24] * hatch sulks away [15:24] ^ jujugui [15:25] hatch: :-) np, I was just wondering why my Y.clone fix worked two weeks ago [15:27] :) [15:28] rogpeppe, redir: http://paste.ubuntu.com/7506019/ [15:32] ok....what's it going to cost me to get someone to write these tests.....? [15:32] :P [15:34] rick_h_ btw - maybe I like the token widget now [15:34] MAYBE [15:35] :-) [15:40] hatch: hah, just a matter of time :P [15:41] * rick_h_ is going to get a t-shirt made up "Jeff says 'maybe..mabye rick was right" :P [15:42] lol [15:52] rick_h_ I can now reproduce Makyo's bug - We need to ignore the inflight response because the 'store' abstraction doesn't return the actual XHR pointer [15:53] hatch: right, I think we chased that before [15:54] the 'proper' fix would be to fix the store abstraction I think - but we can do a workaround for now, I'll do it in a follow-up [15:54] hatch: cool, yea I think a sanity check to just have the response come back and note the container is gone, halt, would beok [15:55] hatch: it's almost same effect as inflight ignoring because it's not like the server stops [15:55] * redir orders some lunch then wants to chat with rick_h_ to work out plan for this and handoff/knowledge transfer [15:55] redir: ok, are we chatting before lunch or after it? [15:55] right right - it would be nice though from the destructor to be able to call something like 'inflight.cancel()' though [15:56] hatch: right, but then it needs access to the store internals [15:56] your choice rick_h_ [15:56] hatch: it's a bit dirty [15:56] rick_h_ well no, the store calls could return a reference to the call [15:56] just like the env does [15:56] hatch: k [15:56] redir: let's do before then while it's fresh in our heads [15:56] this might be one of those 'just' things which turns into a big job hah [15:56] * rick_h_ is going to be shutting down after lunch friday ugh [15:56] so workaround first [15:57] hatch: I have a feeling like I chased that down before and hit that wall [15:57] OK [15:57] tis possible [15:57] let me make a biobreak and I am ready [15:57] hatch: this has the smell of promises causing doom to it [15:58] hatch: I think that's what I hit, some of the store calls are wrapped with promises that have specific return values already [15:58] haha I thought we got rid of promises, or are they still in there? [15:58] and getting at a reference to the ajax call isn't easily done [15:58] we stopped creating more, we never cleaned out the old ones [15:58] oh I thought we did [15:59] https://github.com/juju/juju-gui/blob/develop/app/store/charmworld.js#L280 [15:59] and more [16:01] ohh boy [16:01] promises - the gift that keeps on giving [16:01] rick_h_: ready and in daily HO [16:01] hatch: ok otp [16:05] rick_h_: http://paste.ubuntu.com/7506167/ [16:11] * rick_h_ goes to get food [16:12] rebase is nice when you want to re-order commits [16:19] yep yep [16:37] redir: woot, that bundle came up for me [17:15] ugh edge case [17:15] for the amount of pixels this takes up on a screen there are sure a lot of cases [17:15] :) [17:16] rick_h_: with ~cs:charmworld? [17:16] or with bac's branch? [17:16] redir: both [17:16] redir: I used your bundle first as it was [17:16] rick_h_: failed for me with bac's branch [17:16] and I've just finished a second pass with the source set to lp:charmworld [17:16] I must have the spelling wrong [17:17] redir: I downlaoded it and then just passed it to juju-quickstart [17:17] redir: so not sure [17:17] you pasted it right :) [17:17] redir: have some basics for the local charm docs? I'll try it out on my env I've got here [17:18] rick_h_: actually I need some local charms:) [17:18] charm get XXX [17:18] using charmtools [17:18] oh [17:18] will fetch them down and such [17:18] brb [17:18] rick_h_: how can I be sure it would deploy my charm rather than one ingested? [17:20] redir: you're not tryuing to deploy it [17:21] this is all eye candy, to get a charm into charmworld and then the gui will show it in the top left of the sidebar [17:22] oh [17:23] redir: how goes the battle? [17:24] hey bac side note, do you still have hte apache log info on the mjc traffic? IS asked me to get an RT filed to investigate the traffic and get it corrected and I want to make sure to fill in the fact right [17:25] rick_h_: i have anonymized apache logs from the other day. thedac just got it for me with no RT. is that what you want? [17:25] bac: yes, I just want to get the facts together. Knowing thedac helped look is good info. [17:26] rick_h_: i can paste some representative entries or give you the whole 22M compressed file [17:26] bac: a couple reference points will be good. Mainly I want to make sure we are positive where the traffic was from before filing the RT and how we figured out what was up [17:27] bac: or I was going to rope you into sumitting the RT and copying me on it if you don't mind/have time [17:27] bac: but on the bundle front I've had two good deploys from quickstart the colocated bundle redir put together and we're getting ready to test the local charm ingestion part [17:30] rick_h_: it was positively identified by the user-agent being gsa-crawler. thedac then looked at the non-anon IP address and saw it was internal. [17:30] bac: ok [17:33] rick_h_: http://paste.ubuntu.com/7506455/ [17:33] bac: thanks, appreciate the details [17:34] rick_h_: but IS already took some action to scale back the load caused by the crawler. would be worth a check to see if it has helped. [17:41] rick_h_: do you want me to file an RT? if so, what are we requesting? that they look at the log files to see if they are causing excessive load or that they not index the sites at all? [17:41] bac otp, I'll file in a bit [17:41] bac: they want to see why it's crawling at all [17:41] rt [17:41] ah, best plan [17:42] * rogpeppe is done for the day [17:42] see y'all tuesday [17:42] have a good weekend rog [17:43] rick_h_: and you. and happy weekends to everyone else too! [17:48] later rogpeppe [17:53] rick_h_: otp? [17:55] redir: yea on the phone [18:02] bac got a sec? [18:02] i do [18:02] regualar channel or should I start one? [18:02] hatch: thanks for the tip about iterm2. urwid works fine on it. [18:02] redir: regular [18:02] awesome [18:02] yeah it's by far the most popular terminal client on osx [18:42] redir: how we doing? I've got a 15min break here [18:45] good [18:45] wanna follow up after your call or have a look? [18:46] redir: sounds good [18:47] which? [18:48] oh, follow up after hte interview 4pm ish (hopefully a bit earlier) [18:48] OK [18:48] perfect [18:48] sorry, read that as "after your call have a look" [18:48] come on friday! [18:50] np [18:50] I shouldhn't ask compound questions [18:59] I wish YUI had a deep comparitor [19:07] edge case.....SMASHED [19:07] boo yeah [19:11] oh that just broke everything outside of il [19:11] head....desk [19:17] apparently this render editorial and sidebar business is ingrained into the browser deeper than I had thought [19:26] rick_h_: I have to run two errands before things close. I should be back by 4 [19:26] rgr [19:27] The Witcher 2 is only $4 and avail on Linux [19:27] http://store.steampowered.com/app/20920/ [19:28] hatch: cool or need to chat? [19:29] redir: cool, I'm free when you get back [19:29] rick_h_ all good - I just need to add a bunch of code back in which is causing cascading test failures [19:29] and tackle them in a follow-up [19:29] gotcha [19:29] yea, smaller is better in this process [19:32] rick_h_ I can also just put a patch in and break non il [19:35] actually I can just fudge these tests [19:43] rick_h_ no wonder this didn't work out going whole hog on it heh [19:43] it's all so intertwined in ways that aren't immediaately apparent until you break it :) [19:43] yea, I make bad decisiosn so you don't have to [19:43] :) [19:43] lol [19:43] decisions that is [19:48] excellent, back to where I was 2h ago [19:48] heh, baby steps [19:49] heh it's funny when tests pass but the code their testing doesn't exist [19:49] too much stubbing [19:49] lol [19:49] yea, I'm nervous with the level of stubbing we're getting to [19:50] once we go to a folder based, test hierarchy it will be a lot easier to see where our tests are and how they integrate [20:02] rick_h_: I am back [20:02] redir: cool [20:02] redir: https://plus.google.com/hangouts/_/gqvoo43tsgwyvpgcdtinfcjdema?authuser=1&hl=en [20:40] rick_h_: https://dl.dropboxusercontent.com/u/7386012/cw-2instance-demo.tar.bz2 [20:41] rick_h_: lemme know when you grab it [20:41] redir: rgr [20:41] I'll remove after [20:41] redir: got it, extracted and can read the readme [20:42]