[07:43] <rogpeppe> urulama: yo!
[07:46] <urulama> rogpeppe: heya! 
[10:52] <rogpeppe> urulama: why are we storing machine and unit count in extra-info ?
[12:00] <frankban> morning all
[12:01] <rick_h_> morning
[12:02] <bac> hi rick_h_
[12:02] <bac> and frankban
[12:03] <rick_h_> how's europe treating your bac?
[12:03] <bac> it's great
[12:04] <frankban> bac: welcome back
[12:04] <bac> ty
[12:05] <rick_h_> bac: for the charm failure, it seems to only be when you have the cloud-archive enabled that you get this failure per the comment from Nicolas. 
[12:05] <rick_h_> bac: I'm going to try to run the full test suite with the dep removed today and if the tests pass I think I'll just push a new charm version without the dep. 
[12:06] <bac> rick_h_: ok
[12:06] <rick_h_> I seemed to have added it during the git conversion and maybe it was something I didn't need but ran into during testing/debug
[13:54] <hatch> morning all
[14:03] <rick_h_> howdy hatch 
[14:31] <rick_h_> phew, ok back in irc. I feel human again
[14:32] <lazyPower-sprint> rick_h_: Can I get you to take a look at something for me?
[14:32] <lazyPower-sprint> https://bugs.launchpad.net/charms/+source/rails/+bug/1366660
[14:32] <mup> Bug #1366660: Rack charm does not exist <rails (Juju Charms Collection):Confirmed for lazypower> <https://launchpad.net/bugs/1366660>
[14:32] <rick_h_> lazyPower-sprint: looking
[14:32] <lazyPower-sprint> there's some voodoo going on in the store
[14:33] <rick_h_> so if it used to exist and the branch was removed it's not gone until it's gone from the charmstore (juju go based store)
[14:33] <lazyPower-sprint> yeah, i figured it was some phantom data left over
[14:33] <lazyPower-sprint> this is pretty old, as rack was renamed to trails before I came on board
[14:33] <hatch> this kinesis keyboard is getting easier to use...but really sucks that it has big issues with OSX
[14:33] <rick_h_> lazyPower-sprint: looking, sec
[14:33] <rick_h_> hatch: :( stop using OSX :P
[14:33] <lazyPower-sprint> +1 to rick_h's sentiment ;)
[14:34] <hatch> haha kind of hard being the host OS 
[14:34] <rick_h_> lazyPower-sprint: https://store.juju.ubuntu.com/charm-info?charms=cs:precise/rack
[14:34] <rick_h_> lazyPower-sprint: so yea, we'd need to work with IS, get the charm removal script run against that charm in teh CS, then we have a delete button in charmworld to remove it from there
[14:34] <lazyPower-sprint> ok, do you need me to retarget the bug?
[14:35] <lazyPower-sprint> i dont think this is mission critical to people actually finding it - as its existed for 8 months before i even became aware of it
[14:35] <lazyPower-sprint> but it might be worth adding it as a low priority item to eject it from the store
[14:37] <rick_h_> lazyPower-sprint: yea, bac do you know if we ever got the delete docs into the wiki
[14:38] <bac> rick_h_: i'm unsure.  i think that was benji who worked on it ... a long time ago
[14:38] <rick_h_> bac: it was cmars actually that added it to the core charmstore. There's a script in there. I guess I could just look at the charmstore code now
[14:39] <bac> rick_h_: yes, it was cmars who had created the script.  i think benji worked on doing some deletions.  i'm not sure where he would've documented it.
[14:39] <rick_h_> bac: ah found an email with it in an RT
[14:40] <rick_h_> lazyPower-sprint: forwarded you an email. If you are interested I think it'd be good for you all to know how this works as well as us.
[14:40] <rick_h_> lazyPower-sprint: you can file an RT for the removal sometime and once that's complete we'll remove from charmworld
[14:42] <bac> rick_h_: please forward to me too and i'll put it on the wiki
[14:43] <rick_h_> bac: note that'll change once we get our charmstore in place of the old one
[14:43] <rick_h_> bac: but good to have for the next little bit
[14:43] <bac> ty
[14:50] <hatch> rick_h_:  so do you do any key remappings?
[14:51] <rick_h_> hatch: the kenisis?
[14:51] <rick_h_> hatch: you can recode any key to anything in the keyboard itself
[14:52] <rick_h_> https://www.kinesis-ergo.com/support/technical-support/faqs-advantage-keyboard/ 
[14:52] <rick_h_> hatch: ^
[14:52] <rick_h_> check out the swap from win/osx and the one on remapping a key
[14:53] <rick_h_> jujugui call in 8min, kanban please
[14:54] <hatch> rick_h_:  right, but have you found any favourable mappings?
[14:54] <rick_h_> delete is my meta key
[14:54] <hatch> = is too far away and {} are hard to hit ive found
[14:54] <rick_h_> ls
[14:55] <rick_h_> = isn't a problem for me I guess. 
[14:55] <rick_h_> the win/meta key was too far so moved that down to delete
[14:55] <rick_h_> well, swapped those two really
[14:55] <hatch> ahh yeah that's a good idea
[14:55] <rick_h_> other than that, no I don't think I moved much else around
[14:56] <hatch> i have to plug it in after my laptop boots else it blocks the boot process :)
[14:56] <rick_h_> oh :/
[14:57] <lazyPower-sprint> rick_h_: sounds good to me. thanks for the follow up
[14:57] <rick_h_> lazyPower-sprint: np
[14:57] <rick_h_> lazyPower-sprint: make sure to poke people about GUI/machine view on the orange box stuff please :)
[14:58] <rick_h_> jujugui call in 1 go go go
[14:59] <rick_h_> bac: kadams54 ^
[14:59] <rick_h_> rogpeppe: ^
[15:07] <rogpeppe> rick_h_: oops, was lunching...
[15:26] <hatch> jujugui is there a way to force destroy a service so i don't have to resolve all the failed hooks?
[15:29] <frankban> hatch: you can try with "juju destroy-machine --force {machine where the unit is placed} && juju destroy-service service {service name}", but I am not sure it works
[15:32] <hatch> yeah was hoping for a --force on the destroy-service but it doesn't look like it exists
[16:18]  * rick_h_ goes to get some lunch
[16:59] <lazyPower-sprint> frankban: additionally juju-deployer -T is also gnarly for destroying all machines but your bootstrap node.
[17:00] <frankban> lazyPower-sprint: good to know thanks
[17:08] <hatch> vms.....
[17:09] <rick_h_> oh back and such 
[17:21] <hatch> jujugui I need a review and qa https://github.com/juju/juju-gui/pull/534
[17:22] <hatch> kadams54_:  are you going to review huws brach or do you need to pass it off?
[17:23] <frankban> hatch: FYI while you were away lazyPower-sprint mentioned that juju-deployer -T can be used for destroying all machines but the bootstrap node
[17:24] <hatch> frankban:  oh cool thanks
[17:33] <hatch> kadams54_: I did the fina.l review on huws branch
[17:33] <hatch> Makyo: I added your tag to the card
[17:33] <Makyo> hatch, oh, thanks
[17:33] <Makyo> I forgot :(
[17:34] <hatch> haha np
[17:50] <hatch> rick_h_:  https://bugs.launchpad.net/juju-gui/+bug/1364956 I'm not sure what to do here as we don't support this interaction any longer
[17:50] <mup> Bug #1364956: Removing a unit via the inspector creates a sticky remove unit command in the deployer bar <juju-gui:Triaged> <https://launchpad.net/bugs/1364956>
[17:50] <hatch> close as invalid now?
[17:52] <rick_h_> hatch: otp, will look in a sec
[17:53] <hatch> sure np
[17:59] <hatch> Makyo: your branch ready for review?
[18:00] <Makyo> hatch, should be yep. 
[18:00] <hatch>  cool I;ll take one
[18:00] <Makyo> jujugui need some reviews, QA in real env https://github.com/juju/juju-gui/pull/535
[18:00] <hatch> now
[18:00] <hatch> u got to do one for me :P
[18:00] <Makyo> Sure
[18:01] <hatch> Makyo: you have a merge commit in here?
[18:02] <Makyo> hatch, yeah, I was worried there would be conflicts around deployer bar stuff.
[18:02] <hatch> ahh
[18:02] <Makyo> Scared after my last branch :P
[18:05] <hatch> haha
[18:06] <hatch> Makyo: one comment while my ec2 instance spins up
[18:07] <Makyo> hatch, will look into it (this is the confirm button, not deploy, so I stayed away initially)
[18:07] <hatch> ohh ok that may be it
[18:12] <rick_h_> hatch: so it seems that'd be a good thing to try to get QA on the orange box stuff. 
[18:13] <rick_h_> hatch: I got a contact for the one in london and I'll try to get that email going
[18:13] <frankban> guihelp: I need two reviews for https://codereview.appspot.com/139350043 (quickstart/python). Thanks!
[18:13] <hatch> sounds good I'll put it back into the queue
[18:15] <rick_h_> hatch: update the card with a "NEEDS QA" prefix to help others not grab it or such
[18:15] <hatch> ok i blocked it with a note about orange box qa
[18:15] <rick_h_> cool thanks
[18:26] <hatch> Makyo: so I just qa'd and it looked like it didn't change anything. the commit button was still active long after clicking it and the summary closing
[18:27] <hatch> was a commit missed or something?
[18:27] <Makyo> hatch, I just tried on lxc.  Let me try again on EC2
[18:28] <hatch> just cleared cache and got the same result
[18:30]  * frankban grabs some food
[18:35] <Makyo> hatch, check for a config-changed hook failure, I get that a lot when setting juju-gui-source\
[18:37] <rick_h_> Makyo: hatch I think you have to be on trusty to get the source change correct 
[18:38] <rick_h_> Makyo: hatch and you can check the version.js to make sure it's setup right
[18:41] <hatch> rick_h_: Makyo the files being sent over the wire have the changes as per the pr
[18:41] <Makyo> Huh, okay, digging.
[18:44] <hatch> grabbing lunch
[19:14] <Makyo> hatch, I see what's going on, misunderstood.  Good news is that toggle deploy button will help :P
[19:18] <kadams54_> guihelp: looking for QA and reviews on https://github.com/juju/juju-gui/pull/536
[19:20] <kadams54_> rick_h_: one of the remaining MV cards is for this bug, which is marked as invalid: https://bugs.launchpad.net/juju-gui/+bug/1365053
[19:20] <mup> Bug #1365053: Add units dialogue on pre deployment inspector is confusing <juju-gui:Invalid> <https://launchpad.net/bugs/1365053>
[19:21] <jcastro> rick_h_, oddly enough that ddclient icon renders fine in inkscape on my box
[19:22] <rick_h_>  jcastro yea, does in gimp here to
[19:22] <jcastro> huh
[19:27] <rick_h_> jcastro: yea, it's odd. I've not seen it before but I'm not an svg spec expert
[19:28] <rick_h_> jcastro: I tried to look for an svg validation service or the like w/o any luck
[19:28] <rick_h_> jcastro: so sorry to punt, but if the browser won't show the icon the gui can't either. 
[19:28] <jcastro> no worries
[19:28] <jcastro> I might just redo the icon entirely
[19:28] <rick_h_> jcastro: k, let me know if I can help. And by help I mean get luca to send you to someone on the design side that knows image steuff
[19:29] <rick_h_> kadams54_: looking
[19:29] <rick_h_> kadams54_: ok, so the question then is the add units collapsed by default?
[19:29] <rick_h_> kadams54_: I think this might have been left as a place holder to do that work
[19:31] <rick_h_> kadams54_: so just to verify, it's not yet collapsed like the post-ghost inspector view and needs to be done
[19:39] <frankban> guihelp: need one more review + QA for https://codereview.appspot.com/139350043 . anyone available? thanks
[19:40] <hatch> Makyo: :) cool let me know when you'll be ready for another review
[19:40] <hatch> frankban:  I can look at it 
[19:40] <frankban> hatch: thanks!
[19:41] <hatch> frankban: I don't have a utopic vm
[19:41] <hatch> do I need one?
[19:41] <frankban> hatch: it's not required
[19:41] <hatch> ok sounds good
[19:42] <rick_h_> frankban: are you going to need a charm release soon around this?
[19:43] <rick_h_> frankban: I need to do one for the dep fix and the bug on the cloud-archive and wonder if we should sync up
[19:44] <frankban> rick_h_: no I don't, but I can take care of releasing the charm if you want. what was the fix for libapt stuff? just removing the dep?
[19:44] <rick_h_> frankban: yea, just removing the dep seems to qa ok and passes tests
[19:44] <rick_h_> frankban: if you can peek at that it'd be cool thanks
[19:45] <frankban> rick_h_: cool if functional tests pass then sounds good: perhaps that was required at some point (maybe as a support library for python-apt). who knows
[19:46] <rick_h_> frankban: yes, git blame says I last edited the line but can't recall/find any reason for it to be there
[19:46] <rick_h_> err bzr blame
[19:46] <frankban> rick_h_: ok, I'll start a charm release, which includes running the ftests on precise, and if that works the it's all good
[19:46] <rick_h_> frankban: ty much
[19:46] <rick_h_> frankban: there's a card in the top of the board for it atm
[19:47] <frankban> rick_h_: cool
[19:47] <hatch> hmm I also haven't got bzr set up either hah
[19:49] <rick_h_> hatch: can't get rid of that yet :P
[19:49] <hatch> frankban: can you remind me the best steps to take to get your code down?
[19:50] <frankban> hatch: bzr init-repo juju-quickstart
[19:50] <frankban> cd juju-quickstart
[19:51] <frankban> bzr branch lp:juju-quickstart trunk
[19:51] <frankban> bzr checkout --lightweight trunk sandbox
[19:51]  * rick_h_ runs away for the day. Have a good night all
[19:52] <frankban> bzr branch lp:~frankban/juju-quickstart/utopic-update-dependencies
[19:52] <frankban> cd sandbox
[19:52] <frankban> bzr switch ../utopic-update-dependencies
[19:52] <frankban> hatch: ^^^
[19:52] <hatch> oh wow all the steps :) thanks
[19:53] <hatch> it's been a while since i've bzr'd
[19:53] <frankban> hatch: and then, in the future, you just have to start from branching the code you need to review
[19:55] <hatch> excellent.....can we switch to git yet? :P
[20:02] <hatch> frankban: I don;t have hp creds, did you test hp?
[20:02] <frankban> hatch: in theory we can... the only missing thing is a way to automatically build deb packages in the PPA. anyway, I still like the bzr+reitveld workflow (especially the reitveld part) ;-)
[20:02] <frankban> hatch: I did, you can skip that step if you want
[20:04] <hatch> ok I'll test the rest thx
[20:04] <hatch> you LIKE that workflow? ugh I want to rip my eyes out lol
[20:05] <frankban> hatch: heh, github code review is less than optimal IMHO
[20:06] <hatch> true but the bzr workflow leaves quite a bit to be desired
[20:07] <frankban> hatch: uhm... you convinced me, I'll move quickstart to bitbucket so that we can all enjoy mercurial ;-)
[20:07] <hatch> lol!! 
[20:07] <hatch> victory is mine
[20:08] <frankban> :-)
[20:11] <hatch> frankban: lgtm'd
[20:11] <frankban> hatch: thanks!
[20:14] <hatch> rick_h_:  are you ok with us no longer testing non mv stuff?
[20:14] <hatch> oh he's gone
[20:14] <hatch> heh
[20:23] <hatch> kadams54_: review done - I don't see any tests for anything other than the changes made to state.js 
[20:23] <hatch> Makyo:  is yours ready for another qa?
[20:58] <hatch> jujugui i still need reviews on my last branch
[21:07] <hatch> Makyo: hey u kickin around? Can you remind me of the details for the card "Clear config-changed ECS entries"
[21:07] <Makyo> hatch, we need to be able to back out config changed entries in the ECS.  It's the only thing we can't reverse.
[21:08] <hatch> oh right because we don't know the original values
[21:08] <Makyo> Correct.
[21:08] <hatch> ok I'll work on creating the cloned config card 
[21:29] <kadams54> guihelp: Need reviews and QA on: https://github.com/juju/juju-gui/pull/537
[21:52] <hatch> Makyo:  ok so for this cloned local config store...
[21:52] <hatch> I've come up with 2 rules
[21:52] <hatch> local config changes do NOT modify it
[21:53] <hatch> delta changes do....even if said changes aren't represented in the inspector because of a conflict
[21:53] <hatch> sound good?
[21:54] <hatch> that way we always have a record of the 'true' config values in juju
[21:54] <hatch> so reverting any changes will revert to what juju has, not what was local
[21:54] <Makyo> Yeah, I think that's what we need; we already have a conflict resolution story in place.
[21:54] <Makyo> YEp
[21:54] <Makyo> RFC?
[21:55] <hatch> rfc?
[22:59] <huwshimi> Morning
[23:03] <hatch> morning huwshimi
[23:05] <huwshimi> hatch: How's things?
[23:05] <hatch> they are ok....still getting used to my new kinesis advantage keyboard...geting better though 
[23:06] <hatch> I cam type pretty well but special chars are still hard heh
[23:07] <huwshimi> woah, that thing looks crazy
[23:09] <hatch> yeah it is, but besides the cognitive load being exhausting now my fingers don't really feel like they have done anything all day compared to my old ergo keyboard
[23:11] <hatch> I'll likely have to remap some of the keys for coding but other than that it's pretty awesome....well except that my latptop won't boot with is plugged in
[23:12] <hatch> ...lol
[23:12] <huwshimi> oh, hah
[23:13] <hatch> yeah...not sure waht to do about that
[23:13] <hatch> they say it's apples fault....but I don't know of any other keybaord that does that
[23:14] <huwshimi> nice customer service
[23:15] <hatch> yeah...especially at
[23:15] <hatch> this price...i
[23:15] <huwshimi> ouch
[23:22] <huwshimi> hatch: Do you happen to know how to delete individual units using the ecs? If I do a db.removeUnits(...) it doesn't seem to go through the ecs.
[23:22] <hatch> you have to make the call of the env
[23:22] <hatch> the env then hits the ecs
[23:23] <hatch> huwshimi: https://github.com/juju/juju-gui/blob/develop/app/store/env/go.js#L1310
[23:23] <huwshimi> hatch: Ah great!
[23:29] <huwshimi> hatch: Strange, if you remove a deployed unit it removes the machine as well!
[23:30] <huwshimi> (deployer bar just says it will remove the unit)
[23:32] <hatch> hmm that shouldn't be correct
[23:32] <hatch>  is this in a real env or just sandbox?
[23:32] <hatch> because I did that exact interaction a few times today and it left the machine running
[23:32] <huwshimi> hatch: sandbox
[23:34] <hatch> hmm lemme take a look
[23:35] <hatch> you are correct
[23:35] <hatch> that is odd heh
[23:37] <huwshimi> :(
[23:37] <hatch> I'm guessing you need that machine to stay working?
[23:37] <hatch> :)
[23:40] <huwshimi> hatch: Not for this branch, but it seems like a bug to me :)
[23:43] <hatch> yup, but a sandbox bug at least