#juju-gui 2013-01-28
<therve> hazmat, it's in a landscape branch for now
<bac> good morning italians
<teknico> good morning viet... ehm, puerto rico :-)
<bac> frankban: 2nd review done.  nice branch.
<frankban> bac: thanks. do you feel better?
<bac> frankban: yes, thank you.
<hazmat> therve, ah ic
<hazmat> thanks
<hazmat> therve, any issue if i put a copy into pyjuju?
<therve> hazmat, nope, no problem. It may be in landscape client soon enough anyway :)
<benji___> I wonder if we should make lbox submit error out if there are any "pending" (skipped) tests.
<bac> benji: so i the phantomjs stuff supposed to be working?  not for me.
<benji> bac: yep it works, it can be a (slight) pain to set up though.  In what way is it failing?
<benji> (I'm glad you are back among the living.)
<bac> thanks
<bac> just dies with rc 2
<benji> bac: does the phantomjs executable run for you?  (just run "phantomjs")
<bac> benji: ah...  yes it is on my path but cannot run.  perhaps i grabbed the wrong one for my vm
<bac> thanks benji, that was it
<benji> cool
<hazmat> arosales, benji, bcsaller, bac, frankban, Makyo, teknico standup in 1m
<teknico> hazmat, you're beginning without youOHWAIT
<hazmat> teknico, ack
<arosales> hazmat: Hello
<hazmat> arosales, no worries.. just pinging folks for the gui standup
<arosales> hazmat: ah, ok.  
<benji> hazmat: in the description of "kill node-minify usage lib/merge-files in favor of uglify2" it says "gets rid of java" which, unfortunately, isn't true if we continue to use the YUI minifier.  Do we want to continue using it or switch to non-minified (but still combined) CSS to be rid of Java or should we keep minifying (and Java)?
<hazmat> benji, uglify2 is a minifier
<benji> hazmat: oh, it will do CSS?
 * hazmat pauses while brain processes
<hazmat> benji, clean-css might be an alternative for that
<hazmat> no re uglify and css
<hazmat> https://github.com/GoalSmashers/clean-css
<benji> hazmat: clean-css sounds fine; I'm just going to do the JS side of things in this branch then and leave the YUI/CSS/Java bits alone.
<hazmat> benji, awesome.. i'd check if uglify itself has source code map support.
<benji> hazmat: yep, from the uglify help: "--source-map       Specify an output file where to generate source map."
<hazmat> benji, it looks like uglify-js > 2 has support .. the ugilify2 
<hazmat> is a separate thing
<hazmat> cool
<hazmat> another nodejs css compressor.. https://github.com/ded/sqwish
<hazmat> added card with links to both
<benji> cool
<hazmat> benji, interesting.. node-minify has options for not using yui and for passing args through to uglify and sqwish
<benji> I have a very, very small branch up for review: https://codereview.appspot.com/7228054; it removes the need to have java installed in order to build the app
<bac> benji: i've slogged through your branch.  land as is.
<benji> heh
<Makyo> Taking a look, benji, but getting  an error in there with no context.  Digging into it.
<Makyo> { [Error: Command failed: /bin/sh: 1: undefined: not found] killed: false, code: 127, signal: null }
<Makyo> node debugger isn't catching it, boo.
#juju-gui 2013-01-29
<gary_poster> morning all.  bcsaller and Makyo|out, I'd like to hear about the status of bug 1099921 sometime today.  no rush though.
<_mup_> Bug #1099921: Dragging services fails intermittently <juju-gui:Triaged> < https://launchpad.net/bugs/1099921 >
<bac> hi bcsaller
<bcsaller> bac: hi
<gary_poster> bac, benji is prototyping "Test needed for work-around on building relations."  Is that the thing you said you had done as an aside?
<bac> gary_poster: yeah
<benji> oh
<benji> I'll... put the card back then, and assign it to you, bac
<gary_poster> sorry benji.  that was a product of bac being sick, I think
<gary_poster> and out of that loop
<gary_poster> benji, I suck, but I think that one should wait for goodspud to be around
<gary_poster> benji, call in 2?
<benji> gary_poster: sure
 * benji suspects gary_poster is traveling close to the speed of light.
<gary_poster> :-P sorry
<Makyo|out> Compiz bugging out, in for real in a moment.
 * teknico will be back in half an hour, please start the call without waiting for him, he'll be there shortly
<gary_poster> bac bcsaller benji frankban hazmat Makyo teknico call in 2
<gary_poster> make that 1
<gary_poster> bac hazmat starting
<hazmat> network problems.. trying
<teknico> benji, deRailing people sounds like a pretty cool thing to do, as long as you Djangoize them at the same time :-)
<benji> heh
<Makyo> Is there another PS sprint along with UDS in April/May?
<benji> that sounds like a good name for a blog run by a former Rails guy trying to convert people to Django
<gary_poster> Makyo, yes, that is my expectation
<gary_poster> Makyo, Oakland this year, if you didn't see
<Makyo> gary_poster, cool, thanks.
<gary_poster> welcome
<Makyo> gary_poster, Yeah, I saw.  Oakland, at the Bella Sky Convention Center, Denmark, last I checked :)
<gary_poster> lol
<bcsaller> on a hunch I tested it and I think CSS transitions are working again, the incremental redraw stuff seems to have fixed that. 
<gary_poster> cool!
<bcsaller> someone else would have to verify, I think its running to quickly on chrome, but I *think* its working. I don't see any bad visual artifacts now
 * gary_poster runs to lunch for a bit
<gary_poster> hazmat we do have bug 1104098 on the board as the only single high bug.  I think that is what you are talking about for "enable serving up gui and websocket on same port."  I guess we could treat the bug as the more long term solution that would work for pyjuju and gojuju, like what Francesco investigated...
<_mup_> Bug #1104098: secure GUI on Firefox with self-signed cert requires second, hidden cert acceptance <juju-gui:Triaged> < https://launchpad.net/bugs/1104098 >
<hazmat> gary_poster, it is the same, though the branch in review doesn't do the charm work to enable usage of that. i'm more comfortable given that we're released/announced if we can get an interim fix in. the long term solution also needs vetting on ssl inbound <- proxy -> ssl outbound .. currently francesco suggest ssl needs to be disabled on outbound which invalidates that solution
<gary_poster> ssl outbound from juju you mean
<gary_poster> invalidates it because of go only?
<hazmat> gary_poster, ssl outbound to juju from the proxy
<hazmat> gary_poster, yes
<hazmat> gary_poster, but only because we control the endpoint in the gui on pyjuju
<hazmat> if the endpoint we're part of the state server, in pyjuju the same issue applies
<hazmat> i'm hopeful further experimentation with haproxy can resolve..
<gary_poster> hazmat, if not, do you feel that it would be a reasonable argument to have a non-exposable Juju API-only port
<gary_poster> ?
<gary_poster> in go
<hazmat> but again i'd like to get a fix in place given that we've started directing users to the gui.. that can be haproxy, but then we need to priortize assessing the haproxy as a long term solution
<gary_poster> right
<gary_poster> haproxy can be part of the go bits
<gary_poster> go work
<gary_poster> and when we do that
<gary_poster> we can switch to using that everywhere
<gary_poster> improv on charm ("staging" mode) will still be broken for Firefox with the current fix, right hazmat?
<gary_poster> as broken as it is now I mean
<hazmat> gary_poster, i'm not comfortable with the non exposed port not using ssl, there are non tenant network isolation scenarios with maas/hardware that would effectively allow for attacks.. in cloud environments its reasonable okay though they'd have to guard against std password attacks etc on the port
<hazmat> gary_poster, no this should fix that to, improv will grown a cli option to point to gui-dir
<hazmat> gary_poster, i mean thats one option.. at the moment improv has no cli config..
<gary_poster> ack hazmat makes sense
<hazmat> er.. by cloud envs i mean ec2 non vpc, most other clouds do net tenant isolation
<gary_poster> ok, *now* I'm going to lunch :-P
<hazmat> gary_poster, :-)
<frankban> hazmat, gary_poster : I did some more investigation: it seems to be possible to forward encrypted data on outgoing connections (api agent). this can solve the problem of having an insecure connection to localhost. 
<hazmat> frankban, awesome
<hazmat> well its not localhost in the general case  but that's cool
<frankban> hazmat: in the long term, will we need to use different certs for browser -> haproxy and haproxy -> gojuju?
<hazmat> frankban, probably
<hazmat> frankban, almost definitely
<hazmat> gojuju shouldn't be sharing its private api server cert with a service in the env
<bac> benji: could you look at my branch in review in order to de-red the lanes?  it simply adds the test we discussed
<benji> bac: sure
<benji> bac: Looks good.  I added a couple of comments.
<bac> thanks
<bac> benji: oops.  :)
<benji> heh
<frankban> hazmat: it seems to work also using two certs! https://ec2-184-73-51-76.compute-1.amazonaws.com/
<Makyo> Running into EMFILES with node watching files in make devel.  Helped to increase /proc/sys/fs/inotify/max_user_instances a little (though I suspect I've probably got other problems), in case that helps anyone else.
<hazmat> frankban, excellent, that's the preferred solution then
<frankban> hazmat: cool, however, does that link work for you (firefox)?
<hazmat> frankban, what's the password?
<frankban> hazmat: if you see the login screen, then it works
<hazmat> frankban, i do, cool
<frankban> hazmat: new configuration: http://pastebin.ubuntu.com/1586550/  adding this link to the card
<hazmat> frankban, do you mind if i reassign the card to you then
<hazmat> we don't need the static serving in rapi afaics with this
<frankban> hazmat: i mean bug 1104098
<_mup_> Bug #1104098: secure GUI on Firefox with self-signed cert requires second, hidden cert acceptance <juju-gui:Triaged> < https://launchpad.net/bugs/1104098 >
<hazmat> ah cool
<frankban> hazmat: I think we need further discussion on the path to follow, we still have haproxy unreleased.
<hazmat> frankban, good point.. okay i'll continue on with the rapi serving static. with the intent that this is the future
<hazmat> the beauty of charms is that its not a big deal, alhtough agreed a src dev-base/compile env is not ideal
<frankban> hazmat: yes, we could also add our nginx build to some ppa, maybe better
<gary_poster> +1 on PPA frankban, and awesome!  (worked for me on FF too)
<frankban> gary_poster: cool, EOD, have a nice evening
<gary_poster> you too frankban 
<gary_poster> bac, gave you second review
<gary_poster> (land as is or with trivial changes()
<bac> thx
<gary_poster> benji I approved sauce labs email to juju-gui fwiw so you can verify that account if you want
<benji> gary_poster: thanks
<gary_poster> guihelp, what do you see in https://launchpad.net/~juju-gui/+mailing-list-subscribers 
<gary_poster> just yourself, or a group of us?
<hazmat> gary_poster, i just see you
<gary_poster> :-(
<hazmat> gary_poster, we're not using that
<Makyo> Just you.
<hazmat> gary_poster, we're using mailman directly on lists.ubuntu.com
<gary_poster> right thanks hazmat
<hazmat> ie. the channel title
<hazmat> else it wouldn't really be a public list
<gary_poster> right
<hazmat> speaking of public lists.. that's where the saucelabs invite went out to
<hazmat> not sure that it matters, but we should update the contact info for that perhaps
<gary_poster> benji ^^
<benji> hazmat: I am prototyping using them for our browser tests, what would you like the contact address to be set to?
<hazmat> benji, private list since its a private resource
<benji> k
<hazmat> juju-gui-peeps would do the trix
<benji> making it so
<hazmat> thanks
 * bac preemptive dog walk.  bbiab.
<benji> gary_poster: if you have a second I would like to discuss the current and future of my saucelabs.com card
<gary_poster> benji on call.  will ping soon
<benji> k
<gary_poster> benji, I'm in juju-ui for you whenever you are ready.
<benji> k
<bac> Makyo: review done.
<Makyo> Thanks, bac
 * Makyo -> dogwalk
#juju-gui 2013-01-30
<benji> gary_poster: ...and we're back
<gary_poster> benji, none the worse for wear?  any idea what went wrong?
<benji> my machine wasn't aknowleging that any USB devices exist; lots of things are usb, like WiFi and keyboards and other important things
<gary_poster> frankban, did you have plans as to what PPA to use for the haproxy?  I was thinking a juju-gui PPA might be good fwiw
<gary_poster> benji, so what did you do?  Did you have to perform the Sacred Rite of Beseeching the USB Gods to Intervene, involving bananas and chocolate sauce?
<benji> I think it was yesterday's update that got me.  After connecting an ethernet cable directly into my cable modem I was able to get a kernel update and it was happy after that.
<benji> And what you said.
<gary_poster> :-)
<gary_poster> cool
<benji> mmm, that makes me think of the fried banannas in the Thai place in Fredericksburg
<gary_poster> heh
<gary_poster> teknico, submitted code review of your branch; trying it out now in practice
<frankban> gary_poster: I am testing with my own PPA. IIRC, in launchpad is quite easy to move a package from one PPA to another. +1 on juju-gui PPA
<gary_poster> cool frankban, sounds good
<teknico> gary_poster, thanks for the reviews and the comments. I implemented your suggestions and proposed again
<gary_poster> great teknico.  would you like a follow-up?
<teknico> gary_poster, yes, thanks
<teknico> gary_poster, as far as linking the code docs from the project ones goes, I feel I'm missing something simple
<gary_poster> teknico, ack.  I'm guessing simple links like ../../../ don't work.  Even if they did, they are fragile.  I suppose we could also make a symlink from the yuidocs to within the html output, as part of the doc makefile?
<teknico> gary_poster, yes, I guess going up the dir tree would be fragile, but I can't even come up with a syntax for it :-)
<gary_poster> heh
<teknico> gary_poster, on the other hand, the symlink is the simple thing that I was missing :-)
<gary_poster> :-) cool
<teknico> gary_poster, uhm, no, not really. how do I express "current dir" with a file:// URL? is it even possible?
<bac> benji: when you were investigating saucelabs did you encounter any mention of capybara as an abstraction above the web drivers?
<benji> bac: nope, what does it do?
<gary_poster> teknico IME you are already in the file:// namespace, so relative links work great
<teknico> without protocol qualifier? ok, I'll try it
<bac> benji: it is a more abstract way to express the tests rather than using the web driver.  i just watched the 'retrofitting an existing web app with selenium' talk and he was really in favor of it.
<bac> benji: i can't tell if it is too ruby-centric, though.
<bac> benji: actually it is called "Better Late Than Never: Integrating Selenium After The Fact"
<benji> bac: I'm looking for info about it now.  If it requires a language other than a real programming language to describe the tests, I would be very skeptical.
<benji> I'll take a look.
<bac> benji: it is pretty unreal
<benji> Capybara appears to be Ruby-only.
<teknico> with "py" in the name?!? appropriation! mistification! sacrilege!
<benji> all my future python projects will include references to precious stones in order to confuse rubyists
<teknico> that'll teach them ;-)
<frankban> gary_poster: do you have a minute, after the call, for a quick hangout?
<gary_poster> frankban, y
<frankban> gary_poster: thanks
<gary_poster> bac benji bcsaller1 hazmat frankban Makyo teknico goodspud call now :-P
 * hazmat plays hangout ping-pong
<benji> grr, my two factor auth is screwed up again
<gary_poster> teknico, juju-ui?
<teknico> gary_poster, yep
<gary_poster> bac, juju-ui?
<gary_poster> teknico, don't hate me for abusing your poor code review :-D
<gary_poster> which is to say, sorry
<teknico> gary_poster, no worries :-)
<Makyo> Better to ask forgiveness, etc. :)
<gary_poster> :-) exactly Makyo, thank you teknico 
<gary_poster> didn't work :-/
<gary_poster> no dkim from rietveld, despite google connections, unfortunately
<gary_poster> if we had it, it would work
<gary_poster> but no biggie
 * gary_poster goes to lunch
<teknico> gary_poster, landing my branch, could not use the symlink but had to go for the fragile link solution
<teknico> gary_poster, also changed the Makefile doc targets and added a few, I remain awaiting the flames ;-P
<gary_poster> teknico, heh, ok thanks.  have a good evening
<benji> does anyone that is around know how long the charm usually takes to start?
<benji> it finally started, so I guess the answer is "five minutes longer than you are willing to wait"
<gary_poster> benji how long did it take you? My experience is 10-15 minutes IIRC
<benji> gary_poster: that's in the range, I was pretty bored waiting so I don't know for sure
<gary_poster> :-) k
<gary_poster> benji, would you agree that it would be a valuable task to teach the charm how to start and expose the test server?
<gary_poster> Then we would be able to write a selenium test against that, to run unit tests on different browsers
<benji> gary_poster: yep (we may do something else in addition, of course; but having an easy way to say "oh, run the unit tests too" would be a big win)
<gary_poster> cool
<gary_poster> Makyo, if you are looking for something to do at some point let me know.  I have something that would be probably fast for you, and less so for others
<Makyo> gary_poster, Alright.  Halfway done with #1099921.
<_mup_> Bug #1099921: Dragging services fails intermittently <juju-gui:Triaged> < https://launchpad.net/bugs/1099921 >
<gary_poster> Awesome Makyo!
<benji> bac: I am trying to remember how we got around SSH's fingerprint verification prompts from Juju.  Was the best we came up with setting UserKnownHostsFile and StrictHostKeyChecking in .ssh/config?
<bac> benji: i thought we just used the appropriate command line switch to tell it to leave us alone.
<bac> benji: a quick look at the buildbot charm should show, no?
<benji> bac: if we are directly using SSH that works, but this is Juju envoking SSH on our behalf
<benji> bac: good idea
<bac> oh yeas
 * Makyo dogwalk.
<benji> bac: I haven't attained enlightenment.  (but I have been reminded how many moving parts that project had)
<bac> amazing, huh
<hazmat> benji, that's one way..
<hazmat> benji, it was actually in juju for a little while before people freaked out about the security implications ;-)
<hazmat> so now everyone does it individually.. and blindly says yes.. which is not really an improvement
<hazmat> gojuju ends up doing tls with certs to avoid this fwiw
<hazmat> ie, they pass the server cert down via user data, its an insecure channel..  but its effectively the only proc against the pristine image.
<hazmat> digression
<benji> I could have sworn we found a better way, but I can't remember/find it now.  Maybe it will come to me later.
#juju-gui 2013-01-31
<bac> morning frankban and teknico
<teknico> bac, good morning
<frankban> hi bac 
<teknico> bac, do you see anything wrong with this diff? ;-) https://bazaar.launchpad.net/~juju-gui/juju-gui/trunk/revision/334
<frankban> teknico: a typo: unrelEased
<bac> i can't spell
<teknico> yep :-)
<bac> oops
<teknico> I mean, yep to the typo, not to bac's statement :-)
<teknico> wow, the release tarball is 25MB, and it expands to 160MB :-)
<bac> hazmat: ping
<hazmat> bac, pong
<hazmat> teknico, wow.. that's kinda of silly
<teknico> hazmat, well, good compression ratio, I'd say :-)
<hazmat> node_modules - 127mb
<hazmat> yui 38m yuidocjs 47m
<hazmat> silly
<hazmat> ah.. yuidoc recursively includes yui
 * bac bounced lp2kanban
<teknico> bac, frankban, how much time does the "FINAL=1 make dist" command take to complete? is it normal that it hangs in there for dozens of minutes?
<bac> teknico: depending on your upload speed it could take a while
<bac> you can check the project on LP to see that the release has been made
<bac> if so, then you're just waiting while the tarball is uploaded
<gary_poster> bac, I think you told me it took like 10 ir 15 minutes for you last time?
<teknico> bac, oh right, it's uploading 25M :-( yep, I'm watching LP staging
<bac> gary_poster: no, last time it took a really long time for me as my internet was being usurped and i didn't know it
<bac> hence those two nice bugs.  :)
<gary_poster> :-)
<teknico> bac, yep, given the upload bandwidth I have available, it's going to take 13 minutes at full "speed" :-P
<teknico> frickin' asymmetric lines
<bac> teknico: you have 1 up?
<teknico> bac, what's 1 up?
<bac> teknico: 1mb/s upstream bandwidth
<gary_poster> bac lp2kanban still not working for some reason.  (thank you for being lp2kanban doctor btw)
<teknico> bac, I have about 300kb/s upstream :-/
<gary_poster> (and feel free to request that you gain an apprentice)
<bac> gary_poster: first attempt to relaunch resulted in an unnoticed canonistack startup failure.
<gary_poster> oh ok
<bac> gary_poster: a new instance is now alive and coming up
<gary_poster> cool thank you
<bac> this whole cloud fad can't pass fast enough
<bac> oh, forgot the smiley
 * benji imagines a dirty villager yelling "Help! Help! My internet is being usurped!"
