#juju-gui 2012-11-12
<frankban> hi all, is the staging server broken?
<frankban> morning bac
<bac> hi frankban
<bac> good weekend?
<frankban> bac: yes thanks
<frankban> bac: unfortunately the staging server seems broken
<bac> oh, perhaps i can help!
<bac> seems mighty dead
<bac> frankban: trunk has a file with conflict markers checked in.
<bac> i'll find and fix it
<frankban> bac: thanks
<bac> frankban: it was not a conflict in trunk as i suspected but just a conflict in the checked out copy on the server.
<bac> it should be back in a second
<frankban> bac: cool
<bac> still dead
<frankban> bac: Uncaught ReferenceError: GlobalConfig is not defined 
<bac> frankban: any ideas what could be causing that?
<bac> separately, there is some problem with the rapi-rollup branch getting bad response from LP
<bac> when the cronjob does a 'bzr pull'
<frankban> bac: it seems that assets (e.g. yui.js) cannot be found
<frankban> (sometimes) :-/
<bac> frankban: modules.js:1ReferenceError: Strict mode forbids implicit creation of global property 'GlobalConfig'
<bac> so where should it be coming from?
<frankban> bac: I guess GlobalConfig is created in yui.js
<bac> modules.js looks to have a new directive "ignoreRegistered = true"
<bac> i wonder if that is involved
<frankban> bac: locally it works
<bac> yep
<bac> frankban: i adde a 'var' in front of GlobalConfig in modules.js and it works
<bac> it looks like a 'use strict' may have been inserted somewhere that was preventing GC from implicitly being created
<bac> i made the change locally on the server, so it may fall over when the cronjob runs again
<jovan2> hi guys - is there a mailing list for our juju-gui team? I've a couple of use cases I'd like to share.
<frankban> bac: back from lunch, I also see artifacts at the bottom of the page, it seems the slider isn't rendered correctly anymore, do you see the same?
<bac> frankban: yes, i see that
<frankban> bac: I think that also causes (in some way) the central part of the body to exceed the width
<frankban> tveronezi: morning, I am having troubles with some kind of cache when I change templates. The browser does not show changes unless I run "make clean" and "make server" again. and "appcache-force" doesn't help. Any ideas?
<frankban> oh, today is really a monday...
<tveronezi> Hi frankban. I think you need to clean the browser cache. 
<tveronezi> I have the same problem, but cleaning the cache (ctrl+shift+del) does the job. 
<frankban> tveronezi: and then check "Empty the cache", right?
<frankban> tveronezi: did that, without effect
<tveronezi> frankban... oh... you need to run the "make debug" instead of make server also.
<frankban> tveronezi: ah!
<tveronezi> otherwise you will use the compressed version of our app.
<bac> frankban: i suspect the problems we're seeing on uistage are due to the minimization work that landed recently.
<frankban> cool, and now yui.yahooapis.com does not work... 
<bac> tveronezi: can you look at the staging server
<frankban> bac: yes, locally with make debug it works well
<bac> there are weird layout artifacts.
<bac> tveronezi: there had been a conflict with config.js and i may have resolved it incorrectly
<bac> frankban: can you replicate staging locally by not using debug?
<bac> by that i mean the problems we're currently seeing on staging
<frankban> bac: I can replicate the artifact at the bottom of the page, I cannot replicate the GlobalConfig error. and cannot double check now because yui.yahooapis.com is darn slow
<frankban> bac: ok, double checked: I confirm: artifacts using "make server", everything ok using "make debug"
<tveronezi> bac, frankban... I will check that... 
<bac> jovan2: we have a launchpad team with a mailing list.  you can join the team at https://launchpad.net/~juju-gui-peeps and then subscribe to the mailing list.
<jovan2> thanks bac
<jovan2> bac: I think somebody needs to allow me to view that page, would that be Gary or Kapil?
<bac> jovan2: yeah, i see it is a private team.  kapil is the owner
<jovan2> hazmat: can you add me to https://launchpad.net/~juju-gui-peeps please?
<frankban> mattuk1972 or jovan2: do you have time for a quick UX review (just a screenshot) for my branch: replace bootstrap icons with our assets in the charm panel
<mattuk1972> frankban: sure
<mattuk1972> frankban: just email it along 
<jovan2> frankban: yes please
<frankban> mattuk1972, jovan2: thanks, email sent
<mattuk1972> cool
<mattuk1972> frankban: gets a big thumbs up from me - nice one 
<jovan2> frankban: looks good to me
<frankban> mattuk1972, jovan2: great, thanks
<frankban> bac: do you have time for a review?
<bac> frankban: sure, just a minute
<frankban> bac: thanks, for when you are ready: https://codereview.appspot.com/6819131
<bac> frankban: looking at it now
<bac> even tagged your card!
<teknico> oh right, forgot to do that :-)
<frankban> bac: thanks
<bac> frankban: i cannot get your branch to run locally
<bac> Y.juju is undefined
<bac> this is with 'make debug'
<frankban> bac: :-/
<bac> trying trunk now
<bac> tveronezi: did you get a chance to look at the possible minimization problems?  i cannot get trunk to load now.
<tveronezi> bac, frankban: I know what is going on... 
<tveronezi> bac, frankban: the system does not load the slider-base.css file. we need to add it manually. I am trying to figure out how to load it automatically.
<bac> tveronezi: there are other problems.  running server i get an error trying to define 'app'
<bac> mean to say, there is an error in the line 'app = new Y.juju.App' as Y.juju is undefined
<frankban> bac: trunk runs well for me locally. could you please check if all the resources from the web are correctly loaded?
<tveronezi> bac, frankban: this last one I cannot reproduce... bac can we talk after the meeting?
<bac> frankban: using the 'network' tab i don't see any failures to load.  is there somewhere else i can look?
<frankban> bac: no AFAIK. my only remaining suggestion is to clean the browser cache, then run "make clean" and then "make debug".
<bac> frankban: i've done all of those.  :(
<bac> meeting
<frankban> bac: just did the same thing, and it works... weird
<bac> teknico: hangout?
<bac> jovan2: hangout
<jovan2> on my way
<tveronezi> bac... one sec.... 
<bac> staging should be working now and updates at :00,15,30,45
<bac> frankban: i still cannot get my local env to work.  so i can't do your review until after my lunch and your EOD
<jovan2> bcsaller: hi, if cs is abbr for charm store, what is the abbr for Local charm?
<frankban> bac: no problem, I will land it tomorrow morning, or later if everything is fine
<bcsaller> jovan2:  local:...
<bcsaller> so local:series/name
<jovan2> bcsaller: thanks. Another: if user loads a local config file, should they be able to then amend any settings as well?
<bcsaller> jovan2: local: implies a local repository, an on disk collection of directories of charms
<bcsaller> local: for a different user might be different, but the charm series/name-rev should still be unique in the environment
<jovan2> bcsaller, I was thinking of the config settings for any charm, you have the option to load a config file.
<bcsaller> thats different, those are settings applied to the charm, same as the web form now but stored in a file
<bcsaller> not tied to the notion of local or not, a file of settings could work with any type of charm
<jovan2> bcsaller, ok so that's different, understood. But should a user be able to amend settings *after* loading a config file?
<jovan2> bcsaller, currently they load a config file but then don't see the individual fields any more.
<bcsaller> jovan2: yes, config settings can be changed at any time as far as the system is concerned, for some charms it might not make sense but thats not something we know
<jovan2> bcsaller, ok so when we allow a user to load a config settings file we should still display the fields with the values from the file, but still allow the use to edit individual fields?
<bcsaller> yes
<jovan2> bcsaller, thanks.
 * tveronezi lunch
 * tveronezi back
<jovan2> bcsaller: when you said earlier that a user could ssh with a unit name, is the unit name the same as the unit ip address in this case?
<bac> jovan2: no, you use 'juju ssh wordpress/1' to get to a unit
<bac> juju maps it to the ip address
<bac> doh
 * tveronezi brb...
 * tveronezi back
<Makyo> Could use a few reviews, if folks have time/energy.  Charm panel border: https://codereview.appspot.com/6812107  Click subordinate relation indicator to toggle relation visibility (was remove sub rels): https://codereview.appspot.com/6782063/
<tveronezi> bcsaller: do you have a minute for a pre-impl call?
<bcsaller> tveronezi: sure do
<bcsaller> on g+
<tveronezi> ok
<bcsaller1> tveronezi: sorry about that, it froze up
<bac> tveronezi: i suspect a new 'use strict' that you introduced is causing the definition of GlobalConfig to fail.  it looks like inserting a 'var' in both places it is defined is all that is required.
<tveronezi> bac: g+?
<bac> tveronezi: nah, i'm having a hard time reproducing it, even with a fresh checkout.  but, i have seen it locally and on staging, so let's keep it in mind.
<tveronezi> bac: I think you are right. I am just surprised I didnt see it locally. It should break in production mode because after merging the css files, the resulting file will have the "use strict". The point is that the "GlobalConfig" has no "var" declaration, so it should break the application for me too. We definitely have a problem... I will check it again...
<tveronezi> s/css/js
<bac> tveronezi: thanks
<tveronezi> bac: It seems we are loading GlobalConfig twice. Can you make this change https://pastebin.canonical.com/78235/ ?
<bac> tveronezi: i can but i can no longer reproduce the problem.
<tveronezi> bac: so strange... I see the issue there. I mean, I see the GlobalConfig being declared twice. Well... I think I will commit this change in my next branch. Unless we can reproduce it again.
<bac> tveronezi: and what about 'var GlobalConfig'?
<bac> tveronezi: also if you wanted to do a branch with just those fixes we could push it through under the 'testfix' rules, i think.
<tveronezi> When we run the minimifier, it merges all the variables in a single declaration. So, the resulting var is something like... 
<tveronezi> var juju_config={..., ,GlobalConfig={...,GlobalConfig={...
<tveronezi> bac: ok... I will create a branch for that.
<bac> tveronezi: i'd like to use a package from the gallery ('gallery-ellipsis').  i thought some of the tools would find it and suck it in if i just referenced it in a requires
<bac> ... in a requires section.  that doesn't seem to be true.  can you give me some advice.
<tveronezi> Where do you declare it? "modules.js"? 
<tveronezi> bac ^
<bac> tveronezi: nope.  i was looking at how gallery-markdown was used.  not declared in modules.js.
<bac> modules.js does not reference any third party or gallery stuff
<tveronezi> bac: hmmm... Let me check it. I had some problems with the  "gallery-markdown" too.
<bac> tveronezi: i saw you added it to 'reqs' in the merge-files script
<tveronezi> bac: probably "'gallery-ellipsis" has the same problem.
<bac> i tried that too and it didn't work
<tveronezi> bac: our yui assets dont include 'gallery-ellipsis'. At least I didn find it. Is it from yui?
<bac> tveronezi: it is in the yui gallery, like markdown
<bac> tveronezi: http://yuilibrary.com/gallery/show/ellipsis
<tveronezi> bac: Markdown is not there too. If you add 'gallery-ellipsis' to the "utils.js" file (for example), the system will call...
<tveronezi> bac: http://yui.yahooapis.com/combo?gallery-2012.10.31-20-00/build/gallery-markdown/gallery-markdown-min.js&gallery-2012.10.31-20-00/build/gallery-ellipsis/gallery-ellipsis-min.js
<tveronezi> bac: thanks for helping me to understand why 'gallery-markdown' is not working too. :)
<bac> tveronezi: i want to use it in charm-panel.js and have added it there.  i don't see it getting loaded from yahooapis
<tveronezi> bac: that is strange... again. I see it being loaded. I swear! :)
<bac> tveronezi: ok, i'll poke at it more tomorrow.  thanks.
 * Makyo dogwalk.
#juju-gui 2012-11-13
<bac> hi frankban 
<frankban> hi bac 
<bac> frankban, i see your sprite branch is now on staging.
<frankban> bac: I am seeing the behavior you described there
<bac> frankban, oh, it seems to work for me!
<frankban> bac: lol 
<bac> frankban, but i now see that the up/down chevrons have a white background, not transparency, so they look funny on the grey background.  have you seen that?
<frankban> that's crazy bac, I also see the problem you described in the review (the chevron in the menu bar is still the old one)
<frankban> bac: it seems that the old index.html is being served by staging
<bac> hmm
<bac> browser cache?
<frankban> bac: cleaned, mabybe the html cache manifest?
<frankban> bac: could you please try to run "make appcache-force" in staging, and then restart the server?
<bac> frankban, i did a make clean, is that sufficient?
<bac> check it out now
<bac> frankban, i did appcache-force/restart
<frankban> bac: now it works, thanks, and you are right, the chevrons are not transparent
<bac> i think clean should wipe out the appcache manifest but it does not
<bac> frankban, glad we're all seeing the same thing now
<frankban> bac: maybe we should run  appcache-force each time we update staging. We can clean the cache and the app data each time, but not our users.
<bac> frankban, yes, i think it should be part of the clean target and we should just run make clean
<frankban> bac: re the chevrons, they are transparent in the assets and in the sprite :-/
<bac> oh
<bac> frankban, will you also follow up with the designers regarding chevron up and down?
<frankban> bac: you mean, the reversed directions?
<frankban> bac: re the chevrons, locally I have the sprite with a transparent backgorund, in staging the sprite is not transparent
<frankban> bac: white background in staging :-/ it seems we should fix how we deploy staging.
<frankban> tveronezi: any idea on why the sprite's background in staging is not transparent?
<tveronezi> frankban: I am trying to see what is the problem... just a sec. :)
<frankban> tveronezi: cool thanks
<tveronezi> frankban: I didn't get the problem. Is it something related to the header? It does not use the "sprite". It uses a regular image. I found this trick to make transparent backgrounds, but I dont see it in our code. http://css-tricks.com/snippets/css/transparent-background-images/
<frankban> tveronezi: it is related to the chevrons_(up|down) in the charm panel. they have a white background in staging, they are transparent locally. they use the sprite. Inspecting the code, it seems that the sprite in staging is not transparent
<frankban> tveronezi: to see those, you might want to clear your browser cache
<tveronezi> frankban: hmmm... they look the same to me... http://ubuntuone.com/3ukBtOlhcydsB8VtlZtKha  http://ubuntuone.com/1QpOBke8x9ah5A9BkTj0CZ
<frankban> tveronezi: I am referring to the charm description view. Open the charm panel, select a charm, you should see chevrons on each section of the description.
<gary_poster> hey all
<tveronezi> frankban... hmmm. I see the problem in both local and staging. I need to check the sprite generation. 
<frankban> tveronezi: cool
<gary_poster> teknico, hey.  how go charm tests?  You about ready with a branch?  or would it be good to have someone to pair with?
 * gary_poster reviews
<gary_poster> I am reviewing Makyo's bug 1077006 branch
<_mup_> Bug #1077006: Charm panel left border should be 2px as per UX design <juju-ui:Triaged> < https://launchpad.net/bugs/1077006 >
<benji> IRC works better when you turn on your client.
<gary_poster> words to live by
<hazmat> g'morning
<bac> gary_poster, matt's branch has two reviews.  both frankban and i tagged the card before starting.
<bac> morning hazmat.  i had to poke uistage a bit yesterday and today.  i think we need to update the cronscript to 'make appcache-force' before restarting the gui
<hazmat> bac, k, i'll take care of it
<bac> hazmat, i also changed the cron to run every fifteen minutes as that is what most people thought was happening.  it was actually only run every 30 minutes.
<hazmat> bac, where is the cron now?
<hazmat> i don't see it in crontab for ubuntu or root?
<hazmat> just added make appcache-force to cron script
<bac> hazmat, 'crontab -l' and 'crontab -e' is what i used
<hazmat> ah.. ic
<bac> as ubuntu
<hazmat> bac are you sure re 30m?
<bac> hazmat, previously it was 15,30
 * hazmat discards some faulty gray matter
<bac> oh, sorry, it was 15,45
<gary_poster> bac cool thx.  Forgot about that.  In somewhat related issue, I am seeing problems in my local instance having to do with some images that are being rendered below where they are supposed to: http://ubuntuone.com/6wirTIHiK40RGV3ahJ3a7G
<gary_poster> I have done make appcache-force
<gary_poster> and cleared cache
<gary_poster> I saw some discussion of problems in log from yesterday
<gary_poster> but no resolution
<gary_poster> I also see "Waiting for yui.yahooapis.com"
<gary_poster> Looks like we are getting css and that is taking awhile
<gary_poster> bac, frankban, tveronezi you all were talking about this yesterday I think ^^^ .  any hints?
<gary_poster> This link is taking 15 seconds: http://yui.yahooapis.com/combo?3.7.3/build/widget-modality/assets/skins/sam/widget-modality.css&3.7.3/build/widget-stack/assets/skins/sam/widget-stack.css&3.7.3/build/panel/assets/skins/sam/panel.css&3.7.3/build/overlay/assets/skins/sam/overlay.css
<gary_poster> heh, for a 304
<tveronezi> gary_poster: The quick resolution was to use the debug mode in the demo server;  The css stuff will be fixed by my next branch; 'gallery-markdown' and 'gallery-ellipsis' are not available in our static yui files, so we still need to download those from yuilibs.
<bac> gary_poster, we had that problem on staging yesterday
<bac> use of gallery-ellipsis is not in trunk yet
<bac> tveronezi, i still cannot get it to download
<gary_poster> bac, ack thanks.  tveronezi thanks.  how did this get in trunk--what did we miss?
<bac> gary_poster, if you'd like to pair i'd appreciate it
<gary_poster> bac ok cool, fire up a hangout
<bac> gary_poster, one issue is the combined file has 'use strict' at the top.  GlobalConfig is not defined with 'var' and that causes a failure.
<bac> easy fix is to add 'var' in two modules.js and modules-debug.js
<bac>  s/two//
<gary_poster> bac oh ok cool
<bac> our story for grabbing everything so we serve it up ourselves is not fully done i think
<bac> making hangout
 * bac installing plugin
 * bac getting tea
<tveronezi> bac: I can download those css files. http://ubuntuone.com/6vHKb78Lq8MFTQEAuWqxkf . If I add galery-ellipsis to the charm-panel.js, it adds the ellipsis to the yuilib url... http://yui.yahooapis.com/combo?gallery-2012.10.31-20-00/build/gallery-markdown/gallery-markdown-min.js&gallery-2012.10.31-20-00/build/gallery-ellipsis/gallery-ellipsis-min.js 
 * teknico is back from lunch
<teknico> gary_poster, nope, still struggling with it, would very much like to pair
<teknico> gary_poster, I already got some help from frankban, but am open to pair with anyone
<gary_poster> teknico, ack.  benji or frankban ^^^ ?
<teknico> ("it" being setting up charm tests)
<benji> gary_poster/teknico: I certainly can.  I have started a card already this morning, however.
<gary_poster> benji, how far along are you on that one, then?  and/or will it be done soon? :-)
<benji> gary_poster: probably not "soon", I was trying to figure out the roll in/out transitions for the charm panel; if we switch to ripping out the fade and making it just disappear, that would be quicker
<gary_poster> benji, suggestion open to your veto: just make it disappear, make a low priority bug for the roll-in/roll-out, and move to helping Nicola.  wdyt?
<benji> gary_poster: that's fine
<gary_poster> cool thank you.  teknico ^^^ benji will join you soon
<teknico> gary_poster, great, thanks
<benji> wait, wait, wait... did we completely break our development story?
<benji> do I have to run make every time I change a JS file now?
<frankban> benji: are you using "make debug"?
<benji> frankban: no, should I?
<frankban> benji: it seems so.
<benji> hmm
<benji> I am displeased.
 * teknico on school run, back in half an hour
<benji> gary_poster: the charm panel fade removal is very simple, but I figured that at least you should take a glance: https://codereview.appspot.com/6854043
<benji> it took much longer than it should because I was sabataged by the new default of minimizing JS
<benji> (we should revisit that, it is stupid)
<gary_poster> benji approved
<benji> cool, landing
<benji> re. review approval message: lol
<benji> teknico: what's up?  how can I help?
<tveronezi> benji: it seems the rev 239 breaks the charm search panel. 
<benji> tveronezi: is rev 239 the branch I just laned?
<tveronezi> Yes. I cant see the panel now.
 * benji answers his own question: "yes"
<benji> tveronezi: in what way does it break?
<frankban> benji, tveronezi: confirmed, also in staging, the panel doesn't show up
<tveronezi> benji: I click in the icon and nothing happens. If I revert one revision, it works again.
<benji> tveronezi: which icon?
<tveronezi> benji: charm search. http://ubuntuone.com/4nn1DSpQsT2GW7U45hHOmf
<benji> hmm, I wonder why it worked in my branch; reverting
<benji> I wonder what the best way to reviert is given lbox
 * benji settles on "uncommit"
 * benji realized that it doesn't do what he thought it would do.
<benji> tveronezi and frankban: fix comitted; thanks for the heads-up
 * teknico is back
<frankban> benji: was it the opacity?
<teknico> benji, sorry, was afk
<benji> frankban: here is the fix: http://paste.ubuntu.com/1355684/
<benji> teknico: so, what can I do to help?
<teknico> benji, hangout?
<benji> teknico: sure, yours or mine?
<teknico> benji, emily's: https://tinyurl.com/see-emily-code
<benji> ??
<teknico> :-)
<teknico> benji, frankban set that up for pairings
<gary_poster> bac bcsaller benji frankban hazmat jovan2 Makyo mattuk1972 teknico tveronezi call in 2
<tveronezi> gary_poster: i need to restart... I will back in a sec.
<gary_poster> ok
<Makyo> benji, lp:~makyo/juju-gui/remove-sub-rels - https://codereview.appspot.com/6782063/
<benji> Makyo: thanks; I'll take a look right away
<gary_poster> early lunch biab
<Makyo> mattuk1972, ping
<mattuk1972> hey
<mattuk1972> makyo, hey
<Makyo> mattuk1972, bug #1077006 is in staging - it's the inset left border on the charm panel.  Have a second to take a look at it and see if it meets design?
<_mup_> Bug #1077006: Charm panel left border should be 2px as per UX design <juju-ui:Fix Released by makyo> < https://launchpad.net/bugs/1077006 >
<mattuk1972> makyo, its almost there - its kind of odd how if it appears on a dark colour its lighter than the dark
<mattuk1972> it cuts off a px where it ends too
<mattuk1972> might have to rethink the colour i sent you
<Makyo> mattuk1972, dark colour as in the header where it says 'precise', or when you click deploy and it shows the charm name?
<Makyo> And end as in down at the bottom?
<mattuk1972> yes to all of that
<frankban> tveronezi: I see the old friend "Uncaught ReferenceError: GlobalConfig is not defined " when I run "make server" in your branch
<mattuk1972> maybe ill have to rethink that
<mattuk1972> graphic device
<frankban> tveronezi: "make debug" works well...
<mattuk1972> it really works on this light grey spaces but mess up on dark
<tveronezi> frankban: whats your browser? 
<frankban> chromium
<frankban> tveronezi: cache cleaned, appcache forced.
<tveronezi> precise?
<frankban> quantal
<tveronezi> ok... let me check that...
<frankban> tveronezi: sure
<Makyo> mattuk1972, Alright.  I'll look into the dark space borders.  It's currently just an internal drop-shadow on the panel border, but that can be covered up, I suppose.
<Makyo> tveronezi, ditto here, Chrome and FF on Quantal
<mattuk1972> makyo, can it just be a bit darker? or more opaque? or multiply the colour underneath?
<frankban> tveronezi: I think bac solved that issue in staging addign a "var" before GlobalConfig somewhere (maybe in module.js)
<Makyo> mattuk1972, Yeah, that's what I'll be looking into.
<mattuk1972> makyo, are they the new simpler svg assets I'm seeing in staging? because they are rendering way nicer for me
<Makyo> mattuk1972, Yep, plus some FF specific improvements.
<tveronezi> Makyo, frankban: I simply cannot reproduce it here. I've tried everything: chrome, chromium and ff in precise and quantal. It works fine. Actually, it could never fail because the resulting combined file creates  declaration like... var juju_config = {...}, GlobalConfig={...}, ...   
<tveronezi> Makyo, frankban: I dont know what is going on.
<benji> teknico: I am done with my code review.  How can I help you on the charm?
<tveronezi> Makyo, frankban: I will commit the var chang bac did... 
<tveronezi> Makyo, frankban: can you pull and try it again, please?
<Makyo> tveronezi, I'm seeing it request things from /assets/... rather than /juju-ui/assets/... which was a change we made a while back for the horizon integration.  Might be something to talk to frankban / teknico about
<teknico> benji, I'll push on some more, and pester you again once I hit the next roadblock :-)
<frankban> Makyo, tveronezi: yes, the 'juju-ui' prefix must be restored. I already added a note to my review.
<tveronezi> Makyo, frankban: This is something related to the server.js. There is a comment about this change.
<benji> teknico: ok; I'll look for something else to work on then
<Makyo> tveronezi, ah, alright.
<Makyo> tveronezi, This is what I'm seeing in the minified JS: var juju_config={consoleEnabled:!0,serverRouting:!1,html5:!0,container:"#main",viewContainer:"#main",transitions:!1,charm_store_url:"http://jujucharms.com/",socket_url:"ws://localhost:8081/ws"};GlobalConfig=
<Makyo> Getting a semicolon rather than a comma.
<tveronezi> Mayko: oh!
<tveronezi> Mayko: I still dont get why this thing is working for me.
<tveronezi> Mayko: Did you pull it again?
<frankban> tveronezi: I didn't get the reason why the prefix cannot be preserved
<frankban> tveronezi: now make server works for me
<tveronezi> frankban: I need a diferent prefix, otherwise I cant get the "lib/server.js" line 77 to work.
<Makyo> Pulled, but it was cached.  Works now, tveronezi 
<frankban> tveronezi: ok, but why that cannot be 'server.get('/juju-ui/assets/stylesheets/:file' ... or something? 
<tveronezi> frankban: because if I do this, a request to "/juju-ui/assets/stylesheets/:file" goes to the line 46 instead of the line 77.
<jovan2> bcsaller: hi, what's the opposite of Expose? Unexpose? i.e. the action to undo an Expose.
<bcsaller> jovan2: yes, unexpose
<tveronezi> frankban: forget what I just said. It is working with the link you proposed. 
<bcsaller> but it can also be though of as "exposed: true||false"
<frankban> tveronezi: isn't it possible to make the server parse '/juju-ui/assets/stylesheets/:file' and '/juju-ui/assets/all-third.js' before '/juju-ui/'? I know that your solution is easier, but it could generate troubles when integrating juju-gui in other projects, e.g. jaas
<frankban> tveronezi: oh, cool
<tveronezi> frankban: so, we should start the urls with "juju-ui" right?
<frankban> tveronezi: exactly
<frankban> the static urls
<tveronezi> frankban: do you see the same problem in the lines 70-71-72? It is from another branch.
<frankban> tveronezi: do you mean " server.get('/assets/all-third.js'"?
<tveronezi> frankban, yeap.
<tveronezi> I will try to change those in a sec.
<tveronezi> frankban ^
<frankban> tveronezi: yes, that should be fixed as well, feel free to do that in your current branch or to make another card
<frankban> tveronezi: so, to fully understand the problem: express tries to match all urls in order, if the first doesn't match, it proceeds to the second and so on. at the end, it raises a 404. Am I right? 
<tveronezi> Makyo, frankban: thanks for this nice catch.
<tveronezi> frankban: yeap.
<frankban> tveronezi: cool.
<tveronezi> bcsaller: It would be nice if you could check this solution. https://codereview.appspot.com/6853044/diff/1/lib/server.js It is part of the css stuff. frankban and Makyo are already reviewing it, but It would be nice to see if you approve what I did for this particular file, or if you have another alternative.
<bcsaller> tveronezi: I can take a look soon
<jovan2> bcsaller: the number of subordinates is shown on a service block in the graph view - is this number of subordinate services or units?
<bcsaller> jovan2: I believe its the number of services that subordinate is related to, I can check
<jovan2> bcsaller: a related question - how many subordinates might be typical? and maximum?
<bcsaller> jovan2: 0 is quite common, if they are using them in their deployment 1-3 would be in the normally expected range, there isn't a hard max, but you'll quickly tax your machines if you use too many 
<bcsaller> jovan2: It looks like that number is the count of services related to that subordinate, which makes sense 
<bcsaller> for example "how many things are related to this monitoring service"
<jovan2> bcsaller: I guess you are looking at the subordinate block? I'm looking at the little chart icon on the left-hand side of a normal service block.
<bcsaller> the little 'chart' (and why is that a chart looking thing anyway?) is on the subordinate 
<bcsaller> normal services don't have them
<jovan2> bcsaller: see slide 2: https://docs.google.com/a/canonical.com/file/d/0BwhxhFfxY6uqY0FGaDh5RHFMUzA/edit
<jovan2> bcsaller: I believe the chart-like thingy is supposed to indicate monitoring
<bcsaller> jovan2: we don't have any monitoring, also these wireframe you linked seem to predate the visual design work, that chart widget is the block hanging off a subordinate service now
<bcsaller> jovan2: I put one up at http://uistage.jujucharms.com:8080/
<bcsaller> puppet 
<bcsaller> the sparkline is some sort of aspirational element that makes no sense here 
<jovan2> bcsaller: Ok I see what you've done, but see the second to last slide in the wireframes.
<bcsaller> jovan2: Ahh, you're saying that normal services should show a count if/when they have subordinates running as well
<jovan2> bcsaller: right
<bcsaller> still shouldn't be a sparkline ;)
<bcsaller> but yeah, I don't know if there is a card for that yet
<jovan2> bcsaller: I think Nick thought subordinates could only be for monitoring purposes. If this is not so, can you give more examples please?
<jovan2> bcsaller: if you could email me that would be great, I have to go soon.
<bcsaller> puppet is a good example, but they can be used in many ways. Sometimes with framework charms they represent the application itself, so for example, if its a django or rails charm, the users application might be the subordinate
<bcsaller> depending on how the charm was authored it might be the app is a custom charm and the web framework is the subordinate, we don't require it to be any one way. And we don't know about how that is structured 
<bcsaller> jovan2: do you need more?
<jovan2> bcsaller: thanks, that's good for now. I might some more questions tomorrow :)
<bcsaller> np, have a good one
<bac> Makyo, i looked at staging with firefox and dragging lines around had no perceptible lag.  moving service boxes is pretty laggy, though.  acceptable, i'd think, but noticeable.
<Makyo> bac, Yeah.  It's still just a speed increase, not a fix.  Accessing node attributes in FF is very slow.
<gary_poster> Makyo, big +1 on your fix for bug 1076413 that you asked for review on.
<_mup_> Bug #1076413: Intermittently, svg content div is too wide by 1 pix <juju-ui:Fix Released> < https://launchpad.net/bugs/1076413 >
<Makyo> \o/
<tveronezi> Makyo: The application seems normal in ff. I see no difference from the chromium version.
 * tveronezi lunch brb
