#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://(854)847-3108: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
{'channel': 'juju-gui', 'month': 4}