#juju-gui 2013-02-18
<bac> morning euro friends
<bac> hi rogpeppe, would you have time to chat with me a little later?  i've got questions about the code organization and would like a bit of a walk through.
<rogpeppe> bac: definitely. give us a ping whenever you like
<rogpeppe> bac: we've got a meeting at 1500 UTC but that's all
<bac> rogpeppe: ok.  will you be breaking for lunch soon?  perhaps after that.
<bac> would give me time to collect my wits
<rogpeppe> bac: ok
<frankban> bac: morning, we have the usual problem: http://uistage.jujucharms.com:8080/juju-ui/assets/config.js
<bac> frankban: ok, i'll fix it
<frankban> bac: thanks
<bac> frankban: should be happy now
<bac> changes to config files *really* need to be QA'd b/c they will always break
<bac> frankban: which is exactly what you did!  :)
<rogpeppe> pwd
<bac> rogpeppe: i'd like to chat whenever you have time.
<rogpeppe> bac: https://plus.google.com/hangouts/_/3800a86edfc819420b2e9db27716e96b94774682?authuser=0&hl=en-GB
<rogpeppe> bac: is that link working for you?
<hazmat> bac, ping
<hatch> good morning
<bac> hazmat: ping
<bac> rogpeppe: sorry, i didn't get the alert
<rogpeppe> bac: can't you join the hangout?
<gary_poster> frankban, teknico, bcsaller_ hatch please put your travel details on this page once you have them (and if you don't have tickets already, please get them today!)
<gary_poster> https://wiki.canonical.com/CDO/Sprints/JujuEcosystemSprintMarch13
 * gary_poster not really here
<hatch> yep Ill call this morning - although I think it's a holiday in US and Canada today
<teknico> gary_poster not really here, travel agency reply in right now :-)
<gary_poster> teknico, :-) cool thanks
<hatch> I'm assuming there will be no standup this am?
<gary_poster> hatch usually there is, I think/hope ;-).  People will mutter about it as the time approaches, I suspect.
<hatch> sounds like a plan - I've almost caught up with all the emails and now trying to follow the namespace routing thread
 * gary_poster disappears.  ttyl
<hatch> cya
<bcsaller_> gary_poster: travel plans should be on the last email iteration now, I'll post when I have confirmation
<hatch> jujugui anyone have anything to chat about in the call in 3?
<bac> not really
<teknico> hatch, not really, no
<hazmat> cool, let's pass then, we're down half
<bac> sounds good
<bac> teknico: can you paste something funny/lighthearted here so we don't miss out?
<teknico> bac, :-D
<goodspud> Is fine with me
<teknico> bac, not very funny but true: on the Montreal sprint frankban and I managed to slash 3Kâ¬ from the travel prices BTS (the European travel agency) originally proposed
<teknico> this time it looks like we're not going to save more than 1K
<bac> wow, that's some slashing!  did you do it by booking directly?
<hatch> hah that's still pretty substancial
<hazmat> jujugui speaking of travel don't forget to book your travel
<teknico> bac, no, I just double-checked their proposals, and bothered them enough :-)
<hatch> just to confirm when we say 4-8 that's the landed days? so we fly in 3rd and leave the 9th?
<frankban> hatch: I think so.
<hatch> google flights are too cool, they even tell you when your flights include wifi
<hatch> or have it available
<hatch> if you haven't seen it yet http://www.google.com/flights
<frankban> rogpeppe: hi, how to deploy a local charm with juju-core? using --repository and local:charm-name I get this error: error: cannot get latest charm revision: no charms found matching "local:precise/juju-gui"
<rogpeppe> frankban: hmm, it *should* work
<rogpeppe> frankban: what does your charm dir structure look like?
<frankban> rogpeppe: http://pastebin.ubuntu.com/1677738/
<rogpeppe> frankban: it may be we have a problem with the symlinks
<rogpeppe> frankban: could you try it with a dir structure with no symlinks?
<frankban> rogpeppe: sure
<teknico> hatch, thanks, but: "Sorry, flights from Italy are not currently supported."
<hatch> aww darn!
<teknico> uhm, it supports flights *to* italy though
<frankban> rogpeppe: without symlinks it works, thanks.
<rogpeppe> frankban: ok, cool. does the symlink version work with python juju?
<frankban> rogpeppe: yes, it does
<rogpeppe> frankban: probably worth raising a bug then
<hatch> guihelp - anyone around that can explain to me the usecase behind this namespace routing before I submit my comments on the merge?
<frankban> rogpeppe: yes, I'll do it.
<bcsaller_> hatch: yeah, want to talk about it
<hatch> yeah meet in the boardroom?
<bcsaller_> hatch: in hangout
<hatch> oh cool you can get a dell xps 13 with ubuntu now
<hatch> the best part about it is that you can get it in a higher resolution display than the windows version
<frankban> rogpeppe: filed bug 1129319
<_mup_> Bug #1129319: Local charm deployment not working if symlinks are used <juju-core:New> < https://launchpad.net/bugs/1129319 >
<rogpeppe> frankban: thanks a lot
<rogpeppe> here's a dilemma: is it ethical to ask the company to pay 400 quid more for a flight so that i can get 4 hours sleep rather than none... ?
<hatch> are you worth 400 quid more after 4h sleep?
<hatch> ;)
<rogpeppe> hatch: probably :-)
<rogpeppe> hatch: not to mention the greater likelihood of me missing a connection
<hatch> hah, ok my verdict is that, ethically, it's ok to ask ;)
<hatch> this is comign from the guy who started last week...so my word might be worth nothing haha
<rogpeppe> hatch: :-)
<hatch> how does the per diem usually work? Do I need to get a company CC or do I just put it on my own then expense them?
<hazmat> hatch, own and expense
<hazmat> hatch, breakfast and lunch provided typically, so its just dinner 
<hazmat> typically one at least one team diner
<hatch> sounds good to me
<hatch> bcsaller_: if we do plan on releasing this router code back to YUI it will need almost a complete rewrite to be accepted as it needs to follow the YUI code structure and functional back to IE6
<hatch> be functional*
<hatch> I can make a note in the code review if you feel that's important
<hazmat> hatch, ie6... i thought yui gave up on that
<hazmat> if not then.. perhaps the case should be made.
<hatch> negative - they just restructured the 'Graded Browser Support'
<hatch> yahoo still has around 5% of their users on IE6
<hatch> although it's dropping
<hatch> honestly getting this routing code to work in IE6 would be as easy as switching the ES5 code to use YUI polyfills
<hatch> but there are still code structure changes required before they would accept the pull request
<hatch> polyfills.....wrapper methods....
<hatch> although with that said for them to accept it it would have to be agreed on by the community so it might be a better fit in the gallery
<hatch> I can help navigate the community and procedures if we decide we want to put the effort in going that route
<hatch> I'll add the note to the review just so that we have it recorded somewhere
<hazmat> hatch, my experiences getting patches upstream into yui has been fairly negative.. in terms of time and effort, and the long wait till action
<hazmat> hatch, i'm game to try and but we need to be realistic about time boxing it
<hatch> yeah they have made a lot of steps towards speeding up the process but of course any changes need to fit in with the rest of the library
<hatch> our best bet might be to put it in the gallery
<hatch> and then at that point decide if it is worth going any further
<hatch> hazmat: just FYI - there is going to be a continous drive to remove the 'gallery-' from modules and move as many modules from 'core' into the gallery to leave the 'core' just a framework
<hatch> it's some time away still but that's the end goal
<hatch> on a recent pull of trunk when I attempt to make devel I get an EPERM error during the grunt node install
<hatch> sry permissions issues again
<hatch> well once I solved those I'm getting an error on spritegen
<hatch> make: node_modules/grunt/bin/grunt: Command not found
<hatch> were there any changes to trunk recently that would cause that?
<hatch> looks like grunt has released a new version which might be the issue
<hatch> our package.json only specifies a minimum version
<hatch> yup
<hatch> jujugui - bug 1129464
<_mup_> Bug #1129464: 0.4.x grunt branch breaks all builds <juju-gui:New> < https://launchpad.net/bugs/1129464 >
#juju-gui 2013-02-19
<frankban> rogpeppe: good morning. today I am encountering this failure in the ws auth process: {"Response":"","Error":"machine Login not found"}
<rogpeppe> frankban: hiya
<rogpeppe> frankban:  what request message are you sending?
<frankban> {'RequestId': 1, 'Type': 'Admin', 'Request': 'Login', 'Params': {'EntityName': 'user-admin', 'Password': 'iperuranio'}
<frankban> rogpeppe: ^^^^
<rogpeppe> frankban: hmm, weird
<rogpeppe> frankban: i'll just finish submitting the branch i'm doing, then i'll have a look
<frankban> rogpeppe: great, thanks!
<rogpeppe> frankban: right, branches submitted. will have a look now.
<rogpeppe> frankban: how are you running the API server?
<frankban> rogpeppe: I am connecting to the bootstrap node of a bootstrapped juju env
<rogpeppe> frankban: ah, ok. i wonder if you could try bootstrapping (with --upload-tools) from this branch: lp:~rogpeppe/juju-core/225-api-log-messages
<frankban> rogpeppe: aha! is --upload-tools required?
<rogpeppe> frankban: if you don't use --upload-tools, it'll use the binary that's in the cloud
<rogpeppe> frankban: that is probably the problem then
<frankban> rogpeppe: ack. so, can I bootstrap from trunk or your branch is still required?
<rogpeppe> frankban: no, try bootstrapping from trunk. that should work.
<rogpeppe> frankban: in theory :-)
<frankban> rogpeppe: thanks, do you have a min for two other questions?
<rogpeppe> frankban: sure
<frankban> rogpeppe: what's, in your opinion, the best way for a charm (to be deployed in a gojuju env) to:
<frankban> 1) obtain the bootstrap node address (in particular, the API ws url): I've seen there are some yaml files around where that value is stored
<frankban> 2) check the type of the juju env (go vs python)
<frankban> rogpeppe: ^^^
<rogpeppe> frankban: good questions both
<rogpeppe> frankban: the answers will probably change over time
<rogpeppe> frankban: but for the time being, the answer is probably to look in the config file read by the machine agent
<frankban> rogpeppe: our world is moving ;-)
<rogpeppe> frankban: which can be found in .... let me check
<frankban> rogpeppe: maybe /var/lib/juju/agents/machine-X/agent.conf?
<rogpeppe> frankban: /var/lib/juju/agents/machine-*/agent.conf
<rogpeppe> frankban: snap!
<rogpeppe> frankban: which is a yaml file
<frankban> rogpeppe: yes, cool, so I only need to figure out the number of the current machine
<rogpeppe> frankban: if that file exists, it's go juju
<frankban> rogpeppe: sweet ;-)
<rogpeppe> frankban: there should only be one machine-* directory
<frankban> rogpeppe: makes sense, thank you
<rogpeppe> frankban: presumably you want to find out the address of the API server?
<frankban> rogpeppe: yes, apiinfo/addrs[0] I guess
<rogpeppe> frankban: yes, that's the one
<rogpeppe> frankban: although in the future it will a) change and b) become more than one address, so maybe choose a random address from apiinfo/addrs, or try them in sequence until you succeed.
<frankban> rogpeppe: ack, thanks again
<rogpeppe> frankban: np; any time.
<gary_poster> frankban, could you please double check my understanding of the backlog above by reading/editing the last bullet point from https://docs.google.com/a/canonical.com/document/d/1OEOzDu9lh4ko8oSgl_tjQlk98x_rgtiiSSJYBRopic8/edit ?
<gary_poster> and hi btw :-)
<frankban> hi gary_poster: that's also my understanding
<gary_poster> cool frankban thanks
<frankban> gary_poster: welcome
 * frankban lunches
<benji> bac: what is the news on the API front?  (I'm trying to remember, did you work yesterday?)
<bac> benji: i did
<bac> benji: want to g+ in a few minutes?
<benji> sure
<rogpeppe> bac, benji: if you want some input from me, just say the word
<bac> rogpeppe: thanks.  i'm sure we will
<benji> rogpeppe: cool, thanks; we may do that once we have synced up
<rogpeppe> bac: i'm just putting together the example state/cmd branch.
<bac> rogpeppe: cool
<rogpeppe> actually, i've decided it's better named state/statecmd
<hatch> good morning
<gary_poster> rmorning
<benji> frankban: how did you solve the "error: use of closed network connection" error when destroying an environment?
<gary_poster> teknico, frankban how are plane flights coming?  ok, or problems?
<frankban> gary_poster: we confirmed the flights, waiting for the tickets
<gary_poster> cool frankban 
<frankban> benji: not sure, killed ec2 instances manually. I was then able to bootstrap juju arbitrary changing the control bucket
<benji> frankban: thanks (unfortunately, I don't actually have any running, I wonder if the control bucket is messed up)
<gary_poster> hatch, what are you working on?  That grunt bug would be great to have addressed if it is not already, and should be super fast.  You are blocked on cards atm, so you could also consider the YUI app panel work.  Ben had some thoughts on that so I'd like for you two to have a conversation about that before you start, either with me participating (preferred) or with me getting a summary of the result (fine, if that's t
<gary_poster> he most convenient)
<benji> frankban: that was it, I specified a new control bucket and it worked; I guess reusing a py-juju control bucket confuses go-juju
<gary_poster> the grunt is stop the line though, so someone should address that
<frankban> benji: agreed
<bcsaller_> gary_poster: isn't that error related to what Kapil, Matt and I talked about wrt upping the inotify watch limit? or is it something else?
<bcsaller_>  cat /etc/sysctl.d/10-inotify.conf 
<bcsaller_> # expand inotify limit 
<bcsaller_> fs.inotify.max_user_watches=16384
<gary_poster> benji, could you write down what you just learned in https://docs.google.com/a/canonical.com/document/d/1OEOzDu9lh4ko8oSgl_tjQlk98x_rgtiiSSJYBRopic8/edit please ?
<benji> gary_poster: sure
<gary_poster> thanks
<frankban> gary_poster: re flights, we need to know the hotel address in order to update/compile the ESTA to enter the US.
<gary_poster> ack frankban: hazmat, ^^^
<gary_poster> bcsaller_, https://bugs.launchpad.net/juju-gui/+bug/1129464 ?  Did not make connection.  If that's the solution could you or hatch update the bug?
<_mup_> Bug #1129464: 0.4.x grunt branch breaks all builds <juju-gui:Triaged> < https://launchpad.net/bugs/1129464 >
<gary_poster> Need to run to school to take son from dr.  back in 20
<bcsaller_> gary_poster: I'll add a comment, I think its related 
<benji> gary_poster: notes added
<hatch> gary_poster: yep I can fix that - is everyone ok with me restricting the version of grunt?
<hatch> bcsaller_: sorry which error did I post to irc? I was kind of talking to myself while I was tracking it down
<hatch> heh
<bcsaller_> hatch: related to EMFILE error when using fs.watch on many items iirc
<hatch> ohhh yeah ok :)
<hatch> ok working on the grunt bug
<gary_poster> thanks hatch.  I will add a critical card for you on kanban board
<gary_poster> done
<gary_poster> bac benji dragging your card to prototype (?)
<gary_poster> which command are you doing?
<bac> gary_poster: juju get
<gary_poster> cool, will note, thanks bac
<hatch> bcsaller_: just to confirm it was this error...
<hatch> fs.js:837
<hatch>     throw errnoException(errno, 'watch');
<hatch>           ^
<hatch> Error: watch ENOSPC
<benji> frankban: you succesfully bootstrapped an EC2 node using go-juju, right?  How long did it take to go from bootstrap to "juju status" working?
<bcsaller_> hatch: yeah, I think the listed workaround... works around that 
<hatch> yeah looks like I don't even have that file
<hatch> I wonder if we should add this to HACKING
<frankban> benji: right, between ~five and ten minutes before juju status returning something.
<gary_poster> hatch, bcsaller_ does moving back to grunt 0.3.x address?  IIRC, the discussion was that this was a result of a bug somewhere in the stack.  If so, it would make more sense to me to pin at 0.3.x and wait for a fix later, rather than requiring more system changes, however innocuous, in our HACKING.  All that said, I don't feel strongly about it.
<hatch> gary_poster: two separate issues
<hatch> grunt needs to be pinned back - at least for now
<gary_poster> hatch, so also occurs in 0.3.x ?
<bcsaller_> gary_poster: yes, but it needs to be pinned to 0.3
<hatch> ENOSPC error is also happening with 03.x
<gary_poster> ok hatch.  then HACKING doc is fine.  thanks hatch, bcsaller_ 
<hatch> although adding bcsaller_ 's fix doesn't appear to have solved the issue....investigting further
<bcsaller_> the change to 0.4 will be its own story and should be deferred until the community has changed to the new api, for example spritgen might not work on .4 yet
<hatch> rumor has it the community is pissed that the api has changed so dramatically
<hatch> the community is a fickle bunch
<bcsaller_> on a dot release, yeah
<hatch> ;)
 * gary_poster thinks perhaps 0.x releases are an attractive nuisance for devs.  they seem to imply to people working on the package that backward incompatible changes are ok, but for users that's never ok, or they expect something bigger than a dot release even of the series is 0.x.
<gary_poster> s/even of/even if/
<hatch> bcsaller_: https://github.com/jashkenas/coffee-script/issues/2016#issuecomment-7499441 here is another possible fix, trying now
<bcsaller_> hatch: conceptually the same fix
<hatch> hmm, was I supposed to do something after creating that file you mentioned?
<bcsaller_> you'd have to refresh sysctl or reboot, but yeah
<hatch> oh well that's what I forgot
<hatch> sorry coffee hasn't kicked in
<hatch> heh
<hatch> hmm
<hatch> no luck
<hatch> I'll try a reboot
<benji> anyone seen this one?  "juju status" --> "panic: runtime error: invalid memory address or nil pointer dereference" plus lots and lots of other output
<gary_poster> that looks fun :-/
<hatch> reboot solved it, I'll add to the hacking file with this fix
<gary_poster> thanks hatch.  of course, reboot may have also simply closed some open file handles...
<gary_poster> but not worrying about it atm :-)
<hatch> lol
<teknico> benji, seen that one too
 * benji waits with bated breath.
<teknico> benji, no easy fix :-)
<teknico> the traceback had lots of memory addresses, no identifiers
<benji> any hard fixes? ;)
<teknico> I'm starting to have second thoughts :-/
<teknico> benji, tried again and it worked, no idea why
<benji> hmm
<hatch> gary_poster: you were correct...
<gary_poster> hatch :-(
<hatch> at least rebooting vm's is really really fast
<hatch> :)
<hatch> well a couple reboots and it finally stuck
<hatch> cat /proc/sys/fs/inotify/max_user_watches
<hatch> 16384
<hatch> not sure why it didn't work previously
<hatch> I like the new loading indicator
<gary_poster> me too.  Yay goodspud, greg and benji!
<hatch> yay!
<goodspud> Yay!
<hatch> it should say "Connecting to..." not "Trying to connect.." though.....think positive!!!
<hatch> :P
<gary_poster> heh
<hatch> lol
<benji> Yay!  (why are we cheering?)
<hatch> obviously because you rock
<gary_poster> because we like the new loading indicator
<goodspud> Yay!
<gary_poster> And some people just like cheering :-)
<goodspud> Yay for cheering!
<Makyo> Hooray us!
<gary_poster> lol
<hatch> haha
<gary_poster> jujugui call in 2
<gary_poster> bac hazmat starting without you
<benji> 2013/02/19 15:37:03 JUJU environs/ec2: opening environment "ec2"
<benji> 2013/02/19 15:37:04 JUJU environs/ec2: waiting for DNS name(s) of state server instances [i-92cb0ae1]
<benji> 2013/02/19 15:37:05 JUJU state: opening state; mongo addresses: ["ec2-50-19-23-159.compute-1.amazonaws.com:37017"]; entity ""
<benji> 2013/02/19 15:37:05 JUJU state: connecting to 50.19.23.159:37017
<benji> oops, wrong chan
<benji> 2013/02/19 15:37:05 JUJU state: connection failed: dial tcp 50.19.23.159:37017: connection refused
<frankban> benji: my go env: http://pastebin.ubuntu.com/1682925/
<bac> hatch: could you link your branch to bug in LP?
<hatch> doh
<hatch> sorry one second
<benji> Makyo: "Delete cookies and other site and plug-in data"
<hatch> bac did that work? I had to use --unchanged but I'm not sure if it actually pushed anything
<bac> hatch: you can also do it on the web site
<hatch> ok I'll do that
<bac> hatch: not linked here: https://bugs.launchpad.net/juju-gui/+bug/1129464
<_mup_> Bug #1129464: 0.4.x grunt branch breaks all builds <juju-gui:Triaged by hatch> < https://launchpad.net/bugs/1129464 >
 * bac i *thought* lbox did it for you...
<hatch> ok it's now linked
<hatch> bcsaller_: did you want to chat?
<bcsaller_> hatch: yeah, let's see if the chat opened back up
<bcsaller_> it didn't, I can open another
<hatch> sure, just invite me on G+
<hatch> new webcam hopefully arrives today so I don't need to switch computers all the time :)
<bac> benji: i'm going to grab lunch
<benji> bac: k
<bcsaller_> gary_poster: are you free to join this call on the panel?
<gary_poster> yes bcsaller_ thanks.  where?
<bcsaller_> gary_poster: should have an invite 
<benji> bac: ok, I'm going to upgrade my development machine now.  If you weren't following the discussion in juju-dev, you may need to do the same for the VM you are using 
<teknico> benji, you still there? :-)
<benji> teknico: yep (this iso download is kinda slow)
<teknico> benji, here's a 32bit SSL MongoDb package: https://launchpad.net/~julian-edwards/+archive/mongodb/+packages
<teknico> SSL-enabled
<benji> teknico: thanks.  I don't think that helps though, I need the cloud-init script to know that it exists and download and install it
<benji> and even if that were the case, I strongly suspect that this sort of thing is going to come up again; I need to be on the same platform as the juju-core developers.
<teknico> benji, yep, I'm going to install 64bit too at some point (and bac might want too)
<teknico> benji, is there a way to upgrade from 32 to 64bit without reinstalling?
<benji> not that I know of
<benji> if the install CD offers me the choice I'll give it a try 
<teknico> benji, what's the "cloud-init script" btw?
<teknico> (I think I'll need more than 4GB of RAM to have a workable 64 bit dev. env.)
<benji> It is the code that gets run when a fresh node is started.  I don't know much about it.
<benji> I only have 4GB so I hope that won't be a problem.
<rogpeppe> benji, bac, gary_poster, teknico, anyone else: here's the first of two branches that will implement the juju set command in the API.
<rogpeppe> https://codereview.appspot.com/7326052
<benji> rogpeppe: cool; thanks
<gary_poster> ack will look soon thank you
<rogpeppe> this one just factors out the code
<rogpeppe> the next one will add the call to the API
<rogpeppe> unfortunately there were one or two things that needed fixing along the way, so the factorization is perhaps not quite as clear as it could be
<rogpeppe> but hopefully it shows the way nonetheless
<benji> ok guys, I'll be back in a while... hopefully
<hatch> interesting parallels note - you need to have at least as much HD space free as you have specified for RAM for the VM
<hatch> gary_poster: fyi - I left `sudo sysctl -p` out because it didn't appear to do anything on my system
<hatch> is it possible there are any other flags required?
<gary_poster> hatch AIUI it worked for bcsaller_ and is supposed to work generally.  I suggest including it and then mentioning that it has not worked in some cases, and if problems are encountered a reboot should do the trivk
<gary_poster> c
<hatch> sounds good
<rogpeppe> teknico: any guesses as to which of those packages contains the i386 files i'm after? none of them look big enough (the binary size of the amd64 archive is ~40MB)
<teknico> rogpeppe, I installed the four i386 packages, ~30MB overall
<rogpeppe> teknico: i can't use apt-get because i'm not on the right architecture
<rogpeppe> teknico: currently i'm unpacking the .deb files directly
<rogpeppe> teknico: but i'm not sure if that's the right thing to do
<teknico> rogpeppe, there probably other actions performed by the install scripts in the packages
<hatch> does `lbox submit` push as well? or do I need to propose -cr first?
<rogpeppe> hatch: yeah, it does push
<hatch> thx
<rogpeppe> teknico: maybe. juju seems to make do ok with just using the binaries directly
<teknico> rogpeppe, how is the SSL server certificate generated?
<rogpeppe> teknico: by juju bootstrap
<teknico> rogpeppe, we got an interesting error in firefox after reboostrapping:
<teknico> Your certificate contains the same serial number as another certificate issued by the certificate authority.  Please get a new certificate containing a unique serial number.
<rogpeppe> teknico: ha ha. ok, i guess i should make the serial number more unique
<rogpeppe> teknico: please file a bug
<teknico> rogpeppe, will do
<teknico> rogpeppe, https://bugs.launchpad.net/juju-core/+bug/1130255
<_mup_> Bug #1130255: Invalid SSL certificate after rebootstrapping <juju-core:New> < https://launchpad.net/bugs/1130255 >
<rogpeppe> teknico: thanks!
<gary_poster> frankban, teknico, did you see the hotel email?
<frankban> gary_poster: yes, cool
<gary_poster> great
<teknico> gary_poster, yep, thanks, adding the flight details to the wiki now
<gary_poster> great thanks teknico
<hatch> gary_poster: who do I email this link to? juju-gui-peeps?
<gary_poster> hatch, whatchoo talkinbout?
<hatch> the sub application development outline
<gary_poster> hatch, oh!  nah, juju-gui (public)
<gary_poster> thanks
<hatch> I don't think I have that email :)
<hatch> it's probably a list i should be on though
<gary_poster> hatch, https://lists.ubuntu.com/mailman/listinfo/juju-gui : juju-gui@lists.ubuntu.com
<hatch> thanks
<hatch> gary_poster: you might need to approve my sub request
<hatch> I haven't received the confirmation email yet
<gary_poster> hatch don't think so bu twill check
<hatch> andddd there it is
<hatch> lol sorry
<gary_poster> :-) np
<hatch> ok link sent
<gary_poster> hatch could you make editable pls?
<hatch> hmm
 * hatch googles how to make editable
<gary_poster> hatch, share
<gary_poster> top-right button
<hatch> done
<hatch> sorry I didn't see the 'see' not 'edit' part
<gary_poster> cool thanks hatch.  Do you want edits or comments?
<gary_poster> Easier to see edits but then you have to integrate
<gary_poster> I mean easier to see comments
<gary_poster> but then you have to integrate
<hatch> umm lets to comments, I think it's easier for people to see then
<gary_poster> cool
<hatch> do*
<hatch> hmm, did I write any part of this doc correctly? lol!!
<gary_poster> hatch, you did write big chunks of it correctly!  I'm an editor, sorry.  A lot of the stuff I added was correction.
 * gary_poster needs some lunch
