[00:12] huwshimi: https://github.com/juju/juju-gui/pull/550 +1 [00:12] hatch: Thanks! [00:14] huw #549 will conflict with develop [00:14] you'll want to rebase [00:14] maybe do that then I'll finish the review [00:14] morning huwshimi [00:16] hatch: OK no problems [00:16] rick_h_: Hey [00:17] huwshimi: have you moved into the garage yet? [00:17] your office I mean ;) [00:18] hatch: Not yet, might not be till after our next trip [00:19] ahh [00:19] hatch: are you the only one that does that curly style? [00:19] :) [00:20] lol I would like to think that others do too :) [00:20] you do some funnyness with the curlies [00:20] elses on a new line [00:20] smushing them into the contents [00:20] that's like two extremes [00:22] hatch: Well, if you're the only one doing it we should pick a style... [00:23] huwshimi: look how well picking a commenting style worked out [00:23] ;) [00:24] yea, let's have that one again :P [00:24] haha [00:24] * rick_h_ /me ls [00:24] lsbah [00:24] bah [00:24] lag [00:24] hatch: This is why I've gone with the majority style [00:24] * rick_h_ sets up script to throw angry email anyone uses two spaces, doesn't start a comment line with a *, or uses function(e) [00:25] haha [00:25] huwshimi: you can leave it as is - if it passes the linter that's fine by me [00:25] rick_h_: If you care about those things you should let us know, at the moment it's arbitrary on who does the review [00:25] can be frustrating [00:26] huwshimi: really it's implementers choice if it passes lint [00:26] so you can tell us reviwers to go stuff it [00:26] :D [00:26] haha [00:26] hatch: Also I rebased and didn't hit a conflict [00:26] really....odd I changed some of the exact same lines lol [00:26] huwshimi: yea, but it's stuff I'm passionate about that I argued for when I joined the team but was out voted. I don't want to force 'rick's way' as lead [00:26] ok :) [00:27] I just rant quietly on the inside :P [00:27] hehe [00:27] basically I disagree with every one of those things rick_h_ just posted too lol [00:27] I guess that's why they invented gofmt [00:28] yea, watch out the first time i have to write go code [00:29] go fmt will lock up trying to fix everything [00:29] lol [00:29] stack overflow [00:29] there will be a nuclear cleanup about an hour north of detroit [00:29] lol [00:30] 'melt down caused by gofmt and a developers opinions" [00:30] for what it's worth I also don't like gofmt [00:32] wtf, are we string sorting machine names? [00:32] 0 - 1 - 10 [00:32] 2 - 3 - 4- [00:33] hmm, this is tricky though, once we allow naming the machines we'll have to support names. :/ [00:33] Probably, they are strings :) [00:35] huwshimi: filed a bug and aded to the board if you get looking for something else to poke at. I think you did some of the sorting code? [00:35] rick_h_: Yeah, it's my fault :) [00:35] huwshimi: all good, you're right that they're strings [00:36] it just feels very unnatural currently in practice [00:36] yeah [00:36] oo huwshimi is gona have to write an alphanumeric sorting algorithm [00:36] I'm sure there are some on the googles which you can use for inspiration [00:37] hatch: That's funny I'm pretty sure the card has your head on it [00:37] lol [00:37] is 549 updated and ready? [00:38] bah, walk the list, try to parse the int, if you can...then set it as an attribute [00:38] get to the end of the list and find they all parsed, then sort on the new attribute vs the name [00:38] done [00:38] one iteration through the list, one parseInt on xxx machine names [00:38] not sure that will work for things like 1-foo 10-bar style names [00:39] that's a string, sort it stringy then [00:39] I suppose [00:39] I just want to get pure numbers vs words right for now [00:39] I think people will do apache-1 and apache-2 vs 2-apache 1-apache [00:39] anyway, but we can tell about that later [00:40] true [00:41] hatch: I've pushed up the rebased version of that branch, no changes to my code though [00:41] ok, tested jc's branch, now reloading onto latest trunk [00:43] switching branches is a LOT faster after the first change [00:43] guess all the work is in the deps/etc required [00:46] huwshimi: review done - a few comments around the events [00:46] hatch: much nicer ty [00:47] hatch: I'm hesitant to mark the bug fix committed though as we want to get a better fix? [00:47] rick_h_: oh I suppose... [00:47] rick_h_: be sure to pick a machine with a bunch of containers to try and fill up that third column a bit :) [00:48] hatch: Ah thanks, I was wondering if we could do something like that, much better! [00:48] hatch: hah [00:49] hatch: I was thinking of trying to see if I could do the ghost blog and show 3 services, and click into machine view and see 10 machines of 10 container's each with a ghost blog :) [00:49] hatch: kind of to show that sometimes service view is the clean summary of things and sometimes machine view is the more clear view [00:49] huwshimi: yup as long as all the tokens have their bubble targets set to the mv....so just keep an eye that anywhere the token is created it has `token.addTarget(this)` assuming the token is being created in the mv [00:50] hatch: Ah right, that makes sense [00:50] rick_h_: haha I'm not sure why each machine would have multiple containers of the same service [00:51] huwshimi: I also think addTarget is idempotent but best not to repeat it just to be safe [00:51] hatch: well you can run 10 ghost nodejs instances on one hardware machine [00:52] imagine it's a 6core or something [00:53] rick_h_: ahh I didn't think of that [00:53] yeah I don't think it does multi core by default [00:53] yep [00:54] does lxc do cpu locking? [00:54] or would this be a openstack thing [00:55] I would assume lxc would just share resources so the provisioning must be done with something else [00:56] oh i think kvm does that [00:56] * hatch is just rambling now [00:57] hatch: Changes pushed [00:58] thx [00:58] doesn't appear to be picked up in github though [00:59] uh, somehow it pushed it to my develop [01:00] hatch: next part of your bug [01:00] hatch: when I hit commit, in the summary it says "You ahve 23 unplaced units, do you want to: ..." [01:01] oh poo [01:02] hatch: added a new card for tomorrow [01:03] but got a bunch of great screenshots [01:03] excellent I definitely want to check em out [01:03] so can move forward a little bit but can't go through summary/commit process yet [01:03] so blocker on any video work [01:07] yeah ok I'll jump on that first thing [01:13] hatch: OK, fixed all the weirdness, changes are up [01:14] hatch: got a sec to chat? [01:29] rick_h_: actually just making supper [01:29] gona be around in an hour? [01:30] hatch: all good, we can sync tomorrow [01:30] cool [01:30] huwshimi: I'll also finish up your review in an hourish [01:30] hatch: No problems, no hurry [01:31] hatch: sent the screenshot link [01:31] my middle-click stopped working all of a sudden wtf [01:53] jujugui kind of cool per [01:53] per [01:53] bah [01:56] jujugui https://plus.google.com/116120911388966791792/posts/dR3zqM6E66B kind of cool [01:59] rick_h_: Any idea why the hardware details are not available? [01:59] huwshimi: no :/ [01:59] good point, I need to look into that one next. I wonder if it's because of maas or something [01:59] rick_h_: Have you ever seen hardware details? [02:00] like on ec2 or anything at all? [02:00] * rick_h_ thinks so but would have to double check [02:00] yea, the hardware inf ois all set to undefined in there [02:01] I have a feeling we've broken something [02:01] yea, I can't get the websocket data here in FF, will have to test it out in chrome. [02:01] * rick_h_ adds another card [02:10] huwshimi: ok, so we're not getting any constraint info in the service info. We need to see if there's a way to just get the hardware info on the machine instead [02:11] oh hmm, yea there's a delta that has empty hardwareCharacteristics so not sure what we could do about it [02:17] huwshimi: ok, verified there was a bug to update juju to show that hardware data: https://bugs.launchpad.net/juju-core/+bug/1193998 [02:17] Bug #1193998: maas provider doesn't return hardware characteristics of started instances

