[00:47] <gary_poster> hey hatch, why don't you share your doc with bcsaller so he knows where you are going
[00:48] <hatch> oh sure thing
[00:49] <hatch> the documentation for angular sure is horrible
[00:49] <gary_poster> that's not good hatch :-(
[00:50] <hatch> no definitely not
[00:50] <hatch> there is ample documentation/blogs on how to write an application starting from a typical index.html
[00:50] <hatch> but almost none on doing what we are doing
[00:59] <gary_poster> I see :-/
[00:59] <gary_poster> I hope that is not a bad sign
[01:03] <rick_h_> hatch: I'd love a copy too please :)
[01:09] <hatch> hmm
[01:09] <hatch> think you deserve it?
[01:10] <hatch> :P
[01:10] <rick_h_> hatch: hey, I've got to have some bonus points from the api change landing today :P
[01:11] <hatch> haha
[01:11] <hatch> pm'd the link
[07:52] <fwereade> bac, quick question -- do you use the results of AddServiceUnits and similar calls, or do you just let the watchers give you the info you need?
[09:16] <fwereade> frankban, gary_poster: can you offer a suggestion re my question to bac above?
[09:17] <frankban> fwereade: morning, could you repeat the question?
[09:17] <fwereade> frankban,  quick question -- do you use the results of AddServiceUnits and similar calls, or do you just let the watchers give you the info you need?
[09:18] <frankban> fwereade: we use the results, yes
[09:18] <fwereade> frankban, interesting -- how do you reconcile them with changes from the watcher?
[09:19] <fwereade> frankban, it's just 2 parallel paths, I guess, so the immediate feedback lands immediately and you probably get an already-handled change out of the watcher soon?
[09:20] <frankban> fwereade: we handle possible errors, we give feedback to users before the delta stream arrives. when the watcher notifies the real changes, we update our internal db
[09:20] <fwereade> frankban, ok, I think I asked badly
[09:20] <fwereade> frankban, ServiceAddUnits returns a list of units
[09:20] <fwereade> frankban, what do yu use those units for?
[09:20] <frankban> fwereade: looking
[09:24] <frankban> fwereade: in case of errors, we notify the user, in case of correct response, we add the units to the db. The unit names are keys in our db, so, when the delta arrives we can do updates or inserts as required
[09:25] <frankban> fwereade: the db meaning the model layer used internally by the JavaScript app
[09:26] <fwereade> frankban, ok, so at least in the single-user case it's just a way of getting slightly-quicker inserts, so the subsequent insert event is effectively dropped?
[09:29] <frankban> fwereade: the info from the watcher are used to update the db with all the required information. e.g. AddServiceUnit response -> just add unit names in the db with state "pending". delta -> update those records with all the info included in the stream
[09:33] <fwereade> frankban, ahhh! sorry, it's just the new names
[09:33]  * fwereade sees, andfeels a bit silly
[10:15] <frankban> fwereade: no problem
[12:38] <jcsackett> jujugui: is there a way to see what revision uistage is running?
[12:38] <gary_poster> jcsackett, yes.  getting url
[12:38] <gary_poster> jcsackett, http://uistage.jujucharms.com:8080/juju-ui/version.js
[12:38] <hazmat> not sure there's a cronjob in place there.
[12:38] <hazmat> incidentally the 8080 is finally redundant
[12:38] <gary_poster> there is not, pretty sure
[12:38] <gary_poster> oh cool
[12:39] <jcsackett> gary_poster: awesome, thanks.
[12:39] <gary_poster> welcome
[12:39]  * hazmat puts a cron in place
[12:39] <jcsackett> hazmat: yup, removing 8080 works.
[12:41] <hazmat> gary_poster,  do you think it should be more than bzr up && make prod ... ie clean, up, make ? 
[12:43] <gary_poster> hazmat, make clean has not bitten us much.  conflicts on config changes have bitten us much more
[12:45] <gary_poster> hazmat, so, for cheap improvement, bzr up && make prod is sufficient.  if you are going for gold, you could make a fresh branch while the other one continues to serve, run make prod, drop in a replacement config file, and move the dir over. :-)  I appreciate the simple one.
[12:47] <hazmat> gary_poster, simple one done
[12:47] <gary_poster> perfect thanks hazmat
[12:49] <gary_poster> jcsackett, ^^ we're on 699 now
[12:49] <jcsackett> gary_poster: thanks.
[12:49] <benji> Is it "make clean" that has bitten us or "make clean-all"?  I ask because I hate "make clean"; it should instead be as clean as "-all".
[12:49] <gary_poster> benji, neither
[12:50] <gary_poster> on uistage
[12:50] <gary_poster> the only thing that has bitten us in my memory (and I'm one of the two that have to do the surgery) is the config conflict
[12:50] <benji> darn, I'll have to look for another reason to hate it
[12:50] <gary_poster> :-)
[12:50] <hazmat> at the moment the config delta is 2 lines for credentials in app/config-prod.js
[12:51] <benji> instead of "clean" and "clean-all" we should have had "clean" and "clean-some" :)
[12:52] <bac> "scrub" and "just move the dirt around"
[12:52] <gary_poster> :-)
[12:55] <hazmat> on first load the gui seems to be making two identical queries to jujucharms, and there's a few  nav images that look like they could be sprited.
[12:56] <rick_h_> hazmat: yes, the query is done on load and makes an OPTION and follow up request. Those will go away when the browser is pulled from the feature flag
[12:58] <hazmat> rick_h_, ic.. and the backend doesn't distguish from options atm, so it does the query/result twice. cool re feature flag, is it still doing the options with the backend responding approriately? 
[12:58] <rick_h_> hazmat: no, the new api splits OPTIONS from the second request correctly
[12:58] <rick_h_> hazmat: you can see it with a /:flags:/browser_enabled/ on the url
[12:58] <rick_h_> hazmat: we didn't go back and update the old view code since we're trying to replace it. 
[13:00] <hazmat> sounds good
[13:01] <hazmat> although looking at it with the features flag enabled.. there's some suboptimal image loading.. every charm icon is treated as distinct even when its not, causing redundant image loading.
[13:02] <hazmat> hmm
[13:02] <rick_h_> hazmat: 'treated as distinct'?
[13:03] <hazmat> rick_h_, openstack icons for example are the same but downloaded different.. i'm trying to remember some of the things i did for www.wdl.org.. ie. image heavy site.
[13:03] <hazmat> there was some image strip tile cutting, but its not particularly helpful here.
[13:04] <rick_h_> hazmat: well, we don't know that. We just load the icon that the charm provides and have no insight as to the actual pixels
[13:04] <hazmat> mostly about lazy image loading
[13:04] <rick_h_> hazmat: basically we load them, but they're the last in the request and most are hidden by the collapsed categories so it appears a lot faster than it is
[13:04] <hazmat> right now we load images for the entire result set, instead of what's visible..
[13:04] <hazmat> ic
[13:04] <rick_h_> hazmat: right, but you don't see them load, and then the browser will cache them since they're unique urls
[13:05] <rick_h_> hazmat: the waterfall makes it look a lot worse than the real use experience. 
[13:07] <hazmat> rick_h_, there's still quite a few optimizations though... ie.. http://uistage.jujucharms.com:8080/sidebar/search/~sidnei/precise/moztrap-0/:flags:/browser_enabled/ 
[13:08] <sinzui> orangesquad, any looking at staging? Know why mongodb/0's agent is down?
[13:08] <hazmat> will load moztrap json 4 times.. and still loads icons for the default result set, instead of the actual
[13:08] <hazmat> rick_h_, looks nice though
[13:09] <rick_h_> hazmat: definitely. We're not completely done. We just landed caching of switching simple view changes (fullscreen to sidebar and back) and removing the icon svg from the api data passed yesterday
[13:09] <rick_h_> hazmat: so now that the icons are loaded as normal <img src=> we can start looking at optimizing that more with better headers on the back end, etc
[13:10] <abentley> sinzui: I hadn't seen.
[13:10] <rick_h_> hazmat: feel free to file a bug and we can look into some more tweaks going forward. Right now trying to finish features we require like the fallback to category icons, related charms
[13:10] <sinzui> looks like mongodb/0 fell over 7 hours ago according to the app.log
[13:11] <abentley> sinzui: I wonder what happens if we reboot it?
[13:11]  * sinzui pays mongodb/0 a visit
[13:13] <sinzui> abentley, might help. The db appears to be up locally. I can query it and get sensible numbers
[13:14] <sinzui> I wonder if I can just restart the agent
[13:15] <abentley> sinzui: My problem is I don't know what program is actually the agent.
[13:15] <sinzui> me neither.
[13:16] <sinzui> my hope for service juju-agent restart was dashed
[13:16] <abentley> sinzui: From charmworld/3, looks like python -m juju.agents.machine
[13:17] <abentley> sinzui: and juju.agents.unit
[13:18] <sinzui> abentley: juju.errors.NoConnection: No zookeeper connection configured.
[13:19] <sinzui> juju-admin will let me initialize a zookeeper hierarchy, but I think would be BAD
[13:19] <abentley> sinzui: The full commandlines are:  https://pastebin.canonical.com/91851/
[13:19] <abentley> sinzui: But if we can't find the init file, I think a reboot is better.
[13:20] <sinzui> I see it
[13:21] <sinzui> Same error about zookeeper connection
[13:21] <sinzui> abentley, restart?
[13:21] <abentley> sinzui: go for it.
[13:25] <sinzui> abentley, I see "started" now
[13:26] <sinzui> oh, now I see charmworld has an es relation error.
[13:47] <bac> hi gary_poster, i was looking at the 'make custom ppas' card.  can we do a pre-imp?
[13:48] <gary_poster> bac, sure
[13:48] <bac> gary_poster: cool, in 5?
[13:48] <gary_poster> bac, cool.  guichat is open, I think.
[13:56] <rndm> is there a way to "deploy-to" from the gui?
[13:57] <bac> gary_poster: you there?
[13:57] <rndm> maybe i don't get what's going on but it seems like there's a 1-1 correspondence between services and machines
[13:57] <rndm> that might be my lack of understanding, however
[14:00] <gary_poster> rndm, no.  we won't support jitsu deploy-to ever, at least in my plans (except that we show it just fine).  we will support containerization in juju core this cycle, which is the expected long-term approach to the use case.
[14:01] <rndm> ok, thanks
[14:01] <rndm> lack of deploy-to isn't the problem for us, it's the 1-1 correspondence. when does this cycle end?
[14:06] <abentley> sinzui: It looks like promulgated is not a provided attribute in http://staging.jujucharms.com/~charmers/precise/rails/json
[14:06] <abentley> sinzui: basically, it's not set in the db.
[14:08] <sinzui> abentley, yeah. I don't see it in the db for juju-gui
[14:10] <gary_poster> rndm, 1-1 correspondence can be addressed now with jitsu deploy-to (in pyJuju) or --force-machine (in juju core).  juju gui displays this fine, we just don't support deploying with it yet.
[14:10] <sinzui> I think the short_url for juju-gui is wrong. I see a ~ where I expects a simple path.
[14:11] <gary_poster> rndm, that's the path for what you want now.  containerization will come sometime in the next 5 months, and the hope is that it will come within the next two months AIUI.
[14:13] <rndm> thanks. i was asking when because i prefer containerization but deploy-to is okay for now
[14:14] <gary_poster> cool
[14:14] <sinzui> abentley, the exception log hasn't had an entry since I brought up mongo and es. The applog shows the 5 missing data branches and the 1 FileExists errors that we see every ingest. Thus i think injest is doing its job, but explicit "promulgate" just doesn't work
[14:15] <abentley> sinzui: It seems like it could be aborting early.
[14:31] <rick_h_> jcsackett: so looks like I can't use the icons from huw's branch. So moving them and spriting them will have to live in your branch only. 
[14:47] <Makyo> Tests pass!  Further proof that I don't understand embedding as well as I should!
[14:49] <frankban> Makyo: cool! tests passed for me too, maybe for the same reason?
[14:50] <Makyo> frankban, Not sure.  This was embedded structs causing weird behavior that I still really don't understand.
[14:52] <jcsackett> rick_h_: moving them sure; spriting them is pretty out of scope for what i'm doing. what blocks you from moving forward on that?
[14:52] <benji> rick_h_: I'm trying to add a subapp, but I apparently haven't found all the places that I have to update in order to do so, here is my diff, thus-far: http://paste.ubuntu.com/5716969/
[14:53] <rick_h_> jcsackett: they're not the right images I need. I've got the images I need in the assets dir of docs
[14:53] <rick_h_> benji: looking
[14:54] <jcsackett> rick_h_: ah, so you'll sprite with those, and i'll just move the svgs in mine.
[14:54] <rick_h_> jcsackett: rgr
[14:54] <benji> (this is one of the things that frustrates me when working on our app, it is not clear to me what I have to do to add a new module, and looking at existing modules never seems to give me enough information to crib)
[14:54] <rick_h_> jcsackett: but the objection of adding 6 new requests for those images still stands in huw's branch so they need to get turned into png and sprited. 
[14:54]  * benji will be right back.
[14:55] <rick_h_> benji: subapps are init'd in the Y.App initializer
[14:55] <jcsackett> rick_h_: then i think my branch is blocked? b/c there's no point in me spriting and then you spriting. sounds like my work is dependent on yours.
[14:55] <benji> rick_h_: I don't follow.
[14:55] <rick_h_> benji: sorry, guessing the first part of that diff is in the intializer 
[14:56] <rick_h_> benji: guichat?
[15:00] <rick_h_> benji: I mean that looks right. can you push the branch up to make it easier to debug. Wondering if there's a diff issue cauing it not to load?
[15:04] <benji> rick_h_: pushed to lp:~benji/juju-gui/websocket-logging
[15:04] <benji> rick_h_: after you take a look we can go to guichat if needed
[15:05] <rick_h_> benji: rgr
[15:06]  * benji thinks rick_h_ is drowning.
[15:06] <benji> or perhaps would like to buy a vowel
[15:07] <rick_h_> benji: so this 'works' here. It loads, runs init. logs to console that it started
[15:08] <benji> yow
[15:08] <rick_h_> benji: what is not working as expected?
[15:08] <benji> it's not doing that :)
[15:08] <rick_h_> benji: now I did flip the sandbox because I didn't have rapi running atm
[15:08] <rick_h_> benji: I guess let me go back adn flip that back and run rapi
[15:08] <benji> I wonder if there is some build cruft keeping the new thing from being found.  I'll make clean-all and see if it helps.
[15:09] <rick_h_> benji: sounds good
[15:09] <benji> are you running "make devel"?
[15:09] <rick_h_> benji: yes
[15:09] <benji> k
[15:10] <rick_h_> benji: same success with the sandbox off and rapi running
[15:20]  * gary_poster wonders if a subapp is necessary, benji--you might be able to work with something simpler.  <shrug-for-now> ;-)
[15:33] <benji> gary_poster: maybe.  It looked like an easy way to draw well-defined lines around the functionality; if I ever get it to work I'll let you know
[15:33] <gary_poster> :-) k
[15:37] <benji> rick_h_: it was a cache problem
[15:37] <benji> We *really* need to straighten out our cache story.  These sorts of things are inexcusable.
[15:43] <rick_h_> benji: +1
[15:44] <rick_h_> benji: I think I end up running a make clean-all at least once a day just to make sure
[15:52] <gary_poster> jujugui call in 8.  please update kanban
[15:54] <gary_poster> benji, if you mean browser cache, we don't have a cache any more.  appcache is gone.  if you mean filesystem copies and Make issues, dunno, but that's not a cache per se.  I have not encountered, but if others have then please identify the issue and escalate it.
[15:55] <benji> gary_poster: I mean whatever caused my problem ;)  I suspect it was browser cache (though I realize the app cache is gone)
[15:56] <gary_poster> :-) ok.  we don't send cache headers benji, as you know, so if there's anything wrong, on the bright side it's because we are being too simple.  or because the browsers are broken. :-P
[15:57] <rick_h_> benji: heads up we did some tweaks to get things watched so http://bazaar.launchpad.net/~juju-gui/juju-gui/trunk/view/head:/config.js might be of interest if you get some other files going
[16:01] <gary_poster> bcsaller starting without you
[16:04] <bac> jcsackett: yeah, the hangouts app isn't so stable
[16:04] <jcsackett> bac: nope. 
[16:04] <jcsackett> ~bac: if only i had another option.
[16:05]  * jcsackett probably should buy a webcam for his computer
[16:28] <abentley> sinzui: someone forgot to set charm_import_limit to -1.  That's why it stops in the middle.
[16:43] <luca> gary_poster: Hi gary, are you free for a catch up with ale and i?
[16:44] <sinzui> abentley, easily fixed. That someone must be me. I recreated the app server a few weeks ago
[16:45] <gary_poster> luca, hey.  was about to lunch.  really quick, maybe? :-)
[16:45] <luca> gary_poster: sure
[16:46] <gary_poster> luca trying guichat...
[16:46] <gary_poster> hangouts is bugier than it used to be :-/
[16:46] <luca> gary_poster: already in :)
[16:50] <sinzui> abentley, did you fix the import limit? I see it as -1. Also, I have gzipped the current logs so that we get fresh logs at the start of the next ingest
[17:03] <abentley> sinzui: I adjusted the limit, then ran a manual ingest.
[17:04] <abentley> sinzui: I am perplexed that this does not seem to have fixed it.
[17:06] <abentley> sinzui: oh, setting the limit didn't actually rewrite production.ini …
[17:07] <sinzui> wtf?
[17:08] <sinzui> abentley, I just looked in the db an {"name": "juju-gui", "owner": "juju-gui"} does not have the promulgated attr yet. Make sense since the config is wrong.
[17:09] <abentley> sinzui: Yes, it's alphabetically lower than ~charmers/precise/cinder, which I presume is charm 110
[17:09] <sinzui> :)
[17:10] <abentley> sinzui: Are you running debug-hooks by any chance?
[17:10] <sinzui> no
[17:10] <abentley> sinzui: I don't know why the config change didn't take, then.
[17:11] <sinzui> yeah, I was just off to read the log
[17:12] <abentley> sinzui: I just ran debug-hooks and changed the config, and the hook isn't firing.
[17:13] <sinzui> the log shown two twisted exceptions originating from txzookeeper
[17:15] <sinzui> abentley, these are the errors from a time I think you called set: https://pastebin.canonical.com/91875/
[17:16] <abentley> sinzui: Cascading failure maybe?
[17:17] <abentley> sinzui: Should we try rebooting this one too?
[17:18] <sinzui> abentley, I'll do it. I cannot think of anything else to do. I'd like to trample zookeeper, but I cannot think of what can do that to full emotional satisfaction
[17:19] <abentley> sinzui: Tie a steak around its neck and let the zoo's tigers out of their cages?
[17:20] <sinzui> 284437
[17:21] <sinzui> How did I just type those numbers? I don't even recognise them
[17:21] <abentley> sinzui: Yay!  Now I can 2fa as you!
[17:22] <sinzui> you can, oh, the bloody cat
[17:22] <rick_h_> he still needs your password :P
[17:24] <sinzui> charmworld is back.
[17:26] <sinzui> abentley, I see charm_import_limit = 1000 in production.ini now
[17:27] <abentley> sinzui: Me too.  I'll set it back to -1
[17:27] <sinzui> I am still polling the juju-gui charm and hoping for a change
[17:30] <abentley> sinzui: manually ingesting now.
[17:30] <sinzui> okay
[17:35] <abentley> sinzui: Up to 126 charms now.  juju-gui will probably be 127.
[17:36] <sinzui> abentley, I think there about 134 promulgated charms for precise
[17:37] <sinzui> surely we have a ways to go
[17:37] <abentley> sinzui: juju-gui is now listed, but the entry is 501.
[17:38] <sinzui> well that bad news here is the branch owned by juju-gui now states promulgated == False
[17:38] <abentley> sinzui: I don't see that.  At http://staging.jujucharms.com/charms/precise/juju-gui/json it has promulgated: true
[17:39] <sinzui> huh? Do I have to deal with "eventually consistent" with a single db?
[17:40] <sinzui> abentley, doh, I thought the branch was still owned by juju-gui
[17:42] <abentley> sinzui: The problem is it doesn't have a short_url.
[17:42] <sinzui> :(
[17:44] <sinzui> abentley, it does in the db: /charms/precise/juju-gui
[17:47] <abentley> sinzui: You sure?  The representation at http://staging.jujucharms.com/charms/precise/juju-gui/json and the exception we get trying to load the page both indicate it's not there.
[17:48] <sinzui> I see that, but yes I am sure the db knows the charm is promulgated and has the expected short_url
[17:54] <abentley> sinzui: I find this very confusing, since the /json is a very lightly-edited version of the mongo representation.
[17:55] <sinzui> yes. I think frustrating it the better word.
[17:56] <sinzui> I have just reconfirmed ~juju-gui-charmers/charms/precise/juju-gui/trunk is promulgated and has a short url.
[17:56]  * sinzui ponders restarting the app
[17:57] <sinzui> abentley, did the force ingest complete?
[17:57] <abentley> sinzui: Yes.
[17:58] <sinzui> I will restart the app just to convince myself that we really do not have caching in the app
[17:59] <sinzui> okay done, and json still shown the app cannot see the short url
[18:01] <abentley> sinzui: Oh, i get it locally, too.
[18:01] <sinzui> abentley, /api1/charms/interesting knows the charm is promulgated
[18:02] <abentley> sinzui: The problem is not the promulgation, it's the short_url.  It's been showing promulgated since it started 501ing.
[18:03] <sinzui> abentley, what do you mean started 501ing. I think this charm has never 200ed
[18:03] <hatch-mobile> hello all
[18:03] <abentley> sinzui: It was 404ing before, IIRC.
[18:04]  * sinzui nods
[18:05] <abentley> sinzui: I read the error a little closer, and I think it's due to a missing short_url in another juju-gui charm.
[18:05] <sinzui> abentley, benji's?
[18:05] <sinzui> he has a charm with a tab in the metadata.yaml I think
[18:06] <abentley> sinzui: Could be.
[18:06] <benji> I hope not.  I'm not a big fan to tabs.
[18:06] <sinzui> abentley, said charm is on my list of branches to not die on for the branch I want to work on after this arduous QA
[18:07] <abentley> sinzui: Yes, it is all benji's fault.
[18:08] <sinzui> benji, no need to panic: ~benji/charms/precise/juju-gui/trunk is one of several charms that are broken, and pages/api calls that include them break
[18:08] <hatch-mobile> bcsaller did you have a chance to read through that document?
[18:08] <benji> :)
[18:08] <abentley> sinzui: So I got out my torch and pitchfork for nothing?
[18:09] <sinzui> benji, charmworld needs to normalise the data.
[18:10] <sinzui> I think I want to join an angry mob right now. I bet it would be cathartic.
[18:13] <abentley> sinzui: I have a fix.  Now I need a unit test.
[18:14] <sinzui> what? how? where?
[18:14] <sinzui> a hack to _charm_view?
[18:15] <sinzui> oh, other short_url
[18:16] <abentley> sinzui: Yes, a change to charm view so it doesn't try to list invalid charms as alternatives.  https://pastebin.canonical.com/91882/
[18:16] <sinzui> benji's charm is breaking the promulgated charm
[18:19] <sinzui> abentley, I cannot see how that excludes a charm without a short URL.
[18:19] <sinzui> comment 4 in https://bugs.launchpad.net/charmworld/+bug/1180055 shows an example of my hack to deal with missing short_urls: https://bugs.launchpad.net/charmworld/+bug/1180055
[18:19] <_mup_> Bug #1180055: KeyError: 'short_url' <oops> <charmworld:In Progress by sinzui> <https://launchpad.net/bugs/1180055>
[18:19] <_mup_> Bug #1180055: KeyError: 'short_url' <oops> <charmworld:In Progress by sinzui> <https://launchpad.net/bugs/1180055>
[18:20] <abentley> sinzui: This excludes charms that were not processed successfully, because valid_charms_only defaults True, and only charms that weren't processed successfully will lack short_url AIUI.
[18:22] <sinzui> abentley, I see...valid_charms_only=True
[18:27] <sinzui> abentley, I think we should ponder a change in my plan for bug 1180055. If ingest uses the model charm which guarantees required attributes, view call sites don't need to be so defensive
[18:27] <_mup_> Bug #1180055: KeyError: 'short_url' <oops> <charmworld:In Progress by sinzui> <https://launchpad.net/bugs/1180055>
[18:28] <abentley> sinzui: We should still avoid showing charms that aren't present in the charm store, which is another thing valid_charms_only gives us.
[18:29] <sinzui> abentley, I think there are two cases. I agree we should not claim this bad charm is an alternate for the one being listed.
[18:29] <abentley> sinzui: We could remove those.  I would be fine with that.
[18:30] <sinzui> but If benji wanted to see his charm, m.jc.com could tell him it is evil and must be put down
[18:32] <sinzui> abentley, your fix does not address this case http://staging.jujucharms.com/~benji/precise/juju-gui where the offending charm is primary content. If we don't want to ever show it, then instead of me creating a model, I think we want the api and charm views to know how to say 404
[18:33] <abentley> sinzui: I think we should show it in that case.  For all we know, it's a working charm that just has a bad category or something.
[18:33] <abentley> sinzui: Ideally, we put a warning at the top, and show the page still.
[18:33] <sinzui> okay. Do you think I should proceed with yesterday's plan?
[18:34] <abentley> sinzui: I think so.
[18:34] <sinzui> excellent. I have purpose
[18:35]  * sinzui wishes his Merida doll would arrive.
[18:36] <abentley> sinzui: Once we have a class to represent charms, we should switch all the code over to use it.  Once we do that, the internal representation of the charm becomes less important.
[18:36] <sinzui> yeah, that is my dream.
[18:39] <abentley> sinzui: Then we probably start generating short_url on the fly, since it's redundant with (promulgated, series, owner, name)
[18:39]  * sinzui nods
[18:46] <sinzui> abentley, I can confirm that you dropped the charm-errors collection. I am moving the card
[18:46] <abentley> sinzui: Thanks!
[18:52] <sinzui> abentley, I am going to pause before moving Abel's cards to acceptance. I want to review misadventure with fresh eye.
[19:11] <abentley> sinzui: Could you please review https://code.launchpad.net/~abentley/charmworld/valid-others/+merge/166578?  Technically, this is a fix for 1180055.  I did not mean to steal your bug.  Sorry.
[19:12] <sinzui> abentley, yeah, it fixes 50% or more the occurrences.
[19:12] <benji> umm, the "=" (shouldn't that have been "+") and "-" key bindings are a bit agressive, you now can't type either of those characters anywhere in the environment view (search box, service config, etc.), instead you get zooming all the time
[19:12] <abentley> sinzui: Oh, it's not a complete fix?  I'll add another card rather than stealing yours, then.
[19:15] <sinzui> abentley, your change fixes the viewing of every juju-gui charm except for http://staging.jujucharms.com/~benji/precise/juju-gui because we do want to see it and short_url is called in another place in the template
[19:15] <abentley> sinzui: Cool.
[19:25] <abentley> sinzui: juju-gui is now displayed properly at http://staging.jujucharms.com/charms/precise/juju-gui
[19:26] <sinzui> yep. Thank you
[19:29]  * benji files a bug for the above-mentioned keybinding behavior
[19:45] <abentley> sinzui: I have determined that download time is a large, often dominant component of retrieval time for manage.jujucharms.com/api1/charms/interesting.  I will look at implementing API2 with a more efficient format.
[20:05] <sinzui> abentley, understood.
[20:12] <bac> gary_poster: if you have a sec, i'm trying to ssh to uistage and still cannot.  could you check my key?
[20:17] <bac> hazmat: ^^
[20:22] <hazmat> bac, user:root dir:/opt/uistage
[20:22]  * hazmat double checks 
[20:22] <hazmat> keys
[20:22] <hazmat> bac, looks good
[20:23] <bac> hazmat: did you use ssh-import-id?
[20:23] <hazmat> bac, root@uistage.jujucharms.com doesn't work for you?
[20:23] <bac> hazmat: when i attempt ssh it presents all of my keys but rejects them
[20:23] <hazmat> bac, ic bac@brazos, bac@ubuntu.com and a few others
[20:24] <hazmat> in authorized keys, works for gary and me.. yes re ssh-import-id
[20:24] <bac> hazmat: yes, root@ works.  i was trying ubuntu@
[20:24] <hazmat> ack
[20:24] <bac> hazmat: was that a change?
[20:24] <hazmat> bac, yes previously was ubuntu@ (cloud-image) now root@ 
[20:25] <hazmat> bac, /opt/uistage has the checkouts / cron etc
[20:25] <bac> hazmat: ok.  thanks.