#juju-gui 2013-06-24
<antdillon> rick_h, Hi, would you be able to help get me set up with the latest juju gui?
<rick_h> howdy antdillon 
<rick_h> sure, sounds like fun :)
<antdillon> rick_h, lol thanks
<antdillon> rick_h, If I can get it running locally or access to a staging I can mess with that would be great
<rick_h> antdillon: did you want to run a quick hangout first to kind of figure out where we are or did you have a specific trouble getting it going
<antdillon> rick_h, Yeah sure
<rick_h> antdillon: there's two ways to go. 1) check out the source with bzr and go through the hacking doc http://bazaar.launchpad.net/~juju-gui/juju-gui/trunk/view/head:/HACKING
<rick_h> antdillon: or 2) use the charm to get an instance up and running in canonistack and then ssh into it and work on it remote
<rick_h> antdillon: forgive me if I offend, but going to assume nothing. Have you used bzr much? setup a LP account?
<antdillon> rick_h, That's fine, yes use bzr for our sites and have an account
<antdillon> rick_h, nick is ya-bo-ng
<rick_h> antdillon: ok, then maybe this will be easy. just bzr checkout lp:juju-gui and then walk through this hacking doc that's in the root of the tree
<rick_h> antdillon: you can probably skip the rapi-rolloup step and just use the sandbox. 
<rick_h> antdillon: so start with line 47 of that hacking doc
<antdillon> rick_h, Will do
<rick_h> antdillon: and let me know if you run into trouble. 
<antdillon> rick_h, I sure will
<antdillon> rick_h, Its working a treat, thanks
<rick_h> antdillon: awesome
<rick_h> antdillon: make sure to shout if run into anything. 
<antdillon> rick_h, I will, thanks
<gary_poster> frankban, yay on first branch :-)
<frankban> :-)
<hatch> morning
<benji> rick_h: I could use some ideas on how to wire up access to app.modelController.getCharm.  If you could look at https://codereview.appspot.com/10500044/diff/1/app/widgets/charm-container.js and let me know what you thing, I would appreciate it.
<rick_h> benji: otp will look in a sec. 
<benji> thanks!
<benji> my instinct is to send app.modelController.getCharm through as part of the config, but I can't trace the config and object instantiation all the way back to app
<hatch> benji: did you see how the deploy method is passed into the subapp in the app.js initializer?
<benji> hatch: nope, I'll take a look at that
<benji> hatch: actually, I have seen that... I did it. :)
<hatch> I only ask because on line 222 you use some reference to app instead
<benji> The problem is that I don't see the chain of causality that starts in app and ends in the charm container widget
<rick_h> benji: ok looking
<benji> hatch: right, that's what I'm trying to remove
<rick_h> so benji I'd assume we'd do the same thing we did in the add button to get the charm data we've got, turn it into a Charm model instance, and use that in the drop event. 
<rick_h> benji: guichat?
<hatch> sorry I'm having some issues with my vm
<benji> rick_h: sure, but I need a minute to prepare;  I'll ping you in a couple
<rick_h> benji: rgr
<benji> rick_h: I'm in guichat
<abentley> orangesquad: could you please review https://code.launchpad.net/~abentley/charmworld/remove-bzr-ingest-job/+merge/170899 ?
 * sinzui looks
<gary_poster> hey hazmat, did you see my email about deployer?  sound ok?
<sinzui> abentley, r=me
<abentley> sinzui: Thanks!
<bac> hi benji
<hatch> benji: did you want a review on /charm-dnd-2 ?
<bac> benji: when you have a moment, i need to ask you about some stuff in go sandbox
<benji> hatch: not quite yet; I have to tweak a couple of things
<benji> bac: ok, it'll be a couple of minutes
<hatch> alrighty, lemme know when
<benji> bac: I'm free
<bac> benji: guichat?
<benji> bac: sure
<abentley> orangesquad: Could you please review https://code.launchpad.net/~abentley/charmworld/remove-scan-ingest-job/+merge/171093 ?
 * sinzui does
<sinzui> abentley, r=me
<hazmat> gary_poster, sounds good
<gary_poster> awesome thanks hazmat
<hazmat> gary_poster, reply sent
<gary_poster> thank you :-)
<rick_h> benji: https://code.launchpad.net/~rharding/juju-gui/dnd-test/+merge/171121 is kind of what I was talking about. It's not working right (evt is empty of any data) but the events fire 
 * benji looks.
<rick_h> benji: note I moved the functions inside to try to gain a closure so only one copy of the json'd data was kept around for each charm-token instance
<rick_h> so hacky hacky 
<benji> :)
<benji> that's pretty close to what I have
<bcsaller> I'm having trouble tracking down some bleeding tests on my branch, its somewhere in the existing code. Maybe after the meeting somone can help look at lp:~bcsaller/juju-gui/ghosttown/ with me?
<gary_poster> jujugui call in 10, kanban now pls
<hatch> bcsaller: sure
<bcsaller> hatch: thanks
<abentley> orangesquad: could you please review https://code.launchpad.net/~abentley/charmworld/remove-jenkins-ingest-job/+merge/171124 ?
<sinzui> okay
<gary_poster> jujugui cll now
<gary_poster> ish
<hatch> rick_h: are the featured charms queries cached on the server? sometimes they come in in a slightly different order which would imply no...
<hatch> sorry ^ abentley
<abentley> hatch: No, they aren't.
<hatch> ahh ok - should I file a bug for that? or is it a known thing?
<abentley> hatch: No, caching will only be implemented if and when we need it.
<rick_h> hatch: what's up/wrong with the featured charm order/etc?
<rick_h> hatch: featured charms are manually selected and can change at any time
<rick_h> hatch: so not sure if you're just generally worried about speed or you're setting up a test or something to rely on that info
<hatch> rick_h: abentley just curious - I figure if it's building a list every request I figure it was wasteful load on that server
<rick_h> hatch: so right now it's not. Since featured can be changed by ~charmers it responds immediately :)
<abentley> hatch: We're not aware of any performance problems on the server.
<rick_h> hatch: and for now the perf isn't an issue
<sinzui> abentley, r=me
<hatch> yeah it's not an issue now
<rick_h> hatch: so yea, no caching atm since we don't need it. Our deployment includes squid and can be added as required down the road. 
<hatch> ahh cool cool
<abentley> hatch: Premature optimization is the root of all evil.
<hatch> :)
<benji> rick_h: am I correct that the charm's attributes just get slammed on the charm token object?  I need a clean set of object attributes to JSONify.
<rick_h> benji: correct. the charm token is passed the model.getAttrs()
<rick_h> benji: in my example that's the cfg stored in the intializer 
<rick_h> benji: I stored that cfg off so that it was kept clean from the token's attrs
<benji> rick_h: ah, gotcha
<Makyo> hatch, when you get a sec, would like to talk about a task.
<hatch> sure
<hatch> Makyo: guichat?
<Makyo> Sure, be right there.
<hatch> bcsaller: when the db is destroyed there is no destroy method
<hatch> so it doesn't necessarily detach those events...trying that now
<bcsaller> hatch: I suspect I might need to retain the handle and free them manually 
<hatch> yeah that didn't work :)
<hatch> nope that didn't help either
<hatch> bcsaller: you should probably merge trunk into this to take advantage of the fixes teknico did to the tests
<hatch> oh that didn't help either
<hatch> heh
<hatch> arg
<hatch> bcsaller: ok any of my 'ideas' didn't pan out :( next step would be to go test by test commenting them out
<bcsaller> hatch: thanks for looking, I'll merge trunk and try again, was hoping you'd spot something I'm missing
<bcsaller> we still use way too much state to test :-/
<hatch> yeah - my new branch moves the deploy/inspector code into an app extension so that it can be unit tested properly
<hatch> sorry I coudln't be of any real help
<bcsaller> hatch: I appreciate the time, thanks
<benji> rick_h: I got a crazy error when trying to instantiate a charm model (var charm = new models.Charm(charmData);
<rick_h> benji: crazy?
<benji> ): Uncaught TypeError: Cannot use 'in' operator to search for 'bubbleTargets' in {"initialized":true,"destroyed":false,"distro_series":"precise" [... lots more]
<rick_h> benji: can you paste me the lots more into a pastebin please?
<benji> and bifurcated
 * rick_h wonders if getting more than supposed to and wtf is up with that
<benji> rick_h: com
<benji> pfft
<benji> rick_h: http://paste.ubuntu.com/5796075/
<rick_h> benji: so in looking at the data, the two that jump out at me are initialized and destroyed? Can you try doing a quick hack of del charmData.inialized and charmData.destroyed and see if that changes things?
<rick_h> benji: and then we can chase them down if that's the issue
 * benji tries
<rick_h> hatch: isn't there a way to tell YUI to ignore non-declared attrs in a initializer?
 * rick_h can't find a flag/setting for that atm
<hatch> I'm a little confused - if they aren't declared then they shouldn't exist?
<hatch> I'm probably missunderstanding
<rick_h> hatch: maybe I'm assuming 
<rick_h> hatch: sec, let me try something. 
<hatch> aww man today is a Canadian holiday
 * hatch grumbles about The Man
<bcsaller> swap day?
<hatch> well I didn't even know it's a holiday, just noticed on the calendar hah
<benji> rick_h: I figured it out: that was just a string, I forgot to parse it back into an object.
<rick_h> benji: ah ok yay
<gary_poster> hatch,  since you are working you can use this as a swap day.  Take another day off within the next few weeks and claim it in canonicaladmin as a "swap day" and reference the national holiday
<gary_poster> jujugui and orangesquad, you all are invited to participate in the great bundle naming vote of 2013, sent out by luca__ a little while ago.  Participate if you like. :-)  Use comments n the google doc
 * rick_h ducks
<gary_poster> (thanks again luca__  :-) )
<luca__> gary_poster: np
<sinzui> gary_poster, thanks. I am still pondering, hoping for something that will be a great transitional name for the bright future
<gary_poster> :-) cool sinzui
<hatch> I'm confused by this vote
<hatch> I need continuous ads on Fox News to tell me what to vote for
<gary_poster> lol
<rick_h> gary_poster: now this is the idea of a environment dump/load setup right?
<gary_poster> rick_h, yes.  in contrast to stacks
<hatch> although they are almost the same thing
<hatch> :)
<rick_h> ok, went out on a limb and ranted against the idea from the beginning :)
<hatch> ranting is on a limb for you? are you sure....?
<hatch> :P
 * hatch ducks
<rick_h> hah, see you caught the irony there didn't you :P
<hazmat> let's call them chundles ;-)
<hatch> haha
<rick_h> eundles!
<hatch> undies!
<bcsaller> charm bracelets 
 * rick_h forsees the Haynes lawsuit
<hatch> charm undies
<hatch> wait till we get our charms on you
<hatch> Makyo: run into any issues with the viewlet stuff?
<Makyo> hatch, nah, it's interesting, pretty easy to read. 
<hatch> good good
 * hazmat has a zope3 flashback from hearing viewlet
<hatch> I had to google that
<hatch> :)
<rick_h> hazmat: yea, makes me cringe every time I review a branch!
<hatch> jujugui can we simply call bundles stacks and make the difference transparent? They virtually are the same thing as far as the user is concerned it's only the implementation that differs
<rick_h> hatch: no no no no no kthx no :)
<hatch> why not?
<bcsaller> hatch: it is more complex than that, stacks will have hooks and so on, and persistent identity. You can make a case that a stack with no hooks is very similar though
<rick_h> this is why I want to ditch the 'charm' and make one about the environment and one about the charm
<hazmat> hatch, except stacks have meaning oonce their imported
<hazmat> hatch, bundles don't
<rick_h> one is just a dump of the current environment and you can reload that environment, the other is a full on charm, with an api, etc
<hatch> that's fine - that can be an added feature to stacks once they are done
<gary_poster> hatch, also Mark S says no.  So...it's important that you understand the difference, but... :-)
<bcsaller> they could though, that property is either useful or ignorable 
<hatch> right now a 'stack' could simply be a collection of charms
<rick_h> hatch: think of system backups vs a meta package. 
<hatch> then we could add these 'hooks' and the like lateron
<hazmat> a stack is a logical (really hierarchical) grouping with exported endpoints and possibly additional behavior, they want for different visualization in the gui as well.
<hazmat> ie i can zoom into a stack
<rick_h> system backup is just a dump/restore of the files where they were. A meta package is itself a package that can have install hooks/etc and brings together a bunch of individual packages
<hatch> I understand that - however I think that we are going to confuse our users when these stacks come out
<hatch> it is confusing enough that we need a vote about it
<hatch> so clearly there is something not right here
<rick_h> hatch: I'm partially with you. I wish we'd drop the charm part of the bundles name to help keep them seperate
<hatch> you can think of a stack as a wrapper around a bundle which implements additional functionality ie) hooks
<hatch> which could then be thought of an enhancement ontop of a bundle
<rick_h> disagree :)
<hatch> I don't know who wrote this but in the vote it even says """We currently think that we will want to deprecate this idea once we have stacks, but we donât know when stacks will appear.  It could be well over a year."""
<gary_poster> hatch we can treat a stack like a bundle, but we can't treat a bundle like a stack.  Kapil's explanation gets to the heart of it.
<gary_poster> I wrote that
<hatch> which means that stack is a logical enhancement of a bundle
<hatch> I foresee 1000 of these questions "Which do I want, the wordpress bundle or wordpress stack?"
<hatch> "what is the difference between the wordpress bundle and the wordpress stack?"
<gary_poster> hatch, the plan AIUI is that people will never ask that.  Once we have stacks, we will deprecate and/or convert and rename bundles.
<hatch> exactly
<hatch> so why don't we just call bundles stacks
<hatch> and add features to it
<bcsaller> two similar concepts is bad, I agree, but I think your understanding is flipped, bundles are dumbed down stacks rather than an enhancement story the other way 
<rick_h> I still use a use for this idea of taking your current environment (maybe with multiple stacks deployed) and backing that up/restoring it via the bundles functionality
<rick_h> I still would see a use that is...ugh
<hatch> rick_h: then that could be called an 'export'
<rick_h> then let's call it an export now and now confuse people :)
<gary_poster> hatch, because that's not what Mark S wants.  to make this argument, put it in the doc.  Happily, Mark R has agreed to make the decision, because I did not want to.
<rick_h> and environment export hehe
<hatch> alright I'll add to the doc, thanks for the discussion to flesh out my idea :)
<bcsaller> rick_h: it might be a subset of the environment and it might be added to an existing env on import. I think environment in those cases implies too much
<hatch> document updated, feel free to tear me apart :P
<hatch> now I forget what I was doing prior to this vote
<hatch> lol
<hatch> oh now I remember
<hatch> bcsaller: is your code 'stable' pending this test fix so I can start looking at integrating?
<robbiew> gary_poster: nice work to you and your team on the new gui
 * hatch pats team on the back
<robbiew> ...and I should probably thank the designers...so a nod to them as well
<robbiew> it's fucking awesome ;)
<hatch> and it's only going to get better :)
<rick_h> bcsaller: I guess technically we could do that but my understanding is that it's an all or nothing dump currently. True you can import into an existing environment, but again, it seems to match up more with backup/restore. 
<hatch> rick_h: that name backs you into a corner
<hatch> an 'export' is generic enough to work for anything
<hatch> a name needs to be generic enough to not back you into a corner but specific enough to describe what it does
<rick_h> hatch: but I don't mind. We've got something better coming along. It's a place holder and this way it's kept apart. but it's how I see it. Let the rest fall into place. 
<hatch> I think we agree but are disagreeing on semantics :P
<hatch> "my export name can beat up your export name"
<hatch> :D
<gary_poster> thanks robbiew :-)
<hatch> dialog or dialogue ?
<benji> For the LP project we used British English, I expect that is still the default.
<hatch> dialogue it is
<hatch> grabbing lunch, ding if ya need me
 * Makyo lunch
 * bac seeks reviewers https://codereview.appspot.com/10522043
<hatch> holy smotes
<hatch> that's a large diff
<hatch> smokes*
<hatch> oh and yes bac I'll do it
<hatch> :)
<bac> hatch: make sure you use the link i pasted not the other
<hatch> yup used that one
<bac> hatch: ok.  i accidentally re-used a branch name and lbox tacked it on to a months old review
<hatch> oh heh - yeah I've done that before
<hatch> kind of a issue with bzr I suppose
<gary_poster> jujugui could I have three volunteers to review the wireframes luca just sent out, before EoD today?  If I get more than three, bonus!  I want at least three, other than me.  orangesquad, if you have feedback, it would be appreciated as well, but please get it in today.
<bac> o/
<hatch> I will
<hatch> but he didn't attach the wireframes
<hatch> I replied to him to mention that :)
<bac> if he's gone that's going to make it hard to get reviewed by eOd
<hatch> lol
<hatch> hopefully he gets his email on his phone and will realize eventually
<sinzui> thank's gary_poster, I had not notices I had email
<gary_poster> hatch, bac, I think it might have been ripped from the mailing list
<luca__> Hi all, was my wireframe attached to my email?
<gary_poster> luca__, it was
<gary_poster> not your fault
<gary_poster> I think the mailing list ripped it out
<gary_poster> I can forward to people
<gary_poster> go relax :-)
<gary_poster> thank you!
<hatch> :D
<luca__> gary_poster: haha cheers :)
<luca__> night!
<gary_poster> night
<hatch> night
<gary_poster> bac, you confirm that you did not receive it either?
<bac> i did not get an attachment
<gary_poster> lol ghosttown
<gary_poster> ok forwarding to gui team and orange...
<hatch> bcsaller: it was the lack of a flags object?
<bcsaller> hatch: no, that was an issue in some tests, but I moved the event binding under that flag for the time being 
<hatch> ahh ok
<bcsaller> and all was right in the world 
<abentley> orangesquad: Could you please review https://code.launchpad.net/~abentley/charmworld/remove-store-ingest-job/+merge/171162
 * sinzui looks
<sinzui> abentley, maybe after this we can talk about high bugs and clearing the queue during deployments
<abentley> sinzui: sure.
<hatch> bac: review done
<sinzui> abentley, r=me
<hatch> bcsaller: reviewing
<bcsaller> awesome
<abentley> sinzui: Ready when you are.
<jcsackett> jujugui/orangesquad: can i get 2 reviews on huw's design work for the sharing widget, please? https://codereview.appspot.com/10495045
<gary_poster> jcsackett, I'll give you a code lgtm and you can count as the qa reviewer if you want
<gary_poster> or do you want qa as well?
<jcsackett> gary_poster: oh, i can do qa.
<gary_poster> cool, jcsackett. LGTM.  land it. you count--not your branch.
<gary_poster> I mean...
<gary_poster> sigh...English
<jcsackett> gary_poster: i follow. :-P
<gary_poster> :-)
<hatch> bcsaller: done
<bcsaller> hatch: thanks
<bac> hatch: why should i check that we're logged in before logging out before testing that the unauthenticated check is done?  seems a bit redundant to me.  we're not testing the logout method.
<hatch> bac: but you are - if the logout function isn't working you won't be able to test your code
<hatch> so it's a safety assert to tell you, yes this test can fail
<bac> hatch: no, let's test logout somewhere else if it isn't tested.  but i'm not going to check every time i call it to ensure it worked.
<hatch> allllllright
<bac> i mean, if i call logout and then assert that we're actually logged out, how can i be sure the assert wasn't broken???  :)
<hatch> hah
<hatch> gary_poster: a charm cannot specify options for a config correct? re luca's comment on the dropdown in settings
<gary_poster> yes, a charm can hatch.  lemme make sure I am seeing what you mean...
<bac> gary_poster: this new design by luca will require our auto-growing text entry boxes.  i hope he's ok with that.
<bac> gary_poster: my bug requesting a new 'text' type in juju config was blown off and marked as 'opinion'
<gary_poster> bac, I hope so too.   Might as well mention it.
<gary_poster> :-/
<bac> not even wishlist !
<bac>  s/opinion/sod off/
<gary_poster> :-/
<gary_poster> hatch, what comment?
<gary_poster> bac, what bug?
<hatch> Confirm setting - can we do these as drop downs or do they have to be input fields
<hatch> can as a charm author I specify a list of options?
<gary_poster> oic
<hatch> I was sure it had to be a text input
<gary_poster> no
<gary_poster> yeah text fields you are rght hatch thanks
<hatch> alright thanks for clearing that up - I'll add that to my review
<gary_poster> hatch, which means checkboxes validating value are kinda funny
<hatch> yup that was going in there too :)
<gary_poster> empty string? looks ok!  random ascii? looks ok!  utf8? looks ok!
<hatch> lol
<bac> gary_poster: bug 1171980
<_mup_> Bug #1171980: Allow a 'text' configuration type <juju-core:Opinion> <https://launchpad.net/bugs/1171980>
<gary_poster> ack thanks bac
<bac> yeah, those checkboxes are odd
<hatch> I don't see how that's opinion
<hatch> that's clearly a valid feature request
<bac> hatch: and we've now spent more time discussing it than it would take to implement
<bac> well, almost
<hatch> lol
<bac> i'll be happy to do it if it won't be rejected
<hatch> it almost certainly would be lol
 * gary_poster has to go cook some fish.  I'll try and do some reviews of bac and bcsaller's branches later, but maybe between you two and Makyo you can get those reviewed.  I'll take myself off as a reviewer of bac's branch. looked good so far. :-)
<bac> gary_poster: np
<hatch> could someone take a review of bcsaller's branch so I can merge it into mine? :)
<hatch> CI is broken
<hatch> I think it's a canonistack failure
<hatch>  "ProcessExecutionError"
<hatch> luca is going to have a lot of text to read in the morning after we do these reviews :)
 * bac dogwalk.  will try to do reviews later.
<hatch> Makyo: do you have a card for that branch?
<Makyo> hatch, no, sorry.
<Makyo> hatch, It's in story1 review now
<hatch> ok cool
<hatch> just adding my name to the review tag
<bcsaller> Thanks for the review
<bcsaller> hatch: that is merged now, are you ok to continue with it while I continue work on deployer exports?
<hatch> yep it's going to be a touch more work than I thought but np I'll git-r-dun
<benji> hatch: my branch is ready for review: https://codereview.appspot.com/10500044 (I, however am ready to go, so I'll read the amazing reviews tomorrow)
<hatch> benji: ok cool I'll get right on it
<hatch> bcsaller: is the topology related to the app via views.environment.instance.topo ?
<hatch> I can't remember if thats the proper chain
<hatch> it's so deep it's like it's a Java object :P
<bcsaller> hatch: that looks right, needing to extract it like that is usually a bad sign, when its the whole app we might promote it up and pass it into the view from app
<hatch> yeah that's a good idea
<hatch> ok thanks
<hatch> because the topology has no reference to the jujuapp instance right?
<hatch> ^ bcsaller
<bcsaller> I think we've always said its bad policy to pass app down
<hatch> yep just confirming
<bcsaller> topology isn't however a singleton, something to keep in mind
<hatch> thx
<hatch> we will have multiple topologies?
<bcsaller> picture drawing bundles in a selection 
<hatch> alrighty
<hatch> right now it's a singleton
<hatch> but I can see where it could be easily edited to not be
<hatch> benji: review done
<huwshimi> Morning
<bcsaller> hazmat: ping
#juju-gui 2013-06-25
<hazmat> bcsaller, pong
<hazmat> bcsaller, qualified endpoints should work
<bcsaller> ahh, ok, thanks
<bcsaller> I can emit the proper thing then
<hazmat> bcsaller, cool, 'annotations'  as dict key under service bag, and environment/stack/bundle annotations as top level 'annotations' key.. sound good?.. also a format key
<bcsaller> hazmat: all good, and then charm name can be cs: prefixed, right?
<hazmat> bcsaller, how about just omitting the branch tag, cs: prefix optional
<hazmat> bcsaller, check email for all the ways to spell relations currently
<bcsaller> hazmat: so charm: wordpress, branch: cs:precise/wordpress ?
<bcsaller> hazmat: thanks
<hazmat> bcsaller, not quite.. charm: wordpress  spells cs:<default-series>/wordpress without the branch qualifier
<bcsaller> ahh, ok, didn't realize it would combine series automatically
<hazmat> bcsaller, default series for resolution is already spelled above the service collection in the config
<bcsaller> yeah, makes sense 
<hazmat> bcsaller, are you exporting a whole env or subset?
<bcsaller> hazmat: for now the whole, when we have a UI for selections I think allowing a subset will make sense 
<hatch> morning huwshimi
<huwshimi> hatch: Hello
<hatch> hows your day going huwshimi?
<huwshimi> hatch: Not bad, yourself? Well, evening by now I guess :)
<hatch> haha yeah - I spent too much time today reviewing stuff so I am putting in some OT to try and get back on track
<Makyo> Sticking with this from now on: http://loremgibson.com/
<hatch> what...the....heck?
<Makyo> Maaay require prior obsessive rereadings of William Gibson to find funny..
<hatch> I'm going to guess
<Makyo> Ah well :)
<hatch> I'm working to an 8h Ferry Corsten set
<hatch> heh
<hatch> somehow I'm getting two services in the gui on deploy and it's irritating me
<hatch> dogwalk, come back, solve in 30s heh
<bac> teknico: if you look at fakebackend.js:756 you'll see the error message contains backquotes so my test is just matching what is there.
<bac> teknico: do you find them so offensive that you want me to change the original?
<frankban> gary_poster: started trunk CI tests in ec2
<gary_poster> thanks frankban :-)
<gary_poster> hatch, if you have a quick second today to reply to ant's reply about your CSS/JS design guide concerns that would be great
<teknico> bac: only mildly so, or I'd have noticed it earlier, so don't bother
<teknico> bac: it looks out of place, like some kind of go-ism
<bac> teknico: too late!  done.
<teknico> bac: that's still good, thanks :-)
<Luca___> bac: You sent me "The configuration and constraints in Juju still do not support units." can you expand on that?
<bac> sorry Luca___, i meant numerical units, e.g. 4 Gb
<Luca___> bac: so, what does it relate to?
<bac> Luca___: the display of the constraints where you have 2.0 GHz and 8 GB
<bac> we'll have a 2 and an 8 but no idea of the units
<bac> hatch: ahoy?
<rick_h> Luca___: ping, can I get a 48x48px of the default charm icon? I'm looking and not finding the .svg for that only the pngs for 64/96/etc
<rick_h> sinzui: so setting a min-width on the whole thing is working. Please let me know when the deploy is looked at. I'll point things at staging for the moment.
<hatch> morning
<sinzui> I am already on it
<rick_h> sinzui: thanks
<Makyo> hatch, howdy.  Quick question once you're settled in.
<hatch> Makyo: shoot
<hatch> my damn coffee machine isn't working properly
<Makyo> hatch, boo, get that fixed ASAP!
<hatch> yeah I might need to take a run to starbucks or something
<benji> hatch: let me know when you have a minute to discuss your review of my branch
<hatch> ok Makyo your question?
<Makyo> hatch, I'm curious if I might be missing something.  I can't deploy a charm with trunk and /:flags:/serviceInspector because I don't get a configuration panel.
<Makyo> Sorry, haven't tested trunk directly, after merging with trunk, I mean..
<hatch> hmm that's no good, checking trunk
<Makyo> I am too.  If it works there, I can narrow it down to a conflict.
<hatch> yeah it's working in trunk
<hatch> when I merged trunk into my branch the code which handles the flag in app.js init got very munged up
<Makyo> It's not for me, but that might be a cache thing.
<Makyo> Hmm.,
<hatch> ohhh wait my trunk is right messed up
<hatch> i'll delete and pull it down again
<hatch> Makyo: ok I see the same issue
<hatch> one sec for a fix
<hatch> Makyo: in my local branch I fixed this but for a temporary fix... comment out app.js:584
<hatch> you won't get a ghost but a service will show up after deploy
<sinzui> rick_h, The revno 279 is now set  in production and the page I was watching is correct
<rick_h> sinzui: looking
<Makyo> hatch, but your branch fixes that, yes?
<hatch> Makyo: yeah I rewrote that whole section
<rick_h> sinzui: awesome, thanks
<Makyo> hatch, okay.
<Makyo> hatch, Will land mine with the comment so that it works for others, then yours will uncomment.
<Makyo> Sound good?
<hatch> sure thing
<hatch> I have an odd relation line bug in my branch which I'll need a hand solving but first to get benji going
<hatch> benji: did you want to guichat?
<benji> sounds good
<hatch> oh looks busy
<benji> hatch: it's occupied; I'll make a hangout
<hatch> okee
<hatch> post the link plz
<benji> hatch: https://plus.google.com/hangouts/_/79da42ca1e152d6421fc0cdec80ba437a18b0253?hl=en
<rick_h> woo 370 test failures! go me!
<abentley> orangesquad: Could you please review https://code.launchpad.net/~abentley/charmworld/fix-update-charm-branch-call/+merge/171320 ?
<rick_h> abentley: r=me
<abentley> rick_h: Thanks!
<hatch> rick_h: you're a pro!
<gary_poster> jujugui, call about inspector wireframes with Luca___ in 33 minutes in guichat.  Please make sure you have reviewed them by then.  I will send out an email
<hatch> Makyo: have a second to chat about that relation line bug I mentioned?
<rick_h> hatch: what did I do now?
<BradCrittenden> hatch: you have time to chat about starting inspector work?
<rick_h> hatch: oh, my tests. 
<hatch> 370 test failures
<hatch> BradCrittenden: sure I'd just like to show Makyo a bug which I'm hoping he can point me to solve
<gary_poster> hatch could I ask you to also prep to talk about how to build this stuff?  Maybe you and I could talk beforehand soonish?
<BradCrittenden> hatch: ok
<benji> jujugui: wireframe at http://ubuntuone.com/1eafCNZEU70nFW6mtZBipQ
<Makyo> hatch, yep
<hatch> Makyo: guichat
<hatch> plz
<hatch> gary_poster: can do
<gary_poster> thanks hatch.  ping me when you are free.  10 min or less should do it, I hope
<teknico> benji: thank you
<gary_poster> hey sinzui.  I will be out on Monday next week so I want to move the browser sync to Tuesday at same time.  That conflicts with your call with jc.  do you mind trying to rearrange that?
<benji> my pleasure
<sinzui> gary_poster, jcsackett and I can talk any time
<gary_poster> thank you sinzui 
<sinzui> hey jcsackett do you want to talk now?
<gary_poster> (and jcsackett  ;-) )
<jcsackett> sinzui: sure. we can decide when our new talk time should be. :-P
<jcsackett> sinzui: sent you an invite, but it timed out.
<hatch> gary_poster: so am I giving the "tutorial" to everyone or just bac?
 * sinzui tries again
<sinzui> jcsackett, I found your invite
 * sinzui wonders why phone and browser didn't make a noise
<jcsackett> sinzui: i think you went there just as i got your invite. :-p
<gary_poster> hatch, at 11:30, we will have an inspector kickoff, touching on both the wireframes and the engineering.  Unless you think you can do the full tutorial in 10 minutes on the group call, I'd give the tutorial to bac, and give an overview to everyone else.
<gary_poster> hatch, sorry, 1630 UTC :-P
 * jcsackett is astonished at how many ways this can go wrong.
<sinzui> jcsackett, I have left all hangouts. You make/find one and I will join
<hatch> isn't it 15:10 utc right now?
<hatch> ok bac join me in guichat?
<gary_poster> hatch yes 1512, so I meant 1530.  Sorry, thought I was UTC+5
<hatch> ok good - no coffee makes head not my work to goodly
<gary_poster> :-)
<hatch> another processexecutionerror on CI
<bac> hatch: there
<gary_poster> CI passed this time :-/
<gary_poster> hatch do we need to talk before meeting or are you goon on goals for your side?
<gary_poster> good :-)
<adeuring> sinzui, abentley, jcsackett, rick_h, could one of you have a look at this MP: https://code.launchpad.net/~adeuring/charmworld/1192544-use-charm-class-1/+merge/171332 ?
<hatch> gary_poster: nope alls good just chatting with bac
<gary_poster> cool thanks hatch
<sinzui> thank you adeuring
<gary_poster> jujgui, guichat in 1
<gary_poster> Luca___, you too if you can :-)
<Luca___> gary_poster: cheers coming
<gary_poster> benji ping
<benji> it helps to hit "join"
<gary_poster> jujugui, could someone make another high prioriry card (maybe for today?) to create the skeleton of the left hand panel?
<gary_poster> priority
 * gary_poster has to go to lunch
<Makyo> Left hand panel? 
 * Makyo makes card, will fill in detail.
<rick_h> orangesquad hatch Makyo and company, can I get a pair of reviews on https://codereview.appspot.com/10554044 please? Ignore the updated .json test data file. 
<Makyo> rick_h, sure
<rick_h> thanks Makyo 
<hatch> rick_h: on it
<hatch> and you bet I'll ignore that file :P
<rick_h> hatch: :P you have to go through it line by line!
<hatch> lol
<hatch> I don't think I've typed a single line of code today
<hatch> meetings meetings meetings
<rick_h> hatch: :P curse you reading the docs. I've always like expected, actual...but I suppose the docs do say it the other way around. 
<hatch> rick_h: oh I agree - I wrote so many tests with expected, actual until I had a failing test and was like 'wtf?'
<hatch> thenagain node.js also says you should put commas first.......................
<hatch> ................
<hatch> ..........................
<rick_h> yea, I honestly don't read and look straight at the two bits of info. I just have my brain wired for the other way
<rick_h> hah, I actually trained myself to do that when I did PHP
<rick_h> I kind of did get around to liking it. 
<rick_h> except in python where I much prefer just leaving a stinking trailing comman and carry on
<hatch> haha
<hatch> I tried comma first but I found it just moves the problem
<rick_h> at least the problem is at the front of the line and more visible though
<hatch> true true
<hatch> maybe I don't really notice it anymore because I never leave a trailing comma, and use jshint
<hatch> just like adding a semi-colon it's muscle memory :_
<rick_h> We need a new metric for things. TimeToFubarIdentification-ness
<hatch> :)
<hatch> I wanted to buy a book yesterday but it was only available on kindle....I don't have a kindle....since when did BOOKS get locked behind closed walls :/
<hatch> oh you want to read.....NO!!!! buy our hardware!
<rick_h> hah, get a kindle. The nook is shutting down :P
 * rick_h hates the idea in principal but loves his kindle too darn much to deal with anything else. 
