[07:13] <rogpeppe1> mornin' al
[07:13] <rogpeppe1> l
[07:13] <huwshimi> rogpeppe1: Morning
[07:13] <rogpeppe1> huwshimi: hiya
[07:13] <rogpeppe1> huwshimi: when do you usually knock off, BTW?
[07:14] <rogpeppe1> huwshimi: i don't think we've ever actually coincided at a meeting or anything...
[07:15] <huwshimi> rogpeppe1: I knock off in 45 mins.
[07:15] <rogpeppe1> huwshimi: ah, you stop exactly as my day starts!
[07:15] <huwshimi> rogpeppe1: Yep! Handy isn't it :)
[07:16] <rogpeppe1> huwshimi: kind of amazing we can work it at all :-)
[07:16] <huwshimi> rogpeppe1: haha
[10:27] <frankban> morning rogpeppe1: could you please review https://github.com/juju/charmstore/pull/5 ?
[10:27] <rogpeppe1> frankban: looking
[10:27] <rogpeppe1> frankban: (morning!)
[10:32] <rogpeppe1> frankban: LGTM
[10:32] <frankban> rogpeppe1: thanks!
[10:40] <frankban> rogpeppe1: re the card "store: plan path for core store code to use own mongodb collection/data, (configurable?)". I guess it is already like that, right?
[10:40] <rogpeppe1> frankban: well, it does use its own mongo, yeah
[10:41] <frankban> rogpeppe1: ok, I'll move that card to done
[10:48] <rick_h_> morning 
[10:48] <rick_h_> rogpeppe1: got a sec to chat?
[10:48] <rogpeppe1> rick_h_: hiya, sure
[10:49] <rogpeppe1> rick_h_: wanna start a hangout?
[10:49] <rick_h_> rogpeppe1: https://plus.google.com/hangouts/_/g2acu2ejbn33yfrckk6jnylksia?authuser=1&hl=en
[11:01]  * frankban lunches
[11:11] <rick_h_> frankban: rogpeppe1 did you guys get your travel auth approved? Ramm said he was going to try to do them last night and want to check how far he got
[11:11] <rogpeppe1> rick_h_: mine's only a train ticket, which i think should be ok to just expense
[11:11] <rick_h_> rogpeppe1: ah, gotcha 
[11:42]  * rick_h_ goes to take the boy to day care, biab
[11:59] <bac> frankban: i have updated the quickstart readme for os x.  there is a separate card about updating the page on pypi.  that should not be necessary when 1.4.0 is pushed to pypi, right?  it will happen automatically.
[12:02]  * rick_h_ is back
[12:02] <rick_h_> bac: oh, that's probably true. 
[12:02] <rick_h_> bac: the card about pypi was just as I was qa'ing it looked out of date. I didn't look to note if it was using the readme as the content there. 
[12:03] <bac> rick_h_: np.
[12:03]  * bac wishes you could chain two cards together
[12:03] <rick_h_> well, feel free to wipe one
[12:20] <frankban> bac: +1 on the change on that card
[12:20] <bac> yeah i almost deleted it then reconsidered
[12:48] <rick_h_> luca: ping, can I get edit to the urls doc so I can create the tab to work in?
[12:50] <rick_h_> jujugui reminder about call in 10, please make sure to join the other channel for back channel conversations/etc
[12:53] <luca> rick_h_: done
[12:54] <rick_h_> luca: ty much
[13:01] <hatch> morning
[13:05] <rick_h_> party party
[14:56] <rick_h_> jujugui call in 5
[15:14] <rick_h_> crap, did I take someone's day for standup?
[15:14] <bac> Makyo: what did you say about elevators?
[15:14] <rick_h_> Makyo: hatch whoever I stole sorry and you can take thurs :)
[15:14] <hatch> yeah MINE!!!
[15:14] <hatch> lol s'ok
[15:15] <rick_h_> sorry hatch, was in a hurry today :P
[15:15] <bac> frankban: will your card be in review today?  you think i can do a release this afternoon?
[15:16] <rick_h_> luca: I'm out wed/thurs. I can do our call wed morning, but let's aim to keep it as short as we can please. 
[15:16] <frankban> bac: not sure, just started, will let you know in a bit
[15:16] <luca> rick_h_: this wednesday and thurs?
[15:16] <bac> frankban: ah, ok
[15:16] <rick_h_> luca: yes, I was just killing appointments :) 
[15:25] <Makyo> bac, Roger just guessed LTE meant "less trendy elevators" in chat.
[15:32] <Makyo> rick_h_, is the new upgrade stuff in a document somewhere?  Not having any luck finding it.
[15:32] <rick_h_> Makyo: sec, will look otp
[15:36]  * rick_h_ swears he's seen an image 
[15:37] <lazyPower> jcsackett: !! solved it
[15:37] <jcsackett> lazyPower: \o/
[15:37] <lazyPower> jcsackett: want to know the symptom/fix for that wonky hadoop charm?
[15:37] <jcsackett> lazyPower: yes, absolutely.
[15:37] <lazyPower> Welp, it started with pebkac
[15:37] <jcsackett> ah, i know that problem well.
[15:37] <lazyPower> when i promulgated the charm, charm tools has a series flag. and I omitted that
[15:37] <hatch> it's a serious problem here too
[15:37] <hatch> :P
[15:38] <jcsackett> that junk is epidemic.
[15:38] <rick_h_> Makyo: aha! found it https://drive.google.com/a/canonical.com/#folders/0B7XG_QBXNwY1Vmowb25PejhJOTg
[15:38] <rick_h_> Makyo: look in the bottom right, there's a 'change version'
[15:38] <Makyo> Ah, there we go.
[15:38] <rick_h_> Makyo: so by default, the inspector doesn't need to know the latest or even any list of versions
[15:38] <rick_h_> Makyo: so this leads me to ponder making the gui just delay that work until required
[15:39] <lazyPower> which put the branch tip for lp:charms/hadoop pointed at that trusty charm. Charm tools when checking that ~charmers owned the branch - had a brain fart, because the branch tip was lp:charms/hadoop
[15:39] <lazyPower> so, that all balled up into the problem we saw with an inconsistent publish. It half promulgated teh charm
[15:39] <Makyo> rick_h_, yeah, that sounds good.,
[15:39] <rick_h_> Makyo: or at least for now make it async, and have the inspector start out without the data so that you can move forward
[15:39] <lazyPower> which is consistent with what we found.
[15:39] <rick_h_> Makyo: and then we can disconnect the async call and move it to the button press as we update the inspector UI
[15:39] <rick_h_> jcsackett: got time to chat?
[15:41] <jcsackett> lazyPower: good to know. y'all got a place to document that in case we see this oddity again in the GUI?
[15:41] <jcsackett> rick_h_: sure.
[15:42] <jcsackett> rick_h_: standup hangoug?
[15:42] <jcsackett> er, hangout
[15:42] <rick_h_> jcsackett: sure
[15:42] <hatch> lazyPower jcsackett this kind of seams like an issue in the process IMHO 
[15:48] <jcsackett> hatch, lazyPower: perhaps charm tools should now *require* series on promulgation, so it dies messily and angrily if its omitted?
[15:49] <jcsackett> we now live in a multi-series world for charms. 2 LTSes.
[15:49] <lazyPower> jcsackett: not a bad suggestion
[15:51] <hatch> yeah that sounds like a pretty good idea
[16:05] <hatch> jcsackett didn't you create a bug for removing the fillslot stuff?
[16:05] <frankban> bac: I should be able to propose soon
[16:05] <hatch> or was it just a card? I'm having no luck finding it here
[16:09] <jcastro> hey fellas
[16:09] <jcastro> have you guys seen it where you drag a bundle
[16:09] <jcastro> and then nothing happens, so you drag it again, and again a few times
[16:10] <jcastro> then a few seconds later the gui "catches" up and it returns all the errors 
[16:10] <jcastro> I can't really explain it other than a "lag" for a bundle
[16:11] <rick_h_> jcastro: no, but might be that we wait for juju to acknowledge the bundle before showing the notification and we shouldn't be
[16:11] <jcastro> OH.
[16:11] <rick_h_> jcastro: we can investigate that, I'll file a bug
[16:11] <jcastro> that sounds exactly what I experienced
[16:13] <rick_h_> jcastro: added https://bugs.launchpad.net/juju-gui/+bug/1331061 and will get it on the board to look at soon
[16:13] <hatch> hmm looking
[16:13] <_mup_> Bug #1331061: bundle deployment delay in drag/dropping a bundle in live environments <juju-gui:Triaged> <https://launchpad.net/bugs/1331061>
[16:13] <jcastro> rick_h_, I hadn't ever noticed it until MAAS
[16:14] <jcastro> the gui ran so well this weekend man
[16:14] <jcastro> everything worked
[16:14] <rick_h_> jcastro: yea, live environment vs demo and such probably
[16:14] <rick_h_> jcastro: awesome! glad to hear it. 
[16:14] <hatch> rick_h_ jcastro  yes that's the problem - we wait until juju says it received it before throwing a ntification
[16:14] <hatch> I'll update the bug
[16:15] <hatch> jcastro yay :) 
[16:15] <rick_h_> hatch: thanks, added a maint card for next sprint
[16:15] <jcastro> one other thing
[16:15] <jcastro> I don't know if this is a gui bug or not
[16:15] <jcastro> so, people make bundles right
[16:15] <jcastro> but we're lazy and call all the DBs in each bundle "mysql"
[16:15] <jcastro> so when I want to deploy multiple bundles in one environment
[16:15] <jcastro> it errors our because there can only be one mysql
[16:16] <jcastro> other than renaming charms in bundles to like "mysql-mediawiki" and so on, is there a way we can be smarter?
[16:16] <jcastro> perhaps prompt for a new name if there's a collision?
[16:16] <rick_h_> jcastro: yea, so the plan eventually is to make bundles part of the pre-deployment story. 
[16:16] <rick_h_> jcastro: like the deployer bar/uncommitted stuff
[16:16] <jcastro> oh ok, so I can sort that before I hit the button
[16:16] <jcastro> cool, just wanted to make sure you guys had thought of that
[16:17] <rick_h_> jcastro: but it's not going to happen right away, it's more towards the end of the cycle
[16:17] <jcastro> obviously GMTA
[16:17] <rick_h_> jcastro: yea, the goal is you could even drag a bundle from an email, tweak the unit counts/colocate, etc
[16:17] <rick_h_> and THEN hit deploy
[16:18] <hatch> bug updated
[16:18] <jcsackett> hatch: i made a card in backlog.
[16:18] <hatch> jcsackett thanks
[16:37] <hatch> 14C man our weather just sucks this year
[16:37] <hatch> few days of nice weather followed by two weeks of rain and cold!
[16:38] <rick_h_> heh, we're crossing 30 and I'm very displeased
[16:39]  * rick_h_ grabs my weapons (cell phone, car keys) and goes out to hunt down lunch
[16:39] <hatch> lata
[16:39] <hatch> Makyo any idea when you want to get together to chat about this ecs stuff?
[16:40] <Makyo> hatch, whenever is fine.
[16:40] <hatch> Makyo hows about now in the standup room?
[16:41] <Makyo> Sure, be right there
[16:56] <frankban> bac: https://codereview.appspot.com/105920046
[16:56]  * bac looks
[16:57] <frankban> thanks
[16:57] <hatch> is there a `juju destroy-machine --force` ?
[16:58] <bac> frankban: done.  didn't do QA.
[16:58] <frankban> bac: that;s ok, ty
[16:59] <bac> frankban: so do you want me to do the release?
[16:59] <frankban> bac: yes do it please
[16:59] <bac> ok, i will start in 30 minutes or so.
[17:00] <frankban> bac:cool
[17:00] <hatch> lazyPower hey is there a `juju destroy-machine --force` ? http://stackoverflow.com/questions/24250809/juju-destroy-service-do-not-remove-failed-services/24251250?noredirect=1#comment37469742_24251250
[17:00] <bac> frankban: hey would you tag the branch before you commit?  'bzr tag 1.4.0'
[17:01] <lazyPower> hatch: yep. juju destroy-machine # --force will force removal
[17:01] <hatch> lazyPower thanks that's not in the man file
[17:01] <lazyPower> is there a hook that is in error in your environment or an open debug-hooks session? those are the 2 most common causes
[17:01] <lazyPower> hatch: its pretty much a hulk smash at removal though. use with caution. Its going to send a terminate command to your cloud provider
[17:01] <frankban> bac: tagging is a good idea. I'd be inclined to do that after the release QA
[17:02] <frankban> bac: merged
[17:03] <frankban> bac: so we basically release PPA and PyPI packages and then the last step is to just add a "v1.x.y" tag and push back to trunk
[17:03] <hatch> lazyPower thanks, I updated my answer
[17:03] <hatch> lazyPower feel free to upvote if you think it's the proper answer :D
[17:04] <bac> frankban: sounds good.  but more granular, build PPA, QA packages, then push to pypi.  right?
[17:05] <frankban> bac: yeah, the usual workflow, just adding a "bzr tag" at the end of the process
[17:14] <lazyPower> bzr supports tagging? #TIL
[17:25] <Makyo> hatch, sorry for ducking out.  We good with me starting on the remove relation ECS next?
[17:25] <hatch> Makyo yep I'm just trying to plan the set config stuff - want to resume that chat?
[17:25] <Makyo> Sure.
[17:29]  * rogpeppe is done for the day
[17:29] <rogpeppe> g'night all
[17:30] <rick_h_> have a good night rogpeppe 
[17:36] <hatch> lazyPower can you see if you can answer the guy in #juju he is also asking in the golang channel abuot this stuff
[17:36] <hatch> rick_h_ can you join the standup room?
[17:36] <rick_h_> hatch: rgr
[18:02] <bac> god, why do i never learn and still read the comments?  nice ars article ruined for me...
[18:08] <hatch> bac lol - those comments make it clear that people comment before reading the article
[18:08] <rick_h_> bac: yea, I had the same *ugh!* reaction
[18:09] <bac> my hat is off to people like popey who wade in...
[18:10] <hatch> "Here's your sign"
[18:10] <lazyPower> 'ey Hatch - can i bother you for a testimonial/comment on my Ubuntu application? I'm up for membership review tomorrow and could use any/all of the feedback you can give. 
[18:11] <hatch> lazyPower sure - I have no idea what you're talking about though lol
[18:11] <lazyPower> http://wiki.ubuntu.com/LazyPower
[18:11] <lazyPower> hatch: its part of becoming a Ubuntu Member - there's a membership board that reviews your application (the wiki page) and they rule based on the merit of your contributions to Ubuntu as a whole.
[18:12] <hatch> got it, yep I'll write out some fancyness today for ya
[18:13] <hatch> thanks for helping out the guy in #juju btw
[18:13] <lazyPower> NP. It's what I'm here for :)
[18:13] <hatch> haha i knew I could count on you!
[19:24] <hatch> I finally got around to posting about the latest gui release http://fromanegg.com/ I think I hit on all the main points
[19:48] <hatch> bleh, rick_h_  so this isn't going to be as simple as I had thought, databinding is what stores the dirty fields atm
[19:48] <hatch> not that I thought this would be simple
[19:51] <rick_h_> hatch: right, but that's the conflict issue. 
[19:52] <hatch> right - but we'll now have two 'dirty' indexes
[19:52] <rick_h_> hatch: but the dirty can be in the model from the UI/ECS side ofthings. however, we need a path to getting the databinding dirty/conflict into somewhere the UI can access as well
[19:52] <rick_h_> hatch: right, we always were going to have to
[19:52] <rick_h_> hatch: I guess we can call one 'uncommitted' and one 'dirty/conflict'
[19:53] <hatch> the issue is that the model needs to reach into the databinding to find out what's dirty before sending the dirty list to the ecs so it doesn't overwrite changes that it shouldn't be
[19:53] <hatch> standup hangout?
[19:53] <rick_h_> hatch: sure
[19:55] <hatch> https://plus.google.com/hangouts/_/canonical.com/daily-standup?authuser=1
[19:55] <hatch> oh wait I think I figured it out
[19:55] <hatch> :)
[19:55] <hatch> from now on I should just hop into a hangout and talk to myself
[19:56] <rick_h_> lol, I joined but didn't see you
[19:56] <hatch> yeah the model doesn't actually need to know whats in the databinding conflict because that's only a UI thing
[19:56] <hatch> the model is actually updated right away
[19:57] <rick_h_> hatch: right
[19:57] <rick_h_> +1
[19:58] <hatch> ugh I hate this databinding stuff
[19:58]  * hatch opens file, gets punched in the face
[19:58] <kadams54> Back from the go karting… me being a nice son, I let my old man score the best time.
[19:58] <hatch> wb
[19:58] <kadams54> Though we did tangle up in one corner after he spun out in front of me.
[19:59] <kadams54> http://www.newcastleraceway.com/photos/newphotos/aerial-82409-4.jpg <- the race track we were on.
[19:59] <hatch> nice track
[20:00] <kadams54> These were racing karts… not the ones that your local mini-golf place hase.
[20:00] <kadams54> hase? has.
[20:00] <kadams54> We were both spanked by what appeared to be a 10-year-old girl
[20:01] <kadams54> She wasn't on a rental kart.
[20:01] <hatch> here is our race track https://www.google.com/maps/place/Martensville+Speedway/@52.301784,-106.648735,311m/data=!3m2!1e3!4b1!4m2!3m1!1s0x53045c2c9f46f337:0xffb39df6a0df0a44
[20:01] <hatch> there is also a few rental tracks around 
[20:01] <hatch> but this one is for real race karts
[20:02] <kadams54> Good stuff
[20:02]  * hatch used to race
[20:02] <kadams54> Hah!
[20:02] <kadams54> Man
[20:02] <kadams54> We need to find a race track some sprint
[20:02] <hatch> for 14 years actually :)
[20:02] <kadams54> Then you can help me level up my racing foo for the next father-son matchup
[20:02] <hatch> sounds like a plan to me!
[20:02] <hatch> lol
[20:03] <hatch> I'd love to get back into it again but I don't have the time :(
[20:03] <kadams54> I grew up in Indy so we're big racing fans
[20:03] <kadams54> This was about 30 minutes east of Indy
[20:03] <hatch> oh nice
[20:04] <hatch> kadams54 any idea how long that track is? Ours is about 1km - yours looks very similar
[20:04] <kadams54> hatch: 1 mile or 1.6 km
[20:05] <kadams54> I'll post photos and videos to Google+ once they're ready.
[20:05] <hatch> oh wowzers that's one long lap!
[20:05] <hatch> yes definitely
[20:05] <kadams54> We raced for about 30 minutes, so it was a good amount of time to get comfortable and start to learn the track.
[20:05] <hatch> yeah, well your laps must have been what....35-40s?
[20:06] <kadams54> I think 1'26" was my fast lap, my dad had 1'25"
[20:07] <kadams54> I wouldn't be surprised if the 10-year-old pro was running 35-40s though
[20:07] <hatch> hah, well they probably throttle down the rentals too though
[20:07] <kadams54> Sure seemed like she had twice as much speed when she passed me on the straightaways :-)
[20:07] <hatch> haha
[20:07] <kadams54> It's a good thing, since I t-boned my dad in his spin
[20:07] <hatch> haha
[20:08] <hatch> lazyPower I'm having trouble logging in to wiki.ubuntu.com, it keeps hanging, i'll try again later
[20:12] <ahasenack> hi, I deployed juju-gui on precise with all default options, and then I used that to deploy the hadoop bundle from the store,
[20:12] <ahasenack> I got an error in a juju-gui notification and would like to debug it
[20:12] <ahasenack> the note says:
[20:12] <ahasenack>  1 notifications
[20:12] <ahasenack>     Failed to load charm details.
[20:12] <ahasenack>     Charm API error of type: no_such_charm 4 minutes ago
[20:12] <ahasenack> and that's it
[20:13] <ahasenack> where can I find out what it was trying to do? Which charm was it trying to load details from?
[20:13] <hatch> ahasenack oh yeah there is an issue with a charm
[20:13] <hatch> can you link me to the bundle to confirm?
[20:13] <ahasenack> otherwise the bundle deployed, there are hook errors but that's unrelated as it happened much later
[20:13] <ahasenack> bzr branch http://bazaar.launchpad.net/~charmers/charms/bundles/hadoop/bundle
[20:13] <ahasenack> it what is says in the UI
[20:13] <hatch> ok thanks one sec
[20:15] <hatch> ahasenack hmm that bundle is deploying fine here in sandbox mode - did you happen to use Chrome?
[20:15] <ahasenack> no, firefox
[20:15] <hatch> hmm ok, I'm hoping there is an error in the js console
[20:15] <hatch> (chrome persists errors but I'm not sure firefox does)
[20:15] <ahasenack> there's this, not sure if it's recent or old
[20:15] <ahasenack> Unexpected value translate(undefined,undefined) parsing transform attribute. all-yui.js:19
[20:15] <ahasenack> The Web Console logging API (console.log, console.info, console.warn, console.error) has been disabled by a script on this page.
[20:16] <hatch> yeah that one can be ignored
[20:16] <ahasenack> but, doesn't look like the gui failed, it started the deploy, I got units
[20:16] <ahasenack> should I try again with some debugging mode?
[20:16] <hatch> yeah so basically what that error means is that the charm that the bundle is trying to deploy doesn't exist
[20:16] <ahasenack> hatch: ok, any way to find out which charm that is?
[20:17] <ahasenack> I was expecting it to be in the error message :)
[20:17] <hatch> well the json returned from juju-core should include that 
[20:17] <ahasenack> other than that, the service count seems correct, the readme says 4 services will be deployed, and that's what I got
[20:17] <rick_h_> ahasenack: well there's 3 charms and 4 services in that bundle. Did all of them come up?
[20:17] <hatch> this is definitely a bug that we aren't exposing that to the user
[20:17] <ahasenack> all services are there
[20:18] <ahasenack> hadoop-master, hadoop-slavecluster, hive, mysql
[20:18] <ahasenack> all but mysql have some failed hook, but that happened after the notice I got from juju-gui
[20:21] <hatch> we should expose the charm name to the user though for this error message
[20:21] <rick_h_> hatch: yea, verified each charm responds via the api. That error is typically when the GUI tries to load a charm from manage.jujucharms.com but it can't find it
[20:21] <hatch> I'll create a bug
[20:21] <ahasenack> is that done via port 80 and/or 443?
[20:21] <ahasenack> I'm behind a firewall, let me check connectivity to that host
[20:21] <rick_h_> ahasenack: yes 443
[20:21] <ahasenack> aha
[20:21] <ahasenack> port 80 works
[20:21] <ahasenack> 443 is blocked
[20:21] <rick_h_> ahasenack: it's a typical restful api behind https
[20:21] <rick_h_> ahasenack: that'll do it then
[20:21] <hatch> ahah!!
[20:21] <rick_h_> so the GUI tried to fetch the charm info and failed because of network connectivity
[20:21] <ahasenack> rick_h_: that's not where the charm is deployed from, it's to get other info
[20:22] <ahasenack> ok, gotcha
[20:22] <rick_h_> ahasenack: right, the charm itself comes from another url
[20:22] <ahasenack> thanks guys
[20:22] <rick_h_> ahasenack: but the metadata, used to show things like icons, readme files, etc comes from manage.jujucharms.com
[20:22] <ahasenack> but I was able to see the README for the bundle
[20:22] <ahasenack> in this case, it's the individual READMEs for each charm the bundle deploys?
[20:22] <hatch> rick_h_ when we load the gui we should ping these places to see if we can connect to avoid these issues because they are kind of secret 
[20:23] <rick_h_> ahasenack: well it depends on what you were interacting with at the time. Normally it's from clicking on a service (and the inspector pops up) or something
[20:23] <ahasenack> so, I juju deploy juju-gui
[20:23] <ahasenack> hit the web interface, logged in
[20:23] <ahasenack> searched for hadoop, several options showed up
[20:23] <ahasenack> picked the cluster one
[20:23] <ahasenack> read the README, and other tabs
[20:23] <rick_h_> hatch: well, we've got WIP for the store to have the info so if you don't have access to get this data you can't deploy charms either 
[20:23] <ahasenack> all that worked
[20:23] <ahasenack> does any of that come from manage.jujucharms.com?
[20:23] <rick_h_> ahasenack: yes
[20:23] <ahasenack> maybe on port 80?
[20:24] <rick_h_> it shouldn't, but possible I suppose
[20:24] <ahasenack> that is the only one open here for that site, at the moment
[20:24] <ahasenack> I'll try the network tab before asking for port 443 to be opened
[20:24] <rick_h_> ahasenack: ah yea, some of the api calls will work over 80
[20:24] <ahasenack> ah, good (to have an explanation)
[20:25] <rick_h_> I wonder if some call is hard coded to https or something. Or perhaps the network redirects https to http in your network? 
[20:25] <rick_h_> not sure
[20:25] <ahasenack> telnet on port 443 got stuck
[20:25] <ahasenack> no tcp handshake
[20:25] <rick_h_> :( no https makes techies sad
[20:25] <ahasenack> or is any of that made through my browser?
[20:26] <ahasenack> i.e., my machine hitting manage.jujucharms.com
[20:26] <ahasenack> instead of the juju-gui one
[20:26] <rick_h_> ahasenack: oh, yea that goes through your browser from the GUI
[20:26] <ahasenack> ok, good (to have another explanation) :)
[20:26] <ahasenack> my browser sits somewhere else, I have no connection impediments
[20:26] <rick_h_> not through the service deployed...except some stuff will go through there because it's assumed you might be offline but the environment must be able to get out to do a deploy at all
[20:27] <rick_h_> ahasenack: so yea, interesting
[20:27] <ahasenack> but the bundle deploy goes through the juju-gui machine? This metadata fetching when I'm deploying
[20:27] <rick_h_> ahasenack: yes, to deploy the bundle, your browser sends it to the deployed juju-gui, which then tells juju to deploy these charms/etc
[20:28] <ahasenack> that's ok, what about the no_such_charm error?
[20:28] <rick_h_> ahasenack: well that's curious now. We'd love to have the network log to be able to see which call failed and where it came from
[20:28] <ahasenack> sure, in a minute
[20:28] <ahasenack> Added charm "cs:precise/juju-gui-91" to the environment.
[20:30] <lazyPower> hatch: it does that. it takes ~ 45 seconds to complete teh oauth exchange
[20:30] <hatch> ugh
[20:30] <hatch> who decided that was a good system
[20:30] <hatch> lol
[20:31] <hatch> ahh there it goes
[20:32] <ahasenack> hm, didn't see any reds
[20:32] <rick_h_> ahasenack: ok, well if you can repeat it and get some details we'd love to make sure it works right. 
[20:32] <rick_h_> ahasenack: but otherwise might call it an intermittent network failure atm
[20:32] <ahasenack> found a 404
[20:33] <rick_h_> ok, that'd be something to look at, with what url?
[20:33] <ahasenack> freaking firefox, can't find a way to copy it
[20:33] <ahasenack> hang on
[20:33] <ahasenack> it's against manage.jujucharms.com
[20:34] <ahasenack> and the response is that error note
[20:34] <ahasenack> I bet you are dying to know what it is
[20:34] <rick_h_> lol
[20:34] <ahasenack> https://manage.jujucharms.com/api/3/charm/precise/login was the request
[20:35] <ahasenack> and the response was
[20:35] <ahasenack> {
[20:35] <ahasenack>   "charm_id": "precise/login", 
[20:35] <ahasenack>   "type": "no_such_charm"
[20:35] <ahasenack> }
[20:35] <ahasenack> well, just hit that url yourself
[20:36] <hatch> woah that's not a valid url heh
[20:36] <rick_h_> hah, wonder what that was from
[20:36] <rick_h_> hatch: I wonder if something in state tried to process the /login url of the gui?
[20:36] <ahasenack> is there a way to get the whole network tab contents as a text file of some sort?
[20:36] <ahasenack> in firefox?
[20:37] <hatch> sorry I have no idea....
[20:37] <rick_h_> ahasenack: that's good enough I think. We can file a bug/look into it from there. 
[20:37] <ahasenack> man, there are some weird GETs...
[20:37] <hatch> looking at what might generate that url 
[20:37] <ahasenack> https://manage.jujucharms.com/api/3/search/interesting
[20:37] <ahasenack> why would it search for that
[20:37] <hatch> that's from the charmbrowser
[20:37] <ahasenack> I searched for hadoop, then dragged it
[20:37] <hatch> the initial list of charms
[20:37] <ahasenack> ah
[20:37] <rick_h_> hatch: with double dispatch and such I wonder if something is taking /login and trying to treat it as /precise/login like /mysql
[20:38] <ahasenack> so the 404 one is right after the "interesting" one, in the list
[20:38] <rick_h_> ahasenack: heh
[20:38] <rick_h_> hatch: yea, that sounds like double dispatch coming back on us to me
[20:39] <rick_h_> hatch: with a slower connection or something it's coming back to dispatch /login after state is up/running
[20:40] <hatch> hmmmmmmm
[20:40] <hatch> I don't see how state would be calling an api call though
[20:41] <rick_h_> hatch: well something is trying to dispatch to /precise/login? As if there was a charm details there
[20:41] <rick_h_> hatch: what I'm thinking is that state gets the url and parses it and finds it's a short charmbrowser looking url and tries to dispatch
[20:42] <rick_h_> hatch: but just what it sounds like imo, I could be off
[20:42] <hatch> ahasenack what is the url path after the hostname? when you get that odd url ending in /login
[20:42] <ahasenack> I don't have that anymore, sorry :/
[20:43] <ahasenack> let me try another deploy of something else
[20:43] <hatch> sorry for making you jump through all of these hoops
[20:43] <ahasenack> nah
[20:43] <ahasenack> I do qa, I jump like that all day long :)
[20:44] <hatch> haha well thanks for helping qa the GUI 
[20:45] <ahasenack> so, got it again
[20:45] <ahasenack> just by logging in
[20:45] <ahasenack> I hit logout, then logged back in, did nothing else
[20:45] <ahasenack> notification is there
[20:45] <rick_h_> yea
[20:45] <hatch> ok let me try that on sandbox
[20:45] <hatch> I think this is a double dispatching issue
[20:45] <rick_h_> ahasenack: we'll file a bug and look into it
[20:45] <ahasenack> hatch: now, url path after hostname?
[20:45] <hatch> rick_h_ ahasenack  I can reproduce this locally
[20:46] <ahasenack> what do you mean?
[20:46] <rick_h_> hatch: awesome
[20:46] <ahasenack> hatch: aha
[20:46] <hatch> :D
[20:46] <hatch> ahasenack thanks so much
[20:46] <ahasenack> piece of cake now
[20:46] <hatch> this squeaked past our QA
[20:47] <rick_h_> hatch: woot another release this week :)
[20:47] <rick_h_> hatch: https://bugs.launchpad.net/juju-gui/+bug/1331189 if you want to add any notes/etc
[20:47] <_mup_> Bug #1331189: GUI attempts to load charm details for /precise/login during login process <juju-gui:Triaged> <https://launchpad.net/bugs/1331189>
[20:48] <hatch> thanks I'll add a note
[20:48] <rick_h_> ahasenack: thanks, card added to the board and we'll try to get that updated and an updated release out this week.
[20:50] <hatch> repro comment added
[20:50] <ahasenack> rick_h_: thanks
[20:53] <hatch> darn double dispatch
[20:54] <kadams54> hatch: I checked race times and it looks like the best times are right around 1 minute, which makes me feel a little better :-) http://www.newcastleraceway.com/results.shtml?mylaps=type,run,runid,3118281
[20:55] <hatch> kadams54 haha well that actually kind of makes sense ours is around 32s but that one is .6k longer
[20:56] <kadams54> hatch: My dad and I were talking and we realized that the rental karts also don't have any gears.
[20:56] <kadams54> Big diff from the real racers out there
[20:56] <hatch> only 'shifters' have multiple gears
[20:56] <hatch> which is a very small subset of karting
[20:57] <kadams54> The serious peeps out on the track with us must have been shifters
[20:57] <kadams54> You could hear it through the corners
[20:57] <kadams54> And as they left you in their dust :-)
[20:57] <hatch> well you can easily hear the shifts
[20:58] <hatch> there are others which will just scream but never shift
[21:00] <kadams54> Mine didn't shift or scream ;-)
[21:00] <hatch> haha no it was probably a 4stroke brigs or something
[21:01] <kadams54> "The karts feature 6hp Honda engines on Arrow racing chassis with rear crash guards. "
[21:01] <hatch> it's entirely possible they were shifters at which case...yes they would have blown past lol
[21:01] <kadams54> http://www.newcastleraceway.com/photos/arrowrental.jpg
[21:02] <hatch> yep that's what I used to race :)
[21:02] <hatch> ~65mph top speed
[21:02] <hatch> the shifters are over 100mph
[21:02] <kadams54> It's a great feeling whizzing along at 50 MPH 2 inches above the ground
[21:03] <kadams54> Wowza
[21:03] <hatch> but there are also yamaha's and rotax's which are slower than shifters but still scream but don't have gears
[21:03] <hatch> yep it is
[21:03] <hatch> it's a blast
[21:04] <kadams54> Looked at the various classes they race and there's only one (125cc) for shifters.
[21:04] <kadams54> 15 years and up, which makes me wonder if that girl was older than she looked
[21:04] <bac> shouldn't that be our next 'team building' exercise?
[21:04] <bac> or would bumper cars be more like it?
[21:05] <hatch> kadams54 very possible, although lately I've always thought kids are much older than they really are
[21:05] <hatch> must be whatever they are putting in the milk
[21:05] <hatch> :P
[21:05] <kadams54> bac: I'd be down with that :-)
[21:09] <bac> jujugui: new quickstart packages up on the beta PPA and released on pypi.
[21:10] <bac> qa has been good.  will push to juju/stable shortly
[21:10] <rick_h_> bac: yay
[21:10] <hatch> yay!!
[21:11] <bac> this is 1.4.0 wherein we announce os x support.  rick note that it may take a bit to get it up for brew
[21:11] <rick_h_> bac: rgr
[21:11] <bac> i'm not sure the turnaround for the non-initial PR
[21:11] <bac> it may be they just rubber stamp it if CI is happy
[21:11] <rick_h_> well hope
[21:11] <rick_h_> we'll hope
[21:12] <bac> yeah, anything else would probably bury them
[21:13] <bac> rick_h_: full disclosure: i only did qa on trusty and precise and will do limited on the pip package.  couldn't bring myself to repeat it all on saucy
[21:13] <lazyPower> I like the new layout where the config panel occupys the drawer on the left
[21:13] <lazyPower> +1 to the gui team for this change
[21:13] <rick_h_> bac: ok, well small changes and we'll find out. :) 
[21:14] <rick_h_> lazyPower: heh, UX made us do it, well machine view made us do it
[21:14] <rick_h_> though I do recall it coming up during initial inspector designs
[21:14] <lazyPower> i think it just makes sense now that its there
[21:14] <lazyPower> its like "i was giving up this space anyway with the drawer"
[21:14] <lazyPower> now i'm always moving one direction to interact with stuff. 
[21:14] <rick_h_> yea
[21:15] <rick_h_> and :flags:/mv works nicer
[21:15] <lazyPower> you guys ar etaking care of dense trogoldytes like myself. which is +1
[21:20] <lazyPower> ah, wait. found a bug with this. i refreshed the GUI and now i'm getting the white block issue. http://i.imgur.com/Pa4TyYV.png
[21:20]  * lazyPower goes to file ze bug
[21:22] <rick_h_> lazyPower: I think that might be a chrome issue. I'd be curious if it always happens, happens on that env/url with other browsers, happens in incognito mode, etc
[21:23]  * rick_h_ runs away now to get the boy night all
[21:23] <lazyPower> https://bugs.launchpad.net/juju-gui/+bug/1331202
[21:23] <_mup_> Bug #1331202: Random white blob on screen refresh <juju-gui:New> <https://launchpad.net/bugs/1331202>
[21:34] <hatch> lazyPower do you still have that env up?
[21:36] <hatch> if so, can you look in the browser console for any errors when that happens
[21:36] <lazyPower> hatch: i do
[21:37] <lazyPower> i think this is correlated with what we saw yesterday with hadoop
[21:37] <lazyPower> its a half promulgated charm
[21:38] <hatch> well the url shows that you're trying to access the inspector for a deployed service
[21:38] <hatch> so it should be displaying an inspector there
[21:38] <hatch> so I'm hoping there is an error in the console to help debug
[21:54] <lazyPower> hatch: its due to the charm being half promulgated
[21:54] <lazyPower> this is the same issue as what we ran into with HADOOP yesterday. Incomplete data in the charm store due to a push that didn't complete. 
[21:54] <lazyPower> awesome that I keep finding these corner cases >_>
[22:02] <hatch> lazyPower ok but is there any error messages? 
[22:02] <hatch> We should guard against these issues in the GUI so that even if this does happen it gives the user an error message instead of bricking the app
[22:02] <lazyPower> hatch: nope
[22:03] <hatch> darn ok thanks
[22:53] <hatch> any idea why a juju env would hang on any juju command?
[22:55] <hatch> for example juju status on ec2 is just hanging
[22:57] <hatch> maybe I'm just having a bad ec2 day
[23:05] <huwshimi> Morning
[23:10] <rick_h_> morning huwshimi 
[23:10] <huwshimi> rick_h_: Hey
[23:21] <hatch> morning huwshimi 
[23:25] <hatch> wow ec2 instances are slow
[23:25] <hatch> it's taking like 15mins or more to bootstrap a machine on ec2
[23:26] <huwshimi> hatch: hey
[23:44] <hatch> blarg
[23:45] <rick_h_> hatch: yes, ec2 can be really slow
[23:45] <hatch> now my ghost charm doesn't turn on for something
[23:45] <hatch> or*
[23:47] <hatch> rick_h_ do you know where juju charms are stored in instances?
[23:49] <rick_h_> hatch: sudo updatedb && sudo locate ghost
[23:49] <hatch> heh yeah just did that
[23:49] <hatch> this instance is just so damn slow