<gary_poster> hatch I meant that a lot of the stuff I added was clarification
 * gary_poster needs some lunch in order to clear his head :-P
<rogpeppe> bac, gary_poster: here's the second part of the "juju set" change, that actually exposes the functionality in the API
<rogpeppe> https://codereview.appspot.com/7305101
<rogpeppe> hopefully that will work as a reasonable example.
<bac> rogpeppe: thanks
<rogpeppe> i'm off for the day now, have a good r.o.d. all
<hatch> gary_poster: haha that's fine :) I'll just take lunch now and then I'll add the changes you commented
<Guest29269> I'm alive!
<hatch> phew!
 * benji pulls off the slimy goo that accompanies reincarnation via a celestial portal
<hatch> I always envision reincarnation on demand to be more like those little pods in the Matrix
<hatch> although it probably woudln't dump you into a sewer after
<hatch> that would kind of defeat the purpose
<hatch> ;)
<benji> heh
<hatch> gary_poster: whenever you return - I have updated the document and left comment replies where more clarifiation is required
<bac> well, benji's reincarnation didn't last long.
<hatch> looks like the sewer got him
<bac> so benji you all shiny 64 bit?
<benji> bac: yep; many little things to fix though.  For example, no system beep so I can't hear when people talk to me on IRC
<bac> oy
<bac> yeah, i've spun up a new vm
<benji> oddly, alt-tab doesn't work either; that's a new one
<bac> for some reason i wrongly thought vmware only supported 32bit
<benji> have you been able to bootstrap an environment?
<benji> (I haven't even tried yet, still getting this thing into a usable state.)
<bac> benji: still getting stuff
 * gary_poster not back yet
<bac> i'm surprised i was able to torrent an ISO as quickly as i did
 * bac hearts having a subset of /home/bac in a bzr branch for easy replication...
<gary_poster> bcsaller_, hatch I have to watch the tablet video and then I can have a call anytime :-)
<hatch> tablet video?
<gary_poster> hatch http://www.ubuntu.com/devices/tablet
 * hatch watching video
<hatch> wow
<hatch> "take my money!!"
<hazmat> guihelp is there a cause for the gui just showing up blank ala http://i.imagebanana.com/img/bx7q184n/Selection_001.png
<hatch> hazmat: that happened to me before when it coudln't connect the websockets
<hatch> a quick restart of the servers and it hasn't happened since
<benji> hazmat: I don't have any particular knowlege of that happening, but it looks like the background that we use to hide the app while logging in/connecting isn't getting hidden
<gary_poster> hazmat, yes, what hatch says.  If we make a release, message on screen now says that
<gary_poster> hazmat, suggest looking at network tab.  I bet they will see ws requests failing to connect over and oevr again
<gary_poster> hatch, bcsaller_ no rush but let's meet in juju gui when you are available
<hatch> Ready when you are
<bcsaller_> joining now
<bac> benji: have you gotten your juju-core environment back up?
<benji> bac: very nearly, but I am about to knock off for the day (I didn't take lunch today because of all this)
<bac> benji: i'm trying to install juju-core and getting:
<bac> bac@quantal64:~$ go install -v launchpad.net/juju-core/...
<bac> work/src/launchpad.net/juju-core/state/api/apiserver.go:4:2: import "code.google.com/p/go.net/websocket": cannot find package
<bac> this is with a fresh juju-core trunk
<benji> hmm, no idea
<gary_poster> bcsaller_, hatch, everything resolved and the world is a beautiful place?
<hatch> rainbows and butterflys
<hatch> I'm just reading the D3 module doc/code to see how we can reuse it like bcsaller_ mentioned
<gary_poster> ok cool hatch thanks
<gary_poster> bac or benji, I want to contact Roger about the details about the pyJuju/Go Juju interaction issues.  Could either of you supply them for me?  I think you said that you had to change your bucket name?
<benji> gary_poster: right, I just tacked "-go" on to the end of the previous bucket name; Brad did something similar
<gary_poster> benji, control-bucket in environments.yaml?
<benji> gary_poster: yep
<bac> gary_poster: yes, in environment.yaml you have to make the bucket name different from the one used by pyjuju
<gary_poster> benji, bac, cool thank you both 
<bac> gary_poster: yep
<gary_poster> yep
<gary_poster> benji bac, sorry one more thing.  what's the error symptom?
<benji> gary_poster: I put a copy of the error in that google doc you pointed me at
<gary_poster> oh cool! thanks benji
<bac> benji: i'd forgotten to install hg and git.  'go get' silently fails and that's why the packages were not found.
<benji> heh
<benji> bac: yay!  I have a bootstrapped environment!
<bac> it's one thing to let you shoot yourself in the foot but another to plant land mines.
<bac> benji: yay.  i will before the eod
<benji> heh, yeah
<bac> that said, i'm breaking to walk the dog
<benji> I'm going to stop on that positive note.  See you all tomorrow.
<gary_poster> See you
<gary_poster> Makyo, bcsaller_, hatch, two of us should review Nicola and Francesco's branch https://codereview.appspot.com/7301105/ .  I'll take one, but then we need another.  (If we get two volunteers I'll happily give up my spot ;-) ).  Could at least one of you review their branch before EoD?
<bcsaller_> gary_poster: I'll look at it now
<gary_poster> I'll be responsible for QA, unless Makyo has a GoJuju environment ready
<gary_poster> ok thank you bcsaller
<Makyo> No gojuju yet, sorry :/
<gary_poster> s'ok
<hatch> I don't think I have Go running
<gary_poster> Go is only a deb away
<hatch> I can put some time into it though if you need
<gary_poster> but GoJuju is more involved.  Naah, s'ok hatch.  hatch, let's talk tomorrow morning about timeline for what you are tackling with the app, and whether we can divide it up.
<gary_poster> but meanwhile, explore :-)
<hatch> sure thing - I've read through the d3 component docs and code and now I'm reading through the Y.App.Base code
<hatch> I think Y.App.Base provides us with what we need already
<gary_poster> cool
<Makyo> re: the sub-application aspect?
<gary_poster> yes, Makyo 
<Makyo> gary_poster, Ah, rock on.
<gary_poster> :-)
<gary_poster> I suspected but did not have proof that 'lgtm' as 'not lgtm' are actually official rietveld signals
<gary_poster> but now I see http://code.google.com/p/rietveld/source/detail?r=756dc683ac1060be54e23e6f913b258ffd1582b8
<gary_poster> I'll suggest we change to these codes
<hatch> gary_poster: bcsaller_: can you check the 'coding' section of the google doc - I feel that these are the steps that we need to take - everything else is handled automatically by the core YUI code
<gary_poster> hatch only one other comment, but +1 generally
<hatch> GREAT
<hatch> oops
<hatch> :)
<gary_poster> :-)
<bcsaller_> hatch: so does that imply you'd rather not base it on the component framework?
<hatch> yep - and the only reason is that Y.App.Base has almost everything we need with the exception of the couple additions I mentioned - but maintains a consistant api for working and interacting with views like you normally would
<hatch> things like 'showView', app container event bubbling
<hatch> 'createView'
<hatch> 'activeView'
<hatch> these are things that will be benneficial as the complexity of these sub apps will (no doubt) grow into
<bcsaller_> activeView is a little sketchy in the namespaced world anyway
<hatch> it will be the active view of the sub app
<hatch> if we extend Y.App.Base then we can pass it to anyone and point them to the YUI api (with a few additions) and they can get up to speed really quick
<hatch> the only reason we have to disable router and pjax in the first place is because Y.App was never built with sub views in mind -> I'll probably work on a core patch at some point to split that out
#juju-gui 2013-02-20
<rogpeppe> bac: ping
<bac> hi rogpeppe
<rogpeppe> bac: we've just been debating the yaml parameter to the service set command
<bac> rogpeppe: i *just* got my new 64 bit environment to work and successfully bootstrapped.  was just starting to look at your work from yesterday.
<rogpeppe> bac: how important is it to the gui that the user be able to enter yaml parameters
<rogpeppe> bac: cool!
<bac> rogpeppe: quite important for us to support the upload of a service configuration file
<bac> rogpeppe: the UX guys have spent a lot of time getting the design of the file upload right in the GUI so i know they consider it very important
<rogpeppe> bac: ok, that's useful, thanks
<bac> np
<Guest47530> hmm, all of my windows have gone black and white, that's a new one
 * benji reboots.
<gary_poster> Hi therve.  Thanks for the mail.  The duplication that you eliminated is in the annotations alone, right?  The resulting URLs are essentially untouched.  That is, a service URL is https://host/account/standalone/computers/criteria/environment:env_uuid+service:service0 and a unit URL is https://host/account/standalone/computers/criteria/environment:env_uuid+unit:service0%02F0 
<therve> gary_poster, correct
<therve> the value for environment: changed too
<gary_poster> therve, just because of the UUID instead of the internal name, right?  In terms of assembling URLs from the annotations, the pattern is the same
<gary_poster> (and the size of the annotation)
<therve> gary_poster, yep that's right
<gary_poster> Cool, sounds good therve.  Thanks.
<therve> no problem, thank you!
<gary_poster> bcsaller_, morning.  I'll re-review your TARDIS branch in just a few.  Meanwhile, though, for your other active card, the ground shifted slightly beneath you.  I don't think it should be too bad to adjust, hopefully.  Could you take a look at the first comment in https://bugs.launchpad.net/juju-gui/+bug/1126249 and let me know if you have any questions or concerns?
<_mup_> Bug #1126249: functions/methods to calculate Landscape links for units, services, environment <juju-gui:Triaged> < https://launchpad.net/bugs/1126249 >
<bcsaller_> gary_poster: checking it now
<bcsaller_> gary_poster: I don't think there are any serious issues 
<benji> rogpeppe: the websocket is connected to port 17070, right?  I as because I am getting wierd (non-HTTP-like) results when connecting to that port
<rogpeppe> benji: yeah, i think so
<rogpeppe> benji: yes, 17070 it is
<rogpeppe> benji: and it's https (well, wss)
<gary_poster> cool bcsaller_ thanks.  Re TARDIS branch, I might propose a branch or diff with suggested doc additions.  Would that be ok?
<benji> rogpeppe: oh! maybe that's it; I didn't expect the connection to be encrypted.  Thanks, I'll look at that.
<bcsaller_> gary_poster: yeah
<gary_poster> cool
<rogpeppe> benji: cool.
<benji> rogpeppe: it worked!  thanks
<rogpeppe> benji: lovely
<gary_poster> frankban, hi.  Does charm bug 1130681 make sense to you? I have never seen this problem, so my question for him is why, or under what circumstances, does he hace /usr/lib/juju in the sys.path.  I'm assuming he means that /usr/lib is his working directory, but I don't know when that would occur
<_mup_> Bug #1130681: Import error in api service <juju-gui:New> < https://launchpad.net/bugs/1130681 >
<hatch> morning
<gary_poster> morning hatch
<frankban> gary_poster: looking
<gary_poster> thanks
<frankban> gary_poster: hum, I agree with you, we need more context on that bug
<gary_poster> ok thanks frankban I will follow up
<goodspud> gary_poster, thanks for you comments on the wires yesterday
<gary_poster> Welcome goodspud.  Maybe not helpful, but at least you know someone is still breathing on the other end of the phone :-)
<goodspud> gary_poster, :)   Any comments are helpful.... my mantra
<gary_poster> :-)
 * hatch has a very sore throat so he probably won't be talking much :/
<gary_poster> :-( take it easy
 * gary_poster has been up since 3:30 when the baby cried, so he probably won't be thinking much :-/
<hatch> uh oh!
<hatch> my mac mini ram upgrade is taking forever! to get here
 * hatch needs more rams!
<hatch> of course right after I said that it'll probably show up ;)
<gary_poster> frankban, Andreas replied.  I don't know why he would have encountered that and we have not.  I'm trying to dupe.
<frankban> gary_poster: we never tried with juju-origin: lp:juju. thanks for trying to dupe.
<gary_poster> welcome
<hatch> very cool video on google glass http://www.youtube.com/watch?v=v1uyQZNg2vE
<frankban> rogpeppe: hi, it seems gojuju's juju-log command has a different behavior (compared to pyjuju's one). please see http://pastebin.ubuntu.com/1690685/ . IIUC, '-->' is considered a flag
<rogpeppe> frankban: hmm, does pyjuju's log command accept any flags?
<frankban> rogpeppe: pyjuju accepts that command and considers '--> Entering...' to be its string content
 * rogpeppe tries to understand the python debug-log code
<frankban> rogpeppe: in other words, subprocess.call(['juju-log', '--x']) just prints '--x' in pyjuju, and raises that "flag provided but not defined" error in gojuju 
<rogpeppe> frankban: hmm, so it's different from all the other commands in that respect.
<rogpeppe> frankban: we should follow suite
<rogpeppe> suite
<rogpeppe> suit
<rogpeppe> frankban: got a call, back in a bit
<frankban> rogpeppe: sure, thanks
<benji> frankban: were you guys able to log in via the websocket API?
<frankban> benji: yes, user "user-admin", arbitrary password
<gary_poster> biab
<benji> frankban: how does the JSON document look?  Is there a branch that I can crib from?
<frankban> benji: in the future I believe the password will be the admin-secret.
<frankban> benji: juju-gui trunk, we implemented the authentication in the go environment
<benji> cool!  I'll take a look.
<bac> benji: congrats on getting the ws to talk
<benji> bac: how did you get juju-core to rebuild?
<Makyo> guihelp call?
<bac> benji: er?
<gary_poster> jujugui please have call without me.  
<Makyo> gary_poster, ack
<gary_poster> house leak and rotted subfloor yay!
<teknico> uh?
<benji> yow :(
<teknico> really?
<bcsaller_> sounds awful
<bac> benji: call?
<benji> bac: I have to install the Google video plugin first
<hatch> ugh I accidentally chowned my whole /bin dir
<bcsaller_> pwned
<hatch> yeah who feels like an idiot now....
<hatch> <---- this guy
<hatch> at least I did that on my laptop so hopefully I can boot up into debug mode (or whatever it's called) and change sudo back
<rogpeppe> frankban: actually, i believe that juju-log --x will fail in py juju too
<rogpeppe> frankban: from my experiments, if you'd done 'juju-log "-->entering"', that would fail too
<rogpeppe> frankban: but it will succeed with a space before "entering"
<rogpeppe> frankban: i have mixed feelings about whether we want to duplicate this subtle and somewhat error-prone behaviour in the Go version.
<frankban> rogpeppe: hum, weird, the juju gui charm works well in python logging "--> Enetering". anyway, we are trying to work around this issue. 
<rogpeppe> frankban: yeah, that will work, as the argument has a space in it
<rogpeppe> frankban: but "-->Entering" would have failed
<frankban> rogpeppe: but not in juju-core, right?
<rogpeppe> frankban: yeah, in juju-core too - it parses command line options like gnuflag
<rogpeppe> frankban: except maybe i missed that wrinkle
<rogpeppe> frankban: nope, it's a python argparse thing
<rogpeppe> frankban: if in doubt, you can log with juju-log -- '--> Entering'
<rogpeppe> frankban: (the -- marks the end of flag processing)
<frankban> cool rogpeppe, ok. so rogpeppe  and gary_poster: we should update the charm tools: see http://bazaar.launchpad.net/~charmers/charm-tools/trunk/view/head:/helpers/python/charmhelpers/__init__.py#L51
<frankban> for now we will just avoid calling log_entry and log_exit
<frankban> we decided to write a context manager that should allow for doing the same in a easier way
<rogpeppe> frankban: yeah. sigh, i'll raise a bug and we'll see what the right resolution is
<frankban> rogpeppe: thanks a lot
<benji> rogpeppe: how do I rebuild after modifying the code?
<rogpeppe> benji: "go test" will rebuild and run tests
<benji> % go test
<benji> can't load package: package .: no Go source files in /home/benji/workspace/juju-core/trunk
<rogpeppe> benji: you can check if something builds with "go build" (rarely used) or "go install"
<rogpeppe> benji: ah, go test ./...
<benji> % go test ./
<benji> can't load package: package .: no Go source files in /home/benji/workspace/juju-core/trunk
<benji> oh, ellipsis
<rogpeppe> benji: or if you're in the directory of the package you've changed, "go test" tests the current directory
<rogpeppe> benji: "go install ./..." will build and install everything under the current directory
<rogpeppe> benji: in general, the go command operates on the package in the current directory, but you can give it a list of package names to operate on
<benji> thanks, I was missing the ellipsis
<rogpeppe> benji: np. it's a general pattern-matching wildcard BTW
<rogpeppe> benji: try "go help packages" for more info
<benji> rogpeppe: on an unmodified trunk I get lots of errors, is that expected?
<rogpeppe> benji: nope
<rogpeppe> benji: paste?
<benji> rogpeppe: http://paste.ubuntu.com/1691147/
<rogpeppe> benji: hmm, what revision are you at?
<benji> I have no idea.  I'll update and see if anything changes.
<rogpeppe> benji: ah, i see your problem
<rogpeppe> benji: you're not using GOPATH
<benji> % echo $GOPATH
<benji> /home/benji/workspace/go
<gary_poster> frankban, ack.  looks like line 45 of http://bazaar.launchpad.net/~charmers/charm-tools/trunk/view/head:/helpers/python/charmhelpers/__init__.py#L45 would be best fix--that is, the log command should insert "--".  Do you agree?
<rogpeppe> benji: your branch should be at /home/benji/workspace/go/src/launchpad.net/juju-core
<rogpeppe> benji: not /home/benji/workspace/juju-core/trunk
<benji> % ls /home/benji/workspace/go/src/launchpad.net/juju-core
<benji> cert   cloudinit  contrib       doc         environs  LICENCE  README  schema  store    thirdparty  upstart  worker
<gary_poster> And yes, water damage from washing machine.  Laundry room and into kitchen.  We though it was seasonal expansion of boards but it is water damage.  Hopefully insurance is ok with it.
<benji> charm  cmd        CONTRIBUTING  downloader  juju      log      rpc     state   testing  trivial     version
<gary_poster> Will mean a lot of money, I expect.
<hazmat> gary_poster, ouch
<frankban> gary_poster: agreed, that should fix the problem
<gary_poster> ok cool frankban 
<gary_poster> yeah hazmat :-(
<rogpeppe> benji: what's your cwd (the directory you ran the go build command from) ?
<hazmat> gary_poster, frankban re charm... ls folks noticed some breakage if juju-origin: branch
<benji> % pwd
<benji> /home/benji/workspace/juju-core/trunk
<rogpeppe> benji: right
<rogpeppe> benji: that's not in your GOPATH
<gary_poster> hazmat, ack.  I had just determined that it was something on the branch when I had the water damage thing come up
<benji> gary_poster: yow!  I hope the insurance works out for you.  We had some water damage (but the fast kind) and our insurance payed for everything
<frankban> hazmat: bug 1130681 ?
<_mup_> Bug #1130681: Import error in api service <juju-gui:Incomplete> < https://launchpad.net/bugs/1130681 >
<gary_poster> hazmat, they filed bug ...yeah that one :-)
<gary_poster> and I have duped
<hazmat> that's the one
<gary_poster> hazmat, how is branch installed?  setuptools?
<rogpeppe> frankban: https://bugs.launchpad.net/juju-core/+bug/1130771
<_mup_> Bug #1130771: juju-log is not compatible with python version <juju-core:New> < https://launchpad.net/bugs/1130771 >
<gary_poster> that was my guess as to underlying cause for the difference when I was thinking about it
<benji> rogpeppe: same problem after adding it to my GOPATH (which now reads "/home/benji/workspace/juju-core/trunk:/home/benji/workspace/go")
<frankban> rogpeppe: thanks
<gary_poster> thanks benji.  yeah, we'll see.
<rogpeppe> benji: i suggest you read this: http://golang.org/doc/code.html
 * hazmat has been happy with GOPATH=$HOME
<rogpeppe> hazmat: yeah, i've been tempted to do that
<hazmat> rogpeppe, yeah.. i think i picked up from cheney
<benji> rogpeppe: any hints as to which parts I am confused about?
<rogpeppe> benji: all packages live somewhere in $GOPATH, under $gopathdirectory/src/$packagepath
<hazmat> bcsaller_, ie workspace/juju-core/trunk is suspect
<hazmat> whoops for that was for benji
 * hazmat curses nick completion
<rogpeppe> benji: in your case, the branch needs to be at /home/benji/workspace/go/src/launchpad.net/juju-core
<rogpeppe> benji: because your $GOPATH is /home/benji/workspace/go
<rogpeppe> benji: if you need several juju-core branches, you can use a recent version of bzr, or cobzr (i use cobzr)
<rogpeppe> benji: if you set GOPATH and do "go get launchpad.net/juju-core/cmd/juju" that will do everything for you
<rogpeppe> benji: then you can cd /home/benji/workspace/go/src/launchpad.net/juju-core, and manipulate the fetched branch at will
<rogpeppe> benji: (it sounds like you'd already done that though)
<benji> rogpeppe: I think I see where things are going astray though; thanks for the help
<rogpeppe> benji: np
<rogpeppe> benji: it's a little different to most conventions, but it works quite well.
<hazmat> its actually closer to maven/ivy from java 
<gary_poster> frankban, hazmat, mostly confirmed that the branch approach uses easy install to install juju, and that mucks with sys.path so strongly that its paths comes before PYTHONPATH.  In some more perfect world, I'd say that the right solution would be to have the branch install not use easy install.  In this world, I'm inclined to do a hack like the one Andreas described.  The working directory still comes first in the pat
<gary_poster> h, thankfully, so we can use that.
<gary_poster> I will file a comment and adjust the bug title to reflect the real problem
<frankban> gary_poster: +1, thanks
<hazmat> gary_poster, ack
<hazmat> fwiw, i added a comment noting the issue and a temporary solution for him (ie. use the ppa)
<hatch> and /bin recovered....
<hatch> note to self - pay attention when you start with `sudo chown -R` ;)
<hazmat> ouch
<hazmat> has anyone been able to run juju-core test suite without failure?
<gary_poster> hazmat I don't think so.  jujugui ^^^ ?
<gary_poster> frankban, I filed bug 1130793 fwiw
<_mup_> Bug #1130793: For safety, Python charm-helpers juju-log command should insert a "--" before the log message. <Juju Charm Tools:New> < https://launchpad.net/bugs/1130793 >
<bac> hazmat: yes, on occassion.  as of a few days ago there were some intermittent failures but it would some times run cleanly.
<frankban> gary_poster: cool, contextually we could add the other helpers we have in the gui charm
<gary_poster> hatch, thank you for filing those bugs.  please add url to doc in bug report so people can follow along
<hatch> sure thing
<gary_poster> frankban, +1! 
<hatch> bcsaller_: can I move your namespace aware from review? I need to move a ticket in there which will push it over
<bcsaller_> hatch: yes, its merged
<hatch> ok done!
<gary_poster> lunch and more water damage stuff
<benji> rogpeppe: if I were to add a method to srvClient how would I bootstrap an environment with that new method exposed via the api?
<rogpeppe> benji: use juju bootstrap --upload-tools
<benji> rogpeppe: I was afraid you would say that. :) ...because that's what I did.
<rogpeppe> benji: ah :-)
<rogpeppe> benji: could you paste your copy of apiserver.go ?
<benji> rogpeppe: when I attempt to call it I get {"RequestId":1,"Error":"no such request \"Hello\" on Client","Response":{}}
<benji> sure, one sec
<frankban> rogpeppe: does default-series work? I have precise in my yaml, but nodes are created using quantal
<rogpeppe> frankban: hmm, not sure of current status - better ask in #juju-dev
<frankban> rogpeppe: ok thanks
<benji> rogpeppe: here is the whole file: http://paste.ubuntu.com/1691354/ and here is the diff http://paste.ubuntu.com/1691355/ .  And to be clear, that is the entirety of the change I made.
<rogpeppe> benji: ah, the first argument to Hello needs to be the Hello struct
<hatch> how does the YUI version get updated? I see it's updated to pr3 already which was just released yesterday :)
<rogpeppe> benji: we'd usually name that rpcHello
<rogpeppe> benji: oops, that's what you're returning
<benji> ah, let me try that
<rogpeppe> benji: anyway, any argument needs to be a struct
<rogpeppe> benji: (if you *have* an argument)
<rogpeppe> i've got to go very soon, and i'm going to be away the next two days
<rogpeppe> i should be in sporadic contact via email
<rogpeppe> so please email me if you have any issues
<benji> rogpeppe: thanks for the help
<rogpeppe> benji: np
<rogpeppe> benji: hope it goes alright for you :-)
<benji> you and me both ;)
<rogpeppe> gary_poster: i've proposed the first branch with an API watcher in: https://codereview.appspot.com/7390043/
<hatch> Oooo new ram has arrived
<hatch> lunch
<bac> hazmat: i'm having similar build/install problems as benji.  but my GOPATH seems to be set correctly.  do you see anything funny here: http://paste.ubuntu.com/1691498/
<bac> gah, ...
<bac> nm
<hatch> Boo yeah! 16GB of ram
<hatch> VM's do your worst!
<Makyo> bcsaller_, ping
<bcsaller_> Makyo: whats up?
<Makyo> bcsaller_, have five minutes for a quick hangout?  Weird problem.
<Makyo> jujugui's open
<bcsaller_> joining
<hatch> can anyone comment on the best way to get syntax coloring in bzr status/diff  in ubuntu terminal?
<benji> hatch: I pipe them to vim so it can colorize them, like so: "bzr diff | vim -"
<benji> hatch: I just discovered "colordiff" which is apt-get installable which does what you want ("bzr diff | colordiff")
<hatch> ahh cool, doesn't do status but I can live without
<benji> hatch: "status"?
<hatch> `bzr status` show the changed files
<benji> ah, you want git-style colors for added, modified, etc?
<hatch> yeah I figure we aren't going to be switching to git so I better get bzr setup the way I like it :)
<bac> benji: what version of go are you running?
<benji> bac: "go version" says "go version go1.0.2"
<bac> benji: yeah, me too.  i had 1.0.3 on 32 bit vm but there is not build for amd64 in the PPA.  so '-u' no longer works
<bac> well, it isn't supported
<benji> hatch: you might also be interested in bzrtools which includes a "cdiff" command that is a colorized diff
<benji> bac: what does "-u" do?
<bac> it is supposed to update dependent packages
<benji> ah
<bac> gets rid of those test warnings
<bac> speeds things up
<benji> bac: ok, I can write new function (er... method... I wonder what they call these things) that can take aguments and generate responses or errors
<bac> benji: cool.  i've 'ported' the get command from the old location to the new and tests pass.  i figured i would put it up for review before wiring in the apiserver parts, similar to the flow roger did
<benji> very nice
<bac> smaller branch for the first one, fewer things to scrutinize
<bac> the tests all pass but i'm having a look now to see if they make sense
<hatch> benji: as an alias this gets me pretty close `diff = diff --diff-options -p --using colordiff`
<benji> I'm more of a -u kinda guy.
<benji> wait, -p doesn't do what I though it does.  I learned something today.
<hatch> what does -u do? :)
<hatch> I don't see it in the help
<benji> -u is "unified" format, which is the default for bzr's diff (but regular old diff has to be told to be sane)
<hatch> ahh
<hatch> that sputnik 2 laptop is pretty cool but I definitely don't need 256GB ssd and i7 :) I'd be happy to save a few hundred and drop it down to 128 and i5
<hatch> ok 16GB ram, 128GB SSD, i5
<hatch> 15" screen 8H battery life...4.5lbs
<hatch> well ok might as well add back in the 256GB SSD
<hatch> and something above 200 ppi
<hatch> ;)
<hatch> I think I just doubled the price of the computer
<benji> yow, not only does go have labled continue, the go-juju code uses it
<bac> hatch: yeah, now that they bumped up the resolution on the sputnik display it is more reasonable
<hatch> bac: yeah honestly the laptop that I want is the 15" MBP - ignoring the OS it's probably the best hardware option
 * bac won't disagree
 * bac o/
