#juju-gui 2013-04-01
<gary_poster> bcsaller, are you safe in SF?
<gary_poster> if he is it would be very early there...
<rick_h_> heh, zzzzzz
<gary_poster> :-)
 * rick_h_ goes to check for SF quakes or the like
<bac> hi gary_poster
<gary_poster> hey bac
<bac> hey i'm having some issues dealing with all of the legacy test failures my branch introduced.  some are quite odd, including trying to create charms that claim to have no id, despite clearly passing one.
<bac> gary_poster: do you have time to chat and maybe give me some ideas?
<gary_poster> bac, sure.  should I get a copy of branch?
<bac> yeah, lp:~bac/juju-gui/get-endpoints
<bac> let me push some debugging changes
<gary_poster> k
<bac> ok, grab now
<gary_poster> k
<bac> gary_poster: in guichat
<gary_poster> ack, there soon
<gary_poster> hey hatch, when you start, assuming you don't have anything in progress, why doncha pair with bac
<bac> gary_poster: oh, i meant to mention, to do some of that debugging i had to extrace a variable declaration and assignment out of the big block of them in order for the debugger to not skip over it.  an argument (too late) for 'one var per declaration'.
<bac> ammo for the next time it comes up.  :)
<bac> s/extrace/extract
<gary_poster> bac, oh, interesting!  maybe microblog it--what you just said on IRC-- on the blog so you don't forget?  up to you
<bac> sure
<hatch> morning
<hatch> sure thing
<rick_h_> hatch: do you have details around the _yuid changing on a node? I tried to do some searching this weeekend but didn't find anything 
<rick_h_> hatch: is there some condition that arises? Or it's just unreliable in general?
<hatch> rick_h_: well the yuid doesn't change on the same node, but if it gets re-rendered then it will be different
<rick_h_> hatch: gotcha, but that should be ok as you target an indicator at a container node while you update it's contents. 
<rick_h_> otherwise your indicator would vanish 
<hatch> yeah what I meant was that if your indicator node gets removed for whatever reason - then you try and show it
<hatch> it'll show on a node that's not in the dom any longer
<rick_h_> hatch: right, but the point of this is to make sure the indicator is removed when a view is destroyed/the node goes away
<rick_h_> so for the lifetime of the view it should be good on the container, then the veiw goes away and all indicators used are wiped up
<hatch> oh yes right - It would be more of a concern if it was more general use
<rick_h_> hatch: ok, yea. The point of this is just an extension to use on views to help make sure no indicator is left behind
<rick_h_> since it'll be used on a bunch of browser views. 
<rick_h_> hatch: I can add docs to help narrow the written purpose if that helps. Aside from that can you give it a review look over sometime please?
<hatch> oh yeah for sure
<rick_h_> hatch: cool thanks. Appreciate it
<hatch> I'm just gona grab a coffee then I'll get right on it
<rick_h_> hatch: cool https://codereview.appspot.com/8186045/ to save you link hunting
<hatch> bac: are you still having issues?
<bac> hatch: working through them
<hatch> alright, did you need me to take a look?
<bac> hatch: if you have nothing else to do we could pair after the call.  otherwise i could just keep going and maybe bug you if i get stuck
<hatch> oh I have other stuff but could take a look if you need
<hatch> so I guess lemme know
<hatch> :)
<hatch> bac: a comment on your blog post - you could put the breakpoint in the makeBar function :)
<bac> hatch: you could.  but what if makeBar is called in lots of other situations that are not interesting?
<hatch> then life sux!
<hatch> lol you make a good point though
<hatch> I haven't actually ran into that before
<Makyo> I have, but I've just used F10 to step over to the line I need.
<rick_h_> yea, I just do the debugger before the var declarations and run the function from the console 
<bac> Makyo: really?  when i tried 'step over' it went to the next line out of the declaration
<rick_h_> the only time it's a really big pain is if it's foo=something(), bar=morestuff(foo)
<hatch> rick_h_: yeah I don't like that layout
<Makyo> bac, Hm.  Let me make sure I'm not lying.  This might've been a chained thing instead.
<rick_h_> in which case I probably end up breaking the var up
<Makyo> Oops.  jujugui call now.
<gary_poster> oops thank you
<hatch> O K now to see if I remember how this add relation code worked
<hatch> heh
<gary_poster> add unit?
<hatch> yeah...see I even forgot what it's called
<hatch> haha
<gary_poster> :-)
<hatch> so how was everyones Easter? Eat too much food?
<gary_poster> kids go crazy with too much sugar
<gary_poster> bac, do you know diff between []params.Port(nil) and []params.Port{} ?  Test expects first and obtains second
<hatch> I was thinking when I have kids I'll hide carrots and lettuce - afterall they are from a rabbit
<hatch> haha
<gary_poster> heh
<Makyo> Bathed dogs, who then ran around at the dog park and got all gross again.
<gary_poster> :-)
<hatch> Makyo: yeah - it's impossiblet o keep dogs clean in the spring
 * hatch clearly forgot how to type too
<rick_h_> labs ftw
<hatch> rick_h_: are you saying labs don't get dirty?
<bac> gary_poster: i don't.
<gary_poster> k thanks
<rick_h_> hatch: yea, their coats are super easy thankfully
<bac> the second is obvious but i'm not familiar with the first
<Makyo> Thankfully both the sheps have short coats, so they clean up easily.  
<hatch> rick_h_: oh haha - my dogs are only like 7" off the ground so they get dirty regardless :)
<hatch> the app.js initializer is almost 200 lines...I think it needs to be split up hehe
<rick_h_> hatch: we have to go back to this multiple call business still as well. It's starting to get annoying heh
<hatch> multiple dispatch?
<rick_h_> hatch: yea
<hatch> agreed
 * hatch lights the torches and hands one to rick_h_
<rick_h_> since I'm scolling down to view my work it keeps moving the windows focus on me 
<hatch> why don't you set your container to position absolute? :)
 * rick_h_ loads weapon of CSS destruction
<hatch> haha it shouldn't break anything
<hatch> although you'll probably have to set position relative on the container
<hatch> which might break everything
<hatch> :)
<hatch> ohh funny story
<hatch> I stepped through my garage roof yesterday
<hatch> yesterday - a day
<hatch> heh woops
<bac> hey our wordpress blog has a fan. ronscubadiver from TX just like my post. we have an audience!
<hatch> right...on!
<hatch> gary_poster: are we using _'s in sandbox.js?
<gary_poster> hatch, only for legacy bits
<gary_poster> hatch which means the handlers
<hatch> alright gotcha - I was kind of wondering if these shoudln't be in a closure so we didn't have to prefix them
<hatch> it doesnt really matter
<hatch> just thinking :)
<hatch> jujugui - uistage is broken a conflicted file was comitted
<gary_poster> hatch fixing not committed I don't think checking
 * bac looks
<bac> gary_poster: you doing it? or me?
<gary_poster> bac you thank you
<gary_poster> bac lplease lemme know when done
<hatch> gary_poster: am I correct that I can't test this add_unit code until I first implement get_service?
<gary_poster> hatch, no.  you need deploy, which you already have
<gary_poster> hatch, deploy via the fake backend, get the service from the result, and then use that id for the add_unit
<gary_poster> works?
<gary_poster> you can actually provide the id explicitly and then you don't even need to look at the result
<hatch> oh ok I need to manually trigger it
<hatch> I was trying to figure out how add_unit was called from the UI
<gary_poster> well, since you are not testing that part of the API, that makes sense to me
<gary_poster> that's the test prep
<bac> gary_poster: uistage happy again
<gary_poster> cool thanks bac
<gary_poster> rick_h_, ^^
<rick_h_> gary_poster: thanks
<gary_poster> ty
<gary_poster> we really should deploy that from a charm 
<gary_poster> rick_h_, do you have a deployment plan for jujucharms.com, he said with a shudder?
<rick_h_> gary_poster: otp, sec
<gary_poster> np
<rick_h_> gary_poster: so, from what I understand it's been handed off to #is to complete getting it deployed to prodstack. 
<rick_h_> gary_poster: sinzui will know more/status than I at the moment ^
<gary_poster> rick_h_, but I meant the GUI itself
<rick_h_> gary_poster: oh, the deployment story I imagine is getting the gui charm up and running on prodstack under that domain. 
<gary_poster> rick_h_, and that won't be *any problem at all* will it ;-)
<rick_h_> gary_poster: I've got nothing about deploying gui than you guys have. I'm jumping on your train
<rick_h_> sorry, assumed it was a yellow problem and such :)
<rick_h_> gary_poster: well, honestly shuoldn't be since you guys don't have external services to HA and the like. The only thing will be gettnig HA proxy in front of the Gui and making sure multiple instances can run side by side. 
<gary_poster> rick_h_, ok, cool.  I had the "jujucharms.com is for orange" in my head.  glad we are ironing out.  that could have been a  nasty surprise
<sinzui> No movement on our ticket. I did update it make it clear we have delivered our part for manage.jujucharms.com, and that it is required to deliver juju-gui  as jujucharms.com
<rick_h_> gary_poster: definitely. Orange is moving jujucharms.com to management.jujucharms.com which is our charmworld pyramid app on prodstack
<rick_h_> gary_poster: jujucharms.com should be the prodstack deployed juju gui charm
<gary_poster> yeah, in our configuratuion they shouldn't even need to talk to one another: it will be in-browser "juju"
<rick_h_> gary_poster: maybe you can sinzui and the people working on the gui charm should meet up and head off any craziness at the pass
<gary_poster> so, rick_h_, the only challenge I know of will be that they will want to be able to get the tarball and any deb dependencies from their own locations
<bac> hatch: can you confirm that browser_charm_view fails on trunk for you?
<gary_poster> rick_h_, +1
<bac> it didn't look like anything i would've broken
<gary_poster> bac I had to make clean before it passed
<bac> err
 * bac tries
<gary_poster> not ideal but I didn't have time to investimagate
<bac> i'm glad to know 0 does not deeply equal 2
<Makyo> Out of control notifications.  Back in a sec.
<gary_poster> :)
<hatch> bac sure
 * hatch switches gears
<bac> hatch: nm, given gary_poster's report
 * hatch switches back
<hatch> :)
<gary_poster> sinzui, do you think depoyment is good topic for call in 8 minutes with group?
<gary_poster> deployment of GUI on prodstack for jujucharms
<sinzui> gary_poster, yes
<gary_poster> ok cool
<bac> thanks gary_poster.  wfm now
<gary_poster> cool bac
<sinzui> gary_poster, as I hinted in the last call. We are waiting for manage.jujucharms.com to be deployed. It is a requirement for juju-gui to become jujucharms.com
<gary_poster> sinzui, right.  I didn't think about the fact that the GUI charm itself will need to be hardened for prodstack
<gary_poster> I *think* I know what that will entail
<gary_poster> and for our purposes I don't think it will be too much
<gary_poster> just make it possible to get tarball and debs from custom locations
<gary_poster> and not reach out to other locations in that case
<rick_h_> arosales: so with staging happy http://uistage.jujucharms.com:8080/bws/sidebar should load. Let it load then scroll down below the environment. 
<rick_h_> arosales: click on the charm to view the details, same thing. Scroll down to see the start of display/tabs. No UX so it's just framing for the JS view/functionality vs look/feel :)
<arosales> rick_h_: thanks. I'll take a look now . .  .
<hatch> rick_h_: pretty cool :)
<hatch> hurry up and fix so I can demo the router stuff :P
<hatch> s/fix/finish
<hatch> gary_poster: in the tests I have state.deploy('cs:wordpress', function() {}); and then before that env.get('conn').onmessage(function(received) { ... }); but that callback is never triggered
<hatch> am I missing how this works?
<hatch> let me rephrase that
<hatch> I am missing how this works
<hatch> haha
<gary_poster> hatch sorry calls
<hatch> np I may have it
<hatch> testing now
<gary_poster> ok cool hatch.
<hatch> gary_poster: still on a call? https://code.launchpad.net/~hatch/juju-gui/add-unit my test fails in mocha but passes in the browser
<hatch> TypeError: JSON.stringify cannot serialize cyclic structures. (mocha-phantoâGET /juju-ui/assets/images/picker_1px.png 200 2ms - 965
<hatch> mjs/core_extensions.js:50)
<hatch> it's also very slow +1s
<gary_poster> no on call hatch. you mean fails in phantom right?
<hatch> yeah...oh man I need another coffee or something hah
<gary_poster> looking
<hatch> I'm assuming I"m doing this wrong becuase there is no way that tests should take over 1s
<gary_poster> verified symptoms hatch.  now looking at code
<hatch> thanks
<hatch> my experience with the environment code is virtually 0 so I woudln't doubt I'm doing this wrong
<gary_poster> hatch, let's guichat
<hatch> alright
<Makyo|out> Haircut time
<hatch> gary_poster: http://pastebin.ubuntu.com/5668110/
<hatch> any input?
<gary_poster> hatch, #1, clear out the delta stream, as we said
<gary_poster> before you open
<hatch> oh right - I had that in there but didn't appear to make any difference
<hatch> I'll add it back
<gary_poster> hatch #2, the fact that you are waiting 1 second means that you are still not returning an initial response (client.receive, like in the login op handler)
<gary_poster> because waiting one second means that you are waiting for the delta stream
<gary_poster> when you should be waiting for the client response
<hatch> ahh ok
<hatch> oh looks like I had a typo there
<hatch> man we REALLY need to document attrs and events
<gary_poster> hatch, write down the pain, because otherwise you will forget it
<gary_poster> that is the specific things that you mean
<hatch> yep for sure
<bac> hatch: when you have some time i'd like to get some help
<hatch> sure 5mins?
<hatch> I have new neighbours today....wonder what they will be like
 * hatch hopes they don't throw huge parties every weekend
<gary_poster> hatch, interestingly the unit tests were fine, without any retries, for two or three times in a row.  The most recent ran the unit tests four times before it got a success, but at least it did eventually get a success. :-/ http://10.189.74.2:8080/job/jujugui-test-charm/206/console
<hatch> man that's so irritating
<hatch> it never fails in chrome though does it?
<hatch> bac: ok I'm at a good break point
<hatch> what's up?
<ahasenack> hi guys,
<ahasenack> I deployed juju-gui using "stable", and /var/lib/juju/units/juju-gui-0/charm/juju-gui/build-prod/juju-ui/version.js confirms that
<ahasenack> var jujuGuiVersionInfo=['0.3.1', '470'];
<ahasenack> but I don't see a "landscape" link in the lower right corner, it's been a while since I last deployed this
<ahasenack> maybe I'm just not finding it, where should it be, does someone know?
<gary_poster> ahasenack, the link does not show up until landscape has annotated the environment
<ahasenack> ah, ok
<ahasenack> so I have some bug hunting to do :)
<gary_poster> :-)
<hatch> gary_poster: I think bac may have found our test failing issue
<gary_poster> yay?
<hatch> well whatever he is doing is causing the tests in application basics to fail
<hatch> but randomly
<hatch> sometimes it passes
<gary_poster> :-) fun
<hatch> sometimes 2 fail, sometimes 8 fail
<gary_poster> sounds different to me
<hatch> sure - but if you look at the test suite you'll notice that it doesn't clean up after itself
<ahasenack> gary_poster: what would be a line in the logs that confirms landscape is sending the annotations? I have seen some like these:
<gary_poster> hatch, if we fix it, I'd be thrilled :-)
<ahasenack> 2013-04-01 14:48:40,793: juju.rapi.ws@DEBUG: send delta update [('service', 'change', {'charm': 'local:precise/keystone-213', 'annotations': {u'landscape-computers': u'%2Bservice%3Akeystone', u'gui-y': 153.5838711310003, u'gui-x': 570.5940154188667}, 'id': 'keystone'}), ('service', 'change', {'charm': 'local:precise/nova-compute-87', 'annotations': {u'landscape-computers': u'%2Bservice%3Anova-compute', u'gui-y': 277.31
<ahasenack> 58501443403, u'gui-x': 869.4793787934253}, 'id': 'nova-compute'})]
<ahasenack> (send)
<ahasenack> and
<ahasenack> 2013-04-01 14:48:25,691: juju.rapi.ws@INFO: Process message {"op":"update_annotations","entity":"keystone","data":{"gui-x":570.5940154188667,"gui-y":153.5838711310003},"request_id":3}
<ahasenack> but I'm not sure who sent them
<ahasenack> other than that, no easy traceback on either side so far
<ahasenack> still digging
<gary_poster> ahasenack, the second one is unrelated
<gary_poster> that is the gui annotating viaula location of a service
<gary_poster> visual
<gary_poster> the first is promising
<ahasenack> yeah, figured (x-y coordinates)
<hatch> viaula sounds like some medication name ;)
<gary_poster> :-P
<ahasenack> yeah, that first one has bits of a valid landscape link
<ahasenack> the service:nova-compute part
<ahasenack> it's a landscape computer search
<gary_poster> ahasenack, if I had to guess, I would guess that the environment annotations are not being set/sent to the GUI
<gary_poster> that provides the base of the URL
<gary_poster> and it is what we use to determine if we should turn on the environment annotations
<ahasenack> ok
<gary_poster> ahasenack, ideally you would see these annotations in that stream.  maybe look for the string "environment"?
<gary_poster> ahasenack, other thinsg I can do to help, though it would take me a few minutes:
<ahasenack> I can see landscape connecting to the api
<gary_poster> - give you something to run in the browser to look at the annotations the the GUI knows about for the environment
<ahasenack> I restarted that landscape service and I see the login op, and the api sending back a bunch of stuff
<ahasenack> I need to watch for the other way around now
<gary_poster> - give you something to run in the browser to ask Juju directly for annotations on the environment
<ahasenack> in the "send delta update" bit, there are annotations in it
<gary_poster> ahasenack, when it sent a bunch of struff did it include "environment" associated with an update_annotations op?
<ahasenack> 'annotations': {u'landscape-computer': u'%2Bunit%3Aswift-proxy%252F1', u'landscape-needs-reboot': True}
<ahasenack> I'll have to check, it's a long message
<gary_poster> yeah, we established that services are getting annotations
<gary_poster> yeah, grep it! :-)
<ahasenack> no update_annotation yet
<ahasenack> or "environment"
 * hatch goes to eat
<gary_poster> I'm trying to verify on my side with test data
<hatch> ding if ya need me
<ahasenack> older bits of the logs do have it
<ahasenack> hm, wait
<ahasenack> that's the x-y position ones
<gary_poster> 1 sec ahasenack I got something else for you to look for
<bac> anyone seen google maps today?
<ahasenack> the only "environment" string I have is
<ahasenack> # grep environment api-agent.log 
<ahasenack> 2013-04-01 11:44:01,019: juju.agents.api@DEBUG: Received environment data.
<gary_poster> ahasenack, I'm on crack, but I'm trying to wean myself off. ;-) see http://pastebin.ubuntu.com/5668359/
<gary_poster> ahasenack, those values are old
<gary_poster> ahasenack, but the keys are correct
<ahasenack> gary_poster: so, I should look for a log entry similar to that one, with those keys
<gary_poster> in particular we have to have landscape-url, but all those keys are necessary
<gary_poster> precisely ahasenack 
<ahasenack> yeah, no landscape-url anywhere
<gary_poster> ahasenack, I'm suspicious that landscape is not giving us the keys we need anymore, then
<gary_poster> well, even more suspicious, since I had already qa'd this on our end ;-)
<ahasenack> gary_poster: ok, I'll file a bug on our side
<gary_poster> thanks ahasenack 
<ahasenack> gary_poster: yeah, it changed to fix a bug
<gary_poster> gotcha
<ahasenack> wouldn't be the first time a bug was introduced by a fix
<gary_poster> :-) no
<bac> gary_poster: vacation request submitted.
<rick_h_> jcsackett: hatch if you guys get a few spare minutes :) https://codereview.appspot.com/8171047
<hatch> NEVAAAAAAA
<hatch> rick_h_: is there a risk of that qa.json becoming stale?
<Makyo> >:/
<rick_h_> hatch: yea, but kind of the case with any sample data :/
<hatch> yeah true true
<hatch> Makyo: don't like your hair?
<Makyo> hatch, Nah, it came out fine.  Don't like my wireless router, though.
<hatch> Makyo: your new hair? http://1.bp.blogspot.com/-bJLQi7wKPU8/T7EH46gZ_gI/AAAAAAAABNU/eRblcqMK6GU/s400/09-mohawk.jpg
<Makyo> hatch, I don't think I could quite pull that off.. :)
<hatch> lol
<hatch> how will you know unless you try?
<hatch> you miss 100% of the shots you don't take :P
<Makyo> Who's to say I haven't?
<hatch> true true
<Makyo> (ps: I haven't)
<hatch> lol
<hatch> gary_poster: in python.js ln 133 there is a line this.ws.send(msg) in _send_rpc() can you tell me where this is set?
<gary_poster> looking hatch
<hatch> oh I found it
<hatch> heh
<hatch> figures
<hatch> :D
<gary_poster> :-) k
<hatch> basically I'm trying to track down an error with env.add_unit()
<hatch> on the integration test
<hatch> hey gary_poster you wrote the addUnit method in fakebackend.js right?
<hatch> wait ignore that
<hatch> this is my screwup
<hatch> ok lets roll that back just a bit
<hatch> :)
<hatch> gary_poster: is it possible that the addUnit method doesn't return the proper formatted data? Or is it intentional that I'm supposed to match it to the real output?
<gary_poster> hatch, there's only confidence if there is a test. :-)  Let's see if there is a test for addUnit in the test_fakebackend file...
<hatch> well it works
<gary_poster> hatch, tests seem reasonable.  if you think there's a problem, maybe try to write a breaking one?
<hatch> it's output just doesn't match the native one
<gary_poster> hatch, oh!  no, that's the job of what you are writing
<gary_poster> remember I said there was deterctive work involved?
<gary_poster> detective, even
<hatch> yep ok - so then I'll break these tests
<hatch> and that's ok?
<gary_poster> hatch, um?
<gary_poster> hatch, let's have a guichat :-)
<hatch> sure :)
<jcsackett> hatch, Makyo, rick_h_: can two of you fine folks look at https://codereview.appspot.com/8071044
<Makyo> Sure, on it.
<jcsackett> Makyo: thanks.
<gary_poster> Makyo LGTM
<Makyo> gary_poster, thanks
 * Makyo walks dogs before it rains.
<gary_poster> :-) welcome
<hatch> gary_poster: when you get a second could you check out https://codereview.appspot.com/8236043/
<hatch> I am pretty sure I got it this time
<hatch> haha
 * hatch has a thick skull sometimes
<gary_poster> hatch, yeah.  Still a bit of trouble, I think.
<gary_poster> sorry, hatch, but let's guichat
<hatch> :'(
<hatch> alright
<hatch> gary_poster: code has been updated
<gary_poster> hatch, just saw, looking
<hatch> awesome
 * hatch crosses fingers
<gary_poster> looks good hatch, doing silly normal review things :-)
<gary_poster> will eventually result in a LGTM :-)
<gary_poster> hatch, LGTM with small suggestion
<hatch> thanks - sure I'll add that :)
<hatch> I actually didn't know there was an isUndefined
<hatch> :)
<gary_poster> assert is a nice interface.  I didn't start using it till I saw benji use it
 * hatch wonders what assertion lib we are actually using
<gary_poster> chai
<gary_poster> IIRC
<gary_poster> at least that doc has worked well for me ;-)
<hatch> haha perfect
<hatch> hmm after I added assert(isUndefined(data.err)); I got a 'verify dependency' error
<hatch> but now it's working just fine
<hatch> there is definitely some leakage in some tests here
<hatch> maybe after 13.04 we take a day and go through all of the suites to clean them up
<hatch> assert.isUndefined(data.err);
<hatch> i mean
<hatch> bcsaller: able to take a look at my fakebackend branch for review?
<bcsaller> hatch: got the link
<bcsaller> ?
<hatch> https://codereview.appspot.com/8236043/
<hatch> gary_poster: if you're still around - any idea which task you want me to tackle next so I can do some evening reading
<hatch> bcsaller: I just copied that signature from a previous test
<hatch> oh it looks like it's from python.js ln 227
<gary_poster> hey hatch.  I'm here for a sec.  you still here?
<gary_poster> thanks for getting that branch landed. cool.
<hatch> I am yep
<hatch> I'm glad it's over :D
<hatch> although I have a much much better understanding of what's going on
<hatch> haha
<gary_poster> :-()
<gary_poster> :-)
<gary_poster> first smiley: fat finger led to fat lip
<hatch> haha
<gary_poster> hatch, how about remove_units?  it's all in a similar part of the world, so it would be a natural change.
#juju-gui 2013-04-02
<hatch> can do!
<gary_poster> hatch, after that, expose and unexpose would be easy things to do, I bet.
<hatch> alright assigned
<gary_poster> cool, thank you!  honestly, the only thing particularly tricky there that I see is the annotations, and that is just because we will need to hook up annotation deltas
<gary_poster> but that should also follow existing patterns
<hatch> sounds good
<frankban> morning rogpeppe: does juju-core trunk compile for you? I see cmd/builddb/main.go:9: imported and not used: "launchpad.net/juju-core/state"
<rogpeppe> frankban: i see that too. it should be fixed.
<rogpeppe> frankban: nothing depends in builddb though, i don't think, so it's not critical
<frankban> rogpeppe: doesn't it prevent juju-core to be "go install"ed?
<rogpeppe> frankban: no. just builddb
<frankban> rogpeppe: ok
<frankban> rogpeppe: unrelated, what's your plan on including constraints and settings in the allwatcher? is there anything I can do to help implementing it?
<rogpeppe> frankban: i guess the only thing to do is add new Info types and add their collections to the set of collections watched
<rogpeppe> frankban: it's a bit weird that constraints are in their own collection
<rogpeppe> fwereade__: why are constraints in their own collection?
<frankban> rogpeppe: because constraints are only related to units?
<rogpeppe> frankban: no, constraints are related to units, services and machines
<rogpeppe> frankban: the difficulty is that neither constraintsDoc nor settingsDoc hold the entity name in the doc
<rogpeppe> frankban: well, actually there's no settingsDoc per sre
<rogpeppe> s/sre/se/
<frankban> rogpeppe: yes, the tag
<frankban> rogpeppe: AFAICT constraints include the global key (pk) and settings something else (e.g. serviceSettingsKey)
<rogpeppe> frankban: yes - i think the service settings key is to allow charm upgrades
<rogpeppe> frankban: but i don't know much of the detail
<frankban> rogpeppe: so we need a way to include the entity tag in both docs
<rogpeppe> frankban: yeah, that's probably the easiest way forward. but might not go down well. i'm having another look at adding a level of indirection.
<frankban> rogpeppe: cool, thanks
<fwereade__> rogpeppe, frankban, hey, sorry
<frankban> morning fwereade__ 
<fwereade__> rogpeppe, frankban: basically they're in their own collection because they're conceptually distinct from the various entities and they're not fundamental to the operation of the entities in question
<fwereade__> rogpeppe, frankban: consider also settings
<rogpeppe> fwereade__: aren't they attributes of the entities in question?
<fwereade__> rogpeppe, I'm not sure there's anything strongly indicating that they must be
<rogpeppe> fwereade__: it seems a bit weird that you can do Service.Watch but you don't see the service constraints change
<rogpeppe> fwereade__: well, we could have every attribute in its own collection
<rogpeppe> fwereade__: i'm not sure that would be good though
<fwereade__> rogpeppe, well, I'm not proposing that...
<rogpeppe> fwereade__: i'm not sure what you think is good about having attributes of an object spread across separate collections.
<fwereade__> rogpeppe, well, it's not exactly unheard of... consider annotations, settings, scope membership...
<fwereade__> rogpeppe, it is not always neatest or cleanest to stick everything related to X into the document for X
<rogpeppe> fwereade__: annotations and settings have a good reason (they can be unbounded in size)
<rogpeppe> fwereade__: i don't know about scope membership
<fwereade__> rogpeppe, that's mainly about being able to watch sanely
<rogpeppe> fwereade__: watch scope membership?
<fwereade__> rogpeppe, the real underlying worry is that the more overlapping txns we have on given objects the more contention we'll have
<rogpeppe> fwereade__: i worry that we're prematurely optimising here.
<fwereade__> rogpeppe, yes; and as a corollary *not* get events on the unit every time something irrelevant happens
<rogpeppe> fwereade__: we're making all kinds of guesses about efficiency
<rogpeppe> fwereade__: and we don't know anything about the likely distribution of db ops in a large juju environment
<fwereade__> rogpeppe, I'm writing the code in the most natural way I see, in accordance with things we've done in the past, and in general a feeling that just slapping everything into one giant object is a poor way to go by default
<rogpeppe> fwereade__: putting things into separate collections has costs too though.
<fwereade__> rogpeppe, sure; what are the ones that particularly concern you?
<rogpeppe> fwereade__: n fetch ops vs 1.
<rogpeppe> fwereade__: seeing inconsistent data
<fwereade__> rogpeppe, well, the point is to chunk them such that n=1 most of the time, and reap the benefits of sending only the data you need
<fwereade__> rogpeppe, and similarly, if related data goes together, you don't see inconsistency there
<rogpeppe> fwereade__: perhaps there's is no problem in fact. the issue does concern me though.
<fwereade__> rogpeppe, I have tried to plot a sensible course between the two obviously bad extremes -- single-giant-object vs collection-per-attr
<fwereade__> rogpeppe, I doubt the course is perfect ofc
<rogpeppe> fwereade__: it's probably fine. it's just that every time i turn around there seems to be another collection.
<fwereade__> rogpeppe, but as a heuristic I feel that, if there's no overlap between the users of field A and field B, we should at least consider putting them in separate docs
<fwereade__> rogpeppe, yeah, I know the feeling, but they're actually pretty useful building blocks
<rogpeppe> fwereade__: i feel that there's something to be said for the conceptual integrity of having attributes that relate to an object in the same place.
<fwereade__> rogpeppe, IMO wedging unrelated data into a single object is one of the leading causes of decay to conceptual integrity :)
<fwereade__> rogpeppe, but I kinda feel we're into aphorism territory here
<rogpeppe> fwereade__: yeah
<fwereade__> rogpeppe, I think I do understand your concerns; I still think I've made a reasonable choice, but I'm also interested to hear any pain points you encounter because of it, so that I can make better choices in future
<fwereade__> rogpeppe, thanks :)
<rogpeppe> fwereade__: i will do. np.
<frankban> rogpeppe: so, how do we proceed? are you thinking about decoupling the EntityInfo (sent as part of the delta) and the entity docs?
<rogpeppe> frankban: yes, that's what i'm going now.
<rogpeppe> s/going/doing/
<rogpeppe> frankban: i've made the most important change in the code (the decoupling) and am just figuring out the test changes now.
<frankban> rogpeppe: cool, thank you
<frankban> rogpeppe: in an environment bootstrapped using --upload-tools (quantal) i deployed cs:precise/mysql. the status is stick to pending, in the machine log I see http://pastebin.ubuntu.com/5670077/
<rogpeppe> frankban: hmm, that's the issue that dave cheney saw
<rogpeppe> frankban: i couldn't reproduce it
<frankban> rogpeppe: it seems it only happen when the series of the bootstrap node and the service does not match. I tried to deploy a quantal charm (cs:~charmers/quantal/ceph-3) and I "correctly" have an install error
<frankban> rogpeppe: however, I remember I was able to deploy a precise charm using --upload-tools (quantal) last week
<rogpeppe> gary_poster: it seems that i can't put off adding that layer of indirection to the allWatcher
<rogpeppe> gary_poster: the code is easy, but changing the tests is taking a little while
<gary_poster> rogpeppe, is this necessary for the config and constraints, and future state stuff?
<rogpeppe> gary_poster: config, constraints, status and probably more stuff too
<gary_poster> gotcha
<gary_poster> rogpeppe, will this indirection branch add the config and constraints or is it a step along the way
<rogpeppe> gary_poster: it's a step along the way
<gary_poster> ok (and darn :-) )
<rogpeppe> gary_poster: but adding the other stuff should be "easy" (modulo type renaming :-])
<gary_poster> heh.  rogpeppe, I suspect we ought to have a call today to see where we are, what more we need, and what the timeline is
<rogpeppe> gary_poster: agreed. any time. apart from i've got a call in 35 mins.
<gary_poster> cool rogpeppe. I'm hanging out in http://tinyurl.com/guichat and will be ready to talk whenever you are
<frankban> gary_poster: do you have time for a quick call?
<gary_poster> frankban, sure.  come on by guichat
<benji> so much email
<rick_h_> benji: bwuhahaha, motivation to never leave
<benji> heh
<benji> gary_poster: I'm trying to figure out the status of my "Add relationship attributes to watcher" card.  Do you know anything about it?  Did anyone work on it?
<gary_poster> benji sent you email.  short answer: no progress, you take it
<rick_h_> benji: thought gary_poster sent an email last night. Bottom of your pile :)
<rick_h_> doh, too slow
<gary_poster> :-)
<benji> I read them all so I must have not understood.  
<benji> I'll go back and read it again.
<gary_poster> benji, look for reply to your status email.  
<gary_poster> """I didn't touch this, but I added a card for it (I appropriated the one
<gary_poster> you and Francesco were using for my branch).
<gary_poster> I also added a card for "add config and constraints to event watcher" to
<gary_poster> "Ready to code""""
<rick_h_> benji: "Re: More info in deltas" is the subject
<gary_poster> biab
<rick_h_> <3 notmuch
<gary_poster> :-)
<gary_poster> frankban, ok ready now :-)
<gary_poster> benji, all cool?
<benji> gary_poster: yep!  I missed the one line I was looking for.  Reading for comprehension...
<gary_poster> :-)
<gary_poster> frankban, in guichat again
<rogpeppe> gary_poster: i've just realised my regular call has shifted by an hour. let us know when you're done with frankban, and i'll G+ you.
<gary_poster> ok thanks rogpeppe
<teknico> right! both sides of the pond in sync again, so daily call in 1:15-ish, right?
<rick_h_> teknico: rgr
<gary_poster> rogpeppe, could you join frankban and me in https://plus.google.com/hangouts/_/7fb7c30f3a232db57dd8549738fb98e723d90d4a ?
<hatch> goooooood mornin
<hatch> gary_poster: so are you the only one that gets the CI emails now?
<bac> hatch: i got a jenkins failure email
<hatch> hmm interesting - I only got the one from gary
<hatch> maybe it got lost in the internets
<hatch> will see if I get the next one
<gary_poster> hatch, it was a very big email.  maybe filtered out?
<gary_poster> Looks like canonistack is hosed yet again 
<gary_poster> Going to kill this one too
 * hatch grumbles
