#juju-gui 2013-02-04
<bac> morning
<frankban> gary_poster: hi, do you have a minute?
<gary_poster> hey frankban.  Maybe 15 minutes from now ok?  can do sooner if needed
<frankban> gary_poster: 15 minutes are ok, thanks
<gary_poster> cool, will ping
<gary_poster> frankban, took longer than expected, sorry.  ready now in juju-ui
<frankban> gary_poster: joining
<bac> benji: second review done
<benji> thanks bac
<teknico> bac, what does this sentence of yours mean? "the wrapper should be goldenrod with maybe an accent wall"
<bac> teknico: :)
<bac> just a light-hearted reference to bike shedding
<teknico> oh, I see
<teknico> ok, what does it mean in literal tems then? :-)
<bac> goldenrod is an awful color from the 70s used in suburbia.  i think it is actually resurgent now
<bac> used in conjunction with an avacado colored dishwasher
<teknico> and an accent wall is one wall in a room which is of a different color than the other ones
<teknico> which is not something that I'm accustomed to :-)
<bac> yes, inexplicably.  i came home one day and found one wall in the living room was orange.  it eventually grew on me.
<gary_poster> bac bcsaller benji frankban goodspud hazmat Makyo teknico call in 2
<alejandraobregon> gary_poster: arosales: hazmat: hey guys... 
<alejandraobregon> goodspud is working on a scoping diagram for 13.04... I believe he's shared it
<alejandraobregon> goodspud and i were thinking it would be good to use our meeting to discuss it
<alejandraobregon> and clear up any areas that are hazy right now
<arosales> alejandraobregon: ok, I'll check mail. Should we follow up on this on the upcoming call in ~14 minutes?
<alejandraobregon> gary_poster: arosales: hazmat: What do you think
<alejandraobregon> arosales: that was my thinking.... i have to attend a tablet meeting... and thought would be useful to use that hour to further define the scope for 13.04 based on goodspud diagram...
<alejandraobregon> arosales: can be here for the first bit...
<alejandraobregon> arosales: gary_poster is there anything else we should cover at our meeting
<gary_poster> alejandraobregon, sorry on call.  that sounds good.  goodspud and I have a good handle on the immediate deliverables afaik, so if you want to touch base on that to know where we are that is fine, but I don't have concerns there.  All's good
<alejandraobregon> gary_poster: excellent! okay so i'll leave you in goodspud 's capable hands... he could use the hour to get clarity on a few things
<bcsaller> teknico: do you want to have that talk now or wait till matts up and about?
<teknico> bcsaller, let's do it now, thanks
<bcsaller> teknico: back in gui hangout
<goodspud> arosales, gary_poster, can't join the hangout "You are not allowed to join this hangout"
<gary_poster> goodspud, try using Canonical account?
<arosales> need canonical account
<bac> Makyo: i'm trying to replicate the drag problem on uistage and can't see the failure.  should it still fail there?
<gary_poster> yes bac
<gary_poster> lemme see if I can see it
<bac> i've never seen it so perhaps i'm doing it wrong
<gary_poster> bac I do not see it on uistage anymore either
<bac> gary_poster: ok.  i'll try locally
<gary_poster> bac ok
<Makyo> Not seeing it either.  Maybe bcsaller's refactor fixed it. Trying two browsers
<Makyo> Can't reproduce with two browsers locally.  Oh well! That's good, then.
<gary_poster> Hey goodspud do you have five minutes?  Literally, because I have to run :-)
<goodspud> gary_poster, certainly do
<goodspud> hangout?
<gary_poster> thanks goodspud , yeah
<gary_poster> juju-ui
<teknico> Makyo, time for a quick hangout?
<Makyo> teknico, sure.
<teknico> uhm, I'm trying to add you to a hangout, but it tries to call you, I don't know why :-)
<teknico> Makyo, ^^
<teknico> Makyo, https://plus.google.com/hangouts/_/02bb45411739e441fe107c9f66e2a8cc36ba4ba7
<Makyo> teknico, I'm there, but I don't see you.
<benji> teknico: revised branch up at https://codereview.appspot.com/7248050
<teknico> benji, looking
<teknico> benji, for some reason when looking at the patch set 2 of your branch, I cannot see inline comments anymore
<teknico> I wonder why, it makes things cumbersome
<benji> that's a good question; I think I have had that problem before. I have no idea what causes it.
<bac> Makyo: second review done
<Makyo> bac, thanks.  Will play around with the branch some more and see if it's needed anymore.  If nothing else, I can turn it into a get-rid-of-magic-numbers branch.
<teknico> benji, approved, all comments in the reply, not inline
<teknico> benji, I'll try to tone down the bikeshedding :-)
<bac> Makyo: ugh, look at this render in FF on os x.  seems to be a newish regression.  https://docs.google.com/a/canonical.com/file/d/0B4pGCY-5QO19d0VtT0l4NHNxMk0/edit?usp=sharing
<Makyo> bac, lunch, will be back in a few to get to it.
<bac> no rush
<benji> thanks, teknico; looking now
<gary_poster> bac, interestingly and somewhat unhappily, FF on Quantal does not have that problem :-/
<bac> gary_poster: yeah
<bac> gary_poster: this is ff 18.0.1, fwis
<bac> fwiw
<gary_poster> bac also 18.0.1
<gary_poster> (on ubuntu I mean)
<bac> gotcha
 * bac -> dentist
<gary_poster> benji, thank you for the CI progress.  two questions.  first is to please send the group an email about what needs to happen next.  Are we simply waiting on Diogo to set up something in Jenkins, or do we need more work on our side before that can happen?  I'm happy to have a call and be the scribe if that would be a help.  Second is from the review.  bac asked you in review why you used the python-shelltoolbox branch
<gary_poster>  rather than using the packaged version (which presumably means specifying in the HACKING document that the deb package should be installed).  You replied that this was a mistake you planned to change ("Because I was supposed to change that before proposing the branch.  Fixed.") but the Makefile in trunk still looks the same.  Actually...he also asks whether selenium should be a dependency of test-misc, and you say y
<gary_poster> es, but everything looks the same there too.  Do you know what is going on with those?  If so, I'm curious, and if not...I'm curious. :-)
<gary_poster> "I'm happy to have a call and be the scribe if that would be a help." I mean you and I could have a call, and I could write down what you tell me is next, and send the email.
<benji> gary_poster: re. python-shelltoolbox; I misread his statement to be about selenium (i.e., not installing from a tar in archives/; which is what I changed)
<gary_poster> benji, ah!
<benji> it is better in my estimation to require a bzr branch vs. a deb install but I can do otherwise if wanted
<gary_poster> why benji?  that is shared across the system, which has limitations, but this package changes little, and we have quite a bit of precedent
<benji> automation
<benji> maybe putting package installs in the Make would be good middle path
<benji> s/Make/Makefile/
<gary_poster> we have charm automation for this, and shell toolbox might provide, but not sure
<benji> perhaps a card to make "make" make all that needs to be made (removing some of the prose in HACKING)
<benji> oh! another reason: the tests need a nice, new version of the selenium package which I don't think is available
<gary_poster> benji, remember we are talking about python-shelltoolbox not selenium :-)
<gary_poster> benji, for now would suggest putting python-shelltoolbox in HACKING and removing virtualenv for that.  we use virtualenv where we have to but generally prefer packages in this project atm.  I guess we could have the Makefile do sudo
<gary_poster> Then we could make the card as you describe
<gary_poster> I'm ok with doing this myself benji
<benji> right, but the code that is run needs selenium... hmm, but I guess that is technically a non-sequiter (sp?) because although the "driver" is a Python script and the tests are too, we can run one with the system python and the other with our virtualenv 
<gary_poster> but want to check you are ok with plan. Prefer better than "it doesn't kill kittens" but might take it :-P I think we have a precedent for preferring packages here.
<gary_poster> right
<gary_poster> ah and bin/test-charm depends on selenium now
<gary_poster> ...mm, trying to follow that through...
<benji> I really think all this would be better done with buildout; we are fast approaching a time where we will be doing a lot of work that buildout makes easy (making test runners, building scripts, managing package installation)
<gary_poster> Maybe.  Not very sure of that yet, but you've thought of it more than I.  benji, I would like to get a handle on what needs to be done next.  Do you want to do that verbally, with me as scribe, and then I can let you get back to what you were doing; or do you want to write it up?
<benji> gary_poster: I suspect the results will be more comprehensive if we talk it out.
<gary_poster> cool benji
<benji> gary_poster: I have stormed the gates of juju-ui
<hazmat> benji, i think the door was open ;-)
<benji> heh
#juju-gui 2013-02-05
<benji> gary_poster: did you see the message from StevenK (indirectly) about bug 1112799?
<gary_poster> thanks for helping StevenK benji
<_mup_> Bug #1112799: Uploading a release to stable is broken <juju-gui:Incomplete> < https://launchpad.net/bugs/1112799 >
<gary_poster> :-)
<gary_poster> yes
<benji> heh
<benji> the change that caused the problem is here: http://paste.ubuntu.com/1612461/
<gary_poster> I wonder why my upload yesterday to the trunk series worked
<benji> I /think/ the problem they were trying to solve is that some browsers send UTF-8 encoded text without specifying so in the request headers.
<gary_poster> oof yeah. that's not a good change for us
<gary_poster> right
<gary_poster> and who cares about binary blobs :-)
<benji> they reverted the change, thats why it started working again
<gary_poster> gotcha
<benji> heh
<benji> the log says "moo", no wait, the log says that they were trying to fix https://bugs.launchpad.net/launchpad/+bug/897053
<_mup_> Bug #897053: apport generated urls can trigger UnicodeDecodeError <oops> <qa-ok> <Launchpad itself:Fix Released by stevenk> < https://launchpad.net/bugs/897053 >
<gary_poster> ah ok
<gary_poster> Martin Pool's presentation is really good.  read 2/3 of it earlier this morning
<gary_poster> https://docs.google.com/presentation/d/1awg1CHM1w128iOBp_JOxE2DgHfywBeyjDe2bkx1vfVQ/edit#slide=id.p
<gary_poster> Some of it touches on topics we've discussed lately (tested fakes)
<benji> it seems to me that the right place to introduce this sort of guessing (if we really must) would be the text widget
 * benji gets some coffee.
<gary_poster> yeah
<therve> gary_poster, as it turns out, wsgi doesn't support %2F. But we can encode things on our end I think
<gary_poster> therve, wow!  I'll try to file that away.  Thanks for investigating further.  Glad you encode further.  Double encoding? :-P %252F (saw somebody do that when I did my quick search)
<therve> gary_poster, yeah something like that.
<gary_poster> k cool
<therve> I'm not sure there is anything to file. I've seen people complaining, but there is just not an obvious solution apparently
<teknico_> frickin' telecom "technicians", instead of fixing my line they broke the neighbor's one, leaving me stranded :-P
<gary_poster> bcsaller, Makyo, hi.  how is landing your reviewed branches going?  Over WIP limit: important to get those through the queue.
<bcsaller> gary_poster: mine was merged yesterday
<gary_poster> ah cool bcsaller thanks.
<Makyo> gary_poster, no answer from others on whether or not my branch is needed anymore.  If not, should I just trash the card?
<gary_poster> Makyo, it isn't a nice improvement anyway?
 * gary_poster goes to look at it
<Makyo> gary_poster, No, not really, unless we change history and call it 'name magic numbers', in which case, it's a four line change.
<gary_poster> Makyo, ack.  updateLinkEndpoints docstring in relation.js is fixed in your branch too.  I will disconnect the bug from your card, and then you can quickly land just the trivial but still valuable bits and move on?
<Makyo> gary_poster, sure, sounds good.  Will make a new branch.
<gary_poster> thank you
<gary_poster> card changed to reflect new focus, bug marked as fixed, Makyo
<Makyo> gary_poster, thanks
<gary_poster> bac bcsaller benji frankban goodspud hazmat Makyo teknico call in 2 *in new Canonical-account-only jujugui room*
<goodspud> gary_poster, could you email me the link please 
<Makyo> bcsaller, Can I get a quick +/- on https://codereview.appspot.com/7311046 since you have to deal with this code most?
<bcsaller> gary_poster: having trouble joining, logged into g+ with canonical account but its still rejecting me on the link
<gary_poster> benji bcsaller hazmat starting.  bcsaller try starting from calendar daily standup link?
 * benji wonders how to get the new hangout to use the right account
<hazmat> bcsaller, i opened incogonito and logged back in
<hazmat> the multi account auth doesn't seem to like these hangouts
<hazmat> benji, http://tinyurl.com/jujugui
<benji> "You are not allowed to join this hangout."
<gary_poster> My evil plan is now complete :-P
<gary_poster> Try link from calendar benji
<gary_poster> or incognito like Kapil said
<benji> link from calendar doesn't work
<gary_poster> benji incognito worked for you?
<benji> gary_poster: yep; I guess I'll have to do that and log in every time
<benji> not a big deal, just slightly annoying
<gary_poster> I find that if Canonical is your first logged-in Google identity it works for me
 * bac must resist the urge to eat lunch immediately after the call since it is an hour early
<benji> and if Canonical is my first logged-in Google identity then the rest of the Google world breaks for me :)
<gary_poster> benji, ack.  If this doesn't let us break the 10-participant barrier (we will be 10 people by default once Jeff joins, so that would mean other people like Ale, Jovan, Antonio and so on would have trouble joining) I'm happy to switch back
<benji> yeah, if it has no advantages we should go back, but breaking the 10-participant barrier is a biggie
<frankban> could anyone make the second review for https://codereview.appspot.com/7306045? thanks!
<gary_poster> guihelp ^^^
 * gary_poster goes to agile meeting lunch.  back in 1.5 hours
<teknico> frankban, I'll do it
<frankban> teknico: thanks
<teknico> frankban, review done, nice running tests remotely :-)
<Makyo> benji, ping re: #1091273
<_mup_> Bug #1091273: Style can be applied with different orderings resulting in slight visual differences <juju-gui:Triaged> < https://launchpad.net/bugs/1091273 >
<benji> Makyo: pong
<gary_poster> benji qa lab machines cannot access outside world other than local deb repos and LP, so we will need to change the test script build machines in the way that we discussed
<gary_poster> I will write up
<benji> gary_poster: interesting; sounds good
<Makyo> benji, it looks like we switched to a 'build-shared' target for prod, debug, and devel at some point, and there's now no difference between build-prod/index.html and app/index.html or the files they include.  Suspecting it's no longer an issue, but want to make sure.
<benji> Makyo: ah; yeah it may be a non-issue now.  An easy way to verify would be to take a screenshot of each and compare (flip-book style).
<Makyo> benji, Alright, will do.
<Makyo> benji, verified no difference.  gary_poster, what to do with the card?
<benji> cool
<gary_poster> Makyo, move to done Done, close card as fix released
<gary_poster> I mean close bug
<Makyo> gary_poster, cool, thanks :)
<gary_poster> :-)
 * benji fights with the linter.
 * benji is kicked by the linter and falls out a window.
 * benji falls on his horse which gallops away.
 * benji lives to fight another day.
<benji> review of source maps branch at https://codereview.appspot.com/7305047
<Makyo> benji, taking a look, but also have a question.
 * benji waits in rapt anticipation.
<Makyo> HAd to grab the bug ID, sorry.  Would this maybe help with #1116320?  It seems like the problem is using the un-minified version of YUI, which loads the event stuff from the yahooapis site.
<_mup_> Bug #1116320: External resources still loaded by test-debug  <juju-gui:Triaged> < https://launchpad.net/bugs/1116320 >
<Makyo> benji, ^^^
<benji> hmm, looking
<benji> Makyo: nope, I don't think it will help that.  The using of un-minified versions is only done in the context of minifying it ourselves in the prod flavor.  The debug flavor is the same as it ever was.
<Makyo> benji, Alright, thanks.  Figured I'd check :)
<benji> :)
<benji> gary_poster: that presentation from Martin was good.  The bit about Mocks living beside the thing they mock got me thinking and lead to this paper: http://jmock.org/oopsla2004.pdf -- which I have not entirely digested but seems important
<gary_poster> benji, the abstract was too abstract. :-P I will look at it later.  thanks for link
<benji> heh
<benji> Makyo: thanks for the review, you should tag the card
<Makyo> benji, Good catch, thank you.
<benji> if anyone else would enjoy a review, it is there for the taking
#juju-gui 2013-02-06
<frankban> hi benji: could you please review https://codereview.appspot.com/7299057 ? quick one
<benji> frankban: sure
<frankban> benji: thanks
 * frankban lunches