<gary_poster> Makyo, reviewed.  thank you.  Maybe hatch can give you another review. :-)
 * gary_poster must run
<hatch> I can do that
<Makyo> Thanks, gary_poster.  Have a good evening.
<hatch> Makyo: pulling it down now
<Makyo> hatch, no rush.  I've got some minors from Gary and another task besides.
<hatch> if I want to comment on a 'user experience' thing where should I put that?
<hatch> comment on [revision details] ?
<hatch> ^ jujugui
<Makyo> hatch, When you submit your comments on the review, you'll have the chance to prefix the comments with general notes and UX stuff.
<bcsaller_> You can also bring it up with nick at tomorrow's meeting and arrange for feedback
<Makyo> hatch, What bcsaller_ said, too; all our UX stuff can be made as suggestions to our UX guys; it'll have to go through them during UX check, anyway :)
<hatch> gotcha :)
<hatch> ok message sent
<Makyo> hatch, can you confirm against trunk?
<hatch> can do
<hatch> checking
<hatch> Makyo: works as expected on trunk
<hatch> sorry ;)
<Makyo> hatch, no worries, just curious, since I didn't really touch that.
<hatch> ahh - well I'll hold off on a code review then :) Should I create a bug or is the comment enough?
<Makyo> hatch, comment's enough.
<Makyo> Can do the code review if you want, will just be appended to the list of things to do.
<hatch> ok just finished
<Makyo> hatch, Thanks.  I agree about the isValue thing, but it's been standard in the past.  Maybe worth bringing up on a call?
<hatch> sure.....let the new guy take the heat!!!
<hatch> :P
 * Makyo helpful :D
<Makyo> Nah, we'll bring it up and see what we think.
<hatch> haha - sounds good
<hatch> so after using this new ram for the afternoon it appears that I can no longer run two monitors, one through the TB port and one through the HDMI - almost immediatly after plugging in the HDMI one the TB display goes black
<hatch> :/
<hatch> I wonder if the gpu is sharing memory or something
#juju-gui 2013-02-21
<benji> bac: I'm wandering around in testing infrastructure, but we should probably formulate a plan for today soonish
<bac> benji: my plan is to make the changes per review and get my branch landed
<benji> that sounds good; want to sync up after that?
<bac> then i will be an official Go programmer, a juju core contributor, and an all around badass
<hatch> morning
<bac> yes, benji, that'll be good
<hazmat> bac, they teach the secret handshake then ;-)
<bac> excellent.
<benji> bac is so awesome he doesn't call the wrong number, you answer the wrong phone
<goodspud> Bwa ha ha ha
<goodspud> Is that taken from a "Clint Eastwood" joke?
<benji> goodspud: Chuck Norris
<goodspud> benji, er yeah... that's who I meant :)
<gary_poster> :-)
<goodspud> Clint, Chuck... all the same really (don't hit me Chuck)
<benji> Clint Eastwood doens't hit people, he makes Chuck Norris do it for him.
<goodspud> Bwa ha ha ha
<teknico> bac, care to add a code review link to your card?
<bac> teknico: ok.
<teknico> bac, beat you to the punch :-)
<bac> dang
<teknico> oh, you got reviews already, ok
<bac> teknico: are you doing juju-core reviews or just curious
<bac> i have an abundance of reviews!  :)
<teknico> bac, just curious, I don't feel up to the task yet
<gary_poster> bac you available for a call with me and frankban to share your glorious go juju api command knowledge, now that you have a branch in review?
<bac> gary_poster: sure.  benji may want to join if he has time.
<bac> let me re-tea and i'll join you there?
<gary_poster> thanks bac, pm'd location
<gary_poster> you too benji
<benji> for you I'll clear my schedule
<teknico> gary_poster, ok, where's the party?
<hatch> I've noticed that some code uses camelcased and some uses understores fooBar vs foo_bar - is there a prefered method? I typically write camelcased
<hazmat> hatch, camelcased
<hazmat> hatch, we transitioned mid dev
<hatch> sounds good to me - old habits are hard to break ;)
<gary_poster> Makyo, hey.  I have more feedback for your branch--small but nice.  Trying to add it now..
<gary_poster> comment added
<Makyo> gary_poster, Thanks for the feedback.  I'm not sure I understand.  Do I need to call _navigate rather than navigate or fire('navigate')?  Where do I set the options?  Tests for those lines?
<gary_poster> Makyo, about to have call, but you would need your logout to eventually call the app navigate method with that new option
<gary_poster> Makyo, talk to you after this call or after daily?
<Makyo> gary_poster, Sure.
<gary_poster> thanks
<Makyo> Will try to coffee in the meantime, so I'm not running so slow
<Makyo> gary_poster, nvm, I get it now, was misreading Router.combine.  Will get a test in for that.
<gary_poster> cool thanks Makyo
<gary_poster> jujugui call in 2
<teknico> sorry, hangout crashed and is not starting anymore, trying again
<bac> gary_poster: branch back in review after making changes.
<bac> gary_poster: proceeding with the next branch, dependent on the first
<gary_poster> cool
<hatch> bcsaller_: have time for a chat?
<bcsaller_> hatch: sure
<hatch> in the boardroom
<hatch> if I run --fixes multiple times on a commit will that link to multiple tickets or will it blow up? :)
<gary_poster> heh, dunno hatch.  you can do it in lp though
<gary_poster> "link to bug"
<hatch> sounds good :)
<bcsaller_> I think the arg parser is last write wins
<Makyo> Have yet to use --fixes, been using -bug=xxxxxx in lbox.  That just do the same thing?
<gary_poster> different under the hood in a way you don't care about Makyo.  --fixes annotates branch in a way that LP snarfs up, and I suspect lbox uses LP API to directly communicate the connection
<gary_poster> so inetrchangeable effectively
<gary_poster> hatch are you already factoring out the namespace code into a separate module?  If have some changes--mostly but not exclusively docs--for that code as well.  It would be easier if we did not stomp on one another.
<gary_poster> s/If have/I have/
<hatch> gary_poster: I haven't touched the namespace stuff yet - I'm working on creating the subapp structure right now
<gary_poster> Great hatch.  Lemme know when you get there and we can either coordinate or maybe I will already have my changes in.
<hatch> right now my changes to app.js are going to be minimal - I'm trying to keep them all in the extension - so update away!
<gary_poster> cool thanks
<bac> hatch: let's talk soon about code reviews.  whenever convenient for you.
<hatch> can we do it after lunch? I really want to get this subapp stuff working
<gary_poster> Small simple cleanup branch for review.  bcsaller needs to look at it, and then anyone else (hi, jujugui!).  https://codereview.appspot.com/7372044/
<bac> hatch: ok
<bac> ping me
<bac> gary_poster: i'll look at it.  there is no card, right?
<gary_poster> right bac.  was a review follow-on for bcsaller's branch of some changes I wanted but didn't make it
<bcsaller_> *cough* sorry about that 
<frankban> bac: is it required to ping someone to get a juju-core review? 
<bac> frankban: i didn't and i got four!
<frankban> bac: cool!
<bac> may not hurt to ping fwreade, though
<frankban> bac: I have no rush, approaching EOD
<gary_poster> bcsaller, :-) np.  I read your reveiew, thanks.  In the current structure how does one register a namespaced route?  I assumed that you would register something for the path ":your_namespace_here:/your/path" or for something similar.  Is that it?
<gary_poster>  /:your_namespace_here:/your/path I guess
<bcsaller> gary_poster: that will work, but I think specifying it as an attr of the route definition will be better and will work the subapp stuff cleanly 
<bcsaller> The change to match is a few minutes of work, I can propose it after you land your changes 
<gary_poster> bcsaller, sounds good, thanks.
<bac> gary_poster: done
<gary_poster> Cool, thank you bac.
<gary_poster> Makyo, approved with some small changes
<gary_poster> hatch/bac, please take a look at https://codereview.appspot.com/7395043/ very soon so Makyo can land
<hatch> alright
<bac> hi benji
<benji> hey bac
<bac> i've got a branch that implements the server and client functions for the ws/rpc get command
<bac> benji: would you like to try poking at it with your ws client and see if it behaves?
<bac> benji: or show me how to?
<bac> i.e., gimme your client
<benji> bac: sure, shall we relocate to the hangout to discuss?
<bac> i'm sure others are on the edges of their seats...
<bac> but, ok
<gary_poster> I don't even have a seat!
<benji> bac: here is the code: http://paste.ubuntu.com/1700814/
<bac> benji: invited you
<hatch> the code looks good - I'll do a functionality check now
<hatch> I really hate how harddrives advertise 3TB but are really only 2.73TB ... 270GB is a lot of missing space ;)
<bac> benji: bzr push lp:~bac/juju-core/add-get-2
<benji> thanks bac
<bcsaller> gary_poster, hatch: when you have time can you check that the rules for ns route matching make sense to you in https://codereview.appspot.com/7396050/
<hatch> I must be missing something
<hatch> because it looks like it just returns true all the time :)
<hatch> that was a poorly formed joke
<hatch> and poorly executed
<hatch> bcsaller: just to verify when you said
<hatch> So /:inspector/service/mysql/ would match while
<hatch> you meant :inspector: right?
<bcsaller> yeah
<bcsaller> unfortunate typo
<hatch> revieweddd
<bac> benji: which websocket package does your script use?  the one from pip doesn't have 'create_connection'
<benji> bac: hmm, let me look
<bac> gary_poster: are we chatting in 1 min?
<gary_poster> bac, no.  I hoped we would be, but house person is here.  will ping?
<gary_poster> should be within 15 min
<bac> ok
<benji> bac: "websocket-client"
<gary_poster> bac, ready now.  joining.  you ready?
<bac> gary_poster: joining now
<gary_poster> bac https://codereview.appspot.com/7390043/
<bac> hi benji, i'm getting {"RequestId":1,"Error":"no such request \"ServiceGet\" on Client","Response":{}}
<bac> benji: is there some other registration step i might be forgetting?
<benji> bac: I didn't have to do anything for mine, let me look at your code a second
<benji> bac: the code looks good to me; did you use --upload-tools when you bootstrapped?
<gary_poster> bcsaller, that namespace-restricted route matching looks good to me.  When you prepare for landing, please do include some documentation
<gary_poster> even just comments in the routes section
<bcsaller> gary_poster: thanks, on it
<bac> benji: yes
<bac> benji: i just tried 'Status' and it works
<benji> hmm, well, that's something
<benji> bac: it might be your return signature, you should be returning a struct, not a pointer to a struct (I am far from certain that this is it, but that is the only candidate I have for what the problem might be)
<bac> hmm
<bac> ok
<bac> benji: that is why rog was returning Status{}
<bac> he had to return a struct so he couldn't return nil
<benji> that would explain it (although, I wonder why not just make the standard return signature a pointer to a struct, then returning nil is fine)
<bac> benji: well there is that
<bac> go is weird in that the caller looks the same whether it is a struct or pointer returned
<benji> yeah, that's something that I'm not sure if I like or not; not having to do the "." vs. "->" dance like in C++ is nice, but it might be confusing having the DWIM
<bac> benji: that was it!  fixed the return signature and it works.  thanks!
<benji> cool
<bac> benji: are you okay running with my add-get-2 branch?
<benji> bac: I'm ok enough to try :)  please write down my goal(s) in an email to me and I'll tackle them
<bac> benji: ok, the main thing is to figure out api_test and add relevant test for the new command
<bac> benji: writing email now
<benji> thanks
<benji> tests I think I can handle
<bac> benji: did my msgs just show up in #juju-dev?
<benji> bac: I'm not in juju-dev at the moment
<bac> my client is reporting Your message couldn't be sent to the channel
<bac> ok
<benji> I guess I should add that to my auto-join (it's just so noisy over there)
<hatch> O K lunching
<hatch> bbiab
<BradCrittenden> gary_poster: should we be added to ~gophers?  if not we cannot submit to juju-core
<gary_poster> BradCrittenden, yes we should.  I will ping mramm about it unless you tell me you are doing so
<BradCrittenden> gary_poster: he is currently on #juju-dev.
<bcsaller> hmm, lbox submit is failing for me, trying to figure out why, sorry about any noise its generating
<bac> bcsaller: how is it failing?
<bac> i got a read-only transport failure, which i attributed to not having write permission to lp:juju-core
<bcsaller> bac: http://paste.ubuntu.com/1701833/
<bcsaller> bac: sh ./.lbox.check works fine though
<bac> bcsaller: ok, unrelated
<bac> no clue as to what is happening with yours
<bcsaller> bac: thanks for looking :)
<bac> gary_poster: well, thanks for trying.  :)
<gary_poster> bac :-(
<hatch> ok!!!
<hatch> sooo
<hatch> how do I go about merging trunk into my branch?
<hatch> well the proper way of doing so
<hatch> I need to make sure I have all of the most recent routing code
<Makyo> hatch, If you're in your branch, you can do bzr merge ../../trunk or wherever your copy of trunk is
<Makyo> hatch, Make sure trunk is up to date by doing `bzr pull` in there, first.
<hatch> ahh ok that's simple enough thx
<Makyo> bcsaller, new version of jshint changed the command name, just running into that now.
<Makyo> guihelp, Newest version of jshint dies spectacularly on some of our files - namely JSON, but a few JS files it was fine with before.  Can bcsaller or I set the version in our current branch to an older one for the time being?
<gary_poster> Makyo, +1
<hatch> go for it
<hatch> although what's it barfing on?
<hatch> just curious
<Makyo> hatch, **.json, a few redefinitions across files (YUI, etc.), one instance of 'char' as a var name.  I'd like to get both bcsaller and I's branches landed (or proposed) today, so I'm proposing we drop the version for now, make a card to investigate moving to current when we've got time.
<hatch> oh yeah for sure - drop it down
<hatch> jshint isn't one that you wouldn think would all of a sudden start breaking heh
<Makyo> They just hit 1.0.0, so I'm assuming something big happened :_
<Makyo> :)
<Makyo> bcsaller, when you get back, in package.json, set jshint's version to "0.9.1" rather than ">=0.9.1"
<hatch> haha
<hatch> aww man this routes stuff is kicking my a$$
<hatch> bcsaller: is the _dispatch method in app.js a monkeypatch for the YUI one in Router?
<hatch> I now finally have all of the route parsing business done (and only 2 lines lol)
<hatch> but now it's barfing on dispatch
<hatch> bcsaller: maybe we can pair tomorrow to solve this?
<gary_poster> bcsaller, I made a review of your Landscape aggregation branch.  Please rustle up another one.
<bcsaller> hatch: yes, its overridden
<hatch> yeah I attempted to make my way through it but I think it's best if we work together on this integration part
<hatch> would that be alright?
<bcsaller> sure
<hatch> great - I figure we should be able to get it done in <1h tomorrow
<gary_poster> Makyo, appcache info: thanks! LGTM with trivials
<gary_poster> (and actually fly-bys)
<hatch> if one reviewer has comments and the next has nothing to add but agrees with reviewer 1
<hatch> what should they put? land as is? or....
<hatch> land with other changes?
<hatch> I chose "Land with Gary's trivials" :)
<hatch> has anyone ever evaluated using https://github.com/airportyh/testem ? A bunch of my local dev friends use it and really like it
<gary_poster> never hatch.  If you look at it and think it is worth incorporating into our tools you could do so and propose it some Friday or other.
<hatch> sure I can look into it
#juju-gui 2013-02-22
<bcsaller> lbox propose took 7 minutes :(
<jovan2> Morning! Considering icons for our service providers - AWS etc - does anybody know if there is an icon for LXC?
<gary_poster> jovan2, hi.  no, I do not know of one, and it looks pretty clear to me that LXC does not have an official icon.  However, hallyn or stgraber in #ubuntu-server will probably have authoritative answers, and I have asked them.  I'll report back.
<gary_poster> I was going to sat that to jovan2 but he disappeared as I was writing that :-P
<gary_poster> I'll email him
<hatch> morning
<hatch> brb gota reboot
<hatch> I've got my new webcam, are you guys pumped to see me in HD?
<hatch> I know I am!
<hatch> bcsaller: are you in yet?
<bcsaller> hatch: I am
<hatch> http://bazaar.launchpad.net/~hatch/juju-gui/1130790-create-subapp/view/head:/app/app.js#L467 and 453 have an assignment operator in the if() statements
<hatch> is this intentional or a typo?
<bcsaller> intentional
<hatch> alright :)
<bcsaller> basically, if I was able to take another item from the sequence 
<hatch> gotcha - I think I have figured out why this is erroring out but I'll wait until later so we can work out a sollution - it looks like it's evaluating all routes regardless of the 'namespace' property
<bcsaller> hatch: have you merge the change with match()?
<bcsaller> hatch: looks like you have an older version
<hatch> hmm ok let me do another merge
<hatch> so when I do these merges `bzr merge ../../trunk` it does the merge but then shows changed files which I have to re-commit, am I doing something wrong or is that just how bzr works?
<bcsaller> hatch: yes, you have to commit the merge, if there are conflicts for example you'd resolve them now
<hatch> gotcha
<hatch> https://code.launchpad.net/~hatch/juju-gui/1130790-create-subapp here is the most recent codebase
<hatch> once it loads you'll see that it trys to call the callbacks that aren't on the proper namespace
<benji> man, after getting used to actually being able to quickly see where entities come from (Python) wandering around blind is irritating (Go)
<hatch> we can discuss after the meetings, just putting it there :)
<hatch> how do you like Go?
<hatch> ya know - assuming you knew the language :P
<benji> I actually like a lot of the ideas in Go; unfortunately it seems to have missed some important things we have learned over the last decade or so.
<benji> one of those things being "I should be able to quickly figure out where a name comes from just by looking at the current source file."
<hatch> aww that's unfortunate
<hatch> I've heard Ruby also misses some of the life lessons
<hatch> I don't have any first hand experience though
<bcsaller> hatch: I see a null callback, its using callback = self[callback] rather than the routes subapp || self
<benji> yeah, me neither; I'd like some, if only to be able to complain about it afterward ;)
<hatch> haha
<hatch> bcsaller: ahh I see that now
<gary_poster> jujugui call in 2
<hatch> in copying my music over to my NAS it decided to duplicate about 25% of them
 * hatch is less than impressed
<gary_poster> hatch goodspud call now
<hatch> bcsaller: did you want to work on this router bug now?
<hatch> I have 2H
<bcsaller> hatch: did you change the code to resolve from the proper context object?
<hatch> nope - I thought that was psudo code :) changing
<hatch> but but even if I do that, the callback shoudln't be being called anyways
<bcsaller> hatch: around like 459, that should fix it
<bcsaller> hatch: you're saying its matching improperly? I haven't seen that yet
<hatch> throw a console.log(callback) on ln479 and you'll see that it's calling the namespace routes even on root localhost requests
<hatch> if you can't see that I can screenshare to show you what I mean
<bcsaller> hatch: ok, seeing if g+ is open
<bcsaller> hatch: it is
<hatch> bcsaller: sorry needed to install plugin
<hatch> almost up
<bcsaller> hatch: I think I found the source of the problem, its the way we are mutating the routes ATTR, we mix in options like namespace but this only happens when routes are appended, not inserted at offset so the property (namespace in this example is lost). I can generate a patch
<hatch> ahh - figures there would be some weird stuff going on
<hatch> thanks!
<gary_poster> benji bac frankban teknico please join https://launchpad.net/~canonical-cloud-engineering
<benji> gary_poster: page not found
<gary_poster> benji, works for me, but never mind:
<gary_poster> benji bac frankban teknico nm I am doing it for you
<gary_poster> though you might want to join mailing list
<benji> gary_poster: it is private, doesn't that prevent anyone from seeing it until they are a member?
<gary_poster> benji, ah maybe so
<teknico> gary_poster, it looks like you did the mailing list subscription too :-)
<gary_poster> teknico, heh, maybe.  unintentional if so :-)
<benji> teknico: there is a setting somewhere that lets you choose to automatically subscribe to team mailing lists when you become a member of the team
<frankban> gary_poster: done
<gary_poster> thank you
<teknico> benji, apparently I have that set already :-)
<gary_poster> bcsaller, landscape-aggro (which I keep on thinking of as landscape-aggression) is clear for take off :-)
<bcsaller> gary_poster: thanks for the review, I'll submit it after I get a patch for hatch ready
<gary_poster> cool
<bcsaller> hatch: http://paste.ubuntu.com/5555767/
<hatch> innnnnteresting
<hatch> thanks a bunch!
<hatch> are you going to be putting this in your branch?
<bcsaller> my branch is already landed, you should take it 
<bcsaller> hatch: ^
<hatch> oh I didn't get the email
<hatch> thanks I'll merge it in
<bcsaller> hatch: I forgot that the insertion would invalidate an assumption 
<hatch> I don't see the branch in LP, did you push?
<bcsaller> hatch: you merged the match method from trunk, no? Thats all I was talking about. I don't have a new outstanding branch for this so take the patch and apply it
<hatch> oh yeah sorry that's what I was asking :)
<hatch> ok taking patch......now
<hatch> and as a gift for fixing this
<hatch> here is a tai fighter
<hatch> |-o-|
<hatch> pew pew pew
<bcsaller> queue the robot chicken
<gary_poster> heh
<hatch> Just incase you guys ever need to insert an array of values into another array I had to figure this out the hard way yesterday so I figured I should document it somewhere http://fromanegg.com/post/43733624689/insert-an-array-of-values-into-an-array-in-javascript
<gary_poster> I figured it was an apply trick :-)
<hatch> haha yep, using call/apply is pretty powerfull
<benji> does anyone else who is running quantal been able to deploy anything using go-juju?
<hatch> my laptop has 12.10 on it, I can try if you like
<hatch> although I'd need some sort of guide :)
<gary_poster> I thought frankban had, benji
<gary_poster> he is past EoD though
<benji> hatch: I suspect the setup entailed would be too involved to ask that of you
<benji> I was trying to use the OS the core developers were using and assumed (bad me) that it was quantal.
<gary_poster> benji, they are on precise?
<gary_poster> I know jam is
 * hatch finds it easier to remember version numbers than names :) 12.04, 12.10