<gary_poster> no resources is my guess
<gary_poster> we are only getting a single machine
<hatch> so EC2 would cost us $X/yr could we requisition that $ and buy a box just for us in Canonistack? :D
<gary_poster> :-)
<hatch> I'm only a little bit joking :)
<gary_poster> yeah, I regard building these stats as grist for the mill of getting this fixed one way or another
<gary_poster> I'll be able to say "we have had X runs of the CI in one week. Y% failed because of canonistack.  We'd like to fix this or be able to go someplace else."
<bac> hatch: if it costs $X to buy a box it'll cost about $100X in time trying to get it purchased and installed.
<gary_poster> too true :-(
<hatch> bac: isnt' that what juju is for....:P
<gary_poster> no, that's what the cloud is for "=/
<gary_poster> :-/
<hatch> haha
<gary_poster> off by one smiley
<bac> since benji has such good internet, why don't we just host a box at his house?
 * benji considers adding UPS and a raised floor.
<gary_poster> hey, that's a great idea! We can all get root on his network!
<rick_h_> hah, everyone loves those HP microservers
<rick_h_> a shelf full of those should be the awesome!
<rick_h_> http://www.jorgecastro.org/2012/04/10/maasing-and-jujuing-with-hp-proliant-micro-servers/
<rick_h_> looks like we need to ping robbie for access to robbiestack
<rick_h_> luca__: howdy, I just sent an email to alejandra about a possible meet up today. I meant to copy you and sinzui but suffered email fail of the brain. 
<bac> late but good: http://youtu.be/9shZslfbaS0
<luca__> Hi rick_h_ no problem, I'm available for a catch up but will let Ale reply. We'll be on the standup so we can sort it out then.
<benji> that's pretty good
<rick_h_> bac: I like the "how many blocks are supposed to be in this iteration?" lol
<gary_poster> hey look, the tests are actually runnning now!  how novel
<gary_poster> on canonistack I mean
<gary_poster> ugh!
<gary_poster> and they failed because of bug 1161937.  ugh.
<_mup_> Bug #1161937: Unit tests fail in CI initially, intermittently <juju-gui:Triaged> < https://launchpad.net/bugs/1161937 >
<hatch> bac: does trunk have our fix from yesterday?
<gary_poster> no
<bac> no
<hatch> oh ok - I was thinking that 'might' fix it?
<bac> hatch: i can pull it into a separate branch and land it
<hatch> I am almost certain those failures are caused by something along the same lines as we solved yesterday
<gary_poster> jujugui, call in 2
<gary_poster> frankban, starting without you
<frankban> gary_poster: koining
<frankban> joining even
<benji> bac: that was the best update ever
<hatch> lol
<luca__> rick_h_: https://plus.google.com/hangouts/_/8dff1ab85e077e6f0c07a33419a091a66c4536d5?authuser=1&hl=en
<gary_poster> bcsaller, what's the earliest you would like a regular call time?
<bcsaller> gary_poster: even 8am would be an improvement, a 1/2 hr later
<gary_poster> that's not the question I asked though ;-) 
<gary_poster> bcsaller, ^^
<bcsaller> gary_poster: 9am would be my preference but I don't want it to be too late in Europe 
<gary_poster> ack.
<gary_poster> I could propose M-Th @ 9 and Fri @ 8 bcsaller?
<bcsaller> gary_poster: deal :)
<gary_poster> cool :-)
<gary_poster> hey jujugui.  bcsaller is in a new timezone that means the current daily call time is very early for him.  Does anyone have objections to the following: daily call M-Th, UTC 1600.  weekly call Fri, UTC 1500.
<Makyo> gary_poster, Works for me.
<gary_poster> thx
<benji> that's fine with me
<frankban> gary_poster: ok
<gary_poster> cool
<hatch> iunnoooo
<hatch> :P
<teknico> gary_poster, fine with me too
<gary_poster> thx teknico.  hatch, issue?  let me know if there's a prob
<hatch> no no issue :) that's 10am and 9am here so I should be well into working by then
<gary_poster> ok cool
<hatch> bcsaller: just so we know when we can bug you - what time UTC do you start now?
<hatch> rick_h_: is there a way to copy the text from one panel in a split panel window in iterm?
<hatch> er tmux in iterm
<gary_poster> bac is not here
<gary_poster> hoping it is ok with him
<hatch> gary_poster: he is on the same timezone as me so I don't think it would be an issue
<gary_poster> cool
<hatch> gary_poster: to write the remove_units() fakebackend I executed the command on improv and then took note of the req/res and will duplicate that
<hatch> ^^ correct approach?
<gary_poster> hatch, good start, yes.  For response, you'll want to look at callbacks as well.  Sometimes improv is not as complete
<hatch> right gotcha
<hatch> rick_h_: I found the answer http://unix.stackexchange.com/questions/58763/copy-text-from-one-tmux-pane-to-another-using-vim
<bcsaller> hatch: I think I'm an hour behind you, its 8:30am here now . I usually try to start around now.
<hatch> ahh ok cool
<hatch> GMT-7 or UTC 15:30
<hatch> ;)
<hatch> we should schedule everything in UTC time :)
<hatch> gary_poster: how did you know to add in all of these if checks in addUnit? Did you also look at improv?
 * gary_poster looks
<hatch> some of it is similar to service.js but not all of it
<hatch> ok nope add_unit.py doesn't have those checks in it either
<hatch> looks like you were just being thorough
 * hatch just doesn't /get/ yield in python
<benji> hatch: to get yield you first have to get generators.  A generator is like a function that instead of returning one thing and stopping can return something and then later be asked for another (and another, etc.)
<hatch> so you pass it an array and every time it's called it moves the pointer forward?
<benji> "yield" is like "return" except that it means that you can be asked again for another value and you will yield again
<benji> nope, "yield" yields whatever you pass it (just like return)
<hatch> ok then that's the issue - i don't understand what the difference is...where does this 'next' value come from?
<hatch> if your passing new data in... then how is it any different than a function with return
<benji> the value passed to yield is what next receives
<benji> you don't normally pass in new values to each "iteration" of the generator
<benji> normally you pass in values to get it started and then it generates a series of values; every time you call next the generator is run until it yields a value and that is the return value of the next call
<hatch> ohh ok ok now I get it
<hatch> thanks for that :)
<gary_poster> hatch, sorry, I looked, and then was pulled down two rabbit holes.  I climbed back out of one of them, but it looks like you are all taken care of.
<hatch> :) no problem
<benji> hatch: here is a little generator you could play with: http://paste.ubuntu.com/5670872/
<hatch> must....have....curly......braces.....
<hatch> :P
<benji> :)
<benji> It will be no surprise that I feel exactly the opposite. :)
<hatch> haha nope - My mind just looks for the closing brackets to compile in my head
<hatch> python throws a brain syntax error
<hatch> :P
<teknico> hatch, then there's "yield from": ;-) http://docs.python.org/3/whatsnew/3.3.html#pep-380-syntax-for-delegating-to-a-subgenerator
<rick_h_> luca__: if you get a sec can you pull up the 'weekly' update that last went out and shoot a copy to me/sinzui?
<benji> rogpeppe: I am having some test failures that I could use some help on.  I figured several out but one is still getting me: http://paste.ubuntu.com/5670930/
<rogpeppe> benji: looking
<benji> the problem seems to be that setUpScenario sets up less than what is found, which doesn't make sense to me
<rogpeppe> benji: the problem is *probably* that some test op hasn't undone a remove-relation change properly
<rogpeppe> benji: i thought some branches relevant to that had already been submitted (though i can't quite remember who was doing them. teknico? frankban?)
<benji> hmm, that is a possibility
<benji> this branch hasn't merged trunk since Friday, so maybe a merge will magically fix this (after breaking the world with merge conflicts, but I can't have everything)
<benji> I'll give that a try and if it doesn't help I'll go on a search and destroy mission for an improperly un-done test.
<rogpeppe> benji: y'never know
<frankban> rogpeppe: I think teknico did that kind of clean up
<rogpeppe> benji: a quick check:
<benji> hmm, but the test generates an entirely new scenario, how could another test interfere?
<rogpeppe> benji: what does opClientDestroyRelation look like?
<benji> func opClientDestroyRelation(c *C, st *api.State, mst *state.State) (func(), error) {
<benji> 	err := st.Client().DestroyRelation("nosuch1", "nosuch2")
<benji> 	if api.ErrCode(err) == api.CodeNotFound {
<benji> 		err = nil
<benji> 	}
<rogpeppe> benji: ah, i don't know which function your test failure relates to
<benji> 	return func() {}, err
<benji> }
<rogpeppe> benji: perhaps you could push your branch and i'll take a look
 * benji notes another point against tabs in source.
<rogpeppe> benji: that looks fine
<luca__> rick_h_: the last email that me or Jovan has from Nick is from the 1st of March. Do you have that one?
<rogpeppe> benji: it's ok, gofmt will put 'em back :-)
<teknico> it looks fine to me too
<benji> re. tabs: oh, I know
<teknico> I added reset() (cleanup) functions to a number of tests
 * rogpeppe likes tabs. only one key to indent :-)
<benji> teknico: cool, I'm just a little surprised that this function is dependent on global state
<rogpeppe> benji: which function is failing?
<benji> func (s *allWatcherStateSuite) TestStateBackingGetAll(c *C) {
 * teknico likes them too. Used them for months when starting with python eons ago, before being forced to use spaces :-P
<rogpeppe> benji: ah, hmm. i'd unwittingly assumed it was api tests failing
<benji> I don't think most editors have a problem inserting spaces when you hit the tab key.  Tab key != tab character.
<rogpeppe> benji: ah! i see the problem.
<benji> yay!
<gary_poster> hatch, sorry, I looked, and then was pulled down two rabbit holes.  I climbed back out of one of them, but it looks like you are all taken care of.
<rick_h_> luca__: heh ok. So by 'weekly' we've actually not missed a lot? luca__ but no, I don't have an email from nick on march 1.
<gary_poster> oh bah
<gary_poster> sorry hatch
<rogpeppe> benji: you've just added new attributes to RelationInfo, right?
<benji> yep
<gary_poster> that was supposed to be a different message and my irc client overrode it when I pressed the up key inadvertently
 * hatch confused
<rogpeppe> benji: so you'll need to change allWatcherStateSuite to add the relevant params to the expected added relation
<hatch> oh heh got it
<luca__> rick_h_: hmmm do you have one from Nick sent on the 19th?
<rogpeppe> allWatcherStateSuite.setUpScenario of course
<gary_poster> frankban, when I get an error in the charm like line 12 of http://pastebin.ubuntu.com/5670949/ (ignoring line 13's timeout for the moment) what can I do to diagnose?  The only think I know to do is to try and dupe manually, or rerun with debug-log running.
<rogpeppe> benji: ^
<benji> I'm confused as to why that should need to be done, but now is probably not the time to relieve that confusion.  Thanks!
<rogpeppe> benji: setUpScenario adds stuff to the environment and also returns the stuff we *expect* getAll to fetch.
<benji> ah!
<benji> but, isn't the thing it returns generated from the things it creates?  or are those two entirely distinct?
<rogpeppe> benji: it's hopefully slightly easier to maintain than a large section of code that adds stuff and a large slice with all the stuff that pertains to the code.
<arosales> gary_poster: are you targeting have the gui on the tablet running by ODS?
<rogpeppe> benji: they're almost entirely distinct
<rogpeppe> benji: note that although each change has an equivalent add() call, the add call doesn't interrogate the state.
<frankban> gary_poster: it usually prints a traceback. when it doesn't, it probably means jitsu timed out. In general, debug-log helps a lot, and if a single test fails it can be helpful to manually try to do what the failing test does, i.e. deploy the charm with staging=true.
<gary_poster> arosales, that's a nice to have
<gary_poster> frankban, ack, thank you
<gary_poster> arosales, want a quick check-in since I'm out the next three days?
<arosales> gary_poster: sure, I have some time this afternoon.  I will look for an open spot
<gary_poster> cool
<benji> rogpeppe: I have a problem, adding those constants to the expected values will create an import loop
<benji> I don't really expect you to do anything about it, just complaining. 
<rogpeppe> benji: which constants?
<benji> the endpoint data
<rogpeppe> benji: that's a bit surprising
<rogpeppe> benji: could you paste me the line(s) that cause the loop?
<rogpeppe> benji: AFAICS you don't need anything that's not from state/api/params or charm, but i'm probably missing something crucial
<benji> rogpeppe: I don't have a loop yet, I just expect one.  Let me go down this road and see if the loop materializes.
<frankban> gary_poster: EOD, and I have a prototype/draft of the model handlers/converters. Here is the current diff: http://pastebin.ubuntu.com/5671075/ . If you have time, I'd appreciate some feedback (email) before a continue following this path. Otherwise, no problem. In both cases, have a great week! :-)
<gary_poster> thanks frankban, I will look later.  Hope you have a good week too :-)
<hatch> gary_poster: do you have a minute for an impromptu review?
<gary_poster> hatch, very fast :-)
<hatch> http://bazaar.launchpad.net/~hatch/juju-gui/remove-units/revision/483
<gary_poster> looking
<hatch> thanks :)
<rogpeppe> gary_poster: here's the indirection branch: https://codereview.appspot.com/8269043/
<rogpeppe> gary_poster: which brings me to eod
<rick_h_> hatch: jcsackett Makyo sinzui or anyone else that's feeling in a good mood up for a smallish review please? https://codereview.appspot.com/8268043/
<hatch> rick_h_: I'll take one
<gary_poster> yay rogpeppe thanks!  have a good evening
<rogpeppe> gary_poster: hope you have a good time off!
<gary_poster> thank you :-)
<rick_h_> thanks hatch 
<gary_poster> hatch, fakebackend.js, line 430, why some?  would expect each
<gary_poster> use in line 431 makes sense
<gary_poster> you never return true in outer loop so some is effectively each
<hatch> gary_poster: oh woops, I used to have those two loops inverted so that should be changed to an each
<hatch> thanks
<hatch> oh wait
<gary_poster> cool hatch.  You may want to aggregate errors in line 438
<hatch> no that was there on purpose - so that it would stop if it came to an error
<hatch> the improv just logs errors to the console then returns false
<gary_poster> hatch, then it stops processing?
<gary_poster> returns false...
<hatch> well it 'raises' so I am assuming?
<gary_poster> werid
<gary_poster> just like my spelling/typing
<hatch> :D
<hatch> maybe you could take a look at remove_unit.py just to make sure
<gary_poster> k
<hatch> it throws exceptions and raises which I'm guessing exits the loop?
<gary_poster> hatch
<gary_poster>         except ServiceUnitStateNotFound:
<gary_poster>             context.log.warning("Unit %r does not exist", unit_name)
<gary_poster>             continue
<gary_poster> so that means it ignores missing units
<hatch> ahh ok I can aggregate the errors then
<gary_poster> and then they aren't really errors, oddly enough
<gary_poster> just warnings
<gary_poster> maybe put as separate attr?
<hatch> well err is only checked for truthyness so I will just turn it into an array and push them into there
<hatch> as right now it simply returns boolean and logs to the console
<gary_poster> hatch but my point is that this is not an error condition
<hatch> so this is actually adding more information than we had before
<hatch> ohh I see
<hatch> I'm not sure what would be an error then
<benji> yay, tests pass; my import cycle fears were unfounded
<gary_poster> hatch, only error is if unit's service is subordinate: we can't do that
<benji> time to see if my merge fears can come true instead
<hatch> yeah I didn't even know what that was lol
<gary_poster> hatch, I think service has subordinate flag
<gary_poster> puppet is subordinate hatch
<gary_poster> because it runs on the same machine as a, uh, non-subordinate charm, and supports
<gary_poster> you could have a logging charm too
<gary_poster> it is something that is supposed to be able to support ither charms
<hatch> oh ok - so is that something I should be taking into account?
<gary_poster> other
<gary_poster> nagios is another example
<gary_poster> hatch, would be easy to: get the service and loog at the subordinate flag
<gary_poster> look
<hatch> alright I'll be sure to add that
<gary_poster> hatch your logic in performOp_remove_units looks a bit weird in lines 385-386
<gary_poster> if (!res) then res.error would exist
<hatch> it's because res is boolean
<gary_poster> hatch, but an error object will also be truthy
<gary_poster> I'd document the return values of removeUnits also in the pydoc thing
<hatch> yeah so if (res.error) { data.err = res.error; } data.result = res;
<gary_poster> hatch that would work if you changed the output of removeUnits, yes
<gary_poster> hatch, think about what a reasonable reply from removeUnits would be in the abstract
<hatch> yeah I think I'll try and mirror the other methods
<hatch> to make it consistent
<gary_poster> for instance, I'd be tempted to return a hash of {removed: [], notFound: []} *or* {error: ...}
<gary_poster> but that's off the cuff
<hatch> yeah I could do that if that's allowed
<hatch> you said yesterday not to return any extra data than what's already there
<hatch> so I was trying to stick to that :D
<gary_poster> hatch, remember, there's a difference between fakebackend and pyjujuapi
<hatch> oh right, fakebackend can return whatever
<hatch> pyjujuapi only return the same stuff
<gary_poster> fakebackend is just supposed to be helpful JS thing with helpful JS API including helpful JS responses
<gary_poster> right
<hatch> ok so check for subordinate and aggregate warnings
<hatch> fix conditional
<gary_poster> I assume you will use your new generateServices helper to refactor the add unit test from yesterday too
<gary_poster> good idea
<hatch> yep I will for sure
<gary_poster> good work hatch, on the right track
<hatch> thanks
 * gary_poster returns to reviews
<hatch> getting the hang of this system heh
<benji> gary_poster: I am going to take the rest of lunch now (I was trying to get my branch done before the juju-core guys disappeared, almost made it) but I could use your advice about what to do afterward
<gary_poster> cool benji.
<gary_poster> benji, would be great if you could review the py env and go env commands and note any missing pieces.  We only have set-config listed on board now
<gary_poster> with get-config and get_endpoints in progress
<benji> gary_poster: ok, I'll take a look
<gary_poster> if there are any others we should make cards, and then tackle
<gary_poster> thank you
<hatch> rick_h_: review done
<rick_h_> hatch: thanks!
<rick_h_> hatch: replies sent. Thanks for the catches
<rick_h_> and suggestion on lazy loading the attr
<hatch> rick_h_: got it thanks
<hatch> so...
<rick_h_> hatch: so api is giving me: http://staging.jujucharms.com/api/0/charm/precise/cassandra-1
<rick_h_> hatch: see the options
<rick_h_> I need to loop/output those for display through handlebars which doesn't look looping over objects, but wants arrays
<hatch> yep I understand that
<rick_h_> k
<hatch> I don't think that config should be there at all
<hatch> I'd probably move that getter into a fn
<hatch> which would pull the data from the object and format it
<hatch> as I don't think that an attribute should be used as only a getter for another attribute
<rick_h_> hatch: well, I want this to be backwards compatible with the old charm model and I'll be passing this to the environment/config editing code from you guys
<rick_h_> hatch: so I want to keep split things I just need for me vs changing the model api as a whole. 
<rick_h_> hatch: though I could just move this to the view, but then I can't render the templates as model.getAttrs() :)
<rick_h_> hatch: so maybe if you don't want the double in the model I should look at moving the logic to the view instead
<hatch> if you set the model on the view to be this model then you could
<rick_h_> hatch: not following that last statement
<hatch> well if you're in your view and you set the views model to be this model then you would go template(this.get('model').getAttrs());
<hatch> assuming template is a hbs render function
<rick_h_> hatch: right, so it's called 'charm' and I do that currently. template(this.get('charm').getAttrs())
<rick_h_> but you're saying you don't like both options and config being in the model correct?
<hatch> no no, what I mean is that I don't like an attribute being created just to format another attribute
<hatch> to me you should be creating a parse getter method
<hatch> getFormattedObject: function() {}
<rick_h_> hatch: right, but I want to keep the original object based attribute. I don't want to replace it
<hatch> that's fine - it would be accessible via this.get('object')
<rick_h_> hatch: but you're right, what might be better is to add it as a method on the charm. charm.getOptionsAsArray
<hatch> and getFormattedObject would return the formatted object
<hatch> yeah - that's what I mean
<hatch> I ran into a similar situation in a previous project
<rick_h_> ah ok gotcha. I thought you wanted to change the parse method on the model for load/etc which isn't what I wanted
<hatch> oh no no definitely not :)
<hatch> so do you agree with the approach I'm suggesting?
<rick_h_> hatch: I *think* so. I'll update here in a sec
<hatch> alright :)
<rick_h_> can you call methods from handlebars? I didn't think so. 
<rick_h_> so I can't do {{#each this.getOptionsAsArray()}} right?
<rick_h_> yea, nvm
<hatch> only via a helper
 * hatch lunching &
<rick_h_> hatch: updated when you get time https://codereview.appspot.com/8268043/ 
<rick_h_> jcsackett: have time to look as well please? ^^
<jcsackett> rick_h_: looking.
<Makyo> Turns out, these are not valid x/y coordinates: http://pastebin.ubuntu.com/5671410/
<hatch> Makyo: rofl
<hatch> it is actually on the cardashian plain lol
<gary_poster> Makyo, lol
<Makyo> Just a little side effect of storing annotations as map[string]string.
<hatch> rick_h_: LGTM'd
<rick_h_> hatch: thanks
<gary_poster> bac, I don't have time for a review, but your endpointsbranch looks darn impressive on the face of it
<bac> gary_poster: thx.  hopefully i'll get it landed today.
<bac> lots of red in the branch.  :)
<benji> unhelpful test failur of the day goes to:
<benji> ... obtained params.Delta = params.Delta{Removed:false, Entity:(*params.RelationInfo)(0xf8400e7420)}
<benji> ... expected params.Delta = params.Delta{Removed:false, Entity:(*params.RelationInfo)(0xf8400c8d20)}
<hatch> bac: reviewing
<bac> benji: ah, those objects don't match.  you should make them be the same.
<benji> heh
<bac> hatch: not just yet.  i don't think the final version is on Rietveld yet
<bac> i did a -wip first
<hatch> oh alright
<hatch> lemme know
<bac> lbox propose is crazy slow
<hatch> I'm getting quotes to reroof/shingle my garage roof today
 * hatch don't feel so good no mo
<bac> my roof is 18 years old.  /me keeps his fingers crossed
<hatch> ~$3500 to sheet and shingle a detached garage...
<hatch> that's like $2000 labour haha
<bac> hatch: now it is up: https://codereview.appspot.com/8275043
<hatch> cool
<hatch> bac: does this need to be QA'd?
<bac> hatch: er?
<hatch> like a manual QA
<hatch> make sure everything still works as expected
<bac> hatch: are you asking if i've run it locally?  yes.
<bac> hatch: more poking at it would be appreciated
<hatch> bac: why are you binding to null in endpoints.js ln 167? I remember you saying the reasoning but now I can't remember
<hatch> :)
<bac> hatch: as before, b/c i don't care about the context but just need to curry in other params
<hatch> ahh yes
<bac> hatch: i see i left some commented code a few lines above.  please mark those so i don't forget to remove them
<bac> nm, i just killed them
<hatch> yeah I already marked em
<hatch> so...
<hatch> I'm a little concerned that these utility methods are just hanging off of juju.models
<hatch> imho they should be in a closure in juju.models.utils or something
<hatch> thoughts?
<bac> no thoughts, open to suggestions.  they do look a little bare.
<hatch> alright well if you're not opposed to it then I'll make a note and come back to it
<hatch> lol if(true) wth lint
<hatch> bac: review completed - I'd like to get some others input on moving the code into it's own closure
<bac> hatch: thanks.
<hatch> that's the only reason why it wasn't LGTM'd just fyi
<bac> hatch: the linter was complaining about the body of a for (x in...)  loop needing to be enclosed in an if
<hatch> that's crazy I've never heard of that before
<hatch> thenagain me and that linter don't agree on a lot of fronts :D
<bac> i think it is to force you to use a hasOwnProperty test?  didn't seem appropriate here
<hatch> ahh I suppose that's valid
<bac> the if (true) was used elsewhere so i stole it
<hatch> I guess you could also switch to a YUI iterator of sorts
<rick_h_> I broke jenkins. Does anyone have access to give it a boot? gary_poster ran it again earlier with success on my first branch today.
<gary_poster> rick_h_, on it
<rick_h_> gary_poster: ty much
<hatch> rick_h_ yep
<hatch> oh
<rick_h_> sorry to keep bringing it down :(
<hatch> nm :)
<gary_poster> rick_h_, not your fault :-(
 * rick_h_ wonders why jenkins hates him so...goes to buy flowers
<hatch> gary_poster: do I have your blessing this week to look into cleaning up the tests for an afternoon to try and solve that issue?
<hatch> :)
<gary_poster> on call
<hatch> anyone else need any reviews before I get back to doing real work? ;)
<benji> Makyo: I'm reviewing your branch.
<Makyo> benji, \o/
<Makyo> I'll back out the config-debug changes, forgot to revert that.
<hatch> is there a way to get a service model from a unit name?
<hatch> or do I need to split on '/' ?
<gary_poster> hatch, re blessing: if the in-browser stuff is nearing completion--only a few "implement X" cards left--or if you are blocked, yes
<hatch> alright I'll keep that in my back pocket
<gary_poster> cool
 * gary_poster goes to  reviews
<gary_poster> bac, hatch, very open to hatch's idea of a separate closure.  I'd like that to be a separate, follow-on branch if that's what you decide to do
<bac> ok
<gary_poster> unless it is done already, of course.  my point is merely that if this works, it unblocks other efforts, and is a great incremental step forward, so let's land it
<bac> Makyo: two reviews done on your branch
<bac> gary_poster: hatch's suggestion has not been done yet
<bac> bcsaller: great suggestions.  thanks.
<bcsaller> bac: :) glad to help
<bac> gary_poster: could you please review ben's comments and leave a comment on the MP as how you'd like me to proceed?
<gary_poster> ok
<gary_poster> bac, how long will it take
<bac> probably 1/2 day
<gary_poster> bac, not too bad.  up to you but I suggest that you see if you can identify a compromise with reviewers to land this today (or early tomorrow) and then make a new branch tomorrow.  ben's db stuff in particular is the right thing to do technically, though not necessary at this instance, bot if it is half a day and you land incrementally I'm ok with it
<gary_poster> but
<bac> bcsaller, hatch: you ok with that?  land the branch basically as is with a follow on fix?
<hatch> yeah sure - I'll LGTM it if you can be sure you destroy that stuff in the test please :)
<bcsaller> bac: I'm ok with that plan as well, if another card is made. 
<bcsaller> I'll update the MP
<bcsaller> or CR, whatever :)
<bac> thanks
<bac> hatch: your comment about cleaning up in the tests is directed at the creation of a charm.  but the charm doesn't have any attached events as your comments states.  so to be clear, you are requesting the service with the events be destroyed or the charm too?
<bac> hatch: it's not enough to destroy the env and app?
<hatch> bac: I may have misread - but I thought it was attaching events to something that wasn't being destroyed
<hatch> if that's not the case then feel free to disregard
<hatch> let me check
<bac> hatch: the events are attached to the services modellist.
<bac> lord knows i don't want to introduce any extra test time bombs
<hatch> bac: ok looks like the instance I was concerned about is actually attaching an event to itself so if you charm.destroy(); every time you `new models.Charm();` then that will be good
<hatch> I figure that anytime we use `new` we should follow it up with a `destroy()`
<hatch> I'm hoping that will help :D
<hatch> gary_poster: any idea how I can test the is_subordinate code?
<hatch> since we dont' have a connection to the real charm store
<gary_poster> hatch not sure what you mean--sorry a lot of plates going.  context?
<hatch> the remove_unit fake back end code now throws errors if the service is_subordinate
<hatch> to match the improv code
<hatch> but how do I create a subordinate service
<hatch> I guess I could create another dataset in test/data with a subordinate charm?
<gary_poster> hatch just flip the flag on the service?
<gary_poster> in a test setup?
<hatch> oh heh...I never thought of that
 * hatch slowly walks away
<gary_poster> :-)
<Makyo> benji, I know it's late, but are you still around?
<benji> Makyo: just barely
<Makyo> benji, quick question, feel free to tell me off.  Which yuidoc comment style do you prefer?  I used one from the yuidoc docs, but can easily change.
<benji> I don't really care, we started with the ones with *s down the side then some started removing the stars and one of the spaces (leaving the text 2-space indented from the opening "/**"
<benji> yours have /**, no indent and then **/  (as opposed to "*/") plus I'm sure there is one or two other variations
<hatch> In need of 2x reviews please https://codereview.appspot.com/8280044/
<benji> so my comment was more of a "we need to figure out what we want and enforce it" than a "you're doing it wrong! die in a fire!" ;)
<Makyo> benji, alright.  Deindented while trying to remove the star, will hunt around for the most consistent.  And yeah, no fires :)
<hatch> I do /** */ then with a 2space indent
<hatch> with no stars down the side
<Makyo> Alright.
<benji> ^^^ would be a fine prescription as far as I am concerned 
<hatch> Makyo: you can see how I do it while you're reviewing my branch :P
<hatch> haha
<benji> (and I'll even try to get around to updating the yuidoc linter to complain on anything else)
<Makyo> Well played.  I'll review it just for that :)
<hatch> lol ^5
<hatch> jujugui anyone else available for a review before EOD?
<benji> hatch: I can get you real quick.
<benji> https://codereview.appspot.com/8280044/ right?
<hatch> great thanks
<hatch> yep
<benji> hatch: done
<gary_poster> hatch I will look before I stop today
<hatch> gary_poster: no need, both done :)
<hatch> thanks though
<gary_poster> but if you have other reviews and feel good about it land
<gary_poster> cool
<hatch> now onto expose and unexpose
<hatch> oh no first I'll clean up those tests with my new utility methods
<hatch> hey look at that, CI test caught a real failure
<hatch> lol
 * hatch is fixing
