[15:10] <lazyPower> rick_h_: do you have 2 minutes for me?
[15:10] <rick_h_> lazyPower: sure thing
[15:10] <lazyPower> i just got a mail from castro about the big data topic page, our second listed bundle 404's, but the repository exists in lp
[15:11] <lazyPower> https://jujucharms.com/big-data - the high performance view details link
[15:11] <rick_h_> lazyPower: looking
[15:11] <lazyPower> any insight? i'll file a bug @ github - but it makes no sense to me
[15:12] <rick_h_> lazyPower: is that https://jujucharms.com/high-performance-batch-processing/4 ?
[15:12] <lazyPower> thats the one
[15:12] <lazyPower> its ina  different namespace hwoever
[15:12] <rick_h_> lazyPower: looking to see the diff in the charmers one that shows up vs the other one with the bigdata-charmers
[15:13] <lazyPower> you know rick_h_, if i remember correctly - we are warehousing teh bundles in both places - but only /~charmers/bundle link is the store link (otherwise its marked as development focus in launchpad)
[15:13] <lazyPower> i'm wondering if there's a collision going on here, or something similar
[15:14] <lazyPower> but i bug reported it so we can track progress https://github.com/CanonicalLtd/jujucharms.com/issues/44
[15:14] <rick_h_> lazyPower: yea looking 
[15:17] <rick_h_> jcsackett: can you check out and see why ^ would 404? It looks like it should load via the api here: https://api.jujucharms.com/v4/~bigdata-charmers/bundle/high-performance-batch-processing-6/meta/any?include=bundle-metadata
[15:18] <rick_h_> jcsackett: wondering if the -charmers is causing us to not just remove dupes, but 404 the details 
[15:18] <jcsackett> rick_h_: looking.
[15:18] <rick_h_> lazyPower: I'm going to be this is because the team name ends in -charmers and we've got a temp hack in to remove dupe entries 
[15:18] <rick_h_> lazyPower: so it's 404'ing this one so that the promulgated one is the one that shows/is used
[15:18] <rick_h_> lazyPower: jcsackett can confirm if that's the reason for the 404 and get back to you
[15:19] <rick_h_> lazyPower: we're working on a back end model change to remove the dupes properly, but it'll take some time this month for that to complete and get rolled out
[15:19] <lazyPower> thanks rick_h_, i appreciate you taking a look
[15:19] <lazyPower> yeah, murphy's law + time = current state of things
[15:19] <lazyPower> totally understood
[15:19] <rick_h_> lazyPower: so my 'answer' right now is to update that page to point to the promulgated bundle which should be the best source anyway
[15:19] <lazyPower> ok, thats not something I can do right?
[15:19] <rick_h_> lazyPower: we're working on a release today and can update that url if you can confirm it's ok to do so
[15:20] <rick_h_> lazyPower: no, we have to adjust the url in the template file but it's a one line change jcsackett can get in before release today
[15:20] <lazyPower> i +1 that notion. having a bundle listed vs a 404 is a 100% better experience.
[15:20] <rick_h_> jcsackett: follow ^ ?
[15:20] <lazyPower> if we need to do anything charmer side to update, i'll make that happen
[15:20] <rick_h_> lazyPower: right, so the thing you all can do is update the ~charmers version with the latest code form the other team
[15:21] <rick_h_> it looks a bit behind using r4 of the charm vs r7
[15:21] <rick_h_> jcsackett: http://bazaar.launchpad.net/~bigdata-charmers/charms/bundles/high-performance-batch-processing/bundle/view/head:/bundles.yaml and http://bazaar.launchpad.net/~charmers/charms/bundles/high-performance-batch-processing/bundle/view/head:/bundles.yaml
[15:21] <jcsackett> rick_h_: the promulgated version should just be the bundle absent the /u/..../ stuff, right?
[15:21] <rick_h_> jcsackett: correct
[15:21] <jcsackett> b/c that's *also* 404.
[15:21] <jcsackett> rick_h_: https://jujucharms.com/high-peformance-batch-processing/
[15:21] <rick_h_> jcsackett: https://jujucharms.com/high-performance-batch-processing/4
[15:21] <rick_h_> jcsackett: https://jujucharms.com/high-performance-batch-processing/
[15:22] <jcsackett> those are 404s for me.
[15:22] <rick_h_> https://jujucharms.com/high-performance-batch-processing/ is a 404?
[15:22] <jcsackett> rick_h_: also, we only filter out the *-charmers stuff on search results--we don't *not* display them.
[15:22] <rick_h_> jcsackett: that's what I wanted to verify
[15:22] <rick_h_> jcsackett: since it shows up in the api I was wondering why it would 404
[15:22] <rick_h_> jcsackett: so we might need to runa local storefront and debug the page load through the api
[15:25] <jcsackett> rick_h_: no need.
[15:25] <jcsackett> the answer is far simpler.
[15:25] <rick_h_> jcsackett: hah
[15:25] <jcsackett> the link on big-data is to high-peformance-..., not high-performance-...
[15:25] <jcsackett> that 'r' is pretty important.
[15:25] <jcsackett> i'll go ship a trivial.
[15:25] <rick_h_> jcsackett: ty kindly
[15:25] <jcsackett> lazyPower: ^
[15:25] <rick_h_> lazyPower: typo ftw
[15:25] <jcsackett> simple fix, we'll have it up soon. :)
[15:26] <rick_h_> well FML
[15:26] <lazyPower> \o/
[15:26] <lazyPower> i like simple fixes
[16:49] <hatch> frankban_: so the uuid endpoint, will it be required for the juju-core endpoint as well or just the wss requests?
[16:50] <frankban_> hatch: juju-core endpoint? oh, you mean the HTTP proxy?
[16:50] <hatch> yeah
[16:50] <hatch> ^/juju-core/(.*)
[16:50] <frankban_> hatch: not sure, let me check
[16:50] <hatch> that's for the icons right?
[16:51] <hatch> thanks
[16:51] <frankban_> hatch: that's both for the icons and for uploading local charms IIRC
[16:51] <hatch> ahh
[16:51] <hatch> so then it does make sense that it should require it...in some capacity at least
[16:54] <frankban_> hatch: I confirm they also use the new endpoint: https://github.com/juju/juju/blob/master/apiserver/apiserver.go#L323
[16:55] <hatch> frankban_: alright thanks!
[16:57] <frankban_> hatch: IIRC the ProxyHandler should already redirect everything under /juju-core
[16:59] <frankban_> hatch: so this is actually also a change to be made in the GUI later
[16:59] <hatch> frankban_: correct, it's looking like it simply redirects what's been sent to it
[17:11] <hatch> frankban_: with a deployed juju-gui charm, what's the best way to modify the live source/pdb etc
[17:11] <hatch> for the guiserver that is
[17:15] <frankban_> hatch: hangout?
[17:15] <hatch> frankban_: sure, joining standup
[18:30] <Makyo> uiteam looking for reviews on the charm update to support v4 bundles: https://code.launchpad.net/~makyo/charms/trusty/juju-gui/guiserver-v4bundle/+merge/249236
[20:46] <hatch> woah nodejitsu was bought by godaddy
[20:47] <jrwren> what is nodejitsu?
[20:47] <jrwren> oh. hosting.
[20:47] <hatch> kind of like heroku for node
[20:47] <hatch> sortof
[20:48] <jrwren> godaddy is evil, so sounds like a new nodejitsu work alike is needed.
[20:48] <jrwren> doesn't node work on heroku?
[20:48] <hatch> if you get a node gear
[20:48] <hatch> or whatever they call their vm's
[20:48] <hatch> heh
[20:48] <jrwren> buildpack
[20:48] <hatch> that's it
[20:49] <hatch> a while ago nodejitsu was far superior
[20:49] <hatch> not sure anymore
[20:49] <hatch> it's been probably 2 years since I looked heh
[20:49] <hatch> I can't imagine their new overlords will be very good for the company
[20:50] <hatch> any company that supports a closed internet can shoveit
[21:46] <hatch> I have this simple sublime plugin that marks new/changed lines when working with git - I do not have this functionality with bzr and I miss it!
[21:59] <huwshimi> Morning