[02:17] huwshimi: but the orange box is on 1.18 and doesn't have the fix [02:17] hmm [02:25] rick_h_: huwshimi if you load the env with the service view selected then it has the machine info [02:25] if you load with the mv then it doesnt [02:26] hatch: my issue is the maas bug though [02:26] hatch: verified it's getting backported today but will be in the next release [02:26] ohh so this is in addition to the other bug heh [02:26] hatch: so just no hardware info for maas atm [02:26] hatch: right [02:26] this is a juju bug [02:26] man it's all creepy crawly in here lately :) [02:26] creepy crawly? [02:26] oh buggy :P [02:27] huwshimi: if you get a min can you review/qa https://github.com/juju/juju-gui/pull/548 please? [02:27] and if it's cool go ahead and shipit [02:30] haha yeah [02:33] rick_h_: The fix in that branch also fixes an issue I have in my current branch, expect for deployed services [02:33] rick_h_: shipped it [02:33] huwshimi: awesome thanks for looking [02:33] np [02:36] huwshimi: review done, +1 with some minor stuff [02:38] hatch: Thanks [02:39] ok, time for me to head out for the night [02:39] huwshimi: feel free to land after your updates [02:39] yup mee too [02:39] hatch: Thanks [02:39] night all [02:39] hatch: get out of here, need you fresh for the deploy stage bug tomorrow :P [02:39] rick_h_, hatch: night === uru_ is now known as urulama [07:18] good morning ! [07:22] fabrice: Morning [07:24] huwshimi, morning :) [07:24] ant__: Good morning! [07:24] huwshimi, how's it going? [07:24] ant__: Good thanks. Yourself> [07:24] *? [07:25] morning [07:25] huwshimi, all good this end thanks [07:25] ant__: How long before you head on leave? [07:26] well, approximately :) [07:26] huwshimi, im off on the 24th [07:26] only for 2 weeks though [07:26] still have lots of hols left [07:27] ant__: Ah ok, very soon! [07:28] huwshimi, yeah b-day soon :/ [07:59] Night all [09:28] rogpeppe1: morning, could you please take a look at https://github.com/juju/juju/pull/768 ? [09:34] frankban: looking [09:34] thanks [09:39] frankban: i'm afraid i'm not qualified to review API implementation changes any more [09:40] frankban: it seems reasonable to me, but perhaps it needs a new API version or something [09:40] rogpeppe1: it's not backward incompatible, it's just about adding an additional field, but I see your point, I'll ask in #juju-dev [09:48] frankban: i'd say it does need a new API version. just not sure if core is on them already [09:55] urulama, frankban: if they're doing semantic versions, i guess it would be a minor version increase [09:56] hmm, weird. my camera seems to have started working again. [09:57] rogpeppe1: no updates or any changes? [09:57] urulama: nope, none of the above [09:57] interesting :) [09:57] urulama: hurrah for modern software [10:01] rogpeppe1: it does not seem they are using semantic versioning. AFAICT facades only have a major version number [10:01] frankban: i have a vague recollection of that too [10:01] frankban: i don't know what they intend to do about backwardly compatible changes then [10:02] rogpeppe1: yeah, I'll see that in review. FWIW, I see stuff like common.RegisterFacade( [10:02] "AllWatcher", 0, newClientAllWatcher, [10:02] reflect.TypeOf((*srvClientAllWatcher)(nil)), [10:02] ) [10:02] where 0 is the version [11:11] morning [11:12] frankban: <3 thanks for that update to core [11:12] it'll make our life a lot easier eventually [11:12] rick_h_: yeah, that's the idea :-) [11:13] urulama, rogpeppe1: FYI, core api version must be increased when introducing backward incompatible changes. so apparently the logic is the same as in gopkg versions [11:14] frankban: thanks. i suspected that, as it makes sense [11:15] frankban: unfortunately that gives no way for a client to know if it's talking to an API with a given feature or not [11:16] frankban: i guess it can look to see if the Subordinate field exists in the response [11:16] rogpeppe1: yes, I guess that's the way to go [11:17] rick_h_: morning !? no it's time for lunch [11:17] fabrice: :) === fabrice is now known as fabrice|lunch [11:17] fabrice: hey, still trying to put breakfast together, quit rushing me :P [11:30] * rick_h_ steps away to take boy to day care === fabrice|lunch is now known as fabrice [11:42] rick_h_: I am finished with lunch :) [11:45] rick_h_: but I am not rushing you [11:54] * frankban lunches [13:32] jujugui can I get a second review/qa of jcsackett's bundle work please? I'd like to test it and see if we can get a demo together for things [13:36] frankban: can you peek please? ^ https://github.com/juju/juju-gui/pull/553 [13:37] rick_h_: sure [13:37] frankban: ty much [13:38] * rick_h_ needs to start later. Feels like forever before everyone starts the day heh [13:38] rick_h_: do we still have permission to go over the WIP limits on MV? [13:39] jcsackett: I'm trying ot make room, if you can help move forward a review I'd prefer that first please [13:39] rick_h_: sure. [13:39] jcsackett: but yes, permission granted [13:39] frankban: you card in coding you got reviewed/landed? [13:39] ah no, that's a different one nvm [13:40] jujugui: in addition to the one rick_h_ just pinged with, i need reviews/qa on https://github.com/juju/juju-gui/pull/556 (it's a short one) [13:40] jcsackett: looking [13:40] rick_h_: thanks. [13:41] jcsackett: I can take a look at both [13:42] kadams54: i think frankban is looking at the first one, so just the https://github.com/juju/juju-gui/pull/556 needs it. [13:42] kk [13:56] jcsackett: can I talk you into swapping cards with your head on them there? The sorting I talked to huw about next up for him last night as he did the original sort [13:57] rick_h_: oh, sure. meant to take my head off of that one. [13:57] jcsackett: the one about the change notifications not showing in the footer would be a really nice one to figure out, probably a simple git bisect as it recently broke [13:57] jcsackett: ty [14:27] jcsackett: just to clarify, I should only be able to drag-n-drop onto the root container of undeployed machines, right? [14:27] kadams54: in an environment that doesn't support containers, correct; only the root container should be droppable. [14:31] jcsackett: Alright, QA is good on #556 [14:31] kadams54: awesome, thanks. [14:34] rick_h_: any cards I should be looking at? The one I'm working on right now only impacts sandboxes. [14:39] kadams54: i think i misunderstood earlier--you weren't able to drop units onto a deployed root container? [14:39] Correct [14:40] jcsackett: kadams54 So I can now use the GUI to drop multiple units on a single container in mv? [14:40] Well, belay that. [14:40] pretty sure we are supposed to allow that...i don't recall that not working for me in the branch before. [14:41] kadams54: ok, belaying...you double checking that, or did i misstate something...? [14:41] I'm double checking [14:42] Alright, I'm not sure what I did the first time around, but the last two times I've tried, I was able to deploy to a committed root container. [14:43] QA comments updated. Breathe easy, jcsackett :-) [14:43] kadams54: hooray! [14:43] :) [14:44] excellent [14:44] not being able to do that really irritated me while doing some ghost tests [14:48] kadams54: looking [14:49] https://bugs.launchpad.net/juju-gui/+bug/1368588 [14:49] Bug #1368588: Unplaced units show up in changelog and make the "Commit" button active [14:49] kadams54: ^ would be good I think as that would effect demo [14:49] k [14:49] kadams54: though see if you can reproduce in a live env first. Huw found that and I know there's a bug with the chagnes not showing at all now [14:49] will do [14:49] ty [14:50] jujugui call in 10 [14:50] hatch: Makyo if you guys are free can we meet now in there to chat demo/blog stuff [14:50] jujugui anyone else is welcome to join [14:51] yup joining [14:51] hah, standing desk motor is working a bit harder with the orangebox on the desk [14:55] frankban: apologies, i was pushing another branch and i just accidentally updated the branch you're reviewing. [14:56] jcsackett: np, I can wait [14:57] frankban: well, i won't update anymore until your review is done--what got pushed only addressed comments from rick_h_. [14:57] jcsackett: ah, ok, no problem then, thanks [14:57] jcsackett: where is your card for this task? [14:57] frankban: i was insufficiently specific about branches to push and updated *all* of my active branches. [14:58] in the review lane; it was briefly in landing as i grabbed the wrong card. [14:58] yay (poorly) juggling multiple cards. [14:58] jcsackett: cool, my name is already there [15:00] jujugui call time [15:00] ant__: jcsackett frankban & [15:00] fabrice: ^ [15:21] jcsackett: reviewed [15:23] frankban: thanks! fixing up the code now. [15:23] Makyo: i've reviewed and qa'ed your asterisks branch--looks like rick_h_ was the other reviewer there, so i updated your card tags as well. [15:24] Cool, thanks jcsackett [15:37] * rick_h_ runs to appointment [15:37] biab [15:51] hatch_: where is the temporary work around for subordinates in trunk? [15:57] frankban: in the initializer for the machine view p;anel.js [15:58] it checks each units service if it's set to a subordinate [16:00] hatch_: and it can or cannot work right? [16:01] frankban: it works as long as you don't visit a /mv url directly...If you go from the service view to the mv then it works as expected [16:02] but if you visit the /mv directly the services charm data hasn't loaded yet by the time the token is rendered [16:02] hatch_: ok, so this will continue to be the best guess with old version of juju [16:04] frankban: yeah, not much we can do atm without refactoring the loading/rendering cycle of the mv [16:05] hatch_: ack [16:06] hatch_: can you confirm we don't want to show the scale up view in the inspector for subordinates? [16:06] correct [16:06] you cannot scale subordinates [16:06] hatch_: cool, I am refactoring that part too [16:07] rick_h_: when you get back, we should chat. [16:11] frankban: awesome [16:11] thanks [16:25] lunching [16:32] frankban: i've pushed up changes. do you still have the setup for your QA issue? i believe it is resolved by the db.units.filterByMachine thing. [16:33] jcsackett: I don't have that set up, but I can check again. I'll take a look ASAP. [16:40] jcsackett: on a real env, trying to export a bundle I still get "Uncaught TypeError: Cannot read property 'service' of undefined " [16:43] jcsackett: it might be a red herring, but what happens at line 1929 if the machine does not include any units? [16:45] frankban: good catch; it should abort if a machine has no units. [16:45] jcsackett: yeah, I guess the error I encountered depends on that [16:45] actually, it should just filter machines with no units. [16:46] ok, that's a quick fix. [16:46] i misread your earlier qa error. [16:47] jcsackett: could you please also add a test for existing machine without units, that's a quite common scenario (especially on local envs machine 0) [16:47] frankban: yeah, i'll need to update the "filters machines" test for this. [17:02] frankban: pushed. [17:03] jcsackett: I;ll reswitch and check again asap [17:03] thanks. [17:05] juju gui lf review and qa for an orangebox bug https://github.com/juju/juju-gui/pull/557 [17:14] kadams54: back [17:15] rick_h_: want to qa my branch on Obey? [17:15] Obee [17:15] yeah....Obee [17:16] rick_h_: After looking at https://bugs.launchpad.net/juju-gui/+bug/1368588 I don't think it's a valid bug [17:16] Bug #1368588: Unplaced units show up in changelog and make the "Commit" button active [17:16] kadams54: looking [17:16] Either that, or I wasn't able to reproduce what Huw was seeing. [17:17] kadams54: will try to qa here in a live env [17:17] kadams54: I believe the bug he was mentioning was fixed.....but I'm not sure by the report heh [17:17] I see the behavior he describes, but it's how things are supposed to work now that we're not placing units by default. [17:18] kadams54: ok, so I think the bug here is more of workflow. We default to checking 'leave unplaced' and so the user can hit 'commit->comfirm' pretty easily and nothing appears to happen [17:19] kadams54: so I would ask if we should default to 'leave unplaced' or not default to any value and force the user to check one or the other before hitting confirm [17:19] kadams54: what are your thoughts? [17:20] rick_h_: I like the default we have right now, but mostly because it's very convenient for me :-) [17:20] kadams54: well, let's put ourselves in the shoes of users :) [17:20] I like the default we have now because it's the cheapest option for the user if they misclick [17:20] heh [17:20] kadams54: I can toss it to luca and UX and get their feedback [17:20] It's also hard because I implemented that, so I have a big blind spot. It would be interesting to talk to Huw and get his impressions, esp. since he wasn't a part of any of the discussions around that. [17:21] hatch_: right, but they couldn't mis-click. They'd have to select one or the other if we make it selected [17:21] kadams54: understood [17:21] kadams54: ok, put that card in 'needs specification' and we'll do some follow up work on the best interaction for users there [17:21] Technically, something *does* happen… the service gets deployed. You just can't see it in machine view. [17:22] kadams54: right, I understand [17:22] guihelp: I need reviews/QA for https://github.com/juju/juju-gui/pull/558 . no rush [17:23] rick_h_: Anything else that's a higher priority than my happens-in-sandbox-only card? [17:23] kadams54: any of the three destroy cards [17:23] kadams54: I'd suggest looking at all three to make sure there's not a common theme/overlap while investigating [17:24] will do [17:24] I kinda wonder if they might all be sandbox-only bugs… [17:25] kadams54: good info to find out for sure [17:26] although when huw found these, I had specifically asked him to QA on ec2 and azure [17:26] kadams54: so not sure they'll be sandbox only thing [17:26] things [17:26] ywah the description isn't really complete [17:26] hatch_: k, looking at your branch [17:26] coooooo [17:27] rick_h_: we could also fix these unplaced units issues by 'placing' subordinate services....but then of course they will show up in the mv....whiiiiiiiich I kind of agree with but not really sure [17:27] hatch_: understood [17:28] hatch_: I think this is defintiely an experiment. I expect we'll have some feedback and debate on the subordinate thing [17:28] rick_h_: are there any more bugs that are critical? [17:29] hatch_: no, I think the rest are just bugs we can avoid in any marketing material [17:29] ok cool I'll hop back on my previous card [17:29] ty [17:29] try and get that thing finally landed heh [17:31] jcsackett: LGTM [17:31] and done for the day, good night all! [17:32] night frankban! [17:32] hatch_: couple of notes on your review [17:33] jujugui can we get a second review of hatch_'s fix to unblock the orange box please? https://github.com/juju/juju-gui/pull/557 [17:50] Makyo: I'd be intereted if that works with apache on the root container exposed and mysql and ghost in lxc containers on ec2 [17:51] Makyo: but you need the feature flag to enable that https://github.com/juju/juju-gui/pull/551/files [17:52] rick_h_, working on that now. Can't use apache yet because ghost charm doesn't have the vhost config yet [17:52] But haproxy will work [17:52] Makyo: oh, I thought it did apache [17:52] Makyo: ok cool [17:52] Makyo: was it nginx? [17:52] rick_h_, not sure, just going by what hatch_ said when we talked through what we could do. [17:53] Makyo: ah ok cool thehn [17:55] rick_h_: it relates to apache but apache doesn't know what to do without a vhost file [17:55] hatch_: gotcha [17:55] kind of unfortunate it doesn't include even a default one heh [18:04] hatch_: shipping your branch [18:04] hatch_: thanks for the update, not sure where everyone has gone for the afternoon [18:05] haha, it's beer oclock maybe [18:07] and the motox x won't be on verizon unlocked this time [18:07] time to move on [18:15]