<hatch> hmm unable to reproduce failure on my local machine
<hatch> will fire off another CI see if it was a fluke
<hatch> hmm the test happens on prod on IE
<hatch> investigating
<hatch> *sigh*
<hatch> looks like a bad merge into trunk
<hatch> OR not
<hatch> I love when different tests fail every time you run them
<hatch> hmm it's failing on revno 487
<hatch> going to keep stepping back
<hatch> anyone else around still with a win 8 vm?
<hatch> ok somewhere between 483 and 486 breaks IE
<hatch> sorry its taking me a while to build each version....slow internets
<hatch> ok some change http://bazaar.launchpad.net/~juju-gui/juju-gui/trunk/revision/486 causes tests to fail in IE all over the place
<hatch> ok it's in test_charm_container.js
<hatch> test 'only shows items up to the cutoff at first' causes it to fail...
<hatch> oh rofl wow - I can't believe it
<hatch> ok I'll patch this tonight
<rick_h_> hatch: we brokage things on you? 
<rick_h_> hatch: heh, yea we talked about getting a Windows/IE10 setup going for everyone today actually. That sucks
<hatch> rick_h_: well....yes you 'did' but it's not your's or jc's fault
<hatch> the changes to CharmContainer somehow exposed an issue that we were destroying the container and THEN destroying the CharmContainer instance causing it to throw errors when it tried to destroy the container
#juju-gui 2013-04-03
<rick_h_> hatch: oh hmm, strange. :/ 
<hatch> I haven't figured out the exact change that caused it to expose that - but I'm working towards it
<hatch> the reason it got so far was because sometimes it passes without issue lol
<rick_h_> ok, let me know if you need any help. We've been trying hard to not have our involvement cause you grief
<hatch> we just happened to always get a passing one rofl
<hatch> well I would like someone to duplicate my findings - do you have a win 8 vm?
<rick_h_> hatch: win7, but has IE10 on it
<rick_h_> sec, just committing/linting my current branch
<hatch> sure - I'm oh poo
<rick_h_> oh son of a...
<hatch> lol
<hatch> my fix did not fix
<rick_h_> Vbox is failing on start about a missing < tag :/
<hatch> back to the drawing board
<rick_h_> oh hell, the .vbox xml file is corrupt
<rick_h_> and of course I don't backups my vms...they're vms... :/
<hatch> how the heck...
<rick_h_> yea, there's a -prev file that's missing half of it
<rick_h_> and the .vbox file is empty
<rick_h_> guess last time I shut it down it must have crashed out or something
<rick_h_> bah, have to redo the windows install and setup. Grrrr
<hatch> alright well no problem - it looks like the 'fix' wasn't actually a fix
<hatch> I'll have to look for the root cause
<rick_h_> sorry, no IE10 handy now :(
<hatch> I am leaning towards there being some cleanup issues
<rick_h_> always seems to be
<rick_h_> wonder if there's some way we can monkey patch Y.Base and Y.Base/destroy to console.log creation/destruction and sort the results out
<hatch> well turning on debug logs will - but this is only happening on prod builds
<rick_h_> I just meant to do a tset run and list out all the crap that's not getting cleaned out in one swoop
<hatch> ohh, well I'm not sure if that will include all the information
<hatch> maybe we need better procedures
<hatch> I don't know what those would be haha
<hatch> as this is looking like some obscure race condition issue
<rick_h_> heh, ended up creating a handlebars helper for that obj->array stuff
<hatch> :)
<hatch> ok I gota run for a while but I'll tell you what I have found
<rick_h_> hatch: rgr, have fun
<hatch> if you check out 486 and run in IE10 you will get a TON of failures
<rick_h_> :(
<hatch> but if you comment out test_charm_container.js then they all go away
<rick_h_> really wish we had good ole single yui per file suite put together. oh well
<hatch> OR if you comment out the tests in that suite they go away
<rick_h_> k, I'm going to finish this branch up and I'll try to reset up my VM tomorrow morning and can help out 
<hatch> if you uncomment even a single test - then boom, 100s of failures
<rick_h_> ok...that makes no sense. /me loads up tests in that file.
<hatch> yeah I have absolutely no idea but I really gota run now :D
<rick_h_> k
<hatch> have a good night, talk to ya in the AM
<hatch> rick_h_: -status update- after a few hours of debugging I have come to the conclusion that that test suite is not causing the issue it's just seems to be triggering the issue more often. I believe I have narrowed it down to a couple strong suspects and will bring it up in the AM.
<rick_h_> anyone around for some code reviews? https://codereview.appspot.com/8311043/ is for Huw and is mostly images :) 
<rick_h_> https://codereview.appspot.com/8296043/ is more JS 
<bac> hi rick_h_ -- can i get some guidance from you based on some suggestions ben made yesterday?
<bac> rick_h_: he suggested i wrap some event handling i'm doing into a controller.  i'm a bit confused as the mechanism.
<rick_h_> bac: sure thing. linky to what we're talking about?
<bac> https://codereview.appspot.com/8275043/diff/2001/app/app.js#newcode364
<rick_h_> looking
<rick_h_> bac: sec, looking at how db/db.services work. 
<bac> rick_h_: db.services is just a ModelList...
<rick_h_> ok, I think I'm getting hung up on the term 'controller' being too equal to a Y.View
<rick_h_> bac: so I think he's just meaning something like this: http://bazaar.launchpad.net/~juju-gui/juju-gui/trunk/view/head:/app/subapps/browser/views/view.js#L66
<rick_h_> notice here I've got a helper to do all the event binding for a task
 * bac looks
<rick_h_> bac: and in the destructor I walk through and destroy/detach those events
<rick_h_> bac: so I *think* he's just suggesting you move the event bindings into a descriptive helper, keeping a reference to them, and allowing them to be detached via a second method
<rick_h_> bac: this is some of the stuff causing us issues in tests where events are created, but not auto destroyed/detached when multiple instances are created of something that binds up a bunch of events. 
<bac> rick_h_: so there is no special infrastructure magic ... just create a new class with bind and unbind methods (or whatever i want to call them) that manages subscriptions?
<rick_h_> no, a simpler case is a widget like: http://bazaar.launchpad.net/~juju-gui/juju-gui/trunk/view/head:/app/widgets/charm-search.js#L60 we just added a matching _unBindUI to match the widget api of bindUI
<rick_h_> bac: I don't think you need a new class. All of this has to do with models.something so maybe there's a good class to stick this on already
<rick_h_> bac: and you can do a db.services.bindChangeEvents()
<rick_h_> and then db.services.unbindChangeEvents or the like
<bac> rick_h_: and what would that call?
<bac> what is the glue between my controller and db.services?
<rick_h_> bac: db.services is the controller in this case. 
<bac> no, db.services is a ModelList
<rick_h_> so you can add bind/unbind methods to ServiceList for instance
<rick_h_> bac: yea, that's fine. You can add methods to a ModelList
<bac> rick_h_: nm, my bad.  i didn't realize there was a ServiceList already extending ModelList
<rick_h_> oh hmm, so the only thing is I didn't realize that the callbacks you want to run are coming from models/endpoints. So maybe the work needs to go on that end. sorry trying to see how the parts fit
<bac> rick_h_: yes, and model/endpoints needs to be encapsulated in a new entity
<bac> or at least the new management methods
<rick_h_> bac: hmm, do the callbacks belong on the serviceList themselves? Right now they're just helper methods on juju.models
<bac> rick_h_: they could move there, i think
<rick_h_> bac: so yea, in looking at this I'd move the callbacks into the serviceList object, have the bind/unbind events on there. And then the app.js just calls db.services.bindEvents() or the like
<rick_h_> finally making sure to have an unbindEvents method and make sure it's called on the serviceList.destructor method
<bac> that makes sense
<rick_h_> cool :)
<bac> rick_h_: one loose end, where would you suggest my endpointsMap live?  right not it too is hanging off models
<bac> s/not/now
<rick_h_> looking
<rick_h_> bac: what is an 'endpoint'? a provide/requires target or something?
<bac> rick_h_: yes.  the endpoints map is an object with lists of provides/requires for each known service
<rick_h_> bac: hmmm, maybe endpoints shold be namespaced at least and then the bind/unbind methods created on there. It can take the serviceList instance as an argument and app.js would do models.endpoints.bindServiceList(this.db.services)
<rick_h_> but then endpoints almost wants to be a class so you can keep instance related data (like the event handlers you're holing from bind) and remove them
<bac> yeah, ok
<rick_h_> bac: have a hangout, biab
<rick_h_> bac: ok back. So what do you think? endpoints is a diff module that wants to add event callbacks to ServiceList?
<bac> rick_h_: yeah, that's how i'm going
<rick_h_> bac:  ok cool then. 
<hatch> morning
<rick_h_> morning hatch 
<hatch> is that branch from jc one that fixes whatever was causing the failures?
<rick_h_> hatch: once you've got your morning cup of joe have some reviews if you have a chance :)
<hatch> sure thing
<hatch> rick_h_: so is that branch from jc the one which fixes the test failures?
<rick_h_> hatch: no, he's not aware of the stuff from yesterday atm. 
<rick_h_> hatch: it's fixing some edge cases of the widget itself. I forgot to bring up swapping the teardown code around. thanks for catching
<hatch> last night I spent a few hours trying to track down our overall test failure and I have narrowed it down to one class
<rick_h_> which class? 
<hatch> but in that I found a LOT of tests which fail when run on their own
<hatch> so those will need to be fixed
<rick_h_> hmmm, that's good though if tests fail in isolation
<hatch> sorry, suites which fail
<hatch> no suite should rely on a previous suite
<rick_h_> jcsackett: ^^ so the teardown in the tests first remove the dom and then the object bound to it. Those need to get swapped
<rick_h_> hatch: +1 for sure
<jcsackett> rick_h_: oh, yeah, that would be good.
<rick_h_> why I like the split files in normal YUI tests
<hatch> rick_h_: yep
<rick_h_> jcsackett: yea, in some cases the CI would choke because it was trying to unbind itself from a dom node long gone
<hatch> rick_h_: the failing class has something to do with the jujuTests.utils.SocketStub class
<hatch> if I remove the tests which use that stub they never fail
<rick_h_> hatch: https://codereview.appspot.com/8296043/ is my branch that does the move to the handlebars helper and such
<rick_h_> hatch: hmmm, good to know where to look then. That could suck debugging out the socket stuff like that. I've not really messed with any of that
<hatch> yeah I'm going to bring up my findingsin our standup in 1.5h
<rick_h_> hatch: cool
<hatch> is there going to be a codereview url for Huw's code?
<rick_h_> hatch: yes, I looked it over and qa'd it. It's not complete and we'll get UX to do some reviews in a bit
<rick_h_> hatch: so if you can also peek at that I'd appreciate it
<hatch> ahh ok
<rick_h_> hatch: it's just showing as from me since he seems to have some issues iwth lbox/landing and I'd rather he spent time working on it vs trying to fix it
<rick_h_> I think some of his stuff was hitting some timeouts in the api calls lbox makes to LP and such
<hatch> ahh I gotcha
<rick_h_> so our rule is he codes by night, I help him land by my day, and hopefully he's ready to go the next night. timezones ftw!
<hatch> haha yeah I used to work with a team from AUS, and I was their only NA developer so at the end of the day I'd commit code and vise versa so the progress never stopped heh, it was kind of cool - also irritating sometimes if you needed some info
<hatch> man I wish rietveld id's were sequential
<hatch> or hashes - at least then they woudln't look sequential :D
<hatch> the three reviews I'm working on all end in 043 :D
<rick_h_> lol
<rick_h_> hatch: that's crazy. Missed that when looking. 
<hatch> rick_h_: did you notice that you can't LGTM your own code on rietveld? https://codereview.appspot.com/8311043/
<rick_h_> hatch: yea, oh well. 
<rick_h_> it doesn't know it's actually Huw's code
<hatch> yeah - that's odd that it doesn't allow it
<hatch> but you can still commit it regardless
<hatch> haha
<rick_h_> can't hold me back!
<hatch> rick_h_: I'm qa'ing this design branch and the charm slider thing is just bouncing back and forth outside of the sidebar
<hatch> charm Browser is on two lines with what looks like a search box under it
<rick_h_> hatch: yea, the design branch only effects the fullscreen urls
<rick_h_> the sidebar isn't handled yet
<rick_h_> so http://uistage.jujucharms.com:8080/bws/fullscreen/precise/cassandra-2 is a sample url to qa
<hatch> you should really position absolute this stuff so that you don't have to scroll down :)
<rick_h_> only your local branch that is :)
<rick_h_> hatch: :P
<rick_h_> it really shouldn't reload the page 3 times so it doens't scroll you back to the top :P
<hatch> rick_h_: am I supposed to be able to check/uncheck these checkboxes? or is that still WIP?
<hatch> under quality
<rick_h_> hatch: yea, wip. They'll get replaced with icons if checkmark and red x
<rick_h_> they won't be editable
<hatch> ok and one more thing - the Add button in the top right is two different colors of red
<hatch> it's looking really good though
<rick_h_> hatch: ok, note it please with a screenshot if you get a chance
<rick_h_> I'd still like to be able to land it though with a bug/update report
<rick_h_> if we get it quick I might be able to get staging updated for the UX folks to see progress before their EOD :)
<rick_h_> hmm, I don't see the double red. Do you mean between two places or two colors on the same button?
<hatch> sec
<hatch> i'll screenshot
<rick_h_> thanks
<rick_h_> but yea, this is a first pass. There's still some more updates in a couple of tabs, the interaction between full/sidebar sizes to fix up. url tracking for tabs, etc
<hatch> pm'd the link
<rick_h_> thanks
<Makyo> jujugui call in 2
<Makyo> rick_h_, joining us today?
<rick_h_> Makyo: yep, sec
<Makyo> rick_h_, alright.
<teknico> gentle reminder, quick'n'easy review opportunity, get your fix! https://codereview.appspot.com/8307043
<hatch> teknico: on it
<teknico> hatch, thank you :-)
<hatch> teknico: looks good but can you do me a favour and comment out every other test file in test index.html, run the tests, then uncomment them and use describe.only() and run the tests for both prod and debug?
<hatch> I know it's a lot of work but I'd really like to track down these test failures
<hatch> :)
<hatch> if not that's ok too :)
<teknico> hatch, ok, now breath deeply and say it again *slowly* :-)
<teknico> :-)
<hatch> lol ok
<hatch> I want to make sure that these tests don't rely on anything in the environment from previous tests
<teknico> ok
<hatch> so in order to do that we need to do a couple things
<frankban> Makyo: do you have a minute for a call?
<hatch> first step is to comment out every other test file in the index.html and only run this python one
<Makyo> frankban, sure.
<teknico> ok
<frankban> Makyo: emily
<hatch> next step is to uncomment all of those tests and add .only() to the describe
<hatch> so that it will load all the other tests but only execute yours
<hatch> if any of those fail then we have an issue with it relying (or being affected) by previous tests
<teknico> hatch, do you mean to add .only() to just one of the tests I added, once per test?
<hatch> nope to the describe so describe.only('your test suite', function....
<teknico> hatch, oh, at the top, right
<hatch> thanks sir
<teknico> hatch, do you suspect I might get different results from what you're getting?
<hatch> I do - but I hope you don't :D
<teknico> hatch, ok, trying
<teknico> hatch, when I comment out all other test files, I do get an error:
<teknico> TypeError: 'undefined' is not a function (evaluating 'juju.newEnvironment({conn: conn})') (http://localhost:8084/test/test_env_python.js:22)
<hatch> ugh
<hatch> ok I'm going to propose that we create slack tasks for these fixes and tag them all the same
<teknico> hatch, and I get the same error when using describe.only
<hatch> yeah that's what I was afraid of
<teknico> both when running make test-prod
<hatch> alright can you make a bug on LP with those details and tag it with 'test-improvement'
<hatch> please and thank you :)
<teknico> hatch, sorry, I'm landing my branch and somewhat in a hurry to get out the door :-)
<hatch> ok np I can create it
<teknico> EOD and all that
<teknico> hatch, thanks!
<hatch> I think my sub is finally giving up the ghost after 10years
<bac> you have your own submarine?
<bac> or a really old sandwich?
<bac> bcsaller: hey got a sec?
<hatch> sub wooooooofer :P
<bcsaller> bac: sure
<hatch> bcsaller: any idea when you're going to drop your branch with the fakebackend stuff? I just want to make sure none of my changes are going to be clashing with yours
<bcsaller> hatch: I can push a wip version in a few minutes and give you a link
<hatch> cool thanks
 * hatch races to complete to bcsaller has to deal with the conflicts
<hatch> :P
<hatch> s/to/so
<bcsaller> ha
<bcsaller> hatch: as long as we don't implement the same methods it should merge cleanly
<hatch> yeah bzr is pretty smart that way
<bcsaller> and that would be bad for other reasons
<bcsaller> I did try to attach my face to the cards I'm covering 
<hatch> ugh this testing is driving me up the wall
<hatch> I'm almost 100% convinced all of our errors are comign from the instances created and never cleaned up in the test utils file
<hatch> looking for two quick reviews https://codereview.appspot.com/8331043/
<bac_> hey bcsaller, i'm trying to push the endpoints controller into the views as you suggested.  some tests are failing because, e.g, topo.get('endpointsController') is undefined.  is there another step to push it from the view into topo?
<hatch> going to take lunch
<bac> bcsaller: nm
<hatch> before I go, bac did you get it?
<hatch> oh
<hatch> :)
<hatch> looks like launchpad is down
<bac> hatch: wfm.  mustf
<bac> must've been a short glitch
<bcsaller> bac: I'm guessing you got this but you have to pass it from the env view into the topo.
<bac> bcsaller: yeah Makyo showed me that code
<bcsaller> excellent
<hatch> back
<hatch> and good lp is back up :)
<bac> hatch, bcsaller: the new MP is up, if you're interested in having another look...but i can also get others to do it.
 * bac -> dog walk.  bbiab.
<bac> oh: https://codereview.appspot.com/8338043
<hatch> sure
<ahasenack> guys, I'm having trouble logging in on the juju gui, it just sits there. javascript console has a lot of these: http://pastebin.ubuntu.com/5674867/
<ahasenack> have you seen this before?
<hatch> ahasenack: is this on uistage?
<ahasenack> hatch: no, my own deployment, using "stable"
<ahasenack> using chrome 26.0.1410.43 (Official Build 189671) 
<ahasenack> (not chromium)
<hatch> ok one moment
<ahasenack> hatch: it opened now
<ahasenack> hatch: after ~10min or so
<ahasenack> hatch: it's a big juju deployment, maybe because of that
<ahasenack> hatch: well, bigish, around 40 computers
<hatch> hmm no that shouldn't be it
<hatch> I'm just investigating that error
<hatch> sorry I'm doing like 10 things at once :D
<hatch> ahasenack: ok that error shouldn't happen
<ahasenack> hatch: ok
<hatch> it's saying its an unknown event of type msg
<hatch> but msg is a known and valid event
<hatch> is it reproducable?
<hatch> reproducible*
<ahasenack> hatch: I think it's still showing
<ahasenack> hatch: let me clear the console
<ahasenack> hatch: I don't see it anymore, let me logout and login
<ahasenack> logout got me this
<ahasenack> Uncaught TypeError: Cannot read property 'parentNode' of null 
<ahasenack> http://pastebin.ubuntu.com/5674904/
<ahasenack> let me try login now
<ahasenack> hatch: worked right away, just got one tiny backtrace
<ahasenack> http://pastebin.ubuntu.com/5674908/
<hatch> ok we have a ticket already for that one - actually it may be fixed in trunk already
<ahasenack> I'm trying a new incognito window
<ahasenack> hatch: yeah, it happened again
<ahasenack> hatch: I think right after the login form showed fully
<hatch> it throws the unknown event error?
<hatch> does it hang too?
<ahasenack> hatch: http://i.imagebanana.com/img/iijtafab/Selection_004.png
<ahasenack> hatch: it's not frozen, I haven't typed in a password yet
<hatch> ok let me know if it works as expected
<ahasenack> hatch: I'm logging in, and it looks like it will take a long time again
<hatch> hmm
<ahasenack> page looks frozen, cursor is a normal arrow, events keep coming in in the console
<hatch> hmm
<hatch> I'm not even sure what version 'stable' is
<hatch> jujugui anyone know ^
<hatch> ahh looks like it's from 2013-02-35
<hatch> ahasenack: I would be interested if the error still happens on trunk - are you familiar with the process to deploy trunk? Or is this a 'real' environment you're working with?
<ahasenack> hatch: it's 0.3.1
<ahasenack> hatch: this one I can't upgrade, but if I get the chance I will try trunk
<hatch> hmm
<hatch> I thought our most recent release was 0.2.1
<Makyo> hatch, ahasenack - event is missing the 'op' attribute.  Looks like strange data coming from juju.
<hatch> Makyo: oh you're right
<hatch> I missed that
<hatch> oops
 * hatch kicks himself
<ahasenack> hatch: oh, and it logged in now
<ahasenack> I wasn't paying attention to that window, could have been a few minutes ago
<Makyo> There is an err: true in there, so maybe it's a response to a bad call from the gui.
<ahasenack> I need to go, see you guys around tomorrow
<hatch> Makyo: that's returned by default I think...see ln123 in python.js
<hatch> ahasenack sure thing have a good night
<ahasenack> thanks
<ahasenack> you too
<hatch> bac: review done - let me know if you have any questions
<Makyo> hatch, That would mean the gui's in read-only mode, correct? And if so, the 'eventually logging in' part of the problem seems kind of out of place.  Looking into _firePermissionDenied, though.
<Makyo> Ah, just adds a notification.  Something to ask about later
<hatch> Makyo: yeah that's what I was thinking too
<hatch> I can't think of any other instance when err would be 'true'
<Makyo> Yeah, not unless something really did come from juju with an error.
<hatch> yeah but that would log to the juju console
<hatch> I guess I never got him to check that
<hatch> :)
<hatch> yay one more test then I'm done un/expose
<hatch> holy lots of tests
<hatch> ok I need to assert a string which has single quotes in it so I wrapped it with double quotes....well the linter doesn't like that
<hatch> so I escaped them....but now they won't assert
<hatch> lol
<hatch> any way I can tell the linter to shove-it ?
<hatch> ahah!
<hatch>   /*jshint quotmark:double*/
<hatch> if anyone is still around and looking for a review to do :) https://codereview.appspot.com/8339044/
<Makyo> Sure, give me a few.
<hatch> thanks
<Makyo> hatch, for later, it occurs to me that ahasenack won't be able to check notifications until the login eventually succeeds, since they aren't available until then through the UI, and may not even be stored.  Still, we can hope.
#juju-gui 2013-04-04
<hatch> Makyo: I was thinking the juju terminal console - wouldn't he be able to get it from there? Improv should be dumping that sort of stuff no?
 * mariusko thinks he hits bug #1149410 again...
<_mup_> Bug #1149410: Stuck on "Trying to connect to the Juju environment" <juju-gui:Incomplete> <juju (Ubuntu):Incomplete> < https://launchpad.net/bugs/1149410 >
<frankban> mariusko: what provider are you using?
<frankban> mariusko: and what version of the GUI?
<mariusko> frankban: AWS
<mariusko> I changed back to a stable version. That is juju-api-branch: lp:~hazmat/juju/rapi-rollup and juju-gui-source: stable
<mariusko> Worked for some time. I also sometimes have more success using IP address that DNS name
<frankban> mariusko: you switched back to stable using "juju set"?
<mariusko> frankban: nope, it was a new installation
<mariusko> new deployment
<frankban> mariusko: any javascript console errors?
<mariusko> frankban: "Application Cache Error event: Master entry fetch failed (-1)"
<frankban> mariusko: humm.. are you using chrome/chromium?
<mariusko> frankban: chromium. Isn't FF still not supported?
<frankban> mariusko: try to delete the appcache: go to chrome://appcache-internals/ and remove the entry corresponding to your ec2 machine
<mariusko> frankban: same problem with FF. Python process on the machine is using a lot of CPU 
<mariusko> but it has 1,7 GB RAM
<mariusko> "WebSocket connection to 'wss://x.x.x.x/ws' failed: WebSocket is closed before the connection is established"
<mariusko> frankban: debugging further, /ws gives "503 Service Unavailable: No server is available to handle this request."
<mariusko> I see that there is a haproxy there, and "http://127.0.0.1:8080/" gives nothing
<mariusko> Uhm, even "/var/lib/juju" is gone on the server now
<frankban> mariusko: any error in /var/log/upstart/juju-*
<rick_h_> did something change with the tests? The ones loading json are failing for me as the paths to the test/data/xxx seems to have changed?
<rick_h_> bah, some test is monkeying with the url adding a / to the end in chrome causing the paths to fail
<frankban> rick_h_: make test-server works well for me in trunk
<rick_h_> frankban: yea, there's a test half way through that's adding a / after index.html and causes all the relative paths to test data files to be index.html/data/xxxx.json
<rick_h_> frankban: might be an interaction with chrome I've got here
<rick_h_> hmm, does it for me in test-prod as well though so must not be a chrome thing
<rick_h_> nvm, guess it's something in this branch. 
<rick_h_> hatch: when you get a chance can you peek at/QA the button fix you noticed yesterday? https://codereview.appspot.com/8363043
<mariusko> frankban: killed the instance. Will check next time. New instance working.
<frankban> mariusko: ack
<bac> hatch: ping when you're around
<rick_h_> bac: looks like the branch yesterday went ok then? Caught the reviews after EOD. 
<bac> rick_h_: yeah, just doing some clean up
<rick_h_> bac: I didn't lead you too far astray when what they meant I hope?
<rick_h_> cool
<bac> thanks for your advice
<Makyo> hatch, re juju terminal/improv - that was a live install, not improv, but there is a chance the bootstrap node would have it in its logs; I don't know if that all gets logged.
<Makyo> Also, frankban, last daily for the tablet just about bricked the thing, so I was screwing with that all yesterday, sorry I didn't get more review done; I'll do that first thing.
<frankban> Makyo: no problem, and thanks.
 * frankban fighting against allhands
<benji> hatch: do you need a review for "implement unexpose"?
<hatch> benji yeah looks like i need one more
<benji> hatch: I'll be glad to.  I don't see the URL on the card, do you have it at hand?
<hatch> https://codereview.appspot.com/8339044/
<hatch> thank yas
<hatch> bac: I'm here
<bac> hey hatch
<bac> thanks for the excellent review.  i only had one question about one of your comments.  i think my question is in the review now.
<hatch> alright lemme check
<bac> first comment at https://codereview.appspot.com/8338043/diff/5001/app/store/endpoints.js#newcode24
<hatch> the endpoints map and subscriptions is the properties I was talking about - if you define them in the initializer then they are local to the instance not on the prototoype
<hatch> that's what I mean
<hatch> wrt 'following properties'
<hatch> so judging from your comments you already did that
<hatch> brb
<bac> hatch: cool.  please update the review if you think it is landable
<hatch> bac: endpoints.js has a syntax error...
<hatch> lol how did that get through the linter
<hatch> ln 44
<bac> hatch: it is a style issue but not syntax i think
<bac> fixed
<hatch> oh right
<hatch> that's what i meant :)
<hatch> LGTM'd
<bac> thx
<bac> hatch: i still have an open question about reset as i'm unsure when that is called.
<bac> hatch: should reset call unbind?
<hatch> if there aren't any endpoints in there would you still want to listen to those events?
<hatch> if reset calls unbind then you'll need to rebind them again no?
<bac> yes
<bac> i'll land as is and pick ben's brain later.
<frankban> benji: do you have some notes re missing go watcher attrs? I am filing a bug I will work on after my current handlers/converters refactoring branch is merged
<benji> frankban: I turned the ones I found into cards.
<frankban> benji: are they in story 1? I cannot find them in the board
<benji> frankban: I only found two and one is done now.
<benji> perhaps you found a treasure trove of missing data that I missed.
<frankban> benji: no, I am just trying to figure out what's missing.
<hatch> rick_h_: is huw using OSX and that's why he can't lbox?
<frankban> benji: do you have a minute for a quick call?
<rick_h_> hatch: no, he's had a few diff errors. A couple look like LP timeouts. Another was just problem figuring our linting. CSS rules matching xxx_yyy vs xxx-yyy don't actually output a message
<rick_h_> hatch: so he's just not spent time figuring it all out so he's getting a pass
<benji> frankban: sure
<benji> frankban: the normal hangout?
<frankban> benji: yes, I am there
<benji> frankban: hold on, the Google hangouts plugin isn't working
<hatch> rick_h_: ahh ok
<hatch> rick_h_: I'm a little confused as to why we are using images for that add button - I don't see anything there that coudln't be done with a icon font and some css
<rick_h_> hatch: I'm not sure at all. Since we're getting .pngs from UX I'm not sure if it's a time thing to pull it out or if there's something about it. We can bring it up.
<hatch> alright thanks - yeah because that's 3 http requests right there which could be one icon font and some css
<hatch> I'll approve it but just make a note please :)
<rick_h_> hatch: will add a discussion card to our board
<hatch> (Y)
<hatch> oh look at that CI broke
<bac> benji: reviewed your branch.
<benji> bac: the go-juju one?
<hatch> oh hmm, doesn't look like I can actually do destroy_service until remove_relation is done
<bac> benji: yep
<benji> bac: is your review "binding" (i.e., can I count it as my second review?  please say yes, please say yes...)
<bac> guihelp: i had a pre-existing committment at noon today before we changed our meeting time.  i'm going to have to miss the meeting today.
<hatch> :'(
<bac> benji: sure.  i'll be happy to LGTM it when fixed
<Makyo> bac, alright.  Anything about your current work we ought to know?
<bac> Makyo: it is stellar
<frankban> :-)
<Makyo> \o/
<benji> bac: what I mean is, are we appoved as full reviewers for go-juju?
<bac> Makyo: branch landed.  doing misc stuff right now (lp2kanban, reviews, etc) before picking up another item after lunch
<bac> benji: yes, that is my understanding
<Makyo> bac, sounds good.
<benji> excellent
<bac> Makyo: i'm open to suggestions on what to do next if the crowd has ideas
<bac> benji: the times i've prefaced reviews with "i'm not an official reviewer" the juju-core guys pushed back and said "you're good enough"
<hatch> bcsaller: are you in yet?
<benji> k
<bac> benji: why the lack of tests on that branch?
<benji> bac: I'm confused.  It has tests, not many, but it doesn't do much and it follows the same pattern as the other branches that do similar things.
<bcsaller> hatch: yes, mostly
<bac> benji: did i miss something?  i just saw the one api_test
<bac> i may have missed it due to multiple revisions on the rietveld
<hatch> bcsaller: ok I THINK the order I need to do things are... add_relation > remove_relation > destroy_service
<hatch> because you can't destroy a service unless it has no relations
<hatch> and you need to be able to remove the relations if it has some
<hatch> but you can't remove any if you haven't added any
<hatch> yay TDD
<hatch> :D
<benji> bac: yep, that's probably all there is; for better or worse that is what has been deemed acceptable.
<hatch> bcsaller: so what I"m asking is if that order of events makes sense to you
<bac> benji: ok.  i expecte to see something in statecmd.  but, as you say, it doesn't do much.
<bac> "expecte" -- it's like i'm speaking french now
<Makyo> expectÃ©
<bcsaller> hatch: that makes sense to me. 
<hatch> word
<hatch> these look like large tasks
<bcsaller> hatch: they kind of are, my stuff turned out to be bigger than I thought. W/o relying on the validation juju does (for improv) there is quite a bit to check on any mutation
<bcsaller> hatch: I need to finish the ones I'm doing but I'm open to pairing on it later if you want that 
<hatch> well last night I was dabbling in some C# so I'm glad to be back in javascript...:)
<hatch> c# has 4 different 'length' methods depending what type of array you have....cuz that makes sense
<hatch> :P
<hatch> although the most irritating is the fact that methods AND classes have an uppercase first letter so you have no idea what can be instantiated by looking at the name
<benji> bac: I have fixed the errors you pointed out and re-proposed the branch. (https://codereview.appspot.com/8366043)
<frankban> guihelp: the javascript console (trunk) shows this error when double clicking a service: http://pastebin.ubuntu.com/5677068/
<hatch> that looks like an error caused by bac's changes
<bcsaller> indeed
<hatch> bac are you still around?
<teknico> oh dear gjslint, why do you explode rather than telling what it is that you actually don't like?
<hatch> frankban: maybe create a ticket and assign to bac so he can fix when he returns?
<teknico> it's not good for your health, you know
<frankban> hatch: will do
<hatch> jujugui guichat in 2
<Makyo> bcsaller, rick_h_, luca____  ping
<teknico> https://codereview.appspot.com/8345046
<hatch> teknico: I'll take one
<teknico> hatch, thanks!
<hatch> done
<teknico> hatch, thanks! (remember to tag yourself on the card, actually *before* you make a review :-) )
<teknico> speaking of which: benji, did you say you already got two reviews for your branch? I see no tags on its card
<hatch> tagged
<teknico> (playing card tag police here :-) )
<teknico> hatch, thanks again :-)
<benji> teknico: only one of the reviewers is on the gui team, the juju-core guys don't use that technique.
<benji> my self-imposed rule is that only reviews for projects completely "inside" the gui team use tags to claim reviews
<teknico> benji, but bac said that we can be authoritative reviewers on juju-core too, so why not?
<teknico> I mean, we could add tags for reviews from the juju-core team in their place
<benji> if we can get them to participate, then it would be great; partial participation seems worse than non-participation though
<benji> we could do that
<teknico> Makyo, thank you too (I added your tag :-) ), landing!
<Makyo> teknico, good catch, thanks
<hatch> that moment when you realize you just deleted the wrong folder...
<teknico> yeah, that one :-)
<hatch> in python `for pair in endpoint_pairs[1:]:`  what does the : inside the [] mean?
<benji> hatch: that : makes it a slice, so [1, 2, 3, 4][1:] == [2, 3, 4]
<bac> oy
<hatch> ahh ok
<hatch> thanks
<benji> the first index goes before and a second index goes after, if the first is left off it means 0, if the last is left off it means -1 (last)
<hatch> bac: https://bugs.launchpad.net/juju-gui/+bug/1164589
<_mup_> Bug #1164589: addServiceToEndpointsMap error <juju-gui:Triaged> < https://launchpad.net/bugs/1164589 >
 * bac looking
<hatch> bac: just updated with a new comment on that ticket
<hatch> bac: that error is actually blocking me so I can help if needed
<bac> hatch: first one was easy.  looking into the other
<hatch> oh ok excellent - be sure to now write a test to cover that error :)
<bac> hatch: yes dear
<hatch> lol
<bac> hatch: after the fix for the first i cannot replicate the add relation issue
<hatch> egggggggcelent
<hatch> is there a special procedure for staff purchases from shop.canonical.com?
<BradCrittenden> hatch: re: purchases - no.  if they are still doing the discount code, you should've gotten it when joining.
<bac> hatch: proposing fix now
<hatch> kewl
<hatch> thanks
<hatch> hehe fix-goof
<hatch> bac: a 4 character fix? hehe
<BradCrittenden> i think it is eight.  i had to delete 'null' before adding 'this'
<hatch> oh lol - charmStore needs to be destroyed no?
<hatch> in your test
<hatch> no codereview url has come by so that's why I mentioned in here :)
<bac> https://codereview.appspot.com/8364044
<bac> hatch: could you qa this branch to see if you can cause the add relation failure?
<hatch> yep checking it out now
<rick_h_> jcsackett: hatch if you guys get a few min please? https://codereview.appspot.com/8356044 it's a step one so you can qa it that it works, but it's fugly and only works via direct url calls (can't click into the view)
<bac> benji, rick_h_ : could one of you do a quick review on https://codereview.appspot.com/8364044
<rick_h_> bac: sure thing, loading up
<bac> thx
<hatch> bac, QA'd and OK
<benji> missed it
<bac> thanks hatch
<hatch> rick_h_: I still don't see a position absolute in this branch :P
<rick_h_> hatch: nope :)
<rick_h_> hatch: honestly, last thing we'll do. This way we know any bugs are our own and not interactions
<rick_h_> well, maybe not last...
<benji> bac: if you get a second, I could use a +1 on the review from earlier
<bac> benji: done
<rick_h_> bac done
<hatch> rick_h_: so no more issues with the routing code?
<bac> thanks rick_h_
<rick_h_> hatch: :/ only issue is the double/triple call which I'm ignoring for now
<rick_h_> hatch: goal is to try to get the basics setup for huw to go through and be able to apply UX love to things
<hatch> oh yeah but that was an issue long before the routing stuff
<rick_h_> hatch: ah, well I wasn't really involved before so meh
<hatch> neither was I :P
<rick_h_> hatch: I do forsee one issue I need to work through, but haven't looked awt the problem much yet
<rick_h_> I really wish I had a way to generate urls in handlebars based on something with some brains on current state
<rick_h_> because if I do the url routing in my views by catching click events I don't get dispatch
<rick_h_> but in the templates there's no reall app state to say "oh, you're in /fullscreen so all links should stay in /fullscreen land
<hatch> rick_h_: create a helper which references the generator in the router code
<hatch> I generate urls that way in the service views
<rick_h_> hatch: cool, will look there then. 
<hatch> but instead of using a helper I do it before passing it in
<rick_h_> oh cool, yea dirty thing would be for the master view to set an magic ATTR that's 'whoami' or something but it's nasty/dirty
<hatch> serviceRemoteUri: this.get('nsRouter').url({ gui: '/service/'})
<hatch> for example
<hatch> so that says, change the url for the gui namespace to /service/
<hatch> well....build me a url with the gui namespace with /service/
<rick_h_> hmm, yea the big thing will be the CharmToken widget, when clicked on, will need to open /bws/XXXX/precise/charmid to load the details
<rick_h_> in sidebar, that's this expanded sidebar version, in fullscreen, it's the fullscreen details view
<rick_h_> where sidebar/fullscreen is XXXXX
<rick_h_> so need to get something into the CharmToken Widget to be smart about generating that url/click
<hatch> yup
<rick_h_> thanks bac 
<rick_h_> bac: so in testnig it out YUIDoc doesn't care about the lack of return. The methods don't return anything and rather than add more noise with the whole mutates only mess I just leave it out. 
<rick_h_> at least make code-doc and make view-code-doc don't complain
<bac> rick_h_: that is great news and should be shouted from some mountain top or roof
 * hatch is back on track