<hatch> I read books on dead trees
<hatch> it's a clean renewable resource
<rick_h> hah, e-ink doesn't need re-planting :P
<hatch> books don't require lead circuit boards and lithium batteries  :P
<hatch> lol I really have no idea which is worse
<rick_h> yea, I just love the size/space of it all. The paperwhite is pretty darn awesome withthe light now as well. Camping best friend. 
<hatch> yeah we use kobo here and it's actually really nice to read on
<hatch> but I don't think I'll ever truly switch away from the experience of a book
<rick_h> heh, /me used to say that same thing
<hatch> yeah but I might be more stubborn than you
<hatch> :P
<rick_h> hah! you've met me
<rick_h> hatch: Makyo thanks for the reviews!
<hatch> lol
<abentley> sinzui: In CharmTestCase, what does {'options': {'mode': 'fast'}} mean?
<hatch> np
<rick_h> jcsackett: escapes!
<sinzui> hmm
<abentley> sinzui: Normally, the value of 'mode' is a dict.
<sinzui> abentley, change {'mode': 'fast'} to {'foo': 'bar'}
<abentley> sinzui: No, the problem is the contents.  I don't think a string is a valid type for 'fast' (or 'foo') to have as its value.
<sinzui> abentley, I used an ambiguous example of an "opinionated" charm that allows the user to state they want a fast or stable or cleaver or dumb, or fired
<sinzui> abentley, since I didn't know when you asked (fried/dumb) I think key: value might better text
<abentley> sinzui: Can I change it to {'key': {'default': 'value', 'type': 'string'}} ?
<sinzui> abentley, +1
<hatch> Makyo: do you have a second to take a look at my branch? lp:~hatch/juju-gui/ghost-inspector
<Makyo> hatch, for anything in particular?
<hatch> views/ghost-inspector.js:237
<hatch> guessing that's where the issue is coming from....maybe?
<Makyo> Can you take a step back and explain, please?
<hatch> this is the relationship thing
<Makyo> Oh, okay.
<hatch> just to see if you can see any obvious reason why this branch exposes that error
<hatch> but the original doesn't
<gary_poster> hatch Makyo don't forget that "rip the menu out" might be a reasonable solution for now
<hatch> yep for sure - I'm more concerned that I missed something 'else' which is causing this
<gary_poster> cool
<Makyo> hatch, this looks fine.
<hatch> rick_h:  you didn't answer me about the charm-token widgets....I'm just wondering if there will be 100's of those tokens floating around eventually
<Makyo> hatch, will poke around in more relevant code, though.
<rick_h> hatch: sorry, I removed them. 
<rick_h> hatch: good catch since they weren't in a container that auto cleaned them as per usual
<hatch> great - thanks :)
<hatch> CI is down unable to deploy charm
<hatch> what did you do now rick_h :P
<hatch> I was jk rick_h another one is running :)
<rick_h> hatch: ok, good then :P
<Makyo> hatch, I can reproduce this in trunk.  I think we should remove the menus for now (probably in a quick separate branch), and re-open the relevant bug in case we bring menus back.
<hatch> ohh ok I can't repro in trunk so that's a little comforting I suppose
<hatch> ok I'll clean up this branch and get it landed
<Makyo> hatch, sounds good.  I'll get to the bug/cards
<hatch> thanks for putting in the time!
<hatch> so the best way I have found to diff from trunk with bzr is to merge trunk in and then diff from trunk with trunk as old and the current branch as new
<hatch> it doesn't appear to keep track of the revno it was branched at....at least that I can find
<hatch> didn't teknico land a branch which cached the charm meta data for tests?
<hatch> I am still seeing a lot of GET requests in the console
<hatch> it's entirely possible I was mistaken
<bac> gary_poster: i'll reimburse the first round if you go and wear your bzr t-shirt: https://github.com/blog/1540-raleigh-nc-drinkup
<gary_poster> bac, heh :-)
<bac> offer not good for bcsaller or hazmat
<bcsaller> something I said?
<bac> bcsaller: nah, y'all would run up the tab!  :)
<bcsaller> heh
<hatch> aww boo
<hatch> no flights to get me there in time
<hatch> :)
<benji> hatch: re. "The charm token instances should be destroyed and removed at the end of the tests": how does one do that?  I can't find an example of that in the other CharmToken tests.
<hatch> benji: create a top level var in your describe closure
<hatch> assign the charm token to that
<hatch> call destroy() on that var in afterEach
<benji> hatch: "destroy()" is what I was after, thanks.  What does the "and removed" part reference?
<hazmat> bac but when else am i gonna wear my bzr t-shirt :-)
<hatch> benji: I think I was referring to the container content
<bac> good point hazmat
<bac> jujugui: if you add your flight arrival and departure *times* it'll help with cab sharing.  https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0AtC9etoysSQldDZvazM5T3F2NmFOWUJYcHVfdUhnN1E#gid=8
<gary_poster> +1
<Makyo> bac, Ah, good point.
<benji> hatch: re. https://codereview.appspot.com/10500044/diff/5001/test/test_charm_token_drag_and_drop.js?column_width=80; specifically "Should not be required if you call render() as mentioned below.": The faux _makeDraggable is there to collect data for assertions, so I don't understand the "Should not be required" part.
<hatch> I thought Gary was picking us all up in his van (assuming he has a van because kids) :D
<bac> :)
<gary_poster> yeah, we have a van :-)
<bac> soon minivans will be a thing of the past as each child will have a google-driven smart car.
<hatch> benji: ahh sorry I missread that code
<hatch> my bad
<benji> ok
<hatch> what's flight WN?
<hatch> never seen that one before
<benji> It's Charlie Sheen's airline: "WINNING"
<hatch> lol
<gary_poster> jujugui please two people review bcsaller's branch
<hatch> I'll take one
<gary_poster> thanks
 * benji takes one.
<gary_poster> thanks
<hatch> bcsaller:  is there a way to QA this?
<bcsaller> hatch: the export hotkey 
<bcsaller> or app.db.exportDeployer() for the raw object
<hatch> we are exporting in yaml now.....interesting....
<bcsaller> thats the deployer format
<hatch> yaml doesn't travel over the wire very well :)
<bcsaller> hatch: http://bazaar.launchpad.net/~hazmat/juju-deployer/refactor/view/head:/README
<bcsaller> hatch: a blob is a blob on the wire
<bcsaller> but this isn't about that 
<hatch> yeah I meant as a string
<hatch> yaml seems like an odd format for this no? I can't see anyone ever typing this out
<bcsaller> and with exports they don't have to ;)
<hatch> at least I guess we don't have to write a yaml parser https://github.com/nodeca/js-yaml :)
<bcsaller> already in use
<hatch> oh we use that here already?
<bcsaller> we used the parser for config options
<bcsaller> this uses the serializer
<hatch> oh look at that
<hatch> heh
<hatch> haden't gotten there in the review yet
<hatch> I still think whitespace significant configuration files are a bad idea everywhere :P
<hazmat> bcsaller, fwiw, that's a stable branch atm, dev's on a different one
<bcsaller> hazmat: I expect for what I can export its about the same
<bcsaller> if not easy to fix
<hazmat> bcsaller, yeah
<hazmat> bcsaller, working on diff of env to config atm, might circle back to export within deployer as well, but gui export is still key
<hatch> LGTM'd
<hatch> the ghost config prototype is up for review
<hatch> https://codereview.appspot.com/10565043/
<hatch> now im going to grab some lunch
<gary_poster> jujgui please review branch from Jeff above ^^^
<benji> bcsaller: review sent
<gary_poster> jujugui
<bcsaller> benji: thanks
<bac> i will
<Makyo> gary_poster, hatch  on it.
<gary_poster> thank you both
<hatch> thanks guys
<hatch> who wants to pitch in to buy lgtm.com and write a code review tool? lol
<hatch> oh c'mon we'd make thousands....:P
<benji> it's too bad all four letter domains were snapped up years ago, that would be a good one
<benji> well, it looks like a domain squatter has it, so there is hope yet
<hatch> yeah - I've bought some from squatters in the past - some hold out for the big money but some have taken $1000
<benji> not bad
<hatch> I can't remember what one was....it was some obscure acronym for a client and the squatter wanted $10k
<hatch> just kind of laughed that off
<bac> i used to work for a small consulting firm with a three letter domain name.  we joked (not inaccurately) that it was their most valuable asset.
<hatch> lol!
<bac> they went from 25 to 2 and kept about the same revenue
<hatch> benji: so you couldn't just use container.one('a') ? I actually tested that locally and it was almost identical drag target
<benji> hatch: nope, the charm icon image wouldn't participate in the dragging if I did it that way.
<hatch> that's interesting because it worked here....I suppose another difference between chrome and chromium
<benji> This was on chromium.
<hatch> yeah I'm on chrome in osx
<benji> That might be it.  I made sure Firefox worked on the code as-is, but I didn't try it with just the container.one('a'), that would be interesting.  (but not interesting enough for me to actually try it)
<benji> jujugui: I could use a second review on https://codereview.appspot.com/10500044; thanks!
<hatch> hah yeah that's fine - was just looking at ways to improve that code because it's kind of ugly (not your fault)
<bac> benji: i'll do it
<benji> thanks
<gary_poster> sorry, benji, I would have advertised it if I saw, but very happy you did so :-)
<rick_h> benji: I can relook later tonight
<rick_h> or bac can go then
<bac> benji: actually, i'd better not take it until i finish jeff's
<Makyo> hatch, code lgtm, QAing.
<gary_poster> bcsaller, thank you for landing the deployer-format export.  awesome.  (A) is there anything arosales and jcastro should know in order to try it out?  In particular, do you know what deployer branch they should use to import what's exported?  Otherwise I guess we just need to tell them to use lp:juju-gui as juju-gui-source in the charm when they try it out.  (B) Before we make a release, should we disable import for
<gary_poster>  now (or did you already)?
<rick_h> benji: what does the passing of the container get us that passing a boundingBox node on init of the charm doesn't?
<gary_poster> and look, deploying failed in canonistack again!  exciting.
<benji> rick_h: ooh, that's a good point; that's much nicer
<benji> I didn't put the total plumbing picture together until you mentioned it
<rick_h> benji: content box is created inside of boundingBox which you should be able to pass in on new CharmToken({boundBox: ...})
<rick_h> benji: ah, ok cool
<rick_h> benji: but yea, that's why doing a .set(contentBox) failed. It's auto done based on boundingBox
<benji> I would still like to know why I couldn't .set('contentBox', xxx)
<rick_h> benji: ^^
<benji> oh
<bcsaller> gary_poster: import of the JSON format is still supported, I left it on. Its currently bound to the old 'export hotkey' so nothing special is needed to test. The subset of the deployer format should work with recent versions 
<benji> rick_h: that makes sense, but still, why couldn't I set it?
<benji> (not that I should set it, I now realized)
<benji> s/realized/realize/
<rick_h> benji: http://yuilibrary.com/yui/docs/api/files/widget_js_Widget.js.html#l199 it's a writeOne ATTR
<hatch> benji: it's set as writeonce
<hatch> annnnd rick_h beat me to it
<rick_h> with a link boom!
<hatch> lol u powned me
<benji> and setting a write-once attribute doesn't raise an exception?  that seems like a sadness maker
<benji> heh
<rick_h> ok, let me get the boy a snack and I'll try to finish the review. 
<gary_poster> bcsaller, cool.  JSON format is not what we export anymore though, yeah?  so it is temporarily a feature that is unlikely to do anything but disappoint people?  "The subset of the deployer format should work with recent versions " even with charm store links?
<hatch> benji: nope it's designed to fail silently
<hatch> imho I disagree with their implementation
<hatch> but it's not changing....ever :)
<benji> heh
<bcsaller> gary_poster: no, not any more, though it still works for the DND case cross browser session in sandbox
<benji> I knew I was doomed to be sad forever.
<arosales> woot export landing a day early :-)
<hatch> it's ok, I may eventually convince everyone to switch to Dart at which point I think you'll be marginally happier
<arosales> than you bcsaller :-)
<hatch> that was a joke, I'm not actually going to push Dart.....or am I...
 * benji switches to Dart.
<gary_poster> bcsaller, ok.  I guess it is not discoverable so I am ok with it.  
<hatch> victory!
<gary_poster> lol
<bcsaller> gary_poster: a one line comment around the importexport module would remove the UI for the other formats, but as you say not very discoverable
<bcsaller> arosales: let me know if you hit any issues
<arosales> I mean,thank you bcsaller :-)
<gary_poster> arosales, start gui charm and juju set juju-gui-source=lp:juju-gui and you will have trunk
<gary_poster> it will take just a bit longer to start up that way
<arosales> gary_poster, you read my mind
<gary_poster> :-)
<arosales> so do we still need deployer to import?
<hazmat> yes
<arosales> or is both export and importing handled via the gui
<arosales> hazmat, I take it that yes is for the deployer to import
<hazmat> well.. gui could import, but i don't know that its going to ape the delays in the original deployer
<arosales> hazmat, no worries
<arosales> import was completely out of scope for the gui atm
<arosales> just getting export to work with deployer on a live environment was a super plus the gui team made happen :-)
<rick_h> benji: lgtm then with the boundingBox note and the additional note on the node.remove(true)
<gary_poster> hazmat, arosales, we still plan to run the deployer as a library for import (and maybe export!), but not in time for July 1 :-)
<benji> rick_h: thanks
<gary_poster> ugh, someone shoot canonistack
<arosales> gary_poster, ok, and thanks again for making the gui export work for live environments and with deployer by july 1st.
<arosales> bcsaller, I owe you a beer
<bcsaller> heh
<gary_poster> welcome arosales.  the last thing you'll want us to deliver this week is a GUI release, so your competitors get the new feature automatically.  after you and jcastro verify that everything is working, and work through any kinks if necessary, then we can make a release
 * benji fires an RPG at canonistack.
<gary_poster> :-)
<hatch> gary_poster: did luca say that we DID want the ghost inspector locked to the side or DID NOT? I thought he said to keep it floating?
 * benji watches as canonistack is unphased.
<hazmat> bcsaller, so the old import works with the new export?
<hatch> ^ bcsaller re your comment
<jcastro>  gary_poster is it live on uistage?
<benji> COME WITH ME IF YOU WANT TO LIVE!
<arosales> gary_poster, ok. we'll get on testing and report feedback
 * hazmat catches up with benji
<benji> LOL
<gary_poster> hatch, locked
 * hazmat and gets swallowed up a dartvm exception
<gary_poster> :-)
<hatch> alright thanks
<gary_poster> jcastro, quite possibly.  will ive it a whirl, 1 sec
<bcsaller> hazmat: the old JSON format can still be imported via the fakebackend or the rapi python branches. I don't handle import here, though I could if we want to put more time into this. My understanding is that this isn't the long term solution so I didn't bother 
<hazmat> bcsaller, understood, just wanted to understand your earlier comment re
<gary_poster> jcastro, arosales, live on http://uistage.jujucharms.com:8086/
<jcastro> nice
<jcastro> man, I'm sorry, I'm just not used to things landing early
<jcastro> I am completely flat footed right now
<arosales> jcastro, note the real nice thing here is to be able to export from a live environment not just from a sandbox
<arosales> hazmat, and deployer works with this file?
<hazmat> arosales, not quite, either tomorrow or late tonight, i side-tracked on a feature
<hazmat> namely --diff option to see the delta between an env and the config file
<arosales> hazmat, ok and by Friday is ok too
<hazmat> twas sitting around half-done in my working copy
<arosales> we can get all the docs set less that bit
<jcastro> deployer working with it isn't as important to me as the workflow for people to submit the json
<jcastro> I will have instructions, etc. by tomorrow EOD
<hatch> gary_poster: if we lock the panel to the right does that mean that we only want a single inspector instance open at once?
<hatch> so multiple ghosts but every time you click one it changes the open inspector?
<gary_poster> hatch yes
<gary_poster> hatch until we implement the Mark S special version :-)
<hatch> ok - I'd like to land this branch and then follow up with that restriction cc bcsaller Makyo
<bac> hatch: a third review
<gary_poster> hatch good by me
<hatch> bac: thanks I'll make those fixes and comment where necessary - as far as the interactions are concerned - yes those things need to be fixed - I'll be sure to document them to fix in the followup with the new single inspector restriction
<Makyo> hatch, sounds good.
<hatch> Makyo: bcsaller bac changes made and re-proposed - will be following it up right after to implement the single inspector for multiple views functionality
<hatch> the github event was postponed....maybe until we are there? hah
<hatch> bcsaller: bac mind checking out my branch again to see if you will lgtm so I can get it landed
<bcsaller> hatch:  checking
<hatch> thanks
<bcsaller> hatch: I don't think you addressed my biggest concern which is that this more similar than different from the normal inspector panel wrt handling things like config, I'm not sure we need a new extension and separate code. It seems like we can conditionally assemble viewlets when the model is passed in and bound 
<hatch> so you want to use the controller in views/service.js ?
<bcsaller> hatch: I think they will share more code than not, the template might differ but the logic is mostly the same 
<hatch> I disagree - I think that the service one will end up moving to be more like my version once we have to start adding in event handlers and various advanced functionality
<bcsaller> hatch: that sounds like agreement to me
<hatch> haha
<bcsaller> thats my point though, you've taken it further than the prototype but they both need that code in the end 
<hatch> ok so you want some type of a shared controller between the two....I agree with that
<hatch> the app extension is only the deploy method
<bcsaller> yes, thats what I'm saying, both will need to update configs and constraints
<bcsaller> and a deploy method on the existing controller makes sense to me as well, it would just check pending==true
<bcsaller> hatch: ^
<hatch> *thinking*
 * bcsaller goes to search for food
<hatch> bcsaller: correct me if I"m wrong - you would instantiate a 'ServiceInspector' passing in a service and a complex config with all the events, viewlets, methods for the prototype etc etc etc
<hatch> IMHO that's going to make that service inspector controller way to complex and huge trying to account for all the various methods each will need
<hatch> this needs modularity so that we can instantiate simpler objects for testing and reading
<bcsaller> hatch: if the viewlets had the methods again they would be that, no?
<hatch> then they are views :)
<bcsaller> wouldn't be the end of the world
<hatch> they then need reference to the db, env etc
<bcsaller> or just to the controller 
<bcsaller> brb
<hatch> then the viewlet would need access to the controller
<hatch> sure
<bcsaller> back, sorry, had to get the door
<hatch> np
<hatch> ok how about this
<bcsaller> I agree that we want more code sharing, I'm happy to talk about arrangements of code that get us there, if you'd rather chat about it we can do that too
<hatch> yeah sure lets hop into guichat
<hatch> I'm guessing we are close
<huwshimi> Morning
<hatch> morning huwshimi
<hatch> OSCON looks like a conference I'd like to go to but dayyyyymnnnn it's expensive
<arosales> export env working on aws for a few different bundles (I think that is what we are calling them now).  I'll check hp cloud this evening
<hatch> yeah I got way outvoted on that one
<hatch> :)
<arosales> latest gui is looking good to btw
<hatch> bcsaller: your details are missing from the travel spreadsheet
<bcsaller> hatch: ha, I'll see about fixing that 
<hatch> unless we can convince gary to drive us at 5am it's nice to know when others flights leave :D
#juju-gui 2013-06-26
<teknico1> sorry for the noise, connection flakiness due to bad weather here
<jcastro> hey gary_poster, I have a non informational bug report with no debug content
<jcastro> I tried  to deploy this last night and it wouldn't through the GUI http://jujucharms.com/~marcoceppi/precise/discourse
<jcastro> had no problems deploying haproxy and postgres, but this specific charm would not. The error was vague too, something like "there was an error" and no explanation
<gary_poster> jcastro, ack.  thanks, we'll give it a whirl.
<gary_poster> hey benji, are there default juju deployment constraints?  I don't think so, but checking.
<benji> gary_poster: default values or a default scheama?
<gary_poster> values benji
<benji> nope
<gary_poster> cool thanks benji
<gary_poster> hey luca.  We don't have access to the web team dropbox so we don't have Jaime's assets.  Will you share those with us another way, or do you have another plan?
<luca> gary_poster: I'm just setting up a folder here: https://drive.google.com/a/canonical.com/folderview?id=0B7XG_QBXNwY1V3B3dDNvYXJGRE0&usp=sharing
<gary_poster> cool thanks luca.  so you will send out an email with that and the new flatsies url?
<luca> gary_poster: Yeah, I'm just trying to work out if there are any missing assets from the /psd
<gary_poster> sounds good.  thanks again
<rick_h> benji: can you +1 real quick, and heads up for your branch that it's coming https://codereview.appspot.com/10610043
 * benji looks
<rick_h> jcsackett: is https://codereview.appspot.com/10609043/ ready for eyeballs?
<benji> rick_h: +1
<rick_h> rewrite it all in webgl! http://microsoft-news.com/webgl-spdy3-new-dev-tools-more-confirmed-for-ie11-in-win-8-1/
<rick_h> benji: thanks, sorry it didnt' have cleanup when you hit it. 
<benji> no worries
<rick_h> and spdy our servers! (boo no mod_spdy in the repo)
<luca> Can anyone here tell me how assets should be delivered for the bundle icon? See here: https://docs.google.com/a/canonical.com/file/d/0B7XG_QBXNwY1MlVkNWxHQVJ2UDg/edit
<luca> gary_poster: ^
<gary_poster> luca, will you always want the black and orange thing behind the main icon?  Or are these assets that we want bundle authors to be able to customize (colors esp.)?
<luca> gary_poster: I was thinking that it would be awesome to let them customise the colours but if we can't do that then just the orange and brown is ok for now.
<gary_poster> luca ok.  short answer is, for now, svg.  It would be great if there were a super simple way for charm authors to change colors and add their primary icon, but if they just jave to use inkscape or illustrator or something, so be it
 * gary_poster moves to other computer...
 * gary_poster switched