<teknico> where's round-robin hood when you need him?!?
<gary_poster> heh
<teknico> does anyone else want to look at the release on staging, before I make it final? https://staging.launchpad.net/juju-gui/stable/0.2/+download/juju-gui-0.2.tgz
<hazmat> teknico, we can probably trim the size of the download by getting rid of extraneous node_modules before upload
<teknico> hazmat, I'll try, but if compressing a tar archive works as it should, it won't shed much
<hazmat> the only node_modules we need are runtime app deps afaics (d3, yui), the rest aren't useful for binaries, and can be regen'd for source builds
<hazmat> the big win being dropping yuidocjs
<hazmat> teknico, true
<teknico> hazmat, also, the yui docs are not going to work that way, though
<hazmat> teknico, oh the output links to the node module?
<teknico> hazmat, apparently the yui doc is in node_modules/yuidocjs/output, and uses the redundant libraries in node_modules/yuidocjs/node_modules
<goodspud> gary_poster, thanks for you comments!
<teknico> I don't think we're pointing to it right now, however
<gary_poster> cool goodspud, thank you :-)
<hazmat> teknico, but the question is why we need it at all, its not linked from its doc output
<hazmat> so in the release tarball its not doing anything useful
<hazmat> teknico, ie make yuidoc -> yuidocs directory.. is not linked to node_modules/yuidoc
<teknico> hazmat, right
<teknico> hazmat, after nuking the whole node_modules/yuidocjs subtree, the archive size goes down to 19MB, 6MB less
<hazmat> that's a nice quick win, and 47MB for the extract
<teknico> hazmat, yep
<hazmat> if we can rid of yui in the tarball we can get under 10Mb easily i'd guess. afaics the only thing using it is the node-simulate in build-debug
<hazmat> hmm.. or not app/ass/js/yui links to node_modules.. i guess for debug using the yui cdn seed would do it though
<teknico> hazmat, since I already uploaded to staging, let's do this release as is, and refine the release process afterwards
<hazmat> teknico, sure just thinking of how to cut the chafe/fat from the land
<hazmat> future work indeed
<teknico> gary_poster, the release checklist says "This is a final release. Consider asking others to verify the package on staging."
<teknico> gary_poster, what if there's need for changes? what's the process then?
<gary_poster> teknico, do it again.  Staging is irrelevant
<teknico> gary_poster, do we delete the release on staging and reuse the same version number?
<gary_poster> In the sense that it is wiped out
<gary_poster> yes teknico if that is possible and easy then that would be what to do
<benji> I feel compelled to add that once a release is made to non-staging, then it should not be replaced.  There might be an argument for removing it, however.
<teknico> gary_poster, ok, I see how to do that
<gary_poster> benji +1
<gary_poster> thanks teknico 
<teknico> benji, totally agreed, only considering doing it while it's not final
<teknico> and agreed on the difference between replacing and removing too
<benji> cool; it's really nice that we have the LP staging environment.  It makes life so much easier being able to avoid non-reversable things.
<bac> benji: when you can get staging to not timeout...
<benji> well, there's that
<gary_poster> bac bcsaller benji frankban goodspud hazmat Makyo teknico call in 1
<teknico> is adding discussion cards during the weekly call to be considered cheating? :-)
<gary_poster> bcsaller, Makyo I moved our calls to today.  1PM bcsaller, and..I think you are two hours behind me Makyo, in which case it would be 2:30 for you.  On your calendar in any case.  Do those work for you?
<bcsaller> gary_poster: sounds good
<Makyo> gary_poster, Yep.  Thanks
<gary_poster> thank you both
<frankban> guihelp: it seems the latest release is missing read permission to all for build-debug/juju-ui/assets/javascripts/yui/ . As a consequence, nginx returns a 403 forbidden error.
<teknico> frankban, oops, really? let me check
<teknico> frankban, confirmed :-( there are quite a few directories with that problem in node_modules/, I wonder why
<frankban> teknico: if I run make distfile, the resulting tarball seems correct
<teknico> frankban, my umask is 0022, I don't get it
<teknico> and root's umask is 0022 too
<gary_poster> teknico, could you delete the tarball from the series please?  The charm should go back to working then.  The next release should have a different release number
<teknico> gary_poster, yes, doing it
<gary_poster> thank you
<teknico> done on both production and staging
<frankban> thanks teknico 
<teknico> sorry about this
 * gary_poster realizes he has 25 minutes for lunch
<gary_poster> biab
<teknico> people may want to review and land this before making a release: https://codereview.appspot.com/7227065
<teknico> if noone gets around to it, I'll have another shot at a release tomorrow
<bac> gary_poster: i am through poking at lp2kanban.  please, PLEASE, clean up done:done.  :)
 * Makyo walkinates the dogalope.
#juju-gui 2013-02-01
<teknico> NOTICE: about to make a release
<benji> yow, it's a little cooler this morning than I expected, -7C
<teknico> will someone else check that the release candidate tarball on staging is fit for final release? thanks https://staging.launchpad.net/juju-gui/stable/0.2.0/+download/juju-gui-0.2.0.tgz
<benji> teknico: I'll be glad to look, although I'm not entirely sure what all should be checked
<teknico> benji, thanks, there are some suggestions in the release checklist, in docs/process.rst
<benji> cool, I'll look at those
<teknico> frankban, how do I "juju deploy" from staging?
<benji> teknico: the release looks good.  The tests pass and I started the app and poked around in it for a while and everything worked as expected and no JS errors were generated
<teknico> benji, great, thanks
<benji> my pleasure
<frankban> teknico: you can't. You may want to make and upload a trunk release and then test it before uploading the stable one, e.g.: "juju-gui-source: trunk" in the config file. you can also run the charm tests against trunk setting the env var JUJU_GUI_SOURCE: JUJU_GUI_SOURCE=trunk jutsu test...
<benji> frankban: speaking of the charm, I haven't been able to use the juju-gui-source setting to get the charm to run against a different release; is it supposed to work and how am I supposed to use it?  (I have been doing a "juju set" just after deploying the service.)
<frankban> benji: it should work
<benji> ok, I'll try again and see if I can track down what is going wrong; I assume the "juju set" bit is the right way to do it, correct?
<frankban> benji: something like "juju set juju-gui juju-gui-source=0.1.4
<benji> frankban: oh, I thought you could give it a branch URL
<frankban> benji: otherwise you can pass a customized config.yaml to deploy --config
<frankban> benji: yes, that too, e.g. juju-gui-source=lp:juju-gui
<benji> cool; I'll try harder then ;)
<frankban> benji: it is considered a branch if it starts with "lp:" or "http://"
<benji> oh, so no "bzr:"?  That is probably where I was going wrong.
<frankban> benji: precisely, we should add the "bzr:" scheme too, it's quite easy, feel free to create a card if you want to
<benji> frankban: will do
<frankban> benji: cool thanks
<teknico> benji, while you're at it, maybe add to the card the possibility to deploy from staging :-)
<benji> teknico: sure :)
<benji> frankban: https://bugs.launchpad.net/juju-gui/+bug/1112529
<_mup_> Bug #1112529: Support "bzr:" scheme in juju-gui-source charm setting. <juju-gui:New> < https://launchpad.net/bugs/1112529 >
<benji> teknico: https://bugs.launchpad.net/juju-gui/+bug/1112530
<_mup_> Bug #1112530: Support deploying the GUI charm from LP staging <juju-gui:New> < https://launchpad.net/bugs/1112530 >
<frankban> thank you!
<teknico> benji, thanks
<benji> np
<frankban> guihelp:  I wonder how, now that the charm is in the store, we are supposed to re-propose new changes
<frankban> teknico: done?
<teknico> frankban, what?
<frankban> teknico: the release
<teknico> frankban, nope, still upoading
<teknico> or something :-)
<hazmat> frankban, merge proposal .. with approval by charmers
<teknico> frankban, but I think there's no need to wait landing branches now
<hazmat> frankban, so ideally if there's a round of dev on it, we'd do it with our normal process against the team branch, and then propose to the official charmers version
<frankban> hazmat: so, we might want to collect some changes before re-proposing 
<hazmat> frankban, yes
<frankban> hazmat: cool, thanks
<hazmat> frankban, technically the distinction isn't in the store but the owner in the store.
<hazmat> np
<teknico> frankban, finished, https://launchpad.net/juju-gui/+milestone/0.2.0
<frankban> teknico: great!
<hazmat> frankban, its about 2-5 days for a  charmers review.. this their queue http://jujucharms.com/review-queue
<frankban> hazmat: ack. so, I'd suggest, e.g. when testing the GUI (deployments, new releases, etc.), to always use the latest version of our charm, i.e. most of the times, the one owned by juju-gui. what do you think?
<hazmat> frankban, sounds sensible, but socially we want to continue distill/promote to charmers (aka the official charm)
<frankban> hazmat: of course. agreed
<frankban> teknico: the release tarball seems broken :-( . http://pastebin.ubuntu.com/1597149/
<teknico> what?!?
<frankban> teknico: I am downloading the tarball, I will try to uncompress it manually.
<teknico> frankban, me too, the local copy is correct
<teknico> the size is wrong, and the content is junk :-(
<frankban> teknico: I confirm the uploaded tarball is broken. please remove the release
<teknico> frankban, done, I'll upload again
<teknico> guihelp: the release tarball on staging is correct. Is there a way to upload that copy to production, rather than the one I have locally?
<frankban> teknico: I don't know and I guess no. however, why do you want to do that? I suggest to try the release process again, it could be nice to find what's wrong. Is there a final tarball (downloaded from launchpad) qa step? if not, we should add it.
<hazmat> teknico, define production?
<teknico> hazmat, I meant stable
<teknico> frankban, I'd like to do that because it would be easier and faster. The release process has went well up to generating the tarball: as I said, the local one is correct. I am uploading it again.
<hazmat> teknico, i don't know, effectively your asking can we can copy tarballs in launchpad to replace a broken one?
<teknico> frankban, you can find the release checklist in docs/process.rst. There are a number of qa steps, I'll add one more.
<hazmat> teknico, that seems best.. if the tarball is entirely broken.. replacing/updating seems okay.. 
<teknico> hazmat, I deleted the broken one already
<teknico> hazmat, I'm asking if we can do a lp-to-lp copy in place of a standard upload, as a matter of convenience
<frankban> teknico: thanks, I believe that checking that everything is ok with the tarball at the end of the process is without doubt a good idea ;-)
<teknico> frankban, I guess we hadn't yet had problems with the final uploading step
<teknico> I'm still mistified how this could happen
<hazmat> teknico, not that i know
<teknico> how do you end up with 34MB of garbage after having uploaded a 25MB tarball?
<frankban> teknico: try to restart your router ;-)
<teknico> frankban, I'll see if they can restart the internet
<benji> https://www.youtube.com/watch?v=iDbyYGrswtg
<teknico> broken again :-(
<teknico> this is even weirder though:
<teknico> the gpg signature on lp is correct, while the file is not
<benji> the Elders of the Internet want us to have a standup in 3 minutes
<teknico> I guess the upload_release.py script uploads the .asc signature file too
<goodspud> Hey all. Are we having our daily stand up today?
 * frankban connecting to the Internet for the daily call
<teknico> deleted again :-/
<hazmat> is ther a standup?
<hazmat> looks like
<bac> teknico: at least len(juju) < len(ensemble)
<teknico> bac, that's true :-)
<hazmat> :-)
<hazmat> bcsaller, we're really short on pyjuju reviewers.. if you have a moment would you mind having a look at  https://codereview.appspot.com/7241062/
<bcsaller> hazmat: yeah, just proposed my branch so I can look at that one now
<hazmat> bcsaller, thanks, its thankfully pretty small
<hazmat> a one liner and a drive by
<benji> teknico: a small branch you might review: https://codereview.appspot.com/7231077
<teknico> benji, looking
<teknico> benji, there's a conflict in the lp diff, and Rietveld says "error: old chunk mismatch" on docs/process.rst
<benji> darn; let me look
<benji> teknico: fixed: https://codereview.appspot.com/7231077
<teknico> benji, looking
<teknico> benji, I uploaded the release tarball to U1 (and downloaded it to check, successfully)
<teknico> benji, I shared a folder with you, you should have an email
<teknico> benji, in the folder you'll find the tarball and the .asc signature file
<benji> teknico: cool.  I suppose that I should pick up the release instructions just after the bit about making sure the release works, right?
<teknico> benji, yes, you should put both of them in a releases/ directory in a juju-gui branch
<benji> k
<teknico> benji, well, the release checklist says to run "FINAL=1 PROD=1 make dist"
<teknico> benji, that also tries to build the tarball
<teknico> benji, you only need to run the last step: "python2 upload_release.py juju-gui stable 0.2.0 releases/juju-gui-0.2.0.tgz"
<benji> sounds good
<teknico> benji, however, I don't know where the upload_release.py script comes from :-)
<teknico> it appears in the branch dir during the release process
<teknico> like, it's magic ;-)
<benji> I can work that magic.
<teknico> that's good :-)
<teknico> benji, do you have time for a quick hangout?
<benji> teknico: sure; is juju-ui free?
<teknico> let's see
<benji> it is
<Makyo> James is home sick, I'm going to duck out to a coffeeshop.  Hopefully less awful coughing there.
<benji> teknico: https://codereview.appspot.com/7231077
<teknico> benji, looking
<benji> k
<frankban> so, you think you love JavaScript? http://dmitry.baranovskiy.com/post/91403200
<teknico> guihelp: I cannot find the standard review markers we decided upon ("Land as is", "Land with changes" and so on), where are they?
<Makyo> teknico, I don't know if we wrote those down anywhere.  It's those two and "request re-review", as far as I know.  Any suggestions on where we should put them?  Docs, maybe?
<hazmat> process.rst would do the trick
<teknico> that's where they are!
<teknico> silly me, I was reviewing exactly that file :-D
<Makyo> Oh!  Well, there you go :)
<teknico> it must be friday afternoon ;-)
<teknico> benji, I'm sorry, one more iteration needed :-)
<benji> heh, no worries
<benji> comments in the review?
<teknico> benji, yep
<benji> cool
<bcsaller> Makyo: can I ask what you found to be at the core of the dragging issue?
<benji> teknico: once more, with feeling! https://codereview.appspot.com/7231077
<teknico> benji, allegretto con brio!
<Makyo> bcsaller, When things were updated, the datum associated with each service didn't equal the datum passed in as 'd' to drag.  When setting the translateStr in selection.attr('transform', function(d) { return d.translateStr(); }), we were also overloading the 'd' variable.  Changing it to function(datum) and still using 'd' fixed that.
<benji> :)
<bcsaller> ahh
<Makyo> bcsaller, Additionally, the service in the relations was being matched on modelId, but the relations objects were stale, so relation lines weren't updating properly either.
<Makyo> ...relations which used to be 'relPairs', to clarify.
<teknico> benji, done
<teknico> I guess we need to come up with some joke like: "What do you call two perfectionists one-upping each other? ..."
<teknico> missing the closing part though :-)
<benji> teknico: I have a good punchline but if I tell you, you will come up with a better one.
<teknico> benji, true, but someone's got to give in sooner or later :-)
<teknico> benji, btw, any luck with the release upload?
<benji> teknico: I got the file, but other than that I have been distracted by the QA bits.  I'm looking at it now.
<teknico> benji, out of curiosity, what upload bandwidth do you have available?
<benji> teknico: 5 megabit
<teknico> upload?!? oh wow. oh wow.
<benji> my link is hilariously asymmetrical: 100 down, 5 up
<teknico> well, around here it can be 20 (nominal) down, .3 up, so...
<teknico> more than .5 up is almost unheard of
<teknico> that is 0.3 and 0.5 resp., to be clear
<benji> yeah, that's common here too; one of the big reasons to buy this particular house was that a good connection was available
<bac> https://files.one.ubuntu.com/sEhlVl2GRu28wl3nHw2rhw
<bac> bcsaller: can you see that link?
<bcsaller> bac: after SSO it gives me an error
<bac> doh
 * Makyo discovers lack of charger in laptop back.  Back home
<benji> Makyo: when you walk into the house start yelling "Unclean. Unclean!" at the top of your lungs
<bac> bcsaller: was trying to show you the screenshot for bug 1112717
 * bac needs to figure out ubuntu one share settings
<bcsaller> bac: its on the bug itself, right?
<bcsaller> I can see it there
<bac> bcsaller: yep
<bac> just another amusing/hair pulling bug
<bcsaller> thats great :-/
<bac> bcsaller: if you can think of things you think may be broken let me know and i'll try them
<bac> so far it is fish in a barrel
<bcsaller> bac: I find that surprising as is, at this point I'd assume it mostly doesn't work. Anything with a transform attr on it is suspect it sounds like
<bac> bcsaller: do you think the exercise is pointless atm?
<bac> i.e., is there a class of problem that may be solved in one way so there's no need to identify them all?
<bcsaller> bac: no, generating a list of things that don't work is fine, but I don't think you need to find them all, just calsses of errors
<bcsaller> classes
<bcsaller> sounds like the same thinking
<bac> calluses of errors
#juju-gui 2014-01-27
<gary_poster> ok, in addition to having my opinion of System 76 machines reinforced, now my opinion of Dell machines is reinfirced. :-/
<rick_h_> gary_poster: +1 all the way around
<gary_poster> :-/
<rick_h_> at least in laptop land
<gary_poster> That was what I was thinking--if I got a desktop I'd be fine
<gary_poster> No such luck this time around, anyway
<rick_h_> yea, I did go with system76 for a desktop and ok. Laptops though I'm still not a fan yet. Seen too many issues and build isn't as solid as I'd like
<gary_poster> I don't know who to use for desktops now.  Laptops I'm Apple, and Lenovo otherwise, from here on out until convincing evidence is given. :-)
<rick_h_> that's what I've got written down (reverse order)
<gary_poster> heh
<gary_poster> frankban, hey.  replied to Wm's email about the GUI authentication issues.  Curious about your thoughts, including whether you'd like to set up a meeting with him to explore more.
<frankban> gary_poster: looking
<gary_poster> ty
<hatch> morning
<rick_h_> party
<gary_poster> hiya
<hatch> is there a way to get askUbuntu to email me every time something happens on a thread I've interacted with? 
<hatch> This weekend I found myself wanting 'to' functionality in the GUI
<hatch> because quickstart is in juju-stable will it be in universe in 14.04?
<rick_h_> it was a goal I thought so that it helps you get juju installed
<hatch> I was thinking that it NEEDS to be in there haha, the quickstart story i just too awesome not too
<rick_h_> yea, jcastro showed it off and had some <3 for it end of last week
<hatch> `apt-get install juju-quickstart && juju-quickstart ghost-bundle-simple` is an awesome story
<rick_h_> yep
<frankban> hatch: I just sent an email about oddities I've found while working on the server side basic HTTP auth for the putCharm functionality. Could you please take a look?
<hatch> yup reading it now
<hatch> frankban just to clarify - does option 1 work in firefox 100% of the time?
<hatch> or does it also fail the first time
<gary_poster> also fails first time, according to email
<frankban> gary_poster, hatch: right, also first time
<hatch> hmm
<hatch> looking into this
<frankban> hatch: thank you, it would be nice if you are able to reproduce that
<hatch> I'd need the charm, have you uploaded the version where this is happening?
<gary_poster> frankban: looking for bugs.  so far only found http://stackoverflow.com/questions/9459017/xmlhttprequest-authentication-not-working-in-firefox : 2012, so old, and no resolution.
<gary_poster> frankban: OPTIONS call? http://stackoverflow.com/questions/19234892/xmlhttprequest-based-cors-call-with-basic-auth-fails-in-firefox-and-chrome
<gary_poster> worth investigating charm log at least
<hatch> that should only be required cross domain
<frankban> hatch: lp:~frankban/charms/precise/juju-gui/http-proxy is what I have now. It would be nice if we can dupe that excluding the proxy, to ensure this is not a problem on the gui server side. e.g. pointing the GUI directly to the core API server
<hatch> frankban I'm pulling down the charm now and will give it a go
<gary_poster> true
<gary_poster> hatch, frankban, but charm log coudl be informative
<hatch> frankban the env is spinning up, I'll keep you posted
<bac> hey rick_h_ can you review https://pastebin.canonical.com/103628/plain/ before i submit the RT to see if i forgot anything?
<rick_h_> bac: looking
<bac> rick_h_: i've verified there is no impact on CI so the window where qa and staging point to the same machine is unnecessary
<rick_h_> bac: so we verified we can keep that IP if we have to rebuld staging/qa?
<rick_h_> bac: that's the only part I have questions on in that. Looks good otherwise. 
<rick_h_> bac: I don't know how staging. is currently handled with a rebuilt/keeping the IP in canonistack
<bac> rick_h_: we currently control the IP used by staging.j.c.  it is assigned in the deploy script to the apache instance.  the revno is subsequently updated by using juju, so the FQDN is never used again.
<rick_h_> bac: ah ok then
<bac> so the name can change and no one notices or cares, except those of us who want to hit it
<rick_h_> right
<bac> ok, i'll submit pretty much as is.  i just didn't want to file an RT with obvious holes.
<rick_h_> bac: yea, looks like what we talked about here
<bac> simplified
<rick_h_> right, because we control the IP address it makes things easier?
<bac> rick_h_: well because the name 'staging' is not used in any of the CI machinery
<rick_h_> bac: right cool
<bac> gary_poster: do we have a departmental meeting with IS?
<gary_poster> bac, every other thursday.  cancelled this week because they are out.  Do you have somethng to raise?
<hatch> vim's recording 'feature' has to be the under the worst key possible lol
<bac> gary_poster: yeah, i filed an RT for getting staging on prodstack.  asked spads what else to do to get it scheduled and he said to raise it in that meeting.
<gary_poster> heh, it has bitten me more than anything else in vi as well, yes, hatch
<bac> gary_poster: i don't think we want to wait 2.5 weeks to get it on the radar
<gary_poster> bac ack. I can ask mramm to escalate to robbiew, who can set priority.  gimme rt?
<bac> gary_poster: RT 67257
<gary_poster> bac, ok. will cc you.
<bac> thanks
<gary_poster> bac, staging.jujucharms.com is confusing naming IMO and FWIW.  staging.manage.jujucharms.com?  managestaging.jujucharms.com?  ugh, I know, but we will probably want staging for GUI jujucharms also, unless it is wiped out in favor of other sites soon.
<gary_poster> that's not important for me escalating--just a comment/thought
<bac> gary_poster: good point
<frankban> gary_poster: I am still debugging. re: GUI/quickstart auth, I like your idea, a command like that can be used also by quickstart. curious to see if they come up with other ideas
<gary_poster> cool frankban thx
<bac> gary_poster: ok, i'll modify to request staging.manage.jujucharms.com and qa.manage.jujucharms.com.  what a mouthful.
<hatch> frankban ok I finally got this thing up and running and am getting a 400 when trying to upload the charm
<gary_poster> :-) k thanks
<rick_h_> gary_poster: bac in the prioritizing, can we keep the 'move jujucharms to juju-core' above this?
<gary_poster> rick_h_: ack, +1.  rt please?
<bac> rick_h_: +1
<frankban> hatch: 400? how did you create the zip?
<rick_h_> gary_poster: 67167
<rick_h_> thanks
<frankban> hatch: FWIW, the charm files must be at the root of the zip, e.g. it does not work if you compress the charm dir
<gary_poster> thanks rick_h_.  bac, rick_h_, I suggest making RT links on the kanban cards if you have not already
<rick_h_> gary_poster: yep, full link is there
<gary_poster> ack thanks, soory I missed it
<hatch> frankban I downloaded the zip from github for my ghost charm
<hatch> frankban I pinged you the url
<frankban> hatch: what are the zip contents? does it create a root dir when you decompress it?
<hatch> frankban well would that give me a 400 if they weren't?
<hatch> what should I look for in the charm to make sure I have the proper one deployed?
<frankban> hatch: what's the content of the response body?
<hatch> {"Error":"invalid charm archive: bundle file not found: metadata.yaml"}
<gary_poster> well there ya go ;-)
<frankban> hatch: exactly, metdata.yaml must be at the zip root level.
<rick_h_> hah
<hatch> ok that's not going to work
<frankban> hatch: so you need to create another zip to test it
<hatch> will do
<hatch> buut we will need to allow it to be nested one folder deep
<gary_poster> methinks that dragging a folder (and having us figure out what to zip) will be much less fiddly for users
<rick_h_> +1
<frankban> +1
<rick_h_> though I think the idea of wget xxx.zip and deploy it will be more adminy-useful. 
<rick_h_> kind of like bundles where they're getting sent around via email you can more easily link/share a local/dev charm as a single file
<rick_h_> jujugui call in 5?
<gary_poster> bah thank you
<hatch> frankban works with a single request in chrome
<frankban> hatch: how do you see that it's a single request?
<hatch> just looking in the network tab
<hatch> looking in the charm logs now
<frankban> hatch: ok
<frankban> hatch: /var/log/upstart/guiserver.log
<gary_poster> jujugui call in 2
<gary_poster> Makyo pingy
<hatch> frankban ok I see the two requests in the guiserver logs
<hatch> after the call I'll try firefox
<frankban> hatch: cool
<hatch> frankban unfortunately I can reproduce your issue with Firefox but Chrome works 100% of the time
<frankban> hatch: Firefox version?
<hatch> frankban OSX 26.0
<hatch> it has the issue, open firebug, works no problem :/
<frankban> hatch: re python gcc errors: try installing libpython-dev, if that fixes the issue please add it o sysdeps
<hatch> uable to find package
<frankban> hatch: libpython2.7-dev
<frankban> ?
<hatch> frankban https://gist.github.com/hatched/8651673 these are all the packages I have available
<frankban> hatch: just python-dev?
<hatch> installing
<hatch> hah
<frankban> hatch: so, were you able to dupe the problem in FF?
<hatch> frankban yes, now trying to track down the issue because clearly this is unacceptable 
<frankban> hatch: cool thanks, weird the firebug thing
<hatch> yeah....and you were saying that the same issue happens with option 2?
<frankban> hatch: yes, with option 2 FF just refuses to include the auth header in the first request
<frankban> hatch: but you can dupe that too switching to juju-gui-debug=true and applying that diff
<hatch> yeah, I'll take your word for it for now, just doing some research
<frankban> hatch: I'd be curious to see what's the IE behavior
<hatch> I can spin IE up after my next call
<hatch> unfortunately I feel like I'm coming down with a cold so brain is moving a little slow haha
<frankban> heh
<hatch> frankban ok I'm going to apply the diff and see option 2 - firefox strips the auth headers unless the server responds with a 401, it then should make another request with the headers
<frankban> hatch: so firefox don't trust us
<hatch> it doesn't :) but it SHOULD be making the second response after the guiserver responds with the 401
<hatch> but it doesn't appear to be doing so unless firebug is open
<gary_poster> luca_: https://plus.google.com/hangouts/_/canonical.com/discuss-local ?
<gary_poster> rick_h_: Makyois sick
<luca_> gary_poster: thank you :)
<gary_poster> welcome :-)
<hatch> frankban I guess a hacky workaround is to have it try twice :/
<rick_h_> gary_poster: ok, thanks for the heads up
<frankban> hatch: I think we are hitting https://bugzilla.mozilla.org/show_bug.cgi?id=901342
<frankban> hatch: if you send a string in place of the zip file, the second request is correctly executed. Also note that the firebug network tab is mentioned in the bug comments too :-/
<hatch> frankban hah, in call, will read in a bit
<hatch> frankban ok off call, reading now
<hatch> frankban I would agree that's the same bug
<frankban> hatch: yeah, tried changing the GUI to send a random string and the second POST request is corretcly sent by firefox
<hatch> ok, so....workaround is to try multiple times?
<hatch> I'll also add the most recent version of firefox to that bug
<hatch> yuck I hate writing hack code to workaround bugs
<hatch> bleh
<hatch> frankban I'm spinning up a windows 8 vm to test there
<frankban> hatch: sending the file contents?
<hatch> frankban well we try once, if it doesn't resolve to 200 in x seconds then try again 
<hatch> that 'should' workaround the firefox issue
<frankban> hatch: 200 or 400 or 500...
<frankban> hatch: and now IE... at least it seems the proxy works well
<hatch> yes we'll need to check those other responses as well.
<hatch> yep testing Ie now
<hatch> yeah the proxy seems to work just fine :)
<jcsackett> hey juju-gui, is bac likely to be back online today? have some questions about some ingest code of his.
<rick_h_> jcsackett: should be
<rick_h_> jcsackett: his interwebs hate him
<hatch> frankban it looks like Windows can only (natively) turn a folder into an archive so if the charm has to be the root in the zip then that's not a very good story in Windows. This was a limitation of the juju-core implementation? 
<jcsackett> rick_h_: awesome. i'll shoot him an email then so he and i can link up whenever he's back.
<jcsackett> thanks.
<frankban> hatch: yes, we can propose core devs to change the API like the following: if the zip root includes only a directory, assume the charm is included in that directory. the directory name should not be relevant
<hatch> right ok good I'll file a bug to that effect
<frankban> hatch: cool thnaks
<hatch> at the moment I'm having issues with my ie vm connecting to my juju instance 
<hatch> sorry for the delay
<frankban> hatch: np
 * rick_h_ goes to have a lunch shoveling snow while he waits for his snow blower to arrive 