<hatch> thanks for the patch bac
<hatch> bcsaller: have a second to explain to me how relationships work from the higher level? I see the code but I'm wondering how they function inside each charm....or if this is documented somewhere I could read that instead :)
<bcsaller> hatch, one min
<hatch> sure
<bcsaller> hatch: in hangout
<bac> statik signed on at Mar 10, 2013 20:37:57 and has been idle for 594hr 59min 51s
<bac> i guess i'll try email
<hatch> lol
<hatch> bcsaller: so that I am sure I get this right
<hatch> relationships are valid if
<hatch> they are the same type...
<hatch> one is client, one is server
<hatch> both are 'peer'
<hatch> I'm not sure how peer to peer differs from 'both same type' but they are checked for separately
<bcsaller> hatch: at a high level yes, there is also a notion of subordinate scoped relations which have the same basic rules but generally use an implicitly provided relation, 'juju-info'
<bcsaller> hatch: with client-server, one is client, the other is server (roles) and they have the same interface type
<bcsaller> hatch: with peer they are peers, they all have the same role
<hatch> ahh ok
<bcsaller> hatch: the special behavior around peer relations is that they are automatically joined on deploy
<bcsaller> hatch: there is no explicit step needed because they are 'related to self'
<bcsaller> hatch: you can see that at the bottom of juju/control/deploy.py
<bcsaller> (which I don't know if we implement in our version)
<hatch> doesn't look like it
<bcsaller> nope
<bac> hatch: did you do anything to fix jenkins or was it not a real failure?
 * bac trying to get all set up with vpn, etc
<hatch> there was a lot of work done to do all this in python to throw it all away and redo in go...
<rick_h_> bac: I think my land came alnog after yours and forced a re-run?
<hatch> bac: I just left it, I'll do it towards the EOD
<rick_h_> bac: but guessing as I thuoght the failure on yours was mine
<hatch> rick_h_: no it complets and then does it again, it doesn't stop
<rick_h_> see, what do I know about how it's setup? nadda :)
<bac> hatch: so we assume the failure was spurious/canonistack
<bcsaller> hatch: we really need to fix our use-cases for this thing, we don't want to build all the juju behavior in JS I think, just get the env running
<hatch> bac: I'm going to yes - there is no reason any of our changes have caused that failure
<bcsaller> but it still takes alot to get just as far as we need
<hatch> bcsaller: yeah - how I understood it is that we want it to 'look' like it's working as expected
<hatch> so I'm sure we can forego some of the more complex checks
<hatch> but I am pretty sure we want to check to make sure the relation stuff works properly
<bcsaller> hatch: yeah, its one of the main things we draw
<hatch> bcsaller: mind taking a look in topology/relation.js and let me know if I am seeing this wrong...It looks like we only support server and client connections in the GUI? 625-631 and 659-665
<bcsaller> hatch: peer relations are not ambiguous which is what that method is checking
<bcsaller> hatch: we dont' draw peer relations though as they would look like an arrow pointing back to self or a ring or something.
<hatch> well sure but that's the only method which actually calls add_relation
<hatch> so right now the gui doesn't actually check the charm to see if it's a server or client
<hatch> it just says "you're a client, and you're a server"
<bac> hatch: i'm trying to setup my vpn to the qa lab.  you know the drill, right?
<hatch> bac: umm mine was a little different because I'm using 12.10
<hatch> so I coudln't follow the guide
<bac> hatch: that's what i'm using
<hatch> oh ok, lemme boot up my laptop
<bac> hatch: well, real, quick, once you have network-manager set up, how do you get it to open the vpn connection?
<hatch> click the network symbol in the top right
<bac> if i double-click on it, then it just opens the edit configuration dialog
<bac> top right of what?
<hatch> nope single click on the thing that looks like a cell phone signal strength (with my icon set) then go down to 'VPN Connections'
<hatch> in the very top right of the screen
<bac> ok, i was trying w/in the nm
<hatch> then that will open up another menu that has whatever you called the vpn connection
<hatch> do you see it?
<hatch> honestly my configuration is so messed up I don't think I'll ever be able to upgrade to 13.04 without something exploding :D
<hatch> this was also installed with wubi 3 years ago and without wubi in 13.04 I'm not sure I'll actually be able to upgrade anyways
<bac> hatch: cool, i'm in
<hatch> right on
<hatch> plz don't delete our jenkins configuration :)
<hatch> LG Optimus G at my cell provider is $0 on a 3 year contract....or $499 on a two year...lol
<hatch> bcsaller: I need the mysql equiv to test/data/wordpress-charmdata.json any idea how I would generate that?
<bcsaller> hatch: http://jujucharms.com/charms/precise/mysql has everything
<bcsaller> hatch: under the repo link you can find the interfaces in metadata.yaml (same as for any charm) but they are also spelled out on the website
<hatch> ok so that json file was manually created?
<hatch> must be, I can't find any file which has all of this information in it
<rick_h_> hatch: what file are you looking for?
<hatch> well I need to deploy mysql along side wordpress in the in memory environment tests
<hatch> so I am guessing I need the mysql version of test/data/wordpress-charmdata.json
<rick_h_> k, let me look what api endpoint that is on charmworld
<rick_h_> hatch: http://jujucharms.com/charms/precise/mysql/json
<hatch> oh lol it was that easy eh
<hatch> :)
<rick_h_> hatch: and that's called from the model.load() using the 'charmstore' store
<hatch> kewl
<hatch> pro...gress
<hatch> bcsaller: reviewing
<bcsaller> hatch: thanks :)
<hatch> review done
#juju-gui 2013-04-05
<Makyo> Fiiiiinally unbrincked the tablet.
<Makyo> er.. unbricked
<rick_h_> Makyo: yay
<Makyo> Of course, now it's running Android, so...lets hope the next flash doesn't do the same :o)
<Makyo> I gained a nose, apparently.
<rick_h_> any time you see a UI it's a good thing
<Makyo> Yeah, seriously.  Anything but just plain black D:
<rick_h_> sometimes having to go through POST and Grub is comforting stuff :)
<Makyo> Yeah.
<Makyo> The Dell Optiplex series was good for that, because if it didn't even make it to beep codes, it couldn't turn the fan speed down, so the thing would just rev the fan to top speed until the thing sounded like it would fly away.
<Makyo> Good because none of them were mine, I guess.
<Makyo> Enough computer.  Until tomorrow o/
<rick_h_> party on
<frankban> hi rogpeppe: am I right assuming that the relation id is created in this way? -> "[requirer service name]:[requirer Relation.Name] [provider service name]:[provider Relation.Name]"
<rogpeppe> frankban: that sounds right, yes.
<rogpeppe> frankban: check out the relationKey function in state/relation.go for the definitive answer. the ordering is defined in epSlice.Less in endpoint.go
<frankban> rogpeppe: cool, thanks. IC, roleOrder  ah! any idea about reintroducing the status in the unitInfo?
<rogpeppe> frankban: it's happening, although delayed because i've been trying to diagnose a runtime bug.
<frankban> rogpeppe: great, thanks
<frankban> rogpeppe: anyway, nice change re relation key, much better than "relation-000000X".
<BradCrittenden> guihelp: does anyone understand this card "Expose service config information via Go API"
<bac> it looks surprisingly like 'juju get svc' but that command is already in the Go API
<bac> and there is no corresponding bug
<teknico> bac, the card description seems very clear
<teknico> bac, totally white, actually ;-)
<bac> teknico: you're very helpful, as usual.  :)
<teknico> ain't I? ;-)
<bac> benji: i see you created that card.  got any extra info?
<benji> bac: I haven't looked at it much yet.  It either needs to be an RPC call or a  new watcher
<benji> I've been up sick all night so I'm afraid I'm not going to be around today.
<bac> benji: but how does it differ from 'get'?
<bac> benji: oh, ok.  sorry you aren't well
<frankban> bac: could you please take a look at https://codereview.appspot.com/8406044 ?
<rick_h_> anyone up for a looking over a bunch of html/css :) https://codereview.appspot.com/8412043/
<bac> frankban: sure
<frankban> bac: thanks
<bac> benji: if you aren't going to be around today do you want to hand off the GUI card you've got?  i'd be glad to run with it
<hatch> morning
<bac> frankban: i'm looking but this code is unfamiliar so i'm going slow
<bac> hi hatch
 * hatch is frustrated with this code
<frankban> bac: yes, that's a new module, we can make a call if you want to.
<bac> thanks but not yet needed
<bac> frankban: why did instance_state go away?  is that unrelated to this branch?
<frankban> bac: because, AFAIK, it is unused, it is not included either by the pydelta or juju-core delta, and it generates confusion. I discussed this with Benji and we decided to just get rid of that attribute
<bac> frankban: ok, cool.
<bac> frankban: reviewed
<frankban> bac: great, thanks
<Makyo> jujugui call in 2
<bcsaller> after the call a review of https://codereview.appspot.com/8358045/ will clear 4 cards
<Makyo> rick_h_, jovan2 luca__  call in guichat
<hatch> rick_h_: I think at one point yuidoc required the leading *
<hatch> that's why most of their code has that
<rick_h_> hatch: yea, and those files i linked the one without the * ends with **/
<rick_h_> hatch: I just went to look at their code saying if we're going to convention-ize and do what YUI does (camel var) might as well check and noticed they don't agree eitehr
<hatch> I used to do the * preceeding but got lazy and thats when I stopped :D
<hatch> lol
<rick_h_> editor does it for me, I'm lazy
<rick_h_> just trained my dog well :)
<hatch> haha - right now switching between osx/ubuntu multiple times in the day is killing my finger memory
<hatch> unfortunately I have to pay to get my garage roof redone so no new laptop for me
<hatch> :/
<Makyo> Booo
<hatch> yeah it's $3500 and I worked it out to be about $2000 in materials
<hatch> it'll take 3 pro's 2 full days to do all the work so I figured it would take me 2 full weeks
<hatch> lol
<hatch> home ownership....pffffft
<Makyo> Haha, yeah
<Makyo> Prefer blog post or email for the meeting summary?
<hatch> email
<hatch> bcsaller: the relation response object includes a relation id, interface, and scope - any idea how these are defined?
<bcsaller> hatch: let me see if I can find you a good reference 
<hatch> thanks
<hatch> I notice the relation model has them
<bcsaller> hatch: https://juju.ubuntu.com/docs/charm.html is a good place to start (relation section), the relation ident was added later and just exposes a unique id for the relation 
<hatch> alright thanks
<bcsaller> hatch: if you need more info let me know
<hatch> bcsaller: is there any objection to me storing the charm data in the service model?
<hatch> to build out the relation response I need the information under 'requires' in the charm
<bcsaller> hatch: we have the charm for the metadata and the relation object holds the endpoints
<bcsaller> you don't need to change the models as they already satisfy the use case with real jujus
<hatch> got a sec for a guichat?
<bcsaller> I think what we'll need are a few helper methods in fakebackend to assemble this and make the checks
<bcsaller> I do
<frankban> bye all, have a nice weekend!
<hatch> cya frankban
<hatch> you too
<hatch> bcsaller: in this charm json data I don't see anything specifying weather it is a slave client or peet
<hatch> per
<hatch> peer
<hatch> any idea how that is determined?
<bcsaller> hatch: http://jujucharms.com/charms/precise/mysql/json look at provides and requires, those are translated to server and client respectively 
<hatch> ahh that's what I was thinking but wasn't sure
<hatch> thx
<bcsaller> http://jujucharms.com/charms/precise/wordpress/json is a better example
<bcsaller> peer is a much less common relationship type
<hatch> ahh ok, so a charm can't provide and require?
<hatch> or it can
<hatch> nm
<hatch> I spoke too soon :)
<hatch> do we have an accepted style to pre-hoist fn's in javascript or can we leave them close to where they are used?
<hatch> ^ jujugui
<bcsaller> If I understandd what you mean I leave them close till something else needs them, then into a util module
<hatch> sounds like a plan
<hatch> bcsaller: ok one more :) relation_id is this some arbitrary id for the relation?
<bcsaller> hatch: yes, its a unique id
<hatch> (Y)
<bcsaller> hooks sometimes need to be able to know specifically what they are interacting with 
<bcsaller> we can just use a monotonically increasing number
<hatch> this.db.relations.size() + 1
<hatch> ok?
<hatch> axe that I'll make it 0 indexed
<hatch> this.db.relations.size()
<hatch> :)
<bcsaller> hatch: not size, things could be removed and the number could be reused
<hatch> oh right
<bcsaller> not that it would break anything with fakebackend, but still :)
<hatch> this relation code started out being so simple....then you informed me of all the work it actually has to do :P
<Makyo> ignorance === bliss
<bac> guihelp: frankban file bug 1164593 saying that double clicking on a service just brought up a "loading" message and nothing more.  i cannot reproduce.  has anyone else seen this behavior?
<_mup_> Bug #1164593: GUI hangs on the service detail view <juju-gui:In Progress by bac> < https://launchpad.net/bugs/1164593 >
<hatch> bac: I wasn't able to reproduce that either
<hatch> sorry I forgot to mention on the ticket
<bac> hatch: ok, i'll make a note and use your name in vain
<bcsaller> bac: I suspect you already fixed it with the endpoint map fix, I think it was dying in process before 
<bac> bcsaller: ah, more good ammo
<bac> invalidized
<hatch> bcsaller: got a few minutes to take a peek at https://code.launchpad.net/~hatch/juju-gui/add-relation and let me know if I'm missing anything for the typical client/server relationship
<bcsaller> hatch: taking a peek, then lunch
<hatch> thanks
<hatch> then I'll need you to fill me in this subordinate stuff
<hatch> after lunch is fine :)
<hatch> I also could use some lunch
<bcsaller> hatch: 531 needs a ===, 536, strange way to us if/else 571, relation_id is usually something like "rel:"+ct or similar, have to check that one, then you need to push the relation object into the fakebackend change list or it won't appear in the delta
<bcsaller> mini-review
<hatch> thanks!
<bcsaller> also, check for authenticated at start of method
 * bcsaller heads to lunch
<hatch> bcsaller: 531: done, 536: that was copied from the endpoint.py, 571: relation- is the prefix used right now
<hatch> now I'm lunching :)
<hatch> bcsaller: you're just saying `this.changes.relations.push(relation);` there is no extra stuff that might not be as obvious that is required to add to the list?
<bcsaller> hatch: its a map, not an array and it take an additional argument of true to indicate its a update/add
<hatch> ok is this documented anywhere?
<bcsaller> hatch: another question is do you need to push the two services into their change set as well. 
<hatch> I don't know - I didn't even know about this change list until you said it
<hatch> so I haven't done it for any of the other stuff I've done
<bcsaller> hatch: this is all new code, but _resetChanges, nextChanges implement it. addUnit shows an example 
<bcsaller> pretty much self contained 
<hatch> oh ok so we don't actually use this delta stuff yet
<hatch> alright it's been added this.changes.relations[relationId] = [relation, true];
<bcsaller> hatch: we do, sandbox.sendDelta consumes this
<hatch> ahh ok - and what is this used for on the client?
<hatch> or are these the ws updates?
<bcsaller> this is as though improv were recoding changes in a list to send a batch to the client.
<hatch> gotcha
<bcsaller> so yes, this whole thing is talking over the ws channel and that part arranges the delta updates
<hatch> you know you have a serious syntax error when the linter crashes
<hatch> :D
<hatch> oh poo
<hatch> crud I did this all wrong
<hatch> :/
<hatch> ok not 'all' wrong, just have to shift some stuff around
<hatch> bcsaller: are you still kickin around?
<bcsaller> hatch: yeah, plenty of time left
<hatch> oh right...ok
<hatch> so I kind of screwed up and was passing too much information to the fakebackend
<hatch> in reality all that's passed back is "wordpress:db" and "mysql:db"
<bcsaller> ahh, that makes sense, then it does the resolution from the metadata
<hatch> so from there I can pull the charm - I can then parse the charms to see which is the client and which is the server
<hatch> my question is....can a charm be both a client and a server to eachother
<hatch> so could they both be in eachothers provides and requires
<bcsaller> hatch: yes, it could... rare though, don't think about it in terms of the charm though, only endpoint matches
<bcsaller> if the endpoints match then its allowed
<hatch> ok so as long as they are both 'db' or whatever then it's ok?
<bcsaller> as long as they implement the other side of the expected endpoint
<hatch> so then I would parse wordpress and mysql to find out which one has a requires db and that is the client
<hatch> is that a logical approach?
<bcsaller> client and server are just useful names in this context but meaningless for the most part
<hatch> oh ok so I can ditch that assignment entirely then
<hatch> niiiice
<hatch> just check to make sure one has the other in it's requires
<hatch> under the endpoint....in this case 'db'
<bcsaller> sounds correct
<hatch> I hope so, I hate redoing stuff
<hatch> pet peeve hah
<hatch> and should I include some type of validation to make sure the two endpoints are teh same?
<hatch> or can I rely on the client side to do that for me?
<hatch> ahh wahtever it's an extra line
<hatch> might as well
<hatch> well I guess 3 bcuz 80char limit :D
<bcsaller> hatch: as an aside I changed addUnit to be zero based like juju and updated the tests.
 * hatch shakes fist.....why I auta
<hatch> alright cool
<hatch> :D
<hatch> there complete refactoring and the tests pass
<hatch> yay for tests
<hatch> hmm
<hatch> bcsaller: mind taking a look at this https://code.launchpad.net/~hatch/juju-gui/add-relation When doing the integration tests the add_relation in python.js pre-formats the response which makes me have to check for that in the PyJujuApi - which feels wrong but I don't see any way around it
<bcsaller> hatch: checking
<hatch> thanks
<bcsaller> hatch: you allow endpointToName to be a string but your handling on 459 would break if thats true (and I'm reading it properly)
<bcsaller> the formatting you do makes sense though
#juju-gui 2013-04-06
<hatch> sorry it was kind of a lot of rewrite
<hatch> and lacking inline docmentation
<hatch> this is correct
<hatch> good catch
<hatch> :)
<hatch> so in your oppinion am I doing this right? Nothing else I've done has the python.js augmenting the data
<hatch> so it kind of breaks the flow
<hatch> ok glad you think so
<hatch> because I was unsure it was the right approach
#juju-gui 2013-04-07
<rick_h_> hatch: aha, found a left over timer in a test still. Doh! 
<rick_h_> hatch: https://codereview.appspot.com/8488043 has the drive-by if it helps the tests at all. 
#juju-gui 2014-03-31
 * frankban lunches
<bac> hi rick_h_
<rick_h_> morning bac 
<rick_h_> good time while away?
<bac> rick_h_: hey what is the card re: comingsoon about?  you just want me to add ssh keys for more people?
<rick_h_> bac: yea, there's a css issue atm and no one could fix it
<bac> ouch
<rick_h_> bac: so I was going to ask for hte details on where it's at and do we need to move it or get access for more folks
<bac> rick_h_: just a matter of adding more ssh keys from lp
<rick_h_> I never really followed where that server is at
<bac> rick_h_: you just ssh to comingsoon.jujucharms.com
<bac> rick_h_: so tell me who...
<rick_h_> bac: ok cool, yea me please, hatch and makyo. 
<rick_h_> bac: maybe add a doc section in https://wiki.canonical.com/CDO/Juju/GUI/CI please
<bac> cool google doodle alert
<rick_h_> no doodle here :(
<rick_h_> bac: can you ping when you have time for a quick call please?
<bac> rick_h_: now is good
<rick_h_> bac https://plus.google.com/hangouts/_/7ecpjkem9ldms8f9qpbj5pois8?authuser=1&hl=en
<bac> rick_h_: huw's changes are in the branch on comingsoon.  no conflicts are shown.  i've cleaned and rebuilt.  still busted.
<rick_h_> bac: working here
<rick_h_> bac: thanks for the update, stale cache maybe on your end?
<bac> oh.  cache problem for me
<bac> very good then
<frankban> welcome back bac 
<bac> thanks frankban
<jcastro> hey rick_h_ or frankban
<jcastro> which version of quickstart would be missing MAAS support?
<jcastro> sabdfl tried it on his garage maas and could not find an option for maas
<frankban> jcastro: could you please file a bug? we can try to add maas to the next release. is --upload-tools still required when using maas?
<jcastro> ok
<hatch> jujugui juju-core 1.17.6 deploys the 1.17.7 tools and will throw an error about instance-id. If you get this error update your juju client (I ran into this on the weekend)
<jcastro> frankban, aha! He's on vanilla trusty with 1.1 instead of 1.3, which is in the PPA
<jcastro> anyone have the status for -quickstart in main? Are we still shooting for that?
<rick_h_> jcastro: it's shot down for 14.04
<rick_h_> jcastro: it'll be in universe
<jcastro> ack, I assume that will get bumped to 1.13 though? 
<frankban> jcastro: quickstart in main is blocked by core in main. 1.3 yeah, same question here, is quickstart universe auto-updating?
<jcastro> it's past freeze now right? I believe we need to have it manually synced
<jcastro> we should check
<rick_h_> right, they have to upload still I believe
<rick_h_> because they update from the pypi
<frankban> jcastro: FWIW 1.3 does not include maas support, we still need to implement that, it wasn't planned
<rick_h_> that's the official 'release' that packaging is built off of
<jcastro> so my quickstart has an entry for maas
<rick_h_> jcastro: did you have that in your environments.yaml?
<jcastro> I mean, it has the fields and stuff, do those not work?
<rick_h_> jcastro: I don't think it's a provider we suport 
<jcastro> huh, well, I see it in there, and I certainly didn't add it
<rick_h_> jcastro: in the 'create a new environment' or from your existing environment list?
<frankban> jcastro: quickstart works like the following: if you have an environment in your envs.yaml file, which quickstart does not recognize/support, quickstart will still let you use that and even edit the fields it found, but do not expect validation/creation.
<jcastro> it's in my environments.yaml, but I didn't create it, anyway, that's not as important right now as to what I should tell Mark about MAAS/quickstart, heh
<rick_h_> maas/quickstart doesn't work and wasn't planned. It was deemed a quick 'juju helper' and maas didn't come into the conversation
<rick_h_> so it's all news to us now that you ask abou it. We didn't consider how it would work. Does the deployer/bundles work on maas/
<rick_h_> ?
<rick_h_> we'd have a lot of questions to ask/figure out to see how quickstart work work in that world
<jcastro> I don't know if deployer/bundles work on MAAS
<jcastro> I am not supposed to care about my provider remember? :)
<rick_h_> jcastro: right, that's from an internal point of view. I'll have to ask/figure out that to see what a quckstart tool looks like in a maas world
<jcastro> yeah
<jcastro> so I am wondering if we ask you to do X steps for MAAS does quickstart really make a difference?
<jcastro> "I know how to set up DNS and DHCP, but adding a value to a yaml file? Now you ask too much!"
<rick_h_> jcastro: yea, that's my thing. If we can't do bundles to maas I'm not sure what all we'll be doing for them
<jcastro> IMO we should be doing bundles in MAAS
<rick_h_> I'm in calls but will try to find some answers. If we can make it near close feature-wise we can schedule some work on quickstart
<jcastro> provider-specific limitations totally ruin Juju's promise
<jcastro> rick_h_, yeah I don't think it's big enough to stop what you're doing, I'm just thinking we should have an idea of discussion for vegas
<rick_h_> jcastro: +1
<jcastro> like, I think it missing from quickstart isn't a big deal, these people are doing bare metal installs, and a little yaml file is no big deal
<jcastro> but non-working bundles would be big I think
<rick_h_> right, but I agree bundles on maas should be something we look into
<jcastro> rick_h_, do we know it doesn't work or do you speculate it doesn't work because we never tried it?
<rick_h_> jcastro: never tried it so just not sure
<jcastro> so probably doesn't work
<rick_h_> I'm trying to find some report of people doing that
<jcastro> let me ask
 * rick_h_ hasn't used maas but an excuse to pick up some hardware is always welcome
 * hatch is reviewing huws branch
<hatch> jcsackett did you get a chance to try the new http interface on the ghost charm?
<hatch__> I found a charm this weekend which has multiple maintainers in the maintainer field https://bazaar.launchpad.net/~charmers/charms/precise/haproxy/trunk/view/head:/metadata.yaml 
<hatch__> re our charmworld discussion about multiple maintainers
<hatch__> atm it only shows the first one
<rick_h_> hatch__: right, so we've got a card to move to a maintainers field and the charm should be updated to use it
<bac> rick_h_: just filed expenses for AWS for last four months
<rick_h_> bac: k, thanks
<bac> rick_h_: fwiw, on canonicaladmin "Sign off by" still shows gary
<rick_h_> bac: hmm, will look. I thought I was setup for everything
<bac> oops maybe that was an historic one
<rick_h_> if I could log in I'd tell you if I can see it or not
<kadams54> rick_h_: been diving into charmworld this morning, but I don't have any cards to work on right now. Was wondering if you had any suggestionsâ¦
<kadams54> If not, then this looked like something I could tackle: https://launchpad.net/bugs/1290323
<rick_h_> kadams54: hop on the stand up a couple min early and we can run through
<kadams54> k
<rick_h_> jujugui call in 7 kanban please
<hatch> Makyo did you see they released a vim plugin for Go?
<Makyo> hatch, not yet, though I'm intrigued.  I don't mind Sublime for Go, but it takes a bit to switch editor modes
<hatch> yeah that's my thoughts - right now I switch from sublime > tmux > osx > ubuntu
<hatch> I end up hitting about 5 shortcuts before I find the right one
<hatch> lol
<kadams54> This came up on Friday: here's what I currently use for window management/position in OS X: https://github.com/fikovnik/ShiftIt
<Makyo> hatch, have a link? I already have go.vim
<kadams54> Pretty basic, not as powerful as Amethyst, but does the stuff I want.
<hatch> Makyo umm one sec
<hatch> http://blog.gopheracademy.com/vimgo-development-environment
<hatch> kadams54 yeah I've been trying moom because I want custom (saved) layouts
<hatch> layouts are a big requirement for me
<rick_h_> Makyo: got a sec to chat?
<Makyo> rick_h_, sure
<hatch> rick_h_ I'm going to bench this delta card and work on it as slack so we can keep pushing forward....anything you'd like me on next?
<rick_h_> hatch: state :)
<hatch> lol
<rick_h_> hatch: drink your coffee today?
<hatch> I just might implement the API I want then :P
<hatch> haha drinking tea now
<rick_h_> that'll do
<rick_h_> yea, I mean we need someone to pick up state work and it's blocking a lot of things right now. 
<rick_h_> hatch: if you don't want to do that we can find something else
<hatch> no no it's fine
<hatch> :)
<rick_h_> pow wow time then?
 * hatch puts his politically correct hat on
<hatch> lol
<hatch> yeah I'm ready whenever
<rick_h_> kadams54: ^ 
<hatch> link?
<rick_h_> ok, will get a link
<rick_h_> https://plus.google.com/hangouts/_/72cpigoqi36bc4apugurhfskv8?hl=en
<rick_h_> kadams54: feel free to join in the fun ^ as well
 * hatch changes state object name to KylesState
<rick_h_> let's just get it all the way there KylesFault :P
<hatch> rofl
<hatch> that would be epic
<rick_h_> welcome to the club, it can go next to the class RicksFault, JeffFault, and MattAlwaysWins
<hatch> hahaha
<hatch> oh man that would make for a funny codebase
 * rick_h_ goes for lunchables
