=== jcsackett_ is now known as jcsackett [02:23] morning huwshimi [02:25] :) [02:30] I can haz orange box! :) [02:40] rick_h_: oh really?! In your house? [02:40] huwshimi: yea, jcastro brought one home from his sprint but is taking swap days mon/tues [02:41] so I ran out to steal it for his swap days for GUI MV testing and screenshot/video'ing [02:41] rick_h_: Nice one! [02:41] yea, so busy two days coming up. Have to take it back Tues night [02:44] rick_h_: I thought he lived on the other side of the country? [02:44] well, other end [02:44] huwshimi: no, he's 1.4hrs away from me [02:44] rick_h_: Oh right, nice === uru_ is now known as urulama [06:28] Hi everyone [06:29] First Day :) [06:31] fabrice: Hello! Welcome [06:31] Thanks [06:34] fabrice: You're on urulama's team? [06:34] I suppose [06:35] and you ? [06:35] fabrice: haha, OK, urulama is around so he can probably tell you more [06:35] fabrice: I'm on rick_h_'s team, but the two work very closely. [06:36] hi there fabrice [06:37] yo [06:37] did you manage to get SSO working? [06:38] and have access to mail, wiki, docs? [06:39] no just logging to irc 2 minutes ago I am waiting for vanguard but I said I would start at 9am [06:39] ok, np [06:39] fabrice: when you're up and running, let me know [06:39] fabrice: i'll be jumping in and out today, we have some issues with floods here :) [06:40] urulama: That doesn't sound good! [06:41] huwshimi: no big deal, rain stopped yesterday, but there are some leaks in the basement and at my fathers house as well. [06:41] huwshimi: it's just underground water being to high, luckily we're not near river [06:42] still it doesn sound good [07:21] BTW http://altcoinpress.com/2014/09/irc-freenode-network-hacked/ [07:22] you should probably change your password [08:01] morning urulama, rogpeppe1 [08:01] welcome fabrice! [08:01] morning frankban [08:01] jujugui: fabrice joined today [08:01] frankban: yo! [08:02] frankban: welcome! [08:02] fabrice: ^^^ ;-) [08:02] fabrice: if you want to address all people at once, we use jujugui alias here [08:02] also guihelp [08:03] frankban: thanks ! [08:04] fabrice: mhilton joined 14 days ago, so the process is probably still fresh in his head, you can ask him as well [08:05] welcome fabrice [11:02] morning everyone [11:02] fabrice: welcome to the party [11:02] ! [11:02] rick_h_: yo! [11:03] rick_h_: morning [11:05] hope the boostrapping is going well fabrice [11:05] let us know if you need a hand. [11:05] calender invites coming your way shortly if you're not already on them [11:06] rick_h_: sso sorted, looking at the wikis, and fighting with HP Cloud for mission #1 :) [11:07] fabrice: understood, all good. There's a lot to boot up on. [11:50] * frankban lunches === fabrice is now known as fabrice|lunch [13:07] guihelp: need eyes on https://github.com/juju/juju-gui/pull/548 - it's a pretty small change and should be a quick review/QA. [13:08] fabrice: ping ... hangouts? [13:08] kadams54: rgr looking [13:08] urulama: I am on it [13:08] kadams54: if you get a sec can you peek at frankban's as well for a second review and qa? [13:08] Sure. I'm also looking over huw's stuff. [13:08] kadams54: can you provide some background in that pull request? [13:09] kadams54: I'm not sure what I'm looking at and what it's about [13:09] Sure. [13:09] kadams54: assume it's around the bug 1368650? [13:09] Bug #1368650: adjust date and time is static [13:09] rick_h_: Correct. [13:10] I'm editing the PR to add more context. [13:10] kadams54: cool thanks. Yea some tie in from PR to bug/context is + [13:11] OK, initial comment/description has been fleshed out, so context will be preserved in merge commit. [13:12] kadams54: ty much [13:26] jcsackett: around? [13:26] jcsackett: I need to change to develop on precise, you mention it works with @sha? [13:34] kadams54: thanks for taking a look at my branch [13:34] frankban: yup, np [13:44] rick_h_: yes [13:44] if you do the @sha of a commit, that works on precise. [13:44] jcsackett: so does it need just the sha or the url@sha? [13:44] so just pick the most recent one for develop. [13:44] ok ty [13:44] rick_h_: "https://github.com/name/juju-gui.git @sha" [13:45] ah the space dammit [13:52] rick_h_: did I send an email out last week about the added services sidebar? [13:52] luca: yes [13:52] luca: and I've got it put away atm [13:52] luca: but will break it down later this week [13:53] luca: we had a quick chat on it I think [13:53] rick_h_: ok, I was just looking for it and couldn’t find it in my email so was just wondering hehe [13:53] rick_h_: no worries [13:53] rick_h_: could you tell me what I called the email? lol [13:53] * rick_h_ goes to look [13:54] luca: hmm, not sure. The one I find now is back Aug 13th [13:54] rick_h_: I think I possibly just spoke to you about it but didn’t actually email [13:55] rick_h_: so I’ll email it out now then :) [13:55] luca: ok, I remember seeing two images [13:55] figured they came in email [13:55] rick_h_: yeah, I showed them to you in IRC [13:56] oh, then ok [13:59] guihelp: anyone know where juju logs are stored on OS X? [14:00] kadams54: juju log? [14:00] kadams54: what are you doing/getting a log for? [14:00] kadams54: what logs? local env? [14:00] kadams54: if it's a bootstrap issue add --debug to the bootstrap command [14:00] kadams54: if you're deploying something there's debug-log and unit logs on the unit coming up [14:01] rick_h_, frankban: I've found tailing the logs to be helpful when setting the gui source [14:01] Yeah, the unit logs [14:01] kadams54: so juju debug-log -e ec2 should do the trick [14:02] debug-log reports 'Output from "make distfile" sent to /var/log/juju/make-distfile…' [14:03] kadams54: right so that means it's running the tarball generation/etc [14:03] I'm assuming I'd need to juju ssh -e mytest to see the contents of that log? [14:03] kadams54: right === fabrice is now known as fabrice|coffee [14:03] juju ssh juju-gui/0 [14:04] it's basically a 'be patient' log line [14:04] it takes a bit [14:04] * rick_h_ is waiting at that same line heh [14:08] hatch: around? [14:08] hatch: makyo_ I need a volunteer for a hot orange box bug please [14:10] hatch: makyo_ https://bugs.launchpad.net/juju-gui/+bug/1369576 [14:10] Bug #1369576: juju-gui MV shows subordinate services as unplaced units [14:10] frankban: All done with QA. You're good to go. [14:10] kadams54: thanks! [14:11] rick_h_: I am [14:11] odd though I am not getting dings... [14:11] hatch: please see bug ^ asap please [14:11] hatch: I assume it's a small part of how we identify unplaced units as missing on attribute [14:12] hatch: ping me when you have a fix up please and will qa/land so we can unblock for demo shots/etc [14:12] sure - do we have a running instance I can see? [14:12] hatch: will post a screenshot in a sec, I'm installing a screenshot tool [14:13] oh ok so I'm going to have to fix it blind? haha [14:14] hatch: I list out 4 sub services. Add wordpress and ntp subordinate and see how it shows? [14:14] yup on it [14:14] hatch: I mean if it all works in sandbox then ok, but it's not quite blind [14:15] hatch: https://www.dropbox.com/s/oitc0icdf6oruu9/Selection_001.png?dl=0 [14:16] sandbox does not show the sub in the unplaced units column....spinning up local [14:16] hatch: rgr [14:22] rick_h_: did you get the orangebox at your place? === fabrice|coffee is now known as fabrice [14:23] welcome fabrice [14:23] hatch: thanks ! [14:23] hatch: yes, sitting at it right now [14:23] been working on getting it setup all morning and let the bugs and fun begin [14:24] hatch: http://paste.ubuntu.com/8350773/ is the dump of the services object [14:24] rick_h_: awesome...you take any selfies? rick and oranebox in the car....rick and orange box eating breakfast..... :P [14:24] no, was going to when I get MV up and running do a little pic saying "Tired of looking at juju status...we've got something good coming just for you" [14:24] but then it looks fugly because of these subordinates and I'm in go go go debug mode [14:25] it should be named.....Obey [14:25] * rick_h_ goes on to keep testing stuff [14:26] :) [14:26] ok I think I found where to fix this...just need the real env to test [14:31] rick_h_: new bug https://bugs.launchpad.net/juju-gui/+bug/1369588 [14:32] hatch: rgr, makyo_ can you look? It seems related to your remove relation UX/etc you were doing [14:32] rick_h_: also I cannot reproduce on local....how did you get those ntp units to be unplaced? [14:33] hatch: deployed via the deployer (a bundle) and then I simply loaded the page [14:33] hmm ok lemme see if I have to deploy them [14:35] oh geeze deploying the ghost relation didnd't work [14:35] and then making the relationi post deploy locked up the gui... [14:35] jcsackett: going to file this new bug your way. sorry but want to shake these orangebox bugs out while I've got it today/tmorrow [14:35] jcsackett: guessing there's a missed event stopper in the drop there [14:36] rick_h_: this subordinate thing? [14:36] jcsackett: no, different one [14:37] jujugui where is the gui source located on the instance again? /me can't remember [14:38] rick_h_: link? [14:38] hatch: /var/lib/juju-gui/juju-gui IIRC [14:38] thx [14:39] jcsackett: https://bugs.launchpad.net/juju-gui/+bug/1369593 [14:40] rick_h_: i see. i'll check if i can reproduce on a non orangebox live env; otherwise this could be a fun one. [14:40] jcsackett: yes, please check locally, or check ec2 [14:40] jcsackett: I think ec2 should be similar [14:40] * jcsackett nods [14:44] kadams54: one for your next card please https://bugs.launchpad.net/juju-gui/+bug/1369601 [14:44] rick_h_: rgr [14:44] blarg I can't even create a relation between a service and a subordinate.... rick_h_ this is going to take a bit longer than expected [14:44] hatch: understood [14:45] juju-info relation added between wordpress and wordpress [14:45] *facepalm* [14:45] hatch: can you not create it in the cli or the gui or both? [14:47] yeah via the cli works [14:48] but I still don't get unplaced units [14:48] maybe it has to be done via a bundle... [14:49] rick_h_: stupid q but there are no errors in the console right? [14:50] console is disabled [14:50] jujugui call in 10 [14:50] hatch: nothing I can tell atm [14:50] rick_h_: ok np....there are a few things I can try still then I'll have to put together a bundle and try that [14:50] ahah I got it [14:51] hatch: :/ ok but really you can't relate a subordinate via cli? [14:51] w00t [14:51] well I can reproduce it [14:51] hatch: yay [14:51] ish [14:51] no I can create the sub relation via the cli...cannot via the gui [14:51] will create a new bug [14:51] for that [14:51] apparently we didn't test subordinates [14:51] haha [14:51] yea, we never do :/ [14:52] but it's blocking me getting a single screenshot of the real stuff here so guess it's time to look [14:54] https://bugs.launchpad.net/juju-gui/+bug/1369606 [14:58] jujugui call in 1 go time [14:59] kadams54: ^ [15:00] frankban: ^ [15:00] fabrice: the hangout url is in teh calendar item [15:00] yep coming [15:20] * makyo_ steps out for a few === makyo_ is now known as Makyo [15:20] rick_h_: what about cloudfoundry demo? i remember ben talking about CF bundle [15:21] rick_h_: just to confirm - we never want to show ubordinates in the mv? [15:21] urulama: ME FIRST!! [15:21] * urulama hides :D [15:21] haha [15:21] rick_h_: I'm not able to reproduce https://bugs.launchpad.net/juju-gui/+bug/1369601 - tried both locally and on ec2 [15:21] * hatch_ got no sleep last night....someone kept texting me last night to "go smoke a dub" [15:22] blocked number....wouldn't stop texting [15:22] hatch_: no do not disturb feature on your phone? [15:22] kadams54: I needed the alarm to still go off in the morning [15:23] iPhone's doesn't prevent alarm from going off, just prevents others from contacting via phone or text. [15:23] but I haven't set up the 'important' people for dnd either...I shoud probably do that [15:23] kadams54: tbh I have no idea...I've never used it...I just assumed [15:24] hatch_: my dnd turns off at 7 AM. Alarm goes off at 6:51 AM :-) [15:24] haha nice... so can you set 'important' people for the dnd? [15:26] urulama: oh hmm, will see if that's on here [15:26] hatch_: rgr [15:26] hatch_: they're kind of nutty as they're on every instance and so we agreed (for now) that subordinates aren't on mv [15:26] kadams54: k, looking at what i did again [15:26] ok sounds good [15:28] kadams54: hmm, yea does it every time. duplicated it in the sandbox on comingsono [15:28] kadams54: jump back in standup? [15:28] rick_h_: sure [15:33] jujgui are you supposed to be able to destroy a machine with services on it? [15:35] rick_h_: I think you can destroy an uncommitted one and then the services go back to being unplaced units. Seems like JC worked on that card awhile back. Not sure about uncommitted. [15:36] yea, this is a committed/running machine. Working backwards, first unit, then container see if I can get to machihne [15:36] Wow, we have both token-container.[js|handlebars] and container-token.[js|handlebars] [15:37] lol but of course [15:39] rick_h_: if you have deployed services then you have to remove the services first before destroying the machine [15:39] we don't have a --force enabled in the GUI [15:39] ok yea, you have to remove the units, and then the containers, and then the machine [15:40] rick_h_: do we want to show subordinates in the machine/container columns? atm subordinates don't have their machines set [15:40] hatch_: no, I don't think we show them in either location [15:41] going to care of family now, hopefully come back this evening tty soon [15:41] hatch_: for MV, subordinates don't show atm and we can address it post-release if it turns into an issue [15:41] rick_h_: ok np I'm just trying to pick the best place to fix this [15:42] hatch_: understood [15:46] * rick_h_ goes to the dr apt biab [15:47] ok so the real issue (5 whys) is that the unit doenst get it's subordinate status set [15:48] * hatch_ is just talking outloud [16:01] jujugui is it ever possible to have a machine that's got a different committed/uncommitted state than its root container? [16:01] kadams54: i don't think so. [16:01] the root container *is* the machine. [16:01] jcsackett: sure doesn't seem like it ought to be [16:01] OK, I'm going to go ahead and assume that's true and leave a comment in the code: "jcsackett said this was OK" [16:02] * jcsackett laughs [16:05] kadams54: the root container doesn't exist...just like jcsackett said :) [16:11] guihelp: https://github.com/juju/juju-gui/pull/552 is ready for QA and review <-- I think this is an orange box one? [16:25] frankban: so when the units delta comes in ntp's service shows it as NOT being a subordinate...but then the GUI shows it as a subordinate...do you know if services subordinate statuses are updated after the initial services delta? [16:27] hatch_: service info is updated each time something changes, I can take a look at juju-core to check whether the subordinate flag is sent later, but I'd guess you already know the answer [16:28] yeah...so this is kind of a problem heh [16:28] but I guess I can add something in the handler to go through it's units to mark them as subordinates [16:28] odd that it's not send originally [16:28] because a service can't ever change from a subordinate [16:31] ahh when the service is created it doesn't send us the information [16:31] and we don't have the charm information yet either [16:38] jujugui quick review/qa on asterisks in inspector: https://github.com/juju/juju-gui/pull/547 [16:39] heading out for a run, bbiab [16:47] frankban: would you be able to take a look to see if we could get the services subordinate status when we get the data? It looks like the only way we know about it is because we compare against the charm [16:48] I'm guessing there is a reason why this information was missing though... [16:48] hatch_: taking a look at the code [16:50] thanks - I'm assuming this because there isn't a single ws frame with the subordinate status in it [16:52] hatch_: I confirm the is_subordinate info is not included in serviceInfo. also unitInfo does not have that information. I guess that's because the is_subordinate is actually an attribute on the charm, rather than the service [16:52] yeah....see I can easily fix this bug by doing cross db queries....but that just feels wrong when we should really have this information available on the unit [16:53] ok np thanks for looking, I'll keep on trying to find the best place to add this info [16:57] hatch_: np, FWIW the service has a charmUrl, and it should not be hard in theory to add the information you need in _setDefaultsAndCalculatedValues [16:58] frankban: at that point we don't have the charm info yet [16:58] heh [16:59] it's an unfortunate sequence of events it seems [17:04] hatch_: oh, so we need to know if a unit is from a subordinate charm, in the machine view, but we call charmInfo only when the charm is displayed in the inspector, something like that? [17:10] frankban: well I haven't ironed out the exact sequence of events but when mv is rendered the units do not have subordinate information but the services do [17:10] so I'm trying to find where the services get updated with that information [17:10] but not having much luck [17:13] frankban: if you know where that happens I'm totally open for input haha [17:15] hatch_: I suppose models/charms.js? [17:15] right i just can't find where it updates the service [17:15] np I'll find it [17:15] :) [17:16] it's in these 100k lines somewhere :) [17:19] :-) [17:20] hatch_: I am looking as well, and it's really not clear when and above all IF the "subordinate" service attr is set === hazmat` is now known as hazmat [17:34] frankban: exactly - it appears to be done as a side effect somewhere heh [17:36] hatch_: surely it is set when a ghost service is created [17:36] frankban: but the ghost service isn't created when it comes over the delta [17:40] hatch_: it seems something happens when handling endpoints in store/endpoints.js [17:40] hatch_: done for the day, good luck and have a nice evening! [17:41] thanks you too, cya tommorow [17:44] Why is it that I never see any API requests on my sandbox in web inspector? I would expect to see some WebSockets requests to go through… (Note that this is in Chrome Canary.) [17:44] Does the fakeenv prevent that? [17:51] kadams54: I'm not sure I understand [17:51] sandbox simulates juju [17:51] so it doesn't need to make any reqyests [17:52] OK, sorry, for some reason I had it in my head that fakebackend.js was running in Node on the server, but it looks like it runs in the client instead. [17:52] ohh....yeah we only use node for devtools [17:53] the guiserver backend is python [17:53] You're talking about in a real env, right? [17:54] yeah [17:54] on jujucharms for example it's 100% client side [17:55] and for being single threaded still scales to thousands of units :) [18:26] jujugui back andd all [18:26] kadams54: comment on your pr but looks good thanks for the update [18:26] rick_h_: I'm still working on the fix for the bug - getting closer [18:26] hatch_: awesome [18:27] it can be fixed trivially - but a real fix goes all the way back to delta parsing [18:27] so the real fix takes more time :) [18:27] hatch_: hmm, do we need to have a chat on it then? [18:27] hatch_: I need a 'visible' fix today if we can get a hack up [18:28] sure standup? [18:51] rick_h_: the mass scale up UI in mv shows that you can add extra units for subordinates....do we have a bug for this already? I thought we did but I can't find it [18:51] hatch_: good call, will add one [18:52] going to file a drive by in there as well. I think it should be alphabetical. I don't recall why we didn't [19:00] kadams54: go ahead and ship your branch and I'll do qa when I update the gui here in a few [19:01] rick_h_: trying to figure out the CI test failure [19:01] kadams54: ah cool [19:02] somehow I managed to bork the xy annotations in my env making it so that the GUI will no longer render stuff [19:03] wheeee [19:03] {"Type":"Client","Request":"SetAnnotations","Params":{"Tag":"service-wordpress","Pairs":{"gui-x":"NaN","gui-y":"NaN"}},"RequestId":15} [19:04] not sure how to recover from this besides destroy the whole env? [19:04] set it? [19:04] oh, or you mean if that's there it won't place at all? [19:04] I can set annotations? [19:04] yeah the gui just throws errors so nothing gets rendered to the canvas [19:05] guess this is another bug...it should fail gracefully heh [19:05] yea [19:06] need some steps to reproduce before we can file it though [19:07] ssh into box, open js file, create syntax error in juuuuust the right spot [19:07] :) [19:07] lol [19:07] crap oh well tearing down... [19:07] ok then we can leave that as a low thing to fix one day [19:10] rick_h_: I need to grab some lunch - here is the patch if you'd like to give it a go https://gist.github.com/hatched/daab82c9b132f38ed406 [19:11] hatch_: can you push it into a branch I can set in the gui? [19:11] should work for switching from service to mv and loading right into mv [19:11] oh sure [19:11] hatch_: rgr [19:12] rick_h_: https://github.com/juju/juju-gui/pull/554 [19:12] rick_h_: https://github.com/hatched/juju-gui.git sub-unplaced-1369576 [19:13] it busted when I was doing the qa so I am not 100% sure but should work for the photos :) [19:13] will finish it up as soon as I get back....just starving [19:13] haha [19:17] rick_h_: got the test failure straightened out and shipping. [19:17] rick_h_: FYI, I also have a time off request heading your way soon. [19:20] kadams54: awesome ty [19:45] hey rick_h_ did that fix get you going? [19:50] otp atm [20:11] rick_h_: have you tried orangebox with the trusty charm, or just precise? [20:11] jcsackett: it's only precise because that's what it runs atm [20:12] rick_h_: dig; i reproduced on precise, was working on the bug with root containers. switch to a deployment with the trusty charm b/c it's easier to work with branches, and discovered (at least on ec2) you can't drop at all. [20:13] (at least in google-chrome) [20:13] jcsackett: hmm, that's odd that they're diff [20:13] rick_h_: i concur. i haven't dug into that occurence yet, but made a note to look further into it when i'm done with this bug. [20:13] for now i'll work with sha1s on precise. [20:17] jcsackett: what bug r u working on? [20:17] hatch_: https://bugs.launchpad.net/juju-gui/+bug/1369593 [20:17] Bug #1369593: dropping an unplaced unit on the root container of a new machine in MV reloads the page [20:18] interesting - I've never had that happen [20:18] nor not being able to drop [20:20] hatch_: real env only. [20:21] hatch_: if you have a real env running the trusty gui charm, i would love to see if it's reproducible. [20:21] (ec2, to be the same setup) [20:21] sorry I don't atm but will soon [20:21] local though [20:43] jcsackett: in local I can't even drop on the root container if i'ts uncommitted [20:43] heh [20:43] no error [20:43] hatch_: on trusty? [20:43] yup; [20:43] yeah, that's what i saw too. [20:43] they're not droppable at all in develop now. no idea why. [20:43] hatch_: is a container? [20:43] I recall seeing a bug around this - it's because we disabled dropping to create containers when not on maas [20:43] or is drag-and-drop broken across everything. [20:43] aaaah. [20:43] so I'm guessing it's because of that [20:44] can you drop on the machine token? [20:44] trying [20:44] nope but I can drop on the machine header [20:45] hrm. so it's not precise/trusty. it's a commit that's landed in the last day. [20:45] because i've now updated and on precise i'm seeing the same behavior. [20:45] well I'm going to get back to working on my fix [20:45] rick_h_: ^ i'm going to pursue this b/c it now blocks the bug you filed. [20:45] lemme know if you need another test dummy [20:45] jcsackett: rgr [20:45] hatch_: will do. [20:46] man I wish it was faster to pull down and switch branches heh [20:48] hatch_: +1 [20:49] there must be a way to fetch a diff from what's in the charm and what you want to fetch then run the build [20:49] in theory that would only take a couple mins at most [20:49] (assuming it's possible) [20:55] so, i'm seeing a note that "we don't allow hulk smash" now in the machine view's set droppable code. is that accurate? [20:55] rick_h_, hatch_ ^ [20:55] doesn't sound right. [20:55] jcsackett: originally yes [20:55] but I think we did a 180 on that [20:56] yea, 180, we do allow it [20:56] hm. the comment git blames from earlier this month, but i suppose it may have just been moved around. [20:57] jcsackett: yeah I wish (maybe there is) a way to get a history of blames heh [20:57] ok, so yeah, this is just a case that if containers aren't allowed, none of the machine tokens are made drop-able; the root container token should still be a drop target though. [20:58] jcsackett: agreed [21:02]