huwshimirick_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 Makyo00:03
rick_h_huwshimi: and so the big thing is QA of the changes00:04
huwshimirick_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 tomorrow00:04
mbruzekrick_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:36
mbruzekrick_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:37
rick_h_mbruzek: ok00:38
mbruzekrick_h_, So far I see a comment on the password configuration option # Normalize empty string passwords to None.00:38
mbruzekSo 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
mbruzekDo you know of a way to unset a value?00:39
rick_h_mbruzek: https://juju.ubuntu.com/docs/commands.html00:40
rick_h_there's unset in there00:40
rick_h_mbruzek: but we don't support that in the gui00:40
mbruzekunset: set service config options back to their default00:41
rick_h_mbruzek: right00:41
mbruzekOK let me rephrase that, I don't know of a way to set a config value to None.00:41
rick_h_mbruzek: oh ok00:41
mbruzekI 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:42
mbruzekWhen 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:43
rick_h_mbruzek: yea, there was a giant thread about it before00:45
mbruzekThat is what I am trying to avoid here... I will review this as normal 00:46
huwshimirick_h_: With the mv flag I am unable to deploy a charm. Are you able to?01:28
huwshimihmm... doesn't work on comingsoon for me either.01:29
rick_h_huwshimi: you need Makyo's branch that hooks up the button01:29
rick_h_huwshimi: that uses the state control stuff and you have to enter a magic command into the console to 'deploy'01:29
huwshimirick_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 deploy01:30
huwshimiah right01:30
rick_h_huwshimi: that's the work that the deployer bar is doing01:30
rick_h_huwshimi: so it's in a middle state right now01:30
huwshimirick_h_: I see. That branch is landing now I see.01:31
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 view01: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 everything01:32
rick_h_huwshimi: can you qa this one from me as well please? https://github.com/juju/juju-gui/pull/26101:40
rick_h_heh, lovely WebDriverException: Message: None ; Stacktrace: 03:05
rick_h_yay for no messages03:05
rick_h_huwshimi: any luck qa'ing https://github.com/juju/juju-gui/pull/261 ?03:06
huwshimirick_h_: Just started :)03:06
huwshimi(was having lunch)03:06
rick_h_ah gotcha thanks03:06
huwshimirick_h_: This branch is just repositioning the inspector panel, not reusing the existing browser details panel?03:10
rick_h_huwshimi: it's using the same container space03:11
huwshimirick_h_: Ah, ok.03:11
rick_h_huwshimi: so the inspector popout panels are going into the same container the charm details uses03:11
rick_h_the bws-view-data or whatever03:11
huwshimirick_h_: Great!03:11
huwshimirick_h_: The animations seem to have broken03:12
rick_h_huwshimi: on which ones? 03:12
huwshimirick_h_: The details panel sliding in for the browser or the inspector03:12
rick_h_the inspector ones don't animate 03:13
rick_h_I'll look if I broke the details one as well03:13
huwshimirick_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 work03:13
rick_h_well, they use the same container, but don't use the same code path yet03: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 sure03:14
rick_h_ok, so the charm details animations work ok03:15
huwshimirick_h_: That's strange, I don't see them.03:15
rick_h_oh, no they don't with the feature flag in please03: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 stuff03:16
huwshimioh I see03:17
huwshimirick_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:19
rick_h_for the demo environment we want to just skip them I think03: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 environment03:20
huwshimirick_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 null03:24
rick_h_huwshimi: ok, something in the sticky heading stuff blowing up there03:25
rick_h_huwshimi: will add a card03:25
huwshimirick_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:26
rick_h_and when the charm search/etc goes away03:27
huwshimiAh you could be03:27
rick_h_and when the scroll event tries to figure out the size/etc the nodes are gone03:27
rick_h_and it bombs03:27
huwshimiyeah that makes sense03:28
rick_h_yea, that event isn't setup using addEvent() 03:29
rick_h_so it's not destroyed with the view03:29
rick_h_so changing it to use the event tracker/addEvent should fix it hopefuly03:29
rick_h_oh hmm, it's in the destructor though03:30
huwshimirick_h_: I've finished the QA. Anything else you'd particularly like me to take a look at?03:38
rick_h_huwshimi: if you want to look at that error that'd be cool03:39
huwshimirick_h_: Sure.03:39
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:/il04:01
rick_h_huwshimi: since it has a scrolling body it has a scroll bar in a diff location04:01
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 bad04:02
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 day04:03
huwshimirick_h_: OK no problems. Night!04:03
rick_h_huwshimi: can you put yourself on the card for today please?04:04
huwshimirick_h_: Done.04:05
rick_h_ty much. You leave tomorrow? 04:05
huwshimirick_h_: I leave on Sunday, and then get to the US on Sunday :)04:06
rick_h_lol oh ok hten04:06
huwshimiTomorrow is a public holiday here.04:06
rick_h_ah ok04:06
rick_h_well if I don't run into you before vegas safe travels. Looking forward to getting together04:07
huwshimirick_h_: Thanks, will be good to see you too. Have a good trip down.04:08
rick_h_frankban: was the git checkout stuff broken in the precise version of the charm?10:33
frankbanrick_h_: trying the same on precise charm10: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:35
rick_h_deploying to ec2, and I have precise as the default series in my ec2 env10:36
frankbanrick_h_: ok10:36
frankbanrick_h_: I need to go out for lunch in 24 mins, other than that I am available nay time10:37
frankbanany even10: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 up10:37
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
frankbanrick_h_: also trying with a local env: juju bootstrap --upload-tools --series precise shoudl work around the bug10: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:39
rick_h_frankban: verified the trusty charm does not fail on this issue. So another case of just use the latest charm silly10:52
rick_h_frankban: my hard coded default-series in the environments.yaml bit me10:52
frankbanrick_h_: but it should work with the precise charm too, we test both scenarios on ec210:53
frankbanrick_h_: have to go, will ping you later10:54
rick_h_frankban: have fun, thanks for checking up on it10:54
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 call11:56
frankbanrick_h_: I am back, joining the call12:01
* rick_h_ goes to make coffee and breakfast12:28
jcsackettMorning, all. 13:13
mbruzekGood morning13:15
rick_h_mbruzek: hey, I saw the emails about the charm stuff from jose. I missed you were talking about our charm lol13:16
mbruzekfrankban, 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
mbruzekSorry 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 team13:17
rick_h_mbruzek: it's the one charm you guys shouldn't have to worry about :)13:17
mbruzekrick_h_, so what should I do with Jose's MP?13:18
rick_h_mbruzek: so I think he replied to frankban that he'd update in the right place13:18
frankbanmbruzek: as I mentioned to him, he should repropose the branch against our development branch: lp:~juju-gui/charms/trusty/juju-gui/trunk13:19
mbruzekThe way I read it, he would do that "later"13:19
frankbanmbruzek: yeah, so I think we can safely close this MP13:20
mbruzekOK I will do that then.13:20
frankbanmbruzek: thanks13:21
frankbanrick_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 confusion13:27
rick_h_frankban: sounds good to me. 13:27
frankbanrick_h_: no luck: This branch cannot be deleted as it has 22 branches sharing revisions.13:28
hazmatrick_h_, i don't see any 'local' charm specificity in the apis on the state server for charm file retrival13:28
rick_h_frankban: maybe pushed a MOVED file like we did with the gui when we moved to github?13:28
mbruzekfrankban, 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:28
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 api13:29
mbruzekfrankban utils.py line 36613:30
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:31
hazmatrick_h_, k, i'll try exploring with it a bit more.. i was just reviewing apiserver/charms.go13:32
frankbanmbruzek: 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:32
mbruzekfrankban, I am OK with that one option exist without default.  I just wanted to see if that was OK with the gui team13:33
rick_h_hazmat: looking https://code.launchpad.net/~frankban/juju-core/get-charm-api/+merge/20799413:33
frankbanmbruzek: +1 from me, let's leave login-help as is13:34
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
hazmatrick_h_, different naming convention13:40
hazmatin provider storage for store charms13:40
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 land13:41
hazmatrick_h_, found the issue13:53
hazmatrick_h_, that code should be using the state api to get its download url of a charm13:54
hazmatrick_h_, at the moment its just using its own notion of the storage name/key 13:54
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 that13:55
jcsackettrick_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 work13:56
rick_h_jcsackett: let me know if you want to walk through any of the cards. 13:57
jcsackettrick_h_: how does one setup a local charm in sandbox mode?13:58
jcsackettrick_h_: i'm happy to chat via hangout if you prefer.13:58
frankbanhazmat: interesting, re state api, where are you looking at?13:59
frankbanjcsackett: you can just drag and drop a zipped charm to the canvas13:59
jcsackettfrankban: oh, nice. i didn't know that.13:59
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 it14:00
hazmatfrankban,  state/charm.go  -> BundleURL()14:00
hazmatfrankban, 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:02
jcsackettrick_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 order14:03
rick_h_jcsackett: which may be easy/pita depending on how it works currently14:04
rick_h_jcsackett: but let me know if you hit any questions14:04
jcsackettrick_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:04
frankbanhazmat: so charm, err := state.Charm(curl) and the using an http client to retrieve charm.BundleURL()?14:09
hazmatfrankban, yes.. or juju-core/downloader14:09
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 hour14:20
jcsackettfine by me.14:20
kadams54 Ditto14:20
rick_h_ty 14:20
rick_h_frankban: you need reviews right? I'll do one after the calls. We need a second?14:22
frankbanrick_h_ thanks, jujugui: yes I need a second one14:22
jcsackettfrankban: i can be the other. link?14:24
frankbanjcsackett: https://codereview.appspot.com/9057004414:25
jcsackettfrankban: cool, looking.14:26
kadams54guihelp Currently getting this error when running tests in browser: "No juju config to fetch charmworld store url"14:36
kadams54I 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
kadams54The test runner aborts when it hits that.14:37
rick_h_I think it's just dumped as a warning/message14:37
kadams54OK, well then it dumps and then the test runner just stops running14:37
kadams54Oh wait14:37
rick_h_yea, that's just a warning error and is normal/fine14:38
kadams54Apparently the test runner did not stop running14:38
kadams54It just took minutes for a test to run14:38
kadams54I'd always hit reload or whatnot after 30 seconds of nothing going on14:38
kadams54But 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 irc14:39
kadams54I 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:40
kadams54Error: timeout of 100000ms exceeded14:42
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 bit14:43
rick_h_kadams54: or check that the async/etc got hit/fired14:43
rick_h_kadams54: push/paste the test if you need another set of eyeballs14:47
jcsackettkadams54: 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:49
kadams54Yeah, everything is speedier, but there's some issue with phantomjs and vagrant where they bomb out.14:50
jcsackettjust use an LXC instead of vagrant. :p14:50
rick_h_jcsackett: those osx users don't have lxc14:50
rick_h_jcsackett: though that's an interesting question of does the issue exist when lxc in a vm is used as the environment14:50
jcsackettrick_h_: lxc...in a vm...on your main laptop. that may be too many turtles.14:51
rick_h_moar turtles!14:51
kadams54jcsackett: http://the.taoofmac.com/space/HOWTO/Vagrant14:53
kadams54I'd actually like to get this up and running :-)14:53
kadams54rick_h_: https://gist.github.com/kadams54/a3268988a82c8e9e089c14:57
kadams54I suspect the problem is in line 4014:57
kadams54But with that said, I'm wondering if any of the tested stuff in here is relevant anymore14:58
rick_h_kadams54: hmm so setting withHome on the view needs to trigger something that hits the showHome method14:58
rick_h_I'm not sure that's automatic. I can look after this call to look at that14:59
kadams54Since sidebar is now a much more dumb container and the home stuff has moved14: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 now14:59
kadams54Yeah, I'd been trying to move over just some of the assertions, but on review, the entire test needs moving.15:00
rick_h_kadams54: rgr sounds good15:01
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 correctly15:04
rick_h_kadams54: so this is part of the MainView that is injested into search.js and editorial.js via the charmresults.js15:05
jcsackettfrankban: am i just seeing what i want to see, or is the 'bad wolf' stuff in quickstart a dr. who reference?15:12
frankbanjcsackett: it is15:12
frankbanjcsackett: so you understand it's a really bad error message15:13
jcsackettindeed, end of the world type stuff. :p15:13
jcsackettfrankban: lgtm on your code with one comment, i'm starting qa now but probably won't finish until after the standup.15:22
frankbanjcsackett: cool thanks15:22
rick_h_jujugui call in 515:25
rick_h_jujugui call in 2 ... 1 ... where's makyo to do this for me :P15:29
jcsackettrick_h_: be there momentarily, fighting with G+.15:31
rick_h_kadams54: ^15:32
kadams54Yeah, sorry, I spaced the 11:30 time and left to run an errand15:44
rick_h_kadams54: ok, let us know if there's anything we can do to help with your branch. 15:45
kadams54Will do15:45
rick_h_kadams54: only news is no release today obviously, qa last night brought out a few more cards of work 15:45
kadams54jujugui: 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: ok15:46
kadams54Nothing too big, just needed to setup some appointments15:47
jcsackettfrankban: 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
jcsackettor rick_h_, if you can handle qa ^15:55
rick_h_jcsackett: k, can look at that after review15:56
hatchso I've found out that sublime text is a huge power hog16:04
hatchit could be some of the plugins but it big time drags the battery down16:05
rick_h_hatch: welcome back to vim :P16:05
rick_h_hatch: heads up, we need to noddle on viewlets in a inspector-left world. 16:05
hatchhaha, it seems every sprint I hop back into vim land16:05
rick_h_hatch: and if viewlets and the manager make sense any more16:05
hatchmaybe it'll stick one of these days16:05
rick_h_hatch: we've got a training crew ready to meet you in vegas16:06
hatchI don't see how the inspector-left has any impact on viewlets/viewlet-manager.....it could probably be renamed though16:07
hatchwe still need a view manager I think16:07
hatchthere was a bunch of stuff added into viewlet-manager for the inspector which can probably be refactored out16: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 element16:07
hatchso sure, we can chat about it, there is definitely room for improvment16:07
rick_h_hatch: so all rendering, event bubbling, etc don't work16:07
hatchoh for the left (now right) breakout?16:08
rick_h_hatch: right16:08
rick_h_all of that breaks becaus the inspector is the root element all delegation goes from (container, etc)16:08
hatchahhh ok ok yeah that has always been tacked on - we can definitely improve that16:08
rick_h_so the viewlet-manager/etc isn't helping much, I'm more having to work around the system. 16:09
hatchchat in Vegas or sooner?16:09
rick_h_and then we need to figure out the routing straight to a popup stuff16:09
hatchright right16:09
rick_h_hatch: vegas is fine, just a heads up to ponder it16:09
hatchcool will do, I'll look at it16: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/input16:09
hatchoops heh16:11
rick_h_wrong button :P16:11
hatchyep haha16:11
hatchyeah it definitely needs some work to do right16: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 today16:12
* rick_h_ goes to find foods and biab16:12
rick_h_kadams54: hangout?18:03
kadams54Will be there shortly18:03
* rick_h_ heads out, have a good nigth all19:12
rick_h_err night19:13
Makyojujugui 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?19:59
rick_h_Makyo: there's a known but where a trusty host can't bring up precise machines or something atm20:04
rick_h_Makyo: make sure you've got a default series and that it's trusty for the bootstrap node I think20:05
MakyoOkay, thanks20:05
rick_h_Makyo: frankban was working around this bug in https://launchpad.net/bugs/1309455 today20:05
_mup_Bug #1309455: The auto-generated local env does not work in trusty <juju-quickstart:In Progress> <https://launchpad.net/bugs/1309455>20:05
MakyoAha!  Thanks rick_h_ 20:06
jcsackettrick_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:30
jcsackettassuming 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:32
rick_h_jcsackett: all on the left20:33
jcsackettright, 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 place20:33
rick_h_the interesting question is that it's not really a routable item...20:34
jcsackettrick_h_: right.20:34
rick_h_so ssoi20:34
rick_h_so, we might need to do something where we hide/restore the browser stuff in there20:34
rick_h_as part of working around this20:34
rick_h_jcsackett: so will have to look at where it gets created and determine the best path forward on it20: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: yes20:35
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 routed20:36
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 stuff20: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:37
* rick_h_ will brb going to start a movie for the little guy. 20:38
jcsackettrick_h_: ok. 20:38
jcsackettso, 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:39
rick_h_looking, just want to make sure it's got easy enough access to the browser bits20:40
rick_h_ok, so it looks like it destroys the existing service inspector with the topo.fire('destroyServiceInspector')20:42
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:43
jcsackettrick_h_: that was my thought and my fear.20:44
rick_h_jcsackett: call?20:44
jcsacketts'why i wanted you to tell me to just make it work the way it used to.20:44
jcsackettrick_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 does20:45
jcsackettrick_h_: i dropped, reconnected, and now i can't hear you.20:49
jcsackettdo you even see me in the call?20:49
rick_h_byeok, I dropped 20:50
jcsackettwell, i can hear you typing.20:50
rick_h_heh, ok20:50
rick_h_well I'm out now. Something hung on my end as well20:50
jcsackettrick_h_: ok, let me try again, calling you from the hangout app on my phone.20:50
jcsacketti think the wifi at the shop may not be up to this. :p20:50
jcsackettit's calling you on G+...i can't send a url, b/c iphone.20:53
jcsackettyour canonical account.20:53
jcsackett...or this is just a bust. i can sprint home and we can try in a few?20:54
jcsackettdidn't think it would be *this* hangout hostile.20:54
rick_h_jcsackett: ok, no biggie20:54
rick_h_it's close to EOD and such20:54
rick_h_jcsackett: we can catch up in the morning and plot a path20:55
jcsackettrick_h_: fair. i'll figure this out a bit more, talk early AM tomorrow?20:55
jcsackettand 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:55
rick_h_so poke around the new ui, test_ui_state.js, etc20:56
jcsackettand *doesn't* make it a component of the URL.20:56
rick_h_well the component is still inspector20:56
rick_h_but the metadata will have to instruct it which 'type' to build. We've got a few now20: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 morn20:57
jcsackettDig. 21:00
=== rogpeppe2 is now known as rogpeppe

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!