<benji> gary_poster: I don't know, but when I look at the charm store, the number of quantal charms is paultry.
<gary_poster> benji, oh that's different
<benji> yeah, I hate the code names; unfortunately they infect everything
<gary_poster> benji, that's what is run on the vm side
<gary_poster> which you can change to whatever you want, whatever version your own machine is, at least with pyjuju
<benji> is it?  Given that the dev platform is so intamately tied with the deployment platform, I would expect the OS version to be critical.
<gary_poster> no, what I mean is that the charm runs on the remote machine benji.  Usually we use LTSs for those
<benji> gary_poster: right, but this is go-juju
<hatch> bcsaller: awesome - with your fix in route and then chaging the callback in _dispatch to
<hatch>               callback = self[callback] || self.get('subApps')[namespace][callback];
<hatch> it all looks like it's working
<hatch> :D
<hatch> that's one ugly line though eh? :)
<gary_poster> benji understood.  (1) go juju should do this too--that's one of the goals, and (2) I think frankban did it
<benji> I'll try changing the preferred series.
<gary_poster> default series, I think
<benji> yep
<hatch> I'll be cleaning that line up because it doesn't need to fetch the sub apps in a loop
<bcsaller> hatch: the order is backwards or callback resolution I think, if the sub has it use it there first
<hatch> bcsaller: ok I'll do some testing to determine the proper order
<hatch> I'll probably have to flesh out the sub apps a little more to get some more use cases
<frankban> benji, gary_poster: that's the problem with the gui charm too, i.e. bug 1131608
<_mup_> Bug #1131608: deployed series is arbitrary <juju-core:New for fwereade> < https://launchpad.net/bugs/1131608 >
<gary_poster> frankban, I thought that only was true for the upload tools option?
<gary_poster> I must be confusing the two issues
<gary_poster> Sorry
<frankban> gary_poster: not sure, it's worth to try
<benji> btw, I need --upload-tools *and* to deploy a charm
<gary_poster> ah, benji, I think that's the broken part.  Could be wrong.
<frankban> benji: you can try recompiling and bootstrapping juju-core from a precise lxc. it's not ideal, but, if it works, it can be a (uncomfortable) workaround.
<benji> frankban: that's a good idea; I may have to do that
<frankban> cool, eod, have a nice weekend
<benji> have a good weekend, frankban 
<benji> gary_poster: cool, Danilo is comming back into the fold
<gary_poster> benji, yeah, I heard!  I don't know where though--do you know that?
<benji> Blue
<benji> Squad
<benji> (they added a newline in the middle of their name... hipsters)
<gary_poster> heh
<Makyo> 99% there with win8, missing only network.  Anyone have to change settings for that away from NAT?
<Makyo> guihelp ^^^
<bcsaller> Makyo: I still don't have it working, I was planning on trying again today
<hatch> Makyo: are you using parallels?
<gary_poster> Makyo, I had to use bridged
<Makyo> hatch, virtualbox.
<Makyo> gary_poster, ah, trying that now.
<hatch> ahh I actually had to do the same with parallels
<hatch> :)
<Makyo> That did it, thanks gary_poster, hatch 
<bcsaller> kinda of have ie working in the VM now :-/
<bcsaller> kind of.. blah
<hatch> what issue are you having?
<hatch> ugh itunes is such a junk program
<hatch> bcsaller: I've been trying to track down a little bug maybe you have some insight...._dispatch() is being called 4 times on load
<hatch> this is almost certainly a bug no?
<benji> hatch: I think it is past his end-of-day, but yes, that sounds like a bug 
<hatch> ahh - we need a map where everyone is located so we can see when EOD is ;)
<hatch> ok found it....looks like it was being dispatched 4 times lol
<hatch> but it didn't matter until now!
<hatch> ohhhh boy - how to solve this
<hatch> gary_poster: still around?
<hatch> looks like everyone might have checked out for the weekend
<bcsaller> hatch: its a known issue, the app calls dispatch aggressively and it gets called on delta updates
<bcsaller> hatch: some pages it works out to more and some less, plus if there is a delta depending on the page it can appear as quite a lot
<bcsaller> dispatch alone being called doesn't have to be a big deal though, we mostly treat it as an event saying to any active views, "do you have to update yourself now?"
<hatch> ohh ok so we'll need to change that
<bcsaller> but some views currently do a full rerender to that question
<hatch> calling dispatch causes the sub apps to rerender
<hatch> so they render 4x which is obviously no good
<hatch> that might be a large refactor though
<bcsaller> it is
<bcsaller> notifications and env view both do it better
<hatch> yeah see dispatch is designed to initiate the routing callbacks based on url changes
<hatch> if the url doesn't change, it shouldn't dispatch
<bcsaller> notifications is model bound and env view has an update() phase and then is event rather than render driven
<bcsaller> but callback doesn't have to equal full render
<hatch> no but in my opinion the views should be pretty dumb...the singletons should be outside of the views
<bcsaller> to be clear I'm not trying to defend the model, but its part of a much larger issue which to my mind steams from a lack of model bound views 
<bcsaller> non-persistent views can be dumb and we let them be
<bcsaller> persistent views need to be smarter, "most" of the app is the persistent env view
<hatch> yeah I'm going to need to understand more of how the app operates to see how we can fix this
<bcsaller> that component framework helps handle incremental update (which is what we have been calling it)
<bcsaller> by drawing lines between initial render and event driven update cycles 
<hatch> yeah maybe this weekend I'll find some time to really step through the execution order of this app
<hatch> dispatching 4x on load has to kill the startup time heh
<bcsaller> hatch: it really doesn't, thats not the issue, its often 1/2 that (still an issue) followed by the 1st delta window
<bcsaller> then look at app.on_database_changed
<hatch> ahh ok
<bcsaller> thats deals with an async change to the data from the websocket w/o the app triggering it
<bcsaller> to keep the views dumb they can just dispatch on that
<hatch> ok well as long as it's a known thing because I was sure it was a bug :D
<bcsaller> its a compromise 
<bcsaller> ok, signing off
<hatch> alright at least now I understand its purpose :)
<hatch> have a great weekend!
#juju-gui 2013-02-24
<hatch> *yawn*
#juju-gui 2014-02-17
<frankban> dimitern: morning. re charm GET in core? what's the plan? do we want to implement it as /charms/ HTTPS GET? if you are busy ping me later, no rush
<dimitern> frankban, morning! I don't think core has immediate plans to implement GET, I think we agreed you guys to do it? the placeholder for a GET handler is already in place in charmsHandler
<frankban> dimitern: sure, so it's an HTTPS request right? not a websocket one. cool. just two questions: 1) is it ok something like /charms?charm=curl&path=path/to/file? 2) could you please point me to the code we have to use to retrieve a charm file from the storage?
<dimitern> frankban, 1) I'd prefer /charms?url=curl&file=path/to/file (if file= is missing, you'll get the whole archive); 2) yep, just a sec
<dimitern> frankban, re 2) you can take a look in repackageAndUploadCharm() in apiserver/charms.go
<dimitern> frankban, there's the GetEnvironStorage to access the storage interface and from there you can do a Get(name) to download it, where name := charm.Quote(curl.String())
<frankban> dimitern: thanks, I'll take a look. so if file is missing, you get the charm as a zip, right?
<dimitern> frankban, yep, if you even need to get the whole thing
<frankban> dimitern: AFAICT the GUI does not need that (at least for now)
<dimitern> frankban, so you can just return an error for now if file= is not given
<frankban> dimitern: right, thank you
<rick_h_> morning
<rick_h_> frankban: can you look into the #1279075 card this week for release? That's the #1 bundle marketing bug from ecosystem that we'd like to have for the release/quickstart update this week.
<_mup_> Bug #1279075: Deployer should not stop when a unit has an error <juju-deployer:New> <https://launchpad.net/bugs/1279075>
<rick_h_> frankban: I moved it up into urgent over the other bug about the second bundle failing and such
<rick_h_> frankban: per hazmat in the friday standup the goal is to add a flag we can pass to the deployer that tweaks the behavior but leaves it failing as it does now by default because others rely on it for CI checks and such. 
<frankban> rick_h_: sure. so 1) introduce a flag for the new behavior, 2) that flag is not activated by default and 3) with that flag enabled, the deployment stops only if a unit error is found in one of the units belonging to bundle specific services. correct?
<rick_h_> frankban: well it should only stop if a service fails to come up entirely I think. If any unit comes up and can take a relation then it should
<rick_h_> if the bundle is 5 units and 4 come up ok the bundle should continue to add relations 
<rick_h_> actually, reading the bug they want relations added even if the units don't come up. Not sure about that, but it's the issue they're having is that large scale demo bundles often have a unit or two that don't come up and the bundle aborts and fails the demo
<rick_h_> frankban: but yea, on 1) 2) 
<frankban> rick_h_: ack, ok
<rick_h_> thanks frankban 
<hazmat> g'morning
<rick_h_> morning hazmat, getting TZ adjusted?
<hazmat> rick_h_, been up for a while.. woke up 3am due to some muscle cramps post long hike yesterday.
<rick_h_> ouch
<rick_h_> long hike? You bring a snow blower with you?
<hazmat> rick_h_, yeah.. everywhere around here is covered with snow and 3-8 foot high snow drifts from the blows.
<hazmat> er.. plows
<hazmat> somewhat surreal for the area
<rick_h_> every time I try to take the dog for a walk I have to either wade up past my knees or risk cars sliding around on the street
<bac> hello frankban.  ought to be very quiet here today.
<frankban> bac: morning, not so quiet actually
<bac> oh?
<bac> things on fire?
<rick_h_> ssshhh
<rick_h_> bac: heads up, talked with IS and there's some activity on your charmworld RT
<rick_h_> looks like we should be heading to a resolution there soon
<bac> rick_h_: which one?  :)
<bac> the deployment one or the staging setup?
<rick_h_> bac: deployment
<bac> yay
<rick_h_> staging is 3rd on the list so it's down the road still
<bac> so rick_h_ are you really here today?
<rick_h_> bac: yes
<bac> cool
<rick_h_> bac: I'll be here all week, tip your waitresses
<bac> so rick_h_, in your email are you suggesting during a charmworld upgrade they do a 'destroy-service charmworld' and re-deploy it?  is that what you mean by 'get a new unit'?
<rick_h_> bac: I'd assume they could juju add-unit, move the dns to the new ip, and then be all happy?
<rick_h_> bac: once that was done destroy the old unit
<rick_h_> bac: at least that's how I read things. I could be wrong
<bac> rick_h_: their process is mysterious
<rick_h_> bac: yea, true. 
<bac> and by mysterious i mean way too complicated
<rick_h_> so maybe I'm thinking it's too easy
<rick_h_> lol
<gary_poster> Well, I've been turning my computer on and off for the last 30 minutes, doing the moral equivalent of opening and shutting car windows to see if helps the vehicle start
<rick_h_> hah
<rick_h_> you offend the computer coming back? 
<gary_poster> :-) apparently so
<gary_poster> I think I'm over 2000 unread emails...
<rick_h_> See you thursday
<gary_poster> heh
<gary_poster> rick_h_, could you please verify that you have leankit kanban super-super-powers?  I'm not sure what you couldn't do before, but you now have the same privs as I do according to the interface
<rick_h_> gary_poster: rgr, looking
<rick_h_> gary_poster: yea, looks like it now
<gary_poster> cool thanks
<rick_h_> whoa, board edit crazy
<rick_h_> *cancel cancel*
<gary_poster> moving down the checklist you sent--thanks!  also will review my logins to see what we can do
<rick_h_> gary_poster: thanks, yea. Just stuff I thought of and ran into last week.
<frankban> dimitern: re GET request, when sending back the file, do you think it is better to read and expand the bundle to a temp dir (and then using http.ServeFile) or to directly read the file from the zip archive and send it some way? The former seems easier/safer
<dimitern> frankban, I'd be a bit careful when implementing the extraction, because it's a possible DDoS target if the api server gets flooded with tons of GET requests for the same charm
<rick_h_> dimitern: does the api call support only auth'd requests so that's not an issue? 
<dimitern> frankban, perhaps using a "cache" dir somewhere, and each curl gets extracted to the same place if it's not there already?
<frankban> dimitern: well, it's a ddos target for authenticated users
 * bac installs trusty updates.  reboots.  holds breath.
<frankban> dimitern: yeah that can be an option
<dimitern> frankban, rick_h_ , that's true, but still my spider sense is tingling a bit :)
<dimitern> frankban, also, what you get "for free" is the ability to cache charms and thus answer to subsequent GETs for the same curl faster
<frankban> dimitern, where do you usually store this kind of cache dirs? /tmp? /var/lib/juju/?
<dimitern> frankban, i think /var/lib/juju/agents/.. something - take a look where the charms are cached when deployed
<frankban> dimitern: is charm.Quote(curl) good enough as a directory name?
<dimitern> frankban, yes, it's intended to be filepath safe, although it's perhaps better to use the same tactic as the charmsHandler - i.e. "<charm name>-<revision>-<bundlesha256>" as filename, so that it's both readable in a list of files, and guarantees the same internal contents get the same name
<frankban> dimitern: sounds good, thank you!
<dimitern> frankban, np :)
<bac> rick_h_: i made some changes to your doc in situ.  hope you don't mind.  looks good!
<rick_h_> bac: thanks! appreciate the help and feedback. 
<gary_poster> rick_h_: sent you email reply with important bits
<rick_h_> gary_poster: thanks
<gary_poster> welcome
<hatch> morning all
<rick_h_> party
<hatch> s club party!
<rick_h_> jujugui meeting in 5
<rick_h_> Makyo: standup?
<bac> benji: have we ever tried to promulgate a bundle?  is it possible?  (done via charm-tools)
<benji> bac: I /think/ it is possible.  I don't know about charm-tools, I thought there was a UI on charmworld to do it.
<Makyo> rick_h_, out today, not swapping.  Sorry :(
<rick_h_> Makyo: rgr, thanks for the heads up
<rick_h_> Makyo: can you submit that in canonical admin?
<Makyo> rick_h_, on it.
<benji> is it intentional that we do not confirm scaling down the number of units in a service but do confirm scaling up?  
<benji> It seems just as dangerous to go from 100 to 1 as it is to go from 1 to 100.  Maybe it is because scaling up might cost someone money (directly).
<rick_h_> benji: yea, i think that's the general idea
<benji> I have a small bug-fix branch up for y'all to review: https://github.com/juju/juju-gui/pull/132
<rick_h_> benji: looking
<benji> k
<rick_h_> benji: it is a bit jarring isn't it, without the confirmation on downgrade. 
 * rick_h_ thinks we should update that as well just to be consistent
<benji> it is odd
<rick_h_> yea, just stands out when you're doing both back to back. 
<rick_h_> benji: heads up, that test failure is spurious and I'm looking into it. Feel free to :shipit: with that there
<benji> k
<hatch> hey benji I'm wondering if we can remove the db.fire('update') in your most recent branch as well... I'm not sure what purpose that serves any longer 
 * hatch notes that he might be totally wrong :)
<benji> hatch: I can try removing it, if you want
<hatch> well I'm just trying to think of things which require the canvas to be re-rendered at that point...
<bac> jujugui: any idea how we spell ISD these days?
<hatch> isd?
<rick_h_> ISD?
<rick_h_> heh
<hazmat> ops :-)
<hazmat> bac, not sure we have isd anymore
<hazmat> dunno
 * gary_poster thought they were webops now
<gary_poster> on #webops
<bac> thanks gary_poster.
<gary_poster> welcome
<rick_h_> oh, yea I think it's basically IS and webops but even webops I don't think means what it used to
 * bac wonders why #isd still exists, then.
<hazmat> well there was isd as a form of internal apps web dev at one point as well
<hazmat> d was developer i thought
<hatch> isd sounds like a disease haha
<bac> hazmat: yeay, and they owned SSO, right?
<bac> s/yeay/yeah/
<hazmat> bac, yeah.. although i think some of that shifted to online services
<hazmat> hence i'm not entirely clear they exist as a dev group anymore
<bac> you're right i think
<bac> they are still referenced in the 2fa FAQ.  of course it says it is in beta, too.
<bac> hey marcoceppi, does 'charm promulgate' work with bundles?
<rick_h_> bac: it's supposed to, but not sure we've tested it 
<marcoceppi> bac: not really, currently to promulgate a bundle we just have a ~charmer push to lp:~charmers/charms/bundles/<bundle>/bundle
<marcoceppi> bac: there will soon be a bundle promulgate command as soon as we figure out that process for that
<bac> marcoceppi: for testing could i get you to promulgate one then?
<marcoceppi> bac: certainly
<bac> marcoceppi:  bzr+ssh://bazaar.launchpad.net/~bac/charms/bundles/muletrain/bundle
<bac> marcoceppi: i can be undone, right?
<marcoceppi> bac: yes, we can delete the branch later
<bac> rt
<bac> rick_h_: last week you asked about featuring bundles.  (one part of the orange metatask)  the answer is you can only feature promulgated bundles.  once marco promulgates that branch i'll feature it and see that it works.
<rick_h_> bac: ah, makes sense
<marcoceppi> bac: passes proof, pushing now
<bac> ty
<rick_h_> bac: I remembering having these discussions back when bundles were first done. Thought that was working. Oh well
<bac> rick_h_, marcoceppi: if any of jorge's bundles are of sufficent quality we might consider promulgating them and featuring.
<marcoceppi> bac: I'll got through them again, there are a few that are supposed to be good
<marcoceppi> bac: pushed https://code.launchpad.net/charms/bundles
<rick_h_> bac: marcoceppi there's a marketing meeting to determine featured bundles later this week
<rick_h_> wel'll have a list from that to use
<bac> ok
<hatch> benji yay, less db update events....one step closer to removing double dispatch :D
<benji> :)
<benji> bac: I'm looking at bug 1277188 and wondering if we should change the GUI's behavior or add the proposed warning to the charm proof tool.  Thoughts?
<_mup_> Bug #1277188: charm-proof should warn on revision-less charm URLs <charmworld:Triaged> <https://launchpad.net/bugs/1277188>
<bac> benji: last week i did a branch for bug 1277696 that is waiting for review/landing to juju-deployer
<_mup_> Bug #1277696: Bundles with revision-less charm URLs should deploy <juju-gui:In Progress> <https://launchpad.net/bugs/1277696>
<bac> benji: that branch makes the behavior the same across deployment-ers
<benji> bac: oh!  so the card for 1277188 should be... deleted?  blocked pending the other landing?
<bac> so bug 1277188 now really is about  just making 'charm proof' spit out a warning
<_mup_> Bug #1277188: charm-proof should warn on revision-less charm URLs <charmworld:Triaged> <https://launchpad.net/bugs/1277188>
<bac> benji: not blocked, imo.  just do it.
<bac> they are uncoupled.
<benji> sounds good
#juju-gui 2014-02-18
<rick_h_> frankban: I'm trying to run the functional tests and getting errors on "for pe in os.environ['PATH'].split(os.pathsep):" which seems odd? Seen that before?
<frankban> rick_h_: functional tests for the GUI? no, never seen it
<rick_h_> frankban: yea, they all failed in the FF selenium stuff on PATH keyerror. Trying again
<frankban> rick_h_: uhm... so in the environment the tests are run on the path is not defined, weird
<rick_h_> wondered if I had something missing, will keep poking at it
<rick_h_> brb daycare run
<rick_h_> benji: jujucharms.com is updated so moved the check the etags over. Can you check the etags while I get the charm updated and hopefully we can close the book on the move/upgrade today. 
<benji> rick_h_: sure
<benji> rick_h_: 100% consistent etags and they are in the right format (which is different than they were before)
<rick_h_> benji: rock on, thanks for the check
<benji> np
 * gary_poster adds quiet yay in benji's direction :-)
<gQuigs> can I not restart juju-gui with normal service tools?   Does it need to have an upstart job to manage it?
<rick_h_> gQuigs: the gui is run via an apache install. So you have to restart apache. The gui is just some JS that talks to Juju. Reloading the browser reloads the Gui
<rick_h_> gQuigs: what are you trying to do?
<benji> heh
<gQuigs> rick_h_: just curious how it starts up and is managed; sometimes it was coming up, but not ever finishing connecting to the environment
<rick_h_> gQuigs: so yea, when you load the browser it tries to talk to the juju environment. That's purely the browser trying to setup a websocket connection to the charm and from the charm to the juju api endpoint in the environment. 
<frankban> gQuigs: on the charm/server side, the upstart job is named guiserver, so "service guiserver restart". logs can be found in /var/log/upstart/guiserver.log
<gary_poster> We've never seen an issue there though, have we?  Knowing more about the symptom he describes would be valuable
<rick_h_> no issues I've heard. My first reaction is local network issues during wss setup?
<gQuigs> rick_h_: frankban, thanks both.. this helps a lot
<frankban> gary_poster: agreed. gQuigs ^^^: what browser are you using? does it happen after e.g. cleaning the cache/running in incognito mode?
<rick_h_> gQuigs: sure thing, let us know if you hit more issues we can watch for. We've not heard of any issues, but of course want to make sure we catch anything early
<gary_poster> we have heard of occasional issues on MaaS.  those have seemed to be related to networking.  Getting a test MaaS cluster might be a nice idea eventually.
<gQuigs> frankban: was using Firefox stable on Ubuntu 13.10.  I'll see if I can repdoduce reliably or if it was a one ff
<frankban> cool thanks gQuigs 
<rick_h_> frankban: are you on trusty or saucy?
<frankban> rick_h_: saucy
<frankban> rick_h_: I have a trusty vm
 * gary_poster steps out.  biab
<rick_h_> frankban: if you get a sec can you run the tests on charm trunk on both to see if you can dupe my issue on the trusty side? I'm getting it on both laptop/desktop.
<rick_h_> I'm working on running hte tests manually so I can try to debug vs wrapped in juju-test, but a sanity check on your env would be appreciated. 
<frankban> rick_h_: sure, so "make ftest" on the charm in both saucy and trusty, right?
<rick_h_> frankban: yes please
<rick_h_> the hope is that saucy passes and trusty fails and gives me a hint that it's trusty package related
<frankban> rick_h_: started tests on saucy
<rick_h_> vs some mystery thing in my install that causes it to not work
<gQuigs> rick_h_: frankban the issue appears once the juju-gui VM has been restarted..  it just hangs at connecting to environment (has happened 3/5ish reboots)
<rick_h_> gQuigs: VM restarted?
<rick_h_> gQuigs: what are you deploying to?
<gQuigs> rick_h_: openstack
<rick_h_> gQuigs: so you're restarting the machines then? and on restart it fails to connect at all? Does it come up eventually?
<gQuigs> rick_h_: io've givenb it 5 mins
<rick_h_> gQuigs: ok, so next time it fails, see if you can ssh to the machine and see if the guiserver is running via the upstart script frankban mentioned. I wonder if that's not coming back up for some reason. "service guiserver restart"
<rick_h_> gQuigs: also appreciate if you can open firebug or the javascript console and post any error output from there when it's not connecting
<frankban> gQuigs: also, does the bootstrap node ip address change between restarts?
<frankban> gQuigs: between machine reboots
<gQuigs> frankban: no, no IPs change
<gQuigs1> rick_h_: Firefox can't establish a connection to the server at wss://10.55.60.229/ws. all-yui.js:28
<gQuigs1> 09:14:06.710 The connection to wss://10.55.60.229/ws was interrupted while the page was loading. all-yui.js:28
<rick_h_> gQuigs1: ok, so that is the IP of the gui unit?
<gQuigs> yes
<rick_h_> ok, yea so if you can juju ssh to that and check if guiserver is running "ps aux | grep guiserver"
<rick_h_> gQuigs: and if not, try to restart it to see if that solves the issue 
<rick_h_> "service guiserver restart"
<gQuigs1> hmm...  nothing running with guiserver in the name, but:
<gQuigs1> $ sudo service guiserver restart
<gQuigs1> guiserver stop/waiting
<gQuigs1> guiserver start/running, process 1844
<gQuigs1> ubuntu@juju-openstack-machine-1:~$ ps aux | grep 1844
<gQuigs1> root      1844  2.3  4.5 152996 23032 ?        Ss   14:16   0:00 /usr/bin/python /usr/local/bin/runserver.py --logging=info --guiroot=/var/lib/juju-gui/juju-gui/build-prod --sslpath=/etc/ssl/juju-gui --charmworldurl=https://manage.jujucharms.com/ --apiurl=wss://10.55.60.220:17070 --apiversion=go
<rick_h_> gQuigs1: ah sorry yea. 
<frankban> gQuigs1: is 10.55.60.220 the ip of the bootstrap node?
<rick_h_> hmm, so that's running. and you can't connect to it. The ip of the machine is the same. 
<rick_h_> gQuigs1: anything of interest in the /var/log/upstart/guiserver.log? Especially since reboot time?
<gQuigs1> frankban: yup, and that did not get restarted
<frankban> gQuigs1: just to exclude any client issues, does it work with chrome in incognito mode?
<gQuigs1> frankban: interesting.. it worked after I disabled all of my firefox add-ons
<gQuigs1> frankban: no it must have been a cache thing that required a reboot to clear... weird
<gQuigs1> (private browsing mode didn't do enough...)
<gQuigs1> thanks rick_h_ and frankban!
<frankban> gQuigs1, rick_h_ : uhm... so our websocket client impl is affected in some way by ff cache...
<frankban> rick_h_: we should be able to dupe that stopping and restarting a GUI lxc in a local env
<rick_h_> frankban: something on the network? 
<frankban> gQuigs1: welcome
<rick_h_> frankban: yea, should be simple to test out, I'll add a card to investigate
<frankban> rick_h_: thanks
<jcastro> anyone know a good big data bundle offhand?
<rick_h_> jcastro: there's one sec
<jcastro> or better yet, know a trick to have the GUI show me all the bundles in the store?
<rick_h_> jcastro: under dev right now
<rick_h_> (the second part)
<jcastro> ack
<rick_h_> jcastro: http://comingsoon.jujucharms.com/sidebar/search/bundle/~gary/demo/2/instantBigDataNoSQL/?text=instantBigDataNoSQL
<rick_h_> jcastro: is one that maarten was asking about at CT
<jcastro> perfect
<frankban> rick_h_: charm ftests passed on saucy. I'll set up the charm on trusty in a minute
<rick_h_> frankban: thanks
 * gary_poster back
<bac> marcoceppi, jcastro, benji: the promulgation marking for bundles in charmworld is broken and i'd like to nail down the rules with you.
<jcastro> sure
<marcoceppi> bac: sounds good
<bac> for a charm, it is marked as promulgated if the series==distroseries in the branch data.
<bac> yesterday marcoceppi suggested any bundle owned by ~charmers should be considered promulgated
<bac> is that true?
<marcoceppi> imo, yes, but I'm biased as that's what I suggested
<bac> marcoceppi: well, nows a good time to rethink it!  :)
<bac> i mean, if you need to
<bac> what says jcastro?
<jcastro> (thinking)
<rick_h_> the reason we went away from ~charmers for charms was so that others could own the charm (like ~juju-gui)
<rick_h_> so do we expect the same for bundles?
<jcastro> yes, eventually
<marcoceppi> right, but I dont' imagine bundles would get as much attn
<marcoceppi> or not
<rick_h_> then let's not go through that again
<jcastro> like, if I was MySQL and I wanted to own the bundles for MySQL
<bac> rick_h_: i do not fully understand the series == distroseries test for charms
<jcastro> marcoceppi, I would argue that bundles will and should get all the attention
<marcoceppi> jcastro: right, but they're probably more important and arguably more static than charms are
<jcastro> true
<rick_h_> bac: it's LP workings. I just know originally we had the rule that chrams owned by ~charmers were promulgated, but some LP mechanics allowed that to work for others to own the promulgated one
<jcastro> I think having them owned by ~charmers is fine
 * rick_h_ never got all the series level stuff in LP