<Makyo> tveronezi, Alright, thanks.
 * tveronezi back
<gary_poster> hazmat, in juju-ui.  no rush
<gary_poster> bcsaller, including yours, their are five remaining environment view refactoring cards, right?
<gary_poster> there
<bcsaller> sounds right
<gary_poster> cool bcsaller thanks.  I'm sending out a note highlighting them to everyone.  They are not specced in the bugs, so I will ask everyone to contact you.  If the Europeans can start one, it might be nice to spec one out with writing, or confer with me on a hangout and see if I can do it after a discussion. Per discussion with Kapil, I'm also going to say that (1) we have through next week to get these landed and (2) ea
<gary_poster> ch one should be landed with tests.  I'd like to verify with you if any of the cards are blocked; and if any of them are arguably optional from one perspective or another, without causing significant ugliness/pain.
<gary_poster> I'd be happy to do that here or in a hangout
<bcsaller> still might be premature, there are no examples yet, still working on that 
<gary_poster> oh ok
<gary_poster> can anyone help accelerate that with you bcsaller?  I don't know about your experience with pair programming, but with a good combination it really can be a big benefit.
<bcsaller> makyo and I did ok during the sprint, not sure though
<gary_poster> ok, leave it up to you bcsaller, though am worried about timeline and the ability of others to help swarm.
 * gary_poster needs to get children from school
<gary_poster> biab
<bcsaller> gary_poster: I still have the prototype from the sprint which I'm porting to the new framework, so that could possible be a starting point, but I'd rather finish what I have 
<bcsaller> ok, ttyl
<Makyo> Anyone experienced YUI node.simulate(event) saying "Uncaught TypeError: Cannot read property 'sourceEvent' of null" before?
<Makyo> This merge didn't even touch that line, and it's breaking.
<bcsaller> Makyo: Haven't seen that one but I often have unrelated changes break tests
<gary_poster> no
<Makyo> Oops, was a d3 thing.  d3.mouse was expecting d3.event to be defined.  Easy to get around for testing by saying d3.event = {};
 * tveronezi brb
 * tveronezi back
 * Makyo dogwalks
#juju-gui 2012-11-14
<hazmat> g'morning
<mattuk1972> g'day
<bac> hi gary_poster 
<gary_poster> hey bac
<bac> gary_poster, got a second to g+?
<gary_poster> sure bac
<bac> gary_poster, invited
<gary_poster> tveronezi, fwiw filed bug 1078722 and bug 1078723 per discussion with bac.
<_mup_> Bug #1078722: "make debug" should not minimize third party javascript <juju-ui:Triaged> < https://launchpad.net/bugs/1078722 >
<_mup_> Bug #1078723: changes to third party files and bin/merge-files do not cause regeneration of combined files <juju-ui:Triaged> < https://launchpad.net/bugs/1078723 >
<tveronezi> gary_poster: ok
<tveronezi> gary_poster: I am curious to know why do we need to change third-party files.
<gary_poster> tveronezi, two reasons.  First is that we are the author of some of them (like the svg package).  Second is that we may need to be the maintainer of some of them (bac is trying to fix a YUI ellipsis package that last worked in YUI 3.3)
<gary_poster> tveronezi, also fwiw stepping through them means we don't want them minimized
<benji> grr, my networking continues to flake out on occasion, some twisted app crashes on login, and my key bindings keep getting forgotten
<teknico> sounds familiar :-)
<teknico> benji, good morning, would you still be available for some pairing? sorry for the on and off, I'm not doing this right
<benji> teknico: umm, sure; I am working on my own card now, but if you're stuck I would certainly help
<teknico> benji, great, thanks, hangout at emily's?
<benji> teknico: sure
<benji> gary_poster: do you have a second?
<benji> Emily would like to talk to you: https://tinyurl.com/see-emily-code
<gary_poster> :-) coming
<frankban> Emily tries... but misunderstands, ah ooh
<gary_poster> heh
<gary_poster> spotify in US has virtually no pink floyd :-/
<gary_poster> no beatles either but I already knew/expected that
<gary_poster> tveronezi, I think Makyo mentioned that he thought that the aggregated files should be served from juju-ui/assets/ in order to support integration in other environments.  I think he is right.  This is another example of where the increasing intelligence of the server script is biting us.  We intend to serve things from a static file
<tveronezi> gary_poster: this is fixed by another branch.
<gary_poster> ah, excellent tveronezi 
<gary_poster> I think I'm inclined to raise that as a bigger problem, fwiw: we should make the server as much like serving static files as humanly possible if that is really our gioal
<gary_poster> goal
<gary_poster> I will make a weekly card
<gary_poster> tveronezi, why do you include files like svg-layouts.js in all-third-min.js but exclude them from all-third.js, to be loaded via modules.js?
<frankban> mattuk1972: re growl notifications, in the case of multiple notifications, do we want new ones on top or on bottom?
<gary_poster> I mean, I guess that is good...
<gary_poster> But it seems inconsistent
<gary_poster> and therefore prone to surprising problems
<gary_poster> (it surprised me--I had to dig to find what was going on)
<mattuk1972> frankban, i would say top is newest
<frankban> mattuk1972: cool, thanks
<gary_poster> tveronezi, ISTM we should either always have them in "app" (via modules or minimized in all-app.js)
<gary_poster> or have them always in third party
 * tveronezi back.
<tveronezi> gary_poster: yes... they are loaded by the modules.js
<gary_poster> Was just making those comments in review, but faster in IRC
<gary_poster> yeah, I know
<gary_poster> the question is about consistency
<gary_poster> in debug mode, they are effectively part of the app
<gary_poster> and in production they are part of third party
<gary_poster> I think they should be consistently one or the other
<gary_poster> I can see arguments for either direction
<gary_poster> But consistency and least surprise is what I am looking for
<tveronezi> it depends how we want to debug those files. Do we want to debug then in a single big file or in multiple smaller ones, like yui modules.
<gary_poster> smaller is nicer
<gary_poster> but then what does "third party" mean?
<tveronezi> third-party means, "third-party non yui module."
<gary_poster> To call a spade a spade, a simpler name for that is "d3"?
<gary_poster> if we ever have another we can revisit?
<gary_poster> that might mean we could be more automated in what we do in marge-files
<gary_poster> merge
<gary_poster> yui should contain yui from npm
<gary_poster> d3 should contain d3 from npm
<gary_poster> app files should contain all other js in app.  Possible spelling:
<tveronezi> gary_poster: I didnt get the idea. Why to change the import from all-third.js to d3.v2.js now to change it back to all-third.js when we add another library? We could simply add the new library to the merge-files script.
<gary_poster> $ bzr ls -R app/ | grep -E '\.js$' | grep -vE -e '\Wd3\W' -e '\Wmodules\W'
<gary_poster> that excludes the compiled handlebars output; would have to be added manually
<gary_poster> Maybe better 
<gary_poster> $ bzr ls -k file -R app/ | grep -E '\.js$' | grep -vE -e '\Wmodules\W'
<gary_poster> includes d3-components, which I guess is correct?
<gary_poster> that's what we are doing now
<gary_poster> tveronezi, let's hang out
<gary_poster> juju-ui
<gary_poster> bac bcsaller benji frankban hazmat jovan2 Makyo mattuk1972 teknico tveronezi call in 2
<mattuk1972> thanks gary_poster but i have to run out of the office early today - jovan2 let me know anything that comes up?
<gary_poster> cool mattuk1972 
<benji> teknico: I am going to take a short break and then we'll talk to Emily about what we should do next.
<teknico> benji, ok
<frankban> gary_poster: do you have a min?
<gary_poster> frankban, I will in maybe 5? 10 max?
<gary_poster> is that ok?
<frankban> gary_poster: sure
<gary_poster> thanks
<gary_poster> frankban, juju-ui?
<gary_poster> 11 minutes :-P
<frankban> gary_poster: joining
<gary_poster> bac, you around?
<bac> yep
<bac> gary_poster: ^
<gary_poster> bac, thanks.  quick juju-ui call?
 * tveronezi lunch time.
<bac> gary_poster: ok
<gary_poster> thx
<bac> gary_poster: in the normal spot
<gary_poster> bac, yes
<gary_poster> benji, you around?
<benji> gary_poster: yep
<gary_poster> you probably need to get lunch, benji?
<benji> gary_poster: no rush
<gary_poster> benji, if you are not on a call and don't feel a lunch rush, I'd like to run something past you in juju-ui
<benji> gary_poster: I'll be there in a sec
<gary_poster> thx
<gary_poster> bcsaller, do you think that bug 1078827 that I just filed is more a UX issue or more a technical issue?
<_mup_> Bug #1078827: You can never mark a notification as seen <juju-ui:Triaged> < https://launchpad.net/bugs/1078827 >
<gary_poster> "As far as Francesco and I can tell, there is no longer any way to mark a notification as seen. It would be nice to be able to make them go away."
<bcsaller> gary_poster: UX, there is a method to control that, I think we don't bind it per an old discussion with Kapil. I think clicking them on the view all page highlights them but doesn't remove them, it would just be different handler code or adding an explicit delete button which would remove the model and it would work
<gary_poster> ack thanks bcsaller, I'll bring it up with jovan
 * tveronezi back
<bac> gary_poster: swap day added to canonicaladmin for your approving pleasure
<gary_poster> thx approved bac
<gary_poster> tveronezi, hey.  I plan to write up what we talked about so we have it in writing and agree on it.  I'll make a card and all that.  I'll do it after lunch
<tveronezi> gary_poster: ok tkx.
<bac> tveronezi: 2nd approve for your 'make debug' card.  thanks.
<tveronezi> thanks bac.
<bac> benji: what's the status of your and nicola's branch in review?  is it really up for review?
<benji> bac: I'm trying to get it up for review now.  If you're interested in reviewing it, I will let you know when I succeed.
 * tveronezi brb 15 mins
<bac> benji: please do.  i'm waiting on reviews for my branch (hint, hint) so i'd be happy to look
<benji> :)
<bac> thanks Makyo
<Makyo> Cheers.
 * tveronezi back.
 * bac dog walk before the rain
<gary_poster> tveronezi, please review https://bugs.launchpad.net/juju-gui/+bug/1078898 and give me feedback.  I'm going to file related follow-on bugs meanwhile
<_mup_> Bug #1078898: Makefile does not support static file deployment <juju-ui:Triaged> < https://launchpad.net/bugs/1078898 >
<tveronezi> ok.
<benji> bac: I finally figured it out: https://codereview.appspot.com/6850052
<gary_poster> tveronezi, what did you think?
<gary_poster> benji, any thoughts on my last para of https://bugs.launchpad.net/juju-gui/+bug/1078910 ?
<_mup_> Bug #1078910: development server is unnecessarily complicated and different from production delivery <juju-ui:Triaged> < https://launchpad.net/bugs/1078910 >
<benji> looking
<gary_poster> thx
<tveronezi> gary_poster: looks good... the only problem i see is the css stuff... check the solution I had for my current review... https://codereview.appspot.com/6853044/diff/9001/lib/server.js  
<tveronezi> gary_poster: I realize that this is not the best solution. Probably we will need to skip the css minification.
<benji> gary_poster: right, we will have to start two processes if the watcher is seperate from the server; I would start each as daemons and add a "stop" make target that kills them
<tveronezi> gary_poster: long story short, yui was not designed to be used this way. It is designed to use a combo loader.
<gary_poster> tveronezi, I believe that :-)
<tveronezi> gary_poster, that means that we need to have a smart server, or that we should use yui combo loader from the Internet.
<gary_poster> benji ack, that sounds good.  I was trying to have the watcher be a daemon and the server stay in fg.  I'll update with your suggestion.  thank you
<benji> my pleasure
<gary_poster> tveronezi, I have an idea.  You available for hopefully :-) quick G+ in juju-ui?
<tveronezi> ok...
 * Makyo dogwalkinates.
 * Makyo dedogwalkinates.
#juju-gui 2012-11-15
<bac> frankban, teknico: could one of you look at https://codereview.appspot.com/6846053 if you have time?
<teknico> bac, looking
<bac> thx
<teknico> bac, approved with one mostly useless comment :-)
<bac> teknico: :)
<bac> thanks
<bac> hi mattuk1972, the changes you requested via store_front_review.pdf are now up on uistage.jujucharms.com:8080.  i've got a card for it in 'UX Review' on the kanban board.  please have a look when you can.
<mattuk1972> cool will do
<mattuk1972> bac, hi - I can see that the cells are now a fixed width but i they are not 70px and look too big - also the precise heading font size is incorrect and the leading between charm name and description is incorrect. the text should also be centered vertically in the cell?
<bac> mattuk1972: i told them to be 70px so i'm surprised if they aren't.  is there a way you use to actually measure?
<bac> mattuk1972: huh, the precise h3 is set to 16px.  not sure why.
<bac> mattuk1972: nm, regarding the 70px. i see the problem
<bac> mattuk1972: regarding "he leading between charm name and description is incorrect", what needs to be different.  You specified 19px between baselines but that isn't easy to realize.  The summary font is 12px and I have padding-top for it at 6px.  Do you want more of a gap or less?
<mattuk1972> bad, ill measure it - brb
<mattuk1972> bac!
<bac> np
<bac> thx
<mattuk1972> bac - yours is 2 px further away than i have it - sorry for being so pickyâ¦..
<bac> mattuk1972: that's your job!
<bac> mattuk1972: let me get a screenshot for you
<mattuk1972> bac then why do i feel so guilty? :-)
<bac> mattuk1972: have a look at https://dl.dropbox.com/u/420990/Screen%20Shot%202012-11-15%20at%2010.07.30.png
<mattuk1972> bac, your cells are now 68 :-(
<bac> mattuk1972: chromium 'inspect element' shows me 287px x 70px
<mattuk1972> bac, does it take that from just the cell or is it including the div lines?
<mattuk1972> because they are 2px
<bac> mattuk1972: i think it includes the borders.  i set the height of the cell to 68px so that chromium would show it at 70px.  let me bump it back up to 70
<bac> mattuk1972: https://dl.dropbox.com/u/420990/Screen%20Shot%202012-11-15%20at%2010.19.29.png
<bac> fwiw, chromium now shows the cell at 72px
<mattuk1972> bac, i promise my cd's are not categorised and i don't have an ordered sock drawer â¦.
<bac> you have cds?
<mattuk1972> lol - in the loft
<mattuk1972> yay that now measures 70 px
<bac> ok.  it may be worth passing along to the other devs that we need to take into account the top and bottom borders when matching the specs
<bac> mattuk1972: what about the spacing between charm name and summary?
<mattuk1972> bac, looks good now ty
<bac> mattuk1972: ok, i'll land it now and it'll be on staging at :45
 * tveronezi I will back in one hour.
 * tveronezi back
<hazmat> tveronezi, Makyo, benji, frankban, teknico, bcsaller, jovan2 .. 1m till standup
<bac> benji: are we having a call today?  i nominate you to lead it since i did monday.  :)
<bac> oh, hazmat is here
 * hazmat seconds the nomination ;-)
 * hazmat reads the checklist
<teknico> has anyone been getting call's email notices in the last couple of weeks?
<hazmat> teknico, i've been getting appt reminders.. you can set what kind you want on the event
<hazmat> teknico, you joining?
<teknico> hazmat, I used to get them, then they stopped, without me changing anything (that I noticed, at least)
<bac> hazmat: fwiw, ours is the 'official' python version referenced by leankitkanban:  http://support.leankitkanban.com/entries/20807108-leankit-api-wrappers-and-examples -- happy to coordinate with others, of course
<teknico> benji, btw
<hazmat> teknico, if you check in your g. calendar you should be able to setup an email alert on the event
<teknico> hazmat, thanks, I'll check
<bac> benji: you can't see it, but the giant orange ladder has been joined by a 100ft orange extension cord to power my compute farm, since all of the in-wall wiring has gone kaput
<benji> bac: impressive :)
<teknico> benji, I'm looking at https://code.launchpad.net/~juju-gui/charms/precise/juju-gui/trunk/+activereviews
<teknico> benji, I think I left an extraneous tilde in when making up the branch paths
<teknico> and it propagated everywhere, sorry :-)
<bac> yeah, the electricians were supposed to come back today to finish up but couldn't due to a substation in the interior of the island blowing up
<bac> i guess that is a national electricians day off when substations go boom
<hazmat> bac, re leankit ..interesting thanks.. i've heard tale of of orange at least having additional kanban tooling based on lp2kanban.. and tales of francis having some other experiments with bidi sync.
<bac> hazmat: interesting.  i'll check with them.  who is orange, again?
<teknico> benji, otoh, looking at https://code.launchpad.net/~juju-gui/ , I'm not sure if we should retain the tilde or not
<benji> teknico: it looks good to me
<hazmat> bac, deryck
<bac> right
<teknico> benji, ok, then, I guess it would work either way
<hazmat> jovan what's your launchpad id?
<hazmat> er.. jovan2 ^
<jovan2> hazmat: hi let me just checkâ¦.
<hazmat> jovan2, got it..
<hazmat> jovan2, looks like its.. jovan-ljubojevic
<jovan2> hazmat: jovan-ljubojevic
<hazmat> jovan2, cool.. added you to the group
<jovan2> hazmat thanks
 * bac <- food
 * tveronezi lunch
 * tveronezi back
<benji> I can't remember, were we doing camelCase for variable names or names_with_underscores?
<benji> I think it was underscores, but mixing different conventions for method names and variable names always confuses me.
<bac> hi Makyo, i've noticed some of the cards you've worked on lately have bugs but your branch and MP and launchpad aren't linked together with the bug.
<bac> Makyo: if you use 'lbox propose -bug=' it'll hook it all up right
<bac> benji: i_thought_so_too
<benji> cool
<benji> I will add that to the style guide
<tveronezi> benji, bac: js is camelCase, python is_underscore.
<Makyo> bac, I noticed that, and linked the last one manually.  Will use the -bug feature, though, thanks.
<benji> tveronezi: that might be a slight over generalization
<tveronezi> benji: These are the conventions for js and python that people usually follow. At least they are here... http://google-styleguide.googlecode.com/svn/trunk/javascriptguide.xml#Naming and http://google-styleguide.googlecode.com/svn/trunk/pyguide.html#Naming 
<benji> bac and tveronezi: hmm, we have a conflict of recolections then
<benji> I'm fine either way, but we need to settle on something (I wish I had written this down when we decided)
<tveronezi> benji bac: I remember we talking about that... specially because I was happy to continue to work with camel case in js code. :)
<bac> benji: where is the crockford guide?  i recollect choosing to follow it closely, though not for indent
<tveronezi> bac: http://javascript.crockford.com/code.html
<benji> bac: http://javascript.crockford.com/code.html
<benji> crockford is all cammelCase (upper/lower depending on the kind of thing)
<benji> I guess that settles it: away with the underscores
<bac> hi Makyo, i'm looking at your 'block removal of subordinate relations' branch.  can you tell me how to exercise it?
<bac> Makyo: how to create a subordinate relation in the first place?
<Makyo> bac, Deploy a subordinate (puppet's an easy one), and create a relation between that and one of the other services.  Click on the subordinate relation indicator beside the subordinate to keep the relations visible, then try to delete one by clicking on the label, as with normal relations.  You should get a relevant warning.
<bac> Makyo: ok, i deployed rsyslog but couldn't make a relation with it
<bac> let me try with puppet
<bac> Makyo: got it, thanks
<bac> Makyo: do you see the hideous shading when hovering over the 'Cancel' button?
<Makyo> bac, hmm, yeah, just checked it against a regular relation, too.  Will look into it.
<bac> Makyo: ok
<Makyo> bac, got it.  Typo, or something.  Was removing a yui5 class.  I don't think yui5 is out yet.
<bac> :)
<bac> Makyo: also, my service block for puppet looks very funny.  the shading seems to be inverted.
<Makyo> bac, yeah.  There's a different asset for subordinate services.
<bac> Makyo: review done.  thanks.
<bac> Makyo: when your MP gets approved keep an eye on the board to see that the card moves correctly.  i can't do real testing since staging.lp.net is not working.
<Makyo> bac, thanks, and will do
 * Makyo dogwalks.
#juju-gui 2012-11-16
<mattuk1972>  info graphs are now fixed
<frankban> mattuk1972: hi, the growl notification must appear over the charm panel? isn't it better if it appears on the top right part of the page?
<mattuk1972> eh?
<frankban> mattuk1972: :-)
<frankban> mattuk1972: I am working on the growl notifications
<frankban> mattuk1972: https://docs.google.com/a/canonical.com/file/d/0B6l8lFdCRvtqRjY0S3NIV3N4bmM/edit
<mattuk1972> i thought it was best there as it don't really obscure and controls
<mattuk1972> doesn't really obscure any controls
<frankban> mattuk1972: you mean a click on a notification is really a click on the layer below?
<mattuk1972> no - the notification if it appears where I've suggested won't hinder the user clicking on the search or charm store controls
<mattuk1972> maybe I'm wrong
<mattuk1972> any thoughts jovan2
<jovan2> mattuk1972: not sure what you're asking
<mattuk1972> can u see the thread above?
<mattuk1972> the position of the notification
<mattuk1972> frank ban is wondering if it should appear right at the top of the page rather than at the top of the canvas
<jovan2> mattuk1972: what do ubuntu notifications do? we should be consistent where appropriate. Also. notifications will appear when the user is simply monitoring their environment, most likely, rather than browsing the charm store, so I'm not sure how much of an issue is the charm search field being obscured momentarily.
<mattuk1972> ok so its another bunch of wireframes you need to redo
<frankban> mattuk1972, jovan2: in my current branch (the first for growl notification, others will follow), the notifications appear in the window top right, and they can be closed on click. This way the position is consistent if you resize the page.
<jovan2> mattuk1972, frankban, good point, we need to consider window re-sizing.
<jovan2> frankban: you say closed on click. Is it not better to display more of the details of the notification on click?
<frankban> jovan2: it can be done in a future branch, but consider that sometimes we have just a title and a message, not a real url where to go.
<jovan2> frankban: is the message always going to be some sort of error message wrt a unit for a service? In which case opening up the unit details for the service would be a good idea.
<frankban> jovan2: however, we could add a "view details" link (or something like that) when we have that info. I'd like to postpone this for another branch, if I can get this one landed it can be a base to start requirements discussion.
<jovan2> frankban: I think we should go with the spec for now and evaluate when in use.
<frankban> jovan2: so, notifications over the env view?
<jovan2> frankban, yes
<frankban> jovan2: there is a problem: the notifications div is outside of the env view (and must be outside, because notifications should be preserved if you navigate the app). so their position is absolute, and their z-index is 9999. but the absolute position of the env view top right corner is relative to the window size. so, I can investigate further but at first sight it seems difficult to draw notifications using CSS o
<frankban> nly
<jovan2> frankban: so you need to make it work outside/above of the env area? I think I can live with that.
<frankban> tveronezi: hi
<tveronezi> frankban: hi!
<frankban> tveronezi: could you please review https://codereview.appspot.com/6851058 ?
<tveronezi> sure!
<frankban> tveronezi: thanks!
<tveronezi> frankban: its done, dude. 
<frankban> thanks tveronezi
<tveronezi> Hi benji. Man, do you have a minute for a quick brainstorm? I have a question about one of the requirements in  https://bugs.launchpad.net/juju-gui/+bug/1078898
<_mup_> Bug #1078898: Makefile does not support static file deployment <juju-gui:Triaged> < https://launchpad.net/bugs/1078898 >
<benji> tveronezi: sure, juju-ui hangout?
<tveronezi> ok.
<frankban> tveronezi: replied to your comment.
<frankban> benji: if you have time, could you please review https://codereview.appspot.com/6851058/ ?
<benji> frankban: sure
<frankban> benji: thank you
<frankban> benji: abort! abort! Makyo did my second review. thanks Makyo.
<benji> frankban: heh, thanks
<Makyo> Oops, sorry, didn't see this until after
<frankban> jovan2, mattuk1972: growl notifications are now in staging. The alert icon background is not transparent, but that's a known problem of our staging sprite.
<Makyo> Call today?
<Makyo> benji, frankban, bcsaller, hazmat, etc ^^^
<benji> Makyo: absolutely
<benji> mattuk1972 jovan2 Makyo tveronezi frankban benji bcsaller hazmat: call in 1 minute
<bcsaller> more like -1 minute
<jovan2> benji: apologies but I'm in a Landscape meeting with Mark
<benji> jovan2: no worries
 * tveronezi lunch
 * tveronezi back
 * tveronezi brb
 * tveronezi back
 * tveronezi brb
#juju-gui 2013-11-11
<bac> hi frankban, you around today?
<frankban> bac: yes
<bac> cool.  might just be us.
<frankban> bac: yeah. do you have any idea of how bundle annotations are supposed to work in a real env?
<bac> frankban: i'm not sure what you're asking
<bac> you talking about x,y annotations or something else?
<frankban> bac: yeah sorry, x,y annotations
<bac> frankban: the positioning seems to work.  gary fixed a bug on friday and i tested by deploying four really huge bundles and they were laid out correctly.
<frankban> bac: in a real env?
<bac> ah, sorry, no it was sandbox.
<frankban> bac:  when you drag a bundle file and drop it in the gui canvas, the GUI seems to just pass the YAML contents to the server, and the server uses the deployer to start the import process. Looking at the deployer code ISTM that annotations are just ignored
<frankban> :-/
<bac> oh, not good
<rick_h_> ugh, that sucks
<rick_h_> and explains a lot
<bac> rick_h_, frankban: have you seen the annotations ignored in a real env in practice?  i haven't done an actual bundle deploy against ec2 or other real envs.
<bac> rick_h_: are you working today?
<rick_h_> bac: yea, I did QA on release day in a real env and never got positioning to work
<bac> darn
<rick_h_> bac: no, just peeking in. I'm staying away today as I got sucked in on friday
<bac> rick_h_: then go away!  didn't you read robbie's email?  :)
<bac> rick_h_: i'm about to do the mjc deploy
<rick_h_> bac: hah, yes I did. I think I did that on a sunday :P
<rick_h_> bac: awesome!
<rick_h_> bac: as a follow up, should we move comingsoon back to mjc at that point (and the new bundles ingest) or leave it at staging do you think?
<rick_h_> I guess since it was moved to staging for the demo it should stay put until those are done from maaten and jcastro 
<bac> yeah, i'd wait until an all clear.
 * rick_h_ gets twitchy with comingsoon pointing at staging. Too many times of canonistack blowing things up on us
<rick_h_> ok, running away. Thanks for the production update bac. /me will be so happy when all the moving parts setting back down a bit. 
 * bac stuck waiting for fusion to download update
<bac> adeuring: the new heartbeat information looks good!
<bac> i may augment it to show when the bzr branch was updated.
<bac> hi abentley, jenkins for charmworld is not seeing a recently landed change.  if i select 'build now' it asks for manual input of several items, which i'm uncomfortable setting, assuming it would just trigger the next one.  the trigger log shows that it has run after the landing of r456 but is not seeing changes.
<abentley> bac: Looking, but standup about to start.
<bac> ok
<abentley> bac: What do you mean, not seeing changes?
<adeuring> bac: thanks :)
<bac> abentley: i mean the ScriptTrigger log ends with "Polling complete. Took 4 sec.
<bac> No changes." and no build is triggered
<bac> abentley: last build was 455 but 456 is available.
<abentley> bac: The last thing it landed was 456: http://162.213.35.27:8080/job/charmworld-autoland-lxc/78/console
<bac> abentley: i was looking at http://162.213.35.27:8080/job/charmworld-autoland-lxc/78/ for build #78 which says 455
<luca___> Can anyone tell me what cloud credentials look like? I've asked rick_h_ but he's ignoring me!
<abentley> bac: It says "The new revision is 456" and "juju set charmworld revno=456", so that means it committed r456 and instructed charmworld to deploy 456.
<abentley> bac: That's at the bottom of the log.
<bac> abentley: yes, i see that in the console log.  i do find it confusing that the main page i pasted above indicates it is processing r455.  i know you're not a jenkins apologist i'm just explaining the reason for my confusion.  thanks for clearing it up.
<abentley> bac: That refers to the initial state of trunk, before it commits.
<bac> ty abentley
<abentley> bac: Jenkins is behaving as if we are doing test-after-commit, so it is saying "Oh, this is the new revision since my last test, and here are the changes".  It is somewhat my fault because of the way I set the build up.
<abentley> bac: We could change it so that the pull is done as part of the script, rather than using the Jenkins Bazaar plugin.  I believe that would remove the "changes" info from that page, which would be less misleading.
<frankban> bac: have you received my email to juju-gui-peeps? (testing if my smtp configuration work)
 * bac looks
