[01:27] <rick_h_> yay CI!
[11:26] <rick_h_> anyone around for a short/sweet review https://codereview.appspot.com/13349047 ?
[11:40] <rick_h_> also looking for a second review of Huw's branch https://codereview.appspot.com/13715044/ for the inspector today. 
[11:59] <bac> ahoy
[12:07] <rick_h_> morning bac 
[12:34] <gary_poster> rick_h_, gave review.  I *think* we need a few more things
[12:34] <gary_poster> lemme know if you think I am wrong
[12:35] <rick_h_> gary_poster: rgr, looking
[12:36] <gary_poster> rick_h_, for 1220909, is there a counter-argument to Jorge's request?
[12:36] <gary_poster> bug 1220909
[12:36] <_mup_> Bug #1220909: Searching for "rabbit" doesn't return the rabbitmq charm <charmworld:New> <https://launchpad.net/bugs/1220909>
[12:37] <rick_h_> gary_poster: I think the autocomplete provides some of that since it's matching off the start of the name
[12:37] <rick_h_> so typing rabbit will provide rabbitmq in autocomplete
[12:37] <gary_poster> rick_h_, agreed some, but not all
[12:37] <rick_h_> gary_poster: but honestly...not really
[12:37] <gary_poster> rick_h_, ok cool.  easy to change?
[12:37] <rick_h_> gary_poster: I think it's decent search experience to add some n-gram indexing of the names at least
[12:38] <rick_h_> gary_poster: I'm not 100% sure. Assuming it's supported in ES then should be a config change and a migration to populate the search index?
[12:38] <gary_poster> ack thanks rick_h_ 
[12:40] <luca__> gary_poster: do you know the URL so I can see Makyo's upgrade stuff?
[12:41] <gary_poster> hi luca__ .  I don't think it is ready, actually, after looking at it further, but http://comingsoon.jujucharms.com/:flags:/upgradeCharm/
[12:43] <gary_poster> luca__, for bug #1221665, if your answer to rick_h_ 's question is "yes", I think I agree, but I am curious to see your answer, because I think we could argue either way
[12:43] <_mup_> Bug #1221665: Inspector config fields should be expanded to input size <juju-gui:Incomplete> <https://launchpad.net/bugs/1221665>
[12:47] <rick_h_> gary_poster: questions back at ya
[12:47] <rick_h_> re: review
[12:48] <gary_poster> rick_h_, cool looking
[12:56] <gary_poster> hey rick_h_ , definitely agree I missed out on some details--sorry about that!  however, I'm getting confused concerns about the state of things around (not in) your branch, and wanted to talk through those with you for a sec.  You available for https://plus.google.com/hangouts/_/6be4e6d76bd266bd36ec5c5626c7d5a61d0ea88c ?
[13:01] <hatch> morning
[13:01] <hatch> man these CI failures are kind of irritating heh :)
[13:11] <rick_h_> hatch: I took back the card for the remove units
[13:11] <hatch> rick_h_: instead of commenting out the 'fake' test - in my branch I deleted it and put a comment at the top of the file
[13:11] <rick_h_> hatch: working on getting changes per review 
[13:12]  * hatch sobs, it'll be missed
[13:12] <rick_h_> :P
[13:13] <hatch> I built two boxes yesterday for my monitor and keyboard to give me a standing desk....will see how this goes :)
[13:15] <benji> hatch: cool; I've been trying to figure out a good way to do a sit/stand desk without spending a mint on one of those geek desks
[13:15] <hatch> total cost for this one..... $0 :D
[13:16] <hatch> scrap MDF glued/nailed together
[13:16] <gary_poster> :-)
[13:16] <hatch> unfortunately this one is not adjustable without some help
[13:16] <hatch> haha
[13:17] <gary_poster> hey benji, have you collected any ElasticSearch knowledge by chance?  I'm looking for an estimate on cost of #1220909
[13:17] <_mup_> Bug #1220909: Searching for "rabbit" doesn't return the rabbitmq charm <charmworld:Triaged> <https://launchpad.net/bugs/1220909>
[13:17] <gary_poster> or bac?
[13:17] <benji> gary_poster: a little; I'll see if I can contribute anything
[13:17] <gary_poster> thanks benji
[13:19] <hatch> rick_h_: in your QA of huw's branch did you happen to test if the 'use defaults' toggle still worked as expected?
[13:20] <rick_h_> hatch: yes, I believe I did
[13:20] <hatch> ok cool - looking at the source I wasn't sure if it was going to pick up the selector properly
[13:20] <rick_h_> hatch: feel free to double check me, but pretty sure I did. 
[13:21] <gary_poster> hatch, rick_h_ does not for me
[13:21] <gary_poster> reloading to verify
[13:21] <gary_poster> yeah, does not
[13:21] <gary_poster> hatch ^^
[13:21] <benji> gary_poster: yeah we can do that; I suspect n-gram indexing is disabled so we'll need to come up with a sane config (min=4, max=20 would give the results requested in the issue) and then reindex
[13:21] <gary_poster> have a quick fix for me to try, hatch?
[13:21] <benji> how, exactly, to do that with ES I would have to figure out
[13:21]  * rick_h_ loading to double check
[13:22] <gary_poster> benji, and do we know how that might affect downtime?
[13:22] <rick_h_> gary_poster: so you can't click the "use the default configuration" toggle on the ghost?
[13:22] <benji> I don't know, but if ES is a half-decent piece of software we shouldn't have any downtime.
[13:24] <hatch> gary_poster: rick_h_ I believe you will need to change the selector so that it grabs the container outside of the "Import Config File" button
[13:24] <rick_h_> gary_poster: works here. I did a clear cache/make clean-all and tried again and it still works
[13:24] <hatch> hmm ok I'll pull it down
[13:25] <benji> I think the last Jenkins run failed erroniously.
[13:25]  * benji needs to go AFK for a moment.  Contractor here.
[13:25] <gary_poster> benji, sure.  that gives my no reassurance so far though. :-)  could you add a low-burn "investigate" card for yourself to the jujucharms lane for you to tackle when you get a chance?  It sounds doable so far, so let's take it a bit farther and get a more concrete plan, by conferring with others (aaron or abel?) and digging just a bit.  sound ok?
[13:25] <gary_poster> ack
[13:26] <gary_poster> rick_h_, hatch, I can click on it, and the behavior is correct, but there is no change to the visualization of the fields
[13:27] <hatch> yeah it's probably picking up the wrong element
[13:27] <hatch> so it'll have to be more specific
[13:27] <hatch> (the selector)
[13:27] <gary_poster> so, I was wrong: not actually broken functionally.  but visually not what I though we wanted
[13:27] <hatch> I'm just checking it out right now to see what needs to be changed
[13:27] <gary_poster> brb
[13:27] <rick_h_> gary_poster: ah, I concur. THe fields aren't disabled to start
[13:28] <gary_poster> visually, yeah
[13:28] <gary_poster> functionally fine
[13:29] <rick_h_> right, I flipped the switch before the fields were visible in scroll and it worked so carried on. Thanks for catching. 
[13:29] <hatch> cool - yeah I wrote that part so that's probably why I picked it up haha
[13:30] <luca__> gary_poster: the answer to 1221665 was yes :)
[13:30] <rick_h_> luca__: but then if you've got a couple of big fields you'd have to scroll past all their content to get to config items below it? 
[13:30] <rick_h_> luca__: that seems kind of sucky
[13:31] <hatch> gary_poster: rick_h_: guess this means we need another test :P
[13:31] <rick_h_> hatch: hah! works for me
[13:31] <hatch> shall I take over on this branch?
[13:31] <rick_h_> hatch: please do. I was going to try to land for him if I got a second code qa, but working on the inspector stuff now
[13:32] <hatch> ok cool I'll fix and repropose
[13:32] <rick_h_> would like to have this for luca__'s qa today so we can release it tomorrow
[13:33] <luca__> rick_h_: I would like them expanded, scrolling isn't a usability problem, for now it would be best to expand them and see if its an issue through testing
[13:33] <rick_h_> luca__: rgr
[13:35] <benji> gary_poster: sounds good, card added
[13:36] <benji> so... I guess I need to figure out how to kick off another Jenkins run
[13:36] <rick_h_> benji: will have a branch landing shortly
[13:36] <rick_h_> benji: can get a kick in a sec
[13:36] <benji> sounds good
[13:40] <gary_poster> luca__, cool thanks :-)
[13:40] <gary_poster> benji thx
[13:41] <benji> np
[13:42] <rick_h_> gary_poster: new tests cribbed in https://codereview.appspot.com/13349047/
[13:43] <gary_poster> rick_h_, cool, looking thanks
[13:45] <gary_poster> rick_h_, LGTM, thanks!
[13:45] <rick_h_> gary_poster: awesome, thanks for the review
[13:46] <gary_poster> welcome
[13:46] <rick_h_> gary_poster: I was starting to do some triage/cleanup in the spare time this morning. Anything in particular you wanted me to grab next then? name conflicts on the inspector, or something in bundles, or the textarea bug from luca?
[13:47] <gary_poster> rick_h_, how expensive is textarea work?  That would be my first choice
[13:47] <rick_h_> gary_poster: shouldn't be much, will look. 
[13:48] <gary_poster> thanks rick_h_ .  hatch, rick_h_ I'd like to get Huw's branch landed.  hatch are you fixing up the disabled visualization issue?
[13:49] <hatch> gary_poster: add a space between the & and the . in juju-inspector.less &.use-defaults
[13:49] <hatch> & .use-defaults
[13:50] <hatch> are you going to do that fix? or would you like me to?
[13:50] <gary_poster> ack hatch thx.  you doing second review?  I was going to LGTM it except for this issue, so if you have more input that would be better
[13:51] <hatch> I agree with rick_h_'s comment re view-content
[13:51] <hatch> but other than that and this fix it all looks fine to me
[13:52] <gary_poster> hatch ack.  would you do the fix & landing then?  Hopefully Huw will have another fix for the view-content, which I also agree with
[13:54] <hatch> yep no problem just linting and testing now then will submit
[13:54] <gary_poster> thank you
[13:54] <hatch> I think this is my smallest diff ever
[13:54] <hatch> 1 space
[13:56] <gary_poster> :-)
[13:59] <hatch> it wont let me submit without proposing first for whatever reason so it'll be a while but it's in motion :)
[14:02] <gary_poster> heh, cool thanks
[14:10] <gary_poster> hey jcsackett.  do you need us to do anything about lp:~jcsackett/charmworld/review-queue-metrics or are you on it?
[14:10] <gary_poster> same question for latency-sparklines
[14:10] <jcsackett> gary_poster: all my current charmworld branches are part of the same work, and no worries on it.
[14:10] <gary_poster> awesome thanks jcsackett 
[14:11] <jcsackett> it's supporting some metrics for charmers, not juju-gui-ish stuff. :-)
[14:11] <gary_poster> I figured, cool :-)
[14:12] <gary_poster> hatch did you already have bcsaller's https://codereview.appspot.com/13253050/ followup on your list?  looks like he is ready for you, and would be excellent to get that work landed
[14:15] <hatch> oh woops I missed the followup
[14:15] <hatch> I swear I Dont' get all emails sometimes
[14:16] <hatch> huws branch landed with fix
[14:18] <gary_poster> awesome thanks hatch
[14:22] <hatch> gary_poster: QA still no good
[14:22] <gary_poster> hatch :-( but hthank you for pushing it forward
[14:23] <hatch> is he in today?
[14:29] <gary_poster> hatch should be.  has not requested days off
[14:29] <hatch> ok cool then when he pops in I'll let him know the issue
[14:30] <gary_poster> cool.  hatch what are you tackling next?
[14:30] <hatch> not sure, just reading through the cards
[14:31] <hatch> have anything in mind?
[14:32] <gary_poster> hatch yeah, two choices.
[14:32] <gary_poster> 1: #1221668
[14:32] <_mup_> Bug #1221668: Name validation in the inspector should be validated on key input <juju-gui:New> <https://launchpad.net/bugs/1221668>
[14:32] <gary_poster> 2: (card) ghost inspector: when you click "confirm" and successfully convert to a real service, close the ghost inspector and automatically open the service inspector (or similar)
[14:33] <hatch> I'll pick #1, I'm not convinced we want #2 yet :P
[14:34] <hatch> with that said I don't remember why I wasn't convinced
[14:34] <hatch> haha oh boy I need another cup of coffee I think
[14:34] <rick_h_> hatch: I think I tried to talk you into it. I'm not a fan
[14:34] <gary_poster> rick_h_, not a fan of proposed behavior?
[14:35] <rick_h_> gary_poster: rgr, once you go through and do the work, I'm not sold on the workflow that needs to hide the canvas to show the inspector panel after I hit deploy
[14:35] <rick_h_> especially since the first thing I'll be doing is waiting for instances to come up
[14:35] <rick_h_> and will move along with other tasks
[14:35] <hatch> yeah that's what the issue was....I figured you would move onto anothe ghost, not onto the deployed service
[14:35] <rick_h_> I've not seen the use case for "I go through, do cnofig, do the deploy...now watch the inspector for a while for something?
[14:36] <hatch> maybe if the inspector played nyan cat while waiting
[14:36] <gary_poster> rick_h_, ack.  I thought luca__ was questioning the decision as well, but he as more confident at the sprint than I expected.  luca__ , thoughts on above?  ^^^
[14:36] <rick_h_> if I'm missing a user drive case I'd love to hear it. Just haven't thought of it in my head yet. 
[14:36] <rick_h_> /drive/driven
[14:37] <gary_poster> hatch made a card for you :-)
[14:37] <hatch> do we have checkmarks/x's for #1221668 yet?
[14:37] <_mup_> Bug #1221668: Name validation in the inspector should be validated on key input <juju-gui:New> <https://launchpad.net/bugs/1221668>
[14:37] <hatch> awesome thx
[14:38] <gary_poster> not sure; looking in drive folder...
[14:39] <luca__> gary_poster: rick_h_ hatch the post-deployment inspector should show up automatically after deploy has been clicked, it's to show that something is happening, it's just a validation step.
[14:39] <rick_h_> luca__: isn't the error bar indicator and the bounce upon deploy an indicator?
[14:40] <gary_poster> (I was going to say same thing)
[14:40] <hatch> ME TOO!
[14:40]  * hatch joins tha gang against luca__
[14:40] <gary_poster> :-P
[14:40] <hatch> hzhz
[14:40] <hatch> haha
[14:40] <hatch> even
[14:40] <gary_poster> the first one was a cough when you have cold
[14:40] <gary_poster> a cold
[14:40] <Makyo> Hah.
[14:41] <hatch> haha
[14:41] <luca__> gary_poster: rick_h_ hatch not really, it's automatic, it makes no difference to the users life apart from gives them access to see feedback, it's weird to have the panel just disappear, when you click deploy you're not stating that you are finished with the service, your just saying you want to proceed with it. 
[14:42] <hatch> I'd say a tooltip on the deployed service that says 'spinning up' or something would be clearer
[14:42] <hatch> I'm just thinking that most people would then just close the inspector
[14:42] <luca__> gary_poster: rick_h_ hatch that exists in the inspector
[14:42] <hatch> and go work on another ghost
[14:42] <rick_h_> luca__: then I'd argue that we should be getting rid of the bounce at least. It seems odd to have all that shaking around the UX if it's going to be considered one through process
[14:42] <gary_poster> hatch is what you need in https://drive.google.com/a/canonical.com/?tab=co#folders/0B7XG_QBXNwY1Zm8ya3NIcENyZnM ?
[14:43] <luca__> gary_poster: rick_h_ hatch they can just close the inspector, we're not stopping them from doing that, we're just providing more feedback on the way. It doesn't disrupt them at all
[14:43] <gary_poster> hatch if not ask luca__ or jamie for it
[14:43] <hatch> Does the inspector tell us anything beyond the canvas at that stage?
[14:43] <luca__> gary_poster: rick_h_ hatch the bounce never came from me, or anyone in the team, afaik it's just a placeholder animation
[14:43] <hatch> All it shows is the bar that's in the canvas...but bigger
[14:43] <rick_h_> luca__: right, but it's taking up screen estate and covering things, and mental processsing. I'm curious if there's a real workflow for the continued opening of the inspector on deploy
[14:44] <hatch> gary_poster: yeah I think it's missing from that folder
[14:44] <rick_h_> luca__: that's fine, just saying it's something we have that the users see and deal with. It disrupts the 'single process' flow imo
[14:45] <gary_poster> the current bounce is an engineering artifact IIRC.  There was a different bounce in the firefox demo from ant: it, I dunno, expanded and collapsed IIRC
[14:45] <rick_h_> luca__: but if they have to click on close on the inspector every time they deploy a service and never need/use it that's a pain point for that feedback when we're not sure if that feedback is useful/needed atm
[14:45] <gary_poster> demo is kinda broken atm https://dl.dropboxusercontent.com/u/10004366/juju-gui/index.html#
[14:45] <gary_poster> so can't verify
[14:45] <gary_poster> anyway...
[14:45] <luca__> hatch: gary_poster what are you after?
[14:46] <hatch> service name checkmark/x
[14:46] <gary_poster> luca__, assets for https://bugs.launchpad.net/juju-gui/+bug/1221668
[14:46] <_mup_> Bug #1221668: Name validation in the inspector should be validated on key input <juju-gui:New> <https://launchpad.net/bugs/1221668>
[14:47] <luca__> hatch: gary_poster It has been made, jamie_ can help you with them
[14:48] <hatch> great jamie_ can you email them to me?
[14:48] <jamie_> hatch gary_poster hey guys, how can I help?
[14:48] <hatch> need the checkmark/x for the service name validation indicator
[14:50] <hatch> hey rick_h_ your branch 'may' have failed in CI
[14:50] <hatch> I think it's just a CI issue though
[14:51] <rick_h_> hatch: yea, looks like the same failure/issue we had last week
[14:52] <rick_h_> hatch: yea, there it's back to normal now after your branch
[14:52] <gary_poster> yeah CI is horribly crazy :-( :-(
[14:52] <rick_h_> hatch: I do need to chat for a second on how to hook up what I need in viewlets. I have a feeling what I want to do is against the 'design'
[14:53] <gary_poster> jamie_, hi! thank you.  did you see reply from hatch?
[14:53] <hatch> rick_h_: sure gimme a ring
[14:55] <jamie_> gary_poster hatch got it, we've got the asset, I'll add it to the folder on Google Drive and let you know when it's there
[14:55] <gary_poster> thanks jamie_ !
[14:55] <hatch> thanks
[15:09] <gary_poster> hey Makyo.  luca__  (on call with him and others now) says there are two ux bits that you know about for the inspector.  IIUC they are these:
[15:09] <gary_poster> string in integer field needs [...something. better error reporting?]
[15:09] <gary_poster> upgrade charm needs [...something?]
[15:09] <gary_poster> do you know about thise/.
[15:10] <gary_poster> those?
[15:10] <Makyo> gary_poster, upgrade charm needs specifications on conflicts wrt added/removed config fields for concurrent editing, as well as notification that a charm has been upgraded.
[15:11] <jamie_> hatch hey there, I've uploaded 2 icons to the assets folder in Google Drive: form-validation-tick.png & form-validation-cross.png
[15:11] <gary_poster> Makyo, ok cool, so only upgrade charm stuff, not broader inspector stuff?
[15:11] <Makyo> As for string in integer fields, I think that's it.  I think my concern was wrt constraints, rather than config, and mem=2G,
[15:11] <Makyo> gary_poster, yep, that's still hidden.
[15:11] <jamie_> hatch I need to give you a loading spinner on a transparent bg so you can use it on the dark and light bg
[15:12] <gary_poster> Makyo, ah gotcha, thanks.  So we can launch without it but something we want to improve soon.
[15:12] <hatch> jamie_: no spinner necessary
[15:12] <hatch> it'll happen in real time
[15:12] <Makyo> gary_poster, correct.
[15:12] <hatch> so I just need a check and an X
[15:13] <gary_poster> cool thanks Makyo !
[15:13] <Makyo> gary_poster, Upgrade charm can be a later release, and even then, the more important bit is the notification of upgrade.
[15:13] <jamie_> hatch nice one, okay. Thought you might need it anyways? 
[15:13] <jamie_> hatch I've uploaded the check and X
[15:13] <hatch> I don't think so, it'll be immediate so there will be no need
[15:13] <hatch> thanks
[15:13] <gary_poster> jamie_, we want it for another bit but that's postponed because of engineering
[15:13] <jamie_> hatch cool, my work here is done :-)
[15:14] <jamie_> gary_poster got ya
[15:14] <gary_poster> thanks jamie_ !
[15:14] <jamie_> gary_poster hatch  ping me if you need anything else!
[15:16] <gary_poster> thanks :-)
[15:17] <hatch> thanks
[15:17] <rick_h_> gary_poster: heads up, the textarea stuff is a little more expensive because we can't resize until the nodes are in the dom, and they're not in the dom during the viewlet render() call currently. So adding support to viewlets for an afterRender() method to get around it
[15:18] <gary_poster> ack on call
[15:18] <hatch> jamie_: I'm looking in the folder, what are the files called?
[15:19] <Makyo> Heading to coffee shop so I get there in time for call.
[15:19] <gary_poster> ok
[15:19] <hatch> my legs hurt
[15:20] <hatch> how do you guys do this
[15:20] <hatch> it's only been 2.5h
[15:20] <rick_h_> hatch: takes a couple of weeks
[15:20] <rick_h_> hatch: and I tend to work in 2hr intervals
[15:20] <Makyo> hatch, rick_h_ +1 - I started in 1 hr intervals
[15:20] <rick_h_> but I'm not a model of standing desk coolness
[15:20] <hatch> maybe this will be motivation to lose those 20lbs
[15:21] <hatch> walking might actually be easier
[15:21] <Makyo> Anyway, back in a bit.
[15:22] <hatch> cya
[15:22] <jamie_> hatch: form-validation-tick.png & form-validation-cross.png
[15:22] <hatch> yeah I'm in the wrong folder
[15:22] <hatch> one sec
[15:22] <jamie_> in the folder OSCON Deliverables
[15:22] <hatch> ok found the files
[15:23] <jamie_> hatch cool :-)
[15:23] <hatch> ahh there we go
[15:23] <hatch> jamie_: I dont' think I have a mockup of this, do you guys want it IN the input box?
[15:24] <jamie_> hatch by "it" do you mean the check and the cross? 
[15:24] <jamie_> hatch if so then yes please
[15:25] <hatch> yeah ok - I think I'll need different assets then
[15:25] <hatch> assuming I'm going to use these as a background image
[15:25] <hatch> I'll need the image to have some padding to the right
[15:25] <hatch> I believe that's what Huw ended up doing with the configuration inputs
[15:35] <hatch> in setting up my vm I want to use the bzr technique where you 'init' the repo and then use lightweight checkouts but I can't remember what I should be searching for for the setup
[15:36] <hatch> ahh init-repo
[15:40] <hatch> hmm
[15:48] <hatch> yeah that's not working :/
[15:48] <bcsaller> hatch:  can you take another look at https://codereview.appspot.com/13253050 again when you have time, it should QA this time. looked into it over the weekend
[15:48] <hatch> bcsaller: can do
[15:48] <hatch> pulling
[15:48] <hatch> bzr: ERROR: Server sent an unexpected error: ('error', 'AlreadyControlDirError', 'A control directory already exists:
[15:49] <hatch> has anyone ever seen that error before?
[15:49] <hatch> when running bzr init-repo lp:juju-gui
[15:51] <Makyo> hatch Why are you init-repo-ing? 
[15:51] <Makyo> jujugui call in 8 kanban now
[15:52] <hatch> Makyo: so that I can do lightweight checkouts on my new vm like I do on my laptop
[15:52] <hatch> checking out a 70MB branch every time just doesn't make sense hah
[15:53] <hatch> bcsaller: lgtm'd
[15:53] <bcsaller> thanks :)
[15:53] <hatch> well.. lgtm'd now
[15:53] <Makyo> Why don't you just do bzr pull in the branch?
[15:53] <hatch> i forgot to type it hah
[15:53] <Makyo> Ah :P
[15:54] <hatch> Makyo: my workflow was to init the juju-gui folder, then every branch under it was a very fast pull
[15:54] <hatch> now it pulls down the full repo every time
[15:54] <Makyo> hatch: Me too, but you should only need to init once
[15:54] <hatch> the first time I inited it failed
[15:55] <Makyo> By saying that it was already inited?
[15:55] <hatch> yeah
[15:55] <hatch> no
[15:55] <hatch> it failed with...
[15:55] <hatch> bzr: ERROR: Transport operation not possible: http does not support mkdir()
[15:55] <Makyo> Oops :)
[15:55] <hatch> then I added the ssh key to my session and tried again
[15:57] <Makyo> jujugui call in 2 (What's the URL? Thought I saw it changed, forgot to set up 2fa before I left)
[15:57] <rick_h_> https://plus.google.com/hangouts/_/6be4e6d76bd266bd36ec5c5626c7d5a61d0ea88c?authuser=1 per the calendar
[15:57] <Makyo> rick_h_: thanks, can't get to calendar w/o 2fa
[15:58] <bac> what happened to the tiny one?
[15:58] <rick_h_> bac: google broke the links/remember setup
[15:58] <hatch> Makyo: yeah lightweight checkouts defiitely don't work ... :/
[15:58] <hatch> abentley: kickin around?
[15:59] <abentley> hatch: Hi.
[15:59] <Makyo> hatch: we can talk through it after call if you want, will show you how I do it.
[15:59] <hatch> abentley: when I try to run init-repo I get an error bzr: ERROR: Server sent an unexpected error: ('error', 'AlreadyControlDirError', 'A control directory already exists:
[15:59] <abentley> hatch: It sounds like a .bzr directory already exists.
[16:00] <gary_poster> bac benji call now in https://plus.google.com/hangouts/_/6be4e6d76bd266bd36ec5c5626c7d5a61d0ea88c?authuser=1
[16:01] <hatch> abentley: yeah no such luck
[16:01] <hatch> can I 'un-init' ?
[16:01] <hatch> hah
[16:01] <abentley> hatch: Sure: "rm .bzr".  But since you say it doesn't exist, that doesn't make sense.  Are there control directories for another VCS there?
[16:02] <hatch> it's a brand new vm with bzr just installed
[16:02] <hatch> I ran it twice though
[16:02] <abentley> hatch: what's your commandline?
[16:02] <hatch> when I ran it first it gave me an error bzr: ERROR: Transport operation not possible: http does not support mkdir()
[16:03] <hatch> abentley: bzr init-repo lp:juju-gui
[16:04] <Makyo> hatch: bzr init-repo juju-gui; cd juju-gui; bzr pull lp:juju-gui trunk; bzr branch trunk work; cd work; bzr reconfigure —lightweight-checkouts —bind-to ../trunk; # my workflow
[16:04] <abentley> hatch: I think you might have "init" confused with "init-repo".  "init" creates a bzr branch.  "init-repo" creates a shared repository.
[16:05] <Makyo> hatch: then you can bzr switch -b ../mine/<branchname> or whatever.
[16:05] <abentley> hatch: Since lp:juju-gui can only hold one branch, it does not make sense to created a shared repository there.
[16:05] <Makyo> hatch: yeah, I don't \think you want the lp:
[16:06] <hatch> ohh ok
[16:06] <abentley> hatch: But also, there is already a branch at lp:juju-gui, so you shouldn't init or init-repo.
[16:06] <hatch> well I dont' want to check out the full branch every time
[16:07] <Makyo> hatch: yeah, this will help with that, init-repo creates the shared repo locally. (correct me if I'm wrong abentley)
[16:07] <abentley> Makyo: you are correct.
[16:08] <abentley> As long as you don't try to create the shared repository *on launchpad*, which is what "lp:" means.
[16:08] <hatch> ok ohh ok well phew I'm glad it failed
[16:08] <hatch> haha
[16:09] <hatch> ok working by doing
[16:09] <hatch> `bzr init-repo juju-gui; cd juju-gui; bzr branch lp:juju-gui trunk`
[16:09] <hatch> now all the branch checkouts are fast
[16:12] <hatch> fwereade: is there a regex or a white/blacklist for characters for service names?
[16:14] <Makyo> Heading back home, will be back on tethered net there.
[16:25] <gary_poster> rick_h_, hatch, just spoke to luca__ about "ghost inspector: when you click "confirm" and successfully convert to a real service, close the ghost inspector and automatically open the service inspector (or similar)".  He is very open to different ideas for the future.  However, immediately prior to launch, the behavior as described is part of the larger UX story.  Simply trying to replace it with icons or tooltips or
[16:25] <gary_poster>  other approaches is something that will take thought and time that neither side (UX/engineering) has.  Simply omitting the interaction is something that he's dutifully considered in the past and is happy to reconsider in the future, but for now, prior to launch, that's a key part of the flow that's been designed with testing and feedback.  So in sum: (1) we should implement that behavior for release tomorrow, and (
[16:25] <gary_poster> 2) we should send an email to Luca and Ale, cc'ing peeps, describing what you think a better interaction would be for the future.  Cool?
[16:26] <rick_h_> gary_poster: understood
[16:26] <gary_poster> rick_h_, understood and cool? :-)
[16:26] <rick_h_> gary_poster: yep
[16:26] <gary_poster> :-) k
[16:26] <hatch> I am going to bet that it won't work
[16:27] <gary_poster> hatch technically or with users?
[16:27] <hatch> at the very least I think we will need to wait till the next delta
[16:27] <hatch> I 'think' there is a technical limitation
[16:27] <hatch> but I could be remembering incorrectly
[16:27] <rick_h_> hatch: right now there's not an event infrastructure to communicate that one is closing, open the other
[16:27] <hatch> as it is, if we open the inspector too fast we don't get the current unit count
[16:27] <rick_h_> hatch: so it'll have to be found/added
[16:28] <gary_poster> OK.  If there is we'll have to reconsider.  I suspect it is not a problem myself, because I think we create a service in the db immediately
[16:28] <gary_poster> and we have databinding to update these things
[16:28] <hatch> yeah I suppose you might be right
[16:29] <gary_poster> but if it is a big technical challenge--or even a medium sized one--of course then we should step back and consider that
[16:29] <hatch> arg this new VM Is driving me bonkers!
[16:29] <hatch> I need to write a script to set it up for me
[16:29] <hatch> haha
[16:30] <hatch> `make newVM`
[16:32] <Makyo> hatch: friend of mine wrote/uses https://github.com/josh-berry/homectl though I know some who do keep a Makefile for setting things up.
[16:33] <hatch> ahh cool that's a good idea
[16:34] <gary_poster> Hey Makyo, sometime today could you add cards (currently to Inspector/Next Tasks but we'll probably move them, as we discussed) to represent the remaining necessary tasks for the upgrade charm work?
[16:34] <Makyo> gary_poster: Sure
[16:34] <gary_poster> thanks Makyo 
[16:43] <rick_h_> hatch: got a sec?
[16:43] <hatch> yup call away
[16:47] <rick_h_> gary_poster: do you have a sec to jump into https://plus.google.com/hangouts/_/b9a2b84475d9ae68e7a7396eb719627ff917954f?hl=en ?
[17:00] <hatch> does anyone know what ppa lbox is in?
[17:00] <hatch> for saucy
[17:02] <hatch> rick_h_: so did you want me to show you how to implement that technique?
[17:02] <rick_h_> hatch: you have to compile it manual
[17:02] <rick_h_> hatch: no, I got it
[17:02] <hatch> R YOU FRIGGEN CERIAL!!!!?!?!?!
[17:02] <hatch> lol
[17:03] <hatch> are there docs on how to do that?
[17:05] <hatch> compile lbox that is
[17:07] <rick_h_> hatch: http://paste.mitechie.com/show/1023/ I think
[17:07] <rick_h_> hatch: that's after you get the go ppa and such going
[17:07] <hatch> ahh cool
[17:07] <hatch> thanks
[17:08] <rick_h_> http://paste.mitechie.com/show/1024/ updated
[17:10] <hatch> the 'golang' package also works
[17:12] <hatch> rick_h_: well your commands didn't work :(
[17:13] <rick_h_> hatch: sorry, that was from my shell history
[17:13] <hatch> well maybe missing a command about putting lbox in the bin?
[17:14] <rick_h_> hatch: not seeing anything
[17:14] <rick_h_> hatch: need to start a new shell to update your PATH?
[17:15] <hatch> oh maybe
[17:16] <hatch> negative
[17:16] <hatch> it did pull down the source
[17:16] <hatch> but the install doesn't do anything
[17:17] <rick_h_> hatch: was there an error then? Maybe something missing and installed failed?
[17:18] <hatch> nope nothing
[17:18] <hatch> no output, nothing
[17:18] <hatch> hmm
[17:18] <hatch> there is a /usr/lib/go/bin/lbox now though
[17:19] <hatch> so maybe I need to manually add that to my path
[17:19] <rick_h_> ah, I do have this in my zshrc
[17:19] <rick_h_> if [ -d "/usr/lib/go/bin" ] ; then PATH="$PATH:/usr/lib/go/bin"
[17:19] <rick_h_> fi
[17:19] <hatch> yep I'll have to add that to my bashrc
[17:19] <hatch> going to update the hacking docs with this info too
[17:29] <Makyo> Yay internet :)
[17:30] <hatch> so there is flooding there Makyo?
[17:36] <Makyo> Yeah, quite a bit for a while there.  We're getting a break up north, but there's a dam having trouble down south.
[17:44] <hatch> ahh darn - hope everyone's ok
[18:20] <bac> gary_poster: did you see my canonicaladmin request?
[18:21] <gary_poster> bac, from weekend? if so, yes, approved iirc.  will double check
[18:21] <bac> gary_poster: yes i think saturday
[18:21] <gary_poster> bac, yes, should be approved
[18:21] <bac> ty
[18:22] <gary_poster> ("No documents found" in canonicaladmin and I recall approving it)
[18:22] <gary_poster> welcmoe
[18:41] <hatch> rick_h_: reviewing
[18:41] <rick_h_> hatch: sec, pushing a rev now
[18:41] <rick_h_> hatch: and not done the inline comments yet until that lands
[18:41] <hatch> ok will wait
[18:41] <rick_h_> hatch: thanks, need like two minutes...well 2 lbox minutes. Might be 10 real minutes :P
[18:43] <rick_h_> hatch: ok go for it. I don't have much to add via inline comments really. It's not huge/complicated
[18:43] <rick_h_> thanks
[18:56] <hatch> qaing
[19:00] <hatch> done
[19:01] <rick_h_> hatch: cool thanks. I'll update that back. I had to do the .each() to debug in there and get at things and missed backing that out
[19:01] <rick_h_> I'm running away, will land that tonight. 
[19:01] <rick_h_> gary_poster: let me know if there's something I need to grab asap in the morning to help with landing.
[19:02] <gary_poster> thanks rick_h_ !  have a nice afternoon
[19:02] <gary_poster> hatch, opening inspector right after ghost is really easy as long as it is ok to do this:
[19:02] <gary_poster> this.options.environment.createServiceInspector(ghostService);
[19:02] <gary_poster> from ghost inspector
[19:03] <gary_poster> the hard part is that then I really want to fix the post deploy wiggle :-P
[19:05] <Makyo> gary_poster, there's a flag to control transitions; when that's checked, you could check (for example) a service.get('use_transition') as well?
[19:05] <Makyo> Or something.
[19:06] <gary_poster> Makyo I had this hack, which might be a start:
[19:06] <gary_poster>           var useTransitions = (
[19:06] <gary_poster>               self.get('useTransitions') && d.model.get('unit_count') > 0);
[19:06] <gary_poster> that gets rid of the animations in the one case I care about
[19:06] <gary_poster> but
[19:06] <gary_poster> the canvas still moves, presumably to center
[19:06] <hatch> gary_poster: I don't think that will work because the ghostService model is different
[19:06] <Makyo> gary_poster, correct.
[19:06] <hatch> so it will render the same UI
[19:07] <hatch> for example,. the options is a schema instead of a settings list
[19:07] <Makyo> gary_poster, I was just suggesting a flag rather than testing unit count, which will always be 0 (currently) for subordinates.
[19:07] <gary_poster> hatch, no that's a config option.  it seems to work great. <shrug>
[19:08] <gary_poster> hatch it is the same model
[19:08] <gary_poster> the same object
[19:08] <gary_poster> that's why it works
[19:08] <hatch> hmm /me can't remember when we changed that
[19:08] <hatch> but yay!
[19:08] <gary_poster> it was that way even before inspector
[19:09] <hatch> well I know for sure things like the inspector header test for a schema...if it's there it displays the ghost header
[19:09] <hatch> so there must be some difference...?
[19:09] <hatch> see inspector-header.js:35
[19:14] <fwereade_> hatch, sorry, I've been off packing today: it's in the juju-core/names package
[19:14] <hatch> fwereade_: no problem, thanks I'll look there
[19:14] <gary_poster> hatch pojoModel.scheme is undefined when I call it--which it needs to be, because, again, the model is reused.  I'll try to discover where scheme is reset...
[19:15] <gary_poster> Makyo, gotcha.  Lemme iron this other thing out then I'll want to pick your brain just a bit more.
[19:16] <hatch> gary_poster: ok I think ghost-inspector.js:302
[19:17] <gary_poster> no hatch, it is that when it is the ghost inspector, the model is a charm.  when it is a deployed inspector, the model is a service
[19:17] <gary_poster> charms have schemes, and services don't
[19:18] <gary_poster> so that condition in ghost-inspector could be written more directly
[19:22] <hatch> right, in _deployCallbackHandler it's no longer a ghost, but a real service
[19:22] <hatch> model
[19:24] <Makyo> gary_poster, going to walk dogs while it's sunny, will be back (and on real internet) in a few.
[19:25] <gary_poster> cool Makyo thx
[19:48] <hatch> I was going to use a spare machine for my dev box because it's wayyyy faster but some of these launchpad interactions need a browser...is there any way to do that oauth type stuff through the console?
[19:49] <gary_poster> hatch yes, if you are sshing in from a machine with a browser.  It will give you a link.  you can  copy and paste it into a real browser and accept there and all will be well
[19:50] <hatch> oh ok awesome - I was a little worried there was no other way :)
[19:50] <gary_poster> :-)
[19:56] <hatch> stepping away for a bit to grab something to eat
[20:05] <hatch> back
[20:05] <hatch> jujugui could I get a review on https://codereview.appspot.com/13253056/ plz thx
[20:08] <gary_poster> hatch I'll do it.  going to give you a hack branch to look at if you would.  "localCreation" thing does what I want but is hack.  requesting better approaches
[20:08] <hatch> sure np
[20:10] <gary_poster> hatch lp:~gary/juju-gui/ghostDeploy .  Last thing is that "Build Relation" menu should show and hide synced with inspector.  looked possibly tricky to me but maybe you see easy way. lp:~gary/juju-gui/ghostDeploy
[20:10] <gary_poster> show/hide sync is irrespective of these deploy changes
[20:13] <bac> hi gary_poster, here are the mappings that are done and work: http://paste.ubuntu.com/6116442/
[20:13] <bac> gary_poster: via this diff http://paste.ubuntu.com/6116440/
[20:13] <gary_poster> looking bac
[20:13] <hatch> looking bac at what?
[20:13] <hatch> *snicker*
[20:14] <gary_poster> bah :-)
[20:14] <bac> gary_poster: does that look about right?  i know the regex is greedy but i don't think it matters
[20:16] <gary_poster> hatch qa works but is weird: ghost starts showing, like (ceph 1) but then if you change it it becomes (ceph4).  Preexisting?  Easy to get rid of " 1" from service display, maybe?
[20:16] <gary_poster> initially I mean
[20:17] <hatch> hmm I'll check that out
[20:17] <gary_poster> bac you do not show http://10.0.3.199/charms/precise/wordpress-head transformation , though I suspect it works.
[20:17] <gary_poster> would be good to verify
[20:17] <bac> gary_poster: will try it
[20:17] <gary_poster> thx
[20:18] <hatch> gary_poster: do you mean when you change it to 'ceph4' ? As in there is no space
[20:18] <hatch> then yes that's been there forever
[20:18] <hatch> not really sure the purpose of the integer at the end
[20:18] <bac> gary_poster: goes to http://10.0.3.199/precise/wordpress
[20:18] <gary_poster> bac, I like simplicity of new rules
[20:18] <gary_poster> bac awesome
[20:19] <gary_poster> looks good bac.  here's hoping.  thank you.
[20:19] <gary_poster> hatch I expect it was there to support multiple ghosts, in theory...
[20:19] <bac> cool.  will document the setup script somewhere
[20:19] <gary_poster> hatch I'd suggest one of two courses.  you can choose a third which is "file a bug and move on" :-)
[20:20] <hatch> I can look at removing it from the canvas
[20:20] <hatch> shouldn't be much work
[20:20]  * hatch hopes
[20:20] <gary_poster> 1: remove " 1" from initial names.  Downside is that if we ever want multiple ghosts then that might make things more fragile.  but for now it is fine and makes sense
[20:21] <gary_poster> 2: disconnect service names in inspector from service names in canvas.  downside is that this is not intuitive.  oh here...
[20:21] <gary_poster> hatch, qa bad: try this
[20:22] <gary_poster> 1) create ghost.
[20:22] <gary_poster> (do *not* deploy)
[20:22] <gary_poster> let's say you named it ceph4
[20:22] <gary_poster> 2) create second ghost
[20:22] <gary_poster> try naming it the same thing
[20:22] <gary_poster> what should happen: service stays around
[20:23] <gary_poster> what happens: service disappears and then world breaks
[20:23] <gary_poster> (when you try to change the name again)
[20:23] <gary_poster> I'll doublecheck that this does not happen in trunk...
[20:24] <gary_poster> hatch it is pre-existing :-(
[20:25] <gary_poster> hatch so your branch is qa ok but this is a blocking bug
[20:25] <gary_poster> for release I mean
[20:25] <hatch> there is your bug for the day
[20:25] <hatch> :P
[20:26] <gary_poster> hatch, go me :-P :-)
[20:26] <hatch> haha - yeah yikes I see the bug
[20:26] <hatch> hmm that's going to be a tricky one
[20:27] <hatch> because the names need to be unique but only once it's saved
[20:27] <gary_poster> right
[20:27] <gary_poster> but since we are using real service names...
[20:27] <gary_poster> one option is this hatch:
[20:27] <gary_poster> we keep service names generated, and make them uneditable
[20:27] <gary_poster> for ghosts, we can edit another field
[20:28] <gary_poster> amd this other field is what is used to display
[20:28] <gary_poster> probably pretty easy change
[20:28] <gary_poster> but a hack :-/
[20:28] <hatch> and then on save use that field to set the id?
[20:28] <gary_poster> but we can maybe make it look like not a hack if we make it look pretty :-)
[20:28] <gary_poster> exactly
[20:29] <hatch> haha well we 'could' make it look identical but the code would be a little confusing
[20:29] <hatch> but no more than anything else we have haha
[20:29] <gary_poster> heh
[20:29] <gary_poster> it would only be in one place, yeah?
[20:29] <gary_poster> in the service topology code
[20:29] <gary_poster> everything else already has its won place to look
[20:30] <hatch> I can't remember how that part works
[20:30] <hatch> I can look into it though
[20:31] <gary_poster> hatch I gave you a LGTM and qa ok for this branch.  land it and then investigate bug separately?
[20:31] <gary_poster> all problems are pre-existing
[20:31] <hatch> yeah the bug is definitely separate - but I'll remove the service # indicator
[20:31] <gary_poster> and what you did doesn't make anything worse
[20:31] <gary_poster> ok
[20:32] <hatch> yuss!
[20:32] <hatch> that's really my daily goal, go to to sleep knowing I didn't make anything worse :P
[20:33] <gary_poster> hatch, did you have any deep thoughts about my branch or did I successfully distract you from it? ;-)  I can try bothering Makyo about it, and maybe try handing it off to him depending on how his other task is going
[20:33] <hatch> I got part of the way through it then was distracted :)
[20:33] <gary_poster> hatch, :-P the code was good and the feature is nice. *in regards to this particular bug* you didn't make anything worse. :-P
[20:34] <hatch> haha
[20:34] <gary_poster> hatch cool I'll bother Makyo.  hey Makyo, when you get back please ping me
[20:34] <gary_poster> hatch I'll file a bug, make a card and put your head on it for new bug, yeah?
[20:34] <Makyo> gary_poster, here.
[20:34] <gary_poster> oh hey Makyo 
[20:36] <gary_poster> Makyo, lemme file bug for Jeff, but while I do that could you take a look at lp:~gary/juju-gui/ghostDeploy ?  It is a sketch that works and *might* do what we want.  It seems good for the first service, anyway.  It is an ugly hack though, I currently think.  Additionally, I want one last thing: "Build Relation" menu should show and hide synced with inspector.  looked possibly tricky to me but maybe you see easy way.
[20:36] <gary_poster> Makyo, oh, well...
[20:36] <gary_poster> uh
[20:36] <gary_poster> I don't want to block your progress
[20:36] <gary_poster> how is doc writing going?
[20:38] <Makyo> gary_poster, going okay, about 80% done, then screenshots.  Should be proposed today, I hope.
[20:38] <Makyo> Will pull your branch and look, though.
[20:38] <gary_poster> Cool Makyo.  OK, thank you
[20:41] <gary_poster> hatch, bug on board in inspector for you
[20:41] <hatch> thanks - I can't find where this number is being set
[20:41] <hatch> hah
[20:41] <hatch> getting closer I think
[20:43] <hatch> found it!
[20:43] <gary_poster> hatch  /home/gary/dev/juju-gui/app/models/models.js line 406?
[20:43] <hatch> id: '(' + charm.get('package_name') + ' ' + serviceCount + ')',
[20:44] <hatch> yeah...you got lucky :P
[20:44] <gary_poster> :-)
[20:44] <gary_poster> I was looking for '('
[20:44] <hatch> oo good idea
[20:44] <gary_poster> hatch but actually
[20:44] <gary_poster> if you buy into my approach
[20:44] <gary_poster> you'll want to keep this code
[20:44] <gary_poster> or something similar
[20:45] <gary_poster> so that you have guaranteed-ish unique names
[20:45] <hatch> well it's kind of waky because the name in the inspector doesn't match the name in the canvas
[20:45] <gary_poster> in the real service name
[20:45] <gary_poster> yeah agreed
[20:45] <gary_poster> do what you hink hatch :-)
[20:45] <gary_poster> think, even
[20:45] <hatch> thinking
[20:46] <hatch> well....the serviceName should be bound to the model in the ghost
[20:46] <hatch> then we can keep it as is
[20:46] <hatch> we intentionally didn't bind them though
[20:46] <hatch> because 'why would the service name change' :D
[20:46] <hatch> so I'd probably opt for that
[20:47] <hatch> *he says with no idea the gremlins he may have just let loose on the world*
[20:47] <gary_poster> hatch, didn't quite follow.  if you want to talk it through lemme know
[20:47] <gary_poster> otherwise cool
[20:48] <hatch> sure
[20:48] <hatch> I'll call
[21:00] <gary_poster> Hey Makyo what's the word?  I should head out soon
[21:01] <gary_poster> so maybe will need to take it back tomorrow morning
[21:01] <Makyo> gary_poster, I think it looks good, actually.  That's what I was planning on doing if I wound up with it.
[21:02] <gary_poster> Makyo, oh ok
[21:02] <gary_poster> cool
[21:02] <gary_poster> lemme look at it again
[21:02] <Makyo> Kind of wondering about why we don't return immediately in findAndSetCentroid, but setting the centroid shouldn't have any side-effects, unless it shows up in zoom behaviors.
[21:04] <gary_poster> Makyo, if you don't think we should, I can undo; thought later code might expect the data to be there and be up-to-date.  I was just guessing/trying to code defensively
[21:04] <Makyo> gary_poster, Yeah, I guess my concern is the gas scenario with hundreds of services, where the new one may be way out on the edge.  The more I think about it, though, the less I think it matters.
[21:05] <Makyo> Can be addressed later if it's an issue.
[21:05] <gary_poster> OK Makyo, thanks.  will propose as is, then, if tests pass and so on...
[21:05] <Makyo> Cheers.
[21:11] <bac> gary_poster: i want to update the CDO instructions for deploying juju-gui charm to set ga_key.  But if I do so now, and they follow them with the current charm version, it'll error as the ga_key does not yet exist.
[21:12] <gary_poster> bac, add them to a "upcoming" section?
[21:12] <gary_poster> an
[21:12] <gary_poster> or to our own wiki page for later transfer?
[21:12] <bac> gary_poster: what is our schedule for next release of charm?
[21:13] <gary_poster> bac, next Monday or Tuesday at earliest: I want frankban around
[21:13] <bac> oh yeah, that was the dependency
[21:23] <gary_poster> hatch or Makyo or anyone else, code review plus deep-ish exploratory qa request: https://codereview.appspot.com/13246050/
[21:23] <gary_poster> I'm heading out
[21:23] <gary_poster> will be back later briefly to respond as needed or land if possible
[21:23] <gary_poster> bye all
[21:25] <Makyo> hatch, can you?  Want to get these docs done.  Otherwise, will get before EoD
[21:25] <Makyo> Or anyone else.
[21:26] <hatch> Makyo: my EOD is in 4 minutes so I can get to it once I get back from my errands
[21:26] <Makyo> hatch, oh, nvm then, I still have a few hours.
[21:26] <hatch> so how about - if you can get to it, great, if not, I can when I get back tonight
[23:19] <huwshimi> Morning
[23:50] <huwshimi> hatch: You're crazy! Why did you not just remove the ampersand?