<hatch> Makyo there are a bunch of warnings now "Dropping unused function..." from the d3 stuff
<hatch> anything to be worried about?
<Makyo> hatch, no, just some poorly managed dependency tree stuff on D3s side.  That's just uglify getting rid of stuff that is never used.
<hatch> ahh ok cool
<Makyo> Gotta give uglify credit for being pretty thorough.
<hatch> yup
<hatch> little scary if those methods were called by this[callthismethod]
<hatch> heh
<hatch> rick_h_ I have a question about the ghost inspector and viewNavigate/state lemme know when you're back
<kadams54> Forgot to mention this in standup, but I'm going to be out in an hour for an appointment. Will be back in the saddle around 3 PM Eastern.
<rick_h_> hatch: k, back
<kadams54> Also: KylesFault: less scary than SupportedNowAndAlwaysByKyle
<kadams54> I've got no problem with it being my fault as long as someone else has to support it ;-)
<rick_h_> oooh, I like that one
<hatch> https://plus.google.com/hangouts/_/7acpiciu7u09dga8ifaaamclss?hl=en
<rick_h_> FindKyleAt12480004444
<hatch> lol
<Makyo> jujugui anyone running in OSX with vagrant?  Having trouble getting the tests to pass natively with that, though the pass in CI and on other systems.
<bac> Makyo: i am
<hatch> Makyo running fine here
<Makyo> hatch, rick_h_ PR updated, btw.
<bac> Makyo: but i haven't tried the tests ina while
<Makyo> Hmm, okay.  I'm on the old vagrant, will update.
<kadams54> I have 2-3 tests that fail on a semi-regular basis
<rick_h_> Makyo: cool thanks looking
<hatch> kadams54 can you make note of them - they may be because of a cascading state issue (we used to have a lot of those)
<hatch> Makyo oh yeah I'm on the new one, sorry try updating 
<Makyo> Working on it.  NFS is unhappy
<hatch> :( I love the nfs it's so fast
<Makyo> Oh, nevermind.  /etc/exports was messed up
<Makyo> Had some stuff in there left over from old vbox setup
<Makyo> Conflicting mount points
<hatch> ohh that'll do
<bac> hatch, so the vagrant/nfs has continued to work well?
<hatch> bac yep works like a charm, so fast
<hatch> it's virtually instant to load up the site now when running locally 
<hatch> it used to take a few seconds before
<hatch> total time to run the tests has also dramatically sped up
<bac> yay, i'm reading my email backwards and just got to the part where allhands has been bludgeoned to death.  whee.
<hatch> haha yeah I cheered for that too
<hatch> rick_h_ can the filter stuff at the top of getUrl in state.js go?
<rick_h_> hatch: not until we fix the url to not need to worry about 'search' in the url
<hatch> we don't -do- filters any longer I don't think
<hatch> ohh ok
<rick_h_> hatch: oh, but we do use filters in state. the search term, etc
<rick_h_> hatch: clear and such for updating. and supposedly we'll get to 'tag' like search where you can enter 'precise' and we'll have to detect it as a filter of series
<rick_h_> hatch: but yea, not used to the full extent right now
<hatch> 14 mooms remaining :0
<rick_h_> mooms?
<hatch> I thought you were trying moom
<hatch> every time  you use it it counts down from 100
<rick_h_> yea, not sure what '14 more' fit into
<rick_h_> huh? missed that
<hatch> oh you've bought it already>
<rick_h_> is that a trial one or something?
<rick_h_> oh yea, I just bought it
<hatch> oh lol ok
 * hatch is cheap
<hatch> lol
<rick_h_> didn't realize it had a trial, just found it in the store
<hatch> ohh yeah I went to their website
<hatch> you should go register on their site - there are some limitations to the store version
<Makyo> hatch, mind giving the PR a +/-?
<hatch> oops sorry checking
<hatch> Makyo done - I thought it had already landed :)
<Makyo> hatch, sorry, just wanted to make sure!
<rick_h_> jujugui going afk for a little bit before the interview. 
<rick_h_> hatch__: ping, hop into the call
<rick_h_> Makyo: can you come back for a min?
<Makyo> Ack, sorry
<hatch> Makyo lol that system 76
<Makyo> I KNOW
<Makyo> Ugh
<rick_h_> MOAR FANS!
<hatch> rofl
<Makyo> Need to get a separate mic for it. I think th emic is on top of one of the fans.
<Makyo> Stupid.
<rick_h_> lol
<Makyo> Oh well.
<Makyo> Looking at Thinkpads to replace it.
<rick_h_> ugh sorry
<Makyo> It makes an okay "desktop", but the Air is a little less than ideal for sprint work, since it's not linux on metal.  Makes Go work tough.
<rick_h_> kadams ran away? 
<rick_h_> Makyo: hatch looks like his branch is up for review, if either of you get time to check it out before EOD appreciate it. 
<Makyo> on it
<rick_h_> Makyo: yea, I've got $$ in my pocket but nothing I'm happy to spend $$ on. 
<Makyo> Or, well, let me walk dogs first.  Will be free after.
<Makyo> rick_h_, yeah.  You still pro thinkpad?
<rick_h_> The air is a nice form factor, but no metal and crappy keyboard :(
<rick_h_> I love my 230, but want a more air form factor, better display, HD
<rick_h_> the 240 does that but changes the buttons to a 'click pad' which reviews say is awful
<hatch> Makyo I write go in OSX
<rick_h_> Makyo: so I'm thinkpad cranky atm. They botched the carbon, messed up the 240 trackpoint
<hatch> I haven't found a time when it doesn't work in OSX but does in Ubuntu
<hatch> oh boy did they ever botch the carbon
<Makyo> hatch, oh, cool.  Was curious about the juju project.
<hatch> wth did they do to that keyboard lol
<rick_h_> Makyo: honestly I was looking at the xps13, some people seem to like it, but a friend I trust hated it
<rick_h_> Makyo: so I'm hoping refresh season might hit middle of the year and something good comes out of it
<hatch> Makyo juju probably won't work as it relies on Ubuntu specific dependencies
<Makyo> hatch, yeah, that was my concern with upcoming Gophercon
<hatch> Makyo do you have the haswell equipped air?
<Makyo> I'll get a VM up and running.
<Makyo> Um.
<hatch> I think as long as it's -not- haswell then 14.04 will run on metal
<rick_h_> Makyo: http://discourse.ubuntu.com/t/laptops-for-ubuntu-cant-make-up-my-mind/1541
<rick_h_> ok all, EOD have fun. Thanks again. 
<hatch> cya rick_h_ 
<hatch> I'm going to try fusion at some point here to try and get a good vm running
<hatch> http://macaw.co/
<huwshimi> Morning
<hatch> morning
<Makyo> Big huge +1 on NFS mount./
<hatch> haha see!
<hatch> lol
<rick_h_> bac: looks like that's a winning change. :)
<rick_h_> morning huwshimi 
<bac> rick_h_: well, it was a bit sleazy
<bac> rick_h_: you talking about ceph?
<bac> hi huwshimi!
<huwshimi> Morning all
<hatch> bac nfs
<hatch> bac how was your vacation?
<bac> ah, nfs not sleazy at all
<bac> hatch: it was fantastic!  beautiful, deserted beaches
<rick_h_> bac: oh I missed an nfs change
<bac> hatch: only downside is the dog is now mopey.  he had such a good time he's pissed to be home
<rick_h_> bac: I mean I missed a ceph change
<rick_h_> bac what was the result of that then?
<bac> rick_h_: after lots of experimenting on staging, i decided the best course was just to delete ceph-22 and ceph-20.  when ingested again they were fine.
<rick_h_> bac: ah cool thanks
<bac> i can't explain what happened
<bac> that's where the sleaze comes in
<rick_h_> bac: yea works for me. I think it fell into an exception. We'll see if we hit issues again
<bac> let's blame benji and move on
<rick_h_> hah, good call
<huwshimi> rick_h_: I see you've played some poker. Anything in particular you'd like me to move on to next?
<huwshimi> hatch: Thanks for landing that branch.
<rick_h_> huwshimi: so it's not on here, but you can get the inspector to show up (non ghost)
<rick_h_> and we need to fit it into the full size of the sidebar
<rick_h_> huwshimi: so go to comingsoon, deploy a charm, hit the close button, then click on the service block to get the normal inspector
<rick_h_> oh, we can't now that the MV panel is there heh
<rick_h_> ok, guess not that one
<rick_h_> oh try without the mv flag
<rick_h_> just il
<huwshimi> rick_h_: Yep, got it.
<rick_h_> huwshimi: ok, so the normal inspector on the left on a tall display doesn't fill the height properly
<huwshimi> rick_h_: Ah yeah, looks like another candidate for flexbox.
<rick_h_> huwshimi: so that'd be some good updates around current stuff. 
<huwshimi> rick_h_: Would save all our resize calculations too.
<rick_h_> huwshimi: and aside from that, we can keep moving forward on the machine view parts. We need the deployed unit tokens. Those I think should be widgets and done like the charm token
<rick_h_> huwshimi: cool, if it works across our supported browsers I'm all for it
<huwshimi> rick_h_: Yep, it's how the machine view stuff is working
<rick_h_> huwshimi: cool
<rick_h_> huwshimi: so the 'create a deployed service token' or the 'create machine control in unplaced units panel' would be next UI components to start on
<rick_h_> huwshimi: that help?
<huwshimi> rick_h_: Yep, that's great. Just poking around at the wireframes to see if we have details for the expanded units etc.
<huwshimi> I think there's enough there to get started.
<rick_h_> huwshimi: yea, there should be an expanded view when you place a unit token, but we can start out with just a small widget that can represent a unit. Assume it gets the data from the unit model as a raw JS object for now
<rick_h_> huwshimi: much like the charm/bundle tokens get their model, but as a raw JS object
<huwshimi> rick_h_: OK
<hatch> yay....ghost state done
<hatch> I should add "// I hate this" everywhere :P
<hatch> lol
<hatch> rick_h_ are you up for a post-implementation review?
<rick_h_> hatch: let's do it in the morning?
<hatch> sounds good
<rick_h_> hatch: and maybe not "I hate this" but "XXX this should go YY in refactor card"
<rick_h_> :)
<hatch> it's in my github fork if you get curious
<hatch> lol yeah
<rick_h_> hatch: k, just create a WIP pull request please
<rick_h_> I can comment on that but not just looking at the code
<hatch> https://github.com/juju/juju-gui/pull/214
<rick_h_> ty
<rick_h_> will try to look after the boy goes to bed
<hatch> yep no rush
<hatch> stepping away for a bit
<hatch> bbiab
<hatch> kadams54 you're back
<hatch> you kinda disappeared lol
<hatch> Makyo I made some notes in the interview doc, feel free to comment/change as you see fit
<kadams54> Comcast: "Your area is experiencing an outtage. Estimated time for repair is 8 PM Eastern."
<hatch> noice
<hatch> someone drive into the internet pole?
<hatch> :)
<kadams54> *sigh*
<hatch> the challenge of working from home sometimes :)
<hatch> My cell provider doesn't charge extra for tethering so I try to jump on that if my home network goes bonkers
#juju-gui 2014-04-01
<huwshimi> kadams54: Welcome, by the way!
<rick_h_> hatch: replied to your branch
<hatch> rick_h_ thanks, looking
<kadams54> Thanks huwshimi 
<huwshimi> kadams54: How's it all going? Settling in?
<kadams54> Makyo: thanks for looking at that PR. Didn't have a chance to post it here.
<rick_h_> hatch: so we'll need the inspector trigger point as well in there and then something for machine view right?
<kadams54> huwshimi: yup. I participated in my first architectural discussion with Jeff and Rick today.
<kadams54> Whee!
<rick_h_> he's still here yay!
<hatch> rick_h_ yep
<hatch> kadams54 lol! That one was pretty calm
<hatch> we are getting better
<hatch> :D
<hatch> haha
<rick_h_> hatch: but yea, that's the general pain in the @$#@$ idea for the first pass
<rick_h_> we don't have gary to be peacemaker any more :(
<huwshimi> kadams54: Got caught in the middle, huh.
<hatch> he just took his headphones off and walked away
<kadams54> I agree 100% with rick_h_ 
<hatch> rofl
<hatch> kiss a$$
<kadams54> Except when I agree with hatch 
<hatch> haha
<hatch> lol
<hatch> rick_h_ I spent a bunch of time spinning my wheels on this today so the full inspector and machine view should be faster
<rick_h_> hatch: cool, appreciate it. I know it's now fun :)
<rick_h_> hatch: but, we'll hopefully get out of here with the inspector and browser.js cleaned up which will be good
<rick_h_> just have to make sure we keep the rest of MV going and not get bogged down too much
<hatch> yeah definitely - it's interesting how a poor architectural choice over a year and a half ago has so many implications today
<hatch> re double dispatch and the like
<rick_h_> huwshimi: did you grab a card? If so please make sure to update kanban so we don't dupe work
<rick_h_> well, that's a big one, but I want everyone to walk away with the fact that it's more than that
<rick_h_> there were still the render race conditions/etc. 
<hatch> oh right...I think those could have been mitigated without state but state was definitely the best tool for the job for the big picture
<huwshimi> rick_h_: Oh, I didn't, I was working on the full height inspector.
<rick_h_> it was funny how Nick's presentation was all stuff I hate. Fat views, promises all the way, etc
<huwshimi> rick_h_: Is that this card: "update new inspectors UI to fit within space of the sidebar as a subordinate View"?
<hatch> haha yeah I was laughing inside about that
<rick_h_> huwshimi: ok cool, just want to make sure we don't dupe things and waste time
<hatch> I liked the dependency injection though, that was unique
<hatch> I am not sure I'd use it
<hatch> but cool none the less
<rick_h_> huwshimi: it was meant to be, but I think that card got moved over when you did the ghost inpsector
<rick_h_> huwshimi: so feel free to setup a new card or something
<rick_h_> huwshimi: just so we can tell what's up in the morning
<huwshimi> rick_h_: Yep, will do.
<rick_h_> hatch: yea, I mean it's something I'd have thought of, but we've been in the battlefield. 
<rick_h_> hatch: and that changed opinions somewhat. Testing, etc
<hatch> yeah - I think in Java land people are used to stubbing out more complex structures than we do
<hatch> although you would only need to stub out one large one and pass it around
<hatch> which might be nice
<rick_h_> well I got the impression their testing was less than thorough
<rick_h_> which helps when you can just say "this is hard to test, carry on"
<hatch> yeah he complains about that in #yui
<rick_h_> vs revisiting the design and looking at *why* it's hard to test
<hatch> I guess people would just let things through
<rick_h_> hatch: yea, it was one of his issues with current employer which is good
<hatch> hah yeah
<rick_h_> ugh this cold is kicking my @$##@$#
<hatch> heh you did sound a little out of it
<hatch> like you were talking through your nose a bit
<rick_h_> I have a hard time thinking when I'm sick. Brain slows down
<hatch> yeah, same for all
<rick_h_> so you got me at half strength today lol
<hatch> resources are being used for killing baddies
<hatch> haha, good easy pickins
<rick_h_> huwshimi: oh sorry, missed the card for it in the ready to code
<rick_h_> yes, that's the one
<rick_h_> huwshimi: blind tonight
<huwshimi> rick_h_: Oh, I just added that :)
<rick_h_> huwshimi: yea, got it reset
<huwshimi> rick_h_: Oh, you're playing with things :)
<rick_h_> huwshimi: yea, updated it right
<huwshimi> rick_h_: Thanks
<rick_h_> trying to see if i can find something feaure related for kadams54 next :)
<hatch> a grunt task for building yui modules - maybe we can use this instead of our loader (which doesn't work very well) https://gist.github.com/nhusher/9902519
<hatch> ^ written by Nick
<rick_h_> as soon as we can ditch the grunt part of it
<rick_h_> :P
<kadams54> Hah! Not sure if I want to see what sort of fun rick_h_  finds for me when his mind is a cold-medicated haze.
<rick_h_> slack task! 
<rick_h_> kadams54: hey, I've avoided medication all day
<rick_h_> that just makes me useless, so I'll just stick with miserable
<hatch> lol
 * huwshimi heads home from coffee shop
<kadams54> rick_h_: feel free to send any additional state cards my wayâ¦ I see several more out there, but not sure if I should hold off until hatch's work lands.
<rick_h_> kadams54: so would love to see you pick up either the deployed unit token or the listing of machines in to the MV panel
<rick_h_> kadams54: we can pre-imp to go over them in the morning if you're up for them
<rick_h_> kadams54: yea, I think the inspector is blocked until hatch is done, no pressure hatch
<kadams54> Sure, listing of machines sounds interesting
<kadams54> It looks like those two cards are related?
<rick_h_> kadams54: yea, should be light but get you touching the environment, db, etc. 
<rick_h_> kadams54: yea, so one column is a list of machine, the other is the containers in that machine
<rick_h_> so they're close, but slightly different bits of data so two chunks of work
<rick_h_> one is the nested data of the other
<kadams54> OK
<kadams54> Let's do it
<hatch> Do those require the architecture chat about the machine view view organization?
<rick_h_> hatch: I don't think so, it's just expanding the current View with some data from the db
<hatch> ahh ok cool
<hatch> we should maybe block out some time this week for that chat
<rick_h_> hatch: nothing about workflow, etc. 
<rick_h_> yea, but need to unblock inspector/deployer first
<rick_h_> machine view is the last thing to get done as it needs everything else
<hatch> oh yeah for sure
<rick_h_> so it might be a bit before we get full into MV arch
<rick_h_> so many moving parts at once atm wheeee
<hatch> haha yeah after this is all done i'll be booring
<rick_h_> heh, except then we'll have the big daddy of work coming down the pipe
<rick_h_> on top of a bunch of smaller things we've not gotten done yet
<hatch> haha truth truth
<rick_h_> if we can hit boring by vegas I'll be a happy techie. It won't be afterwards
<hatch> lol 
<hatch> Yo Dawg We Heard You Like Webkit..... https://github.com/trevorlinton/webkit.js
 * frankban lunches
<rick_h_> jujugui afk for a bit making sure the boy goes to tumbling class
<frankban> guihelp: I need two reviews for https://github.com/juju/juju-gui/pull/215 . Anyone available?
<hatch> frankban I can take one in about 40mins
<frankban> hatch: thanks
<kadams54> rick_h_: let me know when you want to chat about machine view
<hatch> frankban so the deployer now reports back to the gui the status of the bundle deployments?
<hatch> Is this a new deployer feature?
<frankban> hatch: no, that's an old guiserver API we never used
<rick_h_> kadams54: rgr, shoot me a link
<hatch> oh, so did we do it incorrectly when we did the old GUI implementation?
<hatch> curious as to why we didn't do it this way to begin with
<rick_h_> hatch: just didn't think about that when we added it
<frankban> hatch: previously we just watched the progress of deployment started by the GUI itself
<hatch> ohh ok cool
<hatch> I was just curious
<kadams54> rick_h_: https://plus.google.com/hangouts/_/7ecpikj49vjg2en7dif8j4dvuc
<rick_h_> hatch: fyi, added some more notes and such to the state urls google doc for the refactor work
<rick_h_> kadams54: sec, google hating on my dual account nature
<hatch> rick_h_ ok I see - so much $
<hatch> ;)
<hatch> jcsackett I couldn't get wordpress to balance using haproxy so I think I might be using haproxy wrong...
<hatch> do u have any experience with it?
<rick_h_> hatch: heh, yea well trying to break down what the new bits of data we'll need. Simplify it down some
<jcsackett> hatch: i haven't played with haproxy at all, tbh, but i can try to look through the docs some evening this week.
<hatch> :)
<hatch> jcsackett well I create the relation...then what? I figured you would access the related service on the haproxy ip
<hatch> but no such luck
<hatch> thanks - I'm trying to find time when I can
 * hatch is trying juju quickstart lxc in a saucy vagrant 
 * hatch crosses fingers
<kadams54> hatch: http://the.taoofmac.com/space/HOWTO/Vagrant
<kadams54> Pretty detailed instructions on setting up LXC containers in Vagrant on a Mac
<hatch> kadams54 I'm leaving that to juju
<kadams54> I've gotten about half way through them - running into problems installing Guest Additions from the commandline. Not seeing the CD mount anywhere.
<hatch> it's apparently provisioning the machine
<kadams54> Let me know how it goes
<kadams54> The instructions above get you to a point where LXC containers have direct access to files on the Mac file system and connecting in is "ssh user@containers.local" (yay Bonjour)
<hatch> that's pretty cool, I'll give that a go, I haven't thought about running lxc's in vagrant for anything other than juju
<hatch> it's still provisioning...maybe it's hung hehe
<hatch> hey look at that, it's working
<hatch> ....
<hatch> famous last words possibly...
<hatch> lol
<hatch> frankban your review is done I'm just qa'ing it
<hatch> looks like I'll have to create a ssh tunnel to the gui instance in the vagrant
<hatch> it's given a 10.x.x.x ip
<frankban> hatch: cool thanks
<rick_h_> kadams54: so in poking around there is an app.db.machines list that's a YUI model list
<hatch> Makyo do you know what the pw is for the vagrant images?
<rick_h_> kadams54: and you should be able to monitor that model list ofr events to keep things up to date I'd think
<hatch> you bet
<hatch> (finally something that won't rely on dbupdate)
<rick_h_> yea, I'd hate to have to do that for these Y.Views like that
<kadams54> Great
<hatch> kadams54 http://yuilibrary.com/yui/docs/api/classes/ModelList.html look for the 'events' section
<bac> so did y'all hear about the world's biggest ferris wheel that opened yesterday in vegas?  about 25% taller than london eye.
<rick_h_> jujugui call in 10, please kanban
<hatch> bac yeah? April Fools?
<bac> nope
<hatch> linky
<bac> hatch: not handy.  it is called 'high roller'.
<bac> LMGTFY
<hatch> bac I see it now
<bac> http://en.wikipedia.org/wiki/High_Roller_(Ferris_wheel)
<hatch> too bad it's view is of a big parking lot lol
<bac> $35 or so
<bac> yeah, its right behind our hotel
<kadams54> It needs to be on top of a casino
<kadams54> Like that roller coaster
<kadams54> Which was also called High Roller, but is now closed :-(
<bac> not to outdone they are planning a bigger one in dubai
<bac> s/to o/to be o/
<hatch> it'll probably have decent views at night
<hatch> during the day vegas is just dirty
<hatch> :)
<bac> and at night it is dirty and lit by neon?
<kadams54> Dubai: the Samsung Mobile of countries. "That's awesome. Now we'll copy and make it bigger."
<rick_h_> glow in the dar dirt woo
<hatch> bac the dirty is harder to see lol
<Makyo> hatch, sorry.  What do you need a password for?
<hatch> Makyo I found it, it's vagrant:vagrant u/p
<Makyo> Okay.
<hatch> Makyo create a ssh tunnel to the juju-gui lxc in vagrant
<Makyo> I've not yet needed it.  good find.
<hatch> Makyo yeah - it's pretty cool, quickstart and everything works in vagrant
<hatch> it's a little slow spinning up...but whichever
<rick_h_> kadams54: ping for stand up
<kadams54> Hah, sorry
<kadams54> Too involved in this MV stuff
<rick_h_> kadams54: :)
<hatch> frankban I don't think the QA worked, do you have a second for a call?
<hatch> oh wait...
<frankban> hatch: sure
 * frankban waits
<hatch> sorry I just want to finish the qa :)
<frankban> np
<hatch> frankban in the standup room
<frankban> hatch: if you need to double check bundles status, you can also point your browser to https://<vagrant-gui-url>/gui-server-info
<hatch> ohh ok, too late
<hatch> :)
<hatch> but It was working as expected other than that one 'issue'
<frankban> heh
<frankban> cool
<hatch> kadams54 xscope looks pretty cool
<kadams54> Didn't buy it for a long time because $30 seemed a lot for a glorified screen ruler. I was wrong.
<rick_h_> ccccccdilrkrudgkrilnrbkvbvvhbclkjfkbtugulikd
<rick_h_> bah
<kadams54> rick_h_ is trying out a new vim-irc plugin
<rick_h_> jujugui going afk for a little bit. If you need me feel free to call, text, or etc
<hatch> get betta
<hatch> kadams54 lol
<kadams54> OK, so app architecture question: this came up in Nick's interview, but how do we handle passing the DB into views?
<frankban> kadams54: passing it as a view attr, so that the view can do "this.get('db')" is the option used when instantiating the environment view
<hatch> kadams54 new Y.juju.myView({db: this.db})
<hatch> for example
<kadams54> OK, I follow that, but one thing that puzzles me is that I don't see db listed in the ATTRS bit in environment.js
<hatch> kadams54 yeah sometimes we forget to add them
<hatch> feel free to add it and document it :)
<hatch> if you pass it in, it's there, weather you define it or not
<hatch> kadams54 when I started almost no attributes were listed/documented
<hatch> :(
<kadams54> :-(
<kadams54> Another question: it looks like there's a JujuBaseView in utils that has functions for binding a model to a view - should I use that mixin with MachineViewPanelView?
<hatch> I'm guessing no
<hatch> but let me see
<kadams54> Seems more useful when a view is tightly tied to a particular model (i.e. a detail view)
<kadams54> Less so when your view be handling multiple models
<hatch> it's only used in the login view and notifications view
<frankban> kadams54: yeah for a model list it does not seem to make much sense
<kadams54> Pro tip: if your headset has controls that clip to your belt, it's always a good idea to remove it before walking away from your laptop.
<hatch> lol
<kadams54> On a related note: USB: can haz magsafe connectorz?
<hatch> hah! magsafe is pretty cool but I've found sometimes they dont' quite line up properly
<hatch> although it has saved my laptop a few times :)
<kadams54> magsafe is magical if you have pets and/or kids
<hatch> no kids!!!
<kadams54> I think dogs may be the worst
<kadams54> They get *SO* happy and hyper.
<hatch> haha, we have 3
<kadams54> OHMYGODSOMEONESATTHEDOORWAGTAILDESTROYEVERYTHING!!!!
<kadams54> That's my chocolate lab
<kadams54> My friend has pugs
<hatch> haha it's true
<kadams54> I once watched them sweep a bowl of chips and a bowl of salsa off a coffee table by dragging all four PS2 controller cables across. And they didn't miss a beat, charging right on through and up to the door.
<hatch> haha love it
<kadams54> Lunching
<arosales> jcastro: do you have a link handy for the rails scalable bundle?  I can't seem to find it at https://jujucharms.com/sidebar/search/bundle/~charmers/mongodb/5/cluster/?text=bundles
<jcastro> arosales, the scalable bundle doesn't show up in the store
<jcastro> rick_h_ is aware of it
<jcastro> http://manage.jujucharms.com/bundle/~charmers/rails/example-single is what we have right now
<arosales> jcastro: for the flyer I was going to put the quick-start examples and we have rails scaleable there
<jcastro> arosales, yea it used to work and then something changed, I don't think it's broken forever broken
<jcastro> just normal broken
<jcastro> rick_h_, ^^^
<arosales> do we know what the quick-start command will look like, perhaps, 'juju-quickstart bundle:rails/scalable
<jcastro> juju-quickstart bundle:rails/example-scalable
<hatch> jcastro arosales he is sick so probably will pop back in later on
<jcastro> ok
<arosales> hatch: thanks
<jcastro> hatch, do you happen to know who was looking into our missing bundle?
<arosales> do any folks know when 'juju-quickstart bundle:rails/example-scalable' will work again?
<arosales> I would like to put this into print, but I don't want folks trying something that won't work either
<hatch> jcastro umm one sec let me see if I can find the discussion
<hatch> jcastro sorry I don't see it anywhere in the task list. bac  do you know anything about the status of ^
<frankban> jcastro, arosales: "juju quickstart bundle:rails/example-scalable" seems to be working here. so my guess is it's present in charmworld but there is a problem with the search
<frankban> http://manage.jujucharms.com/bundle/~charmers/rails/example-scalable
<arosales> frankban: ah good to hear that the quick-start command is still working
<arosales> frankban: the correct command though is "juju-quickstart bundle:<path>" correct?
<frankban> arosales: yes. quickstart accepts several ways to specify a bundle, for promulgated ones, bundle:basket/name is sufficient
<jcastro> frankban, oh cool, thanks for getting rid of ~charmers for that. <3
<frankban> :-)
<hatch> I was talking to a guy the other day who said 'charmers' is so confusing
<arosales> frankban: thanks for confirming the command still works I will insert that into our upcoming flyer and highlight the good works folks here are doing
<hatch> he was wondering why you can't just promote someones charm, why you need to go through so many steps to find the owner of the charm
<hatch> ^ jcastro  just fyi
<jcastro> hatch, what do you mean by promote
<jcastro> promote as in promote in the store
<jcastro> or promote as in spread the word?
<hatch> umm lemme find an example
<frankban> arosales: cool thanks. simplified bundle URLs have been introduced in quickstart 1.2. "juju quickstart -h" includes some examples
<hatch> jcastro so for example https://jujucharms.com/sidebar/search/~clint-fewbar/precise/haproxy-1/?text=haproxy vs https://jujucharms.com/sidebar/search/precise/haproxy-28/?text=haproxy the 'promoted' one is in an entirely different repository than the maintainers
<jcastro> oh you mean the ability to use a personal branch as the canonical store one?
<hatch> yeah - he didn't understand why one just can't be 'promoted' and needs to be a copy losing all of the commit histories and suh
<hatch> such
 * arosales looking at "juju quickstart" and "juju-quickstart"
<rick_h_> jcastro: it should be back in there now
<jcastro> rick_h_, not in the website
<jcastro> but we can quickstart it
<rick_h_> jcastro: hmm, it was showing will look
<rick_h_> otp
<jcastro> no worries
<arosales> jcastro: we should sync up with curtis and have quick-start promoted bundles put into charm testing.
<rick_h_> jcastro: bah, it was working. Now it's gone again. It exists but it's a search bug http://manage.jujucharms.com/bundle/~charmers/rails/example-scalable
 * rick_h_ adds the bug back 
<hatch> yay my blog post finally came in handy for myself lol http://fromanegg.com/post/51864370819/xor-in-javascript
<kadams54> Heh
<Makyo> Holy crap forgot about appointment.  Bakc in a bit!
<hatch> somehow I broke half the routing
<hatch> man this state stuff
<hatch> ....
<hatch> oh aync callstacks you rock
<tvansteenburgh> can anyone explain how i can clip my charm icon image to the rounded corners in the icon.svg template?
 * tvansteenburgh is an inkscape newb
<hatch> Hi tvansteenburgh there are some docs about that
<hatch> one minute I'll see if I can find it
<hatch> tvansteenburgh https://juju.ubuntu.com/docs/authors-charm-icon.html
<hatch> it comes with a template 
<tvansteenburgh> i'm embarrassed that i didn't notice the Charm Icons section of those docs
<tvansteenburgh> tyvm
<hatch> haha np that is a long list :)
<hatch> rick_h_ you around?
<rick_h_> hatch: what's up?
<hatch> I think I'm done this branch, just writing/fixing tests now and wanted to make sure I did what this card encompasses\ https://github.com/hatched/juju-gui/compare/juju:develop...hatched:new-states?expand=1
<rick_h_> looking
<hatch> the viewstate needs to go it's quite the headache :)
<hatch> but I think that's a breaking change
<hatch> so maybe we want to do a release first
<hatch> feeling better btw?
<rick_h_> what's that? You don't care for viewstate? :P I'd never have guessed
<hatch> lol - but THIS time I have science on my side!
 * hatch considers programming a science 
<rick_h_> hatch: comments added
<rick_h_> hatch: but yes, that's the card encompassing
<hatch> hmm - I don't understand your last comment, hangout?
<rick_h_> sure
<hatch> https://plus.google.com/hangouts/_/7ecpjmkjhr157f7i1s2f9vdfb8?hl=en
<hatch> hmm
<rick_h_> hatch: can you jump back in that hangout?
<hatch> https://plus.google.com/hangouts/_/7ecpiqb1951juiealdk2fq8r6k?hl=en
<hatch> new link
<hatch> kadams54 I thought you were taking off early? :)
<hatch> "kid can wait"
<kadams54> I did. Now I'm back.
<hatch> :P
<kadams54> Soon I'll be gone again :-)
<hatch> haha
<huwshimi> Morning
<hatch__> morning
<rick_h_> morning huwshimi 
<hatch> rick_h_ ok thingy moved....should be good enough to get others unblocked
<hatch> now to fix tests and the like
<rick_h_> hatch: make sure to use FF on the tests vs making them test broken things please
<rick_h_> ideally the changes are behind FF and the existing tests 'just work'
<hatch> FF? 
<hatch> flags?
<rick_h_> yes feature flags
<hatch> ohh, yeah, it's all under il and mv now
<hatch> those should be merged soon
<hatch> since both are required now
<hatch> well not 'required' but might as well
<rick_h_> well, yea they're different and helpful for QA for design atm
<rick_h_> e.g. test inspector stuff, drag/drop vs the machine view panel covering everything
<hatch> no longer an issue once this branch lands :)
<rick_h_> hatch: close, but yea. After the refactor and and move the deployer bar stuff from IL to MV
<hatch> hmm phantom keeps crashing again
<hatch> I was wondering when this would start happening again
<hatch__> Makyo did your tests start to fail in juju-views-utils ?
<rick_h_> hatch: just tried out tests with updated trunk and after a clean-all to update the d3 stuff they passed
<hatch> yeah these aren't failing or anything
<hatch> phantom just stops
<rick_h_> oh bummer
<hatch> yeah this used to happen for the longest time then it just resolved itself
<hatch> ....should have known
<rick_h_> heh, cursed hatch computers
<hatch> ExceptionHandler::GenerateDump waitpid failed:No child processes
<hatch> ugh
<hatch> PhantomJS has crashed. Please read the crash reporting guide at ...
<Makyo> hatch, erk, sorry, was on the couch with the other computer.  It was something in there with a #<Object> has no method something something.
<hatch> Makyo oh ok np, so it wasn't phantom just crashing ok
<hatch> maybe a reboot will fix
<Makyo> :)
<Makyo> Hahaha
<Makyo> I feel like a windows developer again.
<hatch> hmm nope
<Makyo> hatch - now crashing for me, too, same error, different location each time.  Will try on ubuntu directly + browser in OS X
<Makyo> Er, I meant to leave that in the input buffer.
<Makyo> hatch - now crashing for me, too, same error, different location each time.  Will try on ubuntu directly + browser in OS X 
<Makyo> test-server works, though.
<hatch> ohh interesting....ok well I'm glad that it wasn't just me
<hatch> I was going to use test-server as well :/ 
<Makyo> That will ensure that tests pass at least somewhere.
<Makyo> Will have to hunt that down.
<hatch> yeah I tried to make it run in CI but GH was down
<hatch> I hope that' CI isn't borked because it runs in phantom once too
<hatch> at least I think..
#juju-gui 2014-04-02
<Makyo> jujugui PR on loading relation indicator images https://github.com/juju/juju-gui/pull/218 (testing CI, too, tests fail on Air, can fix on ubuntu if they fail CI)
<Makyo> s/tests fail/console tests fail
<Makyo> No luck, will check in the AM
<rick_h_> frankban: morning
<frankban> hi rick_h_ 
<rick_h_> frankban: heads up, I talked to wallyworld last night and he says he's tested the joyent provider in trunk (and it's backported to the 1.18 tree) so hopefully that'll work 
<rick_h_> frankban: and thanks for replying to his email on the megawatcher updates. Can you create cards in the backlog for us to update where we watch for those ip address changes?
<frankban> rick_h_: yes I'll do. https://165.225.150.74/ is the GUI deployed on joyent \o/ 
<frankban> rick_h_: there is still  bug #1300846 which affects the quickstart implementation. I'll check if it gets fixed for 1.18
<_mup_> Bug #1300846: Juju crashes bootstrapping joyent <bootstrap> <joyent-provider> <juju-core:In Progress by jameinel> <juju-core 1.18:In Progress by jameinel> <https://launchpad.net/bugs/1300846>
 * frankban lunches
<rick_h_> frankban: awesome, I just saw a branch from him around the provider and wallyworld admitted it needed a "couple of tweaks to be perfect" 
<rick_h_> so not  https://codereview.appspot.com/83540043/
<rick_h_> sorry, so looks like it's in progress and should land somewhere soon hopefully
<rick_h_> frankban: very cool to have another provider working woot thanks for keeping up on that. 
 * rick_h_ runs to take the boy to day care back in a few
<rick_h_> back
<frankban> Makyo: mroning, do you have time today for reviewing https://github.com/juju/juju-gui/pull/215 ? thanks
<frankban> morning even
<rick_h_> frankban: think he's still a couple hours away
<rick_h_> frankban: I'll be relocating shortly when the cleaners get here but can start going through it if you need a second review
<frankban> rick_h_: there is no rush, it was more like a message from the past, thank you
<rick_h_> lol echo echo
<frankban> :-)  rick_h_: I created the two cards in backlog/deck
<rick_h_> frankban: thank you much
<frankban> rick_h_: thanks for the review. re comments: good suggestion
<rick_h_> frankban: thanks for the update :)
<hatch> morning
<rick_h_> morn
<rick_h_> hatch__: https://plus.google.com/hangouts/_/canonical.com/go-over when you get a sec
<kadams54> Are there any Handlebars helpers in the codebase to handle displaying ModelLists (or even ArrayLists)?
<hatch__> rick_h_ thanks for the review - ugly I know *hangs head*
<hatch__> it'll get better!
<hatch__> kadams54 negative, it's always been to specific
<hatch__> domain specific*
<kadams54> Like {{#each}} but using object.each() to iterate rather than a for loop
<rick_h_> hatch__: yea, just want to make sure we know things are broken and note them to make sure we get them all fixed
<hatch__> kadams54 we usually convert it to an array/object then use the native handlebar helpers for looping
<rick_h_> kadams54: yea, often we have, in the view, a prepForTemplate() or something
<rick_h_> kadams54: that builds a handlebars friendly data structure 
<kadams54> Hmm. Would be nice if ArrayList had a function to spit out a plain list
<rick_h_> kadams54: well you can map based on Y.Array.each
<rick_h_> kadams54: but yea
<rick_h_> kadams54: http://yuilibrary.com/yui/docs/api/classes/Array.html maybe? I don't recall
<hatch> kadams54 typeof myArrayList._items === 'array'
<kadams54> Yeah, but accessing private members es no bueno.
<rick_h_> yea, frowed upon. It'll be a smallish list
<rick_h_> you're safe looping it out into a new strcuture
<rick_h_> kadams54: as you'll probably want to turn the models into objects and such anyway
<rick_h_> tweak things in process
<kadams54> Thinking about similar situations in python where there's usually a method on the iterator to have it spit out a list object
<hatch> the _items property will -never- change, it's a YUI convention
<rick_h_> kadams54: yea, I'd just add a prepForTemplate() handler
<hatch> it's ok to access it
<hatch> I promise :)
<kadams54> rick_h_: will do
<hatch> grep _items in our codebase you'll se we use it already
<bac> jujugui: charmworld review please  https://codereview.appspot.com/83620043
<rick_h_> kadams54: http://yuilibrary.com/yui/docs/api/files/app_js_model-list.js.html#l888
<kadams54> Nice
<rick_h_> http://yuilibrary.com/yui/docs/api/classes/ModelList.html#method_toArray for the prettier view
<rick_h_> bac: can look in a bit
<bac> rick_h_: thanks
 * rick_h_ heads back to the house from the coffee shop
<rick_h_> jujugui call in 10 please kanban
<rick_h_> hatch: looking at your commment
<rick_h_> hatch: the code reads that this.environmentHeader is gone
<rick_h_> hatch: replaced by var header
<rick_h_> oh, it's added back in line 57
<rick_h_> hatch: any reason for the change/indirection?
<hatch> minification
<hatch> :)
<rick_h_> jujugui call in 1
<jcastro> rick_h_, hey what's the tldr on showing colocated services in the gui?
<jcastro> I feel like for 14.04 we should have a owncloud all-in-one bundle
<rick_h_> jcastro: http://comingsoon.jujucharms.com/:flags:/il/mv/ in progress see you in vegas
<jcastro> whoa! that looks nice!
<frankban> rick_h_: one thing we missed: the 1.18 change which no longer includes the unit public address in the mega-watcher breaks quickstart :-/
<rick_h_> frankban: ok, well that'll have to be the reason to force an upload update for quickstart
<frankban> rick_h_: quickstart uses the watcher to retrieve the GUI address
<frankban> rick_h_: also, without the change to the MachineInfo I mentioned in the email, there is no way currently for quickstart to get the unit address when using the local env
<frankban> rick_h_: so 1) make the change in core and 2) update quickstart
<frankban> rick_h_: 2) is tricky because we will need to support both new and old behavior
<frankban> rick_h_: I suspect we should escalate those bugs
<rick_h_> frankban: +1
<frankban> rick_h_: and the core fix should be included in 1.18, otherwise we have a limbo in which there is no way to get containers' addresses for API clients
<frankban> rick_h_: what's the timing for 1.18?
<rick_h_> frankban: it's moved so much I'm not even sure any more
<frankban> heh
<rick_h_> frankban: let's talk to sinzui and get that marked as a blocker for 1.18 
<rick_h_> and then we can get that going asap
<frankban> +1
<hatch> Makyo just ran it again and it still failed locally
<hatch> I'm baffled 
<rick_h_> hatch: bisect? does it work on older code?
<rick_h_> go back a week and make clean-all
<rick_h_> there could be a real bug, better to catch it now while bisect path is short
<hatch> yeah going on that now
<hatch> I had a conflict i had to resolve
<rick_h_> other thing is a fresh checkout and see if there's something else that's off
<hatch> I ran into a very odd chrome bug debugging those routes yesterday - it would cache the previous url even though the path didn't have /inspector for example
<hatch> the solution was to open a new tab
<hatch> nananananananana bisect man bisect man
<hatch> hmm nope even old versions are broken
<hatch> new repo time
<hatch> wow our git repository is getting large
<hatch> 90MB or so
<rick_h_> sorry bac getting back to your review
<rick_h_> everyone seems to think today is monday and wants to break stuff :)
<hatch> haha
<hatch> even a new fresh checkout doesn't fix it :/
<hatch> wth
<rick_h_> hatch: then your machine is broken, time to buy a new one :P
<hatch> mine AND Makyo's?
<hatch> c'mon!
<Makyo> Hahaha
<Makyo> hatch, you working in vagrant?
<hatch> yeah
<Makyo> That's the common factor, I think.
<hatch> yeah but what changed? It worked two days ago
<Makyo> d3 upgrade involved regenerating npm-shrinkwrap, maybe that?
<hatch> ohh
<hatch> lemme check out before that
<Makyo> It should still snag the same version - none of the versions changed - but maybe something's going on with that.
<hatch> ok trying a pre-D3 branch
<hatch> maybe we need to update to the latest phantom binary
<hatch> anywho I'll keep you posted
<Makyo> hatch, you'll have to make clean clean-all etc.  Sorry. I'll do the same to check it out.
<hatch> yep it's npming now
<hatch> ugh I long for the day there is an npm rollup
<hatch> Makyo nope still crashed
<hatch> :/
<hatch> ExceptionHandler::GenerateDump waitpid failed:No child processes
<Makyo> Boo!
<Makyo> Yep, same thing here.
<Makyo> What would it take to get test-debug/prod to run locally?
<hatch> it does?
<Makyo> I haven't tried yet, I've been getting that in the vagrant.
<hatch> what do you mean to run locally?
<Makyo> In osx term
<hatch> ohh it can't the way we are running it
<Makyo> Okay. Hmm.
<Makyo> Wonder if it's a saucy thing.  Let me see what happens if I go back to Raring.
<hatch> https://github.com/juju/juju-gui/blob/develop/test-server.sh
<rick_h_> frankban: sorry, one more call. Just talked with james/robie
<frankban> rick_h_: same url?
<rick_h_> frankban: https://plus.google.com/hangouts/_/7ecpjnf6uun25l4dh5sus8edhg?hl=en
<hatch> Makyo I'm updating phantom and mocha-phantom 
 * hatch crosses fingers
