[00:12] <hatch> huwshimi: https://github.com/juju/juju-gui/pull/550 +1
[00:12] <huwshimi> hatch: Thanks!
[00:14] <hatch> huw #549 will conflict with develop
[00:14] <hatch> you'll want to rebase
[00:14] <hatch> maybe do that then I'll finish the review
[00:14] <rick_h_> morning huwshimi 
[00:16] <huwshimi> hatch: OK no problems
[00:16] <huwshimi> rick_h_: Hey
[00:17] <hatch> huwshimi: have you moved into the garage yet?
[00:17] <hatch> your office I mean ;)
[00:18] <huwshimi> hatch: Not yet, might not be till after our next trip
[00:19] <hatch> ahh 
[00:19] <huwshimi> hatch: are you the only one that does that curly style?
[00:19] <huwshimi> :)
[00:20] <hatch> lol I would like to think that others do too :)
[00:20] <hatch> you do some funnyness with the curlies
[00:20] <hatch> elses on a new line
[00:20] <hatch> smushing them into the contents
[00:20] <hatch> that's like two extremes
[00:22] <huwshimi> hatch: Well, if you're the only one doing it we should pick a style...
[00:23] <hatch> huwshimi: look how well picking a commenting style worked out
[00:23] <hatch> ;)
[00:24] <rick_h_> yea, let's have that one again :P
[00:24] <hatch> haha 
[00:24]  * rick_h_ /me ls
[00:24] <rick_h_> lsbah
[00:24] <rick_h_> bah
[00:24] <rick_h_> lag
[00:24] <huwshimi> 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] <hatch> haha 
[00:25] <hatch> huwshimi: you can leave it as is - if it passes the linter that's fine by me
[00:25] <huwshimi> 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] <huwshimi> can be frustrating
[00:26] <hatch> huwshimi: really it's implementers choice if it passes lint
[00:26] <hatch> so you can tell us reviwers to go stuff it
[00:26] <hatch> :D
[00:26] <huwshimi> haha
[00:26] <huwshimi> hatch: Also I rebased and didn't hit a conflict
[00:26] <hatch> really....odd I changed some of the exact same lines lol
[00:26] <rick_h_> 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] <huwshimi> ok :)
[00:27] <rick_h_> I just rant quietly on the inside :P
[00:27] <huwshimi> hehe
[00:27] <hatch> basically I disagree with every one of those things rick_h_ just posted too lol
[00:27] <hatch> I guess that's why they invented gofmt
[00:28] <rick_h_> yea, watch out the first time i have to write go code
[00:29] <hatch> go fmt will lock up trying to fix everything 
[00:29] <hatch> lol 
[00:29] <hatch> stack overflow
[00:29] <rick_h_> there will be a nuclear cleanup about an hour north of detroit 
[00:29] <hatch> lol
[00:30] <hatch> 'melt down caused by gofmt and a developers opinions"
[00:30] <hatch> for what it's worth I also don't like gofmt 
[00:32] <rick_h_> wtf, are we string sorting machine names?
[00:32] <rick_h_> 0 - 1 - 10
[00:32] <rick_h_> 2 - 3 - 4- 
[00:33] <rick_h_> hmm, this is tricky though, once we allow naming the machines we'll have to support names. :/
[00:33] <huwshimi> Probably, they are strings :)
[00:35] <rick_h_> 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] <huwshimi> rick_h_: Yeah, it's my fault :)
[00:35] <rick_h_> huwshimi: all good, you're right that they're strings
[00:36] <rick_h_> it just feels very unnatural currently in practice
[00:36] <huwshimi> yeah
[00:36] <hatch> oo huwshimi is gona have to write an alphanumeric sorting algorithm
[00:36] <hatch> I'm sure there are some on the googles which you can use for inspiration
[00:37] <huwshimi> hatch: That's funny I'm pretty sure the card has your head on it
[00:37] <hatch> lol
[00:37] <hatch> is 549 updated and ready?
[00:38] <rick_h_> bah, walk the list, try to parse the int, if you can...then set it as an attribute
[00:38] <rick_h_> get to the end of the list and find they all parsed, then sort on the new attribute vs the name
[00:38] <rick_h_> done
[00:38] <rick_h_> one iteration through the list, one parseInt on xxx machine names
[00:38] <hatch> not sure that will work for things like 1-foo 10-bar style names
[00:39] <rick_h_> that's a string, sort it stringy then
[00:39] <hatch> I suppose
[00:39] <rick_h_> I just want to get pure numbers vs words right for now
[00:39] <rick_h_> I think people will do apache-1 and apache-2 vs 2-apache 1-apache
[00:39] <rick_h_> anyway, but we can tell about that later
[00:40] <hatch> true 
[00:41] <huwshimi> hatch: I've pushed up the rebased version of that branch, no changes to my code though
[00:41] <rick_h_> ok, tested jc's branch, now reloading onto latest trunk
[00:43] <rick_h_> switching branches is a LOT faster after the first change
[00:43] <rick_h_> guess all the work is in the deps/etc required
[00:46] <hatch> huwshimi: review done - a few comments around the events
[00:46] <rick_h_> hatch: much nicer ty
[00:47] <rick_h_> hatch: I'm hesitant to mark the bug fix committed though as we want to get a better fix?
[00:47] <hatch> rick_h_: oh I suppose...
[00:47] <hatch> 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] <huwshimi> hatch: Ah thanks, I was wondering if we could do something like that, much better!
[00:48] <rick_h_> hatch: hah
[00:49] <rick_h_> 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] <rick_h_> 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] <hatch> 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] <huwshimi> hatch: Ah right, that makes sense
[00:50] <hatch> rick_h_: haha I'm not sure why each machine would have multiple containers of the same service
[00:51] <hatch> huwshimi: I also think addTarget is idempotent but best not to repeat it just to be safe
[00:51] <rick_h_> hatch: well you can run 10 ghost nodejs instances on one hardware machine
[00:52] <rick_h_> imagine it's a 6core or something
[00:53] <hatch> rick_h_: ahh I didn't think of that
[00:53] <hatch> yeah I don't think it does multi core by default
[00:53] <rick_h_> yep
[00:54] <hatch> does lxc do cpu locking?
[00:54] <hatch> or would this be a openstack thing
[00:55] <hatch> I would assume lxc would just share resources so the provisioning must be done with something else
[00:56] <hatch> oh i think kvm does that
[00:56]  * hatch is just rambling now
[00:57] <huwshimi> hatch: Changes pushed
[00:58] <hatch> thx
[00:58] <huwshimi> doesn't appear to be picked up in github though
[00:59] <huwshimi> uh, somehow it pushed it to my develop
[01:00] <rick_h_> hatch: next part of your bug
[01:00] <rick_h_> hatch: when I hit commit, in the summary it says "You ahve 23 unplaced units, do you want to: ..."
[01:01] <hatch> oh poo
[01:02] <rick_h_> hatch: added a new card for tomorrow
[01:03] <rick_h_> but got a bunch of great screenshots
[01:03] <hatch> excellent I definitely want to check em out
[01:03] <rick_h_> so can move forward a little bit but can't go through summary/commit process yet
[01:03] <rick_h_> so blocker on any video work
[01:07] <hatch> yeah ok I'll jump on that first thing
[01:13] <huwshimi> hatch: OK, fixed all the weirdness, changes are up
[01:14] <rick_h_> hatch: got a sec to chat?
[01:29] <hatch> rick_h_: actually just making supper
[01:29] <hatch> gona be around in an hour?
[01:30] <rick_h_> hatch: all good, we can sync tomorrow
[01:30] <hatch> cool
[01:30] <hatch> huwshimi: I'll also finish up your review in an hourish
[01:30] <huwshimi> hatch: No problems, no hurry
[01:31] <rick_h_> hatch: sent the screenshot link
[01:31] <rick_h_> my middle-click stopped working all of a sudden wtf
[01:53] <rick_h_> jujugui kind of cool per
[01:53] <rick_h_> per
[01:53] <rick_h_> bah
[01:56] <rick_h_> jujugui https://plus.google.com/116120911388966791792/posts/dR3zqM6E66B kind of cool
[01:59] <huwshimi> rick_h_: Any idea why the hardware details are not available?
[01:59] <rick_h_> huwshimi: no :/
[01:59] <rick_h_> good point, I need to look into that one next. I wonder if it's because of maas or something
[01:59] <huwshimi> rick_h_: Have you ever seen hardware details?
[02:00] <huwshimi> like on ec2 or anything at all?
[02:00]  * rick_h_ thinks so but would have to double check
[02:00] <rick_h_> yea, the hardware inf ois all set to undefined in there
[02:01] <huwshimi> I have a feeling we've broken something
[02:01] <rick_h_> 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] <rick_h_> 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] <rick_h_> oh hmm, yea there's a delta that has empty hardwareCharacteristics so not sure what we could do about it
[02:17] <rick_h_> 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] <mup> Bug #1193998: maas provider doesn't return hardware characteristics of started instances <maas-provider> <tech-debt> <juju-core:Fix Released by axwalk> <https://launchpad.net/bugs/1193998>
[02:17] <rick_h_> huwshimi: but the orange box is on 1.18 and doesn't have the fix
[02:17] <huwshimi> hmm
[02:25] <hatch> rick_h_:  huwshimi if you load the env with the service view selected then it has the machine info
[02:25] <hatch> if you load with the mv then it doesnt
[02:26] <rick_h_> hatch: my issue is the maas bug though
[02:26] <rick_h_> hatch: verified it's getting backported today but will be in the next release 
[02:26] <hatch> ohh so this is in addition to the other bug heh
[02:26] <rick_h_> hatch: so just no hardware info for maas atm
[02:26] <rick_h_> hatch: right
[02:26] <rick_h_> this is a juju bug
[02:26] <hatch> man it's all creepy crawly in here lately :)
[02:26] <rick_h_> creepy crawly?
[02:26] <rick_h_> oh buggy :P
[02:27] <rick_h_> huwshimi: if you get a min can you review/qa https://github.com/juju/juju-gui/pull/548 please?
[02:27] <rick_h_> and if it's cool go ahead and shipit
[02:30] <hatch> haha yeah
[02:33] <huwshimi> rick_h_: The fix in that branch also fixes an issue I have in my current branch, expect for deployed services
[02:33] <huwshimi> rick_h_: shipped it
[02:33] <rick_h_> huwshimi: awesome thanks for looking
[02:33] <huwshimi> np
[02:36] <hatch> huwshimi: review done, +1 with some minor stuff
[02:38] <huwshimi> hatch: Thanks
[02:39] <rick_h_> ok, time for me to head out for the night
[02:39] <hatch> huwshimi: feel free to land after your updates
[02:39] <hatch> yup mee too
[02:39] <huwshimi> hatch: Thanks
[02:39] <hatch> night all
[02:39] <rick_h_> hatch: get out of here, need you fresh for the deploy stage bug tomorrow :P
[02:39] <huwshimi> rick_h_, hatch: night
[07:18] <fabrice> good morning !
[07:22] <huwshimi> fabrice: Morning
[07:24] <ant__> huwshimi, morning :)
[07:24] <huwshimi> ant__: Good morning!
[07:24] <ant__> huwshimi, how's it going?
[07:24] <huwshimi> ant__: Good thanks. Yourself>
[07:24] <huwshimi> *?
[07:25] <fabrice> morning
[07:25] <ant__> huwshimi, all good this end thanks
[07:25] <huwshimi> ant__: How long before you head on leave?
[07:26] <huwshimi> well, approximately :)
[07:26] <ant__> huwshimi, im off on the 24th
[07:26] <ant__> only for 2 weeks though
[07:26] <ant__> still have lots of hols left
[07:27] <huwshimi> ant__: Ah ok, very soon!
[07:28] <ant__> huwshimi, yeah b-day soon :/
[07:59] <huwshimi> Night all
[09:28] <frankban> rogpeppe1: morning, could you please take a look at https://github.com/juju/juju/pull/768 ?
[09:34] <rogpeppe1> frankban: looking
[09:34] <frankban> thanks
[09:39] <rogpeppe1> frankban: i'm afraid i'm not qualified to review API implementation changes any more
[09:40] <rogpeppe1> frankban: it seems reasonable to me, but perhaps it needs a new API version or something
[09:40] <frankban> 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] <urulama> frankban: i'd say it does need a new API version. just not sure if core is on them already
[09:55] <rogpeppe1> urulama, frankban: if they're doing semantic versions, i guess it would be a minor version increase
[09:56] <rogpeppe1> hmm, weird. my camera seems to have started working again.
[09:57] <urulama> rogpeppe1: no updates or any changes?
[09:57] <rogpeppe1> urulama: nope, none of the above
[09:57] <urulama> interesting :)
[09:57] <rogpeppe1> urulama: hurrah for modern software
[10:01] <frankban> rogpeppe1: it does not seem they are using semantic versioning. AFAICT facades only have a major version number
[10:01] <rogpeppe1> frankban: i have a vague recollection of that too
[10:01] <rogpeppe1> frankban: i don't know what they intend to do about backwardly compatible changes then
[10:02] <frankban> rogpeppe1: yeah, I'll see that in review. FWIW, I see stuff like common.RegisterFacade(
[10:02] <frankban> 		"AllWatcher", 0, newClientAllWatcher,
[10:02] <frankban> 		reflect.TypeOf((*srvClientAllWatcher)(nil)),
[10:02] <frankban> 	)
[10:02] <frankban> where 0 is the version
[11:11] <rick_h_> morning
[11:12] <rick_h_> frankban: <3 thanks for that update to core
[11:12] <rick_h_> it'll make our life a lot easier eventually
[11:12] <frankban> rick_h_: yeah, that's the idea :-)
[11:13] <frankban> 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] <urulama> frankban: thanks. i suspected that, as it makes sense
[11:15] <rogpeppe1> 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] <rogpeppe1> frankban: i guess it can look to see if the Subordinate field exists in the response
[11:16] <frankban> rogpeppe1: yes, I guess that's the way to go
[11:17] <fabrice> rick_h_: morning !? no it's time for lunch
[11:17] <rick_h_> fabrice: :) 
[11:17] <rick_h_> fabrice: hey, still trying to put breakfast together, quit rushing me :P
[11:30]  * rick_h_ steps away to take boy to day care
[11:42] <fabrice> rick_h_:  I am finished with lunch :)
[11:45] <fabrice> rick_h_: but I am not rushing you
[11:54]  * frankban lunches
[13:32] <rick_h_> 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] <rick_h_> frankban: can you peek please? ^ https://github.com/juju/juju-gui/pull/553
[13:37] <frankban> rick_h_: sure
[13:37] <rick_h_> frankban: ty much
[13:38]  * rick_h_ needs to start later. Feels like forever before everyone starts the day heh
[13:38] <jcsackett> rick_h_: do we still have permission to go over the WIP limits on MV?
[13:39] <rick_h_> jcsackett: I'm trying ot make room, if you can help move forward a review I'd prefer that first please
[13:39] <jcsackett> rick_h_: sure.
[13:39] <rick_h_> jcsackett: but yes, permission granted
[13:39] <rick_h_> frankban: you card in coding you got reviewed/landed?
[13:39] <rick_h_> ah no, that's a different one nvm
[13:40] <jcsackett> 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] <rick_h_> jcsackett: looking 
[13:40] <jcsackett> rick_h_: thanks.
[13:41] <kadams54> jcsackett: I can take a look at both
[13:42] <jcsackett> 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] <kadams54> kk
[13:56] <rick_h_> 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] <jcsackett> rick_h_: oh, sure. meant to take my head off of that one.
[13:57] <rick_h_> 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] <rick_h_> jcsackett: ty
[14:27] <kadams54> jcsackett: just to clarify, I should only be able to drag-n-drop onto the root container of undeployed machines, right?
[14:27] <jcsackett> kadams54: in an environment that doesn't support containers, correct; only the root container should be droppable.
[14:31] <kadams54> jcsackett: Alright, QA is good on #556
[14:31] <jcsackett> kadams54: awesome, thanks.
[14:34] <kadams54> rick_h_: any cards I should be looking at? The one I'm working on right now only impacts sandboxes.
[14:39] <jcsackett> kadams54: i think i misunderstood earlier--you weren't able to drop units onto a deployed root container?
[14:39] <kadams54> Correct
[14:40] <hatch> jcsackett: kadams54 So I can now use the GUI to drop multiple units on a single container in mv?
[14:40] <kadams54> Well, belay that.
[14:40] <jcsackett> pretty sure we are supposed to allow that...i don't recall that not working for me in the branch before.
[14:41] <jcsackett> kadams54: ok, belaying...you double checking that, or did i misstate something...?
[14:41] <kadams54> I'm double checking
[14:42] <kadams54> 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] <kadams54> QA comments updated. Breathe easy, jcsackett :-)
[14:43] <jcsackett> kadams54: hooray!
[14:43] <jcsackett> :)
[14:44] <hatch> excellent
[14:44] <hatch> not being able to do that really irritated me while doing some ghost tests
[14:48] <rick_h_> kadams54: looking
[14:49] <rick_h_> https://bugs.launchpad.net/juju-gui/+bug/1368588
[14:49] <mup> Bug #1368588: Unplaced units show up in changelog and make the "Commit" button active <juju-gui:Triaged> <https://launchpad.net/bugs/1368588>
[14:49] <rick_h_> kadams54: ^ would be good I think as that would effect demo
[14:49] <kadams54> k
[14:49] <rick_h_> 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] <kadams54> will do
[14:49] <rick_h_> ty
[14:50] <rick_h_> jujugui call in 10
[14:50] <rick_h_> hatch: Makyo if you guys are free can we meet now in there to chat demo/blog stuff
[14:50] <rick_h_> jujugui anyone else is welcome to join 
[14:51] <hatch> yup joining
[14:51] <rick_h_> hah, standing desk motor is working a bit harder with the orangebox on the desk
[14:55] <jcsackett> frankban: apologies, i was pushing another branch and i just accidentally updated the branch you're reviewing.
[14:56] <frankban> jcsackett: np, I can wait
[14:57] <jcsackett> frankban: well, i won't update anymore until your review is done--what got pushed only addressed comments from rick_h_.
[14:57] <frankban> jcsackett: ah, ok, no problem then, thanks
[14:57] <frankban> jcsackett: where is your card for this task?
[14:57] <jcsackett> frankban: i was insufficiently specific about branches to push and updated *all* of my active branches.
[14:58] <jcsackett> in the review lane; it was briefly in landing as i grabbed the wrong card. 
[14:58] <jcsackett> yay (poorly) juggling multiple cards.
[14:58] <frankban> jcsackett: cool, my name is already there
[15:00] <rick_h_> jujugui call time
[15:00] <rick_h_> ant__: jcsackett frankban &
[15:00] <rick_h_> fabrice: ^
[15:21] <frankban> jcsackett: reviewed
[15:23] <jcsackett> frankban: thanks! fixing up the code now.
[15:23] <jcsackett> 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] <Makyo> Cool, thanks jcsackett 
[15:37]  * rick_h_ runs to appointment
[15:37] <rick_h_> biab
[15:51] <frankban> hatch_: where is the temporary work around for subordinates in trunk?
[15:57] <hatch_> frankban:  in the initializer for the machine view p;anel.js
[15:58] <hatch_> it checks each units service if it's set to a subordinate
[16:00] <frankban> hatch_: and it can or cannot work right?
[16:01] <hatch_> 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] <hatch_> but if you visit the /mv directly the services charm data hasn't loaded yet by the time the token is rendered
[16:02] <frankban> hatch_: ok, so this will continue to be the best guess with old version of juju
[16:04] <hatch_> frankban:  yeah, not much we can do atm without refactoring the loading/rendering cycle of the mv
[16:05] <frankban> hatch_: ack
[16:06] <frankban> hatch_: can you confirm we don't want to show the scale up view in the inspector for subordinates?
[16:06] <hatch_> correct
[16:06] <hatch_> you cannot scale subordinates
[16:06] <frankban> hatch_: cool, I am refactoring that part too
[16:07] <kadams54> rick_h_: when you get back, we should chat.
[16:11] <hatch_> frankban:  awesome
[16:11] <hatch_> thanks
[16:25] <kadams54> lunching
[16:32] <jcsackett> 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] <frankban> jcsackett: I don't have that set up, but I can check again. I'll take a look ASAP.
[16:40] <frankban> jcsackett: on a real env, trying to export a bundle I still get "Uncaught TypeError: Cannot read property 'service' of undefined "
[16:43] <frankban> jcsackett: it might be a red herring, but what happens at  line 1929 if the machine does not include any units?
[16:45] <jcsackett> frankban: good catch; it should abort if a machine has no units.
[16:45] <frankban> jcsackett: yeah, I guess the error I encountered depends on that
[16:45] <jcsackett> actually, it should just filter machines with no units.
[16:46] <jcsackett> ok, that's a quick fix.
[16:46] <jcsackett> i misread your earlier qa error.
[16:47] <frankban> 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] <jcsackett> frankban: yeah, i'll need to update the "filters machines" test for this.
[17:02] <jcsackett> frankban: pushed.
[17:03] <frankban> jcsackett: I;ll reswitch and check again asap
[17:03] <jcsackett> thanks.
[17:05] <hatch_> juju gui lf review and qa for an orangebox bug https://github.com/juju/juju-gui/pull/557
[17:14] <rick_h_> kadams54: back
[17:15] <hatch_> rick_h_: want to qa my branch on Obey?
[17:15] <hatch_> Obee
[17:15] <hatch_> yeah....Obee
[17:16] <kadams54> rick_h_: After looking at https://bugs.launchpad.net/juju-gui/+bug/1368588 I don't think it's a valid bug
[17:16] <mup> Bug #1368588: Unplaced units show up in changelog and make the "Commit" button active <juju-gui:In Progress by kadams54> <https://launchpad.net/bugs/1368588>
[17:16] <rick_h_> kadams54: looking
[17:16] <kadams54> Either that, or I wasn't able to reproduce what Huw was seeing.
[17:17] <rick_h_> kadams54: will try to qa here in a live env
[17:17] <hatch_> kadams54: I believe the bug he was mentioning was fixed.....but I'm not sure by the report heh
[17:17] <kadams54> 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] <rick_h_> 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] <rick_h_> 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] <rick_h_> kadams54: what are your thoughts?
[17:20] <kadams54> rick_h_: I like the default we have right now, but mostly because it's very convenient for me :-)
[17:20] <rick_h_> kadams54: well, let's put ourselves in the shoes of users :)
[17:20] <hatch_> I like the default we have now because it's the cheapest option for the user if they misclick
[17:20] <hatch_> heh
[17:20] <rick_h_> kadams54: I can toss it to luca and UX and get their feedback
[17:20] <kadams54> 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] <rick_h_> hatch_: right, but they couldn't mis-click. They'd have to select one or the other if we make it selected
[17:21] <rick_h_> kadams54: understood
[17:21] <rick_h_> 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] <kadams54> Technically, something *does* happen… the service gets deployed. You just can't see it in machine view.
[17:22] <rick_h_> kadams54: right, I understand
[17:22] <frankban> guihelp: I need reviews/QA for https://github.com/juju/juju-gui/pull/558 . no rush
[17:23] <kadams54> rick_h_: Anything else that's a higher priority than my happens-in-sandbox-only card?
[17:23] <rick_h_> kadams54: any of the three destroy cards
[17:23] <rick_h_> kadams54: I'd suggest looking at all three to make sure there's not a common theme/overlap while investigating
[17:24] <kadams54> will do
[17:24] <kadams54> I kinda wonder if they might all be sandbox-only bugs…
[17:25] <rick_h_> kadams54: good info to find out for sure
[17:26] <rick_h_> although when huw found these, I had specifically asked him to QA on ec2 and azure
[17:26] <rick_h_> kadams54: so not sure they'll be sandbox only thing
[17:26] <rick_h_> things
[17:26] <hatch_> ywah the description isn't really complete
[17:26] <rick_h_> hatch_: k, looking at your branch
[17:26] <hatch_> coooooo
[17:27] <hatch_> 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] <rick_h_> hatch_: understood
[17:28] <rick_h_> hatch_: I think this is defintiely an experiment. I expect we'll have some feedback and debate on the subordinate thing
[17:28] <hatch_> rick_h_: are there any more bugs that are critical?
[17:29] <rick_h_> hatch_: no, I think the rest are just bugs we can avoid in any marketing material
[17:29] <hatch_> ok cool I'll hop back on my previous card
[17:29] <rick_h_> ty
[17:29] <hatch_> try and get that thing finally landed heh
[17:31] <frankban> jcsackett: LGTM
[17:31] <frankban> and done for the day, good night all!
[17:32] <rick_h_> night frankban! 
[17:32] <rick_h_> hatch_: couple of notes on your review
[17:33] <rick_h_> 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] <rick_h_> 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] <rick_h_> Makyo: but you need the feature flag to enable that https://github.com/juju/juju-gui/pull/551/files
[17:52] <Makyo> rick_h_, working on that now.  Can't use apache yet because ghost charm doesn't have the vhost config yet
[17:52] <Makyo> But haproxy will work
[17:52] <rick_h_> Makyo: oh, I thought it did apache
[17:52] <rick_h_> Makyo: ok cool
[17:52] <rick_h_> Makyo: was it nginx?
[17:52] <Makyo> rick_h_, not sure, just going by what hatch_ said when we talked through what we could do.
[17:53] <rick_h_> Makyo: ah ok cool thehn
[17:55] <hatch_> rick_h_: it relates to apache but apache doesn't know what to do without a vhost file
[17:55] <rick_h_> hatch_: gotcha
[17:55] <hatch_> kind of unfortunate it doesn't include even a default one heh
[18:04] <rick_h_> hatch_: shipping your branch
[18:04] <rick_h_> hatch_: thanks for the update, not sure where everyone has gone for the afternoon
[18:05] <hatch_> haha, it's beer oclock maybe
[18:07] <rick_h_> and the motox x won't be on verizon unlocked this time
[18:07] <rick_h_> time to move on 
[18:15] <hatch_> :/
[18:15] <rick_h_> phone ordered, new carrier when it gets here
[18:52] <rick_h_> bah guess not ordered
[18:52] <rick_h_> moto site having issues 
[19:00] <hatch_> heh I'm sticking with my m7 for a while
[19:00] <hatch_> I'm not sure what upgrading will get me
[19:04] <hatch_> I was thinking a nicer camera might be nice to have
[19:07] <rick_h_> yea, the camera is a big deal, the screen update, the wooden back I didn't get to have on the first one, and the new moto action stuff 
[19:07] <rick_h_> but they don't want my $$
[19:07] <rick_h_> hatch_: ty for the update, qa's ok
[19:08] <hatch_> awesome glad we weren't too far off on the orange box stuff
[19:08] <rick_h_> nope, just trying to plan out how to record this demo now
[19:09] <hazmat> rick_h_, there's a bug fix out for deployer (0.4.1) need a minor increment on juju stable ppa for deployer.. some folks on local and openstack providers are seeing regression due to differential juju behavior wrt to post bootstrap contents of jenv file by provider.
[19:10] <hatch_> great
[19:10] <rick_h_> hazmat: rgr, have a link to the bug to use as a track point for us?
[19:12] <hazmat> rick_h_, https://bugs.launchpad.net/juju-deployer/+bug/1368403
[19:12] <mup> Bug #1368403: juju-deployer traceback AttributeError: 'NoneType' object has no attribute 'get_stat' <landscape> <juju-deployer:Fix Released by hazmat> <https://launchpad.net/bugs/1368403>
[19:12] <rick_h_> hazmat: rgr, will look and get a package updated. Tomorrow ok?
[19:12] <hazmat> rick_h_, sounds good
[19:13] <hazmat> rick_h_, thanks
[19:13] <rick_h_> hazmat: np
[19:14] <rick_h_> hazmat: got a sec for an openstack question?
[19:15] <hazmat> rick_h_, shoot
[19:15] <rick_h_> hazmat: doing a video demo of machine view on the orange box with the demo openstack installed
[19:15]  * hazmat nods
[19:15] <rick_h_> for the demo the best thing I can think of is to bring up the two empty machines on the orangebox as two more nove-compute nodes?
[19:15] <rick_h_> and manually place them on there to kind of demo 'growing your cloud' a bit?
[19:16] <rick_h_> is there anything else that's normally the first thing you'd think someone would 'scale up' or something more interesting for those two machines to be as demo material?
[19:16]  * rick_h_ is a bit of an openstack noob
[19:17] <hazmat> rick_h_, hmm... well in bringing up the cloud itself being able to place the parts onto colocated machines is interesting
[19:18] <rick_h_> hazmat: well I was going to start out with it placed via the demo script
[19:18] <hazmat> rick_h_, the add-unit -n 2 nova-compute is going to be pretty similiar.. its the placement of the infrastructure for density bit that's interesting
[19:18] <rick_h_> hazmat: and go through 'look at how it's placed and colocated, now let's use the new features to upgrade it a bit'
[19:18] <hazmat> ic
[19:18] <rick_h_> hazmat: yea, true. I was thinking of doing more rabbit nodes colocated
[19:18] <rick_h_> to expand messaging bandwidth, but that seemed kind of artificial
[19:19] <hazmat> rabbit clustered is okay.. its not totally artificial but i'm not sure how reliable its going to be
[19:19] <rick_h_> hazmat: anything you might deploy along side the openstack stuff?
[19:19] <rick_h_> that I could deploy on the two other nodes in some dense fashion and then relate into the openstacak deployment in a way that's interesting?
[19:19] <hazmat> rick_h_, ceilometer + mongo
[19:20] <hazmat> perhaps
[19:20] <rick_h_> yea, those are in the deployment. I could remove/add them in
[19:21] <rick_h_> ok, I'll play with the compute stuff for the demo. The density stuff will be more interesting in the smaller scale video/demo hatch_ and Makyo are doing. 
[19:21] <rick_h_> this is more 'visualize the big' and theirs is more 'scale down things into the small'
[19:21] <rick_h_> hazmat: thanks
[19:22] <hazmat> rick_h_, drawing blanks atm.. the placement story via gui is primarily for custom placement/curation against limited number of machines.. the openstack overlap is primarily to the extent that people  want to deploy ostack on  a limited number of nodes. ie. above the cloud openstack is orthogonal for the most part.. another option might be just using a single maas node directly and placing a whole app st
[19:22] <hazmat> ack there (mediawiki, mysql, memcached, etc). the big data stuff isn't really well suited to density placement.
[19:23] <rick_h_> hazmat: rgr thanks
[19:35] <rick_h_> kadams54: can you check if the background is supposed to be transparent on the services header in MV?
[19:35] <rick_h_> kadams54: it seems really odd and if not, can you update that please?
[19:38] <rick_h_> Makyo: frames per second on the recording? is 15 ok or should it bump to 24?
[19:38] <Makyo> rick_h_, 15 is usually okay for a screencast
[19:38] <rick_h_> Makyo: ok cool then
[20:00] <hatch_> if it's going to be put on youtube why not record at the highest?
[20:03] <rick_h_> I'm way out of practice for doing these things. 
[20:03] <rick_h_> take 2!
[20:14] <hatch_> *sigh* depending on where this add machine call is called from it has a different callback 
[20:15] <hatch_> break time
[20:30] <kadams54> rick_h_: checking…
[20:33] <kadams54> rick_h_: you mean the Services tab?
[20:34] <rick_h_> kadams54: yes
[20:34] <rick_h_> the nav tab has a css rule setting hte background transparent and no border
[20:34] <rick_h_> and that seems off per designs
[20:36] <kadams54> rick_h_: Is this when the Services tab is active/selected? What should the color be?
[20:37] <kadams54> I looked through the visuals in Google docs and none of them deal with what the services tab should look like when active.
[20:38] <rick_h_> kadams54: true, I think it should stay white, the transparent is a bit of fail with the background/lines showing through
[20:38] <kadams54> rick_h_: I could revert to white with a border, but then it loses it's "tabbish" appearance: http://cl.ly/image/2w3b470i0n1C
[20:38] <rick_h_> when the MV is selected it's white and still has a border, maybe go bacak and look at the commit that added the styles there that are unsetting it
[20:38] <kadams54> That is, it doesn't move to the forefront among the other tabs.
[20:38] <rick_h_> and see if that had any data
[20:39] <rick_h_> kadams54: by data I mean a linked bug or anything
[20:39] <kadams54> Digging
[20:41] <rick_h_> Makyo: around?
[20:42] <kadams54> rick_h_: https://github.com/juju/juju-gui/pull/374 - doesn't appear to have a linked bug.
[20:43] <rick_h_> kadams54: k, thanks for the research. will look into it
[20:44] <kadams54> rick_h_: Another option (one that I'd prefer) would be to change it to #f2f2f2, which would match the canvas background: http://cl.ly/image/0J3t1C0o0q3n
[20:45] <rick_h_> yea, that's not bad
[20:45] <kadams54> Then the tab is clearly active but without letting the background leak through
[20:45] <rick_h_> I think that's what he was going for I bet
[20:45] <rick_h_> but the issue was I had a giant green relation line going through my header lol
[20:45] <kadams54> :-)
[20:45] <rick_h_> kadams54: k, can you move forward with that. We'll jfdi and see if anyone complains
[20:46] <rick_h_> kadams54: just trivial land the change you've got in front of you?
[20:46] <kadams54> jfdi?
[20:46] <rick_h_> just f'ing to it :)
[20:46] <rick_h_> do it
[20:46] <hatch_> DO IT
[20:46] <rick_h_> whoops
[20:46] <hatch_> don't tell anyone but the millions who have access to the channel logs
[20:46] <kadams54> Hah, urban dictionary to the rescue
[20:47] <kadams54> Should I push directly to develop?
[20:47] <hatch_> pssht to trunk!
[20:47] <kadams54> :-b
[20:47] <rick_h_> kadams54: no, do a pr and mark trivial and shipit please
[20:47] <kadams54> Will od
[20:47] <rick_h_> ty
[20:47] <kadams54> do even
[20:50] <rick_h_> Makyo: sending email to peeps, data from screencast is in the dropbox folder
[20:50] <hatch_> not having the ecs update ghost models to real models is seriously causing disasters
[20:50] <hatch_> like I'm surprised this works at all!
[20:50] <Makyo> rick_h_, excellent, thanks
[20:50] <rick_h_> jujugui feel free to listen/look (have to manually sync audio to video) and let me know if it's too bad to use
[20:50] <hatch_> ok thats a little dramatic
[20:51] <rick_h_> there's two of them there at the moment, might try a third depending on feedback before I return the orange box tonight
[20:51] <rick_h_> hatch_: huh?
[20:51] <Makyo> STandard hatch_ fare, then :)
[20:51] <rick_h_> hey, I've got two screencasts showing it work!
[20:51] <kadams54> lol
[20:52] <hatch_> Makyo:  lol true
[20:52] <Makyo> And I'm working on a third, including containerization
[20:52] <hatch_> rick_h_:  how do I get the screencast?
[20:52] <rick_h_> hatch_: go to the dropbox link in the email and open the ogv file and lay the audio file that goes with it and sync the two up so what you see matches what you hear
[20:52] <rick_h_> hatch_: and then do a little dance and three spins and make some more coffee
[20:53] <hatch_> hmm yeah no ogv file there for me
[20:53] <rick_h_> no?
[20:53] <hatch_> a bunch of au files
[20:53] <hatch_> and two aup files
[20:54] <Makyo> hatch_, they have icons.
[20:54] <Makyo> One says 'orangebox maas'
[20:54] <rick_h_> hatch_: go to the list view
[20:54] <Makyo> Oh, just that one, whoops.
[20:54] <rick_h_> hatch_: in the list view it shows up better
[20:55] <rick_h_> machine-view-1.(aup/ogv) and machineview2.aup + machine-view-2.ogv
[20:55] <hatch_> oh there they are
[20:55] <rick_h_> I'm consistant with my naming...almost
[20:55] <hatch_> odd...they just showed up while I was looking at it
[20:55] <rick_h_> might have still been uploading? 
[20:55] <rick_h_> little icon wasn't spinning so thought they were done
[20:56] <hatch_> probably their db propagation taking a while
[20:56]  * rick_h_ has to get the kiddo from school
[20:56] <rick_h_> Makyo: if you can listen sooner vs later I'd appreciate it to know if I need to do one more try before I've got to leave to take it back to jcastro tonight
[20:56] <Makyo> rick_h_, sure, will see about grabbing the audacity files.
[20:57] <Makyo> Guess I could just save to my dropbox
[20:57] <rick_h_> hmm yea tried to share with juju-gui-peeps but didn't work out
[20:57] <rick_h_> so not sure. 
[20:57] <hatch_> this is the first time I've used dropbox... I think I prefer drive
[20:57] <rick_h_> ok, afk biab
[21:10] <hatch_> ok I think I finally got it....sometimes a good break helps clear the mind
[21:14] <hatch_> the indentation that the linter wants for the break; statement in switches is just odd...
[21:19] <rick_h_> hatch_: :P
[21:20] <hatch_> I now have to rewrite all the tests.....BUT somehow every current test didn't fail...
[21:20] <rick_h_> :/
[21:20] <hatch_> suspicious......vewy suspicious
[21:34] <hatch_> Makyo: was it you that did the orange star thing for config changed stuff? http://imgur.com/gjPWIjh
[21:49] <Makyo> hatch_, 404
[21:50] <hatch_> oops sorry creating bug atm will post the link 2 secs
[21:50] <Makyo> Sure
[21:50] <hatch_> Makyo: https://bugs.launchpad.net/juju-gui/+bug/1370260
[21:50] <mup> Bug #1370260: Saving configuration settings creates white block and checkbox css issue <juju-gui:New> <https://launchpad.net/bugs/1370260>
[21:51] <hatch_> reading the source it seems like this would happen heh...not sure how it worked before :)
[21:51] <Makyo> Okay
[21:51] <hatch_> my guess is a css conflict now
[21:51] <Makyo> I don't have time for it if we're fucking with orangebox today.
[21:52] <Makyo> rick_h_, the second audacity project is corrupted for me.  Can you just export WAV files for both of them?  That's all kdenlive will take, anyway.
[21:52] <hatch_> yeah np just making you aware
[21:55] <rick_h_> Makyo: rgr, looking
[21:58] <rick_h_> Makyo: uploading to dropbox
[21:58] <Makyo> rick_h_, cool, thanks
[21:59] <rick_h_> darn slow upload speeds
[22:13] <rick_h_> Makyo: wav file uploaded
[22:13] <rick_h_> well, think it is, it's more than 44 bytes dropbox
[22:14] <rick_h_> Makyo: well it should be updated soon I guess. It's done syncing according to my client
[22:15] <hatch_> stepping away for a bit picking the pooch up from getting his hair cut
[22:15] <Makyo> rick_h_, alright, cool.  Will grab it in a second.
[22:15] <rick_h_> Makyo: ok, it's actually the 'Richard Harding's conflicted copy' one
[22:18] <Makyo> Cool, got it.  Will get the videos done tonight
[22:19] <rick_h_> Makyo: ok cool thanks
[22:19]  * rick_h_ shuts down the orange box and teary eye'd prepares to sent it home
[22:22] <Makyo> We'll miss you~
[22:39] <hatch_> back
[22:40] <hatch_> oh thanks Makyo
[22:40] <hatch_> oh you meant Obee....
[22:40] <hatch_> :'( 
[22:40] <Makyo> Didn't miss you one bit, sorry.
[22:40] <Makyo> :)
[22:41] <hatch_> lol
[22:42] <Makyo> Obee is a sandwich place out here, hard for me to shake that.
[22:42] <Makyo> Well, Obee's.
[22:49] <hatch_> hmm sandwitch
[22:49] <hatch_> I think I'll have a leftover pork sandwich for supper tonight
[23:03] <huwshimi> Morning
[23:05] <hatch_> morning huwshimi
[23:05] <hatch_> how goes the morning?
[23:07] <huwshimi> hatch_: I get to fight writing a test that I couldn't figure out yesterday :)
[23:10] <huwshimi> hatch_: Some friends of mine just moved to Canada.
[23:11] <huwshimi> hatch_: Turns out they're in Saskatchewan!
[23:12] <huwshimi> hatch_: Not only that, but they're in Saskatoon!
[23:28] <hatch_> huwshimi: no way?
[23:28] <huwshimi> hatch_: I've known they were moving there for 6 months or so, but I had no idea where to
[23:28] <hatch_> haha so are they moving here for industry jobs?
[23:28] <huwshimi> (known they were moving to Canada)
[23:29] <huwshimi> hatch_: I think the guy has a job as a biologist at a university or something there
[23:29] <hatch_> ahh very cool
[23:29] <hatch_> so have they moved?
[23:30] <huwshimi> hatch_: His contract expired so they looked around for similar jobs and ended up over there.
[23:30] <huwshimi> hatch_: yeah they moved a few weeks ago
[23:30] <hatch_> haha that's awesome
[23:30] <hatch_> small damn world
[23:31] <huwshimi> yep
[23:31] <hatch_> see it is a real place :P
[23:31] <huwshimi> hatch_: Still doesn't make me believe the place exists though
[23:31] <huwshimi> haha
[23:32] <hatch_> rofl
[23:33] <hatch_> wow that's crazy....
[23:41] <hatch_> huwshimi:  I'm going to be putting in some sporadic OT today....trying to get this stupid branch done - so if you need anything just ping
[23:42] <huwshimi> hatch_: Sure, I'm about to propose a branch that I have no idea if it is doing things in an even remotely sane way, so that'll probably need a review :)
[23:42] <hatch_> haha sounds like a plan
[23:44] <huwshimi> hatch_: https://github.com/juju/juju-gui/pull/560
[23:53] <hatch_> huwshimi: looks good just some trivial comments
[23:53] <hatch_> I haven't qad yet
[23:53] <huwshimi> hatch_: Ah great, thanks!