<benji> frankban: looks good
<gary_poster> benji, once you get 1110823 landed please get me the jenkins username I emailed everyone about yesterday
<gary_poster> bcsaller same for you
<gary_poster> and hi btw :-D
<benji> gary_poster: sure
<gary_poster> thanks
<benji> yow, I decrypeded the GPG message and I got a MIME document with a base64 encoded tgz; this is like some sort of geek obsticle course :)
<gary_poster> heh
<gary_poster> thunderbird handled that part transparently fwiw
<gary_poster> thunderbird + enigmail that is
<benji> "VERIFY ERROR: depth=1, error=self signed certificate in certificate chain"
<bac> funny mine wasn't double tarred like gary's
<gary_poster> good
<gary_poster> So far I've waited 15 minutes for juju status to return after a canonistack bootstrap :-/
<benji> gary_poster: user name: "benji"
<gary_poster> thank you benji
<benji> heh, I like the weather metaphore
<benji> np
<gary_poster> hey hazmat, I'm trying to get canonistack working with juju, both for general good practice and to be able to dupe what the CI is going to do.  I followed the wiki instructions for juju+canonistack AFAIK, and I can bootstrap, but juju status still doesn't return , 25+ minutes ago.  output from juju --verbose status isas follows: http://pastebin.ubuntu.com/1616631/ .  Does that suggest any problem/remediation to you?
<gary_poster> that ssh to 10.55.60.231 seems to not be working out so well...
<hazmat> gary_poster, can you log into the machine with ssh
<hazmat> gary_poster, which region and which provider?
<hazmat> one of the regions requires 'openstack' and one 'openstack_s3' 
<hazmat> gary_poster, i think 02 is swift, and 01 is s3
<gary_poster> hazmat, openstack provider, per https://wiki.canonical.com/InformationInfrastructure/IS/CanonicalOpenstack/QuickStart .  Using default region, which I think is 01
<hazmat> hmmm.. maybe that's a red herring
<gary_poster> ssh timed out
<gary_poster> ah-ha, matsubara improved my .ssh/config.  looks like it might work now...
<gary_poster> yes, all's good.  Will include follow-up in email
<hazmat> gary_poster, cool
<hazmat> i just updated the quick start doc to remove some extraneous config bits
<gary_poster> hazmat, should I add the snippet I gave in the email for step 4 to that quick start?  Maybe recent ssh instructions elsewhere include that, but iwbni the quick start were self-sufficient, I think
<gary_poster> Specifically, I also needed this:
<gary_poster> Host 10.55.58.* 10.55.60.* 10.55.62.* 10.55.63.* *.canonistack *.canonistack2
<gary_poster>     ProxyCommand ssh chinstrap.canonical.com nc -q0 %h %p
<gary_poster> I only had that for 10.55.60.* before
<hazmat> gary_poster, sounds good to me
<gary_poster> k will do hazmat
<bcsaller> gary_poster: do you have some time for a call soon?
<gary_poster> sure bcsaller.  9:55 or 10:00 ok?
<bcsaller> gary_poster: yeah, ping me when ready
<gary_poster> will do
<gary_poster> bcsaller, jujugui is open
<gary_poster> bac benji frankban goodspud hazmat Makyo teknico call in 1
<gary_poster> hatch hi :-)\
<hatch> Ahoy!
<benji> guihelp: has anyone seen this error when running "make test-prod"? Error: extend failed, verify dependencies (http://localhost:8084/juju-ui/assets/all-yui.js:1
<benji> the tests pass when run in the browser
<Makyo> teknico, Anything I can do to help?
<teknico> Makyo, yes, thanks, call?
<Makyo> teknico, Sure.  The old juju-ui hangout is free.
<Makyo> https://plus.google.com/hangouts/_/409819056ea1551523432ac63f4df4a6feaa5922?hl=en-US
<benji> darn, my test failures are due to some change made during review; traking it down now
<dweaver> Question: How do you use juju-gui with local charms repository.  I can see in assets/config.js: charm_store_url: 'https://jujucharms.com/', Can this be set to a local file location like the juju option --repository or is there another way to support local charm repos?
<dweaver> Any help will be appreciated :)
<Makyo> guihelp, ^^^
<Makyo> dweaver, I don't believe there's current support for a local repository, but I've not tried the method you've suggested.
<hazmat> dweaver, at the moment its not supported
<hazmat> dweaver, the gui will work with local charms once their deployed
<bcsaller> (via the cli)
<hazmat> but we don't have a local program that you can run that will give the endpoint interface that the gui needs at the moment
<hazmat> its an interesting discussion point.. at the moment if the gui is deployed over ssl most browsers will ignore sub resources..
<hazmat> that aren't ssl.. the exception seems to be websockets..
<hazmat> but its unclear if thats just a transient quirk.. if its not we can do local charms over websocket.. else.. i'm not sure what options there are
<hazmat> since/because the local program can't present a valid cert for itself running on localhost..
<dweaver> OK, thanks, that answers my query, it is a query coming from HP, so it is likely to be a future requirement, so probably worth thinking about how we're going to achieve it.
<dweaver> eventually, anyway :)
<dweaver> hazmat++
<dweaver> thanks
<hazmat> np... so nutshell local charm search no.. manipulation/introspection of services deployed with local charms are fully supported
<gary_poster> hazmat, for one story, charm might be hook point for something we could do.  You tell the charm about your local server, and it proxies it for you.  We could have it served from /local/* .  Similar proxying could be done in other stories.
<hazmat> gary_poster, local host differs between the proxy and the client..
<hazmat> and nat/firewall prevent remote_ip usage
<gary_poster> hazmat, yes, for this to work, charm would have to be able reach your machine
<gary_poster> so limited value, but perhaps some
<hazmat> too many cases where it won't work to be a solution.
<gary_poster> fair enough
<hazmat> i think just pushing forward with the websocket gives us a possible universal answer.
<hazmat> but it would be good to verify/research why this browser behavior exists.
<hazmat> ie oversight or reasoned
<hazmat> sounds like recent firefox may not allow it.. from some quick googling..
<hazmat> gary_poster, alternatively we have the user separately accept the websocket cert from localhost
<hazmat> in their browser as a crappy but nesc requirement
<gary_poster> yeah
<hazmat> and documented
<hazmat> and then we can avoid the websocket and just make it  a  parallel impl 
<hazmat> of the existing search rest backend
<gary_poster> hazmat, ack, may be best we can do.  Although, for big companies as mentioned above, it may not even be a big deal to put it behind a real cert.
<gary_poster> sounds a bit like other plans too though
<hazmat> bcsaller, would you be up for sanity checking a mind twisted txzk branch ?
<hazmat> dweaver, gary_poster, for them (big) i have other plans.
<bcsaller> hazmat: sure
<gary_poster> hazmat, understood
<dweaver> hazmat, sounds exciting!
<hazmat> hatch, welcome on board!
<hatch> thanks :)
<hatch> Hi everyone
<hatch> My name is Jeff and I hate long walks on the beach
<hatch> :D
<hazmat> :-)
<gary_poster> jujugui, ^^^ :-)
<Makyo> hatch, o/
<bac> hi hatch
<bcsaller> hazmat: send me a link to what you want reviewed when you're ready
<benji> hi hatch
<hatch> Hey, looking forward to getting started
<hazmat> bcsaller, its got some debug junk in it.. which i'm cleaning up.. but ignoring those the rest is ready https://codereview.appspot.com/7307051/
<hazmat> hmm.. that diff is wierd..
<hazmat> bcsaller, not sure why reitveld is getting the diff wrong
<bcsaller> hazmat: too much?
<hazmat> bcsaller, yeah.. way too much
<bcsaller> hazmat: good, it was looking like quite the branch
<hazmat> odd. even lp gets it wrong.. 
<hazmat> trunk shows the managed.py but both are treating it as a new file
<hazmat> in the diffs (reitveld and lp)
<bcsaller> hazmat: if you don't get it working in the next few minutes I can try to generate it locally at the cost of some of the inline review comments
<hazmat> bcsaller, i'm just going to go back and work on yanking the debug bits for now.. maybe just hold till tomorrow till i can get this clean
<bcsaller> hazmat: thanks
<hazmat> i was hoping to get it in for some of the drill work that people are doing.. but they seem to have other concerns atm
<benji> gary_poster: do we want to put some kind of user or branch details in the sauce labs jobs?  Like say user name and branch nick?
<gary_poster> benji sounds nice
<benji> k, it'll be easy to do
<bac> gary_poster: the approach i thought looked promising didn't actually work.  i'm talking with curtis now to see if he has any brilliant thoughts
<gary_poster> good idea bac
<benji> darn, grabbing the branch nick doesn't make any sense because the tests don't know that they are actually running against that branch
<benji> gary_poster (and all other reviewers): https://codereview.appspot.com/7300054
<gary_poster> on call
<gary_poster> benji land with changes
<benji> thanks
<benji> "converting browser tests into runes" -- lol
<gary_poster> :-)
<gary_poster> bcsaller, am I right that there's no juju facility to somehow automatically associate elastic IPs, a la https://wiki.canonical.com/InformationInfrastructure/IS/CanonicalOpenstack#Obtaining_a_Public_IP_Address?  If not will simply suggest we script with the euca-* commands
<gary_poster> (this is for automating CI using Juju, Jenkins, and Canonistack)
<hazmat> gary_poster, can i grab you for some gui charm debugging?
<bcsaller> gary_poster: I don't think the providers do anything special for elastic IPs. You get the public one provided but things like Amazon's elastic ips are provider specific and I don't think we had a general facility for that. I think associating an elastic IP changes the public address though  
<gary_poster> hazmat, sure.
<gary_poster> bcsaller, cool, thank you
<hazmat> gary_poster, for openstack there is a facility for using an elastic ip
<hazmat> use-floating-ips
<hazmat> but it enables it everywhere
<hazmat> and there are not that many
<hazmat> on an account
<gary_poster> hazmat enabled even for the bootstrap?
<Makyo> I remember running into this when I was setting up canonistack.  Was keeping the websocket address from being set properly, correct?
<hazmat> gary_poster, yes
<gary_poster> hazmat, ok thanks.  I'm in jujugui if you want to meet there, or can move to juju-ui
<hazmat> gary_poster, i'm trying to setup something remote with the drill team.. i'll ping again when its happening
<gary_poster> Makyo, ah, I bet you are right, but I was simply trying to make it so that sauce labs can even see the charm at all
<gary_poster> in an automated way
<Makyo> gary_poster, ah, yeah, definitely.  I found that even with a public IP, though, the 'public  address' as reported to juju was still the canonistack address.
<gary_poster> hazmat ok
<gary_poster> Makyo, :-( .  Did you use use-floating-ips or the euca approach?
<Makyo> gary_poster, euca.
<gary_poster> ok
<Makyo> gary_poster, so maybe floating IPs might help there.
<gary_poster> Maybe the other approach will work better.  Will try both.  Yeah, thanks for warning
<hazmat> we could slim down charm deb installs considerably
<hazmat> by considering what the active config options are
<hazmat> ie. if stable don't most of the pkgs, if not staging don't need zk, etc
<hazmat> we should also move the download off launchpad and onto a cdn
<hazmat> its quite slow to download from lp
#juju-gui 2013-02-07
<hazmat> bcsaller, final branch is up for review, still haven't been able to get the review diff right.. it looks fine by hand
<hazmat> bcsaller, revno 52 has the complete diff, all the other revs are on trunk.. 
<bcsaller> hazmat: did a review on lp for you
<hazmat> bcsaller, thanks for the review.. commented back. surprised your coverage report didn't pickup the test, was it only being run against a particular test module instead of the full suite?
<bcsaller> hazmat: it was 'make coverage' 
<hazmat> odd
<hazmat> there's a test that explicitly checks for the backoff content in the logs in test_session
<hazmat> ie. test_managed_client_backoff
<bcsaller> your version of coverage shows it being trigged in manage then? for me managed only shows 83% but most of that is missing calls to error logging
<hazmat> coverage locally reports its covered
<hazmat> for the package i have 94% for the managed module 89% (mostly exception handling)
<bcsaller> hmm, maybe I have an old coverage package
<hazmat> well for the test to pass it has to hit those lines, which is what's od
<hazmat> odd
<bcsaller> hazmat: I'll look into it, I'm guess its something with my environment
<gary_poster> teknico, feeling any better about the bug today?  If not, why don't you ask to pair with Ben or Matt this morning?
<teknico> gary_poster, having lunch now, but maybe a quick call?
<gary_poster> sure teknico.  I'm free for 53 minutes, then we have our regular call in another hour.  Can do it whenever you like within my available time
<teknico> gary_poster, I'm in jujugui
<benji> gary_poster: when you get a second I would like to discuss the UX of the browser compatability warning
<gary_poster> ack benji
<bac> guihelp - anyone free to review my css branch?
<hatch> good morning
<benji> morning, hatch 
<gary_poster> morning
<gary_poster> bac, on it
<bac> gary_poster: cool.  won't take long
<gary_poster> cool
<bac> thanks gary_poster
<gary_poster> welcome
<bac> gary_poster: here is a bit of a rambling explanation: http://dalelane.co.uk/blog/?p=2222
<bac> the reason i suggest we add this is it keeps IE from behaving differently when it sees the server is on the same LAN.  seems like a recipe for disaster to have it work one way in development and then another when deployed.
<gary_poster> bac +1.  Just add a link to the blog post maybe?  Not sure
<gary_poster> thank you
<bac> +1
 * bac looks for something more authoritative
<Makyo> bcsaller_, benji frankban gary_poster call now?
<gary_poster> baf
<gary_poster> sorry
<gary_poster> thanks
<gary_poster>  benji frankban hazmat like Makyo said :-)
<gary_poster> goodspud too :-)
<frankban> guihelp: is the "failfast" behavior of the GUI test suite a bug or something we precisely decided?
<gary_poster> frankban, bug I think
<frankban> gary_poster: ok thanks
<bcsaller_> frankban: I think there is a 'bail' flag in mocha that is being set
<bcsaller_> bcsaller_: I suspect we can pass bail: false to the mocha init
<bcsaller_> talking to myself now, great
<teknico> bcsaller_, that's ok, as long as you listen to yourself
<bcsaller_> all about good manners 
<frankban> :-) bcsaller_ : it works
<frankban> gary_poster, bcsaller_: do we want failfast? otherwise I'll add "bail: false" in my branch.
<gary_poster> :-) I vote for not failfast, but don't feel strongly about it frankban
<bcsaller_> frankban: I don't mind fail fast on the cli tests as we are mostly doing a sanity check at that point, I do the actual debugging in the browser
<bcsaller_> but I don't feel strongly either, usually with the cli tests though a single failure would prevent a lbox submit 
<gary_poster> mm, lbox is a good point
<hazmat> guihelp re cs:precise/juju-gui anyone know why it would result in  2013-02-07 11:10:16,812: hook.output@INFO: E: Unable to locate package python-charmhelpers
<gary_poster> hazmat, that used to happen if person was not using juju from ppa.  supposed to be fixed now, because we add ppa at start anyway
<hatch> is `guihelp` a string that I should set to ding in my chat?
<hazmat> yup
<hazmat> its a group broadcast
<gary_poster> hatch, yes, guihelp (among ourselves) and jujugui (on #juju channel for user help)
<hatch> that's a very smart idea :D
<hazmat> gary_poster, is that fixed in the ~charmers version only the ~juju-gui version?
<hazmat> s/only/or only
<gary_poster> hazmat, ~charmers, pretty sure.  verifying.
<teknico> hatch, hi, you might also want to configure your IRC client so that it shows your first name and last name too
<gary_poster> hazmat, ~charmers.  bootstrap_utils.install_extra_repositories('ppa:juju/pkgs') in install hook
<hatch> teknico: in my whois information?
<teknico> hatch, yep
<hatch> oh cmon I need some kind of anonymity ;)
<gary_poster> frankban, you happen to have any experience with what hazmat mentioned above in charm?  I don't see why/how it would happen
<teknico> hatch, do you? :-)
<frankban> gary_poster: hum... no, looking at the ~charmers revision
<gary_poster> frankban, http://bazaar.launchpad.net/~charmers/charms/precise/juju-gui/trunk/view/head:/hooks/install fwiw
<gary_poster> hazmat, are they running on precise?
<gary_poster> hazmat, or more pertinently, are they trying to run on raring.  We only test on precise.  the juju ppa does not have charm-tools for raring
<gary_poster> python-charmhelpers are in the charm-tools version supplied by both precise and quantal
<hazmat> gary_poster, its all precise
<hazmat> gary_poster, the problem is actually ppa add because its a proxy environment
<hazmat> the add apt repo ends up adding junk the apt repo
<gary_poster> ah :-(
<frankban> :-/
<hazmat> after that it fails because adding nodejs and we don't have a key for it..
<hazmat> nodejs ppa
<hazmat> imo the charm shouldn't be downloading things it doesn't need for it current configuration
<hazmat> ie. i'm using a release i don't need nodejs/imagemagick/etc.. i'm not using staging mode.. i don't need java/zookeeper
<gary_poster> hazmat, added bug for that yesterday on your comment then.  triaged as low given that it was nice to have, but put it on kanban as slack task.  if this is blocker for important things then we can reprioritize.
<hazmat> its a blocker for important things.. but the timeline is tight.. 
<hazmat> i might just hack do a hack for it
<hazmat> sadly lacking access to fix directly
<gary_poster> hazmat, right.  is this a drop everything?  The change would be risky IMO
<gary_poster> you could hack and put it in your own branch?
<hazmat> gary_poster, yeah.. or just pass them to the hook
<gary_poster> risky only in the sense that it would need to be tested.  we would have to move downloading prerequisites into config-changed
<hazmat> gary_poster, understood, i'm testing a hack fix now (just commenting out all the unesc pkgs)
<gary_poster> cool, sounds good
<frankban> Makyo: quick hangout?
<Makyo> frankban, sure.
<frankban> Makyo: http://tinyurl.com/see-emily-code
<Makyo> frankban, There.
<hazmat> odd the gui deploys and gets to started (no hook errors) without the extra packages but it doesn't actual run.. the nginx config gets odd
 * benji tweaks the unsupported browser wording.  It now reads "Your browser is bad and you should feel bad."
<frankban> hazmat: what oddities are you seeing?
<teknico> benji, is "now" before or after the tweaks? :-)
<benji> heh
<benji> we should replace all of our UI elements with memes
<hazmat> frankban, nginx is running but not serving traffic.. all the pieces look like there in place but i can hit the front end webserver (its exposed)
<hazmat> ie. api server running, files on disk
<frankban> hazmat: any error in /var/log/upstart/juju*?
<hazmat> frankban, no.. afaics the only issue is the nginx config
<hazmat> the hooks all run to completion without error
<hazmat> nginx config : http://paste.ubuntu.com/1621578/ charm log: http://paste.ubuntu.com/1621582/
<frankban> hazmat: is "gui" the name of the charm you deployed?
<hazmat> frankban, its the name of the service charm
<hazmat> hmm.. i deployed ~juju-gui's charm version
<hazmat> with this diff http://paste.ubuntu.com/1621609/
<hazmat> i meant to deploy the ~charmers version.. i'll retry with that to verify 
<frankban> hazmat: aha! ppa:juju-gui/ppa is required so that the ssl-enabled haproxy is installed, not the precise one
<hazmat> frankban, gotcha.. that's not in the ~charmers version yet right?
<frankban> hazmat: right
<hazmat> jovan2, the new gui vision looks much improved
<jovan2> hazmat glad you like it
<Makyo> >:/
<gary_poster> Makyo, ?
<Makyo> gary_poster, Firefox and Flash problems.
<gary_poster> gotcha
<gary_poster> bac you available to review Matt's branch?  When that lands I can move some more of the CI Jenkins stuff forward
<bac> gary_poster: i can.  trying to get that hatch patch to work
<hatch> bac - I've never actually tested that code so I would be interested to hear your results :)
<bac> hatch: not good so far
<bac> i expect the ie10 class to be added to <html> but it isn't
<hatch> hmm is the js executing?
<bac> not sure.
<bac> not too adept at using the ie tools
<hatch> inside the script tags console.log('it works!');
<gary_poster> thank you bac
<hatch> I need to close some chrome tabs (I'm out of ram haha) and then I can boot up a Win8 VM if you like
<bac> hatch: cool.  i'm doing a review now but will be back at it in a bit
<bac> Makyo: done
<Makyo> bac, thanks
<bac> hatch: got it to work.
<hatch> oh excellent - what was the issue?
<bac> hatch: there was a typo in the code i copied from you.  missing a closing > before script.  no biggie.
<hatch> oh woops I should fix that in the gist
<hatch> thanks
<hatch> bac: I may be doing this review this wrong but I think you forgot the console.log() in the html ;)
<bac> ergh, probably
<bac> thanks for the catch
<hatch> np and I updated the gist with the missing > :)
<bac> having trouble submitting my changes due to lbox.check
<bac> and then it worked
#juju-gui 2013-02-08
<gary_poster> frankban, land as is.  Really nice.
<frankban> gary_poster: cool thanks!
<gary_poster> :-)
<gary_poster> hazmat, zero rush, but you might be interested in double-checking and commenting on bug 1119412 at some point.
<_mup_> Bug #1119412: charm has difficulties when run behind a firewall <juju-gui:Triaged> < https://launchpad.net/bugs/1119412 >
<benji> frankban: did I miss something?  I was reviewing bug-1117554-gui-tests-in-browser and it has now been merged
<frankban> benji: oh, sorry, didn't notice that and merged after 2 reviews. please complete yours if you want to, I'll create another card and fix things if required
<benji> frankban: I don't think it's your fault.  I just want to know why we duplicated the effort.  When I tagged the card in review there was only one other name on it, now there are three.
<benji> race condition perhaps?  
<frankban> benji: heh, maybe...
<teknico> benji, my fault, I forgot to tag myself when I started reviewing that branch
<teknico> sorry
<benji> well, at least it isn't a bug in software we don't control; expect a wetware patch in your next update
<teknico> wetware is like software in that way, patching never ends :-)
<benji> too true :)
<benji> grr, I broke the sprite generation somehow
<gary_poster> bac bcsaller benji frankban goodspud hazmat Makyo teknico call in 2
<gary_poster> frankban, hazmat starting without you. arosales, 10 or 15 minute warning for tinyurl.com/jujugui
<arosales> gary_poster: roger
<hatch> in the HACKING file it requires a package called `lbox` is it possible the package has been renamed since this doc was written?
<hatch> I am not having any luck finding it
<benji> hatch: that may be in a PPA; if so you'll have to add the PPA first
<therve> probably ppa:gophers/go
<hatch> ppa:gphers/go
<hatch> oops you beat me
<hatch> heh
<benji> hatch: please improve the docs with your new-found knowledge
<hatch> oh improvements are going to be made
<hatch> once I figure out how the heck bazaar works ;)
<benji> :)
<hatch> up and running....wow that was pretty painless
<benji> cool
<teknico> this goes over all the source files, it would be nice to get it landed soon, or it'll be conflict hell: :-) https://codereview.appspot.com/7312067
<teknico> guihelp ;-) ^^
<gary_poster> on it
<teknico> thanks
<bac> me too
<bcsaller> aside from its size it looks like a trivial, but a welcome one
<teknico> if by "trivial" you mean "it doesn't touch executing code", then yes
<bcsaller> thats all I meant, its a great branch
<gary_poster> teknico, land as is.  great.  was the branch useful as code overview as well?
<teknico> gary_poster, yes, I finally got to look at all the code, at least :-)
<gary_poster> :-) cool
<bac> teknico: done
<bac> arosales: fwiw, i was able to create a new live acct and get the subscription linked.  thanks for the pointers.
<gary_poster> Me too
<gary_poster> I have a win 8 iso waiting for me
<bac> thanks teknico.  i understand you needed to set limits to get the thing done.
<teknico> bac, thank you for the detailed review. I applied your changes, and am landing the thing
<arosales> bac: sorry, I was tied up in a meeting.
<bac> arosales: np.  just making that comment.
<arosales> bac: ah good to hear re the license.
<arosales> bac: thanks for the feedback
<arosales> bac: it actually looks like a pretty good testing license too
<benji> the browser warning branch is up for review: https://codereview.appspot.com/7299071
<benji> and I am up for some lunch
<gary_poster> benji, branch has conflicts
<benji> gary_poster: fixed: https://codereview.appspot.com/7299071
<gary_poster> thanks benji
<gary_poster> benji fwiw, seeing weird behavior--not drawing after connection, etc.  trying to debug.
<benji> hmm
<gary_poster> benji may be noise, or other weirdness.  just worked in debug, but worked first in prod too...
 * benji tries to figure out the emoticon for furrowed eyebrows.
<hatch> >:|
<hatch> that one? :)
<gary_poster> yeah that looks pretty good :-)
<hatch> could maybe throw a nose in there if you want to be a little more awesome >:-|
<gary_poster> I'm a big fan of noses
<benji> noses are over-rated, just ask Voldemort
<gary_poster> or snakes generally I guess
<bcsaller> he who should not be nostriled
<gary_poster> lol
<hatch> well if you smell with your tongue that might be kind of cool
<hatch> haha
<benji> heh
<benji> I really should find the $250 and 116 hours required to buy and re-listen to Jim Dale's reading of Harry Potter.  So good.
<hatch> *sigh* 3H trying to get my wifi back up on my laptop and no luck
<hatch> looks like me and broadcom are never going to get along
<gary_poster> benji, make debug is working for me but make prod is not on your branch.  My experience is that it connects, ws sends "Switching Protocols" and then nothing happens
<gary_poster> works in prod
<gary_poster> I mean debug
<gary_poster> like I said
<gary_poster> Chrome, FF, IE
<gary_poster> all the same
<benji> gary_poster: good catch, I'll try to figure out what is wrong with it
<gary_poster> benji, you see it too?
<benji> gary_poster: I haven't attepmted to verify it yet.
<gary_poster> benji, oh ok.  If you duped that would make me happy because I am currently going in the "it must only be happening to me" spiral because it seemed to work at first
<benji> gary_poster: ok, let me look
<benji> gary_poster: there does seem to be some problem, in Chrome I just get the background hash and in FF I get the browser message and when I click continue I get the background hash
<gary_poster> benji, oh, ok great
<gary_poster> I mean not great for the branch :-P
<gary_poster> but great for my sanity :-)
<gary_poster> ok benji, sounds like a Monday thnkg.  thanks for looking
<gary_poster> bye all
<benji> gary_poster: later
<hatch> have a good weekend
#juju-gui 2014-02-03
* hitchcock.freenode.net changed the topic of #juju-gui to: Juju GUI - Mailing List  https://lists.ubuntu.com/mailman/listinfo/juju-gui
<frankban_> dimitern: morning, when you have time, could you please take a look at https://codereview.appspot.com/50090044/ ?
<dimitern> frankban_, sure, will look after the standup
<dimitern> frankban_, morning :)
<frankban_> dimitern: thank you! IIRC, I need two reviews, and when everything is ok I just need to approve on launchpad, correct?
<dimitern> frankban_, not anymore, just one LGTM is enough, and then you need to set the commit message on the MP first and then approve it
<frankban_> dimitern: cool thanks
<dimitern> frankban_, reviewed
<dimitern> frankban_, usually, we set the MP commit message to the same as the description (look at the bzr rv-sumit plugin you can use to approve and submit for landing a CL - it's awesome)
<dimitern> s/rv-sumit/rv-submit/
<benji> jujugui: I need someone with some git fu; I don't have any ideas left on how to get my branch merged.  (other than hand-editing a diff and starting a new branch with it)
<gary_poster> benji you tried cherrypicking?
<benji> gary_poster: nope; I'll google it.  Unfortunately I asked that question at the wrong time, I need to run Owen to day care :\ now
<bac> hi jujugui. I've got a laptop with no display this morning. trying to get my env and vim moved to another. on here via tablet.
<gary_poster> benji alternatively, FBOW the git pattern of rebasing doesn't seem to be any better than breating a diff and that applying it as a patch
<gary_poster> ok benji
<gary_poster> ack bac
<bac> s/vim/vm/
<bac> I don't use no vim
<gary_poster> :-)
 * bac_ some progress
<bac> nick bac
<bac> doh
<rick_h_> hello all, thanks for the review/landing gary_poster 
<gary_poster> hey rick_h_.  you there safely?
<gary_poster> welcome
<rick_h_> gary_poster: yep, long long trip but alive and well
<gary_poster> cool :-)
<rick_h_> surviving first day of meetings. Just one more today I think. I'll try to attend to the standup from here. It'll be 6pm here
<gary_poster> ok cool rick_h_
<rick_h_> I'll try to look into the qa issue on the bws branch. Thought that worked. Thanks for catching it
<gary_poster> np.  very nice otherwise
<frankban> guihelp: is anyone available for a quick review + QA of https://codereview.appspot.com/59560044 (GUI charm)? thanks
<gary_poster> frankban: on it
<frankban> gary_poster: thank you
<gary_poster> hey frankban, this isn't a bug in your branch, but potentially in core (and therefore a problem for us).  I tried to use a local environment with the juju I had currently installed (1.16.5-saucy-amd64).  My ~/.juju/environments/local.jenv says 'password: ""'.  An empty password does not work to log into the GUI.  I noticed that the user is "" also in the jenv file.  Perhaps that's the problem, but I tried logging in 
<gary_poster> on the console with a an empty password and a user name of "user-" and it did not work.  That doesn't really make sense anyway.
<gary_poster> So...
<gary_poster> Any ideas on what we should do there?
<gary_poster> One option is to see if it works on the most recent released juju
<gary_poster> and if it does, pretend everything is OK:-)
<gary_poster> I'm fine with that, but wanted to see what you thought
<gary_poster> It's certainly not ideal :-/
<gary_poster> ah
<gary_poster> my environments.yaml does have an admin-secret for my local env
<gary_poster> it just wasn't copied over to the jenv
<gary_poster> it works fine
<frankban> gary_poster: you should have an admin-secret field in your jenv. I also have user and password as empty strings there, and that's confusing
<gary_poster> frankban: with recent release? trunk?
<frankban> gary_poster: this is 1.16.5-saucy-amd64, trying trunk now
<gary_poster> ok
<gary_poster> I hope it is fixed in trunk.
<gary_poster> If so, the legacy message can say "if there is no password there, try the environments.yaml" file.  That's unpleasant, but accurate, and at least the new version would be OK
<frankban> gary_poster: same thing in trunk, user and password empty, the real password is found in the admin-secret field of the jenv
<gary_poster> frankban: :-(
<gary_poster> um
<gary_poster> so, ideally
<gary_poster> we'd get Tim or someone to treat this as critical
<gary_poster> and fix it
<gary_poster> before the next release
<frankban> gary_poster: so we always have the admin-secret in the jenv, but we also have a confusing user and password fields
<gary_poster> oh
<gary_poster> oic
<gary_poster> hm
<gary_poster> and it is correct for ec2
<gary_poster> (that is, you can use password)
<gary_poster> ok.  so, right\
<gary_poster> IMO ideally we'd have juju core treat this as a critical fix
<gary_poster> then the legacy message would be, roughly, "look in the jenv file for password, or if that's empty, look for admin-secret"
<gary_poster> and the new message would be "look in this file right here for the password"
<gary_poster> I think that would be OK, if we can get juju core to address before next release.  WDYT frankban?
<frankban> gary_poster: oh... in trunk, the jenv file includes the password field once you deploy the first charm
<gary_poster> frankban: :-/
<frankban> gary_poster: I mean, the password field is no longer empty
<gary_poster> right
<gary_poster> well, I guess that would be OK for the GUI
<gary_poster> so we can treat this as not critical for us
<gary_poster> and adjust the legacy message.  agree?
<gary_poster> getting some water, brb
<frankban> gary_poster: yes, when the user see the message the password field should be populated, even in local envs. so I'd need to change the messages to point to the password field (rather than the admin-secret one), and the legacy message should mention the environments.yaml file for juju < 1.16
<gary_poster> cool frankban.  proceeding with qa
<gary_poster> frankban: this is too long, but it is my first stab at a suggestion for adjusting the legacy help text.
<gary_poster> The password for newer Juju clients can be found by locating the Juju environment file placed in ~/.juju/environments/ with the same name as the current environment.  For example, if you have an environment named "production," then the file is named ~/.juju/environments/production.jenv.  Look for the "password" field in the file, or if that is empty, for the "admin-secret".  Remove the quotes from the value, and use 
<gary_poster> this password to log in.  The password for older Juju clients (< 1.16) is the admin-secret for the environment you are using in ~/.juju/environments.yaml.  Note that using juju-quickstart (https://launchpad.net/juju-quickstart) can automate logging in, as well as other parts of installing and starting Juju.
<gary_poster> Still adjust that
<gary_poster> adjusting
<gary_poster> The password for newer Juju clients can be found by locating the Juju environment file placed in ~/.juju/environments/ with the same name as the current environment.  For example, if you have an environment named "production," then the file is named ~/.juju/environments/production.jenv.  Look for the "password" field in the file, or if that is empty, for the "admin-secret".  Remove the quotes from the value, and use 
<gary_poster> this to log in.  The password for older Juju clients (< 1.16) is in ~/.juju/environments.yaml, and listed as the admin-secret for the environment you are using.  Note that using juju-quickstart (https://launchpad.net/juju-quickstart) can automate logging in, as well as other parts of installing and starting Juju.
<gary_poster> Best so far ^^^
<frankban> gary_poster: so here is the situation: admin-secret is always populated correctly. the password field is populated in trunk when at least one charm is deployed after bootstrapping. the password field is never populated in 1.16
<frankban> gary_poster: that's great! thank you!
<gary_poster> cool frankban.  proceeding to Juju trunk noq
<gary_poster> now
<rick_h_> jujugui anyone got a sec to re-qa https://github.com/juju/juju-gui/pull/98 please? /me looks at it and realizes pushing a branch done while tired on a plane was not a good plan. 
<gary_poster> :-)
<gary_poster> rick_h_: I'm doing it while waiting for the charm to set up
<gary_poster> for a different qa
<gary_poster> oh it's up :-P
<gary_poster> 1 sec then
<gary_poster> frankban: LGTM and QA OK.  Thanks!
<frankban> gary_poster: thank you!
<gary_poster> :-)
<frankban> gary_poster: filed two holidays
<gary_poster> frankban: ack, approved
<frankban> gary_poster: re paragraphs, yes that's a GUI branch (to make the text not to be escaped) and a subsequent charm branch. the first one could also help with the quickstart link (i.e. a target blank), thnaks
<gary_poster> cool
<gary_poster> jujugui call in 10
<gary_poster> rick_h_: I am slowed down because I'm trying to figure out a nice way to update my git qa-pr version of your PR
<gary_poster> with your new changes
<gary_poster> simply deleting the branch and then running qa-pr again was insufficient
<gary_poster> I assume it has something to do with the git fetch we are doing
<gary_poster> but currently flailing
<gary_poster> if you have suggestion, it would be welcome :-)
<gary_poster> ah-ha
<rick_h_> gary_poster: hmm, so if you git checkout develop && git branch -d qa-... and then another git qa-pr it won't work?
<rick_h_> gary_poster: or you found a way?
<gary_poster> rick_h_: correct, that does not work, and I think it is because remotes/pr/98 already exists
<gary_poster> andthere is no logic to update that remote
<gary_poster> so I need to update that remote somehow...
<gary_poster> nad then the merge will work
<gary_poster> trying to delet remote now...
<gary_poster> oops
<gary_poster> jujugui call in 1
<Makyo> Finally!
<rick_h_> man, you'd think on a canonical connection this wouldn't be an issue. 
<gary_poster> heh, yeah
<Guest92118> Grrr.
<Guest92118> Services are down, whoops.
<bac> so my mbp is back.  i'm beginning to think vmware ate my graphics card but can't explain how it took multiple reboots to clear up.
<bac> gary_poster: i reviewed the work i did on friday for juju-core 1.17.2 QA and what i said in the meeting was wrong.  the QA was clean.  no remaining issues.
<gary_poster> great bac
<hatch> freenode I'm in you!
<rick_h_> gary_poster: heads up, quickstart package was pushed upstream yesterday. 
<rick_h_> gary_poster: and casey is going to look into how to do a charm store deploy for 1.17.2
<gary_poster> rick_h_: awesome!  thanks!
<gary_poster> great
<gary_poster> rick_h_: if you want some demo cred, you can demo local charm deployment from github.  It's a *great* story
<gary_poster> demo cred is good :-)
<rick_h_> gary_poster: cool yea I htink there's a demo session. hatch can you shoot me some instrucitons?
<gary_poster> I think it will blow people away
<gary_poster> be sure to give Dimiter a shout out
<rick_h_> sure thing, I'll see if I can get setup to duplicate. You need trunk right?
<gary_poster> hatch just gave you +1 with lots of small comments
<hatch> gary_poster thanks will get right on the changes
<hatch> rick_h_ you bet, can you get juju-core trunk working on your local machine?
<rick_h_> hatch: yea send me a link to those build docs and I'll see if I can get it done. It's late here (10pm) but hopefully find time to tru it out
<gary_poster> rick_h_: for best experience, yes, use Juju trunk.  Then you start up GUI, go to https://github.com/hatched/ghost-charm and click on the "download zip" button on the right, drag it in to the GUI, configure it, and deploy.
<gary_poster> On LXC on my network it shows up in a minute or so
<gary_poster> and then you can expose it and actually use ghost
<gary_poster> really awesome
<hatch> yeah I'll send that in an email too, just in case :)
<rick_h_> woot
<hatch> rick_h_ https://code.launchpad.net/~go-bot/juju-core/trunk here is juju-core trunk, read the README for detailed install instructions
<gary_poster> hatch does teh ghost charm download something over network?
<gary_poster> would be more reliable/faster for rick if he had one that did not
<hatch> gary_poster yes it requires access to a number of external resources https://github.com/hatched/ghost-charm/blob/master/hooks/install
<gary_poster> so obviously this evening you need to adjust ghost so that default install does not need network access, like GUI ;-)
<hatch> haha, probably not until ghost stabilizes their build setup :)
<gary_poster> hatch, consider packaging zip, or giving rick a branch that includes zip, like we do for gui?
<gary_poster> also then emphasizes advantage of being able to work with local charms for demos:
<gary_poster> make quick hack, ready to demo
<hatch> I'll have to look into the current ghost build process to see if I can package all of it's deps or if it needs some 'installed' 
<gary_poster> (as soon as the icon actually shows up!)
<hatch> haha
<gary_poster> oh hatch right, npm install.
<gary_poster> nm then
<gary_poster> might not help much
<gary_poster> benji gets lucky PR 100
<hatch> I think they install sqlite so that probably needs to be 'installed'
<hatch> not just exacted but I can look into this 
<gary_poster> cool :-)
<rick_h_> there's an AP right by the demo space so should be good connection there. Look slike friday is open so I'll get a chance to test it out before hand
<gary_poster> cool, perfect
<hatch> rick_h_ I'll send the demo instructions to peeps just so everyone has them 
<rick_h_> hatch: thanks, appreciate it
<rick_h_> ok, bed time, I'm out for real this time
<rick_h_> zzzzzzzz
<hatch> :) night
<gary_poster> :-) night
<gary_poster> hatch, when you have a sec (maybe after you have branch in), would like to talk with you about https://bugs.launchpad.net/juju-gui/+bug/1274955 , maybe on a hangout
<_mup_> Bug #1274955: Juju GUI slow in disconnected environment due to using Google font APIs <micro-cluster> <juju-gui:Triaged> <https://launchpad.net/bugs/1274955>
<hatch> sure, want to do it now?
<gary_poster> :-) sure
<BradCrittenden> see ya rick_h_.  have a good evening.
<hatch> gary_poster https://plus.google.com/hangouts/_/76cpjggu44rijpcdrj53ubb2qs?hl=en
<gary_poster> hatch, lol calling you from another, k one sec
<hatch> haha sorry
<hatch> gary_poster I'm going to restart
<hatch> maybe that will help
<gary_poster> ok hatch
<gary_poster> jujugui, tiny charm branch for review: https://codereview.appspot.com/52230045
<huwshimi> Morning
 * Makyo -> dogwalk, back in a few.
#juju-gui 2014-02-04
<hatch> huwshimi ready for a final review/qa on #95?
<huwshimi> hatch: That'd be great!
<hatch> ok I'm going to take a little break then I'll get on it
<huwshimi> hatch: Thankyou!
<hatch> huwshimi trivial typo on the code review....ok now I'm really going to take a break before qa :)
<huwshimi> hatch: "typeo: maximized" hilarious.
<hatch> haha :)
<gary_poster> https://github.com/juju/juju-gui/pull/101 ready for review, and now I run :-)
<hatch> huwshimi fyi we use a z instead of s in maximized :)
<huwshimi> hatch: Do we?
<hatch> huwshimi I don't know what version of English we use :)
<huwshimi> hatch: Well, our writing style guides are for British English (we're a British company). Not sure if we have additional rules for our code comments.
<hatch> qa ok!
<hatch> huwshimi before you merge it in can you rebase it?
<huwshimi> Sure!
<frankban> morning hazmat: re: bug 1252301 do you already have a plan, can I help in some way?
<_mup_> Bug #1252301: guiserver reports second bundle as failing after the first fails <juju-deployer:New> <juju-gui (Juju Charms Collection):Triaged> <https://launchpad.net/bugs/1252301>
<hazmat> frankban, i'm at sprint and then on vacation till roughly feb 17th, and then multi-tasking for partner/customer deadlines.
<hazmat> frankban, if you have time that would be great.. the simple thing is just to have wait for units  methods, take flag, and pass the flag in via config.. i think.. i haven't thought about it while looking at the code.
<frankban> hazmat: ack. there is already an ignore_error flag passed to that function
<frankban> hazmat: I'll take a better look at it
<hazmat> frankban, thanks
<gary_poster> frankban: +1 on GUI login text PR 103
<frankban> gary_poster: thanks!
<gary_poster> rick_h_: qa bad on your demo icon branch.  To see problem, go to https://manage.jujucharms.com/api/3/charm/~web-brandon/precise/my-site-1/file/icon.svg?demo=true .  Maybe "demo" is not the expected name in charmworld for this functionality?
<gary_poster> welcome
<bac> hi benji, would you have a moment for some makefile advice?
<benji> bac: sure
<hatch> gary_poster can we cancel the merge of huws branch or is it too late? It wasn't rebased
<gary_poster> hatch, I don't know how, sorry
 * gary_poster kinda hates the rebase thing.
 * gary_poster kinda thinks bzr shoulda won
<hatch> yeah I don't know how to cancel it either :) without the rebase bisecting is kind of a pita of unfortunately....having a bunch of broken commits 
<hatch> yeah this part bzr clearly wins
<gary_poster> hatch I think I might have canceled it
<rick_h_> gary_poster: bah, sorry. I assumed charmworld would ignore it. I tried to work on the charmworld side of the branch but the ppa's for charmworld aren't available for trusty
<gary_poster> hatch: ok it is cancelled,pretty sure.  I aborted build
<gary_poster> hatch one of us should do the rebase
<gary_poster> hatch I can try to delete it later
<gary_poster> I mean rebase it :-P which may mean deleting huw's PR
<gary_poster> (closing)
<gary_poster> rick_h_: np.  
<rick_h_> gary_poster: will leave that on hold for the moment and will try to get an older release lxc setup to update charmworld first then
<rick_h_> gary_poster: thanks for the review/qa catch
<gary_poster> cool rick_h_ .  OTOH If you want to land it with a "it's feature-flagged" approach that's fine with me too
<rick_h_> gary_poster: will see what time I get. If it'll be a bit I'll add a FF on it
<hatch> I wonder if we can write an intelligent rebase script so it could act like bzr 
<rick_h_> maybe should anyway since in order to land it would need a charmworld release :/ good call
<gary_poster> rick_h_: IMO it is already "feature flagged": you have to opt in on the console
<rick_h_> gary_poster: oh yea even better :)
<rick_h_> hatch: ugh yea. I need to see if I can update the process to handle this. What we need is a clear process for "update from develop" that doesn't break the feature branch history like it does now
<rick_h_> hatch: if you get a chance, I wonder if we could add a "how to sync with trunk" that's testing out using git rebase develop vs git merge/pull develop
<rick_h_> hatch: and if that helps out
<hatch> yeah...I'm just wondering why rebasing merges into your commits shows up in the diffs
<hatch> that stuff 'should' already be in develop so why is it considering it 'new'
<gary_poster> rick_h_: gave a +1 to the branch with that understanding.  Onlty had small text suggestion
<rick_h_> hatch: I think that's the diff between merge/pull/rebase. You can sync all three ways but they each act different and need to think through it
<rick_h_> gary_poster: rgr, will update it. 
<hatch> I wonder what others do, I can't imagine that this isn't a asolved problem
<hatch> people can't have a ton of broken commits in their trunk
<hatch> ....well....shouldn't :)
<hatch> gary_poster did you see that your font branch failed CI?
<gary_poster> hatch, yeah thanks.  Weird: it failed on IE in sandbox.PyJujuAPI tests!
<gary_poster> No idea why.
<hatch> ok that's odd
<gary_poster> Want to try and dupe locally
<rick_h_> there is a transiet error that happens in CI very rarely
<gary_poster> oh!  was wondering about that
<rick_h_> gary_poster: if it's a really odd error I'd try to run it again
 * rick_h_ goes to find the branch/build
<gary_poster> https://github.com/juju/juju-gui/pull/101
<gary_poster> rick_h_: ^^^ is there a way to trigger a build without pushing another branch?
<hatch> delete the message from CI
<hatch> the 'status: merge request accepted' one
<hatch> then it'll re-run
<gary_poster> hatch, no this is the initial run
<hatch> oh woops, sorry no idea
<frankban> gary_poster: starting the process to release the GUI charm if you agree
<gary_poster> frankban: +1 thank you
<rick_h_> gary_poster: yes, got pulled away https://github.com/juju/juju-gui/blob/develop/docs/continuous-integration.rst#manually-running-a-build
<gary_poster> perfect thanks rick_h_
<rick_h_> gary_poster: so http://ci.jujugui.org:8080/job/juju-gui/327/ looks like it went ok?
<rick_h_> not sure why it didn't trigger a pass in github
<gary_poster> cool, and awesome! thanks rick_h_.  Tweaking branch now.  Gives me rebase practice. :-)
<rick_h_> gary_poster: cool
<hatch> gary_poster was the test failure the long line?
<hatch> or was that just a driveby
<gary_poster> hatch, no, that was a driveby
<gary_poster> hatch, the next test run passed without changes
<hatch> oh :) 
<rick_h_> yea, it's a really odd and rare failure. I guess I should file a bug on it. Only hit it a couple of times
 * hatch sings blame rick_h_  to the tune of 'Blame Canada' from South Park
<rick_h_> but it does happen
<gary_poster> lol
<rick_h_> :P
<gary_poster> I don't think rick_h_ can take any blame for those tests
<hatch> maybe not, but it can be assigned
<hatch> :P
<rick_h_> hatch: I just got out of a meeting with Mark S and he wants you to build Jaas by yourself by the end of the month. GO! :P
<gary_poster> :-)
<gary_poster> heh
<hatch> rick_h_ lol, wouldn't be the craziest request I've gotten haha
<gary_poster> We won't tell you what it is, but if you get it wrong, you're fired ;-)
<hatch> hahaha
<hatch> that's pretty close to some of the requests I've received 
<benji> one month of paid job-hunting; sounds like a good deal to me a
<hatch> "can you build us an app for our startup....but we can't tell you what we do now..."
<gary_poster> heh
<hatch> benji lol
<benji> gary_poster: AWS expenses incoming
<gary_poster> cool benji, I'll catch 'em
<hatch> juju-core can be up/downgraded nicely
<gary_poster> done.
<hatch> at least it appears to not be barfing all over the place
<hatch> seems to be considerably slower though....
<hatch> I just enjoy using the GUI when using Juju....guess that means we did a good job :)
<gary_poster> :-)
<gary_poster> +1
<gary_poster> you know...
<gary_poster> if you look at the jenkins test console (http://ci.jujugui.org:8080/job/juju-gui/331/console)...
<gary_poster> a *lot* of the time is spent on 304 requests
<gary_poster> a *whole bunch*
<hatch> you bet
<hatch> rick_h_ and I have both been wanting to write a cache layer for those json requests
<gary_poster> cache headers would be dagerous
<gary_poster> it's no just json fwiw
<gary_poster> svg and yaml too
<hatch> I was thinking something in the app
<rick_h_> gary_poster: right, but all of those are through the "loadxxx" helper that needs to just send back the data
<hatch> yeah that
<gary_poster> so the app itself would cache?
<gary_poster> in a util?
<rick_h_> so it's just a matter of faking the cache in the test util helper
<rick_h_> no the app, it's in the tests only
<hatch> 'just' famous last words lol
<gary_poster> that might be an 80/20, yeah
<rick_h_> hatch: :P come on. It's easy. You could do it in an hour.
<gary_poster> heh
<hatch> rick_h_ lol shush
 * rick_h_ downloads hatch's ghost zip
<gary_poster> ok hatch or someone else in jujugui, https://github.com/juju/juju-gui/pull/104 has passing tests and is ready for review (hopefully easy) and qa (more annoying)
 * hatch needs someone to actually use the ghost charm so I can get motivated to keep working on it
<gary_poster> do demos count? ;-)
<hatch> haha, well it works for demos now. 'lowest viable product' :P
<gary_poster> :-)
<rick_h_> hatch: Failed to load resource: the server responded with a status of 405 (Method Not Allowed)  
<rick_h_> :(
<hatch> rick_h_ are you using the latest charm and juju 1.17.1+
<rick_h_> 1.17.3-trusty-amd64 
<rick_h_> cs:precise/juju-gui-82
<rick_h_> I got juju from trunk with the go get juju...
<rick_h_> and I changed the juju-gui-source to the develop branch
<rick_h_> in the charm
<hatch> hmm something is messed up with charmworld.....juju-gui latest is revno 83, but it's deploying 82
<frankban> hatch: cs:precise/juju-gui-82 is revno 83
<hatch> ohh ok, so then it 'should' be working
<hatch> frankban I thought the numbers on the end matched the revno 
<hatch> :)
<hatch> rick_h_ can you view the guiserver logs in the charm?
<rick_h_> hatch: looking
<frankban> hatch: I used to know the meaning of the number after the last dash, but I keep forgetting that and I ended up just considering it an obscure auto-incrementing mystical number 
<hatch> haha sounds good
<rick_h_> hatch: which log? nothing in /var/log/juju/juju-gui.log
<hatch> guiserver.log
<hatch> it's in...
<hatch>  /var/log/upstart
<rick_h_> ah right uin upstart
<hatch> yeah this is the actual 'server' logs
<rick_h_> [W 140204 15:07:13 web:1635] 405 POST /juju-core/charms?series=precise (41.164.30.187) 7.48ms
<hatch> that's it hey?
<hatch> frankban any ideas?
<rick_h_> yep
<rick_h_> all I get in there
<hatch> frankban 83 supports the local charm stuff right?
<rick_h_> gary_poster: bac comingsoon has a merge conflict issue
<bac> rick_h_: ok
<frankban> jujugui: https://jujucharms.com/sidebar/search/bundle/~abentley/wiki-bundle/1/wiki/?text=bundle#bws-code is an official bundle that we cannot deploy. since the bundle includes local charms (those with "branch:") the fake backend fails. this is related to bug 1276107 , but I didn't know those kind of bundles were exposed in the GUI  
<_mup_> Bug #1276107: gui fails to deploy a bundle due to "Invalid charm id: undefined" <juju-gui:Incomplete> <https://launchpad.net/bugs/1276107>
<bac> rick_h_: will check it out
<frankban> hatch: revno 83 does not
<hatch> rick_h_ doesn't look like the 83 supports it 
<gary_poster> thanks bac
<hatch> sorry
<rick_h_> frankban: so that is an old old bundle that sohuld be deprecated and removed
<hatch> https://code.launchpad.net/~juju-gui/charms/precise/juju-gui/trunk
<rick_h_> frankban: as we update the rules and proof we don't go back and clear old things out 
<rick_h_> frankban: maybe we should do that
<frankban> hatch: I am in the middle of the charm release. hopefully the new charm with putcharm enabled will be released in 30 mins
<rick_h_> hatch: oh sorry, thought it as there
<rick_h_> frankban: ah ok cool. I'll retry setting up the demo later tonight then
<gary_poster> rick_h_: was using local charms for demo
<rick_h_> thanks for the heads up
<rick_h_> yea, it's friday. I got the juju-core part working so that's a good bit. If the charm gets updated then should be all ready for the demo well in time
<frankban> rick_h_: I'll ping everyone once the charm is released
<rick_h_> frankban: ty
<gary_poster> rick_h_: re frankban's comment about the failing bundle, any ideas how that made it through proof?
<rick_h_> gary_poster: it was pre-proof checking things
<gary_poster> rick_h_: I thought we had a re-import though
<rick_h_> it's one of the first bundles we ever put in to test/prove charmworld could test them. 
<rick_h_> I think it goes into an error state, and we don't repull it but I don't think we clear it out. Am I mistaken on that bac ?
<rick_h_> gary_poster: in theory we're treating it like a bad revision if I recall correctly. 
<frankban> rick_h_: unfortunately that's also the first bundle result if you search for "bundle" on the side bar
<gary_poster> :-(
<rick_h_> frankban: hah, ok. We should yank it. Maybe benji can try out his charm remover on the bundle? 
<gary_poster> yeah was thinking the same thing
<hatch> hulk smash!
<bac> rick_h_: comingsoon should be happier.
<rick_h_> bac: thanks
 * rick_h_ puts a note to look at adding a monitoring thing on our azure account. See if we can get a notice if it fails to load
<bac> jujugui: remember to QA on coming soon if you muck with config.js  (but we always forget)
<abentley> I'm happy to delete the branch if you want.
<gary_poster> ah I have one of those comingsoon config fun things coming up too, maybe
<bac> gary_poster: do more better!
<gary_poster> thanks abentley.  That sounds like a good idea to me.  We still need to delete it in charmworld.
<gary_poster> :-)
<gary_poster> hatch you looking at https://github.com/juju/juju-gui/pull/104 or planning to, or should I beg someone else?
<abentley> gary_poster: btw, the URL after "bzr branch" is a bit weird.  You never need /files after a Launchpad branch URL.
<gary_poster> thanks abentley, yes.  Fixed in trunk (http://comingsoon.jujucharms.com/sidebar/search/bundle/~abentley/wiki-bundle/1/wiki/?text=bundle#code) and even in recent GUI releases.  jujucharms hasn't had an update because we are blocked on switching to juju core.
<abentley> gary_poster: cool.
<gary_poster> http://comingsoon.jujucharms.com/~dweaver/complex-webapp-and-management-bundle/8/complex-webapp/ could look better :-/
<gary_poster> sorry
<gary_poster> correct link:
<gary_poster> http://comingsoon.jujucharms.com/sidebar/bundle/~dweaver/complex-webapp-and-management-bundle/8/complex-webapp/
<hatch> gary_poster yeah I'll be looking at it
<gary_poster> thank you
<hatch> my env is a little messed up right now because of testing for old juju versions and the like
<gary_poster> gotcha
<hatch> jujugui do we know the version of juju in the GUI now? I remember hearing some discussion on the matter but wasn't sure the outcome
<frankban> hatch: no we don't
<hatch> ooooo kaaaayyyyyy
<hatch> little unfortunate
<frankban> hatch: what do you need that for?
<hatch> frankban when the user tries to upload a charm and it's not supported I was going to say "Your version of Juju ({version}) does not support local charm uploads, please use at least 1.18.0"
<hatch> so I'll just drop out their version for now
<frankban> hatch: ack not too bad
<hatch> nope
<gary_poster> jujugui call in 10
<benji> hatch: I can't reproduce bug 1271986
<_mup_> Bug #1271986: Destroying service leaves inspector open <juju-gui:Triaged> <https://launchpad.net/bugs/1271986>
<hatch> benji looking
<hatch> benji it was intermittent 
<hatch> maybe try a couple times?
<benji> hatch: I did.  I'll try some more.  How long were you letting it be in pending before destroying it? 
<hatch> benji 30s or so I think
<benji> k
<hatch> frankban the error returned from the charm when trying to use local charm upload is:
<hatch> Internal server error:
<hatch> error fetching data from https://10.0.3.1:17070/charms?series=precise: HTTP 599: Unknown
<hatch> do we want to expose that url?
<frankban> hatch: is this the error with old juju-core versions?
<hatch> frankban yes, the ~juju-gui charm and juju 1.16.x
<hatch> it should really be returning a 405 imho instead of a 500
<hatch> shall I file a bug on the charm?
<bac> jujugui call in 1?  2?
<gary_poster> jujugui cvall in 2
 * gary_poster has a broken clock on Ubuntu :-P
<bac> ha, i beat you and spelled it right!  :)
<gary_poster> heh
 * gary_poster tries restarting Ubuntu after a software update to see if he gets his clock & cal back
<gary_poster> Makyo: fwiw, software update + reboot = clock.  yay!
<gary_poster> 'course, now chrome crashes :-/
<hatch> price of using beta software I suppose :(
<frankban> gary_poster, rick_h_: gui sandbox mode is broken (my putcharm branch introduced an error in the GUI server when here is no API URL). made an urgent card and starting to work on the (easy) fix. this will delay the charm release to tomorrow, is that a problem? (anyway: yay functional tests!)
<gary_poster> frankban: :-) no problem IMO
<frankban> cool
<hatch> jujugui lf a review and qa https://github.com/juju/juju-gui/pull/105 plz and thanks 
<gary_poster> hatch, on it
<hatch> thanks
<hatch> and now I can do the qa on your branch
<hatch> jujugui can someone on Ubuntu check if the drag and drop works in Firefox? 
<hatch> It's not working in OSX Firefox
<frankban> hatch: drag'n'drop of what?
<hatch> the charms/bundles
<frankban> local charms?
<hatch> sorry
<hatch> from the browser
<frankban> hatch: oh, from the sidebar
<hatch> yeah
<gary_poster> hatch, qa bad.  I'm using 1.16.5-saucy-amd64 .  I have two problems.  First, e.target.responseText is simply 'badMessage'.  You try to parse that as JSON (line 152 of local-charm-import-helpers) and the JSON parser is unhappy and falls over.  Second, even if that were fixed, the server responds with a status of 405 (Method Not Allowed) not 500 or 599 or anything else.  That second one wuld be solved easily by 
<gary_poster> reporting an error when the status >= 400, as I suggested already in the review.
<hatch> gary_poster are you using the ~juju-gui charm? 
<gary_poster> hatch yes
<gary_poster> trunk
<hatch> weird...it returns 500 for me
<hatch> hmm
<frankban> hatch: dragging charms from the jujucharms.com sidebar works for me using ff
<hatch> ok must be OSX only FF
<gary_poster> :-/
<gary_poster> hatch do you want any more info from me on the qa?  hangout?
<gary_poster> whatever helps
<hatch> well no I'm going to have to switch back and deploy a new env and give it another go
<gary_poster> ok
<frankban> hatch: I confirm charms drag and drop is broken on OSX Firefox
<hatch> gary_poster juju-gui-103 is the charm that's deployed?
<gary_poster> hatch, no, charm trunk--the charm Francesco is releasing now.
<hatch> hmm I thought that's what I was running...ok tearing down and starting a new env
<frankban> hatch: trunk is cs:~juju-gui/precise/juju-gui-151
<hatch> oh shoot I'm working on frankban's branch
<hatch> ....
<hatch> WELL THEN!
<gary_poster> :-)
<gary_poster> Yay QA? :-)
<hatch> well it takes considerably longer to be able to test than to actually write the code hah
<gary_poster> hatch, pretty fast if you use a local charm, a local environment, and a release created via `BRANCH_IS_GOOD=1 make distfile`, as I keep saying
<hatch> oh right, but I had already spun up another env on 1.17.2
<hatch> bzr may do rebase nicely but man does it not do lightweight checkouts well
 * gary_poster lunches
<hatch> gary_poster I can't get anything other than a 500 :/
<hatch> juju status shows juju-gui-104 charm as deployed 
<hatch> which was a fresh trunk checkout
<hatch> bzr revno is 159
<frankban> gary_poster: when you have time could you please take a look at https://codereview.appspot.com/57690051 ? no rush and thanks!
<Makyo> hatch, gary_poster re: huw's branch. I rebased and pushed to a branch on my fork.  Want me to use the merge tool (create a PR with my branch, immediately :shipit:) or manually merge huw's branch into develop (will mean having a non-jujugui user in merge history)
<Makyo> ^^^ + anyone else who cares (jujugui)
<hatch> Makyo I'd probably prefer to use the CI system
<bac> Makyo: doing the latter will give huw credit.  i'd go that route, even if he isn't in jujugui
<bac> so, flip a coin!
<hatch> haha
<Makyo> bac, I think it'll give me credit, actually, since the push will come from my user.
<bac> Makyo: then go CI
<Makyo> Though the rebased commit is in his name.
<Makyo> Okay.
<Makyo> Bit of email spam coming up, then.  Disregard!
<hatch> gary_poster here is the output from the guiserver.log file when I try and upload a charm https://gist.github.com/hatched/69720b483da125bf951c does yours look similar but with a 405?
<gary_poster> hatch, 
<gary_poster> [W 140204 16:59:11 web:1635] 405 POST /juju-core/charms?series=precise (10.0.3.1
<gary_poster> ) 97.51ms
<hatch> that's the error you get with an old version of the charm....are you SUUUUUUURE you're not using an old one? :)
<gary_poster> hatch,
<gary_poster> gary@gud:~/dev/guicharm/trunk$ bzr revno
<gary_poster> 159
<hatch> well now I'm right confused
<hatch> and juju status shows juju-gui-104?
<gary_poster> and from bzr info:
<gary_poster> parent branch: bzr+ssh://bazaar.launchpad.net/~juju-gui/charms/precise/juju-gui/trunk/
<gary_poster> from juju status:
<gary_poster> charm: local:precise/juju-gui-104
<hatch> so somehow we are running the same code but getting two different responses from the server
<hatch> hmm
<hatch> 1.16.5-precise-amd64
<hatch> yup we are running all of the same code
<hatch> and getting two different results
<gary_poster> no we are not
<gary_poster> 1.16.5-saucy-amd64
<gary_poster> should not make a diff
<gary_poster> but that's the only one we see so far
<hatch> see the issue with your log is that it doesn't show that it's trying to make a request to Juju
<hatch> if you use an old charm that's the same response
 * hatch puts thinking cap on
<gary_poster> I can redo everything with you on screenshare?
<hatch> well it's not like I don't believe you haha
<gary_poster> sure, but maybe I'm forgetting something or you will think of something else to check
<gary_poster> hatch I have this as first line of my guiserver.log:
<gary_poster> [I 140204 16:56:51 manage:144] starting Juju GUI server v0.3.0
<gary_poster> 0.3.0 old?
<hatch> yeah we can give it a try
<hatch> umm checking mine
<hatch> ^[[32m[I 140204 17:34:06 manage:144]^[[0;10m starting Juju GUI server v0.3.0
<gary_poster> :-/
<hatch> so same
<gary_poster> hatch did you deploy with make deploy?
<hatch> I did it the old fashioned way now to make sure it's all good
<hatch> https://plus.google.com/hangouts/_/72cpibkk7s99ntjs8svf322nk4?authuser=1&hl=en
<hatch> ^ gary_poster 
<hatch> this doesn't really effect us much but there has been a huge improvement to the loaders resolve speed https://github.com/yui/yui3/pull/1606
<gary_poster> so, startup time?
<hatch> nah we don't use the loader at all in our client side app
<gary_poster> ah right
<hatch> the only thing this could speed up is the resolving of the 'make' step
<hatch> the funny thing is that the loader totally breaks the speedy improvements 
<hatch> :)
<gary_poster> why does it break the speedy improvements?
<hatch> because it rolls everything up into only a few requests whereas with speedy those requests should be determined by the server and it's the servers job to send the data down the available pipes
<hatch> so instead of only 3 requests, speedy could open 8
<hatch> and actually make it faster
<hatch> the issue of course is that someone needs to write a speedy capable yui server
<gary_poster> ah
<gary_poster> I see
<hatch> I don't totally understand all of speedy but in theory it should make the web way faster for web sites
<hatch> gary_poster I totally blew everything away, and I still get a 500
<hatch> *sigh* haha
<gary_poster> hatch <shrug> try a saucy vm? :-)
<hatch> the issue now is trying to determine what the error message should say
<hatch> if status == 405 or 500:  
<hatch> hah
<gary_poster> >= 400!
<gary_poster> IMO
<hatch> right but then I have to put a try catch around the json parse
<hatch> and I don't like those.....for no reason 
<gary_poster> :-)
<hatch> I'm spinning up an instance to qa your branch btw
<gary_poster> cool ty
<hatch> so far all osx browsers are good, just trying with ie now
<gary_poster> cool
<gary_poster> bac, juju-gui trying to do comingsoon surgery 
<gary_poster> in prep for my config change coming down the pike
<gary_poster> and while I'm at it
<bac> gary_poster: ok
<gary_poster> juju-gui you may want to make clean next time after you `git pull juju develop`
<bac> gary_poster: the branch we're using is now juju-gui (again)
<gary_poster> bac you mean /opt/uistage/juju-gui?
<bac> gary_poster: you may want to get rid of the others since they are no long needed
<bac> gary_poster: yes
<gary_poster> ok thanks
<gary_poster> git stash is not working
<gary_poster> going to try and be more manual about it
<bac> gary_poster: really?
<gary_poster> bac http://pastebin.ubuntu.com/6874821/
<bac> gary_poster: oh.  is that a by-product of the conflicts?  or i wonder if it hasn't been working for a while
<gary_poster> ah no I think it was a git add?
<gary_poster> yeagh
<gary_poster> I just had to `git reset HEAD app/config-prod.js`
<gary_poster> that kept the changes but moved them out of staging
<gary_poster> then I could stash
<bac> abentley: do you have management permission on the ~ce-orangesquad/experimental PPA?  if so, could you make elasticsearch-java to build for trusty?
<gary_poster> pull
<gary_poster> and pop
<gary_poster> ^^ bac
<bac> s/to build/build/
<bac> pull and poop
<gary_poster> :-)
<gary_poster> bac, comingsoon surgery complete.  patient apparently in recovery.
<bac> for now.  relapse predicted.
<gary_poster> too true
<bac> gary_poster: so did the script change or did you just do it by hand and all is well again?
<gary_poster> bac, what script, he said nervously?
<gary_poster> I did it by hand
<bac> gary_poster: is abentley in SA?
<bac> gary_poster: uistage/bin/update...
<gary_poster> I don't think aaron is in SA, no
<bac> jcsackett: you around?
<jcsackett> bac: yup.
<bac> jcsackett: do you have management permission on the ~ce-orangesquad/experimental PPA?  if so, could you make elasticsearch-java build for trusty?
<gary_poster> bac, did not use script, and I don't think a change is necessary as long as no-one `git add`s the config-prod changes
<bac> jcsackett: i've been using the saucy PPA on trusty for a while so there is no source change
<bac> gary_poster: ok, so the next run of cron with the next commit should work
<jcsackett> bac: i think i have permission. one sec.
<gary_poster> I believe that to be true
<bac> gary_poster: i didn't 'git add' the config change if that's what you suspect.
<bac> i just edited out the conflicts
<gary_poster> bac, no idea, it just...was/
<bac> perhaps we did the last time it blew up...
<abentley> bac: Not in SA, just late lunching.
<bac> abentley: cool.  turns out i'm a member of ce-orange and didn't know it.
<abentley> bac: Heh.
<hatch> gary_poster I'm just running the tests for my branch locally again, would you be able to test it on your machine because clearly mine is broken :)
<hatch> I should have it pushed up in a minute or so
<gary_poster> hatch heh sure.  Just getting a MP ready and then will be free
<hatch> Makyo need a review?
<Makyo> hatch, sure, if you're willing!
<Makyo> Forgot QA instructions, will add.
<hatch> sounds good
<hatch> gary_poster FYI, i switched from your branch to my branch using the typical git branch... and it broke the yui doc stuff looking for the fonts - I had to make clean to fix
<Makyo> Boo test failure.
<Makyo> Looking.
<gary_poster> sorry hatch, yeah
<rick_h_> gary_poster: so I'll try to catch frankban, but saw his message on the charm. Looks like the dmeo is Thurs and not Friday so if we cant' get the charm up tomorrow it'll be helpful to know. 
<rick_h_> but should be ok if the release is tomorrow
<gary_poster> rick_h_: cool.  If you are using your computer then you can use the local charm and we can instructions for that either way
<hatch> gary_poster ok branch updated https://github.com/juju/juju-gui/pull/105 whenever you're available
<gary_poster> cool hatch will be there soon
<rick_h_> gary_poster: rgr, yea. I'll have the env pre-setup. 
<Makyo> Unrelated, checking if merging trunk helps.
<rick_h_> Makyo: hmm, the first failure is  from your recent relatoins stuff though?
<Makyo> rick_h_, yeah, though I don't get it locally.
<gary_poster> small Python charm review request (bac, benji, Makyo?): https://codereview.appspot.com/60130043 .  review should be very easy, & QA slightly more annoying but hopefully not too bad.
<bac> gary_poster: sure
<gary_poster> thank you bac
<rick_h_> Makyo: oh hmm, looking at the full log it seems like something went boom
<rick_h_> Error loading resource http://0.0.0.0:8888/path/to/charm/[object Object] (203). 
<Makyo> rick_h_, Oh!  Didn't see the link at the top.
<bac> gary_poster: i love how we have all three spellings: cachedFonts, cached-fonts, and cached_fonts.
<gary_poster> bac, I know :-/
<gary_poster> traveling between worlds
<hatch> I especially like the Go API responses in js that are capitalized which we then rename to be camelCased :)
<gary_poster> :-)
<hatch> gary_poster I read your description with your charm branch as "...verify in your browser's interceptor network tab..."
<hatch> I read it three time and was like wtf that doesn't make any sense
<hatch> haha
<gary_poster> hatch: lol
<gary_poster> hatch fwiw started qa 5 or 10 minutes ago.  will try both 1.16 and trunk
<hatch> great thanks
 * hatch crosses fingers
<gary_poster> hatch, looking good on 1.16.5.  Switching to 1.17.3
<hatch> gary_poster have you seen any additional correspondence from UI about the 'select a series' dialogue? I remember in the discussion they liked the inspector idea but I haven't seen any mockups
<hatch> yussss
<rick_h_> hatch: I think the idea is cool for now. It sounds like there will be changes to have the series in the charm and the environment will eventually go to an empty value for default series
<rick_h_> hatch: but that'll be down the road. 
<rick_h_> hatch: I can verify with UX tomorrow, but I don't think there's a lot to it to pop up the inspector with the dialog/selection
<hatch> oh so juju needs to extract the charm before it even knows what instance to spin up? interesting...
<rick_h_> hatch: yea, I was talking with Mark R about it toinght
<hatch> I like that you don't need the crazy folder structure then
<gary_poster> hatch, no, I haven't.  If you think it would be pretty easy, and Rick confirms the general approach, then I'd suggest making a stab at it and hoping they give small feedback.  Yes to everythin rick is saying...
<rick_h_> hatch: the first stab at an idea is to unzip in the guiserver perhaps (or use a zip lib)
<rick_h_> hatch: but we've got some time to talk on it. Still only Tues :)
<hatch> haha, I'm just trying to decide what to do next....fakebackend, drag and drop of folder or series selector...
 * hatch flips three sided coin
<rick_h_> I'd think series selector is first in getting it ready to go? folder is bonus?
<gary_poster> +1
<rick_h_> but party party
<gary_poster> if we think that the approach has general UX buy in
<gary_poster> which I do
<hatch> yeah my thoughts as well
<rick_h_> yay we all agree! that means it's time for bed
 * rick_h_ runs away
<hatch> hah
<gary_poster> hatch QA good!  Blessed the PR
<hatch> YUSSSSSS
 * hatch merges before it changes it's mind
<gary_poster> :-)
<bac> gary_poster: i'm trying to do your QA and use the distfile trick.  i get http://paste.ubuntu.com/6875204/
<bac> gary_poster: do i need BRANCH_IS_GOOD?
<bac> s/D/D=1/
<gary_poster> bac, yup
<gary_poster> sorry if I forgot that part
<bac> gary_poster: cool
<bac> gary_poster: i'm having troubles doing QA.  lxc issues.  take 3.
<gary_poster> ack bac, and thank you.  I know this is past EoD
<gary_poster> if you need to pass it to someone else I understand
<bac> agent-state-info: '(error: symlink /var/lib/lxc/bac-local-machine-1/config /etc/lxc/auto/bac-local-machine-1.conf:
<bac>       file exists)'
<gary_poster> ah that looks familiar
<gary_poster> I had to lxc-destroy and do various other purging bits
<bac> yeah, lxc should be smarter.  "the link i'm about to make already exists exactly like i want.  panic!"
<hatch> https://github.com/juju/juju-gui/commits/develop this is a little confusing, it shows the individual commits and the merge commit and they aren't always in order either
<bac> gary_poster: worked fine!
<gary_poster> awesome, thanks bac!
<gary_poster> Hey Makyo, did you send email to Huw?
<gary_poster> queue is not FIFO. :-/  https://launchpad.net/ubuntu/trusty/+queue
<Makyo> gary_poster, working on it now.
<gary_poster> cool thanks Makyo
<hatch> Makyo let me know when your branch passes CI and then I can review/qa
<Makyo> hatch, failed again, need to finish email first.
<hatch> yeah np
<huwshimi> Morning
<hatch> gooooood morning huwshimi 
<hatch> Makyo rebased and landed your branch
<Makyo> What?
<Makyo> Oh, to huwshimi sorry.
<huwshimi> hatch: Yeah, I realised I hadn't ever done that process for us and was going to get you to walk me through it. That stuff is missing from our docs.
<hatch> :)
<huwshimi> I mean, it's kinda there, but doesn't really explain it for a noob
<hatch> ohh ok yeah in that case, good thing you didn't go all cowboy, it's one of those hulk smash sort of things :)
<hatch> next branch I, or someone else, can give you a run through of it
<huwshimi> hatch: Thanks!
<gary_poster> huwshimi: dirty secret: the rebase can get pretty nasty IMO, or at least I don't know how to do it well either :-)
 * gary_poster running
<gary_poster> have a nice rest of day everyone!
<hatch> ctrl+1 has to be one of the most awkward key combinations 
<hatch> unfortunately the viewletManager has had the databinding engine become part of it
<hatch> :/
#juju-gui 2014-02-05
<Makyo> AUGH
<Makyo> I can't reproduce these CI errors at all locally.
<hatch> Makyo you are creating an environment then doing nothing with it in one of your tests
<hatch> maybe that's it?
<Makyo> Oh?  Hmm..
<hatch> line 1001 in test_environment_view.js
<Makyo> Oh, right.  Hmm.  I got yelled at by jshint for that.
<Makyo> Er, for assigning it to a variable I never used.
<Makyo> But I bet I can find a way around that.
<Makyo> Oh, there's already a global x.x
<Makyo> If this works, I owe you.
<hatch> haha, guess we'll see
<Makyo> Damn, I bet that's it, too.  Just causing weird cascading issues.
<Makyo> ...
<Makyo> ... ... ...
<Makyo> Disregard that, I'm an idiot.
<Makyo> It worked locally because of untracked templates.
<hatch> lol
<hatch> hey, at least you can now reproduce it locally
<Makyo> That'll teach me to use commit -a
<hatch> ahh yeah I always do git add -A
<hatch> ran into the same issue with untracked files
<Makyo> Yep.
<Makyo> It was that.
<Makyo> I'm an idiot.
<Makyo> SIGH
<Makyo> Would appreciate a review/QA tomorrow, if you get a chance, hatch 
<hatch> Makyo yeah no problem
<hatch> Makyo are you still around?
<Makyo> Yep ^^
<Makyo> What's up?
<hatch> QA OK
<hatch> buuuut
<hatch> I keep getting relation change errors 
<Makyo> Huh?
<hatch> it happens in trunk, just wondering if you noticed them too?
<Makyo> I get them with simulator on, yeah.
<hatch> ok so you think it's a simulator bug? I haven't been able to pin down the trigger
<Makyo> I thought we had intentionally added them to the simulator for testing the inspector.
<hatch> well only if relations are created
<hatch> so maybe the change is coming in thinking the relation is still there
<hatch> ok well that at least makes some sense :)
<hatch> it doesn't appear to have any effect on the app so I was just trying to pin it down
<Makyo> Oh, hmm.
<Makyo> Alright, yeah.,
<Makyo> I mean, I'm in there plenty, of late, I'll keep an eye out,
<hatch> sounds good, well review and qa are done
<hatch> now I'm thinking on how to add databinding to the viewlet manager
<hatch> I'm thinking composition of some how
<hatch> it just wasn't written with that in mind
<hatch> anywho...
<hatch> just sitting on the couch with my laptop....probably a mistake hah
<hatch> what work/life balance
<Makyo> Hah!
<Makyo> Go away!
<Makyo> Go away.
<Makyo> I have gin, that's my sign to go away.
<Makyo> Will get to review tomorrow.
<hatch> haha sounds good, have a good night
<rick_h_> frankban: ping, have you seen Import from "ghost-charm-master.zip" failed.<br/>invalid request: invalid YAML contents: unacceptable character #x0003: special characters are not allowed in "<unicode string>", position 2 
<rick_h_> in deploying a local charm? It souded like gary_poster|away had tested the ghost charm but hitting that and not seeing any unicode chars in the config/metadata files?
<rick_h_> oh bah, I didn't use the latest core in this env
<rick_h_> ignore me, will rebuild the env and try again
<frankban> rick_h_: never seen. ok. FWIW, I am trying to release the charm
<frankban> rick_h_: in manage heartbeat the Last ingest job seems to just return datetime.utcnow or similar
<frankban> rick_h_: charm released
<rick_h_> frankban: oooh cool I'll try that first then thanks
<frankban> rick_h_: worked here with the ghost charm and core trunk revno 2295: juju boostrap && juju-deploy juju-gui && juju expose juju-gui && juju set juju-gui juju-gui-source=https://github.com/juju/juju-gui.git
<rick_h_> frankban: thanks, just back from lunch and working on starting it now
<frankban> rick_h_: cool
<frankban> rick_h_: the local charm deployment is awesome
<rick_h_> frankban: yea, I'm excited to show it off. 
<rick_h_> I've got let hatch know it worked out well because the field guys gave a talk on "juju and tools issues"
<rick_h_> and one thing that came out was lack of local charm deployment support and I got to say "We've got it this week"
<frankban> :-)
<rick_h_> which lead to Mark S saying "...you should ask for a unicorn in a month"
<frankban> great
<rick_h_> was cool to have that ready to go/say in front of everyone
<rick_h_> now we just need a better offline/not connected story
<rick_h_> but those were the two issues they mentioned
<frankban> rick_h_: it would be cool to have the deployer file accept URLs to zip files and/or git branches, and the deployer to download the file (e.g. from git) and to use the API to upload and deploy the local charm
<rick_h_> frankban: interesting. We had a talk on new symantics added to bundles today that would be useful info for. 
<rick_h_> I think there's a mission to try to keep the deployer simple, so not sure that the git thing would work, but zips seems like something we could do. 
<frankban> rick_h_: yeah, that would allow people to deploy their topology even if they are launchpad allergic
<rick_h_> frankban: can you file that as a bug/feature request on the deployer?
<rick_h_> hazmat: expressed some interest in getting feature requests to help discuss/go through use cases and I think it's a good one
<frankban> rick_h_: sure
<rick_h_> frankban: for that source you can just do "develop" got the source and it'll pull that repo like you had in your command
<rick_h_> frankban: just fyi
<frankban> rick_h_: so  juju set juju-gui juju-gui-source=develop ?
<rick_h_> frankban: rgr
<frankban> rick_h_: that's cool
<rick_h_> it's the replacement for the idea of 'trunk'
<frankban> rick_h_: filed bug 1276532
<rick_h_> as a shortcut
<rick_h_> frankban: awesome thanks
<frankban> np
<rick_h_> frankban: heads up, going to add #1276541 to the board regarding the recent password text updates
<rick_h_> frankban: you're supposed to just drop it on the cavas right? To deploy the local charm?
<rick_h_> I'm getting Import from "bookie-charm-master.zip" failed. invalid charm archive: bundle file not found: metadata.yaml
<frankban> rick_h_: are you using trunk?
<rick_h_> frankban: yes, 2205
<rick_h_> 2295
<rick_h_> and the charm's version.js is trunk of the gui
<rick_h_> well so juju --version shows 1.17.3-trusty-amd64
<rick_h_> I went into the GOPATH/src/launchpad.net/juju-core folder to check the bzr rev
<frankban> rick_h_: I'll try to reproduce
<rick_h_> frankban: what charm did you deploy?
<frankban> the ghost zip from github
<frankban> rick_h_: where do I find yours?
<rick_h_> I tried https://github.com/hatched/ghost-charm with the 'download zip' and https://github.com/bookieio/bookie-charm the same
<frankban> rick_h_: uhm... weird
<frankban> rick_h_: output from /var/log/upstart/guiserver.log?
<rick_h_> getting 400 Bad Request from tornado
<rick_h_> looking
<rick_h_> [W 140205 11:43:41 web:1635] 400 POST /juju-core/charms?series=precise (41.164.30.187) 358.62ms
<rick_h_> [W 140205 11:43:47 web:1635] 400 POST /juju-core/charms?series=precise (41.164.30.187) 350.50ms
<rick_h_> is all it says
<frankban> rick_h_: if you set builtin-server-logging=debug it will show the whole requests/responses
<rick_h_> frankban: rgr, updating
<frankban> deploying the charm now
<rick_h_> frankban: http://pastebin.ubuntu.com/6878648/ is my updated log
<frankban> HTTP error before end of send, stop sending
<rick_h_> yea
<rick_h_> 400
<rick_h_> :/
<frankban> interesting, so you are on ec2
<rick_h_> right
<rick_h_> what are you on?
<rick_h_> just local?
 * rick_h_ wanted to get an ec2 setup all prepped for the demo running and can leave it overnight ready to go for the morning
<frankban> rick_h_: lxc yes
<rick_h_> frankban: hmm, I created an lxc to build core in so didn't want to try to do lxc in lxc
 * rick_h_ wonders if that'll work :/
<rick_h_> frankban: ok, will add a card to investigate ec2 error. If you get time can you see if you can replicate?
<frankban> rick_h_: sure
<rick_h_> thanks, just to make sure I'm not doing something wrong. Will see if I can get a lxc env setup with juju trunk and try again
<frankban> rick_h_: FWIW your bookie charm works well here in a local env
<frankban> trying ec2
<rick_h_> frankban: ok yea must be provider I guess
<frankban> rick_h_: are you using quickstart to deploy the GUI?
<rick_h_> frankban: no, I didn't
<frankban> rick_h_: ok
<rick_h_> I've got to setup that demo as well. When I tried to use qiuckstart in lxc I ended up with two machines still
<rick_h_> had figured it might work on lxc since it's not sudo enabled now
<frankban> rick_h_: asking because quickstart uses /usr/bin/juju, so it always uses stable juju
<rick_h_> frankban: ah, no I did juju bootstrap && deploy juju-gui
<frankban> rick_h_: yes qs + lxc installs the gui on a new machine, because the bootstrap node in that case is localhost
<frankban> rick_h_: right, that's the same I am doing
<rick_h_> frankban: ah that's right
<rick_h_> frankban: ok, yea it's less impressive demo since it takes a bit to setup the second machine but maybe will do a bundle with the quickstart/gui part already running. 
<frankban> rick_h_: to demo quickstart you might want to use juju-core 1.16 (the new version with "sudo" changes for newer revisions is not yet released
<rick_h_> frankban: well I'll probably just 'show off' the -i and that it does bundles from a url. 
<rick_h_> I've only got a couple of mins for that and for the local charm deploy
<frankban> rick_h_: cool
<frankban> juju-core trunk definitely improves debug-log readability
<frankban> rick_h_: e.g. http://pastebin.ubuntu.com/6878732/
<frankban> rick_h_: what's the output of your ec2 "juju status"?
<rick_h_> frankban: ah sorry, destoryed it. Give me a sec
<frankban> rick_h_: ok, so could you please try to bootstrap it with --upload-tools?
<rick_h_> frankban: ah will do
<frankban> rick_h_: I see agent-version: 1.17.2, and that could explain the errors
<frankban> (recursive zip inspection is on 1.17.3 IIRC)
<rick_h_> frankban: yea I had 1.17.3.1
<rick_h_> rebootstrapping with upload tools
<frankban> me too
<rick_h_> gotta love living on the bleeding edge
<frankban> It's what we're always here to do
<rick_h_> oh yea, I mean glad we're finding this stuff and working it out now vs later
<frankban> rick_h_: FWIW for the demo, given connection oddities etc. I'd feel more comfortable using lxc
<rick_h_> frankban: yea, I just have to resetup juju-core on the base machine vs an lxc container. I wanted to be able to blow it away when I was done 
<frankban> rick_h_: cool
<rick_h_> my mistake
<rick_h_> the setup is annoying with the gopath trying to get it to match where I want my src/etc
<rick_h_> as it creates directories where it wants and does it's own source checked out and all
<rick_h_> so     agent-state: started agent-version: 1.17.3.1
<rick_h_> working on getting gui up and running
<rick_h_> frankban: the other thing for the demo is that the charm network stuff can happen over ec2's network vs mine if I use ec2
<rick_h_> change of getting the charm/up/running quickly seems better that way, but then there's the 'can you connect/upload the charm' issue
<frankban> rick_h_: that's right
<frankban> rick_h_: re core trunk vs stable versions, I ended up using stable and using the brutal script in http://pastebin.ubuntu.com/6878807/ when required
<frankban> rick_h_: I am sure there is a better way, but that does the switch job
<rick_h_> frankban: ah cool, thanks that's helpful
<rick_h_> yea, my first time getting trunk and just getting a feel for some sort of workflow
<frankban> rick_h_: exec /bin/bash there is brutal, but I preferred it rather than having to do the source/eval thing each time
<rick_h_> frankban: ooh, that worked
<rick_h_> frankban: with --upload-tools
<frankban> rick_h_: cool, so that's solved, weird that if you use a local env --upload-tools is not required
<rick_h_> yea :/
<frankban> rick_h_: so the steps are http://pastebin.ubuntu.com/6878853/
<frankban> rick_h_: I presume tools are always copied over in lxc containers
<frankban> rick_h_: I confirm I was able to deploy both bookie and ghost from local charms on ec2
<frankban> this thing is beautiful
<rick_h_> frankban: woot
<rick_h_> hah, got ghost up and exposed and hit the page
<frankban> rick_h_: heh http://ec2-54-195-51-213.eu-west-1.compute.amazonaws.com:2368/
<rick_h_> yay
<rick_h_> now to delete service and see if I can dupe it. Wonder if that works
<frankban> rick_h_: it should, I remember it is possible to upload the same charm multiple times
<rick_h_> cool
<rick_h_> yea, I'll leave this up and running. Looks like demo moved to friday so will keep it up for a couple of days and work on lxc setup and have room for something to go boom
<frankban> sounds good
<frankban> rick_h_: http://ec2-54-220-72-34.eu-west-1.compute.amazonaws.com:6543/ ;-)
<rick_h_> frankban: :) surprised it's ready to go already. Long install time on that one
 * rick_h_ needs to get support for a bundled release/offline-cache in the charm
<rick_h_> that's sweet to see someone deploying that :)
<frankban> :-)
<frankban> rick_h_: so, it's sqlite by default?
<rick_h_> frankban: yes
<rick_h_> frankban: sqlite, whoosh, served with waitress
<rick_h_> the goal is to introduce elasticsearch or solr for fulltext, use charms for that, get the charm to support pgsql (bmark.us is postgres)
<frankban> rick_h_: cool, grabbing some food, see you later
<rick_h_> have fun, thnks for the help!
<bac> trusty has not earned my trust
<gary_poster> rick_h_: hey. glad demo prep is going well.  per "now we just need a better offline/not connected story": you can also announce that today's charm that frankban released (assuming it includes the newest GUI as well) fixes the Google font issue for offline environments if you `juju set juju-gui cached-fonts=true`.  This is connected with work we already did this period to make the charm build by default without any 
<gary_poster> access outside the Juju network.  The only remaining bits that we know of to improve this story are to build proxy support for the charm, which frankban prototyped in CA, and to have a juju-local charmworld, which is a bigger topic than the GUI and already discussed at Capetown.
<rick_h_> gary_poster: cool, will add it to the demo notes. 
<gary_poster> Also, per local fonts, I suggest having an answer worked out with Wm Reade about local charm icons before the demo, because I strongly suspect that will be a question.
<gary_poster> Finally...
<gary_poster> rick_h_: finally, it might be worth reviewing page 6 of the old Juju GUI plans doc for the local charm demo.  Specifically, you can mention the folder drag-and-drop, and the drag-and-drop-local-charm-on-service-to-upgrade
<gary_poster> since I siad that maybe you don't need to review page 6 :-)
<gary_poster> hey frankban, when you get back: does the new charm have a new GUI release also?
<gary_poster> I suspect it doesn't, since latest release of GUI in LP os 0.15.1
<gary_poster> which is great: I know this release was about fixing the broken instruction bug
<gary_poster> for login
<gary_poster> the non FIFO queue still has quickstart in there... https://launchpad.net/ubuntu/trusty/+queue
<gary_poster> but there's action at least
<rick_h_> gary_poster: cool thanks for the heads up. 
<gary_poster> welcome
<frankban> gary_poster: I confirm the new charm release doesn't include the new GUI. new charm is 1) improved login help, 2) imrpoved bundle deployments feedback, 3) support for local charms deployments and 4) cached fonts. 3) and 4) are only effective if you switch juju-gui-source to develop.
<gary_poster> cool thank you frankban
<frankban> gary_poster: I am looking for a next card, the charmworld proxy you mentioned could be one, local charms on the fake backend is another. 
<gary_poster> frankban: let's not do the proxy right now--let's help get the current features out the door
<frankban> gary_poster: sounds good
<gary_poster> frankban: there's a new card in local charms project ("Investigate failing on ec2...").  That's resolved (it just needs --upload-tools), right?
<frankban> gary_poster: yes, that's invalid
<gary_poster> cool thx deleted
<gary_poster> frankban: also bug 1276541 is annoying but real-ish
<_mup_> Bug #1276541: password instructions fails to scroll or fit on laptop screen <juju-gui:Triaged> <https://launchpad.net/bugs/1276541>
<gary_poster> I'm not sure if we support screensizes that small officially
<gary_poster> but it is true that the current instructions go on for days (my fault, kinda, because ISTM we need to say all that stuff!)
<gary_poster> maybe the right thing to do is to ask Rick to get an opinion from luca on the right approach, frankban?
<frankban> gary_poster: yes we need all those instructions, but they are displayed only to users of the old-juju new-charm configuration, which can be considered transient IMHO. yes I agree Luca can help there
<gary_poster> cool frankban.  rick_h_, do you think you and Luca have time to talk about his opinion here on the bug you filed, given the transient nature etc.?
<frankban> rick_h_: transient nature because the message if you use juju >=1.17.3 the message is shorter, and should fit your screen
<frankban> gary_poster: another card is quickstart 1.0.1, but that's not urgent, it just needs to be released before 1.18.
<gary_poster> frankban: <shrug> if that's what you feel like doing, it needs to be done. :-)
<gary_poster> to rephrase: it needs to be done, so if that's what you feel like doing, go for it.
<frankban> gary_poster: :-) I think I'll start investigating the fake backend stuff. never worked on that code so: am I right assuming we need to open the zip and parse all the metadata and config we need to simulate we have that charm in the store?
<gary_poster> frankban: yes, exactly.  We'd plan to use a zip JS library, of which there are at least one and maybe two.  I'd suggest treating this initially as an investigation.  If it looks like it will take more than a couple of days to implement, we should re-evaluate priority.
<frankban> gary_poster: ack, http://gildas-lormeau.github.io/zip.js/ seems cool
<gary_poster> cool, frankban.  other one was http://stuk.github.io/jszip/ , as I suspect you also found
<frankban> gary_poster: a first card could be just re-organizing the code so that we have a xhrHandler passed to the environment, and implementing a real one and the base structure of fake one
<gary_poster> frankban: sounds reasonable.  I spoke briefly about this with Jeff, so he may have some thoughts.  We'll certainly need to share the fakebackend instance with the one used by the websocket.  I think I said that one approach would be to have the websocket wrapper that we already have for prod and sandbox grow a "PUT" API--so it could grow xhr methods or an extra xhr object or they could be completely separate.  That's 
<gary_poster> maybe a bit odd, so if there's a better way +1.  AFAIK the only state is in the fakebackend, so as long as you are sharing that instance you are good.
<frankban> gary_poster: ack thank you
<gary_poster> welcome
<rick_h_> bac: benji can either of you review https://code.launchpad.net/~rharding/charmworld/demo-icons/+merge/204970 please? I'm having lbox issues, but it's a small branch. 
<bac> rick_h_: sure
<rick_h_> bac: ty much sir. If it's ok, can you land it? I'm going to EOD in 10min
<rick_h_> and busy tomorrow and hate to leave it hanging
<bac> rick_h_: will do.  any reason you chose "None" instead of "False" for default?
<rick_h_> bac: no, not really
<rick_h_> just tend to go None for kwargs but could be changed without issue 
<bac> rick_h_: ok, i may change that if you don't mind.
<rick_h_> bac: yep, wfm thanks
<bac> rick_h_: otherwise code looks good and doing qa.  have a good evening!
<rick_h_> bac: thanks, have a good day all
<gary_poster> hey hey jujugui call in 10
<benji> we should change our "team ping" phrase to "hey hey"
<hatch> or how about 'engage' 
<benji> I think that would be "bridge to away team"
<hatch> Ooo that's a good one
<hatch> bridge to away team call in 10
 * gary_poster had to watch a youtube of hey, hey, hey it's fat albert
 * gary_poster is back now
<hatch> haha
<benji> Bill Cosby is in talks to reboot Fat Albert
<hatch> nowadays that show would never make it on air again
<benji> (I kid you not.)
<hatch> it would be considered racist and insensitive 
<gary_poster> I had to google it to see if you were joking
<gary_poster> 'course that reboot thing goes back to 2004 on imdb
<hatch> it's new name would be 'Degrassi' 
<gary_poster> bridge to away team jujugui call in 2
<hatch> lol
<hatch> love it
<gary_poster> hatch you coming?
<Makyo> benji, http://www.youtube.com/watch?v=MYP56QJpDr4
<hatch> jujugui FYI benji is quite a bit better than a rubber duck
<gary_poster> lol
 * benji updates his resume
<gary_poster> I always suspected as much...
<bac> benji: good news is you can no longer accidentally 'lbox submit' on charmworld.  bad news is it gives you an incomprehensible, red herring error message when you try.
<benji> heh
<hatch> since the end of 2012 we have removed 157,713 lines of code from the GUI :-O
<hatch> not sure if that's depressing or not
<gary_poster> s/removed/removed or rewritten or otherwise touched/
<hatch> ohhh kay
<hatch> :)
<gary_poster> :-)
<hatch> acording to github my blog has referred 1 person to our repo
<hatch> lol
<hatch> go blog go!
<hatch> so my mouse was going all over the place and clicking things.....dog was sleeping on my mouse in the other room....lol
<gary_poster> heh
<hatch> Makyo is it cold there now?
<Makyo> -23C
<hatch> -24C here lol
<hatch> I win!
<Makyo> Hah!
<hatch> 82% humidity (somehow)
<Makyo> For certain definitions of "winning", sure.
<hatch> lol
<hatch> after about 15C the dogs no longer like to run around outside it seems 
<gary_poster> Hey Makyo, the icons Spencer gave us were ongs, not svgs.  Is that ok?
<gary_poster> pngs
 * gary_poster thinks "not really"
<Makyo> gary_poster, they should be fine.  If we run into issues later, though, swapping them out is a 30 second branch.
<gary_poster> ok fair enough
<Makyo> gary_poster, I suggest asking for the SVGs, yes, but the swap will be easy.
<gary_poster> Makyo: ok, will do.  So I should keep these pngs separate from the once that we sprite-ify, right?  'cause I'll want to add them as images, not classes
<Makyo> gary_poster, yep. They should go with the exposed/landscape/etc indicators.
<gary_poster> ack thanks
<gary_poster> bac charmworld icons appear to be down?
<gary_poster> no
<gary_poster> sorry
<gary_poster> must be something weird locally
<gary_poster> oh, I still have that annoying demo=true thing turned on locally
<gary_poster> Makyo, ok, so I have a small change that always shows the green icon (http://paste.ubuntu.com/6880180/).  Where's the best place to look to see if I should show green red or grey?
<hatch> OO now that's the big question
<gary_poster> :-)
<hatch> gary_poster you can see how I did it in the inspector
<hatch> one sec I"ll find the right place
<gary_poster> I think he has it stashed away somewhere already
<Makyo> gary_poster, the email I sent huw, though it looks like he didn't get to it.  that attr() call would take a function as the second argument.
<hatch> ohh ok
<Makyo> The first argument to the function is the relation, and you can get relation.aggregatedStatus.
<hatch> Makyo did you hook up aggregatedStatus already?
<Makyo> If we name the files relation-icon-{healthy,error,subordinate}.png, then we can just return "relation-icon-" + relation.aggregatedStatus + ".png"
<Makyo> hatch, no, that was the email I sent to huw.
<gary_poster> Makyo: ack thanks sounds perfect
<hatch> in viewlets/service-relationi.js:38 I generate that, so if we are adding it to the relation model then we should fix it there as well
<hatch> just FYI
<Makyo> hatch, this is the RelationCollection wrapper, but that'll be helpful for the aggregatedStatus attribute.
<hatch> yeah - we should keep the aggregate status up to date in the relation 
<hatch> the issue is that each side of a relation could be bad/good
<Makyo> hatch, this is not a relation, this is potentially several relations.
<Makyo> But if that gets set once, cool.
<hatch> right, but wouldn't it be easy to go relation.get('status') :)
<Makyo> Sure, but this isn't a relation, is all I'm saying, it's an array of relations.  If you want to move that to an attribute on relations, then RelationCollection.aggregatedStatus can take that into account, but they're separate models.
<hatch> agreed
<hatch> ugh somehow my changes to viewlet manager are causing other tests to fail :/
<Makyo> This whole torrents as legitimate distribution channels is great until you forget to throttle. 
<hatch> haha
<Makyo> Got this humble bundle through torrents and brought my network to its knees.
<hatch> yeah I've found when I upload my network goes to crap
<hatch> probably the ISP's stickin it to us
<gary_poster> Makyo: I was confused why aggregatedStatus always was healthy even when there were rel errors until I found the code and associated XXX :-) .  So, my entire branch is http://paste.ubuntu.com/6880301/ .  Is there a precedent/pattern for tests of this, or should we be happy with tests of aggregatedStatus, and I should propose?
<Makyo> gary_poster, I think that's good; the tests will be around aggregated status, don't think we need a test for the image element existing.
<gary_poster> cool.  proposing
<gary_poster> Makyo: https://github.com/juju/juju-gui/pull/108 fwiw
<Makyo> LGTM :)
<gary_poster> :-)
<benji> hatch: I'm looking at the "Create dialogue for selecting series when dropping charm archive" card.  I assume the best way to construct the dialog is as shown here: http://stage.yuilibrary.com/yui/docs/panel/dialog.html Right?
<hatch> benji that's actually what I was working on before this viewlet manager card
<hatch> so it's going to be blocked until then because it needs to render a new inspector
<hatch> sorry I should have marked it as blocked
<benji> ah; ok
<hatch> I don't really have any cards to do now that frankban picked up the fakebackend one
<hatch> I'm very close to being done the one I'm on now
<hatch> but then I was going to continue the branch I was working on before this 
<hatch> actually...
<hatch> you may be able to do the zip lib
<hatch> because frankban  will need to set up the fakebackend infrastructure first
<hatch> before he needs it
<hatch> what do you think of that? 
<hatch> ^ benji 
<hatch> or of course you could pick something else entirely :)
<gary_poster> git power: If I make a PR, then discover I have to make a change, and then make the change and do a rebase with squash, how do I push it back to the PR?  the rebased/squashed branch does not match up with the remote branch
<benji> hatch: sounds good to me; what does "do the zip lib" mean exactly?
<gary_poster> the only thing I know to do is push with :, which seems to delete the branch and close the PR, and then push again
<hatch> benjihttps://plus.google.com/hangouts/_/76cpim786onei1vh0evrn2ds30?authuser=1&hl=en
<hatch> blah
<hatch> benji https://plus.google.com/hangouts/_/76cpim786onei1vh0evrn2ds30?authuser=1&hl=en
<gary_poster> which I will do unless someone stops me soon
<frankban> gary_poster: push -f?
<hatch> gary_poster `git push -f`
<gary_poster> frankban: yes thanks
<frankban> yw
<gary_poster> hatch ^^^ thanks also :-)
<hatch> :) 
<hatch> gary_poster you can also `git push origin <yourbranch> -f` then assuming you have your branches set up properly you can be more-sure that it's pushing to the proper place
<hatch> gary_poster you can find out if you have it set up properly by running `git remote show origin` and make sure the urls point to your fork
<hatch> Y.mix() I'll never remember your syntax
<hatch> jujugui looking for a review https://github.com/juju/juju-gui/pull/109
<hatch> easy qa!
<hatch> :)
<gary_poster> I will take it in 15 or 20 if there are no takers by then
<hatch> sounds good, I'll go grab some lunch now then
<gary_poster> cool
<bac> gary_poster: i've been getting lots of churn on the calendar for daily standup.  are those real changes or is my calendar screwy?  i don't see any real changes.
<gary_poster> bac, i hain't done nothin.  
<bac> huh
<hatch> bac yeah I get those too
<Makyo> I want my clock widget back :(
<Makyo> gary_poster, ping.  Np if not worth it today, don't have anything except cards.
<gary_poster> Makyo: hey.  I got my clock widget back after software update and reboot fwiw
<Makyo> gary_poster, Oh, okay.  Will try reboot soon.
<Makyo> Just did update.,
<gary_poster> I don't have anythingto talk about if you don't.  I'm lame duck manager, Makyo :-)
<Makyo> It's a sign of a smooth week, I say :D
<gary_poster> heh ok
<gary_poster> hatch :shipit:
<hatch> :) thanks
<hatch> hey benji any progress on the zippyness?
<hatch> i'm very curious :)
<benji> hatch: notthing significant; it looks like it'll work
<hatch> *phew*  :)
<rick_h_> cool, looks like we'll want the zippyness for bundles in the not so distand future as well
<hatch> rick_h_ shouldn't you be sleeping? :)
<rick_h_> hatch: not yet, only 9pm
<rick_h_> just got back from team dinner
<hatch> ohh I thought it was a bigger difference 
<rick_h_> so it go through today's notes/email the family time
<rick_h_> 7hrs
<rick_h_> well, from est
<rick_h_> oh sorry, it's 10pm
<rick_h_> I can't do math...tired. Guess I should be in bed
<hatch> haha
<hatch> have you done the Table Mountain trip too?
<rick_h_> no, I don't think I'll get out to it. 
<hatch> aww darn, the pictures look awesome
<hatch> is it far away?
<rick_h_> yea, it's like 45min and you've got to arrange a car to drive you out/back
<rick_h_> and the last gondola leaves around 7pm or someting
<hatch> ahh so not very convenient with work and stuff
<rick_h_> yea, unless you bail right at 5pm which some folks did
<hatch> so does the area feel safe? 
<hatch> the internet is awash with "oh it's so dangerous there"
<rick_h_> well, we're in groups. All the houses have walls and spikes with electic fence tops on top
<rick_h_> so it's a bit 'wtf'
<hatch> yeah that's a little crazy
<hatch> rick_h_ are you going to have any time this week to chat about the left panel (browser area) ?
<rick_h_> hatch: should be able to. 
<hatch> cool just let me know whenever, I'll be available 
<rick_h_> hatch: ping me when you get in and I'll try to find a slow
<rick_h_> I don't usually have something every half hour
<hatch> I start at....4PM your time
<rick_h_> hatch: hmm, got time and konw what yuo want now? 
<hatch> yep
<rick_h_> hatch: because I've got a design thing at 4pm tomorrow right now and think we'll be closing up by 4pm on friday
<hatch> cool sec I'll grab a link
<hatch> maybe....
<hatch> https://plus.google.com/hangouts/_/7ecpj6psm7t3stjt2p0o8v2n9s?authuser=1&hl=en
<hatch> there we go
<rick_h_> k, we'll see how the mifi does
<Makyo> jujugui one more review (no QA needed) would be nice: https://github.com/juju/juju-gui/pull/107
<bac> Makyo: i'll do it
<Makyo> bac, cheers, thanks
<hatch> rick_h_ yeah the stream tanked
<hatch> but I got what you were saying
<rick_h_> hatch: sorry, yea tanked and mifi needed a charger
<rick_h_> hatch: cool, appreciate your input on that. It may not work out and be crazy, but think it's worth a look
<hatch> yeah no problem
<bac> Makyo: done
<Makyo> bac, thanks
<Makyo> jujugui got gaierror: [Errno -3] Temporary failure in name resolution in functional tests
<Makyo> On CI, sorry.
<Makyo> Any ideas?
<hatch> try it again, see how temporary it really is :)
<gary_poster> heh +1
<Makyo> I forget, did we figure out a way to re-trigger tests?
<gary_poster> yes, was getting it for you 1 sec
<gary_poster> https://github.com/juju/juju-gui/blob/develop/docs/continuous-integration.rst#manually-running-a-build
<gary_poster> Makyo: ^^^
<Makyo> cool, thanks!
 * gary_poster <3 github doc rendering
<hatch> yeah it's pretty isn't it
 * gary_poster thinks github > git
<hatch> github made git :)
<gary_poster> did not
<hatch> *popular
<gary_poster> ah ok :-)
<hatch> haha yeah
 * Makyo blasts Britten's War Requiem to make Jenkins console watching a little more dramatic.
<Makyo> Tests passed that time, but the PR didn't pick up on it.  Alright if I just link the passing tests in a comment?
<Makyo> jujugui ^^^
<hatch> yeah that should be fine
<hatch> it'll rerun the ci on shipit 
<hatch> anyways
<Makyo> Yep
<huwshimi> Morning
<hatch> hey huwshimi 
<hatch> huwshimi I assigned you a card (which is blocked until tomorrow) to style the new 'select series' inspector for local charm. Will you have time to do it tomorrow?
<huwshimi> hatch: I can
<hatch> awesome thanks, when you get in tomorrow we can have a quick chat so I can show you what it is
<huwshimi> hatch: Great, that'd be handy :)
<hatch> haha, I was trying to get it done for today but no luck, too much typing :P
<huwshimi> :)
<huwshimi> hatch: Have you used the GUI on Safari?
<hatch> I have
<huwshimi> hatch: Have you noticed many problems?
<hatch> it's a little borked
<hatch> looking again
<huwshimi> hatch: Care to elborate? :)
<huwshimi> Ah thanks :)
<hatch> hah sorry just need to switch modes
<huwshimi> I've noticed some minor presentation issues, but nothing major
<hatch> hmm
<hatch> I could have sworn there were issues
<hatch> well bundle export is broken
<hatch> but you know about that one I think
<huwshimi> yeah
<hatch> somehow I got all of the charms to show at the top of the screen
<hatch> trying to repro
<hatch> ok I can't get that one to repro but I have another
<hatch> Click a charm in the charmbrowser and look at the tabview content slide down, click another charm, see it again
<hatch> ^ huwshimi  can you reproduce that one?
<hatch> there is also a mask of some sort that's rendered in the middle of the window when switching between charms in this regard
<hatch> oh that happens in chrome too
<hatch> but the sliding down bit is only in safari
<hatch> I'll create two bugs
<huwshimi> Yeah, I see the sliding down.
<huwshimi> The tabview is the most broken thing in Safari it seems
<hatch> https://bugs.launchpad.net/juju-gui/+bug/1276844
<_mup_> Bug #1276844: Switching charm details views in Safari causes details to scroll <juju-gui:Triaged> <https://launchpad.net/bugs/1276844>
<hatch> tabview bug
<huwshimi> Thanks
<hatch> https://bugs.launchpad.net/juju-gui/+bug/1276845
<_mup_> Bug #1276845: Switching between charms renders modal mask in center of window <juju-gui:New> <https://launchpad.net/bugs/1276845>
<hatch> other chrome modal mask bug
<hatch> yeah other than that safari bug and the bundle export I can't see anything wrong on sandbox
<huwshimi> Thanks
<hatch> ...well Rachael Ray what are we making for supper...
<hatch> huwshimi https://www.evernote.com/shard/s219/sh/8c0f1d1f-31ad-4da0-a1bf-ac30ad178306/a843eb38ae9cf7eb188094ac6c0b3065 this is what you're going to be left with :) sorry
<huwshimi> lovely
<huwshimi> hatch: Do we have designs for this bit?
<hatch> huwshimi nope
<huwshimi> Yay!
<hatch> haha, yep
<hatch> yuss it works....ok I'm off, will write tests and get this landed for you for tomorrow huwshimi 
<huwshimi> hatch: Thanks, have a good evening
<hatch> have a good day
<hatch> cya
<huwshimi> bye
#juju-gui 2014-02-06
<rick_h_> frankban: ping, around?
<bac> hello rick_h_.  haven't seen frankban yet, perhaps he's lunching
<frankban> rick_h_: I am back from lunch
<rick_h_> frankban: howdy, I talked to william and talked about the charm GET. He asked that you and dimiter get together. They're ok with an api with individual file access as long as we realize that it's a very expensive experience for now
<rick_h_> frankban: the plan is for them to work on getting files into mongodb gridfs vs the provider storage so it'll get better with time
<rick_h_> frankban: but they're ok on an api that's designed to be finer grained
<rick_h_> frankban: does that sound like what we needed to run by them for that or is there more I should make sure to push for/bring up?
<frankban> rick_h_: just to have some context, we need charms GET to retrieve the files we need for the local charm story (e.g. readme and icon) right?
<rick_h_> frankban: exactly
<rick_h_> frankban: and I told him that two were the two big ones we want. I got the icon as well because for some charms the vendor/branding will be important
<frankban> rick_h_: and we currently fetch those from charmworld
<rick_h_> frankban: the one thing I wanted to verify is if we get config AND metadata from juju without this? or juts config?
<rick_h_> frankban: yes, but for local charms we want to be able to get them from juju and for now, we need to deal with caching appropriately so that we don't ask for it more than once
<rick_h_> but that's on the Gui to use it properly while the api/design in juju will be more open to multiple files/any file in the charm
<frankban> rick_h_: yes I think we need config.yaml and metadata.yaml as well
<rick_h_> because once it's in mongodb, the performance aspect will be mitigated
<rick_h_> frankban: well we get config from juju right? 
<rick_h_> I mean if we don't how does local charm deploy work now?
<frankban> rick_h_: ah! yes, from the ws API
<rick_h_> frankban: right, so we need to make sure we ONLY use this new api for things we REALLY need/can't get any other way
<frankban> rick_h_: sounds good
<rick_h_> frankban: cool, let me know if anything comes up from that I can help middle-man with
<rick_h_> I guess dimitern is the guy to talk to on the nitty gritty from here
<frankban> rick_h_: if I click to open the charms detail panel from the GUI, the missing tabs for local charms are: readme, configuration (I don'y know why, given we should have it from juju), code and features
<rick_h_> frankban: right, and so we're not going to have feature, we're not going to show code until the implementation is fixed to make it inexpensive, and we'll try to get readme/config in there
<rick_h_> is my understanding 
<frankban> rick_h_: yes, to show code we would need to retrieve all the files inside hooks/. the plan you described sounds reasonable
<frankban> rick_h_: how do we currently handle the charm icons? are they cached, do we store them in some way in our db?
<rick_h_> frankban: no, right now we link via http to them from manage.jujucharms.com and let the browser deal with the caching/etc
<rick_h_> frankban: we'll have to be smart about it and figure out how to embed/deal with that
<rick_h_> frankban: and one answer might be to use the charm server as a cache to link to and enable us to treat them the same, but at a local url vs manage.jujucharms.com?
<rick_h_> frankban: but that's just tossing stuff out 
<frankban> rick_h_: this needs to be changed, for at least two reasons: 1) what you mentioned (avoid calling juju HTTPS when not strictly required) and 2) we might want to display icons for local charms in sandbox mode.
<rick_h_> frankban: well, there's more to that. We can talk about it later
<frankban> rick_h_: ok cool
<rick_h_> bac: do you need a credential file to use ingest on charmworld? I'm trying to give the guys a bundle to deploy to local LXC to be able to setup an offline demo but it's not ingested reviewed charms? https://pastebin.canonical.com/104358/
 * bac looks at paste
<rick_h_> bac: I managed to get 186 charms, but that's it. almost all the log is about bundle errors because of charms not found
<bac> rick_h_: i need context.  you're running charmworld locally and getting that output pasted?
<rick_h_> bac: rgr, I'm using an lxc environment to deploy charmworld, ES, and mongodb and try ing to see if I can get it to run and ingest everything so you can put a Gui in that environment and do a presentation 'offline' since everything is in your lxc environment
<rick_h_> the idea being an IS guy giving a talk can use lxc to setup things the day before, then present without wifi
<rick_h_> bac: but it's only ingesting 186 charms and the only error/issue I can see in the log is p_credentials path doesn't exist: /home/webops_deploy/charmworld/charmbot_credentials.txt and wondering if that means anything to you?
<rick_h_> are you aware of what should go in there and if missing that would prevent some charms (all the reviewed ones?) to not come down
<bac> rick_h_: yeah, in that case you're either going to need a specific credentials file configured in the charm or perhaps defer to a system-wide lplib credential
<rick_h_> ingest is running, and clears. but it's doing the 186 and 27 baskets
<bac> rick_h_: what's your time frame?  can i work offline to get it running and document the process for you?
<rick_h_> bac: sure thing. I just told them I'd look into it. Doesn't have to be this week but should give them a bundle/process that works next week sometime
 * rick_h_ hoped it'd be simple and whip it up real quick. 
<bac> rick_h_: oh, great.  i was afraid you were in need of an answer ASAP and it's not something i have on the top of my head
<bac> rick_h_: let me review the deploying on staging document and see.  i'll ping you shortly
<rick_h_> bac: no, I was just asking if you had any hints for me off the top of your head :)
<rick_h_> bac: thanks! appreciate it
<bac> rick_h_: but i've never deployed the charmworld charm locally
<bac> as it is a bear
<rick_h_> bac: heh https://pastebin.canonical.com/104361/ is the bundle file I exported. The thing to update is the charmworld url in the gui to whatever charmworld comes up as 
<rick_h_> it's pretty close apart from the missing charms. Heartbeat shows it running and processing nicely
<bac> rick_h_: nice
<gary_poster> hey benji, have to take Julia to pre-school at 9.  Will ping when I return? 9:15 or 9:20 tops, I think, if everything goes as usual.
<benji> gary_poster: sounds good
<gary_poster> ty
<bac> rick_h_: to your original question, the lp_credentials is only needed for the review job.  so it shouldn't have any impact on the demo you want to do...unless you want to show the review process
<bac> has nothing to do with ingest
<frankban> jujugui FWIW, rather than rebasing-hell, this approach (suggested by gary_poster) seems to work very well: http://pastebin.ubuntu.com/6885477/
<hatch> that's a lot of steps :)
<gary_poster> make an alias :-)
<frankban> hatch: the good part is that you don't have to think hard on each step
<hatch> I suppose the only issue with it is that you may run into issues merging your changes into a fresh develop
<hatch> so you would have to do it manually
<frankban> hatch: there can be conflicts, but istm less scary than rebasing. 
<hatch> right, I was just meaning with relation to an alias
<hatch> unless an alias will bail out at that point
<hatch> so far my aliases have been very simple
<gary_poster> qa-pr is simple? :-)\
<hatch> frankban gary_poster could we not use squash when merging our branches into develop via the CI?
<hatch> I don't use any of the gui aliases :)
<hatch> git merge --squash
<hatch> that is
<hatch> if it did work... we could pull the commit message from the message with :shipit: in it...maybe?
<frankban> guihelp: I need two reviews + QA for https://github.com/juju/juju-gui/pull/110 (upload charm in sandbox mode preparation) thanks!
<hatch> on it
<frankban> hatch: thanks
<hatch> frankban curious, what does --upload-tools do? The help only says that it 'uploads a local version of the tools' which isn't very helpful :)
<frankban> hatch: if you use a local env that's optional. but if you use, e.g. ec2 with juju-core trunk, it uploads the juju-core binaries from your own build to the cloud, so that ec2 runs exactly what you compiled
<hatch> ohh gotcha - ok yeah I'm running local
<hatch> thanks
<bac> frankban: where do the guiserver logs get written?
<hatch>  /var/log/upstart
<frankban> bac: ^^^
<hatch> which apparently isn't a freenode command :)
<bac> thanks hatch & frankban
<bac> glad i asked...it may have taken me a while to find them there!
<gary_poster> jujugui call in 10
<gary_poster> bac, it's in the charm HACKING.md.  The last section of that doc has some nice debugging tips
<bac> thanks
<frankban> hatch: replied to some of your comments in the review, thanks (and github "real time" conversation in reviews is cool)
<hatch> :) cool, they were all pretty trivial, I'm just doing the qa noq
<hatch> now
<frankban> cool
<gary_poster> jujugui call in 2
<hatch> frankban when running in sandbox in make-prod whats the password for the gui?
<frankban> admin?
<hatch> oh duh
<hatch> hazmat I read that you have a local provider demo for digital ocean?
<hatch> interesting...if you stub Y.one() it also stubs Y.Node.create()
<hatch> var oneStub = testUtils.makeStubMethod(Y, 'one', 'asdfasf');
<hatch> both return the return value
<gary_poster> jujgui, great news: james page reports to rick that quickstart is in trusty universe now.  Yay!  Moreover, he's actively helping us to get it in main as well, so that still might happen.  Double yay!
<gary_poster> jujugui ^^
<hatch> yay
<frankban> :-)
<gary_poster> and meanwhile, I'm going to pick up my daughter from preschool.  biab
<frankban> benji: is evaluating a js zip library part of your current card?
<Makyo> frankban, LGTM
<frankban> Makyo: great thanks
<benji> frankban: yep; it's looking like zip.js (http://gildas-lormeau.github.io/zip.js/fs-api.html) is going to be best for the present with a little future-proofness built in
<frankban> benji: cool thanks
<hatch> that's the one I was leaning towards as well :)
<gary_poster> Makyo: https://github.com/juju/juju-gui/pull/111 :-)
<hatch> so.....much......testsssssss
<hatch> eyes....bleeeeding
<Makyo> Might want to see a doctor about that.
<Makyo> +1, gary_poster :)
<gary_poster> cool thanks Makyo :-)
<benji> hatch: is it intentional that a user can drop multiple zips at once and have them all deploy?
<hatch> benji yes but untested
<hatch> I'm assuming that works?
<hatch> :)
<benji> I haven't tried it.
<hatch> I say untested because it's not really 'supported' there are other issues like the ghost inspectors poping up and stuff
<hatch> it will loop through the files that are dropped and do what it will with them
<benji> hatch: In that case I won't preserve the behavior.
<hatch> sounds like a plan
<hatch> +1
<benji> cool
<bac> gary_poster: just noticed staging.jujucharms.com is completely gone
<bac> gary_poster: will re-deploy it all.
<gary_poster> bac, eek.  OK thank you.  I guess that is fun from the canonistack upgrade
<bac> yeah
<bac> gary_poster: do you know the urgency of the debug=true query string for icons for rick?
<gary_poster> not really bac
<bac> ok. well a functioning staging with it QAed there is a pre-req for a rollout
<bac> hi abentley, you around?
<abentley> bac: Hi.
<hatch> jujugui looking for a review/qa https://github.com/juju/juju-gui/pull/112 I need this one landed before Huw gets in so he can style it....plz and thanks
<benji> hatch: I'll take a look.
<hatch> thanks!
<hatch> gary_poster your branch failed to be merged into develop
<gary_poster> hatch, bah and thanks
<hatch> doesn't give much of an error message though :/
<hatch> np
<benji> hatch: I've never done QA using github, how do I get your branch?
<hatch> benji at the bottom of the conversation list there is a link 'command line'
<hatch> in the section that says Merge with caution!
<hatch> copy and run the first TWO commands
<hatch> do NOT to step 2 :)
<hatch> do*
<benji> ah, it's hidden under "Merging via command line"
<hatch> yeah, we don't want to do that though :)
<hatch> but that way you can just click to copy and don't have to type it out
<gary_poster> benji, the HACKING doc has another approach from Rick that I use fwiw
<benji> gary_poster: thanks; I looked in there but nothing jumped out at me 
<gary_poster> benji, the qa-pr alias is the trick
<bac> jujugui: staging.jujucharm.com rebuild is going slow but seems to be coming up now.
<gary_poster> ack thank you
<benji> hatch: review done
<hatch> thanks
<rick_h_> party party
<gary_poster> what the heck are you doing around rick_h_? :-) it must be well past midnight
<rick_h_> 11pm
<rick_h_> just got back from  evening out. bus down to the waterfront mall area straight from the office today
<gary_poster> ah ok
<gary_poster> cool
<gary_poster> pretty?
<rick_h_> meh, it was a mall. Nice to walk around and such
<rick_h_> can see the tabletop mountain though which was cool
<hatch> rick_h_ https://github.com/hatched/juju-gui/blob/select-series/app/views/viewlets/request-series.js see viewlets do rock when they are used like they are supposed to be :P
<hatch> haha
<hatch> benji you and your empty return values :P
<rick_h_> hatch: where's the rest of it?
<hatch> that's it
<benji> I think it's not just me.
<rick_h_> hatch: like the events, the trigger on drop, the updating the value 
<hatch> rick_h_ well that doesn't exist yet
<rick_h_> hatch: so not so simple if it doesn't work :P
<rick_h_> yes, showing a template is easy...yay!
<hatch> lol
<hatch> I added a card to add events to the viewlets :)
<rick_h_> I'll add a card to change viewlets to views :P
<hatch> that's actually pretty trivial to do
<rick_h_> demo of quickstart deploying a bundle and local charm first thing in the morning
<rick_h_> hatch: yep, was going to make it card #1 for moving inspector to the left
<hatch> well that's not really part of moving the inspector
<rick_h_> jcasto is going to do a quickstart thing as a lightning talk he says
<rick_h_> he was blown away when he had to reinstall his machine and did a juju bootstrap and got that juju wasn't installed
<rick_h_> but did juju quickstart and it got all setup
<rick_h_> hatch: sssshhhh, yes it is :)
<hatch> huw should have styled the series selection by your morning
<rick_h_> meh, I'll keep it where it's at right now. It just drops
<hatch> I was thinking of keeping viewlets and not using views so that we didn't have to create new instances all the time
<gary_poster> bac, mjc down?
<hatch> ohh ok, don't update from develop then
<gary_poster> oh, back now
<rick_h_> hatch: but creating and cleaning instances ftw
<rick_h_> explicit but whatever, we can chat. I had thought we had agreed to tweak that
<hatch> I did, then I started looking at the extra cruft that it brings
<hatch> a Y.VIew
<rick_h_> since I'm on a dial up moden over here and hard to discuss 
<rick_h_> modem
<hatch> 56k?
<hatch> :P
<rick_h_> heh, 2G on the mifi at the moment
<rick_h_> that's like..half the G's I like
<hatch> no longer the same ol' G
<rick_h_> ooh, bac you doing a mjc deploy? or is that for next week?
<gary_poster> hey Makyo, I was looking at implementing aggregatedStatus.  So, looks like I walk the relations, then for reach relation, I have to walk the units of the source and target services to see if there is an error with the agent_state_data.hook value with a corresponding interfaceName + '-relation-changed' for the relation.  Is that 'bout right?
<Makyo> gary_poster, I wound up doing that as part of my branch.  Want to compare notes?
<gary_poster> Makyo: nm, if you've done it.  Was trying to be helpful. :-)
<gary_poster> happy to talk if you'd like to but otherwise will look about for something else
<hatch> gary_poster https://github.com/juju/juju-gui/blob/develop/app/views/viewlets/service-relations.js#L38
<Makyo> gary_poster, no worries! Was working on relation status for the icons in the menu, and realized I had to type 5 lines to get the aggregated status in there.
<hatch> I'd love it if we could somehow move that into the relation objects
<gary_poster> hatch would be difficult because relations don't have direct references to services
<gary_poster> could instead make helper function
<gary_poster> usable in isolation or this kind of context
<hatch> yeah right, I was thinking that there should be something in the db (util method) because it would then have access to it all
<Makyo> gary_poster, I came up with http://pastebin.ubuntu.com/6887685/
<hatch> It would also be nice if a service had reference to it's relation objects
<gary_poster> Makyo: how can relation.hasRelationError() work, given the lack of references I was just mentioning?
<Makyo> gary_poster, http://pastebin.ubuntu.com/6887690/
<Makyo> DecoratedRelations do.
<gary_poster> oic
<Makyo> That's currently on the decorated relation, but it could go on the relation model as well to be used by the viewlets.
<gary_poster> Makyo: that last pastebin is too fragile, I think: if a unit has *any* relation error it will declare all relations it has to be in error
<gary_poster> Makyo: I think you need to do what I descrbed above: see "if there is an error with the agent_state_data.hook value with a corresponding interfaceName + '-relation-changed' for the relation"
<Makyo> gary_poster, It's the same logic as hatch 's link, but yeah, I'll look into it.
<gary_poster> ah, yeah, that's broken too :-/
<Makyo> But like I said, I can store this on the relation model rather than the decorated relation, and then the viewlet doesn't need to do it either.
<hatch> the issue with the viewlets one is that a relation can be both good and bad
<gary_poster> Makyo: but relation model doesn't have source/target
<hatch> depending on which service you're viewing it from
<hatch> whereas in the relation line if either end is bad, the whole thing is bad
<gary_poster> hatch, but that logic is also broken if you have multiple relations betwen the same two servcies
<gary_poster> or actually no
<Makyo> gary_poster, but we have that when decorating the relation.
<hatch> do we want to chat in a hangout? :)
<gary_poster> a unit can have any relation error 
<gary_poster> ok sure
<gary_poster> I nominate hatch to make the hangout :-P
<hatch> on it
<gary_poster> :-) thx
<hatch> https://plus.google.com/hangouts/_/7acpiti1mnfe553mh8r2l4flqc?authuser=1&hl=en gary_poster  Makyo 
<Makyo> hatch, please invite makyo@drab-makyo.com
<hatch> on it
<hatch> done
<huwshimi> Morning
<hatch> hey huwshimi 
<Makyo> Dogs are being ridiculous (part of my frustration on the call, sorry).  Gonna get them out for walks before they drive me up the wall.
<hatch> :)
<hatch> huwshimi develop now has the series selector inspector in it
<huwshimi> hatch: Ah brilliant
<huwshimi> hatch: How do I trigger it?
<hatch> drag a file with a .zip extension onto the canvas should work....
<hatch> i think frankban's fakebackend code landed with enough functionality
<hatch> let me check
<hatch> one minute
<huwshimi> hatch: That worked. I'll style it then!
<hatch> awesome yup it works
<hatch> a few branches landed just in time for you to not have to do a bunch of setup
<hatch> :)
<hatch> huwshimi so basically, the rules are.......do whatever you want with the styling :D
<hatch> benji you wouldn't happen to be around still hey?
<benji> hatch: not really
<benji> :)
<benji> what's up?
<hatch> haha, just looking for a quick update on the zip stuff. I'm trying to decide what to do next
<benji> I've moved into the implementation phase.  Nothing of note to report yet.
<benji> The tests for the existing code are a little sparse, so that's not helping.
<hatch> alright in that case I'll move outside of project 1 for now
<hatch> thanks
<hatch> enjoy your night :)
<benji> later
<hatch> huwshimi hey, just for planning tomorrow, do you think you'll be done with the styling and such by your EOD?
<huwshimi> hatch: Just pushing now!
<hatch> oh haha perfect :)
<huwshimi> hatch: https://github.com/juju/juju-gui/pull/113
<hatch> on it!
<hatch> oh man that looks about 1Billion times better
<huwshimi> :)
<hatch> huwshimi small idea from qa added to the review
<huwshimi> hatch: I'm not quite sure what to do...
<bac> jujugui: http://staging.jujucharms.com/heartbeat up but mildly disgruntled
<bac> hi huwshimi!
#juju-gui 2014-02-07
<huwshimi> Hey bac!
<hatch> I gota run for an hour or so but huwshimi  when I get back I can answer any q's
<huwshimi> sure
<hatch> huwshimi hey back, so any other ideas on implementation or do you just want to land it as is?
<huwshimi> hatch: Apologies I was eating lunch
<huwshimi> Oh
 * benji wonders how often huwshimi eats sashimi.
<huwshimi> Mmm... sashimi
<rick_h_> frankban: demo went off awesome. I've had several people pull me aside to say it was awesome/impressive including Mark S
<frankban> rick_h_: \o/
<rick_h_> so big case of Gui rocks!
<rick_h_> :)
<frankban> rick_h_: very cool, so this was the local charms, right?
<rick_h_> local charms, and then while that deployed I used quickstart -i to choose a non-default environment, and deploy the mongodb cluser bundle 
<rick_h_> so hit both together and blew them away
<frankban> rick_h_: great
<bac> hey rick_h_
<dimitern> rick_h_, awesome! so no issues with local charm uploads?
<rick_h_> dimitern: nope was awesome. we've got some polish to do, but great demo.
<dimitern> rick_h_, perfect! is there a deployed gui with local charms support? staging or something?
<bac> he benji you around?
<bac> rick_h_: ping
<benji> bac: yep; what's up?
<bac> benji: i've got a bundle inheritance question.  you up on that?
<bac> benji: looky here:  http://bazaar.launchpad.net/~bac/charms/bundles/charmworld-demo/bundle/view/head:/bundles.yaml
<benji> I haven't done anything with bundle inheritance, but I'm looking at it :)
<bac> benji: ok, i thought you had.  quickstart hates it.  i'll figure it out
<benji> bac: I don't know for sure, but I think the charmworld-production is missing the "services" key.
<benji> elasticsearch and mongodb should be under a "services" key
<bac> ah, right
<rick_h_> bac: pong
<bac> rick_h_: hey i got a modified version of that charmworld bundle deployed in lxc.  the only tweak required was to change charmworld_import_limit to -1
<bac> charm ships with 110, so you were seeing 110 bundles + back versions
<rick_h_> bac: oh!
<rick_h_> doh
 * rick_h_ is so tired, but should have seen that
<gary_poster> hey rick_h_, glad the demo went so well. :-)
<rick_h_>  gary_poster woot
<bac> jujugui: anyone ever use 'juju destroy-environment --force'? does it clear out stale 'provider-state' and other files that make juju think it is bootstrapped when it isn't?  (i just did i manually before discovering --force)
 * gary_poster has never used
<bac> jujugui: the lcy02 maintenance a few days ago knocked the charmworld CI off-line and it went unnoticed.  it is alive again.
<benji> I wonder if there is a simple and effective dead man's switch we could implement for that.
<rick_h_> jujugui added a customer bug to the kanban in urgent. It's an odd one. Customer has a workaround but if anyone gets a chance to poke at it appreciate it
<rick_h_> I've told them we'd not have a fix until next week, so no one ruin their friday/weekend on it, but want to make sure we're responsive to them. 
<gary_poster> rick_h_: that may well be something specific to that charm.  Do you know the OpenStack charm guy?  He's probably there.
 * gary_poster tries to remember name
 * gary_poster has face...
<rick_h_> gary_poster: ah, james?
<gary_poster> no
<gary_poster> he might know anyway
<rick_h_> k, everyone is running for the hills so will see what I can find out
<gary_poster> rick_h_: adam gandelman
<gary_poster> though, yeah, james has more commits than I expected https://code.launchpad.net/~charmers/charms/precise/nova-compute/trunk
<hatch> lol has face
<gary_poster> :-P
<rick_h_> ok, going afk until probably sunday when I get back to the US. have fun all!
 * rick_h_ ran out of mifi data 2gb in one week :/
<gary_poster> bye rick_h_, safe travels
<bac> frankban: do you know why quickstart/deployer would reject root-disk as an invalid constraint?
<hatch> cya rick_h_  have a safe trip
<gary_poster> bac, don't we whitelist constraints?
<gary_poster> and I don't recall root-disk as a standard one
<bac> gary_poster: is this wrong: https://juju.ubuntu.com/docs/reference-constraints.html
<gary_poster> bac, unlikely, but it may well be *new*
<bac> ah
<bac> gary_poster: perhaps, but it has been part of the manual charmworld deploy, presumably for a while
<frankban> bac: the first whitelist I see in the stack is ALLOWED_CONSTRAINTS in guiserver/bundles/utils.py
<frankban> ALLOWED_CONSTRAINTS = ('arch', 'cpu-cores', 'cpu-power', 'mem')
<frankban> bac: we should update that list if core introduces new constraints
<frankban> and I am not sure about deployer's own validation, but it's worth looking there too
<bac> frankban: agreed.  and proof should match too.  annoying to get a false positive from the cheap test of proof only to have it fail later.
<bac> frankban: as shown here https://juju.ubuntu.com/docs/charms-constraints.html, the constraints list is space-separated for the command-line.  guiserver forces comma-separated.
<bac> frankban: should we support both?
<frankban> bac: we need to support what is supported by the deployer
<gary_poster> (and only that)
<frankban> bac: which can be different by how things are spelled in the juju-core cli
<frankban> bac: what we ideally need is a shared/simple/complete/tested bundle validation Python library that can be used by proof/quickstart/guiserver/deployer...
<bac> preach!
<frankban> :-)
<gary_poster> :-)
<bac> frankban: and when we do, it would be nice if it matched what the juju-core CLI and documentation expects
<gary_poster> crazy talk\
<gary_poster> we part ways there
<bac> gary_poster: you being funny, no?
<gary_poster> bac, I am hilarity incarnate
<bac> which is proven by folks having to ask.  :)
<gary_poster> exactly :-)
<bac> i understand.  my humor goes unappreciated here.
<bac> here = my house
<gary_poster> heh
<bac> abentley: the charmworld ci process seems to be partially dead.  could you give me some pointers?  chat?
<abentley> bac: sure, but opt right now.
<abentley> OTP
<bac> abentley: np.  eta?
<abentley> 10
<bac> thanks
<abentley> bac: Okay, how can I help?
<bac> abentley: let me invite you to a hangout
<frankban> guihelp: what do I need to do in the GUI to add an external js lib (except for adding that in the assets and loading it in index)?
 * gary_poster seems to recall docs in this direction.  looking
<hatch> frankban see merge-files
<hatch> it's in bin/
<gary_poster> (and lib)
<hatch> the one in lib is just the script, the one in bin is the one which has the 'extras' list
<hatch> which I've kind of always found odd
<hatch> heh
<frankban> hatch: so I have to push new libs in that filesToLoad.js, correct? anything else in the Makefile?
<gary_poster> hatch are you looking at huw's branch to make it landable per your qa, or should I or someone else?  https://github.com/juju/juju-gui/pull/113
<gary_poster> frankban: other thing: add a section to hacking doc describing what you did :-)
<hatch> frankban that's it, nothing else required in the makefile
<frankban> gary_poster: yeah I was thinking about that :-)
<hatch> gary_poster yeah I think I'm going to pull it down and make some small changes and then re-push
<gary_poster> ok thanks
<hatch> gary_poster I'm also going to be working on adding view support to the viewlet manager
<hatch> did you have anything else in the pipe you would like ahead of that?
<hatch> in other news I was finally able to get my afp:// mount working
<gary_poster> making notes, will be with you in a sec
<hatch> *barf* this new coffee is horrid 
<hatch> benji any updates on the investigation? Boards still have it in starting
<benji> hatch: I need to update the board.  I'll do that now.  The current situation is that I'm fighting with the testing infrastructure.
<hatch> want to pair on it? Or is it just something you need to slog through?
<gary_poster> hatch, viewlet -> view is good.
<hatch> sounds good
<benji> I'm not interested in pairing just yet.
<hatch> benji ok np lemme know if you do
<hatch> itunes is stuck playing a single song.....oh boy stable 14.04 can't come soon enough
<abentley> bac: Oh, and since I didn't spell it out in voice chat, a swift or s3 container that's configured for public access is just an http URL, so it works with most tools.
<bac> abentley: right
<abentley> bac: I don't think you successfully installed tarmac into /usr/local/lib. https://pastebin.canonical.com/104462/
<bac> abentley: just did.  had to clean out /usr/local/lib.../tarmac.  the new version wasn't getting written
<abentley> bac: Woot!  It worked.
<bac> cool
<hatch> gary_poster huw's branch is landing with trivials from his code
<hatch> odly enough I rebased my fix into his and it showed as him doing the work
<hatch> so it must take the first commit as the 'owner' ? 
<gary_poster> dunno, but good all around
<gary_poster> jujugui call in 8
<hatch> yupyup
<gary_poster> hatch, if rick is not back Monday and you are looking for something to do, maybe investigate DnD charm upgrade?  first cut UX would be to drag a charm on an existing service to trigger upgrade dialog, maybe?
<gary_poster> and the viewlet -> view thing is not done
<hatch> does core support it yet?
<gary_poster> viewlet -> view more important
<gary_poster> sure, same story: upload charm then can simply tell service to switch to new charm id that juju tells you
<hatch> ahh right 
<hatch> I'll create a card in Project 1
<hatch> gary_poster do we want to allow the drop on the inspector as well?
<gary_poster> hatch. I considered it.  If you like it, try it. :-)
<hatch> ok I made a card which will be split out into a few I think
<gary_poster> cool
<gary_poster> jujugui call in 2
<gary_poster> Makyo ping
<Makyo> Keep getting "this party is over but you can start a new one"
<Makyo> Trying other comp.
<gary_poster> weird
<bac> gary_poster: two leave requests added to canonicaladmin for your reviewing pleasure
<gary_poster> btw, another remote collaborative tool worth following: http://screenhero.com/ .  Current killer for us is no Linux support, but supposedly in process/coming: http://feedback.screenhero.com/forums/192060-feature-requests/suggestions/3941833-make-screenhero-for-linux
<gary_poster> ack bac, I eagerly await clicking buttons...will report back in a amoment
<bac> gary_poster: and 1 day is rollover, so i just need to email sarah when approved, correct?
<gary_poster> bac, yes, and cc me
<gary_poster> bac, all approved .  Would you like me to write email to Sarah about using 2013 day?  I've done so in the past and am happy to.
<gary_poster> will cc you
<gary_poster> bac, actually you did it already.  following up.
<benji> another thought on stateless components: instead of the top level dealing with a mutable bag of user state I wonder if we would be better served by passing in immutable state and getting back a sequence of changes to be enacted, that way we wouldn't have to infer changes from a state delta
<benji> e.g.: pass in {sidebar: {minimized: false}} and if the user clicked on the sidebar show button we would get back actions = {sidebar: "un-minimize"}
<gary_poster> benji, fwiw, that's my pattern for rendering actually: the factories return instructions on what to draw, rather than drawing themselves.  I was more direct for the event handlers, since I didn't want to have to come up with a vocabulary for the much larger (and yet-to-be-discovered) possible set of actions
<hatch> benji you're basically taking the event system and bringing it down to the functional level with that
<hatch> which is fine, it removes the async nature of it, (which might be a good thing)
<benji> could be; hopefully with the benefits of events plus the benefits of a functional approach
<gary_poster> I considered having generic data mutation actions, but I was using immutable data that had a _replace method on it to generate a new version, so it kind of felt like that already, for cheaper cost
<Makyo> Boo  My solution doesn't work for some relations.
<hatch> :(
<Makyo> Was blithely checking relation hook failures, but some relations have multiple endpoints that connect to the same interface, like db and db-slave
<frankban> guihelp: I need two reviews for https://github.com/juju/juju-gui/pull/115 . Anyone available? thanks! I'll try to make the changes and eventually land it in the we.
<gary_poster> frankban: on it
<hatch> sure I'll take it
<frankban> benji: ^^^ I already have two reviewers, so, just FYI, that branch introduces the zip library and also adds a zip-utils module where to store helper functions for working with zip archives
<frankban> gary_poster, hatch: thank you!
<gary_poster> frankban: thanks np.  have a great weekend!  should we try to land it for you if we can?
<benji> frankban: sounds good
<frankban> gary_poster: sure! hopefully I will be able to do that in the we, but if not, please anyone feel free to take it
<gary_poster> cool frankban.  ttyl
<frankban> have a great weekend!
<gary_poster> thanks :-)
<gary_poster> hatch are you going to comment on modules-debug/modules-prod instead of the script tag, or shall I?
<gary_poster> :-)
<hatch> haha, I'm on lunch
<hatch> go ahead
<gary_poster> ok cool
<hatch> I kind of wish we used the loader of some sort so that we didn't have to ship all of that js to the client all the time
<gary_poster> but...we are building an app that needs all of it?
<gary_poster> maybe I'm missing something
<hatch> well it's just that you don't need it at all unless you're doing the local charm stuff
<marcoceppi> so. quickstart kind of went a little wonky during the charm school today
<hatch> so it has to be shipped for the 90% of the time that's unused
<gary_poster> tell us more marcoceppi?
<marcoceppi> gary_poster: oh, it's been recorded to youtube for prosperity, but basically it wasn't able to connect to the juju-gui websocket
<marcoceppi> posterity, even
<marcoceppi> let me find you the link where I start to panic
<gary_poster> oh! weird, and I'm sorry.  was there anything unusual about the circumstances?  A bug report--or anything written--giving details would be fantastic
<marcoceppi> juju quickstart -i ~/production.yaml was what I ran
<gary_poster> we'll make one if you don't, of course, but it would be better to have you give us the details (and easier :-P)
<gary_poster> marcoceppi, local env? ec2?
<marcoceppi> gary_poster: I didn't really take time to debug, just kind of swept under the run and moved on
<marcoceppi> hpcloud
<gary_poster> sure of course
<marcoceppi> I'll attempt it again now to see if I can repro
<marcoceppi> is there a verbose flag or someting I can use?
<gary_poster> I bet we haven't done much hpcloud ourselves.  Thank you!
<gary_poster> marcoceppi: --debug
<marcoceppi> cool, will give that a go now
<gary_poster> thank you much
<hatch> gary_poster I don't get an email from linked-in for over a year, I log in thanks to you and now I get about 1 a day lol
<gary_poster> hatch, heh, sorry ;-)
<bac> gary_poster: looking at the deployer code i see that it parses the constraints only as space-separated key=value pairs.  looks like guiserver using comma-separated is an outlier.
<bac> jujugui: if you attempt to apploy a bundle via quickstart or the juju-gui, juju-core api requires that referenced charm urls have revisions in them.  if you don't you get an error message back like "Error": "charm url must include revision"
<bac> the juju-deployer doesn't use the api and juju-core CLI doesn't have that restriction
<bac> anyone know the rational?
<bac> s/apploy/deploy/
<bac> marcoceppi:  ^^^ that's what led to the bug i filed yesterday
<benji> bac: I don't know of any reason we would include that constraint.  frankban would be a good person to ask.
<marcoceppi> bac: thanks for the clarification
<bac> benji: it isn't us.  it is juju-core
<marcoceppi> couldn't you just do revision expansion?
<marcoceppi> so charm: "mysql" would expand to cs:precise/mysql-33
<marcoceppi> or are we of the idea that charms should be explicit? and if so that's something the remote proof will have to include, charm-tools proof only does a few things
<marcoceppi> charm url validation occurs on the API side
<benji> ahh, in that case I would suspect it is an accident of implementation (and an organizational anti-pattern: all clients should use the same API)
<marcoceppi> in the case of proofing, the API I'm referring to is the charmworld api
<marcoceppi> bac: https://manage.jujucharms.com/api/3/bundle/proof is where that should be fixed, not charm-tools
<bac> marcoceppi: it would be better to find out if it is a false restriction and realign the juju-core api with the cli.
<marcoceppi> true
<marcoceppi> fwiw, the cli exapnds it prior to sending the charm url over
<marcoceppi> so either we replicate that within juju-gui or just expose the more strict nature of the api and say you must have a version
<marcoceppi> juju-gui server/quickstart
<bac> i think from the perspective of a bundle specifying a particular revision is desirable, which guarantees this collection of charms works together.  with no revision you get the latest and that group of charms may have incompatabilities.
<bac> i think i just argued with myself, again.
<hatch> yes that's a definite requirement else you get issues like we have with npm dependencies 
<gary_poster> jorge wants the loose approach too
<gary_poster> He thinks he does, anyway :-)
<hatch> well I could see that it would be ok
<hatch> but that's kind of the cowboy approach and not for 'approved' charms
<hatch> er bundles
<hatch> at least IN MY MOST HUMBLE OF OPPINIONS
<hatch> IMMHOO
<gary_poster> hatch is calling out to the Canadian moose in Saskatoon
<gary_poster> (and I agree)
<marcoceppi> gary_poster: bac hatch I think jorge and I are in the same boat
<marcoceppi> Give you enough rope to hang yourself
<gary_poster> :-) k
<bac> marcoceppi: can you clarify that boat
<gary_poster> he wants to be able to have bundles that do not specify versions
<marcoceppi> with regards to specifying versions in charms. I think we can talk about promulgated bundles being locked
<gary_poster> cool
<marcoceppi> but I should be able to strap on spurs and a 10 Gal hat with my own bundle namespace
<gary_poster> I'd agree with that, and I think that's what we had intended for some time now
<gary_poster> heh, sure
<bac> so are we advocating for a change to guiserver to accept revision-less charm urls, look up the latest, and hand it to the juju-core API?
<gary_poster> it's a deployer thing
<marcoceppi> IMMHOO, yes
<gary_poster> and I think it already does it there
<gary_poster> heh
<bac> NO
<bac> well, deployer uses the CLI
<hatch> marcoceppi so, approved bundles would require versions?
<bac> and the CLI does it
<gary_poster> ah right
<marcoceppi> well promulgated bundles, if that ever exists, yes
<gary_poster> though the deployer should be able to change for 1.18
<bac> so, as marcoceppi said earlier, we'd have to have guiserver do the lookup before calling the api
 * gary_poster suggests we wait for 1.18
<gary_poster> and then have the deployer do the righth thing with the API
<bac> i'm confused
<gary_poster> and then use that
<bac> the deployer does what jorge wants
<gary_poster> the POWAA!
<hatch> ugh who chose promulgated to be the word.....SERIOUSLY
<hatch> was 'promoted' too easy?
<hatch> :P
<gary_poster> bac what do you mean?
<marcoceppi> haha, you would get along with jorge swimingly
<hatch> lol
<bac> the deployer uses the CLI and does what jorge wants, revisionless charm urls
<bac> currently
<bac> juju-quickstart and juju-gui use the API and must have revisions
<bac> so....
<gary_poster> bac, in 1.18 the CLI uses the API
<marcoceppi> gary_poster: for juju deploy? I thought it already did since 1.16
<bac> gary_poster: ok, then in 1.18 jorge will be sad in all cases
<gary_poster> marcoceppi: mebbe so.  I know that the API work is still ongoing
<bac> who would like to have a quick hangout?
<gary_poster> bac, no, my hope is that the API does the looking up on the server side now
<marcoceppi> gary_poster: the CLI does the charm url conversion for by doing a look up against store.juju.ubuntu.com
<gary_poster> <snort>
<bac> or shall we continue this whoseonfirst routine?
<gary_poster> marcoceppi: and then talks to the API?
<marcoceppi> when I run juju deploy mysql in 1.17.X it resolves the charm url then, I believe, uses api to do the deploy
 * marcoceppi runs --debug
<gary_poster> seems a shame that the charm url conversion is not done on the server side
<marcoceppi> gary_poster: networking concerns
<bac> marcoceppi, gary_poster: please to be joining me.  https://plus.google.com/hangouts/_/calendar/Z2FyeS5wb3N0ZXJAY2Fub25pY2FsLmNvbQ.t3m5giuddiv9epub48d9skdaso
<marcoceppi> though, the same exists for the desktop I guess
<Makyo> gary_poster, hatch Current impl of relation is in error.  Appears to work, but may be worth a second set of eyes, if either of you have time. http://pastebin.ubuntu.com/6893602/
<bac> gary_poster: bug 1277696
<_mup_> Bug #1277696: Bundles with revision-less charm URLs should deploy <juju-gui:New> <https://launchpad.net/bugs/1277696>
<gary_poster> hatch finished https://github.com/juju/juju-gui/pull/115 ; ready for you
<gary_poster> thank you bac
<gary_poster> will mess with it in a sec
<gary_poster> looking Makyo
<bac> gary_poster: feel free to correct the description if muddy or wrong
<gary_poster> cool thanks
<gary_poster> Makyo: trivial but maybe worth clarification: "...side of the relation are in a relation error state..." -> "...side of the relation are in an error state for this relation..." or something like that?  awkward.  do what you will.  still reading
<Makyo> Oh, right, didn't get to the comment yet.  Will do.
<hatch> gary_poster ok thanks I'll get to it once I get out of viewlet manager mode
<gary_poster> ack thanks hatch
 * bac -> dog walk
<hatch> Makyo looks good just maybe some inline comments explaining what the code does so future us doesn't have to actually read the code :D and just FYI arrays have a native some() in all of our supported browsers
<Makyo> hatch, cool, thanks.  Will ensure 'some', but yeah, comments on the way.
<hatch> this viewlets and views code is a headache
<hatch> from now on, I want the final app spec before I start any code :P
<hatch> enterprise baby!!!
<gary_poster> Makyo, looks good to me.  I have a couple of minor niggles for you to take or leave.  (1) the `indexOf(sourceEndpoint[1].name + ...) !== -1 seems potentially problematic (if I have a name "bar" and another name "foobar", for instance).  Can't we use `...=== 0` instead?
<gary_poster> hatch :-P good luck :-)
<hatch> lol
<Makyo> gary_poster, oh, okay, yeah.  Will take a look.
<gary_poster> Makyo: thanks, cool.  (2) I love me some functional programming, but I wonder if the sourceEndpoint & targetEndpoint assignment would be clearer (and as short or shorter) with conditionals
<Makyo> gary_poster, oh, so sourceEndpoint = endpoints[0][0] === source.id ? endpoints[0] : endpoints[1] or something?
<gary_poster> if (this.endpoints[0][0] === self.source.id) { sourceEndpoint, targetEndpoint = this.endpoints } else {targetEndpoint, sourceEndpoint = this.endpoints}
<gary_poster> or whatever
<gary_poster> yeah what you said is good direction too
<Makyo> Can you expand arrays like that?
<Makyo> That'd be neat.
<gary_poster> no
<Makyo> Boo! >:/
<gary_poster> too much language exploration
<gary_poster> sorry :-)
<Makyo> Haha, I wish
<hatch> apparently some iteration of ES6 has the multi assignment stuff added
<gary_poster> yay
<gary_poster> bac, moved "[suggestion] quickstart cmdline option for which juju to use" card to slack.  putting your new bug in its place.  AOK?
<gary_poster> bac, uh, confused.  So we should close bug 1277188, replaced by bug 1277696; and open a new bug about the comma/space difference in constraints parsing?
<_mup_> Bug #1277188: charm-proof should warn on revision-less charm URLs <charmworld:Triaged> <https://launchpad.net/bugs/1277188>
<_mup_> Bug #1277696: Bundles with revision-less charm URLs should deploy <juju-gui:New> <https://launchpad.net/bugs/1277696>
<gary_poster> OIC
<gary_poster> no, we want all three. :-/ k
<Makyo> gary_poster, hatch http://pastebin.ubuntu.com/6893754/ ?
<gary_poster> looking
<hatch> oo pretty green
<gary_poster> Makyo: looking good.  Only additional thought, that hatch can probably answer, is whether this is the right logic for peer relations
<gary_poster> Is it?  Or is that not even pertinent?
<Makyo> gary_poster, hatch not pertinent; peer relations are filtered out in the drawing process.  Logic will have to change if it goes down into handler level code.
<gary_poster> Maybe not pertinent because it would not participate in a relation menu
<gary_poster> cool
<hatch> Makyo isn't this.source.units is not already an array? Isn't it a LML? Or is toArray() just a passthrough in that case?
<Makyo> hatch, passthrough, I think. source.units is definitely not an array.
<hatch> gotchaz 
<hatch> +1
<hatch> looks good here
<gary_poster> Makyo: cool, looks good.  For future: https://developer.mozilla.org/en-US/docs/Web/JavaScript/New_in_JavaScript/1.7#Destructuring_assignment_(Merge_into_own_page.2Fsection) :-)
<Makyo> Whew, okay.  Glad I caught the weird dual relations case.  Good test is mediawiki with two mysqls.  The interfaces are different on mediawiki, but the same on each mysql.
<Makyo> Bonus :D
<hatch> :) yay
<hatch> yay go future javascript
<hatch> which we can't use if we ever don't support the latest browsers
<gary_poster> heh, open the inspector when you go to that page and look at console.  Maybe this is only new to me
 * hatch hands gary a fancy hat and whistle.... "Welcome to the internet!!!"
<gary_poster> :-P
<hatch> lol
 * Makyo dogwalk, then tests.
<hatch> the viewlet manager now accepts viewlets AND views
<hatch> unfortunately all the css is broken with views
<hatch> yay
<hatch> probably a rather simple specificity fix though so that's good
<hatch> OO 168 test failures
<hatch> there are so many test failures that the scrollback in my terminal doesn't go that far
<hatch> haha oops
<gary_poster> heh
 * gary_poster running
<gary_poster> have a great weekend and next week!
#juju-gui 2015-02-02
<rick_h_> morning, still aroud huwshimi ?
<huwshimi> rick_h_: Morning
<rick_h_> huwshimi: what time is it there?
<rick_h_> I've no idea what my cross over is at this piont heh
<huwshimi> heh
<huwshimi> rick_h_: 4:50.
<rick_h_> ah, so just before your EOD 
<huwshimi> rick_h_: I usually finish up in an hour
<rick_h_> do your review? :P
<huwshimi> rick_h_: haha, I have a big note :)
<huwshimi> rick_h_: Every time I see it I hear your voice demanding that it be done :)
<rick_h_> :)
<mhilton> morning uiteam, everyone have a good weekend?
<rogpeppe1> mhilton: hiya
<fabrice> oh yes gardening the whole weekend
<fabrice> morning rogpeppe mhilton 
<rogpeppe> mhilton: definitely. went over to visit a friend near Kendal and went up to play in the snow in the hills
<rogpeppe> mhilton: igloo building and sledging :)
<mhilton> rogpeppe: I saw a small dusting of snow on the rooftops out the window. It cleared up really quickly though.
<huwshimi> Morning
#juju-gui 2015-02-03
<hatch> uiteam lf a review and qa on https://github.com/juju/juju-gui/pull/691 plz and thanks
<huwshimi> Morning
<hatch> hey huwshimi I have a gui pr up - would be awesome if you could give it a review
<huwshimi> hatch: No problems I'll take a look
<huwshimi> hatch: Looks like the tests have failed
<hatch> yeah I'm re-running
<hatch> looks like a spurious failure
<huwshimi> yeah
<hatch> huwshimi: ugh yet another spurious failure - maybe because ci hasn't run on this branch in a while it's not warmed up
<hatch> lol
<huwshimi> hehe
<huwshimi> hatch: Your branch looks good. Assuming those failures are just Selenium being its usual self.
<hazmat> worth a gander
<hazmat> https://www.youtube.com/watch?v=I7IdS-PbEgI#t=446
#juju-gui 2015-02-04
<hatch> hazmat: will take a look tonight - it's definitely something I've been looking into
<hatch> frankban: our time is running out with regards to not sending the uuid from the gui on api requests. Do you know if that is sent in the envinfo?
<frankban> hatch: do we need to send the uuid when logging in?
<hatch> frankban: I'm not sure...
<hatch> I'm just spinning up an env now
<hatch> hoping that it's in there :)
<frankban> hatch: it seems that connecting to the root URL of the API address is still supported, but in the future we want to connect to /environment/{env_uuid}/api
<frankban> hatch: is this your end goal?
<hatch> frankban: right - apparently that's coming sooner rather than later
<hatch> yeah - so I need to find that uuid
<hatch> unfortunately the 'debug' mode in the gui is not working today ://///
<frankban> hatch: ok to do that we need to know the environment UUID
<hatch> yeah - for some reason debug mode in the gui is no longer serving the individual files
<frankban> hatch: we can handle that in two ways: 1) do not touch the GUI and handle that on the gui server side. this way, the GUI still connects ti its own domain, and the gui server does the redirect or 2) connect the GUI websocket to a specific path of the guiserver, and the guiserver will proxy to the corresponding path of the Juju state server
<frankban> hatch: move this discussion to jaas
<hatch> chooo chooooo
<hatch> I'm still stuck on trying to get the gui to serve the proper assets :/
<hatch> I wonder when that broke
<hatch> oh look it was another chrome caching bug....man this browser is falling apart
<hatch> frankban: ok joining standup
<hatch> jcsackett: weechat uses F11/12 to scroll the nicklist - but F11 makes the window go full screen :) any ideas
<jcsackett> hatch: don't go to channels with that many nicks and/or use a taller monitor?
<jcsackett> hatch: i've never had cause to scroll the nicklist.
<hatch> #juju has too many people :) 
<hatch> ok not going to lie - most of my channels have more than my vertical space
<hatch> looks like my branch from yesterday failed ci merge because of spurious errors...man this CI
<hatch> frankban: hey how do you debug the backend.py code? essentially I want to put a pdb in the 'start' method but it'll need to be in a real env
<frankban> hatch: debug-hook?
<hatch> can you debug hook if everything runs through the same file?
<hatch> uiteam any
<hatch> python peeps want to see if this is the best way to accomplish this http://bazaar.launchpad.net/~hatch/charms/trusty/juju-gui/add-uuid-configjs/revision/230
<hatch> yes this is valid es6 js.....oy vey
<hatch> exports.activate   = () => console.log('this package was activated')
<huwshimi> Morning
#juju-gui 2015-02-05
<frankban> uiteam I need two reviews for https://codereview.appspot.com/195690043 (quickstart/python)
<frankban> thanks!
<hatch> on it frankban 
<frankban> hatch: thanks
<frankban> hatch: have you seen my email re juju connect stuff?
<hatch> not yet
<hatch> i will
<hatch> frankban: review and qa done
<hatch> looks good
<hatch> frankban: I am interested to know why you wrapped those two methods?
<hatch> frankban: so why did you wrap those functions in a functools.wrap decorator? can you not return a function in python normally?
<frankban> hatch: functools.wrap preserves the original name and documentation of the decorated function
<hatch> frankban: ahh
<frankban> hatch: FYI those values are stored in func.__name__ and func.__doc__ 
<hatch> interesting that those aren't included by default
<hatch> any idea why the gui charm needs firefox in its sysdeps?
 * hatch cry's "I just want to run the linter"
<mbruzek> hatch ping
<hatch> sup
<hatch> uiteam, anyone know why I wouldn't have the correct version of pip for the guicharm linter? 
<frankban> hatch: firefox is required by functional tests using selenium
<frankban> hatch: not sure if I understand your second question
<hatch> # Ensure the correct version of pip has been installed
<hatch> tests/.venv/bin/pip --version | grep "pip 1.[4-9]" || exit 1
<hatch> make: *** [setup] Error 1
<hatch> ^ frankban 
<mbruzek> hatch: I am trying to figure out the charm store uris
<frankban> hatch: what pip version do you have?
<hatch> 1.5.4
<hatch> pip 1.5.4 from /usr/lib/python2.7/dist-packages (python 2.7)
<mbruzek> hatch: Kapil has a launchpad url lp:~hazmat/charms/bundles/kubernetes/bundle
 * hazmat ears are ringing
<frankban> hatch: tests/.venv/bin/pip --version 
<mbruzek> hatch: and quickstart maps to that  juju quickstart bundle:~hazmat/kubernetes/kubernetes
<mbruzek> hello haz
<mbruzek> hello hazmat
<hazmat> greetings
<hatch> frankban: ummm 6.0.7?
<frankban> hatch: really?
<hatch> mbruzek: if you want to deploy a bundle using quickstart or the depployer then you'll have to use the old yaml format
<mbruzek> hatch: trying to figure out how quickstart maps bundle:~hazmat/kubernetes/kubernetes to lp:~hazmat/charms/bundles/kuberentes/bundles
<hatch> pip 6.0.7 from ......../develop-trunk/tests/.venv/local/lib/python2.7/site-packages (python 2.7)
<hatch> mbruzek: it guesses
<hazmat> mbruzek: on lp distro is charms, series is bundle is the nutshell
<mbruzek> hatch trying to figure out the mapping so I can write readmes for other bundles
<frankban> hatch: I am rebuilding the devenv for the char, and checking again
<hatch> mbruzek: all of that is changing soon - makyo_ is working on updating the deployer to support the new syntax
<hazmat> hatch: thats not url syntax is it? i thought it was mostly just syntatic incompatible format changes
<hazmat> in the bundle itself
<mbruzek> hatch So I am writing a readme for how quickstart works now.  I just want to know what format will work with our bundle here:  p:~kubernetes/charms/trusty/kubernetes-bundle/trunk
<hatch> no the url changed as well
<hatch> mbruzek: if you want to use that you'll have to point to the old yaml file directly
<hatch> the new bundle yaml format is not supported by the deployer
<mbruzek> hatch: I don't want to point to that url, I like the bundle: uri, I just need to know how it works.
<frankban> mbruzek: quickstart still uses the old charmworld for bundles, and the supported syntax is described in quickstart --help
<mbruzek> frankban: thank you.  Will read up on that
<hatch> for some reason the deployer wasn't updated before the bundle syntax was
<frankban> mbruzek: it will be updated soon to support the new bundle URLs
<hatch> frankban: why do we want to use such an old version of pip? 5 major versions older?
<mbruzek> hatch: frankban: I see the help text now, it seems that quickstart supports 5 formats.  Which one would you recommend?  I see things are changing, what would be the format that would be recommended that works now and in to the future?  
<hatch> I think those two are mutually exclusive :) 
<mbruzek> doh
<hatch> juju quickstart bundle:mediawiki/single
<hatch> we want this format to work
<hatch> but currently it doesn't
<frankban> hatch: I think in the future we want "juju quickstart bundle/mediawiki-single"
<frankban> mbruzek: ^^^
<hatch> oh jeeze that's a new format to me
<mbruzek> hatch: frankban:  Our bundle currently lives here:  lp:~kubernetes/charms/trusty/kubernetes-bundle/trunk  
<hatch> I think I'll just write code - give up on what format is what lol
<frankban> hatch: in the new charm store, the "bundle" string is not a schema, is a series
<mbruzek> It is not yet promulgated.  Is that in a wrong spot?  Should we change that?
<frankban> hatch: it seems that pip quickly switched from version 1.5.6 to 6.0 :-|
<hatch> lol
<frankban> hatch: so yes that check should be changed, feel free to do that as part of your branch
<hatch> frankban: what was it there for? 
<hatch> There must be a reason why we checked at all
<frankban> hatch: I did not add that code, so not sure, perhaps some backward incompatible changes with previous pip versions
<hatch> so think I can just remove the check entirely?
<frankban> hatch: I'd suggest to keep the check, just make it more permissive
<hatch> so just greater than 1.4?
<frankban> hatch: +1
<hatch> frankban: do you know of a way to structure the grep for that? I am having a heck of a time nesting the conditionals in the makefile
<hatch> ifndef apparently doesn't work for me
<hatch> oh makefiles
<frankban> hatch: grep -E "pip (1.[4-9]|6)" ?
<hatch> negative, tried that :)
<hatch> here is what I am attempting to do in the makefile (and failing) https://gist.github.com/hatched/83544f1c201ee1a71a6e
<hatch> for some reason ifndef is not found?
<frankban> hatch: what I suggested works here
<frankban> % echo "pip 6.3" | grep -E "pip (1.[4-9]|6)"                                                                                                                                                                                               (trunk) ubuntu
<frankban> pip 6.3
<hatch> yeah it works from the echo but not in practice
<hatch>  tests/.venv/bin/pip --version | grep -E '1\.[4-9]\.|6\.[0-9]\.[0-9]' || exit 1
<hatch> bleh lol
<mbruzek> hatch: I tried to deploy using quickstart using a raw html bundle, but none of the charm store charms showed up.  I ran this with --debug and the pastebin is here. http://paste.ubuntu.com/10076915/  Can you help me
<mbruzek> ?
<hatch> looking
<hatch> what was the command you used?
<hatch> btw thanks for writing these docs :)
<hatch> mbruzek: still there?
<mbruzek> yes
<hatch> what was the command you used?
<mbruzek> juju quickstart https://raw.githubusercontent.com/whitmo/bundle-kubernetes/master/bundles.yaml --debug 2>&1 | tee quickstart_problem.txt
<mbruzek> The bundle is legit, it works with deployer and references Charm store uris
<mbruzek> I am trying to figure out why none of the charms are loaded
<hatch> hmm yeah you're right it looks good
<frankban> mbruzek: quickstart states that the bundle deployment request has been accepted
<mbruzek> fankban I can show you the juju status that tells me otherwise
<mbruzek> or the gui if you don't believe status
 * mbruzek *grins*
<hatch> mbruzek: have you tried deploying those services directly? 
<frankban> mbruzek: what's the content of https://15.125.118.3/gui-server-info
<frankban> ?
<mbruzek> {"uptime": 3435, "deployer": [{"Status": "started", "Queue": 0, "DeploymentId": 0, "Time": 1423157614}, {"Status": "scheduled", "Queue": 1, "DeploymentId": 1, "Time": 1423159220}, {"Status": "scheduled", "Queue": 2, "DeploymentId": 2, "Time": 1423159241}, {"Status": "scheduled", "Queue": 3, "DeploymentId": 3, "Time": 1423159325}], "apiversion": "go", "sandbox": false, "version": "0.4.2", "debug": false, "apiurl": "wss://10.0.0.166:17070"}
<frankban> mbruzek: so you have pending bundle deployments in the queue, they are executed in order
<mbruzek> frankban: I guess I tried this bundle several times now.
<mbruzek> I can destroy and start over again, but I don't think I would get a different result.
<mbruzek> hatch: I have deployed this bundle through juju-deployer when have the bundle on my local machine.
<frankban> mbruzek: let's check the guiserver logs: they are stored in the gui unit in /var/log/upstart/guiserver.log
<mbruzek> on machine 1?
<frankban> mbruzek: wherever the gui unit is placed: juju ssh juju-gui/0
<mbruzek> frankban: OK found it, is that safe to pastebin?  It does not show my keys or other stuff?
<frankban> mbruzek: I think so, but let's use the canonical pastebin
<mbruzek> frankban: working on it
<frankban> mbruzek: ty
<mbruzek> frankban: had to paste it by hand, no upload feature on pastebin.canonical.com
<mbruzek> https://pastebin.canonical.com/125051/
<frankban> mbruzek: uhm... I don't see any errors in the logs. it seems that the deployer is still working on your first bundle as usual, except it's not deploying anything
<frankban> mbruzek: you can try, from that machine, "sudo service guiserver restart", then "juju set juju-gui builtin-server-logging=debug" and then try to deploy the bundle again (once) and see if the logs show something
<mbruzek> I see a python exception in queues.py is that nothing?
<frankban> mbruzek: not sure if that's related to the bundle deployment
<frankban> mbruzek: but it's well over my EOD now and I have to go, so could you please try what I described and file a bug against the GUI charm with the info attached?
<mbruzek> will do,  thanks for your assistance frankban.
<mbruzek> Have a good day
<mbruzek> night
<frankban> night and ty
<hatch> uiteam do we know which branch I should push my guicharm changes to? lp:charms/trusty/juju-gui  or  lp:~juju-gui/charms/trusty/juju-gui/trunk 
<hatch> and by push I mean propose
<hatch> uiteam lf a review for a smallish diff https://code.launchpad.net/~hatch/charms/trusty/juju-gui/add-uuid-configjs/+merge/248826
<rick_h_> hatch: juju-gui/charms/trusty/juju-gui/trunk
<hatch> oh hai!
<hatch> yeah I have it up for review
<hatch> :)
<rick_h_> ah cool
<hatch> tornado is bonkers
<hatch> just so you  know :P
<rick_h_> :)
<rick_h_> async python ftw
<rick_h_> hatch: just think of it like nodejs
<hatch> ehh I'm still thinking an async language might be better :)
<hatch> makyo_ and I are going to have to get schooled by frankban tomorrow :)
<rick_h_> heh, docs aren't bad
<hatch> nah it's just trying to find the correct spot to put things in the guiserver is the issue
<rick_h_> gotcha
<hatch> having a yeild in the middle of a function then never returning to it really threw me for a loop
<huwshimi> Morning
<hatch> morning huwshimi 
<rick_h_> morn
<hatch> I fixed some of the rendering performance issues in leankit by modifying their stylesheets :) 
<hatch> there are cascading shadows and transparencies so it's no wonder you get screen tearing on slower machines
<hatch> I found this cool site that shows benchmark comparisons for various languages. http://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=dart&lang2=go
#juju-gui 2015-02-06
<sebas5384> hey! o
<sebas5384> o/
<sebas5384> somebody know what happened with the service's settings in the juju-gui ?
<rick_h_> sebas5384: what do you mean?
<sebas5384> rick_h_: it isn't appearing anymore
<rick_h_> sebas5384: umm, no but thakns for mentioning it. We'll get folks right on it
<rick_h_> huwshimi: any time left in the day? ^
<sebas5384> http://awesomescreenshot.com/0154cnfkad
<huwshimi> rick_h_: Yep, let me take a look
<sebas5384> thanks rick_h_ !
<rick_h_> sebas5384: yep, can replicate on demo.jujucharms.com as well
<rick_h_> sebas5384: ty, will file a bug and get the guys on it right away
<rick_h_> huwshimi: added a card marked critical with a bug on it. I assigned it to hatch assuming you'll not have time in your day to complete it but plese leave notes/etc either in the bug or the card
<huwshimi> rick_h_: Yep, sure thing. I can see there's an error there so I'll try and track that down and see how I go.
<rick_h_> huwshimi: review done?
<huwshimi> rick_h_: Sure is :)
<rick_h_> huwshimi: <3
<sebas5384> rick_h_ and huwshimi thanks for the fast response :)
<rick_h_> sebas5384: np, not sure how that one slipped by but hopefully it's a small fix do to some new apis we're using and should be fast. We'll try to get a new rev'd charm out by EOD
<rick_h_> US EOD that is
<sebas5384> I'm going to demonstrate juju gui at a conference tuesday
<rick_h_> sebas5384: you'll definitely have it by then
<rick_h_> sebas5384: fyi, the icon thing is a bug in chrom v40 we're tracking upstream
<rick_h_> sebas5384: so FF is currently the best demo browser unfortunately
<rick_h_> sebas5384: until chrome fixes the svg issue and get it into a release
<rick_h_> https://bugs.launchpad.net/juju-gui/+bug/1415550 for tracking
<mup> Bug #1415550: Charm's SVG icons with wrong size in Chrome <icon> <svg> <juju-gui:Confirmed> <https://launchpad.net/bugs/1415550>
<sebas5384> yeah definitively rick_h_ i'm going to use it with firefox for now
<rick_h_> sebas5384: looking at the upstream bug though looks like v41 will include a fix yay!
<sebas5384> rick_h_: uhuu!
<sebas5384> :)
<huwshimi> rick_h_: So it looks like hatch landed a branch which fixed this a couple of days ago: https://github.com/juju/juju-gui/commit/9dabbda4597c53545fc9ed912165a583d3fd1337
<huwshimi> rick_h_: I've rolled back to the commit before that and confirmed that the bug was there before that commit.
<huwshimi> rick_h_: devel should be fine now.
<rick_h_> huwshimi: ok, awesome. We should get a release rolling then. I'll make sure to bug hatch about it
<rick_h_> huwshimi: can you email -peeps with your findings and I'll reply asking for the release today please?
<huwshimi> rick_h_: Sure thing.
<rick_h_> ty kindly
<huwshimi> rick_h_: Sent!
<rick_h_> huwshimi: awesome
<hatch> frankban: wouldyou be able to point me to the correct place to inspect the path in guiserver? I was thinking the on_message method
<frankban> hatch: looking at the code
<hatch> tornado is very confusing
<frankban> I've found it less confusing than other async frameworks
<hatch> quite possible - it feels to me like it's shoehorning async into a language that isnt
<hatch> (I wrote an async framework for php back in the day) 
<hatch> :)
<hatch> but php didn't have yeild so I actually had an event loop lol
<frankban> hatch: yield is just a way to avoid the callbacks hell
<frankban> hatch: so, I'd presume you'll have to extend url routing in server/apps.py
<frankban> hatch: right now only /ws$ is routed to the websocket handler
<hatch> and what's the path supposed to be now?
<hatch> won't it still be /ws/uuid/
<frankban> hatch: to avoid confusion, I'd make them reflect the juju API server ones. so we need to keep handling /ws$ and add support for /ws/environment/:env_uuid:/api
<frankban> hatch: so same as juju but in the ws/ namespace
<hatch> oh so they actually added the "environment" keyword in there
<hatch> I thought that was just a placeholder :)
<frankban> hatch: heh, no, I think that's the real endpoint path
<hatch> alright, is there a way I can test the api using curl or the like to see if that is indeed the endpoint?
<frankban> hatch: I am pretty sure that's the real endpoint. however, for these kind of tests I usually use ipython + https://pypi.python.org/pypi/websocket-client/ (it's really quick with the latter to establish a websocket connection)
<hatch> ahh cool
<hatch> ok well first is gui release then I'll continue on your reivew comments and this
<frankban> hatch: for instance, I use this script sometimes to watch env changes: http://pastebin.ubuntu.com/10093532/
<hatch> oh yeah...just tiny :P
<frankban> heh but easy to change to make other calls
<hatch> makyo_: didn't you do a guicharm release in 2015?
<hatch> https://jujucharms.com/juju-gui/trusty/17 see the revisions list
<hatch> or was that updated but never released?
<hatch> makyo_: whenever you return I'm wondering if something borked up becuase there is no git tag to match 1.3.0
<hatch> wait there is on trunk...hmm
<makyo_> https://github.com/juju/juju-gui/releases/tag/1.3.0 ?
<hatch> might help if I used the --tags
<hatch> *facepalm*
<makyo_> Whew
<makyo_> Had me worried
<hatch> so that's one problem down - now the charm release :)
<hatch> Makyo: so did you push a new charm release and it maybe not make it onto jujucharms?
<hatch> I was pretty sure you did one rather recently
<hatch> in fact http://bazaar.launchpad.net/~juju-gui-charmers/charms/trusty/juju-gui/trunk/files
<hatch> you did
<Makyo> I did, yeah.
<Makyo> https://jujucharms.com/trusty/juju-gui in the releases dir is juju-gui-1.3.0.xz
<Makyo> So maybe the changelog is borked?
<hatch> hmm yeah that's odd
<hatch> ok well I'll just go on the assumption that it's the UI that's a little busted because the code all looks good
<hatch> Makyo: was sphinx supposed to be in the sysdeps?
<hatch> oh it is....ok then...hmm
<hatch> code release done - commits can resume to the gui
<hatch> still working on the charm side 
#juju-gui 2016-02-11
<mhilton_> bac: [url "ssh://martin-hilton@git.launchpad.net/"]
<mhilton_> bac: insteadOf=lpme:
<mhilton_> bac: obviously change martin-hilton to bac
<kwmonroe> hey folks, i just promulgated ibm-xlc, but it's showing up in the community section (even though it's owned by "charmers") instead of recommended.  any advise on how to fix? https://jujucharms.com/q/ibm-xlc
#juju-gui 2017-02-07
<deanman> frankban, Hiya, quick question regarding https://github.com/juju/juju-gui/issues/2392. Any estimate for the patch delivery ?
<frankban> deanman: hey, sorry, missed the ping, 2.3.1 is due in ~2 weeks according to our schedule
<deanman> frankban, hey great news then, looking forward to see that, thanks for the update!
<frankban> deanman: np, thanks for reporting!
<deanman> frankban, on a side note, is there any feature request to be able to present a bundle as a single unit ?
<deanman> So that you can have more complex architectures in your model without having tens of services always visible in your canvas ?
<frankban> deanman: that idea is under design. yes we want bundles to be real entities in juju. right now, once a bundle is deployed, there is nothing in juju indicating that that's a bundle and not just a collection of charms in your model. for instance, you cannot scale out a bundle. I think a plan exists but not scheduled for the very near future
<deanman> frankban, i think the elasticity scenario is far more advanced and would mean that bundles are treatest as first-class citizens. My request comes from the fact that i simply want a better representation in the web-gui side. 
<frankban> deanman: I see, interesting
<deanman> I was thinking something that you could toggle on-off and either group the charms of a given bundle in a single UI element or expand them
<frankban> deanman: I'll have to ask UX about this, and we'll have to think about how doable it is without some support server side
<deanman> e.g. deploy two complex bundles, 1 is from the charm store and contains 20 charms and 1 bundle which is my application and is 3 charms. With this example the 20 services which I'm simply using as-a-service simply make my 3 charms "invisible" or less important. In the UX language i guess you could say it draws the focus of the end user to the wrong side
<rick_h> deanman: I think the idea there would be the feature flagged idea of cross model relations.
<rick_h> deanman: so you can put them in different models and connect.the bits that need to be connected
<deanman> Hi rick_h, hmmmm...haven't see the cross-model feature yet, can you deploy a subordinate, e.g. a monitoring tool and connect all services ? Will that be visible in the same canvas ?
<deanman> I guess if you are able to see both models at the same time that will work for what i have in mind.