<marcoceppi> I'd argue that I can't see a circumstance in the near future where a team would want to own a bundle
<rick_h_> marcoceppi: so no sales team or open stack team or something?
<bac> or ~jujugui
<marcoceppi> rick_h_: they can author bundles all they want, but if they want to put them in the store it needs to be vetted by charmers
<rick_h_> I'm all for simple if we can do it, just want to avoid migrating again if we can. At least for a w2hile
<jcastro> yeah ~charmers will be fine
<rick_h_> marcoceppi: hmm, that's not going to be true in 6mo
<rick_h_> well 8+
<marcoceppi> rick_h_: oh?
<jcastro> if we ever have a problem with bundle ownership it will be a good problem to have
<rick_h_> but we can deal with it then
<marcoceppi> rick_h_: what happens in 8mos?
<jcastro> Rick is rewriting the store in Erlang
<jcastro> j/k
<rick_h_> woot!
<marcoceppi> haha
<bac> ok so any bundle owned by ~charmers will be promulgated.  the charmers will need to understand not to push any up that aren't of that quality
<marcoceppi> bac: correct, which is current policy
<rick_h_> cool, thanks
<rick_h_> bac: 
<bac> rick_h_:
<bac> did you have more?
<rick_h_> bac: no, sorry. Meant to be "cool thanks bac" 
<bac> marcoceppi: well, it is theoretically current policy.  no code yet to make it happen.  :)
<rick_h_> but I keyboard fail
<rick_h_> <enter> and <space> are next to each other on this kenisis 
<marcoceppi> bac: well, we have that policy for charms, so the same would apply to bundles, and given how small the ~charmers are it's pretty well enforced
<bac> rt
<marcoceppi> cool
<rick_h_> frankban: ok, got tests passing in trusty by manually bootstrapping, making sure precise is the default series, and manually running JUJU_ENV="ec2" ./tests/20-functional.test
<rick_h_> frankban: so closer yay
<frankban> rick_h_: oh, so the problem could be juju-test not propagating PATH?
<rick_h_> frankban: right
<rick_h_> frankban: in trusty
<rick_h_> I'm setting up a saucy lxc to see if it works for me there
<frankban> rick_h_: where are you taking juju-test from?
<rick_h_> frankban: good question
<frankban> rick_h_: mine is from bzr+ssh://bazaar.launchpad.net/+branch/juju-plugins/
<rick_h_> frankban: is it part of charmtools or something?
<frankban> rick_h_: not sure, I just checked out the juju-plugins branch and made a symlink like  /home/frankban/bin/juju-test -> /home/frankban/devel/juju-plugins/sandbox/plugins/juju_test.py
<rick_h_> so yea, I've got it from the juju stable ppa version of charm-tools for trusty
<rick_h_> http://bazaar.launchpad.net/~charmers/charm-tools/1.2/view/head:/setup.py
<frankban> rick_h_: mine has no version :-/
<rick_h_> 1.2.8-0ubuntu1~ubuntu14.04.1~ppa1 here
<rick_h_> juju-plugins hmm
<rick_h_> that's a diff repo entirely
<rick_h_> marcoceppi: ^ juju test from juju-plugins vs charmtools? discuss?
<marcoceppi> rick_h_: only charm-tools, juju-plugins is depreciated and if I knew how to delete a project on LP I would
<marcoceppi> frankban: ^
<rick_h_> marcoceppi: k
<rick_h_> marcoceppi: so we've got juju test tests that fail because PATH isn't in os.environ on the newer stuff?
<rick_h_> marcoceppi: sound familiar at all?
<frankban> rick_h_: ok, so I'll re-run the tests on saucy using charmtools
<rick_h_> probably not if the tests didn't hit os.environ I'd guess. 
<marcoceppi> rick_h_: there's a whitelist of envs that are set during the test run
<rick_h_> frankban: k, sounds like we'll need a card to update the tests or setup to work in the newer stuff
<rick_h_> marcoceppi: orly, cool Sounds like we might need to add one then
<rick_h_> or discuss why PATH is a bad one not allowed
<rick_h_> things are making a lot more sense now :)
<marcoceppi> rick_h_: yeah, I'll expose an environment variable/flag for additional params
<marcoceppi> rick_h_: not that it's a bad one, just one that didn't have a use case
<marcoceppi> idk who put juju/charm-tools up but that's pretty out of date
<rick_h_> marcoceppi: rgr, ok. That explains why it's not set. Seemed a really strange thing to have no PATH but having juju test kill it explains it
<marcoceppi> rick_h_: the idea behind that was to provide as sterile as an environment as possible when running the tests as to not have one users env cause a test to pass/fail
<marcoceppi> charmtools/test.py has the ENV_WHITELIST which is just hardcoded atm
<rick_h_> frankban: ok, so I think we can kill off the debugging now
<rick_h_> frankban: I've added a card to update the tests and possibly charm-tools
<marcoceppi> rick_h_: actually, PATH is in the whitelist
<marcoceppi> so, not sure what is breaking then
<frankban> uhm...
<rick_h_> marcoceppi: hmm, in our tests it throws a keyerror on os.environ['PATH']
<marcoceppi> rick_h_: full trace?
<rick_h_> bah, give me a few min to restart a test run (takes a few min in ec2 land)
<marcoceppi> rick_h_: ack, thanks!
<marcoceppi> rick_h_: OH, wait, I don't think that patch as landed yet
<rick_h_> marcoceppi: ah, phew. 
<marcoceppi> rick_h_: I can cut a release for you now if you'd like
<rick_h_> marcoceppi: yea, I'm pulling from the stable ppa
<marcoceppi> ah, yeah, that's only in trunk atm
<rick_h_> so I'm on 1.2.8 I think I had up there
<rick_h_> ok cool
<rick_h_> marcoceppi: yea, a release with that fix would be useful. 
<marcoceppi> yup, this would be a 1.2.9 release, will do a check for anything else that needs to land and a release
<rick_h_> marcoceppi: been chasing tests all morning 
<rick_h_> marcoceppi: thanks, appreciate it
<marcoceppi> ah, sorry about that!
<rick_h_> marcoceppi: no hurry, now that I know what's up I can work around it for the moment. 
<frankban> hazmat: for when you are back and have time: could you please take a look at https://code.launchpad.net/~frankban/juju-deployer/unit-errors/+merge/206967 ? it's my proposed fix to bug 1279075 and bug 1252301 (the deployer part). Thanks!
<_mup_> Bug #1279075: Deployer should not stop when a unit has an error <juju-deployer:In Progress by frankban> <https://launchpad.net/bugs/1279075>
<_mup_> Bug #1252301: guiserver reports second bundle as failing after the first fails <juju-deployer:In Progress by frankban> <juju-gui (Juju Charms Collection):In Progress by frankban> <https://launchpad.net/bugs/1252301>
<rick_h_> hazmat: we've got this on board for thurs release so appreciate look in next day ish if you can. 
<rick_h_> hazmat: to beat freature freeze and release with new gui/charmworld this week.
<bac> hazmat: and while you're in the deployer mindset, if you could look at my branch too that would be great.
<bac> https://bugs.launchpad.net/juju-gui/+bug/1277696
<_mup_> Bug #1277696: Bundles with revision-less charm URLs should deploy <juju-gui:In Progress> <https://launchpad.net/bugs/1277696>
<hazmat> frankban, bac, rick_h_ ack.. it will have to be tomorrow morning i've got a customer deadline i'm racing against today
<rick_h_> hazmat: understood thanks
<frankban> thanks
<bac> ty
<rick_h_> jujugui call in 6
 * rick_h_ needs to set a 10min alarm
<rick_h_> jujugui call in 1
<rick_h_> Makyo: standup ping
<bac> benji: beep
<Makyo> 2fa sorry :T
<Makyo> benji, https://github.com/juju/juju-gui/pull/130
<benji> thanks
<benji> Makyo: review done; looks good.
<Makyo> benji, thanks
<jcastro> rick_h_, for your blog post
<jcastro> don't do mediawiki
<jcastro> too boring
<jcastro> do something epic like the big data one
<jcastro> or the mongodb cluster
<rick_h_> jcastro: k
<rick_h_> jcastro: for the 'explain' was that a side note?
<jcastro> yeah
<benji> marcoceppi: I have a charmtools branch up for review which adds a warning for bundles that include charms with revisionless URLs: https://code.launchpad.net/~benji/charm-tools/add-versionless-charm-in-bundle-warning/+merge/206986
<jcastro> so like if I rerun quickstart it relaunches the browser?
<gary_poster> yes (it rocks)
<rick_h_> jcastro: so when you run quickstart it looks "do you have an environment? If you do, does juju status show a gui? If it does, where is that gui at?"
<rick_h_> jcastro: +1, why i said in the blog post, it's the fastest way to get back into your env days later
<rick_h_> jcastro: so one more reason for you to <3 and use it
<marcoceppi> benji: I figured you guys would put this in the online proof instead of the offline, but works for me. I'll review shortly
<benji> cool
<rick_h_> jcastro: aside from that, is the blog post ok for what they're wanting? I couldn't tell if they want one, two, etc?
<hatch> rick_h_ you have a blog?
<rick_h_> hatch: yea, though don't hit it all that often
<hatch> cool what's the url? I wana see this blog post :)
<rick_h_> hatch: oh, this is a doc not submitted yet
<hatch> ohh ok
<rick_h_> hatch: https://docs.google.com/a/canonical.com/document/d/1ma0U1ZxILTh5s3NoHiuwKiclRSxJLIY-Q2MEMzBO7Dk/edit
<hatch> cool I'll check it out
<hatch> I used quickstart yesterday from scratch it was pretty awesome using that terminal gui thing
<hatch> is that a python lib?
<hatch> to make the gui that is
<hatch> ascii gui :)
<rick_h_> ncurses
<rick_h_> urwid is the python lib to help make it usable
<hatch> cool I didn't know about that
 * rick_h_ shakes head at the idea of someone that never installed debian/ubuntu using the text installer
<rick_h_> jcastro: is winning, cli deprecation goes on and on
<hatch> rick_h_ Well my first version of Ubuntu was Warty so I'm pretty sure I used the text installer :)
<rick_h_> hatch: ah ok then it was curses based cli 
<rick_h_> do a server install sometime and get to see it
<rick_h_> but anyway, yea quickstart curses for getting going is coolness
<hatch> kind of caught me off guard because I remembered the cli q/a version :)
<hatch> I was like....woah what's this? haha
<rick_h_> man that same tests fails every other run in CI. 
<rick_h_> Makyo: that test failure is spurious. heads up :/
<Makyo> Boo, okay.
<hatch> rick_h_ it's in a different test this time :/
<rick_h_> hatch: it's been that one for the last 4 or 5 times it's failed I've seen it
<hatch> ohh I saw it in a few others 
<rick_h_> hatch: it's always that IE10 setHTML error
<hatch> it's odd how it says there are so many failures but there is just the one
<hatch> and yes it's always the setHTML error but I've seen the same error in different tests
<rick_h_> hatch: hmm, went back through last 4 failures and it's always that test and always that error
<hatch> really? I thought that it showed up in others...maybe I was mistaken 
<hatch> well at least then maybe we can track down the issue
<rick_h_> hatch: yea
<hatch> oo this looks cool http://www.indiegogo.com/projects/fin-wearable-ring-make-your-palm-as-numeric-keypad-and-gesture-interface
 * rick_h_ runs out for lunch today, biab
<Makyo> Ugh, finally.
<benji> rick_h_: I have some questions about this bundle search task; do you have a minute?
<rick_h_> benji: sure thing
<benji> rick_h_: I'll make a hangout
<rick_h_> thanks
<bac> benji: would you be able to review charmworld promulgation fix?  https://codereview.appspot.com/65550043
<benji> bac: sure, one sec
<benji> bac: looks good
<bac> cool
<bac> benji: i also killed that annoying message from enqueue, telling you all of the branches it was skipping.  hope you don't miss it.
<benji> there goes my Saturday night
 * rick_h_ sends cookies to bac 
<bac> we even had a test to ensure the output was sufficiently annoying
<bac> benji: do you need a review?
<benji> bac: nope (unless your name is marcoceppi <hint> <hint>)
<marcoceppi> benji: yes, swamped, will have it reviewed today
<benji> bac: once you're ready for a new task I have one for the bundle searching things
<bac> benji: i am.  what you talking about?
<bac> benji: i was thinking about quickly doing the normalizing to lowercase one
<benji> bac: well I'm trying to figure out the make-bundles-appear-in-search-results-when-one-of-their-charms-is-searched-for, so you can help me with that or...
<bac> benji: did you get a clearer idea of what to do?
<bac> benji: but i'm glad to talk about it
 * bac beverage run
<benji> that's cool, another quick one (and one of the top-two in priority) is makeing "bundle(s)" return all the bundels (and "charm(s)" return all the charms if you are in a giving mood)
<benji> yeah, I know what, I'm trying to figure out how now
<rick_h_> benji: one note, the next deploy we need to bring up a new charmworld unit to replace the bad one running in prodstack
<rick_h_> benji: at that time, we could bring up a new unit and wait for the index to update (the 30min) and then switch over
<rick_h_> benji: it draws out the deploy, but reduces that downtime issue without an index
<benji> ah, good thinking
<Makyo> jujugui tiny review and QA! https://github.com/juju/juju-gui/pull/134
<Makyo> Though... hmm.
<rick_h_> Makyo: looking ... or not
<Makyo> rick_h_,  take a look and see if that passes.  It can be incremental.
 * Makyo makes follow up card.
<bac> benji: quick call?
<rick_h_> Makyo: seems ok here. What's missing?
<Makyo> rick_h_, the fix works around the fact that relations in the vis and relations in the bundle have the same dom id.
<Makyo> Added a card to ensure unique dom ids.
<rick_h_> oh!
<bac> benji-cito: https://plus.google.com/hangouts/_/calendar/Z2FyeS5wb3N0ZXJAY2Fub25pY2FsLmNvbQ.t3m5giuddiv9epub48d9skdaso
<rick_h_> gotcha, cool
<Makyo> But this will be a good increment.
<rick_h_> Makyo: is this something we can add a test for? or some sanity check for future reference? Or if the dom ids were unique we'd not hit this issue so that's the root cause/fix
<Makyo> rick_h_, the latter, yeah. I'll make that my next card, and that part will be testable.
<rick_h_> Makyo: cool thanks. :+1:'d the current branch
<bac> rick_h_: can you join benji and me in the hangout above?
<rick_h_> bac: joining
<bac> so benji i will start on the bundly one
<benji> bac: ok, I guess I'll do the lower-case-all-the-things one
<bac> benji: and i added your face to the pumpkin colored card
<benji> heh
<bac> i guess we can kill it now?  we have cards for the required items
<rick_h_> bac: +1 it was there to evaluate what we could/should do. 
<rick_h_> I'm out. Have a good night all. 
<benji> yeah
<Makyo> jujugui this stupid IE10 CI thing is really biting me.  Anyone have any hints?
<lazyPower> Makyo: What is this IE10 CI thing? I've got some experience with automated browser testing thanks to my last job
<rick_h_> Makyo: grrr, not yet. It was something hatch could not reproduce locally so his branch went on
<rick_h_> Makyo: and now it's annoying everyone 
<Makyo> lazyPower, "Error: Object doesn't support property or method 'setHTML'", but unable to repro locally.
<rick_h_> Makyo: the key thing for retrying is to remove the comment in the pull request that's Status: merge request accepted
<Makyo> Oh, okay.
<rick_h_> Makyo: that causes the lander to not try to load it again
<rick_h_> so just delete that comment and it'll retry
<Makyo> Aha!
<rick_h_> putting a card up for cleaning up this, must be some way to test
<Makyo> There we go.
<marcoceppi> rick_h_: do you have a few seconds for a hangout with regards to promulgated charms and me about to make a mess of that?
<rick_h_> Makyo: there's some notes in the CI doc for the future
<rick_h_> marcoceppi: sure, sec
<Makyo> rick_h_, cool, thanks.  Will rtfm next time :)
<rick_h_> marcoceppi: hangout?
<rick_h_> Makyo: all good, I cheat by writing it so I know the tricks
<marcoceppi> rick_h_: https://plus.google.com/hangouts/_/7acpja2hqsviddhvokd1jo82pc?hl=en
<rick_h_> marcoceppi: sec, fighing the 'not allowed' get your google account right mess
<rick_h_> Makyo: yay
<rick_h_> I watched it so of course not it passed
<Makyo> Woo!
<Makyo> Alright, dogs walked, quick errand, then I'll get the dom ids.
<marcoceppi> rick_h_: you still around?
<rick_h_> marcoceppi: kinda
<rick_h_> marcoceppi: what's up?
<marcoceppi> rick_h_: ah, don't mean to be a bother, re-promulgated heat to ~openstack-charmers but the API is still reporting ~charmers as the approved version. Wasn't sure how long to wait (been about 45 mins since re-promulgation)
<marcoceppi> http://manage.jujucharms.com/api/3/search?name=heat&type=approved&series=precise
<rick_h_> marcoceppi: did you unpromulgate the other?
<marcoceppi> good question
<rick_h_> marcoceppi: hmm, don't see the new one at all atm http://manage.jujucharms.com/api/3/search?name=heat
<rick_h_> marcoceppi: so give it a bit more
<marcoceppi> rick_h_: will do
<marcoceppi> wasnt sure if the API was updated at every injest or not
<rick_h_> marcoceppi: what's the full path? ~openstack-charmers/precise/heat? http://manage.jujucharms.com/api/3/charm/~openstack-charmers/precise/heat ?
<marcoceppi> since it was a re-promulgation, I didn't first unpromlugate (since all promulgate does is set the canonical branch for the source package in the distro)
<marcoceppi> es
<rick_h_> k
<marcoceppi> yes*
<marcoceppi> https://code.launchpad.net/~openstack-charmers/charms/precise/heat/trunk
<rick_h_> ruh roh...damn
<rick_h_> marcoceppi: http://manage.jujucharms.com/heartbeat
<marcoceppi> it shows as mapped to lp:charms/heat
<marcoceppi> rick_h_: I don't know what that means, it says PASS to me
<rick_h_> marcoceppi: looks like ingest has run off the rails
<rick_h_> Ingest queue sizesPassqueued charms: 18537, queued baskets: 1740.
<marcoceppi> OH CRAP
<marcoceppi> that's a lot to ingest
<rick_h_> heh, pass is "the queue is loading"
<rick_h_> not that "it's not shrinking and getting caught up like it should"
<rick_h_> marcoceppi: will have to look into the queue issue tomorrow. Sorry, will ping when we get it updated/straighted out
<marcoceppi> rick_h_: np, thanks!
<rick_h_> marcoceppi: no vangaurd and such in webops atm. Sorry for the issue
<rick_h_> but that explains it not loading
<marcoceppi> yeah, that makes a lot more sense
 * marcoceppi has become accustomed to the 15 min turn around
<rick_h_> yea, when it works it's kind of nice :)
#juju-gui 2014-02-19
<hatch> good evening
<rick_h_> party
<rick_h_> how goes the mountain hatch ?
<hatch> oh I never went to the mountain
<hatch> I went to the lake instead, but I'm back now
<hatch> plans for the mountain fell through :/
<rick_h_> oh, thought I heard something about boarding
<rick_h_> ah, gotcha
<rick_h_> welcome home
<hatch> thanks, I've been to the mountains 3 times this year already so I figure it's not so bad that the 4th was canceled :)
<rick_h_> good stuff, took the fam out to the local little ski hill this week
<rick_h_> think I'm going to get some skis here next month when they have end of year sales
<rick_h_> try to get some lessons next year
<rick_h_> or the way this winter has gone, look into cross country sking
<hatch> ahh awesome, yeah we have been thinking of getting into that too, there are a bunch of trails around here, and...well anything to help me get less fat
<hatch> lol
<rick_h_> hah
<hatch> I see you're on the debug log email train
<hatch> so I'll stay out of that one :)
<rick_h_> yea
<lazyPower> Do you guys know where i can find the recipes for the quickstart images? I'm looking specifically for the preseeds or cloud init scripts we're using to get juju installed on the base image.
<marcoceppi> rick_h_: it definitely happened, it just too a while to happen (re: migration to openstack-charmers)
<rick_h_> marcoceppi: oh yea? 
<marcoceppi> yeah, queue is down to only 3k this morning too
<rick_h_> lazyPower: quickstart images?
<rick_h_> marcoceppi: hmm, I show 37k
<rick_h_> baskets (bundles) is 3k
 * marcoceppi rubs crap out of eyes
<marcoceppi> oh yeah, there is an extra didget in there
<rick_h_> I got logs from webopsn so we'll see today. but yea it does look like it goes down some
<rick_h_> so glad it's processing for you somewhat, just on major 37k delay
<rick_h_> luca__: there's both a monday and friday catch up calls?
<luca__> rick_h_: yes because stuff might happen over the weekend... :P
<luca__> rick_h_: I've just put them in as place holders
<rick_h_> luca__: ok
<rick_h_> just checking :)
<luca__> rick_h_: I set a call up today to discuss stuff
<rick_h_> luca__: ok
<luca__> rick_h_: I had a meeting with Mark this morning at 9am, he signed off Machine View :D
<rick_h_> woot!
<rick_h_> go go go before he changes his mind :)
<luca__> haha
<luca__> I've already told him I'll be passing it on this week for implementation
<luca__> it's all locked and we aren't planning to show him any more designs on i
<luca__> it^
<rick_h_> cool
<rick_h_> bac: morning
<bac> hi rick_h_
<rick_h_> bac: charmworld's gone boom. I'm getting an email ready. I've got a morning full of calls until the standup in a bit so wanted to see if I could handoff. 
<bac> yes, please
<bac> manage, i assume
<rick_h_> yea
<rick_h_> I'll have the email out in a couple of min. logs attached
<bac> boom in what regard?
<bac> oh my, look at those queues!
<rick_h_> heh, well it was over 30k this morning
<rick_h_> email waay
<rick_h_> away
<rick_h_> bac: I will say that marcoceppi's stuff did eventually ingest overnight. So the queue is getting processed, but I think all these issues finding charms and empty bzr branches is causing a slow down perhaps? 
<rick_h_> or the revision fetching code to go haywire. Not sure off the top of my head
<bac> rick_h_: i don't know what of marco's stuff you're referring
<rick_h_> bac: sorry, this came up because marco was submitting charms that were not ingested after 30 or so minutes last night
<rick_h_> they did eventually, but only after going throughthe queue all night
<rick_h_> bac: so the queue is 'working' for some definition, but it's getting waaaaay backed up
<bac> yes, our history fetching is subpar
<rick_h_> the logs have some interesting stuff, but didn't jump out at me what happened. Might need to check if there's been anything going on the juju store side
<bac> we know it is not good but haven't spent the time to fix it since it will be going away.
<rick_h_> yea
<rick_h_> have to limp her along for another 8mo or so though
<bac> it seems the queuing job could look into the db to see if an older revision exists and simply not queue it if it does.  by definition, old revisions are immutable so why refetch them?
<bac> this looks bad: 2014-02-19 01:43:25 [24559] [CRITICAL] WORKER TIMEOUT (pid:2310)
<bac> 2014-02-19 12:00:02,921 WARNI [charm.review][MainThread] lp_credentials path doesn't exist: "/home/webops_deploy/charmworld/charmbot_credentials.txt"
<bac> deploy problem
<rick_h_> bac: want to try to push for our new unit today then?
<rick_h_> bac: jacekn was helping me on vanguard
<bac> rick_h_: i want to investigate a little before we lose the current bad state
<rick_h_> bac: k
<bac> rick_h_: i'm also a bit unclear of the steps for the unit swap.
<bac> if we bring up another charmworld instance, talking to the same mongo and es, won't they be clobbering one another?
<rick_h_> bac: yes, but they should be clobbering with the same data for a short time
<rick_h_> bac: maybe we can stop the queue in supervisor on the current running instance first
<bac> actually we could just stop the ingest process on the existing unit first
<rick_h_> so that it's just serving as pure read-only
<rick_h_> right
<bac> yep
<rick_h_> and then bring up the new unit, flip the dns to the IP addresses on the new unit for m.j.c
<rick_h_> and then take down the old unit after dns updates
<rick_h_> in theory at least
<bac> rick_h_: it could be that we have too much work to do in the time alloted.  the timer pops with items still in the queue.  when the process is restarted it just adds to the work and then we're doomed.
<bac> upon ingest process restart we should use the --clear option to start from scratch.  though, if our period is too short we'll never finish.
<rick_h_> bac: right, but I'd expect to see fewer errors/issues with that. The queues just back up but still go. 
<rick_h_> bac: we can test it out and see. Can we add another worker to the queue processing side? 
<bac> i don't see a lot of unexpected things in the logs except the CRITICAL timeout i pasted
<rick_h_> all the charms not found and no files in the charm is normal? /me hadn't realized that had gottn that way
<bac> rick_h_: oh, those errors may be tied to the other issue, the lp_credentials not found
<bac> those could be private branches that cannot be read by lplib in anonymous mode
<rick_h_> bac: ah ok
<bac> rick_h_: jace found the credentials to be empty and was going to restore them.
<bac> rick_h_: i propose we have him kill and restart the ingest process, which will clear the queues, and then monitor them to see what happens.  note that staging is processing just fine.
<rick_h_> bac: rgr, sounds good thanks
<bac> rick_h_: queues reset on m.j.c and processing at a reasonable rate.  will keep an eye on things
<frankban> guihelp: I need one review + QA for https://codereview.appspot.com/65970043 (quickstart branch in preparation for new release). Is anyone available? thanks!
<rick_h_> frankban: looking right now
<frankban> thanks rick_h_ 
<bac> rick_h_: turns out the last deploy installed an old crontab file for charmworld.  the queueing process is getting run two different ways, thus ingest can never keep up.
<bac> rick_h_: this a direct result of RT 67228
<rick_h_> bac: arg, yea thanks for the diagnosis. 
<rick_h_> at least it's something we know about I guess. Time to press to get that fixed. 
<gary_poster> fixing deploy of charmworld to make it sane was something we he've had on the list
<rick_h_> so combo of lp creds not there and double ingesting ever cycle
<rick_h_> yea, the RT has been in progress, just haven't gotten the fix that is noted as needing to happen...to happen
<bac> rick_h_: yeah.  so they think creating a new unit of charmworld is the fix?
<rick_h_> all the work on what's wrong and how to fix it has been done
<rick_h_> bac: yes, the RT notes that after talking with juju-core that unit is fubar now 
<rick_h_> bac: and the only fix is a fresh one
<bac> rick_h_: so should i wait for deej and get him to make it happen?
<rick_h_> the issue is something with how IS is using the git support in juju to track changes from the original charm to handle upgrades
<bac> rick_h_: and will subsequent deploys need this unit replacement dance?
<rick_h_> bac: I'd see if deej is going to be around, but if not we really need to find someone to make the fix. 
<rick_h_> bac: I don't think so. I believe that once this damanaged unit is replaced, we're back on normal track
<rick_h_> but I'm assuming that IS is stopping whatever put it in this bad state to start with
<bac> rick_h_: jace is no longer vanguard.  mjc is now cowboyed to be in a happy place.  perhaps we can work with the next vanguard or deej to get the proper fix from the RT deployed.  this issue is wasting lots of our time.
<rick_h_> bac: +1
<rick_h_> bac: let me know if you find out if deej is around and if I need to ping someone higher up to get the fix out
<rick_h_> around today that is
<bac> he is not yet here.  gary_poster is deej us/east?
<gary_poster> bac yes
<bac> us/fredrickburg
<gary_poster> yup
 * rick_h_ checks directory
<bac> cool;
<rick_h_> bac: and not away in holiday list so give it a bit and let's see if we can track him down :)
<rick_h_> frankban: LGTM + QA ok thanks!
<frankban> rick_h_: great thank you
<frankban> uhm, note to myself: remember to check the landing lane before running "lbox submit"...
<lazyPower> rick_h_: apparently i was referring to the jujuredirect project
<lazyPower> i found the scripts I was looking for though. Thanks for following up
<rick_h_> lazyPower: cool
<bac> rick_h_, gary_poster: deej is in the house and we're working on it now
<bac> rick_h_: are you aware of what orange squad has been doing with putting dependencies in a swift/s3 bucket rather than in the charm dependencies?  deej just brought it up saying that's the new preferred way to provide static dependencies.
<rick_h_> bac: no, I'm not aware. 
<rick_h_> bac: I know we had an issue with our charm size being too big at one point
<rick_h_> not sure if there was a trick to work around that we had to go through?
<rick_h_> luca__: is there a hangout for the meeting? I don't see one in the calendar invite
<luca__> rick_h_: I shall add one!
<rick_h_> luca__: ty
<marcoceppi>  aweee yeahhh it's phone time
<marcoceppi> hah, I'm in the wrong room, but now you guys know I'm on the phone
<rick_h_> marcoceppi: lol
<hatch> lol
 * hatch needs to figure out a way to speed up his lxc machine creation