<hatch> lol
<frankban> hatch: FYI I noticed that if an error occurs core returns a 400 code and the details can be found in the response body. we need to handle that case, maybe just adding an error notification
<hatch> ok sounds good, I wasn't entirely sure the structure of the response but now that we have it it's easy to check for.
<frankban> sure
<hatch> ugh I hate Windows
<hatch> I can't seem to get this tunnel to work
<hatch> yay finally got the tunnel to work
<hatch> should have known to just done it in the host
<hatch> frankban  just FYI it looks like there is an issue with the .zip upload in IE but the inspector is....well it's the IE inspector lol 
<hatch> frankban  here is the error from IE when I try to upload a zip https://gist.github.com/hatched/b80599004f52d3464458 does this look like an error from juju-core/guiserver? The IE inspector is being pretty useless so I'm having a hard time tracking it down 
<hatch> gary_poster https://bugs.launchpad.net/juju-gui/+bug/1273363 IE11 show non-supported browser window....I'll let you decide if this is an issue or not :)
<_mup_> Bug #1273363: Non-supported browser warning on IE11 <juju-gui:New> <https://launchpad.net/bugs/1273363>
<gary_poster> hatch: does everything else work?
<gary_poster> hatch, nm: I will add IE 11 support to huw's list, and see if he's willing :-)
<hatch> gary_poster nope there are some d3 issues
<hatch> at least that's all I've found
<gary_poster> hatch, darn.  ok thanks
<hatch> so it IS broken so that's a good thing the warning is there
<gary_poster> yup
<gary_poster> though we should maybe suggest IE 10 also :-)
<hatch> yeah that's probably a good idea
<hatch> frankban ok I've figured out why IE doesn't work for dropping the zip.... IE calls zips "application/x-zip-compressed" not "application/zip"
<Makyo> Ugh.  Alright.  Half-here.  Will be all-here once meds kick in.
<rick_h_> Makyo: hey, good meds I hope. If you get a sec would appreciate a pointer to the location of the code you reference in the reafctor card for "Finding the real position from canvas coordinates"
<rick_h_> Makyo: my git-fu is failing to find something promising
<Makyo> rick_h_, sure thing!  One sec.
<frankban> hatch: uhm, thanks for investigating
<hatch> frankban I'll take over getting the fix landed for that
<hatch> frankban after adding python-dev I was also able to get make check to run on quickstart thanks
<hatch> so-much-multitasking
<frankban> hatch: cool, :-)
<hatch> frankban maybe 2h before our daily tomorrow you can give me a walk through of the execution order of quickstart? 
<hatch> 3 vm's running and this thing is still humming along
<hatch> vroom vroom
<Makyo> Oh for pete's sake.
<jcsackett> bac: can you look at https://code.launchpad.net/~jcsackett/charmworld/fix-trigger-test-criteria/+merge/203401
<bac> jcsackett: sure
<jcsackett> thanks.
<bac> jcsackett: done and thanks.
<hatch> rick_h_ it looks like your neighbours across the street are lazy at snow removal :)
<rick_h_> hatch: heh, he's got a giant john deere two stage thrower. I think he waits for it to get high enough to be able to use his beast and then just does 3 passes and calls it a day
<hatch> lol
<rick_h_> and when I see him out I beg him to run his giant machine in front of the mailbox
<hatch> community mail there?
<rick_h_> ?
<rick_h_> we all have a mailbox and mail person that delivers each day
<rick_h_> not sure what makes community mail or what other options there are
<hatch> ohh now I See, sorry I didn't look close enough
<hatch> rick_h_ the new areas here have a single mailbox which you have to walk to instead of curbside or at the door mailbox
<hatch> is what I meant about a community mail
<rick_h_> ah, yea that would stink
<bac> benji, rick_h_: i've added a note regarding the deployment issue to our google doc with the rollout instructions. please be aware of it if you request a deploy in the near future.
<rick_h_> bac rgr
<benji> k
<bac> rick_h_: sadly deej is not going to be around to work on it this week.  :(
<hatch> rick_h_ haha I agree it would
<rick_h_> bac: bummer, hate this stuff hanging over our heads
<bac> yep
<hatch> I wonder if juju will run in a vagrant instance 
<rick_h_> hatch: they've got images for that
<rick_h_> hatch: http://blog.utlemming.org/2013/12/beta-cross-platform-juju-development.html
<hatch> cool I'll have to check those out. Until I can get an on-metal version of Ubuntu working vagrant images seem like the most efficient way of working on various juju bits
<hatch> actually, even after I do it would probably still be the best
<hatch> mdn.microsoft.com now requires you to log in to read the docs.... FAIL
<hatch> msdn that is
<rick_h_> jujugui review please https://github.com/juju/juju-gui/pull/87 I think I found the code Makyo was referring to. Makyo if you're up for a review would appreciate your eyes to make 100% sure it's the right things. 
<Makyo> Yep, on it rick_h_ 
<bac> man, ignore your trusty vm for a few days and there is hell to pay.  so much updating.
<rick_h_> bac: hah, tis true
<bac> it's like one of those damned japanese toys you have to feed
<rick_h_> just hope it didn't die from neglect and now it can't come back to life
 * rick_h_ updated the laptop to trusty this weekend so out of stable machines. Crosses fingers
<hatch> rick_h_ you updated your work machine to non-stable env? lol
<hatch> rebel!
<rick_h_> hatch: both of them man, it's crazy
<hatch> bac what do you use to clean your laptop screen? 
<rick_h_> will have to stagger updates
<hatch> lol!
<hazmat> rick_h_, how's it been so far?
<hatch> I usually wait months before updating to the newest STABLE version haha 
<rick_h_> hazmat: trusty? so so. Just got lxc juju working today with the 'manually create /etc/lxc/auto' trick and latest golxc
<rick_h_> hazmat: other than that been fine
<bac> hatch: hah, i use the squirt bottle i bought from sunglasses hut for $5 b/c they promised free refills and a microfiber.  luckily there is SG Hut 1/4 mile from here so i will make them refill that sucker until i get my money's worth.
<hazmat> rick_h_, cool, good to hear. i'll probably wait few weeks, but planning on diving early
<bac> that said,i think windex and a rag works really well
<hatch> haha ok, so some diluted rubbing alcohol it is then! I was going to try the same but I wasn't sure....apple and all haha
<rick_h_> hazmat: yea, laptop was kind of on rarind and ran into some issues with old python so jumped
<rick_h_> raring
<bac> hatch: it's just glass.
<bac> well, sort of
<hatch> bac no it's squishy 
<hatch> I thought it was glass too
<hatch> haha
<rick_h_> hatch: it's magic apple glass. You have to take it to an apple store for cleaning or void your warranty :P
<hatch> rofl
<hatch> I wouldn't put it past them
<bac> rick_h_: is this the problem with lxc/trusty that was supposedly solved: ERROR Get http://10.0.3.1:8040/provider-state: dial tcp 10.0.3.1:8040: connection refused
<rick_h_> bac: no, that's a failed old environment. rm your .juju/environments/local.jenv I think
<bac> i don't have one of those
<rick_h_> bac: also make sure `sudo lxc-ls` is clear of any lingering units
<bac> it is
<bac> :)
<rick_h_> bac: is anything in .juju/environments?
<bac> wait it was local.jenv
<bac> thanks
<rick_h_> cool
<rick_h_> bac: and then sudo mkdir /etc/lxc/auto 
<rick_h_> will fix the last issue I had today
<bac> already did that
<rick_h_> k
<huwshimi> Morning
<gary_poster> morning
<hatch> ahoy huwshimi
<hatch> sweet charm upload now works in IE11
<hatch> that was kind of a pita to debug, but the new IE11 debugger is leagues ahead of it's predecessor 
<hatch> jujugui looking for a review https://github.com/juju/juju-gui/pull/88 no qa necessary
<gary_poster> cool hatch.  any result on the FF issue?  I didn't see a resolution
<gary_poster> I will review
<hatch> gary_poster we ran into what we think is this bug https://bugzilla.mozilla.org/show_bug.cgi?id=901342 but with the changes to fix IE appear to have fixed FF, I'm going to have to spin up my other ubuntu vm to check there too
<gary_poster> hatch, so you mean the auth headers sem to have fixed FF?
<hatch> I find when I open certain vm's together it kernel panics so gota do all this in order haha
<gary_poster> heh\
<gary_poster> I saw the bug from frankban's email, yeah
<hatch> gary_poster yeah, they are now working first time every time in OSX
<hatch> OSX FF that is
<gary_poster> awesome
<hatch> Chrome always worked
<hatch> IE11 required them....even though there is absolutely nothing wrong with how we were doing it before
<hatch> :/ IE
<gary_poster> hatch +1 with ultra trivials.  Only downside to new setup is that making small changes feels so expensive now. :-(
<hatch> but hey....if it works better...yay
<gary_poster> definitely yay
<hatch> lots of moving parts for sure - not to mention the required setup to build custom juju, custom charm, custom branch lol
<hatch> I wish I had a vm with IE10 still....but it looks like Win 8 just auto updated me to 11
<hatch> maybe that's a good thing, everyone else with IE10 will be running 11
<gary_poster> heh ok
<hatch> so the gui charm is using the tornado web server?
<gary_poster> yes
<hatch> well the good news is that it works properly according to the basic auth spec....unfortunately browsers don't haha
<hatch> gary_poster the auth headers appear to have fixed it in Ubuntu FF which is odd because Francesco said that wasn't the case....but I'm sure he will test it again while working on the charm
#juju-gui 2014-01-28
<marcoceppi> gary_poster: ping
<gary_poster> marcoceppi: pong
<marcoceppi> gary_poster: hey, we're sprinting and using maas + juju + gui
<marcoceppi> gary_poster: when deploying a simple mysql + mediawiki bundle relations aren't being created
<marcoceppi> repeated on multiple pieces of hardware for multiple bundles for multiple deployments
<marcoceppi> what do you need from me for debugging
<gary_poster> and works on ec2 I assume
<marcoceppi> not tested against ec2
<marcoceppi> just against various heaps of hardware, but the physical add-relation command works from the gui and juju
<marcoceppi> on juju 1.17.0
<gary_poster> k, thank you.  frankban: can you direct marcoceppi to the bundle deploy log in the charm?  (marcoceppi, looking for docs if he's not around)
<rick_h_> using the bundle the relations are added by the deployer and not the gui. We'd have to trace/look at the websocket log
<gary_poster> we have good logs on charm
<rick_h_> heh or that sounds even better
<frankban> gary_poster, marcoceppi: gui server logs can be found in /var/log/upstart/guiserver.log
<gary_poster> logs to send: /var/lib/juju/units/[NAME OF UNIT]  /var/log/upstart/guiserver.log
<gary_poster> thanks frankban, and HACKING doc was perfect :-)
<gary_poster> marcoceppi: also, if you are curious https://<juju-gui-url>/gui-server-info might be interesting
<frankban> gary_poster: yes: https://bazaar.launchpad.net/~juju-gui/charms/precise/juju-gui/trunk/view/head:/HACKING.md#L222
<frankban> marcoceppi: ^^^
<gary_poster> frankban: is it worth mentioning builtin-server-logging=debug also?
<frankban> gary_poster: it is already mentioned in the HACKING file
<frankban> line 233
<gary_poster> frankban: I know, that's where I was stealing it.  I meant do you think it would help to ask marco to change that config for our debugging
<marcoceppi> gary_poster: frankban http://paste.ubuntu.com/6832109/
<marcoceppi> nothing really interesting in guiserver.log
<frankban> gary_poster: oic. it is useful to inspect the Websocket requests/response from the GUI to the guiserver
<frankban> marcoceppi, gary_poster: lines 154-157 seem interesting
<rick_h_> frankban: +1 seems Juju didn't like something in the data 
<marcoceppi> OH I KNOW THIS BUG
<rick_h_> marcoceppi: have the bundle file up? does it have any constraints in it?
<marcoceppi> we need 1.17.1
<marcoceppi> it's the statewatcher bug
<frankban> marcoceppi, gary_poster: line 158 also means you should see an error notification in the GUI
<marcoceppi> in 1.17.1 for jujuclinet/deployer
<gary_poster> Interesting in a MY GOSH COULD WE PLEASE HAVE SOME DECENT INFO FROM THE DEPLOYER TO LOG ;-)
<frankban> :-)
<rick_h_> I thought we patched things to not send an "EnvError" like that? Didn't bac add that?
<frankban> marcoceppi: yes I remember Kapil mentioned the watcher unexpectedly closed bug
<frankban> rick_h_: 'Error': u'state watcher was stopped' looks like a good message to me
<gary_poster> yeah that's the improved version, IIRC, rick_h_.  we used to send a stringified json thing as the message,  Now we send 'state watcher was stopped'
<rick_h_> frankban: oh, duh. that's the 'type'
 * rick_h_ hits more coffee
<gary_poster> :-)
<rick_h_> yay for logs go frankban 
<gary_poster> :-)
<frankban> :-)
<rick_h_> jujugui have to run up to the kids day care for a few min. afk. 
<gary_poster> ack
<hazmat> frankban, thats resolved
<hazmat> frankban, in trunk
<frankban> marcoceppi: ^^^
<frankban> thanks hazmat 
<hazmat> frankban, the py jujuclient isn't async, so if it was used for a little while, it wouldnt be able to process pings, rogpeppe2 yanked ping timeouts on the server.
<marcoceppi> frankban: how do I get trunk?
<hazmat> marcoceppi, go get launchpad.net/juju-core ?
<hazmat> -u -v
<marcoceppi> hazmat: oh, I know that, I thought he meant trunk of juju-gui
<marcoceppi> we're started compiling
<frankban> cool
<hazmat> frankban, speaking of interesting info to log, any progress on feedback/validation errors branch?
<gary_poster> marcoceppi: I don't *think* you want trunk of gui?
<hazmat> frankban, i'd like to push a new deployer release before friday, if not it can make the release after.
<hazmat> lots of goodies got merged last week
<frankban> hazmat: working on the server side putcharm API now, improving feedback is likely to be my next card
<marcoceppi> I was confusing what frankban was suggesting
<hazmat> frankban, fwiw, i pushed a new jujuclient with those apis
<frankban> hazmat: looking
<frankban> hazmat: ic, add_local_charm right? seems great
<hazmat> yup, that's the one
<hazmat> frankban, the size param is required btw
<hazmat> for file objects
<hazmat> there's some broken code in stdlib httplib that looks like it would handle file objects, but doesn't correctly
<frankban> hazmat: in our case, that request is generated by the GUI (javascript+xhr) and the server goal is to just act as a proxy to the real endpoint
<hazmat> understood
<jcastro> hey frankban and hazmat
<jcastro> can we talk about that bug where the deployer bails if a unit doesn't come up properly?
<hazmat> jcastro, sure... its actually intended behavior.. but i can see where that wouldn't be ideal for the gui.
<jcastro> really? 
 * jcastro is confused
