[00:00] <huwshimi> hatch: I thought I had all those states correctly created, but I must have broken something
[00:02] <huwshimi> hatch: You're branch will be a lot simpler then too.
[00:03] <hatch> otp sec
[00:09] <hatch> huwshimi nope I should only ever have one class applied
[00:09] <hatch> where are you seeing two?
[00:10] <huwshimi> hatch: Oh, I thought here you set two: https://github.com/juju/juju-gui/pull/425/files#diff-0ed25fe35627272b0f6b928691ad7f44R165
[00:14] <hatch> hmm looking 
[00:17] <hatch> huwshimi right I'm setting two there because I need the per machine constraints message shown but not the edit constraints inputs
[00:17] <hatch> so what it does it basically cascade setting only the last one
[00:17] <hatch> or is it....
[00:17] <hatch> hmm
[00:18] <hatch> maybe that's a typo
[00:18] <hatch> heh sorry long day
[00:18] <hatch> lemme check
[00:18] <huwshimi> hatch: Yeah, it looks like it.
[00:18] <huwshimi> hatch: Which begs the question, why do you track the state of all the classes then, why not just set the one you want?
[00:20] <huwshimi> The whole point of setting a single state class is so that you don't have to track the state of the UI
[00:21] <hatch> right so that was a typo
[00:21] <hatch> and because of that you make a good point
[00:21] <hatch> well that's irritating
[00:22] <hatch> huwshimi thanks I'll fix this up tonight 
[00:22] <hatch> it's clearly been a bad few days lol
[00:22] <huwshimi> hatch: haha, everything OK?
[00:22] <hatch> oh yeah, this is just the branch that doesn't end
[00:24] <huwshimi> hatch: I think you're just over complicating it :)
[00:25] <hatch> it's gone from level 10 complexity down to about a 2 after your comments haha
[00:25] <huwshimi> hatch: i expect that diff will halve in size :)
[00:26] <hatch> at least
[00:28] <huwshimi> :)
[04:06] <hatch> huwshimi hey when is your EOD/
[04:06] <hatch> ?
[04:06] <huwshimi> hatch: In four hours
[04:07] <hatch> nice - want to do a review/qa on my branch when I finish it?
[04:07] <huwshimi> hatch: Sure
[04:07] <hatch> awesome thanks
[04:07] <hatch> I went out so now I'm back to get this darn branch done
[04:07] <hatch> haha
[04:10] <huwshimi> hatch: Good luck!
[04:32] <hatch> alllllmost done
[04:32] <huwshimi> yay
[04:32] <hatch> it's fast when you've done it so many times over already
[04:32] <hatch> :D
[04:33] <huwshimi> hehe
[04:37] <hatch> huwshimi https://github.com/juju/juju-gui/pull/425 let'r'rip
[04:39] <huwshimi> hatch: Looks like you need a rebase with all those commits there before it lands
[04:40] <hatch> yeah I'll rebase it down to 1
[04:40] <hatch> sec
[04:40] <hatch> well...once you qa/review it
[04:40] <hatch> having separate commits helps remove unused code
[04:40] <hatch> haha
[04:43] <huwshimi> hatch: Code looks good, just qaing
[04:48] <huwshimi> hatch: Looks good. See that wasn't so hard :)
[04:49] <hatch> lol
[04:50] <hatch> and rebased
[04:51] <hatch> huwshimi so once this lands there is the car 'finish styling for scale-up UI' is now unblocked for you
[04:51] <huwshimi> hatch: Nice one. Thanks for sticking with it!
[04:51] <huwshimi> hatch: Yep, thanks.
[04:52] <hatch> it's much better now - good idea with the css, even if you think it's my idea
[04:52] <hatch> :P
[04:52] <huwshimi> hatch: It was!
[04:52] <hatch> lol ooookkkkk
[04:52] <hatch> if it works out at scale I'll take credit then
[04:52] <hatch> up until then...your idea
[04:52] <hatch> lol
[04:52] <huwshimi> haha
[05:12] <hatch> I'm heading out, have a good day huwshimi 
[05:12] <hatch> cya
[05:13] <huwshimi> hatch: Night
[06:02] <urulama> huwshimi: hello australia
[06:03] <huwshimi> urulama: Good morning Slovenia
[06:09]  * urulama goes through mails, always fun to see how work moves with the Sun across the globe :D
[06:55] <rogpeppe> urulama, huwshimi: mornin'
[06:55] <huwshimi> rogpeppe: Morning
[06:55] <urulama> morning, rogpeppe
[09:18] <frankban> rogpeppe: morning, how are you doing?
[09:18] <rogpeppe> frankban: hiya
[09:18] <rogpeppe> frankban: good, thanks
[09:18] <rogpeppe> frankban: shall we continue?
[09:20] <frankban> rogpeppe: sure, I'll be in https://plus.google.com/hangouts/_/canonical.com/gogogo in one minute
[09:34] <rogpeppe> urulama: have you finished reviewing?
[09:34] <urulama> rogpeppe: em, yes, sorry, LGTM
[09:35] <rogpeppe> urulama: could you add the LGTM to the review, please?
[09:35] <frankban> urulama: cool thanks can you add a comment?
[09:35] <rogpeppe> urulama: i've just made the README.md change, BTW
[09:35] <urulama> rogpeppe: it's in the tests as well
[09:35] <rogpeppe> urulama: yup
[09:35] <rogpeppe> urulama: all changed
[09:36] <rogpeppe> urulama: (it was also in the sample bundles under testing/repo
[09:36] <rogpeppe> )
[09:38] <urulama> rogpeppe: anything else needed then the comment on https://github.com/rogpeppe/charm/commit/62a7a846075d080e6a36d0025f7fe6e85cd12144 ?
[09:39] <rogpeppe> urulama: sorry, i don't understand the question?
[09:39]  * urulama is still learning the process
[09:39] <rogpeppe> urulama: ah, no, LGTM is good
[09:39] <rogpeppe> urulama: or :shipit:
[09:40] <urulama> rogpeppe: :shipit", ... 3, 2, 1 ... off it goes ... kaboom ...
[09:41] <rogpeppe> urulama: actually, you shouldn't be the one saying ":shipit:"
[09:41] <rogpeppe> urulama: LGTM or +1
[09:42] <urulama> rogpeppe: after only a week, i'm not sure my "LGTM" counts for much as well ;)
[09:42] <rogpeppe> urulama: :-)
[09:43] <rogpeppe> urulama: we'll get a review from someone on juju-core too
[10:37] <rogpeppe> urulama: we're looking into the existing store code, getting an idea for how it works and how we might need to change it
[10:37] <rogpeppe> urulama: we wondered if you might care to join us
[10:38] <urulama> rogpeppe: sure, not that i think i'll help much :D
[10:38] <urulama> this?
[10:38] <urulama> https://plus.google.com/hangouts/_/canonical.com/gogogo
[10:39] <urulama> rogpeppe: noone there :D
[10:40] <urulama> rogpeppe: i mean, only empty seats :D
[10:43] <urulama> frankban: http://pastebin.com/2T5Szyd1
[11:30] <rick_h__> morning
[11:37] <jrwren> morning
[12:25] <rick_h__> jrwren: how goes? Did you get the charm tests to run yesterday?
[12:25] <jrwren> I did not.
[12:26] <jrwren> I was going to ask how most folks do it.
[12:26] <jrwren> Lack of local is a real bummer.
[12:26] <jrwren> Do folks just use AWS? or their home openstack?
[12:26] <jrwren> I've not pointed juju at my devstack just yet.
[12:26] <rick_h__> jrwren: yea, run it via ec2. juju bootstrap ec2 && make test -e ec2
[12:26] <jrwren> such a bummer. I've been really digging local :)
[12:27] <rick_h__> jrwren: you can expense each month a chunk of time for work related stuff. It's why the startup docs wanted to get credentials unique for work 
[12:27] <jrwren> sounds good.
[12:27] <rick_h__> jrwren: yea, local is a game changer for dev workflows
[12:27] <jrwren> I'm more thinking of the speed of execution.
[12:27] <rick_h__> right
[12:29] <urulama> jrwren: frankban said that it took an hour and even more sometimes on a local. so. no that useful :(
[12:29] <jrwren> really?!?
[12:30] <urulama> i can't see why either.
[12:30] <jrwren> i was even considering tinkering with manual
[12:31] <rick_h__> I thought there was some technical limitation. Local doesn't support some of the test cases I thought. It's a bit of a step-child as it doesn't have provider storage/etc
[12:31] <urulama> jrwren: writing manual with automatically bootstraped machines (without add-machine ssh:IP)?
[12:31] <rick_h__> manual is even more step-child heh
[12:31] <jrwren> i don't know. I'm not familiar with juju manual at all.
[12:32] <rick_h__> I used it for the CI setup on rackspace for bookie since rackspace isn't a supported provider
[12:32] <jrwren> oh cool. that is GTK rick_h__ !
[12:32] <rick_h__> it's cool, nice to be able to use the charms
[12:32] <rick_h__> but a pita to manual bring up the machines/etc. 
[12:33] <rick_h__> hazmat: wrote a layer over digital oceans api to work with the manual provider which smooths out some edges. 
[12:33] <jrwren> i got reasonably good with nova cli at my last gig
[12:33] <rick_h__> so manual provider is cool and useful for those cases, but not something I look to use unless I have to :)
[12:33] <urulama> rick_h__: what if only a switch would be added so that the env is not bootstraped, just used?
[12:34] <rick_h__> urulama: for the charm tests?
[12:34] <urulama> on manual
[12:34] <rick_h__> on manual...I'm not following I guess. 
[12:34] <rick_h__> If you don't bootstrap an env,  you don't have state tracking services to do anything? 
[12:35] <urulama> rick_h__: the env could already be bootstraped, that was a suggestion
[12:36] <rick_h__> urulama: ok, so it's bootstrapped by something, so you've manually brought up a machine, done the bootstrap step, and now it's in manual mode still. I'm missing the bit that's changed. 
[12:36] <jrwren> urulama: you mean run charm tests against already bootstrapped env?
[12:36] <urulama> jrwren: yes
[12:41] <hazmat> manual provider to me is the bees knees ;-)
[12:42] <hazmat> need storage, need networking, need flexibility for the real world.. manual provisioning and placement.. automated of course ;-)
[12:42] <urulama> hazmat: +1
[12:43] <urulama> hazmat: and for development, just fill your laptops and desktops with VMs and pretend to have a cluster with 10+ hosts :D
[12:44] <hazmat> urulama, yup.. i do that with manual provider as well.. https://github.com/kapilt/juju-lxc/blob/master/juju_lxc/add.py#L37
[12:45] <hazmat> urulama, its a bit rough around the edges.. but i can create containers/machines offline on an airplane with it.
[12:45] <jrwren> i saw the post where someone ran different openstack services in containers and at first I said, "WAT?"
[12:45] <hazmat> need upload-tools cause juju for reasons illogical wants to do a full tools lookup on every add-unit/deploy/add-machine.
[12:45] <jrwren> but for dev it makes some good sense
[12:45] <hazmat> jrwren, prod is going that way too
[12:46] <hazmat> jrwren, it also makes sense
[12:46] <jrwren> hazmat: all in the same KVM
[12:46] <hazmat> jrwren, or spread in containers across multiple kvms
[12:46] <jrwren> http://astokes.org/juju-deploy-to-lxc-and-kvm-in-the-local-provider/
[12:46] <hazmat> its just density and portability
[12:46] <jrwren> oh yes, it makes good sense.
[12:46] <hazmat> jrwren, the openstack cloudinstaller does just that containers in kvm
[12:47] <jrwren> running nova-compute and glance that way doesn't make sense to me.
[12:47] <jrwren> O_O
[12:47] <jrwren> it does?
[12:47] <hazmat> jrwren, they switched up since that blog post.. no longer parallel containers and kvms, they nest lxc in kvm now.
[12:47] <hazmat> jrwren, yup
[12:47] <jrwren> doesn't make much sense to me.
[12:48] <jrwren> oh, THAT cloud-installer.
[12:53] <urulama> hazmat: yes, offline is nice ... we made a demo with juju & openfoam charm where emergency response people could create local hpc clusters from their laptops on the site of the flood ... it was really cool :D
[12:55] <urulama> hazmat: used ubuntu live, with preinstalled juju and openfoam charms on a usb stick, just use swithc, use the usb in all of them and reboot ... hpc cluster of the fly :D
[12:56] <hazmat> urulama, nice
[12:58] <jrwren> The thing I don't grok re: charm ftest is why --to 0 for juju-gui?
[13:00] <urulama> jrwren: i am only guessing, but would say that you know that it's already up there so deploy of the charm is quicker
[13:01] <jrwren> if that is the only reason, seems like tests could detect local and not --to 0
[13:01] <urulama> jrwren: just guessing
[13:01] <jrwren> but, I thought same thing, and just tried to hack w/out --to 0 in test and use local, and no go :(
[13:02] <jrwren> and I"m not sure why it failed. Hopefully good things to learn.
[13:02] <urulama> jrwren: these are the errors? http://pastebin.com/2T5Szyd1
[13:09] <frankban> urulama, jrwren: colocating ftests to the bootstrap node is a decision we made months ago, when local provider wasn't supported by Juju (IIRC, but surely it wasn't as fast as it is now with templates). Functional tests needs are implemented so that for each test the GUI is deployed, so switching to colocation resulted in a faster test run (~30mins vs ~120 mins) due to the fact we don't have to wait for machines t
[13:09] <frankban> o be provisioned. At the time, juju-test was also the preferred/suggested test runner to use for charms: it handles bootstrapping and destroying environments. I'd also be +1 on adding the ability to reuse an already bootstrapped environment to it. For those two reasons, it is currently impossible to run ftests on local envs, but that can be fixed in a relatively easy way, given a time slot to do that we never had
[13:09] <frankban>  ;-)
[13:10] <jrwren> thanks for the background frankban 
[13:11] <jrwren> urulama: yes, those errors
[13:11] <jrwren> anyway, now I can answer 'yes' to rick_h__.  It runs fine in ec2.
[13:12] <rick_h__> jrwren: woot
[13:12] <rick_h__> jrwren: ok, do you have a branch with any updates to the docs then? 
[13:12] <rick_h__> jrwren: and if so put that up for review via lbox and we can work on moving your card across for today 
[13:13] <jrwren> i'm not sure how to do this becuase I already pushed :parent on Monday?
[13:14] <jrwren> will lbox let me brach review based on a different revno ?
[13:14] <jrwren> or maybe I can branch from a revno and push that to my own branch for review?
[13:14] <frankban> urulama, jrwren: http://bazaar.launchpad.net/~juju-gui-charmers/charms/trusty/juju-gui/trunk/view/head:/HACKING.md#L75
[13:16] <rick_h__> jrwren: right, that's done and gone. However, the idea now is to not push to :parent, but look at updating the docs based on any experience getting the tests ready and to add lbox notes to the docs based on getting lbox installed, working to submit a branch, etc
[13:16] <rick_h__> jrwren: so you'll probably be working on the docs as you go through lbox process and need to update the merge proposal a couple of times 
[13:16] <jrwren> frankban: right, i'd love to be able to remove lines 75-77 from that file :)
[13:17] <jrwren> rick_h__: ah! got it.
[13:17] <frankban> jrwren: cool
[13:32] <frankban> rogpeppe: when you are ready, I am in gogogo
[13:32] <rogpeppe> frankban: ok, cool. am just reviewing a branch elsewhere
[13:32] <rogpeppe> frankban: be with you soon
[13:32] <frankban> cool
[13:59] <jrwren> anyone have a good git to bzr rosetta stone?
[14:00] <rick_h__> jrwren: hmm, not sure. What are you trying to do?
[14:01] <mbruzek> I am trying to deploy a bundle and I am getting an error.  Wondering if you guys could help me with the problem.
[14:01] <jrwren> remove the default remote
[14:01] <mbruzek> Running this command: juju quickstart -n nagios-mediawiki-mysql /home/mbruzek/workspace/bundles/nagios/bundle/bundles.yaml
[14:01] <jrwren> so when I push it wont go to the place it was last.
[14:02] <mbruzek> Getting no errors in the console, but the UI gives me the following notification
[14:02] <mbruzek> An error occurred while deploying the bundle: ('No charm metadata @ %s', 'precise/local:precise/mediawiki/metadata.yaml') 
[14:03] <mbruzek> I see that the path is an issue, but I have edited the bundle to get a correct path and still not working.  
[14:06] <arosales> Hello juju gui folks
[14:06] <arosales> I pushed a bundle last night
[14:06] <arosales> https://code.launchpad.net/~a.rosales/charms/bundles/cf-bundle/bundle
[14:06] <arosales> but I am not seeing it be ingested. I wanted to check here before opening a bug.
[14:07]  * arosales also not seeing https://code.launchpad.net/~maarten-ectors/charms/bundles/storm/bundle in the charm store
[14:14] <rick_h__> arosales: looking
[14:15] <rick_h__> arosales: sorry, take a sec have to get charmtools/ppas on here
[14:15] <rick_h__> arosales: check to make sure they pass proof
[14:16] <jrwren> does lbox infer incorrect branch url on charms?
[14:18] <rick_h__> jrwren: hmm, don't recall. There's a flag to specify. 
[14:18] <rick_h__> I think it tries to infer based on the .bzr/locations information so if you haven't pushed it up to your namespace or what not it might not be 100% right
[14:19] <arosales> rick_h__, will do
[14:21] <rick_h__> arosales: the file name needs to be bundles.yaml
[14:21] <rick_h__> (note the s)
[14:21] <jrwren> rick_h__: indeed. a push --remember fixed it
[14:21] <rick_h__> arosales: charm proof will yell about it not being a bundle
[14:21] <rick_h__> arosales: that's the same for the other bundle as well
[14:23] <jcsackett> hatch: didn't see any PRs from you this morning. you get taken care of?
[14:23] <hatch> jcsackett yep landed
[14:23] <hatch> am I the only one who reviews the closed pr's every day? maybe I have a problem...
[14:23] <hatch> lol
[14:26] <jcsackett> hatch: i certainly don't, but that sounds like a good idea.
[14:26]  * rick_h__ changes location to head home from the coffee shop
[14:26] <jcsackett> hatch: did you get a chance to look at my second PR? it has a test failure, but it's spurious--pushed new revs now to force a rebuild.
[14:26] <hatch> I didn't I thought the error was a bonified one for once....oops sorry I'll take a look now
[14:27] <hatch> you can also manually trigger a build without pushing changes by logging into jenkins
[14:30] <hatch> jcsackett just one small comment, firing up for a qa now
[14:32] <arosales> rick_h__, thanks giving that change a try now
[14:33]  * arosales will wait at least 30 minutes
[14:33] <hatch> jcsackett qa issue, commented in pr
[14:34] <jcsackett> hatch: dammit. :p
[14:34] <jcsackett> ok.
[14:34] <jcsackett> thanks.
[14:34] <jcsackett> hatch: i replied to your other comment.
[14:37] <hatch> cool
[14:37] <hatch> wow chrome is such a poor browser compared to safari on every level except the devtools and available plugins
[14:39] <hatch> it's sad really
[14:40] <jcsackett> the dev tools are really nice though.
[14:40] <jcsackett> and the extension community is better.
[14:41] <hatch> yep...well and that safari is only available on osx
[14:41] <hatch> but it's proof that a browser CAN be better
[14:41] <hatch> rick_h__ I don't think seeing this for my watch is a good sign... https://www.evernote.com/shard/s219/sh/afefea06-4715-4a44-ad3c-542d1a6cd5b7/a2b67c51dfeda456142e3ccc022498b3/res/a7400332-a8b5-4510-b42a-ac45805d4243/skitch.png
[14:43] <kadams54> Makyo: just noticed you're working on delete for containers
[14:43] <kadams54> We may want to collaborate, since I have delete for machines
[14:45] <hatch> I'm pretty sure those two are one and the same :) or really really close to it
[14:45] <hatch> heh
[14:45] <kadams54> Yeah, I think they'll end up being pretty much the same
[14:46] <hatch> well don't they make the same call in the env?
[14:46] <hatch> I may be mis-remembering
[14:48] <kadams54> I don't know about the env, but they both fire the same event and the code to remove the token itself will be 99% the same.
[14:50] <hatch> jujugui call in 10
[14:51] <kadams54> Yeah, containers and machines are the same function call in the env
[14:51] <kadams54> So pretty much dupe cards
[14:58] <Makyo> kadams54, yeah, I noticed that yesterday, we'll have to chat as to the best path forward.  Didn't get too far with that appointment
[14:59] <Makyo> jujugui call in 1
[14:59] <rick_h__> what he said ^
[14:59] <rick_h__> hmm, I feel alone, no one else there? 
[14:59] <rick_h__> or does chrome hate me?
[14:59] <rick_h__> jrwren: rogpeppe frankban ^
[15:00] <rick_h__> bac: kadams54 ^
[15:00] <rogpeppe> uru-afk: standup...
[15:01] <rick_h__> jrwren: kadams54 bac starting without you then
[15:02] <kadams54> joining
[15:11] <Makyo> kadams54, https://plus.google.com/hangouts/_/gtwlcpt2ysfo6qtjdgghqrjfbaa
[15:13] <hatch> jcsackett ping when you get that up and I'll take a look again
[15:13] <hatch> and someone is cooking ribs.......
[15:13] <hatch> concentration gone....
[15:14] <jcsackett> hatch: just a moment. waiting for test run to finish.
[15:15] <jrwren> so... i have two factor on my personal google account too... :)  I'll have to figure out an app specific PW for google
[15:16] <hatch> rick_h__ so in the scale-up UI, if the user chooses to scale up with automatically place, does that mean we need to go and create machines and place the units on them? Or just put them in unplaced and let it auto place on commit?
[15:18] <hatch> I'm guessing create machines and place
[15:18] <hatch> else it's the same as manually place but with setting the constraints
[15:22] <rick_h__> hatch: heh, that went back and forth
[15:23] <rick_h__> at one point, they wanted that to still take you to machine view, but with the machines populated with the units
[15:23] <rick_h__> hatch: so yea, it's got to be in the machine regardless
[15:23] <rick_h__> my debate was around if we force users through machine view in that case
[15:23] <hatch> well if they manually place we can open the machine view on submit
[15:23] <hatch> if they want to auto place we can probably skip that
[15:23] <jrwren> huh, and the LP/google 2-factor integration is different than default google 2-factor, so I still have to user personal acct. 
[15:24] <rick_h__> hatch: right, that's what I was arguing for
[15:24] <rick_h__> jrwren: yea, it defers to our own auth system
[15:24] <hatch> rick_h__ then that is what we will do :)
[15:24] <rick_h__> :) 
[15:26] <hatch> oh look at that, unplaced units don't show up in the machine view
[15:26] <hatch> :/
[15:27] <hatch> they have to be committed first then they show up in both placed and unplaced
[15:27] <rick_h__> you're not making sense so I'm going to stop listening lalalalalala
[15:28] <jrwren> i'm gonna head for an early lunch right now, unless you are read for next step call, rick_h__ ?
[15:28] <hatch> that's probably for the best rick_h__ ....
[15:29] <rick_h__> jrwren: have a good lunch, commenting on your MP right now and can pick up after food
[15:34] <hatch> rick_h__ ok now this branch is blocked until the  add units backend is fixed... http://comingsoon.jujucharms.com/:flags:/mv/ deploy mysql, switch to machine view, use mass scale up UI and add 5 units (see it added into the ecs but no unplaced shows up in the list)
[15:36] <rick_h__> hatch: ok, I see that the mass scale up thing is borked. That's not this card though, that's outside of the inspector. 
[15:36] <rick_h__> hatch: I'm confused here
[15:36] <hatch> the same methods that the inspector needs to call is the same methods that calls
[15:37] <jcsackett> hatch: finally up. phantomjs/mocha is getting crashier for me.
[15:37] <rick_h__> hatch: ok, so sounds like this card is blocked, we need a new one for the bug (I don't see a card for it on the board) and that card needs to get worked on first?
[15:37] <hatch> yes we need to get the newly created units to show up in the unplaced column
[15:37] <hatch> so they can actually be placed
[15:37] <rick_h__> hatch: ok
[15:38] <hatch> I can create a card, unsched? or...
[15:38] <rick_h__> hatch: yes
[15:38] <rick_h__> hatch: create a card, mark it unsched as it's a bug in stuff that used to work that's failing now and we need to get updated
[15:39] <hatch> I'm guessing that this bug has existed for some time...ever since we added the ecs stuff
[15:39] <rick_h__> hatch: then we fail at noticing, filing a bug/follow up cards on it :(
[15:40] <hatch> friday card for selenium tests comin riiiiight up
[15:40] <hatch> :)
[15:41] <hatch> jcsackett ok cool will qa again
[15:47] <hatch> jcsackett so I feel like the test change does not cover all of the cases in which this bug existed....
[15:47] <hatch> I see three places the event payload was changed but only one test updated
[15:48] <jcsackett> hatch: wasn't sure testing was actually necessary; that an individual pane goes away when it receives the appropriate null is tested, and that metadata gets put in the right spot is tested.
[15:48] <jcsackett> i can add tests for this specific coverage if you like, though.
[15:48] <hatch> jcsackett well I mean that the proper state objects are fired
[15:48] <jcsackett> hatch: fair; i'll update.
[15:49] <hatch> cool thanks
[15:51] <hatch> jcsackett +1'd with those tests
[15:51] <jcsackett> hatch: cool.
[15:52] <jcsackett> thanks for the review. :)
[15:52] <hatch> unfortunately you're not quite out in the clear just yet :)
[15:54] <rick_h__> marcoceppi: lazyPower do you guys have any other charmworldlib clients than charmtools?
[15:55] <rick_h__> rogpeppe: is there an api doc or something we can generate for the charmstore api?
[15:55] <marcoceppi> rick_h__: yes
[15:55] <rick_h__> marcoceppi: can you shoot me a list or any hints on them? I need to document the clients we're effecting with the v4 api work
[15:57] <marcoceppi> Amulet, charmtools, are the two biggest. There's maybe 3-8 more smaller tools built around that
[15:57] <marcoceppi> I'll email you a list
[15:57] <rick_h__> marcoceppi: <3 ty much
[16:01] <rick_h__> bac: regatta day across the wifi beam?
[16:02] <rick_h__> bac: oh, right NC. microwave over the wifi? 
[16:06] <rick_h__> abentley: does the reporting site use charmworldlib/charmworld api? Or is it only talking to the charmstore api?
[16:06] <abentley> rick_h__: otp
[16:07] <rick_h__> abentley: rgr, ty
[16:10] <abentley> rick_h__: We do use the charmworld API.  We use it to get a list of all charms.  I think that is all we use it for.
[16:10] <rick_h__> abentley: ok thanks
[16:14] <rick_h__> luca__: I thought we agreed in vegas that we were only doing one level of nesting. 
[16:14] <luca__> rick_h__: that’s fine with me
[16:14] <rick_h__> luca__: that doing more thatn that broke down the UX a bit and was a rare thing 
[16:15] <rick_h__> luca__: at that point we'd encourage using the cli to manage that special case
[16:15] <luca__> rick_h__: I don’t mind, it’s super rare so I’m not fused :)
[16:15] <rick_h__> luca__: ok cool. 
[16:16] <rick_h__> luca__: I just wanted to make sure you also remember this conversation before I put it down in stone in the bug :)
[16:17]  * rick_h__ goes to grab some food stuffs
[16:17] <luca__> rick_h__: that’s all good, I knew we made a decision but I didn’t have it documented anywhere
[16:32] <kadams54> rick_h__: got a question about this change-version.svg…
[16:33] <rick_h__> kadams54: what's up?
[16:33] <kadams54> Is this for the Change version link in the inspector?
[16:33] <kadams54> Currently a yellow dot icon?
[16:33] <rick_h__> kadams54: yes, it's an icon for that text
[16:36] <kadams54> rick_h__: It's an SVG; the original is a PNG. It looks like the PNGs get all sprited up. Should I convert it to PNG, or is this part of a transition to SVGs?
[16:36] <rick_h__> kadams54: yes, I'd add the svg to our assets directory, but I think a png will work peachy there
[16:36] <kadams54> OK
[16:39] <kadams54> rick_h__: OK, this is what I was afraid of… the icon doesn't work on the dark background of the inspector. It seems like it was made for a light background?
[16:39] <rick_h__> kadams54: looking for the wireframes/images of the full thing sec
[16:40] <rick_h__> kadams54: so looking at https://drive.google.com/a/canonical.com/#folders/0B7XG_QBXNwY1Vmowb25PejhJOTg
[16:41] <kadams54> Yup
[16:41] <rick_h__> the icon is a white one for the dark background, you're right that this icon doesn't match that up at all
[16:41] <rick_h__> so we should push back on UX/spencer. 
[16:41]  * rick_h__ looks for email thread
[16:42] <kadams54> The icon also looks slightly different from the one in the visuals here
[16:43] <rick_h__> kadams54: k, replied to the thread from spencer
[16:43] <rick_h__> kadams54: will watch for replies
[16:43] <rick_h__> kadams54: yea, I wasn't worried about that, they had some change of heart/etc. 
[16:44] <rick_h__> but the icon being a dark icon makes it darn hard to be valid
[16:44]  * rogpeppe is done for the day
[16:44] <rogpeppe> g'night all
[16:44] <rick_h__> rogpeppe: hey, night. 
[16:44] <rick_h__> rogpeppe: if you get a chance, I ping'd earlier about the api for the charmstore
[16:44] <rick_h__> rogpeppe: if you can take a peek at something for the morning I'd appreciate it so I can get these notes together for gustavo
[16:49] <hatch> kadams54 so it looks like you were the one who added the create machine stuff in machine view panel https://github.com/juju/juju-gui/blob/develop/app/widgets/machine-view-panel.js#L449 is there a reason why you put this here instead of in the ecs? I feel like it should be in the ecs so I'm looking for input
[16:53] <kadams54> hatch: feel free to adjust separation of concern as you see fit.
[16:54] <hatch> ok sounds good - I have to add a similar functionality to the units and it feels like it should be in the ecs so the consumer doesn't need to care about extra steps
[16:54] <hatch> any thoughts?
[16:54] <kadams54> hatch: I suspect when much of this was setup ECS was also under heavy development by you and Makyo. It could probably use some tweaking as things settle in.
[16:56] <kadams54> hatch: my only thought is that it doesn't look like there's much to these methods as it is. There's a call to db.machines.addGhost that might be able to move over to the ECS side, but it pretty quickly this.get('env').addMachines().
[16:57] <hatch> no it's not much at all, but anyone who calls add_machine has to know to also call these other methods which is not clear
[16:57] <kadams54> hatch: it looks like you could eliminate the _createMachine method and just have _handleCreateMachine call into the ECS directly.
[16:57] <hatch> exactly
[16:57] <kadams54> But we'll still need the placeUnit call on line 452, right?
[16:58] <kadams54> separate from the createMachine call
[17:00] <kadams54> rick_h__: I edited the SVG directly to flip to a white version of the icon: http://cl.ly/image/350E3u470Q2X
[17:01] <kadams54> Still looks off - needs to be a little beefier.
[17:01] <kadams54> We'll see what Spencer replies with.
[17:01] <rick_h__> kadams54: cool
[17:07] <rick_h__> kadams54: I'm going to move that card back then 
[17:07] <kadams54> OK, I was just getting ready to mark it as blocked and move it to tracking :-)
[17:07] <rick_h__> jcsackett: did you get to peek at huw's stuff? Or kadams54 could you look then?
[17:07] <kadams54> rick_h__: sure, I can look at them.
[17:08] <hatch> kadams54 sorry I linked you the wrong line :) I meant moving this line into the ecs https://github.com/juju/juju-gui/blob/develop/app/widgets/machine-view-panel.js#L524 
[17:08] <hatch> oopsssss
[17:08] <hatch> I think the comments still hold true :)
[17:08] <kadams54> Yeah, that's fine
[17:08] <rick_h__> thanks kadams54 
[17:11] <jrwren> https://twitter.com/JayRWren/status/486920538485321728
[17:18] <hatch> bad link
[17:19] <hatch> you tweet a lot
[17:19] <hatch> :)
[17:20] <hatch> followed
[17:21] <jrwren> i had bad homonym in that tweet. Deleted it
[17:22] <jrwren> https://twitter.com/JayRWren/status/486923301647052801
[17:25] <hatch> haha
[17:26] <hatch> ahh the internet
[17:28] <hatch> jrwren so do you live in a country-like area? 
[17:29] <frankban> done for today, have a great week all!
[17:29] <rick_h__> have fun frankban!
[17:29] <jrwren> hatch: no, that is 2.5 miles from downtown Ann Arbor. A city of 100,000+
[17:30] <hatch> oh crazy
[17:56] <rick_h__> jrwren: back from lunch? Did you get the feedback from the merge proposal then?
[17:56] <rick_h__> kadams54: thanks for looking at that. 
[17:58] <jrwren> yes back.
[17:58] <jrwren> got the feedback. trying to document whatever I just did.
[17:58] <rick_h__> ok cool
[17:58] <rick_h__> thanks
[17:59] <jrwren> if you get time, we can talk next too.
[17:59] <rick_h__> jrwren: ok, have a call in 1min and will ping after that
[18:00] <hatch> rick_h__ just relocating will be in the room shortly
[18:00] <rick_h__> hatch: rgr
[18:03] <mbruzek> Hey guys I am trying to deploy a bundle with local charms.  No errors in the console, but seeing the error in the GUI. An error occurred while deploying the bundle: ('No charm metadata @ %s', 'precise/local:precise/mediawiki/metadata.yaml') 
[18:03] <rick_h__> it doesn't support local charms
[18:04] <rick_h__> you have to use just the deployer and it has some limitations
[18:05] <mbruzek> thanks for responding rick_h__ I see you are in meeting.  I need to use local charms on power, because of the limited network.
[18:05] <mbruzek> rick_h__, The command I am using is juju quickstart -n nagios-mediawiki-mysql /home/mbruzek/workspace/bundles/nagios/bundle/bundles.yaml
[18:05] <mbruzek> So that is not supported?
[18:05] <rick_h__> correct
[18:05] <rick_h__> that's not supported
[18:09] <jrwren> what is the difference between charms/juju-gui and ~juju-gui/charms/trusty/juju-gui/trunk ?
[18:09] <rick_h__> mbruzek: there's an issue with local charms support over the api via the gui because of the way the versioning works and a juju-core bug we hit up against
[18:11] <rick_h__> jrwren: ready to chat when you are, meet in the standup hangout
[18:12] <jrwren> ready
[18:12] <rick_h__> jrwren: hmm, I don't think there is a juju-gui owned charm is there? /me goes to check.
[18:12] <mbruzek> rick_h__, I don't doubt it, just trying to figure out what the equivalent juju-deployer
[18:12] <mbruzek> command
[18:15] <mbruzek> Looks like juju-deployer -c ../../bundles/nagios/bundle/bundles.yaml is working
[18:24] <tvansteenburgh> hey guys, is there a way to query the charmworld api for "all bundles that contain charm X"?
[18:26] <rick_h__> tvansteenburgh: no, it's one of the calls we're adding to the new api as it's needed
[18:26] <rick_h__> tvansteenburgh: the charm names are indexed so you can try to do a search for bundle:mongodb
[18:27] <rick_h__> and it should find bundles with a mongodb charm in it, but it's not able to find bundles with cs:trusty/mongodb in it
[18:27] <tvansteenburgh> ah, ok, that'lll probably suffice for now, thanks rick_h__!
[18:46] <jrwren> so... how do I delete a review?  how might I update one? I'm used to reviewboard.
[18:47] <rick_h__> jrwren: using reitveld you can lbox propose again
[18:47] <rick_h__> it should update the existing merge proposal
[18:52] <jrwren> ok.
[18:52] <jrwren> how would I squash commits?
[18:52] <jrwren> or does bzr kinda of handle that when merging?
[18:53] <rick_h__> jrwren: yea bzr does that on merging. You get to assign a new single commit message
[18:53] <jrwren> that is what threw me.
[18:53] <jrwren> its been at least 4yrs since I used much bzr
[18:54] <rick_h__> hah, welcome to a dual vcs world
[18:54] <rick_h__> though you're here at a good time when there are at least two 
[18:56] <jrwren> 2 is less than 3 :)
[19:05] <jrwren> !np
[19:13] <jrwren> is there a charmstore charm? :)
[19:14] <rick_h__> jrwren: nope, but it's on the todo list for the charmstore work 
[19:24] <jcastro> hatch, FYI for your charm: https://nodesource.com/blog/chris-lea-joins-forces-with-nodesource
[19:26] <rick_h__> ah crap, this is a sad day
[19:26] <hatch> jcastro what the heck....
[19:26] <rick_h__> we'll have to get IS to allow us to do a manual repo now
[19:26] <rick_h__> sudo bash -
[19:27] <rick_h__> when you just don't give a flying poo
[19:27] <hatch> yeah....
[19:27] <jrwren> sudo -i ?
[19:27] <jrwren> why was that ppa so important?
[19:27] <rick_h__> jrwren: because it was the only way to get recent nodejs in a stable way
[19:27] <rick_h__> jrwren: the whole company's JS devs rely on that one
[19:28] <rick_h__> jrwren: and because it's a PPA it goes through LP build farms and it 'less evil' than most things
[19:28] <rick_h__> npm/etc don't support older revisions for long, you have to update and LTS updates are so out of date at release time it's sad
[19:28] <jrwren> trusty ships 0.10.25... isn't that new enough for almost everything?
[19:29] <kadams54> suck
[19:29] <jrwren> as for precise... oh well.
[19:29] <kadams54> rick_h__: was reading through some older e-mail threads; do you know of any card to make autoselect the first machine and container when rendering machine view?
[19:29] <hatch> kadams54 huw did that
[19:30] <rick_h__> kadams54: huw finished it
[19:30] <kadams54> Oh, that's why I'm not finding it in backlog or on deck.
[19:30] <kadams54> Never mind.
[19:30] <rick_h__> :)
[19:30] <kadams54> Did that land yet?
[19:30] <hatch> yop
[19:30] <rick_h__> should be on comingsoon
[19:31]  * rick_h__ tests it out
[19:31] <kadams54> Yes
[19:31] <kadams54> OK, I realized what my problem was.
[19:31] <kadams54> I had no machines, so there was nothing to autoselect
[19:31] <rick_h__> yea, working here
[19:31] <rick_h__> right
[19:31] <kadams54> But we still display the "Add container" link
[19:31] <rick_h__> you have to deploy a bundle first
[19:31] <kadams54> Or just create an empty machine.
[19:32] <kadams54> What do we want to do with that link when there's no machines?
[19:32] <rick_h__> kadams54: we're working with UX on the empty story
[19:33] <rick_h__> kadams54: and they're getting some mockups so I'd not worry about it atm 
[19:33] <kadams54> k
[19:34] <kadams54> rick_h__, hatch: Another question: are unplaced units supposed to be deployed when I click on the Deploy button?
[19:34] <rick_h__> kadams54: no
[19:34] <rick_h__> kadams54: that might be related to stuff hatch is looking at? Not sure
[19:35] <hatch> kadams54 this is actually a problem I'm running into right now too
[19:35] <kadams54> rick_h__, hatch: I think that might be really tricky. They get added to the ECS because they're ghosted services in service view, so we want them to deploy in that context.
[19:35] <hatch> yeah exactly
[19:35] <kadams54> But in machine view, we don't want them to deploy until the user actually places them.
[19:36] <rick_h__> hatch: kadams54 so we need to throw an error in the deployment summary when there are unplaced units remaining
[19:36] <rick_h__> and disable the confirm/deploy button
[19:36] <kadams54> Even when in service view?
[19:36] <rick_h__> we'll have more cases like this when we get to things that aren't allowed to happen, unresolved conflicts in config, etc
[19:36] <kadams54> That's going to throw a wrench in the whole drag, drop, deploy flow.
[19:36] <rick_h__> kadams54: well this gets to the thing I thought hatch was working on. If you just deploy 5 units and don't pick to manual place, they should be auto placed on machines
[19:37] <rick_h__> and not as unplaced units
[19:37] <kadams54> Well basically that's what happens right now. They get autoplaced.
[19:37] <rick_h__> but it's part of the debate going on around having to go through machine view to do a deploy at all
[19:37] <rick_h__> kadams54: right, but they shold show up that way in MV
[19:37] <rick_h__> so the user sees what's up
[19:37] <hatch> yeah
[19:38] <kadams54> As already placed?
[19:39] <rick_h__> kadams54: we need to talk to luca about it tomorrow. I know we've talked about it both ways
[19:39] <rick_h__> 1) as already placed. The default is one unit per machine, so create those machines, put those units in it, and wait for the user to deploy
[19:39] <rick_h__> this is needed for aws anyway since you can't manual place 
[19:40] <rick_h__> 2) even on one unit per machine, auto create the machines, show the units, but allow them to unplace/remove and manual place. When they hit deploy from service view, they get sent to machine view. 
[19:40] <rick_h__> but not sure how that makes things any easier/nicer 
[19:43] <hatch> rick_h__ mind scheduling that call after I start tomorrow?
[19:43] <hatch> I can also join a little early if needed 
[19:44] <rick_h__> hatch: sure thing, I'll bug them about it :)
[19:44] <rick_h__> Makyo: https://bugs.launchpad.net/juju-gui/+bug/1329149 is fix committed right?
[19:44] <_mup_> Bug #1329149: Destroying a service does not use ecs <juju-gui:Triaged> <https://launchpad.net/bugs/1329149>
[19:44] <hatch> committed right
[19:44] <rick_h__> yay for bug triage day, abentley's motivated me to go do it. 
[19:46] <Makyo> rick_h__, yep
[19:49] <rick_h__> thanks for the confirmation 
[19:59] <rick_h__> I think bac programmed an irc bot while he was away :P
[20:00]  * rick_h__ runs away, have a good night all
[20:23] <jcsackett> kadams54: saw you reviewed huw's branch. thanks--i got sidetracked hunting down QA errors and stuff in my branch and completely forgot about his.
[20:23] <kadams54> jcsackett: no problem.
[20:28] <hatch> jcsackett there were more qa issues?
[20:29] <hatch> did I do a poor job reviewing? 
[20:29] <jcsackett> hatch: no, i meant after having done those huw's branch slipped my mind. just now i went to update the kanban board and realized my goof.
[20:29] <jcsackett> but kadams54 saved the day.
[20:29] <hatch> ohhh ok :)
[21:05] <jcsackett> jujugui: anyone have an actual environment with an up to date version of the develop branch for the gui? i need to verify something.
[21:05] <hatch> jcsackett I can spin one up...I'm guessing yours is running?
[21:06] <jcsackett> hatch: mine is running on an lxc env. i just switched it from one branch back to develop, so it got an up to date develop, and now the buggy behavior is gone.
[21:06] <jcsackett> i'm not sure if i've got a screwy thing going on, or what.
[21:06] <hatch> fire one up on amazon?
[21:06] <jcsackett> or if it's something only presents sporadically and i'm just getting lucky all of a sudden.
[21:06] <hatch> seems like you have lots of lxc issues :)
[21:06] <jcsackett> hatch: i have lxc issues for dev.
[21:07] <jcsackett> juju running an lxc env is golden--and earlier i observed what you described in LXC.
[21:07] <jcsackett> but fair enough, i'll spin up an ec2 env.
[21:07] <hatch> I mean, I can spin one up too if you need
[21:07] <hatch> just takes some time
[21:08] <jcsackett> hatch: no need. if no one has one just running for some reason, it's no faster than me spinning up an ec2.
[21:17] <hatch> cool
[21:52] <jrwren> i'm outtie.  chat ya'll tomorrow.
[21:59] <hatch> cya jrwren 
[23:00] <huwshimi> Morning
[23:12] <hatch> morning huwshimi 
[23:12] <huwshimi> hatch: Hey
[23:12] <hatch> how goes the battle?
[23:43] <huwshimi> Not bad, yourself?
[23:53] <rick_h__> morning huwshimi 
[23:54] <huwshimi> rick_h__: Hey