<marcoceppi> hatch: ask hazmat, he had some crazy btrfs stuff that made lxc creation lightning fast
<hatch> that I'll do, 10m+ is too long
<hatch> rick_h_ I created a new bug card which needs to be fixed before release for Project 1 but I can't move it to urgent...it keeps putting it in high so I'm leaving it in Project 1 for now
<rick_h_> hatch: ok sounds good
<rick_h_> thanks for the heads up
<hatch> it would sure be nice if the GUI told you what 'stage' the new machine was at...
<hatch> even if it just said 'waiting for machine' and 'running hooks' :)
<Makyo> jujugui call in 10
<rick_h_> hatch: heh, yea on the radar
<hatch> rick_h_ yeah I know....I've been running on real environments for the past little while so I'm noticing all the little 'nice to have's' that we don't see when usingthe sandbox :)
<rick_h_> hatch: yep, that's what got me thinking on it as well
<rick_h_> during charm development when I was bringing up new machines and wanted to know when I could get at the logs
<rick_h_> e.g. after it's brought up, juju is running on it, etc
<gary_poster> we got push back on that before
<rick_h_> yea
<hatch> gary_poster haters gona hate :)
<gary_poster> :-)
<rick_h_> jujugui call in 2
<hazmat> hatch, marcoceppi its on http://github.com/kapilt/juju-lxc ... its not polished yet the way the juju-digitalocean provider plugin, ie. it has setup that needs to be done manually.. but its what i use everyday.. and can do 50 containers in an env in under a minute offline... hoping to come back to it in march to polish and socialize, but if you need a 5m intro.. i'd be happy to walk through
<rick_h_> hazmat: howdy, wanted to check for standup on reviews and commit bits for frankban on deployer?
<hatch> hazmat thanks I'm pretty swamped today but I'm definitely interested so I'll be in touch
<rick_h_> hazmat: we're getting releases together for MWC and would like to be able to close up the bugs for jcastro for the bundle marketing. 
<hazmat> rick_h_, i'm switching tracks to it now.. i'd rather skep the standup, and do the work.. ie.  should be done in next 2hrs.
<rick_h_> hazmat: rgr, thanks
<hatch> benji so what technique did you use to get it to pass the gjslint? I've tried a few different things and no such luck
<Makyo> jujugui anyone else receive a message thanking them for downloading a Landscape trial?
<hatch> nope
<gary_poster> no
<Makyo> Huh!  Oh well.
<hatch> you were h4x0r3d
<rick_h_> hatch: is the scope kind of nuts?
<hatch> rick_h_ well I even tried assigning something to it right away and it's still complaining
<hatch> so I don't know wth is going on
<rick_h_> hatch: push the branch up, I'll pull it down and see what it does here
<hatch> rick_h_ ok just trying one more thing first
<rick_h_> hatch: rgr
<hatch> rick_h_ https://github.com/hatched/juju-gui/tree/upload-inspector-drop I even tried assigning a value to startTheApp right after it's assignment and it still thinks it's unused 
<benji> hatch: I transformed the code from "var foo;\nfoo = bar" to "var foo=bar;"
<hatch> benji hmm yeah I tried that too
<hatch> sonofa
<gary_poster> ...hippopotamus?
<hatch> lol
<hatch> now THAT is a new one
<gary_poster> surprise and delight, that's what we're after.  At least one of 'em, anyway.
<rick_h_> hatch: which file? lint passes here
<hatch> ugh
<hatch>  /vagrant/test/test_startup.js:25:(0133) Unused local variable: startTheApp.
<hatch> well ok I guess I'll just leave it then
<rick_h_> hatch: hmm, yea push it up with a pull request and see if CI dupes
<hatch> ok well I just want to write a few more tests then will do
<Makyo> What versions of gjslint?
<Makyo> (forget if those are locked down)
<frankban> juju-gui: new quickstart 1.1.0 released on the juju stable PPA and on PyPI. New features include: support juju-core 1.18, get admin-secret from juju-generated jenv file, use existing ssh-agent if possible + minor fixes to code and documentation
<gary_poster> yay!!!
<rick_h_> frankban: woot! you up for doing a small blog post on the jujugui blog? I'll link it from the twitter account. 
<Makyo> rick_h_, I think it should autotweet blog posts now
<frankban> rick_h_: will do
<rick_h_> Makyo: oh awesome
<rick_h_> frankban: thanks
<rick_h_> Makyo: hatch yea, it's a python package that's in the archives so should be version locked
 * frankban bbiab
<hatch> ubuntu on air is starting now
<rick_h_> hmm, wonder if that'll load on my phone
<hatch> it should
<hatch> it's just yewtewbe
<hatch> http://www.youtube.com/watch?v=gGG_GHYzSLs
<hatch> ^ rick_h_  that's the url to the youtube stream (which hasn't started yet)
<rick_h_> hatch: yea, works in chorme beta on my phone but not chrome stable on the tablet
 * rick_h_ is trying to watch while cooking some lunch wheee
<hatch> ahhhh
<hatch> blarg now I'm getting a ton of test failures surrounding the index.html file.....:/
<rick_h_> did you break your environment hatch? :P
<rick_h_> stale branches lead to too much fun
<hatch> I might have....but the diffs don't show that there are any changed files which could cause this
<hatch> argsaurce
<rick_h_> happy to test it out if you push up again
<rick_h_> see if I can dupe or if it's your setup
<hatch> I think I'll push and then delete the entire branch and reclone
<rick_h_> l
<rick_h_> k
<rick_h_> one of those characters
<hatch> lol
<hatch> ok apparently deleting that directory also made it re-build the vagrant image
<hatch> not cool
<hatch> hah
<rick_h_> uh, ok
<hatch> today is not my day apparently
<rick_h_> heh, what is your setup so I don't dupe it? :)
<rick_h_> is vagrant all vbox still?
<hatch> yeah
<rick_h_> hmm, in my research it seems the worst VM tech on osx these days
<hatch> parallels is the bet, but their Ubuntu support is absolute shit
<hatch> and the same goes for their support
<hatch> it's only $100....not like you would expect ANY support for that
<rick_h_> yea, I was going to get fusion pro which I was reading is the best
 * hatch isn't bitter at all
<rick_h_> :/
<hatch> their support is all 'reply with canned responses' bs
<hatch> it's like "thanks, I can read the FAQ too"
<hatch> we have a lot of deps
<hatch> haha
<hatch> rick_h_ yeah my env must have been busted somehow. it now passes lint just fine
 * hatch blames python
<rick_h_> hatch: heh, glad it's playing nice now
<hatch> cool hangouts now tells you 'your next meeting is starting now'
<rick_h_> yea, kind of neat
<Makyo> jujugui small review. QA is everything works w/ bundle vis and environment (no change in behavior, just ensuring unique ids) https://github.com/juju/juju-gui/pull/135
<rick_h_> Makyo: cool, looking
<rick_h_> Makyo: some failing tests?
<Makyo> Boo. Worked here..
<rick_h_> seems legit
<Makyo> Let me dig in, may have had a .only left over
<Makyo> Ah, yeah.  Crap.  Sorry.  1sec.
<hatch> rick_h_ 1:1 time?
<rick_h_> hatch: linky
<hatch> pmd
<Makyo> rick_h_, https://plus.google.com/hangouts/_/calendar/Z2FyeS5wb3N0ZXJAY2Fub25pY2FsLmNvbQ.ji7urs3vqfdc7f3nnbk33hh67s?authuser=1
<rick_h_> Makyo: cool, one sec
<bac> rick_h_: update: mjc is processing charms/bundles like a champ.  i've asked deej for an update as to the status but heard no reply
<bac> nothing was added to the RT
<rick_h_> bac: thanks was watching that. Yay for working but :/ for communication
<rick_h_> bac: thanks for tracking that all day
<bac> rick_h_: could be busy, lunching, etc.  i'll check again before eod
<rick_h_> bac: cool thanks
<bac> benji: at your leisure could you look at https://codereview.appspot.com/65920045/
<bac> it is mighty small
<benji> bac: sure
<benji> I'll take a look now.
<rick_h_> Makyo: +1 ty
<benji> bac: I thought that card was about making the search strings "charms" and "bundles" (with or without the "s") return all of the charms/bundles.
<rick_h_> benji: +1
<bac> benji: well, yes, we *could* do that.
<bac> benji: and due to popular demand i think i will
<bac> benji: wait here...
 * benji opens up a newspaper and leans agains the wall.
<bac> benji: we should be able to do both.  our current search is broken, as there is apparent support for using 'match_all' if no search term is given to return all results.  but it does not work.
<bac> if it worked, then 'bundles:' would return all bundles but 'bundles:mysql' would return only bundles with mysql
<benji> bac: I would think you could just tweak what you have to do the kind search alone if there is no ":" and following string
<bac> benji: but 'match_all' should work and be tested
<hatch> new leankit UI coming up http://leankit.com/blog/2014/02/leankits-update-ui/
<rick_h_> looks cool
<rick_h_> was playing in the backlog today
<hatch> I was looking at Trello for us
<hatch> and I can't really see anything it does better than lk
<hatch> at least for our typical workflow
<rick_h_> yea the ability to do images and docs is cool
<rick_h_> but we'd have to do several boards 
<rick_h_> i use it for my personal stuff but not sure it'd scale for the team
<hatch> yeah my thoughts exactly
<Makyo> I use trello for other projects.  Easy to get used to multiple boards.  But yeah, LK is fine for us.
<Makyo> Though the update makes it look like trello :P
<rick_h_> lol
<hatch> well it can't look much worse than it does now.... :D
<hatch> my only real complaint to it is that it could use some performance improvements
<hatch> it tends to lag if it's open for a day
<Makyo> I liked that performance improvement blog from Trello, actually.  That was a neat way to attack the problem.
<hatch> yeah it was pretty cool
<hatch> so many issues people have had to deal with becasue they dont' use YUI events :)
<Makyo> It's almost like you really like YUI or something
<hatch> actually I'm trying to find alternatives because I don't feel like they are trying to improve it any more
<hatch> but nothing else exists that takes care of all of the event issues people have
<hatch> I'm hoping they surprise me but I have heard that the YUI team is being pulled to work on other Y! projects all the time
<hatch> one really cool thing we could take advantage of is to start writing ES6 modules and then 'build' them into YUI modules
<hatch> which is not supported
<hatch> s/not/now
<hatch> jujugui I accidentally cloned my juju-gui repo using https and now I need to push back up, anyone know if I can tell it to use the ssh keys?
<hazmat> hatch, remove remote.. add new one with ssh
<Makyo> or remote set-url
<hatch> hazmat ahh good one thanks
<hatch> jujugui lf a review/qa for https://github.com/juju/juju-gui/pull/136 it will require a real env being spun up
<hatch> dont' everyone jump up at once :D
<hatch> the tests passed.....does that help? :)
<rick_h_> hatch: hah, might try to look at it tonight at the coffee shop
<hatch> jujugui lf a review/qa for https://github.com/juju/juju-gui/pull/137 qa can be done in sandbox
<hatch> rick_h_ thanks, anything you'd like me on for the rest of the day?
<rick_h_> hatch: want to peek at that safari test failure?
<rick_h_> would be cool to include safari support in 1.0
<hatch> sure thing
<rick_h_> hatch: or that damn IE test failure
<rick_h_> hatch: that one will get you cake from teammates
<hatch> lol, the intermittent one?
<rick_h_> hatch: but yea, just anything in the high maint for now I think
<rick_h_> hatch: yea, the one that took Makyo 4 landing attempts to get through yesterday
<hatch> ok I'll take a look at that one
<rick_h_> thanks
<hatch> I have now blocked the high lane, so someone HAS to review my branches :P
<rick_h_> lol, yea I'll look at them either tonight or in the morning. Should have you unblocked then
<hatch> oh I'm not blocked....everyone else is lol
<hatch> and my latest branch just failed because of that ie failure hah
<hatch> I was able to reproduce locally though so that's good
<hatch> odly enough it's in help-dropdown.js ....
<rick_h_> hatch: yea, but it's in the mask bits and it started when you added drop mask support
<rick_h_> hatch: so I have a feeling there's some mask collision/race conditoin there between the two
<hatch> well actually, it shouldn't work at all
<hatch> it should throw the error 100% of the time
<hatch> haha
<hatch> hmm interesting...
<hatch> jujugui anyone still around want to help me sanity check something?
<Makyo> hatch,  sure.
<hatch> Makyo ok switch to a fresh develop branch
<Makyo> (is this the help-dropdown thing? Because I couldn't repro after I ran updates)
<hatch> in app.js:846 put a debugger statement
<Makyo> Okay.
<rick_h_> marcoceppi: why for I get hangout things from you? Are you trying to send me messages?
<hatch> and then in test_app put a .only on 719
<hatch> and then put another debugger in help-dropdown.js:91
<hatch> now....when you run the tests using test-server (in chrome is fine)
<hatch> when you hit the app.js debugger you should run Y.one('#help-dropdown') and it'll give you `null`
<hatch> then when you hit the debugger in help-dropdown run this.get('container')
<hatch> it will be the rendered template somehow?
<hatch> it 'should' be null because it was set as null on instantiation
<Makyo> Maybe Null isn't what we want?  The default container is a <div> Node, but you can override this in a subclass, or by passing in a custom container config value at instantiation time. If you override the default container in a subclass using ATTRS, you must use the valueFn property. The view's constructor will ignore any assignments using value.
<Makyo> </quote>
<hatch> well null definitely isn't want we want, but it's null because the Y.one('#help-dropdown') returns null because the element doesn't exist...
<hatch> I'll look into the view source
<hatch> sec
<Makyo> #main is indeed empty.  Did you mean to instantiate something there?
<hatch> ahhh I think I found it...http://yuilibrary.com/yui/docs/api/files/app_js_view.js.html#l347
<hatch> it looks like if a container is falsy then it makes a new one from a '<div/>' string
<Makyo> Yyyyeah.  That's the part I quoted.  It's expecting a Node, per the docs.
<hatch> the question is....why does it sometimes have an element and sometimes not
<hatch> we can fix it pretty easily now that we know what the issue is....but why is there an issue there....it 'should' just create a div and be done with it
<Makyo> It is an empty div, for me.
<Makyo> this.get('container').getDOMNode() 
<marcoceppi> rick_h_: no, it's Google being crazy
<hatch> the only place it won't be is in IE......sometimes
<hatch> that's whats causing the failure
<Makyo> Yes.
<hatch> so what I'm saying is....I don't see why it doesn't create the element.....sometimes
<Makyo> Which is where we were at the start. :)
<hatch> basically the Y.Node.create('<div/>') is returning an empty object.....sometimes haha
<hatch> well I'm going to fix the instantiation code to solve this issue but I am really curious as to why it's failing
<hatch> ahhhh I figured it out
<hatch> it's a race condition between the mocking of Y.one() and the Y.Node.create() call 
<hatch> You cannot stub Y.One without Y.Node.create() failing see http://yuilibrary.com/yui/docs/api/files/node_js_node-create.js.html#l20
<hatch> Y.one()
<hatch> Makyo thanks for sanity checking that
<Makyo> hatch,  np
<rick_h_> hatch: wtf is 'launchpad' downloading 2gb for?
<hatch> rick_h_ not sure?
<hatch> I'm going to need some more information
<rick_h_> hatch: just launchpad has a progress bar says downloding 700mb of 2gb
<hatch> hmm link?
<rick_h_> and no idea what it's downloading. Nothing in there says what it is
<rick_h_> it's launchpad on the mac
<rick_h_> no link, just in my little app bar 
<hatch> ohhh
<hatch> I thought you were talking about launchpad.net
<hatch> :D
<rick_h_> heh, no, looks like it's over a little star icon, imovie?
<hatch> if you open up App Store
<rick_h_> doesn't show anything in my app store app, but in the launchpad UI there's downloading
<hatch>  it should show your downloads
<hatch> hmm that's odd
<hatch> iMovie is a star
<hatch> so that could be it
<hatch> it showed all of the downloads in the app store for me
<hatch> but thenagain the app store software is a little bonkers sometimes
<hatch> so it might show up later lol
<hatch> rick_h_ hows the resolution?
<rick_h_> it's ok so far. Not gotten editors and such going
<rick_h_> just trying to get through setup, install updates, etc
<rick_h_> before heading to the coffee shop
<hatch> cool, well if you run into anything else odd I'll see what I can help :)
#juju-gui 2014-02-20
<hatch> jujugui looking for a quick review on https://github.com/juju/juju-gui/pull/138 to fix the ie test failures
<rick_h_> ls
<rick_h_> grrrr
<hatch> :)
<rick_h_> this is an annoying damn thing
<rick_h_> and vmware fusion is irritating, osx terminal is irritating
<hatch> rick_h_ get iterm
<rick_h_> yea? is it the thing to get 
<hatch> it's the best terminal app out there by far
<hatch> iterm2 actually
<rick_h_> k
<hatch> http://www.iterm2.com/
<hatch> and I haven't used fusion before....but I think that's what bac uses
<hatch> irc client...Textual (it's $2.50 or something in the app store)
<hatch> PCKeyboard Hack (for remapping the caps lock) and KeyRemap4MacBook for key remappings
<rick_h_> caps lock moved well enough
<rick_h_> heh, irc is ssh to my server and irssi
<rick_h_> I'm there :)
<rick_h_> fusion says it's 'sharing' the drive but it's empty on the guest
<hatch> BetterTouchTool for better gesture support
<rick_h_> so :P lying software
<hatch> haha
<hatch> Caffeine so it doesn't go to sleep all the damn time
<hatch> and umm
<hatch> I think that's all the suggestions I have
<rick_h_> k, thanks
<hatch> Skitch for screenshots and sharing (Evernote companion app)
<hatch> oh and go and get Xcode started downloading
<hatch> you'll need it for things like `make`
<rick_h_> yea, got xcode
<hatch> oh and you'll probably want open pgp
<hatch> but maybe not if you don't add email to osx
<hatch> I use Postbox for email because it has pgp support as a plugin but it's $10 so if you don't plan on using osx a whole lot then might as well just stick with email in Ubuntu
<rick_h_> yea, mutt cli ftw
<hatch> eww lol
<rick_h_> woot, finally figured out how to show hidden folders so I could install my fonts
<hatch> ohh yeah that
<rick_h_> pita
<hatch> sorry I forgot about those things
<hatch> there should be an off switch to the 'idiot mode' that they start in lol
<rick_h_> now if I could just figure out how to share folders with this ubuntu instance I could get the gui up and running :/
<rick_h_> and review/qa your branches
<hatch> nfs?
<hatch> ohh wait
<hatch> use vagrant
<rick_h_> no, not that desperate
<hatch> you'll be up and running in no time
<rick_h_> but it blew up on you today
<hatch> yeah but that's the first time in months
<hatch> just DO NOT run two vm software at the same time...it'll kernel panic and crash :)
<rick_h_> lol
<hatch> I did that today haha
<hatch> I probably do that once a week lol
<hatch> but really the vagrant images are just so easy to use
<rick_h_> hmm, ok might look at it if I can't figure it out I guess
<hatch> when I get some free time I'll set up our vagrant images to use nfs 
<hatch> because the virtualbox fileshare is pretty slow
<hatch> but it's good enough for now
<hatch> I'm running #137 again to see if it passes CI because it's failure was the intermittent one
<rick_h_> cool yea
<rick_h_> it's nice to have a fix for that
<rick_h_> make sure you've got a card for that
<hatch> created friday card
<rick_h_> k
<hatch> rick_h_ given up yet and gone with vagrant? :)
<rick_h_> heh, not yet
<rick_h_> did a reboot, gotten the dock cleaned up, fonts better, and colors tweaked down
<rick_h_> now if only I could get this drive share...
<hatch> what font did you go with?
<rick_h_> I'm a liberation mono fan myself
<rick_h_> ok, ssh works to the vm so we're in business
<rick_h_> rsync ftw
<hatch> interesting...I use source code pro heh
<rick_h_> yea, guy here is promoting that one
<hatch> it's a well done font, easy to read
<hatch> although sometimes having those serif's would be nice
<rick_h_> meh serif
<hatch> but it reads well even without them
<hatch> Makyo wrecked me - he educated me why text has serifs
<hatch> (don't look it up unless you also want to be wrecked)
<rick_h_> been there done that
<rick_h_> it's for print
<rick_h_> I don't believe in serif for lcd/computer displays
<hatch> well no it's so that your eye can move from one character to the other easily across a single line
<rick_h_> right, but look into it. It's intended for a print medium. 
<hatch> https://github.com/blog/1778-webhooks-level-up
<hatch> hmm interesting maybe I'll have to read further into it
<hatch> oh quickstart you rock
 * hatch would love it even more if he could provide git branch info for the gui :)
<rick_h_> /juju-ui/version.js
<rick_h_> done
<hatch> hah wut?
<rick_h_> http://gui.ip.address/juju-ui/version.js
<rick_h_> that's the git hash info
<rick_h_> and the git branch info is from the config
<rick_h_> juju get juju-gui
<hatch> `juju quickstart -e amazon -gui="github.com/hatched mybranch"` 
<hatch> is what I mean
<rick_h_> oic
<hatch> just save me a step in the future is all
<hazmat> frankban, ping
<frankban> hey hazmat 
<hazmat> frankban, two items.. first via time machine.. do you remember the openstack dashboard work you did? 
<hazmat> that integrated juju gui
<frankban> hazmat: yes I do
<hazmat> frankban, do you happen to have a screenshot of it?
 * hazmat is digging through email from late 2012
<hazmat> frankban, the other item, was the unit-errors branch.. i didn't really understand why the separate feedback mechanism... and the whole watcher handler functions returning callbacks on env seems a bit strange.
<frankban> hazmat: looking, but I don't think I have a screenshot, code is here: https://bazaar.launchpad.net/~juju-gui-peeps/juju-gui/horizon/files
<hazmat> frankban, thanks
 * hazmat looks for 2fa dev
<frankban> hazmat: the watcher/API layer is still generic. it just allows for injecting semantic. We need a way to react to unit errors in different ways (e.g. just log them, or raise an exception as soon as a unit is found in an error state (which is precisely the current default behavior). That's just a functional approach (pass a function that is called on errors), allowing us to customize the watcher behavior: the importe
<frankban> r layer seems still decoupled from the API to me, it just provides some logic
<hazmat> frankban, how is that different then the feedback mechanism on deployments?
<hazmat> which was put in place for this exact same reason (handle errors vs warnings differently)
<hazmat> depending on usage mode
<frankban> hazmat: ISTM the feedback collects messages, errors and warnings, and then code can use the feedback to react to collected messages. here we have a slightly different use cases. we have unit errors, and we need to customize how those are handled. e.g. the default deployer behavior is to exit as soon as possible if a unit is in error, without waiting for all the other entities to be started. in that case the fact we
<frankban>  are logging errors is incidental, the goal is to exit the application asap. from he guiserver perspective, we instead want to log errors but still keep on watching the other units until they are started or in error.
<frankban> hazmat: so we need a way to tell to the watcher: please keep watching, do not raise UnitErrors, just notify them to me an d I'll handle them in the way I like. in this scenario, the watcher is a middleware: it has access to the watch, and it is provided on_error logic (as a function) from the caller
<hazmat> frankban, that aspect is fine.
<hazmat> where things go strange to me is  the defaults funcs in the watchers as callback generators on env, instead of just passing a feedback style object.. the env isn't really a place to handle that logic imo, its for env manipulation not policy. i'd like to keep the behavioral customization of handling feedback policy on the deployment. 
<frankban> hazmat: yes that's unfortunate, but it seemed required to me given the watcher data differences between go and python juju implementations. the log callbacks are closures storing a reference to the env because of that. even before the change that logging code was in the env.wait_for_units for the same reason IMHO. if we want to push that forward, we can just expose a units2errors method on the environment and have 
<frankban> the callback itself call logger.error on the messages returned by that method. it is doable, I ended up with just using the logger stored in the env for practicality. as I said, that code was already on the env, I just moved it in a separate method
<hazmat> frankban, the python env impl is going to be deleted, not supporting it would have been fine.
<hazmat> frankban, fair enough
<hazmat> frankban, is the usage code here juju-gui/server/guiserver/bundles ?
<frankban> hazmat: cool, that would simplify things. we can simplify the callbacks once py support is removed
<frankban> hazmat: yes. I need to add a small change to that code given the introduction of deployer.guiserver.get_default_guiserver_options
<frankban> hazmat: bundles/base.py is where the deployer is imported and used
<hazmat> hmm.. yeah.. i don't see any feedback customization there 
<hazmat> its still expecting errors
<frankban> hazmat: deployer/guiserver.py customizes Deployment._handle_feedback
<hazmat> frankban, ic that but its still based on error passing which is fine, the base usage is guarding against impl
<frankban> hazmat: no juju-horizon screenshot here, sorry
<hazmat> frankban, no worries. thanks for looking. still thinking through the branch and looking for 2fa 
<hazmat> frankban, i guess merge as is is okay, would you mind fixing up the merge errors to trunk, the alternative i can find is adding config options to the watch class ie ignore_states, error_states etc, but i don't see anything in the mp that would cause issues for the gui on a refactor later.
<frankban> hazmat: great, I'll merge trunk and push then
<hazmat> frankban, cool, thanks
<frankban> hazmat: thank you for the review! are you in europe?
<hazmat> frankban, no.. just bad sleep schedule post capetown
<frankban> hazmat: oh :-/
<hazmat> well today actually it was toddler wake up call at 4am. it happens.
<rick_h_> babby hours! :)
<frankban> hazmat: branch pushed
<frankban> rick_h_: http://jujugui.wordpress.com/2014/02/20/juju-quickstart-1-1-0-released/
<rick_h_> frankban: awesome thanks! Looks like it auto hit the twitter account as well
<frankban> cool
<hazmat> frankban, merged and released 0.3.2
<frankban> hazmat: awesome! thanks
<frankban> weird that launchpad does not show that
<hazmat> frankban, i push to pypi
<frankban> hazmat: I know, I mean, https://code.launchpad.net/~juju-deployers/juju-deployer/trunk does not show the revision, and https://code.launchpad.net/~frankban/juju-deployer/unit-errors/+merge/206967 does not consider it merged...
<hazmat> frankban, oh.. i hadn't pushed master.. the rel is out on pypi though
<frankban> hazmat: yeah I see, thanks
<frankban> bac: morning, I'll be working on the charm to include deployer 0.3.2 and integrate guiserver changes. when you have time, could you please take a look at how to update juju-quickstart in trusty?
<bac> frankban: sure
<frankban> thanks
<bac> frankban: so both j-deployer changes are merged?
<frankban> bac: yes
<bac> frankban: excellent.  no forky
<frankban> bac: moved the cards, yeah exactly
<bac> ty
<bac> frankban: for clarification, the card about updating in trusty is only relevant for post-freeze changes, right?
<bac> post-freeze / post-release
<frankban> bac: not sure, rick_h_ ? ^^^
<rick_h_> bac: well james handled getting us submitted into universe. I'm not sure how we make sure that updates 
<rick_h_> freeze is today, so we'd like to get this new 1.1 release as the frozen trusty version
<rick_h_> bac: so maybe check with james page on if we need to do anything 
<rick_h_> bac: and then post-freeze I'd assume we'd fall under the juju ppa and keep updates in there unless they're security related. 
<bac> rick_h_: will do.  but my understanding of the card was to document what we do after release.
<bac> sure we can make PPA changes but other non-security changes could potentially be submitted
<rick_h_> bac: ah ok. That sounds cool, we've also got the initial task of making sure we're in the release I guess
<bac> here is the Stable Release Update (SRU) explanation, in case you're interested.  i'll summarize its affect on us somewhere:  https://wiki.ubuntu.com/StableReleaseUpdates
<rick_h_> bac: and jamespage was working on trying to shepard us into main vs universe
 * rick_h_ loads