<Makyo> hatch, okay.  I'm ducking back to Raring real quick, will compare notes.
<Makyo> jujugui need qa on https://github.com/juju/juju-gui/pull/218 real quick.  Fast one.
<rick_h_> frankban: http://paste.ubuntu.com/7194939/ is the other package they've got that is a lot like this
<hatch> ugh I just wish I could run Ubuntu on metal
<hatch> someone fix the kernel
<rick_h_> frankban: they make --no-adjust-repos the default in the distro package
<hatch> Makyo new versions didn't help...
<hatch> although now it's just crashing without any error
<frankban> rick_h_: sound good, so --distro-only and --ppa? 
<Makyo> hatch, improvement!
<Makyo> Well, okay.  Not really.
<hatch> lol
<rick_h_> frankban: sounds good to me
<hatch> I wonder if we are runnign too many tests and it's overloading something
<hatch> too much domness or something
<hatch> there are 1040 issues....
<hatch> yikes
<Makyo> Yeah.  Curious if it's an NFS problem.
<Makyo> Will check raring, almost done provisioning.
<hatch> cool - wasn't there a reason why we upgraded though?
<frankban> rick_h_: cool, both == --ppa, none == --ppa
<Makyo> Don't believe it worked for bac?  Something.
<Makyo> hatch, if the downgrade works, though, we can rule out NFS.
<hatch> yeah it's just very odd that it just happened
<rick_h_> frankban: sounds good to me
<Makyo> and keep nfs on raring, maybe trusty
<Makyo> YEah.
<hatch> with no changes...
<Makyo> hatch, other than added tests, like you said.
<hatch> yeah but rolling back to an old version didn't make it pass
<rick_h_> hatch: when you rolled back you make clean-all?
<hatch> you bet
<rick_h_> hatch: so that you got the old node/d3 deps?
<rick_h_> cool, just checking
<hatch> I even tried a fresh new repo
<hatch> https://github.com/ariya/phantomjs/issues/11706
<hatch> ^ hmm
<Makyo> hatch, I juist think it might be a system dependency,  not a node dependency.
<Makyo> Oh, hmm.
<hatch> works now?
<Makyo> Oh, no, you're GH issue
<hatch> ahh yeah...
<Makyo> hatch, try modifying the phantomjs command to output more?  --debug=true I think
<hatch> hmm not according to it's docs
<hatch> but I can try
<hatch> oh --setting debug=true
<hatch> ok trying that
<Makyo> hatch, okay, sorry.  Was going off the global install on my linux box.
<hatch> well because we use mocha-phantomjs to run the tests
<Makyo> Oh, right, hah.
<hatch> still no output
<hatch> ugh
<Makyo> Gah
<hatch> rick_h_ I don't think this is a valid route /inspector/apache2/service
<hatch>  /inspector/apache2 would show the details by default
<hatch> and /inspector/apache2#tabName would show the appropriate tab
<hatch> unless 'service details' means something else?
<hatch> oh s/service/charm
<hatch> makes sense
<rick_h_> hatch: rgr
<rick_h_> hatch: oh wait, so that was the url to have service details shown from the inspector
<rick_h_> so /inspector/apache2 is inspector
<rick_h_> and /service on it means details of that service popout
<rick_h_> hatch: welcome suggestions 
<hatch> isn't that the charm details? what are the service details?
<rick_h_> hatch: from the inspector you click the link and the details pops out to the left
<rick_h_> that's not quite charm details, it's different data?
<hatch> I was pretty sure it was the exact same thing
<rick_h_> well the data comes froma  different place
<rick_h_> service data vs browser model data
<rick_h_> tabs are different etc
<hatch> hmm
<hatch> lemme mull it over
<rick_h_> k
<hatch> but ok I understand now
<hatch> thx
<Makyo> hatch, charm version differences are taken into account there.
<Makyo> Store will always show you the latest version.
<hatch> yeah right but to me /inspector/apache2/charm means the charm details for that service
<Makyo> Oh, sorry.  Don't have the doc in front of me.
<hatch> where /inspector/apache2/service doesn't really say anything about the service, it's talking about the charm
<Makyo> Trying to debug CI failure.
<hatch> I'm mulling....I'm mulling!
<Makyo> Mmm, mulled wine
<rick_h_> hatch: it's the information in the service. It's readme/etc
<rick_h_> hatch: it's more of a comparison to charm details (browser) service details (/service) unit details (/unit/4)
<rick_h_> those are the 3 versions/distinctions
<hatch> I just think that /inspector/apache2 IS the service and we are showing the charm details used to create that service
<Makyo> hatch, on a more interesting note, tests work in raring.
<Makyo> s/interesting/positive
<Makyo> Didn't mean to imply, sorry.
<hatch> hmm so everything works on raring?
<Makyo> That was test-debug, let me do test-prod
<rick_h_> hatch: we've just got to port what already exists. Something has to say "this inspector is open on X" and something else needs to say "inspector is open on this with the details open"
<hatch> yep for sure
<hatch> arm the charm details don't have any url
<hatch> it just minimizes the sidebar
<hatch> just fyi
<rick_h_> huh?
<rick_h_> /precise/mysql-10 is a charm details url. 
<rick_h_> plus /sidebar/precise/mysql-10, and /sidebar/search/precise/mysql-10?text=mysql
<hatch> not when you click it from the inspector
<hatch> it minimizes the browser and opens the left panel
<hatch> without a url change
<rick_h_> right, that's what we do now
<rick_h_> which is why we're inventing a new url
<rick_h_> there's not space to show the sidebar + inspeector + details. In the new world we'll show inspector + details
<hatch> right
<rick_h_> hatch: so what's the issue/argument point here? 
<rick_h_> you don't like the word service and prefer the word charm?
<bac> hey rick_h_, regarding an XXX bug for removing the deprecated field, we could do that, but it is kind of out of our hands.  i don't see it happening before the death of charmworld.
<rick_h_> bac: k, nvm then
<hatch> rick_h_ yeah - /service seems weird
<rick_h_> hatch: ok, then happy to entertain a better word
<rick_h_> details was ditched because there's two types of details off the inspector. I didn't pick charm because things would get called charmDetails and such and it's an overloaded term already. 
<rick_h_> you're right that technically the inspector is the details of the service
<rick_h_> so service isn't great either
<hatch> yeah....hmm
<hatch__> hmm apparently freenode didn't like it either lol
<Makyo> hatch, test-prod fails with the same error :(
<hatch> ugh
<hatch> what in the heck is going on
<Makyo> No clue :(
<Makyo> Will keep poking.
<Makyo> Meanwhile, think I figured out CI problems, created discussion card for what I found.
<hatch> ugh devops issues infuriate me
<Makyo> Also meanwhile, if chiptunes are your thing, the ChipWIN April Fools album is actually pretty good, despite being mostly jokes. http://chiptuneswin.com/album/chiptunes-srsbsns
<hatch> I've tried to do the chiptune thing
<hatch> can't quite get into it
<Makyo> Haha, that's fair :)
<Makyo> Took me a bit to get past the fact that it's not mixed down to the wall-of-sound that we've come to expect from music these days.  Motown popularized that  years ago, and it's just gotten more and more extreme since.
 * Makyo rambles.
<Makyo> AGH I hate not having .lbox.check
<Makyo> Sorry for the spam.
<rick_h_> Makyo: a pre-commit or pre-push hook added to the docs would be cool :)
<Makyo> rick_h_, Alright, will investigate over lunch!
<hatch> yeah pre-push hook would be awesome
<hatch> although also somewhat irritating
<hatch> because you could never push incomplete code
<hatch> heh
<hatch> git pushncheck
<hatch> :)
<hatch> so it's an alias maybe
<Makyo> hatch, there's apparently a --no-verify option
<hatch> oh interesting
<Makyo> At least, to pre-commit hooks, reading up on pre-push
<hatch> ohhhh rick_h_  you changed our 1:1 ok lunching now
<hatch> :)
<hatch> bbiab
<rick_h_> hatch: changed it? /me thought it was always here. 
<rick_h_> hatch: oh, this is the time change in effect maybe?
<rick_h_> it's still 2pm for me
<hatch> oh it says it was just changed
<hatch> odd...ok whichever I thought it was right now
<hatch> I'm hungry anyways
<hatch> :D
<rick_h_> it is right now
<rick_h_> I'm in there, huh?
<hatch> weird
<hatch> ok joining
<frankban> rick_h_: I have to go, I have a possible prototype to fix the issue, see http://pastebin.ubuntu.com/7195287/ (lp:~frankban/juju-core/machine-addresses). There might be still something to fix, you can take a look at the discussion in #juju-dev. Please feel free to email me if you get additional info. I'll check tomorrow morning if I can do something. Have a nice evening!
<rick_h_> frankban: thanks so much, have fun!
<Makyo> Got an email of someone trying to recruit me through a dating app.  Unfortunately, the recruitment company has debug mode on, and so now I have their DB server password.  Classy.
<Makyo> Wonder if it's some ridiculous CTF.
<rick_h_> lmao
<Makyo> Looks like it made it to HN, now their cache is failing.
<Makyo> Aaaand now it's just blank.  That was fast.
<hatch> Makyo what were they recruiting you for?...
<hatch> :P
<Makyo> Never did find out.  Their redirect thing is what threw the debug error.
<Makyo> It was a click-tracking thing on the recruiter's site.
<hatch> ohh haha
<hatch> the other day I was recruited for a mechanical engineering position
<hatch> I think they read the 'software engineer' and was like....."close enough"
<hatch> lol
<rick_h_> kadams54: hey, meant to stab you and let you know today is you QA day
<rick_h_> and welcome back to the interwebs :)
<kadams54> Yeah, I realized that around 1 today :-)
<rick_h_> I'll need the pokey stick back for bac tomorrow
<bac> rick_h_: er?
<hatch> lol
<hatch> stabby stabby
<bac> oh, to do QA?
<bac> yeah, good luck with that
<rick_h_> bac: friday chat was that we want to bring back the QA day. I'll use a pokey stick to help remind folks 
<bac> i *always* forget
<bac> ok, i'll try to remember
<rick_h_> thus the pokey stick, I've got to remember before EOD tomorrow unlike today
<kadams54> Soâ¦ what's the best way to do this QA?
<kadams54> comingsoon.jujucharms.com?
<rick_h_> kadams54: works for me
<kadams54> Production?
<rick_h_> or do a live environemtn
<rick_h_> test out your lxc or ec2 setup
<kadams54> Oh yeah
<kadams54> I was going to get EC2 setup
<rick_h_> the goal is to test all kinds of things, whateer your fancy is and try to find a bug
<hatch> yeah - do odd interactions too
<rick_h_> try your non default browser of choice, non default env of choice
<rick_h_> preted you think like hatch 
<rick_h_> pretend
<hatch> lol
<hatch> enter my mind.....
<rick_h_> break outside the mold a bit and try to make sure things still work as expected
<hatch> kadams54 my mind http://upload.wikimedia.org/wikipedia/en/thumb/a/a3/Escher's_Relativity.jpg/300px-Escher's_Relativity.jpg
<kadams54> :-)
<rick_h_> hatch: that pic doesn't have enough promises in it :P
<hatch> lol
<Makyo> kadams54, actually, if you're doing QA stuff, think you could do a quick check on my PR?
<kadams54> Sure
<Makyo> 218
<Makyo> https://github.com/juju/juju-gui/pull/218
<Makyo> Sorry
<kadams54> Question: how intelligent should bundles be? That is, if I deploy the hadoop:cluster bundle and then attempt to deploy mediawiki:single after, is it fair to expect the mysql service in mediawiki to be renamed?
<hatch> kadams54 nope
<hatch> it'll fail
<hatch> there will be a bundle configuration step at some point
<kadams54> Yeah, I know it fails
<kadams54> That just seems sorta unfair to me as the user though :-)
<kadams54> Especially in complex environments
<rick_h_> kadams54: because you might want to share that service
<rick_h_> so let's say you have a beefy mysql server
<rick_h_> and want to share it across wordpress and mediawiki bundles
<rick_h_> kadams54: so it's a valid question, but we don't have the abliity to handle it right now
<rick_h_> so we error
<kadams54> Except you can't deploy the bundle
<kadams54> Yeah
<rick_h_> right, and you can't from the cli
<kadams54> OK
<kadams54> If the CLI can't do it :-)
<rick_h_> if you've got scripts that rely on that service name (juju log mysql/0)
<rick_h_> it'll break if you rename it automatically
<rick_h_> renaming is a bad thing in some cases
<kadams54> Not the existing service
<kadams54> The new service
<rick_h_> well a bundle is a repeatable deployment
<rick_h_> so in one cloud it's named X and Y in another?
<rick_h_> if you've got benchmark tools to automate testing you can't use it now
<kadams54> You just need to use a deterministic renaming algo
<rick_h_> it's all imaginary for sure
<kadams54> mysql-1 in both clouds
<kadams54> bam
<rick_h_> well then you're fine if you call it that in your bundle
<rick_h_> just don't use the default service names in your bundle and you're fine :)
<kadams54> Now you sound like a Java guy
<rick_h_> railsmysql, railsapp, railsmemcache :)
<kadams54> "Explicitly configure everything and you'll be fine!"
<rick_h_> just playing devils advocate 
<kadams54> ;-)
<rick_h_> it's something we'll deal with as bundes mature I think
<hatch> stacks ahoy!
<rick_h_> crazy to think they're still young little things. 
<rick_h_> this is the first ubuntu release with them in there
<kadams54> Someday they'll grow up and leave the nest *sniff*
<hatch> and we'll be ecstatic to have an empty house
<Makyo> jujugui docs change, but would appreciate someone checking my work: https://github.com/juju/juju-gui/pull/220
<hatch> rick_h_ routeDefault calls a jujucharms() view who actually only renders 'hello world' to the dom....was this supposed to be removed some time ago? 
<hatch> the XXX is from jcsackett  July 2013
<rick_h_> hatch: yea, there's a bug for it still I think
<hatch> hmm
<jcsackett> hatch: that was a long time ago, i think it was when we had a demo mode on top of the fullscreen mode etc etc.
<jcsackett> hatch: given even fullscreen is dead (right?) you can rip out any of that stuff you find.
<rick_h_> bah, thought there was one
<hatch> yeah I vaguely remember something about that
<hatch> jcsackett yep it's gone
<rick_h_> now I can't find, I'll have to look later sorry
<hatch> ok np I'll remove it
<hatch> if you find the bug plz assing to me
<hatch> assign even
<rick_h_> ok, I'm out all. Have a good night!
<hatch> enjoy
<hatch> Makyo looking at your branch
<hatch> Makyo review done
<hatch> sorry I kind of tore it apart...but in a good way :D
<kadams54> ALso just finished review on 218
<Makyo> hatch, re: the NO_VERIFY env var: this is specific to pre-push.  Pre-commit uses the --no-verify option.  We could leave it in, but it won't do anything.  Want to keep it?
<Makyo> It's not slowing anything down, just extra stuff.  No harm in leaving it.
<hatch> Makyo maybe we drop the --no-verify entirely and only use the env var so that it's the same across both check and lint?
<Makyo> hatch, it's not by check or lint, is by hook type.
<hatch> right
<Makyo> git commit --no-verify or NO_VERIFY git push
<Makyo> Etc.
<Makyo> Sure.
<hatch> NO_VERIFY=1 git commit 
<hatch> NO_VERIFY=1 git push
<Makyo> Sure.
<hatch> I'm just going for easiest to understand for new gitters
<Makyo> Sure.
<hatch> feel free to disagree :) 
<bac> rick_h_: would you remove benji from the short list of assignees in kanban?  i get sad everytime i see his name.
 * hatch hands bac a tissue
<Makyo> hatch, no, you're right,t hat's what hacking.rst is for
<Makyo> hatch, can I bother you real quick to check again and see if that's along the lines of what you were thinking
<hatch> sure
<hatch> looking
<bac> jujugui: would some bored soul please review https://codereview.appspot.com/83270048 ?  it is trivial.  only question is warning vs error.
<hatch> Makyo :+1: thanks
<hatch> I just deleted 200 lines of browser routing code and it still mostly works.....
<hatch> wow fullscreen required a lot of cruft
<hatch> bac on it
 * hatch isn't bored though
<hatch> I love that python can deconstruct vars....I wish js could do that (coming in ES6? 7?) 
<Makyo> Pssst.
<Makyo> Coffeescript can~
<kadams54> Eh?
<hatch> Makyo lol 
<hatch> no it just hides it
<Makyo> I kid, I kid.
<hatch> bac reviewed...plz see comment
<hatch> Makyo they are bringing arrow fn's to js in ES7 I think....
<hatch> it makes me sad
<bac> hatch: i just included QA instructions on the RV
<hatch> bac ok, before I qa let me know what you think of that comment
<rick_h_> bac: updated
<bac> hatch: i'm of two minds about your request.  i chose to do the easy thing because i think the intent is provide a simple check for people that forgot to remove the juju-gui from their bundle.
<bac> hatch: but it is easy enough to fail on either a service named 'juju-gui' or a charm url that has 'juju-gui' in it
<hatch> hmm
<hatch> are there any charms which could have juju-gui in them besides the actual gui?
<rick_h_> bac: I'd think we can get away with a warning. Because technically they can have a bundle with the gui, but it'll fail quickstart/dragging/dropping int he gui
<hatch> I think the potential false negative/positive is much less checking the charm
<rick_h_> bac: but will work for deployer/automated builds
<rick_h_> bac: and we only case about what 'will not work' which is colliding names
<rick_h_> bac: so if someone wants two guis, maybe different config/etc then more power to them
<rick_h_> imo 
<rick_h_> the goal if the work is to stop people from doing something sane (taking their env and exporting it) and having it fail to deploy 
<bac> rick_h_: but if it is just a warning then it'll get ingested into charmworld and be presented in the juju-gui sidebar and then not be deployable
<bac> so we'll have stuff over there that fails when you drag it in
<rick_h_> bac: ah true. Ok, yea, so guess it's an error
<rick_h_> so you can use a bundle of your own with it
<rick_h_> but not have it get ingested
<rick_h_> bac: sounds good to me
<hatch> rick_h_ mind weighing in on the "check service name or charm name" discussion?
<hatch> you can be the tie breaker
<hatch> :)
<hatch> no pressure
<rick_h_> we just need to check service name
<rick_h_> it's the only thing not allowed
<rick_h_> and the only thing that's causing users to hit errors
<hatch> ok that's valid
<rick_h_> there's nothing wrong with two guis like I said
<hatch> bac lgtm'd
<bac> hatch, rick_h_: in light of that i'll change the message to
<bac> Bundles may not services named "juju-gui".
<hatch> good call
<bac> but i'll make it make sense
<hatch> +1
<hatch> rofl
<hatch> HOW IS BABBY FORMED
<hatch> ^ still the best thing on the internet
<rick_h_> bac: thanks. We've done users a disservice with this so far so definitely good to help get them on the right track. 
<bac> hatch: are you going to QA?
<bac> hatch: sorry it is a pain.
<bac> hatch: i'm proposing that charm-tools patch next to make it less painful going forward
<hatch> bac sorry I don't have charmworld 
<bac> rick_h_: yeah, too bad we didn't pay a little more attention to the export process.  it became integral really fast and a few mistteps really bit us.
<hatch> I wouldn't even know where to start 
<bac> hatch: no biggie
<hatch> maybe someone who already has charmworld up and running
<bac> hatch: we can just let it land on staging and then qa from there.  i've proven it works on my machine.
<hatch> sure
<hatch> rick_h_ /precise/mysql and /bundle/... are really doing the same thing....is there a reason why they are handled separately? 
<hatch> one is rendered in sidebar and one is rendered in routedirectcharmid
<Makyo> jujugui anyone know what this is about? http://ci.jujugui.org:8080/job/juju-gui-merge/221/console This is on merging a docs only branch, has this changed otherwise?
<hatch> hmm
<hatch> I'd re-run
<hatch> I have seen it before and I think I just re-ran
<rick_h_> hatch: because they're different views, bundles, and url parts?
<rick_h_> hatch: e.g. bundle/mysql/scalable bundle/mysql/4/scalable 
<rick_h_> /precise/mysql is just the mysql charm with the latest revision
<hatch> yeah, lots of duplication of functionality across the two
<rick_h_> hatch: right, but they share a common View base, entityBase
<rick_h_> and so it's shared a bit, but the url matching/state is different. But this is what I mean about breaking things down into better state bits. 
<rick_h_> detail: bundle, id: mysql/4/scalable or detail: charm, id: precise/mysql, or detail: service, id: mysql, or detail: unit, id: 5
<hatch> do we have a list of the valid bundle urls?
<rick_h_> ~user/basket/bundle ~user/basket/version/bundle  (and without ~user where it's assumed it's promulgated and is ~charmers)
<rick_h_> so those 4 possible urls
<hatch> right now they are all /bundle/:user/:basket/:revno/:bundle
<hatch> ok cool thanks
<rick_h_> right, user and revno are optional and can be assumed as ~charmers or latest version
<hatch> hmm I wonder if I should remove minimized as well
<hatch> rick_h_ this is confirmed? ^
<hatch> Makyo looks like just re-running it was the trick?
<huwshimi> Morning
<Makyo> hatch, yep.
<Makyo> Sorry, was dogwalking
<hatch> no prob
<hatch> morning huwshimi 
<huwshimi> Internet is bad this morning.
<hatch> they need to run another phone line to the island I guess eh?
<huwshimi> hatch: Yep, it's a hassle when someone wants to make a call!
<hatch> lol, they pick up the phone and the internet goes down
<hatch> ugh parents
<huwshimi> haha
<huwshimi> hatch: There is fibre running past my house, they just haven't turned it on yet.
<huwshimi> Yay! I'm getting 0.31mbps!
<hatch> lol nice
<huwshimi> brb, rebooting router
<Makyo> hatch, got a minor fix for the provided example hook in hacking.rst.  Mind if I just land it?  Fixing a typo.  https://github.com/juju/juju-gui/pull/221
<Makyo> Just making it a bit more compatible.
<hatch> Makyo sure
<hatch> what does it do?
<Makyo> I wrote bash syntax, but used #!/bin/sh in the shebang.  Calls test to ensure that make lint runs unless NO_VERIFY was set.
<hatch> ahh
<hatch> coolio
<hatch> rick_h_ if you're looking for some night time reading material. I have removed viewmode but not yet added in all the state bits https://github.com/hatched/juju-gui/compare/remove-viewmode?expand=1
#juju-gui 2014-04-03
<rick_h_> Makyo: that error happens once in a blue moon and seems saucelabs related
<frankban> guihelp: anyone available for reviewing/QAing https://codereview.appspot.com/83880044 (quickstart)? thanks!
<bac> frankban: i will shortly
<frankban> bac: thanks
<hatch> morning
<rick_h_> morning hatch 
<hatch> hey rick_h_ when you did the nr_cpus=1 did you just put that in the list of the commands when editing the startup?
<rick_h_> hatch: have to put it in the right place
<rick_h_> where it says splash and such
<hatch> oh ok, I thought that might have been the case - I coudlnt' find any docs online about it
<rick_h_> change those to noslash noxxxx and add nr_cpus=1
<rick_h_> nosplash that is
<hatch> ok thanks - man I just want this darn thing on Ubuntu lol
<rick_h_> lol yea 
<rick_h_> thanks for following up and trying
<rick_h_> I've been knocked out dead early this week 
<hatch> https://bugzilla.kernel.org/show_bug.cgi?id=60635
<hatch> I am using redfind already....not sure how else to do an efi boot
<rick_h_> yea, I think we need to make that clear
<rick_h_> the bug linked might not be valid because he's missed we're using refind already
<hatch> I wish I knew -anything- about kernels lol
<kadams54> Anyone know why MachineList is a LazyModelList and not just a ModelList?
<kadams54> Doesn't seem like the performance advantage of LazyModelList would be needed here
<kadams54> And I'm depending on change events firing on the machines in the list in order to keep the MachineView up-to-date, which LazyModelList makes less likely.
<hatch> kadams54 there could be thousands of machines
<hatch> s/could/will
<kadams54> hatch: scratching my head over YUI stuff - could I have you take a quick look?
<hatch> 2 mins just gota grab my breaky
<kadams54> np
<hatch> ohh kay link?
<kadams54> http://pastie.org/private/hu1ljam1js0lhdtxozxdbw
<hatch> yep
<hatch> that's right
<hatch> :)
<kadams54> When I create a Machine and add it to MachineList, the raw object that I get back out of the list has a null displayName
<hatch> try foos.create()
<hatch> are the returned values actually strings? or is that just in your paste?
<kadams54> yes
<kadams54> actually strings
<kadams54> Paste is taken directly from web inspector console
<hatch> does create help?
<kadams54> No
<hatch> hmm ok lemme look at the lml code
<kadams54> http://pastie.org/private/qgxsrjhx5canncqqdqn7ug
<hatch> ok I'm going to fire up a jsfiddle here
<hatch> or jsbin for that matter
<rick_h_> kadams54: foos.items(0).get('displayName')
<hatch> it a pojo
 * rick_h_ is guessing displayName is an ATTR?
<rick_h_> oh nvm then :)
<rick_h_> bad guess
<hatch> so'ok!
<kadams54> LazyModelList stores the objects as POJOs instead of full Models for performance reasons
<frankban> kadams54: the displayName is added to machine objects by MachineList.add
<frankban> kadams54: it calls _setDefaultsAndCalculatedValues
<kadams54> Ah
<kadams54> And that's probably overwriting my "0" with a calculated value
<hatch> oh there we go :) I was just writing a repro with raw YUI
<hatch> heh :)
<kadams54> Which is why we get a "null" string
<kadams54> Instead of null
<hatch> thanks for stepping in frankban
<hatch> bleh lifestyle changes taste so bad...
<hatch> #dietingisforsuckers
<kadams54> heh
<kadams54> Thanks frankban - that was the missing piece
<frankban> welcome
<Makyo> jujugui call in 10
<rick_h_> I think Makyo has his alarm set for 11min vs 10 :P
<Makyo> 10 minutes by my phone, just whenever that goes off.
<Makyo> (but now I'm totally doing that.  Thanks rick_h_ :D )
<luca__> rick_h_: Makyo hatch can we have a call once your off your call? :)
<hatch> we can
<rick_h_> luca__: rgr
<luca__> thanks
<frankban> bac: http://bazaar.launchpad.net/~go-bot/juju-core/trunk/view/head:/doc/bazaar-usage.txt
<bac> thanks frankban
<rick_h_> luca__: https://plus.google.com/hangouts/_/canonical.com/daily-standup
<luca__> just saving my doc
 * frankban biab
<hatch__> brb
<frankban> rick_h_: so, should we keep joyent support out for now? I know our exception is for fixing quickstart on newer juju-core. I wonder if that's to be intended as exclusive i.e. only the buf fix, no other developments/changes added in the meanwhile
<kadams54> I was just getting ready to submit a pull request, but after rebasing to latest on develop, I can't get to the machine view anymore
<rick_h_> kadams54: hit the machine view tab in the nav
<kadams54> Yeah, I did.
<kadams54> Nothing
<rick_h_> kadams54: oh hmm, that works in comingsoon
<rick_h_> http://comingsoon.jujucharms.com/:flags:/il/mv/
<rick_h_> hit machine view button?
<rick_h_> kadams54: if it doesn't work locally make clean-all maybe? Or check for errors in console/etc
<kadams54> Will do
<kadams54> *sigh*
<kadams54> Error in my code
<rick_h_> frankban: can you write up an email about the joyent provider now landing and our wish to have that in quickstart to james page and robie and copy me? 
<rick_h_> frankban: we'll ask if it'll be possible, if not. Let's hold on landing that branch until the bugs land first
<rick_h_> so we can release just what we promised them, a bugfix release
<rick_h_> frankban: and if so, then we can follow up with the joyent under whatever rules we can get that in under
<rick_h_> frankban: and if not, then landing joyent in quickstart will be the start of the new ppa releases, but not in trusty
<frankban> rick_h_: sounds good
<kadams54> guihelp https://github.com/juju/juju-gui/pull/222 is ready for review and QA (list machines in machine view)
<Makyo> kadams54, on it
<kadams54> thanks
<rick_h_> jujugui going to go afk for some lunchable. biab
<hatch> enjoy
<frankban> kadams54: so, do we display both top level machines and containers in that part of the machine view?
<kadams54> Not entirely sure. There's a machine column and a container column, so I'd guess so?
<kadams54> My card was for listing the machines in the machine column, so the container column is still non-functional
<frankban> kadams54: if I read your diff correctly, you are listing all the machines (db.machines.toArray()). That would include also the containers. It is possible to only list top level machines by using machines.filterByParent(null)
<kadams54> Ah, did not realize the collection contained both machines and containersâ¦
<kadams54> Is there a reason containers aren't in a separate collection?
<frankban> kadams54: it's not a separate entity in juju-core itself, and also they share almost all the properties. it's a tree, where a phisical machine can host containers and containers can host other containers etc.
<hatch> rick_h_ âArguing with an engineer is like wrestling with a pig in mud â you realise far too late it is enjoying itâ  rofl
<kadams54> frankban: got it. Will modify the code accordingly.
<frankban> kadams54: cool thanks
<kadams54> hatch: Nice. I'll have to remember that one.
<hatch> I want a tattoo of that haha
<kadams54> Your wife might argue with you about that.
<hatch> what if it's in Japanese? Chinese? Then I'd be part of the cool kids 
<hatch> I'd just tell everyone it means "Love"
<hatch> lol
<hatch> Makyo I just booted up vagrant and it's creating a new image.....
<hatch> any idea how I would point it to the old one again?
<Makyo> Um.
<Makyo> I think it's in a .vagrant or something folder in ~?
<rick_h_> hatch: :)
<frankban> rick_h_: had a chat with robie in #juju, joyent is out, the other parts of the plan sound great to him. I think landing joyent later next week is fine.
<rick_h_> frankban: rgr thanks
<hatch> rick_h_ want to have a quick discussion about this branch
<rick_h_> hatch: sure link
<hatch> https://plus.google.com/hangouts/_/7ecpj9soau6943l97kuv7qnknc?authuser=1&hl=en
<bac> hi frankban, when bootstrapping joyent, after creating an environment with quickstart, i get http://paste.ubuntu.com/7199671/
<frankban> bac: uhm, is this the 1.18 branch?
<bac> i think so.  let me double check
<bac> frankban: yes, it is using the version i built using the 1.18 branch.  however, 'juju version' shows 1.19.0-trusty-amd64
<bac> frankban: i merged 1.18 into my lw checkout of juju-core trunk.  is that correct?
<frankban> bac: I don't think so, you should just branch the 1.18 branch and switch to that. I guess trunk includes other changes
<frankban> bac: my 1.18 branch is 1.17.8-saucy-amd64, bzr revno 2257
<bac> frankban: i'm unsure how to do that with lightweight checkouts.  usually i do a 'bzr switch -b', which gives me a copy of trunk.  how would i get a checkout of 1.18 in place?
<frankban> bac: also, before compiling "godeps -u dependencies.tsv" can be a good sanity check (go get launchpad.net/godeps)
<hatch> poor bws-icon
<hatch> delete!
<frankban> bac: I followed the bzr docs in trunk, and so I created a shared repo outside the $GOPATH, in ~/devel/juju-core. There I can just bzr branch some-branch. at that point you can "bzr switch {target}" from the juju-core in $GOPATH/src/...
<bac> frankban: ah, gotcha.  i'm used to just working in the other workspace
<frankban> bac: yeah the configuration in that doc is cool because you have both the structure go requires ($GOPATH/src/launchpad.net/juju-core) and a real shared repo to work on, given that the former is bound to the real repo as a lightweight checkout. So, basically, $GOPATH/src/launchpad.net/juju-core is just what we usually call "sandbox"
<bac> frankban: right.  i just didn't know you could manually insert a different branch in ~/src/juju-core
<frankban> time to go, have a nice evening
<bac> frankban: wait!
 * frankban waits