<jcastro> so if a unit doesn't come up it's supposed to error out?
<hazmat> jcastro, well deployer's original use case was automated testing and hacking on ostack charms, if it didn't come up right, it was a fail... there's options on deployer to try and auto-resolve errors as well, per some lscape use cases around ha stack
<jcastro> oh I see!
<hazmat> jcastro, yeah
<hazmat> jcastro, but for the gui, that doesn't feel like its really appropriate
<jcastro> the bundle use case for bundler would be something like "19 out of 22 instances have come up" and the relationships and bundle would be deployed, but you'd have to manually resolve the issues
<hazmat> frankban, gary_poster, ^ any comment?
<hazmat> jcastro, agreed
<jcastro> I think it's more for "bundles" than just the gui
<frankban> hazmat, jcastro : I'd suggest  a deployer option to switch behavior, I don't remember how difficult it is
<gary_poster> +1
<hazmat> frankban, should be straightforward.. its a short-circuit to wait_for_units
<gary_poster> I wonder if default should be behavior jcastro describes
<jcastro> if it's deploying a bundle do it the resilient way, and maybe if not doing a bundle it reverts to "test mode"
<hazmat> gary_poster, for gui, i think so. for cli.. a switch
<hazmat> non default switch that is
<hazmat> jcastro, there isn't a deployer distinction to bundle vs not bundle
<jcastro> yeah as long as the default is what the users want, which IMO would be "get the thing up and running"
<gary_poster> hazmat: for cli, simply because of history
<frankban> hazmat: that would be great, considering that the importer is instantiated with the defaults by the gui server
<jcastro> for everyone else --bundle-test-bail-out or whatever
<hazmat> jcastro, would you mind filing a bug?
<jcastro> yeah there's a bug, I can't find it right now, digging
<gary_poster> hazmat: I think the "continue on error" case would be preferred for users, where "stop on error" should be opt in for devs
<gary_poster> if we are moving the tool to be more user centric
<gary_poster> but if the vision is for deployer to continue to be dev focused then I agree
<hazmat> gary_poster, well.. not entirely.. ops wants stop on error to
<hazmat> and qa as well
<hazmat> jcastro, not seeing the bug flipping through the open list
<jcastro> Well if I am deploying an HA bundle and some units don't come up but the service gets up, then I am up and running and just manually fire up more nodes
<jcastro> instead of being dead stop 
<gary_poster> hazmat: huh, ok
<gary_poster> yeah, I am seeing jcastro's position, but <shrug>
<jcastro> hazmat, so for example, the mongodb charm has a race (which yes, should be fixed)
<benji> rick_h_: I'm having a problem with a test, do you see any reason this assertion would fail? http://paste.ubuntu.com/6832325/
<jcastro> but the entire bundle is undeployable because out of 13 upcoming units, one will bail
<jcastro> https://bugs.launchpad.net/charms/+source/juju-gui/+bug/1252301
<_mup_> Bug #1252301: guiserver reports second bundle as failing after the first fails <juju-gui (Juju Charms Collection):Triaged> <https://launchpad.net/bugs/1252301>
<jcastro> here's the bug
<benji> rick_h_: the error is: AssertionError: expected null to equal 'sidebar'
<rick_h_> benji: looking
<jcastro> hazmat, my other POV is that instances are disposable entities that may or may not come up depending on the provider so deployer should plan for failure
<jcastro> for example if a unit goes away juju won't die, it'll just fire up another one and relate it
<gary_poster> frankban: mm, I added deployer as "also affects" to jorge's bug.  was that right?
<jcastro> I did that yesterday but I might not have gui bug powers
<frankban> gary_poster: it seems right to me. hazmat: IIUC that bug describes a side effect of what we are discussing: IIRC if a pre-existing unit is in an error state, wait_for_unit raises an error
<rick_h_> benji: would have to find the code that app uses on fire
<benji> rick_h_: will you unpack that a bit?  I don't quite understand.
<rick_h_> benji: you're firing an even on app, which must be caught and then triggers a change event on subapp? the viewNavigate is getting no viewmode in the change object
<rick_h_> benji: hangout?
<benji> rick_h_: sure; how about the daily hangout?
<rick_h_> benji: rgr
<jcastro> frankban, quickstart -i is a thing of beauty by the way
<frankban> jcastro: great! :-)
<hatch> I wonder why my +1's on G+ never show up on the posts
<rick_h_> hatch: it was an unworthy +1, Google has said so
<hatch> haha, it's happened quite a bit in the past week or so, I get the notification that people have +1'd a post but then the post doesn't show it
<rick_h_> 'eventually consistant'
<hatch> tooth paste, coffee, oranges.....flavours that do not mix well
<hazmat> frankban, yeah. the wait_for_units should ideally be self-contained at least to services being deployed.
<jcastro> hazmat, is that bug sufficient or do you need anything else from me?
<hazmat> jcastro, its not quite the same, but i'll add a note
<bac> jcsackett: do you plan a deploy of your charmworld change to production?
<jcsackett> bac: we're actually only interested in triggering tests for charms from staging right now, b/c charm testing has been completely sorted out and we can tweak things on staging easily.
<bac> jcsackett: perfect
<jcsackett> bac: as long as charm_testing_* variables aren't set in the charm config, testing shouldn't be triggered on production at all.
<jcsackett> once everything is locked down we'll turn it off on staging and file an RT to have those config vals set on prod.
<Makyo> jujugui call in 10
<benji> sigh; I really wanted this done by the call
<rick_h_> benji: no luck?
<benji> rick_h_: well, I did something that is not entirely evil, but I'd rather it have been simpler
<benji> now I just need a couple more tests and it should be reviewable
<rick_h_> hatch: the hard part will be all the manual work to turn viewlets into views :P
<rick_h_> curses, he ran away on me!
<hatch> "did you turn it off and back on again" 
<hatch> looks like osx has the same issue resolution that windows xp has
 * gary_poster has to switch computers
<Makyo> Oops, jujugui call in 1
<rick_h_> bac: stand up please
<rick_h_> hatch: the hard part will be all the manual work to turn viewlets into views :P
<frankban> jujugui: I am getting "You're not allowed to join this video call."
<hatch> rick_h_ oh no that should be pretty mechanical
<hatch> with some changes to the viewlet manager it can even be done in stages
<hatch> rick_h_ lemme find that plugin example
<Makyo> gary_poster, want that I should be on that call?
<Makyo> (I see the invite, just missed the discussion around it)
<rick_h_> hatch: yea, I mean I found people asking a bunch of questions and the usualy answer is the global before/after calls but nothning that could hoook/load into it
<hatch> rick_h_ I think I was going to monkey patch the methods which call the before/after calls to allow middleware to be injected
<hatch> I'm just looking at istanbul
<hatch> it integrates with mocha, just want to see how they do it
<rick_h_> hatch: rgr, ok. Yea that's my plan as well
<rick_h_> and I'm looking at beforeEach/afterEach actually
<hatch> why is everything they do documented so poorly lol
<rick_h_> hatch: yea, I didn't come away from this search liking mocha any more than before tbh
<rick_h_> you got my hopes up with a plugin architecture
<hatch> there is a setup() method, but no documentation on what params it actually takes :/
<hatch> hmm mocha actually works pretty interesting under the hood
<hatch> rick_h_ ok here is probably the best place to inject https://github.com/visionmedia/mocha/blob/master/lib/suite.js
<hatch> that modifies the actual test suite
<hatch> it's where it defines the before/after etc methods
<rick_h_> hatch: rgr
<hatch> frankban have some time in a couple minutes to give me a run through of quickstart?
<bac> gary_poster, frankban: how does that discussion on the auth call affect the current quickstart effort?  are the .jenv files not going to be named based on the local env name?
<gary_poster> bac, they will continue to be named based on the local env name AIUI
<bac> gary_poster: ok, so quickstart has that info but the charm does not.  that's the difficulty, correct?
<gary_poster> bac, right
<bac> gary_poster: i feared they were tending to making the jenv files opaquely named
<gary_poster> not aiui
<bac> gotcha
<frankban> hatch: sure, ready when you want
<hatch> frankban https://plus.google.com/hangouts/_/76cpiisbms6bilnp0eh9n94nuc?hl=en
<benji> rick_h_: I'm going to take lunch now; would you be able to pair with me some time after lunch on these tests?  There are no tests for some of the code I am changing and building up enough state to get a simple test to run is killing me.
<hatch> benji I wouldn't do what you're trying to do
<hatch> I would implement a unit test for either side then a selenium test for the integration test
<hatch> (assuming you're doing the minimize-charm-browser-when-inspector-charm-details-opens work)
<benji> hatch: that's what I'm trying to do.  I want to call a function and test that it fires an event.
<benji> the function in question is not called in the test suite
<hatch> hmm ok, well when you get back from lunch if rick_h_  isn't available I can also give you a hand with it
<benji> thanks
<hatch> I may end up liking python after doing this quickstart work
<hatch> shhh don't tell rick_h_ 
<benji> heh
<rick_h_> benji: sure thing
<rick_h_> hatch: :P
<hatch> haha
<frankban> guihelp I need two reviews + QA for https://codereview.appspot.com/57820043 . Anyone available? Thank you!
<frankban> it's the server side putcharm
<Makyo> New modem \o/
<hazmat> frankban, out of curiosity what do you like tornado?
<hazmat> er.. s/what/how
<hatch> it's good, a little windy and tough to control, but it clears a nice path
<frankban> hazmat: yes I do, it worked pretty well for the charm needs
<Makyo> hatch, listen: no
<hatch> Makyo lol
<hatch> OH CMON that was funny
<frankban> need to go now, see you!
<hazmat> frankban, more modern/better than twisted? more explicit than gevent?
<gary_poster> frankban: will review/get reviews for that.  ttyl
<benji> rick_h_ and hatch: you can play paper-rock-scissors now to decide who helps me
<hatch> haha
<hatch> benji sure I'll help
<rick_h_> benji: I got it :)
<hatch> got the code pushed up to gh?
<rick_h_> :P
<hatch> lol
<rick_h_> benji: standup hangout?
<benji> rick_h_: sure
<hatch> ok rick_h_ go ahead I'll cede....this time....
<rick_h_> hatch: you can come along but beware :P
<rick_h_> I'll show you how the browser is setup to already deal with extra views while we're at it hah!
<hatch> well maybe I'll listen in
<hatch> haha, I'm actually thinking of a slight refactor to the side bar 
<hatch> so we would have two different approaches
<rick_h_> think all you want, we'll meet and do battle
<rick_h_> code wars!
<benji> http://i1.kym-cdn.com/photos/images/newsfeed/000/296/322/c6f.gif
<rick_h_> benji: hatch https://plus.google.com/hangouts/_/calendar/Z2FyeS5wb3N0ZXJAY2Fub25pY2FsLmNvbQ.j0rk5d371ph8331ijtf48t2uj0?authuser=1
<hatch> benji lol
<benji> "You're not allowed to join this video call."
<rick_h_> benji: :(
<hatch> try again
<rick_h_> ok, I'll create one
<hatch> it's been doing that
<rick_h_> or hatch got in
<rick_h_> benji: ah, might be a work vs non-work account thing
<rick_h_> I can create one for non-work accounts
<rick_h_> hatch: benji https://plus.google.com/hangouts/_/76cpjjso2tiuhku81mmnp9md8g?hl=en
<hatch> does anyone have any favourite python learning resources? 
<hatch> I'm mostly interested in the ecosystem
<rick_h_> hatch: hmm, I mean I went through a ton of books and such when learning python to get out of php. I don't know I've got a single/couple favs. 
<rick_h_> hatch: but more than happy to help answer any ecosystem questions/etc
<hatch> well there is stuff like pip, virtual envs, __whatevers__
<hatch> so less about the syntax of the language and more about how applications are actually structured
<gary_poster> hey arosales, we'd like to get quickstart in main in trusty.  Is that possible?  Who would you suggest we talk to?
<rick_h_> hatch: yea, there's still some personal preference stuff in there that builds up with experience. There's a couple of books on 'good practices'
<arosales> gary_poster, I would start with https://wiki.ubuntu.com/MainInclusionProcess
<arosales> and get the bug filled out with the required points listed in the wiki
<gary_poster> ok thank you arosales.
<arosales> gary_poster, after that it is makeing sure the bug has ubuntu core devs subscribed and following up with the core devs if the bug isn't be reviwed in time for feature freeze.
<gary_poster> arosales: do we have a juju and/or ecosystems contact for that in particular?
<arosales> gary_poster, not specifically. Best bet is to subscribe ubunt-mir team to the bug so it shows up in the archive admins queue
<gary_poster> ok
<hatch> so is there a python api docs somewhere?
<hatch> tried here http://docs.python.org/2/library/
<hatch> but it doesn't have the 'call' method for some reason
<hatch> oh nm
<hatch> I was using the docs wrong
<hatch> heh
<hatch> carrryon
<hatch> brain....wants....to.....type.......'var'
<rick_h_> hatch: lol
<rick_h_> yea, and the ; and the function vs def
<hatch> haha it's hard!
<hatch> I wish you could indent one more time on def's
<hatch> the fn name is hard to scan for
<hatch> could maybe be my syntax highlighting though
<hatch> rick_h_ which syntax is preferred in the python world? https://gist.github.com/hatched/8675743
<hatch> or does it really matter
<rick_h_> hatch: replied
<rick_h_> bah, lost my formatting
<rick_h_> hatch: there we go
<hatch> you guys are really functional eh? :)
<rick_h_> testable :)
<hatch> cool I like it better your way
<rick_h_> so then if bootstrap_requires_sudo: cmd.insert(0, 'sudo')
<hatch> thanks
<rick_h_> np
<benji> rick_h_: how do you get github to not eat indentation?
<rick_h_> benji: markdown, add 4 spaces first
<benji> ah!
<rick_h_> so it's a code block
<hatch> I think you can also do ``` ```
<hatch> maybe that depends on the md type though
 * hatch dislikes that there are dif implementations of md
<benji> rick_h_ (and hatch): https://gist.github.com/hatched/8675743/#comment-995086
<rick_h_> benji: +1
<rick_h_> benji: wasn't sure on line length in there
<hatch> python and js appear to have very similar operations
<rick_h_> I'd rather have the if block vs dealing with newline in there
<rick_h_> OMG I think it finally works!
 * rick_h_ does a happy dance
<hatch> ?
<hatch> lol
<rick_h_> hatch: https://github.com/juju/juju-gui/pull/89
<hatch> kewl lookin
<rick_h_> and mocha can go choke on a carrot atm 
<rick_h_> pita to get this hacked into play the way they bootstrap everything for you on load so you can't intercept crap
<hatch> ohh lol I Was reviewing it
<hatch> till I saw the huge commented out section
<hatch> haha /me fail
<rick_h_> oh no man, it's WIP. I've got to find every instance of makeContainer and pass a this in as the first argument
<rick_h_> and remove all the cleanup instances
<rick_h_> and figure out how to clean it up with more comments/wtfs
<hatch> you should probably land them as separate branches
<hatch> or at least separate commits
<rick_h_> definitely commits, but hard to do as different branches
<rick_h_> if I don't remove the cleanup the container won't exist. If I don't update the context argument then the calls will all fail with wrong args
<hatch> right
<hatch> hmm
<hatch> rick_h_ why the addCleanup method? can't they just push to jujuTestCleanup?
<rick_h_> hatch: could, but I like the clean api better. 
<rick_h_> hatch: "call this function with a cleanup" and you dont' have to know jujuTestCleanup/etc
<rick_h_> just addCleanup
<bac> frankban: (hoping you see this tomorrow morning): please review the admin-secret change  https://codereview.appspot.com/57900043
<hatch> maybe _jujuTestCleanup = {}
<hatch> er
<rick_h_> meh, I guess it's nitpicking but I liked it better
<hatch> []
<hatch> whichever implementers choice 
<hatch> defining the function is a perf hit is the only negative
<rick_h_> originall it was _jujuTestCleanup as a hidden var and then realized wtf...no one's going to use _juju...
<hatch> haha no the idea behind using _jujuTestCleanup is to signify to other devs that you shouldn't interact with it directly
<rick_h_> :P it's been a long day
<hatch> lol
<hatch> also you don't need bind() as you have it in your WIP (although I suspect that's not staying anyways)
<hatch> bind() returns a function that's bound to the context 
<rick_h_> yea, I was hitting some issues there. The scope changes around a bit
<rick_h_> right
<hatch> yeah with call() you have it right
<gary_poster> bac, fwiw I think jenv files started in 1.16 (per your MP)
<hatch> +1  
<hatch> I like it
<rick_h_> I was running into the various bits are in a context of mocha.suite, Hook, etc
<rick_h_> getting it straight is a pita
<hatch> yeah, this is pretty much exactly how I was going to do it so yay! lol
<rick_h_> lol, ok well will clean it up and get it going up for review in the morning if I can get my sed/awk fu on to mass update the makeContainer calls
<rick_h_> though I wonder what will happen to makeContainer calls not in the before hook but the test itself :/
<hatch> it should add to the cleanup and clean it up in the after
<rick_h_> hatch: right, but will the context of 'this' have access 
<rick_h_> hatch: because the this in there is the Hook object, not the test fun
<hatch> ohh...hmm
<rick_h_> hatch: I'll get it worked out. anyway, small happpy dance
<hatch> yeah - maybe we can assign a global context object that the utils methods can use
<gary_poster> Makyo or hatch, either of you up for being the second reviewer of frankban's https://codereview.appspot.com/57820043 ?  I'm trying to do qa and review
<hatch> sure
<Makyo> ty hatch
<Makyo> Rushing on tests
<gary_poster> thank you
<hatch> gary_poster can you ping me after you're done yours so I can learn from the comments (if any)
<gary_poster> sure hatch.right now I'm flailing at trying to update juju core :-P
<hatch> haha, I'm failing at getting mine to stop using the custom built one lol
<gary_poster> :-)
<hatch> I borked my path, there needs to be a $PATH api
<hatch> so you could splice into it and stuff haha
<hatch> array methods on $PATH
<benji> rick_h_: here's my WIP if you have a minute to look and comment or formulate thoughts for a discussion tomarrow about how to split the events up plus anything else you see, I would appreciate it
<rick_h_> benji: rgr
<rick_h_> benji: link? or issue pushing?
<hatch> rick_h_ you should just KNOW
<hatch> lol
<benji> rick_h_: https://github.com/benji-york/juju-gui/compare/juju:develop...benji-york:auto-open-close?expand=1
<hatch> :) legit checkpoint commits
<hatch> I dont' think I've ever seen someone write 'checkpoint' lol
<rick_h_> benji: k, I'm a little confused will look at it. 
<hatch> rick_h_ it must be that app is a bubble target (somehow) of the topo
<hatch> might have to grep for that one
<gary_poster> hatch, that local charm DnD is looking pretty cool :-)
 * gary_poster excited to see it hooked up
<gary_poster> hatch, I completed review of https://codereview.appspot.com/57820043/ .  Not the most scintillating review ever :-)
<hatch> yeah it's pretty nice, and it looks like core will be fixing the folder in a zip issue too
<hatch> haha ok thanks
<hatch> I'm guessing @gen.coroutine is part of a lib?
<hatch> I didn't think python had real coroutines 
<rick_h_> hatch: that's part of tornado I think
<rick_h_> the @gen stuff
<rick_h_> hatch: http://www.tornadoweb.org/en/branch2.4/gen.html
<hatch> ahhh
<hatch> async is hard :P
<rick_h_> darn it, my pebble isn't in the first orders :(
<hatch> the steeeel one?
<huwshimi> Morning
<hatch> hey huwshimi 
<hatch> huwshimi did you want us to prioritize upgrading the node dep? (if possible) are you able to do it?
<huwshimi> hatch: I can give it a go, but I have no idea how to do it.
<hatch> huwshimi do you know how to deploy a local charm and all that business? 
<rick_h_> hatch: yea, ordered day of annoucement but guess I'm still in a second batch 
<hatch> rick_h_ that's a good thing - everyone else gets the first broken run
<hatch> :)
<huwshimi> hatch: I've done it before (to LXC).
<hatch> huwshimi yeah our issues were when it was uploaded to ec2
<hatch> so you pull it down, update the python deploy files, update the package.json, shrinkwrap, then push it up somewhere then deploy from that repo
<huwshimi> hatch: Have you done it before? How long a task might it be?
<hatch> huwshimi for you, probably a day, just because of learning the process, testing takes a while to spin up ec2 machines etc
<huwshimi> hatch: Sounds horrible
<hatch> lol
<huwshimi> hatch: Sounds like the worst kind of monkey testing.
<hatch> well it's taken me a day to do a 15 line diff in a python script because of learning haha
<hatch> so it takes a while to get up to speed sometimes 
<rick_h_> https://github.com/blog/1767-redesigned-conversations 
<hatch> still can't reply to a comment :/
 * gary_poster runs