<bac> rick_h_: ok
<rick_h_> bac: thanks for the link. This will definitely be useful over the 14.04 support cycle.
<bac> rick_h_: getting an SRU is, rightfully, a painful and frightening experience.  let's try to avoid it.
<rick_h_> bac: definitely, I don't think we've got anything that would jump out as a big security issue but that's about all I can think of atm. 
<gary_poster> only sudo usage. :-P
<rick_h_> gary_poster: as an attack vector?
<gary_poster> yeah
<rick_h_> good point. And we shouldn't need it for trusty. Maybe it's worth a freeze exception to be able to go back and remove it once 1.18 hits for 14.04
<hazmat> 1.18 seems required for 14.04
<rick_h_> yea
<rick_h_> they were saying within 2ish weeks
<rick_h_> if that's true we'd have the ability to drop sudo usage from quickstart for the lifetime there. 
 * rick_h_ notes to look into filing a freeze exception
<gary_poster> +1
<rick_h_> frankban: up for 1-1 today? 
<frankban> rick_h_: sure
<rick_h_> frankban: https://plus.google.com/hangouts/_/canonical.com/rick
 * frankban lunches
<benji> rick_h_: there is a fly in the lower-case search ointment: the search corpus contents are returned via the charmworld API so if we lower case, e.g., the name of the charm then the search results in the GUI will include the improperly cased charm name
<rick_h_> benji: ummm...suckiness
<gary_poster> another field, I guess?
<rick_h_> yea, we're back at the multi field setup
<benji> we /could/ look up each charm in the search results and substitute in the data in the mongo db
<rick_h_> benji: but could we add two fields to ES, raw_name and name or something?
<rick_h_> or the other way around I guess. name and indexed_name
<benji> yeah, we considered that at the outset but it looked a bit like the internal structure of charm world really wanted a one-to-one mapping from charm/bundle data to ES field.  Not that it would be impossible to do, it may just take more refactoring than we initially thought
<rick_h_> right, ok. So we can either expand that, or go back to ES having the multiple indexes on a single field you mentioned yesterday?
<rick_h_> benji: any idea on which path seems most sane at this point?
<rick_h_> benji: and do you think either are landable before the EOW and you leave next week?
<rick_h_> (and MWC starts on monday)
<rick_h_> benji: we can chat in hangout and do 1-1 when you've got a sec?
<benji> rick_h_: I am leaning slightly toward the {type: "multi_field"} appraoch right now mainly because it is the way the ES people suggest doing this (this being case insensitive search on otherwise unanylized fields)
<rick_h_> benji: rgr, that sounds reasonable to me
<benji> rick_h_: I can hang out when you're ready
<rick_h_> benji: https://plus.google.com/hangouts/_/canonical.com/rick
<rick_h_> hatch: let me know when you get in and we can go over the qa on your branch
<rick_h_> hatch: I've got the running env up and can get you access to peek at it
<hatch> rick_h_ yeah please do, I can't reproduce your issue
<hatch> jujugui a small hack I put together last weekend http://fromanegg.com/post/77277923553/juju-gui-google-hangouts-proof-of-concept
<benji> very cool hatch 
<hatch> :) thanks 
<hatch> I'm going to email it to canonical tech see if anyone else has any input on it
<BradCrittenden> hatch: looks very cool
<hatch> thanks bac 
<frankban> hatch: great, so, can you use the GUI/ change the environment from inside the hangout?
<hatch> frankban you bet, it's a fully functional gui
<frankban> hatch: cool
<benji> I had thought of something similar, but the other way around, instead of putting the GUI in hangouts I though of using twilio browser client to do in-app voice chat between users 
<hatch> benji cool, my first attempt was to integrate a Hangout into the GUI but their api doesn't allow that (at least yet)
<benji> interesting
<hatch> integrated twilio would be cool though, I didn't know hey had a peer to peer api, I thought it was only phone
<benji> hatch: you might also be interested in https://togetherjs.com/
<benji> yeah, they have iOS, Android, and browser integration now; pretty cheap too, 0.25 cents per minute
<hatch> ahh cool 
<hatch> yeah I've seen togetherjs - it's kind of reproducing what we are doing with the gui heh
<benji> a bit, yeah; I was specifically thinking about the per-user mouse cursors.  It would be very nice to be able to voice chat (integrated or not) and be able to see the other person's cursor
<hatch> yeah that would be very cool
<frankban> guihelp: is anyone available for reviewing/QAing https://codereview.appspot.com/63570048 (gui charm)?
<benji> bac: when doing the initial review of your branch yesterday I noticed a regex tweak you could do, but it is proably too late now, so for future reference:
<benji> the regex was '^\s*(bundle|charm)[s]{0,1}:(.*)'; the "[s]{0,1}" part could be replaced by "s?"
<bac> benji: thanks.
<bac> benji: i've got bigger fish to gore
<benji> heh
<hatch> rick_h_ found the bug thanks - I'll have to also check in IE because it's a MIME issue (again) 
<rick_h_> hatch: rgr, thanks!
<bac> i was just complaining about the internet dropping out a lot here.  my karmic reward?  the water has gone out.
<hatch> lol
<hatch> I'd much rather have the internet go out than the water :)
<rick_h_> bac: time to move? You know we could melt you enough snow to fill your water pot here
<bac> rick_h_: ship some down here.  it'll melt on its own.
<rick_h_> bac: let me know when you've got 1-1 time if your interwebs work 
<hatch> rick_h_ do you still have that env up?
<rick_h_> hatch: yep
<hatch> could you put a debugger in app.js:_determineFileType() and let me know what the dataTransfer.types object is?
<hatch> plz and thanks
<rick_h_> second, otp
<hatch> every time I see that I think "On The Potty" :D
<rick_h_> hey, that's still a good excuse
<hatch> lol true, but in that case you should probably be concentrating on something other than IRC lol
<hatch> rick_h_ Ie10 bug https://bugs.launchpad.net/juju-gui/+bug/1282633 prioritize as you will
<_mup_> Bug #1282633: Clicking service name on icon does not open inspector in IE19 <ie10> <juju-gui:New> <https://launchpad.net/bugs/1282633>
<bac> rick_h_: free now.  you got a hangout space?
<rick_h_> bac: yea, on the calendar link. Did you get the invite?
<rick_h_> https://plus.google.com/hangouts/_/canonical.com/rick bac 
<bac> rick_h_: no
<frankban> http://python.org has a new look and an interactive shell, seems cool
<hatch> kewl
<hatch> every browser has an integrated shell for JS :P
<frankban> lol, well... not all browsers IIRC
<hatch> haha ok 
<frankban> rick_h_: re the "Improve jenv login message (subdivide; see description)" in the maintenance lane: isn't that already done?
<rick_h_> frankban: so it notes a few parts. One of which is a change to juju-core. Was that completed already?
<rick_h_> jujugui call in 10
<frankban> rick_h_: yes the fix is in core trunk
<rick_h_> frankban: ok, yea if everying in the notes there then please move that off to releaseable.
<frankban> rick_h_: ok cool I'll move the card
<rick_h_> jujugui call in 2
 * hatch pokes rick_h_  for that object :)
<rick_h_> hatch: redeploying the gui on the updated branch. Will be a sec
<rick_h_> hatch: you pushed your update right?
<hatch> nope
<rick_h_> :)
<hatch> I just need to know what it is so I can write the proper test
<hatch> like what the chrome dev shows as the object 
<rick_h_> oh, well right now it's deploying the gui and about to get a juju set to your branch again
<hatch> oh ok :)
<rick_h_> right, heh will be a few min
<gary_poster> biab: lunch and such.  have a 1 PM call so will be back by then
<rick_h_> hatch: what am I looking for?
<hatch> rick_h_ could you put a debugger in app.js:_determineFileType() and let me know what the dataTransfer.types object is?
<rick_h_> ["Files"]
<hatch> perfect
<hatch> thanks
<rick_h_> ok, destroying
<hatch> wait
<hatch> wait
<hatch> wait
<rick_h_> oh...not
<hatch> :)
<rick_h_> okie
<hatch> ok if it was ["Files"] then it should work...
<hatch> what about...
<hatch> dataTransfer.items
<rick_h_> DataTransferItemList {0: DataTransferItem, length: 1, remove: function, clear: function, add: function}
<rick_h_> kind: "file"
<rick_h_> type: "application/zip"
<hatch> hmm odd
<hatch> it should definitely work then
<rick_h_> working now
<rick_h_> but this is on the apple :/
<rick_h_> doh
<hatch> lol!
<rick_h_> let me go back to my desktop
<hatch> :D
<rick_h_> bah, trying to sneak lunch in by working from the kitchen counter :)
<hatch> haha sorry
<rick_h_> dataTransfer.types
<rick_h_> ["Files"]
<rick_h_> DataTransferItemList {0: DataTransferItem, length: 1, remove: function, clear: function, add: function}
<hatch> :/
<hatch> but it doesn't work?
<rick_h_> kind: "file"
<rick_h_> type: "application/zip"
<rick_h_> right, it download
<rick_h_> downloads
<hatch> ok umm
<rick_h_> this is linux on chrome-dev
<rick_h_> Resource interpreted as Document but transferred with MIME type application/zip: "file:///home/rharding/Downloads/ghost-charm-master/ghost.zip".
<rick_h_> in the console
<hatch> can you put a debugger in showInspectorDropNotification() and see if that method gets called?
<rick_h_> yes, it's hit
<hatch> ok and one more
<rick_h_> and completes successfully
<rick_h_> though I don't see the mask
<hatch> you won't, it's transparent
<rick_h_> appDragOverHandler() fileType is 'zip'
<hatch> can you put a debugger in the callback in _attachInspectorDropMaskEvents to see if the drop event is fired
<rick_h_> loading
<rick_h_> no, the drop event is not hit
<rick_h_> it's a race there isn't it? to create the mask, watch for drop, while the user is dropping?
<rick_h_> hatch: want a hangout with screenshare to help?
<hatch> yeah sure
<hatch> if you're done lunch
<rick_h_> heh, for wimps
<hatch> lol
<hatch> https://plus.google.com/hangouts/_/7ecpj3q3mtp6andr7ra00j83es?hl=en
<hatch> rick_h_ ^
<hatch> you left me :(
<hatch> lol
<rick_h_> heh, hangouts crashed hard
<hatch> I'll fire up a vm with stable and see what I can do
<rick_h_> now when I go back it says to install the plugin
<rick_h_> hatch: cool thanks
<hatch> yeah it does that sometimes when doing screenshares in Ubuntu
<rick_h_> bac: email inbound if you get a few min to look through. 
<bac> ok
<rick_h_> hatch: Makyo wasn't there talk about not exporting the Gui when you do an export?
<rick_h_> did we ditch that for some reason? or am I not remembering?
<hatch> hmm
<hatch> thre was talk
<hatch> I can't remember now....I think it was decided that there shold be the option
<hatch> should*
<rick_h_> it's come up today and I'm trying to think if there's a reason not to. The one thing I can see if that if you use quickstart or deployer via cli on a new env you won't have a gui ootb
<rick_h_> though quickstart will
<rick_h_> yea, the option would be best, but is there a good reason to not default to not exporting it?
<rick_h_> if you quickstart deploy you'd get a gui on node 0, otherwise you might already have a gui
<hatch> depends if your exporting for a bundle or exporting your environment
<hatch> your environment includes the gui
<hatch> a bundle likely wouldn't
<rick_h_> right, but even if you export your env is it a pain to not have the gui there?
<rick_h_> in the export itself
<hatch> maybe if you have it configured
 * hatch is just being the devils advocate 
<rick_h_> definitely, please do
<hatch> I'd say it's easier to remove it form a bundle
<hatch> than to miss it from a env export
<rick_h_> so the only config I can think of that'd be 'environment' required would be the charmworld url?
<hatch> yeah probably right....but it's a lot easyer to remove something form the bundle than have to manually add it back in 
<hatch> easier even
<hatch> man I can't type today
<hatch> you may have subordinates on the gui maybe?
<rick_h_> oh hmm, that's interesting
<hatch> that would make it extra complex to re-create manually
<rick_h_> the story of jujucharms where the gui is the environment center
<rick_h_> I just feel like the 80/20 rule says 80% of the time leave it out 
<hatch> well it really depends what they are using the export  button for
<hatch> I'd almost say it's the other way around
 * rick_h_ goes back to the email
<hatch> because it goes back to that it's a lot easier to remove it from a bundle export than to add it back into an environment export
<rick_h_> how so? because you have to know the syntax/charm path?
<rick_h_> hmm, I guess I see. 
<hatch> because of the potential configurations
<hatch> yeah....Iunno, I'm for leaving it in until we get a configuration option
<rick_h_> k, thanks for talking me out of it :)
<rick_h_> I'll check/create a bug. Something that's come up a couple of times now. 
<hatch> haha :)
<hatch> ok back to work now from lunch
<luca__> rick_h_: hey, what does http://www.cohesiveft.com/ do?
<luca__> rick_h_: is it purely security and networks?
<rick_h_> looking
<luca__> rick_h_: thanks, the I'm at an event and the CTO is giving a talk, I'm not really following but wondering if there is some overlap with Cohesive and Juju, for possibly user testing.
<rick_h_> luca__: possibly. It looks like they're layering and wrapping docker containers. 
<rick_h_> which juju is a level above docker and bcsaller_ was playing with wrapping docker in juju
<luca__> rick_h_: ah
<rick_h_> looks like some software networking bits in their image there 
<luca__> rick_h_: yeah, I was wondering if I should talk to him possibly for network view user testing
<rick_h_> actually they look like a network tooling company
<hatch> looks like they could be a competitor maybe?
<bac> rick_h_: done with the doc.  i went ahead and made some small changes in place
<hatch> man their website is confusing....
<luca__> hatch: yeah hehe
<bac> rick_h_: looks nice
<hatch> luca__ rick_h_  if I were to take a guess, i'd say they provide software to connect cloud machines into your own network....not sure where the docker bits come in though
<luca__> hatch: I see, they need a better website
<luca__> hatch: and maybe a better offering :D
<rick_h_> bac: thank you much!
<rick_h_> hatch: luca__ yea, it looks like they're a software network tool provider and they've extended to proviing their tools on top of cloud providers to compete with amazon virtual private clouds
<hatch> luca__ lol, well maybe the offering is good....they need a better landing page explaining their offering :D
<rick_h_> so they'd be a network layer in juju
<rick_h_> luca__: so yea, I'd say they might be interested if their network layer tools work on things like openstack, etc
<luca__> rick_h_: I see
<luca__> rick_h_: I have a word
 * hatch ... that moment when tests pass which should fail
<luca__> lol
<hatch> Makyo what did you use to record your gui vids?
<hatch> rick_h_ bleh I found another issue with the local charm upload in FF that we cannot get around - quick hangout to chat about direction?
<rick_h_> hatch: sure thing
<hatch> https://plus.google.com/hangouts/_/72cpivunma60m4l9aimlgkks78?hl=en
<hatch> rick_h_ ^
<Makyo> hatch, Audacity and recordmydesktop.  May change with the air, though, depending if there's a better solution there.
<hatch> Makyo I just tried using Screenflow on OSX and even at $100 it's not very well done
<hatch> pretty buggy
<Makyo> Boo :/
<hatch> it's touted as the best though which isn't saying much
<hatch> it has some great features, don't get me wrong, but the bugs wreck it
<Makyo> hatch, Used to use http://www.techsmith.com/jing.html# at the library on win/OS X
<rick_h_> techsmith is a local place. 
<rick_h_> used to use their camtasia stuff back in the day
<hatch> hmm I'll check that out
<hatch> there appear to be some reasonable video editors as well
<hatch> maybe the Ubuntu software has matured enough now...
<Makyo> I've had pretty good luck with kdenlive
<Makyo> For my talk thing I used imovie though, since I only had that on the plane.
<hatch> cool cool
<hatch> http://www.techdrivein.com/2013/09/top-5-video-editors-for-ubuntu-linux.html
<Makyo> Oh, I'd forgotten about Lightworks
<Makyo> Cinelerra never did work for me.
<hatch> funny that lightworks is for windows and linux ....not osx hah
 * bac curses kernel upgrade and vmware
<bac> but, happily we have water again
<rick_h_> bac: yay water
<rick_h_> running away, night all
<hatch> cya
<hatch> hey rick_h_  if you appear tonight, I have pushed the fixes to the inspector drop branch buuut it looks like Ubuntu chrome has the issue that we were seeing on dev too
<hatch> I'm not entirely sure how to work around it...
<rick_h_> hatch: k, so the missing event
<rick_h_> hatch: let's drop the mask then, just go for straight drop target to get this wrapped up tomorrow 
<rick_h_> hatch: and we can look again in a bit 
<hatch> rick_h_ well the mask is the drop target, else we need to make every element in the inspector a drop target
<hatch> the only sollution I can think of is to extend the timeout
<hatch> but that's still going to hope they move the moose at least every 500ms :)
<hatch> moose....hah
<hatch> rick_h_ https://code.google.com/p/chromium/issues/detail?id=112409 :(
<hatch> I guess that's just going to be a bug in Chrome then...
<hatch> rick_h_ if you could star the issue - maybe they fix more stars first :)
<hatch> I'm going to add a comment that it's still an issue
<hatch> I'll increase the timeout and add this url to the code - but that's the best we can do 
#juju-gui 2014-02-21
<rick_h_> hatch: ugh, ok let's chat in the morning and get a plan together
<hatch> +1
<rick_h_> our brains need to rest a bit tonight :)
<hatch> hah rick_h_  I think the CI is stuck
<rick_h_> looking
<hatch> I'm not entirely sure what it's even running
<rick_h_> all good, killed it. It's done that once/twice before
<rick_h_> just login and you can stop the in progress job
<hatch> ohh ok cool thanks
<gary_poster> so long everybody!  I'll miss you. :-)
<rick_h__> morning
<hazmat> rick_h__, g'morning
<rick_h__> hazmat: still an early bird? little ones not sleeping in for you yet?
<hazmat> rick_h__, today was all me.. up at 2 sore throat, and lots to do.
<rick_h__> ugh, /me sends some meds down your way
<rick_h__> morning hatch 
<hatch> morning
 * benji_ takes the car to the shop.