<bac> frankban: for joyent are the sdc user/keys the same ones for manta?
<frankban> bac: yes
<bac> ok.  perhaps we can make that clearer in the field descriptions
<bac> or maybe make the manta ones optional and force them to be the same if blank
<frankban> bac: yes, that can be an improvement. FWIW my envs.yamls looks like http://pastebin.ubuntu.com/7199750/
<bac> frankban: if you're still around have you seen this before http://paste.ubuntu.com/7199773/
<kadams54> Makyo, frankban: FYI, updated https://github.com/juju/juju-gui/pull/222 to only pull top-level machines. Also realized I had one commit that didn't get pushed.
<frankban> bac: no, but I guess your previous attempt left something there, and juju-core got confused by the binary change.
<Makyo> kadams54, cool, thanks.  Was having trouble on this comp, switched to Air to find vagrant out of date.  Will switch back.
<bac> frankban: huh.  ok, i'll poke around.  thanks.  won't bug you again.  good night.
<frankban> bac:  you can try "juju destroy-environment joyent -y --force" and check nothing is in ~/.juju/environments/
<rick_h_> kadams54: tossed a few comments in for fun 
<rick_h_> kadams54: which might be out of date now it sounds like
<frankban> bac: cool, there is no rush in landing this branch, so if you are blocked we can take a look at that together tomorrow
<kadams54> rick_h_: yeah, saw those. I caught the constructor one early enough, but will update the tests as requested on the next pass through the code (after another other reviews).
<rick_h_> kadams54: cool
<rick_h_> kadams54: remind me in the call I'll mention how the initializer and some other 'magic' methods work
<hatch> think C classes
<hatch> that's how initializers work :P\\
<kadams54> hatch: I haven't programmed in C since college, over a decade ago :-)
<rick_h_> hatch: right but other things like render and such can be cascaded (at least for widgets/etc)
<hatch> base derrived classes yeah
<hatch> kadams54 haha yeah same here
<kadams54> Yeah, I was thinking that constructors needed to cascade when I wrote that
<kadams54> Then I remembered this is YUI, not plain JS.
<rick_h_> there's a good yuiconf talk on video for how base works 
<kadams54> And this was an initialize method, not a constructor
<kadams54> Hit me with the link
<hatch> rick_h_ kadams54 https://docs.google.com/file/d/0By84yWo_5i6LYXNsdnhHV2Z2TUU  aww yeah C++
<hatch> see that one has a 3.5" floppy on it!
<hatch> lol
<rick_h_> kadams54: https://www.youtube.com/watch?v=_zhQIfT7g58&index=6&list=PLF49A40DA7A11F08A ftw
<kadams54> Woot
<hatch> ohh yeah I remember that talk
<rick_h_> one of my fav yui talks
<hatch> yeah luke is great
<hatch> at smugmug now
<bac> rick_h_: just a heads up, manage.jujucharms.com/heartbeat currently shows an API2 failure.  it is a false positive caused by us currently not featuring any charms, just bundles.
<Makyo> No plumber yet, but we did get our new doors delivered.  Bonus.
<hatch> Makyo might be time to fire this guy
<hatch> :)
<bac> Makyo: so you've had this leak at the meter for weeks now?
<Makyo> Yep.
<bac> yowza
<Makyo> I just got a water bill, actually.
<Makyo> $286.04
<Makyo> https://www.dropbox.com/s/jregju31mdzuuhc/IMG_20140403_130049.jpg
<hatch> ouch!
<hatch> rick_h_ https://github.com/juju/juju-gui/pull/223 WIP 
<hatch> this doesn't have the tests fixed but I'd like some third party input
<Makyo> hatch, ping when you have a second.
<Makyo> Want to get a good ECS card.
<hatch> hmm I'm just cooking lunch atm
<hatch> can we do it in 45mins or are you not doing anything now?
<Makyo> Will do lunch too, finish this review.
<Makyo> 45 mins is fine
<hatch> sounds good
<bac> rick_h_: i'm stuck working with the juju guys trying to get the joyent provider to work.  that's kind of like QA, isn't it?  :)
<rick_h_> bac: hah, sorry catching up
<rick_h_> bac: oh lol for your qa day, yea we'll call it
<hatch> Makyo whenever you're ready, rick_h_  you may want to be part of this discussion as well
<Makyo> hatch, sure
<rick_h_> hatch: rgr
<hatch> creating room
<hatch> https://plus.google.com/hangouts/_/7acpjdgv54v5pnjt0fc9v0snjs?authuser=1&hl=en
<hatch> rick_h_ btw there have been some developments wrt the kernel bits - tonight I'm going to give them a try
<rick_h_> hatch: thanks, let me know how it goes
<hatch> apparently both of us have been installing Ubuntu incorrectly 
<hatch> we need to use EFI mode instead of legacy
<rick_h_> yea, not sure how that happened 
<hatch> yeah I'll definitely keep notes
<rick_h_> didn't really see an 'efi' mode during install from the usb cd
<hatch> yeah neither did I...
<hatch> w00t down to 9 failures
<rick_h_> hatch: that sounds darn right reasonable :)
<hatch> :shipit: amiright?
<rick_h_> and lies
<hatch> oo the tests found a real bug
<hatch> lookatthat
<rick_h_> #so-thats-how-it-works :)
<hatch> haha
<rick_h_> as much I tests are a pita, I so love them when they catch a bug before it lands
<hatch> somhow I deleted three tests and fixed one and still have 8 failures....
<hatch> rick_h_ in test_browser_app.js browser subapp display tree there is a `hits` object
<hatch> why do they default to true?
<hatch> That seems backwards?
<hatch> I feel like I'm missing something
<rick_h_> hatch: k
<rick_h_> hatch: they default to true?
<rick_h_> hatch: there's a 'resetHits() method
<hatch> ohh ok I broke something
<hatch> right
<rick_h_> that gets called in setup and manually for multi dispatch tests
<hatch> right
<hatch> sorry
<hatch> hmm
<hatch> test failures when things work in the real world...not fun
<rick_h_> hatch: let me know if you want another set of eyes
<hatch> thanks but I just skipped the final two because they would need state
<hatch> rick_h_ ok pushed....would be awesome if you could find some time to qa/review
<hatch> keeping in mind the follow-up will be to properly implement the state
<rick_h_> hatch: rgr
<hatch> thanks
<rick_h_> yea, realize the whole 'test and build state' card here didn't get there because of the viewmode removal
<rick_h_> but smaller branches == better
<hatch> yeah agreed
<hatch> I did remove over 1000 lines in total
<hatch> that's awesome lol
<rick_h_> yea, I mean this is good, just time consuming 
<rick_h_> between this and inspector we're paying a price for the better code hopefully
<rick_h_> but let's try not to find anything else to rewrite :)
<hatch> lol is there anythign else?
<rick_h_> shush, you'll send back luck our way
<hatch> haha
<rick_h_> hehe...except I'm not kidding 
<huwshimi> Morning
<rick_h_> morning huwshimi 
<huwshimi> rick_h_: Has our ci broken?
<rick_h_> huwshimi: not that I'm aware of. What's up?
<rick_h_> huwshimi: you had a legit failing test. You replied that it could be removed, but never updated and removed the test
<huwshimi> rick_h_: Well, all the current MPs have builds that have started but not completed.
<rick_h_> huwshimi: I was going to ask what happened yesterday and if there was something that got stuck
<rick_h_> huwshimi: oh heh, yea that's broken
<rick_h_> sec, have to stop
<rick_h_> huwshimi: should be good to go hopefully
<huwshimi> Ah great
<rick_h_> hatch: replies in bound, will start qa
<hatch> thanks I'll take a look
<huwshimi> rick_h_: What should I tackle today? I see kyle is already working on the machine panel tokens...
<rick_h_> huwshimi: he's working on the data, but not the tokens
<rick_h_> bah, he's gone. I thought he would get that landed
<rick_h_> huwshimi: what were you working on yesterday? Is that done then?
<huwshimi> rick_h_: Ah, I thought there were two cards about tokens and now there's only one so I assumed he must have done it. I must have mis-remembered.
<rick_h_> huwshimi: ah well his card says 'using deployed unit token' but it's not ready yet so he's just dumping out text
<rick_h_> huwshimi: so I'd say to start looking at the token I suppose. 
<rick_h_> huwshimi: https://drive.google.com/a/canonical.com/?urp=https://docs.google.com/&pli=1#folders/0B_l975nRB6BuM2p4eTZMSXpWRTQ
<rick_h_> we can go over them during hte call
<huwshimi> rick_h_: That'd be great, thanks!
<rick_h_> hatch: qa notes added
<rick_h_> hatch: I ack that not all are in/for this branch. Just noting things that are broken. 
<hatch> ok cool
<hatch> looking
<hatch> line reflow?
<rick_h_> otp
<hatch> I actually prefer when there isn't one long line and then another word on the next line :)
<rick_h_> hatch: oh yea, well the limit is 79, not 20 and 15
<hatch> limit.....not required :P
<rick_h_> it looks odd imo and breads readability and I bet one or two of those will fit on one line now
<rick_h_> fighting on everything :P
<hatch> hah no it's just going to take me a while to reflow all of these
<rick_h_> open in vim, run gq
<rick_h_> it's one command :)
<hatch> that doesn't require a plugin?
<rick_h_> no, I don't believe it does
<hatch> hmm ok I'll have to download vim
<rick_h_> http://www.methods.co.nz/asciidoc/chunked/ch36.html
<rick_h_> w...t...f doesn't it exist in your virtualmachine?
<hatch> or did you just want me to do those two lines
<rick_h_> ssh, vim xxxx.js
<hatch> not the entire file?
<rick_h_> the cases of those comments 
<hatch> oh ok, then done
<hatch> :)
<rick_h_> some of them jump out as looking stupid so I noted them in review
<hatch> that's an interesting functionality of vim
<hatch> to reflow a line
<rick_h_> very handy when editing blocks of text/comments and emails
<hatch> yeah if you don't use a real client :P
<hatch> rick_h_ so changes are made - I'm not clear on your qa notes, did you want me to fix those things?
<rick_h_> hatch: https://plus.google.com/hangouts/_/calendar/cmljay5oYXJkaW5nQGNhbm9uaWNhbC5jb20.dd77sn7kjl6unba21lutdr0p70?authuser=1
<hatch> is there an aus call?
<hatch> or did I miss it?
<hatch> achievement: Ubuntu 14.04 on MBP
<rick_h_> hatch: missed it, it before you and I talked
<huwshimi> hatch: Did you get all the touch packages installed as well? No idea why I have them...
<hatch> huwshimi I don't know what that is
<hatch> :)
<hatch> every few minutes it pops up with a system error report
<hatch> so it's not really usable 
<huwshimi> hatch: You don't know what Ubuntu Touch is?
<hatch> and I can't actually shut it down outside of the terminal either
<hatch> oh the Ubuntu Touch packages
<hatch> I don't think I got those
<huwshimi> So strange...
<hatch> I have to find where I file bugs
<hatch> the inability to shut down is kind of a big one
<huwshimi> hah
<hatch> switching to wifi
<rick_h_> sudo shutdown -h now
<rick_h_> or per zsh alias 'shut'
<rick_h_> kadams54: hey, around?
<kadams54> I am now :-)_
<rick_h_> kadams54: how's your branch? Is it ready to land? huwshimi is doing some work with the token part that will build on it
<rick_h_> kadams54: I had thought your branch might get in before he got running
<kadams54> Ah, yeahâ¦ let me get that pushed out
<rick_h_> kadams54: ty much
<rick_h_> huwshimi: ^
<kadams54> np
<rick_h_> huwshimi: what did you need to do? Just install the packages mentioned in the bug report?
<huwshimi> kadams54, rick_h_: Brilliant, thankyou!
<huwshimi> rick_h_: Somehow when I upgraded to Trusty it installed all the Ubuntu Touch packages as well.
<rick_h_> huwshimi: hah
<hatch__> huwshimi does it do anything different with those packages?
#juju-gui 2014-04-04
<huwshimi> hatch__: I don't think so, I just have all sorts of apps floating around.
<hatch__> oh heh
<hatch__> well I'd probably pick that over the constant system error report dialogues
<hatch> they are probably because of something apple hardware related heh
<rick_h_> sorry, sent to huwshimi but meant hatch
<rick_h_> hatch: what did you need to do? Just install the packages mentioned in the bug report?
<hatch> rick_h_ I created a livecd using dd but didn't convert the iso, just used dd 
<hatch> then rebooted
<hatch> in rEFInd I picked the usb option which has 'EFI' in the text that popped up
<hatch> then it installed and works.....almost.....like a charm
<hatch> :)
<rick_h_> hatch: from the mac iso?
<hatch> I'll try and put together a blog post tonight, but it was really fast/simple
<hatch> nope used the desktop one
<hatch> the kernel guys use the desktop one they said
<hatch> I'm not really sure what the mac version does considering you can't dl the mac version except for as a daily
<huwshimi> hatch: it has a different boot setup, I think with modern macs you want the standard image
<hatch> huwshimi ahh ok
<hatch> well if it wasn't for these darn system errors....it doesn't even give me the ability to view the error
<hatch> I'll have to figure out how to read these
<hatch> it must store them somewhere
<hatch> I'll also need to investigate multi touch
<hatch> three finger drag doesn't work
<hatch> but two finger scroll does
<hatch> MOAR multitouchy
<hatch> :)
<hatch> rick_h_ more than 900 http://venturebeat.com/2014/04/03/microsoft-azure-portal/ :-)
<hatch> huwshimi are you running on metal or in a vm?
<hatch> I thought you were on a vm
<huwshimi> hatch: Metal. Always have.
<hatch> oh interesting - well you clearly know more than rick_h_  and I because we coudln't get it to run lol
<huwshimi> hatch: Well, I booted from a usb disk and clicked install.
<hatch> lol ok yeah that didn't work for us haha
<hatch> well I'm just happy it works now, bugs and whatnot can be resolved
<hatch> I mean, it's not even released yet hah
<huwshimi> hatch: This has been the smoothest upgrade experience for me in a long time.
<hatch> yeah? That's good, this is an important release for us
<huwshimi> hatch: Not good you're having a bunch of issues two weeks out from release though
<hatch> well...I guess I give them some slack being that brand new apple hardware is probably a little finicky  
<rick_h_> hatch: well I don't have the new dashboard yet I guess. 
<huwshimi> hatch: Oh, you got a new mbp then?
<hatch> huwshimi yeah late 2013 MBP 15"
<huwshimi> Nice!
<hatch> I got all the options but stuck with the 500GB drive
<hatch> $500 more for 1TB was not a good value proposition for me
<hatch> haha
<huwshimi> yeah
<huwshimi> hatch: What's not working?
<hatch> I switched back to OSX now, but it all appears to be working well
<hatch> it feels a little laggy
<hatch> there is a system error for 'something' that keeps poping up every few minutes
<hatch> and I need more multi touchies
<hatch> but other than that it seems to be working well
<hatch> it can even handle the retina screen decently
<hatch> oh and that shutdown bug
<hatch> the laggyness I'm guessing is a driver issue
<huwshimi> hatch: Could be worse.
<hatch> oh yeah I'm not complaining
<hatch> I am a little curious who to get in touch with to get a 'better' video driver if that is what's causing the laggyness
<hatch> and just to be clear, we aren't talking laggy, just not as smooth as osx
<huwshimi> hatch: What driver are you currently using?
<hatch> whichever one came with it
<huwshimi> If you go to System Settings > Software & Updates > Additional Drivers tab, you can install a new driver.
<hatch> oh I just assumed noone would have come out with one yet
<hatch> I'll have to switch back and give it a go
<hatch> :)
<huwshimi> kadams54: Not sure if it's just an old build that's just finished up, but it looks like a couple of lint errors in your branch.
<hatch> now the question is...which irc client to use
<huwshimi> hatch: Were there new drivers?
<hatch> no idea
<hatch> still in osx land
<huwshimi> Ah
<hatch> ok switching
<kadams54> *sigh* bit by the Selenium bug
<rick_h_> kadams54: :(
<rick_h_> huwshimi: do you use something to disable the trackpad when typing?
<huwshimi> rick_h_: Only the checkbox in the Mouse & Touchpad settings
<rick_h_> huwshimi: k
<huwshimi> rick_h_: I don't have tap-to-click on though
<huwshimi> rick_h_: Only the physical press
<rick_h_> ah
<huwshimi> rick_h_: I prefer the physical press
<rick_h_> huwshimi: yea, I hate the force level of the click
<rick_h_> I prefer physical buttons on my thinkpad 
<rick_h_> I must have wimpy fingers and get annoyed with the click sounds too easily :)
<huwshimi> haha
<rick_h_> it is cool to finally have it working on metal though. installing all my normal deps
<rick_h_> should be fun to try out my tiling window manager setup on here and see how it feels with a touchpad
<huwshimi> rick_h_: I just wish I could boot osx as a vm for safari testing.
<rick_h_> huwshimi: yea, I think it's actually possible, but not legal
<rick_h_> ugh, slow repos means installing takes for ever
<kadams54> I dug into the Selenium failure more
<rick_h_> kadams54: yea? we've had runs of this before but seemed selenium based. It's seeming to be an issue starting up the firefox selenium tests. 
<kadams54> It's happening when Selenium gets an HTTP status code between 300  and 304
<kadams54> When that happens, it triggers this line of code:
<kadams54> return self._request('GET', resp.getheader('location'))
<kadams54> It seems like our location header in the response is None
<rick_h_> yea, it's a simple http server. So the question is why is it getting a 300/304? It loads an html file directly without redirect
 * rick_h_ ponders setting up apache on there to proxy these ports out to sauce
<kadams54> http://0.0.0.0:8889/test/index.html
<kadams54> Is that right?
<kadams54> It's port 8888 locally
<rick_h_> right
<rick_h_> no, port 8888 is for the test run
<rick_h_> and 8889 is for the merge run
<kadams54> Ah
<rick_h_> so the two jobs can test/merge different branches at once
<rick_h_> lol, and then npm issue
<rick_h_> kadams54's branch is not meant to land
<rick_h_> CI doesn't like it
<kadams54> :-b
<kadams54> Hmm. 304's for me locally, which makes sense. The code is 300 <= statuscode < 304, so a 304 isn't going to trigger it.
<rick_h_> oh hmm, well 302 is a redirect
<rick_h_> which some things might throw, but I can't see what would do it
<rick_h_> would have to track the network tab and see if anyone throws a 302 redirect for some reason
<kadams54> Ah, yeah
<kadams54> I was only looking at the initial request for index.html
<rick_h_> yea, I wonder if something of the initial deps throws something that it doesn't care for
<kadams54> Well in 3 minutes I'm heading to bed.
<rick_h_> all good, thanks for poking at it some
<kadams54> CI build success or not.
<rick_h_> I should be taking my meds and heading to bed myself
<rick_h_> kadams54: oh yea, it's well past EOD, please don't feel like you have to watch it
<kadams54> Fret not. Catching up on my hulu queue on the big monitor ;-)
<bcsaller> *6
<hatch> huwshimi yeah so a bunch more bugs came up with one critical one that I haven't found a solution for ye
<hatch> t
<rick_h_> chrome is core dumping on me, still installing my base package suite
<rick_h_> and done, time to link configs and reboot and hopefully be close to normal
<rick_h_> other than the fn/ctrl keys and meta/alt keys both being backwards :/
<huwshimi> hatch: Oh, no good
<huwshimi> hatch: Did the sluggish go away?
<hatch> huwshimi well when I try to change any of the drivers and click save it just reverts to the old one
<huwshimi> *ness
<huwshimi> hatch: Oh
<hatch> so because of that i have no wifi
<rick_h_> the only driver I could get was the broadcom one
<rick_h_> there wasn't anything else
<hatch> and there is no network control over VPN
<hatch> other than...
<hatch> rick_h_ you were able to select the broadcom one and it worked?
<hatch> Did it enable wifi?
<rick_h_> hatch: it seems to but I don't have permissions to edit the wifi
<rick_h_> so had to change a group and need to reboot in a sec
<hatch> I also found that unless I boot with the ethernet dongle in then I have no internet because there is no 'Network' control
<hatch> hmm, seems like it's a little unstable still
<rick_h_> yea, something in the hardware has to pick up the dongle on boot to expose it
<rick_h_> ok, reboot time to see how well it all went
<rick_h_> woot, on the wifi and working
<rick_h_> will have to fix these keybindings doh
<hatch> nice I'll have to look into the wifi stuff
<hatch> it's odd that I couldn't change the driver
<rick_h_> oh sucky, you can't remap the fn key as it's not exposed
<rick_h_> $#@$@#
<rick_h_> and chrome still seg's ugh
<hatch> hmm
<hatch> there 'has' to be some way to remap the fn key
<hatch> this keyboard format has been around for so long someone must have written something :)
<rick_h_> no, it's isolated at the hardware level
<rick_h_> it doesn't even show up in xev
<rick_h_> woot, meta/alt keys fixed
<rick_h_> now just have to figure out how to deal without middle click
<hatch> ohh really? I swap it using software in OSX
<rick_h_> hah, can't figure out how to paste the link into this terminal 
<rick_h_> how the $#@$@# do people live without middle click?
<hatch> right click?
<hatch> lol
<hatch> I have never used middle click
<rick_h_> paste.ubuntu.com/7201599/
<rick_h_> fixes my control, meta, and alt keys for me
<rick_h_> well my terminal doesn't have copy/paste commands built into it
<rick_h_> so you just always middle click into it
<rick_h_> I could normally use shift-insert, but no insert key on this keyboard either
<hatch> hmm the only key I actually want to change is the fn and control buttons
<rick_h_> heh, and fn is hardware controlled and you can't change it
<rick_h_> at least not with xmodmap or any normal mapping things I know of
<hatch> yeah I'm just wondering why it can be done in software with windows and osx
<rick_h_> oh maybe it can
<rick_h_> I'm floored it doesn't register in xev, never seen that before
<hatch> KeyRemap4MacBook is what I use to swap them in OSX
<hatch> Windows can apparently use something called Sharp Keys
<hatch> rick_h_ http://cyberdork33.wordpress.com/2008/11/04/swap-fn/ does this mean anything to you?
<rick_h_> I would if I could open it
<rick_h_> I can't middle click the link to auto open in a browser, and can't copy/paste it out lol
<hatch> haha aren't you using gnome-terminal?
<rick_h_> nope, urxvt...
<rick_h_> which is getting painful quick
<hatch> ahh-
<hatch> I'm going ot miss iterm
<rick_h_> I disagree lol
<rick_h_> pos
<hatch> oh right, it has a GUI for settings :P
<rick_h_> right, this is what I was talking about
<rick_h_> you can use this to force the hardware to send FnX by default vs the hardware keys for lights/volume/etc
<rick_h_> but this does not swap the fn key with the ctrl next to it
<hatch> ohh hmm
<hatch> http://askubuntu.com/questions/193529/how-to-swap-between-fn-and-ctrl-keys thinkpads say it's a bios option heh
<rick_h_> yea, what I mean. It's more at a bios level
<rick_h_> hardware that is
<rick_h_> oh hell, can't scroll right with 2-finger scroll?
<hatch> that works for me
<rick_h_> I can scroll up/down but not side to side
<hatch> oh hmm I didn't try that
<hatch> I'm back in OSX land right now
<rick_h_> heh
<hatch> well now how the heck does the keyremap work in osx
<hatch> eventType:keyMod          code:0x3f       name:Fn              flags:Fn                                 misc:characters:    	KeyCode::FN
<hatch> eventType:keyMod          code:0x3f       name:Fn              flags:                                   misc:characters:    	KeyCode::FN
<hatch> that's what it says it's doing
<hatch> http://www.nongnu.org/xbindkeys/xbindkeys.html
<hatch> that's what the keyremap4macbook author suggested
<hatch> not sure if it'll actually work though heh
<bac> frankban: i didn't need to but i re-reviewed your patch.  thanks for the changes.
<frankban> bac: thank you!
<bac> frankban: for your reading pleasure, here is the bug i filed regarding joyent and ssh keys:  bug 1302561
<_mup_> Bug #1302561: Joyent gives decode error on SSH key with passphrase <juju-core:New> <https://launchpad.net/bugs/1302561>
<frankban> bac: cool
 * frankban lunche
