[11:58] <rick_h_> frankban: ping, around?
[12:16] <bac> hello rick_h_.  haven't seen frankban yet, perhaps he's lunching
[12:22] <frankban> rick_h_: I am back from lunch
[12:27] <rick_h_> frankban: howdy, I talked to william and talked about the charm GET. He asked that you and dimiter get together. They're ok with an api with individual file access as long as we realize that it's a very expensive experience for now
[12:27] <rick_h_> frankban: the plan is for them to work on getting files into mongodb gridfs vs the provider storage so it'll get better with time
[12:27] <rick_h_> frankban: but they're ok on an api that's designed to be finer grained
[12:28] <rick_h_> frankban: does that sound like what we needed to run by them for that or is there more I should make sure to push for/bring up?
[12:29] <frankban> rick_h_: just to have some context, we need charms GET to retrieve the files we need for the local charm story (e.g. readme and icon) right?
[12:29] <rick_h_> frankban: exactly
[12:30] <rick_h_> frankban: and I told him that two were the two big ones we want. I got the icon as well because for some charms the vendor/branding will be important
[12:30] <frankban> rick_h_: and we currently fetch those from charmworld
[12:30] <rick_h_> frankban: the one thing I wanted to verify is if we get config AND metadata from juju without this? or juts config?
[12:30] <rick_h_> frankban: yes, but for local charms we want to be able to get them from juju and for now, we need to deal with caching appropriately so that we don't ask for it more than once
[12:31] <rick_h_> but that's on the Gui to use it properly while the api/design in juju will be more open to multiple files/any file in the charm
[12:31] <frankban> rick_h_: yes I think we need config.yaml and metadata.yaml as well
[12:31] <rick_h_> because once it's in mongodb, the performance aspect will be mitigated
[12:31] <rick_h_> frankban: well we get config from juju right? 
[12:31] <rick_h_> I mean if we don't how does local charm deploy work now?
[12:32] <frankban> rick_h_: ah! yes, from the ws API
[12:32] <rick_h_> frankban: right, so we need to make sure we ONLY use this new api for things we REALLY need/can't get any other way
[12:32] <frankban> rick_h_: sounds good
[12:33] <rick_h_> frankban: cool, let me know if anything comes up from that I can help middle-man with
[12:33] <rick_h_> I guess dimitern is the guy to talk to on the nitty gritty from here
[12:35] <frankban> rick_h_: if I click to open the charms detail panel from the GUI, the missing tabs for local charms are: readme, configuration (I don'y know why, given we should have it from juju), code and features
[12:36] <rick_h_> frankban: right, and so we're not going to have feature, we're not going to show code until the implementation is fixed to make it inexpensive, and we'll try to get readme/config in there
[12:36] <rick_h_> is my understanding 
[12:37] <frankban> rick_h_: yes, to show code we would need to retrieve all the files inside hooks/. the plan you described sounds reasonable
[12:38] <frankban> rick_h_: how do we currently handle the charm icons? are they cached, do we store them in some way in our db?
[12:38] <rick_h_> frankban: no, right now we link via http to them from manage.jujucharms.com and let the browser deal with the caching/etc
[12:39] <rick_h_> frankban: we'll have to be smart about it and figure out how to embed/deal with that
[12:40] <rick_h_> frankban: and one answer might be to use the charm server as a cache to link to and enable us to treat them the same, but at a local url vs manage.jujucharms.com?
[12:40] <rick_h_> frankban: but that's just tossing stuff out 
[12:41] <frankban> rick_h_: this needs to be changed, for at least two reasons: 1) what you mentioned (avoid calling juju HTTPS when not strictly required) and 2) we might want to display icons for local charms in sandbox mode.
[12:41] <rick_h_> frankban: well, there's more to that. We can talk about it later
[12:42] <frankban> rick_h_: ok cool
[12:50] <rick_h_> bac: do you need a credential file to use ingest on charmworld? I'm trying to give the guys a bundle to deploy to local LXC to be able to setup an offline demo but it's not ingested reviewed charms? https://pastebin.canonical.com/104358/
[12:51]  * bac looks at paste
[12:52] <rick_h_> bac: I managed to get 186 charms, but that's it. almost all the log is about bundle errors because of charms not found
[12:52] <bac> rick_h_: i need context.  you're running charmworld locally and getting that output pasted?
[12:54] <rick_h_> bac: rgr, I'm using an lxc environment to deploy charmworld, ES, and mongodb and try ing to see if I can get it to run and ingest everything so you can put a Gui in that environment and do a presentation 'offline' since everything is in your lxc environment
[12:54] <rick_h_> the idea being an IS guy giving a talk can use lxc to setup things the day before, then present without wifi
[12:55] <rick_h_> bac: but it's only ingesting 186 charms and the only error/issue I can see in the log is p_credentials path doesn't exist: /home/webops_deploy/charmworld/charmbot_credentials.txt and wondering if that means anything to you?
[12:55] <rick_h_> are you aware of what should go in there and if missing that would prevent some charms (all the reviewed ones?) to not come down
[12:56] <bac> rick_h_: yeah, in that case you're either going to need a specific credentials file configured in the charm or perhaps defer to a system-wide lplib credential
[12:56] <rick_h_> ingest is running, and clears. but it's doing the 186 and 27 baskets
[12:57] <bac> rick_h_: what's your time frame?  can i work offline to get it running and document the process for you?
[12:57] <rick_h_> bac: sure thing. I just told them I'd look into it. Doesn't have to be this week but should give them a bundle/process that works next week sometime
[12:57]  * rick_h_ hoped it'd be simple and whip it up real quick. 
[12:58] <bac> rick_h_: oh, great.  i was afraid you were in need of an answer ASAP and it's not something i have on the top of my head
[12:58] <bac> rick_h_: let me review the deploying on staging document and see.  i'll ping you shortly
[12:58] <rick_h_> bac: no, I was just asking if you had any hints for me off the top of your head :)
[12:58] <rick_h_> bac: thanks! appreciate it
[12:58] <bac> rick_h_: but i've never deployed the charmworld charm locally
[12:58] <bac> as it is a bear
[12:59] <rick_h_> bac: heh https://pastebin.canonical.com/104361/ is the bundle file I exported. The thing to update is the charmworld url in the gui to whatever charmworld comes up as 
[13:00] <rick_h_> it's pretty close apart from the missing charms. Heartbeat shows it running and processing nicely
[13:02] <bac> rick_h_: nice
[13:45] <gary_poster> hey benji, have to take Julia to pre-school at 9.  Will ping when I return? 9:15 or 9:20 tops, I think, if everything goes as usual.
[13:46] <benji> gary_poster: sounds good
[13:46] <gary_poster> ty
[13:49] <bac> rick_h_: to your original question, the lp_credentials is only needed for the review job.  so it shouldn't have any impact on the demo you want to do...unless you want to show the review process
[13:49] <bac> has nothing to do with ingest
[14:34] <frankban> jujugui FWIW, rather than rebasing-hell, this approach (suggested by gary_poster) seems to work very well: http://pastebin.ubuntu.com/6885477/
[14:36] <hatch> that's a lot of steps :)
[14:36] <gary_poster> make an alias :-)
[14:37] <frankban> hatch: the good part is that you don't have to think hard on each step
[14:37] <hatch> I suppose the only issue with it is that you may run into issues merging your changes into a fresh develop
[14:37] <hatch> so you would have to do it manually
[14:38] <frankban> hatch: there can be conflicts, but istm less scary than rebasing. 
[14:38] <hatch> right, I was just meaning with relation to an alias
[14:38] <hatch> unless an alias will bail out at that point
[14:38] <hatch> so far my aliases have been very simple
[14:41] <gary_poster> qa-pr is simple? :-)\
[14:41] <hatch> frankban gary_poster could we not use squash when merging our branches into develop via the CI?
[14:41] <hatch> I don't use any of the gui aliases :)
[14:42] <hatch> git merge --squash
[14:42] <hatch> that is
[14:45] <hatch> if it did work... we could pull the commit message from the message with :shipit: in it...maybe?
[15:00] <frankban> guihelp: I need two reviews + QA for https://github.com/juju/juju-gui/pull/110 (upload charm in sandbox mode preparation) thanks!
[15:01] <hatch> on it
[15:02] <frankban> hatch: thanks
[15:40] <hatch> frankban curious, what does --upload-tools do? The help only says that it 'uploads a local version of the tools' which isn't very helpful :)
[15:42] <frankban> hatch: if you use a local env that's optional. but if you use, e.g. ec2 with juju-core trunk, it uploads the juju-core binaries from your own build to the cloud, so that ec2 runs exactly what you compiled
[15:42] <hatch> ohh gotcha - ok yeah I'm running local
[15:42] <hatch> thanks
[15:49] <bac> frankban: where do the guiserver logs get written?
[15:49] <hatch>  /var/log/upstart
[15:49] <frankban> bac: ^^^
[15:49] <hatch> which apparently isn't a freenode command :)
[15:50] <bac> thanks hatch & frankban
[15:50] <bac> glad i asked...it may have taken me a while to find them there!
[15:50] <gary_poster> jujugui call in 10
[15:51] <gary_poster> bac, it's in the charm HACKING.md.  The last section of that doc has some nice debugging tips
[15:52] <bac> thanks
[15:55] <frankban> hatch: replied to some of your comments in the review, thanks (and github "real time" conversation in reviews is cool)
[15:56] <hatch> :) cool, they were all pretty trivial, I'm just doing the qa noq
[15:56] <hatch> now
[15:56] <frankban> cool
[15:58] <gary_poster> jujugui call in 2
[16:06] <hatch> frankban when running in sandbox in make-prod whats the password for the gui?
[16:07] <frankban> admin?
[16:07] <hatch> oh duh
[16:21] <hatch> hazmat I read that you have a local provider demo for digital ocean?
[16:49] <hatch> interesting...if you stub Y.one() it also stubs Y.Node.create()
[16:49] <hatch> var oneStub = testUtils.makeStubMethod(Y, 'one', 'asdfasf');
[16:50] <hatch> both return the return value
[16:59] <gary_poster> jujgui, great news: james page reports to rick that quickstart is in trusty universe now.  Yay!  Moreover, he's actively helping us to get it in main as well, so that still might happen.  Double yay!
[16:59] <gary_poster> jujugui ^^
[16:59] <hatch> yay
[16:59] <frankban> :-)
[17:00] <gary_poster> and meanwhile, I'm going to pick up my daughter from preschool.  biab
[17:18] <frankban> benji: is evaluating a js zip library part of your current card?
[17:20] <Makyo> frankban, LGTM
[17:20] <frankban> Makyo: great thanks
[17:30] <benji> frankban: yep; it's looking like zip.js (http://gildas-lormeau.github.io/zip.js/fs-api.html) is going to be best for the present with a little future-proofness built in
[17:30] <frankban> benji: cool thanks
[17:41] <hatch> that's the one I was leaning towards as well :)
[18:13] <gary_poster> Makyo: https://github.com/juju/juju-gui/pull/111 :-)
[18:20] <hatch> so.....much......testsssssss
[18:21] <hatch> eyes....bleeeeding
[18:24] <Makyo> Might want to see a doctor about that.
[18:24] <Makyo> +1, gary_poster :)
[18:24] <gary_poster> cool thanks Makyo :-)
[19:08] <benji> hatch: is it intentional that a user can drop multiple zips at once and have them all deploy?
[19:09] <hatch> benji yes but untested
[19:10] <hatch> I'm assuming that works?
[19:10] <hatch> :)
[19:10] <benji> I haven't tried it.
[19:10] <hatch> I say untested because it's not really 'supported' there are other issues like the ghost inspectors poping up and stuff
[19:10] <hatch> it will loop through the files that are dropped and do what it will with them
[19:12] <benji> hatch: In that case I won't preserve the behavior.
[19:12] <hatch> sounds like a plan
[19:12] <hatch> +1
[19:12] <benji> cool
[19:18] <bac> gary_poster: just noticed staging.jujucharms.com is completely gone
[19:18] <bac> gary_poster: will re-deploy it all.
[19:19] <gary_poster> bac, eek.  OK thank you.  I guess that is fun from the canonistack upgrade
[19:19] <bac> yeah
[19:19] <bac> gary_poster: do you know the urgency of the debug=true query string for icons for rick?
[19:19] <gary_poster> not really bac
[19:20] <bac> ok. well a functioning staging with it QAed there is a pre-req for a rollout
[19:57] <bac> hi abentley, you around?
[19:57] <abentley> bac: Hi.
[20:04] <hatch> jujugui looking for a review/qa https://github.com/juju/juju-gui/pull/112 I need this one landed before Huw gets in so he can style it....plz and thanks
[20:05] <benji> hatch: I'll take a look.
[20:05] <hatch> thanks!
[20:07] <hatch> gary_poster your branch failed to be merged into develop
[20:07] <gary_poster> hatch, bah and thanks
[20:07] <hatch> doesn't give much of an error message though :/
[20:07] <hatch> np
[20:22] <benji> hatch: I've never done QA using github, how do I get your branch?
[20:22] <hatch> benji at the bottom of the conversation list there is a link 'command line'
[20:22] <hatch> in the section that says Merge with caution!
[20:23] <hatch> copy and run the first TWO commands
[20:23] <hatch> do NOT to step 2 :)
[20:23] <hatch> do*
[20:23] <benji> ah, it's hidden under "Merging via command line"
[20:24] <hatch> yeah, we don't want to do that though :)
[20:24] <hatch> but that way you can just click to copy and don't have to type it out
[20:34] <gary_poster> benji, the HACKING doc has another approach from Rick that I use fwiw
[20:34] <benji> gary_poster: thanks; I looked in there but nothing jumped out at me 
[20:34] <gary_poster> benji, the qa-pr alias is the trick
[20:52] <bac> jujugui: staging.jujucharm.com rebuild is going slow but seems to be coming up now.
[20:52] <gary_poster> ack thank you
[21:09] <benji> hatch: review done
[21:09] <hatch> thanks
[21:11] <rick_h_> party party
[21:12] <gary_poster> what the heck are you doing around rick_h_? :-) it must be well past midnight
[21:13] <rick_h_> 11pm
[21:13] <rick_h_> just got back from  evening out. bus down to the waterfront mall area straight from the office today
[21:13] <gary_poster> ah ok
[21:13] <gary_poster> cool
[21:13] <gary_poster> pretty?
[21:14] <rick_h_> meh, it was a mall. Nice to walk around and such
[21:14] <rick_h_> can see the tabletop mountain though which was cool
[21:16] <hatch> rick_h_ https://github.com/hatched/juju-gui/blob/select-series/app/views/viewlets/request-series.js see viewlets do rock when they are used like they are supposed to be :P
[21:17] <hatch> haha
[21:18] <hatch> benji you and your empty return values :P
[21:18] <rick_h_> hatch: where's the rest of it?
[21:18] <hatch> that's it
[21:18] <benji> I think it's not just me.
[21:18] <rick_h_> hatch: like the events, the trigger on drop, the updating the value 
[21:19] <hatch> rick_h_ well that doesn't exist yet
[21:19] <rick_h_> hatch: so not so simple if it doesn't work :P
[21:19] <rick_h_> yes, showing a template is easy...yay!
[21:19] <hatch> lol
[21:19] <hatch> I added a card to add events to the viewlets :)
[21:20] <rick_h_> I'll add a card to change viewlets to views :P
[21:20] <hatch> that's actually pretty trivial to do
[21:20] <rick_h_> demo of quickstart deploying a bundle and local charm first thing in the morning
[21:21] <rick_h_> hatch: yep, was going to make it card #1 for moving inspector to the left
[21:21] <hatch> well that's not really part of moving the inspector
[21:21] <rick_h_> jcasto is going to do a quickstart thing as a lightning talk he says
[21:21] <rick_h_> he was blown away when he had to reinstall his machine and did a juju bootstrap and got that juju wasn't installed
[21:21] <rick_h_> but did juju quickstart and it got all setup
[21:21] <rick_h_> hatch: sssshhhh, yes it is :)
[21:21] <hatch> huw should have styled the series selection by your morning
[21:22] <rick_h_> meh, I'll keep it where it's at right now. It just drops
[21:22] <hatch> I was thinking of keeping viewlets and not using views so that we didn't have to create new instances all the time
[21:22] <gary_poster> bac, mjc down?
[21:22] <hatch> ohh ok, don't update from develop then
[21:22] <gary_poster> oh, back now
[21:22] <rick_h_> hatch: but creating and cleaning instances ftw
[21:23] <rick_h_> explicit but whatever, we can chat. I had thought we had agreed to tweak that
[21:23] <hatch> I did, then I started looking at the extra cruft that it brings
[21:23] <hatch> a Y.VIew
[21:23] <rick_h_> since I'm on a dial up moden over here and hard to discuss 
[21:23] <rick_h_> modem
[21:23] <hatch> 56k?
[21:23] <hatch> :P
[21:24] <rick_h_> heh, 2G on the mifi at the moment
[21:24] <rick_h_> that's like..half the G's I like
[21:24] <hatch> no longer the same ol' G
[21:25] <rick_h_> ooh, bac you doing a mjc deploy? or is that for next week?
[21:27] <gary_poster> hey Makyo, I was looking at implementing aggregatedStatus.  So, looks like I walk the relations, then for reach relation, I have to walk the units of the source and target services to see if there is an error with the agent_state_data.hook value with a corresponding interfaceName + '-relation-changed' for the relation.  Is that 'bout right?
[21:27] <Makyo> gary_poster, I wound up doing that as part of my branch.  Want to compare notes?
[21:28] <gary_poster> Makyo: nm, if you've done it.  Was trying to be helpful. :-)
[21:28] <gary_poster> happy to talk if you'd like to but otherwise will look about for something else
[21:28] <hatch> gary_poster https://github.com/juju/juju-gui/blob/develop/app/views/viewlets/service-relations.js#L38
[21:28] <Makyo> gary_poster, no worries! Was working on relation status for the icons in the menu, and realized I had to type 5 lines to get the aggregated status in there.
[21:29] <hatch> I'd love it if we could somehow move that into the relation objects
[21:29] <gary_poster> hatch would be difficult because relations don't have direct references to services
[21:29] <gary_poster> could instead make helper function
[21:30] <gary_poster> usable in isolation or this kind of context
[21:30] <hatch> yeah right, I was thinking that there should be something in the db (util method) because it would then have access to it all
[21:30] <Makyo> gary_poster, I came up with http://pastebin.ubuntu.com/6887685/
[21:31] <hatch> It would also be nice if a service had reference to it's relation objects
[21:32] <gary_poster> Makyo: how can relation.hasRelationError() work, given the lack of references I was just mentioning?
[21:32] <Makyo> gary_poster, http://pastebin.ubuntu.com/6887690/
[21:32] <Makyo> DecoratedRelations do.
[21:33] <gary_poster> oic
[21:34] <Makyo> That's currently on the decorated relation, but it could go on the relation model as well to be used by the viewlets.
[21:34] <gary_poster> Makyo: that last pastebin is too fragile, I think: if a unit has *any* relation error it will declare all relations it has to be in error
[21:35] <gary_poster> Makyo: I think you need to do what I descrbed above: see "if there is an error with the agent_state_data.hook value with a corresponding interfaceName + '-relation-changed' for the relation"
[21:35] <Makyo> gary_poster, It's the same logic as hatch 's link, but yeah, I'll look into it.
[21:35] <gary_poster> ah, yeah, that's broken too :-/
[21:36] <Makyo> But like I said, I can store this on the relation model rather than the decorated relation, and then the viewlet doesn't need to do it either.
[21:36] <hatch> the issue with the viewlets one is that a relation can be both good and bad
[21:36] <gary_poster> Makyo: but relation model doesn't have source/target
[21:37] <hatch> depending on which service you're viewing it from
[21:37] <hatch> whereas in the relation line if either end is bad, the whole thing is bad
[21:37] <gary_poster> hatch, but that logic is also broken if you have multiple relations betwen the same two servcies
[21:37] <gary_poster> or actually no
[21:37] <Makyo> gary_poster, but we have that when decorating the relation.
[21:37] <hatch> do we want to chat in a hangout? :)
[21:37] <gary_poster> a unit can have any relation error 
[21:37] <gary_poster> ok sure
[21:38] <gary_poster> I nominate hatch to make the hangout :-P
[21:38] <hatch> on it
[21:38] <gary_poster> :-) thx
[21:38] <hatch> https://plus.google.com/hangouts/_/7acpiti1mnfe553mh8r2l4flqc?authuser=1&hl=en gary_poster  Makyo 
[21:39] <Makyo> hatch, please invite makyo@drab-makyo.com
[21:39] <hatch> on it
[21:39] <hatch> done
[21:57] <huwshimi> Morning
[21:59] <hatch> hey huwshimi 
[22:01] <Makyo> Dogs are being ridiculous (part of my frustration on the call, sorry).  Gonna get them out for walks before they drive me up the wall.
[22:01] <hatch> :)
[22:02] <hatch> huwshimi develop now has the series selector inspector in it
[22:02] <huwshimi> hatch: Ah brilliant
[22:02] <huwshimi> hatch: How do I trigger it?
[22:03] <hatch> drag a file with a .zip extension onto the canvas should work....
[22:03] <hatch> i think frankban's fakebackend code landed with enough functionality
[22:03] <hatch> let me check
[22:03] <hatch> one minute
[22:04] <huwshimi> hatch: That worked. I'll style it then!
[22:05] <hatch> awesome yup it works
[22:05] <hatch> a few branches landed just in time for you to not have to do a bunch of setup
[22:05] <hatch> :)
[22:05] <hatch> huwshimi so basically, the rules are.......do whatever you want with the styling :D
[22:06] <hatch> benji you wouldn't happen to be around still hey?
[22:07] <benji> hatch: not really
[22:07] <benji> :)
[22:07] <benji> what's up?
[22:07] <hatch> haha, just looking for a quick update on the zip stuff. I'm trying to decide what to do next
[22:08] <benji> I've moved into the implementation phase.  Nothing of note to report yet.
[22:08] <benji> The tests for the existing code are a little sparse, so that's not helping.
[22:08] <hatch> alright in that case I'll move outside of project 1 for now
[22:08] <hatch> thanks
[22:08] <hatch> enjoy your night :)
[22:12] <benji> later
[23:33] <hatch> huwshimi hey, just for planning tomorrow, do you think you'll be done with the styling and such by your EOD?
[23:33] <huwshimi> hatch: Just pushing now!
[23:34] <hatch> oh haha perfect :)
[23:42] <huwshimi> hatch: https://github.com/juju/juju-gui/pull/113
[23:43] <hatch> on it!
[23:44] <hatch> oh man that looks about 1Billion times better
[23:45] <huwshimi> :)
[23:47] <hatch> huwshimi small idea from qa added to the review
[23:55] <huwshimi> hatch: I'm not quite sure what to do...
[23:58] <bac> jujugui: http://staging.jujucharms.com/heartbeat up but mildly disgruntled
[23:58] <bac> hi huwshimi!