<bac> frankban: i received Re: [Juju-gui-peeps] Visual placement of services in bundle deployment on real environment
<frankban> bac: ok, with my listing of two bugs, right?
<bac> yes
<frankban> hazmat: ping
<hazmat> frankban, pong
<frankban> hazmat: the deployer does not support annotations, correct?
<hazmat> frankban, not yet, this is just for gui positions?
<frankban> hazmat: yes
<hazmat> frankban, k, i can add some support in today
<frankban> hazmat: that would be great! it is critical for us now that we support bundles
<frankban> hazmat: in the next days I will work on a deployer branch (fixes for our import calls from the guiserver) and on a jujuclient branch (make EnvError pickable + optional ToMachineSpec support in deploy()). How does it sound?
<hazmat> frankban, also fwiw re placement in bundles. http://pythonhosted.org/juju-deployer/config.html#placement
<frankban> hazmat: cool
<hazmat> frankban, afaik that covers the tomachinespec support for deploy
<hazmat> there's a new release of jujuclient coming as well to catch up with core's recent api work
<hazmat> frankban, re enverror pickable.. you mean json serialization support?
<hazmat> frankban, there's a longer discussion  with rick_h_ about changing deployer to be more library based instead of cli (ie no more ErrorExit exceptions).
<hazmat> fwiw
<frankban> hazmat: re jujuclient I mean this diff -> http://pastebin.ubuntu.com/6377430/
<hazmat> frankban, gotcha, okay
<frankban> hazmat: long story short, the guiserver calls the deployer in a separate process, any exception should be propagated using futures, but to do that, the ProcessPoolExecutor pickles exceptions. That python bug prevents the exception to be correctly deserialized, an the diff is a quick workaround. do you want me to propose that, do you want to just include the fix in your next release?
<hazmat> frankban, i'll just include it
<frankban> hazmat: the branch is in https://code.launchpad.net/~frankban/python-jujuclient/pickable-enverror
<frankban> hazmat: great thanks
<frankban> hazmat: ok so I'll work tomorrow just on the deployer fixes for the guiserver, ok?
<hazmat> frankban, sounds good
<hazmat> frankban, 0.15 jujuclient uploaded has the exc fix and deploy() machine_spec support
<hazmat> to pypi that is 
<frankban> hazmat: awesome! :-)
<frankban> hazmat: so, thanks a lot. so tomorrow I'll grab the deployer with annotations support if it is ready and work on the guiserver code there.
<hazmat> frankban, sounds good
<hazmat> frankban, does gui charm get deployer from pypi or cloud archive
<frankban> hazmat: the gui charm includes the deployer tarball.
<hazmat> frankban, ic, thanks
<frankban> bac: when you have a minute later, could you please review and qa https://codereview.appspot.com/24600043 ? 
<bac> frankban: sure
<frankban> bac: thanks, have a nice evening
<bac> you too
<hatch> rick_h_,  hey I don't suppose you're kickin around?
<rick_h_> hatch: around, what's up?
<hatch> just working on huw's branch now and implementing your changes
<hatch> but I'm wondering why onboarding is handled by the browser.js and not app.js?
<rick_h_> hatch: couple reasons. One, it's only in the build viewstate, it's part of the browser experience in that way
<rick_h_> hatch: and getting that viewstate info up out to the app was a pita and bad code smell
<hatch> oh, I was under the impression that it was done over top of whatever would be there
<rick_h_> hatch: no, it's only in build mode
<hatch> but I guess it makes sense
<rick_h_> hatch: so originally there was all this url hacky crap to check if it should show when it was in app.js
<rick_h_> hatch: which got convoluted when you considered default view mode and such
<hatch> cool, so that is another thing that can be simplified post fullscreen removal :)
<rick_h_> hatch: so it was a MUCH simpler thing to move to browser.js and check viewmode directly
<hatch> right
<hatch> I knew there had to be a reason for it :)
<rick_h_> hatch: what doesn't get simpler (once you get past removing everything and fixing all the state machinery bits)
<rick_h_> hatch: that and I HATE app.js doing more work. It's a lot easier to test as it is now. 
<hatch> :)
<hatch> only 4 more hours to go, should be able to get this done before then :)
#juju-gui 2013-11-12
<hatch> juju.ubuntu.com is missing the css assets
<rick_h_> hatch: css is working here, but a syntax error from the all-yui.js
<rick_h_> woot for non-https assets
<hatch> haha
<frankban> hazmat: ping
<bac> rick_h_: i'm an askubuntu junkie now!  :)
<rick_h_> bac: hah
<frankban> rick_h_: hi, how to convert a bundle:~... to a real URL to the YAML?
<rick_h_> frankban: good question :)
<rick_h_> frankban: frankban so everything after the : is the bundle id and should be appended to mjc/bundles/$id/json I think
<rick_h_> frankban: sorry lied, bundle (no s)
<rick_h_> frankban: http://manage.jujucharms.com/bundle/~jorge/wordpress/wordpress-simple/json for instance
<frankban> rick_h_: so bundle:~frankban/wiki-bundle/1/wiki ->  http://manage.jujucharms.com/bundle/~frankban/wiki-bundle/1/wiki/json
<rick_h_> frankban: rgr
<frankban> rick_h_: cool thanks
<bac> rick_h_: thanks for marking your bugs 'fix released'.  a reminder for me to do the same.
<bac> frankban: does fusion initially give you the wrong display resolution?
 * benji realized he wasn't on IRC.
<rick_h_> we missed you!
<gary_poster> :-)
<rick_h_> bac: watch out, doing mass released from the kanban cards 
<gary_poster> btw, hi everybody
<frankban> bac: the display resolution seems ok
<gary_poster> rick_h_, was going to wait till jujucharms.com, but all good
<bac> frankban: huh, i can't get mine to come up the same between boots.  very mild annoyance.
<rick_h_> gary_poster: oh, ok. I figured since users get it when they deploy I'd update
 * rick_h_ hits the brakes
<gary_poster> rick_h_, done-done not super clear, but since I think we ought to get this stuff to jujucharms.com, we ought to wait.  I need to make a card to test jujucharms.com deployment/migration, before we issue the rt.
<gary_poster> currently wading through hundreds of mails...
<rick_h_> gary_poster: cool, did we get the ok to not wait for the 'big annoucement' then?
<gary_poster> rick_h_, I made an executive decision ;-)
<gary_poster> jujucharms.com is just looking too sad
<gary_poster> I'll clear with sally
<rick_h_> gary_poster: yay
<gary_poster> but I think we have to
<hatch> morning
<gary_poster> rick_h_, you made any secret progress on git for gui lately? :-)
<gary_poster> morning hatch
<rick_h_> gary_poster: :P 
<rick_h_> gary_poster: just dreams
<gary_poster> hatch, you running with  huwshimi's branch for first task?
<gary_poster> rick_h_, :-) the killer is landing, right?
<hatch> gary_poster: yep, I have it 3/4+ done
<gary_poster> awesome thanks hatch
<rick_h_> gary_poster: basically we'll need to write a plugin for stridercd to do per-merge CI on landing or dupe tarmac and setup jenkins for it. 
<hatch> internet connection on the highway was very flaky unfortunately
<gary_poster> hatch, :-)
<rick_h_> gary_poster: exactly, everything else works, just need to write up processes and helpers for people
<rick_h_> gary_poster: but nothing supports that "ci one more time before doing auto merge" that we expect
<gary_poster> huh.  but stridercd gives us the hookpoint we need, as opposed to travis?
<rick_h_> gary_poster: yea, stridercd is open source and I talked with the author and he's very interested in the idea. 
<gary_poster> oh ok.  would we need to host it?
<rick_h_> gary_poster: travis people think it falls outside of their 'job to do' and we can't patch it
<gary_poster> oh, hosted beta
<rick_h_> gary_poster: yes, probably. We could charm/run it. Now it has a hosted option, but it's not free and we'd probably have to get the patch in to work the way we want anyway
<gary_poster> right :-/
<gary_poster> k
<rick_h_> which is why coming back to just replacing the tarmac bit in jenkins is almost the same thing at that point
<rick_h_> we still have to run/setup something to do it
<gary_poster> lol, old friend of mine is giving a stridecd quote at the bottom
<gary_poster> " Strider's Selenium and Heroku support are killer features "
<gary_poster> Casey Duncan, Pandora
<gary_poster> benji, used to work at ZC ^^^
<rick_h_> gary_poster: yea, it's actually kind of interesting and it's JS which we have some skills in house for
<rick_h_> gary_poster: lol, small world
<gary_poster> heroku might be free at the size we need?
<benji> heh
<rick_h_> gary_poster: definitely
<gary_poster> hm
<gary_poster> probably not something we'd want to advertise ;-)
<rick_h_> gary_poster: I just assumed with the other teams wanting to do the same thing we'd end up wanting to charm/run it canonistack or something
<gary_poster> yeah
<rick_h_> gary_poster: yea, that was my instinct 
<hatch> a few pics from my trip https://plus.google.com/u/0/+JeffPihach/posts/51jMuJDDGSY (let me know if you can't see them)
<hatch> I'm in the blue :)
<gary_poster> hatch, is that your nose in the blue jacket? :-)
<gary_poster> heh
<hatch> haha
<hatch> twas a little cold at the top :)
<gary_poster> yeah, I bet.  pretty tho
<hatch> oh yeah
<gary_poster> rick_h_, so...
<gary_poster> rick_h_, our CI is busted now
<gary_poster> rick_h_, ...I suppose we could have some kind of lightweight local tester as we do now...
 * gary_poster has to step away
<bac> frankban: how long should the charm ftest take to run?
<bac> against ec2
<rick_h_> bac: when I was trying to release it crossed an hour and wasn't done yet
<frankban> ~1 hour IIRC
<bac> gah
<rick_h_> hatch: you good on huw's branch or need anything?
<bac> i wish our startup messages logged the time of start
<frankban> yeah, it deploys the charm several times, and the deployment is the slow one (download + upload)
<rick_h_> bac: ps aux 
<rick_h_> bac: :) it's how I was tracking time
<bac> frankban: oh, right, and my super-fast pipe doesnt' help
<rick_h_> bac: you can see the functional test runner start time
<bac> rick_h_: +1
<hatch> rick_h_: nope all good just doing some more cleanup and updating tests
<rick_h_> hatch: coolio
<rick_h_> frankban: looking at the card on the bundle deployment progress and it mentions a timeout will be implemented to clear old deployment info. Any idea what kind of timeout that'd be? XXseconds, minutes?
<hazmat> frankban, pong
<frankban> rick_h_: to be decided, hours sounds good, like 1 day, but that's really low priority
<rick_h_> frankban: rgr, ok. Just want to make sure it's not some short time I need to worry about it leaving memory before I grab the status
<frankban> hazmat: hey, the deployer branch I mentioned yesterday is ready for review. could you please take a look at https://code.launchpad.net/~frankban/juju-deployer/new-release-fixes/+merge/194851 ?
<frankban> hazmat: I saw you integrated service annotations support, great!
<hazmat> frankban, definitely already looked over, the only that give me pause is the bzrignore, wondering about *.egg in there
<frankban> hazmat: yeah, maybe that's better, updating
<hazmat> thanks
<frankban> hazmat: the new diff is ready in lp
 * gary_poster switched http://comingsoon.jujucharms.com/ back to mjc from sjc
<gary_poster> (you may need to hard reload)
<frankban> rick_h_: cool, thanks for taking care of that card. anyway, I suppose that clean up will be made (just to save some memory) not as cron job, but more like a callLater call when the deployment is completed, so, from the gui perspective, it should be safe
<rick_h_> frankban: rgr, thanks
<rick_h_> frankban: do you have a sec for a quick hangout? 
<frankban> rick_h_: sure
<rick_h_> frankban: https://plus.google.com/hangouts/_/76cpj35m02d9qkracsqqq5t3kc?hl=en
<gary_poster> sometimes the best way to handle an email is a branch.  jujugui, very quick review of https://codereview.appspot.com/25220043 please?
<rick_h_> gary_poster: looking
<gary_poster> ty
<benji> heh
<benji> quote of the day
<gary_poster> :-)
<hatch> rick_h_: after finishing huw's branch I realize that it should be a plugin not a widget  because it doesn't actually handle rendering anything just enhancing a source node
<hatch> any objection?
<rick_h_> hatch: widgets can grab onto existing DOM. It's in their very nature with syncui and bindui
<rick_h_> hatch: so maybe?
<rick_h_> :)
<hatch> right I've changed it to use srcNode
<hatch> but typically a widget is a 'contained' feature with the ability to do PE
<hatch> this can NEVER render itself
<hatch> which pushes me to the plugin route
<rick_h_> hatch: plugin to what though?
<hatch> the 'dropdown' element. in this case #notifications and the help-dropdown template
 * rick_h_ pulls up branch
<hatch> Y.one('#notifications').plug(Y.juju.Dropdown);
<hatch> it would then be a dropdown element
<rick_h_> hatch: oh, the Node
<hatch> unless at some point we want to have the widget rendering something
<rick_h_> hatch: but then there's the ability to address it and update content, etc? call?
<hatch> yeah sure
 * hatch needs button in chrome to create hangout
<rick_h_> https://plus.google.com/hangouts/_/7acpiurni6n9donhd3pfs96u0g?hl=en
 * gary_poster disposed of emails...
<hatch> gary_poster: after a discussion with rick_h_ we have come to the conclusion that this code needs to be refactored to be more usefull in the future
<gary_poster> hatch, this is huw's?
<hatch> yeah
<rick_h_> be less of a painful to maintain in the future
<gary_poster> hatch, k.  needs to happen now?  should I come handout to hear details?\
<gary_poster> hangout :-P
<hatch> sure I can run you through it
<hatch> https://plus.google.com/hangouts/_/7acpjir38dla81ft5cqng44kvc?hl=en
<jcastro> ok rick_h_
<jcastro> today is the day, I can feel it!
 * rick_h_ ducks
<jcastro> all I really should be waiting on is the quickstart PPA to be updated?
<rick_h_> jcastro: what's today? the day of what?
<gary_poster> bac and rick_h_ thanks for manning askubuntu, cool
<rick_h_> frankban: ^ ?
<gary_poster> jcastro, what do you want there?
<rick_h_> gary_poster: quickstart support for urls
<jcastro> ^^^
<rick_h_> gary_poster: it's in trunk, but not in the ppa 
<gary_poster> oh
<gary_poster> yeah
<bac> gary_poster: on #juju they have a bot not listening for juju gui questions.  only way i knew about them.
<rick_h_> gary_poster: that was the last thing we hit trying to get the 'bundle instrcutions' ready from friday
<frankban> jcastro: working on adding bundle: support and then on a ppa release
<rick_h_> bac: +1
<bac> s/not/now/
<frankban> jcastro: will ping when ready
<jcastro> frankban, oh that makes it even easier for me
<jcastro> awesome, thank you!
<bac> gary_poster: and we have jcastro cleaning up after us on askubuntu.  :)
<gary_poster> frankban, awesome thanks. when you get around to it, please also make sure the rest of us can kick to the PPA, andf know how to.  maybe doc in branch would be good
<gary_poster> :-)
<frankban> gary_poster: it's https://code.launchpad.net/~juju-gui-charmers/+recipe/juju-quickstart-daily owned by Juju GUI Charmers, so it should be available for everyone, correct?
<gary_poster> frankban, definitely.  I just couldn't find it Friday when I was flailing around with a variety of things
<frankban> gary_poster: cool, I'll add the link to the HACKING file in the branch
<gary_poster> awesome thanks
<hatch> frankban: I see in the emails that you got your new computer...which one did you end up getting?
<gary_poster> frankban, fwiw next charm release should include 0.12.1 or 0.13.0 of GUI to include layout fixes (yours plus race condition I fixed Friday)
<gary_poster> that needs to happen before jujucharms.com release
<frankban> gary_poster: sounds good
<frankban> hatch: macbook pro 13 2.6Ghz with 16G of memory
<hatch> frankban: the late 2013?
<hatch> as in .... 'new version' :)
<frankban> yes, new version
<hatch> awesome! have you tried to see how long the battery will last yet?
<hatch> A microwave should calculate the time to run and make the platter end up at the same spot so that I don't have to reach for my coffee
<hatch> *a-better-mouse-trap
<gary_poster> rick_h_, idle thought as I mess with kanban (btw, cards that appear to disappear are usually simply moving to temporary location while I garden): high priority for me is to get CI working again, and I want to spend resources on this.  if we have a believable plan for getting this working reliably along with getting git transition, for the same cost or less than other CI work, then we have resources to work on git.  
<gary_poster> Worth talking about later.
<rick_h_> gary_poster: rgr, I grabbed this gui deployer status as it looked like next highest thing. I'm open to chat if something else is in fact higher
<jcastro> gary_poster, when do you anticipate the quickstart stuff to land in a proper Juju release? (hand wavy vauge timeline is fine)
<gary_poster> rick_h_, oh, no it is good.  my thought was "Rick wants git, and git transition would be cool even though low priority; if the hard thing is getting CI/tarmac/whatever working the way we want, then maybe we just slip Rick's existing work into that train"
<rick_h_> gary_poster: +1 overall on the idea. 
<gary_poster> jcastro, "landing" will be putting it in main Juju PPA, is the plan.  That works for you?  If so, we could do as soon as you like, but I wasn't planning on driving it until we had planned features and feedback.  OTOH deployer seems like it is kinda treating juju ppa as alpha/beta distribution channel, so can be sooner (now-ish) IMO
<jcastro> you mean ppa:juju/devel?
<gary_poster> jcastro, yes
<gary_poster> uh
<gary_poster> I think, checking
<jcastro> hey so, having it in that PPA is one less PPA people would need to do a cloudfoundry one shot
<jcastro> maybe we should toss it in there? But maybe towards the end of the week?
<jcastro> that'll give me some time to put the bundle through its paces
<gary_poster> jcastro, I meant ppa:juju/stable .  Yeah, we could definitely put it in ppa:juju/devel but...is that actually used by anyone? https://launchpad.net/~juju/+archive/devel
<rick_h_> no, the proof and such aren't updated in there any more that I could tell
<rick_h_> I ran into issues with that as I was tracking -devel and it was getting out of date packages
<gary_poster> yeah, https://launchpad.net/~juju/+archive/stable has action
<bac> gary_poster: please reject the expense report i just submitted.  i made an error
<gary_poster> bac you want me to reject it, or do you want to tell me how to edit it?  if it is very small, just have me do it.  I have it open.
<bac> gary_poster: i have two more months i missed.  would probably be easier to start over
<gary_poster> bac, ack.  Done.
<bac> gary_poster: do we categorize as cloud computing or misc?
<gary_poster> bac...no idea.  I do cloud computing, I think.  checking
<gary_poster> yeah I use cloud computing.  shrug?
<Makyo> jujugui call in 10
<gary_poster> thx
<frankban> hazmat: any prevision about when my deployer branch can be merged into trunk?
<hazmat> frankban, shouldn't be a problem, just backed up on some adhoc meetings/discussions atm
<frankban> hazmat: ok, thanks
<hazmat> frankban, it will get merged/released today (0.29)
<frankban> hazmat: great!
<gary_poster> jujugui call in 2
<gary_poster> hatch are you leading or am I?
<gary_poster> either is fine
<hatch> I can
<gary_poster> cool
<rick_h_> frankban: linky me please?
<frankban> rick_h_: in the cards
<frankban> card even
<rick_h_> frankban: rgr, thanks
<benji> r*ck_h_: I would be glad to help you with ctags
<Makyo> Bleh, sorry.
<Makyo> frankban, lmk when you have time for call/card
<frankban> Makyo: now is ok
<Makyo> frankban,  https://plus.google.com/hangouts/_/76cpigg1rv0tkg38rclkrihns4?hl=en
<Makyo> Maybe that works?
<gary_poster> bac approved expenses
<rick_h_> frankban: any reason to qa on ec2 vs lxc? 
<frankban> rick_h_: quickstart does not support lxc (which requires sudo)
<rick_h_> frankban: oh, it works if it's already bootstrapped though?
<frankban> rick_h_: no, we have a card to make quickstart use a bootstrapped env
<rick_h_> frankban: ah, ok then
<rick_h_> benji: cool, I was trying a npm library that failed to work out. Then tried to do a custom ctags language for js, but ctags won't read the .ctags options file. 
<benji> rick_h_: oh, I thought you were doing Python; I have only put a little effort into JS.  Maybe now is the time to do a bit more.
<rick_h_> benji: yea, the scope of the go.js env file got me going "Man I wish I had that tag listing sidebar plugin going on here"
<rick_h_> I don't normally use it, but somehow clicked today and ctags'ing things fell over 
<gary_poster> hey benji, we have a card in bundles section that is "add a collection for metrics to charmworld."  You've done that, right?
<benji> gary_poster: yep
<gary_poster> cool thanks
<gary_poster> jujugui, I just did a pretty harsh kanban rejiggering.  if you are looking for a pre-existing card that you think we need to handle soon, look in backlog (see link at top of kanban).  meanwhile, other cards are pretty streamlined.  Maintenance, Quickstart, and Multi-step maintenance task lanes all have good things to do.  Green "story" cards in maintenance should probably wait for the multi-step maintenance task lan
<gary_poster> e to open up, and then only one green card at a time is active down there.  Lemme know if you have any questions.
<gary_poster> hatch, any card out is good, or if you want to declare that another small bug card is a must-have, feel free. Meanwhile, there are some good cards in maintenance: high that I marked with the GUI icon for easy visual identification
<gary_poster> (the monitor with a globe in it)
 * gary_poster lunches
<hatch> great thanks
<hatch> I'm having issues lbixing for some reason so trying to land this branch
<Makyo> jujugui easy quickstart review https://codereview.appspot.com/25340043
<gary_poster> Makyo, did you and frankban consider an option to automatically remove juju-gui?  Would be easy and nice I'd argue, but it's an idea I'd prefer you all to evaluate the merits of.
<gary_poster> (rather than you regarding this message as a request :-) )
<gary_poster> maybe spelling is the hardest part.
 * gary_poster really runs away now.
<bac> jujugui: very small makefile change to charm: https://codereview.appspot.com/24790045
<bac> Makyo: i'll look
<hatch> bac: i'll take it
<Makyo> bac, thanks.
<frankban> gary_poster: I considered that, but it seems part of the interactive story, I suggested the current behavior as a first step. Also consider an evil bundle with a service named juju-gui but that's really another kind of service, with relations...
<hatch> bac: lgtm'd
<hatch> grrrr test failures when run together
<bac> was that grrr aimed at me?
<hatch> bac: nope, at our test suite
<hatch> your all good to go :)
<frankban> jcastro: quickstart v0.3.0 released on the ppa
<hatch> gary_poster: wow that's quite the rejiggering! any chance we can clear out the Releasable column?
<hatch> oo there are some juicy ones in High
 * hatch pushes everyone away and grabs them all for himself
<hatch> miiiiiiine alll miiiiiiine
<Makyo> Go for it :P
<hatch> it's a right triangle of GUI cards
<hatch> how cute
<jcastro> frankban, ok updating
<jcastro> rick_h_, should I file a bug for the gui for using out of date instructions now?
<jcastro> wget -O bundle.json https://manage.jujucharms.com/bundle/~jorge/cloudfoundry/3/cloudfoundry/json 
<jcastro> and friends, we probably don't need to do that anymore?
<jcastro> frankban, so how do I use this bundle: url, assuming this is the bundle I want to try
<jcastro> http://comingsoon.jujucharms.com/sidebar/search/bundle/~jorge/cloudfoundry/3/cloudfoundry/?text=cloudfoundry#bws-deploy
<frankban> jcastro: yeah, the quickstart instructions can be simplified.
<rick_h_> jcastro: yea, we'll update the instructions to not use wget
<frankban> jcastro: for example: "juju quickstart -e ec2 bundle:~hatch/wiki/7/TestBundle"
<rick_h_> jcastro: so with the ppa it would just be juju quickstart bundle:~jorge/cloudfoundry/3/cloudfoundry
<rick_h_> jcastro: that url is in the top of the window there by the icon as "Location"
<rick_h_> jcastro: so we'll move that down to the quickstart command
<jcastro> ahhh!
<jcastro> wooo, it's working!
<bac> Makyo: LGTM w/ QA
<bac> one small request
<rick_h_> jcastro: aseome, glad to hear
<rick_h_> err, awesome
<jcastro> this one works with constraints
<Makyo> bac, Sure.
<jcastro> so am I safe to add constraints to say, discourse? 
<rick_h_> jcastro: yep, constraints should be fine now
<frankban> jcastro: yes, it shoudl work with constraints
<rick_h_> jcastro: yea, you should get an error now if the constraints are invalid
<jcastro> and what about deploying --to one node?
<rick_h_> jcastro: you can only use the gui supported constraints right now
<rick_h_> hmmm, I thought there was a --to support in there. I don't think we support it via quickstart right now
<frankban> jcastro: unit placement is supported by the new juju-deployer, that will be integrated soon (hopefully tomorrow) in the gui charm. that means bundles with unit placements should just work. that said, the GUI does not support unit placement, and AFAICT does not include placement info in the bundle exports
 * jcastro nods
<jcastro> ok so I can manually add it into the bundle in the meantime
<frankban> jcastro: I think it's worth a try. I can test one bundle with placements, if you provide one, tomorrow or in two days, after the gui/guicharm are released
<jcastro> ok
<jcastro> heh, moved my environments.yaml out of the way to see what would happen
<jcastro> but prompting for creds is for v2 of bundles right?
<frankban> jcastro: not yet implemented. instead of moving your env.yaml you can also run, e.g. "JUJU_HOME=/tmp juju quickstart" ;-)
<jcastro> ah, good tip!
<rick_h_> bah, irc locked up
<rick_h_> jcastro: you can manually add it, but quickstart won't support it. The raw deployer command looks like it would though
 * hatch bouces head of desk....feels better than dealing with cascading test failures
<gary_poster> hatch, "any chance we can clear out the Releasable column?": yeah.  wanted to do it after jujucharms.com release.  I wanted that annoyance (of the big column) to help push us to do so, and remind us that jujucharms is so far behind. But whatever, if everyone wants me to move 'em, we'll get it done either way. :-)
<hatch> haha sounds good
<hatch> note to self...manually removing a views container will trigger a test suite 20s later to fail with node.js errors *head....desk*
<rick_h_> hatch: why was the view around 20s later?
<hatch> rick_h_: now that's the question isn't it?
<rick_h_> hatch: hehe
<hatch> jujugui looking for a review of my refactoring from huw's branch https://codereview.appspot.com/25390043/
<rick_h_> hatch: looking
<hatch> thanks
<hatch> I think it turned out pretty well
<rick_h_> hatch: feedback inbound, few questions for you
<rick_h_> hatch: please take a peek while I QA
<hatch> alright
<hatch> rick_h_: good catch on the fullscreen
<hatch> because there is a card to remove that right away, should we bother with trying to prevent ti?
<hatch> prevent/refactor to catch that
<rick_h_> hatch: not sure, I mean if we do a release tomorrow/thurs it'll be a broken thing 
<rick_h_> until the next release of jujucharms.com, I'm not a big fan of knowingly breaking it for some underterminate amount of time 
<hatch> yeah....good point
<hatch> damn I hate doing work that I know is goign to be deleted very soon :)
<hatch> ok going to lunch then will fix
<rick_h_> hatch: I'd say the quickest hack would be to navigate to the sidebar url and turn on the tour? 
<rick_h_> e.g. if you click on 'show me the tour' it takes you to it?
<hatch> yeah that's probably the easiest
<rick_h_> hatch: heh, yea, since the first item in the turorial is to highlight the sidebar, which in fullscreen just gets you a nice grey bar down the side of the page
<rick_h_> I was wondering if maybe the tutorial can just show on fullscreen as well, guess not :/
<hatch> rick_h_: bleh I don't like anything I come up with for the sidebar
<hatch> fix
<rick_h_> hatch: :/
<hatch> either I have to pass extra stuff in
<hatch> or I have to add event listeners
<rick_h_> hatch: so I'd vote we hide that link for now, just comment it out. Test it though. 
<gary_poster> Makyo, hey.  I wanted to triage the bundle vis bug, so investigated.  This seems to address.  Could you see what you think?  http://paste.ubuntu.com/6407015/
<hatch> rick_h_: I'll take that!
<rick_h_> hatch: and then when adding the allview.js it can watch/be tied to the onboarding there
<rick_h_> hatch: at least the events have a common place to work together there, agree?
<hatch> right - when we are within a 'parent' view then it'll make more sense
<rick_h_> hatch: right, and the parent can work on handling the nav or whatever needs to be done. 
<hatch> yeah
<rick_h_> though onboarding has to come out of browser.js for that :/
<rick_h_> hatch: thoughts on making the help menu part of browser.js like the onboarding then?
<Makyo> gary_poster, That will work, I think! I don't know that it will always work if called again if we plug in pan and zoom in, but if we only ever set the centroid once on load, then I guess that's the only time we need it to work.
<hatch> well with fullscreen gone then the onboarding and help can go into the 'parent' view
<rick_h_> hatch: right, but that's farther away than I want to count on for now tbh
<rick_h_> we've been saying it was going away for a while now
<rick_h_> making architecture decisions on that seems cheating
<gary_poster> Makyo, ok cool, thanks.  I'll see what tests exist for this and run with it.
<Makyo> gary_poster, awesome.  Guess it helps to have a fresh set of eyes on it.  Had my head in the sand about that stupid centroid problem, but if we want to just use a bounding box for statically positioned elements, then that should also work.
<gary_poster> cool Makyo :-)
<hatch> rick_h_: I'm using a navigate event because I didn't think that removing one of the features was ideal either....at least this is easy to remove later
<rick_h_> hatch: rgr
<bac> rick_h_, gary_poster: would either of you have a few minutes to chat?
<rick_h_> bac: sure
<bac> rick_h_: cool, i'll invite you
<rick_h_> I can quit harrassing hatch for a minute :)
<hatch> hah
<gary_poster> I can too, bac.  tell me if you want me
<hatch> the navigate isn't working properly either - edge cases
<hatch> bleh
<rick_h_> hatch: heh, well update the rest and push it up and we can take a look at it. There must be something that's not too horrible to do
<rick_h_> hatch: what edge case did you hit?
<hatch> if you land on a fullpage page from the url the onboarding instance is never created
<rick_h_> bac: sec, chrome updated and wants a plugin there
<bac> rick_h_: not letting you join?
<rick_h_> bac: moving to FF
<bac> rick_h_: you want to invite me (canonical me)
<rick_h_> bac: ok, got in https://plus.google.com/hangouts/_/76cpjh1086s40kevifkj5fa1ng?hl=en
<gary_poster> Makyo, https://codereview.appspot.com/25460043 ?
<Makyo> Looking
<gary_poster> thanks
<bac> gary_poster: can you join a chat ?  https://plus.google.com/hangouts/_/76cpjh1086s40kevifkj5fa1ng?hl=en
<rick_h_> hatch: ok, so thouoght on that
<rick_h_> hatch: why not do something in the navigate to tell onboarding to 'force show'?
<hatch> the instance doesn't exist
<hatch> so it would need to be created then
<hatch> and 'pushed' into the browser
<hatch> I really think we can accept the 'highlight left bar which isnt' there' issue in fullscreen
<hatch> they should have already seen it once
<rick_h_> hatch: huh? you navigate and it hits the browser, the browser can check query strings and force show the onboarding 
<rick_h_> huh? how is that? jujucharms.com forces to fullscreen by default. There's a reasonable chance they didn't see it
<hatch> I suppose...
<hatch> what if I remove fullscreen this week? lol
<rick_h_> heh, have fun
<hatch> parsing query strings requires a bunch of testing too
<rick_h_> hatch: sure, it needs one test in the test_browser_app and one for a flag passed into the init of the onboarding view?
<gary_poster> hatch, rick_h_ not really following along, but if you think I can try to eliminate requirements, I'm happy to try
<rick_h_> gary_poster: well the first step is to remove the button to re-show the onboarding right now
<gary_poster> ?
<hatch> rick_h_: well that but also the 'renderOnboarding' method is only called in the sidebar method
<rick_h_> gary_poster: but working around that, there's the issue of getting the browser-based "show only in sidebar" onboarding link working when clicked from the help menu in fullscreen
<hatch> so browser doesn't even support it in fullscreen right now
<rick_h_> hatch: right, and navigate will hit that
<gary_poster> can we simply not show the linkl when in fullscreen?
<rick_h_> hatch: call please? I feel like we're passing by on a step
<gary_poster> are the links actually vauable in fullscreen?
<rick_h_> gary_poster: no, the first stage of the onboarding is to highlight the sidebar charm view
<hatch> yes it's rendered once on load
<hatch> sure we can call
<hatch> just logging in
<hatch> I got logged out
<rick_h_> hatch: right, and you'll hit that sidebar method on every load
<gary_poster> rick_h_, ...right, but we already are supposed to have code that prevents onboarding when you start out in fullscreen
<rick_h_> hatch: k, sec door
<hatch> gary_poster: the dropdown bypasses that and shows it manually
<hatch> because it accesses the onboarding instance directly
<gary_poster> hatch, so don't either show dropdown when in fullscreen, or don't show that part of the dropdown (or gray it out) in fullscreen
<hatch> it's rendered once
<hatch> there is no 'if fullscreen'
<hatch> I actually like that better though
<gary_poster> and it doesn not respond to "display: none" ? :-P?
<hatch> more to rip out soon but not as workaroundy
<hatch> well nothing knows it's in fullscreen
<gary_poster> events fire!
<gary_poster> handlers handle!
<gary_poster> excitement mounts!
<hatch> I'm not sure the app knows if it's in fullscreen or not
<rick_h_> hatch: k, sorry, wheels arrived yay
<rick_h_> hatch: calling
<hatch> link?
<hatch> google hates me
<gary_poster> pretty sure we fire events, and if not, +1 on adding events assuming this is fast
<rick_h_> https://plus.google.com/hangouts/_/72cpinh2n9qbc8gp1jfl222g6c?hl=en
<rick_h_> I think a hard coded navigate with a ?force-onboarding=true will work easy enoough
<gary_poster> "easy" and reasonable enough UX is my interest.  we're ripping this out, so be open minded about solutions
<hatch> gary_poster: rick_h_ convinced me of uglyness
<hatch> :)
<rick_h_> it's not that ugly :P and like you keep saying, fullscreen is going away
<gary_poster> hatch, rick_h_ if fast, I'm ok.  if not fast, let me try to make a case :-)
<hatch> it's fast
<hatch> :)
<rick_h_> gary_poster: yea, I think it's a few lines. < 10 + tests
<gary_poster> awesome
<hatch> for some reason google thinks gary and I have been in a call all day and won't let me join any more
<rick_h_> lol, that's ok. Chrome is going nuts on me and won't load the hangout extension but FF will 
 * rick_h_ is living on the edge