<frankban> (s)
<luca___> rick_h_: showed mark the demoâs, he said it looks great :)
<rick_h_> luca___: woot woot
<luca___> :)
<hatch> party...on
<hatch> rick_h_ did you get a chance last night to give http://www.nongnu.org/xbindkeys/xbindkeys.html a go?
<hatch> it looks like it might work using the 0x3f code from KR4MB
<rick_h_> luca___: we're working on the machine view and the representation of the unit, machine, and container in each column
<rick_h_> luca___: so if there's an update from spencers folder of shots we could use that asap
<luca___> rick_h_: the latest can be seen here: https://www.dropbox.com/sh/lvdydgiu7jeuuso/7MlRX5-IPu
<rick_h_> kadams54: ^
<luca___> rick_h_: Iâm in a wrap up meeting at the moment
<rick_h_> luca___: rgr, have fun
<luca___> rick_h_: but Spencer should be free for a call if to talk you through them
<rick_h_> luca___: all good, it'll be an initial stab that's not fully functional so just want to make sure we're closer vs farther
<luca___> ah ok
<luca___> rick_h_: Iâll move the images over to the gdrive and share the link with everyone
<rick_h_> kadams54: so from that, #13 - #18 are the keys to what you're working on
<rick_h_> kadams54: and we should chat, because I'd like to work together on these toksn to share common bits and follow a bit of the charm token pattern we used before that worked well
<hatch> :'(
<kadams54> Yeah, will definitely need pre-impl chat for this
<rick_h_> hatch: why the :'(?
<rick_h_> serious, the charm tokens are some of the most reusable, no problems to us, code in the codebase
<rick_h_> what possible complaint can you have on it?
<rick_h_> kadams54: look through the shots. I'll head back to the house from the coffee shop here and we can chat pre-stand up
<hatch> juuuuuuust jokin
<hatch> my only 'issue' with them is that they should be views
<hatch> but that's just because I don't really know where widgets fit into the ecosystem anymore
<luca___> rick_h_: I shared the MV with juju-gui-listâ¦.is that ok?
<hatch> the other option is to just use a template rendering....I'm not sure there is any 'contained' funcitonality with the machine tokens
<hatch> I could be wrong though
<hatch> well too late now :P
<hatch> ^ luca___  lol
<luca___> hatch: yeah but I canât remember if that just shared mv with people outside of the company....
<hatch> ohh that I'm not sure about
<hatch> is there no way to see inside the groups?
<luca___> I think itâs private
<luca___> hatch: if you click the âmailing listâ link at the bottom of the email it takes you here:
<luca___> hatch: https://launchpad.net/~juju-gui-peeps
<hatch> yeah that's private
<hatch> was....
<hatch> lol
<hatch> oh man.....friday
<jcsackett> hatch: don't you *dare* shit talk the tokens. :)
<hatch> lol
<hatch> hmm the machine view tokens need to be draggable, better make them views
<rick_h_> luca___: sure thing
<rick_h_> luca___: you used peeps?
<luca___> rick_h_: juju-gui-peeps@lists.launchpad.net
<rick_h_> hatch: please join in the call then if you've got architecture ideas
<rick_h_> luca___: that's private and cool
<luca___> rick_h_: nice, had a mini heart attack
<hatch> rick_h_ linky?
<hatch> luca___ haha I hate it when that happens
<rick_h_> kadams54: can you setup a link please?
<kadams54> Yup
<hatch> this almond milk is vile
<luca___> yeah, hatch
<luca___> donât you date bad mouth tokens!
<hatch> #lifestylechange
<hatch> haha
<kadams54> rick_h_: https://plus.google.com/hangouts/_/7acpinhuclebv09kb1or515ac4
<rick_h_> hatch: ^
<hatch> hmm
<hatch> kadams54 it says I'm not allowed to join
<rick_h_> hatch: connect from canonical account
<rick_h_> use a private browser tab if required
<hatch> ahh ok
<rick_h_> jujugui call in 5 kanban please
<rick_h_> jujugui call now
<frankban> rick_h_: we are in https://plus.google.com/hangouts/_/calendar/cmljay5oYXJkaW5nQGNhbm9uaWNhbC5jb20.t3m5giuddiv9epub48d9skdaso
<hatch__> Makyo so how is your coffeescript coming? Are you finding that you're actually more productive with it?
<Makyo> hatch, yeah, I'm liking it.  It feels more expressive.  There's a quirk with order of operations with regards to parens which took some getting used to, but that's about it. Once I started thinking of it as a compiled language, it made sense.
<hatch> innnteresting
<Makyo> It's like working with Java in a way (the concept, not the language).  You write something that compiles down to very succinct byte code.
<hatch> what is this order of operations thing?
<hatch> my google fu is failing me
<Makyo> Parens are optional for function calls, so you can do foo bar, baz and it calls foo with bar and baz as arguments.  But if you have foo(bar(a, b), baz) and try to do foo bar a, b, baz, that reduces to foo(bar(a), b, baz), so if you have function calls as arguments, it's best to just use parens.  It's a language design thing.  Sometimes it's good (I'm looking at you, d3 chaining), but sometimes it increases confusion rather than increasing
<Makyo>  readability.
<hatch> ahhh yeah that would be a tough bug to find too
<hatch> rick_h_ is ~charmers/precise/mysql-9 supposed to work the same as precise/mysql-9 ?
<hatch> at the moment it just gives an empty details tab
<rick_h_> hatch: depends, it may/may not be the same charm
<hatch> oh I thought that for it to be promoted it had to be charmers
<rick_h_> http://bazaar.launchpad.net/~charmers/charms/precise/mysql/trunk/files yea it should because it is a ~charmers branch
<rick_h_> hatch: it's not always true, see the juju-gui promulgated charm
<rick_h_> hatch: the ~charmers rule is ONLY always true for bundles
<hatch> oh ok so it's a bug in....charmworld? 
<hatch> https://manage.jujucharms.com/api/3/charm/~charmers/precise/mysql-38 404s
<rick_h_> hatch: yea, so bug we dont' see much because we intentionally drop the user for promulgated charms
<rick_h_> hatch: feel free to file on charmworld
<hatch> I'm just trying to figure out if I should parse ~charmers out of the url in the GUI
<rick_h_> no, if it's specified by the user then it should be there
<rick_h_> however, internals might do that when generating links using logic
<hatch> ok sounds good, I'll file the charmworld bug then
<Makyo> Woo plumbers
<rick_h_> so links to a promulgated bundles might generate a link without it, but if a user enters it, it's valid
<rick_h_> Makyo: lol
<hatch> yay plumbers!
<hatch> kadams54 wrong G+ account :)
<hatch> that was my work one
<Makyo> This is gonna be ugly.  Oh well.  At least we'll have it fixed.
<rick_h_> Makyo: heh, heavy machinery leaves marks 
<Makyo> Yep.
<Makyo> Also having to run the line in along the ceiling to avoid having to either bore through or tear up the concrete pad.
<Makyo> Unforunately, the studs run the wrong way, so that means outside the drywall.
<rick_h_> Makyo: can you confirm for me which browser returned "" and which one was null?
<hatch> man we have a lot of urls
<rick_h_> Makyo: re: the friday talk for a blog post on it
<rick_h_> hatch: more coming
<Makyo> rick_h_, firefox was null, chrome was ""
<rick_h_> Makyo: ty
<bac> hey jcastro, i'm investigating the discrepancy between your bundles on m.j.c (http://manage.jujucharms.com/search?search_text=bundle%3A+jorge&op=) and on staging (http://staging.jujucharms.com/search?search_text=bundle%3A+jorge&op=)
<bac> jcastro: i assumed the extras on staging were 'stale' ones, removed from launchpad, that were not deleted from staging, but that does not seem to be the case.  any insight?
<rick_h_> jujugui off to dr biab
<kadams54> Makyo, hatch: Just catching up on the coffeescript discussion. We started to write our tests in it on my last job.
<kadams54> Things got much easier once our resident coffeescript expert told me, "Oh yeah, it's kinda of an unwritten convention to just be explicit about parens"
<kadams54> That was the most confusing thing for me: just because Coffeescript allows certain syntactical laziness/shortcuts doesn't mean you should actually use them.
<hatch> so they fixed some javascript oddities and created new ones for kicks
<hatch> lol
<kadams54> I think everything works out once you get a handle on the conventions
<kadams54> I just wish the language had more balls to be opinionated
<hatch> I figure it's going to go away come ES6/7
<rick_h_> <3 python and pep8 pep257, etc
<kadams54> Yup
<kadams54> If you just use the syntax conventions of python, you'll be fine
<kadams54> Except for the whole underscore vs. camelcase thing
<kadams54> DON'T DO THAT IN COFFEESCRIPT!
<kadams54> ;-)
<hatch> lol what?
<kadams54> var my_variable_is_cool
<kadams54> Instead of:
<kadams54> var myVariableIsCool
<kadams54> I told rick_h_ you can always spot python devs writing JS code
<hatch> yep
<hatch> we had many discussions about that when rick_h_ started on the team
<hatch> haha
<hatch> camelCaseForTheWin!
<kadams54> I don't think one is inherently better than the other
<kadams54> I just hate mixing
<kadams54> And camelcase is standard in the JS world
<hatch> yeah it is
<hatch> someone did a study once that proved that snake case was better
<hatch> I think if I'm going to use vim I'll need to remap caps lock to escape
<hatch> switching modes sucks so much reading for escape all the tiome
<hatch> ok we have about 50 different url formats....I think
<hatch> I might have missed some
<kadams54> ?
<hatch> kadams54 which one?
<hatch> I made two statements :)
<kadams54> 50 different URL formatsâ¦ not sure what you mean by that.
<hatch> ohh like /bundle/hadoop/3/demo
<hatch>  /bundle/hadoop/demo
<hatch> ...
<hatch> it wouldn't be as bad if we dropped support for old urls heh
<hatch> but that's not a good idea
<kadams54> Ah
<Makyo> Only took them 10 minutes to knock out the internet.  Record time.
<Makyo> jujugui going to conserve data from tethering and run offline; still have charmworld set up.  Will have phone if you need me.
<hatch> lol
<hatch> cya
<Makyo> Well, no Internet until Tuesday, so no sense in conserving.
<Makyo> Will have to work from the coffee shop Monday anyway.
<hatch> did they put a backhoe through the phone line or something?
<frankban> guihelp: I need two reviews + QA for https://codereview.appspot.com/84630043 (python/quickstart). Some QA steps need compiling the juju-core 1.18 branch. Anyone available?
<frankban> thanks a lot and have a great weekend!
<Makyo> hatch, yeah
<bac> frankban: i can do qa, since i have everything in place from yesterday
<frankban> bac: yeah it would be great, thanks
<bac> jcastro: did you see my question here about an hour ago?
<jcastro> bac, been slammed one sec
<bac> jcastro: no rush, just would like five minutes of your time today, whenever
<jcastro> now is the time!
<jcastro> ok so I keep a bunch of bundles in ~jorge
<jcastro> but all the ones that are important got promoted to ~charmers
<BradCrittenden> jcastro: yeah, but staging and m.j.c show different ones for ~jorge.  so i'm trying to figure out why the difference.  my theory about you deleting them off LP is wrong.
<BradCrittenden> (sorry, i lost connectivity)
<jcastro> I have no clue why they are different, heh
<jcastro> maybe some of them pass proof but some don't?
<hatch> rick_h_ when you return, in your experience did the router parse hashes for you?
<BradCrittenden> jcastro: thanks.  i'll keep looking
<rick_h_> hatch: yea we had to update it to do that
<hatch> rick_h_ alright I didn't think it did it by default
<hatch> thx
<rick_h_> hatch: map jj to esc
<rick_h_> " Maps for jj to act as Esc
<rick_h_> ino jj <esc>
<rick_h_> cno jj <c-c>
<jcastro> Charm school at the top of the hour, The topic is Juju Plugins:  http://ubuntuonair.com, we'll be taking questions in #juju
<hatch> interesting....why jj vs caps?
<rick_h_> hatch: because caps lock is ctrl
<rick_h_> hatch: and because jj is on home row
<rick_h_> and almost never used in real typiung
<rick_h_> typing
<rick_h_> so your hands stay where they already are
<hatch> ahh ok that makes sense
<kadams54> rick_h_: Looking through the Token class, I see some stuff that's charm-specific
<kadams54> _charmIconSetter, utils.determineEntityDataType(cfg) === 'charm', charmIcons attr, etc.
<kadams54> Wondering if the first task should be to refactor Token into something more generic
<hatch> kadams54 imho they are a little too different that the shared parts would be minimal
<hatch> it might be pre optimization 
<kadams54> I can understand that for machines, but deployed units (my card) are basically charms attached to a container/machine, right?
<hatch> hmm those are the ones in the first of the three columns in the machine view?
<hatch> those will need to be expanded to create new machines and whatnot
<hatch> so much more complex than the charm tokens
<kadams54> The first column is undeployed units
<hatch> ohh
<hatch> hmm lemme take a look at the design again
<kadams54> The third column is containers and the units deployed within them
<kadams54> i.e., charms that have been deployed to a specific machine and/or container
<rick_h_> kadams54: no, the token is used here
<rick_h_> just the general idea as a model
<rick_h_> kadams54: no, because unit tokens will have these mix ins for the constraints, machine selector, etc
<rick_h_> I think it's a totally different thing than the charm token which is static, never updates, no new metadata/data entry on it
<hatch> yeah any shared functionality will be minimal
<kadams54> OK. I started off coding up a DeployedUnit class that was based conceptually on Token
<kadams54> Then started to reconsider
<rick_h_> kadams54: and tokens are currently charms/bundles and you'll have many unit tokens for a given service
<kadams54> But sounds like I was on the right trackâ¦
<rick_h_> kadams54: and tokens are widgets and we want to try to use views as they'll give us a nicer event design for this
<rick_h_> kadams54: there's still to look at, getting the right icon, etc
<rick_h_> but the interactions and such will be vastly different and more complicated with one only 'size' or version to be drawn vs many for charm tokens
<kadams54> Yeah, I've spent most of the afternoon perusing through View and Widget docs, as well as watching that Luke Smith presentation
<rick_h_> did that presentation help some?
<rick_h_> as far as designing YUI classes and structure
<kadams54> Yes
<hatch> rick_h_ if you have an inspector open with charm details and you have the relations tab selected AND the code tab selected in the details
<hatch> that's two hashes
<hatch> do we maybe drop the idea of using hashes
<hatch> because they aren't scalable with the multi url story
<rick_h_> hatch: no, we have to have only one hash, so I don't think we support hashes for tabs in the inspector
<rick_h_> hatch: I dont know that the case of tabs in the inspector are as strong a user story
<rick_h_> I can see wanting to show you the code or readme of a charm
<rick_h_> the config tab on a service? there's the config tab in the details. 
<rick_h_> hatch: so I think we keep the existing functionality, wrap it into service details, and skip it on the inspector, what do you think?
<hatch> yeah that's fine - thinking a little further ahead, are there other instances where we would have the charm details open and something else which would require a hash?
<rick_h_> on top of that, it's not something we've supported to date and I don't recall seeing any feature requests for it so far. 
<hatch> thinking of when they have the charm details in the 'sidebar' view
<rick_h_> hatch: yea, we'll have to look into that at that time
<hatch> ok dumb hash parsing it is!
<hatch> *phew*
<rick_h_> yea, if we can support something now that we didn't support before I'm +1 (like charm details tabs and service details tabs)
<rick_h_> but not going to break out back trying to support all things
<rick_h_>  /out/our
<rick_h_> obviously let me know if you find a case where you disagree and we can look into it more
<hatch> yeah I can't think of any beyond the one I mentioned first...but if we drop the inspector hashes then all's good
<rick_h_> hatch: how goes it overall? 
<hatch> good good I'm just trying to write a thing for router to return a request object form a url string
<rick_h_> going to EOD soon, dinner with folks tonight, so let me know if you want to have any chat/etc before the weekend hits
<rick_h_> hatch: can we just use the YUI router code to do that for us? Something already takes the url to req, resp, next
<rick_h_> and we're just messing with the req part
<hatch> you'd think! Nick wrote a method for an old version of YUI that I'm going to repurpose - it still requires the router but the router doesn't have a good access point for that
<hatch> it builds the url all over the darn place
<rick_h_> ah, sucky
<rick_h_> well I could hope :)
<hatch> it has one nice method _getRequest()
<hatch> which unfortunately requires something totally different passed in than a url
<hatch> heh
<rick_h_> well yea, I mean it's just got to be close as the route thing isn't parsing a ton, just the few routes
<rick_h_> so easy enough to hardcode 
<hatch> yeah I have about 50 routes
<hatch> once this is done it'll make testing them super easy
<rick_h_> but the router bit isn't parsing those, the new code will. Mocking YUI router is just the three?
<rick_h_> or am I misunderstanding? the complicated code handling 50 combinations is in the state.loadRequest right?
<hatch> the parseUrl method that I made takes a request object. I need to get from the url to the request object
<rick_h_> right, the request object will be one of 3 routes (ok, with a querystring or hash on it?)
<rick_h_> it seems it should be a huge subset of the 50
<hatch> right, but right now you add a url and a state object to a 'urls' object in the test and it runs through them all
<hatch> super easy to add/remove/modify the tests then
<rick_h_> right, but I'm worried the parsing code is going in the wrong place at the moment. 
<rick_h_> because it's doing more than YUI will do when you put it in place
<hatch> nope the parseUrl takes the request object from the router
<hatch> I just need to get to that request object from the url in the tests
<rick_h_> hatch: call? 
<hatch> yeah sure
<hatch> https://plus.google.com/hangouts/_/76cpir8rpegm2m1llno864gvog?hl=en
<rick_h_> jujugui have a great weekend all. I'm out
<bac> you too rick_h_
<kadams54> seeya
<bac> jujugui: frankban still needs one more review.  i've done the qa.  https://codereview.appspot.com/84630043/
<bac> have a nice weekend
#juju-gui 2014-04-06
<huwshimi> Morning
#juju-gui 2015-03-31
<jcastro> hey rick_h_ https://jujucharms.com/solutions
<jcastro> what's the difference between "solutions" and bundles and charms
<jcastro> is solutions just the sum of bundles and charms?
<rick_h_> jcastro: atm yes, there's still some debate over terminology
<rick_h_> jcastro: so /solutions is the list of promulgated bundles/charms
<rick_h_> jcastro: vs a search
<jcastro> ack
<jcastro> hey I have good news to report
<jcastro> someone told me about a charm and I put in generic terms in google and it totally worked
<hatch> nice!
<rick_h_> jcastro: <3 getting there
#juju-gui 2015-04-03
<lazyPower> Mornin UI Engineering team
<rick_h_> morn
<rick_h_> and good form on the title :)
<rick_h_> lazyPower: actually can you help me with the openstack bundle today sometime?
<lazyPower> rick_h_: i'm working on deploying that now in canonistack
<lazyPower> rick_h_: https://bugs.launchpad.net/juju-quickstart/+bug/1440069
<mup> Bug #1440069: Quickstart fails consistently with canonistack <juju-quickstart:New> <https://launchpad.net/bugs/1440069>
<lazyPower> minor bump in the road
<rick_h_> lazyPower: :( ok will get that looked at but will probably be after the release we're preparing for next monday
<lazyPower> rick_h_: i'm not stressed over it - deployer is working for now
<rick_h_> lazyPower: k, I think it's an easy hack to just mark the fields as not required but will have to dbl check
<frankban> lazyPower: so region and tenant are considered non-optional by quickstart, perhaps they were mandatory in juju before. the fix for that is trivial
<frankban> lazyPower: this is similar to https://bugs.launchpad.net/juju-quickstart/+bug/1437451
<mup> Bug #1437451: quickstart fails on openstack with use-floating-ip missing <landscape> <juju-quickstart:New> <https://launchpad.net/bugs/1437451>
<lazyPower> ah, yes it is.
<rick_h_> frankban: yea, I was going to mark lazyPower's a dupe of that one and copy in the data to make it one bug
<frankban> rick_h_: cool thanks
<frankban> lazyPower: as mentioned, the fix for that is really easy (in quickstart/models/envs.py iirc)
<rick_h_> frankban: will line it up in maint high for a quick update right after the release is rolling and we're set for things there
<lazyPower> rick_h_: so yinz are rolling another release today after the big roll out of apiv4 yesterday?
<rick_h_> lazyPower: that was just the gui release
<rick_h_> lazyPower: monday we'll be doing the whole jujucharms stack updtes
<rick_h_> release week! or weeks
<rick_h_> I guess
<rick_h_> lazyPower: so merged your bug over to https://bugs.launchpad.net/juju-quickstart/+bug/1437451 for tracking purposes
<mup> Bug #1437451: quickstart fails on openstack with use-floating-ip missing <landscape> <juju-quickstart:New> <https://launchpad.net/bugs/1437451>
<lazyPower> ack, i'll track that one
<rick_h_> ty for the report 
<rick_h_> we don't try things on canonistack a ton on our end 
<lazyPower> honestly i dont either
<lazyPower> today is the first in many months
<lazyPower> rick_h_: confirmation on your email - i can help with this.
<lazyPower> let me wrap up my pod standup and i'll reach out. do you need this sooner rather than later?
<rick_h_> lazyPower: we can update the url in our codebase today but need it there before the release hits or we'll have broken new urls
<rick_h_> lazyPower: so today or monday would be great, might be able to go to tues thb
<rick_h_> tbh
<lazyPower> ack
<marcoceppi_> so
<marcoceppi_> can we package libmacaroons0, python-macaroons and libsodum13 (and python-theblues) in ppa:juju/stable ?
<marcoceppi_> otherwise I can't update charm-tools, amulet, etc
<marcoceppi_> this also is a real damper on this for charm-tools on OSX and Windows
<rick_h_> marcoceppi_: yea, the deb packaging is on our todo list but we've not added those yet
<jrwren> we have all of those.
<rick_h_> marcoceppi_: because of the compiled builds?
<jrwren> they are in our ppa
<rick_h_> jrwren: we packaged theblues python library ?
<marcoceppi_> right, query is to put them in ppa:juju/stable
 * rick_h_ looks
<rick_h_> marcoceppi_: yes, we'll get them there. 
<jrwren> rick_h_: oh, maybe not python-theblues. I missed the parenthesized package.
<marcoceppi_> rick_h_: well "pip install charm-tools" won't work on Windows as it does now
<rick_h_> jrwren: right, we've got packaging to do on the python lib that we've not done yet. We're trying to get folks what we have early vs waiting until it's all done and getting them less time
<marcoceppi_> because macaroons I assume
<rick_h_> marcoceppi_: right, it's based on a wrapper for C macaroons lib
<jrwren> sounds like a good good friday task :)
<rick_h_> marcoceppi_: we'll have to look into what we can do on that end. 
<marcoceppi_> so windows isn't that hard I guess, I'll just throw it in the MSI
<rick_h_> jrwren: heh, well release prep is already our friday task :)
<rick_h_> marcoceppi_: feel free to file bugs on the issue tracker for whatever you need and we'll work to get them addressed as we can
<marcoceppi_> I'll see what we can do with OSX, it's sad this breaks pip installability for any tool using the API
<marcoceppi_> rick_h_: sure, but wanted to discuss. Are macaroons really required for anonymous access to CS?
<rick_h_> marcoceppi_: not for anonymous access but as we move to acls and such it'll be required for much of things coming down the pipe
<rick_h_> marcoceppi_: and it'll be required to upload charms
<rick_h_> marcoceppi_: to auth who you are and to upload new versions of your charm/bundle/etc
<marcoceppi_> damn
<marcoceppi_> okay
<marcoceppi_> good to know
<rick_h_> marcoceppi_: happy to help work on solutions there including providing builds/etc for whatever we need. much like we have juju osx builds we can head that route
<rick_h_> marcoceppi_: and can help do things like brew-install-able?
<marcoceppi_> making it a brew target would be good, I'll spend some time working through which would make charm-tools lib easiest
<marcoceppi_> (and open bugs) thanks o/
<rick_h_> marcoceppi_: sure thing, sorry to make life harder there
<marcoceppi_> the future is never easy
<rick_h_> it's shiny though :) 
<marcoceppi_> It does seem nice from what I've read through so far
<marcoceppi_> thanks for publishing/creating it!
<rick_h_> no problem and like I said, let us know how we can make life suck less. We're not done yet and really happy to help make this stuff useful
<lazyPower> rick_h_: do we know if the charm store will ingest the newer series that are coming, centos/windows2012r2/et-al?
<lazyPower> rick_h_: reason i ask - cloudbase has pushed their nova-hyperv charm and its not ingesting afaict  - https://code.launchpad.net/~gabriel-samfira/charms/win2012hvr2/nova-hyperv-charm/trunk
<rick_h_> lazyPower: good question, I do not thing it will because it's tied to charmworld atm and charmworld is using a hard coded list if I recall
<rick_h_> lazyPower: so that will require an update and a release to charmworld to retify and we'll also ahve to invistigate the charmstore
<rick_h_> lazyPower: will file bugs and start to investigate but will be next week 
<lazyPower> ok, i know that we're starting to work with cloudbase and the new series - it would be good to roll alexpilotti and gsamfira into this convo as this directly affects his team
<lazyPower> s/his/their
<rick_h_> lazyPower: did you want to start an email then and copy myself and urulama in please?
<lazyPower> sure can, let me do that now
<rick_h_> lazyPower: as we'd like to ask what series to expect coming down the pipe and such
<alexpilotti> lazyPower: o/
<rick_h_> lazyPower: and can reply with the bugs we create so they can track our progress and such
<urulama> lazyPower: looking
<lazyPower> ok, email deployed even though everyone responded here
<rick_h_> urulama: adding cards/bugs to both charmstore and charmworld for us to track what needs to be updated to support whatever list we get from them. 
<rick_h_> lazyPower: all good
<rick_h_> paper trails and transparency ftw
<gsamfira> rick_h_: heya :)
<rick_h_> gsamfira: howdy :)
<gsamfira> rick_h_: off the top of my head, the following series should be expected: https://github.com/juju/juju/blob/master/version/supportedseries.go#L52-L59
<rick_h_> gsamfira: ooh, nice list ty kindly
<gsamfira> also, there is a high chance that debian jessie will also be supported
<gsamfira> so you can also add "jessie" to the list :D
<gsamfira> : my pleasure
<rick_h_> gsamfira: k, well we've got a legacy system we're working to deprecate that has a hard coded list. I'm pretty sure we'll be more flexible coming soonish but that works for now. 
<gsamfira> rick_h_: sweet :D
<rick_h_> ok, ftr https://bugs.launchpad.net/charmworld/+bug/1440139 and https://github.com/juju/charmstore/issues/343 for the two systems and will make sure we indicate progress/etc on those bugs
<mup> Bug #1440139: verify charmworld will ingest new series  <charmworld:Triaged> <https://launchpad.net/bugs/1440139>
<rick_h_> lp|away: bah you can't run from me! :P
<urulama> gsamfira: thanks for offering help, we already have a solution, so once it is properly tested, it'll land. might happen soon ;)
<urulama> gsamfira: the common package solution sgtm!
<gsamfira> urulama: awesome! Seeing our charms in the store will be amazing!
<gsamfira> we've been waiting to get to this point ever since we did the PoC last year in Atlanta :D
<rick_h_> gsamfira: very cool. Please feel free to hit us up for anything that hits the charmstore early so we can get things in ahead of time. We watch the commits to core but sometimes things that we need to care about slips by. 
<rick_h_> gsamfira: don't hesitate to bug us if you think we might get in the way :)
<gsamfira> rick_h_: many thanks! :D 
<lp|away> rick_h_: oh i haven't run away
<lp|away> just in and out :) whats up?
<rick_h_> lp|away: well now I forgot :P
 * lp|away snaps
<lp|away> i bet it comes to you later while we're on holiday. Tricky passin thoughts as they are.
<urulama> gsamfira: in case you're still around ... http://www.jujugui.org/q/hyperv
<urulama> gsamfira: or http://www.jujugui.org/u/gabriel-samfira/nova-hyperv-charm/win2012hvr2/0
<urulama> gsamfira: (this is our QA MAAS server, but gives you a glimpse that your charm will be visible in next release)
<stokachu> rick_h_: is there a non versioned api url for retrieving https://api.jujucharms.com/charmstore/v4/~landscape/bundle/landscape-dense-maas/archive/bundle.yaml
<stokachu> rick_h_: im wanting to pull down a fresh copy of that bundle to pass to juju deployer but didn't want to keep updating the package is that api version would change how i get to the file
<stokachu> *if that api version*
#juju-gui 2015-04-04
<rick_h_> stokachu: around?
<stokachu> rick_h_: hey
<rick_h_> stokachu: sorry, wifi acting up and laggy
<rick_h_> stokachu: just heads up, will reply to the bug, really intresting 
<rick_h_> stokachu: are you or anyone in your area in nuremberg?
<stokachu> rick_h_: nah closest is london
<rick_h_> stokachu: as it's something I'd like to chat/hash out some more
<rick_h_> stokachu: ok, well will start a conversation in the bug but might be worth setting up something more face to face on the whole idea 
<rick_h_> more long term
<stokachu> rick_h_: ok, whats the bug number again?
 * stokachu being lazy
<rick_h_> stokachu: 1440228
<stokachu> rick_h_: ah yea was talking to david about that earlier
<stokachu> rick_h_: though did you mean to mark it invalid?
<rick_h_> stokachu: yea, but let me write up my giant reply
<stokachu> rick_h_: ok cool
<rick_h_> stokachu: basically I was ping'ing to warn "yes I'm marking invalid atm on the juju-gui, but interesting idea and let's start a conversation"
<stokachu> rick_h_: cool man sounds good
<rick_h_> and curious if I should setup a session in nuremberg on this some more 
<rick_h_> or if we should chat via email, a list, or something else
<rick_h_> anyway, conversation starting, ty for the bug because it's an important idea. 
<stokachu> rick_h_: cool once you reply ill provide some more context where this came up
<rick_h_> stokachu: ok, on the way
<stokachu> cool thanks
<rick_h_> stokachu: feel free to move to an email on the juju or canonical-juju lists if you want to open it up more or just myself if you think I'm nuts
<stokachu> haha ok
<stokachu> rick_h_: cool i like those approaches
<stokachu> rick_h_: i updated the bug with some more information
<rick_h_> stokachu: sounds good
<stokachu> thanks
<rick_h_> stokachu: and we can help file bugs/facilitate tooling updates to charm tools that provides charm get command
<rick_h_> stokachu: and we're working with core on bundles in core so we'll bring this into that conversation/specs that are being worked on
<stokachu> rick_h_: cool that'll be awesome
<stokachu> ill take a look at charm tools while that work is going on
<rick_h_> marcoceppi_: https://github.com/juju/charm-tools can't be the latest charm-tools?
<rick_h_> stokachu: https://launchpad.net/charm-tools looks later
<stokachu> ok looking at that now
<rick_h_> stokachu: the interesting part for supporting bundle get is http://bazaar.launchpad.net/~charm-toolers/charm-tools/1.6/view/head:/charmtools/get.py
<marcoceppi_> rick_h_: it's not, charm-tools is hosted on lp
<marcoceppi_> I guess we should probably move it to lp eventually
#juju-gui 2016-04-07
<freak_> i have deployed juju-gui and also expose it..but when i type watch juju status i get this outputn: http://paste.ubuntu.com/15667891/
<freak_> anyone please help
<rick_h_> freak_: seems like it's still going. 
<rick_h_> freak_: if it hung for some reason would have to peek at the logs by juju ssh juju-gui/0
<rick_h_> freak_: and then checking out /var/log/juju/unit-XXXXX where the XXXX is the unit log for the juju gui unit 0
<urulama|eod> rick_h_, freak_: it looks like machine is in error state ... 
<rick_h_> urulama|eod: oh doh, yea. 
<rick_h_> freak_: can you run juju status --format=yaml ?
<rick_h_> freak_: this is juju 2.0? 
<freak_> yes juju2.0
<rick_h_> freak_: on which cloud?
<freak_> machine state is in error
<freak_> local.maas
<freak_> local.maas cloud
<rick_h_> freak_: which version of maas?
<freak_> output of juju status --format=yaml is http://paste.ubuntu.com/15668019/
<freak_> can you tell me where this yaml file is located whose output its showing
<rick_h_> freak_: it's generated yaml
<rick_h_> freak_: so not a file on disk there
<freak_> MAAS version 1.9.0+bzr4533-0ubuntu1~trusty1
<rick_h_> freak_: are any of the nodes in the 'ready' state?
<rick_h_> freak_: it looks like the maas has no nodes in the ready state and off for Juju to take from the pool of nodes?
<freak_> I have 1 node in deployed state which is bootstrap node 
<freak_> i want juju-gui to be colocated with bootstrap node
<rick_h_> freak_: did you deploy it with --to:0 ?
<freak_> i had only 1 node in the pool so thats why i did not added --to=0 
<rick_h_> right, but the bootstrap node is machine 0
<rick_h_> so the --to:0 will put it on that machine #0
<freak_> so how can i revert the deployment
<rick_h_> juju destroy-service juju-gui
<freak_> when i run command destroy-service   it shows error http://paste.ubuntu.com/15668159/
<freak_> dear rick_h i destroyed juju-gui
<freak_> and deployed again
<freak_> now below is the state http://paste.ubuntu.com/15668222/
<rick_h_> freak_: it's just --to=0 I think
<freak_> is it --to=0 or --to:0
<rick_h_> sorry, =0 or --to 0
<freak_> in the start i did --to=0 this is the output http://paste.ubuntu.com/15668288/
<freak_> my machine name in maas is node0.maas
<rick_h_> freak_: sorry, I see what's up. so machine 0 is only in the admin model. You're in the default which is meant to be the place to work on things so you can destroy-model
<rick_h_> freak_: so to deploy to the bootstrap machine, machine 0, you have to be in the admin model
<rick_h_> freak_: so I think it might be worth doing a 
<rick_h_> juju switch admin
<rick_h_> juju destroy-model default
<rick_h_> and then if you want it all on one machine you'll have to use the admin model, though it's tough because you can't remove that model without destroying the controller and rebootstrapping
<freak_> rick_h  now this is the status after switching to admin http://paste.ubuntu.com/15668416/
<freak_> now how can i access the juju in my browser
<freak_> rick_h i want to change my public address in yaml file ..how can i change that
<freak_> i can only see that through juju status --format=yaml
<rick_h_> freak_: that IP is assigned from MAAS i believe. You can't go in and change it as it's the IP the machine has
<freak_> dear rick_h   check this http://paste.ubuntu.com/15668791/
<freak_> my public ip is in unresolved endpoints can this be the reason
<freak_> because in browser 192.168.6.193/JUJU doesn't open
<rick_h_> freak_: so if you go to https://192.168.6.193/ you don't get the GUI/
<rick_h_> freak_: ?
<freak_> no
<rick_h_> freak_: do you get a 404 or 500 or ?
<freak_> when i type 192.168.6.193 in browser it ask for username and password
<freak_> i opened file accounts.yaml
<freak_> and used that username and password
<rick_h_> freak_: ah ok, but on that form in text at the bottom shold be a juju command to get your password for the GUI
<urulama> freak_: you should do "juju show-controller --show-passwords" 
<hatch> hello
<freak_> http://paste.ubuntu.com/15668875/
<freak_> rick_h this is the output http://paste.ubuntu.com/15668875/
<freak_> i used the admin@local and password mentioned in this url
<hatch> freak_: when you entered those credentials did you get in?
<freak_> no it does loading and again show prompt for username password
<hatch> does it say the username and password is invalid?
<freak_> no it does not say invalid password or username
<freak_> it simple do some loading and then again show prompt for username and password
<hatch> ok that's quite odd, are there any console errors?
<hatch> when you say prompt do you see a page which says "Juju" on it, or is this a browser authentication input?
<freak_> its browser authentication input which says your connection to this site is not private and then ask for username and password
<hatch> ok that's not provided by the gui
<rick_h_> hatch: I think it might be http access to the state server or something. 
<hatch> I am not sure where that's comign from
<rick_h_> hatch: this is deployed on machine 0 in juju 2.0
<hatch> into the admin model? That doesn't work 
<hatch> at least it didn't for me yesterday on tip
<freak_> i'm in admin model
<rick_h_> hatch: ok, can you help him get the gui in 2.0 installed them as an alternative so the juju gui command runs properly?
<rick_h_> freak_: what version of juju are you on exactly? juju --version
<freak_> juju version 2.0-beta3-trusty-amd64
<hatch> alright so for some reason on that version installing to the admin model doesn't work
<hatch> if you run `juju list-models` you will see two models
<hatch> `juju switch default`
<hatch> then deploy the gui to that one
<hatch> `juju deploy juju-gui`
<freak_> so how to resolve that ..earlier i was in default ....and that was not working machine was in admin and it was not deploying juju-gui
<rick_h_> hatch: he has one machine on maas
<rick_h_> hatch: and so we removed default and used admin
<hatch> oh..I didn't know maas worked with one machine 
<hatch> hah, learn something new every day
<hatch> anyways
<hatch> hmm
<hatch> I unfortunately haven't had enough time to investigate why it won't deploy to admin
<rick_h_> hatch: so the question is can you get him a working juju gui command on beta3 please
<hatch> that is the question...
<freak_> actually hatch situation is like that we have one machine which is the bootstrap node we want juju-gui on same machine colocated
<rick_h_> hatch: I thought the upgrade-gui command worked in beta3 with the tarball
<hatch> I didn't think it landed until beta4
<hatch> things are in heavy flux right now, hard to keep all the pieces straight :)
<hatch> there are only like 30 developers landing code every day ;)
<hatch> freak_: sorry, I'm just thinking about how this could work for you
<freak_> hatch whenever i'm in admin my machine state is error  when i issue command juju status
<hatch> freak_: in a little bit here this will be a non-issue as juju 2 will ship with a gui by default :) Right now I'm just waiting for a response from another dev about this issue
<freak_> but when i move to admin machine status changesto started
<hatch> yeah I'm actually not sure if maas and juju 2 work with only a single machine
<hatch> I really have no idea, never tried it
<hatch> I had just assumed not
<freak_> no i think you misunderstood, i have 3 machines 1 is region controller , 2nd is cluster controller and 3rd is the node which i have bootstrapped for juju
<freak_> and on node 3 i'm colocating juju-gui
<hatch> ohh
<freak_> so actually under cluster controller we have pool of machines in pool i have added only 1 node
<freak_> and on that i boot strapped JUJU and want to colocate juju-gui
<hatch> right alright, let me spin up juju 2 and see if I can deploy to admin 0
<hatch> you might be just in a wierd time of flux :) 
<freak_> http://paste.ubuntu.com/15669492/
<freak_> may be this will help http://paste.ubuntu.com/15669492/
<hatch> freak_: yeah the gui isn't actually installed
<hatch> "theres your problem!"
<hatch> ;)
<hatch> but I'm actually trying to figure out why for you first
<freak_> no i destroyed the service juju-gui
<freak_> and then deploy it again and expose
<freak_> and share log with you
<hatch> oh ok
<freak_> still i cannot access gui through ip 
<hatch> does it still say it's "Waiting for agent initialization to finish"
<freak_> yes
<hatch> yeah so it's not done installing, and I"m pretty sure it's hanging
<hatch> my new model just came up and am deploying the gui
<hatch> I'll know shortly
<freak_> ok
<hatch> freak_: ok so it looks like that issue has been resolved in juju tip
<hatch> with tip I'm able to deploy the gui properly into machine 0 in the admin model
<hatch> how familiar are you with golang? :)
<freak_> no, and also don't know what is juju tip
<freak_> can you explain juju tip
<hatch> tip, head, trunk :) where everyone is landing code
<hatch> basically to fix the issue you're running into you need to either a) not use the admin model or b) build juju from source 
<hatch> or c) wait until the next beta is released
<hatch> but c is the least fun
<freak_> but when i do not use admin mode my machine status is error
<hatch> yeah I'm not sure about that, that's beyond my expertise 
<freak_> could you please guide me how to build that juju tip ?
<freak_> you are referring to and exactly what procedure did you follow to build the juju tip that you just built ? 
<hatch> if you're not familiar with the golang flow it's going to be a long process
<freak_> could you please share it ? appreciate the help
<hatch> your best bet might be to ask in #juju about what might be going wrong with your other machines 
<freak_> Also, would Beta 4 address this issue ? If yes, then can you share the ppa/repository to install that
<hatch> and if that doesn't work out then you might just be in a broken spot and will need to revert back to juju 1.25
<hatch> beta 4 can only be built from source right now
<freak_> ok.thanks for support
<freak_> its better that i should revert to 1.25
<hatch> yeah 1.25 works really well, juju 2.0 is _really_ close to a stable release :) but not quite yet and it seems like you hit one of the rare edge cases
<freak_> any approximate or wild guess about the expected date of release ?
<hatch> it'll be coming out with the xenial release
<hatch> so I think that's April 21
<freak_> thanks for help a great deal. Appreciate it ! 
<freak_> have a good one !
<freak_> see you around 
<hatch> no problem, have a good day!
<urulama> freak_: beta4 is just around the corner, it'll be out next week. the PPA to use, check out this page https://jujucharms.com/docs/devel/reference-releases#development
<urulama> freak_: and that one will also include gui, so you'll just run "juju gui" and that's it, no need to deploy gui charm anymore
#juju-gui 2016-04-08
<wenbscholar> hatch are you around here ?
<freak_> hi everyone
<freak_> i'm facing issue regarding juju2.0 beta 3.. i have installed juju-gui but when i open it in browser it demands password and a note is written below on the page to check environments.yaml
<freak_> in juju2 there is no environments.yaml
<freak_> username is already filled as user-admin
<frankban> freak_: that seems like an old juju-gui version
<freak_> i have installed juju-gui from this charm cs:~hazmat/trusty/juju-gui-2 
<frankban> freak_: in juju2 you can find your credentials with "juju show-controller --show-password"
<frankban> freak_: that's very old
<frankban> freak_: juju deploy juju-gui
<frankban> freak_: most recent revision is 52
<frankban> freak_: https://jujucharms.com/juju-gui/trusty/52
<freak_> i tried that yesterday but it gets struck in Waiting for agent initialization to finish
<frankban> freak_: that seems more a juju message while bootstrapping, not charm related
<frankban> freak_: the GUi works with juju 2 only starting from version 2.1.0, so you'll need one of the recent releases
<freak_> but in cs:~hazmat/trusty/juju-gui-2 charm it does not struck and go through.....issue is that its the older version
<frankban> freak_: now that you have a controller up and running, you can try installing the new GUI, like "juju deploy juju-gui new-gui" and see if that works. if it works, you can destroy-service on the old one
<freak_> doesn't work this one also struck in Waiting for agent initialization to finish         
<freak_> finally guys all issues resolved. Now running JUJU 1.25 and GUI also running .. Thanks rick_h, hatch, frankban for your support
#juju-gui 2016-04-09
<freak_> i'm facing an issue ..i have deployed and exposed mysql and wordpress.. but wordpress not getting public address
<freak_> in juju status against public address: node0.maas is written.....although same thing is written in juju-gui public address
<freak_> and i can access juju-gui
<freak_> it means its resolving names
<freak_> anyone here please help me... upon exposing wordpress its not getting tcp port 80..infact not getting any open port
<freak_> any way out
<freak_> ?
<webscholar> I have installed wordpress and mysql, created the relation ship also but wordpress is not accessible in the browser 
<webscholar> Any one can help me in this regard
<webscholar> There is no public IP allocated in the juju
<webscholar> here is the juju status
<webscholar> wordpress:     charm: cs:trusty/wordpress-4     exposed: true     service-status:       current: unknown       since: 09 Apr 2016 16:09:15+05:00     relations:       db:       - mysql       loadbalancer:       - wordpress     units:       wordpress/2:         workload-status:           current: unknown           since: 09 Apr 2016 16:09:15+05:00         agent-status:           current: idle           since: 09 Apr 2016 18:20:10+
<webscholar> http://paste.ubuntu.com/15711942/
#juju-gui 2017-04-09
<saaj> hi
#juju-gui 2018-04-05
<fabrice> oin #webops
<jujaju> juju.cmd.juju.commands bootstrap.go:528 failed to bootstrap model: subprocess encountered error code 1
<jujaju> sweet - solution (this time) was sudo ufw disable
<jujaju> Tried disabling the firewall yesterday but to no avail juju was still seeing bad security certs from localhost ip:port
<jujaju> ended up nuking lxd and juju to try and start over instead of fixing the configs