<gary_poster> bye all
<rick_h_> hatch: does the Environment really have no destructor?
<rick_h_> hatch: or am I blind?
<hatch> rick_h_ the environment view?
<rick_h_> hatch: rgr
<hatch> nope it doesn't
<hatch> not sure why, it never has 
<hatch> rick_h_ it's not really an issue because it's never destroyed haha
<hatch> but we should have one for testing
<rick_h_> hatch: heh, except for tests
<rick_h_> hatch: ok, thanks for sanity checking
<hatch> rick_h_ so I'm writing tests and I need to stub out the 'call' method in utils.py 
<hatch> _, version, _ = call('juju version') 
<hatch> here is the 'real' code
<rick_h_> hatch: k, that's what the Mock library is for and you should see some @patch stuff in there
<rick_h_> or "with patch"
<hatch> ok looking
<hatch> ok got it
<hatch> https://pypi.python.org/pypi/mock
<hatch> that one?
<rick_h_> yep
<hatch> ""Mock is very easy to use"" HAH maybe if you know Python
<hatch> :P
<rick_h_> yea, kind of the basis of mocking like that. You have to learn a bit on how it works
<hatch> I'll get er figured
<rick_h_> k, I'll be in/out if you need a hand. Dinner making time
<hatch> yeah it's close to EOD time for me too and I need to go shovel a parking spot because the graders came by
<hatch> and graded a nice 3ft pile of snow into the street spot :)
<hatch> this might be a working tonight thing
<rick_h_> wheeee
<rick_h_> yea, same here trying to get this event chain right
<rick_h_> was so happy leaving the inspector be lately
<hatch> haha. I want to convert the viewlets to views and then modify the viewlet manager to work with views
<hatch> there is just not enough time  in the day
<hatch> or night
<rick_h_> yea, I know. 
<rick_h_> there's a good path, just needs some stabbing to find the tender bits
<hatch> haha look at this pic http://jalopnik.com/there-have-been-274-car-crashes-in-austin-today-1510853622
<hatch> how the heck does that even happen!
<hatch> ice? snow? 100MPH should be safe right?
<Makyo> -Only- 29% of the tests fail now!  Yay!
<hatch> lol what are you working on?
<huwshimi> hatch: I think he's working on breaking everything
<hatch> haha
<huwshimi> hatch: Only 71% to go.
<Makyo> Aaaand down from 264 to 9 failures in one swell foop.
<Makyo> My develop was a little stale :T
<Makyo> The downside being I've not figured out how to rebase out merge commits yet.
<hatch> Makyo yeah I'm not entirely sure about those either
<Makyo> Maybe cherrypick, dunno.  Will burn that bridge when I get to it.
<Makyo> Aaaand down to 6 (with a new bug, d'oh)
<Makyo> This would be a one-line addition to rick_h_'s plugin, I think, but I haven't fully investigated.  Will bring it up tomorrow.
#juju-gui 2014-01-29
<rick_h_> dammit, the inspector isn't a real view and doesn't have YUI events available to it. It can't this.fire or inspector.on()
<Makyo> I hate this test :T AssertionError: expected 300 to equal 298.552734375
<rick_h_> hah, JS match...you're drunk 
<rick_h_> math that is
<hatch> evening
<rick_h_> party
<hatch> hows it going?
<rick_h_> bed time, branch is pushed for the night
<rick_h_> benji: pushed another update to that branch per hatch's comments. 
<benji> rick_h_: cool, I'll take a look
<benji> rick_h_: do you have any tips on diffing your branch and mine?  git diff auto-open-close..qa-auto-open-rick (with two or three dots) shows lots of things I wouldn't expect
<rick_h_> benji: you should be able to diff hashes in line. Since I started with your branch
<rick_h_> benji: git checkout qa-auto-open-rick
<rick_h_> git log
<rick_h_> find the merge point
<rick_h_> and then diff $hash..HEAD?
<benji> rick_h_: I'll give that a try.  I was hoping for something more direct.
<rick_h_> benji: https://github.com/mitechie/juju-gui/compare/benji-york:auto-open-close...mitechie:auto-open-close
<rick_h_> benji: hmm, crap we have different develop bases which is why things are there you don't expect
<rick_h_> benji: so the key would be to get the common base point by updating develop and getting that into your branch
<hatch> rick_h_ so is PR 91 still a WIP? I was looking at it last night and assumed so...
<rick_h_> hatch: yea, it's got two failing tests still
<rick_h_> hatch: but it was something to see if I could get the origin idea working based on benji's branch
<rick_h_> original*
<hatch> cool lemme know when she's ready 
<rick_h_> hatch: will do, thanks for the pre-review. It made me clean up a little bit of what I should have
<benji> rick_h_: I'm looking at the two test failures
<rick_h_> benji: it should just be another round of bootstraping all the stuff required to create an Inspector instance. None of the current tests run createServiceInspector or whatever that func is
<rick_h_> benji: so that has to be called before testing the events
<benji> rick_h_: ok
<rick_h_> benji: so that you have a this.inspector.viewletManager 
 * rick_h_ thinks that's what it was thinking back to when he gave up last night
<gary_poster> ubuntu mouse stopping work
<gary_poster> that is, ubuntu mouse handling broke again and I had to log out/in
<gary_poster> hey frankban, I spoke with jamespage about Ubuntu packaging and he requested that we put quickstart on PyPI so he has official releases to work with
<gary_poster> is that something you could whip up quickly?
<frankban> gary_poster: sounds good. I think so, what Pypi account am I supposed to use?
<gary_poster> frankban: I suggest yours, and then add everyone else on GUI with a PyPI acct as admin
<rick_h_> frankban: you can use yours but I think you can grant access to other pypi users
<frankban> gary_poster, rick_h_ cool
<rick_h_> frankban: mitechie is my username here
<bac> frankban: i see that quickstart starts an ssh-agent whether one is running or not.  couldn't we check to see if one is alive and happy before clobbering the existing one?
<gary_poster> frankban on PyPI I am "gary" and benji is "benji".  I don't see bac or Makyo on a quick glance.
<gary_poster> actually maybe you don't need to add me :-P
<frankban> bac: Makyo knows the details for SSH keys handling
<bac> creating a new ssh-agent every run means i have to re-enter my passphase.
<frankban> gary_poster: I'll add you! :-/
<gary_poster> :-) k
<bac> frankban: add bac please
<hatch> the best part about OSX is coming across bugs, googling them, then seeing that people have had the same issue for 4 years
<frankban> gary_poster: could you please take a quick look at https://codereview.appspot.com/51790045 ? (quickstart update for PyPI)
<gary_poster> on it
<frankban> thanks
<gary_poster> frankban: LGTM'd :-)
<frankban> gary_poster: thank you
<gary_poster> np!
<frankban> jujugui https://pypi.python.org/pypi/juju-quickstart
<frankban> bac: no "bac" user found on PyPI
<frankban> hatch, Makyo: what's your PyPI user name?
<gary_poster> awesome thanks frankban
<hatch> wtpi is pypi
<hatch> :P
<frankban> hatch: please go to https://pypi.python.org/pypi, register, give me your username and then enjoy the cheese
<hatch> lol ok
<hatch> sweet I got 'hatch' as a username
<hatch> that never happens
<gary_poster> jujugui call in10
<gary_poster> jujgui call in 2
<gary_poster> jujugui
<gary_poster> Makyo: pingy
<Makyo> Sorry, SSO.
<bac> frankban: try bradcrittenden
<bac> for pypi
<frankban> bac: it worked
<bac> \o/
<hatch> frankban I'll ping you after my call :)
<frankban> hatch: ok
<rick_h_> gary_poster: can you invite me or link me to the meeting please? 
<hatch> gary_poster do you know PostreSQL? Linkedin wants to know...lol
<gary_poster> hatch: but of course! ;-)
<hatch> annnnd signing out to log back into linked in in another year
<frankban> hazmat: working on the feedback branch for the deployer, I should be able to propose it tomorrow morning
<hazmat> frankban, cool, thanks
<hazmat> hatch, pypi == npm
<hazmat> registry
<frankban> mp
<hatch> not sure which website is worse pypi or npm though
<hazmat> not to be confused with pypy
<hazmat> or with pie pi 
<hazmat> the later of which is yummy and mind expanding :-) http://upload.wikimedia.org/wikipedia/commons/d/d4/Pi_pie2.jpg
<Makyo> <Obligatory Tau video> http://www.youtube.com/watch?v=jG7vhMMXagQ
<hatch> frankban still around?
<hatch> I have no idea when your EOD is :)
<hatch> rick_h_ are you available to guide me through this testing business?
<hatch> python testing that is
<rick_h_> hatch: on a call but can in a bit
<hatch> ok cool np, ping when ready
<rick_h_> might trade some help
<hatch> right now my help is selling at a 2:1 help unit ratio
<hatch> market conditions...
<hatch> :P
<frankban> hatch: I am here, EOD in 40 mins
<hatch> oh ok cool, do you have time to guide me through the testing now?
<frankban> hatch: sure
<hatch> https://plus.google.com/hangouts/_/7ecpjd60csb16idpl8krnvb4es?authuser=1&hl=en
<hatch> ^ frankban 
<frankban> hatch: joining
<bac> frankban: i get the following while doing QA on my branch.  https://pastebin.canonical.com/103823/
<frankban> bac: one minute, on call
<bac> frankban: quickstart terminates with juju-quickstart: error: bad API server response: state watcher was stopped
<bac> frankban: ok.  just curious if it looked familiar
<rick_h_> bac: yes, that's supposed to be fixed in 0.17.1
<frankban> yeah...
<bac> jujugui: per frankban's message, anyone know if juju 0.17.1 is packaged anywhere or do i need to build by hand?
<hatch> bac it's released already
<gary_poster> yup
<bac> i don't see it on trusty
<hatch> hmm the email said it was available on trusty
<rick_h_> bac: it's released today
<hatch> at least I thought it did
<hatch> juju-core 1.17.1 is available for trusty and backported to earlier
<hatch> series in the following PPA:
<hatch>   https://launchpad.net/~juju/+archive/devel
<rick_h_> jujugui pita review, read the notes. Had to skip the notifier tests atm. It needs rework and adding as a new card. https://github.com/juju/juju-gui/pull/89
<hatch> i'll take one
<rick_h_> hatch: thanks
<gary_poster> how many do you need rick_h_
<rick_h_> gary_poster: 2 please. thought it's mostly mechanical so fine with just one
<rick_h_> gary_poster: the main thing is the heads up on the notifier tests. 
<gary_poster> rick_h_: ok, I'll leave it alone unless requested then :-)
<bac> thanks hatch.  that ppa got disabled on upgrade to trusty and i failed to re-enable it
<hatch> ahh
<hatch> rick_h_ 44 files changed? lol
<rick_h_> hatch: well, makeContainer is popular :)
<bac> jujugui: i need to be afk for the rest of the day.  ttyl.
<rick_h_> bac: c-ya
<rick_h_> yay for the end of conference calls
<hatch> rick_h_ you're gona hate me...
<rick_h_> hatch: then stop
<hatch> lol
<rick_h_> hatch: I'm already very angry after chasing down the stupid notifier test bugs
<rick_h_> :OP
<rick_h_> :P
<hatch> rick_h_ what's with the onboarding.js changes
<rick_h_> hatch: it didn't clean up after itself
<rick_h_> now it does
<rick_h_> lots of tests are like this unfortunately. Creating objects that never die
<hatch> well when it's container gets destroyed it would remove it's children
<hatch> which is all you're doing there....no?
<rick_h_> no, it's got events bound and the tests never call destory on the object
 * rick_h_ pulls it back up
<hatch> ohh nm empty removes the events too
<rick_h_> hatch: oh sorry, so this is that the object doesn't have a destructor itself. see the test_onboarding file that goes with it
<rick_h_> matching changes
 * rick_h_ kicks self for missing this during review/helping getting onboarding landed. 
