[02:46] <hatch> huwshimi thanks for keeping the landing requests going on that branch to get it landed :)
[02:48] <huwshimi> hatch: np :)
[02:49] <hatch> so you're all set for the rest of the day? 
[02:52] <huwshimi> hatch: Yep!
[02:52] <hatch> huwshimi https://www.kickstarter.com/projects/1620669801/synek-any-beer-ever-made-fresh-on-your-counter
[02:57] <huwshimi> Looks great
[03:00] <rick_h__> hatch: looks like CI's been happy since mayko's change?
[03:00] <hatch> rick_h__ negative, http://ci.jujugui.org:8080/job/juju-gui-merge/462/ this one failed
[03:00] <hatch> we
[03:00] <hatch> er
[03:01] <hatch> sorry that failed with the noritfications test
[03:01] <hatch> notifications
[03:01] <hatch> so yes
[03:01] <hatch> :)
[03:01] <rick_h__> hatch: yea, more nervous about the failure to run tests :)
[03:01] <rick_h__> notifications diaf
[03:01] <rick_h__> and all that
[03:01] <huwshimi> rick_h__: Mine have been failing all day :)
[03:01] <hatch> are you ok with me adding a .skip to that test?
[03:01] <rick_h__> hatch: actually that's a damn good point
[03:01] <rick_h__> hatch: I am, we've got a card to fix those tests and ack that we won't get to it until post machine view
[03:02] <rick_h__> hatch: we all know the damn thing is erronous so +1 on .skip 
[03:02] <rick_h__> hatch: but please find the bug/card and XXX it in code
[03:02] <hatch> cool, I'll do that right now once I confirm the failures
[03:02] <rick_h__> hatch: rgr
[03:10] <hatch> https://github.com/juju/juju-gui/pull/418 and now we wait to see if the tests pass :)
[03:11] <hatch> my adapter to hook my xbox controller up to my laptop arrived, works like a charm....
[03:12] <rick_h__> hah, very cool
[03:12] <hatch> now the gaming master race can use a controller :)
[03:12] <hatch> (he says from an underpowered laptop)
[03:12] <rick_h__> hah
[03:13] <hatch> oh rick_h__  have you used your document camera yet?
[03:13] <rick_h__> hatch: yea a few times
[03:13] <hatch> I'm thinking of getting one myself and there are so many options
[03:13] <rick_h__> I only used it on a call once
[03:13] <hatch> any insight?
[03:14] <rick_h__> oh wtf, this is cool. I have this one but wired http://www.amazon.com/Ipevo-iZiggi-HD-Wireless-Document-CDVW-01IP/dp/B00GUELRK2/ref=sr_1_10?ie=UTF8&qid=1404357237&sr=8-10&keywords=document+camera+ipevo
[03:14] <rick_h__> didn't know they had a wireless one
[03:15] <rick_h__> comes with some osx software that works out nice
[03:15] <rick_h__> linux is a bit more hit/miss
[03:15] <hatch> bahahaha https://plus.google.com/118445028821328031751/posts/HrqeHHBNkRp
[03:16] <hatch> are there any tips you have about like quality, functionality, etc
[03:16] <rick_h__> so the quality is pretty good
[03:17] <rick_h__> it's not as nice as a scanner or as easy to use as a scanner 
[03:17] <rick_h__> but scanners only work for full document sheets well
[03:17] <rick_h__> I've used it to lay out receipts for work next to each other, and send in one jpg of them all 
[03:17] <rick_h__> and you can't use a scanner as a video camera
[03:17] <rick_h__> so to record/etc
[03:17] <rick_h__> I've not used it a ton, but the few times I've used it, seems to work out. It's a bit hard to get it setup to snapshot a full page doc
[03:18] <rick_h__> but had to do that once with something that had to be signed 
[03:18] <rick_h__> and saved me a trip to a fax machine
[03:18] <hatch> and the resolution is ok?
[03:18] <hatch> http://blog.trello.com/trello-on-your-wrist/
[03:19] <rick_h__> yea, seems to be. It's a webcam basically
[03:19] <rick_h__> hatch: yea, saw that. Will have to try that out when it ships
[03:19] <rick_h__> I use trello for my GSoC stuff on bookie
[03:19] <hatch> cool thanks
[03:19] <hatch> ahh yeah
[03:19] <rick_h__> hatch: I mean I'm not sure if I didn't get as a gift if I'd spend my $$ on it though
[03:19] <hatch> reviews for the watches are all over the place, some say the samsung has better screen, others say the LG does heh
[03:19] <rick_h__> hatch: it's not connected sitting on a desk behind me and only connected as needed
[03:20] <hatch> ahh
[03:20] <rick_h__> hatch: yea, but everyone agrees the lg has better battery life
[03:20] <hatch> this is true
[03:20] <hatch> definitely important
[03:20] <rick_h__> hatch: and I'll take that, plus the screen issue is that the LG screen isn't as rich, but it works better outdoors
[03:20] <rick_h__> so samsung has prettier, but sometimes useless screen
[03:20] <rick_h__> lg isn't as pretty, but more usuable at all times
[03:20] <hatch> I'm pretty much against samsung anyways 
[03:21] <rick_h__> then there's that :)
[03:21] <hatch> so it's really a non-contest haha
[03:21] <rick_h__> +1 to anti samsung
[03:22] <hatch> I forgot how crazy java was
[03:22] <rick_h__> lol
[03:22] <hatch> com.google.android.clockwork.watchfaces.WatchFaceStyle.Builder
[03:23] <hatch> like what the h e double hockeystick 
[03:23] <rick_h__> yea, I really want to do mobile dev work sometimes, but then I see java or obj C and run back away
[03:23] <hatch> yeah I wanted to dabble with this watch but wow...
[03:24] <rick_h__> lol
[03:24] <hatch> Swift is pretty nice though
[03:24] <hatch> not that that's going to help 
[03:24] <rick_h__> tell luca we want to do a gui watch app :P
[03:24] <hatch> haha - I don't think it allows any styling
[03:24] <hatch> it COULD receive notifications though
[03:25] <hatch> scale up/down etc
[03:25] <rick_h__> lol
[03:25] <hatch> could be pretty cool actually
[03:25] <rick_h__> ask ant if his mobile charm details is watch mobile
[03:25] <hatch> "Ok Google, scale up my wordpress service to 5 units"
[03:25] <hatch> lol
[03:28] <hatch> I wonder if some of our really smart people on the phone team could flash ubuntu touch onto the watch
[03:28] <hatch> itty bitty icons
[03:29] <huwshimi> hatch: OK, now I'm confused. Are you planning to completely replace the UI that exists for the current scaleup or are you just adding some bits and modifying what we have?
[03:29] <hatch> huwshimi I was going to replace the whole thing - because it now needs to be sharable between the ghost and service inspectors
[03:30] <hatch> some of the back end code can be sharable I think but the front end stuff is all new
[03:30] <huwshimi> hatch: Ah great, makes thing easier for me then :)
[03:30] <hatch> egggggcellent 
[03:49] <hatch> huwshimi_ ok I'm heading off - so even if you don't get as much done as you'd like by your EOD put it into a landable state so I can land it in the morning and keep going :)
[03:53] <huwshimi_> hatch: Yep, no problems. Thanks
[03:53] <hatch> np, thanks, and have a good night
[06:21] <rogpeppe> urulama, huwshimi: mornin'
[06:22] <huwshimi> rogpeppe: Morning
[06:23] <urulama> morning
[06:26] <urulama> huwshimi: wow, australia ... and i thought i was alone :)
[06:26] <huwshimi> urulama: Hey! Welcome!
[06:26] <urulama> huwshimi: tnx
[06:27] <urulama> huwshimi: good to be here ;)
[06:27] <huwshimi> urulama: Is this your first week?
[06:28] <urulama> huwshimi: yes, started on Monday. experienced information overload the first three days, now i plan to play with juju for few days 
[06:30] <huwshimi> urulama: Yeah, it's all a bit crazy to begin with. It's great that you have a chance to play with it all to start off.
[06:31] <huwshimi> brb, changing locations
[06:34] <urulama> huwshimi: rick prepared set of "missions" to get to know the dev cycle and also how juju works, which also made you create different public cloud accounts which will be used anyway ... it's meant for newcomers ... looks nice
[06:55] <rogpeppe> urulama: cool. i'd like to see the "missions".
[08:57] <frankban> hi rogpeppe, how is it going?
[08:57] <rogpeppe> frankban: yo
[08:57] <rogpeppe> ~
[08:58] <rogpeppe> !
[08:58] <rogpeppe> frankban: not bad, thanks
[08:58] <frankban> :-)
[08:58] <rogpeppe> frankban: how was your greek island?
[08:59] <frankban> rogpeppe: it was beautiful, the sea, nice small towns, good food
[09:00] <rogpeppe> frankban: nice
[09:00] <frankban> urulama: morning, and welcome!
[09:01] <rogpeppe> frankban: you up for pairing on finishing up the apiv4 spec?
[09:02] <frankban> rogpeppe: sounds good, I'll be ready right after a coffee. 
[09:02] <urulama> frankban: morning
[09:02] <urulama> frankban: and tnx :)
[09:03] <rogpeppe> frankban: cool. i'll grab breakfast
[09:17] <frankban> rogpeppe: I am in https://plus.google.com/hangouts/_/canonical.com/daily-standup?authuser=1 no rush
[11:53] <rick_h__> welcome back frankban 
[11:53] <frankban> rick_h__: thanks!
[11:54] <frankban> rick_h__: are you out today?
[11:54] <rick_h__> greek island? Sounds awesome. 
[11:54] <frankban> rick_h__: yeah, crete
[11:54] <rick_h__> frankban: yea, heading up north for family camping over the holiday weekend
[11:55] <rick_h__> frankban: rogpeppe and hatch can help fill you in on things for the couple of days. I'll be back on tues
[11:55] <frankban> rick_h__: cool, so no call in 5, right? I am pairing with Roger on the v4 specs, have a great long weekend
[11:55] <rick_h__> frankban: lots of docs/specs to catch up on and I'm sure your emails are backed up a bit
[11:55] <rick_h__> frankban: yep, no call. 
[11:55] <rogpeppe> rick_h__: have a good one
[11:55] <rick_h__> thanks rogpeppe 
[11:56] <rick_h__> urulama-away: meet frankban, frankban meet urulama-away, and jrwren is the other new hire. rogpeppe make sure to do the intro on the standup please. 
[11:56] <urulama> rick_h__: we met in the morning :D
[11:57] <rick_h__> oh, coolio then
[11:57] <urulama> rick_h__: italy is close :D
[11:57] <rick_h__> you morning people :P
[11:57] <frankban> :-)
[11:57] <urulama> rick_h__: what about the call tomorrow at 5pm? 
[11:57] <rick_h__> urulama: I don't see a call on my calendar for 5pm tomorrow?
[11:58]  * frankban lunches
[11:58] <rick_h__> urulama: unless tha'ts the friday standup?
[11:58] <rick_h__> urulama: in that case hatch will run the stand ups while I'm out
[11:58] <rick_h__> urulama: hopefully with better bandwidth
[11:58] <urulama> rick_h__: yes, the standups :D
[11:58] <rick_h__> yea, hatch knows the drill. Just try to keep them short/sweet :)
[11:59]  * urulama back to the process of killing dying charms
[12:04] <bac> morning
[12:04] <bac> hi frankban.  welcome back.  hope you had a good break.
[12:59] <rogpeppe> frankban: hangout?
[13:02] <frankban> rogpeppe: sure
[13:02] <frankban> bac: thanks, I had a great time, how is it going?
[13:03] <bac> frankban: good.
[13:34] <hatch> morning all
[13:34] <hatch> wb frankban 
[13:37] <bac> urulama: with LXC 0 is actually the host machine.  it cannot be host to other services.  frankban may be able to provide a more coherent answer.
[13:38] <jrwren> urulama: i just did the same thing :)
[13:40] <urulama> jrwren: ;) let's see where the limit's are 
[13:45] <frankban> urulama: quickstart co-locates the GUI on machine 0 only if 1) it's not a local env and 2) machine 0 is trusty or precise. I see a card to avoid co-location also on azure
[13:51] <urulama> frankban: what happens with local env? isn't it only with "machine 0" on local env?  so how does 1) hold?
[13:55] <jrwren> is juju-local really an empty package which installs dependencies?
[13:55] <bac> urulama: i don't understand your question.  if it is a local env then it does not colocate the gui.
[13:56] <bac> jrwren: yes.  not uncommon.
[13:57] <jrwren> cool.
[13:59] <urulama> bac: right, my bad.
[14:07] <urulama> jrwren: based on questions about Safari ... did you try the "brew install juju --dev"? 
[14:08] <jrwren> urulama: yes, that is exactly what I was running.
[14:09] <jrwren> urulama: unfortunately its only 1.19.3, and building trunk is apparently non-trivial
[14:09] <jrwren> urulama: so I stopped using juju osx for a bit, while I get more familiar
[14:10] <jrwren> This may be a good time to ask, https://launchpad.net/juju-core/trunk/1.19.3/+download/juju-core_1.19.3.tar.gz  is a tarball which includes dependencies.  Is there such a tarball for 1.19.4 ?
[14:18] <hatch> jrwren building juju is trivial on Ubuntu :)
[14:19] <hatch> jrwren https://launchpad.net/juju-core/trunk/1.19.4
[14:19] <hatch> on there
[14:21] <jrwren> lets make it trivial other places too :p
[14:22] <urulama> ^^^
[14:22] <urulama> well, brew was a nice start tbh
[14:23] <jrwren> indeed. brew is great.
[14:23] <hatch> great....well....
[14:23] <jrwren> not as great as ubuntu.
[14:25] <hatch> jrwren urulama I'm guessing both of you guys are running on osx?
[14:26] <urulama> hatch: no, just one of the machines at home
[14:27] <hatch> ahh - I have to run it as the host os atm - the drivers just aren't quite there yet for this mbp
[14:27] <urulama> hatch: parallels?
[14:27] <jrwren> just a bit of OSX, yes.
[14:28] <urulama> hatch: do you use parallels for running ubuntu?
[14:28] <hatch> I HAVE Parallels but it's garbage for anything other than Windows, I'm using virtual box/vagrant, but others have had good luck with fusion 
[14:28] <urulama> hatch: why? you just need to change xorg config file and it works as a charm with 14.04 (pun intended :D)
[14:29] <hatch> urulama if I'm paying $100 for software I don't want to have to spend more hours making it work :)
[14:30] <hatch> lol
[14:30] <urulama> hatch: naaaa, it's only $100 the first year, it's $50 every next year for every upgrade :D :D :D
[14:30] <hatch> haha ok good point
[14:30] <hatch> tbh the thing which really irritated me with them was their lack of support
[14:30] <jrwren> i thought it was $80/$40 :p
[14:30] <hatch> it amounted to "have you tried turning it off and on again" :P
[14:31] <hatch> urulama what version of parallels are you running? 
[14:32] <urulama> hatch: 9
[14:32] <hatch> I think I'm on 8, which might be the problem....
[14:32] <hatch> nothing above 12.04 will run on it without display issues 
[14:32] <urulama> hatch: oh, yes, if you want to run 14.04
[14:33] <urulama> hatch: even 9 has display issues with 14.04, so if you don't want to change that xorg conf file, don't bother ugrading
[14:33] <jrwren> 8 on 10.9 is terrible. They really don't support the old version on the newer OSX. They shouldn't claim to. They are wrong to claim ot.
[14:34] <hatch> I have Ubuntu running on metal on this thing....it just needs a few driver/kernel updates so hopefully those will come soon
[14:38] <arosales> stokachu: hello
[14:38] <arosales> rick_h__: re bug 1317109
[14:38] <_mup_> Bug #1317109: unable to override login password <add-user-story> <cloud-installer> <juju-core:Triaged> <juju-gui:Won't Fix> <https://launchpad.net/bugs/1317109>
[14:39] <arosales> what is the recommended way to pass the admin password to the web login for juju-gui. I thought it was a charm config, but thought I would ping here.
[14:40] <jrwren> i'll put ubuntu on this mac... eventually :)
[14:41] <hatch> arosales hey he is gone until Tuesday
[14:42] <hatch> arosales is this so you can log in automatically like quickstart does?
[14:42] <jrwren> urulama: if you like, here is patch for brew juju formula for --devel to be 1.19.4 http://pastebin.ubuntu.com/7742234/
[14:42] <urulama> jrwren: tnx
[14:43] <arosales> hatch: correct
[14:44] <hatch> arosales ok it does it by generating a single use login token 
[14:44] <hatch> might I ask what the end goal is and I can hopefully provide a solution? 
[14:45] <stokachu> hatch, with our openstack installer we have the abilty to set a common password for several services
[14:45] <stokachu> most openstack credentials including horizon dashboard
[14:45] <stokachu> we offer juju-gui for a visual on th eopenstack installaion but we are unable to set that password to the one defined in our installer
[14:46] <hatch> right, hmm ok
[14:47] <arosales> to have the cloud-installer lauch the gui in a similar fashion as quickstart. stokachu may have some addtional input.
[14:47] <stokachu> does quickstart update the jenv file to a new password after deployment?
[14:47] <stokachu> i think it reads admin-password
[14:47] <hatch> so each subsequent loading of the GUI requires the password, the token is single use only....is that ok with you guys or do you want to default the password all the time?
[14:48] <hatch> stokachu no the login token is entirely separate
[14:48] <stokachu> preferably a default password that wouldnt change
[14:48] <stokachu> ah ok
[14:48] <hatch> but one that's not the admin-secret?
[14:48] <stokachu> hatch, as long as i could deploy juju-gui with a 'ui-pass' or something so that someone could login that way
[14:48] <hatch> like, you want to say 'GUI here is your password, log in with this one all the time' 
[14:48] <stokachu> yea
[14:49] <hatch> ok atm that's not possible 
[14:49] <hatch> your best bet is to create a bug report in the gui project so that rick can get it into the queue 
[14:49] <stokachu> yea it was set to wont fix :(
[14:50] <hatch> oh really.....interesting
[14:50] <hatch> have a link?
[14:50] <hatch> jujugui call in 10 kanban now
[14:50] <stokachu> https://launchpad.net/bugs/1317109
[14:50] <_mup_> Bug #1317109: unable to override login password <add-user-story> <cloud-installer> <juju-core:Triaged> <juju-gui:Won't Fix> <https://launchpad.net/bugs/1317109>
[14:50] <stokachu> im not sure what juju-core will do to help this
[14:50] <frankban> hatch: so, the password charm option does not work?
[14:51] <stokachu> frankban, i tried that and it doesn't seem to
[14:51] <hatch> stokachu well the GUI needs the 'real' admin-secret to send to core to log in
[14:51] <stokachu> gotcha
[14:52] <frankban> stokachu: so, that seems to be a charm bug, separated to the one you linked. If the charm exposes an option like that, and warns about the risks, that should definitely work
[14:53] <frankban> stokachu: trying the charm locally
[14:53] <arosales> hatch: if stokachu is setting up their environments.yaml he should know or set the admin password and pass that value via the 'password' config option, correct?
[14:53] <stokachu> frankban, that password could be for the credentials to the websocket on juju?
[14:53] <hatch> arosales correct
[14:54] <hatch> arosales but it seems that that option isn't working
[14:54] <frankban> stokachu: the GUI uses the same password
[14:54] <hatch> we'll know shortly
[14:54] <hatch> now that frankban is on it :)
[14:55]  * arosales agrees with frankban, if that doesn't work its a valid bug
[14:56] <stokachu> frankban, i set the 'password' config option in my test, is that the one youre using?
[14:57] <frankban> stokachu: yes, I am trying it now and check if it works with "juju set"
[14:57] <stokachu> ok
[14:57] <hatch> thanks frankban 
[14:58] <hatch> jujugui call in 2
[14:58] <arosales> stokachu: and frankban and to confirm the value for the password string is the admin password found for the given environment in ~/.juju/environment.yaml, correct?
[15:00] <hatch> jrwren call 
[15:00] <jrwren> i must be hitting wrong url
[15:00] <jrwren> http://tinyurl.com/jujugui ?
[15:00] <jrwren> yup, wrong url
[15:01] <hatch> in your calendar there should be a link
[15:01] <kadams54> Sneaky, isn't it?
[15:09] <hatch> haha
[15:10] <hatch> kadams54 I'll pull down your branch but I'm assuming we can 'just deal' with the blue dot for now :)
[15:10] <hatch> frankban how goes the password field test?
[15:11] <kadams54> hatch: I also have an e-mail out to Spencer to see if I can get the service block with a blue border asset.
[15:11] <bac> hey rogpeppe, what's the difference between 'map[string] []Id' and 'map[string] Meta' ?
[15:11] <hatch> arosales yes the password is the admin-secret in the environments.yaml
[15:11] <frankban> stokachu: using "juju set juju-gui password=..." worked here: the GUI automatically logs me in
[15:11] <hatch> ^ arosales 
[15:11] <bac> rogpeppe: and don't say Id vs Meta :)
[15:11] <kadams54> hatch: Even though it's not *technically* in scope for this ticket, it seems like having both the blue border and the indicator dot should go together.
[15:11] <hatch> kadams54 cool, isn't it an svg, so you can just edit the file? Or is it too complex? I've never actually looked into it
[15:12] <stokachu> frankban, so you set the password, went to the web ui, typed admin/password and it worked?
[15:12] <rogpeppe> bac: in JSON, one looks like {"foo": ["id1", "id2"]}; the other looks like {"foo": {"name": "a name", etc}}
[15:12] <kadams54> I talked with Makyo about it last night and he said we'd need a new asset. But I didn't think about modifying the existing SVG directly… I'll take a look.
[15:12] <hatch> stokachu no setting the password to the admin-secret will auto log it in
[15:12] <rogpeppe> bac: oops, not quite
[15:12] <hatch> that won't let you set a 'custom' password
[15:12] <bac> rogpeppe: so the second is a not a list?
[15:12] <frankban> stokachu: no, I set the password to the real juju one, and then the GUI does not even show the log in form, it just shows you the canvas
[15:13] <rogpeppe> bac: the second holds a single item for each entry in the map
[15:13] <rogpeppe> bac: the first holds a list of items for each entry
[15:13] <stokachu> i see
[15:13] <bac> rogpeppe: so for expand ids, you want to return a list of expanded ids per requested id or just a one-to-one mapping?
[15:14] <rogpeppe> bac: the first one will actually look like: {"foo": [{"id": "precise/wordpress-23", "revision": 23, "series": "precise"}, ...}
[15:14] <rogpeppe> bac: given the name of the path, what do you think? :-)
[15:14] <rogpeppe> bac: (the former)
[15:14] <bac> rogpeppe: that's why i'm asking
[15:15] <rogpeppe> bac: perhaps you could suggest a better way of wording the explanation. i *thought* it was unambiguous, but evidently not
[15:15] <bac> rogpeppe: can we do a hangout?
[15:15] <rogpeppe> bac: join us in the standup
[15:15] <frankban> stokachu: basically the charm generates a config file for the GUI (you can see it going directly to https://<GUI URL>/juju-ui/assets/config.js . By default, the password is null there, with juju set you can re-generate the config to include the password (and that means setting the password like that is very insecure)
[15:16] <stokachu> juju set juju-gui password=.. the preferred way?
[15:17] <frankban> stokachu: but that's an option if you really really want to do that. The other (better) possibility is to generate a timed one-shot password as done by quickstart
[15:18] <stokachu> frankban, the one time password is generated each time the webui is accessed?
[15:18] <frankban> stokachu: or just use quickstart to open the GUI
[15:18] <stokachu> does it prompt people to use the login form?
[15:19] <frankban> stokachu: the one time password can be generated by making an ws API call to the GUI server, the response of which includes a uuid that can in turn be used as a quiry string when accessing the GUI
[15:20] <stokachu> ok
[15:20] <frankban> stokachu: if you refresh the GUI, you should be still logged in. If you log out or use another browser, you must generate another one time password
[15:20] <frankban> stokachu: quickstart does that and works well with already bootstrapped environments
[15:21] <stokachu> ok thanks
[15:22] <frankban> stokachu: here is an example of how to create the auth token: http://bazaar.launchpad.net/~juju-gui/juju-quickstart/trunk/view/head:/quickstart/juju.py#L60
[15:22] <frankban> stokachu: and it can be used like this: http://bazaar.launchpad.net/~juju-gui/juju-quickstart/trunk/view/head:/quickstart/manage.py#L556
[15:22] <stokachu> frankban, ok cool 
[15:29] <kadams54> hatch: was able to modify the existing SVG. Pushed the updated code to my branch. Now that I see the border + indicator in action, it's pretty noticeable and IMO should be behind the flag.
[15:30] <hatch> kadams54 ok I'll wait for review then
[15:34] <frankban> bac: could you join the hangout again?
[15:35] <kadams54> hatch: all changes pushed; review away.
[15:35] <arosales> stokachu: also if you are setting up the environment. Suggest you set the ~/.juju/environments.yaml admin password to something like 4testingPlzchange, and then when you deploy the juju-gui deploy the charm with your customer config. Thus you don't have to do a config-set post deploy.
[15:35] <bac> frankban: sure
[15:36] <stokachu> arosales, yea for simplicity sake we'll probably do that
[15:43] <arosales> stokachu: cool
[15:57] <hatch> w00t I think CI is fixed.....we'll see....we'll see
[15:59] <hatch> kadams54 ermahgerd that's blue
[15:59] <hatch> lol
[15:59] <hatch> is there a mockup I can compare to?
[16:04] <kadams54> Yeah
[16:04] <kadams54> hatch: http://cl.ly/image/2n3f3S312819
[16:05] <hatch> kadams54 ahh ok so we will need new assets then
[16:05] <kadams54> hatch: eh?
[16:05] <hatch> the border is much thinner and gradiented 
[16:06] <hatch> gradient'd 
[16:06] <hatch> has a gradient
[16:06] <hatch> yeah that one
[16:06] <hatch> :)
[16:06] <hatch> and the little handles are grey still
[16:07] <kadams54> hatch: I don't think we need any more assets for this card.
[16:07] <hatch> not this card, send an email and create a follow-up pending the new asset
[16:07] <hatch> see PR
[16:08] <hatch> btw - taking a screenshot on a retina then downscaling it makes images HUGE!!!!!!
[16:08] <hatch> lol
[16:08] <kadams54> Yes, well… talk to our designers. I don't have a retina!
[16:09] <kadams54> The service blocks have looked slightly different (thinner border, gradient, slightly different shape) on the mocks for some time now.
[16:15] <kadams54> It also seems like I've seen several variations in different mocks. I just assumed that that was because they were still playing around with different designs.
[16:16] <hatch> oh that's possible
[16:17] <jrwren> whoa, i just noticed that jujugui charm uses pip to install things from pypi, have you noticed many cases where pypi fails?
[16:17] <hatch> jrwren the charm has everything self contained
[16:17] <hatch> it must work without an internet connection
[16:17] <jrwren> ah, so its pip installing from the charm?  cool.
[16:19] <frankban> jrwren: yes, it does not use PyPI. however, it needs to apt install some packages from the ubuntu repositories
[16:24] <jrwren> saw that. python-pip being one of them
[16:34] <jcsackett> hatch__: what part of my work is blocking you? state code, or something else?
[16:36] <hatch__> jcsackett the inspector dispatcher and internal inspector dispatching 
[16:36] <hatch__> when the user clicks the relation link I need to open the inspector and switch to the relation tab
[16:38] <hatch> jcsackett but it's ok I have more than enough other stuff to do
[16:38] <hatch> it's not blocking me, just the card :)
[16:40] <jcsackett> hatch: ok.
[16:42] <jrwren> why does the mongodb for localdb use so much space?
[16:43] <hatch> jrwren hmm I haven't noticed
[16:43] <hatch> how much are you seeing?
[16:43] <jrwren> 1G on one host, 6G on another.
[16:44] <hatch> yikes!
[16:44] <hatch> definitely worth asking in #juju I've never seen that before
[16:44] <jrwren> ok
[18:06] <hatch> since the internet has been down I've found that I burn about 1GB/day of data during work
[18:07] <hatch> would likely be 2GB but I've cut out my youtube/streaming habit  :)
[18:07] <hatch> add netflix into there, probably burn through 4GB/day easily
[18:07] <hatch> ouch
[18:11] <jcsackett> jujugui: 1st of several reviews, please https://github.com/juju/juju-gui/pull/422
[18:11] <hatch> heh on it
[18:11] <jcsackett> hatch: just noticed i didn't lint it.
[18:12] <jcsackett> i'll ping you in a moment when lint changes go up.
[18:12] <jrwren> hatch: only 120GB/month, well under comcast's 250GB faux-limit ;]
[18:13] <hatch> jrwren I'm using our crown corp telco, we don't have no BS "limits"
[18:13] <hatch> unlimited cell and internet data
[18:13] <hatch> jcsackett sure np
[18:24] <jcsackett> hatch: ok, it's updated.
[18:24] <jcsackett> and i'm grabbing some lunch.
[18:25] <hatch> yeah I'm also going to do just that
[18:25] <hatch> I'll review when I get back
[18:40] <hatch> jcsackett test failure
[18:40] <hatch> looks like a dependency issue
[19:03] <jrwren> cs: is charmstore, right?  
[19:03] <jrwren> i'm trying to repro https://bugs.launchpad.net/charms/+source/juju-gui/+bug/1333159
[19:04] <_mup_> Bug #1333159: Unable to upgrade juju-gui <juju-gui (Juju Charms Collection):Triaged> <https://launchpad.net/bugs/1333159>
[19:04] <hatch> jrwren it is
[19:04] <hatch> looking
[19:04] <jrwren> i deploy cs:trusty/juju-gui-2 no problem, but an upgrade does not seem to use git.
[19:05] <bac> jrwren: cs: does stand for charmstore but it is protocol for our charm urls
[19:05] <jrwren> uniter.charm git_deployer says no current staging repo
[19:05] <jrwren> do I need to do something special to make the unit use a staging repo?
[19:05] <jrwren> or... i wonder if this is actually a bug in juju which is already fixed.
[19:07] <bac> jrwren: juju previously used git but now it does not.  if the original filer had mentioned which juju version we'd know.
[19:07] <jrwren> i'll ask for that info in the bug
[19:08] <hatch> sorry got distracted, thanks for helping bac
[19:16] <jcsackett> hatch: well dammit.
[19:17] <hatch> jcsackett heh yeah you got to run make test-debug test-prod :)
[19:21] <jcsackett> ...huh. i'm not sure how to debug it if it only occurs on test-prod...because there's no test-prod-server is there?
[19:22] <hatch> jcsackett you bet there is :)
[19:23] <hatch> jcsackett there was no service inspector tests?
[19:24] <hatch> I was sure there was
[19:24] <jcsackett> hatch "ack service-inspector test" revealed nada.
[19:24] <jcsackett> so if there are, they're not requiring the module.
[19:24] <jcsackett> and nothing was named such.
[19:24] <jcsackett> browser_app does some implicit testing.
[19:25] <hatch> cra'cra'yo
[19:25] <hatch> I'll leave you to debugging your dependency issue...they are a pita!
[19:26] <hatch> but when you do find it, be sure to add it to the module that requires it, not just the test suite :)
[19:29] <hatch> eventually we'll be able to switch to es6 modules and no longer have these issues
[19:32] <bac> jujugui: someone *just* told Delta about the hurricane.  i'm going to defer my flight to saturday, meaning i'll work tomorrow and take monday as a swap.
[19:33] <hatch> bac sure np, better safe
[19:33] <hatch> where are you going?
[19:33] <bac> obx
[19:33] <hatch> ahh 
[19:36] <jcsackett> bac: i'll hope where you staying isn't hit too bad. :)
[19:36] <bac> jcsackett: me too!  hope to not spend next week cleaning up.
[19:48] <kadams54> guihelp: are there docs for the RPC API being used in app/store/env/go.js?
[19:48] <hatch> kadams54 you mean beyond RTFS?
[19:48] <hatch> ;)
[19:48] <kadams54> Hah!
[19:49] <hatch> kadams54 what kind of questions did you have?
[19:49] <hatch> frankban knows all the answers but I can do my best :)
[19:49] <kadams54> Well the remove service/container/machine methods are going to need to invoke API calls
[19:50] <jcsackett> hatch: i think i've sorted it; bad dependencies in the test, nothing in the modules.
[19:50] <jcsackett> frankly baffled that test-debug worked, actually.
[19:50] <hatch> jcsackett well...really we should only need to include a single module in the tests and the rest should be resolved
[19:50] <jcsackett> hatch: yeah...that's so not true of *so* many tests. :p
[19:53] <hatch> jcsackett lol I know!
[19:54] <hatch> which one was missing?
[19:54] <hatch> kadams54 those aren't already implemented in the backend?
[19:55] <hatch> kadams54 destroyMachines is there destroy_service
[19:56] <hatch> is there
[19:56] <hatch> so everything is implemented already from the environment side of things
[19:56] <kadams54> I'm working on services right now… I didn't see anything in go.js or environment_change_set.js…
[19:57] <hatch> both destroyMachines and destroy_service are in go.js
[19:57] <kadams54> Bah… I was looking for remove_service
[19:57] <kadams54> OK, carry on, ignore me
[19:57] <jcsackett> hatch: when i cribbed from ghost-inspector for inspector module i did a bad copy paste, and pasted ghost-service over regular service.
[19:58] <hatch> the guy is here fixing the internet....hopefully heh
[19:58] <hatch> so when he is done we can have a call and I can show you all the stuff
[19:58] <jcsackett> again: baffled test-debug passed.
[19:58] <hatch> if you like
[19:58] <hatch> ohh - I think test-debug passes because there is some leakage on the modules
[19:58] <hatch> whereas prod doesn't include anything that's not explicitly defined
[19:58] <jcsackett> that makes sense.
[20:01] <hatch> we still really need to refactor the damn system
[20:01] <hatch> heh
[20:15] <hatch> jcsackett so is it all updated now?
[20:15] <hatch> the PR i mean
[20:15] <jcsackett> hatch: i'm rebasing to clean up before you start your review and to kick off another test run.
[20:15] <jcsackett> b/c i want to see what just failed fail again, b/c i can't make it happen locally.
[20:15] <hatch> ahh ok cool np
[20:16] <jcsackett> ...and this is just the service details bit. still not getting to the unit bit.
[20:17]  * jcsackett does not feel like he's had good luck with cards lately.
[20:17] <jcsackett> :p
[20:18] <hatch> jcsackett this is the intermittent test failure
[20:18] <hatch> the two attempts I made at fixing it apparently were for naught 
[20:18]  * hatch has sadface
[20:19] <jcsackett> hatch: i'm very sorry it didn't work.
[20:19] <jcsackett> i am however thrilled that this ain't my branch. :)
[20:20] <hatch> haha
[20:20] <hatch> oh great I get another temporary line running across my backyard
[20:20] <hatch> those drillers sure made a mess
[20:24] <jcsackett> hatch: fun times.
[20:25] <jcsackett> i like, btw, that "above ground power" is an exception for you.
[20:25] <jcsackett> also, the PR is all up to date.
[20:25] <hatch> jcsackett lol - well this is like a wired in extension cord, not like coming from a pole :)
[20:25] <hatch> so it's even one step further down from "from a pole" power :D
[20:26] <jcsackett> hatch: oooh.
[20:26] <jcsackett> hatch: that does sound super dodgy. :p
[20:26] <hatch> yeah apparently they now need to directional drill to my house to run the new lines....
[20:26] <hatch> someone is gona get one big "oops" bill
[20:28] <jcsackett> hatch: what are you having done?
[20:29] <hatch> they are installing fiber into the neighbourhood 
[20:30] <hatch> so yay for faster internet, sadface for the mess they are making
[20:47] <hatch> back on land line
[20:47] <hatch> download-all-the-things!!!
[20:59] <hatch> kadams54 you had some issues using event simulate and view handlers right?
[20:59] <jrwren> Alright ya'll, I'm gone until Monday for American holiday. Have a great weekend.
[21:00] <hatch> jrwren cya, enjoy the holiday
[21:10] <hatch> kadams54_ you've had issues in the past with simulating events in views right?
[21:10] <hatch> for some reason I can't simulate an event on a view
[21:10] <hatch> the callback is never called
[21:10] <hatch> was hoping you ended up running into this
[21:11] <kadams54_> hatch: not ringing a bell…
[21:12] <kadams54_> Well, OK, I remember having problems with a simulate call… but I can't remember the details.
[21:12] <kadams54_> Let me ponder it for a moment and it should come back.
[21:20] <jcsackett> hatch: have you gotten to look at the PR yet?
[21:20] <hatch> just about to start, I'm at a loss about this problem so a break is needed
[21:25] <jcsackett> hatch: lemme actually put up a different PR. i've solved the event issue for units, so that's done now too.
[21:25] <jcsackett> (unless you got into it in the last five minutes, in which case carry on)
[21:25] <hatch> a new PR or just updating this one?
[21:29] <jcsackett> hatch: nevermind. go ahead and finish that review and i'll push up the other one after.
[21:29] <jcsackett> it'll make the second one super easy to read through.
[21:29] <hatch> ok sounds good
[21:30] <hatch> jcsackett ok why did you do this to previousInspector
[21:30] <hatch> so confused
[21:30] <hatch> heh
[21:31] <jcsackett> hatch: do what now?
[21:31] <jcsackett> i left some comments in the PR explaining some of it.
[21:31] <hatch> you removed var previousInspector = this._activeInspector; 
[21:32] <hatch> oh, so unsetting the variable for the single case didn't work?
[21:36] <jcsackett> hatch: nope.
[21:36] <jcsackett> so we only set previousInspector when we know we want to destroy it.
[21:37] <hatch> seems flimsy, ok still looking
[21:40] <jcsackett> hatch: how is it flimsy? whenever we create a new inspector, we store the old one?
[21:41] <hatch> jcsackett it's just not clear why it's done the way it's done
[21:41] <jcsackett> the only reason we did it globally before was b/c we *always* deleted the previous inspector.
[21:41] <hatch> so future us will have to re-investigate
[21:42] <jcsackett> i mean, i can throw in a comment.
[21:42] <hatch> yeah I'm still looking to see if there is any alternative
[21:46] <stokachu> so does the charmstore have an api exposed to pull a revision of a charm?
[21:48] <hatch> stokachu add -### to the end
[21:48] <hatch> for the charm version
[21:48] <hatch> where ### is the versin
[21:48] <stokachu> what if i just want to find the latest?
[21:49] <hatch> don't have a -##
[21:49] <hatch> :)
[21:49] <stokachu> if i call ServiceDeploy within juju api, it requires a charmUrl
[21:49] <hatch> https://jujucharms.com/precise/mysql-46/ vs https://jujucharms.com/precise/mysql-43/
[21:49] <stokachu> which requires cs:series/charm-rev
[21:49] <hatch> see the `Location:` in the heading of the details pane that opens
[21:50] <stokachu> so i need to scrape the page and grab that url?
[21:50] <stokachu> no json data is exposed via the charmstore?
[21:51] <hatch> stokachu sure, see the net tab in the browser console for the response from the charmstore
[21:53] <hatch> stokachu here for example https://manage.jujucharms.com/api/3/charm/precise/mysql-43
[21:53] <stokachu> hatch, perfect just what i was looking for
[21:54] <stokachu> even has a url field
[21:54] <stokachu> even better!
[21:54] <hatch> excellent
[21:54] <stokachu> thanks :D
[21:54] <hatch> anytime
[22:02] <kadams54_> hatch: Sorry, I'm drawing a blank. The callback not firing just doesn't seem right. It seems like my problem was more with the event object and the data being passed to it. That said, I can't remember for sure, so all bets are off.
[22:06] <hatch> ok I'm going to have to create a repro to see if it's something else
[22:06] <hatch> thanks
[22:06] <hatch> jcsackett ok review done, I think there is an existing approach that will fit a little nicer
[22:07] <hatch> take a look and let me know what you think
[22:07] <hatch> kadams54_ did you want to chat about the environment stuff? and how it interacts with the ecs?
[22:07] <hatch> or do you got it
[23:00] <huwshimi> Morning
[23:12] <jcsackett> hatch: thanks for the comments. i'll have to attend to these on monday.
[23:13] <hatch> jcsackett ok np
[23:13] <hatch> have a good break
[23:13] <hatch> huwshimi morning
[23:13] <huwshimi> hatch: Hey
[23:13] <hatch> huwshimi I unfortunately have run into an issue when writing the tests for my latest changes
[23:13] <huwshimi> hatch: Oh
[23:14] <hatch> simulating a click event is not being caught in the view's container
[23:14] <hatch> and i have no idea why
[23:15] <huwshimi> hatch: Want me to take a look?
[23:15] <hatch> sure just a sec I'll push this up
[23:17] <hatch> huwshimi https://github.com/hatched/juju-gui/tree/hook-up-scaleup
[23:17] <hatch> do you know how to pull this down?
[23:17] <hatch> and continue working on it?
[23:17] <huwshimi> hatch: Yep, all good
[23:18] <hatch> awesome - ok so the issue is that I simulate a click on the + but the `_toggleScaleUp` method is never triggered
[23:18] <hatch> it's not even a race, it just never happens
[23:18] <hatch> if I attach an event listener the event is simulated, but for some reason it's not being caught
[23:19] <hatch> I'm hoping you have better luck heh
[23:20] <huwshimi> Let's see :)
[23:22] <hatch> there are a number of possible ui interactions with the view so doing it via simulate i think is the only way to really get it
[23:25] <jcsackett> hatch: have a good weekend. :)
[23:43] <huwshimi> hatch: http://paste.ubuntu.com/7744570/
[23:43] <huwshimi> hatch: You need to render the view to a container in the DOM for the simulate events to work.
[23:46] <hatch> ohhhh son of a
[23:46] <hatch> thanks!
[23:46] <hatch> lol
[23:46] <hatch> that kind of makes sense
[23:46] <hatch> sheesh
[23:46] <huwshimi> :)
[23:46] <hatch> thanks so much
[23:47] <huwshimi> hatch: Just a fresh set of eyes :)
[23:48] <hatch> ugh man I spent so much time on that
[23:48] <hatch> yep I guess so
[23:48] <hatch> or u r just super smart
[23:48] <hatch> :)
[23:49] <huwshimi> hatch: Well, I didn't want to brag
[23:50] <hatch> haha