<hatch> haha
<rick_h_> drag-n-drag is borked in the new dev update from today wheeee
<rick_h_> ok, my head is killing me. I'll check in later hatch to help get this unblocked. Thanks for working through getting it going
<hatch> enjoy time away from the lcd :)
<rick_h_> hatch: still confused on https://codereview.appspot.com/25390043/diff/1/test/test_dropdown_extension.js#newcode33
<rick_h_> hatch: in looking at your reply 
<hatch> looking
<rick_h_> hatch: oh, the code isn't updated yet
<rick_h_> ignore me
<hatch> oh yeah
<rick_h_> just going through your comments back
<hatch> I was going to push it but will now when this linking is fixed
<hatch> lboxing takes a long time on my laptop :)
<hatch> being able to redo the kanban board like this is pretty cool, definitely wouldnt be doing that if it was on a wall :)
<hatch> rick_h_: new version is up on codereview it'll require another qa unfortunately
<rick_h_> hatch: will take a look
<hatch> thx
<gary_poster> bundle vis svg highlight is offset to left a bit in FF. :-/
<hatch> blarg
<gary_poster> not important enough to prioritize, but a shame
<gary_poster> if you feel like tackling quickly feel free ;-) but not worth a lot of time
<gary_poster> IMO
<hatch> yeah that's kinda ugly
<hatch> it almost looks like that's how it's supposed to be haha
<gary_poster> heh
<hatch> gary_poster: still not MBP review from anandtech yet hey? :/
<gary_poster> hatch, :-)
<gary_poster> hatch, may just wait till next.  trying not to spend 2-3K unnecessarily ;-)  Laptop is falling apart but mostly work on desktop.  Must...protect...bank balance...
<hatch> haha yeah I'm in the same ballpark although it sure would be nice to have a better machine for the sprints and whatnot
<rick_h_> hatch: ok, review is a lot nicer, a few comments, pulling down to qa now
<rick_h_> hatch: LGTM aside from the small set of notes 
<rick_h_> hatch: thanks for pushing it
<gary_poster> night all
<hatch> cya!
<gary_poster> :-)
<hatch> rick_h_: cool so are you going to lgtm on the review?
<rick_h_> hatch: I did, but did you tweak the things in the review?
<rick_h_> hatch: though note this requires two reviews
<rick_h_> hatch: because it's over size
<hatch> just about to finish
<hatch> oh right
<rick_h_> hatch: cool
<rick_h_> maybe you can bribe Makyo :)
<Makyo> Sure
<hatch> Makyo: thanks - i'm just lboxing with the new changes
<Makyo> Will keep an eye out then :_
<Makyo> :)
<hatch> ohhh lboxxxxx
<hatch> Makyo: https://codereview.appspot.com/25390043/ thanks
<hatch> +666 diff :O
<Makyo> D:
<hatch> hey gary_poster|away any chance you're around?
<Makyo> hatch, the "show tutorial" link doesn't do anything for me; is that next iteration?
<hatch> hmm it should...
<hatch> sidebar or fullscreen?
<Makyo> Sidebar.
<hatch> ok checking
<Makyo> It was the first link I clicked after just loading /
<hatch> oh what the
<hatch> :/
<hatch> arg ok thanks I'll figure it out
<hatch> weee
<hatch> Makyo: ok I have no idea wth is going on sorry I'll have to figure this out
<Makyo> hatch, okay, good luck.  Code otherwise LGTM, will re-qa when you're ready.
<hatch> ok i think I got it
<hatch> localstorage converts everything to a string
<hatch> Makyo: ok re-proposing
<hatch> when is your EOD?
<Makyo> Half an hour, but no qualms about giving more time.
<hatch> gary_poster|away: whenever you have a spare moment lp:~hatch/juju-gui/hide-on-relation create a relation and watch the inspector - I found 'hiding' it to jarring
<Makyo> Dinner's already cooking.
<hatch> :) my EOD was 20mins ago but I wanted to get these two branches done hah
<hatch> I want to start off on a good note lol
<hatch> Makyo: ok updated, should work now :)
 * Makyo pulls.
<Makyo> I'm REALLY sorry, hatch, but one more thing.  After opening onboarding from that link, I can't close it because force-onboarding is still in the URL.
<rick_h_> Makyo: ooh, good call 
<hatch> UGH!
<Makyo> I wind up with http://localhost:8888/sidebar/?force-onboarding=true#/sidebar/?force-onboarding=true
 * hatch rages on fullscreen
<hatch> now I have to fire events from onboarding to navigate
<rick_h_> hatch: or go to localstorage during navigate
<rick_h_> hatch: it's dirty, but the navigate call can clear the localstorage, put a big XXX: GAHHHH in there
<hatch> oh I see what the issue is
<hatch> the cross handler is wakobuziness
<rick_h_> cross handler?
<hatch> well iunno what's going on
<hatch> somehow clicking the X is triggering a navigate
<hatch> button it is
<hatch> there we go
<hatch> Makyo: ok new fix coming down the line
 * hatch shakes fist, it better work this time
<hatch> Makyo: ok done
<hatch> er up
<Makyo> Hm.  Up to you on this one if you want to push it to another branch.
<Makyo> Closing onboarding leaves 'force-onboarding' in the url.  Everything works, but if you navigate to fullscrean, when you navigate -back-, it opens onboarding.  Could additionally show up if someone bookmarks that URL. I would not be opposed to a smaller branch done soon after if you want to tackle that separately, though that depends on our release plans.
<hatch> I'd rather not have this url stuff in there to begin with because it's just a hack to workaround fullscreen stuff
<Makyo> Understood.
<hatch> so....hmm
<hatch> on close I could fire another navigate event to clear it out
<Makyo> Fullscream.
<rick_h_> hatch: ditch url param go with localStorage, session, something you can set/clear invisibly
<hatch> lol yes
<Makyo> Yeah?  Would it just be whatever the URL is minus the force-onboarding query?
<hatch> rick_h_: good idea
<Makyo> +1
<hatch> I'll deal with that in the morning
<hatch> right now I have a Go vs Javascript talk to prepare for Saturday
#juju-gui 2013-11-13
<Makyo> Alright.
<Makyo> Good luck
<hatch> morning
<gary_poster> morning!
<hatch> quiet here today
<rick_h_> we're partying too hard
<hatch> haha
<hatch> gary_poster: whenever you have a spare moment lp:~hatch/juju-gui/hide-on-relation create a relation and watch the inspector - I found 'hiding' it a little to jarring
<gary_poster> hatch ack.  I showed the first half (hiding) to luca and got his ok, but not reappearing.  Will look after I finish an email (minute or two)
<hatch> sure no rush, I'm going to go grab some breakfast
<gary_poster> cool
<gary_poster> frankban, LGTM with question
<gary_poster> frankban, second LGTM
<adeuring> bac, benji: could one of please review this mp: https://code.launchpad.net/~adeuring/charmworld/more-heartbeat-info-3/+merge/195065 ?
<benji> adeuring: sure, I'll take a look
<adeuring> thanks!
<frankban> gary_poster: thank you! the -e argument can come before or after, I put that after just to make copy/paste easier for users which already have a default env, can switch the order if you think it's better
<gary_poster> frankban, cool, understood. Leaving as is makes sense then
<frankban> gary_poster: cool, landing
<hatch> hahaha http://eleks.github.io/js2js/ javascript to javascript compiler
<gary_poster> heh
<gary_poster> hatch, relation behavior looks nice to me.
<gary_poster> hatch, it is not what I showed luca though
<gary_poster> I showed him just disappearing
<gary_poster> I think what you have is better
<hatch> yay
<hatch> land and ask for forgiveness later?
<hatch> :P
<luca> hatch: gary_poster where do I see it?
<hatch> hmm good question
<hatch> luca: can you build/run gui branches?
<gary_poster> luca, do you want to check out a branch, or do you want to look at it on  comingsoon, or do you want a hangout?
<gary_poster> if you look at it on comingsoon that means it will have landed, to be clear
<luca> gary_poster: hatch I can bar but I'm pressed for time. I can see it via a hangout
<hatch> ok cool
<luca> hatch: send me a link for a hangout and I'll jump on
<gary_poster> hatch, luca, https://plus.google.com/hangouts/_/calendar/Z2FyeS5wb3N0ZXJAY2Fub25pY2FsLmNvbQ.j0rk5d371ph8331ijtf48t2uj0
<hatch> yusss
<luca> gary_poster: hatch looks excellent :)
<hatch> lol
<gary_poster> :-) cool
<benji> adeuring: your branch looks good; I had a few non-blocking thoughts and suggestions
<adeuring> benji: thanks!
<benji> my pleasure
 * frankban biab
<hatch> 3 line test...30 lines of stubs
<hatch> aww yeah
<gary_poster> I hope everyone is enjoying these bug emails as much as I'm enjoying causing them to be sent out.
<hatch> they make my day
<hatch> it makes me feel important...like getting snail mail
<gary_poster> :-)
<hatch> when you need to write 70 lines of stubs for two method tests there is a good chance that the method needs to be split up...lol
<luca> gary_poster: spam spam spam
<gary_poster> luca, I have some good deals I'll forward you as well.  Great prices!
<luca> gary_poster: sweet!
<gary_poster> :-)
<rick_h_> miracle drugs unite!
<hatch> lol
<gary_poster> Makyo, interesting: https://bugs.launchpad.net/juju-gui/+bug/1246928
<_mup_> Bug #1246928: Offers inexistent revisions to 'upgrade' (really, downgrade) to <juju-gui:Triaged> <https://launchpad.net/bugs/1246928>
<bac> hi frankban, have time for a quick chat?
<frankban> bac: sure
<bac> frankban: cool, i'll invite you
<bac> frankban: sorry, hangouts is taking forever to log me in
<bac> frankban: https://plus.google.com/hangouts/_/72cpi9b979kk5galo5ar2b5c1o?hl=en
<gary_poster> hatch, I'll take inspector shrinking 
<hatch> thanks
<Makyo> jujugui call in 10
<gary_poster> ty
<gary_poster> hatch LGTM & QAOK with a request for a bit more of a comment
<gary_poster> jujugui call in 2
<hatch> gary_poster: thanks!
<gary_poster> thank you, very nice
<gary_poster> 0 New bugs
<gary_poster> 5 gazillion spam emails
<gary_poster> benji yoo hoo
<gary_poster> hey hatch, should I wait for dropdown help widget to land before I start making a gui release?
<hatch> if that's alright, I'm just fixing the tests now
<gary_poster> cool hatch sounds good
<frankban> bac: the new bundle url option in the Deployer API call is optional, correct?
<marcoceppi> Hey party people, I'm at re:invent and I want to pimp the gui so hard it hurts
<marcoceppi> is there an easy way to list bundles in the GUI?
<hatch> lol
<bac> frankban: bundle_id, yes
<hatch> marcoceppi: sorry there isn't a 'bundle' category, a bug was just recently created for that though
<rick_h_> marcoceppi: maybe bac  knows if there's a way to generate a search for that doctype?
<rick_h_> marcoceppi: searching for jorge brings up all his bundles which is a series of them
<marcoceppi> I just need a few that I can search for and deploy
<marcoceppi> rick_h_: awesome
<hatch> yeah that's probably the best way
<rick_h_> marcoceppi: yea, search for jorge then you can demo those handful
<marcoceppi> rick_h_: good enough, I'll also demo export import
<frankban> bac: ok, in that context I'd suggest "BundleId" <shrug>, it's good to have it optional, in the next future also quickstart can use that param
<hatch> marcoceppi: great!
<bac> frankban: there is a card for quickstart already
<hatch> Makyo: I'm proposing the help-dropdown branch now, then i'll give it a once over and let you know....are you going to be able to qa in...~20mins?
<frankban> bac: ic, cool
<hatch> note: chrome slow? Check if you left the simulator running all night and have 1000's of services running in the background :D
<rick_h_> hatch: lol
<rick_h_> jujugui also heads up that the latest chrome dev edition is a mess, stay away if you're using it. Never had it this borked in a upgrade. 
<Makyo> hatch, yep
<hatch> Makyo: ok it's ready....phantom didn't crash this time so it took a lot less haha https://codereview.appspot.com/25390043/
<gary_poster> marcoceppi, search for ~gary: two good ones for demo
<gary_poster> bah
<gary_poster> bac, I guess ~ fix is not deployed to charmworld yet
<bac> gary_poster: should be
<bac> was the other day
<gary_poster> marcoceppi, http://comingsoon.jujucharms.com/bundle/~gary/demo/2/instantBigDataNoSQL and http://comingsoon.jujucharms.com/bundle/~gary/demo/2/mixAndMatch/
<bac> wfm http://manage.jujucharms.com/search?search_text=%7Ebac&op=
<gary_poster> bac, http://comingsoon.jujucharms.com/sidebar/search/?text=~gary
<bac> gary_poster: oh, that fix was in charmworld
<gary_poster> bac, ack. thought would be in api too
<rick_h_> gary_poster: oh hmm, we might need to url escape that search input perhaps. Maybe we don't
<gary_poster> rick_h_, https://manage.jujucharms.com/api/3/search?text=~gary
<rick_h_> gary_poster: heh, yea boom
<rick_h_> bac: did you want me to ask webops for a traceback from the logs or should we just file a bug that api search is hitting a different path not correcting the ~ ?
<gary_poster> how would you expect that to be escaped? %7E doen't cut it
<rick_h_> gary_poster: I think it's just probably a code path to search that didn't get covered in the other branch, my guess at least
<gary_poster> k cool
<bac> rick_h_, gary_poster: yes i think that's the case.
<bac> rick_h_: so i don't think the traceback would tell us more
<rick_h_> bac: right, well it'd tell us the code path
<rick_h_> bac: cool, will leave it be
<bac> i'll make a card
<gary_poster> thx
<frankban> gary_poster, rick_h_: anyone else: charm branch ready for review: https://codereview.appspot.com/26130043 . My branch is merged, so, thanks to Kapil, no forks in there.
<gary_poster> awesome!
<gary_poster> I'll take it frankban 
<frankban> gary_poster: thank you
<adeuring> benji: regarding your suggestion to record the time each (of possibly more than one) server was started: What should we use as the keys? the hostname caomes immediately to mind -- but the hostnames may change over time. Right now, it's for example "juju-staging-machine-3" for staging. Could become "juju-staging-machine-4" when charmworld is deployed again.
<adeuring> that would leave cruft in the mongo DB
<benji> adeuring: yeah, hostname was what I was thinking too, but I guess in this cloudy world hostnames are somewhat transient
<benji> thinking out loud: we could use the UUID of the root partition
<benji> we could just roll with it and know that very old hostnames are probably cruft
<benji> we could expire very old server names, say after 30 days
<adeuring> benji: right, that would be an option. Another option would be to use the juju unit name -- but that does not work in test environments...
<benji> in the charm we have root so we could pull the ID out of the BIOS
<benji> I'm leaning towards expiring old name/startup times when we add a new startup time.
<adeuring> benji:question here is how to distinguish between machines that are really gone and those that are simply not restarted for some time.
<benji> adeuring: that suggests either the "human factor" solution of just realizing which are old and ignoring them or adding some kind of liveness indicator
<benji> for example, probabalistically updating an "I'm alive" timestamp in MongoDB on each request
<adeuring> benji: ok, a helper script "remove_stale_start_times" or somesuch (started manually) would work.
<benji> something like this: on each request we get a random number and if that number is > 0.99 we put the current timestamp in the DB in this server's slot
<benji> adeuring: yeah, I would keep it simple initially
<adeuring> benji: random updates of "start time" are probably not what rick_h_ had in mind ;)
<rick_h_> adeuring: what are you guys talking about?
<benji> adeuring: heh, no this would be for the liveness indicator, in other words, the start time is valid as long as the machine is still "alive" and it is alive if its liveness timestamp has been updated in the last N hours/days
 * rick_h_ is confused what this is all in reference to
<adeuring> rick_h_: your suggestion to show the time a charmwolrd server was started on the heartbeat page
<hatch> gary_poster: sorry I'm trying to submit this branch but npm keeps failing for whatever reason...
<adeuring> benji: ah, ok, another indicator, once we identify machines
<gary_poster> np hatch.  doing qa and collecting changelog and so on.
<rick_h_> adeuring: oh, we can't just do a time = datetime.utcnow() in the app's __init__.py?
<rick_h_> adeuring: and have the heartbeat diff it?
<benji> adeuring: well, it could be another indicator, but it is to address the problem of telling the difference between a machine with an old start time because it just hasn't been restarted in a while and one that has gone away and been replaced
<rick_h_> adeuring: it's not a huge memory hog and if the thing gets restarted the timer restarts?
 * rick_h_ didn't think it was his suggestion anyway, but ok. 
<adeuring> rick_h_: I have already a branch ready; uses a mongoDB record instaed (I don't like global varoables...)
<rick_h_> adeuring: yea, but getting persistant storage involved is ugh because you have to track/clear/etc as you're running into. 
<rick_h_> adeuring: I know there's an aversion to global variables, but it's tiny, config is already global, and it auto resets when the app restarts
<benji> plus, keeping the value in the DB lets us deal with having multiple servers (which we very much should be considering)
<rick_h_> benji: I guess, but we care about the server we're talking to right?
<adeuring> rick_h_: see benji's remark ;)
<rick_h_> benji: I guess it goes back to the 'why' did we want it. 
<rick_h_> adeuring: yea, catching on slowly. 
<rick_h_> adeuring: I don't think this was something I asked for, I don't see the usefulness off the top of my head tbh. The revno is good enough for things I can think about caring about. 
<rick_h_> so you guys have fun with it :)
<adeuring> ;)
<gary_poster> frankban, LGTM and QAOK.  Thank you!
<frankban> gary_poster: cool thank you! I am investigating a problem reported in #juju and then land it
<hatch> looks like NPM is down I won't be able to submit this until it's back :/ I'm getting 500's on all npm calls
<frankban> gary_poster: quick hangout?
<gary_poster> sure.
<gary_poster> frankban, https://plus.google.com/hangouts/_/7ecpj64sk94egc6grifl8ko0b4?hl=en ?
<Makyo> frankban, time for a quick chat after this?
<frankban> yes
 * hatch hopes npm is back up now
 * Makyo restarts for updates.
<hatch> NPMMMMMMM!!!!!!!!!!
<benji> I have a charmworld branch up for review: https://codereview.appspot.com/26140043/
<frankban> Makyo: I am ready when you want
<Makyo> frankban, https://plus.google.com/hangouts/_/7acpjtb7d5f9efjcrvqtpc5cd8?hl=en
<hatch> ok they say they are back up, trying again
<Makyo> gary_poster, have a moment? If not, can wait for our call.
<gary_poster> Makyo, sure.  have a hangout or should I make one?
<Makyo> Have one already: https://plus.google.com/hangouts/_/7acpjtb7d5f9efjcrvqtpc5cd8?hl=en
<gary_poster> Makyo, can't hear or see you
<hatch> welp still broken
<gary_poster> hatch, "npmjs: i feeling fine again" ?
<hatch> still not working for everyone it seems
<gary_poster> oh: "i was feeling better briefly on sick hardware so i'm moving myself to another machine."
<hatch> they should use Juju
<hatch> :D
<gary_poster> heh, yeah
<gary_poster> hatch, why is this hurting us?  I thought cache was our savior in situations like this
<rick_h_> gary_poster: you have to have an initial pull to cache
<hatch> yeah that
<rick_h_> gary_poster: so when you lbox, into a tmp dir, it's empty
<hatch> for some reason it won't cache -all- modules for me for some reason
<hatch> no idea why
<rick_h_> *cough*download cache*cough*
<gary_poster> I thought even then we had a user-level cache
<gary_poster> ~/.npm/
 * rick_h_ zips up his .npm and emails it to hatch :)
<hatch> yeah - for whatever reason it never deploys from there
<gary_poster> :-(
<hatch> right now I'm getting a shasum match failing
<hatch> maybe someone else will have better luck landing for me?
<hatch> ~hatch/juju-gui/help-dropdown
<bac> benji: has anyone started your review?
<rick_h_> hatch: sec, I can try. 
<hatch> thanks
<benji> bac: not that I am aware of
<bac> benji: ok, i'm looking
<benji> thanks!
<frankban> guihelp: quick fix for the manual provider bug: https://codereview.appspot.com/26190043
<gary_poster> looking
<frankban> gary_poster: thanks
<gary_poster> np, ty
<rick_h_> hatch: -cr went through, doing submit now
<gary_poster> frankban, LGTM with no changes, doing QA...
<bac> benji: code looks great but i cannot QA right now as i have a charmworld running that took a long time to set up.
<benji> bac: that's fine; I have QAed quite a bit and the potential failure modes are pretty benign (famous last words)
<hatch> rick_h_: thanks lemme know
<gary_poster> rick_h_, btw do you know about lbox -adopt?
<rick_h_> gary_poster: kinda, I tried it once and got it wrong so just go the long way around 
<gary_poster> heh ok
<rick_h_> hatch: landed
<gary_poster> yay!
<hatch> rick_h_: awesome thanks
<rick_h_> gary_poster: yea, this kind of sucks to dupe, but always works for me 
<gary_poster> cool
<bac> frankban: you around?
<frankban> bac: yes
<bac> frankban: does this look like what i should be doing with the async client?  is the last line necessary?
<bac> http://pastebin.ubuntu.com/6412125/
<frankban> bac: looks good from a quick look. the last line must be removed, the io loop must be started once per thread, and the app already does it.
<gary_poster> frankban, the relationship does not occur in the bundle until after the services have started, right?
<bac> frankban: ok, i'm trying to test it interactively in isolation so that's why it is there.
<bac> gary_poster: that is what i've observed
<rick_h_> gary_poster: yep, takes a bit
<frankban> bac: if you really need to check the response, I usally prefer to used gen.coroutine and yield, so that it is sequential and you don't need to write callbacks
<gary_poster> k cool
<gary_poster> frankban, "LGTM and QAOK.  Thank you!"
<bac> frankban: i actually don't but am doing it here so that i can figure out why it is not working
<frankban> gary_poster: to your previous question, yes, that's how the deployer works. thank you for the review!
<gary_poster> figured. welcome!
<frankban> bac: cool
 * frankban landing and then disappearing
<gary_poster> :-)
<gary_poster> thank you
<gary_poster> jujugui, I'm making a gui release...while on calls :-P .  I may ask for help.  Anyway, Please hold off on landing to gui branch for a bit
<rick_h_> gary_poster: rgr
<hatch> :) gary_poster in hangout, come whenever
<hazmat> out of curosity has anyone else had slowness issues with leankit boards loading slowly?
<rick_h_> hatch: just tried it and not fast, but not unbearable. 5-10s?
<rick_h_> err hazmat 
<hazmat> rick_h_, i was seeing minutes, just related it directly to chrome-beta though.. chrome stable and its fine
<rick_h_> hazmat: I'm on chrome dev channel
<rick_h_> hazmat: but the latest dev channel release is full of fail, so not surprised
<hazmat> rick_h_, specifically the zendesk.js asset would take minutes to load and that would hold up the whole page
<rick_h_> hazmat: I only see a zenbox.js at 40ms from a cleared cache
<rick_h_> hazmat: so network latency?
<rick_h_> well, network fall-over
<hazmat> rick_h_, no.. it would never show up
<rick_h_> oh
<hazmat> just timed out always
<hazmat> i could wget the file but chrome would never load it
<rick_h_> gotcha, yea not seeing it here. 
<rick_h_> chrome 33, cleared cache, etc
<hazmat> no worries, i'll stick with stable for now
<rick_h_> yea, been back/forth between ff nightly and chrome dev a lot the last couple of days
<Makyo> gary_poster, I can still hear you.  Just a sec, it;'ll come back
<Makyo> SIGH
<Makyo> This network...
<gary_poster> :-)
<arosales> gary_poster, hello
<gary_poster> hey arosales 
<arosales> gary_poster, could you recommend anyone to talk error messages with evilnickveitch  and juju-core in terms of documentation?
<gary_poster> arosales, which error messages?
<arosales> in general error messages generated by the gui, and from juju-core we would like to document for users
<gary_poster> arosales, ack.  we probably would want to include quickstart in that too.  I think hatch (around now) and frankban (not around now) would be good choices.
 * hatch perks up
<arosales> gary_poster, thanks. I still need to find a good juju-core person. So it will probably be morning us time. I'll reach out to hatch and frankban to coordinate
<arosales> thanks
<gary_poster> frankban in particular would be good for bundle error messages, juju-core messages we expose, and quickstart.  hatch can help with where we might expose them.
<gary_poster> great arosales, sounds like a good initiative
<hatch> actually right now I'm working on juju-core unit errors for the GUI hah
<arosales> gary_poster, np, thanks for the help.
<gary_poster> :-)
<hatch> trying to track down all of them
<arosales> hatch, works out nicely :-)
<gary_poster> hatch, nice relation shrink/expand does not work on saucy FF for me :-/ .  Filing bug.  not a showstopper
<hatch> hmm, do other css transitions work?
<rick_h_> want me to test on FF nightly? steps to repo?
<rick_h_> repro ugh
<gary_poster> trying to remember where others are
<hatch> edit a config field
<hatch> the 'save' thing will slide up
<gary_poster> oh right.  yeah that works
<hatch> hmm darn
<hatch> I'm trying on qantal, see if I can repro
<gary_poster> k
<gary_poster> I'm trying on IE10
<rick_h_> reminds me, I saw IE11 was released to win7 and such. Do we need to qa/check that out? 
 * rick_h_ isn't sure how the rules on IE-land are written
<hatch> rick_h_: I already created a card for Friday :)
<gary_poster> rick_h_, hatch, yeah we need IE11. :-/
<rick_h_> hatch: ah, good stuff
<hatch> I'm ON IT!
<gary_poster> hatch, shrink/expand works on IE10
<hatch> yeah I tested in IE10 but not in FF
<hatch> looks like it doesn't work in quantal either :/
<gary_poster> :-/
<gary_poster> And Mac FF is broken in other ways I forget
<hatch> can't drag and drop
<gary_poster> Everything seems to work pretty nicely in IE10 actually.  bundle deploy was good.
<hatch> yeah IE10 is surprisingly good in 'most' areas :)
<gary_poster> DnD in IE10 doesn't get positioning right but I am overlooking that :-P
<hatch> positioning....what positioning :P
<gary_poster> :-)
<hatch> fyi it's caused by the center 'drop here' thing
<gary_poster> even when it is not there?
<gary_poster> visible
<gary_poster> not visible, sigh
<hatch> hmm I thought it worked properly when it wasn't there
<hatch> it's been a while since I looked into it
<gary_poster> seems to put everything off to the left
<hatch> yeah darn ok
<hatch> I think the issue with firefox is a height calculation issue
<hatch> sourcemaps aren't working though
<hatch> will have to look into it later
<gary_poster> cool
<gary_poster> thanks for quick triage
<hatch> looks like benji 's bug 1251014 is a case I didn't anticipate
<_mup_> Bug #1251014: The "Select relation type" dialog can be hidden by the inspector. <juju-gui:Triaged> <https://launchpad.net/bugs/1251014>
<hatch> should be easy to fix though
<hatch> just move the event firing
<benji> Yay for exploritory QA
<hatch> :)
<hatch> benji: is this your first? lol
<benji> hatch: almost
<BradCrittenden> benji: i just saw your question about the password.  you still need it?
<benji> BradCrittenden: yep
<gary_poster> jujugui finished releasing GUI.  trunk is open.  Working on charm now...
 * bac walks jojo.  bbiab.
<rick_h_> hatch: around?
<hatch> rick_h_: yup
<hatch> sorry I missed the ding
<hatch> Makyo: what vm did you use for your air?
<Makyo> VirtualBox, running Raring server.
 * Makyo dogwalks, btw.