<rick_h_> hatch: so what am I going to hate you for?
<hatch> I am trying to figure out a way to avoid having to pass 'this' into makeContainer every time
<rick_h_> hatch: good luck, it's stupid mocha scopes
<rick_h_> hatch: everything has to be in the hook context to be visible unless I stick it on window. which I almost did...but that feels evil and wrong
<hatch> that's irritating
<rick_h_> and there's no way to globally rebind the makeContainer function from the juju test utils scope since each test has it's own Hook context
<hatch> yeah I just noticed that
<hatch> how fail is that :/
<rick_h_> you'd have to loop throgh all the Suites, and down in there go through each Hook context of each, and they can nest and ...
<rick_h_> I told you, I'm very cranky with Mocha, etc atm. This was a much bigger pita than it should be, but oh well. 
<rick_h_> hatch: but trust me, I tried to make it not suck, if you find a better way I'll thank you for the insight and move alnog
<hatch> lol
<hatch> well their scoping is totally wako
<rick_h_> yes...yes it is
<hatch> it doesn't make any sense
<rick_h_> sure it does, it's how the damn things works. It laods all the files, sticks all the tests in their own Hook contexts, and basically loops them
<rick_h_> in a nested pita tree of SAuites
<rick_h_> Suites
<hatch> lol well ok it makes sense, it's just not very friendly 
<rick_h_> but it makes it darn hard to monkey patch things 
<rick_h_> or even trace/debug things
<rick_h_> anyway, going to walk away and nuke some lunch. let me know if you have any ideas on improving. I'm definitely for it, but in the end I think that the api of needing to pass this isn't bad. I even catch/report an error that is hopefully clear 
<rick_h_> hatch: the notifier stuff is noted in the pull request
<hatch> yeah I replied again, guessing it didn't send another email for that :)
<rick_h_> card added to fix it, but will be second card
<rick_h_> ah, well email checks every so often so might not have it yet
<hatch> rick_h_ what is the model of your laptop?
<rick_h_> hatch: x240
<rick_h_> rerr 230
<hatch> cool
<hatch> guy is just asking what people use for linux laptop hardware
<rick_h_> Makyo: heads up, test branch landed so watch out for conflicts
<Makyo> >:/
<rick_h_> benji: ^ 
<benji> thanks
<rick_h_> russian roulette, touched 44 files and was one of them yours?! bwuhahaha
<benji> rick_h_: I think I have the test setup right for those two failing tests, but... the event the tests fire doesn't exist anywhere else in the codebase
<benji> rick_h_: oh!  it's a typo
<rick_h_> benji: yay
<benji> "inpsector"
<rick_h_> doh
<rick_h_> I kept mixing up the case last night
<rick_h_> Takeover vs TakeOver
<benji> tab completion
<rick_h_> and such
<rick_h_> nice, jcastro giving quickstart some <3 http://discourse.ubuntu.com/t/mangling-config-files-by-hand-pshawwww/1438
<rick_h_> purdy screenshots
<jcastro> I _love_ the "has errors" bit
<jcastro> I totally didn't notice that the first time around
<rick_h_> jcastro: yea, hopefully we can get it into main/universe https://launchpad.net/bugs/1273865 and make for an awesome getting started experience
<rick_h_> I'd imagine it's gotta be cool for your on site classes
<jcastro> oh hey, does the server team know about that bug?
<rick_h_> jcastro: yea, we pinged james page on it and we're working on it
<jcastro> they're handling juju but I think we should make clear that juju without quickstart will be kind of lame
<jcastro> ok, nice!
<jcastro> rick_h_, I showed it off at a class first actually
<hatch> stupid power button
<hatch> jujugui why is minor < 17 false when minor is 16 in python? 
<hatch> does maths work in reverse in python? lol
<rick_h_> hatch: code? maybe the types are off
<rick_h_> is minor a string?
<gary_poster> hatch
<gary_poster> >>> "16" < 17
<gary_poster> False
<gary_poster> >>> 16 < 17
<gary_poster> True
<hatch> https://gist.github.com/hatched/8696341
<rick_h_> hatch: right, a version might be 16a
<rick_h_> so it's a string ootb
<hazmat> strings to ints
<gary_poster> one of imporvements in 3.3:
<gary_poster> >>> "16" < 17
<gary_poster> Traceback (most recent call last):
<gary_poster>   File "<stdin>", line 1, in <module>
<gary_poster> TypeError: unorderable types: str() < int()
<gary_poster> yay
<hatch> >>> "1" >= 1
<hatch> True
<hatch> I thought js was messed up lol
<rick_h_> >>> ord("1")
<rick_h_> 49
<rick_h_> 49 > 1 :)
<rick_h_> welcome to ascii or unicode as the python version you're using might be
<hatch> 2.7.3
<gary_poster> but yes, this is one of the warts that py 3 was made to fix
<rick_h_> whoa, chrome update looks so much nicer yay!
<hatch> ok so int(minor) should fix ?
<hatch> sorry I mean
<hatch> is using int() the 'proper' way
<hazmat> yes
<hatch> cool
<hatch> and people rag on JS for having oddities haha
<hazmat> error catching on conversion is also nice
<rick_h_> hatch: yea, toss a test for a version with a character in it and make sure it's caught and handled ok. 
<hatch> it should have thrown by this point so that won't be necessary 
<rick_h_> hatch: heh, the issue is JS magically casts it for you using its own rules and that leads to wat videos
<hatch> will do
<hatch> hey THIS would have been a wat video too!
<hatch> lol
<hatch> well how resilient will I need to make this method? Is Juju switching form semver any time soon? haha
<Makyo> gary_poster, retcon on the feature flag :( I forgot about the remove relation dialog modifications I made.
<Makyo> Would be >15min
<Makyo> We just have a pre-indicator now.
<gary_poster> Makyo: ack, good 'nuff
 * gary_poster has to go and work offline.  I will be on email.
<hatch> I think the python linter is more picky than the js one
<hatch> jujugui does anyone know if quickstart uses lbox to propose?
<bac> hatch: yes.  you can tell by the .lbox files
<benji> hatch: I believe it does.  If it has a .lbox file it almost certainly does
<hatch> thanks, guess this vm is missing lbox and the gophers ppa heh
<benji> may apt-get have mercy on your soul
<Makyo> Shoot.
<Makyo> This also affects bundle visualizations.
<hatch> umm this vm doesn't have a GUI
<hatch> lol
<hatch> how do I auth with launchpad
<Makyo> Uh, crap, I forgot.
<hatch> Makyo didn't you run into this issue some time?
<rick_h_> install links2 and update-alternatives?
<hatch> the lbox w/o a gui?
<hatch> rick_h_ that really the only way?
<bac> hatch: doesn't it spit out a LP url for lplib auth?  if so, you could visit it in another browser. no?
<hatch> bac it doesn't
<bac> hmm
<hatch> at least here it's not
<bac> hatch: you can always just do a LP MP
<bac> old skool
<hatch> that will skip reitveld though no?
<bac> yes
<hatch> yeah I think i'd much prefer someone to comment on my first mostly-solo python branch hah
<bac> hatch: still can do reviews on a launchpad merge proposal
<bac> in fact, we insist
<hatch> ohh I didn't know that
<hatch> in that case...
<bac> push your branch, go to it in the browser of your choice, select something that smells like "propose for merging"
<hatch> yup typing it out now
<hatch> jujugui lf quickstart review and qa https://code.launchpad.net/~hatch/juju-quickstart/no-more-sudo/+merge/203846 
<hatch> http://shop.oreilly.com/product/0636920028154.do wow 1600 pages for learn python book hah
<Makyo> Oh hush.
<Makyo> You're nearing 'evangelism', but you work for a company that lists python as a core technology :P
<Makyo> (Though juju in Node would certainly be interesting :D )
<hatch> haha
<hatch> everyone knows node is faster than python anyways 
 * hatch ducks and runs
<hatch> seriously though, 1600 pages is a lot for any book haha
<huwshimi> Morning
<hatch> hey huwshimi
<hatch> Makyo definitely like the emoticon in your PR
<hatch> are those fish?
<Makyo> Ahahaha!
<Makyo> They're pennants.
<Makyo> Our feature flags are now actual flags.
<Makyo> Boo, build failed.  Investigating.
<hatch> lol
<Makyo> DAMNIT.  I ran make prep >:/
<Makyo> one commit ago.
<hatch> hmm I am running juju 1.17.1 and it's requiring sudo for local
<huwshimi> hatch: This is the correct way to check if the viewport has changed right? Y.on('windowresize', function(e) {...
<hatch> just resize
<hatch> Y.on('resize', function(e) { ...
<hatch> huwshimi although there is a windowresize which normalizes the resize event across browsers
<hatch> event-resize I think
<huwshimi> hatch: Hmm.... neither seem to be firing
<hatch> try Y.config.doc.on('resize' ..
<hatch> or Y.config.win
<hatch> sec looking
<hatch> huwshimi you can probably just get away with Y.one('window').on('resize', ...
<huwshimi> hatch: config.doc and config.win don't exist
<hatch> Y.cfg? maybe
<hatch> crap now I gota go look
<hatch> yeah it's Y.config.doc 
<hatch> and Y.config.wion
<hatch> win*
<huwshimi> Y.one('window').on('resize' works
<hatch> so there really is nothing in Y.config.doc?
<hatch> in jujucharms.com there is
<hatch> but it's fine the Y.one('window') is ok, Y.one(Y.config.win) would be better though :)
<hatch> if it actually exists
<hatch> Y.config.win/doc are supposed to be referenced to the 'actual' cached doc and windowreference 
<huwshimi> Ah, I mis-read the error: Uncaught TypeError: Object #<HTMLDocument> has no method 'on'
<hatch> ohh ok
<hatch> so they changed that
<hatch> yeah Y.one('Y.config.win).on('resize', ...
<huwshimi> yeah
<hatch> it used to be a Y.Node, they must have changed that for perf
<huwshimi> Ah ok
<huwshimi> hatch: Strangely though that seems to fire twice on every resize.
<hatch> put a debugger before you attach your event, it's likely that you are attaching it twice
<hatch> resize also fires periodically as the user is resizing so you 'may' also be seeing that
<huwshimi> hatch: It looks like the attachment only happens once, but the event fires twice
<hatch> hmm
<hatch> and the event objects passed into the callbacks are the same?
<huwshimi> hatch: I wonder if we only want to show this message once in a session?
<huwshimi> hatch: zooming in the browser fires a viewport resize event so it'll pop up a lot of messages while you're zooming
<hatch> ok load in the event-resize module (add it to the requires) and then listen on windowresize
<hatch> that debounces the resize events
<huwshimi> hatch: What does that do?
<hatch> sorry debouncing means that every time something is fired it resets a time
<hatch> r
<hatch> once that timer runs out it fires the event
<huwshimi> hatch: Do you happen to know what that time is?
<huwshimi> Actually we might not want a timer here
<hatch> 100ms http://yuilibrary.com/yui/docs/api/files/event_js_resize-window.js.html#l27
<huwshimi> For example if you're zooming back in after a few minutes you probably don't want to see the message again
<hatch> ohh right, I don't actually know what you're working on :)
<huwshimi> :)
#juju-gui 2014-01-30
<marcoceppi> hey guys
<marcoceppi> quickstart, no --upload-tools flag?
<frankban> marcoceppi: no, we don't have that option
<marcoceppi> frankban: could you add it?
<marcoceppi> frankban: quickstart doesn't work on maas because maas needs --upload-tools
<frankban> marcoceppi: you can just run "juju bootstrap --upload-tools" and then quickstart will reuse the environment already bootstrapped. 
<marcoceppi> frankban: well, we were doing quickstart -i :)
<marcoceppi> which is so sexy
<frankban> marcoceppi: FWIW quickstart -i can be used to run an existing environment. anyway, is this a maas bug?
<marcoceppi> frankban: it's a juju-core/streams bug
<marcoceppi> frankban: well, we run juju init, then quickstart -i to edit the default maas stuff
<marcoceppi> makes the demo more impressive
<frankban> marcoceppi: understood, could you please file a bug on quickstart, describing this use case?
<marcoceppi> frankban: will do
<frankban> marcoceppi: thanks
<frankban> hazmat: morning, could you please review https://code.launchpad.net/~frankban/juju-deployer/improve-guiserver-feedback/+merge/203915 ?
<BradCrittenden> morning frankban.  i landed my quickstart branch yesterday even though i was getting intermittent errors on charm deploy like https://pastebin.canonical.com/103823/ even with juju 1.17.1.  the admin-secret was correctly being used to authenticate so i assumed it was unrelated to my branch.  just a heads up in case i assumed wrong.
<ahasenack> hi guys, is the juju-gui charm branch really this big?
<ahasenack> 135336kB   221kB/s - Fetching revisions:Inserting stream:Estimate 3772/3247                                                                                             
<ahasenack> bzr branch is still going
<ahasenack> it finally finished, short of 152Mb
<bac> ahasenack: development on juju-gui is now happening on github at https://github.com/juju/juju-gui
<bac> ahasenack: the Launchpad page for the project needs to be updated to reflect that.
<ahasenack> bac: what does that mean? lp:charms/precise/juju-gui is invalid?
<bac> ahasenack: my apologies.  no the *charm* is still on launchpad.  the code for the app is on github.
<bac> so lp:charms/precise/juju-gui is still correct
<ahasenack> and huge
<ahasenack> if I do juju deploy juju-gui it will fetch 150Mb?
<ahasenack> that's the amount "bzr branch lp:charms/precise/juju-gui" said it downloaded
<bac> ahasenack: the charm is big due to bundled dependencies but i'm surprised it is that big.
<ahasenack> bac: can you try, on a fresh directory outside any bzr local repo? 
<bac> ahasenack: if you use juju-quickstart to deploy the charm will not be downloaded to your local machine before deploying (unless you're using a local environment).
<ahasenack> I'm not using juju quickstart
<ahasenack> after branch,
<ahasenack> $ du -hs juju-gui/
<ahasenack> 78M	juju-gui/
<frankban> ahasenack: that's the size of the branch, not the size of the single checkout. I believe most of space is for /bzr
<bac> juju downloads the charm before pushing it to your provider.  if you were to use juju-quickstart the charm is deployed directy to your provider.
<frankban> .bzr even
<bac> s/directy/directly/
<ahasenack> frankban: the du size is about half of what bzr said it downloaded, fwiw
<ahasenack> if you use juju-deployer, it will branch the charm branch first, and then deploy locally. I don't know if there is a "light" branch that can be used
<frankban> ahasenack: the charm includes the current juju-gui release, it is now ~4.6MB but used to be ~40MB. That's why over time the branch size increased a lot
<rick_h_> ahasenack: because we package up releases of the gui into the charm along with deps so that it's offline installable it gets big
<ahasenack> it got big because of the revisions
<rick_h_> ahasenack: rgr
<ahasenack> if you once had a 100Mb tarball in it, then remove it and add a 5Mb instead, the branch will still at least be 100Mb big
<rick_h_> ahasenack: a shallow checkout shouldn't be that big
<bac> juju-gui: juju-deployer should be doing a lightweight checkout not a branch
<rick_h_> exactly
<rick_h_> it's what we do with the gui itself when you specify a branch to use as the gui source. No need for revision history to deploy
<ahasenack> bzr co --lightweight lp:charms/precise/juju-gui <-- this downloaded roughly 5Mb
<rick_h_> ahasenack: that's the plan
<ahasenack> maybe it should use bzr export
<bac> bac@trusty64:/tmp$ bzr checkout --lightweight lp:charms/precise/juju-gui
<bac> bac@trusty64:/tmp$ du -sh juju-gui
<bac> 5.7M	juju-gui
<bac> oops, didn't see you'd done the same
<ahasenack> co --lightweight is still a bound branch
<rick_h_> ahasenack: yea, just minus the history so it should be just fine for juju-deployer needs. 
<ahasenack> rick_h_: ok, I'll ask hazmat
<ahasenack> wither co --l or export even
<ahasenack> either
<frankban> bac: re: the error: never encountered, it does not seems related to your branch or to quickstart in general
<frankban> bac: relatedly, could you please take a look at https://codereview.appspot.com/58680043 ? (quick branch)
<rick_h_> ahasenack: I'll file it as a bug on the deployer
<ahasenack> deployer has the --update option, so I think co --l is better than export
<rick_h_> ahasenack: add notes/tweak https://bugs.launchpad.net/juju-deployer/+bug/1274494 please
<_mup_> Bug #1274494: deployer does not do lightweight checkouts of charms <juju-deployer:New> <https://launchpad.net/bugs/1274494>
<ahasenack> thanks
<rick_h_> but yea, we've tried to optimize the gui charm a bit but it's got a big history as we weren't always so light weight. 
<rick_h_> gary_poster: brought it up and brought down the size only recently
<rick_h_> jujugui cool article on helpful ec2 tips/tricks. I like the billing monitoring bits https://launchbylunch.com/posts/2014/Jan/29/aws-tips/
<bac> frankban: will do
<bac> frankban: done
<bac> rick_h_: any reason we didn't keep juju-gui on launchpad and do an import from github?
<frankban> bac: thank you
<rick_h_> bac: because I didn't think/now we could change it like that and what came up in discussion was noting a MOVE
<bac> rick_h_: it may be, too, that vcs-imports from git are not reliable.  can't recall.
<bac> rick_h_: but if someone unwittingly checks out from lp, they get 40MB for one file.  :)
<rick_h_> bac: heh, tis true
<benji> rick_h_: I need to pair with someone.  Let me know when you have time.
<rick_h_> benji: rgr, on call atm but will ping when off
<benji> rick_h_: thanks
<bac> frankban: lightweight bzr checkouts directly from launchpad become unusable with your _vcs_branch prompt!
<frankban> bac: uhm, I'll try it, maybe we have to revert to using bzr info
<bac> frankban: in that scenario, i think using bzr anything will be a huge hit.
<frankban> bac: ah! because it fetches info from lp
<bac> yeah.  so just 'cd download-cache' causes the world to stop
 * benji considers becoming an electrician
<hatch> frankban do u have juju 1.17.1 installed? can you try and bootstrap local without sudo? It's throwing an error here
<hatch> frankban thanks for the review btw 
<frankban> hatch: I'll try ASAP
<hatch> thanks
<hatch> bac https://twitter.com/imlxgr/status/427916382748291073 lol
<bac> ha.  but that's not me.  i'm carpel tunnel free (atm)
<bac> well i have them, they aren't messed up
<bac> atm
<hatch> haha
<rick_h_> benji: off the call
<benji> rick_h_: I'm on one now. :)
<rick_h_> benji: see you later :)
<benji> k
<hazmat> frankban, gui branch merged and deployer 0.3.1 released to pypi
<frankban> hazmat: great thanks!
<frankban> hatch: what error?
<hatch> frankban that sudo is required
<hatch> and then any attempts after wards fail with some odd error about connecting to a local ip 
<hatch> I have to go and manually delete the folders to fix it
<frankban> hatch: even if you changed the path to include $GOPATH/bin, quickstart invokes juju with its full path (i.e. /usr/bin/juju) so you are actually using 1.16. To test your branch I'd suggest to temporary change the cmd to just "juju". Now you must detsroy the environment using 1.16. Moreover (and I forgot to mention it in the review), I'd keep the 'sudo privileges required to bootstrap the environment' message also w
<frankban> hen using 1.17, since sudo is still required, and the only difference is that it is invoked by core and not by quickstart
<hatch> frankban I mean I was just using core, not quickstart
<hatch> v 1.17.1 of core seems to require sudo for local environments
<frankban> hatch: revno?
<hatch> frankban no revno, installed from the repo
<hatch> er
<hatch> ppa
<hatch> 1.17.1-precise-amd64
<hatch>  /usr/bin/juju
<frankban> hatch: I don't see it here: https://launchpad.net/~juju/+archive/stable
<frankban> hatch: are you using trusty? are you sure juju is installed from the PPA and not from universe?
<hatch> I'm on precise....
<frankban> hatch:  apt-cache madison juju-core
<hatch> https://gist.github.com/hatched/f10981633e833e0b3073
<hatch> you're not seeing the same?
<frankban> hatch: no... I think it's worth asking core devs about this. it seems 1.17 is no longer published in the stable ppa. in trunk I have 1.17.2 and it does not require sudo. 
<hatch> ok so then I need to update quickstart then to test for the 'patch' 
<hatch> because 1.17.1 definitely asks for sudo
<frankban> hatch: I'd ask core devs if the release you have is reliable. If they consider 1.17 a development release we could in theory directly check for 1.18
<bac> gary_poster: call in 2 minutes?
<frankban> bac: I guess call in 30
<bac> frankban: i meant our 1:1
<bac> sorry for not being clear
<frankban> bac: oh ok
<gary_poster> bac replied on pm, but https://plus.google.com/hangouts/_/calendar/Z2FyeS5wb3N0ZXJAY2Fub25pY2FsLmNvbQ.b6tepoq090fnj4qfdg23a3okhg
<hatch> frankban ok 1.17.2 is the first version to not require sudo
<benji> out of context programmer quote of the day: "Sometimes a ball of mud is better than a tree." -- gary_poster 
<gary_poster> lol :-)
<benji> rick_h_: ping me when you have a few minutes
<rick_h_> benji: ping
<benji> rick_h_: I'll make a hangout
<frankban> hatch: is 1.17 a development version? will it be released to the stable ppa?
<hatch> frankban odd releases are not considered stable 
<benji> rick_h_: https://plus.google.com/hangouts/_/7acpi97gmmj5u8id27kf6un30g?hl=en
<frankban> hatch: so, as a consequence, I assume they are not published in the stable PPA. If so, I'd say, from our perspective, no sudo if version >= 1.18
<hatch> I suppose that's reasonable, is there any negative side effects you can think of if someone uses sudo on 1.17.2+ ?
<hatch> I can't think of any
<frankban> hatch: not sure, however, quickstart always install juju-core from the PPA (or from the base repos, assuming a newer version is present). So, if we can ensure development versions never land on the PPA or on production, we are ok with 1.18 check
<Makyo> jujugui call in 7ish.
<hatch> ok sounds good
<frankban> guihelp: I need one QA (there is not so much to review) for https://codereview.appspot.com/55230044 (charm). Anyone available?
<Makyo> jujugui call now ish
<gary_poster> oh thanks Makyo
<bac> jujugui: roger now says the mongo error from juju is a different known problem
<hatch> I think that a pure functional js application would be a pretty cool system
<hatch> but...but....events
<rick_h_> events are a means to an end that's all
<rick_h_> we have them, but their use can be a disaster so it has to be guided
<rick_h_> thanks gary_poster interesting points for me to think on now. /me wants to demo some inverse system of my current system
<gary_poster> rick_h_: :-) cool.  thanks for pushing the layer idea.  I agree it needs to be addressed, and needs a champion
<Makyo> FYI James is home sick, so will be taking care of food/walking dogs/etc. 
<hatch> I downloaded and started playing EVE lastnight
<hatch> we'll see if I enjoy it after the 14 day trial
<rick_h_> Makyo: review done will qa. Let me know if you disagree with my notes or are confused by them
<hatch> Makyo starting review
 * hatch still thinks it looks like fish on a pole
 * hatch is still thinking about a purely functional js app
<dimitern> hatch, gary_poster, I'm proposing a fix for bug 1273464 at the moment
<_mup_> Bug #1273464: putcharm api fails for compressed charm contents wrapped in a folder <api> <charms> <juju-core:In Progress by dimitern> <https://launchpad.net/bugs/1273464>
<hatch> dimitern thanks :)
<gary_poster> fantastic thanks dimitern
<hatch> it's kind of an odd duck but it solves a lot of issues cross platform :)
<dimitern> it even works with arbitrary nested dirs, as long as all the metadata, config and revision files are in the same dir
<hatch> awesome!
<dimitern> https://codereview.appspot.com/54680045 there it is, if you want to take a look
<hatch> dimitern FYI I'm to report back to the GUI team the status on the new api work so can you please include me in the discussions as they come up
<dimitern> hatch, sure, I'll remember - we don't have immediate talks scheduled though
<hatch> even better :P
<hatch> Makyo does Object.create() do a deep clone of the prototype you pass into it? I can't remember
<hatch> Makyo ok I thought I was right but I just wanted to be sure http://jsbin.com/efeSAxUq/1/
<Makyo> hatch, that's existing style  Â¯\_(ã)_/Â¯
<hatch> Makyo ok review complete - mind checking the comments over and letting me know if you want to chat about anything
<Makyo> hatch, we had a lot of talk this morning about consistency; I hope my responses are in line with that.  In short, I don't want to maintain two things that act in exactly the same way for different models in totally different ways; nor do I want scope-creep for this task.
<hatch> :+1:
<Makyo> ty
<hatch> (that doesn't quite have the same effect without the emoticon) :)
<Makyo> Will create a slack card for investigating factories, though. Kind of an abuse of constructors for no real benefit, seems like.
<hatch> yeah, it may have been left over from a refactor or something
<Makyo> Exactly. BoundingBox works the same way, but there's been work on it since it was created.
<hatch> rick_h_ lol this._cleanups.pop()(); go javascript
<rick_h_> hatch: no sense taking up memory creating a var we don't need :)
<hatch> haha 
<rick_h_> especially in hidden back end util code
<hatch> rick_h_ is there a deepEquals in python's assert? I can't seem to find the docs on the assert stuff
<hatch> I'm probably looking in the wrong places
<rick_h_> hatch: what are the two bits of data?
<hatch> here is what the util method is returning return int(major), int(minor), patch
<rick_h_> ok, so you're returning a tuple. You should be able to just assertEqual that
<hatch> self.assertEqual('foo', 'bar', 'baz', return_value)
<hatch> like so?
<rick_h_> no, self.assertEqual((foo, bar, baz), return_value)
<rick_h_> with quotes
<hatch> ok cool
<hatch> where are those docs anyways?
<hatch> the assert ones
<rick_h_> http://docs.python.org/2/library/unittest.html
<rick_h_> see 
<rick_h_> http://docs.python.org/2/library/unittest.html#assert-methods
<rick_h_> in  particular
<hatch> ok yep I was looking in the wrong place :)
<hatch> thanks
 * rick_h_ is so glad he got the 32gb N10
<rick_h_> remind me I need to get the 64 if they ever update it
<rick_h_> offline movies on planes ftw
<hatch> yeah 16H on the same plane will suuuuuck
<hatch> haha
<hatch> were you able to get business class?
<rick_h_> no :/
<hatch> boo urns
<hatch> probably serious $ for the upgrade
 * gary_poster been on calls straight since five hours ago :-)
<gary_poster> Time for lunch
<rick_h_> gary_poster: :/ lunch + motrin!
<gary_poster> :-)
<bac> hi hatch -- the work you're doing with quickstart and sudo, can you explain it briefly?
<bac> is using sudo no longer required for bootstrapping a local env?
<hatch> bac sort of
<hatch> :) ...
<hatch> so
<hatch> in versions 1.17.1 and lower you will still require sudo for local deployments
<bac> hatch: and in higher it disallows it?
<hatch> anything higher, the not quite yet released 1.17.2,  and higher it is not required
<bac> hatch: it seems juju-core trunk not only doesn't requires it but errors if you try to use sudo
<hatch> so since 1.17 is a dev release I'm setting quickstart to not use it in 1.18 and higher
<hatch> oh?
<hatch> hmm that's unfortunate
<hatch> what's the error?
<bac> yeah
<hatch> ok then I'll have to fix quickstart to target 1.17.1 and lower for sudo and not for anything else
<bac> so i'm trying to do interop testing with quickstart and juju-core trunk and there is no way to launch locally with the current combo
<hatch> man this is confusing hah
<hatch> yeah sorry, once I finish this quickstart branch then it will work
<hatch> I just have to finish the tests now, so once I finish my lunch I'll finish those up and you can test with this branch
<bac> ok
<bac> hatch: can't i just comment out the 'cmd.insert('sudo')' line?
<hatch> I suppose you could
<hatch> :)
<bac> seems to workish
<hatch> ish?
<hatch> what does that break?
<bac> well, it got past that point and is chewing along.  so far so good.
<bac> workish means it is in the process of working.
<hatch> gotcha :) ok running back to lunch, ping if you need
<hatch> rick_h_ need review on your pr?
<rick_h_> hatch: no, just self-reviewd it. Small and I waited to amke sure CI passed so should be good
<hatch> you don't destroy the container :(
<Makyo> Someone have 30sec free?
<hatch> yup
<rick_h_> hatch: that's the point, you can't the way the code works now
<Makyo> hatch,  comment LGTM QA okay on https://codereview.appspot.com/55230044
<Makyo> Still can't get rv to let me log in.
<rick_h_> hatch: I gave it a special class and will update the bug that it needs some love
<hatch> Makyo done
<Makyo> hatch, thanks!
<hatch> rick_h_ ohh the notifiers are left in the dom after each test 
<hatch> I see
<rick_h_> hatch: because the notifier has Anim code that comes in after a set timeout and expects to do things
<hatch> yeah....we should fix that
<rick_h_> hatch: if you pull the container the Anim dies an ugly death
<hatch> :)
<rick_h_> hatch: thus the bug :)
<hatch> haha
<hatch> rick_h_ what would cause  ```major, minor, patch = version_string.split('.', 2)``` to fail, in frankban's review he gave an example where it was involved in a try/except but I can't seem to get it to downright fail in the command line
<hatch> the docs don't give any indication either
<rick_h_> hatch: link to the review? The only thing I could see is if the version string wasn't 3 parts but two
<rick_h_> or not a string, maybe None
<hatch> well if it wasn't a string then ok
<rick_h_> or didn't container a .?
<hatch> but can a shell-out return non string values?
<hatch> https://gist.github.com/hatched/8716939
<hatch> rick_h_ there is the method with his suggested changes
<rick_h_> hatch: so I'd make sure to note the format expected. "1.17.0-trusty-amd64" and then the only thing I'd watch out for is assuming three parts
<rick_h_> will 2.0 be reported as 2.0.0
<rick_h_> or 2.0?
<rick_h_> or that you got no output, so if output was None
<hatch> that would have failed on the split though
<rick_h_> hatch: not sure tbh. 
<rick_h_> hatch: right
<hatch> ok so maybe he just suggested incorrectly
<hatch> I'll put the try around the split instead
<hatch> the first one that is
<rick_h_> hatch: link to his note? maybe if I read what he said I can be more helpful?
<hatch> https://code.launchpad.net/~hatch/juju-quickstart/no-more-sudo/+merge/203846/comments/476131 almost at the bottom
<rick_h_> hatch: ok, so yea. It's fine the way it is. The try/except is good in case you get back something unexpected. 
<rick_h_> hatch: so what was the original questoin? what could cause you to hit the exception?
<hatch> https://gist.github.com/hatched/8716939 see the new.py is what I just changed it to
<hatch> yeah I was trying to hit the exception for testing but coudln't without it failing before there
<rick_h_> oh crap my pebble shipped...Tues :(
<hatch> I think my new version is what he intended
<rick_h_> hatch: what happens if the version string is 2.0
<rick_h_> ?
<hatch> then you get ['2', '0']
<hatch> splits never return errors that I could find (or read on the docs)
<rick_h_> http://paste.ubuntu.com/6845543/
<rick_h_> hatch: ^
<hatch> ohh unpacking is the issue
<rick_h_> type python on the terminal and give it a try :)
<hatch> yeah I have been, I didn't think the unpacking would be an issue
<hatch> ok so...
<hatch> https://gist.github.com/hatched/8716939
<hatch> newnew.py
<rick_h_> the first one is pretty safe
<rick_h_> sure, works I think
<hatch> because output could never be anything but a string?
<rick_h_> I don't think so. but the call could fail
<rick_h_> if you don't have juju installed or something
<rick_h_> but I think that's promised at this point?
<hatch> right and that's already caught earlier in the app
<hatch> yeah
<rick_h_> k
<hatch> ok reverting to what he had
<rick_h_> cool
<hatch> the python test runner is irritating me
<hatch> it's like sometimes it bails without throwing an error if another test fails sometimes
<hatch> rick_h_ is there a .only equivalent in the python test suite?
<hatch> bah figured it out
<benji> I'm down to three test failures.
<hatch> yay
<bac> hey hatch, i was thinking the version of juju-core i hand-built called itself 1.17.2 ... but i wonder if it'll get bumped to 1.18 when released.  will impact the cut-off for your sudo work.  may want to touch bases with roger about it.
<hatch> bac 1.17.2 will be released in the dev side of things
<hatch> but the public releases will be 1.18.x
<bac> for anyone following along, the mongo-on-fire error occurs with the 1.17.2 patch
<hatch> the sudo stuff I have checks for below 1.17.2
<bac> yeah, that'll work
<hatch> https://code.launchpad.net/~hatch/juju-quickstart/no-more-sudo
<hatch> here is the branch if you want to see my changes
<bac> hatch: you've got conflicts...
<benji> oh man, those three tests only fail on a second run (reload of the test page)
<hatch> bac BLARG *grumble grumble grumble*
<rick_h_> benji: check the url hash
<rick_h_> benji: that's the card/issue Makyo brought up yesterday
<rick_h_> and I'll hopefully take a peek at tomorow/during flight
<rick_h_> benji: the test run has to start with a clean url (no hash) or it'll fail 
<benji> rick_h_: yep, I realized that was the problem.  Given that you know too, I assume it is a pre-existing condition.
<rick_h_> benji: yep, card in the slack task lane to look into it
<benji> ok
<benji> (I suggest that since it has cost me at least an hour of work it should be urgentified.)
<rick_h_> benji: as I said, hoping to work on it in travel tomorrow
<benji> cool
<bac> hatch: i think your local_bootstrap_requires_sudo is broken for some values, e.g.  1.18.1 and 2.17.2
<hatch> 2.17.2 works
<hatch> 1.18.1 doesnt
<hatch> I switched the wrong > :/
<hatch> thanks for the catch bac
<bac> ah, right, 2.17.1 didn't...
<huwshimi> Morning
<gary_poster> hey huwshimi.  talk to you soon
<huwshimi> Sure!
<mhall119> rick_h_: just wanted to say thanks for your juju help the other day, it seems the root cause of my problems was that staging wasn't using postgresql:db-admin when it should have
<huwshimi> rick_h_, hatch: Do either of you happen to know if you can resize the Phontom viewport in a single test?
<hatch> huwshimi I dont' know, I would also be pretty confident saying not the way our test structures are currently done
<hatch> but you can fire a fake resize event, no?
<hatch> if you like, you can push the code up and I can take a look
<huwshimi> hatch: I need to test two things... when the viewport starts at 1024px and another when it gets resized below that.
<huwshimi> hatch: I'll push it up
<rick_h_> mhall119: coolio glad you got it working
<rick_h_> huwshimi: I'd think it should be a selenium test to do that
<rick_h_> huwshimi: hatch http://stackoverflow.com/questions/16664433/how-to-resize-current-browser-window-in-selenium-webdriver-with-java
<rick_h_> huwshimi: /me isn't sure what you're working
<hatch> rick_h_ can selenium resize the window?
<rick_h_> hatch: see the linky 
<hatch> oh cool
<hatch> sorry my internet today has been bonkers
<hatch> so much lag
<rick_h_> hatch: it's using the java driver but should be available in all drivers
<hatch> I'm probably being DOSd
<rick_h_> I told you not to disagree with me. Too easy to take down those canadian interwebs :P
<hatch> lol, I need the internet we have at the head office
<hatch> 1GB/min lol
<hatch> rick_h_ when I had that issue about string vs int you mentioned that it was something to do with ascii to unicode conversion....is there docs about this issue?
<rick_h_> hatch: don't recall the issue but yea tons of unicode docs but it's a bit of a black pit. Block out some time. 
<rick_h_> http://lucumr.pocoo.org/2013/7/2/the-updated-guide-to-unicode/ maybe
<rick_h_> http://kunststube.net/encoding/ for generic unicode info 
<hatch> oh haha, the issue was "17" >= 17 == False but "1" >= 1 == True 
<rick_h_> oh, that's not unicode based stuff
<hatch> yeah I know about unicode, I was more interested in the technical issues with this 
<rick_h_> that's just  http://www.asciitable.com/
<hatch> I'm not pickin up what you're puttin down
<huwshimi> rick_h_, hatch: I've mocked out the tests for what I'm trying to achieve: https://github.com/huwshimi/juju-gui/commit/2225754cb0d26e50ffb6faae8f40b9bd98dbd2b8
<rick_h_> so python objects have __eq__ methods (see http://www.rafekettler.com/magicmethods.html) and when you do str == int it uses those methods to compare the values
<hatch> huwshimi yeah setting the size does not fire a resize event
<hatch> huwshimi you may be able to do Y.one(Y.config.win).fire('windowresize')
<hatch> or whichever resize event you're using
<hatch> Y.one(Y.config.win).simulate('resize') might be the proper syntax
 * hatch opens up the code
<hatch> huwshimi look at test_d3_components.js:150
<hatch> rick_h_ ahhh ok, see these are the things the language tutorials just seem to miss hah.
<rick_h_> hatch: for int, __eq__ just checks they're the same integer value. however, you had a string. When you == a string and in it, it compares the int value of that string. Which is the character code for it. So you were getting "character code for "7" which is 55
<hatch> gotcha, yeah that makes perfect sense once you know how it's working
<rick_h_> hatch: rgr, so yea. Look at the acsii table and you'll see that 55 is the code for a 7 character
<rick_h_> http://www.asciitable.com/
<hatch> yeah
<hatch> makes perfect sense
<hatch> cool that you can define your own magic methods
<huwshimi> hatch: If I use that can you set it to a particular size?
<rick_h_> yea, so let's say you create a class "boats" and want to be able to say if boat1 > boat2, you can flesh out hte magic methods that describe how to compare boats (say by a tonnage attribute)
<rick_h_> and make that actually work out just fine
<hatch> huwshimi the second parameter to simulate is a custom options object. I've never used it but it reads like it 'should' work to supply a custom 'what happened' object
<huwshimi> hatch: Additionally, I'm not sure if that helps me to set the initial size of the page without firing a resize
<hatch> http://yuilibrary.com/yui/docs/api/classes/Node.html#method_simulate
<hatch> rick_h_ yeah that's super cool
<hatch> might get confusing if you lose context as to what a boat is
<hatch> being loosely typed and all
<rick_h_> huwshimi: gary_poster is the AU going down tonight?
<huwshimi> rick_h_: Should be any minute now
<rick_h_> huwshimi: k, joined but no one around so was curious
<huwshimi> rick_h_: Oh, is there a regular url again?
<rick_h_> huwshimi: there was a url on the calendar event so used that
<huwshimi> I usually just get an invite
<huwshimi> Ah right
<rick_h_> oh, well let me know where to be when it's time
<gary_poster> me here
#juju-gui 2014-01-31
<huwshimi> rick_h_: Might hassle you about some selenium stuff quickly if you're still around once I've finished with Gary.
<huwshimi> gary_poster: https://github.com/huwshimi/juju-gui/compare/small-screen-notification
<huwshimi> rick_h_: If you're around, I guess knowing how we run our selenium tests would be a good start :)
<rick_h_> huwshimi: sorry, afk for the most part at the moment. If you send me a branch/email I can try to take a peek
<huwshimi> rick_h_: It's ok, I'll have a poke around.
<frankban> morning fwereade: I was prototyping a way to add the env name to the hooks context, if you have time, could you please take a quick look at http://pastebin.ubuntu.com/6848457/ ?
<frankban> that seems to work, not sure if it's worth of making two api requests for the uuid and the env name
<fwereade> frankban, roughly sane
<fwereade> frankban, the tricky bit is during an upgrade
<fwereade> frankban, upgraded units might want to call that method on a server that hasn't finished its upgrade yet
<frankban> fwereade: uhm... does it affect the current impl?
<fwereade> frankban, sorry, can I kick you sideways to jam please?
<frankban> fwereade: sure
<fwereade> frankban, wait no I can't he doesn't work fridays
<fwereade> dimitern, do you have a moment to discuss uniter api changes with frankban?
<dimitern> fwereade, frankban, sure
<frankban> dimitern: thanks
<frankban> thank you fwereade 
<dimitern> frankban, I've seen the paste - I have some suggestions re the api
<frankban> cool
<dimitern> frankban, I think we should add a CurrentEnvironment api call, that returns both the UUID and Name and deprecate the CurrentEnvironmentUUID call
<frankban> dimitern: +1
<dimitern> fwereade, do you concur?
<frankban> dimitern: that's what I was thinking as well
<fwereade> dimitern, frankban: yep, that definitely sgtm
<fwereade> dimitern, frankban: I'm mostly concerned about managing the changeover at upgrade time
<dimitern> frankban, and re backward compatibility, we need to make sure the client-side api handles gracefully the case when CurrentEnvironment is not available in an older apiserver
<dimitern> frankban, which means the code should work without a name or get the name in some other way
<frankban> I see
<frankban> dimitern: is it possible to have newer server and older units?
<dimitern> frankban, yes - until the upgrade is complete
<dimitern> fwereade, right?
<fwereade> dimitern, frankban: yes, during an upgrade there's currently no guarantee which will finish first
<frankban> dimitern: in that case also, old units would still call CurrentEnvironmentUUID
<dimitern> frankban, yes
<frankban> dimitern: so, if server > unit: we keep CurrentEnvironmentUUID, reimplementing it so that it uses CurrentEnvironment and return just uuid, error
<dimitern> frankban, just a sec
<dimitern> frankban, we implement CurrentEnvironment -> name, uuid in the apiserver; we keep CurrentEnvironmentUUID; the client-side tries to use CurrentEnvironment first for st.Environment(), and if it fails with CodeNotImplemented, uses CurrentEnvironmentUUID instead and keeps the name empty
<frankban> dimitern: sounds good
<dimitern> frankban, and the compatibility code should be in its own function (e.g. environ1dot16 or something - look for 1dot16 in state/api for examples)
<frankban> dimitern: do you want that check to be made at client call level? e.g. in state/api/uniter/environ? and how to call the new client method? NameAndUUID? Info?
<dimitern> frankban, I think the best way is to change st.Environment() method in state/api/uniter/uniter.go to call CurrentEnvironment directly, and if params.IsCodeNotImplemented(err), call func (st *State) environ1dot16() (string, error) and call CurrentEnvironmentUUID inside, returning an *Environment with just a UUID
<frankban> dimitern: ok will take a look
<dimitern> frankban, if err is nil, just return a *Environment with both name and uuid. Then, in state/api/uniter/environ.go we don't need st *State inside, but name and uuid strings as fields, and two methods Name() and UUID() which both return just strings (no errors - update the doc string of UUID() please), e.g. e.name and e.uuid
<frankban> dimitern: so, just o know I understand the direction, something like this? http://pastebin.ubuntu.com/6848807/
<dimitern> frankban, looks great, apart from a few minor suggestions: 1) doc comments on all exports (lines 7, 83, 103, 124), 2) tests for the IsCodeNotImplemented fallback - look in TestAddLocalCharm in state/apiserver/client/client_test
<dimitern> frankban, sorry, re 2) - not easy to test actually, but at least manually testing it should suffice
<frankban> dimitern: yeah, that just a prototype
<frankban> dimitern: I'll add comments and tests and also docs if required (to ducument the new env var in the hooks context)
<dimitern> (i.e. just change line 71 to call CurrentEnvironment1 or something and add some debug logging to environment1dot16 to ensure it gets called)
<dimitern> frankban, great, thanks
<frankban> cool
 * frankban bbiab
