[00:12] hatch: you still around? [00:12] or bcsaller? [00:13] I am [00:13] bac: whats up? [00:13] bcsaller: hey i've got a problem where 'make check' when run by lbox fails 90% of the time. makes it really hard to land branches [00:14] bcsaller: that's the hell i'm stuck in now. would you mind landing a branch for me? [00:14] bcsaller: it is bzr+ssh://bazaar.launchpad.net/~bac/juju-gui/featured [00:14] yeah, you have the LGTM's and all? [00:14] bcsaller: yep, it's ready to go [00:14] I'll give it a go [00:15] between gjslint dumping core and this problem i've been poking at it for quite a while now [00:15] bcsaller: thanks a bunch [00:16] The random port for make test-server sometimes means that it can timeout while loading the YUI code in debug mode, I've seen that once or twice, but mostly it works from the CLI which didn't interfere with lbox for me [00:16] trying make check now [00:27] bac: landed it [00:28] thanks ben [00:28] with that i'm outta here [00:28] * bac -> ich bin ein berliner [00:45] hatch: I'm going to have to introduce you to bzr mv === gary_poster is now known as gary_poster|away [01:06] hatch: notes sent [01:07] hatch: looking good, lots of notpicking and a couple of bigger decisions to debate tomorrow [01:21] hello, can anyone help me debug a gui problem ? [01:22] http://paste.ubuntu.com/6177888/ [01:22] run this script to create an environment [01:22] then, using the gui, try to create a relation between p1 and w1 [01:22] then p1 and w2 [01:25] davecheney: will give it a shot here in a sec [01:25] thanks [01:25] rick_h_: if you already have an enviroment running [01:26] davecheney: all good, will try with lxc [01:26] the issue is you cannot create two relatoins from p1 to anything [01:26] afte the first one [01:26] all the remaining services are grey and will not accept a relation from p1 [01:32] davecheney: so yea, I can confirm it but when I force the second relation via the cli it's a different type, website vs reverserproxy? [01:33] that is just a label [01:33] if you do [01:33] add-relation w1 p1 [01:33] well those are two different interfaces that haproxy supports [01:33] or p1 w1 [01:33] it's just a label [01:33] defined by the order of the relation [01:33] they are both the http interface [01:33] davecheney: ah, ok cool [01:34] so if you do p1 w1 [01:34] it's called reverse proxy [01:34] if you do w1 p1 it's called website [01:34] it would be good if the gui would say [01:34] label:interface [01:34] rather than just label [01:34] for example when relating mediawiki [01:34] trunk should do that actually [01:34] you have two mysel interfaces [01:34] davecheney: ok, do you mind filing a bug on it then? I'm guessing we don't have good logic for multiple targets for an interfaces, but then again mysql works fine with two services on one interface. [01:34] db:mysql [01:35] db_slave:mysql [01:35] rick_h_: what title should I use for the bug ? [01:36] davecheney: so I'm testing the apache2 charm and the wordpress instances and apache2 provides three relation types [01:36] once i use one, the next time I try to relate, only two optinos are available. [01:37] I'm not an expert on juju relations, should it be completely possible to reuse the same relation type against many services? [01:37] davecheney: so the bug I'd go with "unable to relate multiple services with a single service on the same relation [01:37] or does that not make sense to other heads? [01:37] maybe with/to [01:39] rick_h_: sounds like it [01:40] afaik there is no limit on the number of peers of you can relate a service too [01:40] lemmie ask hazmat [01:40] hazmat: is there a limit to the number of relations to a service ? [01:40] thanks davecheney, let me know the bug # and I'll add it to the kanban under bugs to peek before I head to bed tonight [01:40] davecheney, no [01:41] davecheney, there is a notion of such in the charm metadata though [01:41] its not acted upon [01:41] also the gui solves once for requires [01:41] effectively from a semantic perspective only provides are unlimited as a relation endpoint [01:42] peers are self established and effectively have a rel max count of 1 [01:42] s/self/auto [01:43] they shouldn't appear in the gui as a valid rel target, but some display nesc for peer rel errors [01:43] hazmat: i don't understand anything you just said [01:43] can haproxy have more than one service related to it ? [01:43] semantically no [01:43] it requires http [01:43] hazmat: i can do it with the cli [01:44] and when I try the same, add-relation w2 p1 action in the gui [01:44] from eithre p1 to w2 [01:44] or w2 to p1, it does not work, all the other services are greyed out [01:44] hmm.. yeah.. it does look like it works for haproxy. for most services it doesn't [01:45] hazmat: where is the bug ? [01:45] ie. you can't relate wordpress to multiple mysql for examples logically [01:45] the gui [01:45] or the charm ? [01:45] davecheney, the charm actually supports this, i'm talking about the way the gui auto solves the valid relation endpoints for drag targets (by ghosting non valid targets) [01:45] their's some assumptions made beyond the base model [01:46] hazmat: ok, rick_h_ , thanks will log a bug [01:46] hence the phrase semantically [01:46] because otherwise you get errors for the vast majority of requires dependencies uses [01:46] which don't support multiples here [01:47] hazmat: rick_h_ https://bugs.launchpad.net/juju-gui/+bug/1233462 [01:47] <_mup_> Bug #1233462: gui does not allow multiple relations between wordpress and ha proxy [01:47] hazmat: but it works with mysql and wordpress [01:47] davecheney, its only supported by the charm with explicit service config [01:48] what is the difference ? [01:48] davecheney, how [01:48] davecheney, wordpress can only use one mysql db [01:48] not multiples [01:48] hazmat: ok, so is this a charm bug or a gui bug ? [01:48] it only works for haproxy charm, because its specifically implemented via charm config [01:48] davecheney, neither [01:48] what is explicit service config ? [01:48] charm config [01:49] you have to configure the haproxy charm for this to work, relating to multiple upstream services [01:49] otherwise its just broken [01:49] hazmat: lets not get bogged down with what haproxy does when it gets that second relation [01:49] you know what, now that you say that this has come up before [01:49] my issue is, i can do something on the cli that I can't do in the gui [01:49] davecheney, why not? its perfectly relevant to the gui behavior here [01:49] which is don't let me casually get a bunch of broken services [01:50] by accidental relation creation [01:50] hazmat: ok, please answer this [01:50] how does the gui know ? [01:50] where is the metadata that explains that ha proxy can only have one relation on the website:http relation ? [01:50] davecheney, fufilled requirements ('requires') are considered satisified if they have an established relation [01:50] sorry, reverseproxy:http relation [01:51] hazmat: please don't talk charm speak to me [01:51] i don't understand it [01:51] speak plainly and use the words I use [01:51] which are add-relatoin, gui and cli [01:51] relation endpoints, are one of three types .. peer, client/require, server/provider [01:51] peers are auto established on deploy, no need for add-relation [01:52] ok [01:52] client <-> server ... the gui will only do a client as a valid add-relation target, if doesn't have a another client-server relation [01:52] servers can do unlimited clients [01:52] what [01:52] stop [01:52] "he gui will only do a client as a valid add-relation target" [01:52] please explains this bit [01:52] i don't understand [01:52] * hazmat sighs [01:53] g+? [01:54] davecheney, https://plus.google.com/hangouts/_/2e5dc0e9a9e103bfccc16a95c045b1a2ce449249?hl=en [01:54] hazmat: mind if I jump in to catch up? [01:54] rick_h_, sure [01:54] sorry, i don't ahve my teleconference kit with me [01:54] i'm at a coworking space [01:54] we can do this another time [01:54] all i'm looking for is the magic bit of configuation in the charm that says 'i can have multiple relations' [01:54] which i'm guessing is provides an requires [01:54] requires is at most one [01:54] provies is many [01:55] nutshell yes [01:56] davecheney, put another way the only charm that supports multiple requires relations that doesn't result in broken usage i know of is haproxy [01:56] provides: [01:56] website: [01:56] interface: http [01:56] ^ from ha proxy [01:56] ahh, but wordpress doens't have a requires [01:57] yes.. both haproxy and wordpress provide http.. but haproxy has to require an upstream http. [01:57] and even then haproxy requires explicit service configuration to be set for this usage to work [02:02] provides: - The deployed service unit must have the given relations established with another service unit whose charm requires them for the service to work properly. See below for how to define a relation. [02:02] requires: - The deployed service unit must have the given relations established with another service unit whose charm provides them for the service to work properly. See below for how to define a relation. [02:03] from our docs [02:03] brilliant ... [02:04] hazmat: looking at the mysql charm [02:04] it provides db:mysql to many clients [02:05] and requires salve:mysql-oneway-replicatoin to many clients [02:05] there is a limit: n field in the docs [02:05] but it is not implemented [02:05] requires: to one client [02:05] er.. requires: to one provider [02:06] hazmat: so you are saying i can only have one master and one slave ? [02:06] no.. you can have several slaves [02:06] you said it requires: x... [02:07] so i can do juju deploy -n2 mysql slave [02:07] all requires: are in common usage to one relation (which is implemented and constrained as such by the gui) [02:07] the juju add-relation m1:slave slave:master [02:07] sorry, terrible names ? [02:07] number of units has nothing to do with relations [02:07] number of services does [02:07] aaaaaaahhhhhhhhhhhhhhhh [02:07] now I understand [02:08] so i cannot do [02:08] juju deploy mysql s1 [02:08] juju deploy mysql s2 [02:08] juju add-relation m1:slave s1 [02:08] juju add-relation m1:slave s2 [02:08] because that is what I *think* is happening with the haproxy example [02:09] not quite [02:09] juju add-relation m1:master s1:slave [02:09] juju add-relation m1:master s2:slave [02:10] the haproxy to not result in a something broken does [02:10] rick_h_: that is the bug [02:10] the name of the relation shuld be reverseproxy [02:10] not website [02:11] davecheney, that's a judgement call [02:11] davecheney, we basically color / label the relations by the name of provider afaicr [02:11] in the gui [02:12] or is it the other way around.. don't remember.. i tried both ways.. one worked better for the majority [02:12] right [02:12] so it's wordpress, website:http <> haproxy reverseproxy:http [02:16] oh good you guys are discussing that bug [02:16] * hatch reads the backlog [02:19] I seem to remember this exact issue being brought up by someone else [02:19] I wonder if this can be better documented/illustrated somewhere [02:20] hazmat: as I read it, wordpress provides website:http [02:20] which means many services may require it [02:20] is that correct ? [02:22] hazmat: the short version is [02:22] haproxy can only proxy one service [02:22] the gui is doing the right thing [02:22] the client is doing the wrong thing [02:24] I hope that's right, I spent a long time on those darn endpoint calculations :D [02:24] (in the gui) [02:25] unless of course that's not the case, then it was someone else :P [02:25] LP1233462 [02:25] #1233462 [02:25] <_mup_> Bug #1233462: gui does not allow multiple relations between wordpress and ha proxy [02:25] davecheney: not sure if you saw, but all of your previous bugs have been fixed and committed waiting for release [02:26] hatch: nice [02:26] thanks [02:27] i look forward to consuming them [02:28] davecheney: ok I'm not the utmost expert in this field but as per your bug I would bet that the GUI is acting correctly [02:28] unless you have done some magic in the hook for the requires [02:28] so maybe the CLI allows you to do it because you 'might' want to do it?? [02:28] hatch: the gui only consumes metadata.yaml, right ? [02:29] the GUI gets it's metadata from charmworld [02:29] 'formatted' metadata [02:29] hatch: my point is, nobody reads the hooks [02:29] they are opaque [02:30] agreed [02:30] thenagain noone reads the source of any module they include into their system :D [02:30] hatch: when I say noone, i mean the gui, the cli, etc [02:30] their contents do not influcnce the gui endpoint calculations [02:30] correct [02:31] there would be no way they could [02:31] 12:28 < hatch> unless you have done some magic in the hook for the requires [02:31] ^ so this isn't possible [02:31] well you can write whatever you want in your hooks - so that might be why the CLI allows it [02:31] hatch: in that case, the gui shuld allow this as well [02:31] which sounds wrong [02:32] hmm [02:32] yeah I can't really disagree with that [02:34] guess that's not really up to me which one is doing it wrong :) [02:37] but looking at how, for example mysql has it's relations set up, I would hazard a guess that you are only ever supposed to have a single require per endpoint === gary_poster|away is now known as gary_poster === TheRealMue is now known as TheMue [13:10] The email! It doesn't stop! [13:14] gary_poster: we need an email protection program that mirrors the witness protection program [13:14] rick_h_, lol sounds good [13:14] you get sent away and you can't tell anyone where you went [13:14] as long as you don't have to deal with the subsequent fallout, +1 :-) [13:28] gary_poster: i've commented in https://bugs.launchpad.net/juju-core/+bug/1224568 what's now reported in case of a hook error [13:28] <_mup_> Bug #1224568: Improve hook error reporting [13:29] gary_poster: could you check if this is ok for you? [13:29] TheMue, awesome, thanks, yes! looking [13:30] TheMue, could you include a concrete example there or in a pastebin? [13:31] TheMue, fwiw, it sounds perfect so far. :-) [13:32] gary_poster: ok, will add it [13:32] thank yoU [13:49] luca__: for these images in the bundle token, are they centered, left align, right align? Say a bundle has 3 tokens, where do we want them? [13:57] all-over-the-place! [14:05] gary_poster: done [14:05] TheMue, ack and thanks! on call, will review after call [14:16] the power went out here last night - I remember when everything wasn't battery powered and that mattered :D === hatch_ is now known as hatch [14:17] heh [14:18] yea, it's kind of cool how if you UPS up the internet gear you can keep going without power for a while [14:18] we are very close to the local switch, so I'm goign to assume that if we get a 'real' outage we would also lose internet [14:19] but I have no idea what's inside those big green boxes [14:19] :) [14:22] so...it's been a couple days since the finally of breaking bad...I hope people can stop talking about it now [14:22] :P [14:27] benji: got a sec to chat charm id in the bundle api response? [14:28] rick_h_: sure [14:28] rick_h_: did you get a chance to read my responses to your comments? [14:28] hatch: little bit. I basically read "we'll talk tomorrow" and left it at that :) [14:29] haha ok cool, I'm trying to find out if there are icons for bundles [14:29] it doesn't look like it [14:31] the docs mention a 'has_icon' property but that's not retured [14:36] hatch: yea, sec otp [14:43] hatch: ok, got a sec if you want to chat then? [14:44] calling [15:04] benji: so I'm looking at that deployer file and I see that in the services list the key is db, and there's a 'charm' attribute in there that says mysql [15:04] benji: the rest don't have a charm name, but the key looks like the name [15:04] benji: is there any rule of thumb on this atm? [15:05] rick_h_: I'm 80% sure that the key is the service name, not the charm name (e.g., "intranet" not "apache2") [15:06] benji: ok, so I should look to be adding a firm name attribute for our use then as it's a bit inconsistent in the deployer format of the api call === matsubara is now known as matsubara-lunch [15:08] rick_h_: +1 [15:09] rick_h_: I'm begining to think that the GUI-needed details should not be superimposed on the deployer data, but "beside" or "above" it in the data layout [15:09] that way if an attribute is added to the deployer data we don't have to worry about key collisions [15:10] so remember when I said a 'real' poweroutage [15:10] lol [15:10] ka-boooooom goes the transformer === hatch_ is now known as hatch [15:14] benji: true, we used the idea of 'metadata' in the other api calls for things that might need to expand/be additional info. Maybe that idea makes sense here [15:15] benji: though that won't work with the current deployer stuff since it would nest the deployer info one level down into the object. Maybe a reserved 'metadata' keyword the deployer can promise to not use? Single key safety? [15:15] this of course assumes that the deployer ignores things it doesn't care about which I've not verified [15:16] rick_h_: I think I'm -0 on a reserved keyword (for two main reasons: 1) from an information architecture view point it doesn't sit right, and 2) coordinating with other people is hard/irritating ;) [15:17] benji: yea, but then how were you thinking of making it 'above/below'? [15:17] benji: do you mean on the api call itself? I think we were in agreement for a api/3/bundle/~bac/wiki/3/wiki/details new call? [15:17] for the search results use, its easy [15:18] right for /detais we just either make a top-level object with two keys ("bundle" and "charm_details" perhaps) [15:18] gotcha, yea. So in that new call I'd probably do keys like 'deployer' 'metadata' [15:19] and anything in deployer is the same format you'd expect, and the metadata is the consistant "extra" we've had in other calls [15:19] the name kind of sucks in this case, but I'd rather keep that key consistant with the rest of the api [15:20] http://staging.jujucharms.com/api/2/charm/precise/apache2-2 like here where the doctype was part of metadata [15:20] * rick_h_ thought we used it elsewhere as well... [15:23] rick_h_: yeah, I don't really like "metadata" in isolation there, but the consistency argument makes sense [15:23] benji: right [15:30] frankban: ping, got a sec? [15:30] rick_h_: sure [15:31] frankban: so, I think your fix is ok. It does the job, but it gets around the issue vs fixing the issue it appears [15:31] frankban: so when I test trunk, I minimize, reopen, the details are there but then get blanked [15:31] frankban: as if something stepped in and deleted it. This is very visible in IE because of the sloweless of it [15:32] rick_h_: yes, the sidebar.render() makes them disappear [15:32] frankban: your fix re-renders it, which seems pretty smooth in chrome (it deletes and rerenders quickly) but then in IE it's really noticable that it was there and then gone and then back again [15:32] frankban: so I'm wondering if the "best" fix isn't to try to get at the deletion vs rerendering? [15:33] rick_h_: it depends: I don't know why we are re-rendering the sidebar, and if the reason also applies to the details [15:33] frankban: k, looking through the code now. I know there was a bug around something there. Trying to recall. [15:34] rick_h_: thanks [15:37] frankban: https://code.launchpad.net/~rharding/juju-gui/more-state-issues/+merge/182459 is the branch that did it. It was cleanup related. A couple of bugs are tied to it [15:38] * gary_poster goes for a quick walk. back in time for call. [15:38] frankban: the second to last item in the MP description fit in there. We forced re-render because of an odd chain of paths where there's no ._sidebar instance but the viewmode didn't change. I'm trying to recall the path that hit that. [15:39] frankban: hangout? [15:39] rick_h_: sure [15:41] frankban: https://plus.google.com/hangouts/_/c28ca959a840aa4051c5bdcd11f691bfe11d92c7?hl=en [15:50] jujugui call in 10 [15:55] gary_poster: I'll get back to you tomorrow on the build relation thing, I want to think it over a bit [15:55] Makyo: the new Krewella cd 'Get Wet' is out, not sure if you're a fan? https://itunes.apple.com/ca/album/get-wet/id689472430 [15:55] gary_poster: the solution we have in the pipe line is a button that appears on hover over the top of the service block, but the service block design has not be solved. [15:57] hatch, not heard of them, but will take a look :) While we're at it. Chibitech finally released an album instead of singles, if you're into chip stuff: http://chibitech.bandcamp.com/album/moenes-vol-1-the-idol-composers-groove /cc jcsackett [15:57] will have to take a look after the call [15:58] Ofc [15:58] jujugui call in 2 :) === matsubara-lunch is now known as matsubara [16:26] Makyo: my dogs hate your music [16:26] lol [16:26] Hahahah [16:27] rick_h_: it seems the sidebar shows up before routeDirectCharmId is called [16:28] hatch, currently stuck on http://www.youtube.com/watch?v=l2f6UbMnlq4 though [16:28] frankban: yes, I'm looking now. I think the bug is in the cleanOldViews and the viewmode state change [16:29] frankban: when you go from minimized to sidebar the old sidebar is still there, even though _cleanOldViews should have run .destroy() on it [16:29] Makyo: slightly different than this version of The Fox http://www.youtube.com/watch?v=jofNR_WkoCE [16:29] Do I want to click this? Will this make me want to strangle someone? [16:29] Yep. [16:30] lol! [16:30] C'mere hatch. Stranglin' time. [16:30] what does the fox say? ding ding ding ding ding ding lol [16:31] James got the woot shirt with that on it. Sigh. [16:32] lol [16:34] frankban: so http://paste.mitechie.com/show/1026/ I think fixes it [16:34] frankban: the destroy is called in _cleanOldViews but it never removed the html. This causes the flicker effect when it's made visible again. Fixing the destroy fixes the flicker [16:35] Makyo: http://www.youtube.com/watch?v=mbyzgeee2mg by the same guys [16:35] That video is so ridiculous :P [16:36] lol [16:36] frankban: so this gets to the point that originally we kept the html around so that minimize/unminimized where instant user experiences [16:36] rick_h_: that's great! so we were seeing a ghost of the old sidebar [16:36] frankban: but then we ended up with invisible html holding events on the DOM that it should not have and started to clean it up [16:37] rick_h_: makes sense. and the updateVisible fix really shows its effects, right? [16:39] rick_h_: ok, bzr pushed the changes, if you want to do a quick final QA. I'll change the test as you suggested and then land the branch, ok? [16:45] frankban: rgr, looking now. Sorry for the delay, had someone at the door. [16:46] frankban: so one more thing then [16:47] frankban: rather than add the force flag, I think it would make sense for the _cleanOldViews to also remove this._details if it exists and the old viewmode we're removing is sidebar. [16:47] frankban: then we don't need the force bits at all? [16:49] rick_h_: makes sense, so in _shouldShowCharm, if we have a charmID but not a _details, we return true [16:49] (and we don't need force) [16:49] frankban: well the viewmode should have been changed though...I'm looking. It seems shouldShowCharm might be off? [16:50] frankban: so it should work the way it is right? If we have a charm id, and the viewmode changed (minimized to sidebar) then we should show the charm [16:50] we then call renderCharmDetails which checks "is there already a details rendered under this._details" [16:50] frankban: so if we clean up this._details in the _cleanOldViews then that check will work correctly and we'll be fine [16:51] rick_h_: ok, I'll check it tomorrow, and repropose [16:51] frankban: ok, sounds good. Sorry to run you through it all. [16:51] thanks for tracing it through [16:52] rick_h_: no worries: your solution is simple and clean, thanks for helping me [17:24] hey hatch, did you see https://bugs.launchpad.net/juju-core/+bug/1224568? [17:24] <_mup_> Bug #1224568: Improve hook error reporting [17:24] looking [17:25] gary_poster: odd that I have it 'affecting' me but I don't get the update emails [17:25] thanks for pointing it out [17:26] hatch, look for subscription information on right of bug [17:26] "You are not subscribed..." [17:26] click on link to change [17:26] weird, so what's the point of 'affects' ? haha [17:28] hatch, I think it was introduced as a way to reduce people adding "+1" comments [17:28] ohh [17:29] this is looking great [17:29] do that's going to be coming in 1.16? [17:29] so* [17:31] hatch yeah I think so [17:31] hatch, so he means all of those keys come in the unit state keys right? [17:32] just reading the diffs [17:33] ok yes so basically he added a new Data param which includes those keys [17:33] basically exactly what we asked for [17:33] hatch, so those keys are nested in "Data"? [17:34] right [17:34] cool. [17:34] yeah so we can modify the contents of Data all we want without stirring up a mess down the road [17:34] oic [17:34] we don't set status, core does [17:35] we have the keys to core's house [17:35] ;) [17:36] I can't seem to link to a line in the diff, but there is now a StatusData key [17:36] I've read the diff [17:38] the only question I have....is I see the data there for the errors [17:39] but I don't see how we can tell if it's an error [17:39] see comment #4 and #5 on the bug [17:39] oh nm [17:39] hatch, status, yeah? [17:40] yeah my brain has just been failing lately [17:40]