<hatch> Makyo: cool thanks
<hatch> hmm apparently the dinging in my irc app is broken
<rick_h_> hatch: the mac folks I talk to are more parallels/fusion folks. Guess it's supposed to work better on OSX
<rick_h_> hatch: all good, I'll check in with you tomorrow. Want to make sure that the way this communication with the WSS and suck goes it's blocking or waits on rpc call or not
<hatch> rick_h_: yeah but parallels doesn't appear to support the latest ubuntu
<hatch> I just twitted at them to ask if they have an ubuntu support matrix
<hatch> so I'm going to give virtual box a go on the mrs computer
<hatch> I'll need more information on your wss q
<hatch> :)
<hatch> saucy server with 3.11 installed with virtual box on the air
<hatch> looks like it's working well so far
#juju-gui 2013-11-14
<evilnickveitch> arosales, hatch, gary_poster  thanks !
<arosales> we'll catch you tomorrow evilnick
<hatch> rick_h_: looks like parallels 9 supports 13.10 so i'll need to upgrade if I want to use it on there...just fyi
<rick_h_> hatch: coolio
<gary_poster> hey frankban.  thanks for charm branch.  sorry again for bad qa.  trying out your branch
<frankban> gary_poster: I was going to reply to your email, it does not seem a bad qa IMHO, it seems just a network connection problem, the environment setup exited with an error
<gary_poster> oh!
<frankban> gary_poster: so the charm is good, the less good thing is that when setup exits with an error we should call setup again when the user runs, e.g. make unittest
<frankban> gary_poster: so the branch I proposed is just a fix for that (remove the activate file if setup fails, so that next time setup is called, pip install is re-executed))
<gary_poster> frankban, oh, so when no dists were found for lazr.authentication for some reason, which I missed because I was moving too fast, then everything above it (yaml and mock) were effetively aborted?
<frankban> gary_poster: yes, I checked with a fresh lxc, and the dependencies are all correctly installed (I just found the missing rsync sysdep, added in the branch). so it seems pip install -r is transactional, so you were starting the test suite without any dependencies
<frankban> gary_poster: also proposed a similar quickstart branch. the logic si the same: "Remove the activate file if the requirements installation process fails."
<gary_poster> cool
<gary_poster> trying charm build again
<frankban> gary_poster: so good news, the charm does not introduce bugs in the testing infrastructure. bad news: PIP_DOWNLOAD_CACHE prevented my to find this problem earlier
<gary_poster> frankban, ack.  Don't see a way around that unless we make the download cache shared. what do you think of having a PIP_DOWNLOAD_CACHE as a branch that the makefile checks out?
<gary_poster> (or bzr ups)
<gary_poster> frankban, lazr.authentication reliably fails for me. :-( http://pastebin.ubuntu.com/6415348/ investigating
<frankban> gary_poster: with the branch I proposed, at least "pip install -r ..." is retried in case of previous errors. So, for example, the first "make" failed yesterday for you, and the subsequent "make test", instead of showing import errors, retries the requirements download.
<gary_poster> ack, definite improvement
<gary_poster> interesting.  https://pypi.python.org/pypi/lazr.authentication is only owned by leonard.  he didn't transfer. but...yeah.  I can't downoad that, for some reason.
<frankban> gary_poster: here is the full verbose log of "pip install lazr.authentication" without cache in my local machine, if it can help: http://pastebin.ubuntu.com/6415408/
<frankban> gary_poster: generated using "pip install -v --log lazrauth.log lazr.authentication"
<gary_poster> ack thx looking at charm pip log too
<gary_poster> frankban, charm log excerpt very diff: http://pastebin.ubuntu.com/6415421/
<gary_poster> Could not fetch URL https://launchpad.net/lazr.authentication (from https://pypi.python.org/simple/lazr.authentication/): <urlopen error [Errno -2] Name or service not known>
<gary_poster> !
<gary_poster> https://launchpad.net/lazr.authentication loads fine in browser
<frankban> Could not fetch URL https://launchpad.net/lazr.authentication/+download (from https://pypi.python.org/simple/lazr.authentication/): <urlopen error [Errno -2] Name or service not known>
<frankban> oh, yeah
<frankban> gary_poster: the same for https://launchpad.net/lazr.authentication/+download I guess
<gary_poster> frankban, yes. and http://pastebin.ubuntu.com/6415433/
<frankban> hum...
<gary_poster> and http://pastebin.ubuntu.com/6415437/
<gary_poster> frankban, what do you think of having a PIP_DOWNLOAD_CACHE as a branch that the makefile checks out, or ups?
<gary_poster> lp:~juju-gui/juju-gui/charm-download-cache or something.
<gary_poster> frankban, bizarrely, worked that time. :-/
<gary_poster> still think download cache would be a good idea
<frankban> gary_poster: huh? does it work now? yes I agree re the separate branch, medium priority? It's just for the tests and I'd like to understand why lazr.auth failed for you
<gary_poster> frankban, yes it works now.  no idea why.  it can now access those pages when it could not before. :-/
<gary_poster> frankban, separately https://codereview.appspot.com/26530043/LGTM
<gary_poster> https://codereview.appspot.com/26530043/ LGTM
<gary_poster> (with comment)
<frankban> gary_poster: confused about the comment, how do you use $ACTIVATE to diagnose?
<gary_poster> frankban, you can source the file and then use the venv's python to see if you can dupe the problem
<frankban> gary_poster: aha! good suggestion, changing also the other quickstart branch then
<gary_poster> cool
<gary_poster> frankban, https://codereview.appspot.com/26540043/ also LGTM with trivial
<frankban> gary_poster: great, thank you
<gary_poster> welcome frankban.  replying to my own email about this.
<frankban> gary_poster: both branches landed, thanks for the reviews and for the email! 
<frankban> trying to build new quickstart packages now
<gary_poster> rick_h_, will ping soon, sorry, still talking
<rick_h_> gary_poster: np
<jcastro> frankban, heya, so what's the plan for putting quickstart in the normal juju ppa?
<gary_poster> benji, will be late sorry.  rick_h_ joining now
<benji> gary_poster: no worries
<jcastro> rick_h_, hey if you have time today, when the stuff lands in prod on jujucharms.com I'd like to write it up, maybe talk me through it over g+ later?
<rick_h_> jcastro: rgr
<frankban> jcastro: not sure about the plan, gary_poster can give a better answer when he's free from calls
 * jcastro nods
<bac> hi frankban, can you give me some advice on how to use and test @gen.coroutine?
<frankban> bac: 1min
<bac> frankban: grab this branch when you get a chance lp:~bac/charms/precise/juju-gui/increment-deployments
<frankban> bac: looking
<bac> frankban: clearly i'm not returning the values correctly.
<frankban> bac: gen.Return is something you have to raise
<bac> frankban: and then is it a real exception or is that a return mechanism?
<frankban> bac: when you have a coroutine, you can either exit without values (without returning or just with "return" without values) or you can raise a gen.Return, that will be treated as a return value. This is a workaround to python2 not being able to use return in a generator.
<gary_poster> jujugui, I need helpfrom someone who can test the charm upgrade.  I was going to try and do it but am swamped in calls.  You would set up charm r76 the way IS has it (https://wiki.canonical.com/InformationInfrastructure/WebOps/CDO/JujuGui) and then upgrade to the newest version of the charm and document what needs to be done
<frankban> bac: in general, when you have a function decorated with gen.coroutine, the test is easier to write using the tornado.testing.gen_test decorator.
<gary_poster> for webops
<gary_poster> bac or benji, I can talk now with one of you, and move the other to the afternoon.  preference?
<bac> gary_poster: same/same
<gary_poster> ack
<bac> gary_poster: so now or later?  :)
<gary_poster> bac, benji's not responding, so let's do it now
<bac> frankban: ok, i'll look for gen_test
<benji> gary_poster: that's fine, we can go this afternoon
<gary_poster> thanks benji
<benji> gary_poster: but I do need a quick pre-imp on a card after you're done though
<gary_poster> benji heh ok.  not a lot of time.  will squeeze in
<frankban> bac: the idea with gen_test is that the test itself can use yield in order give the execution control back to the ioloop and wait for the result
<bac> frankban: ok, on a call with gary_poster atm.  be back shortly.
<frankban> gary_poster: I'll test the charm upgrade. So bzr revno 76 of lp:charms/juju-gui, juju-core environment and builtin-server=false, correct?
<gary_poster> thank you frankban !  yes
<frankban> cool
<gary_poster> frankban, also note the ga-key instructions on that page
<frankban> gary_poster: oh, so currently we are not using ga... ok so the new options are ga and builtin-server
<gary_poster> yes
<frankban> cool
<hatch> Dart 1.0 was released today http://news.dartlang.org/2013/11/dart-10-stable-sdk-for-structured-web.html
<hatch> so now we can port to Dart?
 * hatch runs
<hatch> Makyo: OneTab needs the ability to 'store' a single/group of tabs
<hatch> It says it supports that but I can't figure out how :)
<hatch> jujugui can I search commits on launchpad? I'm trying to find the commit to juju-core which added the unit details object
<bac> hatch: much easier with bzr locally, no?
<frankban> gary_poster: the old charm downloaded the gui release file v0.10.1. Is this surprising or am I missing something. I expected the old charm to download the last release. oh, maybe it was the last to be tgz?
<hatch> bac: it's looking like it
<frankban> yes it was
<bac> hatch: do you know what file?
<hatch> bac: well it was a series of them
<bac> hatch:  you can do 'bzr log <path-to-file>' and it'll only show you commits that changed that file
<hatch> if I could find the bug that would help either
<gary_poster> frankban, yeah probably last tgz
<frankban> gary_poster: do I have to simulate latest version, or just proceed with the upgrade?
<frankban> gary_poster: maybe it's better to just go on. let's see
<gary_poster> frankban, I think proceed is fine
<frankban> ok cool
<hatch> found it https://bugs.launchpad.net/juju-core/+bug/1224568
<_mup_> Bug #1224568: Improve hook error reporting <juju-core:Fix Released by themue> <https://launchpad.net/bugs/1224568>
<hatch> jeesh that took forever
<Makyo> jujugui call in 10.
<frankban> gary_poster: so revno76 does not work in juju-core (apache returns a 403, I guess it is related to the fact the gui was served from inside the charm directory.
<gary_poster> frankban, so what they told us must be wrong?
<frankban> gary_poster: they either fixed this issue or used another, less restrictive, version of juju-core
<frankban> gary_poster: juju-core is another viarable now, but I remember we had a fix for the permission problem...
<frankban> variable even
<gary_poster> we did
<gary_poster> frankban, you saw #webops?
<frankban> gary_poster: yes, and confirmed, solved giving +ar to /var/lib/juju/agents/unit-juju-gui-0/charm
<gary_poster> ack
<frankban> gary_poster: so I think it worked at the time with an older juju-core, but then they introduced this restriction
<gary_poster> ok
<gary_poster> that rings a bell
<Makyo> jujugui call in 2
<gary_poster> rick_h_, pingy ping
<adeuring> benji: could you have another look at my MP? The changes are big enough to need another review...
<benji> adeuring: sure (I'm on a call now, but will as soon as I can)
<adeuring> thanks!
<hatch> frankban: is there a way I can inspect the web socket traffic from the juju-core side?
<hatch> ahah I finally got it sending the information
<frankban> hatch: if you bootstrap with --debug all the ws traffic is in the debug-log
<rick_h_> hatch: or Makyo can I get one of you to do a first pass reviews on https://codereview.appspot.com/26290043/ w/o QA and just one for now. I've got to qa it all in a live env and I'll write up QA instructions once I make sure it all works right. Then I'll bug for two real reviews and a QA. 
<Makyo> Sure
<hatch> I'll take a quick glance
<rick_h_> Makyo: thanks
<hatch> oh Makyo you're on it
<bac> hey frankban, i want to mock AsyncHttpClient.fetch() so that it returns a response with a non-200 code.  what thing should i actually return?  a Future?
<hatch> rick_h_: don't like composition hey? ;)
<rick_h_> hatch: what do you mean? 
<hatch> I just had app.js open, you removed the mixin in favour of a utils file
<rick_h_> hatch: oh, I don't like tools that don't need any access to object state and require building into a dummy object just to test :P
<frankban> bac: yes, a concurrent.futures.Future (with a result already set)
<rick_h_> hatch: right, but it meant that it was spread across views/utils, app, the extension, the topology, etc
<hatch> yeah that was all over the place
<rick_h_> hatch: but yea, I felt this cleans things up as I needed to be able to wrap all places that deploy a bundle into one path I could test and add a watcher to
<rick_h_> and an extension didn't get me anything
<hatch> yeah true true
<Makyo> rick_h_, yeah, first pass looks good.
<rick_h_> Makyo: cool, appreciate making sure there's nothing crazy while I get the QA stuff in order. 
<hatch> rick_h_: do websocket frames wrap for you? It looks like it's broken in chrome
<hatch> I'm asking because you're on dev :)
<rick_h_> hatch: I'll have to look in a few. My charm is in progrerss of re-working due to changing the source 
<hatch> sure no rush https://code.google.com/p/chromium/issues/detail?id=286419 claims it was fixed in chromium but it would be too bad if that wasn't back ported
<hatch> ahh looks like they just have some bad css in the inspector now
<hatch> I wonder if I can provide a patch...
<benji> adeuring: I've finished looking at the branch.  I supplied a diff that you can use to add some comments to the new tests if you like.
<adeuring> benji: thanks!
<rick_h_> frankban: still around?
<frankban> rick_h_: yes
<rick_h_> frankban: nvm, found it. Case mis-match in grep 
<frankban> ok
<rick_h_> jcastro: your bundles for jenkins and mediawiki still have the cpu= constrints
<jcastro> ack, I'll blow em away in a minute
<rick_h_> jcastro: thanks
<frankban> gary_poster: juju upgrade-charm + juju set juju-gui ga-key=UA-1018242-44 builtin-server=false run ok. to be noted that in the process the latest (local) release of the GUI was also installed
<hatch> does anyone know of any broken charms or a way I can cause an error in a real env?
<rick_h_> hatch: how so? We try not to ingest broken charms 
<rick_h_> hatch: how are you looking to trigger an error?
<gary_poster> hatch, mediawiki broke for me yesterday :-/
<hatch> trying mediawiki
<gary_poster> frankban, yay, thank you. so, looking at https://wiki.canonical.com/InformationInfrastructure/WebOps/CDO/JujuGui at bottom... sorry, on call, one sec...
<hatch> I think we need to write some broken charms to test hook failures and the like
<gary_poster> frankban, I am going to edit the instructions and then ask you to approve diff
<frankban> gary_poster: ack
<gary_poster> thx
<hatch> unfortunately mediawiki worked just fine :/ hah
<gary_poster> sorry :-)
<gary_poster> hatch make a charm and break it?  use an old revision of the juju gui charm that doesn't support juju core?
<hatch> I'd really like a testing charm which allows us to test failures
<hatch> I have the string format of the StatusInfo
<hatch> but StatusData is implementers choice :)
<gary_poster> frankban, http://paste.ubuntu.com/6416799/ has ballpark side-by-side diff, which omits chars over 80.  http://paste.ubuntu.com/6416801/ is new.  http://paste.ubuntu.com/6416811/ is original.
<frankban> gary_poster: looking
<gary_poster> hatch, so make a testing charm! :-) or use an old revision of the charm you made that was broken at one point, or introduce a new error in a branch of it
<gary_poster> I can push it up if you want :-)
<gary_poster> thank you
<hatch> pssht, I don't write broken anything
<hatch> :P
<gary_poster> :-)
<hatch> yeah I'll write a broken one
<frankban> gary_poster: the new instructions look good. the only thought I have is that currently they have juju-gui-source set to something (a url IIRC). maybe we want them to switch to local? 
<gary_poster> frankban, ah!  yes, thank you.
<gary_poster> great catch
<frankban> gary_poster: in my test, I did not set juju-gui-source, so my test worked well with stable. I'd assume it should work also fi they switch on the fly from url: to local.
<gary_poster> ok thanks
<frankban> np
<bac> frankban: hey got a sec still?
<frankban> bac: on call, will ping you
<bac> ok, thanks
<gary_poster> charmworld update starting now-ish. eek
<rick_h_> charmworld? or the jujucharms.com?
 * rick_h_ looks again
<bac> wow, condesation from my cup fell on my MBP track pad and it went crazy with fantom events.
<bac> s/condesation/condensation/
<jcastro> rick_h_, oh bummer, in the jenkins bundle the constraints are blank
<jcastro> does that still mess stuff up?
<rick_h_> jcastro: that's ok, but the cpu one gets rejected
<rick_h_> so you can't deploy it
<jcastro> oh right!
<jcastro> it's cpu-cores
<jcastro> on it
<hatch> evilnickveitch: can you pm me your email and I can get you the list which was made 2 weeks ago
<hatch> then I can expand on it later
<frankban> bac: ping
<bac> hi frankban
<bac> frankban: can you look at this real quick http://paste.ubuntu.com/6416921/
<frankban> bac: sure
<bac> frankban: i expected calls to increment_deployment_counter to return a boolean but instead i'm getting a tornado.concurrent.TracebackFuture
<frankban> bac: ok = yield utils.increment_deployment_counter(bundle_id, cw_url)
<frankban> bac: it seems yield is missing: each gen.coroutine returns a future
<bac> frankban: ah, right!
<frankban> bac: also you can use mock.Mock(return_value=BadResponse) instead of defining your own mock function. <shrug>, but then you can take advantage of assert_called_once_with
<evilnickveitch> hatch, ok
<frankban> (and IIRC FakeResponse can also be mock.Mock(code=404)) etc...
<gary_poster> frankban, jujugui, jujucharms has new stuff.  yay!
<rick_h_> gary_poster: woot!
<frankban> great!
<rick_h_> gary_poster: now to send the email "STAY OFF COMINGSOON IN FRONT OF CUSTOMERS" :)
<rick_h_> or large tech conference gatherings 
<frankban> gary_poster: so from now on updating jc.com will also mean updating the GUI there. sounds cool
<gary_poster> frankban, you mean 'cause the tarball is there, yeah
<frankban> gary_poster: yes
<frankban> cool, time to go, bac: is everything ok?
<bac> frankban: yes!  i may ask someone here to review it but ask you to do a 2nd tomorrow.
<frankban> bac: ok
<gary_poster> hatch, you have been volunteered to brainstorm about Le Web. :-) if you have any ideas, please follow up with that mail from Sally
<hatch> on it
<gary_poster> thanks
<rick_h_> oh oh oh, it's working finally!
<frankban> gary_poster: just noticed bundles don't work in jc.com: Object #<PythonEnvironment> has no method 'deployerImport' . we might want to ask for an apiBackend change in config js and/or applying a patch like this http://pastebin.ubuntu.com/6417214/ to the charm (not tested)
<gary_poster> frankban, ah frak :-/ thanks will pursue
<frankban> gary_poster: ok thanks, have a nice evening
<gary_poster> tahnks frankban !
<gary_poster> you too!
<rick_h_> jcastro: does the discourse charm take a while to setup in a live deploy?
<rick_h_> jcastro: nvm, github goes boom and this charm goes with it :/
<jcastro> rick_h_, yeah, about 20 minutes
<jcastro> rick_h_, it doesn't do much until it relates to postgres
<jcastro> then it does a bunch of stuff
<rick_h_> jcastro: yea, one of it's deps hit github which was 500'ing and it took a LONG time to timeout and die
<rick_h_> jcastro: yea, just testing it as a bundle and making sure my in-progress/bundle complete notifcations are working
<jcastro> yeah, well, it's rails, the entire platform depends on the right dice roll of servers being up
<rick_h_> yea
<gary_poster> jujugui, looking for quick charm review of https://codereview.appspot.com/26430044/
<bac> i will
<gary_poster> thank you
<gary_poster> hey benji.  ready any time.  sorry.  lemme know when you are ready
<bac> gary_poster: quick enough?
<benji> gary_poster: sure, one minute
<gary_poster> bac :-) thank you yes
<gary_poster> Makyo, approved swap
<Makyo> gary_poster, ty :)
<gary_poster> it was a hard choice ;-)
 * gary_poster moving all releasable kanban cards to done...leankit is working hard...
<gary_poster> heh, "An error occurred while cards moving."
<gary_poster> Our massive card mountain proved too much for the poor little kanban board...
<benji> heh
<gary_poster> jujugui, the releasable lane is clear :-) (much rejoicing etc.)
<rick_h_> hatch: Makyo ok, I think I've fixed the final issue. QA instrucitons noted in the MP now https://codereview.appspot.com/26290043/ if you guys can start review
<rick_h_> hatch: Makyo I'm running my hopefully finally fresh QA from scratch, but the code is near enough final and ready for full review and such. Only need one QA if hatch wants to bribe Makyo to do it for him :)
<bac> benji: i manually hit some URLs on staging yesterday to increment metrics and saw them work by getting the 'total'.  today they are back to zero.  is that expected?
<hatch> rick_h_: ok I'll do the review first and see where that gets us
<bac> hatch: man, that mayor in toronto is getting classier by the day!
<hatch> bac: hah, I don't really follow it but it sure sounds like he likes to party
<rick_h_> bah, one more thing to fix
<rick_h_> jcastro: so nope, can't have the empty constraint values. Thave have to be legit
<jcastro> rick_h_, .... so basically, you need me to remove them entirely?
<jcastro> rick_h_, is this a deployer bug?
<rick_h_> jcastro: it's a mix I think. Yes, we should remove them as that'll update in 15min vs a production deploy
<rick_h_> jcastro: the thing is that Go won't accept an empty value for the key
<jcastro> ok so you want me to do it now?
<rick_h_> jcastro: so we should probably rip empty ones out along the path to juju-core before it gets them
<rick_h_> jcastro: yes please, they're up in the store for people to see and they won't work
<rick_h_> and we've been telling sales folks to use them to demo, but if they do it in a live env, it'll die
<jcastro> wait, what?
<rick_h_> right now, is someone were to bootstrap an ec2 env, and deploy your bundle, it'll fail silently
<jcastro> done!
<rick_h_> jcastro: ty much kind sir
<bac> rick_h_: did you say jcastro's cloudfoundry bundle was super slow to deploy?
<rick_h_> bac: yea, takes about an hour to finish I think
<bac> grrr
<bac> i used it for a test since it only has one service
<jcastro> bac, it takes an hour
<jcastro> if you want a fast one do mediawiki
<bac> jcastro: yours?
<jcastro> mediawiki-simple to be precise
<rick_h_> bac: lol, looks can be deceptive
<jcastro> yea
<hatch> rick_h_: is putting each param on a new line some python thing? :P
<bac> jcastro: mediawiki bundle?
<rick_h_> hatch: :P it's a reads nice thing when you can't fit on one line to start 
<bac> ah, mediawiki-simple
<hatch> haha
<jcastro> bac, if you have it locally please bzr pull, I just updated it about 2 minutes ago
<bac> jcastro: i need to deploy from staging for my test
<benji> gary_poster: ooh, one other thought I had in my notes: the "connect to a local juju environment from the GUI" feature doesn't have to be limited to the LXC provider, therefore we can let people manage their own EC2 (or private cloud) from a hosted GUI
<gary_poster> true, benji
<gary_poster> thanks
<rick_h_> gary_poster: heads up, filing this on the charm, but might be a deployer fix, not sure atm. https://bugs.launchpad.net/charms/+source/juju-gui/+bug/1251420
<_mup_> Bug #1251420: reporting an error from the environment isn't formatted well <juju-gui (Juju Charms Collection):Triaged> <https://launchpad.net/bugs/1251420>
<gary_poster> ack rick_h_ thx
<rick_h_> gary_poster: going to move forward with my branch as is, it shows that poor error message to the user for now since it's not my branch's fault? Is that ok or would you prefer I hide the message for now?
<gary_poster> rick_h_, go forward, thx.  what you see is <Env Error - Details:\n { u'Error': u'json: cannot unmarshal string into Go value of type uint64',\n u'RequestId': 1,\n u'Response': { }}\n > ?
<rick_h_> gary_poster: yea, you see "The deployment errored: xxxxxxxxxxxx"
<rick_h_> in the notification dropdown
<rick_h_> jcastro's bundles working all my code paths in QA so well :)
<jcastro> rick_h_, I am debating stealing maarten's and putting them in there
<gary_poster> jcastro, I copied quickstart to https://launchpad.net/~juju/+archive/stable
<rick_h_> jcastro: cool, gary has a working version of a couple of them I think
<jcastro> but I don't want to just shove them in there because
<jcastro> I'd rather have "real" ones that people actually use
<jcastro> instead of "here's what I think big data should look like even I know nothing about big data."
<jcastro> gary_poster, \o/
<gary_poster> yeah jcastro I put some of Maarten's in "demo".  Can add more if you like.  https://jujucharms.com/sidebar/search/?text=demo
<jcastro> rick_h_, wanna sync up on G+ wrt. quickstart? I'd like to write it up now that everything is landed
<rick_h_> jcastro: sure thing
<gary_poster> ok quitting time.  ttyl
<rick_h_> gary_poster: have fun
<gary_poster> thanks you too
<jcastro> https://plus.google.com/hangouts/_/7ecpjr7uvbg386q48qdcdnf7qc?hl=en
<bac> jcastro: on ec2 how long should it take to see some action when deploying your mediawiki-simple bundle?  i got nothing.
<jcastro> it's about 7 minutes for the bootstrap
<jcastro> and then after that they should come up quicklyish. 
<rick_h_> bac: wait on ingest cycle, it's got a constraints bug in it atm
<bac> jcastro: that's deploying from the gui?  i've hit the deploy button, it was acknowledged, but nothing
<bac> rick_h_: should it give feedback?
<rick_h_> bac: yea, there's empty constraints that it fails on
<rick_h_> bac: welcome to my branch :)
<bac> rick_h_: ok, good time to walk the dog
<bac> rick_h_: but shouldn't it give feedback if it fails with constraint errors?  or does it just silently slink away?
<rick_h_> bac: well, is this in sandbox or real env?
<bac> ec2
<rick_h_> bac: in a real env, it hits Go and Go up and dies. and my branch is working on displaying that Go error back to the user
<bac> ah, gotcha
<rick_h_> bac: so right now, there's an error thrown, but the gui isn't listening for it and my branch is working on that atm
<bac> rick_h_: i've also changed charmworld-url to point to staging.  lots of things to go wrong.
<rick_h_> bac: he's updated his bundle so once it ingests the constraints should go away 
<rick_h_> so that bundle should work shortly
<bac> ok great
<Makyo> jujugui trying to QA in an lxc, anyone have experience with this? lxc-start: command get_init_pid failed to receive response
<rick_h_> Makyo: no, never seen it. I know quickstart doesn't support lxc if you're trying quickstart?
<Makyo> rick_h_, just trying to get an environment without juju so I can qa quickstart installing it.
<hatch> rick_h_: ok almost done the review - am I missing why we can't process deltas for these updates instead of longpolling?
<rick_h_> hatch: ok, heading out. I landed one small change to fix using the import button
<rick_h_> hatch: we're not longpolling are we? I'm not sure how deltas work tbh. This was the api spelled out in the card from frankban
<hatch> Note: This returns once the server has something to update on. It might wait a while.
<rick_h_> hatch: see http://bazaar.launchpad.net/~juju-gui-charmers/charms/precise/juju-gui/trunk/view/head:/server/guiserver/bundles/__init__.py#L127
<rick_h_> hatch: true
<rick_h_> hatch: so no idea, this is what I had for instructions to work from
<hatch> ok maybe I'll let this sit for tonight and ask him in the morning
<rick_h_> hatch: I dont' think there'sa way in the delta to tell is a change was from a bundle request or just a command
<rick_h_> hatch: so just watching the delta as it exists will do me much good tbh
<rick_h_> hatch: especially since you can run multiple bundle deploys at once and have several running around at once until they complete
<hatch> right but can't we send the data down the delta that's being returned from this rpc call
<hatch> I don't know, I'm curious as to why that's not the case
<rick_h_> hatch: probably because this is run by the guiserver and the delta is proxied through it, but not part of it
<rick_h_> hatch: so the guiserver could mix up requestid and such if it tried to use the same channel
<hatch> right so we should be able to send a fake delta
<rick_h_> hatch: possibly I guess, I'm not sure if that's feasible from the guiserver/deployer side to generate fake deltas that look legit/work from the go env side
<hatch> I'm sure there is a valid reason why we aren't doing that but curious as to what that is
 * rick_h_ doesn't know enough about the delta stream
<hatch> would simplify this :)
<hatch> crap half my notes are on one rev and half are on the other
<rick_h_> hatch: :P well now you tell me on day 3 of working on it 
<hatch> you'll have to decode them :P
<rick_h_> hatch: all good
<rick_h_> hatch: hopefully not that many notes :P
<hatch> haha no - I am probably goign to lgtm it
<hatch> i havent' decided yet
<hatch> lol
<rick_h_> heh, well feel free to hold off. I'm going to EOD and do another round of QA in the morning. Kept finding 'one more small thing' each fresh deploy today
<rick_h_> and still need the second review and a 3rd party QA so won't go anywhere until later tomorrow
<hatch> sure thing I'll get the review finished for sure
<hatch> but not sure about qa today
<rick_h_> rgr, all godod
<hatch> I'm probably going to go back to lying down
<rick_h_> all good
<rick_h_> just mean no hurry
<rick_h_> yea, cool. Go medicate and such. I'm out of here. Will push this boulder farther up the hill tomorrow
<bac> rick_h_: this time it popped right up
<rick_h_> bac: cool
#juju-gui 2013-11-15
<bac> hi frankban, thanks for the great review!  i've reproposed and would like if you'd give a look, especially to the url encoding bits.  https://codereview.appspot.com/26740043
<gary_poster> rick_h_, hey.  Dunno if hatch will be around today (sick).  If it gets later with no reply from him on your branch, please ask around for someone else to follow up.
<gary_poster> rick_h_, I also can give answer to hatch's last question, if desired
<rick_h_> gary_poster: ok will do. It needs two reviews and he was generally cool with things and said he was debating a LGTM but wan't to check on using deltas
<rick_h_> gary_poster: so I'll rope someone in for a second review/QA while I tinker with it per hatch's review 
<gary_poster> ok cool
<rick_h_> gary_poster: if you know the 'why' for hatch appreciate the reply. (and I can see as well) 
<gary_poster> can be roped if desired, though I have interruptions for next hour or so
<gary_poster> ok will reply
<rick_h_> gary_poster: rgr, thanks
<frankban> bac: looking
<rick_h_> jujugui updated per hatch's review and looking for a second review/qa please https://codereview.appspot.com/26290043/ 
<hatch> morning
<hatch> still sick, but not enough to miss :)
<rick_h_> hatch: chicken noodle soup for your lunch today, rock on
<frankban> hatch: we are two
<hatch> yup
<hatch> I had to dig in the freezer for some
<rick_h_> you mean the back porch? :P
<hatch> lol it's not QUITE cold enough every day for that
<rick_h_> we had -7C the other day. Getting cold too early this year
<hatch> woah! I had no idea it got that cold there
<rick_h_> yea, we get down into some negative F range pre-wind chill
<rick_h_> but that's usually more Jan weather than mid-nov
<rick_h_> shoot, had our first snow before all the leaves fell 
<hatch> frankban: out of curiosity why can't guiserver receive a 'watch' rpc call from the gui and then send 'fake' deltas down the wire which we can react to? Why do we have to essentially long-poll for them instead?
<hatch> rick_h_: I LGTM'd I'm still not sold on the util object vs class but I'll let it go ;)
<rick_h_> hatch: rgr, did you see my point though that there will never be more than one 'instance' since that data is the same? I think that's what led me more utils vs object
<hatch> yeah so I was thinking in that case it could be an extension on another clas....like say....app :)
<rick_h_> hatch: well that and just refactoring the methods didn't have an object to start (well it was an extension, but on their own)
<rick_h_> hatch: :P right but then you need a 'fake app' to test and such. Ugh
<rick_h_> hatch: but I admit it's something that can go a few diff ways without being too crazy
<hatch> no no, you can just var myext = new MyMyExtension()
<hatch> yeah that's why I didn't argue over it :)
<rick_h_> hatch: except this.env doens't exist in new MyMyExtension
<hatch> implementers choice....for now!
<rick_h_> wheee! I won the joy of this lovely branch with all the live ec2 QA/testing work yay me
<hatch> myext.env = envStub;
<hatch> :P
<rick_h_> bah, invisible properties to the test reader then "what's this 'magic' attribute'
<rick_h_> go get your soup early
<frankban> hatch: no technical reasons, just a design decision. we decided to reuse a pattern already present in juju-cure (the megawatcher) and to not introduce a new one. Even if it feels more natural to just push changes from the server, the more I think about it the more I feel we made the right decision, especially considering that the deployer can eventually be implemented in core.
<rick_h_> gotta love how things to first written and depoyed in python to get re-written in go down the road potentially
<hatch> frankban: does the 'longpolling'  introduce any potential performance/race conditions or is it simply a flag on the guiserver side that says 'when this comes up, notify the user here'
 * rick_h_ wishes the config-changed hook to go faster...faster