<bac> hi frankban, when you have some free time could you try to reproduce https://bugs.launchpad.net/bugs/1274692
<_mup_> Bug #1274692: Mongo error when deploying charm <juju-core:New for dimitern> <https://launchpad.net/bugs/1274692>
<frankban> hi bac: do I need to switch to revno 2282? what's the exact quickstart command you run?
<bac> frankban: yes, i was testing with the latest juju-core.  unfortunately it requires modifying quickstart/app.py to remove the 'cmd.insert('sudo')' if you're running locally.
<bac> frankban: i was just starting with: .venv/bin/python ./juju-quickstart
<bac> frankban: i have seen the failure on lxc and ec2
<bac> frankban: and trying again, manually bootstrapping with --upload-tools
<bac> s/and/am
<dimitern> frankban, bac, make sure you've rebuilt the binaries before doing bootstrap --upload-tools
<bac> dimitern: i have.  i'm surprised it has to be done manually, though.
<gary_poster> frankban: hi.  have we already changed quickstart to not create ssh keys for 1.17.x and higher (per "Juju Docs - SSH key requirements" thread
<bac> dimitern: i'm seeing http://paste.ubuntu.com/6849358/
<dimitern> bac, when deploying from source it's needed, otherwise you might end up bootstrapping with some older binaries and there's no way to tell
<frankban> bac: quickstart never uses --upload-tools: that can be the cause of the issue
<dimitern> bac, try with --show-log and --debug ?
<bac> frankban: yes, that's why i'm doing the bootstrap manually.
<dimitern> frankban, ah! that's the issue most likely
<bac> frankban: but this issue was seen using the ppa version
<bac> of juju
<bac> 1.17.1
<dimitern> bac, the ppa version doesn't include the fix, which i committed yesterday
<frankban> bac, dimitern: so it seems it should be fixed now, is it valuable for me to try to dupe?
<bac> dimitern: i get this from 'juju bootstrap' http://paste.ubuntu.com/6849369/
<dimitern> frankban, bac, well, I claim i've fixed it, but if you can repro it after the fix, i'll be most interested
<bac> frankban: not now, i guess
<bac> frankban: let me get a successful run using --upload-tools and see
<frankban> gary_poster: as per discussion with fwereade, since juju reuses keys if they are set up, we decided to keep that functionality in quickstart: it should continue to work with newer juju versions
<gary_poster> frankban: cool thx
<frankban> bac: ok
<dimitern> bac, something might be odd with the control bucket from a previous test perhaps? destroy/bootstrap should fix it
<bac> frankban: i'll add a note to HACKING making it clear you cannot use a hand-built juju with quickstart unless you bootstrap manually.  is that accurate?
<frankban> bac: even if you have $GOPATH/bin in the path, quickstart invokes /usr/bin/juju, so you are not actually using the trunk binaries. I think the confusing part pf this story is that you were using a broken ppa package
<dimitern> bac, frankban, so can we consider bug 1274692 for invalid then?
<_mup_> Bug #1274692: Mongo error when deploying charm <deploy> <race-condition> <juju-core:Triaged by dimitern> <https://launchpad.net/bugs/1274692>
<frankban> dimitern: if you confirm the 1.17.1 from PPA was broken, then I am inclined to say yes, but I'd wait for bac to confirm this in trunk
<dimitern> frankban, I can definitely confirm 1.17.1 from the ppa is broken, but trunk should be ok
<bac> dimitern: i'm testing now and will mark it invalid if trunk is ok.
<dimitern> bac, cheers
<bac> dimitern: but i still cannot get a clean bootstrap with upload tools, after changing control buckets
<frankban> bac: to do that, in addition to removing the sudo call in quickstart, you might want to change "/usr/bin/juju" to just "juju" everywhere in app.py
<bac> frankban: i have linked /usr/bin/juju and jujud to be the trunk version
<frankban> bac:  try to destroy the environment using both the PPA version and the trunk version of juju
<frankban> bac: cool
<bac> frankban: neither show an environment started
<bac> nothing to destroy
<dimitern> bac, you could manually delete your control bucket from the ec2 console, remove any .jenv files and try anew
<hatch> bac is distUtils already included in quickstart?
<bac> hatch: it is a core library
<bac> so, it'll always be there
<hatch> lol no docs http://docs.python.org/2/distutils/apiref.html#module-distutils.version
<bac> oh that's weird
<hatch> It works now I think I'll just wait for frankban 's review haha
<bac> hatch: if you are curious you can do help(distutils.version)
<hatch> >>> help(distutils.version)
<hatch> Traceback (most recent call last):
<hatch>   File "<stdin>", line 1, in <module>
<hatch> NameError: name 'distutils' is not defined
<hatch> even the cli doesn't want me to use it
<hatch> haha
<frankban> hatch: "import distutils" before that
<hatch> AttributeError: 'module' object has no attribute 'version'
<hatch> it don't exist yo!
<bac> hatch: are you running trusty?
<bac> import distutils.version
<bac> help(distutils.version)
<bac> profit
<hatch> 12.04
<gary_poster> rick_h_: you saw spencer got you the images?
<hatch> python 2.7.3
<bac> frankban: are .jenv files supposed to be left around after an env is destroyed?
<frankban> hatch: >>> from distutils import version
<frankban> >>> help(version)
<hatch> there we go
<frankban> bac: no AFAIK, but their removal is not always guaranteed
<rick_h_> gary_poster: yep, offline'd them into dropbox
<frankban> hatch: from __future__ import braces
<rick_h_> gary_poster: thanks for the poke
<gary_poster> rick_h_: cool, np
<hatch> ""Version numbering for anal retentives and software idealists."" lol!
<rick_h_> bac: hatch we should be off of distutils. It's going away. setuptools or bust
<hatch> yeah ok I'm leaving my branch as is lol
<rick_h_> bac: hatch https://mail.python.org/pipermail/distutils-sig/2013-March/020126.html
<bac> frankban: not guaranteed to be removed and it looks like they are not regenerated if environments.yaml changes
<frankban> hatch: I'd prefer "Version numbering for anarchists and software realists."
<rick_h_> sorry, distribute, nvm
<bac> rick_h_: really.  is there another package that provide versioning?
<rick_h_> ignore me
<rick_h_> bac: for versioning pkg_resources provides it
<frankban> hatch: didn't know your branch is ready for review
<hatch> frankban oh, I guess LP doesn't send emails when the branch is updated :/
<hatch> sorry bout that
<rick_h_> bac: https://github.com/juju/jenkins-github-lander/blob/develop/src/jenkinsgithublander/__init__.py
<bac> rick_h_: sorry, i meant parsing and comparison
<rick_h_> bac: sorry, jumped into the middle of a conversation and missing context. Ignore me. Carry on. 
<frankban> hatch: np, I'll look at it asap, so, is distutils not worth of bothering?
<hatch> reading the docs I don't really see what it gets us
<hatch> maybe some parsing
<hatch> save a couple lines....maybe?
<hatch> it doesn't look like I can do comparisons
<frankban> bac: yeah, if something goes wrong and the jenv is not deleted the only solution I know is to remove the files manually. I hope that happens only when you do unexpected things, like using different version of juju or removing instances manually (e.g. from the ec2 console)
<frankban> hatch: In [8]: from distutils.version import LooseVersion
<frankban> In [9]: LooseVersion('1.18') < LooseVersion('1.17.2wtf')
<frankban> Out[9]: False
<bac> frankban: doesn't StrictVersion work for our needs?
<frankban> hatch: implementer choice IMHO, but if you decide for distutils that's how it is used. And in our case StrictVersion should work as well, as bac suggests
<frankban> hatch: if you use ipython (which I strongly suggest) you can also do things like "object?" to see docs and "object??" to also see the definition
<frankban> hatch: and it also has inspect/autocompletion and other cool features
<frankban> dimitern: I have a juju test intermittently failing in trunk: http://pastebin.ubuntu.com/6849689/ I am on saucy revno 2285
<dimitern> frankban, that's a known issue, but it's very hard to reproduce
<dimitern> frankban, do you get it consistently?
<frankban> dimitern: it is intermittent, it fails once every 3/4 runs
<benji> hatch: I have an event handler that is being called multiple times even though the event is only fired once.  Any idea why that might be?
<hatch> benji that means it was attached multiple times
<hatch> if you put a debugger in front of the attach point then you can see when it gets called
<benji> oooh, that makes sense
<hatch> :)
<benji> hatch: while I have you; what does "addEvent" do?  I can't find it in the YUI docs anywhere.
<hatch> it's an extension rick_h_  wrote which allows you to hold onto the event handler to detach later without having to manually manage them
<hatch> benji grep for Y.Event.EventTracker
<bac> frankban: can i trouble you to verify you can do a 'juju bootstrap --upload-tools' with juju-core trunk?
<benji> thanks
<frankban> bac: trying
<bac> thx
<hatch> app/assets/javascripts/event-tracker.js is the source :)
<benji> this is one of those things in "assets"; that's such a silly place for code we wrote ourselves and isn't managed as an external project
<frankban> bac: it worked, what errors are you encountering?
<bac> frankban: unable to upload tools to the bucket
<frankban> bac: local env?
<bac> ec2
<frankban> bac: trying ec2
<hatch> benji haha yeah, I use `git grep -n foo` all the time :)
<gary_poster> jujgui call in 10
<gary_poster> jujugui call in 2
<gary_poster> safe travels rick_h_
<dimitern> gary_poster, hatch, the fix for bug 1273464 just landed
<_mup_> Bug #1273464: putcharm api fails for compressed charm contents wrapped in a folder <api> <charms> <juju-core:Fix Committed by dimitern> <https://launchpad.net/bugs/1273464>
<gary_poster> awesome thanks dimitern!
<hatch> awesome thanks
<dimitern> please test it with zip created on windows as well - it should work just the same
<gary_poster> hey luca_ could you please get us the relationship circle assets before you get on the plane?
<luca_> gary_poster: I'll see, Spencer will have to deliver that
<gary_poster> ok thanks luca_
<benji> darn, now I have to merge in all those conflicts
<frankban> hatch: your mp has conflicts
<hatch> *sigh*
<hatch> haha
 * gary_poster stepping out for lunch
<hatch> booting up vm
<hatch> frankban what's the best way to merge these? it doesn't appear to want to let me
<frankban> hatch: who is blocking you? ;-)
<hatch> frankban it says they have diverged then just dumps out
<frankban> hatch: pull trunk, then merge trunk, you should see conflicts, fix them and then "bzr resolve" + commit
<hatch> yeah I didn't create a shared repo for this branch so is there any way I can merge trunk into my current branch without pulling it down into a separate folder?
<hatch> I really need to figure out a way to link the gui source directory in the charm to my local directory so it would be easier to work with
<frankban> hatch: bzr merge lp:juju-quickstart ? but I suggest you to setup a shared repo. I also use lightweight checkouts, and the work flow is similar to the one you are used to with git. the charm solves deploy issues with "make deploy" so basically the charm does not need to be in a local charm repository
<hatch> yeah I will set up a shared repo, I wasn't expecting this branch to take this long :D
 * Makyo dogwalk
<hatch> bac did you handle the frankban  ok conflict fixed
<hatch> woah
<hatch> lol
<hatch> lets try that again
<hatch> frankban conflict has been fixed and pushed
<hatch> :)
<frankban> cool
<frankban> on it
<hatch> thanks /me crosses fingers
<frankban> hatch: done
<hatch> frankban lol, alphabetical fail
<frankban> :-)
<frankban> hatch: I know you think this branch is taking forever, but, given this is your first Python code, I am instead surprised about how quickly you got fluency on the language
<benji> jujugui: my branch is up for review at https://github.com/juju/juju-gui/pull/96
<hatch> benji on it
<hatch> benji oh you'll need to rebase
<hatch> somehow...
<rick_h_> benji: looking
<hatch> oh rick_h_  you're still here?
<hatch> heh
<benji> hatch: I... though I had done that.
<hatch> lol
<hatch> git is confusing sometimes
<hatch> frankban well thanks! I'm on the fixes right now
<frankban> hatch: fixed my comments, I think the correct comparison is just: return (major, minor, patch) < (1, 17, 2)
<hatch> oh cool
<rick_h_> benji: build failed due to make lint
<benji> darn, I ran lint... oh that was before all the git calistenics I did to get things merged
<rick_h_> benji: but LGTM with a couple of comments and places to make sure we clean up things 
<benji> rick_h_: thanks; I'm going to take lunch now (with a side of wishing for death -- bad head cold).  Afterward I'll address the review issues and attemp a rebase.
<rick_h_> benji: rgr, good luck
<benji> (Didn't Richard Pryor have problems with rebasing too?)
<hatch> launchpad reviews are sure horrible
<hatch> sheesh
<rick_h_> anyone tried 1.17.2? /me is sticking with 1.17.0 atm since it was working ok locally
<frankban> rick_h_: trunk works well with local envs, so I presum 1.17.2 is ok too
<rick_h_> frankban: cool
<hatch> frankban ok the fixes have been pushed
<hatch> I think I finally got the deps in the proper order haha
<frankban> hatch: :-) they looks good, but I am past EOD and don't have time now to QA, could you please ask someone else?
<hatch> sure
<hatch> bac benji 
<hatch> thanks!
<frankban> thank you, have a nice we!
<hatch> you too :)
<bac> hatch: sure
<hatch> thanks
<bac> hatch: i need that change now anyway!
<hatch> haha aww yeah!
<hatch> oo boy that's a lot of functional refactoring
<hatch> should make it da-bomb to test though
<rick_h_> hatch: huh? 
<hatch> rick_h_ I just refactored my local charm upload to be purely functional
<rick_h_> hatch: oh cool
<hatch> lots of functions in functional style
<hatch> lol
<bac> hatch: QA looks good.  i didn't let it bring the envs all the way up but it started bootstrapping without mentioning sudo.
<hatch> that's good thanks for the QA!
<hatch> so now how should I land this since I can't use lbox? 
<bac> hatch: sorry, i didn't see your question.
<bac> hatch: create a fresh branch for lp:juju-quickstart.  merge your branch into it. then check it in with a nice message of the form:
<bac> bzr ci -m '[r=frankban] Don't use sudo, blah blah'
<bac> then bzr push lp:juju-quickstart
<hatch> no problem
<bac> hatch: make sure you run make lint first
<hatch> heh yeah
<bac> since lbox usually does it
<hatch> it's really too bad lbox doesn't work in the console and requires a browser for auth
<bac> there is a work-around for that but i can't do it off the top of my head
<hatch> ugh kernel panic....go osx
<bac> hatch: wait
<bac> hatch: at the end of quickstart i get this message
<bac> Run "sudo juju destroy-environment -e local [-y]"
<bac> to destroy the environment you just bootstrapped.
<bac> the sudo is not required for destroy, right?
<hatch> I'm guessing that if sudo is not required to start then it's not required for destroy
<hatch> good catch
<bac> i'll confirm.  but if that is true we should change that message
<hatch> yeah, ok I'll do that after lunch
 * hatch hunnnnngry
