| Makyo | Fiiiiinally unbrincked the tablet. | 01:49 |
|---|---|---|
| Makyo | er.. unbricked | 01:49 |
| rick_h_ | Makyo: yay | 01:52 |
| Makyo | Of course, now it's running Android, so...lets hope the next flash doesn't do the same :o) | 01:52 |
| Makyo | I gained a nose, apparently. | 01:52 |
| rick_h_ | any time you see a UI it's a good thing | 01:53 |
| Makyo | Yeah, seriously. Anything but just plain black D: | 01:53 |
| rick_h_ | sometimes having to go through POST and Grub is comforting stuff :) | 01:53 |
| Makyo | Yeah. | 01:53 |
| 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. | 01:54 |
| Makyo | Good because none of them were mine, I guess. | 01:54 |
| Makyo | Enough computer. Until tomorrow o/ | 01:55 |
| rick_h_ | party on | 01:55 |
| 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]" | 10:49 |
| rogpeppe | frankban: that sounds right, yes. | 10:50 |
| 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 | 10:51 |
| frankban | rogpeppe: cool, thanks. IC, roleOrder ah! any idea about reintroducing the status in the unitInfo? | 10:54 |
| rogpeppe | frankban: it's happening, although delayed because i've been trying to diagnose a runtime bug. | 10:55 |
| frankban | rogpeppe: great, thanks | 10:55 |
| frankban | rogpeppe: anyway, nice change re relation key, much better than "relation-000000X". | 10:56 |
| BradCrittenden | guihelp: does anyone understand this card "Expose service config information via Go API" | 13:05 |
| === BradCrittenden is now known as bac | ||
| bac | it looks surprisingly like 'juju get svc' but that command is already in the Go API | 13:06 |
| bac | and there is no corresponding bug | 13:06 |
| teknico | bac, the card description seems very clear | 13:07 |
| teknico | bac, totally white, actually ;-) | 13:07 |
| bac | teknico: you're very helpful, as usual. :) | 13:09 |
| teknico | ain't I? ;-) | 13:09 |
| bac | benji: i see you created that card. got any extra info? | 13:11 |
| benji | bac: I haven't looked at it much yet. It either needs to be an RPC call or a new watcher | 13:13 |
| benji | I've been up sick all night so I'm afraid I'm not going to be around today. | 13:13 |
| bac | benji: but how does it differ from 'get'? | 13:13 |
| bac | benji: oh, ok. sorry you aren't well | 13:13 |
| frankban | bac: could you please take a look at https://codereview.appspot.com/8406044 ? | 13:23 |
| rick_h_ | anyone up for a looking over a bunch of html/css :) https://codereview.appspot.com/8412043/ | 13:28 |
| bac | frankban: sure | 13:45 |
| frankban | bac: thanks | 13:45 |
| 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 | 13:47 |
| hatch | morning | 14:00 |
| bac | frankban: i'm looking but this code is unfamiliar so i'm going slow | 14:04 |
| bac | hi hatch | 14:04 |
| * hatch is frustrated with this code | 14:05 | |
| frankban | bac: yes, that's a new module, we can make a call if you want to. | 14:05 |
| bac | thanks but not yet needed | 14:06 |
| bac | frankban: why did instance_state go away? is that unrelated to this branch? | 14:16 |
| 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 | 14:18 |
| bac | frankban: ok, cool. | 14:19 |
| bac | frankban: reviewed | 14:19 |
| frankban | bac: great, thanks | 14:20 |
| Makyo | jujugui call in 2 | 14:58 |
| bcsaller | after the call a review of https://codereview.appspot.com/8358045/ will clear 4 cards | 15:01 |
| Makyo | rick_h_, jovan2 luca__ call in guichat | 15:02 |
| hatch | rick_h_: I think at one point yuidoc required the leading * | 15:31 |
| hatch | that's why most of their code has that | 15:31 |
| rick_h_ | hatch: yea, and those files i linked the one without the * ends with **/ | 15:32 |
| 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 | 15:32 |
| hatch | I used to do the * preceeding but got lazy and thats when I stopped :D | 15:32 |
| hatch | lol | 15:32 |
| rick_h_ | editor does it for me, I'm lazy | 15:32 |
| rick_h_ | just trained my dog well :) | 15:32 |
| hatch | haha - right now switching between osx/ubuntu multiple times in the day is killing my finger memory | 15:34 |
| hatch | unfortunately I have to pay to get my garage roof redone so no new laptop for me | 15:34 |
| hatch | :/ | 15:34 |
| Makyo | Booo | 15:37 |
| hatch | yeah it's $3500 and I worked it out to be about $2000 in materials | 15:38 |
| 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 | 15:38 |
| hatch | lol | 15:38 |
| hatch | home ownership....pffffft | 15:39 |
| Makyo | Haha, yeah | 15:39 |
| Makyo | Prefer blog post or email for the meeting summary? | 15:40 |
| hatch | 15:40 | |
| hatch | bcsaller: the relation response object includes a relation id, interface, and scope - any idea how these are defined? | 15:51 |
| bcsaller | hatch: let me see if I can find you a good reference | 15:51 |
| hatch | thanks | 15:51 |
| hatch | I notice the relation model has them | 15:52 |
| 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 | 15:53 |
| hatch | alright thanks | 15:53 |
| bcsaller | hatch: if you need more info let me know | 15:53 |
| hatch | bcsaller: is there any objection to me storing the charm data in the service model? | 16:51 |
| hatch | to build out the relation response I need the information under 'requires' in the charm | 16:51 |
| bcsaller | hatch: we have the charm for the metadata and the relation object holds the endpoints | 16:51 |
| bcsaller | you don't need to change the models as they already satisfy the use case with real jujus | 16:52 |
| hatch | got a sec for a guichat? | 16:53 |
| bcsaller | I think what we'll need are a few helper methods in fakebackend to assemble this and make the checks | 16:53 |
| bcsaller | I do | 16:53 |
| frankban | bye all, have a nice weekend! | 17:08 |
| hatch | cya frankban | 17:12 |
| hatch | you too | 17:12 |
| hatch | bcsaller: in this charm json data I don't see anything specifying weather it is a slave client or peet | 17:34 |
| hatch | per | 17:34 |
| hatch | peer | 17:34 |
| hatch | any idea how that is determined? | 17:34 |
| bcsaller | hatch: http://jujucharms.com/charms/precise/mysql/json look at provides and requires, those are translated to server and client respectively | 17:35 |
| hatch | ahh that's what I was thinking but wasn't sure | 17:35 |
| hatch | thx | 17:35 |
| bcsaller | http://jujucharms.com/charms/precise/wordpress/json is a better example | 17:36 |
| bcsaller | peer is a much less common relationship type | 17:36 |
| hatch | ahh ok, so a charm can't provide and require? | 17:38 |
| hatch | or it can | 17:38 |
| hatch | nm | 17:38 |
| hatch | I spoke too soon :) | 17:38 |
| 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? | 17:49 |
| hatch | ^ jujugui | 17:49 |
| bcsaller | If I understandd what you mean I leave them close till something else needs them, then into a util module | 17:49 |
| hatch | sounds like a plan | 17:50 |
| hatch | bcsaller: ok one more :) relation_id is this some arbitrary id for the relation? | 17:58 |
| bcsaller | hatch: yes, its a unique id | 17:59 |
| hatch | (Y) | 17:59 |
| bcsaller | hooks sometimes need to be able to know specifically what they are interacting with | 18:00 |
| bcsaller | we can just use a monotonically increasing number | 18:00 |
| hatch | this.db.relations.size() + 1 | 18:01 |
| hatch | ok? | 18:01 |
| hatch | axe that I'll make it 0 indexed | 18:01 |
| hatch | this.db.relations.size() | 18:01 |
| hatch | :) | 18:01 |
| bcsaller | hatch: not size, things could be removed and the number could be reused | 18:02 |
| hatch | oh right | 18:02 |
| bcsaller | not that it would break anything with fakebackend, but still :) | 18:03 |
| hatch | this relation code started out being so simple....then you informed me of all the work it actually has to do :P | 18:06 |
| Makyo | ignorance === bliss | 18:35 |
| 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? | 18:38 |
| _mup_ | Bug #1164593: GUI hangs on the service detail view <juju-gui:In Progress by bac> < https://launchpad.net/bugs/1164593 > | 18:38 |
| hatch | bac: I wasn't able to reproduce that either | 18:38 |
| hatch | sorry I forgot to mention on the ticket | 18:38 |
| bac | hatch: ok, i'll make a note and use your name in vain | 18:38 |
| bcsaller | bac: I suspect you already fixed it with the endpoint map fix, I think it was dying in process before | 18:39 |
| bac | bcsaller: ah, more good ammo | 18:39 |
| bac | invalidized | 18:40 |
| 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 | 18:51 |
| bcsaller | hatch: taking a peek, then lunch | 18:51 |
| hatch | thanks | 18:51 |
| hatch | then I'll need you to fill me in this subordinate stuff | 18:52 |
| hatch | after lunch is fine :) | 18:52 |
| hatch | I also could use some lunch | 18:52 |
| 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 | 18:56 |
| bcsaller | mini-review | 18:56 |
| hatch | thanks! | 18:56 |
| bcsaller | also, check for authenticated at start of method | 18:57 |
| * bcsaller heads to lunch | 18:57 | |
| hatch | bcsaller: 531: done, 536: that was copied from the endpoint.py, 571: relation- is the prefix used right now | 19:03 |
| hatch | now I'm lunching :) | 19:03 |
| 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? | 19:34 |
| bcsaller | hatch: its a map, not an array and it take an additional argument of true to indicate its a update/add | 19:53 |
| hatch | ok is this documented anywhere? | 19:53 |
| bcsaller | hatch: another question is do you need to push the two services into their change set as well. | 19:53 |
| hatch | I don't know - I didn't even know about this change list until you said it | 19:54 |
| hatch | so I haven't done it for any of the other stuff I've done | 19:54 |
| bcsaller | hatch: this is all new code, but _resetChanges, nextChanges implement it. addUnit shows an example | 19:55 |
| bcsaller | pretty much self contained | 19:55 |
| hatch | oh ok so we don't actually use this delta stuff yet | 19:56 |
| hatch | alright it's been added this.changes.relations[relationId] = [relation, true]; | 19:59 |
| bcsaller | hatch: we do, sandbox.sendDelta consumes this | 20:06 |
| hatch | ahh ok - and what is this used for on the client? | 20:06 |
| hatch | or are these the ws updates? | 20:06 |
| bcsaller | this is as though improv were recoding changes in a list to send a batch to the client. | 20:07 |
| hatch | gotcha | 20:07 |
| bcsaller | so yes, this whole thing is talking over the ws channel and that part arranges the delta updates | 20:07 |
| hatch | you know you have a serious syntax error when the linter crashes | 20:14 |
| hatch | :D | 20:14 |
| hatch | oh poo | 20:24 |
| hatch | crud I did this all wrong | 20:39 |
| hatch | :/ | 20:39 |
| hatch | ok not 'all' wrong, just have to shift some stuff around | 20:39 |
| hatch | bcsaller: are you still kickin around? | 21:23 |
| bcsaller | hatch: yeah, plenty of time left | 21:24 |
| hatch | oh right...ok | 21:24 |
| hatch | so I kind of screwed up and was passing too much information to the fakebackend | 21:24 |
| hatch | in reality all that's passed back is "wordpress:db" and "mysql:db" | 21:24 |
| bcsaller | ahh, that makes sense, then it does the resolution from the metadata | 21:25 |
| 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 | 21:25 |
| hatch | my question is....can a charm be both a client and a server to eachother | 21:25 |
| hatch | so could they both be in eachothers provides and requires | 21:25 |
| bcsaller | hatch: yes, it could... rare though, don't think about it in terms of the charm though, only endpoint matches | 21:26 |
| bcsaller | if the endpoints match then its allowed | 21:26 |
| hatch | ok so as long as they are both 'db' or whatever then it's ok? | 21:26 |
| bcsaller | as long as they implement the other side of the expected endpoint | 21:27 |
| hatch | so then I would parse wordpress and mysql to find out which one has a requires db and that is the client | 21:27 |
| hatch | is that a logical approach? | 21:27 |
| bcsaller | client and server are just useful names in this context but meaningless for the most part | 21:27 |
| hatch | oh ok so I can ditch that assignment entirely then | 21:27 |
| hatch | niiiice | 21:28 |
| hatch | just check to make sure one has the other in it's requires | 21:28 |
| hatch | under the endpoint....in this case 'db' | 21:28 |
| bcsaller | sounds correct | 21:28 |
| hatch | I hope so, I hate redoing stuff | 21:29 |
| hatch | pet peeve hah | 21:29 |
| hatch | and should I include some type of validation to make sure the two endpoints are teh same? | 21:30 |
| hatch | or can I rely on the client side to do that for me? | 21:30 |
| hatch | ahh wahtever it's an extra line | 21:31 |
| hatch | might as well | 21:31 |
| hatch | well I guess 3 bcuz 80char limit :D | 21:32 |
| bcsaller | hatch: as an aside I changed addUnit to be zero based like juju and updated the tests. | 21:32 |
| * hatch shakes fist.....why I auta | 21:33 | |
| hatch | alright cool | 21:33 |
| hatch | :D | 21:33 |
| hatch | there complete refactoring and the tests pass | 22:29 |
| hatch | yay for tests | 22:29 |
| hatch | hmm | 22:44 |
| 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 | 22:58 |
| bcsaller | hatch: checking | 22:59 |
| hatch | thanks | 23:00 |
| 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) | 23:03 |
| bcsaller | the formatting you do makes sense though | 23:04 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!