<hatch> rick_h__ so thoughts on upping the timeout and putting that chrome bug link?
<rick_h__> hatch: yea, let's chat. I've got a few notes to run through
<hatch> ok coffee is on, 2 mins
<hatch> :0
<hatch> :)
<rick_h__> doh
<rick_h__> ok, shoot me a link
<hatch> bleh it's taking forever https://plus.google.com/hangouts/_/76cpjp39uok6fu53clukspafeg?hl=en
<rick_h__> hatch: I can dupe :(
<hatch> that seems like a blocker, no?
<hatch> :(
 * hatch was really hoping it was his branch
<rick_h__> hatch: it means it goes to 'feature flagged' :/
<rick_h__> so we can still release pretty relation lines for MWC demos 
<rick_h__> and they can demo in chrome ok
<hatch> do we want to 1.0 without local charms?
<rick_h__> no, it'll have it, just not public. We won't blog/etc it
<rick_h__> but the MWC people can demo it
<hatch> I am not sure pretty relation lines are 1.0 worthy :)
<rick_h__> yea, true I guess
<rick_h__> so maybe it's just another rev, but we need a release for MWC
<hatch> no offence to the pretty lines of course :D
<hatch> oh yeah I totally agree
<rick_h__> hatch: any chance you can look at that today and work on the upgrade afterwards?
<rick_h__> hatch: if it's a quick fix maybe we can get it in a release today for monday?
<hatch> yep I can, although frankban  wrote it, he might be faster if he has the bandwidth
<hatch> if not, I can get on it 
<rick_h__> we know the upgrade story will take on
<rick_h__> but created #1283067
<_mup_> Bug #1283067: dropping a local charm in Firefox does not deploy it into the sandbox <juju-gui:Triaged> <https://launchpad.net/bugs/1283067>
<rick_h__> frankban: do you have the time to peek at this bug and see if there's a quick fix we can get today for release? ^
 * hatch grabs his coffee
<frankban> rick_h__: yes I'll take a look
<rick_h__> thanks frankban 
<hatch> cool, 
<benji_> rick_h__: I had hoped sleeping on it would provide more insight, but I can't get the multi-field indexing approach to work (well it doesn't break anything but it doesn't do what we want), so I'm afraid doing this quickly is a bust.  We need to learn more about ES.
<rick_h__> benji: ok, did you and bac get a chance to catch up yesterday?
<rick_h__> benji: he's going to be out Mon/Tues so if we can get that doctype search working for Monday deploy that'd still be a partial win
<benji> since he was going to be out early next week I figured if I got this working it would have to be someone else so I didn't talk to him.  I wasn't aware that I would be taking his branch.
<rick_h__> yea, understood. 0/2 for monday 
<benji> rick_h__: I bet I can figure out his branch though; should I pick that up next?
<rick_h__> benji: I was just looking to see if he pushed up anything before he left
<rick_h__> I'm not seeing anything other than his https://code.launchpad.net/~bac/charmworld/improve-bundle-search/+merge/207290
 * benji looks
<rick_h__> benji: if you can run with it and get that up and going I'd appreciate it. I can get a charmworld deploy done monday and that would be nice to have
<rick_h__> benji: yea, see how far you can get. I might be able to run with it some this weekend so let's make sure to catch up before your EOD and hangoff to me. 
<benji> rick_h__: that doesn't look like the latest code.  He asked me to review that branch on Wednesday and I noted that it didn't actually do what the card was about.  He then began working on it some more.  I can take it from that branch (or perhaps start over, since it isn't on-target) but it'll be rework.
<rick_h__> benji: yes, understood. It'll be rework and can't be helped without delaying into Wed or later next week in which case we'll miss the MWC demo time this was asked specifically for. 
<benji> will do
<rick_h__> thanks
<hatch> rick_h__ we are going to have to parse the zip contents - on a real env we would need to store the zip filename in the annotations otherwise
<hatch> so unfortunately that part is kind of an all-or-nothing approach
<rick_h__> hatch: what's wrong with the annotation? I'm confused
<rick_h__> benji: one heads up, when brad and I talked the one thing that came out was that the api search and the website search are two code paths
<rick_h__> benji: and that a "" search in the api returns all results
<hatch> well they get sent along with every request, so it bulks up the requests and it's pretty clunky
<hatch> at least imho
<benji> yep
<rick_h__> while that did not seem true on the website search
<rick_h__> benji: cool
<rick_h__> hatch: ok, well it was on the roadmap for the feature anyway
<hatch> which?
<rick_h__> hatch: the zip to help find service by name not zip filename
<hatch> ohh yeah - I'm hoping that the sandbox api can be repurposed
<hatch> I'll look into that first
<rick_h__> hatch: but let's make sure we shortcut, if we dont' have any local charms in the env we can skip it still
<hatch> oh yeah for sure
<rick_h__> k
<rick_h__> friday is not liking us today is it
<hatch> this week has just been frustrating all over :)
<rick_h__> yea, suppose so
<hatch> I need an idea for a Go lang project
<hatch> get my head outa js for the weekend
<rick_h__> heh, I'll send you my list over
<hatch> haha I'm looking for small projects
<hatch> maybe a week of personal time sort of things
<hatch> benji what was wrong with your car?
<rick_h__> hatch: yea, charm proof would be a small something to check out doing. I was thinking of doing my small readable web service in Go as an experiment and test scale
<benji> it has a coolent leak (and needs some brake work)
<hatch> shitty, what kind of car?
<hatch> rick_h__ oh Go can handle scale :) 
<hatch> charm proof in Go? Isn't it written in python already?
<rick_h__> hatch: yea, just mean a good example project to 'port' and compare
<hatch> ohh gotcha
<hatch> that might not be a bad idea
<hatch> maybe I'll write a Bookie competitor in Go :P
<hatch> jk
<rick_h__> hey, more power to you
<hatch> it could be called Gookie
<hatch> lol
<hatch> rick_h__ http://nightwatchjs.org/ nodejs selenium driver api
<hatch> it 'looks' simpler than our python one
<rick_h__> hatch: hmm, but this is a selenium server and we use saucelabs for that
<rick_h__> https://github.com/beatfactor/nightwatch/issues/53
<hatch> oh shoot I misread
<hatch> I thought that it interacted with a selenium server
<rick_h__> it IS the server
<rick_h__> is how I read it
<hatch> well it does...but right heh
<hatch> teach me for not reading before sharing
<hatch> benji hey when you had your git rebase issues did you try creating a patch and applying that on a new branch?
<rick_h__> hatch: I tested things out. The key is that if you updated your branch to latest develop to do 'git rebase develop' and all your commits get layered nicely
<hatch> rick_h__ following along in #yui?
<rick_h__> hazmat: did that on https://github.com/juju/juju-gui/pull/139
<rick_h__> hatch: oh no, /me goes to look
<rick_h__> hatch: yea, use rebase when push upstream changes into topic branch
<rick_h__> that works nicely
<benji> hatch: I considered it, that may have even been the final solution; I can't remember exactly.
<hatch> rick_h__ well remember benji's issue with a bunch of wips and merges from develop
<hatch> I was hoping for a reasonable 'fix' and it looks like creating a patch file is the best
<rick_h__> yea, I mean I've done both. Created a new branch from develop and cherry pick. 
<hatch> rick_h__ so then what are we talking about re the rebase develop if you weren't following along in yui :)
<rick_h__> that went ok, but tedious
<rick_h__> no, I wasn't at the time
<rick_h__> I was just replying to your questoin to benji
<rick_h__> as it was something I wanted to test out and just had cause with the safari CI branch since it hung for a week there
<hatch> ohhh ok ok
<hatch> so you had commit commit merge commit commit ?
<hatch> and doing a rebase against develop removed the merge commit?
<rick_h__> so I updated my safari branch with latest develop first `git co develop; git juju-sync; git co $mybranch; git rebase develop
<rick_h__> it didn't remove it, it avoided it
<rick_h__> a merge commit is a merge commit. It's now part of the history
<rick_h__> hatch: so https://github.com/juju/juju-gui/pull/139 had a rebase on develop in there, two rebases for lint/etc during review. looks clean :)
<frankban> rick_h__, hatch: quick fix for bug 1283067 ready for review -> https://github.com/juju/juju-gui/pull/140
<_mup_> Bug #1283067: dropping a local charm in Firefox does not deploy it into the sandbox <juju-gui:Triaged by frankban> <https://launchpad.net/bugs/1283067>
<rick_h__> frankban: looking
<frankban> thanks
<hatch> rick_h__ so how did you get rid of the merge commit there then? the rebase on develop got rid of it?
<hatch> s/on/from
<rick_h__> hatch: you're saying to get rid of something taht exists
<rick_h__> I'm saying that you need to avoid the merge commit to start with by using rebase vs merge
<hatch> well in #139 it looks like you did
<hatch> there is no merge commit in there
<rick_h__> right
<rick_h__> I avoided it by doing a git rebase develop
<rick_h__> that's how I updated my long running feature branch
<rick_h__> hatch: follow? or am I still talking nuts?
<hatch> ok so you didn't 'merge' develop in...you rebased it in
<rick_h__> hatch: rgr
<hatch> me likey
<hatch> ok so from what I understand the 'best' way to fix benji 's issue is to use a patch and git 'should' ignore the parts of the diff that are unchanged in upstream
<hatch> but the proper way to do it is to rebase upstream in
<hatch> upstream in this case being develop
<rick_h__> hatch: right
<rick_h__> hatch: correct, you should be able to git rebase develop over and over in a long running branch safely, fixing conflicts between trunk and your WIP as you go
<rick_h__> jujugui call in 10
<rick_h__> frankban: yay works. Want me to :shipit:?
<frankban> rick_h__: yes thanks
<hatch> stupid browser differences
<hatch> frankban how did you figure out that that was necessary?
<rick_h__> hatch: there's a bug in zip.js called out in the code
<frankban> hatch: ff debugger + feeling lucky with google
<rick_h__> lol "I feel lucky, oh so lucky"
<rick_h__> nice diff to use that whitespace flag feature on as well <3
<frankban> yes indeed
<hatch> frankban ok cool :) I was hoping that there might have been some cool technique or something :P
<rick_h__> jujugui call now
<hatch> frankban have a quick second now to run through my questions?
<hatch> https://plus.google.com/hangouts/_/calendar/cmljay5oYXJkaW5nQGNhbm9uaWNhbC5jb20.t3m5giuddiv9epub48d9skdaso?authuser=1
<frankban> hatch: sure, be there in a minute
<frankban> hatch: I am there
<Makyo> rick_h__, you mentioned copying me on an email, but having a hard time finding it.
<Makyo> What was the subject?
<rick_h__> Makyo: sec, it was a document. Looking
<Makyo> rick_h__, oh, oops.  Will check.
<Makyo> There it is.
<Makyo> Sorry, got it :)
<rick_h__> Makyo: https://docs.google.com/a/canonical.com/document/d/1ma0U1ZxILTh5s3NoHiuwKiclRSxJLIY-Q2MEMzBO7Dk/edit
<rick_h__> Makyo: cool, adding the link to the card as well
<Makyo> Cool, thanks.
 * Makyo restart for updates.
<hatch> http://vimeo.com/58200103 
<hatch> anyone else excited to see pictures of Pluto?
<hatch> like 4 serious!
<hatch> :)
<rick_h__> we're getting pics of pluto?
<hatch> well in a year probably
<hatch> http://pluto.jhuapl.edu/index.php
<hatch> 9.5 year trip or something hah
<hatch> jujugui looking for a really quick review on https://github.com/juju/juju-gui/pull/141 no qa needed
<benji> hatch: I'll take a look
<hatch> thanks
<hatch> rick_h__ do you know where I can find the aforementioned charm-proof repo?
<rick_h__> hatch: it's in charm-tools
<hatch> ohh duh
<hatch> I'll take a look at the Go conversion....if you don't mind
<rick_h__> woot, got the ok for the 1.0 release go go 
<rick_h__> hatch: yea, definitely. 
<hatch> cool, I have no idea what will come out of it
<rick_h__> yea, just something small to tinker with
<hatch> so I just looked at it
<hatch> it's actually pretty sizeable
<hatch> once you include the scripts for actually parsing the stuff
<hatch> good couple thousand lines
<hatch> which is fine
<hatch> I had assumed it would be smaller for whatever reason
<rick_h__> now to play "run those functional charm tests!" 
<benji> to the tune of Play That Funky Music
<rick_h__> "get down and boogy and let functional tests pass"
<benji> lol
<rick_h__> boom and fail
<rick_h__> doh
<hatch> lol
<hatch> it seems anything with 'charm' in it blows up for us
<hatch> charmworld
<hatch> charm tests
<hatch> :P
<hatch> lets rename them to trinkets 
<rick_h__> ERROR empty image-stream in environment configuration
<rick_h__> ummm, ok
<hatch> uhh what
<rick_h__> yea, that's my thought
<hatch> Makyo new OneTab record here ....276
<hatch> and about 15 more tabs open lol
<rick_h__> Makyo: did you have a card today? Were you looking at the video or something else? 
 * rick_h__ was just kanban gardening while waiting for live tests wheeeee
<hatch> I found two really cool sublime plugins, gitgutter and git
<hatch> gitgutter shows the changes in your file in the line gutter
<hatch> and git gives you git commands in sublime
<hatch> sublime > terminal is kind of a pita when you only want to see diffs and stuff
<rick_h__> hatch: or Makyo able to help me test this please?
<hatch> sure what do you need
<rick_h__> preferably non trusty
<hatch> I have 12.04
<rick_h__> hatch: I pull down lp:~rharding/charms/precise/juju-gui/1.0 and see if you can make test including the live ec2 tests
<hatch> sure
<hatch> bzr checkout --lightweight should be the default :)
<hatch> bzr branch pssshhht 
<benji> rick_h__: ready for handoff?  I think all we need is review and QA and it'll be done.
<rick_h__> benji: sure thing
<hatch> rick_h__ running `make test`
<rick_h__> benji: https://plus.google.com/hangouts/_/72cpiv9f3hglut66ffdl7mq950?hl=en
<rick_h__> hatch: thanks
<rick_h__> hah, he runs make test and then loses his internet connection
<rick_h__> "thou shall not release!"
<hatch> rick_h__ https://gist.github.com/hatched/cba361ff581bf4d51a6d this is the error I get
<Makyo> rick_h__, sorry, yeah, video. Have IRC open on the wrong laptop :(
<rick_h__> hatch: did you run 'make sysdeps"
<hatch> nope i'll try that
<rick_h__> hatch: yea, run that first and then make ftest JUJU_ENV="ec2" or whatever your ec2 env is named
<hatch> unable to locate libpython-dev
<rick_h__> hatch: sudo apt-get install libpython-dev
<rick_h__> oh, you don't have it on precise?
<hatch> yeah that package doesn't exist
<rick_h__> looking
<hatch> what's the equivalent for precise?
<hatch> pffft python portability issues
<hatch> :P
<rick_h__> try just 'python-dev'
<rick_h__> but make sure you catch the rest of the sysdeps in the Makefile
<hatch> already the newest version
<hatch> will look at the other deps
<rick_h__> k
<rick_h__> sudo apt-get install build-essential bzr libapt-pkg-dev python-virtualenv rsync xvfb
<hatch> libapt-pkg-dev looks like it was missing
<hatch> will see if that was the issue
<rick_h__> k
<hatch> looks like that was the kicker
<hatch> whatever it's for
<rick_h__> hatch: cool, it'll run for a while hopefully
<hatch> well it apparently doesn't like my JUJU_ENV value
<rick_h__> hatch: right, it needs to be whatever you call your ec2 env in your environtments.yaml file
<rick_h__> I call mine ec2
<hatch> https://gist.github.com/hatched/cd5196ac5b83cc4bf231
<rick_h__> ok
<benji> rick_h__: I did some basic QA and it looks good.  Here's the MP: https://code.launchpad.net/~benji/charmworld/doctype-search/+merge/207738
<rick_h__> make ftest JUJU_ENV="amazon"
<rick_h__> benji: awesome, will look when I get this deploy up and done. 
<benji> cool
<hatch> ok will try that
<hatch> lol juju-test is missing now
<hatch> I'm just going to read this hacking file to see what I am missing
<rick_h__> lol ok
<rick_h__> yea you need charm-tools
<rick_h__> sorry, didn't realize you'd not messed with the charm
<hatch> not on this vm I guess
<hatch> best way to install charmtools?
<rick_h__> sudo apt-get install charm-tools
<hatch> installing from ppa now
<rick_h__> do you have the stable ppa?
<hatch> yay finally
<hatch> looks like it's starting the env
<rick_h__> yay
<rick_h__> benji: does this require the : or is it optional?
<benji> rick_h__: required; I figured the structure was a better way to go, but it would be easy to make it optional 
<rick_h__> benji: ah, see in the tests that they both work cool
<benji> well the bare words work, but if you have terms after the word you have to have a colon
<rick_h__> benji: well just 'bundle' works for all bundles in the test 
<benji> right
<rick_h__> right, the bare words are what I was worried about. That's the main use case
<benji> cool
<rick_h__> the : identifier is more advanced optional
<rick_h__> hatch: still running?
<hatch> yup
<hatch> there has been an error though
<rick_h__> :(
<hatch> https://gist.github.com/hatched/9143581
<hatch> doesn't give me any information as to what failed yet though
<rick_h__> yea, will have to wait for them to finish
<hatch> sorry my internet is very slow right now for whatever reason
<rick_h__> you had one 'ok' thuogh so that's more than me
<rick_h__> it takes a while 
<hatch> lol I'm guessing that 1.0 is not being released today? :)
<rick_h__> depends on what your errors say
<hatch> rick_h__ https://gist.github.com/hatched/a9f7df762c14e797fbc1
<rick_h__> hatch: what's your juju version? juju --version
<hatch> 1.17.1
<hatch> precise
<hatch> it's `juju version` btw :P
<rick_h__> heh
<hatch> that's the Go way
<hatch> lol
<hatch> unless they fixed that
<rick_h__> well --version works 
<rick_h__> it's what I've been using
<rick_h__> hatch: can you test one more thing then please? 
<rick_h__> can you stick that directory inside a directoy named precise and try to install it and check the unit log?
<hatch> oh ok they must have fixed it
<hatch> install it in a real env?
<rick_h__> yes please
<hatch> sure thing
<rick_h__> if the tests fail and the unit was in error it'd be helpful to find out what the error is
<hatch> bootstrapping
<rick_h__> I can't deploy right now, there's some issue core is looking into
<rick_h__> thanks
<hatch> lxc bootstrap is so much faster
<hatch> lol
<rick_h__> sorry to distract you. I'll start working on setting up a precise vm to work around the current issues
<rick_h__> heh no doubt
<hatch> no problem I needed a break from local charm anyways
<rick_h__> hatch: you can test it there as well I guess. Maybe it does error in lxc
<hatch> so you get me to deploy a local charm....damnnnn youuu
<hatch> lol
<rick_h__> lol
<hatch> ahh it's ok the ec2 setup is already running
<rick_h__> but if the tests says it's in error I need to know what error to try to see what's not happy in the charm
<hatch> yup I'll keep you posted
<rick_h__> thanks, /me goes to get a refill...come on EOD
<rick_h__> going to have to start my birthday party drinking early after today
<hatch> it's your bday?
<hatch> well why didn't you say something!
<rick_h__> tomorrow
<hatch> well then! Happy early Bday
<rick_h__> hah
<rick_h__> thanks, where's the wine?
<hatch> I'd say you could watch the USA Olympics hockey game tomorrow, but you guys lost :P 
<rick_h__> I hear it wasn't a very good game all around
<hatch> I haven't heard much except my friends who care about hockey texted me lol
<hatch> ERROR cannot repackage charm: symlink "tests/.venv/include/python2.7" is absolute: "/usr/include/python2.7"
<hatch> have you seen that before?
<hatch> running make clean
<rick_h__> make clean on the new copy
<hatch> ahh that appears to have fixed it
<hatch> rick_h__ 2014-02-21 21:31:15 INFO install     raise ValueError('Error: no releases found in the charm.')
<hatch> that would be an issue :)
<rick_h__> ok, so do me a favor. this is what I was thinking
<hatch> favour
<hatch> :P
<rick_h__> in the releases folder change the version from 1.0 to 1.0.0
<hatch> ok changing
<rick_h__> I wonder if that's what I'm hitting
<hatch> wait....do you want me to do that in the deployed one and retry? or from ground 0
<rick_h__> in the local copy and redeploy the charm
<hatch> alrighty
<hatch> will ping
<rick_h__> mv releases/juju-gui-1.0.xz releases/juju-gui-1.0.0.xz
<hatch> juju-gui-1.0.xz ?
<hatch> I've never seen that extension before
<hatch> odd
<rick_h__> its ok
<rick_h__> it's our special super compression extension. It's rare
<hatch> ohh ok :) what does it use?
<Makyo> xz :)
 * Makyo : jerk.
<rick_h__> http://tukaani.org/xz/format.html
<hatch> lol SORRY
<hatch> I'm doing three things at once here haha
<Makyo> It is 100% a Friday.
<rick_h__> friday release day!
<rick_h__> boom!
<Makyo> Woooo...ooo...oo~
<hatch> lol we said we would never do that!
<rick_h__> well it was supposed to be easy. I think the issue is I left off a .0 
<rick_h__> just hitting a juju bug causing me to not get passing tests
<rick_h__> if this works we're back in business
<hatch> rick_h__ started
<rick_h__> hatch: woot
<rick_h__> so now to rerun the tests for one final check
<hatch> oh kay
<hatch> runnning
<rick_h__> ty much
<rick_h__> hatch: have to run and get the boy from day care. Back in 20ish
<hatch> no prob
<hatch> I'll ping with the results
<rick_h__> hatch: getting some OK's ?
<hatch> yup rockin the ok's
<rick_h__> yay!
<hatch> not done yet though
<rick_h__> cool, all good
<rick_h__> thanks for the help
<hatch> rick_h__ passed with flying colours
<hatch> well...if the terminal wasn't black and white
<rick_h__> hatch: awesome, released
<rick_h__> thanks!
<rick_h__> we hit 1.0!
<rick_h__> now if ES on charmworld didn't go boom we might see it ingested sometime today :/
 * Makyo dogwalk
<hatch> rick_h__ maybe we need to invest some resources on getting GOOD at ES
<hatch> like a few books or something to some people :)
<rick_h__> hatch: yea, no kidding
<hatch> conveniently you're in the unique position to authorize such expenditures lol
<hatch> finally got the sublime gist plugin all configured properly on this machine
<hatch> yay
<Makyo> hatch, I nominate you to be the ES guru.
<hatch> Makyo my brain is running out of guru room
<hatch> lol
<hatch> it didn't have much to begin with
<Makyo> Just set YUI aside for a bit... :)
<hatch> haha it's been slowly sliding to make room for Go and Python
<hatch> I'm not sure if I can put ES in there, maybe tucked in a corner somewhere
<Makyo> Gooooo *fistshake*
<hatch> haha
<Makyo> Been tinkering with Coffeescript in freetime. I kinda like it.  I can see it being a maintenance nightmare for a large project, though.
<hatch> yeah it adds yet another abstraction from the real code which I'm not a huge fan of
<hatch> even experienced coffee users still think in javascript hah
<Makyo> Yeah.  Fun, but would make management hard.
<Makyo> Well, it still reeks of JS/.
<Makyo> It's not quite its own thing yet.
<hatch> lol
<hatch> this weekend I might try and create a juju gui sublime text plugin
<Makyo> How would that work?
<hatch> have all the make targets keybound :)
<hatch> `ctrl+j,l` could run the linter
<hatch> for example
<Makyo> Oh, hey, that could be neat.
<hatch> it has a 'build' option built in, but we need more targets than that
<Makyo> I just have multiple terminal tabs and use Ctrl+R :P
<hatch> the plugins are in python too so would give me some python practice
<hatch> haha yeah so do I lol
<Makyo> Yeah, that's cool.
<hatch> I found this good Git plugin which allows you do do all the git stuff with keybindings
<hatch> and it shows you the modified rows in the code
<hatch> I can now properly save a selection, file, multiple files, etc to a gist from sublime
<hatch> so with a quality juju gui plugin maybe I won't need to open the terminal
<hatch> lol
<hatch> the terminal is fast...but keybindings are faster :)
<hatch> Makyo you're a vim user, correct? With Gary gone am I now the only ST2 user?
<Makyo> I alternate.  Vim for JS/Coffee, alternate for Python, ST2 for Go.
<hatch> ahh with https://github.com/DisposaBoy/GoSublime ?
<Makyo> I think so?
<Makyo> 1sec.
<Makyo> Ahoor.
<Makyo> Shoot, I mean.
<Makyo> My copy of sublime expired.
<Makyo> I think that's it, though.
<hatch> cool
<hatch> I think it just gives you notifications now that it's expired unless you get a key
<hatch> it's been so long, I bought a key a while ago
<Makyo> This has happened a few times.  Works if I just redownload.
<hatch> ohh ok cool
<Makyo> Hmm, it may not be that package, not sure.  Mostly just used completion and the gofmt-on-save features.
<Makyo> Oh, yeah, it is that plugin.
<hatch> hah cool, I was looking for others but havne't found any
<hatch> so I was pretty interested
<Makyo> It works okay!
<Makyo> Better than go in vim, in my experience, but I didn't spend much time on that, since frankban and I were pairing at the time.
<hatch> ahh
#juju-gui 2014-02-22
<rick_h__> woot! it's alive
<rick_h__> deploying hatch's charm to a live ec2 env with Gui 1.0
<hatch> saweeeet
<rick_h__> finally getting around to final QA test
<rick_h__> lovely day this damn friday
<hatch> lol
<rick_h__> good news is 1.17.3 works and fixes my deploy issue :)
<hatch> nice
<rick_h__> ok, blog post up
<rick_h__> phew, now just have to qa benji's branch and we'll be all set for deploy-land on monday
<rick_h__> ooh, got the new kanban UI now
<rick_h__> hatch: we should have the series selector a drop down vs a free text
<hatch> think so? I was thinking radio button
<rick_h__> well it'd be 5 or so radio buttons and you can only pick one
<rick_h__> selector lets us have a good default
<rick_h__> and if you go into it, you see others
<rick_h__> without info overload of all of them listed for all to see
<rick_h__> added a card, we can chat on it next week.
<hatch> yeah, 5 series? 
<rick_h__> yea, right now
<rick_h__> it'll be about that I think. As new ones come out we should be able to deprecate the oldest
<hatch> I didn't think there would be that many
<hatch> precise, raring, trusty ?
<hatch> quantal
<rick_h__> yea, I mean realisticly it should just be 2 LTS, but then there will be other OSs and we do "support" a charm existing in any series between LTS
<hatch> maybe
<hatch> yeah true true
<hatch> I don't like selects
<hatch> they are slow
<hatch> :)
<rick_h__> but intentional in this case. Guide to the sane default
<rick_h__> make the exception harder :) 
<hatch> no slower than typing of course  lol
<rick_h__> pain to those that want to customize bwuhahahaha
<hatch> I don't think we have a styled select yet
<rick_h__> good reason to do one
<hatch> they are pretty involved
<hatch> 100% js
<hatch> unless someone made a yui one already
<rick_h__> oh you mean that kind of one
<rick_h__> ugh
<hatch> browser styled one would never pass UX ..... and they are ugly
<hatch> lol
<hatch> sorry i'm also playing hearthstone right now
<hatch> :)
<rick_h__> yea, I did some work around one before. When the big jquery one came out
<rick_h__> hah, all good. I'm trying to load data to qa benji's branch
<rick_h__> woot!
<hatch> :)
<hatch> could probably use autocomplete somehow
<rick_h__> come on charmworld CI 
<rick_h__> go go go
#juju-gui 2015-02-16
<huwshimi> Morning
#juju-gui 2015-02-17
<hatch> uiteam lf reviews for https://github.com/juju/juju-gui/pull/695
<Makyo> On it
<hatch> thanks
<hatch> man this test suite....
<hatch> uiteam I need one more review https://github.com/juju/juju-gui/pull/695
<jcsackett> hatch: i can look at it in a few.
<hatch> thanks
<jcsackett> hatch: remind me in js what .bind is doing.
<jcsackett> it's been too long, and the weird ways of the gui code no longer make sense to me. :p
<Makyo> jcsackett, setting the context of 'this' within the function being bound.
<jcsackett> so fn.bind(fn_args, context) is the usual signature?
<hatch> jcsackett: yep
<hatch> so bind actually returns a new function which is run in the context
<Makyo> fn.bind(context, args...)
<hatch> jcsackett: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Function/bind
<Makyo> So fn.bind(this, args) ensure that fn has access to all that's in `this` context
<hatch> thatses in thises
<hatch> :)
<Makyo> It's all very generic
<hatch> and yet....surprisingly specific
 * jcsackett laughs
<jcsackett> hatch: comments on your PR. very possibly just me misreading things, so feel free to straighten me out if that's the case.
<hatch> will do!
<hatch> thanks!
<hatch> jcsackett: good comments - it's all js funkyness I'll explain in the questions
<jcsackett> hatch: thanks.
<hatch> jcsackett: replied
<hatch> hope that my responses make sense
<hatch> going to grab some lunch
<hatch> jcsackett: my comments make sense?
<jcsackett> hatch: yup, just now was able to reply.
<huwshimi> Morning
#juju-gui 2015-02-18
<huwshimi> Morning
#juju-gui 2015-02-19
<jcastro> rick_h_, can you please check the solutions page?
<jcastro> that bundle is still 404
<rick_h_> jcastro: yes, we're still trying to deploy. It's updated on staging atm https://staging.jujucharms.com/big-data all links work
<jcastro> seriously everything we've tried to demo today has been utterly broken
<rick_h_> jcastro: ok, we're pulling hte logs from prodstack for the error you hit yesterday. It seems to have been a temp thing no one else could replicate
<jcastro> yeah I get that
<rick_h_> but we should have the log for it just have to get it since we don't have direct access to those logs
<rick_h_> sucky stuff's failed on you, send me a list and i'll get them all check out. 
<huwshimi> Morning
#juju-gui 2015-02-22
<huwshimi> Morning
#juju-gui 2016-02-25
<jcastro> yo hatch 
<jcastro> when you have something working with 2.0 lmk, we want to help test
<jcastro> even if it's like a wip
<hatch> jcastro: sure - it's looking like we'll have the charm updated enough to be used to test tomorrow
<jcastro> hatch: oh wow, that's awesome, perfect!
<hatch> jcastro: yeah we've been working real hard on updating everything  - public release should be going out next week so having some help qa would be really helpful :)
<fabrice> 720489
<jcastro> hatch: same with the new juju beta, should I just tell the guys that you'll announce on the juju list?
<jcastro> I'd like to get as many eyeballs on this as possible
<hatch> the beta?
<hatch> we could I suppose
<hatch> I didn't really think of it :)
<jcastro> yes please, we're releasing in april, eyeballs to the max by default!
<hatch> jcastro: fwiw we'll also be releasing more versions of the gui before the real 2.0 release
<hatch> it'll be the first of many before the 2.0 release :)
<jcastro> yeah no worries, I think once everyone gets a working set of 2.0 betas of core and gui that that should make it easier for us to work out the bugs
<hatch> oh yeah definitely!
<hatch> I'll keep you posted on the release
#juju-gui 2016-02-26
<cory_fu> Not sure if this is the right place to ask, but https://jujucharms.com/cassandra/ is not ingesting the most recent commit (reverted a merge, then reverted the revert), and `charm2 publish` is failing with "Alias [cs] has more than one indices associated with it [[cs-bc968f36-3d9a-4329-8551-fce8e052058c, cs-a300c88c-19cc-4f6e-80e3-4b20c21374a5]]"
<urulama> cory_fu: thanks, that's interesting
<urulama> cory_fu: you're right about the issue, we'll fix it and then ingestion and publishing should work again
<cory_fu> Thanks
<cory_fu> urulama: Is it the "merge, revert, re-apply" that broke it?
<urulama> cory_fu: no, no, there were reboots ov VMs over the day due to glibc bug
<cory_fu> Ah, I see
<cory_fu> urulama: Should the ingestion be working yet?  Still seeing the old version
<urulama> cory_fu: waiting on webops
<cory_fu> Ah, ok
<urulama> cory_fu: cassandra updated, "Id":"cs:~charmers/trusty/cassandra-14","PublishTime":"2016-02-26T22:17:10.485Z"}
<cory_fu> Thanks!
<urulama> np
#juju-gui 2017-02-24
<kaisers2> Hi! I'm looking for help in finding out which email address is used by a jujucharmstore. Anybody with 2mins? :)
<kaisers2> Correction: "... a jujucharmstore namespace."
<kaisers2> There's a namespace defined for our company but i cannot find a way how to access it for updating charms...
<kaisers2> uh,oh nevermind any longer, i just found my answer. :)
<arosales> Hi
<arosales> Any body else seeing 404 @ jujucharms.com/<charm-name>
<arosales> https://jujucharms.com/canonical-kubernetes
<arosales> 404 for me as well as others I have  tried
<arosales> note I am logged in or the beta program
<arosales> sorry itsa 400, not a 404
<arosales> and now anything @ https://jujucharms.com/
<rick_h> arosales: no, not here
<hatch> arosales looks good here as well
<arosales> ok, tried on a different machine and it works there. Only difference it I went through the full auth cycle on the alternate machine
<arosales> on the problem machine I guess it picked up my browser cookie for SSO
<arosales> but seems to just be me
<arosales> rick_h: hatch thanks
<rick_h> arosales: hmm, k. If you dupe/see it more let us know and we'll see if there's something we can do
<arosales> rick_h: will do
<arosales> jujucharms.com is totally 400 on one machine. I guess I should look for a cookie/maroon in chrome and try to force a better response
<arosales> *macaroon 
<hatch> arosales if you can reproduce it then I believe we can find the problem
<hatch> arosales can you open the chrome devtools and then refresh the page
<hatch> a 400 is quite an odd response code for the main landing page
 * arosales already started removing cookies and site data for *jujucharms*
<hatch> oh
<hatch> darn
<arosales> but ack if I can reproduce I'll report @ github
<hatch> well a report won't help much if we can't reproduce it :)
<arosales> ah, home page is back
<arosales> I'll see if I can reproduce
<hatch> ok we'll have to pull up the logs and see if we can deduce the issue from there
<hatch> you probably won't be able to reproduce now
<hatch> I have an idea what the issue is but will have to confirm with the logs
<hatch> arosales when was the last time you visited jujucharms.com with this machine?
<arosales> hatch: sorry I got heavy handed there with removing cookies before you pinged :-/
<hatch> no problem
<arosales> hatch: this morning
<hatch> hmm ok, an update did roll out since then
<arosales> but I wasn't logged in
<arosales> I only saw the issue after I logged in
<arosales> but now seems ok
<hatch> hmm ok that's a little more confusing :D
<hatch> but glad it's back up and running :)
<arosales> hatch: thanks for the replies here
<hatch> no problem, glad to help