<gary_poster> hey sinzui.  were you ok with being responsible for getting back with Matt Wedgwood about getting the GUI deployed, and the schedule I proposed, including getting an up-to-date version of the GUI deployed on the prod machines this week?
<sinzui> gary_poster, yep, and because of the squad changes, Much of the work will be with those doing webops this month
<gary_poster> cool thanks sinzui
<gary_poster> rick_h, abentley have you heard back from dan with flight approval yet?  If not, sinzui would you like me to ping him about it?  the longer we wait the more it costs
<abentley> gary_poster: yes.  I have updated the spreadsheet with my auth number.
<rick_h> gary_poster: I just got the email in the last 20min and sent my email off to corp travel just now
<rick_h> gary_poster: with luck will have info before EOD
<gary_poster> yay abentley and rick_h, thanks.  abentley, do you think before EOD will work for you as well?
<gary_poster> bcsaller, when you get in, you're the only other one.  do you not have requisition approval yet?  If so, tell me who you sent it to and I'll ping them.
<abentley> gary_poster: Not sure yet.  Auth had the wrong departure date, so I've emailed events@canonical.com to ask what to do.
<gary_poster> ah ok abentley, I will ping sarah about that, thanks.
<sinzui> rick_h, ping me when you are ready to hangout
<jcastro> gary_poster: did we make a decision on bundle?
<gary_poster> jcastro, it looked like bundle won.  I'll clarify with mramm on juju-dev right now.  since he was +1 anyway I'd be surprised if it were anything other than "bundle."
<hatch> :.(
<hatch> :'''''(
<hatch> :{{{{{{{{(
<jcastro> don't be sad, bundle is fine!
<hatch> *wahhhhhhh*
<hatch> lol
 * hatch sets up a google alert for stack vs bundle questions
<hatch> haha I'm horrible
<jcastro> oh hey guys, the juju-gui readme appears to need  updating
<jcastro> juju deploy cs:~juju-gui/precise/juju-gui
<jcastro> you want that to be from the store instead now right?
<gary_poster> yeah jcastro thanks
<gary_poster> btw I asked mramm in privmsg.  didn't feel like potentially stirring up hornets nest on dev when we are supposed to be settling on name. :-)
<hatch> haha
<gary_poster> jcastro, hatch, it is decreed: bundles.
<hatch> how unfortunate!
<gary_poster> on the bright side, we can move on. :-)
<gary_poster> I agree with your concerns and others
<hatch> :)
<gary_poster> but better to get back to getting this done
<jcastro> gary_poster: we need the readme for the gui fixed by Monday btw
<gary_poster> jcastro, ack, will do.
<luca> gary_poster: is the old_new interface available?
<luca> gary_poster: when someone downloads juju what interface do they see?
<hatch> oldnew
<gary_poster> luca, hatch is correct
<luca> this one: https://docs.google.com/a/canonical.com/file/d/0B7yNWRv_QU7WYzB4RU9EZTZVc0k/edit
<luca> hatch: gary_poster ^
<gary_poster> luca, more or less.  that has some never implemented bits like the new service icons
<luca> yeah
<luca> gary_poster: mark has a keynote tomorrow
<luca> gary_poster: and is asking for an image of Juju
<luca> gary_poster: Should I send him the dark grey one?
<gary_poster> luca, do you know what the conference is?
<gary_poster> luca, I would send him the old one (set a few services up on http://uistage.jujucharms.com/ , for instance) and the oldnew one (http://uistage.jujucharms.com:8086/).  I'd suggest that you recommend the old one for publicity because of the OSCON launch, but mention that the oldnew one is much more attractive even though it is transitional, so you were offering it as well if it were more appropriate for the audience.
<luca> gary_poster: I phoned Ale and she said the same thing so I'll sort out the images now
<gary_poster> cool luca
<hatch> gary_poster: last night bcsaller and I had a discussion about merging the controllers for the ghost/service view and using composition to plug in methods to allow for easier testing so that's why that branch hasn't landed yet and I have modified the cards on the board
<hatch> we actually had a rather long discussion but we were really arguing semantics in the end.....so it was a good discussion haha
<gary_poster> hatch, ok.  when's the new landing target? :-)
<hatch> EOD or sooner (depending how many reviews I have to do ;) )
<gary_poster> cool
<gary_poster> abentley, hi.  talking to sarah.  how far off was your departure date in the authorization?  days? months? years?
<abentley> gary_poster: 1 day.  Ticket ID: [Canonical Events #89]
<gary_poster> ack thanks
<gary_poster> abentley, answer is to proceed.
<abentley> gary_poster: Okay.
<gary_poster> thanks abentley 
<gary_poster> benji, thank you for landing dnd deploy.  cool. :-)  (1) did Makyo look at whether transferring x/y position was easy with you, or is that still an open question? I'd like to know what additional card to make, and how to schedule it. (2) when you drag from the token, you see the token as the drag marker.  when you drag from the full charm box (token + name + downloads) you see the full charm box as the drag marker, 
<gary_poster> but I think it would be nicer to still use the token.  Was this already discussed?  If so, and the question was based on UX rather than a technical issue, was Luca involved?
<Makyo> gary_poster, not yet, but I can check real quick.
<gary_poster> cool thanks Makyo 
<benji> gary_poster: (1) I was just typing up a question for Makyo; (2) It wasn't discussed.  I figured seeing the thing you dragged made sense so it didn't occur to me to do otherwise.
<gary_poster> benji, cool thanks. :-)  luca do you have time to have an opinion on #2?  Is it clear, or would you like at example?  You can play with this on http://uistage.jujucharms.com:8086/
<gary_poster> luca, to be clear, I'm fine with deferring to you on this.  I'm just raising the question.
<benji> note that for case (2) the thing being dragged is still the charm token, it is the case that the token just has more/different data in it
<gary_poster> benji, ack
<Makyo> benji, d3.mouse(this) will give you coordinates of the drop on the screen.  This doesn't take into account panning.  You'll have to either add two arguments or just retrieve arguments[1] (arguments[0] will be undefined) in order to get the service module.  From there you can get the current translation with var topo = module.get('component'), translate = topo.get('translate'), scale = topo.get('scale');
<luca> gary_poster: benji I can drag to canvas (thats sweet!) but it doesn't show me any token or anything? Should I be seeing anything at the moment?
<rick_h> luca: yea, looks like it shows and works in FF and not in chrome 
<gary_poster> luca, when you are dragging, you should see either a token or the full box
<Makyo> benji, I believe you'll have to multiply both items in the coordinate pair by scale (I'm doing this in my head; so I may be wrong)
<gary_poster> oh?
<gary_poster> wfm
<gary_poster> on chrome
<Makyo> Works for me.
<luca> oh weird
<benji> and it worked for me locally on chromium and firefox; looking at :8086 now
<luca> it works for me now too....
<benji> chromium is happy
<hatch> probably cache issue then
<benji> firefox is happy too
<gary_poster> wfm on chromium
<rick_h> on chrome (official) dev level here and it doesn't show. 
<luca> oh I see what the issue was
<luca> If I drag from the token on ceph it shows a broken image
<luca> same with mysql
<luca> and wordpress
<gary_poster> wfm on firefox but I only ever drag the box, never the token
<rick_h> gary_poster: yea, same here
<gary_poster> luca, don't know, can't dupe.  any messages in the console?
<gary_poster> rick_h, same for you--broken image?
<gary_poster> rick_h, you on os x?
<luca> if I drag from the token I get the full image, always
<rick_h> gary_poster: I'm on linux on chrome dev channel. It's not a broken image, but a document placeholder image. 
<luca> if I drag from the icon I get a broken image
<gary_poster> luca, what do you mean by token and icon?
<benji> I'm seeing something simiar in firefox.  *Some* of the tokens show when dragged from the image, some don't.  They all work either way though.
<luca> I'm happy to share screen with someone to validate
<rick_h> hangout-a-palooza!
<gary_poster> heh
<gary_poster> ok
<gary_poster> my network may be sucking.  can try guichat luca
<benji> correction, the behavior I am seeing is in chromium
<benji> I'll address this in my follow-on (ghost positioning) branch.
<jcsackett> jujugui: can i get a second review of https://codereview.appspot.com/10609043/ ?
<bac> jcsackett: sure
<jcsackett> bac: thanks.
<gary_poster> benji, rick_h could I have you guys in guichat for a sec?
<rick_h> gary_poster: sure thing
<gary_poster> thanks
<benji> gary_poster: sure
<gary_poster> thanks
<bac> done jcsackett
<jcsackett> thanks bac.
<hatch> ugh.....there is nothing more irritating than tracking down event errors
<teknico> hatch: tell me about it...
<rick_h> hatch: meh, it's what tracebacks are for :P
<teknico> anyone up for a second review of https://codereview.appspot.com/10605043 ?
<hatch> its like 'oh you want a traceback....ha, ha, hahahahaha'
<hatch> rick_h: that's the thing - event tracebacks don't go back past the handler :)
<rick_h> hatch: I guess depends on the event. I've gotten some
<hatch> in this case the traceback stops in YUI event land...
<hatch> the cleanest, easiest to follow code....ever
<hatch> :P
<Makyo> jujugui call in 10, Kanban now
<gary_poster> oh hatch!  you were suposed to run yesterday and I stepped on you!
<gary_poster> please remind me when it is your day and I will be quiet :-P
<hatch> haha it's ok you were on a roll and we were behind :D
<gary_poster> :-) thx
<hazmat> ls
<hazmat> oops
<hatch> hehe
<hatch> I use ll which is aliased to ls -al
<hatch> I prefer the layout :)
<teknico> you cannot be on a roll when you're on a rock, not enough space to dance ;-)
<teknico> not enough *room
<gary_poster> hey teknico you landed add/remove relation?  oh, still waiting on second review.  anyone agree to do it?
<frankban> gary_poster, teknico: I'll do it
<teknico> gary_poster: nope, just asked for it
<teknico> frankban: thanks
<gary_poster> thanks frankban 
<teknico> guihelp: you run make test-server, it says one failure, there are no failures on the page. what do you do? :-)
<hatch> look closer
<Makyo> teknico, hmm, maybe leave the console open with break-on-all-errors?
<frankban> teknico: maybe check the js console?
<teknico> how much closer? :-)
<hatch> thiiiiiiiiiiiis close
<hatch> but yeah, open the console, break on errors
<hatch> like Makyo said
<Makyo> jujugui call in 2
<teknico> Makyo: hatch, where's the command to do that?
<rick_h> gary_poster: finishing up the flight setup, info is in the spreadsheet
<gary_poster> awesome
<hatch> I'm not looking forward to merging this branch bcsaller hah
<hatch> how does insurance work with zipcars?
<hatch> can I as an international traveler get one?
<hatch> gary_poster: you might want to check your power setting on your wifi router - I used to have bad connections outside too, then I upped the power setting and it's much better
<gary_poster> bcsaller, fwiw, this is 1.1 miles away and I think it is awesome.  other options but this is my fave.  http://www.happycow.net/reviews.php?id=27049
<bcsaller> gary_poster: cool, thanks
<gary_poster> hatch, it appears to be that linux doesn't swicth from two routers providing the same network very well
<gary_poster> so if I start linux downstairs, it's not happy upstairs and vice versa
<gary_poster> os x is fine
<hatch> gary_poster: ahhh ok ok
<hatch> gary_poster: any idea of this hotel will have good wifi?
<gary_poster> hatch, has wifi, nobody complains <shrug> :-) http://www.tripadvisor.com/Hotel_Review-g49463-d3527157-Reviews-Hampton_Inn_Suites_Raleigh_Downtown-Raleigh_North_Carolina.html
<hatch> I suppose that's all one can hope for :)
<hatch> looks like a nice place
<bac> gary_poster: is there a better design resource i should be using than the wireframes we looked at?
<luca> bac: what do you want to see?
<gary_poster> bac, if new wireframes are not in the folder luca mentioned a few hours ago we can ask him
<hatch> unicorns......pick unicorns.......
<luca> rofl
<bac> gary_poster: i thought there was mention of 'visual design' documents vs wireframes.  (hi luca!)
<luca> bac: visuels, wireframes and assets can be found here: https://drive.google.com/a/canonical.com/?tab=co#folders/0B7XG_QBXNwY1V3B3dDNvYXJGRE0
<gary_poster> bac, see https://drive.google.com/a/canonical.com/?tab=co#folders/0B7XG_QBXNwY1V3B3dDNvYXJGRE0
<gary_poster> visuals in one folder
<bac> thanks
<gary_poster> wireframes in other
<bac> luca: i'm doing charm settings page.
<gary_poster> luca, I'm telling folks that we will need a scrollbar for the whole inspector too, despite images.  Agree?
<hatch> bcsaller: review done
<bcsaller> hatch: thanks
<luca> gary_poster: there is a scroll bar on this image: https://docs.google.com/a/canonical.com/file/d/0B7XG_QBXNwY1VnJrN0ppUHc0bk0/edit?usp=sharing
<teknico> everybody STAND BACK while I SHATTER the One Thousand Tests barrier!
<hatch> w0000000
<gary_poster> teknico, lol
<luca> gary_poster: the only bit that scrolls is unit area
<luca> gary_poster: and also the settings page
<gary_poster> luca whole thing will need to scroll
<gary_poster> arbitrary number of alerts
<gary_poster> or have you verified that the minimum pixel size to get everything in is OK?
<luca> yeah but we was wondering if for the post-rep inspector only the light grey area scrolled
<gary_poster> given, say, two Landscape alerts at top plus upgrade charm, and 4 or 5 alerts at bottom, which feels like a reasonable extreme
<luca> pretty much that, we talked it through and felt that since the scale units area is collapsable then it should give more than enough room to view units
<hatch> bcsaller: ohhhhhhh alright you can leave format in there :)
<hatch> Makyo: share a cab on the 14th?
<Makyo> hatch, Sure.
<gary_poster> luca, what's the pixel height of the inspector with, say, 5 units showing and, say, 8 alerts showing?
<hatch> benji: share a cab on the 20th?
<gary_poster> 5 units: I mean the unit scroll area is 5 units high
<benji> hatch: what time do you want to leave?
<hatch> I'm not sure how far the hotel is from the airport....but say...6:30?
<luca> gary_poster: the view we work to is a height of 768px, generally talking in that we should be able to fit enough information, the user has the option of minimising all of the Scale unit area so they can have more room if needed.
<gary_poster> hatch, 12 or 13 miles; 20-25 minutes
<benji> my flight takes off at 8:00 so that would cut it closer than I like.  I'd be fine leaving at 6:00 (assuming the airport is about 15 minutes away), but that may be too early for you.
<gary_poster> luca, but if it is not minimized and inspector is too big for height then what happens?  it simply goes beneath bottom of screen?
<luca> gary_poster: no, the bottom always sits 20px above the bottom
<gary_poster> luca, guichat?  maybe faster, and not making sense to me yet :-)
<luca> gary_poster: sure
<gary_poster> thx
<hatch> benji: 6 would be fine
<benji> cool
<hatch> bcsaller: the prototype on the ServiceInspector controller isn't ever used is it? getName, bind, render etc
<bcsaller> hatch: looking
<bcsaller> hatch: facade methods previous, don't recall taking them out of the control path though
<hatch> ok I don't see them ever being called - I'll look further
<gary_poster> jujugui fwiw I marked the scroll card as blocked.  luca is going to consider what behavior he wants.  Basically, for now continue as we said on the call: ignore the fact that the inspector gets too big.
<hatch> "wow that's one big building.......what building?"
<hatch> :)
<gary_poster> :-)
<hatch> bcsaller: yeah I was just overwriting some stuff that I shouldn't have been, almost ready to propose with the new changes
<bcsaller> hatch: great
<hatch> I THINK I like this better
<hatch> heh
<hatch> that's a lie...I do
<bcsaller> good :)
<hatch> proposing now....
 * hatch grabs some eggs to cook on computer while tests are running
<hatch> hmm it failed....
<hatch> trying again hoping it was just launchpad being wako
<hatch> bcsaller: https://codereview.appspot.com/10565043
<bcsaller> hatch: reviewing
<hatch> thanks - I still need to add comments and the like
<hatch> but I wanted to get this out there asap
<hatch> Makyo: with your new branch - I would have to double click the service icon to open the inspector?
<Makyo> hatch, single click works.
<hatch> hmm ok this will not work with the new single controller
<bcsaller> hatch: what won't?
<hatch> you need to pass a considerable amount of data into it...
<hatch> not just the db
<hatch> so possibly another layer of abstraction is needed
<Makyo> What won't work?
<hatch> showing the service inspector
<hatch> it needs to know at that point if it's a ghost or not, and then send the appropriate config to the new controller system
<Makyo> Why not?
<Makyo> Where's the difference, though?  It's the same code as the double click method.  All of that is available in both locations.
<hatch> yeah in trunk that's fine but not once this lands https://codereview.appspot.com/10565043
<hatch> not your fault - I'm just pointing that out...
<bcsaller> I'm being slow, I don't see the issue yet
<Makyo> There are already comments (your comments, I believe) to that effect.  Is that not just part of working incrementally?
<hatch> there isn't an issue in your branch
<hatch> but there will be an issue as soon as I land mine - which we'll have to possibly solve by an abstraction layer to not have to pass the complex configs around
<hatch> sorry I wasn't clear :)
<Makyo> Ah, okay
<jcastro> hey gary_poster 
<jcastro> I'm documenting the submission process
<jcastro> we noticed the export format is yaml instead of json?
<gary_poster> jcastro, on call but will follow when I can
<gary_poster> jcastro, yes, that's what deployer uses now
<jcastro> oh ok, we were just curious, thanks
<bcsaller> hatch: got a sec to chat?
<hatch> I do
<gary_poster> Makyo, hatch, I dunno what the story is about how you want to handle Makyo's branch, but as is it LGTM
<hatch> gary_poster: yeah I meant to actually LGTM it
<hatch> but forgot to hit send :/
<gary_poster> :-) ok, send it and he can land it
<gary_poster> how much more work for you hatch?
<hatch> it's done
<hatch> gary_poster: https://codereview.appspot.com/10565043 the final version
<hatch> I'm just merging trunk right now and dealing with the conflicts
<hatch> then I'll submit
<hatch> which are now resolved
<hatch> soooo I can submit it whenever
<gary_poster> awesome hatch :-) including Makyo's changes?
<gary_poster> 'cause IIUC his change would be tricky with yours
<hatch> it will break
<hatch> but the proper fix to that is a follow-up branch that ben and I chatted about a few minutes ago
<hatch> so maybe he shouldn't land that
<hatch> and we can implement that fix in the follow-up
<bac> gary_poster: can you see these diagrams?  i can only open one or two: https://drive.google.com/a/canonical.com/?tab=co#folders/0B7XG_QBXNwY1NEtGaHJYZGM4enM
<gary_poster> hatch ok.  please coordinate with Makyo?
<gary_poster> bac, yes I can see all of them
<bac> gah
<hatch> Makyo: don't land your branch :) "the lgtms are a lie"
<gary_poster> heh
<hatch> I thought someone might get that joke :)
<bac> i get a google frownie
<bcsaller> cake :)
<Makyo> You are so lucky lbox submit failed.
<hatch> lol
<gary_poster> :-)
<hatch> bac: they work here too
<hatch> bcsaller: yup :D
<bac> well la-tee-da
<bac> maybe one of you could fax them to me
<hatch> lol
<hatch> ok I'm submitting my branch now
<bac> oh, and now they work...  thanks goog
<hatch> the mocks on that link are pretty cool
<hatch> I'm going to grab some lunch bbiab
<sinzui> Which juju-gui charm do we want to use to deploy to production? ~juju-gui or ~juju-gui-charmers. The later is older, but you might see it as stable to the former development charm?
<sinzui> gary_poster, bcsaller ^
<bac> ~juju-gui-charmers is the released version.
<bac> sinzui: ^
<bac> ~juju-gui is devel
<sinzui> fab. Thanks bac. are there plans to update the stable charm this week?
<bac> that i don't know
<gary_poster> sinzui, yes, simply to update the README at least
<bac> i mean, yes
<gary_poster> :-)
<gary_poster> bcsaller, branch LGTM
<sinzui> gary_poster, because it talks about the dev charm? :)
<gary_poster> sinzui, yes :-)
<sinzui> gary_poster, I want to tag stable so it is clear what I want in production. I will do an update to the charm and submit it for review.
<gary_poster> sinzui, perfect thanks.  Will that include a drive-by README fix?  Would be lovely, but not necessary
<sinzui> understood
<hatch> bcsaller: lgtm'd let er rip!
<hatch> after gary's changes of course :)
<BradCrittenden> hatch: you have a minute for a chat?
<hatch> I do
<bac> cool
<hatch> guichat
<hatch> bcsaller:  have a second to join our chat?
<gary_poster> Makyo, I'd like to get the remove service branch landed.  I know that means reconciling with hatch's landed changes.  are you already focused on that, rather than the unit count controls?
<Makyo> gary_poster, yes.
<gary_poster> yay thanks Makyo 
<Makyo> gary_poster, mostly works, but quick question for you and hatch 
<gary_poster> cool
<hatch> ahhhhh
<hatch> there are going to be soo many conflicts haha
<gary_poster> well, his branch wasn't *that* big :-)
<Makyo> There weren't any, just updating the showMenu code.
<gary_poster> cool
<Makyo> Actually, give me a second to check on this behavior w/o the inspector flag.
<gary_poster> k
<hatch> Makyo: ok you will need to pass in the config which is in views/topology/service.js:1353:1359
<hatch> but that's only for the service view, the ghost one is more complex
<Makyo> hatch, I promise you that it is exactly the same code as double click.  Pinky swear.
<gary_poster> lol
<hatch> it can't be
<hatch> dbl click calls show_service
<hatch> you're in showServiceMenu
<Makyo> hatch, yes.  And if the serviceInspector flag is set, I'm doing exactly the same work.
<Makyo> In fact, I could make the branch a one-liner and just call show-service.
<hatch> yes - do that
<hatch> your code will _not_ work with the new controller
<Makyo> hatch, It dooooes I promise D:
<hatch> see the new code in show_service
<hatch> it cant lol
 * gary_poster sighs
<Makyo> hatch, the code in showServiceMenu is LITERALLY copied directly from showService.
<gary_poster> hey hatch, why dontcha wait on his branch
<gary_poster> :-)
<hatch> Makyo: yes....the OLD show_service
<hatch> haha
<gary_poster> or have a guichat?
<gary_poster> but this is low on productivity :-)
<Makyo> Very, very low.
<hatch> ok ok land it
<Makyo> I'll put show service in there and re-propose.
<bac> hatch: quick chat again?
<gary_poster> hatch, there's also a review process :-P
<hatch> bac: there
<hatch> I'm not saying there is anything wrong with your code Makyo - but once you merge it in, it will fail
<hatch> :)
<Makyo> hatch, part of merging is resolving conflicts.  I merged, I resolved the conflicts, it works.
<Makyo> I just want to be belieeeved.  But show-service works too, and has less code dup in the end, so I'll just do that, yeah?
<gary_poster> Makyo, propose it. :-) let's give it a whirl
<hatch> lol
<hatch> Makyo: perfect :)
<Makyo> We good? :)
<hatch> oh we goooooood
<Makyo> Gonna land, then, so I can count units.
<hatch> :)
<hatch> thanks
<hatch> ok I'm not entirely sure what to do next here
<hatch> ahh the switching of the inspectors
<hatch> bcsaller: near landing that event detach code?
<bcsaller> hatch: the first submit hit a conflict, doing it now for real
<hatch> gary_poster: re 1194866 - the error message was just a canned message - Makyo brought up in a review that the new code should pass the real message through
<hatch> bug 1194866
<_mup_> Bug #1194866: Cannot deploy http://jujucharms.com/~marcoceppi/precise/discourse from GUI <juju-gui:Triaged> <https://launchpad.net/bugs/1194866>
<hatch> so just fyi at least the error messages will be better soon
<gary_poster> hatch, ah cool
<hatch> bcsaller: ahh cool - I just wanted it for this next branch
<hatch> oh fyi the latest firefox (22) runs our tests about 6% faster on average heh
<hatch> it's still about 14% slower than chrome though
<bcsaller> hatch: branch landed
<hatch> these are my totally unscientific tests :)
<hatch> thank yaz
<hatch> man we are iterating fast on this codebase haha
<gary_poster> yay us!
<hatch> I'm really glad this isn't svn haha
<hatch> on*
<gary_poster> :-)
<hatch> gary_poster: I 'add' a service then click 'cancel' in the ghost inspector, does the ghost dissapear? What if I click the 'x' ?
<gary_poster> hatch, lemme get wireframes open 1 sec
<hatch> I guess the wireframe doesn't have a cancle
<hatch> cancel
<hatch> just a save...
<hatch> which I guess would keep the ghost there
<gary_poster> hatch on wireframe...uh-oh
<hatch> I think my wireframe version is a little old
<gary_poster> hatch on wireframe, we used to have a trashcan
<gary_poster> this *used* to be the answer:
<gary_poster> save and "X" are equivalent
<gary_poster> click the trashcan to delete it
<hatch> that makes sense
<gary_poster> trashcan I think is supposed to be all the way through, not just on Settings inspector panel
<hatch> do you have a link for the latest wireframe?
<hatch> mine is v1 it says
<gary_poster> hatch look in email from luca...or short answer is https://drive.google.com/a/canonical.com/?tab=co#folders/0B7XG_QBXNwY1V3B3dDNvYXJGRE0 :-)
<hatch> oh I don't think I got that email
<hatch> i've never seen this page before :)
 * hatch wants to * folders
<gary_poster> oh goodness, that wasn't sent peeps
<hatch> hehe woops
<gary_poster> forwarded
<gary_poster> anyway hatch, the trashcan disappeared
<hatch> alright I'll pretend there is one there
<gary_poster> hatch, +1 thanks.  I'll ask luca
<hatch> bcsaller: would you be ok with putting the 'factory' in environment.js along with the get/setInspector methods
<bcsaller> hatch:  I can get back to you in a few minutes
<hatch> no prob
<bcsaller> I like being able to leave multiple panels open with the simulator running and watching the units come and go. 
<huwshimi> Morning
<hatch> bcsaller: some light watching the sunset....you're weird
<hatch> :P
<hatch> lol I actually enjoy watching the simulator too haha
<bcsaller> it shows how far we've come with the update model
<hatch> yeah the dispatch issue is allllllmost gone :)
<hatch> bcsaller:  should this.get('db').charms.getById(model.get('charm')) work where the charm attribute is precise/ceph-11
<hatch> it returns null
<hatch> which isn't possible as far as I can tell because it's already been loaded
<bcsaller> not cs:precise/ceph-11?
<bcsaller> no, that looks right
<hatch> yeah actually the charms modellist is empty...
<bcsaller> I was just about to ask that 
<bcsaller> app.db.charms.map(function(m) {return m.getAttrs();}) should have looked sane
<hatch> so we have a bigger issue here then
<hatch> that service shouldn't hit the env without a charm in the db
<rick_h> hatch: is this the drag/drop stuff?
<bcsaller> it previously jumped through hoops to get the charm loaded, sounds like its not anymore 
 * rick_h is just joining into irc after a while away
<hatch> rick_h: nope using 'add'
<rick_h> hatch: k, so that should pass a ready model instance into the deploy command
<hatch> ahh ok we never add that into the db
<rick_h> hatch: we create a full model from the object we pulled form the Browser api
<hatch> rick_h: do you pull down the full charm data all the time or only when I click add ?
<rick_h> hatch: so when you hit add, we've already gotten all of the charm data from the browser code. in subapp/browser/views/charm.js there's the _addCharmEnvironment that's walking that through
<rick_h> there's no point pulling data from the old api, we just convert an instance of BrowserCharm to Charm and send it along. 
<hatch> *sigh* umm ok
<hatch> I knew this would bite us eventually haha
<rick_h> hatch: so this.charmPanel.deploy is the method that's called with the model instance
<hatch> right right
<rick_h> where this is the main App
<rick_h> `this`
<hatch> that data should be pushed into the db
<hatch> then on subsiquent requests we don't need to query the api
<hatch> and also have it available when we need it hehe
<hatch> I'm not blaming or anything just outlining what should probably be done moving forward
<hatch> holy it's past 5 already
<hatch> rick_h: is what I mentioned possible?
<hatch> possible with minimal work that is :)
<rick_h> hatch: sorry, at a coffee shop and in/out network
<rick_h> hatch: so yea, it's probably possible. benji did the initial add functionality and we can get the model into the db just fine. 
<rick_h> hatch: I'd suggest the charmPanel.deploy method do that when it get a s model
<hatch> that's what I was thinking
<hatch> rick_h: I remember us talking about needing to use a single charm model down the road
<hatch> I think we are down the road :D
<rick_h> hatch: yea, ideally we'd ditch the old Charm model and just use BrowserCharm 
<rick_h> hatch: I've got a card I want to do to audit all the calls to the old api and deprecate/get rid of them
<rick_h> once that's done the model switch should be easy
<bcsaller> hatch, rick_h : I haven't thought through all the implications of what your saying but remember wrt charm loading that the GUI isn't the only source of these, the delta can bring in new services that may have charms not even in the store, so the existing code paths maybe still needed
<rick_h> bcsaller: definitely, but ideally we could shim them into a BrowserCharm instance and get to combine them bit by bit
<rick_h> bcsaller: but yea, I've not chased it all the way through. However we had the vision of loading environment charms into the browser as well so we need to get to one 'model' for it
<rick_h> it's just not been priority since we pulled it from the 13.04 browser goals. 
<bcsaller> I'm fine with the idea that the browser is the source of truth for charms in the client.
<rick_h> bcsaller: right, the API from manage.jujucharms.com needs to be the single point of data for things vs the old jujucharm/search/json and search. 
<hatch> my issue is that if you close the inspector for a ghost and need to create a new one, the charm data no longer exists anywhere
<hatch> so pushing it into the db will help that case
<hatch> the case where it won't help however is when we open the page
<rick_h> hatch: can we sit down and chat tomorrow about it?
<hatch> yeah it's past my EOD anyway I suppose heh
<rick_h> hatch: ok. Let's try to at least build a checklist of stuff to make sure we sanity check/run through and go from there. 
<rick_h> build a todo list for getting it 100% straightened out
<hatch> good idea
<hatch> I don't really like how this is working anyways
<rick_h> hah
<hatch> the code I'm writing
<hatch> I mean
<hatch> didn't we talk about having fully populated service with charms at all times?
<hatch> so if you loaded up an environment with X services on it, the service and charm models would be ready to go
<hatch> did that go away with deploying from the charmstore?
<hatch> s/charmstore/browser
<rick_h> hatch: so the charms are always fully loaded. When you browse, we have all the charm data so that we can pass it to the env or config panels or anything without making a new http request. 
<rick_h> hatch: we keep a cache in the browser subapp, but we might need ot hook some of that up to the db or other place in the env. I'm not sure tbh
<rick_h> I've not looked through all the other uses of the base charm model. 
<hatch> I mean if I load up an environment with a set of services already
<hatch> those should be populated with charms no?
<hatch> or did we decide to leave them as shells
<rick_h> yes, but using the old apis and whatever the juju environment feeds out of the websocket connection
<rick_h> e.g. that's not changed at all
<hatch> right ok - so in theory we could change the browser cache to use the charm db
<rick_h> but anyway, it's 7:30pm and I'm trying to hold multiple conversatoins at hte coffee shop. Can walk through this tomorrow. :)
<hatch> haha yeah sure np
<hatch> have a good night
<rick_h> you too
#juju-gui 2013-06-27
<gary_poster> hey luca.  I suddenly have 20 minutes free. :-) I have a few follow-up questions about your reply (whicvh I really appreciate).  Do you have a moment, or are you lunching?
<luca> sure, guicaht?
<luca> guichat^
<gary_poster> luca thanks yes
<gary_poster> sorry didn't see
<rick_h> luca: got a sec?
<frankban> guihelp: I need to retrieve the env object from within a viewlet. Is there a way for viewlets to access their own viewContainer?
<rick_h> frankban: shouldn't the view container give the viewlet anything it needs? Pass down cfg or helpers?
<bac> frankban: i need to do the same thing and have modified the call to render to accept it.  hold on and i'll paste my changes
<bac> frankban: http://paste.ubuntu.com/5804591/
<rick_h> bac: why not just pass in the db? Seems like this connects the two classes a lot now for testing and such?
<frankban> bac: very nice, thank you
<frankban> rick_h: how to retrieve, e.g., the env from the db then? However, perhaps we could just pass ViewContainer.options?
<rick_h> frankban: yea, I was seeing that. This is added to the root class vs a class that's later inheriting I guess. 
<rick_h> frankban: I like the idea of an optional cfg second param instead 
<rick_h> render(model, options)
<bac> frankban: but i'm passing the viewcontainer.  can't you get options and env from it?
<frankban> sounds good, also extended to the other viewlet methods I guess. what is options? viewContainer.options?
<frankban> rick_h: ^^^
<bac> frankban: yeah
<rick_h> bac: render(model, {db: ciewContainer.get('db')})
<bac> rick_h: sorry i didn't see your comment
<rick_h> frankban: options is just a arg name. 
<rick_h> frankban: call it cfg, foobar, whatever. Basically a space for passing in any optional data?
<rick_h> frankban: I guess I'm just looking at this diff and not the big picture of how it's working. So ignore me if it doesn't apply I guess. 
<bac> rick_h: bcsaller, hatch and i discussed this yesterday and thought it may need to be broader, but i see your point
<rick_h> I just get twitchy when I see something getting the full instance of something else as those two classes are now tied at the hip vs something more generic
<frankban> rick_h: AFAICT this is a framework, our render is called for us, so I guess we must decide what to pass as second arg
<rick_h> frankban: right, then nvm I guess. I've not used it yet so was looking at things like a Y.View calling another Y.View where it has control over how render is called
<rick_h> frankban: is the init custom then?
<rick_h> frankban: e.g. could the viewlet be given optional init config and then it's already there for this.render()?
<frankban> rick_h: you can pass options to the viewContainer initializer (an Y.View). a viewlet is more a configuration object, with hooks/methods called by the viewContainer. It seems nice to me if the viewlet can receive (or store, as you suggested) those option values. I am also fine with Brad;s solution of passing the whole viewContainer, even if I guess we will be mostly interested in its options
<luca> rick_h: I'm in a meeting now for an hour but can we catch-up after?
<rick_h> luca: sent an email on your way. Feel free to reply to that or we can chat after your meeting. 
<luca> rick_h: ah brilliant, cheers :)
<frankban> BradCrittenden, rick_h:  what I described: http://pastebin.ubuntu.com/5804671/
<rick_h> frankban: cool. I like that way it's limited to bits of data vs the whole class and the temtation to try to share methods/etc across. Seems less 'dirty'. 
<BradCrittenden> frankban: looks good
<teknico> anyone up for a second review of https://codereview.appspot.com/10677043/ ?
<gary_poster> teknico, any takers?  if not, please invoke j u j u g u i :-)
<gary_poster> luca, I don't understand this line from inspector behavior:
<gary_poster> "You can scroll the inspector but the scroll goes underneath the dark grey divider line"
<teknico> gary_poster: nope, proceeding with deployment of Secret Weapon
<gary_poster> cool teknico :-)
<gary_poster> luca, and that line seems key :-)
 * gary_poster goes to another call, but more explanation would be great
<BradCrittenden> gary_poster: we up?
<bac> brb
<gary_poster> we are bac
<gary_poster> cool
<teknico> `juju deploy jujugui`: anyone up for a second review of https://codereview.appspot.com/10677043/ ?
<gary_poster> heh
<benji> teknico: hi, I'll take it
<bac> gary_poster: am i in the wrong place?
<teknico> benji: I mean, thank you ;-)
<teknico> whoops
<gary_poster> bac, maybe.  1c5347001459ec985658a81e5c3a019abc715e05 ?
<gary_poster> bac from calendar
<bac> no, did it change with the new calendar invite?
<teknico> benji: thank you
<benji> rick_h: have a minute for some browser wierdness discussion?
<rick_h> benji: sec, finishing up standup
<benji> l
<benji> k
<benji> now everyone knows I'm using a QWERTY keyboard
<rick_h> doh!
<gary_poster> bac, you still here?
<teknico> is anyone able to "make code-doc" successfully in trunk?
<rick_h> teknico: nope
<rick_h> benji: free now, guichat?
<benji> rick_h: I figured it out. Your contribution will be noted for posterity.
<rick_h> woot! I love being awesomely helpful by not attending!
<rick_h> I guess 'by absence' would fit better
<gary_poster> rick_h, hatch, either of you have idea on what to grep for for that yuidoc failure (http://pastebin.ubuntu.com/5804801/)
<gary_poster> ?
<rick_h> gary_poster: looking
<gary_poster> thx
<hatch> gary_poster: try subapp
<hatch> er
<hatch> subclass
<hatch> just thinking
<gary_poster> hatch you mean grep for subclass?
<hatch> yeah sorry
<hatch> it's possible that the class isn't defined if ther is a subclass of juju.something
<hatch> brb
<hatch> gary_poster: any luck?
<gary_poster> hatch, if you comment this out then yuidoc stops complaining
<gary_poster> http://pastebin.ubuntu.com/5804847/
<gary_poster> but
<gary_poster> then there is nothing in the yuidoc directory (if you move any old ones aside first)
<hatch> yeah that's definitely not right
<hatch> umm can you bisect to find the failure
<hatch> er...
<hatch> check out the last revno
<gary_poster> I can't--more mtgs--but maybe teknico? :-)
<rick_h> I'm looking at where the error is thrown in node_modules/yuidocjs/lib/docparser.js and it makes no sense :/
<rick_h> console.log(modules) [get a nice fancy list] console.log error'ing module [it's not in the previous list...]
<rick_h> for some reason it's trying to find a 'juju' module but there isn't a 'juju' module file. 
<teknico> hatch: when can we have a one-on-one about viewlet/databinding?
<hatch> nevvvaaaa
<teknico> nice :-)
<hatch> ok but really pretty soon
<hatch> just waiting for the morning rush to slow down around here :)
<teknico> rick_h: the first doc comment gary_post3r pointed out, in apps/subapps/browser/browser.js , says "@module juju"
<hatch> bac: are you able to make a branch and commit with that view-container update? I can if you arent' able to
<bac> hatch: frankban has come up with an alternative that looks better
<hatch> oh? I thought that was pretty clean :) what's the alternative?
<bac> http://pastebin.ubuntu.com/5804671/
<bac> i haven't integrated his change yet
<rick_h> teknico: gotcha. Yea, guess there's not really a juju module to be a part of. Ends up just a namespace. 
<rick_h> teknico: do the docs go anywhere? 
<rick_h> I must be blind today
<hatch> bac: frankban hmm I don't really like that as much because then you don't have access to the viewlet for anything
<teknico> rick_h: they should go in the top level yuidoc/ dir
<teknico> rick_h: but it does not get created anymore
<abentley> sinzui: Can we do a mid-imp review of https://code.launchpad.net/~abentley/charmworld/config-storage/+merge/171801 ?
<rick_h> teknico: so I changed it to https://pastebin.canonical.com/93510/ and no error
<rick_h> teknico: but no docs
<rick_h> hatch: other way around? 
<rick_h> hatch: isn't this the viewlet getting access to the viewContainer?
<bac> hatch: it gives what we need with less coupling.
<hatch> yeah.....ok you're right I read this wrong
<hatch> the context will still be the viewlet
 * hatch goes to grab his coffee
<teknico> rick_h: yeah, something else is amiss
<luca> gary_poster: the divider line is the dark grey line under the "upgrade" available notification.
<hatch> http://gizmodo.com/how-a-fridge-full-of-beer-that-only-unlocks-for-candian-596858353
<hatch> rofl
<hatch> teknico: ok want to chat now?
<hatch> I have another call in 15 but we can probably get it done in time
<teknico> hatch: yes please
<hatch> guichat is open
<adeuring> sinzui, abentley, jcsackett, rick_h could one of you review these two small MPs: https://code.launchpad.net/~adeuring/charmworld/1192559-forgotten-jenkins-results/+merge/171825 https://code.launchpad.net/~adeuring/charmworld/1192544-dont-hide-charms-with-processing-errors/+merge/171756
<abentley> adeuring: looking.
<adeuring> thanks
<abentley> adeuring: could FailingStoreProviderResults be a function?
<abentley> adeuring: You're replacing a function, so that seems intuitive to me.
<adeuring> abentley: no, when you pass a function to patch.object(), it is called during the call of patch.object()
<abentley> adeuring: Not in my experience.
<adeuring> abentley: well, I tried it...
<abentley> adeuring: See test_store.py for some examples.
 * adeuring is looking
<gary_poster> bcsaller, when you are here, could you take bug 1195354?  made card in miscellaneous
<_mup_> Bug #1195354: Export exports relations incorrectly <juju-gui:Triaged by bcsaller> <https://launchpad.net/bugs/1195354>
<gary_poster> teknico, is "Broken tests for pyJuju sandbox" landed yet
<teknico> gary_poster: it is, just yet
<teknico> moved the card
<adeuring> abentley: got it. I misunderstood the parameter "new"
<bcsaller> gary_poster: kapil's email said  relations:                                                                                                                                                                                                                                                                    
<bcsaller>         - [blog, [db, memcached]]           
<bcsaller> one line change either way I think
<abentley> adeuring: The changes you've made to the tests in 1192544-dont-hide-charms-with-processing-errors look wrong to me.  You should be testing that charms with errors are not hidden, not changing them to refer to store errors.  I believe the store error stuff already has tests.
<gary_poster> bcsaller, xchat might have eaten what you said, I am afraid, but I think you are saying that this will be easy :-) .  Maybe also that you need to clarify something with Kapil?
<bcsaller> both those things. My orig email suggested what the bug says but he offered back that its a list rather than ':' delimited
<adeuring> abentley: OK, having tests that charms with errors are shown make seinse. But I could not find tests for the store_error case. Maybe I missed them though...
<bcsaller> I can do either though, like I said, one line change :)
<abentley> adeuring: in search.py: test_api_search_charm_with_store_error, test_search_charm_with_store_error.  In models.py, test_find_charms_default
<gary_poster> hey hazmat, could you connect with bcsaller on list vs bug above?
<adeuring> abentley: ok, so I'll just change the originals tests that charms with processing errors are not hidden.
<abentley> adeuring: +1
<bac> gary_poster: canonicaladmin for you
<abentley> adeuring: r=me on 1192559-forgotten-jenkins-results
<adeuring> abentley: thanks
<gary_poster> sinzui, am I right that manage.jujucharms.com will integrate with SSO?
<rick_h> gary_poster: it does already. The login function should work for anything in ~charmers
<gary_poster> sinzui, and are there any others on the charm side of the world that you know of?
<gary_poster> rick_h, when I click on login, I get a 503 Service Unavailable
<gary_poster> No server is available to handle this request.
<rick_h> gary_poster: hmmm wfm
<gary_poster> rick_h, ok worked that time
<rick_h> gary_poster: looks like new SSO layout/etc
<gary_poster> yeah
<sinzui> gary_poster, I am logged in
<gary_poster> bac, accepted :-)
<bac> gary_poster: oh, and another.  my sick day from a while bak
<bac> back
<sinzui> gary_poster, I just logged in
<sinzui> gary_poster, I think the bug here is that we did not test what someone who has not role to login sees
<gary_poster> sinzui, ack works for me now as I said.  could you please add manage.jujucharms.com to bug 1184961
<gary_poster> so it gets an icon
<gary_poster> doe SSO
<gary_poster> for
<sinzui> gary_poster, ~charmers and the m.jc.com developers can loggin
<sinzui> gary_poster, logging in lets you do charm QA.
<gary_poster> sinzui, ack cool thanks.  my main point is that icon bug.  could you add yourself to the bug?
<gary_poster> I mean, mj.c
<luca> rick_h: free to talk?
<rick_h> luca: sure thing
<rick_h> luca: taking over guichat
<sinzui> gary_poster, yellow/ui group appear to be the only staff that are NOT in https://launchpad.net/~juju-jitsu/+members
<gary_poster> sinzui, lol
<gary_poster> sinzui, you saw the icon bug request, right? :-D
<sinzui> gary_poster, I think your people would be helped by membership...and I will look into what happens when you are not permitted to sign in
<hazmat> bcsaller, re emai. those are separate services..         - [blog, [db, memcached]]    is two relations in one line.. no qualifiers.. qualifiers are done as 'service:rel_name' 
<sinzui> gary_poster, No I didn't see it
<sinzui> number?
<bcsaller> hazmat: ah, must have misunderstood, thanks
<gary_poster> sinzui, bug 1184961
<sinzui> thank you. I will look into this.
<gary_poster> thanks sinzui
<sinzui> ha ha, the deploy was so fast it happened as I was testing login/logout
<sinzui> abentley, your login/logout link staste bug still exists and somewhat confusing when a deploy happens
<adeuring> abentley: i updated the branch
<abentley> adeuring: r=me then.
<adeuring> abentley: thanks
<abentley> adeuring: I had already approved it, conditional on fixing the tests.
<abentley> sinzui: That's weird.  I couldn't reproduce it.
<sinzui> abentley, It happened during the rollout. It was fast. I cannot make it happen now
<abentley> sinzui: Can we do a mid-imp review of https://code.launchpad.net/~abentley/charmworld/config-storage/+merge/171801 ?
<sinzui> oh, and it just did... abentley. I just logged out. I had to force reload to see login again
 * sinzui reads
<teknico> gary_poster: jenkins failed but it seems unrelated to my branch, can we retry?
<gary_poster> teknico I will retry if you look at video and see if you learn anything, and maybe doc in fole. :-)
<gary_poster> file
<teknico> gary_poster: oh, the video, I keep forgetting that. what do you mean by "doc in file"?
<teknico> I guess "document in a file anything I learn"
<gary_poster> teknico, I was thinking like your FIXMEs
<gary_poster> Makyo, coming to meeting sorry
<hatch> rick_h: got a minute for a chat?
<rick_h> hatch: rgr
<hatch> in guichat
<rick_h> hatch: trying
<Makyo> jujugui call in 10 kanban now
<abentley> sinzui: how's that review going?
<sinzui> abentley, In the last in your branch (# This is not acceptable to Elasticsearch, because config is a list.) you demonstrate that 'e' was not found. I think it was deleted by the exception block. Should it be? If the config options is already in the right format, I would have indexed it after a no-op
<sinzui> Oh
<sinzui> it was options that was a list
<sinzui> abentley, we have configs that that a list?
<sinzui> do we also have configs that are a string?
<frankban> hatch: do you have a minute for a chat after the call?
<jcsackett> sinzui: can i grab you to chat right after the juju gui standup? probably 15 min?
<sinzui> jcsackett, yes
<jcsackett> cool, thanks.
<teknico> gary_poster: the underlying problem with the Jenkins failure is a timeout with "Charm API server did not respond", so maybe a network hiccup
<sinzui> abentley, I think my questions are moot. We don't support config being anything other than a dict with a single item of 'options': {}. Anything else is ignored now. your branch continues to ignore it, but we also get an exception in ingest to document the charm is bad
<gary_poster> teknico, ah ok.  I think they had a deployment
<gary_poster> jujugui sorry got lost in irc and mail.  coming
<abentley> sinzui: I forget what the precise mapping issue I ran into yesterday was.  But we had something that is supposed to be a map in our format, and instead it was a list.
<abentley> sinzui: This originally just aborted the migration, which is unacceptable.  So I handled it by swallowing the exception.
<abentley> sinzui: But since this is a migration, any existing document would be in the old format.  So we should not retain it.  We should delete it.
<sinzui> abentley, understood and agreed. We let users craft the yaml by hand. I suppose proof should/does callout this issue
<abentley> sinzui: Right.
<sinzui> abentley, the migration script does a print. Shouldn't it be a log because for webops to investigate.
<sinzui> or maybe you expect webops to check the juju-log
<abentley> sinzui: I don't think that migrate has logging enabled.  I should check that.
<abentley> sinzui: yeah, no references to 'log' at all.
<sinzui> abentley, I think all stdout is captured by the juju-log. I think I saw the issue in the log when we had migration 007 bow up
<sinzui> blow up
<abentley> sinzui: Right.  I meant that I don't think the migrate script has python logging enabled.
<sinzui> okay. I follow. That is a nice to have. I think your branch is in a good state. and +1 for documenting what a DISTRO_CHARM_DATA looks like
 * sinzui thinks bzr_branch leaked through, but is nice ti see as an addition
<abentley> sinzui: Cool.  Yes, DISTRO_CHARM_DATA allows me to justify the changes to the old JSON API.
<abentley> sinzui: Okay, can we talk about how we would re-implement migration?
<sinzui> yeah
<hatch> frankban: i'll be right back then we can chat
<frankban> hatch: thanks
<bac> thanks hatch.  i had not merged from trunk and didn't have ghost-inspector yet
<bac> to look at event handling
<jcsackett> sinzui: want to join me in tinyurl.com/guichat?
<sinzui> jcsackett, in a few  minutes, I am in another hangout
<jcsackett> ok.
<hatch> bac: you'll also want to create your own object similar to the one on line 126 of ghost-inspector.js and then include it into the controller
<hatch> you do that by adding it to the array on views/service.js:1176
<hatch> I can outline in more detail if needed
<hatch> frankban: guichat?
<frankban> hatch: sure
<jcsackett> sinzui: when you're free ping me and i'll send an invite; guichat was needed. :-)
<bac> hatch: i'm working on the service inspector so i think your point about adding to the array is not right
<bac>  s/right/required
<hatch> bcsaller: are you around?
<hatch> can you join guichat with frankban and I
<bcsaller> yes
<jcsackett> sinzui: i've got to run out. i'll ping you when i'm back, see if you're free then.
<sinzui> okay. sorry jcsackett
<rick_h> sinzui: ping, got a sec to chat?
<rick_h> sinzui: jcsackett can I get reviews on this short branch please? https://codereview.appspot.com/10691043/
<bcsaller> hatch: that did fix it :-/
<frankban> bcsaller: how to add that formatting function for each value in constraints? I'd like to use that to convert undefined to an empty string
<bcsaller> frankban: did you try using constraints as the name, I'm not sure that would work but maybe I can make that happen
<bcsaller> because you're right, we don't want to have to repeat that everywhere and we don't always know all the key names in the code anyway
<benji> rick_h: I have a charm-token-related question for you when you have a minute
<frankban> bcsaller: it does not work with just 'constraints', yeah it would be a nice functionality
<abentley> sinzui: Notes on our chat: https://docs.google.com/a/canonical.com/document/d/1hYCZWzTdtyv9IfZ1wdx82COrYSMwRRfeIRkVTfNMQvw/edit
<bcsaller> frankban: ok, I'll look at hacking something up. 
<frankban> bcsaller: great
<jcsackett> sinzui: i am back, are you free?
<rick_h> benji: hey, sorry I missed your ping
<rick_h> benji: what's up?
<hatch> bcsaller: darn....oh well those things happen :)
<rick_h> jcsackett: hatch can you guys peek at this short one please? https://codereview.appspot.com/10694043 fixes a bug that annoys hatch so I can earn brownie points to disagree with something else later on :P
<bcsaller> hatch: adding support for hierarchical  bindings to deal with nested key paths. So methods on 'constraints' will be used for 'constraints.foo' if that doesn't define the method in question.
<benji> rick_h: I want to talk about svg icons and .small .medium and .large 
<benji> guichat?
<rick_h> benji: sure thing
<hatch> bcsaller: I'm not sure what you're saying
<bcsaller> hatch: I can explain it in chat or show you in a bit in code
<hatch> ok ummm i'll make a hangout
<hatch> calling
<hatch> not sure if I picked the right account :)
<gary_poster> rick_h, LGTM
<rick_h> gary_poster: ty much
<rick_h> jcsackett: thanks as well. You caught me trying ot make sure each test failed/passed lol
<rick_h> I need to do better at that
<hatch> oh man there is a lot of drama around X and MIR
<rick_h> hatch: welcome to canonical
<hatch> why are people so resistant to change haha
<jcastro> ok fellas
<hatch> "RAWR don't event attempt improve my linux RAWR"
<jcastro> so the drag and drop is pretty much awesome
<hatch> (thats'a how I read these comment threads)
<rick_h> jcastro: benji is working on some browser tweaks and such to it now
<jcastro> nod
<sinzui> hatch. All developers believe it is fine for themselves to introduce change, but distrust anyone else proposing a change that might topple their changes
<hatch> jcastro: yes that is awesome :)
<rick_h> jcastro: so send beer his way and hold off if something's not quite right yet
<jcastro> I was like "ok if this doesn't land it's no big deal"
<jcastro> now after using it it's like, why would I ever click the add button ever?
<hatch> sinzui: lol
<hatch> these developers need to work on a webapp haha
<sinzui> hatch, indeed.
<rick_h> howdy sinzui can you peek at https://codereview.appspot.com/10691043/ real quick and I wanted to see if you had time to chat on priority/next
 * sinzui looks
<sinzui> I do have chat time. I am all talk and no action
<rick_h> woot
<sinzui> 17px? are you mad. Why choose a prime number of a dimension (other than 2)
<rick_h> it's what the ratio worked out to be going off the other images. 16.8px actually
<rick_h> .35 * charm icon size ish
<sinzui> 17 px is a poor input when scaling images designed for 64/128/256
 * sinzui looks for crack pipes
<rick_h> .35 * 48px
<rick_h> the large one is 57px :P
<rick_h> and that came from UX 
<benji> rick_h: it seems that after('render') is indeed called after render() is called, but not after it is really, really rendered by the browser.
<bac> "17px? are you mad"  ha!
<rick_h> benji: oh shoot me 
<benji> however, if instead of after('render', myFunc) I use setTimeout(myFunc, 1000) it works
<benji> :/
<sinzui> rick_h, LGTM.
<sinzui> rick_h, my daughter only sets the volume of the TV to increments of 5. She sites a study that 57% of the population are bothered by displays that accept odd numbers. I now set the TV to prime numbers only. I like to watch her twitch.
<hatch> prime numbers only....so the tv is either very loud or very quiet? haha
<rick_h> benji: ah ffs, it's a race since the actual rendering is done off the same event. 
<rick_h> hatch: go smack someone on YUI around for the widget renderer crap
<hatch> what widget renderer crap?
 * hatch gets his pimp hand ready
<rick_h> http://yuilibrary.com/yui/docs/api/files/widget_js_Widget.js.html#l579
<rick_h> ^^ wtf, why is the actual DOM rendering done off the event RENDER?
<rick_h> I guess so they can enforce the fireOnce-ness of it...ugh.
 * benji hands hatch an animal print fedora.
<rick_h> benji: ok, hack time. 
<benji> yay! I get to add a setTimeout to the code base
 * benji greps
<rick_h> benji: no no no
<benji> darn! I'm not the first one
<benji> :P
 * hatch puts my pimp hand away
<hatch> actually that's how I'd write it too
<hatch> :)
<hatch> well not exactly
<hatch> but close haha
<rick_h> hatch: I think what we can do is change the event to after(renderedChange)
<hatch> I don't know what the problem is so I can't say what to do :)
<rick_h> benji: http://yuilibrary.com/yui/docs/api/files/widget_js_Widget.js.html#l583 is after the actual rendering, the ATTR for RENDERED ('rendered') is set to TRUE
<rick_h> benji: so we can add an event watch for that, since we KNOW it's after the REAL rendering.
<rick_h> benji: and then do your work
<benji> ooh, I like it
<benji> that'll be  this.on('renderedChanged', myFunc), right?
<rick_h> benji: so to watch for ATTR changes you'll have to use the event syntax renderedChange I believe
 * rick_h goes to dbl check attr event watch syntax
 * benji wonders where those docs are.
<hatch> use after
<benji> yep, after would be better
<benji> well, I guess it doesn't matter in this case, but generally "after" is what I want for attribute changes
<rick_h> benji: yea, so per http://yuilibrary.com/yui/docs/attribute/#events looks right
<sinzui> bac, do you have a few minutes to review these my text changes to the juju-gui charm? https://codereview.appspot.com/10698043/
<rick_h> sinzui: ok, have tmie to chat now, sorry. benji is distracting me :P
<benji> :)
<bac> sinzui: y
<rick_h> sinzui: invite on the way
<hatch> benji: 'on' will allow you to prevent the attribute change value, 'after' you can be sure that it hasn't been prevented by anything else
<hatch> mind if I ask what the issue is?
<benji> ah, that's a good point
<bac> sinzui: in HACKING you are telling them to get the released version of the charm to start work, not the devel branch.
<benji> hatch: this doesn't seem to work for me:
<benji> this.addEvent(this.after('renderedChanged', Y.bind(this._addDraggability, this, container)))
<bac> ~juju-gui-charmers is release, ~juju-gui is devel, sinzui
<hatch> Change
<hatch> no d
<benji> I need to inspect some element dimentions after they are rendered
<benji> ah!
<hatch> benji: this.after('render', function() {}) doesn't work?
<hatch> that's kind of the purpose of the after render :)
<hatch> event*
<benji> hatch: nope because that event is (apparently) fired after all the render() methods are called, not when the nodes have actually been rendered by the browser
<sinzui> bac, I think I am asking them to hack on the dev version
<bac> sinzui: line 22 of HACKING refers to lp:~juju-gui-charmers
<sinzui> bac: I think that is wrong then
<bac> yeah, i think so
<hatch> benji: I don't think so, reading the code here
<hatch> are you sure you used 'after' and not 'on'
<hatch> after fires /after/ the defaultFN is run
<hatch> whic is aftter the elements are in the dom
<benji> if I put a debugger call in the event handler I can't the elements on the screen
<benji> and they have no computed style
<benji> (which is what I really want)
<hatch> oh, I htink that's because the renderUI isn't attaching the element to the contentBox
<hatch> can you see if the content/boundingbox is in the dom?
 * benji looks
<hatch> sorry for the q's I just want to know where the real issue lies
<hatch> so, this.after('render', function() { debugger; });
<hatch> then there should be a yui3-charmtoken element in the dom
<benji> basically (there is more in there, than just the debugger call
<benji> here is the renderUI funciton: 
<benji> http://paste.ubuntu.com/5805499/
<hatch> yeah that isn't the proper place to put that
<hatch> that's why it's not working
<hatch> guichat real quick?
<benji> hatch: sure
<hatch> cool
<rick_h> benji: hatch guichat? I can tell you right where this is
<hatch> yup
 * rick_h just went through the widget source
<sinzui> bac, I propose reverting my changes to HACKING.md. I think it is fine as it is.
<bac> sinzui: yep
<hatch> great chat guys :)
<rick_h> man, that is some crazy stuff
<sinzui> bac, sorry about the deplay. I reverted the HACKING.md changes: https://codereview.appspot.com/10698043
<hatch> bcsaller: reviewing
<hatch> bcsaller: so am I to understand that by default it will always apply the child binding? and then if no child binding is applied then it'll look for a parent one?
<hatch> the code reads like it only applys the parent binding
<hatch> so curious as to where the child binding is assigned
<bcsaller> hatch: on call, one sec
<hatch> np I put the comment in the review
<bac> hatch, when you have a moment would you grab my branch and see if i've done anything untoward wrt events?  lp:~bac/juju-gui/inspector-settings
<hatch> sure thing
<hatch> checking out
<hatch> now that i Know how to do diffs in bzr this is a lot easier haha
<hatch> bac: don't use ID's - then we won't be able to have multiple inspectors
<bac> hatch: do you even know about 'bzr diff -c'?
<bac> that one eluded me for way too long
<hatch> nope
<hatch> I use bzr diff --old ../trunk --new branch-name | subl (to pipe to sublime)
<bac> 'bzr diff -c 500' shows you the diff of what was changed in rev 500
<hatch> ohh that's cool but I usually commit to much for that and want to diff from trunk
<bac> if you're using lightweight checkouts that can be shortened to: diff -r ancestor::parent
<hatch> ohh cool!
<hatch> I think I am using light weight checkouts because they check out pretty fast
<hatch> bac: if you're going to change var dd = to var _ = you can just delete the var assignment
<bac> hatch: but then the linter complains
<hatch> oh I didn't know that
<hatch> alright
<bac> yeah "Don't use new for side effects"
<bac> which is what we're doing
<hatch> yeah I suppose that's....sort of valid heh
<hatch> ok so your code looks good with the exception of the id's
<bac> hatch: so you're suggesting replace the id with a one-off class?
<hatch> yup
<bac> cool
<hatch> id clash bugs are damn near impossible to track down hah
<benji> rick_h and hatch: the "set the dragImage when the drag starts" approach worked!
<hatch> ^5!!!!!
<hatch> thats the best approach yet! :)
<benji> I'm a little surprised it worked because the drag is already happening at the point.  But I'm glad it worked.
<benji> Now I just have to rework all the tests and figure out if I can fix chromium's crazy clipping of the category and generic icons.
<hatch> I am surprised as well for the same reason, can't wait to see the code :)
<hatch> cmd+w and cmd+s are way to close to eachother
<bac> hatch, benji, bcsaller: I'm going to have to turn-over my critical card (OSCON: Build service settings inspector page) since I'll be out until Tuesday.  Would one of you put your face on it to at least ensure someone takes it?  I can do a call later if anyone volunteers.
<hatch> bac: what do you anticipate the time to complete to be?
<hatch> I 'might' be able to pick it up but I'm also out monday
<benji> bac: I'm afraid I have to run, but if you don't get any other takers you can send me an email with the brain-dump and I'll adopt it.
<bac> benji: thanks
<bac> hatch: another day?  the config file control and the expose section are undone
<hatch> ahh ok
<hatch> well I can probably take it then
<bac> hatch: feel free to pawn it off on benji or someone else.
<hatch> pending no more odd issues with the current thing I'm working on
<rick_h> benji: yay!!!!!!
<bac> fat chance
<hatch> lol
<bac> ok, kthxlater
<hatch> rick_h: HTC released the source for the One Google Edition yesterday and someone has already compiled it into a usable rom so you can get native android on a HTC One :)
<rick_h> hatch: cool
<hatch> that was the only thing holding me back from buying a new phone
<hatch> soooo HTC One next week possibly? :)
<hatch> http://forum.xda-developers.com/showthread.php?t=2341395
<rick_h> Contract End Date: 12/15/2013
<rick_h> I'll have to wait until the end of the year to switch my phone off verizon and go with a phone from google
<hatch> I thought you had an N4?
<hatch> a*
<rick_h> hatch: no, galaxy nexus
<hatch> ahh, well by then the new N4 will likely be out
<hatch> but not on a contract so it'll probably cost you $400 or something
<rick_h> yea, hoping to buy the phone straight out and move to a GSM carier 
<hatch> we used to be CDMA here but they recently switched to GSM and it's been awesome
<rick_h> yea, all good. I'll have held onto the GNex for 2 full years and ready to spend $$ for my own phone and hopefully save some $$
<hatch> unfortunately on my carrier you don't get a discount if you don't get a phone
<rick_h> I'll keep my verizon mifi though. <3 the LTE and network. Figure worst case I'll use that to help my phone with coverage on a smaller carrier
<hatch> so might as well get a sub'd phone and root it
<rick_h> right, why I have to switch carriers. 
<rick_h> I'm not sticking with verizon. 
<hatch> the plan I'm on http://www.sasktel.com/search/controller/_/R-Product_Services_Talk%26%2344%3B_Text_%26amp%3B_Data_Plans the Ultimate 65
<hatch> pretty good plan imho
<hatch> http://techcrunch.com/2013/06/27/immigration-reform-passes-senate-house-leadership-calls-bill-a-pipe-dream
<hatch> so.... in the Senate can do all this work to draft and write a bill, which the house then ignores and makes their own?
<hatch> is that the typical process?
<hatch> man I friggen love this app
<hatch> maybe I'm bias
<hatch> but it's friggen cool
<bcsaller> hatch: got a sec to chat?
<hatch> oui oui
<hatch> guichat?
<hatch> bcsaller: email sent to peeps so you should get it soon
<bcsaller> hatch: thanks
<huwshimi> Morning
<hatch> morning
<hatch> meeting in 5?
<hatch> jujugui weekly meeting aus edition now?
<Makyo> Is that in guichat?
<huwshimi> Yeah, I think so
<hatch> sure thin
<hatch> I'm live streaming a paul van dyk set in guichat
<hatch> so join up :)
<gary_poster> jujugui call now :-)
<gary_poster> bcsaller, if you can join that would be cool
<hatch> gary_poster: maybe some combination of the two always-on-sticky-headers with the ability to accordion if wanted :)
<gary_poster> hatch feel free to follow on in thread :-)
<hatch> who's Jamie? Haven't seen that name before :)
<hatch> ahhh gooooo directory
<hatch> it's Master Chief's real name
<huwshimi> gary_poster: Ready
#juju-gui 2013-06-28
<hatch> kewl single inspector stuff is done with a config factory
<gary_poster> hey luca.  when you have a moment, I'd love to have a hangout with you on the scrolling behavior.  it sounds like you have something in mind that I will like a lot, but I just don't understand it yet.
<luca> gary_poster: sure, I'll hopefully be free in a bit, trying to get the service blocks done
<gary_poster> cool thanks luca
<gary_poster> arosales, we still need to actually release the GUI so the contest's export instructions work.  Please let me know ASAP when you all have verified that it works as you need, so we can start the qa for making a release
<rick_h> gary_poster: it looks like the updated staging isn't updating the css. I'm not getting my changes for the related charms stuff on there atm but it shows up in trunk and works locally. 
<gary_poster> rick_h, hm, ok, I'll dig for a sec
<gary_poster> rick_h, poking at things and not sure what to look at to see if I did anything. :-) what do I check?
<rick_h> gary_poster: so a manual force would be to rm build-shared/juju-ui/templates.js && make build-shared/juju-ui/templates.js
<luca> gary_poster: did you want to discuss scroll bars?
<gary_poster> rick_h, but what do I need to look on uistage at verify that the update happened?
<gary_poster> luca, on call for the next 39 min.  Will you be available then?
<luca> gary_poster: sure
<gary_poster> thanks
<rick_h> gary_poster: so the trouble. is that the juju-gui.css is out of date. I guess we can verify it's timestamp vs the lib/views/browser/*.less
<rick_h> gary_poster: there should be a badge_approved_17.png in that combined css file coming from the lib/views/browser/charm-token.less file
<rick_h> for a quick grep-able bit to look for
<gary_poster> rick_h, ran out of time just forced.  fixed on uistage?
<hatch> morning
<rick_h> gary_poster: yes, thanks
<gary_poster> cool welcome
<rick_h> morning hatch 
<hatch> gary_poster: re your dec email - none are showing up for me in CA - should I do it or is it broken? :)
<gary_poster> hatch, we have to add them ourselves in CA
<hatch> ohh ok, I misunderstood
<hatch> annnnd done
<teknico> you can review a 4K lines diff in about 30 seconds! great opportunity, today only, don't miss it! https://codereview.appspot.com/10746043
<hatch> teknico: can we really trust you? :)
<hatch> maybe you put h4x0r code in there
<hatch> *shifty eyes*
<teknico> hatch: thaaat's the question, isn't it? ;-)
<teknico> hatch: you have the tools to catch that, but it will turn the review into a 90 sec one ;-)
<hatch> haha
<teknico> hatch: thanks
<arosales> gary_poster, I have tested a gui only / gui-wordpress-mysql / gui-wordpress-mysql-mongo-ceph
<arosales> on aws
<arosales> the yamls look correct, but I haven't yet been able to re-import with deployer just yet
<arosales> gary_poster, I'll check on HP cloud this morning, and check the status of the deployer with hazmat and then sync up with your on our 1x1.
<sinzui> orangesquad, I want to have another 15 minute chat in 20 minutes. We can reuse our standup hangout to discuss the big picture for July and maybe August
<gary_poster> arosales, ok cool.  ideally I'd wait till we have that confirmation before we release, but I may start optimistically before then so we have enough qa time before eod.
<gary_poster> luca, guichat?
<gary_poster> hopefully fast :-)
<arosales> gary_poster, agreed, from my testing it is looking good
<gary_poster> great thanks arosales 
<luca> gary_poster: sure, let me grab a room
<arosales> thanks for delivering that in a release no less :-)
<gary_poster> cool thanks
<gary_poster> arosales glad to help! thanks for promoting gui
<arosales> literally its our pleasure
<gary_poster> :-)
<hatch> gary_poster: could you do me a favour and check out my branch to see if you can actually get the error you brought up?
<hatch> I thought it wouldn't work either
<hatch> but I can't make it break
<gary_poster> hatch on call will try
<gary_poster> later
<hatch> thanks - I just want to be sure I'm not missing something obvious
<gary_poster> jujugui call in 10, kanban now
<arosales> hazmat, on that note is there a branch I can test the deployer import on charm store charms?
<hazmat> arosales, ~hazmat/juju-deployer/python-env/
<arosales> hazmat, thanks.
<hatch> jujugui creating relations is broken in trunk
<Makyo> hatch, works for me..
<hatch> really?
<Makyo> Yes.
<hatch> hmm
 * hatch clears caches
<hatch> poo
<hatch> looks like it's my branch and bad cache
<hatch> darn and my branch doesn't appear to have any reason that would break
<gary_poster> jujugui call now
<gary_poster> ish
<sinzui> rick_h, jcsackett, adeuring, https://plus.google.com/hangouts/_/cf491220dfb7736cee2876baf29110eeb52f5997
<Makyo> So.
<Makyo> Good thing I can hear everyone.
<Makyo> closer to the new style, gary_poster, just minus some styling and checkboxes.  i.e. interaction.
<rick_h> orangesquad: heads up that they're working on the power around here after the storms last night. Things are flickering and lost it twice now. I might come/go a bit
<jcsackett> rick_h: ack.
<hatch> rick_h: above ground power?
<rick_h> hatch: well when I got back from the vet all the lights were out with trucks around the poles and power's gone out and hit the UPS twice so far. 
<rick_h> hatch: so yea...I guess it's above ground
<rick_h> or it's the block's below ground, no idea. 
<hatch> ahh - around here the power is under ground in residential areas except where there is the transformers
<hatch> usually it's those things that go in storms here
<hatch> hah
<hatch> ka------boooooooom
<rick_h> hatch: yea, I mean they're clearly working on local power. We kept it through the storm, but a block away didn't. So I'm not sure what's up. 
<hatch> that video looked like it was a good storm too :)
<rick_h> yea, I was surprised/happy we kept power tbh
<jcsackett> rick_h: got a sec to hat on hangout?
<jcsackett> s/hat/chat/
<rick_h> jcsackett: sure thing
<jcsackett> gary_poster: any chance we can get the templates rebuilt/recompiled on staging? they have not, and so despite the flag being gone the share button will not render.
<jcsackett> which causes other fun problems for the sharing widget, as you might imagine. :-P
<gary_poster> jcsackett, tell me what command to run and I will do so.  big extra points for figuring out what needs to be fixed in Makefile.  I'd look but other priorities atm
<rick_h> jcsackett: I'd ping bac but I don't think he's around today. I wonder if someone else has access to the staging setup?
<rick_h> gary_poster: that same command you ran for me needs running. What command is the staging server running on a new version update?
<rick_h> gary_poster: rm build-shared/juju-ui/templates.js && make build-shared/juju-ui/templates.js
<gary_poster> rick_h, jcsackett done
<gary_poster> rick_h, make build-prod
<hatch> oop another make error....time to switch to grunt /troll
<rick_h> hatch: well I'm guessing some command wasn't moved to the new location when staging was split up. 
<rick_h> hatch: as it was working well on the old url for a long while
<hatch> nope this is clearly a make error
<rick_h> hatch: shush
<hatch> haha
<jcsackett> rick_h: huh, it's not fixed.
<rick_h> before you get assigned to fix it 
<rick_h> jcsackett: yea, looking
<hatch> so my insurance company lets us renew our insurance online.....but we have to go into the branch to set up an account :/
<hatch> convenience gain.... 0
<rick_h> gary_poster: any chance the command was on the wrong checkout? 
<rick_h> jcsackett: can you check if the css file has all the rules in your branch that was deployed out? http://uistage.jujucharms.com:8086/juju-ui/assets/juju-gui.css
<rick_h> jcsackett: I'm guessing something is missing since the share widget has the li dots on it
<jcsackett> rick_h: i can, but there aren't rules to make the share button not render.
<gary_poster> rick_h, http://pastebin.ubuntu.com/5808236/
<rick_h> jcsackett: right, but just checking if the file's up to date or not. 
<rick_h> gary_poster: thanks, will do a test here with that and see if there's a build step missing. 
<hatch> gary_poster: I'm going to switch to the settings page - so just let me know whwnever you have a moment to do that QA, no rush
<gary_poster> thanks rick_h 
<gary_poster> hatch if someone else verifies for I am AOK with it
<jcsackett> rick_h: looks like it.
<rick_h> jcsackett: looks like it's up to date? or out of date?
<jcsackett> that is to say, looks like all the rules are there.
<rick_h> e.g. so the dots should be there?
 * rick_h is confused
<jcsackett> they get cut off by sizing, not decoration.
<jcsackett> rick_h: and again, no css rules were changed in this branch, so even an out of date css file could have all the rules.
<hatch> Makyo: bcsaller either of you guys have a moment for a quick QA?
<hatch> https://codereview.appspot.com/10724043/
<gary_poster> luca, try again in guichat? :-)
<gary_poster> frankban, i privmsg'd you, in case it didn't ping
<jcsackett> rick_h: what did you do? it's working.
<rick_h> jcsackett: nothing atm. I don't have access to the staging server. I do see some issues though. Subapp tempaltes aren't part of the makefile's template list. 
 * jcsackett wonders if there's a delay between templates rebuilding us getting them, even with cache clearing...
<rick_h> jcsackett: and not sure if there's a cache on the server side?
<jcsackett> rick_h: there's almost certainly a server side cache, come to think of it.
<jcsackett> rick_h: probably worth filing a bug about the subapp templates in makefile's template list.
<rick_h> jcsackett: trying to see if the css files are keyed in the makefile as well since ours are in a subdir
<rick_h> jcsackett: yea, trying to finish tracking down bits and maybe I can get my find-fu on to fix it. /me is spoiled by zsh **/*
<rick_h> I never use find any more 
<rick_h> jcsackett: so there's en ETAG on the js file, but that sohuld have changed/updated when the source was updated. 
<teknico> why use find when you can F9-c-f? ;-)
<rick_h> teknico: huh?
<teknico> rick_h: no midnight commander, eh? :-)
<rick_h> teknico: heh, no. ls app/**/*.(handlebars|partial)
<Makyo> I always forget about midnight commander until I typo `mv`
<rick_h> teknico: and I don't think out Makefile will be able to run mc
<rick_h> /out/our
<teknico> oh, ok, missed the context
<rick_h> and man I can't wait until we get to scss and can ditch this treating the css files as a template build step. Just call scss on the files in the makefile themselves. 
<teknico> and I'm also going to miss you all for ten days: wish me a happy Europython! :-)
<rick_h> teknico: jealous!
<rick_h> jcsackett: well now that it's showing make sure to let jcastro see the sexy he's been wanting :)
<jcastro> yeah!
<jcastro> I just realized with the oscon reveal that that means I shouldn't take videos of deploying stuff with the gui?
<rick_h> jcastro: I'd say not :/
<rick_h> jcastro: http://uistage.jujucharms.com:8086/precise/ceph-11/ for your enjoyment
<jcastro> rick_h: which part is different today?
<rick_h> jcastro: share button
<jcastro> I don't see it
<rick_h> jcastro: next to add?
<rick_h> jcastro: clear cache maybe?
<jcastro> ah
<jcastro> not in FFx
<jcastro> weird
<rick_h> jcastro: hmm, in FF here. Bet it's a cache issue
<jcastro> k
<rick_h> jcastro: ok, so the template list is incomplete and there's no actual make target on the css files so it doesn't rebuild when that's all that changes. 
<rick_h> oops, jcsackett ^
<jcastro> gary_poster: oh hey, that Discourse charm gui bug, I'd like to demo it at oscon
<jcastro> not a hard requirement, but dang it would be awesome
<gary_poster> jcastro, I figured, but we haven't gotten to it.  probably no time before we have to make a release for you.  will see if I can squeeze it in.
<jcastro> man, this drag and drop
<jcastro> I am just sitting here dragging shit into the ui
<jcastro> for no reason other than just doing it
<hatch> lol
<hatch> out of curiosity what's the discource gui bug?
<jcastro> it doesn't deploy from ~marcoceppi/blah blah
<hatch> ohh the local charm thing
<jcastro> no I mean from cs:~marcoceppi blah blah
<jcastro> it does work fine in the uistage though. ;)
<jcastro> cheatin' uistage!
<hatch> haha yup
<hatch> you could demo on sandbox ;)
<hatch> "look how fast servers spin up with juju"
<hatch> haha
<jcastro> hah yeah
<sinzui> rick_h, jcsackett, do both of you have time to join my in the stand-up hangout?
<rick_h> sinzui: rgr
<gary_poster> jcastro, oh, you want discourse bug fixed for *OSCON*.  Yes, definitely plan on it.  I read it as fixed for Monday.
<jcastro> oh ok, thanks!
<benji> gary_poster: [I was lunching/relocating.] Sure, I'll get those entered before my EOD.
<gary_poster> benji, cool thanks.  we need to countersign/countercountersign before then too.
<jcsackett> sinzui: sure.
<benji> gary_poster: oh, in that case I'll do it right now
<gary_poster> cool
<benji> gary_poster: is the target date 2014-04-01?
<gary_poster> benji yes
<benji> k
<hatch> bcsaller: do we know what charm data is provided by default by the delta?
<bcsaller> hatch: I *think* its just the reference id by default in the service data, I'd have to check
<bcsaller> hatch: I think we use that Id to then go to one of the charm store apis, where that is currently the old one
<hatch> alright so when we get a delta to create a new service we should go pull the charm data, then show the service in the UI
<hatch> then we can get rid of the charm.loaded flag
<benji> gary_poster: https://www.youtube.com/watch?feature=player_detailpage&v=ReJ3RltihME#t=309s
<benji> I'm ready for simultanious key turn.
<gary_poster> benji, lol cool
<benji> I'm both proud and ashamed that it only took me 30 seconds from thinking of that clip to finding it.
<gary_poster> heh
<gary_poster> benji, I don't have it.  I think allhands is having issues.  I'll send an email to P&C about it
<benji> :/
<gary_poster> thank you for entering
<gary_poster> yeah
<gary_poster> four people have issues so far
<benji> "Objective Sheet Submitted" 
 * hatch holds out hand for donations to buy faster machine to run lbox_check tests
<hatch> rick_h: I hear you just got a new machine that you aren't using :P
<rick_h> hatch: hah, I use it to run my lbox_check :P
<hatch> lol
<hatch> maybe I can push my changes to your box
<hatch> lol
<rick_h> the rick_h lbox service...wonder if I could turn that into a startup
<hatch> lol
<hatch> I have to admit I've heard worse startup ideas
<hatch> bcsaller: mind taking a peek at the new code
<hatch> the charm.loaded needs to stay - at least for a follow-up to fix the charm system later
<rick_h> jujugui can I get a couple of sanity checks on the small makefile change please. QA instructions included. https://codereview.appspot.com/10756043
 * benji looks.
<hatch> gary_poster: if you get a moment mind taking a look at https://codereview.appspot.com/10724043/ for a followup LGTM
<gary_poster> LGTM hatch
<hatch> thanks!
 * rick_h fears his 3 lines broken benji's computer 
<rick_h> broke, bah. come on EOD
<benji> heh
<benji> I got distracted by trying to get my tests to pass.
<rick_h> benji: ah ok. I feared things were going bad. 
<benji> rick_h: nope, but the review is done with QA; I had a suggestion on the regex.
<rick_h> benji: awesome. thanks for the suggestion. 
<benji> my pleasure
<rick_h> gary_poster: landing the makefile update. Hopefully this fixes the issues we've seen today. Let me know if anyone runs across any others like it. /cc jcsackett 
<gary_poster> yay thanks rick_h 
<Makyo> bcsaller, or hatch, I'm having a hard time binding an event in a viewlet.  Either of you have time in ~5min for a quick chat?
<bcsaller> sure
<bcsaller> Makyo: in chat now
<hatch> Makyo: in guichat
<hatch> come on by
<Makyo> hatch, just chatted with bcsaller, sorry.  Thanks though.
<hatch> oh heh alright np
<Makyo> Was defining the event on 'events', needed to be 'viewletEvents'
<hatch> ahh
 * hatch remembers now why he doesn't do CSS
<gary_poster> sinzui, hi.  one more topic.  MS asked that uistage.ubuntu.com become comingsoon.jujucharms.com when OSCON starts.  May I ask you to add that to your IS coordination list?
<gary_poster> sinzui, ideally uistage would redirect, but if they simply point to same machine that is OK
<gary_poster> I suppose we could handle the redirect ourselves if they point to the same machine
<sinzui> I think I understand
<sinzui> gary_poster, anyone going to uistage.ubuntu.com -> comingsoon.jujucharms.com...and the reveal one or both domains become jujucharms.com?
<hatch> do we have a card/ticket for removing all of the old unused css after the switchover?
<gary_poster> sinzui, anyone going to jujucharms.com goes to stable production GUI.  anyone going to comingsoon.jujucharms.com sees equivalent of current uistage.jujucharms.com:8086.  (this one is different from what I said before) finally, anyone going to uistage.jujucharms.com is redirected to jujucharms.com (the stable version)
<gary_poster> sinzui, we could have comingsoon turned on now
<gary_poster> we could also control the uistage redirect if desired but probably better if dns points to production gui...we can implement a redirect later so that uistage actually changes the url
<gary_poster> hatch no.  I'll make one.
<sinzui> gary_poster, so as I am asking for the current stable charm and the stable code to be deployed to what will be jujucharmscom. If webops and I see no issues, we should do the DNS change now?
<gary_poster> sinzui, +1 on comingsoon DNS change now.  -1 on the uistage DNS change now, but we can do that at or after OSCON
<sinzui> okay. Thank you for clarifying.
<gary_poster> thank you!
<gary_poster> hey benji, I wanna make a release.  I want your branch in it.  what's the timeline?
<hatch> gary_poster: thanks
<gary_poster> thank you for mentioning it hatch
<benji> gary_poster: I just submitted it for review; I'm looking over it before soliciting reviews
<benji> s/just submitted/am submitting/
<gary_poster> ok
<gary_poster> cool
<gary_poster> let's try to speed it through if we see no probs
<benji> sounds good
<gary_poster> Makyo, did frankban hand off to you for his constraints work?
<Makyo> gary_poster, yes.  Still working on getting modifyUnits plugged in, though.  I have events properly firing now, at least.  I have his code already branched, though.
<sinzui> orangesquad, gary_poster. The sun was just swallowed by a storm and I cannot hear the music over the thunder. I might loose power/net if this new house problems.
<gary_poster> sinzui, ack.
<gary_poster> cool Makyo thanks
<benji> jujugui: I need two quick reviews so this branch can go into the pending release: https://codereview.appspot.com/10763043
<Makyo> benji, on it.
<benji> thanks
<hatch> benji: i'll take one
<benji> thanks hatch 
<hatch> needs QA?
<hatch> gary_poster: http://www.sublimetext.com/blog/articles/sublime-text-3-public-beta
<gary_poster> hatch QA yes
<gary_poster> hatch sublime, already installed but haven't done much with it yet
<hatch> benji: can I request that you add this functionality to the new deploy method in trunk?
<benji> hatch: you can request anything your heart desires
<hatch> well...I am asking becuase if I ask for that I won't lgtm it
<hatch> :)
<hatch> so depends if you want the lgtm or not haha
<hatch> or follow-up
<benji> I think gary_poster will want it in a follow-up.
 * gary_poster vites for follow-up :-)
<gary_poster> votes
<hatch> alrighty then :)
<Makyo> benji, LGTM.
<Makyo> Closed Reitveld, will LGTM through there in a sec.
<gary_poster> Oh btw Makyo did you look at those svgs from luca?
<Makyo> gary_poster, Oh!  Yeah!  They should be fine, I think.  We'll have to re-jigger some of the margins and such, but that should be relatively easy, I think.  It helps that they don't have drop-shadows.
<Makyo> Sorry, will email.
<gary_poster> cool Makyo.  May I make a card and assign you?
<hatch> lol re-jigger
<Makyo> Yep!
<gary_poster> cool Makyo  thanks
<hatch> what show is that from
<gary_poster> just a word for me
<Makyo> It's kind of a south/south-central US idiom.  Friend from CA laughed at it last time I used it.
<gary_poster> etymology http://www.etymonline.com/index.php?term=jigger<shrug>
<gary_poster> http://www.etymonline.com/index.php?term=jigger that is
<hatch> languages!
<hatch> I'm gona speak in clicks from now on
<gary_poster> _The Gods Must Be Crazy_
<gary_poster> don't remember the movie but remember liking it
<gary_poster> (he spoke in clicks)
<hatch> oh haha
<hatch> I was wondering where that was going
<gary_poster> :-)
<gary_poster> bushman discovers coca cola bottle; hilarity ensues
<benji> the story of my life
<gary_poster> lol
<hatch> benji: fyi there is a conflict with trunk
<hatch> in the less file
 * benji looks
<benji> hatch: fixed (pushing merged branch now)
<hatch> yeah it's a super small thing
<hatch> benji: lgtm'd I included the issues caused by the missing deploy method in the reply
<gary_poster> benji, I need to be out of here in 20 minutes, fwiw.  I can do the release later this evening though.  hatch, are those qa issues?
 * benji reads.
<hatch> gary_poster: they are - but can only be fixed by the follow-up branch
<gary_poster> :-(
<hatch> unless we delay this branch to add those features
<hatch> that feature*
<gary_poster> ack
<benji> hatch: I haven't QAed the branch after merging with trunk, are you saying that there is a new deploy method that I should be calling instead?
<hatch> benji: under the flag yes
<benji> ah
<hatch> guichat about it?
<gary_poster> hatch, this breaks the ghost inspector, but is fine outside of the feature flag?  or, it doesn't break anything under the feature flag but doesn't work either?
<hatch> those qa issues were under the feature flag
<hatch> sorry I wasn't clear there
<gary_poster> gotcha
<gary_poster> and it doesn't break anything pre-existing
<gary_poster> but we need those changes in order to work with the inspector, right?
<gary_poster> so fine to make a release with this
<hatch> work with the inspector from deploying by dragging
<hatch> yes a release is fine
<gary_poster> right
<gary_poster> cool
<gary_poster> thanks
<hatch> deploy by click still works with the flag
<gary_poster> cool
<gary_poster> benji, you good on this?  You can make a card and ask someone else to do it if you like :-)
<benji> I'm cool doing a follow-up branch.
<gary_poster> cool thanks benji.
 * gary_poster brb
<benji> I'll also address the review suggstions there, since we are in a rush.
<benji> if that ^^^ is ok with hatch 
<hatch> benji: yep for sure - my comments were super trivial
<benji> cool
 * benji lands.
<hatch> before the release is rolled someone should probably do a qa on it :)
<gary_poster> hatch, was going to do that, but will be packing for trip tonight, so if you Makyo or bcsaller were willing to do the pre-release qa that would be much appreciated
<gary_poster> if not I will do it
<gary_poster> if you did the release that would be cool too! :-) the docs are pretty good I think
<hatch> ok don't worry about it, one of us will be able to
<hatch> I've never done it :)
<hatch> not sure I want to go alone first time on a friday night haa
<gary_poster> ok thank you.  shoot me a mail telling me how far it got
<gary_poster> yeah friday is not the best :-/
<gary_poster> ugh the resize is broken on the internal pages again :-/
<gary_poster> fixed at least once before
<gary_poster> if not twice
<gary_poster> forgot what the deal was
<gary_poster> darn.  I was going to talk to jeff and rick about reusing charm widget
<gary_poster> hatch, guichat for 5?
<gary_poster> if busy no problem
<hatch> yup
<gary_poster> thx
 * benji waits for lbox sumbit to finish
<rick_h> gary_poster: whats up?
<gary_poster> rick, hey.  hatch will share evil plan.  must run. :-) thanks
<rick_h> k
 * gary_poster runs
<hatch> rick_h: guichat plz
<rick_h> hatch: can you invite me? on the tablet
<hatch> sure one sec
 * benji suspects lbox has frozen.
<benji> branch landed, follow-up branch began, bug filed: time for EOW
<benji> Have a good weekend all.
<hatch> benji: you broke the build lol
<benji>                                                                                                                                                                                                                                                                                                                                                    
<benji> hatch: I'm looking at the test failure
<hatch> benji: oh ok I just started on it too
<benji> I wonder how that happened.
<hatch> heh thought you went already
<hatch> it only fails in FF
<hatch> (repeated locally)
<benji> hatch: maybe I should leave you to it.  Do you prefer one over the other?
<hatch> I don't really know what the purpose of these asserts are
<hatch> why does it 'need' to be 0
<hatch> benji: I think I have fixed it
<benji> cool!
<benji> I am more and more of the opinion that an assert without an explanitory comment is a bug.
<hatch> yeah sometimes it's just not very clear as to why the assert is necessary
<hatch> ok yup fixed
<hatch> proposing
<hatch> benji: if you wouldn't mind sticking around for a bit to LGTM this for me so I can at least have a single reviewer :D
<benji> hatch: sure
<hatch> thanks I'll ping when lbox completes
<hatch> jujugui could I get some reviews plz https://codereview.appspot.com/10769043
<benji> hatch: looking
<hatch> thanks
<benji> hatch: oh, that's much better than what I had
<benji> hatch: review done
<hatch> haha well it's the same idea, just removed the cruft :)
<hatch> thanks, landing
<hatch> lol nice review
<hatch> ok once that lands I'll QA and try and not screw up the release ;)
<benji> the release docs are quite good
<hatch> yeah they look like it
<benji> ok, I really have to go now; bye!
<hatch> cya :D
<arosales> hopefully its just me but are other folks seeing the uistage load
<arosales> http://uistage.jujucharms.com:8080/
<arosales> canvas and charm store nav is not coming up for me.
<hatch> checking
<hatch> no store, canvas though
<hatch> but the store isn't at that url
<hatch> did you want this one? http://uistage.jujucharms.com:8086/
<arosales> ah yes, that works better
 * arosales was just looking for a working version.
<hatch> :) the 8086 is the sekrit version ;)
<arosales> hatch, thanks
<arosales> pwd
<hatch> no problem
<hatch> jujugui - is the DD supposed to work on rapi? I don't get the (+) on the cursor and it doesn't drop
<Makyo> DD?
<hatch> drag and drop
<Makyo> Oh,.
<hatch> I'm trying to do the release but I can't release it if that's supposed to work heh
<bcsaller> Thats very odd as thats just a UI specific way to call deploy, no?
<hatch> that's what I thought
<hatch> I'm investigating now
<hatch> makedragstart handler is never called
<hatch> hmm
<hatch> odd
<hatch> dragstart is fired but it's callback isn't called
<hatch> that don't make no sense mang
<hatch> oh
<hatch> nope that's not it
<hatch> heh
<Makyo> Where does createServiceInspector live?
<Makyo> I can't grep quickly because I have stuff in vim copy buffer.
<hatch> yup 'drop' never fires
<hatch> Makyo: environment.js
<hatch> views/
<Makyo> Wow, that sucks.
<Makyo> Most of today's work is moot.
<hatch> uh oh, why?
<Makyo> Just surrounding event stuff, which got weird when I merged with trunk.
<gary_poster> hey
<Makyo> I'l ljust GUESS
<hatch> oh hey gary
<hatch> glad you're still here :)
<gary_poster> so you said that dnd doesn't work with improv?
<hatch> noope, the drop event doesn't fire
<hatch> that's as far as I've gotten so far
<gary_poster> wow that's pretty weird
<hatch> yeah....I'm pretty blown away hah
<hatch> if I change sandbox to true, I get a drop target, if it's false, I dont'
<gary_poster> trying to dupe
<Makyo> I can dupe.
<gary_poster> ok
<hatch> it's a D3 issue....it's makyo's fault
<gary_poster> that sucks :-/
<gary_poster> lol
 * hatch runs away
<hatch> haha
<gary_poster> I doubt that
<Makyo> Nah, not cool.
<hatch> yeah actually it's in the YUI section
<hatch> lol
<hatch> OHHH
<hatch> I KNOW!!!!
<hatch> I KNOW!!!!!!!
<Makyo> Do tell.
<gary_poster> yeah I was kinda expecting a follow-up
<gary_poster> :-)
<gary_poster> and duped btw
<hatch> lol
<gary_poster> it drags very nicely fwiw
<hatch> well my guess is that we are missing a yui module
<hatch> oh wait
<gary_poster> not so much wit hthe drop though
<hatch> nm
<hatch> nope the drop whitelist is there
<hatch> damnnnnn
<hatch> I was so excited
<hatch> and now so let down
<hatch> :'(
<hatch> well darn
<gary_poster> it looks so nice in the sandbox...
<gary_poster> my chromium and chrome are broken for some reason :-(
<gary_poster> they start flashing and wiggling
<gary_poster> when I load a page with stuff going on
<hatch> maybe it's checked out for the week
<hatch> :)
<gary_poster> heh, been that way for the whole week
<hatch> benji is going to be very.....irritated
<hatch> ahh getting closer
<hatch> ok I lied
<hatch> 'dragover' fires
<hatch> so I suppose that's a little closer
<gary_poster> I have a suspicion.  trying to verify
<gary_poster> in show_environment
<gary_poster> in app.js
<gary_poster>             useDragDropImport: true, #this.get('sandbox'),
<gary_poster> that is, I bet that something is configured in the environment that ben did
<gary_poster> which benji needs
<gary_poster> and assumed he already had
<bcsaller> that would stop it
<gary_poster> yes, hatch, bcsaller, that is the trick
<hatch> haha damn
<hatch> can that be on all the time?
<bcsaller> so just never tested without
<gary_poster> yup
<bcsaller> it has to be now
<gary_poster> well
<bcsaller> thats the old version of a feature flag 
<hatch> :)
<hatch> right on
<bcsaller> but now its a real feature, all grown up
<gary_poster> heh
<hatch> good work gary :)\
<gary_poster> thanks :-)
<hatch> so.....who's gona fix? ;)
<hatch> I can do it in a bit then do the release pending CI
<hatch> well and any other obscure issues haha
<bcsaller> I have to take off in a few minutes for something or I'd offer. 
<hatch> alright I have nothing to do tonight so I'll git-r-dun!
<Makyo> Man, this reminds me of my last job in some pretty awful ways :P  Can I suggest no more Friday afternoon releases?
<bcsaller> ha, have a good weekend
<gary_poster> well, bcsaller, hatch, thank you.  mm
<hatch> Makyo: bring it up on Friday
<hatch> lol
<bcsaller> ouch
<gary_poster> Makyo, yeah, this was a extra special request for arosales
<Makyo> gary_poster, Ah, alright!  I'm all for getting things out the door, just maybe not Fridays as standard practice :)
<gary_poster> Makyo, huge +1
<gary_poster> would not have done this otherwise
<Makyo> Old job was Fridays at 11PM, on call until Monday at 5AM. 
<gary_poster> heh
<gary_poster> yeah
<Makyo> They had the QA people sleeping on cots in the bathrooms testing in 6hr shifts.
<Makyo> It was nuts.
<gary_poster> wow
<hatch> ok great so I'll fix that, CI, QA, release 0.6.2
<gary_poster> yeah, I was already kind of grimacing about how this might go
<gary_poster> if this is the worst we've got...
<gary_poster> we're lucky
<gary_poster> hatch 0.7.0 pls
<gary_poster> we actually have two real features that people will care about!
<gary_poster> :-)
<gary_poster> dnd and deployer format export
<hatch> ahhh right ok cool
<gary_poster> hatch other thoughts (bcsaller if you are around feel free to disagree):
<gary_poster> (1) consider making card to rename importexport.js to dragdrop.js?
<gary_poster> (2) consider passing the flag in to the import export module and disable the file part?
<gary_poster> trying to see if it actually is separate...
<hatch> 1 - agree, will make a card
<hatch> 2 - not really sure why/when we would want to disable any of it
<gary_poster> hatch, well tbh my first concern is that I still don't understand why the import export module needs to be there.  it only has two branches to handle a drop
<gary_poster> and neither of them should be used for the charm drop
<hatch> hmm
<gary_poster> hatch, and then my second point is that neither of those branches are actually interesting if you are not using a sandbox
<gary_poster> wow, yeah
<gary_poster> you can comment out all of _handleFileDrop
<hatch> throwing this out there - it might be the preventeDefault/stopPropogation
<hatch> in _ignore on the dragover/enter
<hatch> (sorry trying to feed the dogs right now, will test soon)
<gary_poster> ok trying
<gary_poster> hatch, yes that appears to be it
<hatch> hmm that's odd
<gary_poster> hatch, so all we need to get this to work is the 
<gary_poster>               dragenter: '_ignore',
<gary_poster>               dragover: '_ignore',
<gary_poster> registration
<gary_poster> I'd prefer to move that out of the importexprt
<gary_poster> into some generic module
<hatch> yeah - I would like to know why that's required
<gary_poster> agreed
<gary_poster> hatch, you really cool with doing this?  I'll take the bullet if you need me to
<hatch> nope that's fine - I don't have anything better to do :)
<gary_poster> heh
<gary_poster> ok hatch
<gary_poster> thank you
<gary_poster> I'll try to check in with you later
<gary_poster> but thank you!
<hatch> no problem :) have a good one
#juju-gui 2013-06-29
<hatch> gary_poster: just FYI - looked at the docs, and you MUST prevent dragover to be able to drop. What a stupid spec *facepalm*
<gary_poster> hatch heh, bizarre.  so are you moving that to somewhere more general?
<hatch> I'm renaming that file to dragdrop
<hatch> and unflagging it
<gary_poster> I don't think that's an ideal solution but I am OK with it
<gary_poster> particularly under the circumstances ;-)
<gary_poster> thanks, stepping away again
<hatch> there is some funky business going on with the relations and positioning in /trunk
<hatch> that turned out to be a lot more work than I thought, going to just copy the prevent defaults into the other file
<gary_poster> hatch, funky business with relations and positioning?
<hatch> https://bugs.launchpad.net/juju-gui/+bug/1195934
<_mup_> Bug #1195934: Deploying service from dd & add causes positioning issues <juju-gui:New> <https://launchpad.net/bugs/1195934>
<hatch> see photo
<gary_poster> ugh
<hatch> that combined with the relation line issue caused by the menu makes this feel broken
<gary_poster> agree :-(
<hatch> kind of don't want to release...tbh
<gary_poster> relation line caused by menu?
<gary_poster> wait, I thought that was only on feature flag?
<hatch> nope that's everywhere
<gary_poster> !! misunderstood
<hatch> featureflag has the fix by turning off the menu
<hatch> and requring long click
<gary_poster> I see
<gary_poster> I thought that was unique to new inspector stuff
<gary_poster> hatch, scratch the release.  thank you for trying.
<hatch> that was the original idea but Makyo said it was a known bug that has somehow been reagrivated at the same time as the new inspector stuff
<gary_poster> I'll send an email to antonio and peeps and make cards and ask Makyo and benji to investigate
<gary_poster> on Monday
<hatch> alright - include in the email that he just needs to copy those two events and the ignore method over for the drop to start working on rapi
<hatch> broken trunk :-(
<Makyo> How?
<gary_poster> ack hatch.  where did you think it was best to move the two events over?
<gary_poster> Makyo don't worry about it unless you want to.  not  anything to do with you except you will be able to fix it fastest
<gary_poster> I will send a card
<gary_poster> in sum, though, three things
<Makyo> YEah, was just wondering if 'broken trunk :-(' meant something other than the cards already discussed.  Hard to tell without further explanation.
<gary_poster> 1) the drag drop issue we found with improv.  we discovered the reason and fix, but not yet in trunk.
<gary_poster> 2) bug 1195934
<hatch> well in renaming the inport/export file, I think it would make sense to move the drop handler for the service into there
<_mup_> Bug #1195934: Deploying service from dd & add causes positioning issues <juju-gui:New> <https://launchpad.net/bugs/1195934>
<gary_poster> 3) relation line gets confused when you start it from the menu now
<gary_poster> hatch how do you dupe 3?
<hatch> umm one sec I'll run through again just to be sure
<gary_poster> hatch can't dupe 3 fwiw
<gary_poster> on sandbox anyway
<Makyo> gary_poster, I've seen that one.  The mouse coordinates are being taken from the position relative to the upper-left-hand-corner of the menu.  I thooought we were passing the vis to d3.mouse, but maybe not!  I think you need to pan to reproduce, gets worse the more you pan/drag
<hatch> ahh right - I was panning but didn't even click that I was doing that
<Makyo> Because then the relative position is further away from the absolute origin of the SVG scene.
<hatch> I deploy two services, pan them into the middle, then try and create a relation from the popup menu
<hatch> then the line is all "hey I'm over here....where are you?"
<gary_poster> ack hatch, duped thanks
<hatch> I think that all 3 need to be fixed then we can release :)
<gary_poster> agreed.
<hatch> I really wanted to release but it just looks bad :)
<gary_poster> absolutely.  correct call.
<hatch> were you able to dupe #2?
<gary_poster> I think so.  definitely saw something bad.  lemme try the exact instructions...
<gary_poster> hatch duped and got variation.  recorded on bug.
<hatch> ok great thanks
<hatch> So I suppose it's finally EOD then heh I suppose at least it was a good QA session
<gary_poster> yes.  thanks again hatch.  have a good night and weekend.  You too Makyo
<Makyo> You too.
<hatch> you too! cya
#juju-gui 2013-06-30
<huwshimi> Morning
#juju-gui 2014-06-23
<rick_h_> morn huwshimi 
<huwshimi> rick_h_: Hey :)
<hatch> hey huwshimi 
<huwshimi> hatch: Hey
<hatch> glad to start the week off without an active PR? heh
<huwshimi> hatch: Yes!
<huwshimi> hatch: Thanks :)
<hatch> haha np
<hatch> there was one small cleanup I wanted but i think kyle is going to add it to his branch
<hatch> he found a bug with his branch that he said he was going to fix over the weekend but I haven't seen it land yet
<huwshimi> yeah
<hatch> I just updated the PR with the bug he found for others....I guess he didn't add the comment afterall
<rick_h_> huwshimi: getting the next set of cards lined up in the backlog/on deck for the next 2wk cycle
<rick_h_> huwshimi: let me know if anything seems odd or there's anything missing we don't have cards for that we should
<huwshimi> rick_h_: Ah great, I'll have a look
<rick_h_> huwshimi: I think this next 2wk cycle is mainly around the updated scale up journey and the 'change version' update and really we're finishing/polishing it seems. 
<huwshimi> yay!
<rick_h_> huwshimi: so shatter my dreams of having this become a scaled back 'polish' task after this 2wk iteration if you can think of anything :) 
<rick_h_> but better now than later
<huwshimi> ok :)
<hatch> haha
<hatch> rick_h_ have you ever used `setcap` http://linux.die.net/man/8/setcap ?
<rick_h_> hatch: nope
<hatch> rick_h_ darn, I'm having a hard time trying to figure out how it'll help me use port 80 in the ghost charm https://bugs.launchpad.net/charms/+bug/1229377/comments/7
<_mup_> Bug #1229377: Charm needed: Ghost blogging platform <Juju Charms Collection:Fix Committed by hatch> <https://launchpad.net/bugs/1229377>
<rick_h_> hatch: why not just have apache/proxy requirement for port 80?
<hatch> rick_h_ currently, that's what it is - but until bundles become first class citizens in juju it's not a perfect experience if the user doesn't fully read the readme
<hatch> and I really don't want to build in nginx or the sort
<rick_h_> hatch: hmm, ok guess. Most frameworks default to a non-80 port though, but yea it'd be cool to support
<rick_h_> hatch: so since hooks run as root why not just have root bind and run with it
<rick_h_> ?
<hatch> a previous comment said that ghost shouldn't run as root
<hatch> it's been quite confusing
<hatch> don't use root, use port 80...ahhhhh
<hatch> lol
<rick_h_> well, if it's run in a container/etc then what's the issue?
<rick_h_> I'd push back and ask for an example charm that does this without running as root. What does wordpress use? 
<hatch> I think it has apache running inside or something
<hatch> I have pushed back on the port 80 requirement
<huwshimi> rick_h_: There are a few things in Luca's QA doc that don't have cards: https://docs.google.com/a/canonical.com/document/d/1p-wPlgVqZoYlMRuChLpAjkJAKZcw-wkSZfs6deIWmc8/edit
<hatch> so hopefully they let it in
<rick_h_> huwshimi: onboarding is saved for last
<rick_h_> huwshimi: and some of these I think are fixed released. Will go back through it
<huwshimi> rick_h_: Things like the popover size controls
<huwshimi> rick_h_: close controls on the summary
<huwshimi> rick_h_: I can add cards for the ones I know are missing if you like?
<rick_h_> huwshimi: hmm, thought those were the cards in backlog
<rick_h_> huwshimi: yea, those are in the backlog on deck
<huwshimi> oh yeah that's there
<rick_h_> huwshimi: but do feel free to add anything you see missing that's not fixed already
<huwshimi> ok sure
<huwshimi> rick_h_: I'll start picking up some of those backlog cards today as I'm nearly done here.
<rick_h_> huwshimi: oh ok, I was going to mention it but you had a card in 'branch start' so figured you were set
<rick_h_> huwshimi: but definitely, grab any on deck if you're free
<huwshimi> great
<hatch> huwshimi did the review on your branch
<hatch> you seem to be getting the hand of this js thing :)
<huwshimi> hatch: Ah brilliant thanks.
<hatch> s/hand/hang
<huwshimi> hatch: Would you prefer a switch?
<hatch> 6:1 6:12 of another :)
<hatch> I think a switch would minify smaller
<hatch> I would probably go with a switch if I was doing it, but the benefit would be negligible 
<hatch> :)
<huwshimi> hatch: Sure, I'll change it :)
<hatch> hah ok cool
<huwshimi> hatch: Ugh, 'this' isn't passed into switch cases? Yay!
<hatch> :) if it's gona be too much of a pita you don't have to do it 
<huwshimi> hatch: Ah, no, I forgot to pass this to the new forEach
<huwshimi> hatch: Changes are up if you want to take a look: https://github.com/juju/juju-gui/pull/398
<hatch> cool looking
<hatch> looks good
<huwshimi> great
<huwshimi> thanks!
<hatch> huwshimi I set up to re-run your merge
<huwshimi> hatch: Ah thanks
<hatch> it failed with a intermittent error
<huwshimi> hatch: We seem to have a lot of those
<hatch> dont I know it!
<hatch> huwshimi the other branch failed with the same error
<huwshimi> hatch: Yay!
<hatch> it looks like saucelabs might be borked
<huwshimi> Yay!
<hatch> I can try and land them in the morning
<huwshimi> thanks
<hatch> annnnd I'm out, have a good one
<rogpeppe1> mornin' all
<rick_h_> morning party people
 * rogpeppe1 lunches
<hazmat> why is charm config read only during deploy?
<hazmat> also why do interfaces/relations not show for a  deployed charm?
<hazmat> oh.. you have to explicitly select not default configuration..
<hazmat> odd
<rick_h_> hazmat: charm config is getting updated and we're looking at pulling that read-only bit
<rick_h_> hazmat: the thought was that the defaults should be sane and to make it as clean/few things to click on as possible to get deployed/going
<rick_h_> hazmat: but we've got work this 2wk cycle to update that
<rick_h_> hazmat: and for interfaces/relations, no idea. I guess by clicking the charm you can see what to relate to. Constructed relations show in the tab for them
<rick_h_> but never really had relation info, not sure if we get that from the charm data from the env or not. 
<hazmat> rick_h_, ie. i've deployed nova-compute.. charm details on it, doesn't show the related/interface tab
<hazmat> charm browser does..
<rick_h_> hazmat: yea, because we don't have the data from the charm model data from the environment so we scope down the tabs to match the data we have
<hazmat> rick_h_, we do get interfaces/relations from env.. (not related though)
<rick_h_> hazmat: with the work in progress to add the data/update the apis to the juju store we'll be able to update that
<rick_h_> hazmat: right, we don't have the info to build that tab. We didn't have any request/requirement to build an alt UI to that tab
<hazmat> rick_h_, this is part of the charm definition.. doesn't need the store to display named rels and interfaces
<hazmat> its available in the charm info api off the env
<rick_h_> hazmat: right, sorry. You're right that we have the end points, but the api doesn't match the info to build the UI. It needs updating to work for deployed charms. 
<rick_h_> hazmat: and just never been asked for or thought about to be honest. 
<hazmat> seems like a basic usability bit.. ie. i've got x deployed, what can i do with it (what else do i need to deploy)
<rick_h_> hazmat: right, there's work in the machine view stuff to update the inspector to show 'popular relatable charms'
<rick_h_> and moving config to it's own tab. I'll file a bug on the tab though for deployed charms 
<rick_h_> hazmat: https://bugs.launchpad.net/juju-gui/+bug/1333258
<_mup_> Bug #1333258: gui does not show related charms tab for deployed charms <juju-gui:Triaged> <https://launchpad.net/bugs/1333258>
<hatch> morning all
<rick_h_> party
<hatch> so party
<bac> rick_h_: i submitted a vacation day request
<rick_h_> bac: k thanks. hatch sent me an email as well will get those in
<hatch> w00t
<rick_h_> jujugui any time off the next 2 weeks please submit so we can plan cards for the 2wk sprint
 * hatch isn't sure if new system is better than old system
<hatch> :P
<bac> hatch: yeah.
<bac> be aware, if you click on the big calendar to start a new request, it pre-populates not with the date you clicked on but with today's date.  sneaky.
<hatch> I suppose this new one actually allows you to go back and modify things
<hatch> that almost makes up for the scheduled downtime that seems to be a feature in the salesforce world lol
<bac> jujugui: does anyone know if the new HR system allows you to see a calendar for colleague's work schedule? i can't find it.
<hatch> yep
<hatch> go to Team Members
<hatch> Paid Time Off
<hatch> then click on the team members face
<hatch> you can also change the level of PTO.....I always change it to level 10.....( I don't think this does anything but I feel special at level 10 days off ) :D
<hazmat> rick_h_, thanks
<bac> rick_h_: i'm going to be traveling on the thursday before the sprint, the 17th. mark that as a swap day so you'll see i'm unavailable?
<rick_h_> bac: sure, works for me. 
<bac> hatch: that works but you can't see schedule for people not on the team
<hatch> ohh, I suppose - could you with the old one? I never tried
<hatch> tbh
<hatch> jujugui in ecs mode do we really need to confirm removing relations? Or can we just do it and then they can add it back in before hitting commit if they did it by accident (somehow)
<rick_h_> hatch: you mean do we need to ecs remove relation at all?
<hatch> no, there is a dialogue that pops up asking you to confirm that you want to remove the relation
<rick_h_> hatch: ah, no. I'd assume that no we'd not need to
<rick_h_> we should ping UX though on how to represent a removed relation in the canvas. I feel like that's a whole in the UX
<hatch> good point, I'll fire off an email
<rick_h_> bac: pm
<Makyo> jujugui call in 10
<rick_h_> get your planning poker buzzers ready!
<hatch> 3
<hatch> 2
<hatch> 4
<hatch> 4
<hatch> 4
<hatch> 1
<hatch> 2
<hatch> 3
<hatch> *phew*
<hatch> ok warmed up
<rick_h_> jujugui call in 1
<rick_h_> antdillon: ^
<hatch__> kadams54 http://fromanegg.com/post/67170468715/intro-to-go-from-a-javascript-developer-barcamp-yxe
<hatch> kadams54 of course there was a whole spoken track which outlined the differences while showing it in go
<kadams54> 813345
<kadams54> hah!
<kadams54> hatch: Thanks, looks like some good material.
<hatch> yeah the talk got good ratings in the reviews 
<hatch> ugh Ci
<hatch> rick_h_ I wonder if we used a bigger instance for our CI if we would end up with the same issues
<hatch> kadams54 I re-triggered the merge run for #399
<kadams54> 859619
<hatch> 368718641818143813
<hatch> I win
<kadams54> Man, I gotta quit doing that.
<hatch> lol!
<kadams54> hatch: thanks
<hatch> I'm thinking of painting the edge of mine with some clear nail polish and only leaving a small sliver open
<hatch> then it can't be hit as easy
<hatch> going to try it first with some tape
<rick_h_> hatch: it's a big instance currently
<hatch> rick_h_ interesting - I'm just wondering why the http requests are so.....darn......slow......
<kadams54> dilrklkdecijlvjntbluutlkffgkbebjfbfvlr
<hatch> rofl
<rick_h_> hatch: it's 4 cores and 8gb of ram
<hatch> rick_h_ lol what the heck
<hatch> blame java?
<hatch> :D
<rick_h_> hatch: :)
<hatch> everyone, in your local laws do you have a legal limit of .04 BAC for driving? 
<rick_h_> hatch: .08
<hatch> ours are changing to .04 and the penalties are bonkers imho
<rick_h_> hatch: with .02 for < 21yrs old and .17 is bad bad times
<hatch> I've tweeted at the govt asking for statistics 
<hatch> http://www.sgi.sk.ca/about/articles/2014/trafficsafetychanges.html
<hatch> http://www.sgi.sk.ca/images/0-content-pages/2014_consequences_660.jpg
<rick_h_> well, I'm always for locking that down imo. Too many people, my family especially, going about :/
<hatch> I'm very very skeptical that it will help anything
<hatch> .04 is one beer after work
<rick_h_> http://www.michigan.gov/msp/0,4643,7-123-64773_22774-49577--,00.html
<hatch> right, but what those stats dont' say is the BAC of the person
<hatch> just that they were alcohol related
<hatch> that's the problem with all of these stats they are missing the details
<hatch> rick_h_ lol 289,000 crashes.....in a year???
<rick_h_> hatch: for our one steate
<rick_h_> state
<hatch> jeebus you guys like your booze 
<hatch> lol
<hatch> maybe you should drop yours to .04 :P
<rick_h_> :)
 * hatch says that while he waits for his own traffic stats
<hatch> ""Michigan law enforcement agencies arrest an average of 103 motorists a day for drunk and impaired driving.""
<hatch> wow!
<hatch> I am kind of guessing that those stats as a % are not outliers and each state/prov probably follows similar stats
<rick_h_> well I think it does depend on states
<rick_h_> driving, the types of driving, conditions, etc
<rick_h_> michigan with the snow/ice seasons, the overall rush/poor driving, really poor roads. I'd expect us to be towards the upper 10%
<hatch> I suppose worse conditions would increase the probability that an impaired driver would crash
<rick_h_> right
<rick_h_> and get noticed/pulled over/etc
<hatch> true true - I drove around a lot this weekend, people don't need any help driving like idiots 
<hatch> lol
<rick_h_> jujugui heads up the board is ready for the cycle. We almost hit planned counts and had a little over 20% unsched work. 
<hatch> really? awesome - I thought we were sunk :)
<hatch> go us!
<rick_h_> well last cycle I over sub'd the board a bit to get a feel for the bigger team size and the blues is a lot of unknowns
<rick_h_> so the board wasn't a good indicator, but all good
<rick_h_> this time we're right on, so should be good and if the new starters help with any of it we should be golden. 
<hatch> great
<hatch> jujugui fyi 'make devel' almost works 100% on osx :)
<rick_h_> lol
<hatch> rick_h_ just reviewed Huw's latest branch, needs a touch of work so I'm sure he'll get it landed early his morning
<rick_h_> hatch: rgr, ty much
<rick_h_> bac: rogpeppe can you guys take a peek at https://github.com/juju/charmstore/pull/6 when you get a few mins and make sure that makes sense?
<rogpeppe> rick_h_: i'm pretty much at eod, but i'll try to take a look
<rick_h_> rogpeppe: tomorrow is ok
<rick_h_> rogpeppe: just on the radar. with francesco out and bac getting up to speed going to lean on you for review help
<bac> rick_h_: will do
<hatch> jujugui - if I tell juju-core to delete a machine which has a number of containers in it (via the api) will it auto tear down the containers or will it throw an error?
<rogpeppe> hatch: i'm not sure
<rogpeppe> hatch: there has been some debate about the desired semantics there
<hatch> ok - at the moment for the ecs I'm going to assume that any delete operation will 'just work' and we can re-evaluate later I suppose. 
<rick_h_> hatch: throw up a branch on ec2 and let's see?
<rogpeppe> hatch: personally i would prefer the former, but some people want things to be more explicit because you might be tearing down important stuff
<hatch> rick_h_ I'm not sure how to easily simulate an api call through the gui
<rogpeppe> hatch: it shouldn't be hard to try it out
<hatch> 'easily' being the key word there
<rick_h_> hatch: we have the api calls, just need to console.log to find and build the right call?
<bac> rick_h_: i looked at cmars PR.  it may be good as a first start but i think webops is leaning towards storing dependencies in an S3 bucket for prodstack deploys rather than bundling.
 * bac wishes jcsackett were around
<hatch> rick_h_ rogpeppe I think I found my answer in the gui source 
<hatch>       @param {Boolean} force Whether to force machines removal even if they
<hatch>         host units or containers.
<rick_h_> bac: oh didn't realize that. Good to know I guess. So for deploying we need a step to get deps into the private space s3 bucket?
<rogpeppe> hatch: cool
<bac> rick_h_: yes.  i'll check with sinzui to see how they've set things up
<rick_h_> bac: ok cool. 
 * rogpeppe is done for the day
<rogpeppe> g'night all
<bac> bye rogpeppe
<hatch> heh state bites again...oops https://bugs.launchpad.net/juju-gui/+bug/1333376
<_mup_> Bug #1333376: Clicking links in relation dialogue shows inspector under charmbrowser headers <juju-gui:New> <https://launchpad.net/bugs/1333376>
<hatch> hmm, we need ghost-service-name to service-name utilities 
<rick_h_> hatch: yea, we dance around that and probably needs to be more formal
<hatch> atm removing a ghost relation between two ghost services fails because of that
<hatch> I'm investigating but it might be a follow-up
<rick_h_> hatch: rgr
<hatch> yep follow-up Ill create a bug
<kadams54> hatch: https://github.com/juju/juju-gui/pull/393 should be QA-able again. Also addressed review issues.
<hatch> ok looking
<hatch> ugh github 'expand' buttons aren't working
<hatch> this is makign this review very difficult
<hatch> well I totally borked my develop branch...
<rick_h_> stop doing that hatch 
<hatch> but it's so funnnnn
<hatch> ugh git
<hatch> ok NOW I can qa the branch
<hatch> kadams54 (Note: should this link be hidden when a machine is not selected?) <--- you should send an email to design and create a bug/card to track the response so we don't forget about it
<kadams54> Will do
<hatch> is clicking create supposed to close the create-machine box?
<kadams54> hatch: Yes. Close the form, create the machine.
<kadams54> The mocks don't have the form sticking around after machine creationâ¦ unless I'm misunderstanding?
<hatch> see the qa issue in your PR
<hatch> kadams54 if I create a machine, then drag a unit to that machine my only options are lxc or kvm, so I can't put it on bare metal....is this by design because it feels like a bug?
<hatch> I'll add it as a qa issue in the PR 
<hatch> kadams54 ok qa done
<bac> hi rick_h_, do you have some time to talk?
<rick_h_> bac: in 10?
<bac> sure. ping when free
<rick_h_> bac: ping freee! told ramm I had important calls to make :)
<bac> ha.
<bac> standup
<rick_h_> rgr
<hatch> I wonder if i could hire an intern to write tests for me
<kadams54> testern
<hatch> lol
<hatch> that
<hatch> it would actually be a great education
<rick_h_> hatch: but you've gotten so much better at writing them :P
<hatch> haha
<hatch> I could then pass this knowledge on
<hatch> !
<rick_h_> there you go, hatch the test teacher
<rick_h_> here's your 'homework' and make sure it's done by tomorrow so I can get my code review in
<hatch> lol
<hatch> exactly
<hatch> rick_h_ I think that #1333395 should be my next card after this branch lands because the relation removal story is incomplete/broken until then
<_mup_> Bug #1333395: Cannot delete ghost relation between two ghost services <juju-gui:Triaged> <https://launchpad.net/bugs/1333395>
<bac> rick_h_: is there a plan for local charm support in bundles? i know we've talked about it but i'm unclear about the decision/roadmap
<rick_h_> bac: we've talked about a lot of them to be honest. No one is settled on at the moment. 
<rick_h_> hatch: ok
<rick_h_> hatch: makes sense
<rick_h_> bac: if there's a store in every environment out of the box, then you'd just publish to your environment. 
<rick_h_> bac: or there's some bugs to work out around juju-core and versioning to make bundles work in the current form 
<rick_h_> bac: and then there's resources/fat charms/bundles that could be used to solve the problems
<rick_h_> but that's not on the current todo list
<bac> rick_h_: gotcha.
 * rick_h_ runs away for the day
<rick_h_> evening all
<hatch> lata!
<hatch> Makyo any idea where the add relation tests are? There are the add_relation tests for non mv in test_env_go but I don't see any which test the mv path
<Makyo> one sec.
<hatch> thanks
<Makyo> test_env_change_set.js:462 (I think that's what you're looking for, correct me if not)
<hatch> well that tests the change set stuff - but nothing that the actual call to the go env ends up in the ecs
<hatch> I was looking for something to copy....lol
<hatch> maybe it was just overlooked?
<Makyo> Not sure..
<hatch> oh well no problem
<huwshimi> Morning
<rick_h_> morning huwshimi 
<huwshimi> rick_h_: Hey
#juju-gui 2014-06-24
<hatch> hey huwshimi 
<huwshimi> hatch: Ye
<huwshimi> *Hey
<huwshimi> typing
<hatch> lol
<hatch> crap CI hung on your build
<hatch> huwshimi so in your branch you still have the min/mid/max classes - are those used somewhere?
<hatch> https://github.com/juju/juju-gui/pull/400/files#diff-225b0a8e53f0646bec2686e3d713bbd5R37
<hatch> that line for example
<hatch> rick_h_ u on?
<huwshimi> hatch: They're not, but I'm expecting to use them in another branch. I can remove them from this one if you like?
<hatch> no it's ok as long as you know you'll use them
<huwshimi> yep
<hatch> ok +1'd
<hatch> you can land it whwnever
<huwshimi> hatch: Thanks!
<rick_h_> hatch: what's up?
<hatch> rick_h_ oh hey, the PR ci will need restarting
<hatch> I was just about to grab the info
<hatch> :)
<rick_h_> hatch: gotcha, sec
<rick_h_> hatch: I only see the prod one going
<rick_h_> hatch: and that's in a test run to land
<hatch> rick_h_ yeah I had to kill the one in the pr lane because it hung
<hatch> so it will likely still be running...no?
<rick_h_> hmm, tests are running atm
<rick_h_> hmm, maybe it's this other one
<hatch> right - not the landing script
<hatch> the pr one
<rick_h_> ok, killed one
<rick_h_> hopefully that's the right one :)
<hatch> haha we'll know shortly!
<hatch> maybe this weekend I'll find some time to add the 'if running KILL IT DEAD' mode :)
<rick_h_> it's supposed to do that :P
<rick_h_> (cd build-prod && \ python ../bin/http_server.py 8888 2> /dev/null & \ echo $!>ci-check-gui-server.pid)
<hatch> oh haha - well then, why does it give the ERADDRINUSE issue?
<hatch> ohhh
<hatch> that's not checking the node server
<rick_h_> echo ci-check-gui-server.pid
<rick_h_> ci-check-gui-server.pid
<rick_h_> cat ci-check-gui-server.pid
<rick_h_> 4360
<rick_h_> kill `cat ci-check-gui-server.pid`
<rick_h_> rm ci-check-gui-server.pid
<rick_h_> hatch: oh hmm, yea then maybe it needs more of it 
<hatch> yeah I think it's the node server that throws the error
<rick_h_> gotcha, yea well happy to run more pid/pid-checking to help it
<rick_h_> doens't happen too often thankfully. 
<rick_h_> hatch: you hatch on launchpad?
<hatch> yep
<rick_h_> you're a rude man making me look it up on LP hatch :P
<rick_h_> ok, you've got ssh rights. ssh ubuntu@ci.jujugui.org
<hatch> lol sorry I was in the other room
<rick_h_> don't mess up my server or I'll have to come to canada and drop you down a hole in the ground
<hatch> lol yeah I wont be at it until this weekend for sure
<rick_h_> at what?
<rick_h_> you not in canada right now?
<hatch> haha of course I am
<hatch> I meant, I won't be breaking your server until this weekend
<rick_h_> well don't do that!
<hatch> :)
<hatch> Ooo nice new column in the board
<rogpeppe> mornin' all
<huwshimi> rogpeppe: Morning
<rogpeppe> huwshimi: hiya
<rick_h_> morning
<rogpeppe> rick_h_: hiys
<rogpeppe> hiya
<rogpeppe> even
<rick_h_> rogpeppe: howdy
<rogpeppe> rick_h_: the bundles parsing/verification PR is up at https://github.com/juju/charm/pull/9
<rick_h_> rogpeppe: cool looking. 
<rogpeppe> rick_h_: it does all the internal verification, but doesn't verify against actual charms
<rick_h_> rogpeppe: ok, can you create a bug/additional card to look into that part?
<rogpeppe> rick_h_: ok, will do
<rick_h_> rogpeppe: we're thinking that'd part of the publish side of things?
<rick_h_> vs part of the actual model side here
<rogpeppe> rick_h_: i'm thinking that it can live inside the charm package
<rick_h_> outside you mean?
<rogpeppe> rick_h_: no, inside
<rogpeppe> rick_h_: something like BundleData.VerifyWithCharms([]*Charm) error
<rogpeppe> rick_h_: which means it can be called by any client that happens to know the charms that the bundle service charm urls resolve to
<rick_h_> rogpeppe: ok, looking through this pr and will see how it fits
<rogpeppe> rick_h_: thanks
<rick_h_> rogpeppe: how does such 'combining of errors' work? They're basically complete sentences. How does one take them and combine them more than just listing them out? Does it ', and' each or anything as part of this common practice?
<rogpeppe> rick_h_: usually it just involves prefixing "something happened: " onto an existing error
<rogpeppe> rick_h_: in this case, the final error might look something like "cannot verify bundle: placement "foo:bar" refers to non-existent service (and 303 more errors)"
<rick_h_> rogpeppe: ok, but then we need to make sure to update the clients cli and webui to do this post processing. It seems like adding more places to catch the update than to make it work right
<rogpeppe> rick_h_: all errors returned by the API are currently without capitals or periods
<rogpeppe> rick_h_: so this just continues in the same vein
<rick_h_> rogpeppe: right, and we've had to do work in the gui to try to parse them and make them presentable
<rick_h_> rogpeppe: right, it's an existing issue I'm bringing up potentially attempting to address while we're here in the code
<rogpeppe> rick_h_: if we're going to change that, i'd prefer to change the entire API
<rogpeppe> rick_h_: rather than adding a single inconsisent place
<rogpeppe> inconsistent
<rick_h_> heh count me in :) but we're in control of this bit of code and we know that errors parsing the bundles will need to get in front of the users 
<rick_h_> so they can debug and fix them
<rogpeppe> rick_h_: consistency trumps convenience IMHO in this case
<rick_h_> rogpeppe: ok, then we should add cards for the core cli and the gui to update bundle errors when connect to the updated store so that we don't lose track of known usability issues that we should correct. 
<rick_h_> maybe bugs would be better since they can't be updated until a store update is deployed and used 
<rogpeppe> rick_h_: i'm not entirely sure it's a CLI issue - errors are currently printed in lowercase
<rogpeppe> rick_h_: but i'll add an issue to the gui. are gui issues tracked in lp ?
<rick_h_> Why would it be good to make the error message a complete english thought with proper writing in one place and not the other? 
<rick_h_> rogpeppe: yes, they are
<rogpeppe> rick_h_: mainly because many things on the unix command line print stuff in lower case - there's honourable precedent :-)
<rogpeppe> rick_h_: and it's less code, which is always a win in my book :-)
<bac> rogpeppe: i've got the latest charmstore and tried to run 'make check' but get errors referencing missing testing items like MgoSuite, etc.
 * rogpeppe goes to see what make check does
<rogpeppe> bac: for the record, when dealing with go packages, i almost never run make
<rick_h_> rogpeppe: but through CI and such make is the single interface all devs can use to hack/operate
<rogpeppe> rick_h_: sure, it's useful for CI
<rick_h_> rogpeppe: the make targets need to be valid and make check is the common target in all proejcts for a CI-like run through lint, test, etc
<rick_h_> so in QA it's quite common to make check, make run, and then qa
<bac> rogpeppe: i'm just looking at the README and it references 'make check'
<rogpeppe> bac: ok
<rogpeppe> bac: have you tried doing: godeps -u dependencies.tsv ?
<rogpeppe> bac: it all seems to work for me
<rogpeppe> bac: could you paste the exact errors you get?
<bac> rogpeppe: https://pastebin.canonical.com/112262/
<rogpeppe> bac: hmm, odd.
<rogpeppe> bac: could you try doing "rm -r $GOPATH/pkg" then "go install ./..." and trying again?
<bac> rogpeppe: from inside the charmstore directory?
<rogpeppe> bac: yes
<bac> rogpeppe: didn't help.  what version of juju/testing do you have? mine is b09...
<rogpeppe> bac: b0941ff1bf4d3db1ffbbe09f75fa8383eae5764c
<bac> same
<rogpeppe> bac: do you see the same thing if you just run "go test" (in the same dir)
<bac> rogpeppe: yes, and it is unsurprising.  if i look in juju/testing i see no MgoSuite anywhere
<kadams54> Juju GUI architecture question: how do we connect to the juju state server?
<rick_h_> kadams54: websocket
<hatch> via websocket
<hatch> and magic 
<bac> rogpeppe: if you look in juju/testing where do you find those defined?
 * hatch shakes hands in the air
<rick_h_> lots of magic
<hatch> *magic*
<rogpeppe> bac: in mgo.go
<kadams54> rick_h_: Where at in the code?
<hatch> heh well....
<rogpeppe> bac: what do you see if you run "git status" in the juju/testing dir?
<hatch> kadams54 I can get you the loc, one sec
<bac> clean
<bac> rogpeppe: there is no mgo.go in my juju/testing
<hatch> kadams54 here is the websocket instance https://github.com/juju/juju-gui/blob/develop/app/store/env/base.js#L234
<rogpeppe> bac: could you paste the entire output of your "git status" please?
<hatch> kadams54 here is where we make the requests https://github.com/juju/juju-gui/blob/develop/app/store/env/go.js#L181
<hatch> kadams54 did you have a specific question in mind?
<bac> rogpeppe: i went to my juju/testing and did a 'git pull' and it got the mgo.go file along with lots of others.  why did the 'go get -u' and the 'godeps' not update it?
<rogpeppe> bac: i don't know - that's why i wanted to see exactly what git status printed for you
<kadams54> hatch: that satisfies my curiosity for now, thanks
<rogpeppe> bac: AFAIK go get -u just does a git pull
<bac> rogpeppe: this is what git status said before i did the manual pull: https://pastebin.canonical.com/112263/
<rogpeppe> bac: thanks. i've no idea then. "go get -u" just runs "git pull --ff-only"
<hatch> kadams54 np
<bac> rogpeppe: i'm going to blow away everything and try again
<hatch> hey cory_fu 
<rogpeppe> bac: that can be a good plan...
<rogpeppe> bac: have you tried testing again now that you did the pull?
<bac> well i just want to see if it is reproducible
<rogpeppe> bac: wait!
<bac> rogpeppe: i did and it passed
<rogpeppe> bac: what does "git remote -v" print for you in the juju/testing dir?
<rogpeppe> bac: too late...
<rogpeppe> bac: darn
<rogpeppe> but... it printed the right head
<kadams54> Hey, who should we be sending design/UX questions to right now? Luca's out, right?
<rogpeppe> jeeze, i dunno
<hatch> kadams54 spencer
<rick_h_> jujugui call in 9
<bac> wow, crazy loud tsunami drill.  i guess that's what you want from a tsunami alarm.
<hatch> what does one do when a tsunami alarm rings? Run inland? 
<bac> rogpeppe: so you'll know, i'm trying to set up and test the charmstore as we'd do for CI.  it looks like we have some problems with our dependencies. here's what i've done (mainly as stated in the README) : https://pastebin.canonical.com/112265/
<makyo_> jujugui call in 2
<bac> run downstairs, grab beer and camera, then go to the roof.
<rogpeppe> bac: you need to do go get -t
<hatch> ahh to the roof
<hatch> I guess that makes sense :)
<bac> rogpeppe: go get -t -v github.com/juju/charmstore  ???
<rogpeppe> bac: in full, you'd need to run: go get -v -t -u github.com/juju/charmstore/...
<rogpeppe> bac: the final "/..." is important
<rogpeppe> bac: otherwise you won't get deps for subdirs
<rick_h_> jujugui call now 
<kadams54> hatch: https://github.com/juju/juju-gui/pull/393 is ready for QA again. I want to hold off on sending this e-mail until this branch is landed and you can see stuff working/not working on upcoming.
<kadams54> Here are the questions I'm planning on sending out, in case you want to review: https://gist.github.com/kadams54/681a40f7bd9d603a53bb
<cory_fu> So, I'm still trying to understand how juju-gui connects back to the juju state server.
<cory_fu> I thought maybe https://github.com/juju/juju-gui/blob/develop/app/app.js#L382 was where it got the address of the state server, but that just seems to be the connection to the GUI backend?
<kadams54> cory_fu was unsatisfied with the "magic" explanation.
<cory_fu> :)
<bac> rogpeppe: adding the -t worked.  i'll update the readme
<rogpeppe> bac: thanks
<bac> rogpeppe: yeah, the ... was important too
<kadams54> 948647
<kadams54> ccccccdilrklllutrivjhvjttuigtldiclbejkuderdh
<kadams54> Alright, that's it
<cory_fu> I'm failing to understand how it can be using the public address for the juju-gui unit yet still have commands get to the state machine on machine 0
<kadams54> ccccccdilrklnvjvvhbrtekkhcebgrrjeejurdfdvuvc
<kadams54> guihelp: --^ (cory_fu, not my yubi spam)
<cory_fu> kadams54: You don't have another USB slot more out of the way?  :)
<cory_fu> Oh, yeah, thanks
<hatch> cory_fu I'm not sure the question
<kadams54> I realized what it is - when I'm cmd-tabbing, my pinkie is right over that USB slot. I may try the other one.
<hatch> cory_fu kadams54  we don't connect directly to the juju state server
<hatch> we connect to the gui server
<cory_fu> hatch: Ok, so I need to know how the GUI server talks to the state server
<hatch> it also uses websocket but from a python server
<hatch> http://bazaar.launchpad.net/~juju-gui-charmers/charms/precise/juju-gui/trunk/files
<hatch> that's the charm source
<hatch> cory_fu so are you trying to write your own application with communicates with the state server?
<cory_fu> hatch: Yeah.  I'm working on the Cloud Foundry charm and it turns out we're going to need to communicate with the state server, similar to how the GUI does
<hatch> ok there is api documentation around that....
<hatch> one sec I'll see if I can find it
<hatch> at least I thought there was....
<cory_fu> Ah.  I found what I needed.  :)
<rick_h_> cory_fu: yes, the gui talks to the guiserver in the charm
<rick_h_> cory_fu: and then it proxies all requests to the state server and intercepts a couple of special api calls like bundle deploys that juju doens't natively handle
<cory_fu> Ok.  That's basically what I expected.  Thanks.  :)
<hatch> cory_fu perfect....where was it ? 
<hatch> hah
<rick_h_> oh heh, hatch has your back. 
<cory_fu> hatch: https://bazaar.launchpad.net/~juju-gui/charms/trusty/juju-gui/trunk/view/head:/hooks/utils.py#L140
<rick_h_> cory_fu: yea, you're looking for http://bazaar.launchpad.net/~juju-gui-charmers/charms/precise/juju-gui/trunk/files/head:/server/
<cory_fu> That function is exactly what I needed
<hatch> ahh perfect
<hatch> yeah the guy who does this work is off atm :)
<hatch> good luck with the charm
<cory_fu> Thanks.  :-)
 * rick_h_ goes to make up some lunch
<hatch> has anyone else been running into issues with yahoos cdn taking forever to respond?
<hatch> oh our test suite....
<hatch> jujugui looking for a review/qa on this first relations branch https://github.com/juju/juju-gui/pull/402
<kadams54> hatch: lookingâ¦
<hatch> thanks
<hatch> kadams54 what was the issue with the previous qa issue on your branch?
<hatch> https://github.com/kadams54/juju-gui/commit/be1356a686a51632160fae08a8570d7e59310a3a
<hatch> that commit?
<kadams54> It was the unitOrEvent variable that got renamed back to unitâ¦ it needs to be nulled out if it's actually an event rather than a unit.
<kadams54> Yeah, that commit
<hatch> ok cool - in the future can you use a real commit message :)
<hatch> review looks good, qa'ing
<hatch> kadams54 try a make clean and clean your cache (re huw's branch)
<kadams54> hatch: yeah, I did both, still seeing the funky button.
<hatch> hmm odd alright then
<hatch> kadams54 adding a container without selecting a machine is kind of odd heh
<hatch> because it creates a machine
<kadams54> Yes. There's a lot of funkiness around MV in general.
<kadams54> If you stick to the happy path, everything is all rainbows and unicorns
<kadams54> Stray off and the world goes sideways.
<hatch> ok one more small qa issue
<hatch> one of these days I'll get all of you to stop using anchor tags :D
<kadams54> Ah ha ha ha ha
<kadams54> hatch: I'm puzzled about why that's happening for "Add container", but not "Add machine" - they both have the same handler function which does preventDefault().
<kadams54> Giving span a tryâ¦
<hatch> it happens for both for me
<kadams54> What about on http://comingsoon.jujucharms.com/?
<hatch> kadams54 it might need an e.halt() 
<hatch> basically anchors are stupid
<hatch> and I'm not goign to change my mind on that :D
<kadams54> Pffft, no way!
<hatch> lol
<kadams54> Jeff would totally call that out in review.
<kadams54> ;-)
<hatch> haha 
<kadams54> Oh good gravy
<hatch> really though - anchors in a webapp are only useful if you're taking advantage of pjax
<hatch> which we aren't
<kadams54> spans don't have the right styling.
<hatch> lol
<hatch> this branch just won't die
<hatch> kadams54 try using e.halt() instead of e.preventDefault()
<hatch> jcsackett where did you use to get those shirts made up from the sprint?
<kadams54> hatch: OK, that worked - change pushed.
<hatch> even I'm getting sick of QA'ing this branch lol
<hatch> you must be right pissed
<hatch> haha
<kadams54> I'm ready to be done, for sures
<kadams54> Though I have a long list of stuff to turn into bugs and cards, so even after this one lands, it will live on.
<kadams54> And that's aside from questions to send to design.
<hatch> qa ok;d
<hatch> land that!
<hatch> kadams54 you'll probably want to move your branch-start card back and then create smaller cards from it
<kadams54> Hmmâ¦ you're talking about the deleting machines/containers one?
<hatch> yeah
<hatch> there is a lot of work there
<hatch> probably more than 4 days
<hatch> judging by how long it took me to do the relations one heh
<kadams54> OK. I already created a separate card for ghosted stuff.
<rick_h_> hatch: kadams54 sorry, just catching the conversation drive by
<rick_h_> hatch: kadams54 we do need to chat and plan out a path?
<hatch> we does
<kadams54> Sounds like it
<rick_h_> standup linky?
 * rogpeppe is done for the day
<hatch> lata rogpeppe 
<rick_h_> rogpeppe: have a good evening
<hatch> rick_h_ sure
<rogpeppe> rick_h_: see ya tomorrow
<rogpeppe> hatch: likewise
<rogpeppe> g'night all
<jcsackett> hatch: teespring.
<jcsackett> hatch: was going to build another one for the last sprint, but alas the required minimum went up.
<hatch> booo!
<hatch> well this sprint there will be more people
<hatch> hopefully I'll say something stupid again
<hatch> er....
<rick_h_> man, hatch you're making it too easy
<hatch> lol
<rick_h_> "it's not a matter of if...only a matter of when, and I want to buy the square for day #1"
<hatch> haha
<bac> rick_h_: in jenkins CI what is the authentication token?  do we just use the same one for all projects?
<rick_h_> bac: each project can define one, I've just used the same one I think on the two projects
<rick_h_> bac: but feel free to set a custom one for the store 
<bac> rick_h_: i don't understand what it is
<bac> just a string?
<rick_h_> bac: yea, just a private string
<bac> pertaining to nothing?
<bac> what is the point?
<rick_h_> bac: in order to trigger a build via a url call (poor man's api) you can use the token to limit who can trigger a build
<rick_h_> bac: it's like a shared secret kind of auth or poor man's api token
 * bac feels safer
<rick_h_> bac: actually not sure if the lander supports a key per project. :/ 
 * rick_h_ checks code
<rick_h_> bac: so it might need to be the same for the moment
<bac> rick_h_: doesn't matter, i'll just use the same one
<rick_h_> bac: ok cool
<bac> rick_h_: and for each jenkins test run do i get a new "machine"?
<rick_h_> bac: no
<rick_h_> bac: not currently, we've not had to. That's something we might have to think about. I know the juju ci does create slave machines to test on
<rick_h_> bac: I'd suggets we work with them on that side so that they can bring up machines across platforms, but we have a more simple sanity check for work. 
<bac> rick_h_: ugh, i just edited the juju-github-lander test script when i thought i was editing charmstore's.
<bac> rick_h_: anyway to revert?
<rick_h_> bac: no, there's a backup script that runs but not a good way to revert as the ini file isn't part of the lander's github project
<bac> dang
<rick_h_> bac: oh you mean in the build steps in the jenkins UI?
<bac> rick_h_: yeah
<rick_h_> bac: yea, no good way to restore without pita backup xml fun
<bac> i replaced 'make test, blah blah' with the steps for charmstore
<rick_h_> we have a full backup for doing a full restore but not easy to get 'this field'
<bac> rick_h_: ok, i'll look at the makefile and see if i can figure it out
<rick_h_> bac: hmm, yea it should be close to the other job
<rick_h_> bac: which job did you edit?
<bac> jenkins-github-lander
<bac> http://ci.jujugui.org:8080/job/jenkins-github-lander/configure
<rick_h_> bac: ah ok, I'll update
<bac> make testdeps; make lint; make test
<bac> ??
<rick_h_> bac: updated, copied from the -merge version of the job
<bac> oh cool
<rick_h_> just removed the landing stage
<rick_h_> having two jobs is a bonus sometimes :)
<bac> rick_h_: for jenkins we specify the sha1 of the commit to test.  is that the sha of the branch that has been proposed? e.g. https://github.com/bac/charmstore/commit/7d8c2efae2517c3d1e01d8f686223d3a9ad1420c
<bac> rick_h_: if it gets that sha at the end of the url, but doesn't know about the specific user, it can fetch it from github?
<rick_h_> bac: yes, git watches the list of branches in the pr namespace and knows how to check out each commit sha 
<rick_h_> bac: so you can give it any commit in any pr and it'll checkout/test that sha
<bac> nice
<rick_h_> normally it just gets the latest sha in the pr
<hatch> kadams54 did you review/qa my branch yet?
<kadams54> In progress right now.
<hatch> cool thx, i'm gona go grab some lunch
<hatch> mmm check this out! http://www.withings.com/activite/en-US me wants
<hatch> well except that it doesn't work with android
<rick_h_> so I just watched a video and don't know anything more than when I started
<hatch> rofl
<hatch> I thought the same thing haha
<rick_h_> it's a pretty fitbit?
<hatch> yep
<rick_h_> pass, I <3 my pebble steel
<hatch> basically by the time it's released I will have forgotten about it
<hatch> oh well
<hatch> I want the Google watch
<rick_h_> got a new awesome watch face that is nice and clean
<hatch> that thing is darn cool
<rick_h_> heh, that one will be tough. I'll be darn tempted to get my google now on my wrist
<rick_h_> but I think that'll definitely a gen2 switch over
<hatch> I'm kind of hoping they release it tomorrow, I'll be staring at my screen with my cc in hand waiting during the keynote
<rick_h_> heh, I was glad I had no calls at noon 
<rick_h_> you can be sure the chromecasts in the house will be watching the keynote
<hatch> of course it won't be available in Canada...so I'll have to have you buy it for me
<hatch> lol
<rick_h_> works for me
<rick_h_> when two of them show up I'll just tell the wife I was getting it for you
<rick_h_> and hide the other one :)
<hatch> hahaha
<hatch> there was a watch face competition for that watch....
<hatch> I +1'd a couple....now where do they keep these +1's
<hatch> hmm empty...
<hatch> that's not right
<hatch> https://plus.google.com/photos/+Motorola/albums/6025927350868561553
<hatch> it's kind of too bad pebble didn't go colour and round :)
<bac> rick_h_: ugh, our jenkins is precise but charmstore is not very precise-happy
<hatch> time to switch back to warty
<hatch> hmm that's an interesting failure in ci
<rick_h_> bac: ok, well we can deploy a new jenkins server on trusty. 
<bac> rick_h_: man that would make life easier
<rick_h_> bac: or we look at using jenkins/jenkins-slave to run the tests on a slave related machine
<bac> trusty! trusty!
<hatch> wait for my merge to land plz :)
<rick_h_> bac: yea, I first thought we could move all of ci to trusty, but jujucharms and prodstack is still precise 
<bac> rick_h_: here's what i've got so far: http://ci.jujugui.org:8080/job/charmstore/configure
<rick_h_> bac: so we'd need to get our prodstack envs moved as well
<bac> rick_h_: the go-ness of it makes it kind of messy
<rick_h_> bac: want to peek at the jenkins slave charm and see if we can more easily tie that in?
 * rick_h_ is looking
<bac> rick_h_: going to trusty would give me a modern version of go too.
<rick_h_> bac: right
<rick_h_> bac: but if we setup the slave machine, we have one place to view the results reports
<rick_h_> but run the tests on another machine that can be the go-centric place and can be trusty easily without effecting current stuff
<bac> we do or we don't?
<bac> why the but?
 * bac brb
<rick_h_> bac: sorry, mixed stuff in there
<rick_h_> bac: the CI config looks good. The tmp stuff reminds me of the lbox clean directory stuff from GUI heh. 
<rick_h_> hatch: build fail
<hatch> yeah I re-triggered it
<rick_h_> bac: hmm, no trusty jenkins-slave charm :( I would think that we could try to fork/push that. 
<hatch> not sure what the old issue was, but hopefully this one will work just fine
<hatch> looks like it's running now
<hatch> *crosses fingers*
<bac> rick_h_: oh, i guess i should blow away that tmp dir
 * bac wonders how long before i rewrite it all in python
<rick_h_> bac: yea, wish sinzui and them weren't so under water and could chat/participate. 
<bac> rick_h_: i talked to sinzui earlier
<bac> he gave me some references but they aren't doing anything exactly like this
 * rick_h_ goes to check logs, assumed they'd have to do all the tests on precise/trusty and such across platforms
<rick_h_> bac: ok, what do you think of the path forward of updating the jenkins-slave charm for trusty, get it deployed and wired up to ci.jujugui.org, and then moving the test runs of the store to there?
<bac> rick_h_: it was all pm'd
<rick_h_> bac: ah, ok nvm then
<bac> rick_h_: https://pastebin.canonical.com/112297/
<rick_h_> bac: interesting
<bac> rick_h_: what has to be done to that charm? i don't see anything precise-specific in it
<rick_h_> bac: ok, well I've got two worries. One that precise not working is a problem we'll need to solve. But I think that can wait until after we get stuff working
<rick_h_> bac: I think the only thing we'll have to do is to fork it and push it up under the precise/ namespace
<bac> rick_h_: the issue with precise are 1) old go that needs work-arounds, 2) no juju-mongo package backported.
<rick_h_> bac: so I'd start by testing it out by just pulling it down and publishing it under either yourself or our juju-gui space we use for our own charm. 
<bac> ok
<rick_h_> sorry ~juju-gui-charmers is the shared one
<bac> jujugui: anyone have problems deploying local charms unless you specify --repository?  http://paste.ubuntu.com/7697163/
<hatch> bac yes that is required
<bac> hatch: well, it looked liked it guessed properly but didn't really since it appened /trusty
<kadams54> bac: True confession: I've only ever deployed a local charm (the ghost one) via the GUI.
<hatch> bac yea i haven't ever got that to work heh
<bac> yeah, it doesn't come up often
<hatch> bac what if you were in ~/charms and then did `juju deploy local:trusty/jenkins-slave` ?
<bac> hatch: i think that would work
<hatch__> bac it would be nice if we could go `juju deploy .`
<Makyo> Two failures \o/
<hatch> Makyo are you around?
<hatch> oh hah
<hatch> :)
<Makyo> Yep
<hatch> \o/ for failures
<hatch> so my question :)
<hatch> when we create a relation between two ghost services the information which is in the changeset is the service names not a reference to their models
<hatch> so if the user changes the service name (it's not yet been deployed)
<hatch> then the relation fails
<Makyo> Hmmm.  Seems like an easy enough change.  I know we crammed that in last minute.
<Makyo> "Easy enough" in the heaviest sarcasm quotes I can muster.
<hatch> lol
<hatch> sooooo I was thinking we should instead add an extra id to the models 
<hatch> and we use those id's for reference for the ecs stuff
<hatch> then the models can change under it and it doesn't matter
<Makyo> hatch, don't we already have those?  The 120947$ ids?
<Makyo> Those don't change.
<hatch> right, but I'm pretty sure those go away once it's been deployed....no?
<hatch> I'll investigate further....but you don't see any issue with using the ghost id's then resolving them wherever they need to be resolved? 
<hatch> there are a few places where we rely on the id to display the information
<Makyo> Well, sure, but once they're deployed, we already have a mechanism for replacing that info in future ECS records, right?
<Makyo> YEah.
<hatch> yeah ok cool
<hatch> good thing we are agile haha, I'm not sure how anyone would have created a spec for this stuff :)
<hatch> kadams54 hey, do you know why halt() worked this morning when preventDefault() didn't? I realized I told you to use it but didn't say why...
<kadams54> hatch: I suspect it's because the click event is bubbling up?
<hatch> yeah, halt calls preventDefault and stopImmediatePropagation so it stops it bubbling....this has caused us issues in the past when listening on containers for events so we try and use it sparingly 
<kadams54> Though I'm pretty annoyed right nowâ¦ the merge CI build is failing on an IE error that is happening in a section of code (test_inspector_charm.js) that doesn't seem very related to anything I changed.
<kadams54> Something in the "closes itself safely" test is causing hash URL pollution, which means test_cleanup.js fails at the very end.
<hatch> ahh, check that there isn't an ANCHOR tag, being clicked without a preventDefault
<hatch> :P
<kadams54> :-)
<kadams54> Believe me, I'm looking for that like a hawk
<kadams54> But there's no click simulates in the test in question, so no easy suspects
<hatch> well....if you have a few commits can you revert them back and see which introduces the issue?
<kadams54> Haven't tried that yet, but the problem seems to be here: https://github.com/juju/juju-gui/blob/develop/app/views/viewlets/charm-details.js#L90
<hatch> looking
<kadams54> IE 10 interprets that line as "set the hash to '#'"
<kadams54> Though I'm not sure why that would start failing right now
<hatch> that line has been there for a while
<hatch> yeah...
<hatch> what r u working on?
<hatch> or I suppose, do you have the code up somewhere
<kadams54> Hah!
<kadams54> You KNOW what I'm working on
<kadams54> It's the same PR I've been working on!
<kadams54> I can't land it because of this IE test failure.
<kadams54> Need to get dinner now, but may bisect tonight
<hatch> oh.....the same one?
<hatch> that's the one that won't work
<hatch> wth
<hatch> yeah take a break :) 
<kadams54> Hmmâ¦
<kadams54> I'm pretty sure we do this to reset any tab info that might have been stored in the hash
<kadams54> But the reality is that there doesn't appear to be a good cross-browser way to remove the hash.
<kadams54> Still very puzzled as to why this would break now, and why it only breaks in IE. I get manually duplicate the same behavior in Chrome when I set window.location.hash in the console.
<kadams54> But dinner calls.
<huwshimi> Morning
<jcsackett> morning, huwshimi.
<huwshimi> jcsackett: Hey!
<jcsackett> heya, how have you been?
<huwshimi> jcsackett: Good thanks. Yourself?
<jcsackett> i've been good. busy, but good. :)
<huwshimi> :)
<rick_h_> morning huwshimi 
<huwshimi> rick_h_: Hey
#juju-gui 2014-06-25
<bac> hola huwshimi
<huwshimi> bac: Hey :)
<huwshimi> rick_h_: Any feelings on what keyboard shortcut we should use for hiding the sidebar?
<huwshimi> rick_h_: I was thinking Shift+f for "fullscreen"
<huwshimi> or full-width or something
<rick_h_> huwshimi: oh hmm, didn't think about it...ponderings
<rick_h_> wish we could use S but that's taken
<huwshimi> yeah
<rick_h_> huwshimi: h? for hide
<rick_h_> f would be ok, I'm just used to thinking of things like f11 fullscreen and such in browsers
<rick_h_> so when I'm in a browser 'fullscreen' means a bit different, or like image galleries that go 'fullscreen' with the pic
<huwshimi> yeah
<huwshimi> rick_h_: I'm happy with 'h'
<rick_h_> huwshimi: ok, let's roll with that until someone wants to have a debate on it :)
<huwshimi> rick_h_: OK :)
<huwshimi> rick_h_: I'm happy to drag this out a bit more now if you prefer? :)
<rick_h_> huwshimi: hah, that's ok. I'm done debating stuff today
<rick_h_> morning
<bac> morning
<rick_h_> morn
 * rogpeppe lunches
 * rick_h_ is changing locations and heading to the coffee shop
<bac> rick_h_: you relocated?
<rick_h_> bac: yep
<rick_h_> sorry, coffee in hand now ready to face the rest of the day
<bac> rick_h_: hey, for the ci instance do you have the environements .jenv file?  it is my understanding that sharing that is the only way to collaborate on juju environments.
<rick_h_> bac: aha, ok yes I do have it. However, I just realized my router is not setup to let me ssh home to my desktop to get it. (new routers ftw and fml)
<rick_h_> bac: thinking, I have a GUI on that instance and will see if I can find the address and get into it at all. 
<bac> rick_h_: for charmworld we have a private branch with the tools to get it up and running.  we then commit the .jenv file and push it back up to LP.
<rick_h_> bac: ok, can work on setting that up. I'll add a card to maint to get the files in. 
<bac> cool
<bac> rick_h_: the trusty jenkins-slave charm has been ingested and is available. i'm going to experiment with it on ec2
<rick_h_> bac: ok cool
<rick_h_> bac: I'm trying to see if I have the info to get into the GUI on there atm. Worst case I'll be heading home before stand up
<bac> ok
<rick_h_> just like to get out of the way of the cleaners 
<bac> our isp went south today so i'm at coworking spot. nice change of scenery.
<rick_h_> yea, I've not been coming out here much. In one way nice, put on the noise cancelling headphones and more light 
<rick_h_> but then there's those people around you talking about politics and disasters on one side and religious ones on the other side of me
<rick_h_> bac: ok, sending gui info in pm
<bac> rick_h_: also, what's the utility in making the internal IP address clickable?
<rick_h_> bac: well if you're on that network (openstack?) you might be able to reach it?
<rick_h_> or vpn'd or something
<rick_h_> bac: I admit it's probably not somethings used very often
<bac> rick_h_: i understand how to configure jenkins-slave now.  i'm going to add one to our CI instance.
<rick_h_> bac: rgr, sounds good
<foobarbazqux> rick_h_: what do you use for volume control/display in awesomewm?
<jcsackett> ...and who has been messing with my IRC configs...
<rick_h_> jcsackett: no, I just launch pavu<tab>
<rick_h_> and use that
<jcsackett> rick_h_: pavu<tab>? you mean pavuk? b/c that's the only pavu command i see.
<rick_h_> sec otp
<jcsackett> rick_h_: ok, no hurray.
<jcsackett> ...i cannot type this morning.
 * jcsackett goes for more coffee
<rick_h_> jcsackett: bah, I can't login to my home machine atm
<rick_h_> jcsackett: I think it's pavucontrol
<rick_h_> the pulse audio control thingy
<jcsackett> rick_h_: ah, ok. thanks. i'll dig into that.
<bac> rick_h_: you home now?
<kadams54> Getting a "this party is over" message in Google Hangouts for the standup room.
<hatch> jujugui call in 9
<hatch> kadams54 working fine here - are you clicking the link in the calendar?
<kadams54> tinyurl.com/jujugui
<hatch> that's not the link :)
<kadams54> Yeah, I know, but I'm having problems getting into my calendar via the web UI
<kadams54> So all I have is what my desktop calendar app gives me
<rick_h_> bac: home now
<rick_h_> bac: what's up?
<kadams54> hatch or rick_h_ : can you paste the real URL in IRC?
<rick_h_> kadams54: will do
<hatch> kadams54 odd google.com/calendar is up and fast for me
<rick_h_> kadams54: https://plus.google.com/hangouts/_/canonical.com/daily-standup?authuser=1 watch the authuser based on your setup
<kadams54> hatch: the problem is with my 2FA
<hatch> oh, you hit it so many times it's probably out of synx
<hatch> sync
<kadams54> hatch: potentially, yeah, but I was hoping to fix it after standup
<kadams54> rick_h_: still getting that message, but I suspect that's because I'm not logged into my canonical account right now. Could you invite my kadams54@gmail.com account?
<rick_h_> kadams54: create a privte tab and login fresh in there with 2fa
<rick_h_> kadams54: and then you can settle this out after the call
<rick_h_> kadams54: at this point I normally have to log out of everything google related and resetup accounts
<kadams54> rick_h_: yeah, I'm using a private tab, but I can't log into my canonical account at all. Can't get past the 2FA step.
<hatch> kadams54 I 'think' 2fa gets out of sync if you hit it 3 times without logging in....I'm not sure how to fix beyond that 
<rick_h_> bac: so if you crontab -e as the jenkins user you can see the backup job and the lander cron job listed there
<bac> cool
<rick_h_> hatch: did you need another set of eyes on kadams54's or huw's landing issues?
<hatch> rick_h_ I should be ok - I'm going to leave kadams54 until he gets back
<hatch> he said he has a solution 
<rick_h_> hatch: ok let me know if you need a hand
 * rick_h_ goes back to typing lots of words per minute
<hatch> will do
<hatch> rick_h_ shift+h hides the sidebar? That's a little too common of a key combo imho
<rick_h_> oh, thought it was control h
<rick_h_> maybe huw and I crossed wires on the first key
<rick_h_> hatch: I'd suggest going with control-h
<rick_h_> the thought was 'hide'
<hatch> ohhh ok that would make more sense 
<hatch> yeah it's definitely shift in his branch :)
<bac> rick_h_: can you 'juju ssh trusty-slave/0' after switching to azure-ci? if so, could you 'ssh-import-id bac' on that machine? i thought just having the .jenv would allow me to ssh in but it does not.
<rick_h_> bac: done
<bac> ty
<hatch> rick_h_ ctrl+h === backspace on my computer can you test on yours?
<rick_h_> hatch: oh hmm, well that sucks
<rick_h_> alt-h?
<hatch> that prints a . up at the top of the line
<hatch> so i'd be ok with that :)
<hatch> works on your machine?
<hatch> ËËËËËËË
<hatch> interesting....
<hatch> :)
<rick_h_> I don't know, I mean it's up to the browser. I'd be happy to QA it
<rick_h_> I don't get the dots you do
<hatch> oh ok, well I'd be happy to go with either ctrl or alt really...
<hatch> i'd probably prefer ctrl+h 
<hatch> ?
<rick_h_> well, if it goes through to the browser I'm ok with
<rick_h_> it
<rick_h_> if not, (the keyboard/OS captures it first) then alt-h?
<hatch> sure
<rick_h_> can you just swap it out in yoru lcoal qa branch and give them a try?
<hatch> I can
<rick_h_> man, going from the laptop at the coffee shop to the kenisis is messing up my order of chars today
<hatch> haha - my keyboard stopped working the other day
<hatch> I'm going to need a new one
<hatch> well, it started working again
<hatch> but that means it's on the way out heh
<rick_h_> hah, let me know if you need keyboard advise
<rick_h_> or need me to send you one or three
<rick_h_> make room in the closer for some more :)
<hatch> ctrl+h works like a charm btw
<rick_h_> hatch: cool, I'm +1 on that
<hatch> unless they are in an input
<rick_h_> which is fine imo
<rick_h_> well, maybe...debating
<rick_h_> but even alt-h will not work in an input field right?
<hatch> right, just tested none of our keybindings work when the user is in an input
<rick_h_> ok, then sounds like a plan
<rick_h_> that's a bummer
<hatch> yeah - maybe a slack task to get that fixed up
<hatch> ok replied in kind to the pr
<rick_h_> hatch: since you have the branch down is there anything else with it? Is it reasonable to just land the change?
<hatch> rick_h_ well there is more work than just that change, changing everywhere that says Shift+h to Ctrl+h.....but it wouldn't be hard, just mechanical
<hatch> would you prefer I do that instead?
<hatch> s/instead//
<rick_h_> hatch: ah up to you. If it's tiny and can move forward I'm +1 on it, but if it gets in your way never mind
<hatch> it's ok I already have it pulled down so I can do it
<hatch> huws other branch fails CI via failing tests so I'll leave that one up to him to fix
<rick_h_> +1
<hatch> why is it so hard to find the keynote streaming url
 * rick_h_ goes to get food to prep for google fanboi keynote time
<rick_h_> https://www.youtube.com/watch?v=wtLJPvx7-ys
<hatch> https://www.youtube.com/watch?v=wtLJPvx7-ys
<rick_h_> because you didn't ask :P
<hatch> heh
<hatch> :D
<rogpeppe> hatch, or anyone else: would you be able to join a call for a moment to talk about browser cross-site restriction stuff?
<rogpeppe> hatch: and decent workarounds
<rick_h_> rogpeppe: sure, what do you need?
<rogpeppe> rick_h_: https://plus.google.com/hangouts/_/canonical.com/macaroons?authuser=1
<rogpeppe> rick_h_: (or authuser=0)
<hatch> oops sorry i stepped away, rick_h_  you got it?
<hatch> blah I can't join anyways, I'm going to guess, yes :)
<bac> man azure is not unslow
<hatch> haha
<jcsackett> Makyo: i've looked at your PR. only real question was "tests?" but there's a few more things on the PR.
<Makyo> jcsackett, thanks; much of the code was already tested since it was just moved to new UX, but I'll see if there's more I can add around the edges.
<rick_h_> hatch: yea, think got it
<hatch> great thanks
<jcsackett> Makyo: yeah, i'm just nervous about a whole new viewlet that has no apparent tests. :p
<hatch> sry bout that
<Makyo> jcsackett, sure, makes sense. 
<Makyo> Tests could also use some reorganization to help that.
<hatch> holy crap Material Design through Polymer
<rick_h_> hah! antdillon's auto colored stuff is in googleio keynote
<rick_h_> go antdillon 
<hatch> haha
<antdillon> rick_h_, I copyrighted that!
<rick_h_> antdillon: hah
<hatch> lol 55min commute....not bad 
<Makyo> I used to have one of those.
<Makyo> I don't know that I'd call it "not bad".
<hatch> haha right? I laughed when he said that
<hatch> boooo the motorola watch isn't available yet
<rick_h_> 2/3 ain't bad
<hatch> well I think the samsung one only works on samsung phones
<hatch> at least that's what their old ones were
<rick_h_> there's a few of them out there 
<kadams54> hatch: FYI, I committed and pushed a fix for that cardâ¦ waiting to see how the PR CI build goes before I try shipping it again. https://github.com/kadams54/juju-gui/commit/b8ce6093e8dc4318babbf63038fc52c002fdc9c7  <-- the fix
<kadams54> rick_h_: where should I go to get my 2FA problems straightened out? The FAQ mentions the #isd and #is channels on IRCâ¦
<rick_h_> kadams54: yea, in the canonical irc channels
<kadams54> Just #canonical, or should I join a specific channel?
<hatch> kadams54 the canonical irc server
<rick_h_> kadams54: yea, sec
<rick_h_> kadams54: sent you a link in PM
<kadams54> thanks
<bac> rick_h_: on azure i'm getting a weird error about not being able to find download tools.  i think that is causing the relation hooks to not run.
<bac> the error does not occur on ec2 with the same charm.
<rick_h_> bac: hmm, maybe I need to do some juju upgrade fu on there?
<rick_h_> I know people have gotten errors like that when there's streams issue
<bac> jujugui: if we draw a relation does the gui wait for confirmation from the watcher before showing it?
<bac> if the relation fails do we show the line?
<bac> rick_h_: upgrading juju might not hurt
<rick_h_> bac: otp but will look in a bit
<bac> rt
<rick_h_> bac: tried a juju upgrade-juju and it didn't do anything
<bac> juju damn-juju
<Makyo> juju kickstart
<rick_h_> bac: then tried with --upload-tools and got the error https://pastebin.canonical.com/112448/
<rick_h_> bac: so looking at where to go from here. 
<bac> rick_h_: can you ssh in and upgrade via apt?
<bac> i've never used upgrade-juju
<rick_h_> bac: does that work? /me hasn't seen that
<bac> rick_h_: why wouldn't it?
<rick_h_> bac: no idea, I've never thought about it in that way
<bac> oh, i just see it as another package.  hope it doesn't blow anything out from under juju
<rick_h_> bac: so we'd have to add the ppa, because we want something later than precise right
<rick_h_> bac: yea, I'm not sure how the tools/machine 0/db and such interact tbh
<bac> rick_h_: any chance it is provider-specific?
<bac> the issue, i mean
<rick_h_> bac: I'm getting tempted to think CI is setup on an env that isn't shared correctly, on precise, on a 1.17 dev version of juju :/
<rick_h_> bac: well I was thinking you could test by using the azure creds in the wiki, change the control bucket, and start a new env
<rick_h_> bac: and verify if the charms work together in a newer clean juju env
<bac> rick_h_: so recreate a new CI env on azure for testing and possible migration?
<rick_h_> bac: maybe start with just seeing if it fixes the issue and removes azure as the issue
<bac> sure
<rick_h_> bac: since it's cheap to tear down 
<bac> good plan
<rick_h_> bac: and if there's no issue, then we plot out a migration to a proper shared env
<bac> rt
<rick_h_> doing things the right way vs the rick didn't know better way
<bac> rick_h_: is storage-account-name the azure spelling for control-bucket?
<rick_h_> bac: double checking, but think so
<rick_h_> bac: yes
 * rick_h_ goes for a walk around the block
<bac> hey rick_h_ it looks like you can't just change those values for azure like you can the control bucket.  i think you have to go to their web site, login, enter a new value for storage-account-name and it'll spit out the new value for management-subscription-id
<jcsackett> Makyo: i note you responded to my review but i haven't seen new commits. did you mean to push something, or is that still in progress?
 * bac relocates
<hatch> lazypower are you reviewing today?
<Makyo> jcsackett, still in progress moving the tests around - sorry for the delay, was on other laptop :(
<jcsackett> Makyo: cool beans. :)
<hatch> jujugui anyone use google play music?
<lazypower> hatch: its marco and jcastro - did you need something?
<hatch> lazypower ahh, I just want my ghost charm approved for this weekend so I can work on a blog post :)
<hatch> I have some time off coming up reeeeal soon
<lazypower> hatch: did you see i replied on your bug?
<lazypower> i'm kind of put off by the amount of banter on ghost not being served up over port 80
<hatch> heh yeah I agree with you
<lazypower> this is *basic* web stuff. if your charm says "This goes to port 8080" then fine. let it go to port 80. case closed. you deploy it behind haproxy or apache.
<hatch> lets just get the darn stuff in the store then we can update it later imho
<lazypower> s/port 80./port 8080./
<lazypower> hatch: well thats the thing. everybody is gung ho about getting their stuff in the store *then* iterating
<lazypower> you'll have the same issues with ~charmers being a bottleneck
<lazypower> we gate *every commit* that will land in your charm.
<lazypower> thats in the store
<lazypower> so if we can get it HQ before it lands there, we're good to go. 
<lazypower> now in terms of the ghost charm. I'll need to pull it, deploy it, evaluate it
<lazypower> but the last time i looked at it you were scary close to having a solid review
<lazypower> there were just some small things that were blocking it, and looking over the comment bantering, it appears you've fixed them
<hatch> there has to be a better way to do this stuff 
<hatch> like tbh I don't really care if it's ~charmers or not but I'd like an icon in the GUI :)
<lazypower> have you pushed your charm to lp:~hatch/charms/trusty/ghost/trunk?
<hatch> precuse 
<hatch> precise
<lazypower> ok, s/trusty/precise/
<lazypower> then you're "in the store" - you're just not a recommended charm yet
<hatch> right - and no icon
<lazypower> there's a reason being a recommended charm is a pain in the butt. We want them to be *solid* charms.
<hatch> and the user can't type `juju deploy ghost`
<lazypower> i want to fire a bazooka at it
<lazypower> and it better stand up
<hatch> they have to do `juju deploy lp:~hatch/ghost`
<hatch> er
<hatch> lp:~hatch/previse/ghost
<hatch> precise
<hatch> bleh
<hatch> lol
<hatch> Ooo a huge spool of fiber is sitting on the street
<hatch> looks like someone might be getting real fast internet soon
<hatch> <---- this guy
<huwshimi> Morning
<hatch> hey huwshimi 
<huwshimi> hatch: Hey
<hatch> I left a few too many comments on your hotkey branch :)
<hatch> I should learn to finish a thought before hitting 'send' :)
<huwshimi> hatch: hehe, thansk
<huwshimi> *thanks
<huwshimi> hatch: ctrl+h also opens history in chrome
<hatch> oh....hmm
<hatch> well then....
<hatch> what about alt h?
<huwshimi> hatch: opens help in firefox
<hatch> lol
<hatch> for $130/mo I can get 260Mbps down and 30Mbps up.... not bad....
<rick_h_> hatch: I'm a play music guy. It's replaced everything else for me
<hatch> I'll still probably stickwith the $40/mo option :)
<hatch> rick_h_ do you use streaming or still buy songs?
<hatch> I'm trying to find a way to share my library with my wife, doesn't look like it's possible
<rick_h_> hatch: so I uploaded all my stuff and then I just stream. I can add almost any album without buying it
<rick_h_> hatch: ah yea, have to get her the google lib
<rick_h_> hatch: I might try the amz one. I wanted to try it out as I can share my prime subscription with her
<rick_h_> and the music service is tied to prime
<rick_h_> I wonder if I upload/etc she also can see get access to it
<rick_h_> but it's a much smaller set of songs
<hatch> I installed an app on my synology nas which seems to be working, but buying songs from play then adding them to the nas is kinda of a pita
<rick_h_> yea
<rick_h_> why I just go with play
<rick_h_> just pay my $7 and get everything I want
<hatch> heh it's $10 in Canada :)
<rick_h_> I do have it hooked up to my tablet so my wife can use it there
<rick_h_> yea, I think it went to $10 after a $7 trial early adopter thing
<hatch> ohhh
<hatch> I think I still prefer to own the music, then I have music when offline
<hatch> :)
<rick_h_> well you can pin and have it offline
<hatch> even streaming songs?
<rick_h_> I do that with all the kids albums so that I can have them for the boy when we lose connectivity/camping
<rick_h_> yep
<hatch> ahh that's cool, didn't know that
<rick_h_> yea, it works pretty seemlessly across your stuff and cloud stuff
<hatch> the real question is....do I spend $120/yr buying music to make streaming worth while...
<rick_h_> yea, I use it a ton because we'll take the boy to see a movie, then get the album on the way to the car to listen to on the way home/etc
<rick_h_> it's more the convienence
<rick_h_> and with chromecasts able to send it from my phone to any tv in the house it's a bonus
<hatch> ahh
<hatch> https://play.google.com/store/apps/details?id=com.synology.DSaudio&hl=en
<hatch> works really well
<rick_h_> cool
<hatch> could use some UX improvements
<hatch> like figuring out how to set up the accounts sucked
<hatch> but other than that it streams well, and you can download to the device 
<rick_h_> woot http://jrwren.wrenfam.com/blog/2014/06/25/leaving-a-great-job-for-a-great-job/
<rick_h_> bac: around?
<hatch> OOoooo
<hatch> Who's he?
<hatch> oh
<hatch> I know
<hatch> lol
<rick_h_> that's Jay, the local guy I know that's starting Monday :)
<rick_h_> getting exicted to start bringing in the new folks
<rick_h_> and that's all I'll say here for now :)
<hatch> haha - I'll try and pop online on Monday to join the call
<hatch> as long as there aren't too many tweens streaming selfies from the lake I should have enough bandwidth
<hatch> lol
<rick_h_> lol
<hatch> there is only one tower up there
<hatch> so its fast but bandwidth is limited
<rick_h_> gotcha, audio only time
<hatch> unless i get lucky and they haven't gotten up yet haha
<hatch> huwshimi so what shortcut do we want to use?
<huwshimi> hatch: How about we just do it on any keypress
<hatch> lol
<hatch> every keypress hides and shows it
<hatch> so it's like a rave
<hatch> a sidebar rave
<rick_h_> what's wrong witht he ctrl-h?
<hatch> that shows the history 
<hatch> I guess
<rick_h_> oh
<rick_h_> and alt-h?
<hatch> opens help in ff
<hatch> haha
<rick_h_> wtf
<hatch> we can't catch a break
<rick_h_> ctl-alt-shift-meta-h
<rick_h_> there done!
<hatch> I wonder if our hotkey system supports multiple modifiers
<hatch> lol
<hatch> it does 
<huwshimi> yeah, it does
<hatch> huwshimi what about ctrl+alt+h ?
<rick_h_> ok, new plan
<hatch> doesn't do anything here on osx
<rick_h_> under help and feedback we add a row with a small _ link
<rick_h_> and that link does the show/hide
<rick_h_> and forget keyboard shortcuts
<hatch> hmm that's an interesting idea
<hatch> buuuuut
<hatch> maybe hiding the sidebar will be a useful functionality
<rick_h_> I'm buzzed on wine from dinner
<rick_h_> so now's a good time to get them
<rick_h_> fine, then make it a full link "toggle sidebar"
<hatch> haha, keep throwin em out and we'll see what sticks
<hatch> well the ctrl+alt+h I think should work
<hatch> and we have one other shortcut with 2 modifiers
<rick_h_> ok, you're worried that _ will be too useful...but you're willing to do ctrl-alt-h?
<hatch> lol I mean it'll be hard to switch between if people want to do that
 * hatch bets we'll be adding in a handle to the sidebar again in no time
<hatch> lol
<rick_h_> huwshimi: we trust your judgement to come up with something that works and doesn't suck and want to allow thinking outside of the keyboard box
<rick_h_> hatch: shush
<rick_h_> no one...well except huw...asked you :P
<hatch> haha
<rick_h_> hmm, I think we chased huw away
<huwshimi> rick_h_: I'm thinking ctrl+alt+h
<rick_h_> huwshimi: ok, then cool to me
<huwshimi> rick_h_: I think it's not something we want to accidentally press and not know how to get back
<rick_h_> huwshimi: yea, that's why I liked the move to a real link
<rick_h_> huwshimi: but I'm cool either way
<hatch> cool as a cucumber 
<huwshimi> rick_h_: I could land with ctrl+alt+h and then send an email and make it ux's problem :)
<hatch> http://www.airconco.com/images/cucumber1.jpg
<rick_h_> huwshimi: naw, they've got their hands full without this one
<rick_h_> and the only people asking for it are ecosystem and they can ctrl-alt-h just peachy
<huwshimi> ok
<rick_h_> so let's go keyboard and land it and wait for a follow up bug report later on :)
<huwshimi> haha ok
<hatch> so the question is....do I buy one of the smart watches currently available or wait until the motorola one comes out?
<rick_h_> hatch: I'll be bringing the LG one to london
<hatch> heh you ordered it already?
<rick_h_> yea, figured wtf I want to try it out and see how it goes
<rick_h_> and I'll try it out around london for directions/dinners/etc
<hatch> yeah that'll be cool the samsung one has more sensors
<hatch> but I like the lg's look better
<rick_h_> yea, but the display is said to be not as good and LG looks nicer, and I hate samsung
<hatch> oh wait a second....it only has a heart monitor
<hatch> don't care bout that
<rick_h_> right
<hatch> as long as it's pumping I'll know
<hatch> lol
<hatch> what colour did you get?
<rick_h_> black, I'm plain
<hatch> ok I bought a white one....don't tell my wife
<hatch> it's a little too easy to buy things with google wallet
<hatch> sorry, make that way to easy
<rick_h_> lol
<hatch> it ships on the 3rd, so should arrive before London
<huwshimi> Hmm... windowNode.simulate('keydown', { keyCode: 104, key. shiftKey: true, altKey: true }); should work with multiple modifiers right?
<hatch> yep
<hatch> you have a typo though
<hatch> an extra space 
<hatch> between key. shiftKey
<rick_h_> yea, wha'ts that key.?
#juju-gui 2014-06-26
<hatch> oh....yeah that whole thing is a typo
<hatch> lol
<huwshimi> oops, that was a comment delete error
<huwshimi> windowNode.simulate('keydown', { keyCode: 104, shiftKey: true, altKey: true });
<hatch> I can't say that that's the proper syntax (I'm pretty sure it is though) but it should work
<hatch> are you saying that when you add an extra modifier it stops working?
<huwshimi> Nevermind, I'm an idiot
<hatch> well I wasn't gona say anything....
<hatch> but since you brought it up.....
<hatch> :P
<huwshimi> :)
<hatch> ok now I want my new watch.....patience is not a virtue 
<rick_h_> hatch: heh, just closed my tab checking my xps build status
<hatch> still in China is it?
<hatch> I remember when I bought my last computer form Dell it took a month and a half heh
<hatch> granted it wasn't one of those 'fast ship' ones
<rick_h_> yea, still 'in production'
<hatch> think it'll get here before london?
<huwshimi> I give up on ever hoping my tests will pass our CI
<hatch> lol
<hatch> lemme take a look
<hatch> huwshimi that looks like it's the intermittent failure
<huwshimi> It's actually getting a bit ridiculous at this point.
<huwshimi> hatch: Yeah, I realise that's the problem, it's just a hassle that that happens every time
<hatch> yeah I'm not going to disagree there
<rick_h_> yea, I mean it's an issue, but try watching juju-cores landings :) 
<rick_h_> I actually feel better about our CI lately. It really rarely fails 2 times in a row
<rick_h_> and really I think it fails 1 in every 7 ish branches
<rick_h_> which is still :( 
<hatch> we'll get there
<hatch> in time...in time
<rogpeppe> huwshimi: mornin'
<huwshimi> rogpeppe: Woah, a very early morning to you too :)
<rogpeppe> huwshimi: :-)
<rbasak> rick_h_: hey! Got some time to chat about juju-quickstart and status in Ubuntu?
 * rbasak isn't sure who else would need to be in that conversation
<rick_h_> rbasak: on a call atm but should be free shortly
<rbasak> rick_h_: OK, thanks!
<rick_h_> rbasak: free as a bird!
<rbasak> rick_h_: ten minutes? I just grabbed some food!
<rick_h_> rbasak: ok, sounds good
<rbasak> rick_h_: https://wiki.ubuntu.com/StableReleaseUpdates#Procedure
<rbasak> https://bugs.launchpad.net/ubuntu/+source/juju-quickstart/+bug/1311321
<_mup_> Bug #1311321: ascii can't decode error in 14.04 server install <juju-quickstart:Fix Released by frankban> <juju-quickstart (Ubuntu):New> <juju-quickstart (Ubuntu Trusty):New> <https://launchpad.net/bugs/1311321>
<rbasak> https://bugs.launchpad.net/ubuntu/+source/juju-quickstart/+bug/1309678
<_mup_> Bug #1309678: a value is required for the control bucket field <juju-quickstart:Fix Released by bac> <juju-quickstart (Ubuntu):New> <https://launchpad.net/bugs/1309678>
<rbasak> https://bugs.launchpad.net/juju-core/+bug/1306537
<_mup_> Bug #1306537: LXC local provider fails to provision precise instances from a trusty host <deploy> <local-provider> <lxc> <juju-core:Fix Released by wallyworld> <juju-core 1.18:Fix Released by wallyworld> <juju-quickstart:Fix Released by frankban> <juju-quickstart (Ubuntu):New> <juju-quickstart (Ubuntu Trusty):New> <https://launchpad.net/bugs/1306537>
<rbasak> rick_h_: https://bugs.launchpad.net/ubuntu/+source/juju-quickstart/+bug/1325013
<_mup_> Bug #1325013: juju-quickstart has no dep8 tests so can break when juju-core changes <juju-quickstart (Ubuntu):Triaged> <https://launchpad.net/bugs/1325013>
<rbasak> rick_h_: https://bugs.launchpad.net/juju/+bug/1081247
<_mup_> Bug #1081247: maas provider releases all nodes it did not allocate [does not play well with others] <maas-provider> <verification-done> <pyjuju:Invalid> <juju-core:Fix Released by julian-edwards> <juju-core 1.16:Fix Released by rogpeppe> <MAAS:Invalid> <juju-core (Ubuntu):Fix Released> <juju-core (Ubuntu Saucy):Fix Released> <juju-core (Ubuntu Trusty):Fix Released> <https://launchpad.net/bugs/1081247>
 * rick_h_ runs for coffee and breakfast. early meetings ftw
<jcastro> hey rick_h_
<rick_h_> jcastro: otp what's up?
<jcastro> oh good, you can just listen then.
<jcastro> so you know how the cluttered search sidebar is my favorite? 
<rick_h_> jcastro: yep
<jcastro> I am now realizing that every time we accept a charm into trusty, we double the horribleness
<rick_h_> shortcut to hide it has landed
<rick_h_> heh yea
<jcastro> for example, try "elasticsearch" 
<lazypower> thats strange. Trusty ES shows up under other, and not the recommended charms.
<rick_h_> jcastro: ok, phone calls over. 
<rick_h_> jcastro: yea, we try to not confuse users and show one 'recommended' charm
<rick_h_> jcastro: and the precise one is 'more popular' and wins
<jcastro> rick_h_, I really want the full screen search back
<jcastro> this isn't going to get any better as the number of charms goes up
<rick_h_> jcastro: understood, wip to help
<rick_h_> jujugui call in 2
<rick_h_> rogpeppe: ^ antdillon 
<Makyo> Was expecting "to your scattered bodies go", which I think pegs me as a nerd.
<rick_h_> rogpeppe: available for a hangout?
<rogpeppe> rick_h_: yup
<rogpeppe> rick_h_: got one to hand?
<rick_h_> rogpeppe: https://plus.google.com/hangouts/_/gwumte2sj2qezub4v54iy37dvqa?authuser=1&hl=en
<hatch> rick_h_ so I've been messing with this hide sidebar branch and I think we have to expand its functionality a bit.
<rick_h_> hatch: ruh roh
<hatch> if the user has hidden the sidebar and then clicks a service the sidebar should open again
<hatch> else it just looks broken
<rick_h_> hatch: but but but, that's the point
<hatch> because the url changes but nothing shows up
<rick_h_> it's just a manual hack for demo/etc
<rick_h_> it's not a usable experience
<rick_h_> at least for the moment, file a bug but it's going to be down the list tbh
<hatch> right, but I'm not sure what demo is possible without a sidebar when they click a service
<hatch> ok that's fine
<hatch> thx
<rick_h_> hatch: right, for the demo, they need to manually show/hide the sidebar 
<rick_h_> like manually picking the slides or the terminal during a presentation
<rick_h_> you have to swap between then on your own
<rick_h_> hatch: but agree, it's a definite nice to have to have it not suck
<jcastro> rick_h_, heya
<rick_h_> jcastro: party
<jcastro> what are the chances you have a sec to talk bundles with carla/ant?
<rick_h_> jcastro: changes are good for the next 2hr
<hatch> rick_h_ ok cool, as long as people know that they have hidden the sidebar so anything which requires that will also be hidden heh
<hatch> other than that his branch is gtg so I'll land it
<bac> so, my ISP saw we had a lot of traffic going to port 6667 so they concluded we had a TROJAN and helpfully blocked the port for us.
<hatch> rick_h_ we are now getting the intermittent ci failures on the merge job too
<bac> freenode == 6667
<hatch> looks like we need to put some time into fixing it now
<hatch> bac lol - lots of traffic? freenode?
<rick_h_> hatch: k, otp will lok
<rick_h_> look
<hatch> https://saucelabs.com/jobs/3eeb9e9d9dba479cbf5621b069399007 
<rick_h_> hatch: that's the common issue on that crap stuff
<hatch> right - but now it's also happening on the merge ci
<hatch> it never used to happen on that one 
<hatch> it appears the frequency of the failures has gone up
<hatch> and it's spreading.....like a virus....a test virus
<hatch> :)
<hatch> yeah it's happened twice in a row now on two different branches
<rick_h_> ok, but that's bad luck
<rick_h_> it's happened before
<rick_h_> hatch: ok, off the phone
<rick_h_> hatch: yea, that sucks. We've had that kind of mass sauce tests hate us before and it usually makes a day suck and passes
<rick_h_> hatch: but yea, we definitely want to fix that as part of our code/clenaup work post machine view
<hatch> right, it's just, how much time is wasted re-running ci builds to see if they pass
<rick_h_> hatch: right, if today it takes 4 tests runs, that's 2hrs. Fixing notifications is several days of work noe 2hr
<rick_h_> so it takes having this happen for a week in a row to be a blocker like that imo
<rick_h_> and it's not like this solves all CI failures, this notification one in IE is the most regular of them for sure. 
<rick_h_> and it'll be first on the list of fixing up test stuff post machine view
<hatch> this is in ff now
<hatch> too
<rick_h_> ok
<hatch> it's only this test
<hatch> but I don't see anything wrong with it, or the previous ones
<rick_h_> right, and I spent a day trying to update that test and found it's a fundamental issue in how notifications are written and the fix means rewriting that code
<hatch> blarg
<hatch> notifications are one of the last original code things
<hatch> heh
<rick_h_> I took a day to try to fix it and the hack is more than a day of work, and the workarounds are uglies than this failures
<rick_h_> the only right thing to do is to change it to be less timeout heavy and work properly in an event world 
<rick_h_> which is a base level rewrite of how it works
<rick_h_> hatch: sorry it's sucking today. We will make it better, but not today. 
<hatch> I'm just curious why it happened all of a sudden
<hatch> something must have changed
<rick_h_> it's a timing thing
<rick_h_> the sauce machine is slower than usual, the network, and it fails
<rick_h_> it's depenent on the stack and it's a big stack of pita and that stack is now 10 inches tall every single day
<rick_h_> it's 9.8" one day, and 10.2" another day
<hatch> haha
<rick_h_> and if it gets to 10.3" the tests tell us to go screw ourselves and die
<hatch> I wonder if we went on a 'private' sauce instance if it would be faster
<hatch> they don't say there is any difference in performance
<rick_h_> hatch: right, it's something I want to bring up. 
<rick_h_> hatch: when we get theblues going and hopefully are doing more sauce-like tests I want to try to get us a real account
<rick_h_> welcome BradCrittenden!
<hatch> yeah cool
<rick_h_> hatch: at that point it'll be easier to justify and make a case it's a cross project thing
<hatch> right
<rick_h_> hatch: but yea, not looked into it yet. Just talked with them at pycon
<hatch> haha that louis suarez got banned for 9 games
<hatch> ahh
<rick_h_> ok, I have to refill my coffee, afk for a min
<hatch> lazypower are you collecting the steam summer adventure cards? I need two of the ones you have ;)
<rbasak> rick_h_: can I suggest that quickstart prompts for ssh key creation before installing packages? Then the user can get over the interactive part without having to wait first.
<hatch> +1
<rbasak> (otherwise I come back to a test that I started earlier to find that it's waiting on a prompt)
<hatch> rbasak I'd recommend filing a bug
<rbasak> I'd be happy to if it sounds like it's doable
<hatch> I have no idea, but it would improve the experience so I'm all for at least investigating it
<rick_h_> rbasak: yea please file a bug and we'll investigate
<hatch> they are running the fiber through my neighbourhood right now
<rbasak> Filed https://bugs.launchpad.net/juju-quickstart/+bug/1334757 - thanks. I don't have permission to set Importance: Wishlist.
<_mup_> Bug #1334757: ssh key generation prompt happens after a long wait, mismatching the user's expectation that it will all be ready when he comes back <juju-quickstart:New> <https://launchpad.net/bugs/1334757>
<rick_h_> rogpeppe: had a talked with design and eco on bundles and there's a couple of notes for the bundle spec. I'll update the spec after lunch and then file a couple of bugs
<hatch> rbasak thanks a lot
<rick_h_> rogpeppe: but we wanted to support categories and description as optional items to the spec 
<rogpeppe> rick_h_: how is "description" different from README ?
<rick_h_> rogpeppe: and want to talk about pulling vcs info during a publish, so it's part of the publish process, but we'll have some metadata that the store will want to keep 
<rogpeppe> rick_h_: (personally i'd be happy ditching README)
<rick_h_> rogpeppe: the description is a paragraph while the readme is a full blown document going through optios, what it does, how it works, minute details
<rogpeppe> rick_h_: ok
<hatch> Makyo when you have a second I'd like to have a chat about implementing the 'removal' story in the ecs when there are hierarchical changes to be made 
<rick_h_> rogpeppe: e.g. https://jujucharms.com/bundle/mongodb/5/cluster/#readme is the readme, but the desciption might be "Deploys a 3-shard mongodb cluster"
<rick_h_> rogpeppe: anyway, will follow up after lunch in the right places but wanted to let you know. 
 * rick_h_ goes for food
<bac> rick_h_: i'm trying to launch against azure.  i'm getting 'affinity group conflict' so i assume there is a machine associated with 'bactest' that is still alive, though juju doesn't know about it.  on their dashboard i cannot figure out which machines are which.  would you happen to know how?
<rick_h_> bac: I just match the names in the dashboard with the juju status outpuyt
<rick_h_> output, using the dns names
<bac> rick_h_: right but i now have no juju output
<Makyo> hatch, sure, now's good.
<rick_h_> bac: :/ ok looking
<hatch> Makyo ok going to the standup room
<rick_h_> bac: go to the monitor tab and move the timeline to 24hrs and view which machine has data for things like disk going back the right timeframe?
<bac> oi
<rick_h_> bac: can you join the other irc channel from this morning please?
<bac> rick_h_: i got a list of the real ones
<rick_h_> bac: awesome, let me know if you need a hand
 * rick_h_ goes for lunch 
 * rogpeppe is done for the day.
<rogpeppe> g'night all
<rick_h_> see ya rogpeppe 
<rbasak> juju-quickstart 1.4.0 uploaded to Utopic. It should land in the next hour or so.
<rick_h_> rbasak: <3
<rbasak> Thank you for making it easy :)
<rbasak> I didn't need to change the packaging at all.
<rick_h_> bac and frankban rock on that 
<Makyo> jujugui need add'l reviews/qa on https://github.com/juju/juju-gui/pull/405 - switching to new upgrade UX. I suspect I'll have conflicts on my next branch, so I'd like this to land ASAP.
<hatch> on it
<Makyo> hatch, thanks.
<hatch> jcsackett what's round 16?
<rick_h_> hatch: soccer
<hatch> oh....
<hatch> I saw 5 minutes of a game yesterday and saw a guy flop
<hatch> he flopped, sat down holding his knee, when no one cared, he got up and started playing again...
<hatch> stupid game
<hatch> Makyo code is good
<hatch> do you need another qa as well?
<Makyo> hatch, I should be good, the next few branches will be additional QAs.
<lazypower> hatch: got a gui question for ya - http://askubuntu.com/questions/488575/juju-configuring-a-service-by-clicking-on-charm-with-stand-alone-implementatio
<hatch> Makyo ok cool
<hatch> +1
<hatch> lazypower looking
<hatch> lazypower ok I'll reply thx
<lazypower> its easy points, thought you'd like that one
<hatch> really wish people would ask one question at a time
<hatch> :)
<hatch> lazypower and answered
<hatch> woot I broke 900 points on AU
<hatch> look at me go
<lazypower> upvoted
<hatch> man it's so loud here
<hatch> they are directional drilling or something....
 * rick_h_ steps a way for a bit. 
<rick_h_> see you all at the AU call tonight
<hatch> rick_h_ when you return - have you seen this error before? http://ci.jujugui.org:8080/job/juju-gui-merge/433/console usually it happens once then works the next time but this keeps happening on this branch and there isn't any information on the failure other than that it failed
<hatch> trying again, 4th time is the charm!
<rick_h_> hatch: that's github's api not responding nice
<hatch> oh ok 
<rick_h_> hatch: we should add some error checking in the result of the api response to the merge command
<rick_h_> if github has a timeout/etc you get stuff like that
<hatch> if broke try again
<rick_h_> yea, pretty much
<rick_h_> nothing to do but ask github again 
<rick_h_> pretty please do this merge for me
 * rick_h_ sneaks back into the shadows
<hatch> "hey cool, it works"
<hatch> Ooooo
<hatch> after all that work I ended up solving it in 7 LOC's
<hatch> *sigh*
<bac> rick_h_: those bugs for the SRU have been updated.  i'm not sure i convinced myself on the 'regression potential' for the last one.
<Makyo> jujugui quick PR for review/QA https://github.com/juju/juju-gui/pull/406
<hatch> sure
<Makyo> Fixes #1328981
<_mup_> Bug #1328981: Reloading the inspector on upgrade of a charm creates blank sidebar <juju-gui:Triaged> <https://launchpad.net/bugs/1328981>
<hatch> Makyo so is clicking this change version button supposed to block out the entire inspector with no way to close it? :)
<Makyo> hatch, Did in the previous version, this should fix that.
<Makyo> Can you check your cache?  This has been an issue in the past.
<Makyo> Also, report the URLs that you see in the process.  Should clear sectionA, then repopulate with inspector/<service>
<hatch> Makyo I mean, I click Change version then a list shows up
<hatch> which I can't close
<Makyo> hatch, yes, you didn't QA the previous branch, but that was step 1, step 2 is styling/etc.
<Makyo> Which includes setting active tab to null, etc.
<hatch> ok when I click to upgrade it changes the url to http://192.168.33.10:8888/precise/mysql-31/#/precise/mysql-31
<hatch> so it shows the charm details
<hatch> but it doesn't always do this....hmm
<Makyo> Are you clicking the word 'upgrade'? there's two links there, just like there was in the previous impl, it just hasn't been styled yet.
<Makyo> the 'upgrade' link does not have an href and should not change your URL.
<hatch> oh lol oops
<Makyo> Sorry, I promise styling is coming next.
<Makyo> 7 days was just too long for that branch.
<hatch> lol np
<hatch> ok I see I can't test this on sandbox
<Makyo> I can.  Not sure what's up on your end.
<hatch> well it doesn't say to reload the inspector
<hatch> it just reloads
<hatch> without issue
<Makyo> hatch, hmm, I noticed this with mysql too.  Can you try wordpress while I see what's up? I have the feeling it's a databinding issue.
<hatch> sure trying wp
<Makyo> (That button for reloading the inspector is databound to an attr on the service.
<Makyo> )
<Makyo> jujugui .au weekly call in 9, for those going.
<hatch> "error interacting with charmworld api"
<hatch> Cannot set charm on a service with units in error without the force flag.
<hatch> interesting
<hatch> ^ that last one was because simulator
<hatch> interesting non the less
<hatch> Makyo wordpress also 'just changes' 
<Makyo> hatch, yeah, that's a core thing.  SetCharm api endpoint doesn't work when the service has units in error, reproduced in sandbox.
<Makyo> Butts.
<Makyo> Let me prowl some more.
<Makyo> Databinding is a little too magical.
<hatch> ok lemme know
<Makyo> Looks like it has something to do with the delta stream.  service.charmChanged doesn't get set to true unless things come back in the delta in the proper order.
<Makyo> Which is a little dumb.
<Makyo> I'll poke more after the call.
<rick_h_> mm, no huw
<rick_h_> there he is
<huwshimi> Morning
<rick_h_> hatch: coming along?
<rick_h_> huwshimi: call?
<hatch> hey huwshimi  yep joining call
<huwshimi> Joining
<huwshimi> brb changing location
<hatch> 13s relocation? :)
<hatch> oh :)
<hatch> jujugui lf a review and qa for https://github.com/juju/juju-gui/pull/407 plz and thx
#juju-gui 2014-06-27
<rick_h_> heh, busy day when now is the first time I've loaded up the dell order status page fo the first time today
<rick_h_> and still building :)
<rbasak> bac: thank you for doing the SRU justifications for me. I'm working on the Trusty SRUs now.
<rick_h_> morning
<rick_h_> rbasak: awesome thanks
<bac> morning rick_h_
<rick_h_> bac: morning
<rick_h_> bac: talked with wallyworld last night. They're building a CI setup for several of the small libraries around juju
<rick_h_> bac: we talked about having the charmstore CI be located there and in the same place as the other libraries used
<bac> rick_h_: progress this morning! axw discovered i was encountering two bugs with juju.  one just committed to trunk and the other on the critical list.
<bac> the latter has a work-around
<rick_h_> bac: and I think everyone is on board with that. 
<bac> rick_h_: cool
<rick_h_> bac: oh, very cool 
<bac> rick_h_: the other bug i think only affected us east.  everyone says to use us west
<rick_h_> bac: so I'm tempted to say our goal is to work with them to get things up for now. 
<rick_h_> bac: ugh, sounds like nutty bugs
<bac> rick_h_: to complete my day of frustation i found my car battery dead.  and when i used my neighbor's car to jump start it, his car died and wouldn't restart.  should've stayed in bed.
<rick_h_> ouch, taking down the neighbors with you? That's not good. 
<bac> rick_h_: is wallyworld working with anyone who overlaps with us?
<rick_h_> bac: martin I believe is running the show from his team
<bac> which martin?
<bac> nicks, man. proper names due me no good.
<rick_h_> bac: packman? /me goes to check spelling
<bac> mgz.  cool.
<rick_h_> I'm not sure on his nick :P
<bac> and best, he's in a proper time zone
<rick_h_> there you go, mgz :)
<rick_h_> so he's doing the actual CI setup and overlaps with us. 
<bac> ok, i'll ping him when i come back.
 * bac bbiab
<rick_h_> have fun
<bac> rick_h_: so the goal is to just move charmstore over there, not the others?
<bac> hi rbasak, i've put in SRU info on the three bugs for quickstart.  can you have a look and tell me if i need to make changes?
<rick_h_> bac: yea, the gui and private tools I think we'll keep with the current setup and be aware that we should rebuild CI at some point due to juju issues
<rick_h_> bac: but core folks will also work on the charmstore and it makes sense to have that together with the other juju tools
<rick_h_> bac: and rbasak is looking at the SRU, he commented before you joined irc this morning so rocking on woo!
<bac> rick_h_: ever see this on azure?
<bac> juju-quickstart: error: bad API response: cannot assign unit "juju-gui/0" to machine 0: unit placement is not supported with availability-sets-enabled
<rick_h_> bac: oh hmm no. But we got CI up before the availability set support landed in juju
<rick_h_> that's going to be interesting
<bac> rick_h_: yeah, the old instances don't have a.s.  my new one does and it is pissy
<rick_h_> bac: yea, I wonder how that effects machine view
<bac> rick_h_: i'm going to tear it down and file a bug against quickstart.  we can reassign later if needed
<rick_h_> that sounds a LOT like we need to support doing something there in order for MV to work in the GUI
<bac> i have done some mighty fine juju QA this week.  :(
<rick_h_> bac: https://github.com/juju/docs/issues/85 says there's some docs on the feature in juju-core/doc/azure-provider.txt
<bac> cool
<rick_h_> bac: yea, availability-sets-enabled is a new attribute at bootstrap time and kills manual placement
<rick_h_> wtf
<bac> hey, i found a work-around to a juju annoyance:
<bac> juju destroy-environment `juju switch`
<bac> no more juju nanny state
 * rick_h_ relocates to the coffee shop to get over the shock of the news
<rbasak> rick_h_, bac: I made a couple of very minor changes to meet SRU requirements for the "Support trusty environments" backport: http://paste.ubuntu.com/7710956/
<rbasak> Just FYI. Tests still pass, and I'm happy that this should be fine.
<rbasak> I think you've improved processes quite a bit since that commit, so this should be easier next time - just one issue per commit, please :)
<bac> rbasak: thank you
<bac> rbasak: so it'll go in as version 1.3.1?
<rbasak> bac: yes - because I'm cherry-picking from trunk, and I think I'm missing at least one commit that went into 1.3.2. So I can't really call it 1.3.2.
<bac> rt
<rbasak> This is pretty common in SRUs - no process issue here. I just shouldn't bump the version unless I'm taking the whole new version wholesale, and I'm not doing that because it's easier for me to SRU-justify fewer changes.
<rbasak> Well, for *you* to SRU-justify fewer changes. Thanks for doing those bugs :)
<bac> np rbasak. i felt my 'regression rationals' were a bit weak and transparentl so.  :)
<rbasak> bac: we'll worry about that if the SRU team object :)
<rbasak> I've got the juju-quickstart SRU ready for upload now, but we can't get it landed or tested without the juju-core MRE SRU in place. I'll work on that now.
<bac> rbasak: ok.  just let me know if you need anything from me.
<bac> rick_h_: it is a little bit of a non-issue now, but i did just get a quickstart launch on azure with gui running.
<rick_h_> bac: yay? :)
<bac> rick_h_: while i wait on mgz i'll see if i can get a jenkins slave to work
<rick_h_> bac: do we have bugs/links/etc for the stuff you hit that caused us grief?
<rick_h_> bac: just want to make sure we're good citizens and when I say we've had issues they're logged
<bac> of the two juju ones, one is fixed in trunk, the other was on the critical list for 1.20.  i have not filed one for the availability-sets impact on us
<rick_h_> bac: yea, that'll be one of my goals to look at what we need to do for that across our tools
<bac> rick_h_: i'll open a bug limited to quickstart just for tracking
<rick_h_> bac: ok thanks
<rick_h_> bac: I think the bug needs to be two-fold. One to make sure we don't colocate by default on azure (like lxc) and second that we allow that flag to override the bootstrap is part of quickstart as well. 
<rick_h_> bac: which kind of falls into an existing quickstart bug of not being able to pass extra bootstrap config already
<bac> rick_h_: qs could look at the yaml and error if azure without that setting
<rick_h_> bac: don't follow? 
<rick_h_> which yaml?
<bac> environments.yaml
<rick_h_> bac: well we want them to use availability set
<rick_h_> sets
<bac> azure without availability-set-enabled: false is an error
<rick_h_> it's enabled by default because it's the only way to make sure your env doesn't fall over on yo
<rick_h_> you
<bac> ok
<rick_h_> what they did makes sense, it just puts us in a bind as far as user interactions and how our tools currently work
<bac> i shall write a descriptive bug and the proscriptive part can come later
<rick_h_> so I can't really even argue against it, just have to get it fixed for users
<bac> rick_h_: bug 1335121 filed, maint card created
<_mup_> Bug #1335121: Azure availability set support causes failure <juju-quickstart:New> <https://launchpad.net/bugs/1335121>
<rick_h_> bac: ty 
<bac> rick_h_: fwiw, i finally got jenkins and jenkins-slave up in the new azure env and the slave does show up in the config.  recall it did not on our current environment.  but the new azure uses work-arounds that are not appropriate for production.<shrug>
<rick_h_> bac: yea
<rick_h_> bac: ok, I think it's good that we leared a lot, we know that we need to update CI at some point, but can't today due to azure issues. Maybe we can when 1.20 hits
<bac> rick_h_: so our current ci is a little brain dead but we dare not tear it down!  :)
<rick_h_> bac: but should hold pattern for now and coordinate with martin/ian on CI for charmstore
<rick_h_> :)
<bac> rick_h_: mgz does not appear to be around today
<rick_h_> bac: ok, let's add a tracking card to the charmstore lane and bring it up next week
<rick_h_> maybe by email cc'ing me/ian as we had the conversation
<rick_h_> bac: did you get rogpeppe's branch to pass tests and build properly?
<bac> ok.  mgz works with ian and axw, so no one around until monday
<rick_h_> bac: if so can you LGTM it and rogpeppe can land it and move forward. 
<bac> rick_h_: i'll double check
<rick_h_> bac: sounds good (on the mgz/monday work with the net week)
<rogpeppe> bac: make sure you pull juju-core and godeps to update its dependencies first, please
<rogpeppe> bac: because it needs to work with juju-core's deps
<hatch> jujugui I'm still in need of a review https://github.com/juju/juju-gui/pull/407
<kadams54> Looking
<rick_h_> jcastro: or Makyo or kadams54 ^ ?
<rick_h_> sorry, jcsackett ^
<rick_h_> thanks kadams54 
<hatch> thanks
<rogpeppe> hmm. there's an awkward ambiguity in charm urls with respect to the store URL name space
<rogpeppe> i was thinking that it would be logical to allow https://charmstore.com/precise/wordpress/any/file/path/in/the/zip/file
<rogpeppe> for retrieving contents of charms
<rogpeppe> since https://charmstore.com/precise/wordpress currently retrieves a zip file of the whole thing
<rogpeppe> but...
<rogpeppe> you can't tell if charmstore.com/trusty/precise/foo is a file called precise/foo in the charm called trusty, or a file called foo in the trusty version of the charm called precise
<rogpeppe> so perhaps we're best just serving individual files from a different root
<rogpeppe> say charmstore.com/contents/trusty/wordpress-23
<rogpeppe> and we could accept only fully qualified URLs with a specified series and revision
<rogpeppe> rick_h_, hatch, bac: what thinkest ye?
<bac> rogpeppe: juju-core dependencies.tsv reference errgo but it isn't in my tree.  why doesn't 'go get -u' fetch it for me?  or is it not really required?
<rogpeppe> bac: you probably need go get -t
<bac> damn that -t
<rogpeppe> bac: but godeps -f -u *.tsv
<rogpeppe> should do the job
<rogpeppe> bac: if you do that, you shouldn't need to use go get at all
<bac> i didn't know of -f
<rogpeppe> bac: it's a new flag
<rogpeppe> bac: you might need to go get -u launchpad.net/godeps
 * rogpeppe is minded to get rid of -f and make it the default. possibly with a -F flag to supress automatic get
<rogpeppe> it's almost always what you want
<rick_h_> rogpeppe: I think that we can't allow a charm to be named a series. 
<rick_h_> rogpeppe: and that will avoid any confusion/issue.
<rogpeppe> rick_h_: is that actually enforced now?
<rick_h_> rogpeppe: I believe it's an error on charmworld ingestion
<rick_h_> rogpeppe: I don't know about the charmstore
<rogpeppe> rick_h_: that does mean we can never add a series that happens to mirror an existing charm name
<rick_h_> rogpeppe: but I think it's sane to enforce and helps us keep things clean
<rick_h_> rogpeppe: we'll end up having a nice conversation with the charm author :)
<bac> ok, rogpeppe, i've done all of that now.  so i'm in my GOPATH for juju/charm.  how do i fetch your version for testing?
<rogpeppe> bac: git add remote rogpeppe git@github.com:rogpeppe/charm
<rogpeppe> bac: git fetch rogpeppe
<rogpeppe> bac: git checkout rogpeppe/bundledata
<rogpeppe> bac: wait!
<rogpeppe> bac: it's no longer in juju/charm
<bac> rogpeppe: well i want the exact version from your pull request
<rogpeppe> bac: it's in gopkg.in/juju/charm.v2
<bac> rogpeppe: we're not talking about https://github.com/juju/charm/pull/9
<rogpeppe> bac: so, first do: go get gopkg.in/juju/charm.v2
<rogpeppe> bac: yeah, we are
<rick_h_> rogpeppe: but I think this is why I want to do the api space spec and planning. To hammer all the rules/etc out in the merging of charmstore vs charmworld apis. 
 * bac is totally confused
<rogpeppe> bac: gopkg.in goes to github.com to get the code
<rick_h_> rogpeppe: because precise/wordpress doesn't return a zip in charmworld, but a json of the charmdata
<rogpeppe> bac: the actual branch is "v2" in juju/charm
<rogpeppe> rick_h_: i see
<rick_h_> rogpeppe: so we need to plan out a v4 api that makes sense of both ends and update clients/etc 
<rogpeppe> rick_h_: planning the url name space is what i've been doing
<rick_h_> rogpeppe: and I'd rather do it once vs ad-hoc
<rogpeppe> rick_h_: yup
<bac> rogpeppe: so do i keep $GOPATH/src/github.com/juju/charm ?
<rogpeppe> bac: you do need to keep that for a while, because juju-core still depends on it
<rick_h_> rogpeppe: ok, can you share out a doc then with the current store api endpoints and the charmworld ones and we can go through them in a call and resolve conflicts/plan updates that make sense?
<rogpeppe> bac: but if you go into $GOPATH/gopkg.in/juju/charm.v2 and follow above instructions, you should get a copy of my branch for testing in the right place
<rogpeppe> rick_h_: yup, sounds good.
<bac> rogpeppe: ok, will do.  pulling from a rogpeppe remote seems dangerous, though, as i dont' know it is really the one under review.
<rick_h_> rogpeppe: http://charmworld.readthedocs.org/en/latest/api.html has the info for charmworld
<bac> rogpeppe: what if you had two branches in flight?
<rogpeppe> bac: i suggested "git fetch", not git pull
<rogpeppe> bac: that fetches the branch data but doesn't actually update anything
<rogpeppe> bac: then you can check out the branch you need
<bac> rogpeppe: ok, i didn't see that bit
<rogpeppe> bac: of course, it's git remote add, not git add remote
<bac> rogpeppe: yeah, i figured that out
<rick_h_> jujugui call in 5
<rick_h_> kanban please
<bac> rogpeppe: http://paste.ubuntu.com/77115
<rogpeppe> bac: The Paste you are looking for does not currently exist.
<bac> rogpeppe: oops: http://paste.ubuntu.com/7711522/
<Makyo> jujugui call in 2
<rogpeppe> and that's after you've done a "godeps -u dependencies.tsv" on the latest tip of juju-core?
<rick_h_> jujugui call now jcsackett Makyo (ant is out) 
 * bac joins
<bac> rogpeppe: es
<bac> s/es/yes/
<bac> rogpeppe: yes, i'd done the updates as you requested
<hatch> jcastro marcoceppi you can now hide the charmbrowser with a shortcut key :)
<marcoceppi> \o/
<hatch> marcoceppi ctrl+alt+h will hide it, you can see all the shortcuts with shift+/
<rick_h_> hatch: or ?
<rick_h_> I thought ? worked for shortcuts
<hatch> well to get a ? you hit shift+/ :D
<rick_h_> oh
<rick_h_> well ? seems a lot easier than shift+/ :P
<hatch> haha I always say shift+/ because I just assume people will hit / thinking of ?
<hatch> maybe I'm the edge case :D
<hatch> kadams54.....the test is still running......
<hatch> lol
<hatch> oops I ordered something from amazon from a third party....
<hatch> darn, it's going to take a couple weeks to get here :(
<rick_h_> whoops
<hatch> next time I guess I should pay more attention
<hatch> heh
<hatch> it's just so easy to buy things sometime
 * rick_h_ goes to get lunch
<hatch> Makyo so I'm working on getting the ghost inspector to show on drop again and running into an issue where if you open an inspector 
<hatch> then close it, when you deploy it'll re-open that inspector
<hatch> I remember you fixed this once before do you have any pointers?
<Makyo> Doesn't sound familiar to me, hmm... May be in the deploy callback?
<hatch> well you worked on the 'on deploy switch to a service inspector' bit
<hatch> maybe it's in the inspector code
<hatch> ahh I think that's where it is
<hatch> go sounding board go!
<hatch> these ads....hilarious... http://www.autoblog.com/2014/06/27/colorado-washington-pot-dui-psa-ads-video/ 
<Makyo> jujugui https://github.com/juju/juju-gui/pull/406 QA steps are a little more extended now.  Works in sandbox, but requires a bit of a wait - feel free to do something else in the meantime.
<kadams54> Makyo: I'll take a look.
 * rogpeppe is done for the day.
<rogpeppe> happy weekends all
<rick_h_> have fun rogpeppe 
<hatch> cya rogpeppe  have a good weekend
<hatch> jujugui lf a quick review/qa on https://github.com/juju/juju-gui/pull/408
<hatch> rick_h_ any preference for another card for me?
<rick_h_> hatch: sec looking
<hatch> thanks
<rick_h_> hatch: no preferences. take your pick. the bundle delay thing might be a short/sweet one in maint?
<hatch> sure that sounds like a good small one
<rick_h_> Makyo: branch land failed. npm bit the farm
<Makyo> Booo
<rick_h_> jujugui just tried to walk a person in #juju through machine view to do some work. |-| far from getting it working like he wanted
<hatch> rick_h_ just read the backlog.... his comment about wanting to drag to the container column was something I was thinking about too (remember the hover over machine to show containers?) I think the issue we are solving is one of massive scale, if you have 10-20 containers total we can easily show them all at once
<rick_h_> hatch: yep
<hatch> this is a UX discussion of course
<hatch> without UX
<hatch> :D
<rick_h_> hatch: definitely, I think the main thing is that there's not much unknown/new. The lxc/container syntax threw him off
<rick_h_> hatch: and the fact that machine 0 doens't show any services because it's node 0 and has gui hulk-smashed on it I guess?
<rick_h_> The 'root level' threw him off. So we need to correct that
<hatch> I never really thought of this, but if you were a noob and were presented with machine view, how would you know to click on each machine to see the containers
<hatch> ?
<rick_h_> and some things that are in trunk that he didn't have in his gui deploy
<hatch> definitely a UX problem there
<rick_h_> hatch: right, but that's why we've talked about having the column just say "select a machine to view container details" or something by default
<hatch> right right
<hatch> but maybe showing all containers is also a possibility
<hatch> and then when you select a machine it filters the list
<rick_h_> overall felt good but was interesting to grab someone off the irc street and have htem walk through it :)
<hatch> I think I'll send that idea to peeps
<rick_h_> hatch: do me a favor, grab that chat maybe and just put it in a pastebin and put it up?
<rick_h_> hatch: and we can break it down from there at some point
<hatch> sure
<hatch> hmm my client does not copy/paste well heh, investigating
<hatch> hmm and no logs
<rick_h_> hatch: ok, np. I can pull it.
<rick_h_> delegation fail! :)
<hatch> if you could that would be awesome - the logs werent' enabled for that channel for some reason
<hatch> and copy/paste fails hard because of the layout I guess
<hatch> it puts each thing on a new line and skips names sometimes so it's very hard to read
<rick_h_> hatch: https://gist.github.com/9f0f521c60ca7a15fd13.git
<hatch> thanks
<hatch> rick_h_ do you remember if we brought up to them already about having a onboarding message in the third column?
<rick_h_> hatch: no, but I've got a UX meeting monday and will bring it up
<hatch> ok so I won't send this email then? Or should I send it so you have something to reference?
<rick_h_> hatch: you can send it, we can chat about it on monday
<hatch> ok
<rick_h_> start a conversation and all that
<hatch> rick_h_ email sent, sorry it's lengthy 
<hatch> :)
<hatch> jujugui lf a quick review/qa on https://github.com/juju/juju-gui/pull/408
<bac> rick_h_: throwing the poor new guys at amulet in the first week.  brutal.
<hatch> bac lol
<hatch> oo rah!
<rick_h_> hatch: heh all good
<rick_h_> bac: :) well I was hoping to find papercuts in charms that had amulet tests since they audit I thought there'd be a bunch 
<bac> rick_h_: it'll just be funny when the ask the rest of us about amulet and we all shrug and say "dunno, haven't really ever used it."  :)
<rick_h_> bac: look ok overall?
<bac> rick_h_: yeah, nice
<bac> i think i'd be happy to get such an intro doc on my first day.
<rick_h_> bac: cool, yea we'll see how it goes
<hatch> it took me a year to get invited to all the right mailing lists! lol
<hatch> that's half the fun!
<hatch> haha
<kadams54> hatch: still need someone to look at 408?
<hatch> I do!
<hatch> thanks
<kadams54> What?
<kadams54> Ohâ¦
<kadams54> No.
<kadams54> I didn't mean I was going to look at it.
<kadams54> ;-)
 * rick_h_ steps away for a few 
<hatch> kadams54 hah damn uuuuu
<kadams54> hatch: shipit
<hatch> dun! thx
<hatch> jujugui looking for a quick review/qa https://github.com/juju/juju-gui/pull/409
<arosales> is lp or git the recommended way to file bugs against juju-gui?
 * arosales doesn't see "issues" on https://github.com/juju/juju-gui
<Makyo> arosales, lp, I believe.
<arosales> Makyo: ok, thanks. Are you still doing proj mang. and releases out of lp?
<hatch> yep lp plz
<hatch> we are
<hatch> er
<hatch> well the charm
<bac> hatch: you ok?
<hatch> bac lol what?
<Makyo> arosales, hatch the charm is through lp, but can pull gui trunk from github now
<bac> hatch: well, that last flurry of comments made no sense.
 * arosales will submit bug in lp -- thanks!
<hatch> bac haha sorry
<rick_h_> arosales: what's the issue?
<arosales> rick_h_: I had a user report http://paste.ubuntu.com/7712762/  but I was uable to reproduce myself
<arosales> so I was going to suggest he open a bug if it continues to plague him.
<rick_h_> arosales: right, he filed a bug and I triaged it
<rick_h_> arosales: it's FF only atm and filed but low atm
<hatch> what the....
<hatch> heh
<rick_h_> https://bugs.launchpad.net/juju-gui/+bug/1335192
<_mup_> Bug #1335192: Drag and drop sidebar text to itself navigates in firefox <juju-gui:Triaged> <https://launchpad.net/bugs/1335192>
<arosales> ah ok, good to hear it was filled
<rick_h_> yep, actually someone I know...used to work for him ages ago
<hatch> rick_h_ ohh ok - there is a e.stopImmediatePropogation() missing somewhere there
<rick_h_> hatch: something with drop target/etc something
<hatch> there was an issue with that in FF before with dropping on the canvas
<rick_h_> hatch: yea
<hatch> stepping out for lunch bbl
<kadams54> hatch: looking at PR 409
<bac> jujugui: i'm toast so i'm calling it a day.  have a nice weekend
<kadams54> bac: have a good weekend too!
<rick_h_> bac: have a good weekend
<Makyo> jujugui quick review, slightly longer QA: https://github.com/juju/juju-gui/pull/410
<kadams54> Makyo: I'll take a look in just a moment. You and hatch are killing it today.
<Makyo> Feels good to be off that stupid upgrade task for a day or two
<rick_h_> I'm also going to run away. Have a good weekend folks!
<hatch> yo
<hatch> kadams54 isn't confirmation the religious thing
<hatch> vs conformation
<hatch> or did I mix those up? hah
<hatch> yeah I'm pretty sure it's conformation :)
<hatch> maybe it's confirmation
<hatch> oh, confirmation is the religious thing and the act of confirming 
<hatch> hah
<hatch> long week I guess
<kadams54> hatch: yeah, "confirm" is the root word, so "confirmation". Which is also a religious ceremony. Yay weekend!
<hatch> lol
#juju-gui 2014-06-29
<huwshimi> Morning
<rick_h_> morning huwshimi 
<rick_h_> how goes?
<huwshimi> rick_h_: Hey, good thanks. Yourself?
<rick_h_> heh, crashing thumpers monday so yay?
<rick_h_> huwshimi: how goes the work on the service blocks?
<huwshimi> rick_h_: I actually paused on that as I didn't have the brain power for it on Friday :)
<rick_h_> huwshimi: ah ok
<rick_h_> huwshimi: oh, missed that the name of the card changed :)
<huwshimi> :)
<rick_h_> huwshimi: there's another one for you when you get free with some styling help for the non-styling folks. "Style the upgrade inspector view..."
<rick_h_> huwshimi: ok, carry on then. Just wanted to make sure you weren't blocked. I'll get back to having the rest of my sunday. 
<huwshimi> rick_h_: Yep, no problems, I'll take a look at that too.
<huwshimi> rick_h_: Have a nice evening :)
#juju-gui 2015-06-24
<arosales> https://jujucharms.com/ 503 for others?
<arosales> ah back now
<rick_h_> arosales: checking, we've got a once in a while timeout thing we're trying to get a fix into prodstack I think you hit
<rick_h_> arosales: our pingdom checks are hitting it every once in a while 
<arosales> rick_h_, it 503'ed for maybe a minute for me, enough to post in here, but then came back
<rick_h_> arosales: ok, will pull logs and make sure what it hit. 
<arosales> working for me now fwiw
<arosales> so don't spend too much time on my account :-)
<rick_h_> all good, it's something we're monitoring until we can land the fix out to prod
#juju-gui 2015-06-26
<mhilton> morning everyone
#juju-gui 2018-06-27
<nik> hi
<Guest70425> hi
<Guest70425> hi
<Guest70425> i have no idea where i am
<Guest70425> what is this?
