[02:42] hey huwshimi [02:42] hatch: Ye [02:42] *Hey [02:42] typing [02:42] lol [02:43] crap CI hung on your build [02:44] huwshimi so in your branch you still have the min/mid/max classes - are those used somewhere? [02:44] https://github.com/juju/juju-gui/pull/400/files#diff-225b0a8e53f0646bec2686e3d713bbd5R37 [02:45] that line for example [02:45] rick_h_ u on? [02:45] hatch: They're not, but I'm expecting to use them in another branch. I can remove them from this one if you like? [02:45] no it's ok as long as you know you'll use them [02:45] yep [02:45] ok +1'd [02:46] you can land it whwnever [02:47] hatch: Thanks! [02:59] hatch: what's up? [03:00] rick_h_ oh hey, the PR ci will need restarting [03:00] I was just about to grab the info [03:00] :) [03:00] hatch: gotcha, sec [03:01] hatch: I only see the prod one going [03:01] hatch: and that's in a test run to land [03:02] rick_h_ yeah I had to kill the one in the pr lane because it hung [03:02] so it will likely still be running...no? [03:02] hmm, tests are running atm [03:02] hmm, maybe it's this other one [03:02] right - not the landing script [03:02] the pr one [03:02] ok, killed one [03:02] hopefully that's the right one :) [03:02] haha we'll know shortly! [03:03] maybe this weekend I'll find some time to add the 'if running KILL IT DEAD' mode :) [03:03] it's supposed to do that :P [03:03] (cd build-prod && \ python ../bin/http_server.py 8888 2> /dev/null & \ echo $!>ci-check-gui-server.pid) [03:03] oh haha - well then, why does it give the ERADDRINUSE issue? [03:04] ohhh [03:04] that's not checking the node server [03:04] echo ci-check-gui-server.pid [03:04] ci-check-gui-server.pid [03:04] cat ci-check-gui-server.pid [03:04] 4360 [03:04] kill `cat ci-check-gui-server.pid` [03:04] rm ci-check-gui-server.pid [03:04] hatch: oh hmm, yea then maybe it needs more of it [03:04] yeah I think it's the node server that throws the error [03:05] gotcha, yea well happy to run more pid/pid-checking to help it [03:05] doens't happen too often thankfully. [03:06] hatch: you hatch on launchpad? [03:06] yep [03:06] you're a rude man making me look it up on LP hatch :P [03:07] ok, you've got ssh rights. ssh ubuntu@ci.jujugui.org [03:07] lol sorry I was in the other room [03:07] don't mess up my server or I'll have to come to canada and drop you down a hole in the ground [03:10] lol yeah I wont be at it until this weekend for sure [03:10] at what? [03:10] you not in canada right now? [03:10] haha of course I am [03:11] I meant, I won't be breaking your server until this weekend [03:11] well don't do that! [03:11] :) [03:14] Ooo nice new column in the board [06:43] mornin' all [06:43] rogpeppe: Morning [06:54] huwshimi: hiya [11:27] morning [13:15] rick_h_: hiys [13:15] hiya [13:15] even [13:15] rogpeppe: howdy [13:16] rick_h_: the bundles parsing/verification PR is up at https://github.com/juju/charm/pull/9 [13:16] rogpeppe: cool looking. [13:16] rick_h_: it does all the internal verification, but doesn't verify against actual charms [13:17] rogpeppe: ok, can you create a bug/additional card to look into that part? [13:17] rick_h_: ok, will do [13:17] rogpeppe: we're thinking that'd part of the publish side of things? [13:17] vs part of the actual model side here [13:17] rick_h_: i'm thinking that it can live inside the charm package [13:17] outside you mean? [13:18] rick_h_: no, inside [13:18] rick_h_: something like BundleData.VerifyWithCharms([]*Charm) error [13:19] rick_h_: which means it can be called by any client that happens to know the charms that the bundle service charm urls resolve to [13:20] rogpeppe: ok, looking through this pr and will see how it fits [13:20] rick_h_: thanks [14:13] rogpeppe: how does such 'combining of errors' work? They're basically complete sentences. How does one take them and combine them more than just listing them out? Does it ', and' each or anything as part of this common practice? [14:13] rick_h_: usually it just involves prefixing "something happened: " onto an existing error [14:14] rick_h_: in this case, the final error might look something like "cannot verify bundle: placement "foo:bar" refers to non-existent service (and 303 more errors)" [14:15] rogpeppe: ok, but then we need to make sure to update the clients cli and webui to do this post processing. It seems like adding more places to catch the update than to make it work right [14:15] rick_h_: all errors returned by the API are currently without capitals or periods [14:15] rick_h_: so this just continues in the same vein [14:15] rogpeppe: right, and we've had to do work in the gui to try to parse them and make them presentable [14:16] rogpeppe: right, it's an existing issue I'm bringing up potentially attempting to address while we're here in the code [14:16] rick_h_: if we're going to change that, i'd prefer to change the entire API [14:16] rick_h_: rather than adding a single inconsisent place [14:16] inconsistent [14:16] heh count me in :) but we're in control of this bit of code and we know that errors parsing the bundles will need to get in front of the users [14:16] so they can debug and fix them [14:16] rick_h_: consistency trumps convenience IMHO in this case [14:17] rogpeppe: ok, then we should add cards for the core cli and the gui to update bundle errors when connect to the updated store so that we don't lose track of known usability issues that we should correct. [14:18] maybe bugs would be better since they can't be updated until a store update is deployed and used [14:19] rick_h_: i'm not entirely sure it's a CLI issue - errors are currently printed in lowercase [14:20] rick_h_: but i'll add an issue to the gui. are gui issues tracked in lp ? [14:20] Why would it be good to make the error message a complete english thought with proper writing in one place and not the other? [14:20] rogpeppe: yes, they are [14:21] rick_h_: mainly because many things on the unix command line print stuff in lower case - there's honourable precedent :-) [14:21] rick_h_: and it's less code, which is always a win in my book :-) [14:27] rogpeppe: i've got the latest charmstore and tried to run 'make check' but get errors referencing missing testing items like MgoSuite, etc. [14:27] * rogpeppe goes to see what make check does [14:28] bac: for the record, when dealing with go packages, i almost never run make [14:28] rogpeppe: but through CI and such make is the single interface all devs can use to hack/operate [14:29] rick_h_: sure, it's useful for CI [14:29] rogpeppe: the make targets need to be valid and make check is the common target in all proejcts for a CI-like run through lint, test, etc [14:29] so in QA it's quite common to make check, make run, and then qa [14:29] rogpeppe: i'm just looking at the README and it references 'make check' [14:29] bac: ok [14:31] bac: have you tried doing: godeps -u dependencies.tsv ? [14:31] bac: it all seems to work for me [14:32] bac: could you paste the exact errors you get? [14:32] rogpeppe: https://pastebin.canonical.com/112262/ [14:33] bac: hmm, odd. [14:34] bac: could you try doing "rm -r $GOPATH/pkg" then "go install ./..." and trying again? [14:34] rogpeppe: from inside the charmstore directory? [14:34] bac: yes [14:36] rogpeppe: didn't help. what version of juju/testing do you have? mine is b09... [14:37] bac: b0941ff1bf4d3db1ffbbe09f75fa8383eae5764c [14:37] same [14:38] bac: do you see the same thing if you just run "go test" (in the same dir) [14:39] rogpeppe: yes, and it is unsurprising. if i look in juju/testing i see no MgoSuite anywhere [14:39] Juju GUI architecture question: how do we connect to the juju state server? [14:39] kadams54: websocket [14:39] via websocket [14:39] and magic [14:39] rogpeppe: if you look in juju/testing where do you find those defined? [14:40] * hatch shakes hands in the air [14:40] lots of magic [14:40] *magic* [14:40] bac: in mgo.go [14:40] rick_h_: Where at in the code? [14:40] heh well.... [14:40] bac: what do you see if you run "git status" in the juju/testing dir? [14:40] kadams54 I can get you the loc, one sec [14:41] clean [14:41] rogpeppe: there is no mgo.go in my juju/testing [14:41] kadams54 here is the websocket instance https://github.com/juju/juju-gui/blob/develop/app/store/env/base.js#L234 [14:41] bac: could you paste the entire output of your "git status" please? [14:42] kadams54 here is where we make the requests https://github.com/juju/juju-gui/blob/develop/app/store/env/go.js#L181 [14:42] kadams54 did you have a specific question in mind? [14:43] rogpeppe: i went to my juju/testing and did a 'git pull' and it got the mgo.go file along with lots of others. why did the 'go get -u' and the 'godeps' not update it? [14:43] bac: i don't know - that's why i wanted to see exactly what git status printed for you [14:44] hatch: that satisfies my curiosity for now, thanks [14:44] bac: AFAIK go get -u just does a git pull [14:44] rogpeppe: this is what git status said before i did the manual pull: https://pastebin.canonical.com/112263/ [14:45] bac: thanks. i've no idea then. "go get -u" just runs "git pull --ff-only" [14:46] kadams54 np [14:46] rogpeppe: i'm going to blow away everything and try again [14:46] hey cory_fu [14:46] bac: that can be a good plan... [14:47] bac: have you tried testing again now that you did the pull? [14:47] well i just want to see if it is reproducible [14:47] bac: wait! [14:47] rogpeppe: i did and it passed [14:47] bac: what does "git remote -v" print for you in the juju/testing dir? [14:47] bac: too late... [14:47] bac: darn [14:47] but... it printed the right head [14:47] Hey, who should we be sending design/UX questions to right now? Luca's out, right? [14:48] jeeze, i dunno [14:48] kadams54 spencer [14:51] jujugui call in 9 [14:54] wow, crazy loud tsunami drill. i guess that's what you want from a tsunami alarm. [14:58] what does one do when a tsunami alarm rings? Run inland? [14:58] rogpeppe: so you'll know, i'm trying to set up and test the charmstore as we'd do for CI. it looks like we have some problems with our dependencies. here's what i've done (mainly as stated in the README) : https://pastebin.canonical.com/112265/ [14:58] jujugui call in 2 [14:58] run downstairs, grab beer and camera, then go to the roof. [14:59] bac: you need to do go get -t [14:59] ahh to the roof [14:59] I guess that makes sense :) [14:59] rogpeppe: go get -t -v github.com/juju/charmstore ??? [15:00] bac: in full, you'd need to run: go get -v -t -u github.com/juju/charmstore/... [15:00] bac: the final "/..." is important [15:00] bac: otherwise you won't get deps for subdirs [15:00] jujugui call now [15:11] hatch: https://github.com/juju/juju-gui/pull/393 is ready for QA again. I want to hold off on sending this e-mail until this branch is landed and you can see stuff working/not working on upcoming. [15:13] Here are the questions I'm planning on sending out, in case you want to review: https://gist.github.com/kadams54/681a40f7bd9d603a53bb [15:15] So, I'm still trying to understand how juju-gui connects back to the juju state server. [15:15] I thought maybe https://github.com/juju/juju-gui/blob/develop/app/app.js#L382 was where it got the address of the state server, but that just seems to be the connection to the GUI backend? [15:15] cory_fu was unsatisfied with the "magic" explanation. [15:15] :) [15:16] rogpeppe: adding the -t worked. i'll update the readme [15:16] bac: thanks [15:16] rogpeppe: yeah, the ... was important too [15:19] 948647 [15:19] ccccccdilrklllutrivjhvjttuigtldiclbejkuderdh [15:19] Alright, that's it [15:19] I'm failing to understand how it can be using the public address for the juju-gui unit yet still have commands get to the state machine on machine 0 [15:19] ccccccdilrklnvjvvhbrtekkhcebgrrjeejurdfdvuvc [15:20] guihelp: --^ (cory_fu, not my yubi spam) [15:20] kadams54: You don't have another USB slot more out of the way? :) [15:20] Oh, yeah, thanks [15:20] cory_fu I'm not sure the question [15:21] I realized what it is - when I'm cmd-tabbing, my pinkie is right over that USB slot. I may try the other one. [15:21] cory_fu kadams54 we don't connect directly to the juju state server [15:21] we connect to the gui server [15:21] hatch: Ok, so I need to know how the GUI server talks to the state server [15:23] it also uses websocket but from a python server [15:23] http://bazaar.launchpad.net/~juju-gui-charmers/charms/precise/juju-gui/trunk/files [15:23] that's the charm source [15:24] cory_fu so are you trying to write your own application with communicates with the state server? [15:25] hatch: Yeah. I'm working on the Cloud Foundry charm and it turns out we're going to need to communicate with the state server, similar to how the GUI does [15:26] ok there is api documentation around that.... [15:26] one sec I'll see if I can find it [15:26] at least I thought there was.... [15:27] Ah. I found what I needed. :) [15:28] cory_fu: yes, the gui talks to the guiserver in the charm [15:28] cory_fu: and then it proxies all requests to the state server and intercepts a couple of special api calls like bundle deploys that juju doens't natively handle [15:28] Ok. That's basically what I expected. Thanks. :) [15:28] cory_fu perfect....where was it ? [15:28] hah [15:29] oh heh, hatch has your back. [15:29] hatch: https://bazaar.launchpad.net/~juju-gui/charms/trusty/juju-gui/trunk/view/head:/hooks/utils.py#L140 [15:29] cory_fu: yea, you're looking for http://bazaar.launchpad.net/~juju-gui-charmers/charms/precise/juju-gui/trunk/files/head:/server/ [15:29] That function is exactly what I needed [15:29] ahh perfect [15:29] yeah the guy who does this work is off atm :) [15:31] good luck with the charm [15:32] Thanks. :-) [15:58] * rick_h_ goes to make up some lunch [16:23] has anyone else been running into issues with yahoos cdn taking forever to respond? [16:33] oh our test suite.... [16:42] jujugui looking for a review/qa on this first relations branch https://github.com/juju/juju-gui/pull/402 [16:42] hatch: looking… [16:43] thanks [16:43] kadams54 what was the issue with the previous qa issue on your branch? [16:43] https://github.com/kadams54/juju-gui/commit/be1356a686a51632160fae08a8570d7e59310a3a [16:43] that commit? [16:44] It was the unitOrEvent variable that got renamed back to unit… it needs to be nulled out if it's actually an event rather than a unit. [16:44] Yeah, that commit [16:44] ok cool - in the future can you use a real commit message :) [16:44] review looks good, qa'ing [16:55] kadams54 try a make clean and clean your cache (re huw's branch) [16:56] hatch: yeah, I did both, still seeing the funky button. [16:56] hmm odd alright then [16:57] kadams54 adding a container without selecting a machine is kind of odd heh [16:57] because it creates a machine [16:58] Yes. There's a lot of funkiness around MV in general. [16:58] If you stick to the happy path, everything is all rainbows and unicorns [16:59] Stray off and the world goes sideways. [17:01] ok one more small qa issue [17:01] one of these days I'll get all of you to stop using anchor tags :D [17:01] Ah ha ha ha ha [17:07] hatch: I'm puzzled about why that's happening for "Add container", but not "Add machine" - they both have the same handler function which does preventDefault(). [17:07] Giving span a try… [17:07] it happens for both for me [17:08] What about on http://comingsoon.jujucharms.com/? [17:08] kadams54 it might need an e.halt() [17:08] basically anchors are stupid [17:08] and I'm not goign to change my mind on that :D [17:08] Pffft, no way! [17:09] lol [17:09] Jeff would totally call that out in review. [17:09] ;-) [17:09] haha [17:09] Oh good gravy [17:09] really though - anchors in a webapp are only useful if you're taking advantage of pjax [17:09] which we aren't [17:09] spans don't have the right styling. [17:09] lol [17:10] this branch just won't die [17:10] kadams54 try using e.halt() instead of e.preventDefault() [17:11] jcsackett where did you use to get those shirts made up from the sprint? [17:12] hatch: OK, that worked - change pushed. [17:13] even I'm getting sick of QA'ing this branch lol [17:13] you must be right pissed [17:13] haha [17:14] I'm ready to be done, for sures [17:15] Though I have a long list of stuff to turn into bugs and cards, so even after this one lands, it will live on. [17:15] And that's aside from questions to send to design. [17:17] qa ok;d [17:17] land that! [17:18] kadams54 you'll probably want to move your branch-start card back and then create smaller cards from it [17:18] Hmm… you're talking about the deleting machines/containers one? [17:18] yeah [17:18] there is a lot of work there [17:19] probably more than 4 days [17:19] judging by how long it took me to do the relations one heh [17:19] OK. I already created a separate card for ghosted stuff. [17:19] hatch: kadams54 sorry, just catching the conversation drive by [17:19] hatch: kadams54 we do need to chat and plan out a path? [17:19] we does [17:19] Sounds like it [17:19] standup linky? [17:19] * rogpeppe is done for the day [17:19] lata rogpeppe [17:19] rogpeppe: have a good evening [17:20] rick_h_ sure [17:20] rick_h_: see ya tomorrow [17:20] hatch: likewise [17:20] g'night all [17:44] hatch: teespring. [17:44] hatch: was going to build another one for the last sprint, but alas the required minimum went up. [18:04] booo! [18:04] well this sprint there will be more people [18:04] hopefully I'll say something stupid again [18:04] er.... [18:05] man, hatch you're making it too easy [18:05] lol [18:05] "it's not a matter of if...only a matter of when, and I want to buy the square for day #1" [18:10] haha [18:12] rick_h_: in jenkins CI what is the authentication token? do we just use the same one for all projects? [18:13] bac: each project can define one, I've just used the same one I think on the two projects [18:13] bac: but feel free to set a custom one for the store [18:14] rick_h_: i don't understand what it is [18:14] just a string? [18:14] bac: yea, just a private string [18:14] pertaining to nothing? [18:14] what is the point? [18:15] bac: in order to trigger a build via a url call (poor man's api) you can use the token to limit who can trigger a build [18:15] bac: it's like a shared secret kind of auth or poor man's api token [18:15] * bac feels safer [18:15] bac: actually not sure if the lander supports a key per project. :/ [18:15] * rick_h_ checks code [18:16] bac: so it might need to be the same for the moment [18:16] rick_h_: doesn't matter, i'll just use the same one [18:16] bac: ok cool [18:18] rick_h_: and for each jenkins test run do i get a new "machine"? [18:20] bac: no [18:20] bac: not currently, we've not had to. That's something we might have to think about. I know the juju ci does create slave machines to test on [18:20] bac: I'd suggets we work with them on that side so that they can bring up machines across platforms, but we have a more simple sanity check for work. [18:20] rick_h_: ugh, i just edited the juju-github-lander test script when i thought i was editing charmstore's. [18:21] rick_h_: anyway to revert? [18:21] bac: no, there's a backup script that runs but not a good way to revert as the ini file isn't part of the lander's github project [18:21] dang [18:22] bac: oh you mean in the build steps in the jenkins UI? [18:22] rick_h_: yeah [18:22] bac: yea, no good way to restore without pita backup xml fun [18:22] i replaced 'make test, blah blah' with the steps for charmstore [18:22] we have a full backup for doing a full restore but not easy to get 'this field' [18:23] rick_h_: ok, i'll look at the makefile and see if i can figure it out [18:23] bac: hmm, yea it should be close to the other job [18:23] bac: which job did you edit? [18:23] jenkins-github-lander [18:24] http://ci.jujugui.org:8080/job/jenkins-github-lander/configure [18:24] bac: ah ok, I'll update [18:25] make testdeps; make lint; make test [18:25] ?? [18:25] bac: updated, copied from the -merge version of the job [18:25] oh cool [18:25] just removed the landing stage [18:25] having two jobs is a bonus sometimes :) [18:35] rick_h_: for jenkins we specify the sha1 of the commit to test. is that the sha of the branch that has been proposed? e.g. https://github.com/bac/charmstore/commit/7d8c2efae2517c3d1e01d8f686223d3a9ad1420c [18:35] rick_h_: if it gets that sha at the end of the url, but doesn't know about the specific user, it can fetch it from github? [18:36] bac: yes, git watches the list of branches in the pr namespace and knows how to check out each commit sha [18:36] bac: so you can give it any commit in any pr and it'll checkout/test that sha [18:36] nice [18:36] normally it just gets the latest sha in the pr [18:42] kadams54 did you review/qa my branch yet? [18:42] In progress right now. [18:43] cool thx, i'm gona go grab some lunch [19:31] mmm check this out! http://www.withings.com/activite/en-US me wants [19:33] well except that it doesn't work with android [19:33] so I just watched a video and don't know anything more than when I started [19:34] rofl [19:34] I thought the same thing haha [19:34] it's a pretty fitbit? [19:34] yep [19:34] pass, I <3 my pebble steel [19:34] basically by the time it's released I will have forgotten about it [19:34] oh well [19:34] I want the Google watch [19:34] got a new awesome watch face that is nice and clean [19:34] that thing is darn cool [19:35] heh, that one will be tough. I'll be darn tempted to get my google now on my wrist [19:35] but I think that'll definitely a gen2 switch over [19:35] I'm kind of hoping they release it tomorrow, I'll be staring at my screen with my cc in hand waiting during the keynote [19:35] heh, I was glad I had no calls at noon [19:35] you can be sure the chromecasts in the house will be watching the keynote [19:36] of course it won't be available in Canada...so I'll have to have you buy it for me [19:36] lol [19:36] works for me [19:36] when two of them show up I'll just tell the wife I was getting it for you [19:36] and hide the other one :) [19:36] hahaha [19:37] there was a watch face competition for that watch.... [19:37] I +1'd a couple....now where do they keep these +1's [19:37] hmm empty... [19:37] that's not right [19:41] https://plus.google.com/photos/+Motorola/albums/6025927350868561553 [19:42] it's kind of too bad pebble didn't go colour and round :) [19:45] rick_h_: ugh, our jenkins is precise but charmstore is not very precise-happy [19:45] time to switch back to warty [19:46] hmm that's an interesting failure in ci [19:47] bac: ok, well we can deploy a new jenkins server on trusty. [19:48] rick_h_: man that would make life easier [19:48] bac: or we look at using jenkins/jenkins-slave to run the tests on a slave related machine [19:48] trusty! trusty! [19:48] wait for my merge to land plz :) [19:48] bac: yea, I first thought we could move all of ci to trusty, but jujucharms and prodstack is still precise [19:48] rick_h_: here's what i've got so far: http://ci.jujugui.org:8080/job/charmstore/configure [19:48] bac: so we'd need to get our prodstack envs moved as well [19:49] rick_h_: the go-ness of it makes it kind of messy [19:49] bac: want to peek at the jenkins slave charm and see if we can more easily tie that in? [19:49] * rick_h_ is looking [19:50] rick_h_: going to trusty would give me a modern version of go too. [19:50] bac: right [19:50] bac: but if we setup the slave machine, we have one place to view the results reports [19:50] but run the tests on another machine that can be the go-centric place and can be trusty easily without effecting current stuff [19:50] we do or we don't? [19:50]