[00:03] <huwshimi> rick_h_: Any specific cards you'd like me to take a look at today?
[00:03] <rick_h_> huwshimi: the big thing I'm going to try to QA and land the stuff from jcsackett and Makyo
[00:04] <rick_h_> huwshimi: and so the big thing is QA of the changes
[00:04] <huwshimi> rick_h_: OK, I can do some QA.
[00:04] <rick_h_> if you want to help QA those that's cool and once I can get them in we want to QA and see if we're good for release tomorrow
[00:36] <mbruzek> rick_h_, Thanks for responding.  I have deployed the charm with the "" values in there, it starts up on its own.  There is not a way to unset a variable (that I know of at least).
[00:37] <mbruzek> rick_h_, There was no other code changes other than config.yaml, so I am looking through the code to see if the config-changed hook uses None or empty string on any of those variables.
[00:38] <rick_h_> mbruzek: ok
[00:38] <mbruzek> rick_h_, So far I see a comment on the password configuration option # Normalize empty string passwords to None.
[00:39] <mbruzek> So setting password to "" looks safe, the other ones seem to be related to ssh keys which are harder to track down but I am on it.
[00:39] <mbruzek> Do you know of a way to unset a value?
[00:40] <rick_h_> mbruzek: https://juju.ubuntu.com/docs/commands.html
[00:40] <rick_h_> there's unset in there
[00:40] <rick_h_> mbruzek: but we don't support that in the gui
[00:41] <mbruzek> unset: set service config options back to their default
[00:41] <rick_h_> mbruzek: right
[00:41] <mbruzek> OK let me rephrase that, I don't know of a way to set a config value to None.
[00:41] <rick_h_> mbruzek: oh ok
[00:41] <rick_h_> right
[00:42] <mbruzek> I will get to the bottom of this.  I was just looking for any red flags from the GUI team if they KNOW this is an unsafe option.
[00:43] <mbruzek> When I was still green I reviewed the rabbitmq-server charm and it has some values that did not have defaults, so I defaulted them to "" and James Page noticed that was wrong because the code handles None differently than "" so I actually had to change them back.
[00:45] <rick_h_> mbruzek: yea, there was a giant thread about it before
[00:46] <mbruzek> That is what I am trying to avoid here... I will review this as normal 
[01:28] <huwshimi> rick_h_: With the mv flag I am unable to deploy a charm. Are you able to?
[01:29] <huwshimi> hmm... doesn't work on comingsoon for me either.
[01:29] <rick_h_> huwshimi: you need Makyo's branch that hooks up the button
[01:29] <rick_h_> huwshimi: that uses the state control stuff and you have to enter a magic command into the console to 'deploy'
[01:30] <huwshimi> rick_h_: I was just trying with the button in the inspector. Does that not work either?
[01:30] <rick_h_> huwshimi: right, so that just 'queues' up the deploy
[01:30] <huwshimi> ah right
[01:30] <rick_h_> huwshimi: that's the work that the deployer bar is doing
[01:30] <rick_h_> huwshimi: so it's in a middle state right now
[01:31] <huwshimi> rick_h_: I see. That branch is landing now I see.
[01:32] <rick_h_> huwshimi: yea, hoping to get that going so we can demo the working flow of inpsector on the left, going through deployer bar, and then into machine view
[01:32] <huwshimi> Nice
[01:32] <rick_h_> it's not complete, but we can demo that we've got all the ideas in place and we just need more time to finish stringing the wires to everything
[01:40] <rick_h_> huwshimi: can you qa this one from me as well please? https://github.com/juju/juju-gui/pull/261
[01:40] <huwshimi> Sure
[01:40] <rick_h_> thanks
[03:05] <rick_h_> heh, lovely WebDriverException: Message: None ; Stacktrace: 
[03:05] <rick_h_> yay for no messages
[03:06] <rick_h_> huwshimi: any luck qa'ing https://github.com/juju/juju-gui/pull/261 ?
[03:06] <huwshimi> rick_h_: Just started :)
[03:06] <huwshimi> (was having lunch)
[03:06] <rick_h_> ah gotcha thanks
[03:10] <huwshimi> rick_h_: This branch is just repositioning the inspector panel, not reusing the existing browser details panel?
[03:11] <rick_h_> huwshimi: it's using the same container space
[03:11] <huwshimi> rick_h_: Ah, ok.
[03:11] <rick_h_> huwshimi: so the inspector popout panels are going into the same container the charm details uses
[03:11] <rick_h_> the bws-view-data or whatever
[03:11] <huwshimi> rick_h_: Great!
[03:12] <huwshimi> rick_h_: The animations seem to have broken
[03:12] <rick_h_> huwshimi: on which ones? 
[03:12] <huwshimi> rick_h_: The details panel sliding in for the browser or the inspector
[03:13] <rick_h_> the inspector ones don't animate 
[03:13] <rick_h_> I'll look if I broke the details one as well
[03:13] <huwshimi> rick_h_: Well, they should if they re-use the same node though right?
[03:13] <rick_h_> it might be a follow up to make the details from the inspector animate like the service ones. 
[03:13] <rick_h_> they need more work
[03:14] <rick_h_> well, they use the same container, but don't use the same code path yet
[03:14] <rick_h_> I've kind of hacked them in for now with a follow up card to make them true views vs just viewlets 
[03:14] <rick_h_> the css chain is probably a bit different. It might be an easy fix, not sure
[03:15] <rick_h_> ok, so the charm details animations work ok
[03:15] <huwshimi> rick_h_: That's strange, I don't see them.
[03:16] <rick_h_> oh, no they don't with the feature flag in please
[03:16] <rick_h_> place
[03:16] <rick_h_> bah
[03:16] <rick_h_> that's broken on trunk as well http://comingsoon.jujucharms.com/:flags:/il/
[03:16] <rick_h_> so this branch did not break it, it's the new navigation stuff
[03:17] <huwshimi> oh I see
[03:19] <huwshimi> rick_h_: There are lots of places that if a url doesn't exist then the gui breaks instead of handling them (e.g. http://localhost:8888/inspector/service_29/:flags:/il/)
[03:19] <huwshimi> (I know that's unrelated)
[03:19] <huwshimi> (To this branch)
[03:19] <rick_h_> huwshimi: yes, that's due to the inspector stuff. I'm trying to think about it. In a live environment we want those to work. 
[03:20] <rick_h_> for the demo environment we want to just skip them I think
[03:20] <rick_h_> but we'll have to tackle that and figure out a good path. The idea is that you'll be able to link me to the inspector of a service in our shared live environment
[03:24] <huwshimi> rick_h_: I found another bug, but it happens on comingsoon as well. With the 'il' flag, if you click a charm in the sidebar and it opens the details panel and then you click 'deploy' the console shows an error: Cannot read property 'setStyle' of null
[03:24] <rick_h_> looking
[03:25] <rick_h_> huwshimi: ok, something in the sticky heading stuff blowing up there
[03:25] <rick_h_> huwshimi: will add a card
[03:26] <huwshimi> rick_h_: It's a really strange place to have an error. Doesn't seem related.
[03:26] <rick_h_> huwshimi: yea, I think there's some scroll event between the view getting killed for the inspector 
[03:27] <rick_h_> and when the charm search/etc goes away
[03:27] <huwshimi> Ah you could be
[03:27] <huwshimi> *yeah
[03:27] <rick_h_> and when the scroll event tries to figure out the size/etc the nodes are gone
[03:27] <rick_h_> and it bombs
[03:28] <huwshimi> yeah that makes sense
[03:29] <rick_h_> yea, that event isn't setup using addEvent() 
[03:29] <rick_h_> so it's not destroyed with the view
[03:29] <rick_h_> https://github.com/juju/juju-gui/blob/develop/app/subapps/browser/views/charmresults.js#L154
[03:29] <rick_h_> so changing it to use the event tracker/addEvent should fix it hopefuly
[03:30] <rick_h_> oh hmm, it's in the destructor though
[03:38] <huwshimi> rick_h_: I've finished the QA. Anything else you'd particularly like me to take a look at?
[03:39] <rick_h_> huwshimi: if you want to look at that error that'd be cool
[03:39] <huwshimi> rick_h_: Sure.
[04:01] <rick_h_> huwshimi: one other thing in qa'ing stuff here myself. The scrollbar fix actually messed up the inspector view a little bit in the :flags:/il
[04:01] <rick_h_> huwshimi: since it has a scrolling body it has a scroll bar in a diff location
[04:02] <huwshimi> oh
[04:02] <rick_h_> huwshimi: so that scrollbar showing fix is only when it's a charm result (editorial or search)
[04:02] <rick_h_> huwshimi: I missed that in qa originally, my bad
[04:03] <rick_h_> anyway, doesn't look like we'll be able to release tomorrow. Thanks for the qa in helping to point out issues out there. 
[04:03] <rick_h_> huwshimi: have a good day
[04:03] <huwshimi> rick_h_: OK no problems. Night!
[04:04] <rick_h_> huwshimi: can you put yourself on the card for today please?
[04:05] <huwshimi> rick_h_: Done.
[04:05] <rick_h_> ty much. You leave tomorrow? 
[04:06] <huwshimi> rick_h_: I leave on Sunday, and then get to the US on Sunday :)
[04:06] <rick_h_> lol oh ok hten
[04:06] <huwshimi> Tomorrow is a public holiday here.
[04:06] <rick_h_> ah ok
[04:07] <rick_h_> well if I don't run into you before vegas safe travels. Looking forward to getting together
[04:08] <huwshimi> rick_h_: Thanks, will be good to see you too. Have a good trip down.
[10:33] <rick_h_> frankban: was the git checkout stuff broken in the precise version of the charm?
[10:35] <frankban> rick_h_: trying the same on precise charm
[10:35] <rick_h_> frankban: also, the little guy wants to sleep in today. Is it ok to push back out 1-1 a little bit this morning?
[10:35] <rick_h_> frankban: I'm working on replicating it here. I hit it trying to put together a demo branch for kapil yesterday. 
[10:36] <rick_h_> deploying to ec2, and I have precise as the default series in my ec2 env
[10:36] <frankban> rick_h_: ok
[10:37] <frankban> rick_h_: I need to go out for lunch in 24 mins, other than that I am available nay time
[10:37] <frankban> any even
[10:37] <rick_h_> frankban: ok cool. Let's try after lunch then. bac is out so I don't have anything else until our stand up
[10:38] <rick_h_> and I'll see about duping this. I need to update my envs and switch my default series. bye bye precise! :)
[10:38] <frankban> :-)
[10:39] <frankban> rick_h_: also trying with a local env: juju bootstrap --upload-tools --series precise shoudl work around the bug
[10:39] <rick_h_> frankban: cool, yea I hit this because i wanted a real env so wondering if there's something in the version of git I hit. It had a strange error trying to do the clone of the new repo from git. 
[10:52] <rick_h_> frankban: verified the trusty charm does not fail on this issue. So another case of just use the latest charm silly
[10:52] <rick_h_> frankban: my hard coded default-series in the environments.yaml bit me
[10:53] <frankban> rick_h_: but it should work with the precise charm too, we test both scenarios on ec2
[10:54] <frankban> rick_h_: have to go, will ping you later
[10:54] <rick_h_> frankban: have fun, thanks for checking up on it
[11:56] <rick_h_> frankban: I'm back from taking the boy to day care. Let me know when you're back from lunch and we can do our call
[12:01] <frankban> rick_h_: I am back, joining the call
[12:28]  * rick_h_ goes to make coffee and breakfast
[13:13] <jcsackett> Morning, all. 
[13:13] <rick_h_> party
[13:15] <mbruzek> Good morning
[13:16] <rick_h_> mbruzek: hey, I saw the emails about the charm stuff from jose. I missed you were talking about our charm lol
[13:17] <mbruzek> frankban, Thanks for commenting on the juju-gui merge proposal.  I have a follow up question. If this next review passes should I not merge it with the charm in precise/juju-gui ?
[13:17] <rick_h_> mbruzek: no, we run our own promulgated charm. 
[13:17] <mbruzek> Sorry I didn't make that more clear rick_h_ 
[13:17] <rick_h_> mbruzek: it's not a ~charmers root charm and all changes should go through the team
[13:17] <rick_h_> mbruzek: it's the one charm you guys shouldn't have to worry about :)
[13:18] <mbruzek> rick_h_, so what should I do with Jose's MP?
[13:18] <rick_h_> http://bazaar.launchpad.net/~juju-gui-charmers/charms/precise/juju-gui/trunk/files
[13:18] <rick_h_> mbruzek: so I think he replied to frankban that he'd update in the right place
[13:19] <frankban> mbruzek: as I mentioned to him, he should repropose the branch against our development branch: lp:~juju-gui/charms/trusty/juju-gui/trunk
[13:19] <mbruzek> The way I read it, he would do that "later"
[13:20] <frankban> mbruzek: yeah, so I think we can safely close this MP
[13:20] <mbruzek> OK I will do that then.
[13:21] <frankban> mbruzek: thanks
[13:27] <frankban> rick_h_: what do you think about removing lp:~juju-gui/charms/precise/juju-gui/trunk and lp:~charmers/charms/precise/juju-gui/trunk? those branch will be no longer updated and can generate confusion
[13:27] <rick_h_> frankban: sounds good to me. 
[13:28] <frankban> rick_h_: no luck: This branch cannot be deleted as it has 22 branches sharing revisions.
[13:28] <hazmat> rick_h_, i don't see any 'local' charm specificity in the apis on the state server for charm file retrival
[13:28] <rick_h_> frankban: maybe pushed a MOVED file like we did with the gui when we moved to github?
[13:28] <mbruzek> frankban, What is the preferred fix here?  Leave login-help without a default?  If we do that then that allows users to set login-help to "" when they don't want anything displayed there.  Or change the if statement to generate the default text when login_help is None or empty string?
[13:29] <rick_h_> hazmat: hmm, talked with frankban about that this morning and we've added a card to make it non-local charm specific in the core api
[13:30] <mbruzek> frankban utils.py line 366
[13:31] <rick_h_> hazmat: I'll look for his patch there. The gui branch tries to load the files from juju but it responded that the charm couldn't be found so all the icons were just broken. So something is in there. 
[13:32] <hazmat> rick_h_, k, i'll try exploring with it a bit more.. i was just reviewing apiserver/charms.go
[13:32] <frankban> mbruzek: I don't have a strong opinion, and I don't know the story behind the decision to make proof warn when there is no default. A None default makes sense for the login-help, as you mentioned. On the other side I don't see so much value in having an empty login help. So I guess implementer choice?
[13:33] <mbruzek> frankban, I am OK with that one option exist without default.  I just wanted to see if that was OK with the gui team
[13:33] <rick_h_> hazmat: looking https://code.launchpad.net/~frankban/juju-core/get-charm-api/+merge/207994
[13:34] <frankban> mbruzek: +1 from me, let's leave login-help as is
[13:40] <rick_h_> hazmat: maybe only local charms are in the storage location we're looking in? Does juju store those in a different path or naming convention? I also don't see anything 'local' specific/filtering there. 
[13:40] <hazmat> rick_h_, different naming convention
[13:40] <hazmat> in provider storage for store charms
[13:41] <rick_h_> hazmat: ok, so that might be the issue. we're using the url local:precise/charm and if it's not cs:precise/charm then we'll have to tweak that to find it in juju land
[13:53] <hazmat> rick_h_, found the issue
[13:54] <hazmat> rick_h_, that code should be using the state api to get its download url of a charm
[13:54] <hazmat> rick_h_, at the moment its just using its own notion of the storage name/key 
[13:55] <rick_h_> hazmat: k, can you file a bug to that effect and assign it to yellow squad and I'll update our card on the board with a link to that
[13:56] <jcsackett> rick_h_: i'm thinking of taking on the new state inspector issues for local charms on project a--there an easier way to look into that than bootstrapping an environment with local charms?
[13:56] <rick_h_> jcsackett: yes, the code should work for sandbox as well. So the issue is pre environment work
[13:57] <rick_h_> jcsackett: let me know if you want to walk through any of the cards. 
[13:58] <jcsackett> rick_h_: how does one setup a local charm in sandbox mode?
[13:58] <jcsackett> rick_h_: i'm happy to chat via hangout if you prefer.
[13:59] <frankban> hazmat: interesting, re state api, where are you looking at?
[13:59] <frankban> jcsackett: you can just drag and drop a zipped charm to the canvas
[13:59] <jcsackett> frankban: oh, nice. i didn't know that.
[14:00] <rick_h_> jcsackett: yea, we use hatch's ghost charm to test :)
[14:00] <rick_h_> jcsackett: so you download the zip from github (download zip button) and drag it onto the environment and it should popup an inspector asking you to choose a series and upload it
[14:00] <hazmat> frankban,  state/charm.go  -> BundleURL()
[14:02] <hazmat> frankban, name := charm.Quote(curl) ; storage.get(name) only works with local charms.. it should really be using the charm state api to retrieve the url and just download it direct from that instead of using storage apis at all.
[14:03] <jcsackett> rick_h_: ah, i see, and that upload inspector is not loading. ok, easy enough to reproduce.
[14:03] <rick_h_> jcsackett: right, I've not looked to know what the root issue is. It's definitely due to the state stuff so need to see how it used to work and port it over to the new world order
[14:04] <rick_h_> jcsackett: which may be easy/pita depending on how it works currently
[14:04] <rick_h_> jcsackett: but let me know if you hit any questions
[14:04] <jcsackett> rick_h_: well, i've looked into a bunch of the new state handling stuff, so i'm in the right headspace. i'll ping you as i hit stumbling blocks.
[14:09] <frankban> hazmat: so charm, err := state.Charm(curl) and the using an http client to retrieve charm.BundleURL()?
[14:09] <hazmat> frankban, yes.. or juju-core/downloader
[14:17] <frankban> cool
[14:20] <rick_h_> jujugui going to push back the standup 30min if that's ok. Want to check in on the #is call at the top of the hour
[14:20] <jcsackett> fine by me.
[14:20] <kadams54>  Ditto
[14:20] <frankban> np
[14:20] <rick_h_> ty 
[14:22] <rick_h_> frankban: you need reviews right? I'll do one after the calls. We need a second?
[14:22] <frankban> rick_h_ thanks, jujugui: yes I need a second one
[14:24] <jcsackett> frankban: i can be the other. link?
[14:25] <frankban> jcsackett: https://codereview.appspot.com/90570044
[14:26] <jcsackett> frankban: cool, looking.
[14:26] <frankban> thanks
[14:36] <kadams54> guihelp Currently getting this error when running tests in browser: "No juju config to fetch charmworld store url"
[14:37] <kadams54> I suspect it's due to networking issues (not on my usual network) and vagrant. Was wondering if anyone had ever seen it before.
[14:37] <rick_h_> kadams54: that's failing something? It shoulnd't be an issue. 
[14:37] <kadams54> The test runner aborts when it hits that.
[14:37] <rick_h_> I think it's just dumped as a warning/message
[14:37] <kadams54> OK, well then it dumps and then the test runner just stops running
[14:37] <kadams54> Oh wait
[14:37] <kadams54> Hah
[14:38] <rick_h_> yea, that's just a warning error and is normal/fine
[14:38] <kadams54> Apparently the test runner did not stop running
[14:38] <kadams54> It just took minutes for a test to run
[14:38] <rick_h_> gotcha
[14:38] <rick_h_> cool
[14:38] <kadams54> I'd always hit reload or whatnot after 30 seconds of nothing going on
[14:39] <kadams54> But since I'm complaining about it in IRC, it had enough unmolested time to get through the hangup and move on…
[14:39] <rick_h_> lol yay irc
[14:40] <kadams54> I think there may be some sort of leak in our tests (or maybe mocha)… I've noticed that when I re-run the suite multiple times in a particular tab, it gets slower and slower. Opening up a new tab seems to fix the problem.
[14:42] <kadams54> Error: timeout of 100000ms exceeded
[14:43] <rick_h_> kadams54: ok, so taht's an async test that did not complete 
[14:43] <rick_h_> kadams54: look for a missing done() in the async bit
[14:43] <rick_h_> kadams54: or check that the async/etc got hit/fired
[14:47] <rick_h_> kadams54: push/paste the test if you need another set of eyeballs
[14:49] <jcsackett> kadams54: i've experienced a similar issue (leak-like slowdown) when running tests in the browser; when running them via test-{debug,prod} everything's a lot speedier.
[14:50] <kadams54> Yeah, everything is speedier, but there's some issue with phantomjs and vagrant where they bomb out.
[14:50] <kadams54> :-(
[14:50] <jcsackett> just use an LXC instead of vagrant. :p
[14:50] <rick_h_> jcsackett: those osx users don't have lxc
[14:50] <rick_h_> jcsackett: though that's an interesting question of does the issue exist when lxc in a vm is used as the environment
[14:51] <jcsackett> rick_h_: lxc...in a vm...on your main laptop. that may be too many turtles.
[14:51] <rick_h_> moar turtles!
[14:53] <kadams54> jcsackett: http://the.taoofmac.com/space/HOWTO/Vagrant
[14:53] <kadams54> I'd actually like to get this up and running :-)
[14:54] <jcsackett> wow.
[14:57] <kadams54> rick_h_: https://gist.github.com/kadams54/a3268988a82c8e9e089c
[14:57] <kadams54> I suspect the problem is in line 40
[14:58] <kadams54> But with that said, I'm wondering if any of the tested stuff in here is relevant anymore
[14:58] <rick_h_> kadams54: hmm so setting withHome on the view needs to trigger something that hits the showHome method
[14:59] <rick_h_> I'm not sure that's automatic. I can look after this call to look at that
[14:59] <kadams54> Since sidebar is now a much more dumb container and the home stuff has moved
[14:59] <rick_h_> kadams54: right, so this is an example of a test that does't matter to sidebar, but does to search.js and editorial.js now
[15:00] <kadams54> Yeah, I'd been trying to move over just some of the assertions, but on review, the entire test needs moving.
[15:01] <rick_h_> kadams54: rgr sounds good
[15:04] <rick_h_> kadams54: right so that test it checking https://github.com/juju/juju-gui/blob/develop/app/subapps/browser/views/view.js#L91 is bound correctly
[15:05] <rick_h_> kadams54: so this is part of the MainView that is injested into search.js and editorial.js via the charmresults.js
[15:12] <jcsackett> frankban: am i just seeing what i want to see, or is the 'bad wolf' stuff in quickstart a dr. who reference?
[15:12] <frankban> jcsackett: it is
[15:12] <jcsackett> \o/
[15:12] <frankban> :-)
[15:13] <frankban> jcsackett: so you understand it's a really bad error message
[15:13] <jcsackett> indeed, end of the world type stuff. :p
[15:22] <jcsackett> frankban: lgtm on your code with one comment, i'm starting qa now but probably won't finish until after the standup.
[15:22] <frankban> jcsackett: cool thanks
[15:25] <rick_h_> jujugui call in 5
[15:29] <rick_h_> jujugui call in 2 ... 1 ... where's makyo to do this for me :P
[15:31] <jcsackett> rick_h_: be there momentarily, fighting with G+.
[15:32] <rick_h_> kadams54: ^
[15:44] <kadams54> Yeah, sorry, I spaced the 11:30 time and left to run an errand
[15:45] <rick_h_> kadams54: ok, let us know if there's anything we can do to help with your branch. 
[15:45] <kadams54> Will do
[15:45] <rick_h_> kadams54: only news is no release today obviously, qa last night brought out a few more cards of work 
[15:45] <kadams54> ok
[15:46] <kadams54> jujugui: the main thing I had for standup is that there's a family emergency I need to take care of before Vegas, so I may be in and out more on Friday.
[15:46] <rick_h_> kadams54: ok
[15:47] <kadams54> Nothing too big, just needed to setup some appointments
[15:55] <jcsackett> frankban: i'm having issues qaing b/c my network is playing poorly with repositories and the juju pkgs ppa won't install/update. i'll try again later today from another network. it's not your branch tho.
[15:55] <jcsackett> or rick_h_, if you can handle qa ^
[15:56] <rick_h_> jcsackett: k, can look at that after review
[16:04] <hatch> so I've found out that sublime text is a huge power hog
[16:05] <hatch> it could be some of the plugins but it big time drags the battery down
[16:05] <rick_h_> hatch: welcome back to vim :P
[16:05] <rick_h_> hatch: heads up, we need to noddle on viewlets in a inspector-left world. 
[16:05] <hatch> haha, it seems every sprint I hop back into vim land
[16:05] <rick_h_> hatch: and if viewlets and the manager make sense any more
[16:05] <hatch> maybe it'll stick one of these days
[16:06] <rick_h_> hatch: we've got a training crew ready to meet you in vegas
[16:06] <hatch> lol
[16:07] <hatch> I don't see how the inspector-left has any impact on viewlets/viewlet-manager.....it could probably be renamed though
[16:07] <hatch> we still need a view manager I think
[16:07] <hatch> there was a bunch of stuff added into viewlet-manager for the inspector which can probably be refactored out
[16:07] <rick_h_> hatch: I'm having to work the popup viewlets out of the view manger because they're not a sub dom child element
[16:07] <hatch> so sure, we can chat about it, there is definitely room for improvment
[16:07] <rick_h_> hatch: so all rendering, event bubbling, etc don't work
[16:08] <hatch> oh for the left (now right) breakout?
[16:08] <rick_h_> hatch: right
[16:08] <rick_h_> all of that breaks becaus the inspector is the root element all delegation goes from (container, etc)
[16:08] <hatch> ahhh ok ok yeah that has always been tacked on - we can definitely improve that
[16:09] <rick_h_> so the viewlet-manager/etc isn't helping much, I'm more having to work around the system. 
[16:09] <hatch> chat in Vegas or sooner?
[16:09] <rick_h_> and then we need to figure out the routing straight to a popup stuff
[16:09] <hatch> right right
[16:09] <rick_h_> hatch: vegas is fine, just a heads up to ponder it
[16:09] <hatch> cool will do, I'll look at it
[16:09] <rick_h_> hatch: I've worked around it for now, but I've got a card to think of a better long term solution and would appreciate your feedback/input
[16:11] <hatch> oops heh
[16:11] <rick_h_> wrong button :P
[16:11] <hatch> yep haha
[16:12] <hatch> yeah it definitely needs some work to do right
[16:12] <rick_h_> hatch: cool, so speaking of pondering I'm going to go ponder my lunch choices. Thinking I'll leave my bat-cave today
[16:12] <hatch> enjoy!
[16:12]  * rick_h_ goes to find foods and biab
[18:03] <rick_h_> kadams54: hangout?
[18:03] <kadams54> Yup
[18:03] <kadams54> Will be there shortly
[19:12]  * rick_h_ heads out, have a good nigth all
[19:13] <rick_h_> err night
[19:59] <Makyo> jujugui having trouble getting juju to play with LXC, machine one never provisions.  I seem to remember something about clearing mongo caches; is that what I'm missing?
[20:04] <rick_h_> Makyo: there's a known but where a trusty host can't bring up precise machines or something atm
[20:05] <rick_h_> Makyo: make sure you've got a default series and that it's trusty for the bootstrap node I think
[20:05] <Makyo> Okay, thanks
[20:05] <rick_h_> Makyo: frankban was working around this bug in https://launchpad.net/bugs/1309455 today
[20:05] <_mup_> Bug #1309455: The auto-generated local env does not work in trusty <juju-quickstart:In Progress> <https://launchpad.net/bugs/1309455>
[20:06] <Makyo> Aha!  Thanks rick_h_ 
[20:30] <jcsackett> rick_h_: i've sorted the issue--apparently my debugger wasn't working right when i thought render didn't pop up--it's just rendering beneath the charmbrowser so it's invisible (unless you zoom out via browser controls rather than app). do we want this to render where it used to, or are all inspectors supposed to be on the left?
[20:32] <jcsackett> assuming all on the left, we can either set it to push the charmbrowser down so it's visible? or replace the browser a la the service inspector? the latter is, i think, considerably more work.
[20:33] <rick_h_> jcsackett: all on the left
[20:33] <jcsackett> right, like i assumed. so then appearance wise, should it take up all the space of the sidebar like the service inspector?
[20:33] <rick_h_> jcsackett: so we should remove the browser instance, and put the inspectot in its place
[20:33] <rick_h_> yep
[20:34] <rick_h_> the interesting question is that it's not really a routable item...
[20:34] <jcsackett> rick_h_: right.
[20:34] <rick_h_> so ssoi
[20:34] <rick_h_> bah
[20:34] <rick_h_> lag
[20:34] <rick_h_> so, we might need to do something where we hide/restore the browser stuff in there
[20:34] <rick_h_> as part of working around this
[20:34] <jcsackett> yeah.
[20:35] <rick_h_> jcsackett: so will have to look at where it gets created and determine the best path forward on it
[20:35] <jcsackett> "it" being the request-series inspector?
[20:35] <rick_h_> I'm not sure off the top of my head, for the ghost inspector we do "route"
[20:35] <rick_h_> jcsackett: yes
[20:36] <rick_h_> jcsackett: thinking it through,the normal process is to drop the charm, select the series, and then you get a ghost inspector, which is routed
[20:37] <rick_h_> jcsackett: so if we just hide the browser, then once you pick a series it needs to get destroyed, along with the browser stuff
[20:37] <rick_h_> if you close out, and choose not to complete the process we need to show back the browser 
[20:37] <rick_h_> jcsackett: want to point me where in the code the inspector is created and we can see if there's a sane way to hide the browser?
[20:38]  * rick_h_ will brb going to start a movie for the little guy. 
[20:38] <jcsackett> rick_h_: ok. 
[20:39] <jcsackett> so, it's created in service.js, which sets up the drag/drop handler for zip files. it has a method which calls the create/render code for the request-series thing, so that could handle hiding the charm browser at the same time.
[20:40] <rick_h_> looking, just want to make sure it's got easy enough access to the browser bits
[20:42] <rick_h_> ok, so it looks like it destroys the existing service inspector with the topo.fire('destroyServiceInspector')
[20:43] <rick_h_> but that may/may not be open. It really does need to set something in the state. Like component: "inspector", metadata: { services: services, file: file}
[20:44] <jcsackett> rick_h_: that was my thought and my fear.
[20:44] <jcsackett> :p
[20:44] <rick_h_> jcsackett: call?
[20:44] <jcsackett> s'why i wanted you to tell me to just make it work the way it used to.
[20:45] <jcsackett> rick_h_: migrated to a coffee shop that may be less than ideal, but let's give it a go.
[20:45] <rick_h_> yea, but that's no good. The topo.fire() needs to be a "destroy anything that's sticking around right now, but restore it if I close the dippy deployment inspector" which is basically what state does
[20:46] <rick_h_> https://plus.google.com/hangouts/_/7ecpj54iefa352n1pbj99t88eg?hl=en
[20:49] <jcsackett> rick_h_: i dropped, reconnected, and now i can't hear you.
[20:49] <jcsackett> do you even see me in the call?
[20:50] <rick_h_> byeok, I dropped 
[20:50] <jcsackett> well, i can hear you typing.
[20:50] <rick_h_> heh, ok
[20:50] <rick_h_> well I'm out now. Something hung on my end as well
[20:50] <jcsackett> rick_h_: ok, let me try again, calling you from the hangout app on my phone.
[20:50] <jcsackett> i think the wifi at the shop may not be up to this. :p
[20:51] <rick_h_> k
[20:53] <jcsackett> it's calling you on G+...i can't send a url, b/c iphone.
[20:53] <jcsackett> your canonical account.
[20:54] <jcsackett> ...or this is just a bust. i can sprint home and we can try in a few?
[20:54] <jcsackett> didn't think it would be *this* hangout hostile.
[20:54] <rick_h_> jcsackett: ok, no biggie
[20:54] <rick_h_> it's close to EOD and such
[20:55] <rick_h_> jcsackett: we can catch up in the morning and plot a path
[20:55] <jcsackett> rick_h_: fair. i'll figure this out a bit more, talk early AM tomorrow?
[20:55] <jcsackett> and you just said basically the same thing. so yeah, i'll ping you tomorrow morning.
[20:55] <rick_h_> jcsackett: rgr, take a peek at the state stuff. We'll need a new url test in the state code that builds an inspector component with metadata that says "this is a local charm deploy"
[20:56] <rick_h_> so poke around the new ui, test_ui_state.js, etc
[20:56] <jcsackett> and *doesn't* make it a component of the URL.
[20:56] <rick_h_> well the component is still inspector
[20:57] <rick_h_> but the metadata will have to instruct it which 'type' to build. We've got a few now
[20:57] <rick_h_> there's the normal service inspector, the local charm deploy, and the upgrade one I think. 
[20:57] <rick_h_> anyway, poke around and we'll chat in the morn
[21:00] <jcsackett> Dig. 
=== rogpeppe2 is now known as rogpeppe