<rick_h_> hatch: think node-like :P
<gary_poster> the latter, hatch
<hatch> ahh cool cool
<frankban> hatch: it's longpolling-like but in the same connection, so I don't see too much performance degradation. It just mimics a request/response over a wss connection. If races are discovered, that's a bug. In theory, when the client calls Next, it receives all the messages not yet received if there are, otherwise the next new event when it is generated
<hatch> sounds good
<hatch> I was mostly curious
<hatch> rick_h_: is someone else doing the qa on your branch or would you like me to?
<rick_h_> hatch: I was hoping to rope Makyo into the second review and qa, but if you've got bandwidth to qa would appreciate it
<rick_h_> hatch: not sure what your live juju env is looking like these days
<hatch> I have a juju core instance locally for lxc and setup for ec2
<rick_h_> hatch: ok cool, this is only for ec2-land so if you can qa would appreciate it
<rick_h_> hatch: tried to put some cut/past instructions on there and note the various code paths
<hatch> on it
<rick_h_> still working on a success for all 4 paths myself with various bundles
<rick_h_> keep finding new bugs or corner cases in things 
<gary_poster> hey frankban, I copied quickstart over to ppa:juju/stable yesterday
<gary_poster> I think maybe "releasing" it can be copying it over from the beta ppa?
<gary_poster> going forward as a process I mean
<gary_poster> what do you think?
<rick_h_> jcastro: used it for his blog post yesterday http://www.jorgecastro.org/2013/11/14/from-0-to-hero-in-a-few-minutes/
<jcastro> yes, mwahaha, you can't remove it now
<rick_h_> lol, trapped by a blog post
<gary_poster> :-) cool
<hatch> haha
<hatch> jcastro: hey do you know anyone who knows nginx really well? I'd love it for the http interface for my ghost charm :)
<jcastro> we used to
<frankban> gary_poster: cool thanks, sounds good. 
<jcastro> he did the setup in the wordpress charm
<gary_poster> great
<jcastro> hatch, is just straight up theft from wordpress not feasible?
<hatch> not sure I haven't looked into it
<hatch> I just figured we needed an nginx charm
<hatch> there are some, but none are promoted
<rick_h_> woot, it's working. Double bundle deploys, one is scheduled. party on
<frankban> bac: thanks for the changes, just added a comment. do you have an example charmworld URL to use to wwatch deployments count?
<hatch> :)
<bac> frankban: can't yet as juju gui and quickstart aren't sending them yet
<bac> frankban: i mean they are not yet sending the optional BundleID so it doesn't get triggered
<bac> frankban: i'll probably update the GUI today to do that
<frankban> bac: ack
<bac> frankban: so i think the best QA is just deploying a bundle and seeing that nothing blows up.
<rick_h_> bac: my branch plays around with that stuff so watch out 
<frankban> bac: I'll check the guiserver logs
<rick_h_> bac: the good thing is that the deployBundle call takes a 'name' parameter that it looks like no one uses, just passes null
<rick_h_> sweet, "bundle 1 completed" "bundle 2 starting"
<frankban> rick_h_: the gui will use it once we have bundle disambiguation I guess
<rick_h_> frankban: oh! that's what the name is for
<rick_h_> frankban: makes sense. I was going to bring up that gary_poster should add that to his list of 'bundle features needed' as well
<gary_poster> rick_h_, ack.  added
<gary_poster> ty
<frankban> bac: is you branch merged with ~juju-gui trunk?
<bac> frankban: which branch?
<frankban> bac: lp:~juju-gui/charms/precise/juju-gui/trunk/
<bac> frankban: are you asking if i've pulled the latest changes from the charm trunk into my branch?  no, i haven't
<bac> frankban: i'll do that and make sure there are no conflicts and tests pass.
<frankban> bac: thanks, then I'll QA
<luca__> how is everyone/everything today? All going good?
<rick_h_> hatch: actually, nothing here should be ec2 specific. I was using quickstart to initially bring things up and that required ec2. 
<hatch> oh now you tell me
<rick_h_> hatch: but that speed is offset by the other changes. Sorry to lead you to ec2 there 
<rick_h_> hatch: heh, yea I got thinking "why did I have to dothis on ec2?" 
<rick_h_> but hey, I got some good qa notes/bugs on ec2 yesterday/today :)
<gary_poster> hey luca__ .  all good.  releases have gone well to good reaction.  I have some jaas thoughts I want to share with you and ale before Tuesday on what we think we ought to start with next for jaas (hint: we think our previous plans are still necessary for jaas)
<luca__> gary_poster: cool, we should schedule something for Monday
<gary_poster> agree
<hatch> rick_h_: updated status for deployment: 0
<hatch> that is kind of...odd
<hatch> like what's the 0 for?
<bac> frankban: merged, unittests pass, pushed
<rick_h_> hatch: yea, I'm hoping with the naming /id stuff bac is doing we can make that nicer
<rick_h_> hatch: it's the deployment id, we don't have anything else to call it
<rick_h_> hatch: but you can do parallel imports so we have to be able to tell notifications apart
<gary_poster> luca, you and ale only have 4:30-5:00 Monday.  Will schedule.
<hatch> how about "Updated status for deployment id: 0"
<hatch> :)
<gary_poster> luca__, I should say :-P
<rick_h_> hatch: I like small edits :)
<hatch> haha, just wait, it's still running, there may be more
<luca__> gary_poster: ok
<rick_h_> hatch: all good, thanks for trying it
<luca__> gary_poster: add Peter too if you think he should be there
<gary_poster> luca__, he won't be at Tuesday meeting will he?
<gary_poster> prep for that is what this is about in my book
<gary_poster> aligning among ourselves
<gary_poster> I wonder if I should give you a preview today so you can warn others if you think it is necessary :-)
<luca__> gary_poster: he won't be at the tuesday meeting
<gary_poster> ok
<gary_poster> luca__, you have 30 min today sometime?
<hatch> rick_h_: so both discource and postgres dropped onto the canvas almost right away and I only saw a single notification
<luca__> gary_poster: sure, I'm in a cloud installer call from 4-5 but I can jump on after that
<hatch> bug?
<gary_poster> luca__, isn't that your EoD?
<luca__> gary_poster: sort of, it's ok though
<rick_h_> hatch: right, but they're still loading right? not green
<frankban> bac: please fix a lint error introduced by your last change
<hatch> postgres turned green without a notification
<hatch> still waiting on discourse
<gary_poster> ...ok luca__ I'll schedule and try to make it fast :-)
<bac> gah
<rick_h_> hatch: right, it'll wait until it's done and relations are done to say it's completed
<rick_h_> hatch: there's not a ton of updates unless it errors then you get a notification the instant things error
<rick_h_> otherwise it's "Started" ....wait a bit ... "Completed"
<luca__> gary_poster: :)
<hatch> ohh ok, I was under the impression that it had one on each machine being spun up
<rick_h_> hatch: if you deploy another one right now you'll get notified it's "scheduled" and then when the first bundle is done it'll to go "Started" and then "completed"
<hatch> but that wouldn't make any sense
<hatch> because you can see it in the canvas
<rick_h_> hatch: yea, it's more of a 'how is my bundle doing' state and the big thing was that errors would fall silently so this is providing a "Did it work or fail" summary notification
<frankban> hatch: yeah it would be like having subtitles
<rick_h_> lol, "Juju Gui, now with french sub-titles"
<frankban> :-)
<jcastro> hey rick_h_, I forgot to ask yesterday, the ability to deploy --to in a bundle? Is that v2? or v3? 
<jcastro> I want to have an all  in one discourse instance, including gui/bootstrap
<rick_h_> jcastro: so that should owrk from the deployer now. Not sure what's up with that on the quickstart front. frankban on the radar?
<hatch> discourse sure takes a while to spin up
<jcastro> yeah I know it works with proper deployer
<gary_poster> jcastro, shoudl work from deployer now, yes.  won't be visible or changeable in GUI though.  When that changes is currently up for debate.
<rick_h_> hatch: yea, it's got to pull the world of ruby from gems, github, etc
<jcastro> but now that I have quickstart I want to point people towards that instead of "raw" deployer
<bac> frankban: done
<hatch> oh jeebus I forgot it was ruby
<gary_poster> lol
<hatch> ruby.....because python wasn't....we've got nothing
<gary_poster> lol
<rick_h_> gary_poster: yea, but quickstart could support it even though the gui doesn't have a representation
<hatch> haha
<jcastro> hatch, man you want a good time, you think that's bad ... deploy the cloudfoundry bundle and debug-log that
<gary_poster> rick_h_, yeah, was agreeing with you on that.
<jcastro> rick_h_, I was thinking more from a "just ignore that section and pass it on to deployer"
<hatch> haha
<jcastro> that way we could do "all in one" bundles for people to deploy and just say "they don't show up in the gui properly but we'll fix that later."
<gary_poster> yeah, think that works now
<frankban> jcastro: quickstart deploys bundles using the guiserver, which then uses the last deployer version. so it should work
<jcastro> also, I had this crazy dream trying to figure out a nickname for bundles that are all in ones, instead of "one shots" as I've been calling them
<rick_h_> frankban: oh, whenI looked at the source the --to was a special flag picked up by code the guiserver path wasn't using
<jcastro> I'm going to start calling them happy meals.
<gary_poster> <snort>
<jcastro> self contained, all in one boxes.
<jcastro> I knew you'd get a kick out of that
<gary_poster> :-)
<rick_h_> where's my toy!
<jcastro> frankban, ok I'll give it a shot now
<jcastro> how is --to documented in the bundle file?
<frankban> jcastro: cool, let me know how it goes. rick_h_: I am referring to http://pythonhosted.org/juju-deployer/config.html#placement
<jcastro> so to: 0
<jcastro> should work?
<frankban> jcastro: give it a try
<frankban> (never used myself)
<jcastro> hey bac
<jcastro> did you guys ever finish off that bundle doc and hand it off to nick?
<jcastro> we should probably land that soon
<jcastro> I can finish it off today if you'd like
<frankban> bac: deploying
<bac> jcastro: i spoke to nick about your comments and he said he'd take care of it
<bac> jcastro: probably last week
<hatch> ya know I just read a blog post yesterday about why distributing ruby apps suck....now I see why first hand
<hatch> lol
<jcastro> ok I'll chase him down, thanks
<hatch> rick_h_: install hook failed on discourse and I didn't get a notification
<rick_h_> frankban: ah, you're right. I was confused back when I missed the juju-client has machine_spec
<rick_h_> hatch: hmmm, no notification that the bundle errored?
<hatch> nope
<hatch> and clicking retry in the gui doesn't appear to do anything....
<jcastro> frankban, it didn't error out
<jcastro> but it also didn't to: 0, fired up individual instances
<jcastro> also, whoever make "juju quickstart ." work, thank you!
<rick_h_> hatch: hmm, yea I just noticed that resolve issue on aonther bundle where I did get the error
<rick_h_> hatch: can you try another bundle, the wordpress-simple or the mediawiki one?
<hatch> yup
<hatch> also found a sidebar bug haha
<rick_h_> hatch: thanks, I'll try out the discourse onein particular. 
<rick_h_> sidebar bug?
<hatch> when I opened the unit details it was under the sidebar
<hatch> so I closed it
<rick_h_> yea, that's intentional
<hatch> now I opened it and it no longer has the 'jorge' search results
<rick_h_> oh hmm, lovely
<hatch> oh well....once fullscreen is gone we can hopefully rely on the yui routing
<frankban> hatch, rick_h_ : the deployer can take some time before returning a hook error
<rick_h_> frankban: k
<jcastro> frankban, should I file a bug?
<rick_h_> frankban: yea, I noticed a small lag, but it's purely a wait/see
<frankban> jcastro: investigating
<rick_h_> hatch: filed the bug on the resolved button
<hatch> rick_h_: haha I filed one on retry
<rick_h_> doh
<hatch> rick_h_: ok I deployed the wordpress bundle it had the 'started' message
<hatch> then say....5-10s later it had the 'completed' message
<hatch> but both are still yellow
<rick_h_> hatch: what ID was that for?
<hatch> 1
<hatch> both were for 1
 * rick_h_ wonders if that was bundle 0
<rick_h_> hatch: it said completed? not scheduled and started?
<hatch> it said started, then completed
<hatch> no scheduled
<hatch> so it must think that the discourse one is done? but didn't notify
<rick_h_> hatch: yea, if it started the second then it's killed off the first one
<hatch> sounds like a bug
<hatch> not sure from which end though
<hatch> this is tough to debug
<hatch> :)
<rick_h_> yea, it's been a tough branch to do
<hatch> no console errors or anything
<rick_h_> and now you're kiling my joy in testing it ok this morning
<hatch> well I'm going to start on my 'fail testing charm' and bundle
<rick_h_> no console in the charm (and I tried to turn that on) 
<rick_h_> gah! /me starts up another ec2 env
<hatch> rick_h_:  here is the retrying bug https://bugs.launchpad.net/juju-gui/+bug/1251664 so you can relate it to your bug
<_mup_> Bug #1251664: Retrying doesn't appear to do anything <juju-gui:New> <https://launchpad.net/bugs/1251664>
<rick_h_> hatch: yea, done. I marked mine  a dupe of that and figure they'll go together
<hatch> rick_h_: so I'm going to tear this ec2 instance down, cool? or do you need anything from it?
<bac> frankban: so did your deploy and QA complete?
<rick_h_> hatch: yea, kill it. I'll run again here. You did hte discource bundle first and then wordpress right?
<hatch> yeah
<hatch> and the discourse charm failed
<rick_h_> hatch: I swear it worked here, but I did different bundles in a different order
<rick_h_> I had a different charm fail and such
<rick_h_> hatch: rgr
<hatch> ohh ok
<hatch> well I'm going to write a charm which fails so we can test these things
<rick_h_> hatch: rgr
<hatch> destroy-environment should have like 3 levels of 'are you sure?'
<hatch> which gets more dramatic each time
<hatch> "are you sure you want to destroy your environment"
<hatch> "all of your data will be lost forever"
<hatch> "lost into the deep dark abys that is unallocated memory never to be seen or heard from again, can you really do that to such innocent data"
<frankban> jcastro: maybe I've found the problem. hazmat: ping
<frankban> jcastro: to double check, could you please try to deploy with "to: '0'" (quoted)
<jcastro> got it
<jcastro> frankban, that worked
<hazmat> frankban, jcastro ack, in meeting, noted re bug
 * jcastro nods
<frankban> jcastro: ok, thank you, we will need another release of the deployer and of the charm to fix that. in the meanwhile, I think it's fine to use quotes there
<jcastro> ok so now with to: and constraints: I am good to go
<frankban> jcastro: cool
<jcastro> frankban, yeah for now I'll leave the current discourse one in the store and create a different all in one
<jcastro> discourse-happymeal <--- just kidding
<Makyo> jujugui call in 10
<frankban> bac: AttributeError: 'Deployer' object has no attribute 'charmworldurl'. w eboth missed that, used without the underscore in _import_callback
<bac> frankban: thanks
<frankban> bac: and so I guess that "if" is the only part of that branch code that's not covered
<gary_poster> jujugui call in 2
<hatch> frankban: before you take off for the day I have a couple questions about Go for my talk tomorrow
<frankban> hatch: now is ok
<hatch> https://plus.google.com/hangouts/_/calendar/Z2FyeS5wb3N0ZXJAY2Fub25pY2FsLmNvbQ.t3m5giuddiv9epub48d9skdaso?authuser=1
<hatch> it'll be really quick :)
<rick_h_> lies! don't be fooled frankban 
<hatch> lol
<benji> I have a charmworld branch up with some refactorings needed for my current work.  I added some comments for the reviewer to make it easier to see what is going on: https://codereview.appspot.com/22190049/
<gary_poster> unfortunately reviewer comments don't migrate across patch sets
<benji> jujugui: charmworld branch up for review: https://codereview.appspot.com/22190049/  I added some comments for the reviewer to make it easier to see what is going on.
<hatch> gary_poster: nope they don't :(
<gary_poster> benji will look later if no o ne else takes you up on it :-)
<benji> thanks
 * rick_h_ curses npm!!!!!!!!!!!!!
<hatch> it's down again eh?
<rick_h_> yea, so juju set juju-gui-source is full of fail for QA
 * rick_h_ takes this branch out to the shed out back
<hatch> I've always wondered where that saying comes from
<hatch> it would make a mess of the shed
<rick_h_> https://twitter.com/npmjs/status/401406454088732672 guess it's coming back wheee
<rick_h_> jujugui is manage.jujucharms.com not responding for anyone else?
<bac> wfm
<rick_h_> bac: ok, thanks
<rick_h_> heh, it completed after 1.7M 
<rick_h_> hmm, looks like it's something in the inter-tubes http://www.downforeveryoneorjustme.com/manage.jujucharms.com shows it as down as well
<rick_h_> hatch: aha! you didn't get the error because there was no error message in the websocket
 * rick_h_ goes to check branch and see what to do about a completed with error without a message
<gary_poster> benji reviewing
<bac> jujuguipals: charmworld review please https://codereview.appspot.com/23330046
<gary_poster> benji LGTM
<gary_poster> bac reviewing
<gary_poster> will not do qa though
<bac> gary_poster: you are a reviewing machine
<gary_poster> :-)
<bac> well, ok then
<benji> gary_poster: thanks
<gary_poster> welcome
<gary_poster> bac, I'm wondering about edge cases for that new search behavior.
<gary_poster> bac, for instance, what if I type ~gary demo?
<gary_poster> I'd be looking for Gary's demo
<gary_poster> Is there some autocomplete rule I should be aware of?
<gary_poster> Since the autocomplete is now GUI's only search tool...
<gary_poster> it would ne nice if it had the features that m.j.c search had
<gary_poster> maybe (?)
<bac> well the old autocomplete rule was you'd get a 'name: text' search
<gary_poster> I have another call
<gary_poster> bac, yeah, we can separate that out into another card/branch for The Future
<gary_poster> but
<gary_poster> at the least
<bac> brb
<gary_poster> ok
<rick_h_> hatch: got a sec?
<hatch> rick_h_: yup
<rick_h_> hatch: https://plus.google.com/hangouts/_/7acpi4rj1mataa0gd8t6esan2g?hl=en
<gary_poster> bac ping me when you have a sec for a call.  comments will go faster there and you can beat me over the head more readily
<bac> gary_poster: now?
<gary_poster> cool
<bac> gary_poster: ringing
<rick_h_> hatch: ok, they both errored here. With crappy error boxes because they've got no error message. However, that's a fix for another branch in another project of code
<rick_h_> hatch: let me know what you get and then Makyo can just review if he gets a chance and get this landed
<hatch> sounds like a plan - the gui is almost up
<Makyo> Will do
<hatch> well I THOUGHT it was almost up
<hatch> lol
<hatch> lxc's apparently take a long time to start
<rick_h_> should only the first time you launch your first one
<rick_h_> after that it's fast!
<hatch> rick_h_: when you say 'fast' like <1m?
<rick_h_> hatch: my lxc units pull up in < 2min 
<rick_h_> bootstrap is < 1min and juju deploy juju-gui is < 2 or 3
<hatch> hmm yeah mine is definitely longer
<rick_h_> now setting the branch takes a bit, 10 maybe?
<hatch> ~15m total for the gui
<hatch> http://www.indiegogo.com/projects/linux-voice
<hatch> looks interesting
<hatch> unfortunately the price in GBP is a little craycray
<hatch> will be over $100/yr for me :(
<hatch> yeah I think these lxc's are running at 10m
<hatch> maybe it doesn't do multiple lxc creation at once very well
<hatch> rick_h_: well it has staged up the bundle properly so yay
<bac> gary_poster: i was so proud of my tilde-matches-owner test with bonnie and clyde.  next time.
<gary_poster> bac, :-) sorry
<hatch> oh c'mon discourse fail already so I can qa ok this!
<hatch> yay
<rick_h_>  error notification this time?
<hatch> uh oh
<rick_h_> no, no uh oh allowed
<rick_h_> there's no message, that's the known issue part. 
<hatch> https://plus.google.com/hangouts/_/7acpjifot1t4vf39qmvgc5if18?hl=en
<hatch> ^ rick_h_
<rick_h_> yayayayyaay. Makyo so hatch has QA and we're good. 
<Makyo> Coolcool,
<Makyo> \o/
 * bac off to festivities.  have a good weekend.
<hatch> you too
<hatch> enjoy
<gary_poster> bye bac
<gary_poster> benji, are you outta here also?
<gary_poster> or do you have another hour?
<benji> gary_poster: I'm pretty much outta here :)  Did you have something in particular?
<gary_poster> benji, cool.  wanted to run a document past you.  it'll wait.  have a great weekend!
<benji> gary_poster: something to look forward to
<gary_poster> ;-)
<hatch> gary_poster: email lgtm :)
<gary_poster> hatch, :-) thanks
<gary_poster> feel better hatch
<gary_poster> have a great weekend everyone
 * gary_poster waves
<hatch> thanks, you too cya
<bac> hatch you still here all by yourself?
<rick_h_> heh, hatch can't leave! Moar branches!
#juju-gui 2013-11-16
<hatch> sorry guys i missed the ding :)
#juju-gui 2014-11-10
<frankban> uiteam: I need two reviews and (possibly) two QAs for https://codereview.appspot.com/174790043 (quickstart/python). This is a long diff (sorry) with some interesting changes, including dropping support for juju < 1.18. Any help really appreciated. Thanks!
<rick_h_> frankban: rgr
<frankban> rick_h_: thanks
<hatch> morning all
<hatch> kadams54-away: can we push the call 5mins?
<hatch> rick_h_: they are calling winter here now a 'polar vortex' 
<hatch> nearly spit my coffee out when I read that
<hatch> kadams54-away: ping when you return and we can start on that AS chat
<kadams54> hatch: back
<hatch> welcome
<hatch> my coffee is almost cold
<hatch> I think I need a heated cup 
<kadams54> I just figured everything in the Canadian prairie lands was heated.
<kadams54> Engine heaters, heated sidewalks, heated gutters, heated cupsâ¦
<rick_h_> hatch: yea, pretty much
<hatch> haha - heated sidewalks, where do you think I live? In the rich area?
<kadams54> hatch: FYI, I'm in themeeting room.
<hatch> oh ok, joining
<hatch> maybe...
<kadams54> hatch: freakin' google
<hatch> lol
<kadams54> hatch: multiuser randomly decided to time out on my canonical login
<hatch> ohh yeah that happens and always during a call lol
<kadams54> Well, probably not randomly, but I hit my "keep me logged in" timeout
<whit> 502 https://jujucharms.com/docs/
<whit> Bad bad gateway
<rick_h_> whit: yea, it's not there
<rick_h_> whit: bad link, fixed in trunk and will try to release
<whit> gotcha
<whit> cool, glad it's know
<whit> n
<hatch> kadams54: I'll create the cards right now
<kadams54> Excellent
<hatch> kadams54: ok the three steps are done
<hatch> I think splitting it up into these three will make them 1 day/card
<hatch> ish
<kadams54> +1
<hatch> Makyo: lol nice T
<Makyo> It was the most delightfully strange thing, I had to get it.
<Makyo> uiteam call in 3
<rick_h_> or 3 on Makyo's watch
<kadams54> I'm in the room, but it says no one else is there?
<hatch> kadams54: odd it said you were in there but when I joined there was noone else
<hatch> lol
<hatch> we have crossed dimensions it seams
<hatch> same place at different times@
<kadams54> Now rick_h_ is here with me, but no one else.
<hatch> 3000 line test file.....now where is the test I need to modify....
<hatch> :)
<hatch> rick_h_: I'm going to be done this card fairly soon so just giving you some heads up so we can chat about the next step
<rick_h_> hatch: ok
<hatch> uiteam lf reviews and qa on https://github.com/juju/juju-gui/pull/650
<kadams54> uiteam: anyone know a way to consistently reproduce an error notification in a local sandbox env?
<hatch> kadams54: yeah just add it from the console
<hatch> app.db.notifications.add({ ... })
<rick_h_> yep, there's a type flag on there for errors
<hatch> yeah like Makyo said in the call - level: error
<hatch> rick_h_: I'm ready to chat about what's next whenever you have a moment
<rick_h_> hatch: k, joining
<kadams54> hatch: thanks
<hatch> kadams54: that work for you?
<kadams54> Yup.
<hatch> great
<kadams54> Fixed the problem, writing the test now.
<hatch> awesome
<hatch> notifications has been on the docket to be refactored for 2 years
<hatch> lol
<kadams54> not it
<kadams54> Before I submit this PR, I want assurances that my status as "having touched it last" does not constitute de facto ownership.
<rick_h_> lol
<rick_h_> I can make no such promises :P
<kadams54> Why did that "lol" sound evil in my head?
<kadams54> ;-)
<rick_h_> "git blame...it's Kyle! come on down. You're the next contenstant!"
<rick_h_> ent
<hatch> hahaha
<kadams54> "The price is *wrong* Bob."
<kadams54> Oh sorryâ¦ "The price is *wrong*, bitch."
<hatch> lol
<kadams54> uiteam: need reviews and QA on https://github.com/juju/juju-gui/pull/651
<kadams54> hatch: Looking at 650
<hatch> on it
<hatch> kadams54: can you re-run the tests on this one
<hatch> it looks like a spurious error - but you are also working in notifications
<kadams54> Yeah, let me finish QAing yours.
<hatch> cool
<hatch> also we can
<hatch> t clear notifications anymore I guess
<hatch> probably should create a bug for that kadams54 ^
<kadams54> hatch: just got a chance to look at the CI failure. Still gonna re-run tests, but I'm even more sure now that it's spurious. I added a test to test-notifications.js and the failure was in test-notifier.js, so not even the same file.
<hatch> yeah for sure - just want to be sure :)
<hatch> uiteam still looking for one more review https://github.com/juju/juju-gui/pull/650
<rick_h_> hatch: working my way there
<hatch> thank yas
<hatch> lunching
<hatch> because there is a juju-gui user and project on LP is very confusing 
<hatch> lets see if this time I can download the charm properly :)
<rick_h_> hah
<hatch> 138850kB   617kB/s | Fetching revisions:Inserting stream:Estimate 3486/12174
<hatch> I'm pretty sure I'm already over
<hatch> rick_h_: you said it was 120MB?
<rick_h_> something like that
<hatch> yeah wth
<hatch> bzr branch lp:~juju-gui/charms/trusty/juju-gui/trunk/ develop-trunk
<hatch> this is what I am running
<hatch> yeah I'm over 200 now
<hatch> rick_h_: is lp being auto sync'd to our GH repo?
<rick_h_> hatch: no, it's manual
<hatch> https://code.launchpad.net/~juju-gui/juju-gui/develop
<rick_h_> and huh?
<hatch> that has commits from last week
<hatch> looks like from the bot 
<rick_h_> hmm, no idea
<rick_h_> I thought we setup a bit MOVED file
<rick_h_> hmm, looks like it
<hatch> heh crazy
<rick_h_> didn't realize it was importing
<hatch> lol neither did I
<hatch> I'm trying to branch the repo again without the trailing /
<hatch> maybe that'll make it faster
<hatch> rick_h_: when you downloaded it did you have a cobzr setup? 
<rick_h_> hatch: no, I do that after the fact if I want to hack on it
<hatch> hmm ok and you ran the same command that I had above?
<rick_h_> bzr branch lp:~juju-gui/charms/trusty/juju-gui/trunk/ develop-trunk  
<rick_h_> for instance
<hatch> ok I have that running right now without the trailing slash - will see where it goes to
<hatch> guess I'll just let this thing run
<hatch> hmph I have no idea what's going on
<hatch> uiteam anyone else able to do me a favour and try and branch the guicharm to see how big it is?
<hatch> abentley: hey when bzr is branching, do you know where it puts the files before it's finished?
<abentley> hatch: I believe a temp dir inside the directory with a name starting with 'bzr-limbo-'.
<hatch> I'm trying to branch the gui charm and here is where I'm at so far
<hatch> 571695kB   616kB/s / Fetching revisions:Inserting stream:Estimate 3710/12174
<hatch> but the folder is only 56K
<hatch> abentley:  so I am trying to figure out if it's even downloading anything
<hatch> here is the command I ran bzr branch lp:~juju-gui/charms/trusty/juju-gui/trunk develop-trunk
<abentley> hatch: At that point it's creating the branch, and there are no files.
<hatch> 580MB downloaded with no files?
<abentley> Once it finishes creating the branch, it updates the working tree, and that's when it creates the files.
<abentley> hatch: Well, it depends what files you mean.  I expect there's plenty of data in .bzr.
<hatch> right but shouldn't a du -ha show more than 56K?
<abentley> hatch: That depends.  Are you using a shared repository?  That's where the bulk of the data goes.
<hatch> abentley: I just created a new folder and ran that branch command
<abentley> hatch: That doesn't tell me whether you're using a shared repository.  What does "bzr info" say about the directory or its parent directory?
<hatch> Unshared repository with trees (format: 2a)
<hatch> Location:
<hatch>   repository: .
<hatch> so no, not shared :)
<abentley> Well, I suppose it's possible that the data's all in memory.  Is the bzr process really huge?
<hatch> not really
<hatch> 100MB
<hatch> ish
<hatch> it's over a GB now
<hatch> heh
<hatch> abentley: how about this - can you get the repo size without downloading it?
<abentley> hatch: no, not really, but I think I have a copy here....
<hatch> rick_h_: recently downloaded it and it was only 120MB for him hah
<abentley> hatch: Yeah, 98M for me.  Probably a bit stale.
<hatch> *sigh* 
<hatch> so any ideas on what's happening now or how I may debug this?
<hatch> 1068064kB   618kB/s - Fetching revisions:Inserting stream:Estimate 3969/12174
<hatch> much bigger than 120MB :)
<hatch> and by the looks of that estimate there is a long way to go
<hatch> :) 
<abentley> Not really.  Sorry.  jam might know, but I never worked on that repo-fetching code.
<hatch> alright np thanks for the help :)
<hatch> abentley: rick_h_ I figured out a 'fix' for my issue
<rick_h_> you quit doing it wrong? :P
<hatch> I needed to launchpad-login then it worked?!?!?!
<hatch>  30105kB   612kB/s - Fetching revisions:Inserting stream:Estimate 283/968
<hatch> note the estimate size
<hatch> wth?!? This seams like an lp bug
<hatch> now we'll see if it actually stops at 120 haha
<abentley> hatch: Without your lp login, "bzr branch lp:" will not use SSH, so it will use bzr's http support.  It should have printed a warning about how that is slower.
<hatch> abentley: it wasn't slower - it was downloading at the same rate
<hatch> du -ah is now showing 100+MB
<hatch> definitely a bug there somewhere
<abentley> hatch: Yes, but it's not as efficient using http, so the same amount of data does not get you a branch as quickly.
<hatch> but is it orders of magnitute higher?
<hatch> and done
<hatch> wow....that was painless 
<hatch> 139MB toal
<hatch> total
<abentley> hatch: Can be, depending on what kind of junk is in the repo.
<hatch> before it was well over 1.5GB with du showing 56K
<hatch> yikes
<hatch> rick_h_:  updated process docs :) https://github.com/juju/juju-gui/pull/652
<rick_h_> noted :P
<hatch> oops thanks :)
<hatch> shipped
<hatch> what's this code in this charm....no curlies, no semicolons
<hatch> https://twitter.com/github/status/531914601248882689
<hatch> hmmmm
<rick_h_> heh, /me runs away scared
 * hatch pulls down fresh versions of all his git repos....just incase
