[00:01] hatch: Yeah, it'll be nice to move out of the bedroom :) [00:02] haha, yeah - I've been thinking of adding a furnace into my garage and turning it into an office so I can get out of the house....so far that plan has not worked out :) [00:06] hatch: Yeah, it's nice to have a nice separate space. I'll actually have to walk out the front door to go to work now :) [00:07] haha, that'll be nice :) [00:07] yeah :) [00:15] ok, I'm going to ship this [00:20] hola huwshimi [00:20] bac: Hello! [00:20] huwshimi: how's it going? all wintry? [00:21] bac: Not so wintry today: http://www.rosebay.tased.edu.au/webcam/medium.jpg [00:21] (that's a semi-live shot) [00:21] a little snow left, but 18C today [00:30] huwshimi: very nice! [00:31] hobart sprint! [00:31] huwshimi: also, you probably noticed - I added a ton of new cards into Project 1 from lucas qa [00:31] lots of ux'y bits there, some of which can probably be combined [00:31] hatch: Yeah, no problems. [00:31] bac, I agree! [05:10] huwshimi: one comment on review, just doing qa now [05:10] hatch: Ah thanks, I haven't even finished typing up my qa notes! [05:11] haha, ok I'll wait [05:11] I just finished this weeks homework so was just about to shut down before I saw your branch :) [05:12] hatch: Just added [05:12] nothing complicated [05:14] on it [05:17] huwshimi: qa issue, posted in the review - I'm not sure what the mockups say about this [05:17] hatch: Are we really doing custom radio buttons!? [05:17] huwshimi: well we do custom checkboxes...so why not radios! [05:17] I guess... [05:17] the technique is the same at least :) [05:18] huwshimi: tbh that's probably low priority, I can ask luca about it in the morning if you like [05:18] it's ok, it's just potentially a whole lot of work [05:18] hatch: The more menu exists in the mockup for an empty container column [05:19] yeah? Kind of odd, no? [05:19] morning all [05:19] urulama: Morning! [05:19] hey there, huwshimi [05:19] urulama: morning! [05:19] hatch: yeah, it doesn't seem ideal [05:20] huwshimi: ok if that's in the mockups comment as such in the PR then it's gtg [05:20] hatch: you still up? :) [05:20] urulama: heh yeah - just finished homework, and saw huw's branch up [05:21] listening to the Chillout channel on di.fm [05:22] hatch: :) [05:23] hatch: Thanks a lot for the review [05:23] huwshimi: np, should be good to land - but someone else should probably review it in the am as well [05:24] hatch: that's a mongo class, right? [05:24] yep np [05:25] urulama: yeah, second week [05:25] hatch: ask if you pass it, if you implement proper n-grams :) [05:26] urulama: haha [05:26] well patterns are this coming up week [05:26] so we'll see [05:26] https://university.mongodb.com/courses/10gen/M101JS/2014_Aug/syllabus [05:26] does that link work if you're not logged in? [05:27] hatch: no [05:27] ahh darn [05:27] well yeah, doesn't look like they dig into any advanced querying [05:27] np, let me know if n-grams pop up in class, please :) [05:28] you bet [05:28] so far I'm at 100% [05:28] pressure is mounting [05:28] I have to now maintain that [05:28] lol [05:28] :) [05:28] * urulama goes hunting for food [05:29] * hatch goes hunting for sleep [05:29] night all [07:35] mornin' all [07:35] rogpeppe: morning [07:35] urulama: hiya! [07:57] rogpeppe: hey. how was your double-weekend (4days)? :D Hope you managed to catch a breath and re-energize [07:57] urulama: good, thanks. [07:57] urulama: definitely needed it :-) [07:58] rogpeppe: great to hear! [10:28] jujugui: need to jump out for 10min [11:54] urulama, you can post what you mailed me as an answer! [12:05] jcastro: done [12:30] morning all [12:31] Updated: https://github.com/juju/charmstore/pull/77 Needs review, especially rogpeppe. [12:31] jrwren: cheers, will look [12:31] jrwren: morning [12:31] urulama: good morning [12:44] jrwren: how's quickstart going? let me know when you're finished with revision API and quickstart. I've added some cards for the CS search if interested. [12:45] urulama: quickstart is done. revision is in review, hopefully with not too much left todo [12:45] jrwren: good news :) [12:46] while i'm looking at jrwren's branch, here's nice little algorithm problem i came across when writing some tests for the PutMeta stuff. Here's some code: http://play.golang.org/p/1rUf8iNBhq . The challenge is to fill in the body of Reorder. I think it should be trivial, but I haven't quite worked out a nice method yet. [12:46] urulama: ^ [12:47] i was always terrible at that. [12:47] rogpeppe: saved it for the evening :) [12:50] crap. i managed do bork my juju environment. [12:58] urulama: how's it borked? [13:03] rogpeppe: without any evironments, juju status hangs in the air, have to terminate it. Also, can't destroy environments. strange. I'm on another VM currently, but will have to look what happened [13:03] urulama: is this using ec2 or local? [13:03] rogpeppe: local [13:04] urulama: do you know what you did to bork it? [13:04] rogpeppe: i'll do history revision later, will try to reproduce on the new one. [13:20] * urulama lunches [14:03] guihelp: looking for reviews on https://github.com/juju/juju-gui/pull/509 [14:04] hatch: when you have a moment, let's talk about https://github.com/juju/juju-gui/pull/510 [14:06] sure, gimme a few [14:06] rogpeppe, frankban: how do i upload someBundle.zip using /archive API? [14:07] urulama: POST to /archive/id [14:07] urulama: with an appropriate content hash [14:07] not working. posting mediawiki.zip fails as it expects series, and if series are added, it expects a charm and therefore metadata.yaml [14:08] urulama: e.g. /archive/precise/foo?hash=4544f44f33f3f4f43 [14:08] urulama: series is "bundle" [14:08] oh sorry, i missed that it was a bundle [14:08] what frankban says [14:09] {"Message":"cannot read bundle archive: archive file \"bundle.yaml\" not found","Code":""} [14:09] but there is bundles.yaml :) [14:10] urulama: heh, we don't like plural [14:10] frankban: indeed, there shall be only one! [14:10] :) [14:11] kadams54: ok wassup? [14:11] did you make sure you were running on the new version? [14:11] urulama: are you expecting it to work with bundles.yaml ? [14:11] hatch: So the problem I ran into I *think* is different from what was fixed earlier… [14:11] the first bundle that i took from LP (mediawiki) has bundles.yaml inside [14:11] can you add steps to reproduce in the PR? [14:12] rogpeppe: also all docs reference bundles.yaml not bundle.yaml [14:12] without steps to a qa issue, the issue is basically useless [14:12] hatch: It's the same steps you outline for QA. [14:12] yeah when I follow those on any os the tokens never leave the UI [14:12] hatch: After I click on deploy, the tokens disappear. Old behavior was that the uncommitted state was removed, but they didn't disappear. [14:13] tbh I don't even think it's possible for them to do so [14:13] are you using ec2? [14:13] That's running in Chrome/Ubuntu on a local lxc. [14:13] and you're sure you're running my PR? [14:13] what if you switch to develop? Same? [14:14] kadams54: i'm doing QA/review on your branch now. [14:14] jcsackett: thanks [14:14] hatch: I'll verify against develop [14:14] urulama: unfortunately the recent bundles specification doesn't mention the name of the bundle.yaml file... [14:14] hatch: i've pushed up my changes to the branch of omg; i think it resolves everything now. [14:14] jcsackett: cool thanks, I'll take a look [14:14] urulama: but i'm pretty sure that "bundle.yaml" is correct [14:14] urulama: the old format allowed a bundle to actually define several bundles [14:15] rogpeppe: this makes old bundles incompatible with new CS [14:15] urulama: that's definitely true, yes [14:15] urulama: that was a deliberate decision - there are quite a few differences [14:16] rogpeppe: aaaaa, ok. [14:16] urulama: we simplified and generalised some aspects of it [14:18] jcsackett: when you get a moment can you also QA #510? kadams54 is reporting a qa issue that shouldn't even be possible :) [14:19] hatch: sure, i'll see if i can reproduce. [14:19] it'll be a few, though. [14:21] yeah no rush [14:28] jcsackett: hey you have a real failure in your update [14:28] test failure * [14:29] huh. that doesn't come up locally. [14:29] that'll be fun to sort. [14:30] heh make sure you try test-prod [14:31] doesn't make check run that? [14:31] or does check only do test-debug? [14:33] honestly I have no idea [14:33] I run `make lint test-debug test-prod` [14:33] I'm sure it does though [14:33] I've just noticed some of the test failures come from running under prod lately [14:37] * jcsackett nods [14:37] hatch: seeing if i can reproduce kadams54 qa error on your pr now. [14:38] thanks [14:38] sorry it's got to be on a real env.....but at least lxc is pretty fast :) [14:38] jcsackett: I'm doing my mongo U stuff in an lxc....lovin it, it's not cluttering up my primary machine :) I can't believe I didn't do this workflow before [14:39] hatch: lxc's are nice. :) [14:39] hatch: you should also check out vagrant-lxc, which i've heard good things about if you like vagrant. [14:40] hatch: i can't reproduce his error, but i've found a different one. [14:40] i'll add notes to the PR. [14:40] thanks [14:43] jcsackett: oh very odd issue [14:46] kadams54_: there's the internet I expect.... [14:46] lol [14:47] :-) Not my internet - I walked away while waiting on juju-gui-source to take and forgot to plug my laptop in. [14:47] Power settings kick in and turn off network after so many minutes of inactivity. [14:48] I suspect most of my timeouts are due to inactivity/working on my Ubuntu desktop + forgetting to plug in. [14:48] ohh haha I gotcha [14:49] I have this mac mini that's not being used I was thinking of turning into an Ubuntu box....not sure about it though because I love the portability of my laptop [14:50] jujugui call in 10 [14:54] frankban: i can get bunle into the CS (meaning that charms have been validated), however, /ID/meta/bundles-containing always returns [] [14:55] urulama: what's ID in that request? [14:57] frankban: so the bundle looks like: http://paste.ubuntu.com/8150598/ [14:58] frankban: and id is either mysql or /precise/mysql or even /precise/mysql-0 [14:58] frankban: and id is either mysql or /precise/mysql or even /precise/mysql-1 [14:58] * hatch pats jcsackett on the back...."It'll be ok....it'll be ok" ;) [14:59] urulama: ok will check after the call [15:00] * jcsackett holds up sign at hatch. the sign says "NO" [15:00] lol [15:09] hatch: did you try to diagnose it yourself? [15:10] urulama: yeah it's a broken thunderbolt port [15:10] they need to run their own diagnosis though, then order a new logic board [15:10] then next week I'll need to take it in again to get it replaced [15:10] hatch: nice :) [15:11] urulama: yeah the good news about apple products is that I can go somewhere, sit there while they fix it, then take it home [15:11] any pc stuff you have to leave it there for a while and such [15:11] or ship away [15:11] unless they say "we need to keep it." [15:11] frankban: i can get meta on any of the charms in the bundle so all are there [15:12] urulama: and the bundle is there, correct? [15:12] it is [15:12] jrwren: heh, I made it very clear that I need it to work [15:12] frankban: get on /archive returns a zip [15:12] frankban: with proper content [15:12] urulama: bundle-metadata? [15:13] hatch: thanks for the tip. I shall remember that next time. [15:13] jrwren: yeah I called last week and booked the appointment for thursday morning so I will wait and they can fix it then return it [15:13] if I would have dropped it off then yeah [15:16] frankban: all there [15:16] frankban: {"Services":{"haproxy":{"Charm":"precise/haproxy","NumUnits":1 ... [15:17] frankban: /v4/precise/haproxy/meta/bundles-containing returns [] though [15:21] urulama: is it empty if you specify any-series=1 and any-revision=1? [15:21] frankban: no, just tried [15:22] frankban: having both =1 returns the bundle [15:22] frankban: two revisions even, which is ok! [15:23] frankban: any-revision=1 must be set to get results. [15:23] urulama: it should work with just any-revision in theory, if the id is precise/haproxy [15:24] frankban: it does [15:25] urulama: this is because the bundle does not include a full URL [15:26] urulama: services specify unrevisioned charms, so no full URL match succeeds [15:27] urulama: this is the current behavior, we can change this so that the last revision of the charm matches the bundle, but this also mean what's valid today will be no longer tomorrow. [15:27] urulama: generally speaking, I believe those kind of bundles are broken by design ;-) [15:28] urulama: could you please double check passing a bundle with fully qualified charm urls? [15:28] frankban: on it [15:29] urulama: thanks, that bundle should be included in the results without specifying any-revision [15:30] frankban: charm with revision returns the bundle without any-* flags [15:31] frankban: man, this will be PITA to use in real life :) [15:31] frankban: esp. if bundles will specify "hand-made" charms [15:33] urulama: I am not sure about the real uses of that api call, but if you think there are use cases that can be helped by the different behavior, then we can discuss that and change the spec [15:34] urulama: but there is a cost server side [15:36] frankban: looking from the GUI perspective, if a bundle is "neat", than charm will show it's bundles. but not all of them (when revision is not set), so we need another check if the charm is the latest one, we should not care about revision and show also the bundles with /bundles-containing?any-revision=1 [15:38] urulama: ok, so the server should check if the current charm is the last revision, and in that case, also include the bundles with revisionless charms. this is doable, would you like to make a card? [15:39] urulama: we can also decide whether this is something we tackle now or later, if the need for this is demonstrated [15:39] frankban: i'll think about it for a sec ... i don't see any problems with it and we do get results consistent with the behaviour of the system [15:40] frankban: for now, i'll just add a comment to the doc [15:40] urulama: sounds good [15:44] jcsackett: so your bug that you found in my branch.... does the icon show up on the machine? and not the token? Or just doesn't show up on the token? [15:44] And you were saying on develop it shows up once you click on the token? Where does it show up on? [15:46] frankban: naaa, it's not ok. any-revision will of course also include all bundles that reference old charms, which should not be shown. [15:46] frankban: so latest charms should only show bundles that include charms without revision, but not behave as any-revision=1 [15:47] hatch: one you commit changes (1 machine with 1 unit on the root container), the machines show up as committed with no units. on develop, once you click on the machine (not the root container), you see the service unit icons. [15:48] on your branch, when i click tokens, i still see no units. [15:48] hatch: develop is *also* wrong, i think, but it's less wrong. [15:48] yeah - so do the squares show up and no icon? [15:48] or just nothing? [15:48] (I'm spinning it up atm) [15:49] I THINK the tokens aren't being updated properly and my changes exacerbate the problem [15:50] * rogpeppe grabs a bite to eat [15:50] urulama: IIRC that's what we discussed in London. the behavior of that call should really depend on the goal/where it will be used. the meaning can be either what you propose or "give me all bundles that references (or used to reference) this charm" [15:51] hatch: nothing shows up. [15:51] rogpeppe: how generic do you need this? can you use sort.StringSlice or sort.IntSlice instead of sort.Interface ? [15:51] hatch: no squares, no indication of units at all. [15:51] urulama: I haven't a strong opinion, so if you want I am +1 on changing that [15:53] urulama: so +1 on adding a card. that said, I still feel this is a corner case and we should discourage publishing bundles with revisionless charms [15:55] frankban: let's leave it for now as it is [16:01] frankban: charm-related might need a fix though ... the results contain old revisions of the same charm [16:03] frankban: ah, and that is in both requires and provides ... i'll add a card for that [16:03] urulama: I am not sure that's an error [16:04] urulama: old revisions of the same charm are still related [16:05] frankban: i'm not sure if i'd like to see such results as user. [16:05] urulama: clients can further filter their results, but they can't if we don't provide them [16:06] urulama: if in the spec we state that the api call "returns all charms that are related to the given charm", then not including old revisions can be condusing from the client perspective [16:07] jrwren: i want it like i described, because then it's generally applicable [16:08] frankban: ok, it might make sense if i want to se what other revisions of the same charm have this, true. [16:08] urulama: indeed, we also have a test specifically checking that we return multiple revisions of the same related charm. [16:12] frankban: added this comment in the doc "We currently return all revisions of the same charm as well. Depending on the ranking of the results, we might add a flag "[¬-self=1]" to filter such results." [16:12] so in case top 10 related charms are just revisions most of the time, we might drop them ... [16:13] urulama: perhaps only-latest=1? [16:14] urulama: for what charm are you seeing the same charm to be related? [16:14] haproxy [16:16] and apache2 [16:16] frankban: other charms don't seem to have this, indeed [16:17] urulama: that's because they both require and provide http I guess [16:17] frankban: yes [16:17] urulama: so technically they are related to self [16:17] frankban: and technically it's ok to return themselves :) [16:18] urulama: yeah [16:19] urulama: and I know, relations stuff is horrible ;-) [16:20] frankban: :) [16:20] frankban: as long as we know what to expect and when, all is fine. [16:21] heh parsing relations....oh I remember writing the code for that in the GUI [16:21] I hope they don't ever change the rules because I never want to touch that again [16:22] it's fine for a charm to both require and provide the same interface. it's a bit like a func(int) int [16:22] rogpeppe: sure, it's just a matter what user expects to get from "which are related" ... something we'll measure and correct if needed :) [16:23] urulama: yeah. we could just exclude self from the results if necessary. [16:28] hatch: i've pushed a testfix for my PR, all seems well now if you get time to review. [16:29] i'm grabbing some lunch [16:41] guihelp: anyone else run into this error when setting juju-gui-source? http://pastie.org/private/syp0svijdtezstyc4t9amg [16:41] I seem to get it pretty frequently and today I can't seem to shake it. [16:46] kadams54: look into the logs to see what the error is [16:47] kadams54: are you trying to change the repo on precise? [16:55] jcsackett: I've found a number of issues around dragging units to newly created machine containers [16:55] tbh I'm not entirely sure wth is going on heh [16:55] sometimes the image src is just 'src' [16:55] hatch: on your branch, or QAing mine? [16:55] on develop [16:56] just switching to my branch now [16:56] you can even get into a place where it'll deploy the service but no units [16:56] hatch: yeah, unit icons on tokens are kind of a mess. [16:56] then you can't delete the service, ever [16:56] this is a little frustrating [17:01] jcsackett: ok now I see the issue with my branch vs develop [17:02] what to do, what to do [17:03] urulama, rogpeppe, guihelp: I need two reviews for https://github.com/juju/charmstore/pull/81 (charmstore). no rush and thank you! [17:07] hatch: http://pastie.org/private/ipvckjbsobugmfnmaiw - just seems to indicate the git process died with a non-zero exit code. [17:07] I'm changing the repo on trusty. [17:08] kadams54: what did you set the config to? [17:08] can you paste the line? [17:09] hatch: juju set -e local juju-gui juju-gui-source="https://github.com/juju/juju-gui.git develop" [17:09] try `juju set -e local juju-gui juju-gui-source="develop"` [17:10] there might be an issue in specifying the same repo as the default repo [17:22] So re-running `juju set` doesn't seem to do anything. I don't see any more entries in the log files… how do I force a retry/restart and get it out of the error state? [17:23] kadams54: you have to resolve the issue [17:23] then re-set [17:23] juju resolved juju-gui/0 [17:23] juju set ... [17:23] Ah [17:23] My juju education continues. [17:24] :) [17:24] jcsackett: so I'm proposing that I land my branch as is and then do a follow-up to fix the icons wholesale for the tokens [17:25] they are so broken I really don't know what to do wrt my branch if that's the blocker [17:25] thoughts? [17:30] hatch: works for me. [17:31] marking as so on your PR. [17:33] sounds good thanks [17:41] * rogpeppe is done for the day. finally solved my algorithm problem; i'm still sure there's a nicer solution! [17:41] g'night all [17:42] night rogpeppe [17:42] good luck with the algo :) [17:43] hatch: perhaps you could do better? here's the code: http://play.golang.org/p/paZzZJYZdd [17:44] rogpeppe: what is it supposed to do? [17:47] hatch: order one slice according to the ordering in another [17:47] hatch: i tried to make the comments explanatory, but perhaps not well enough :-) [18:01] haha ok I'll take a look if I get some time [18:14] hatch: Finally was able to get a full real env re-test done on #510. I wasn't able to reproduce the original bug, but I did encounter a new one. Since you shipped that PR, not sure where I should report it? [18:14] kadams54: is it caused by my branch? [18:14] Yes [18:14] Didn't see it on develop [18:15] ok then yep file it on that PR [18:15] er [18:15] post it on the PR [18:18] hatch: Well, never mind. I can't reproduce it consistently. Only happened once in 5 tries. When I autoplaced a unit and then deployed, it flipped back over to an unplaced unit while waiting for juju-core to ack, then on ack (correctly) became a deployed unit on a deployed machine. [18:19] oh that's very odd [18:19] this was on a real env? [18:19] lxc? [18:21] * Makyo -> appointment [18:27] hatch: Yeah, lxc. [18:27] kadams54: that's very interesting, I'm not even sure how that's possible tbh [18:28] I'm fine with dropping it for now, since I can't get it to happen more than once. [18:28] Just something to watch out for [18:28] See if it starts happening more [18:28] yeah definitely - this mv is a mess [18:28] not anyones fault heh [18:28] just been modified and stuff so often [18:29] we'll have to go back and reorg it afterwards [18:29] whee! [18:34] Makyo: (For when you get back) Is PR#508 ready for another look? === urulama is now known as urulama-afk [18:55] jcsackett: +1'd [18:55] kadams54: do you still need another? [18:57] hatch: thanks! [18:57] jujugui: i could use one more review (no qa needed) of https://github.com/juju/juju-gui/pull/505 [19:00] hatch: on #509? Nope. [19:00] kadams54: ok then, lets get it shipped :) [19:01] hatch: Yeah, working on changes right now based on the feedback :-) [19:01] ohhh ok ok [19:01] sorry I thought it was done-done [19:01] Hold your horses [19:01] ;-) [19:01] lol [20:03] guihelp: I have a question about the bug I'm currently working on. Some places in the UI machine constraints are displayed as CPU/memory/architecture. Other places its CPU/memory/disk. Anyone know which it should be? Disk? Arch? Both? [20:10] kadams54: so...this is an artifact from old juju to new juju [20:11] as far as what's correct and what's required [20:11] I have no idea [20:11] kadams54: probably best to send an email to peeps [20:13] cpu-power cpu-cores mem arch tags disk [20:13] I think those are all the ones from core === arosales_ is now known as arosales [20:22] hatch: done [20:30] kadams54: great [20:31] tags are something to do with MAAS btw [20:31] not sure what though heh [21:15] jcsackett: are you going to rebase and ship your branch? [21:15] Makyo: do you need any reviews or anything for your branch? [21:16] hatch, just got back. Yeah, I think I do [21:17] ok looking again [21:18] thx [21:23] Makyo: so is something supposed to happen when I click the button? [21:23] I have mysql, wordpress, relation, extra units, extra machines, extra containers [21:23] when I click the button nothing happens, no errors [21:24] Anything in the ECS should be wiped out. [21:24] Confirming on my end. [21:24] and the deployer bar should update, remove all the stuff from the canvas? [21:24] Correct. [21:24] yeah, nothing is working... lemme try clearing the cache [21:25] Makyo: yeah can you check locally again? updating develop [21:25] because the button clicky no worky [21:26] hatch: i am still waiting for a second review. [21:26] I can add it to the PR but I just want to be sure there isn't something totally weird going on heh [21:26] hatch, I see what happened. Will fix that in a second. [21:26] cool [21:26] Give me two minutes. [21:26] jujugui jcsackett needs one more review (no qa) [21:27] hatch: I'll take a look [21:27] thanks sir [21:31] hatch, pushed [21:31] ok re-testing [21:31] hatch, jcsackett: done with review, looks good. [21:33] Makyo: thanks - all good except one template issue [21:34] kadams54: cool, thanks. [21:36] hatch, yeah, I'm breaking from designs already per kadams54, so it doesn't really make sense there (probably why the designs didn't have it there). I'll see what I can do, I guess. [21:36] Makyo: I meant the message didn't make any sense [21:37] it's saying things will be committed but it's clearing them [21:37] hatch, because you aren't even supposed to be able to clear them at that point. [21:37]