<bac> hatch: and for >= 1.7.2 the '-e' is deprecated
<hatch> yeah, which is bonkers
<bac> no kidding!
<hatch> because you need it for bootstrap
<hatch> so it makes no sense
<bac> you need it for every other damned command
<hatch> lol
<bac> should yell at thumper about that
<hatch> I just asked in #juju-dev
<bac> ha!
<benji> here is a nice article I read during lunch about some of Chrome's nicer dev/debug tools: https://medium.com/p/f1f29cb2c5e0
<hatch> cool I'll check it out
<hatch> monitorEvents is cool
<hatch> I didn't know about that one
<hatch> deploying local charms via the GUI is so darn cool :D
<hatch> and the charms even deploy and everything :)
<hatch> this is going to be a huge release next
<hatch> benji - I really have no idea the proper way to rebase your branch
<hatch> with all of those merges and commits from rick
<hatch> hmm
<hatch> maybe it'll need to be rebased into a couple commits
<benji> hatch: I'm looking at it now and I don't either.  I'm going to attempt to create a new branch and use patch to get the changes into it
<benji> I wish I had time to read a book on git.
<gary_poster> mm, maybe Makyo would know, if he's around?
<hatch> when you do that... I'd like it if you could try `git rebase -i HEAD~17` then squash them into logical commits
<Makyo> _o/
<hatch> but I did that before and totally borked my branch and had to cherry-pick
<Makyo> Either patch or cherry-pick, yeah.
<gary_poster> hey Makyo.  are you up on pretending to be a git expert for benji?
<hatch> lol
<gary_poster> oh yeah cherry pick
<gary_poster> might be easier?
<gary_poster> under these circumstances
<hatch> well not really because he needs all of them
<Makyo> Create a new branch off develop, then cherry-pick changes from your working branch.  You can either recreate your PR, or push -f over the old one (daaangerous, though, not recommended)
<Makyo> hatch, But can rebase without the merge commits then.
<Makyo> I think...
<hatch> can he though? he would have worked ontop of them
<hatch> so I don't think that will work...
<Makyo> Well, if you cherry-pick into a branch that already has those commits?
<Makyo> Then they're not merges.
<hatch> hmm...good point
<hatch> it might work
<Makyo> That's what I mean.  git juju-sync; git checkout -b new-feature-branch; git cherry-pick...
<hatch> then rebase after the cherry-picking
<Makyo> Yeah.
<hatch> that's probably a good technique
<Makyo> cherry-pick is a pain.
<Makyo> But it'll do it.
<Makyo> To be fair, patching will be easier if there's a lot of changes, though.
<hatch> I am really curious if using HEAD~`7 will do it
<hatch> er
<hatch> git rebase -i HEAD~17
<hatch> then leave the merges
<hatch> then he'll only have to cherry pick a few commits
<benji> so, how do I get a patch with just the differences between my branch and the official develop branch?
<Makyo> diff against develop into a file, then apply with git patch, I think.
<Makyo> I'm hesitant to give commands, because I know I'm going to mix it up with bzr.
<hatch> the issue with patch is that it's going to include the merge diff too
<hatch> isn't it?
<Makyo> No, because that won't differ from develop.
<Makyo> You'll have to juju-sync before either of these options.
<hatch> ahh right right gota diff against develop not local trunk
<Makyo> Yeah.
<bac> hatch: have a look at https://help.launchpad.net/API/EndUserHints .  the /bin/echo trick might be what you need
<Makyo> (Which is sort of like diffing against local trunk after syncing develop)
<bac> hatch: for your lbox woes, i mean
<hatch> hmm thanks I'll take a look 
<bac> hatch: you close to landing that quickstart branch?
<hatch> bac sorry was working on js for a bit :) will do that stuff for the naming now
<hatch> bac actually, is there a way we can store the sudo require status somewhere? 
<benji> I think Rick put some changes from another one of his branches into this one.  A branch that may not have landed yet, so I'm getting lots of changes that aren't native to this branch.
<bac> hatch: looking
<hatch> bac actually....
<hatch> I can probably do this using format()
<bac> yep
<bac> you got alls you need
<hatch> bac can you check this out to see if this is correct? I don't really want to run a whole QA cycle to test :P https://gist.github.com/hatched/8742817
<hatch> I think I used format() properly 
<hatch> :)
<bac> hatch: you can drop the is_local at line 11.  otherwise looks great
<hatch> ahh right
<hatch> bac done https://code.launchpad.net/~juju-gui/juju-quickstart/trunk
<hatch> thanks for the help
<bac> ooooh, hatch, you're gonna get it!  you broke francesco's 100% test coverage!
<hatch> shoot I didn't know we were doing that!
<hatch> I can fix in a follow-up 
<hatch> :)
<bac> hatch: he's been obsessive about it from day one.
<hatch> figures i'd be the one to break it
<bac> Makyo: i looked into it a bit more after being really annoyed by the quickstart ssh-agent problem.  it looks like the fix is quite simple.  would you have time to have a look?  https://codereview.appspot.com/53740045
<Makyo> bac, sure.
<bac> Makyo: i see that some tests are not mocking out ssh-agent calls, so 'make test' spins up five still.
<Makyo> Oh, boo.
<Makyo> Looks good otherwise.  Still can't get on rv but will try again in a bit.
<Makyo> s/get on/login on
<bac> Makyo: i've made the changes to mock out the test calls to the actual ssh-agent.  pushing changes now.
<Makyo> bac, cool.  Will look in a few.  May have to make comments here, haven't figured out rv issue.
<Makyo> (just get a 500 whenever I try to sign in)
<bac> Makyo: you can use the LP merge proposal if you'd like.  would at least be more persistent than IRC logs.  :)
<Makyo> bac, sure thing.
<hatch> gary_poster I looked at huw's branch and suggested the fix for the test failures
<bac> cool.  going to do short walk with jojo
<gary_poster> awesome thanks hatch
<Makyo> Alright.
<Makyo> Should do the same in a bit.  Grr snow.
<hatch> no problem
<hatch> POLAR VORTEX!!
<Makyo> Pff.
<hatch> lol
<Makyo> I like to think of it as 'winter'.
<hatch> rofl agreed
<Makyo> Dogs are enjoying it, though. http://ubuntuone.com/gallery/56atUQ5IHr3CkOXeT605zL/IMG_20140131_094451.jpg
<Makyo> Falcon had to sniff something on the other side of Zephyr.  Obviously the most efficient way was underneath him.
<gary_poster> heh :-)
<gary_poster> and...that
<gary_poster> is a bit of snow
<hatch> you're dogs names are Falcon and Zephyr? HAHA That's AWESOM!
<gary_poster> have a great weekend all
 * Makyo dogwalk.  Again. :T
#juju-gui 2014-02-01
<rick_h_> anyone around?
<rick_h_> oh heh, it's Sat. no one's going to be around doh
#juju-gui 2014-02-02
<huwshimi> Morning
#juju-gui 2015-01-26
<robbiew> rick_h_: could you shoot me that link for jujucharms.com activity whenever you get a chance?  no rush
<hatch> robbiew: he is not in atm
<hatch> I'm guessing back in an hourish :)
<rick_h_> robbiew: invited you in and you should get an email. 
<rick_h_> robbiew: let me know if you don't
<robbiew> rick_h_: got it, thanks!
<rick_h_> robbiew: woot
<huwshimi> Morning
#juju-gui 2015-01-28
<sebas5384> ping rick_h_
<rick_h_> sebas5384: pong
<sebas5384> rick_h_: I found some strange things in the juju gui, here's an screenshot
<sebas5384> http://awesomescreenshot.com/0024ae5f3e
<sebas5384> at the https://demo.jujucharms.com
<hatch> that bug again
<hatch> sebas5384: what browser/version/os?
<sebas5384> hatch: mac osx, chrome Version 40.0.2214.91 (64-bit)
<hatch> ahh interesting
<hatch> so it only appears to happen in chrome in oxc
<hatch> osx
<hatch> sebas5384: does it happen all the time or has it fixed itself after refresh?
<sebas5384> hatch: I refreshed and it still doing that
<rick_h_> hatch: I got it in chrome dev in ubuntu this week as well
<hatch> oh great they are re-introducing bugs into chrome
<hatch> :)
<hatch> svg's are not our friend with chrome it seems 
<mbruzek> What is the best way to get the revision number that the bundle is looking for?
<mbruzek> I know it is not tied to the bzr revision, oh!  Just look them up on jujucharms.com
<hatch> sebas5384: could you file a bug with that screenshot plz?
<hatch> sebas5384: tbh I'm not sure if there is anything we can do about it but we'll look into it, maybe we're missing some attribute 
<hatch> respective chrome bugs are marked as resolved so they may have introduced a regression
<sebas5384> hatch: yeah sure, and it seems to be just the size of the svg
<sebas5384> hatch: do you have the link to where i can file the bug?
<hatch> yup one sec
<hatch> sebas5384: https://bugs.launchpad.net/juju-gui
<sebas5384> hatch: thanks!
<hatch> no thank you :)
<sebas5384> hatch: https://bugs.launchpad.net/juju-gui/+bug/1415550
<mup> Bug #1415550: Charm's SVG icons with wrong size in Chrome <icon> <svg> <juju-gui:New> <https://launchpad.net/bugs/1415550>
<sebas5384> :)
<hatch> sebas5384: thanks!
<sebas5384> hatch: np!
<huwshimi> Morning
#juju-gui 2015-01-29
<huwshimi> Morning
<Makyo> uiteam makefile update https://github.com/juju/juju-gui/pull/690 (doh, forgot to hit enter)
<huwshimi> Makyo: I'll take a look
<hatch> Makyo: why is it called vagrant-provision?
<rick_h_> hatch: around?
<hatch> you bet
<rick_h_> hatch: added a card for you, higher priority than your 'story card' for next week
<hatch> just qa'ing Makyo's thingy
<hatch> ok looking
<rick_h_> hatch: juju is giving up a heads up that it's coming close to closing time on our api calls without the uuid in the api urls 
<rick_h_>  /up/us
<rick_h_> hatch: let me know if you need to chat about it or if it's pretty clear
<hatch> definitely chat - I have no idea :)
<hatch> standup:?
<rick_h_> hatch: k 
<hatch> Makyo: so apparently make sysdeps is installing firefox
<hatch> lol
<Makyo> hatch, required for phantomjs
<Makyo> (well, -A- browser.
<Makyo> )
<hatch> ohh right right
<Makyo> but yeah, the vagrant setup actually gives us all we need for the system setup, figured it wasn't worth duplicating a list of dependencies.
<Makyo> But we could probably rename the file
<hatch> yeah probably worth doing that
<Makyo> (Vagrant doesn't care what it's named)
<hatch> oh that's good
<hatch> it's still installing
<hatch> I'm sure the qa will be fine
<hatch> :)
<hatch> so pumped to have a sysdeps in the gui now though
<hatch> Makyo: qa and review done
<Makyo> What the heck, mouse just ate it
<Makyo> Computers Â¯\_(ã)_/Â¯
<hatch> haha
#juju-gui 2015-01-30
<hatch> lp|Metrics: The graphic titled 'Social Engagements' is pretty cool :)
<hatch> that small svg bug is really irritating
<hatch> I can now reproduce it after updating chrome
<hatch> :/
<hatch> annnnnd now I can't reproduce the export bug
<hatch> ^ rick_h_ :/ 
<hatch> rick_h_: yeah nothing I can do will reproduce that bug any longer. I'm going to have to bench it, maybe it was some obscure caching issue?
<hatch> jujugui anyone able to test a GUI bug for me?
<hatch> frankban: any luck reproducing that bug?
<hatch> looks like it only happens when dragging a charm to the canvas from the charmbrowser
<mbruzek> hatch ping
<mbruzek> Can anyone here explain the jujucharms.com injest process?
<mbruzek> I am not seeing a different version of the charm.
<hatch> mbruzek: it should take about 30m
<hatch> assuming of course that it passes proof
<mbruzek> hatch: this is a personal branch
<mbruzek> hatch does it always run proof on those branches?
<hatch> same rules apply
<hatch> yup
<mbruzek> hatch: so can you explain something to me?
<hatch> sure, any topic in particular? 
<hatch> or should I just pick something :P
<mbruzek> the code is on bzr revision 3.  The jujucharms.com shows kubernetes-master-1, there should be a 2 in there too, but maybe it did not pass proof
<mbruzek> How does jujucharms.com revision the charm?
<hatch> honestly I'm not too sure now that the revision file is no longer required
<mbruzek> hatch: I pushed 3 almost 30 minutes ago, but I do/did not see the kubernetes-master-2 in jujucharms.com
<hatch> in theory it could be up to an hour, if you pushed it just after the last ingestion started
<mbruzek> bzr shows me 3 commits now, myself, whit, and myself.
<mbruzek> But when I look at jujucharms.com I only see kubernets-master-1 I can not find kubernetes-master-2
<mbruzek> which would have been whit's version
<hatch> that does look to be the case
<hatch> I don't have access to the machine to view the logs
<mbruzek> hatch: I see your point about ingestion that is fine. I can wait.
<hatch> friday - everyone who does is gone :)
<mbruzek> hatch: OK
<hatch> but yeah maybe give it 15 more mins or so
<hatch> Does it pass proof locally?
<mbruzek> The thing is I have to build a bundle to point to the LATEST version of my charm.
<mbruzek> hatch: yes it does, just double checked
<hatch> ok then yeah maybe just hold off another 15m or so and then fire an email to peeps 
<mbruzek> hatch: I don't see how proof is tied in here.  People can push stuff in their namespace that does not pass proof
<mbruzek> hatch: like if they are building a charm and don't know about proof
<hatch> then it won't end up in the charmbrowser
<mbruzek> hatch: If you say so.  I didn't know that
<mbruzek> hatch: whit's changes were not passing proof that is what I was fixing.  his code was up there to the latest version
 * mbruzek is confused
<hatch> this is under your namespace or charmers?
<mbruzek> we created a group called ~kubernetes
<hatch> ok yeah I see -1 
<mbruzek> https://code.launchpad.net/~kubernetes/charms/trusty/kubernetes-master/trunk
<mbruzek> You see 3 commits there right?
<hatch> yeah
<hatch> there were some issues with ingestion speed last week, I can't remember if those were resolved 
<mbruzek> when my old bundle was pulling cs:trusty/kubernetes-master-1 I was getting proof errors in whit's code
<mbruzek> so I set out to fix the code, revision three and I want to know what number this will show up in for the charm store browser
<mbruzek> so I can build the bundle to point to the right code
<mbruzek> hatch what makes the charmstore increment the counter, I am aware it is not tied to bzr.
<hatch> I don't know - I think that it does it on each ingestion where the code differs
<hatch> mbruzek: yeah it still hasn't ingested - Your best bet would be to email peeps
<mbruzek> who is peeps?
<mbruzek> your peeps?
<hatch> sent ya a msg :) 
<hatch> you should have done this about 4 hours ago :P
<mbruzek> hatch:  yeah
<hatch> now if you had a GUI problem - i'd be able to help you out :D
<mbruzek> doh
<mbruzek> Now I see it is -2
<mbruzek> JUST after I checked in the damn bundle
<mbruzek> argh
<hatch> https://jujucharms.com/u/kubernetes/kubernetes-master/trusty/2 there it is :)
<mbruzek> why is this one 2 and the other one was showing up as -1 when there are 3 bzr commits?
<hatch> mbruzek: likely the reason I mentioned above - it didn't ingest the second commit
<hatch> https://jujucharms.com/u/kubernetes/kubernetes-master/trusty/2#revisions
<hatch> it's a little confusing, I agree
<hatch> bug report? :)
<mbruzek> no rick will  just hulk smash me with his logic
<mbruzek> and it might makes sense to him, I would believe that
<mbruzek> I am happy now that I can see it, but I *JUST* checked in the code
<hatch> lol
<hatch> so yeah looks like you had just missed the previous ingestion
<mbruzek> meaning I just checked in the bundle with the old -1 revision, so I have to check in 3 more bundles
<hatch> good thing version control makes it easy :)
<hatch> rebase ftw!
<hatch> mbruzek: so you're good now?
<mbruzek> hatch: yes thank you
<mbruzek> hatch: thanks for your help and sticking with my questions
<mbruzek> hatch: happy Friday!
<hatch> haha np, to you too
#juju-gui 2015-02-01
<huwshimi> Morning
#juju-gui 2016-02-01
<stokachu> fabrice: i was wondering what still needed to be done for https://github.com/juju/theblues/pull/8 to finalize?
<stokachu> i have my own debian package repo for theblues as well
<rick_h__> jrwren: ^
<stokachu> also is this package blocked on anything for making it into the official archives?
<jrwren> stokachu: I don't know. going to official was never a goal. It may not pass deblint
<jrwren> stokachu: ah, it depends on libmacaroons which is not in official archives, so there is a dep chain up which would need to become official.
<stokachu> ok, is there any word on if libmacaroons will be in the official archives for xenial?
<jrwren> stokachu: I know of no effort. Maybe best to ask in #ubuntu-devel
<jrwren> stokachu: or even check debian WNPP?
<stokachu> how are you guys using it?
<stokachu> just compiling from source?
<jrwren> stokachu: we packaged libmacaroons ourselves, so again, probably much deblint. Never with scrutiny of an official archives package
<stokachu> so is it safe to say then i shouldn't be relying on theblues for our projects?
<rick_h__> stokachu: it's safe to say we should be working to get that pushed farther. theblues is supposed to be the client library we offer folks as a canonical supported tool. 
<rick_h__> stokachu: it's just not gotten the attention/roadmap love as it's been young and mostly used on the team
<stokachu> no worries, im just in a bit of a time crunch with this other project that uses the charmstore api
<stokachu> and i don't see getting libmacaroons in debian then ubuntu anytime soon
<rick_h__> stokachu: you need it packaged and in before freeze?
<stokachu> yea 
<stokachu> i can always just use requests and call out manually
<rick_h__> yea, I don't think the team realized that 
<stokachu> nah i didn't tell anyone I needed that either
<rick_h__> we'd prefer to use the client tool and to make it official and avoid the juju based library messes of the past
<stokachu> as this project was kind of last minute
<stokachu> yea
<rick_h__> stokachu: understand. 
<jrwren> the requests calls can get tricky with auth and macaroons IIRC.  But I may be confused on that.
<stokachu> well whatever i can do, i can get into debian mentors and get libmacaroons packaged
<stokachu> it's just finding someone to quickly pull it in before our freeze
<rick_h__> stokachu: I don't think we can get it in before freeze. The team is sprinting next week and the package does work
<stokachu> yea
<stokachu> so right now im only using the api to pull in a bundle file
<rick_h__> stokachu: if we can find someone to help review/push it along we can ask the team to help with the items
<stokachu> could probably ask stephane or xnox
<rick_h__> stokachu: the team will need someone to help them build out the required effort to see what needs doing
<stokachu> ah
<stokachu> ill see what it takes to get libmacaroons packaged
<rick_h__> stokachu: ty, if you can get a cursory list of what's ungood in the current package then we can chat how much time it'll take to address. 
<stokachu> since theblues is really ubuntu only that shouldnt be as bad
<rick_h__> stokachu: thank you
<rick_h__> stokachu: yea
<stokachu> np
<stokachu> i ran a lintian against my theblues package and it didn't give any bad errors
#juju-gui 2016-02-02
<cloudgur_> question .. what is the best way change the default charm logo when using the layer-docker model ?
<cloudgur_> I've updated the config.yaml for logo as normal but the dependencies keep pulling in the docker logo as icon.svg in the charm root path after build
<hatch> cloudgur_: you had a question about a charm icon in the GUI?
<jrwren> the question was more about the new charm layers system.
<jrwren> i'm guessing the layer docker includes an icon, but there needs be some way to override that default.
<cloudgur_> Exactly .. Any clues ?
<cloudgur_> Lazypower might have some insight
<hatch> cloudgur_: the GUI will always display the icon file in the root of the charm 
<cloudgur_> agreed
<hatch> cloudgur_: so what you want to do is modify that file
<cloudgur_> was wondering how to over ride the icon.svg pulled by the layer-docker charm.  The config.yaml value is showing but the intended icon.svg does not
<hatch> oh I see what the issue is
<hatch> now as far as how to solve the issue
<hatch> cloudgur_: so I haven't actually ran into this before - I'm assuming that if you place your own icon.svg in the root of the directory it's not being used?
<cloudgur_> If I build the charm, then manually place the icon.svg then all is good
<cloudgur_> Was hoping the config.yaml value for the default setting would be picked up instead
<hatch> ahh ok yeah that's beyond my area of expertise :) best would probably be either mailing the juju mailing list
<hatch> or waiting for lazypower :)
<hatch> here is the juju mailing list if you aren't already on it https://lists.ubuntu.com/mailman/listinfo/juju
#juju-gui 2016-02-03
<agunturu> Trying to use JUJU for the first time. Just wanted to find if charm actions can be accessed in the JUJU UI? 
<hatch> hi agunturu 
<agunturu> Hi hatch
<hatch> They have not yet been implemented in the GUI _yet_ 
<agunturu> Ok. Thanks.
<hatch> agunturu: they are certainly on the 'to do' list - but if you wanted to be kept up to date on their progress feel free to file an issue here: https://github.com/juju/juju-gui/issues
<agunturu> Hi hatch, is it possible to list the actions and parameters for the actions using CLI?
<agunturu> I only can see the list of actions using âjuju action defined"
<hatch> agunturu: I think there is a --descritpion flag
<hatch> sorry it's been a while :)
<hatch> description
<hatch> --description
<hatch> (third time is the charm)
<agunturu> Tried that but looks like description is at the action level.
<agunturu> ubuntu@juju:~/mwc16charms/trusty/clearwater-juju$ juju action --description defined ims-a
<agunturu> juju action defined: no description available
<hatch> ahh, nope I'm not sure then sorry - you may have better luck in #juju
<hatch> oh I see you also asked there :)
<hatch> there is also the juju mailing list if no one pops in in #juju to answer your question https://lists.ubuntu.com/mailman/listinfo/juju
<hatch> OR on askubuntu :)
<agunturu> .hanks for you help. Regards
<hatch> :) np
<stokachu> anyone succesfully connected to juju 2.0 api server?
<urulama> stokachu: with gui? no, internal API changes broke GUI compatibility with latest GUI 2.0
<stokachu> yea i had to redo how our library connected with it
<stokachu> even the param keys changed name :(
<stokachu> https://github.com/Ubuntu-Solutions-Engineering/macumba/blob/jujuv2/macumba/__init__.py
<stokachu> if youre interested
<urulama> did you try it with aplha2? i am surprised that all those SetEnvironment* calls still work
<urulama> Or anything with Environment it actually
<stokachu> i actually haven't tried those environment calls yet
<stokachu> just the basic ones like status/deploy
<stokachu> with alpha2
<stokachu> currently going through all the facades and refactoring this library 
<stokachu> yea there isn't even a facade for environment anymore
<stokachu> those definitely won't work
<urulama> At least all Environment calls will get renamed to Model, also i think GetEnvironmentConstraints is now GetModelChanges ... 
<urulama> and EnvironmentManager is renamed to ModelManager
<stokachu> i see the ModelManager facade but not one for Model
<stokachu> there is a Controller one
<urulama> it's best if you ping on juju-dev channel and get them help you with the migration to v2