<rick_h_> lol
<rick_h_> hatch: lol your branch was rejected
<hatch> baqhahaha
<hatch> damnit
<hatch> fixing
<rick_h_> :P nothing but trouble 
<hatch> wait what....it says my indentation is incorrect
<hatch> ohh I didn't have a line between them
<hatch> trying again :)
<rick_h_> uiteam night, I'm out. 
<hatch> I'm pretty sure I do not like the large hook file instead of having multiple smaller ones
<jcsackett> hatch: +1.
#juju-gui 2014-11-11
<frankban> uiteam: I need reviews for a quickstart branch: https://codereview.appspot.com/169380043 anyone? thanks!
<rick_h_> frankban: heh slim pickings today. Will look
<frankban> rick_h_: thanks!
<rick_h_> uiteam call in 5 please kanban
<rick_h_> kadams54: call?
<hatch> kadams54: hey, lonely day in the office? :)
<kadams54> hah yeah. rick_h_, me, and Makyo on the North American continent.
<hatch> isn't it also a holiday in the US?
<hatch> anyways just thought I'd check in see if you needed any reviews or anything for those cards from yesterday 
<hatch> no? ok :) I'll probably pop in later 
<aisrael> rick_h_: Is your team responsible for the content on https://juju.ubuntu.com/charms/ and/or jujucharms.com?
<rick_h_> aisrael: yesk for jujucharms.com, not on the first though we're deprecating that site soon hopefully
<aisrael> rick_h_: Ok. Right now, that first link calls out six 'showcase' charms, but they all lead to a 404
<rick_h_> aisrael: ah good stuff. I'll ping the web team on it.
<aisrael> Thanks!
<aisrael> I'll open a bug on it just so we have tracking
<rick_h_> aisrael: understood, email away and copied you on it
<kadams54> uiteam: Looking for QA and reviews on https://github.com/juju/juju-gui/pull/653
<rick_h_> kadams54: looking
<rick_h_> kadams54: <3 man I love this feature
<rick_h_> kadams54: I'm going to show this off like nothing else come friday
<rick_h_> :)
<kadams54> Nice :-)
<kadams54> It does demo well
<rick_h_> well and it's going to be so farn useful with the big opensteack demos and such
<rick_h_> darn
<rick_h_> kadams54: +1 maybe Makyo can get you a second one for today?
<Makyo> Sure, on it.
<kadams54> Makyo: thanks!
<rick_h_> ty Makyo 
<huwshimi> Morning
#juju-gui 2014-11-12
<rick_h_> morning huwshimi 
<huwshimi> rick_h_: Hey :)
<hatch> uiteam what's the proper way to test for null config value within a python charm hook? 
<frankban> self.assertIsNull(value)?
<frankban> hatch: ^^^
<hatch> frankban: I mean as a conditional
<hatch> I need to know if the user has defined a config value or not
<hatch> so I need to test for null and ""
<rick_h_> hatch: I'd just check if it's a digit and if it is, then try to use it as a port
<frankban> value = config.get('my-option'); if value...
<hatch> rick_h_: int(config.get('...')) ?
<hatch> basically the default config value is null (it's actually empty default which juju considers null)
<frankban> hatch: if the value is declared as an int on the config.yaml, I am fairly sure that you cannot get another type
<rick_h_> ah gotcha
<hatch> ok the docs are very confusing then
<rick_h_> hatch: yea, frankban has it 
<hatch>   port:
<hatch>     description: |
<hatch>       Supply a different port to host the GUI on besides the default 80 and 443.
<hatch>     type: int
<hatch>     default:
<hatch> according to the docs that should be null
<rick_h_> hatch: it depends on juju version and such. There was some work on their end to split up null vs "" and the GUI doesn't respect it currently :/
<hatch> so I'm trying to make the parser as resilient as possible in the event the user sets it to "" as well
<rick_h_> hatch: so frankban's idea will work because "" is falsey in python
<rick_h_> if "": 
<rick_h_>     print 'false'
<rick_h_> err true I mean
<hatch> right, but what is null if it's an int field
<kadams54> lol
<hatch> does it send "null" ?
<hatch> or...
<hatch> I could test it, but testing these hooks is painful :)
<rick_h_> hatch: try it out :)
<rick_h_> lxc deploy away!
<hatch> it's in the install hook 
<hatch> so I can't really do the hooks debugging
<rick_h_> log it out what you get and any checks you want
<frankban> hatch: I think that value can be either None (the Python spelling for null/nil) or an empty string, and even if it's just 0 (the zero value for integers in Go) that check would still be ok
<hatch> YAML > Go > JSON > Python 
<hatch> yay 
<hatch> lol
<rick_h_> hatch: never bored :)
<frankban> bool(None) == bool('') == bool(0) == False
<hatch> frankban: yeah I'm just concerned that it'll send something like "null" which will be truthy
<rick_h_> frankban: right but he's worried about getitng bool('null')
<hatch> yeah
<rick_h_> hatch: just try it 
<rick_h_> hatch: we're all just guessing for you
<hatch> yup trying now
<hatch> :)
<frankban> hatch: if you get the string "null" the problem is elsewhere
<hatch> the local charm deploy api needs some work :/
<hatch> interesting, it fails
<hatch>         log('default null is')
<hatch>         log(config['port'])
<hatch> unit-juju-gui-0: 2014-11-12 15:38:55 INFO start KeyError: 'port'
<hatch> maybe charmtools doesn't support null config values
<hatch> er charmhelpers
<hatch> error: invalid value "json" for flag --format: unknown format "json"
<hatch> uhhh
<rick_h_> hatch: there was a bug around that a while back. Maybe time to update charmhelpers?
<hatch> ohh - there just may be :)
<hatch> any idea why that format flag on get doesn't work?
<hatch> juju get --format=json juju-gui
<hatch> throws that error
<hatch> _config_get = command('config-get', '--format=json')
<hatch> that's in the helpers
<hatch> so I'm just trying to determine what's failing
<hatch> or maybe format only works in hooks?
<hatch> (which would be odd)
<rick_h_> hatch: right, I'm saying there was a bug I'm trying to find around that
<hatch> 1.20.11-trusty-amd64
<rick_h_> hatch: that's your juju version? and the charmhelpers version?
<rick_h_> bah I swear I saw this thing and google is failing me
<hatch> no version information in the charmhelpers.py file
<rick_h_> uiteam call in 5
<rick_h_> kanban please
<hatch> but --format doesn't work on the CLI either
<rick_h_> right
<rogpeppe> hatch: what output do you get from the CLI ?
<hatch> rogpeppe: <hatch> error: invalid value "json" for flag --format: unknown format "json"
<rogpeppe> hatch: ha, so i see
<rogpeppe> hatch: there's a TODO in the code
<rick_h_> damn I love having good docs search now
<rogpeppe> hatch: i'm surprised it isn't implemented
<hatch> rogpeppe: but it works in the hooks?
<rick_h_> http://qa.storefront.theblues.io:6543/docs/authors-hook-environment#hook-tools
<rick_h_> hatch: yea, it's a hook tool
<rogpeppe> hatch: it should work in the hook tool
<rick_h_> kadams54: call?
<mhilton> bac, rick_h: It looks like mojo is creating blues-browser tarballs with all the bzr history in them so they are 170odd MB is that enough to explain the timing?
<kadams54> rick_h_: joining.
<rick_h_> mhilton: call?
<rick_h_> mhilton: wrong channel please
<hatch> rick_h_: rogpeppe ahh ok
<hatch> ok I can probably test this via the hooks I guess
<hatch> rogpeppe: is there a bug about that --format? Or just a note in the code? :)
<rogpeppe> hatch: there's no bug referenced in the code comment
<hatch> ok do I just file a bug on the Juju project?
<hatch> juju-core that is
<hatch> uiteam is there a way I can deploy a local charm without it being in the specific undocumented folder structure? Or should I just create a symlink to the real folder?
<frankban> hatch: if you are talking about the gui charm, just run make deploy
<mhilton> hatch I do the symlink thing
<hatch> frankban: yeah I was just hoping I didn't have to do workarounds for such a basic functionality heh
<hatch> mhilton: ok thanks
<hatch> symlink appears to work well
<rick_h_> hatch: so I have a /src/charms directory with trusty/precise directories and do all my charm dev in those for just that reason. Once I set it up it's been cool but yea annoying
<hatch> rick_h_: yeah I tried that workflow but it doesn't really work when you have the same charm for both versions of ubuntu
<hatch> ghost, juju-gui etc
<rick_h_> hatch: right, just have two checkouts really
<hatch> then you also have to have very odd names for repositories
<hatch> ohh
<hatch> I think I'm going to file a bug around this
<rick_h_> hatch: and have to sync between them, and since you forked and can work between your branches it's ok
<hatch> it's really a poor UX imho
<hatch> it's not intuitive
<hatch> rogpeppe: could you point me to the line of code in GH where the note is about --format=json?
<hatch> uiteam does the config-changed hook get any indication of the  old/new values? Or which fields have been changed?
<jcsackett> hatch: don't think so.
<hatch> I didn't think so
<hatch> any ideas on how I may close a previously opened port?
<mhilton> hatch: Are you using charmhelpers?
<frankban> hatch: the gui charm stores previous values
<hatch> mhilton: yes
<hatch> frankban: oh?
<mhilton> hatch: in that case the Config option can do that for you.
<mhilton> s/option/object/
<frankban> mhilton: the gui charm does not use charmhelpers
<rick_h_> hatch: there was an email about the latest juju alpha that adds support for finding what ports are open though
<frankban> hatch: look at backend.py
<mhilton> hatch: http://pythonhosted.org/charmhelpers/api/charmhelpers.core.html#charmhelpers.core.hookenv.Config
<hatch> frankban: right so I have backend.config
<hatch> which is utils.get_config()
<frankban> hatch: I think that the backend.different method is used there
<hatch> ahh I see how it does it
<hatch> mhilton: yeah the version of charmhelpers we have here doesn't have that
<hatch> frankban: thanks
<jcsackett> rogpeppe: archivedownloadcount in stats is supposed to show deploys for a charm, right?
<frankban> np
<mhilton> hatch: sorry, you might be able to crib what it does though.
<hatch> mhilton: yeah looks like the guicharm already has the functionality baked in
<rogpeppe> jcsackett: it shows downloads, which might not be the same thing
<rogpeppe> jcsackett: if you deploy a charm twice in an environment, it will only download once
<jcsackett> rogpeppe: ok--so is that why the discrepancy between downloads here http://manage.jujucharms.com/charms/trusty/wordpress and here https://api.jujucharms.com/v4/trusty/wordpress/meta/any?include=stats
<hatch> man I miss chrome devtools :P
<jcsackett> b/c i'm noticing basically everything has *very* low counts.
<rogpeppe> jcsackett: we didn't grandfather in the old counts
<jcsackett> hm, ok.
<rogpeppe> jcsackett: so everything has started from scratch
<rogpeppe> jcsackett: perhaps raise an issue about that
<jcsackett> that's reasonable, but some of the feedback we've gotten is about the low counts we're showing.
<jcsackett> rogpeppe: yeah... rick_h_, thoughts ^
<hatch> rogpeppe: could you point me to the line of code in GH where the note is about --format=json? (whenever you have a moment, I'd like to add it to the bug report)
<rogpeppe> hatch: line 31 here https://github.com/juju/juju/blob/master/cmd/juju/get.go
<hatch> thanks :)
<rick_h_> jcsackett: rogpeppe yea, I wasn't sure if we wanted to try to split things up a bit and reset since there's so much legacy numbers but I think having 0 is bugging people more than my hope for a fresh start :)
<hatch> golang syntax highlighting in github is pretty nice
<jcsackett> rick_h_, rogpeppe ok, i've filed an issue.
<hatch> kadams54: will review your branch
<kadams54> uiteam: looking for reviews on https://github.com/juju/juju-gui/pull/654 < hatch, rick_h_ 
<kadams54> Damn you hatch, you're fast.
<hatch> github pinged me
<hatch> said 'check this ish out yo'
<kadams54> FYI, build failed fast, so I'm guessing a lint issue. Fixing now.
<kadams54> hatch, rick_h_: checkout this code diff: https://github.com/juju/juju-gui/pull/654/files#diff-f49ed99ac4fd4002b0649222733b6feaL50
<kadams54> Great example of how much the code was simplified by this change.
<hatch> bahahaha
<hatch> +1M
 * rick_h_ gets a cigar out "I love it when a plan comes together"
<hatch> brb
<hatch> rick_h_: hahahahaahaha
<hatch> we need a MR T
 * hatch will be Face
 * kadams54 nominates Wayne Witzel for Mr. T.
<rick_h_> I nominate urulama for Mr T, I want to see him with mad chains :)
<kadams54> lol
<kadams54> bling galore
<rick_h_> the best would be getting wayne for Mr T
<rick_h_> but not ready to adopt him over here yet :P
<kadams54> Maybe next year I'll add some gold chains to the gamehawk: http://imgur.com/a/OVbqs
<rick_h_> lol
 * rick_h_ donates to that kickstarter
<hatch> "and the winner goes to.....The A Team with the real black guy" 
<hatch> - family guy
<hatch> ahh funny episode 
<rick_h_> hatch: looking at the review, can you do QA please?
<hatch> lol urulama with bling
<hatch> he's going to look at these dings later and be like 'uhhhh?' :D
<hatch> rick_h_: yep on it
<rick_h_> ty
<hatch> kadams54: are these handlers just copy/pasted or were there internal changes?
<kadams54> hatch: the actual handler code worked mostly without change.
<hatch> alright
<kadams54> I did make one internal change, which was to shift from serviceName to using ID everywehre
<kadams54> That also simplified code
<hatch> doesn't that cause issues with ghost services?
<kadams54> Nope.
<rick_h_> hatch: can you make sure to QA with subordinates please? It's been on my mind that I've not tried that yet
<kadams54> Works better for ghosts
<kadams54> The issue we had with ghosts was that we were using service names everywhere and on ghosts the ID is different from the name.
<hatch> right - but if you change the visibility status of the ghost then deploy
<hatch> does it break then?
<hatch> ( I haven't got to qa yet)
<kadams54> Shouldn't. The code handles ID changes.
<hatch> cool
<kadams54> The token will re-render with the new ID.
<kadams54> But definitely worth testing the snot out of it :-)
<hatch> ok qa'ing now
<hatch> kadams54: +1 QA OK - there is a qa issue but it's minor
<kadams54> I'll check it out
<hatch> oh crap I just found another bug
<hatch> blarg
<hatch> ok one sec I'll try and reproduce it and then add to the PR
<hatch> (might be pre-existing though_
<kadams54> Let's get them all out of the system now :-)
<hatch> kadams54: ok added this new bug to the PR
<hatch> I'm pretty confident it's how it calculates what's related or not
<hatch> so likely pre-existing
<hatch> kadams54: I replied to the multi handler reply
<kadams54> hatch: And I replied back :-)
<hatch> we really need to figure out a better system for discussions on PR's
<hatch> lol
<hatch> maybe a rasp-pi with an led which turns green when review comments are done
<hatch> and red again when new ones need discussing
<hatch> lol
<hatch> rasp-pi might beoverkill :)
<hatch> lunching
<kadams54> hatch: when you get back, I commented on the QA issues.
<hatch> looks good thx
 * hatch isn't back
<kadams54> OK, if this build passes, I'll ship PR#654.
<hatch__> kadams54: did you need me to create cards/bugs for those qa issues?
<kadams54> hatch__: I can create them.
<hatch__> kadams54: so we should probably focus on those bugs next
<kadams54> True. I'll pick them up before optimizing the events.
<hatch__> great - if there is anything I can help with lemme know
<rick_h_> hatch__: woot it works!
<hatch__> rick_h_: lol YEAHHHHHHHH
<rick_h_> hatch__: and I didn't see the dns name because hover paginates your dns entries after 10 :/
<hatch__> lol
<rick_h_> it was name #11 for my dns 
<hatch__> took it up to 11!
<hatch__> rick_h_: so here is what i have https://gist.github.com/hatched/9b0a1723be672a1ee3fe
<hatch__> but it's never using the custom ports
<rick_h_> hatch__: looking
<hatch__> so I need to debug this script somehow
<hatch__> so I can use debug  hooks, but then I need to install pdb?
<rick_h_> hatch__: so I'd log out what backend.config and backend.prev_config are
<rick_h_> hatch__: are your log items in the modify_open_ports function getting called?
<rick_h_> hatch__: e.g. you have log items there?
<hatch__> yes it's saying it's using the default values
<hatch__> if hasattr(config, 'port')
<hatch__> so this is never resolving to true
<rick_h_> hatch__: ok, so yea I'd look at what the config has in it by logging the config/prev_config
<rick_h_> hatch__: I'd also log in the closing command above close_port
<hatch__> ok cool, and best way to dump a complex object in python?
<rick_h_> I bet backend.config, backend.prev_config is wrong
<rick_h_> hatch__: just str() it 
<hatch__> ahh ok sounds good - will try
<rick_h_> log(str(config))
<hatch__> thx
<rick_h_> np
<hatch__> deploying the same local charm increments the counter but still deploys the old code
<hatch__> how awesome 
<hatch__> lol
<rick_h_> heh
<hatch__> good thing I got my lxc going fast again somehow
<hatch__> rick_h_: https://gist.github.com/hatched/a455aae7cae3c5b35bc5 so as you'll see port is available in the first dump which is `config`
<hatch__> oh wth
<rick_h_> hatch__: oh, but you're checking hasattr
<rick_h_> that's for a class
<rick_h_> you just want to do 
<rick_h_> if 'port' in config
<hatch__> odly enough it resolves to true for the first confitional though lol
<rick_h_> it's a key in dict check
<rick_h_> hatch__: and the same with the prev config
<hatch__> damn, I had that but thought hasattr was more appropriate because it's a method :)
<hatch__> https://docs.python.org/2/library/functions.html#hasattr
<hatch__> makes no mention of it requiring a class
<rick_h_> no, it's for a class if you do obj.port
<hatch__> just says object
<rick_h_> you would check obj.hasattr('port')
<hatch__> wow docs fail heh
<hatch__> so which approach do you prefer?
<rick_h_> if 'port' in config
<hatch__> alright will give that a go
<hatch__> so am I nuts or are the docs incorrect?
<rick_h_> you're confusing a key with an attribute
<rick_h_> JS has magic 'hash is an object' stuff
<hatch__> OHHH now I see 
<hatch__> yes my terminology name clashing
<hatch__> oops
<rick_h_> hatch__: http://paste.ubuntu.com/8972163/ for some clarity
<hatch__> gotcha - I'm going to have to bust out the python book again this week
<rick_h_> all good
<hatch__> "use it or lose it" :P
<rick_h_> woot, guimaas update complete and email sent out. 
<kadams54> uiteam: Question: what happens to the units attached to a ghost service once that ghost service is committed?
<rick_h_> kadams54: so the service is first put into juju, then units are added to it after it's real
<rick_h_> kadams54: I believe we first have a 0 unit service and then add to it
<kadams54> So the old units, the ones associated with the ghost service, are blown away rather than being updated.
<rick_h_> kadams54: no, they're updated I believe. They turn from ghost units to real units? 
<kadams54> rick_h_: it looks like the highlight/fade/hide flags are not being carried over when that transition happensâ¦ any pointers on where to look in code?
<rick_h_> looking
<rick_h_> kadams54: https://github.com/juju/juju-gui/blob/486c9b93632b5582a8c4b2c65c85efbf0c9c5614/app/utils/environment-change-set.js#L1160
<kadams54> thanks
<rick_h_> kadams54: I think that's where the new live units come in and we turn the ghosts into real models
<rick_h_> kadams54: at least a point to put a debugger and see what happens
<hatch__> is there a way to unset a juju config value? Set it back to null?
<rick_h_> hatch__: juju unset
<hatch__> that's for all config values though
<rick_h_> oh
<rick_h_> well no idea then
<hatch__> rick_h_: atm if you set a port there is no way to get 80 and 443 back open without setting it to 443 manually
<hatch__> because 80 just redirects to 443 :)
<rick_h_> hatch__: gotcha, oh well gui is stateless-ish just blow it away and redeploy :P
<hatch__> haha it's an int, the only way to even flag off of that is to set it to 0 or something
<hatch__> because it errors if you try to pass empty string
<hatch__> I could of course make it a string field
<hatch__> but....that doesn't feel right
<hatch__> heh
<rick_h_> Makyo: do you have time to peek at https://codereview.appspot.com/172410043 today please?
<rick_h_> Makyo: oh, you had an appt, if not all good we'll get it looked at
<hatch__> rick_h_: nm I read the cli docs incorrectly :/
<rick_h_> you and docs don't get along :P
<hatch__> no kidding! today just isn't my day it seems 
<kadams54> rick_h_: The code you pointed me to updates the unit's serviceâ¦ but there seems to be code elsewhere that's changing unit.id from '8163515$/0' to 'mysql/0'.
<kadams54> Either that or it's creating a new unit. Either way, somewhere along the line the unit ID changes. Within that same space of code, the fade flag is also dropped from the object we store in the DB.
<huwshimi> Morning
<kadams54> huwshimi: Morning
<huwshimi> kadams54: Hey!
<hatch__> rick_h_: citizen M is advertising to me again...you know what THAT means!!!!
<rick_h_> hatch__: :P
<hatch__> lol
<rick_h_> kadams54: yea, have to chase it down. Can you set a watch or stop on the db or something?
<kadams54> Yeah, I can setup a temporary event handler that inspects unit changes/adds
<rick_h_> kadams54: might be able to get hatch__ or Makyo to help chase it as they did more of it. 
<rick_h_> kadams54: cool yea that should hopefully work out. 
<hatch__> sorry what? I'm just reading Tornado docs
<rick_h_> hatch__: lol
<hatch__> right? more docs
<hatch__> lol
<rick_h_> hatch__: kadams54 is trying to figure out how ghost units turn into real units and why the hide/show flags are getting dropped
<hatch__> gotcha
<hatch__> ok lemme open that code and refresh my mmeory
<hatch__> ^ kadams54
<rick_h_> hatch__: I started pointing him at https://github.com/juju/juju-gui/blob/486c9b93632b5582a8c4b2c65c85efbf0c9c5614/app/utils/environment-change-set.js#L1160
<rick_h_> but that's not quite the right spot
<hatch__> kadams54: models.js:857
<hatch__> thats the first handler from the delta updates
<hatch__> kadams54: also line 40 of the same file is the generic process_delta handler
<hatch__> which is called from the method on 857
<hatch__> hmm wait sorry turns out my version is different than trunk heh
<hatch__> oops one sec
<hatch__> https://github.com/juju/juju-gui/blob/486c9b93632b5582a8c4b2c65c85efbf0c9c5614/app/models/models.js#L796
<kadams54> thanksâ¦ I just hit EOD for now so I'm going to have to dig in more later tonight
<hatch__> yeah sure np hope that puts you on the right track
#juju-gui 2014-11-13
<hatch> kadams out today?
<rick_h_> hatch: not on the calendar
<hatch> hmm ok then 
<frankban> uiteam: https://jujugui.wordpress.com/2014/11/13/juju-quickstart-1-5-0/
<frankban> hazmat: ^^^ this also includes the existing environment handling changes you suggested 
<hatch> frankban: any idea where tornado.options is defined? I'm not having any luck tracking it down - it appears to be the proper place to put the new ports to open for the guiserver
<frankban> hatch: looking
<frankban> hatch: so basically the charm configures the guiserver (tornado) upstart script. the guiserver options parser is in server/guiserver/manage.py:setup
<hatch> frankban: oh so options are just flags?
<hatch>     {{if insecure}}
<hatch>         --insecure
<hatch>     {{endif}}
<frankban> hatch: no, options can be also parameters
<hatch> --charmworldurl="{{charmworld_url}}"
<hatch> but all done via the template correct?
<frankban> exactly
<hatch> ok got it thanks
<frankban> hatch: that's the upstart configuration file, which is used to start and daemonize the guiserver. the you'll need to add those parameters to the guiserver too, and the parameters are defined in the module I mentioned above
<frankban> hatch: add the parameters so that they are accepted by the guiserver
<hatch> yeah I had gotten that far, it just didn't click how `options` was getting populated :)
<hatch> now that's the missing piece
<frankban> hatch: options is a global name in tornado, the parse_command_line() call automatically populates the options with the values from the command line
<hatch> ahh I see
<hatch> so my only problem with python so far is that there is no indication of the import location of the files you're importing simply from the name :)
<hatch> maybe there is a trick to tracking them down besides grep?
<rick_h_> hatch: so imports are grouped, stdlib first
<rick_h_> then 'installed packages'
<rick_h_> then 'local packages' (things you wrote usually files closely
<hatch> ok so for example from tornado.ioloop import IOLoop
<hatch> I don't see a folder here named tornado
<hatch> or a file
<frankban> hatch: that's not stdlib, it's an external package installed by guiserver in order to run
<hatch> right
<hatch> so how am I to know where this file is?
<hatch> is that only available in the penv?
<frankban> hatch: in the charm, if you run "make" the development environment is created
<hatch> ok so what I was looking for wasn't available in the code anyways
<hatch> I would have just had to know to go look for the external tornado dep api website
<frankban> hatch: and it is created as a Python virtualenv in tests/.venv
<frankban> hatch: this means that all the dependencies are actually installed there
<hatch> so how would I find the source for tornado.options?
<frankban> hatch: specifically in tests/.venv/lib/python2.7/site-packages/
<hatch> this is what I'm getting at, I was looking for where tornado.options was defined
<hatch> but it's not in our source tree
<hatch> because it's only installed into the venv
<hatch> is this correct?
<frankban> hatch: tests/.venv/lib/python2.7/site-packages/tornado/options.py
<frankban> hatch: yes correct
<hatch> is this a typical python workflow? To not have deps source in the source tree?
<frankban> hatch: yes
<hatch> ok and where is it defined to pull down the deps?
<hatch> *.pip files I guess
<frankban> hatch: usually when you apt-get or pip install a python package, this is put in the global repository for python libraries (e.g. /usr/lib/python2.7/dist-packages)
<frankban> hatch: virtualenvs are used to avoid installing everything globally, and instead you recerate a local place where to pip install packages, including a local python interpreter
<hatch> yeah it's just a little odd that I have to go to a website to find the source then go to that website to read it
<frankban> hatch: the venv is created by tests/00-setup
<frankban> hatch: you don't have to go to the website, the packages are there, just in another dir, not the same as the code
<hatch> ok so maybe my issue is that i need to run a file in /tests 
<hatch> intersting that there isn't this functionality in pip like in npm :)
<frankban> hatch: a quick trick to find where the code lives: you can execute the python present in the virtualenv: % tests/.venv/bin/python
<frankban> then:>>> import tornado
<frankban> >>> tornado.__file__
<frankban> '/home/frankban/devel/juju-charm/sandbox/tests/.venv/local/lib/python2.7/site-packages/tornado/__init__.pyc'
<hatch> well right - but you need to know which file actually sets up the venv first
<hatch> with node projects it's simple you know you just run `npm  install` 
<frankban> >>> from tornado import options
<frankban> >>> options.__file__
<frankban> '/home/frankban/devel/juju-charm/sandbox/tests/.venv/local/lib/python2.7/site-packages/tornado/options.pyc'
<hatch> here you have to really dig for something which sets up the venv 
<hatch> oh now I see because pip install does it globally by default
<hatch> frankban: do you remember why we went with tornado over apache?
<frankban> hatch: tornado is asynchronous
<hatch> I'm not sure I understand...
<rick_h_> hatch: because we run stuff that catching api calls to do things like bundle deployments and such with added code
<rick_h_> hatch: so apache was just another layer we didn't need
<hatch> ahh ok ok
<hatch> yeah that makes sense
<hatch> I forgot about our bundle hacks
<hatch> heh
<hatch> there is a weird bug in the GUI when deploying bundles where sometimes they dont' render where you dropped htem
<hatch> I can't seem to reproduce it reliably however
<hatch> or reproduce it frequently for that matter
<hatch> (unfortunately)
<frankban> hatch: https://bazaar.launchpad.net/~juju-gui/charms/trusty/juju-gui/trunk/view/head:/README.md#L170
<hatch> http://www.cbc.ca/news/canada/saskatchewan/ground-stations-built-by-sask-firm-play-big-role-in-historic-comet-visit-1.2828928  :)
<hatch> rick_h_: jcsackett see even the Rosetta people know we exist :P
<jcsackett> hatch: bah, it's a canadian news outlet. can't be trusted.
<hatch> lol!! 
<hatch> kadams54: hey did you end up finding what you needed? 
<kadams54> hatch, rick_h_: I've hit a wall on my current added services card. Going to need some help figuring out how to proceed.
<rick_h_> kadams54: rgr, on a call atm 
<kadams54> Apparently I had not yet hit <Enter> on that message; got distracted by a phone call.
<hatch> hah - sure what's up?
<hatch> can't find where the units are being updated?
<kadams54> The units seem to be deleted entirely.
<kadams54> The ghosted ones that is.
<kadams54> Then the new, non-ghosted unit comes in and is handled by process_delta
<kadams54> Which means it has no hide/fade/highlight flags.
<kadams54> And since the ghosted one has already been deleted, there's no option to copy the flags over to the new unit.
<hatch> why not? Can't you query its service to get the visibility status?
<hazmat> frankban, which were those.. the bundle stuff using the -S for import?  .. what's initial support for the manual provider..
<hazmat> i use gui with manual all the time.
<hazmat> frankban, oh.. the don't bootstrap everytime thing..
<hazmat> k
<rick_h_> hatch: bring up your manual machine, run quickstart -i and fill out the manual fields to add a env for manual, and then it'll bootstrap/install gui
<hatch> ^ hazmat
<hatch> :P
<rick_h_> bah, hazmat ^
<frankban> hazmat: yeah the bootstrap strategy change
<frankban> hazmat: re manual provider, quickstart lets you bootstrap all the environments you have, but now the manual provider is actually recognized, validated, etc
<hatch> kadams54: ahh I see now where it's removed
<hatch> so when it comes in you should be able to query the services's visibility status
<hatch> then apply that to the units
<hatch> no?
<rick_h_> frankban: landscape called out the quick fixes for quickstart in the cross team call yay
<rick_h_> frankban: so mad props
<kadams54> hatch: True, though this makes me a bit leery.
<hatch> why?
<frankban> cool
<kadams54> hatch: code smell. We have units all over the place: in the DB, on the service, on the machine, and we have to make sure that the flags get replicated into all those locations. Now I find out that some other part of the code is deleting the units and re-creating them from juju-core data, meaning we have one more spot where flags need to be replicated onto a unit.
<hatch> yep
<hatch> that's definitely not being refactored by Friday
<hatch> there is a card to fix the unit handling
<hatch> but it's at least a week of work
<kadams54> I wish service.get('units') and machine.get('units') weren't ModelLists embedded on those models, but rather facades to db.units.filterByService and db.units.filterByMachine
<hatch> there are performance implications to that
<hatch> but atm I'm just concerned about getting this feature out Monday morning
<hatch> if this bug can be fixed by a simple cached query on the service then lets do'er then move on to the other bug
<Makyo> uiteam call in 4 kanban now
<hatch> kadams54: for the record, I too wish it was better :)
<kadams54> uiteam: looking for reviews and QA on https://github.com/juju/juju-gui/pull/655
<Makyo> on it
<hatch> frankban: in an effort to speed up this process can you tell me where the output from logging.info calls go to?
<frankban> hatch: /var/log/upstart/guiserver.log
<hatch> thanks :)
<frankban> hatch: sometimes, when I need to hack on the unit, I just stip the guiserver service and run the upstart command in the shell, without daemonizing. that way you can see the output directly, and even add pdb debugger calls to the code you want to inspect
<frankban> stop the guiserver even
<hatch> interesting - I'll have to give that a try sometime
<hatch> kadams54: +1's
<hatch> frankban: https://gist.github.com/hatched/3f6c74fa6d024ee0e12c
<hatch> the error is a little cryptic
<hatch> have you ever seen this before?
<hatch> Sorry to bug you, I'm just trying to keep moving forward here :)
<frankban> hatch: Unrecognized option 'port' does not sound that cryptic ;-)
<hatch> lol I mean...
<frankban> hatch: did you define that option in manage.py:setup?
<hatch> the traceback doesn't go very far but I think that it's being thrown from this line
<hatch> logging.info(options.port)
<hatch> oh no I didn't
<hatch> I'll do that
<frankban> hatch: cool
<hatch> frankban: so now might be a good time to try out your technique 
<frankban> :-)
<hatch> frankban:  so now you'll need to educate me on where the charm is stored in the unit :-)
<frankban> hatch: us ethe python interpreter to find that
<frankban> python
<frankban> import guiserver
<frankban> guiserver.__file__
<hatch> heh cool
<hatch> frankban: nice got it running, thanks :)
<frankban> hatch: cool!
<hatch> aparently juju log fails when it's trying to output None
<hatch> right on - it's working :)
<hatch> rick_h_: ok so....I'd like someone to look at this code before I get on the tests but I can't remember how to push it up to my own branch lol
<rick_h_> hatch: bzr push lp:~hatch/charms/trusty/juju-gui/customport 
<rick_h_> I think
<hatch> ok lets see
<hatch> rick_h_: nice, you were right
<hatch> https://code.launchpad.net/~hatch/charms/trusty/juju-gui/custom-port
<rick_h_> hatch: https://code.launchpad.net/~hatch/charms/trusty/juju-gui/custom-port/+merge/241716
<rick_h_> diff should load shortly
<rick_h_> frankban: if you're still around would love eyeballs on ^
<rick_h_> frankban: but if your EOD have a good night
<frankban> rick_h_: looking, wip right?
<hatch> hmm not a lot of loc's for how long it took :/
<rick_h_> frankban: rgr
<frankban> hatch: for the final proposal please use lbox
<hatch> frankban:  yes there are no tests
<hatch> I can't use lbox actually
<hatch> will have to figure out the reitveld process manually
<frankban> hatch: done
<hatch> frankban: thanks, looking
<hatch> frankban: so config isn't a map?
<hatch> re your suggestion to do `port = config.get('port')`
<hatch> config = utils.get_config() must return an object then
<hatch> interesting
<hatch> frankban: thanks for the comments - glad to see I was on the right track :)
<hatch> I'm going to grab some lunch now
<hatch> bbl
<frankban> hatch: get is a builtin method on python maps (aka dicts)
<frankban> done for the day, food night all!
<frankban> good night even!
<hatch> kadams54: heyya how goes the new bug? Was it the unrelated function not working properly?
<kadams54> Unrelated worked fine, but we shouldn't be toggling off highlight state for services unless they're actually highlighted.
<kadams54> So that's fixed, tested, just linting and prepping push
<hatch> ohh gotcha, cool - I was really hoping it wasn't some difficult problem heh
<hatch> kadams54: I like your technique of finding the bug, writing a test, then fixing the bug 
<hatch> juju debug-log
<hatch> bleh
<kadams54> uiteam: https://github.com/juju/juju-gui/pull/656 is ready for reviews and QA
<hatch> cool will check it out
<hatch> kadams54: uhhh what? How does this fix the issue? I'm glad it does...just...what? lol
<kadams54> hatch: are you sure you want to know?
<hatch> well...maybe you should add a comment in the code because looking at it there is no reason why it's there
<hatch> know what I mean?
<hatch> or no clear reason
<kadams54> I thought "don't toggle things that are already set correctly" was clear enough.
<hatch> so toggle highlight off, but only if it's not hidden and has highlight?
<kadams54> Toggle highlight off if it's not already off and not hidden.
<kadams54> If it's already off and we do an unhighlight, we end up with unintended consequences on downstream, due to the interplay between these states.
<kadams54> For example, unrelated services becoming unhidden at the wrong time.
<kadams54> I'll add a comment to that effect
<hatch> kadams54: works great - can't find any more issues -
<kadams54> yay
<hatch> the clearing of the container column is a little abrupt though
<hatch> it would be nice if there was some onboarding in there
<hatch> ^ rick_h_
 * rick_h_ reads to catch up
<rick_h_> hatch: hmm, yea I thought we had some onboarding at one time about selecting a machine. 
<rick_h_> hatch: let's get it up on comingsoon and we can send an email to the list about it and see if anyone has any feedback
<hatch> sounds goo
<kadams54> The onboarding is in the machine column, not the container column
<rick_h_> kadams54: right
<rick_h_> hatch: kadams54 thinking, the best experience would probably be that if you hid something and then unhid it that it would return to where it left off selection-wise
<hatch> I am wondering though if that is how people will use it
<hatch> they will probably click something else ?
<rick_h_> hatch: yea, maybe. We can run with it and adjust
<rick_h_> it's smaller adjustments from this point
<rick_h_> let's get people using it 
<hatch> kadams54: I +1'd so u just need one more
<hatch> then people can hammer on it :)
<hatch> the guicharm make unittest needs syntax highlighting
<rick_h_> hah
<hatch> rick_h_: is there a reason why these test files are prefixed with numbers?
<hatch> 00-setup 10-unit11-server
<hatch> etc
<rick_h_> hatch: the test tool uses it to run them in the right order
<rick_h_> e.g. boostrap, install, check stuff, build relation, etc
<rick_h_> alphanumeric sorting ftw
<hatch> ahh ok I figured there must be something :)
<hatch> I like how the unit test runner has a 'verbosity' property
<rick_h_> kadams54: looking at your branch next
<kadams54> Makyo beat you to it, so it's landing now
<kadams54> But feel free to hammer away at it more :-)
<rick_h_> kadams54: ah all good then
<rick_h_> kadams54: so after that next refactor card let's work on a release please. 
<kadams54> +1
<rick_h_> I just sent a status email and if we could do the release tomorrow or friday first thing that'd be perfect :)
<hatch> rick_h_: could I pass this branch off to someone else? I feel like these tests could take me another day because I need to learn all about them 
<hatch> I too would like this in the release
<rick_h_> hatch: ok, can you send an email copying me to frankban asking for help in his am to get the tests going?
<hatch> I feel real bad dumping this :/ I just don't want to miss the release 
<rick_h_> hatch: but make sure we set aside time to go through it and see what gets done
<rick_h_> hatch: all good, you've done some great stuff there. Think of it less on dumping and more of mentoring :) 
<rick_h_> and here comes the snow
<rick_h_> hmm, so does my other watch face clock go to slovenia and urulama or australia and huw
<hatch> haha 
<rick_h_> one for london, one for sydney, now I've got most of the team figured out :)
<hatch> is huw on Sydney time? I thought he was further west
<rick_h_> east actually I think
<rick_h_> or something, it's all backwards 
<rick_h_> google says he's +10 so that's sydney in the picker
<hatch> lol
<hatch> he must get really tired hanging upside downall the time
<Makyo> :/
<Makyo> We seem to be regressing.
<rick_h_> Makyo: ?
<Makyo> Oh, crap, that's overloaded.  Just meant hatch acting 12.
<rick_h_> oic, sorry release stuff all over regressing makes me scared :P
<hatch> bahaha
<Makyo> YEah, I didn't realize, hah c.c
<hatch> Makyo: shush and get your catdog out of the window ;)
<hatch> btw there is also an absolutely hilarious cartoon called Catdog
<Makyo> Yeah, I remember :)
<hatch> rick_h_: email sent
<hatch> did you want to chat about that card in tracking?
<rick_h_> hatch: sure thing, just got off a call
<rick_h_> hatch: standup room?
<hatch> sure 1 min just relocating to a room with good enough wifi :P
<rick_h_> Makyo: can you join the standup hangout?
<huwshimi> Morning
<hatch__> morning huwshimi
#juju-gui 2014-11-14
<rogpeppe> mornin' all
<mhilton> morning rogpeppe, everybody
<rogpeppe> mhilton: hiya
<mhilton> rogpeppe: If you find time it'd be great to get a review of https://github.com/juju/charmstore/pull/219
<rogpeppe> mhilton: looking
<rogpeppe> mhilton: reviewed
<mhilton> rogpeppe: many thanks
<frankban> rick_h_: gui charm branch is going well, almost done, going afk, will propose after lunch
<rick_h_> frankban: <3 ty much
<rick_h_> uiteam taking over guimaas to prep for demos for the UOS session today
 * frankban afk
<frankban> uiteam I need two reviews + QA for https://codereview.appspot.com/174170043 (GUI charm/python). Anyone, thanks!
<rick_h_> frankban: will do but will probably be after standup
<frankban> rick_h_: thanks np, I'll ping Jeff too
<rick_h_> frankban: so we'll shepard it through probably after your EOD to land
<rick_h_> frankban: ty for helping with that!
<frankban> rick_h_: doe sthe next charm release include a GUI one? anyway, I am available for releasing the charm later or on my monday morning, and now good luck with UDS
<rick_h_> frankban: yes it will. There's one card left before a new gui release with added services
<rick_h_> I'll be trying to pull it all together and want to make sure whatever release we do to prodstack on monday includes it
<frankban> cool
<rick_h_> frankban: ty, I'll let you know how far we get today
 * frankban afk again, trying to finish lunch
<rick_h_> uiteam I've got a demo of gui running on the develop branch. If you plan on borking trunk please don't :) (I'm pretty sure I'm safe)
<hatch> well it appears that my internet is shot today :/
<rick_h_> hatch: kadams54 found a bug in prepping for the demo with hiding units on machine view 
<rick_h_> hatch: kadams54 will leave this up on guimaas for debugging and such after the session
<kadams54> Hit me
<rick_h_> kadams54: hatch so one of the services is in error, with a relation in error
<rick_h_> when I hit hide, it doesn't hide
<rick_h_> if I hide a second service, both the new one and the first one that failed to hide at first now hides
<kadams54> Ah, so something with the error status is borking the hide action.
<rick_h_> probably
<kadams54> Well, I guess that's better than hitting hide on the second service and having it do something completely random :-)
<rick_h_> yea
<frankban> hatch: morning, https://codereview.appspot.com/174170043
<hatch> rick_h_: bleh ok :/
<hatch> frankban: awesome will take a look
<hatch> today it appears I'm on dialup lol
<rick_h_> lol
<rick_h_> you can watch the animated gif of our UOS session
<rick_h_> uiteam anyone want to be in the actual hangout for the chat? the etherpad for notes is at http://pad.ubuntu.com/uos-1411-whats-new-and-upcoming-in-the-work-of-juju-ui-engineering and the irc room is #ubuntu-uds-devops-1
<kadams54> rick_h_: what's the hangout URL?
<rick_h_> kadams54: no idea yet, working on it
<hatch> rick_h_: lol yeah I'll watch the stream in B&W via rabbit ears on my old crt 
<hatch> frankban: so this get() method that's on the config - is that provided by the json serializer?
<lazyPower> hey gui team - i'm  helping you get setup
<lazyPower> has anyone made a hangouts on air link for the broadcast yet?
<rick_h_> lazyPower: no, I thought a sessoin chair or someone was going to
<frankban> hatch: it's a default method on all python dicts
<rick_h_> lazyPower: do I need to create just a hangout on my canonical account and get you a link or how does this need to work to be on air?
<lazyPower> doing it now
<rick_h_> lazyPower: ty
<lazyPower> https://plus.google.com/hangouts/_/hoaevent/AP36tYek4Fu7CwFd9SQQ9f4CrPfzUOyHQ_E-pq1YS2zjwGaUPtyYBw?authuser=0&hl=en
<frankban> hatch: python -c 'help({}.get)'
<hatch> ohh intersting
<hatch> thanks
<hatch> much nicer than all my conditionals
<frankban> hatch: FWIW, to take a look at all dict methods: python -c 'help({})' and that works for all python objects
<jcsackett> dammit, hangouts won't let me stay on.
<jcsackett> rick_h_: rather than hopping in and out i'll just stay off. sorry.
<hatch> the video isn't loading for me, might just be my connection though
<hatch> http://summit.ubuntu.com/uos-1411/meeting/22387/whats-new-and-upcoming-in-the-work-of-juju-ui-engineering/
<hatch> kadams54: are you on the AS bug?
<kadams54> Yeah, I will after the demo.
<hatch> alright cool
<hatch> frankban: why lambda vs function?
<hatch> read some docs, dont' really see when it's useful
<frankban> hatch: simple function, just one line, mostly a personal preference, sometimes I find the slightly more expressive...
<frankban> hatch: no hard rules there
<hatch> got it
<hatch> I see you added a port validator
<hatch> that's pretty nice
<hatch> frankban: code looks good just pulling the branch down
<hatch> but at 80kbps it's taking a while :)
<frankban> :-/ thanks for looking at it
<hatch> no thanks for picking up my slack :)
<hatch> frankban: +1's
<frankban> hatch: cool, landing it
<rick_h_> uiteam call in 7 kanban please
<rick_h_> hatch: kadams54 ok, talk is over so you guys can have the guimaas for debugging if that helps
<rick_h_> some issues with the demo on a live env it looks like
<rick_h_> uiteam gui has the guimaas for a bit for new feature debugging
<kadams54> rick_h_: Thanks - I'll dig into the bugs after standup.
<kadams54> rick_h_: What's the publicly-exposed URL for the guimaas?
<rick_h_> kadams54: check out https://docs.google.com/a/canonical.com/document/d/1v3Bs7JU_mYrwRFbXWcQzNRje_EYz0nqqz9yaR4Nadro/edit
<rick_h_> kadams54: http://maas.jujugui.org/MAAS is the maas side, not sure which item you're looking for 
<kadams54> rick_h_: thanks
<kadams54> rick_h_, hatch: I think I found the bug that came up during MAAS
<kadams54> er, during demo.
<hatch> oh?
<hatch> spillit
<kadams54> Yeah, a change I made in fixing the last bug caused this one. The machine change event wasn't being fired for fades, so the token in MV wasn't being re-rendered.
<kadams54> I found that while working on decreasing change event noise
<kadams54> So it's actually already fixed.
<kadams54> I think.
<kadams54> :-)
<hatch> lol
<hatch> awesome
<hatch> you added a test for it, right? :)
<kadams54> yes
<hatch> but the bug that was in the demo was the service token not being hidden
<hatch> nothing to do with the mv
<kadams54> ah, true
<kadams54> dangit
<rick_h_> kadams54: that was in develop, is this fix in your current branch?
<kadams54> rick_h_: Yes, though as hatch pointed out, the problems you saw were in service view, not machine view.
<kadams54> So I think we still have bugs
<kadams54> rick_h_: I'm having problems SSHing into MAAS. I'm assuming you took the SSH keys off Launchpad?
<rick_h_> kadams54: yes, just ssh-import-id
<kadams54> I have three keys on launchpadâ¦ not familiar with ssh-import-idâ¦ did it grab all three, or just one?
<rick_h_> kadams54: what's your lp username?
<kadams54> kadams54
<kadams54> https://launchpad.net/~kadams54/+sshkeys
<rick_h_> kadams54: ok all three imported try again
<kadams54> Hmm, still no go. What username should I be using? kadams54?
<rick_h_> ubuntu@
<kadams54> http://pastie.org/private/f5gr8xhesfyw7qiosjiew
<kadams54> rick_h_: Wow, OK, I think I may have badly misunderstood something due to my sshuttle newbie-ness. I was expecting it to use the SSH keys to login, so when I'd get the password prompt above I assumed something was wrong.
<kadams54> But then I tried the password specified in the Google Docs and that seems to have worked?
<kadams54> At least, sshuttle reports I'm connected
<hatch> I always read that as ss-shuttle :)
<hatch> rick_h_: so this api layer - we rely on a separate module to make the requests so really it's just a thin wrapper around that modules public method
<rick_h_> hatch: right, that's my thought. 
<hatch> so my question is, how far does this rabbit hole go? Do we  want to create a new 'network' layer?
<hatch> if we want to offer this api to general users we'll need to offer a stack
<rick_h_> hatch: sec, let's chat in 3min
<hatch> sure just ping whenever
<rick_h_> hatch: meet you in the standup
<hatch> joining
<hatch> rick_h_: just having an issue joining
<hatch> couple mins
<rick_h_> kadams54: you're in?
<kadams54> rick_h_: Maybe? Just realized that sshuttle was dying after I started it up; had to take it out of daemon mode to see the message.
<kadams54> Apparently I need to reboot in order to use it :-\
<rick_h_> kadams54: reboot your machine or the maas controller?
<kadams54> Reboot my machine. It's a workaround for a bug in MacOS X 10.7
<kadams54> I also have an AWS env up and running that I'm currently using the debug a potential fix
<kadams54> So I'm going to hold off on rebooting for a bit.
<rick_h_> k
<kadams54> I was able to replicate the bug on relations with errors
<kadams54> hatch: It's a problem in findUnrelatedServices
<hatch> ahh 
<kadams54> uiteam: OK, general juju question here. I had juju-gui, wordpress, and mysql deployed in my AWS env. The JS code was throwing an uncaught exception when trying to process a wordpress loadbalancer relation that looked like it was meant to be connected to nginx.
<kadams54> But I had no nginx deployedâ¦ so why would the relation even exist?
<jcsackett> kadams54: to my knowledge, it shouldn't.
<jcsackett> is your env still up?
<kadams54> jcsackett: I'm switching juju-gui-source on it right now, so no, but it will be available again shortly.
<jcsackett> kadams54: that's alright, i want you to look at something via cli anyway, if you can.
<jcsackett> kadams54: juju status wordpress
<jcsackett> check the relations on that--then we'll know if the gui is processing something weirdly, or if your juju env has a weird thing.
<kadams54>     relations:
<kadams54>       db:
<kadams54>       - mysql
<kadams54>       loadbalancer:
<kadams54>       - wordpress
<kadams54> https://ec2-54-68-167-143.us-west-2.compute.amazonaws.com/services/:flags:/as/
<hatch> kadams54: I think wordpress has a peer relation
<kadams54> What's a peer relation? I've heard that term before, but never really understood what it was.
<hatch> well essentially it's a relation to something else installed in the same charm
<hatch> kadams54: they don't have lines anywhere because it's part of the same service
<kadams54> Ah, OK, that would make sense
<hatch> Peer relations are a different matter, in that peer relations are the mechanism by which service units share information internally. It's not unusual for peer service units to maintain convenient caches of distributed information in their own peer settings, and this inevitably involves generating settings keys at runtime.
<hatch> ^ kadams54
<hatch> from the docs
<hatch> I don't know how to properly use one, I just know what it is haha
<kadams54> uiteam: OK, https://github.com/juju/juju-gui/pull/657 needs reviews and QA to fix this bug.
<hatch> lol
<kadams54> It's a very small PR, but needs a real env for QA.
<hatch> kadams54: can you add a comment why it might not exist in the code :)
<jcsackett> huh, so peer relations are generated automatically? that's peculiar.
<kadams54> hatch: Done.
<hatch> kadams54: so when you real real env, would lxc work?
<kadams54> Yeah?
<kadams54> Shoot, now that I think about it, sandbox ought to have the same problem.
<kadams54> As long as you deploy a service that has a peer relationship.
<hatch> but I don't think it did
<hatch> I've used wordpress a lot....
<hatch> so is this actually the fix? hehe
<jcsackett> if it doesn't come up in sandbox or lxc, history says it's a timing issue.
<hatch> kadams54: I'm spinning up an lxc env to test this out
<kadams54> NOOOOOOOO!
<kadams54> Just kidding.
<hatch> lol
<hatch> maybe last bug?
 * hatch ducks
<hatch> lol
<hatch> haha
<hatch> hatch ducks
<hatch> quack quack
 * kadams54 suppresses the urge to punch ducks.
<hatch> kadams54: so I am getting an error in develop when even trying to use the gui because of a hook failure in mysql
<hatch> did you get the same bug?
<rick_h_> kadams54: hatch what's up? 
<hatch> so on lxc I deployed juju-gui wordpress and mysql via the cli
<hatch> switched to the guy and related wordpress and mysql
<hatch> now the gui fails with a hook error in utils
<hatch> (the mysql service failed on start)
<hatch> I am not sure why mysql failed on start....but I hope that someone else can reproduce this
<hatch> because I can't actually use the gui heh
<rick_h_> ok so this is something different than the show/hide thing?
<hatch> I can't even get that far
<hatch> the gui is unresponsive on load to the canvas
<rick_h_> heh, what did you break? :P
<hatch> I'll take a screenshot of the traceback 
<rick_h_> hatch: so this is even before using the develop branch
<hatch> this is using the local charm version
<hatch> this is because agent_state_data is undefined on utils.js:1418
<hatch> ^ kadams54 didn't you do something about agent_state_data resiliency recently?
<kadams54> Sure seems like I did, didn't I?
<kadams54> https://github.com/juju/juju-gui/pull/640
<kadams54> hatch: ^
<hatch> looks like we need to also add some here
<hatch> although I'd like to know why there is no agent_state_data though
<hatch> was that juju-core bug ever created?
<kadams54> Odd
<kadams54> You shouldn't be getting that error if you have the patch in that PR
<kadams54> Are you sure your local charm has the latest code, including that fix?
<kadams54> hatch: And no, the juju-core bug was not created
<kadams54> At least, not that I know of
<kadams54> uiteam: Jenkins merge builds seem to be hung. The current build's been going for 1 day and 1 hour.
<kadams54> http://ci.jujugui.org:8080/job/juju-gui-merge/782/
<hatch> kadams54: no the bug I'm seeing is not related to your branch/fix - it's in the relation line decoration 
<hatch> code
<hatch> kadams54: you can just kill the build
<hatch> although you may need to log into the box to then kill the node process
<kadams54> hatch: you said utils.js:1418, right?
<hatch> correct
<hatch> not in develop though
<hatch> in release
<kadams54> hatch: Yeah, that's the code I changed.
<hatch> ohh so develop has this fixed?
<kadams54> Yes.
<hatch> ohh ok cool heh I'll try swapping the branch
<kadams54> hatch: I've never gotten on the jenkins boxâ¦ not sure how?
<hatch> kadams54: ok you are correct develop does have it fixed :)
 * hatch shame
<kadams54> hatch: yay!
<hatch> lol
<hatch> kadams54: I have juju-gui wordpress-mysql
<hatch> if I highlight mysql then fade wordpress juju-gui shows up 
<hatch> wasn't this what your branch fixed?
<kadams54> Yes.
<kadams54> Looking to see if there's a regression.
<kadams54> Oh, ah ha
<kadams54> I did fix it
<kadams54> On the PR that had its merge build hang for a day.
<kadams54> So the fix still hasn't landed on develop
<kadams54> Grr.
<hatch> hmm ok - is that merge running now?
<kadams54> yes
<hatch> ok cool well once it's done and you update your pr can you ping me for the qa?
<kadams54> Once it lands successfully, I'll rebase it into the PR.
<kadams54> Yup
<hatch> my env is all set up for it now so it'll be quick
<kadams54> hatch: PR updated
<hatch> pulling down thx
<rick_h_> kadams54: hatch so once things land is the guimaas still setup?
<rick_h_> e.g. can we change the source to master and then back to develop and QA the exact same env?
<kadams54> rick_h_: Not sure I followâ¦
<rick_h_> kadams54: so taking the gui in guimaas and setteing the source tree back to stable right now
<kadams54> Yup
<rick_h_> kadams54: when we think a fix is landed, I'll update it back to develop and see if it works 
<kadams54> Yeah, sounds good.
<kadams54> Which reminds me, since I rebooted, I ought to be able to sshuttle in
<kadams54> Hurrah! I'm on the MAAS box!
<hatch> +1
<hatch> we should really sort the added services tokens
<hatch> they are always in a different order
<hatch> :)
<kadams54> uiteam: need one more (tiny) review on: https://github.com/juju/juju-gui/pull/657
<Makyo> Got it
<kadams54> Makyo: thanks!
<jcsackett> uiteam: i need two reviews, one QA on https://github.com/CanonicalLtd/blues_browser-charm/pull/13
<jcsackett> lxc env is fine for QA.
<kadams54> rick_h_: Branch is landed. Update guimaas at your convenience.
#juju-gui 2014-11-15
<rick_h_> kadams54: will do ty
<rick_h_> kadams54: <3 so much 
<kadams54> uiteam: On the off chance that anyone is still aroundâ¦ https://github.com/juju/juju-gui/pull/658 is ready for two reviews and QA.
#juju-gui 2014-11-16
<huwshimi> Morning
#juju-gui 2015-11-13
<stokachu> is there an api call i can utilize to query the solutions a particular charm is used in?
<stokachu> so i can pull bundle information
<rick_h_> stokachu: yes...sec
<rick_h_>     "bundles-containing",
<rick_h_> stokachu: https://github.com/juju/charmstore/blob/v4/docs/API.md look for bundles-containing
<stokachu> ah ok perfect
<rick_h_> stokachu: so like https://api.jujucharms.com/charmstore/v4/mysql/meta/any/?include=bundles-containing I think
<stokachu> so does that just pull my bundles?
<rick_h_> no, but i think there's a thing with versioning in that .../me is trying to recall
<rick_h_> stokachu: it's used to feed the "Used in X solutions" e.g. https://jujucharms.com/u/kubernetes/kubernetes
<rick_h_> stokachu: what charm are you looking for what bundles use it?
<stokachu> rick_h_: is this the format for a simple charm query https://api.jujucharms.com/v4/trusty/mysql
<stokachu> oh i see
<stokachu> https://api.jujucharms.com/v4/trusty/mysql/readme
#juju-gui 2016-11-14
<redir> morning juju-gui
<redir> There's an individual in juju-dev looking for some help with https://github.com/CanonicalLtd/jujucharms.com/issues/372
<redir> shall I send them your way?
#juju-gui 2016-11-17
<redir> is anyone doing anything on guimaas right now?
<jrwren> redir: well, it is down and we can't rebuild it right now, so we aren't really doing anything with it, other than lamenting it not working.
<redir> well I guess that explains why it isn't working for me either.
<redir> or 
<redir> I got a couple going
<redir> renamed them so it is obvious they are in use
<redir> please don't release them :)
