[10:47] bah, reitveld doesn't want to load for me today. [10:55] there it goes, just needed to warm up today I guess [12:18] jujugui, we have a GUI UDS session that we need to lead/attend on Thursday, 18:05-19:00 UTC. We ought to also attend, at least partially, the "Juju Charm Testing" session (Thursday 15:05-16:00 UTC), the "Charm Development Tooling" session (Wednesday 18:05-19:00 UTC), the "Charm Policy Review" session (Wednesday 15:05-16:00), and the "Juju Core Development" session (today 19:05-20:00 UTC). I'll put those in an emai [12:18] l now... [12:18] gary_poster: I wonder if we should promulgate the "Elmo's Pain" blog post to one of the lists. Maybe at least him. :) [12:18] morning [12:19] morning, bac; I trust your return trip was OK [12:20] it was a-ok. best as could possibly be for having to catch a cab at 4:45 [12:20] benji, yeah, the thought crossed my mind as well. :-) I was also considering advertising the blog more generally. I'll do it soon, though I have higher priorities atm so if someone wants to do some of those that would be cool too. oh, that reminds me. [12:20] I think we have two very high priority bugs atm [12:20] one is the memory leak [12:20] the other is the problem when we update the demo site and we can't see it anymore until we clear out our appcache [12:21] gary_poster: i got feed back from some of our spikey haired colleagues that the blog is interesting but they won't read it since it seems to be an internal gripe/work-around collection. food for thought. [12:21] bac, which spikey haired ones? [12:21] for example, perhaps :-) [12:21] ok, it was just one. [12:21] his initials are curtis hovey [12:22] heh [12:22] ok cool [12:22] lol [12:23] gary_poster: bac I could see though getting a tag or category into one of the planets perhaps? Maybe a "this is share-worthy state of GUI" for those that don't care how the sausage is made. [12:24] rick_h_, yeah good idea. do any of the planets still have decent readership? I was under the impression that they were losing steam [12:24] gary_poster: hmm, I'm an rss junkie so not a good person to ask [12:24] heh [12:25] jcastro might have a good suggestion [12:25] good idea thanks [12:54] gary_poster: hiya [12:55] hey rogpeppe1 :-) [12:55] gary_poster: i've just done a pretty major refactoring of the rpc package. it all seems to be working ok, but i wonder if you could check that the branch works with your stuff. [12:55] gary_poster: the branch is here: lp:~rogpeppe/juju-core/300-rpc-refactor [12:56] cool, rogpeppe1, sounds good. I'll get someone to give it a whirl. bac, you up for that? [12:56] gary_poster: i'm quite happy with it - i think it's got rid of a few lurking bugs and added some cool new possibilities [12:57] gary_poster: in particular, rpc can now be bi-directional [12:57] gary_poster: sure [12:57] rogpeppe1: thanks! [12:57] thanks bac [12:57] rogpeppe1, so you mean Juju can now initiate a conversation? [12:57] as opposed to only responding? [12:57] gary_poster: yes [12:58] ah cool rogpeppe1, that is potentially a big deal [12:58] gary_poster: yeah, i think so [12:58] great [12:59] I will keep that in mind in my thoughts going forward [12:59] di you have any immediate ideas on how to apply that? [12:59] gary_poster: i was thinking in particular of cross-environment relations, but i'm sure there are other places where it could be useful [12:59] ah, of course [12:59] gary_poster: there's no requirement that both sides speak the same API of course [12:59] sure [12:59] log streaming [13:00] benji: i'm not sure about that actually [13:00] benji, watchers would work with that, but...yeah [13:00] benji: i think for genuine streams, it might be better to just use a normal non-websocket URL [13:00] rogpeppe1, benji, actually I was thinking that we might be able to use the statsd pattern for logs too. I want to talk to mew about standards [13:01] rogpeppe1: yep, you're probably right [13:01] I mean, it would be a relation interface, as rogpeppe1 suggested at the relevant meeting [13:01] gary_poster: interface or not, the GUI still has to get access somehow [13:02] rogpeppe1, yes, but there are lots of log aggregator tools out there now [13:02] if we speak the right language, we can play the game [13:02] gary_poster: ah, that sounds good [13:02] gary_poster: BTW did you see that go 1.1 is out now? [13:03] rsyslog is maybe the most basic. [13:03] I did, rogpeppe1! I intend to look at the new features. Does that affect the project immediately, or will we havet owait for 13.10? [13:03] gary_poster: i think we'll move over immediately [13:03] cool [13:03] gary_poster: there's not much that impacts us directly. [13:04] gary_poster: i can lose a few hacky bits [13:07] rogpeppe1, actually I had a thought for the statsd story that I was going to talk to you about. we want a "statsd" interface that can operate in both a container scope and a global scope. Specifically, the container scope is good for Landscape and for "adapter" subordinates (statsd -> XXXNEW_PROTOCOL); the global scope is good for gui and statsd servers and graphs (graphite). We can simply require that users spec [13:07] ify the interface twice, once for each scope, but I thought it would be good to record this use case so we can contemplate addressing it at some point. Would you suggest simply filing a bug? Or do you think I'm missing something in my evaluation of the situation? [13:08] "addressing it at some point": making it possible to declare an interface once, applying to both scopes [13:09] gary_poster: won't adapter subs have only the global interface? [13:10] gary_poster: i.e. aren't adapters just about adapting from something local to the global stats relation? [13:18] gary_poster, the uistage.jujucharms.com is getting yanked... [13:19] gary_poster, hp is charging for instances [13:19] rogpeppe1, well, that's a question. so if the scenario is that we have charm A that provides a statsd interface and charmB that requires a NEWSTATS interface, and it is possible to translate statsd to NEWSTATS relatively trivially and automatically, what do you do? I envisioned that you would want subordinate charmC on charmA that would translate statsd to NEWSTATS, and then you would relate charmB to charmC. The [13:19] advantages AFAICT are that you add incremental load to the adapter charm that scales out naturally [13:19] hazmat, hm. the biggest problem here is juju.ubuntu.com, I think. [13:19] gary_poster: could you explain that a bit? [13:19] rogpeppe1, sorry, yes, wanted to reply to hazmat, 1 sec [13:20] gary_poster: np [13:20] hazmat, this is probably a discussion for sinzui and maybe alejandraobregon [13:21] gary_poster, why are stats relayed through juju? [13:21] gary_poster, i thought heka + new websocket for stats [13:21] as statds [13:22] hazmat, one thing at a time :-P I'll return to that conv. in a sec . For now, can we prolong uistage until sinzui and alejandraobregon unveil the new jujucharms.com? [13:22] gary_poster, hazmat, noted. I think we will plan a new instance [13:22] sinzui, hazmat, I suggest that you coordinate timing so there is not a link to nowhere from juju.ubuntu.com, but will step aside otherwise. [13:25] gary_poster, sinzui based on converations the deploy/reveal of that may get delayed even after tech is done. [13:26] so best to fix up current links [13:26] hazmat, I heard the same, yes [13:26] that's right. I understand they want to rethink the site's initial exerpience [13:26] gary_poster do you have a staging site for the gui around? [13:26] er. trunk testing [13:27] hazmat no, will arrange soon, and does not need to block you [13:27] public facing bit is the only thing I think we need to coordinate [13:28] Back to virst conv., rogpeppe1 and hazmat. stats not relayed through juju, that's not what I'm talking about hazmat. statsd talks directly to consumer, whoever they are. The question is about future-proofing generally, since this is a topic that GUI, Landscape, and Core (at least themue had a related session) care about. when statsd becomes old news and XXXNEWTHING is new approach, what do we do? two approaches [13:28] . one is that everyone learns how to talk the new format and the old format. that's fine. but I was raising an interesting use case (that is practically important for Landscape only atm) of adapter charms. [13:29] well, I was saying that adapter charms might be a way to approach the problem [13:29] and I was thinking that they might work best as subordinates [13:29] gary_poster: are you thinking that stats are shown in the GUI? [13:29] and landscape is a subordinate now, and how they want to consume the metrics is from the perspective of a subordinate [13:30] Someone is making staging.jujucharms.com (manage) very angry. I an getting volleys of hate mail [13:30] sinzui: that's me [13:30] sinzui: looks like the interesting api call is blowing up on something new. [13:30] sinzui: was just trying to do a final QA on my branch which hits it [13:30] Shall I forward you all the hate, or are you content just knowing it cannot talk [13:30] gary_poster: a subordinate can still have global relations [13:31] sinzui: well, depends on the hate. If it's something I can help fix today before EOD sure. Else someone else might want to grab it. [13:31] rogpeppe1, metrics only for a single unit. our use case is diagnosis. metrics for aggregates are for dedicated solutions, like statsd + graphite connecting to one or more services [13:31] eh, lines are being crossed, I'm afraid [13:31] rogpeppe1, yeah, I know. [13:32] rogpeppe1, quick call in the hopes that it straightens things out faster than otherwise? [13:32] gary_poster: good idea [13:32] rogpeppe1, https://plus.google.com/hangouts/_/7fb7c30f3a232db57dd8549738fb98e723d90d4a [13:36] rick_h_, this is the bug: https://bugs.launchpad.net/charmworld/+bug/1179942 [13:36] <_mup_> Bug #1179942: Max retries exceeded with url: /charms/_search?size=10 [13:43] morning all [13:53] rogpeppe1, just lost you :-/ [13:54] morning hatch [13:56] can I watch a youtube stream of the vUDS talks? [13:57] hatch I don't think it is a stream. I think you have to go to each talk. maybe wrong [13:58] gary_poster: network difficulties, sorry [13:58] np rogpeppe1 still in hangout if you would like to rejoin [13:59] gary_poster: trying but it doesn't seem to like me currently [13:59] :-) [14:00] rick_h_: do you know if we have bugs filed for all of our remaining UX commitments? or is that still in progress while the designs are completed? [14:04] jcsackett: right, we asked luca to file bugs with the assets/etc attached in chunks that made sense. [14:04] jcsackett: describing to him how we thought of things as 'widgets' or components that fit together [14:05] rick_h_: which staging is broken? [14:05] gary_poster: connection coming and going but hangouts still not there [14:06] abentley: bug sinzui just posted: https://bugs.launchpad.net/charmworld/+bug/1179942 [14:06] <_mup_> Bug #1179942: Max retries exceeded with url: /charms/_search?size=10 [14:06] abentley: breaks anything hitting ES I think atm [14:06] rick_h_: Gotcha. [14:08] sinzui: It sounds like you've been looking at staging. This looks like the same ES fail I've seen a couple of times. [14:09] rogpeppe2, ok thanks for trying. the main point we were discussing was whether setunit can coexist peacefully with addunit and removeunit. I think they can, and they ought to. I'd say that the underlying change is that juju needs to maintain a "goal number" of desired units, and have agents moving the actual number of units to meet that desire. setunit directly changes that goal value. addunit and removeunit tr [14:09] ansactionally (that is, within a single transaction) get the current goal value, modify it, and set it. setunit is a better concurrent approach generally, but removeunit and addunit will still work fine technically in the new world. existing tests relying on addunit and removeunit should be fine. what do you think? [14:15] sinzui: You can see in the charm.log that ES failed to start when restarted. (/var/lib/juju/units/elasticsearch-0/charm.log at 2013-05-14 07:06:19,759) [14:16] hey there is a new version of go released [14:19] yeah go devs switching soon according to Roger [14:19] I mean juju devs [14:19] yea, says it's backwards compat [14:19] go Go :) [14:20] when ever I see Go releases I realize how spoiled I am by the Python stdlib [14:22] sinzui: I'm restoring staging. [14:23] I was just surprised to see a go release [14:23] over a year since their last one [14:23] :) [14:24] hey Makyo you around? [14:24] well...with the exception of bug fix ones [14:24] gary_poster, Yep, though net's a little flaky. [14:24] darn, so it wasn't the router? [14:24] hatch, apparently not. Which is good in a way, I guess :) [14:24] I'll swap later. [14:25] Makyo, ack. I'm worried about that appcache problem we see on tinyurl.com/jujucharms (https://ec2-23-20-230-72.compute-1.amazonaws.com/). I'm afraid it is going to affect jujucharms.com and we are going to be very unhappy. Could you investigate, or maybe hand off some of your knowledge about this to someone else (hatch?) [14:26] is this the no css issue? [14:26] gary_poster, Sure, either or. I think the end result will be appcache just going away. [14:26] It's no resources, hatch , not just css. [14:27] Makyo, no appcache will make us sad, yeah? [14:27] rick_h_: staging is back. [14:27] gary_poster, the only things in there are the service blocks, which are going away, correct? [14:27] abentley: cool thanks [14:27] And index.html [14:27] grrrr, chrome crashed while attempting a heap capture [14:27] :/ tests passed when they should have failed [14:27] Makyo, hmm, good point. how big are the service blocks right now? [14:28] gary_poster, 25K [14:28] For all assets. [14:29] Makyo, wow, yeah, let's dump it, unless you disagree. If you agree, do you have time for that (it involves a bit of Makrfile jiggery) or would you prefer I find someone else so you can focus on the Go branches [14:30] gary_poster, I'll do it, should be quick. I think it's just too clumsy for our needs. All or nothing, too hard to clear, no way to not include index.html, etc. [14:30] ok thanks much Makyo [14:31] gary_poster, np. Landing service placement, then that, then proposing branch 2/3 of the go stuff. [14:31] cool, sounds good [14:31] hatch: did you fix/find the issue with that CI issue of 'cannot find image'? [14:32] if it's from two weeks ago, yes. /me hopes ther's not a new one [14:32] hatch: sorry "Can not find requested image" failure to be more exact [14:32] gary_poster: my branch landing just tossed it out with that failure :/ [14:32] :-( :-( [14:32] rick_h_: I don't follow...was it someone else maybe? [14:32] hatch: I thought you were looking at the CI failure with the image ids/names not looking right? [14:32] hatch, no, he's talking about the fix where you set the new openstack image [14:32] hatch: my bad if I'm remembering incorrectly [14:33] ohh yeah no I have no idea about that - it wasn't me - I am trying to find where the login username is being changed to 'admin' [14:33] I didn't catch what the final fix was for that [14:34] hatch, /me worries you were taken over by aliens...or /me was! [14:34] lol [14:34] ubuflu turns into ubuabduction [14:34] heh [14:35] lol [14:35] there was a massive storm last night so maybe they came in under the cover of thunder [14:36] fyi lower third info for G+ hangouts for vUDS or in general http://paste.ubuntu.com/5598305/ [14:36] gary_poster, were you just going to review the s-cloud-* BPs @ https://blueprints.launchpad.net/juju-gui [14:36] cool thanks arosales [14:37] for vUDS guid development sessions tomorrow [14:37] s/guid/gui/ [14:37] arosales, I was going to extract public facing bits from https://docs.google.com/a/canonical.com/document/d/12NlmaoSJswYe2H1u9Z0pjAhrBtqdtN_h76n5rfj05JA/edit# and discuss [14:37] Thursday, not tomorrow, thanks to you :-) [14:39] gary_poster, ah yes :-) [14:40] * arosales needs more coffee :-) [14:40] :-) [14:40] gary_poster, sounds good, thanks. [14:40] cool, thanks [14:40] gary_poster, let me know if you have any questions [14:40] thanks arosales, will do === _mup__ is now known as _mup_ [14:43] rick_h_, abentley, jcsackett, I think someone tested search with asdf and got an error, this is it: https://bugs.launchpad.net/charmworld/+bug/1179970 [14:43] <_mup_> Bug #1179970: KeyError: 'Docs' [14:44] sinzui: ack [14:44] sinzui: Yes, I did. Not sure what happened there, because that was after I'd run 'juju resolved --retry elasticsearch/0'. It should have succeeded, and later attemtps did succeed. [14:49] rogpeppe2: i've exercised the GUI using your RPC branch and don't see any issues. [14:49] bac: thanks a lot [14:49] bac: that's good :-) [15:10] somehow I wrote that whole login/logout route rewrite and didn't get a single indentation lint error....either I'm getting better at this stuff or something is seriously wrong :) [15:17] jujugui Looking for a review and a qa on https://codereview.appspot.com/9415043/ a QA needs to be done using all three back ends please :) [15:19] hatch, conflict in lp diff: https://code.launchpad.net/~hatch/juju-gui/auth-routes/+merge/163732 [15:20] ahh crap [15:20] ok ignore that email [15:21] thanks for pointing that out teknico :) [15:22] hatch: quick hangout once you're done reproposing? [15:22] yeah I just want to make sure everything works after fixing that [15:23] annnd it doesnt [15:23] :-) [15:23] *expletive* [15:23] hatch, after talking with teknico, ping me to talk about CI plz. I'm pretty sure you know more than you are letting on about how to fix that CI failure. Or one or both of us are aliens. [15:24] ok we can chat now [15:24] teknico, gets to go first [15:24] sec while I grab my headset [15:24] hatch: https://plus.google.com/hangouts/_/02bb45411739e441fe107c9f66e2a8cc36ba4ba7 [15:25] ok there [15:26] rick_h_: Technically, you won't need has_icon, because icon.svg would be listed in "files", but I'm happy to include it as a convenience. [15:38] gary_poster: ok guichat? [15:38] ok hatch [15:43] hey bac, you have a sec? [15:43] gary_poster: sure [15:43] thanks bac, guichat? [15:43] yep [15:53] jujugui kanban now, call in 7 [16:03] abentley: ah true. cool [16:15] Makyo: is your "Refactor RepoSuite to juju/testing" card reviewable? it links neither to Rietveld nor to LP [16:15] teknico, yes, sorry. Card confusion with splitting branches. [16:16] teknico, https://codereview.appspot.com/9074045/ [16:17] Makyo: gotcha [16:32] rick_h_: are you around today? [16:32] hatch: yea, what's up? [16:34] in fixing my tests I have somehow broken a charm browser test suite and I am at a total loss as to wtf is going on - any chance you could take a look? [16:35] hatch: sure, linky the branch in progress [16:35] https://code.launchpad.net/~hatch/juju-gui/auth-routes [16:35] thanks [16:35] hatch: k, pulling down. Give me a few [16:36] rick_h_: you should see aftereach failing in browser_charm_view right after "qa content is loaded when tab is clicked on" [16:36] and commenting that test out causes a number of tests to fail much later in the full suite....so I'm totally lost haha [16:37] hatch: in app.js so both routes login/logout should be there? solving merge conflict... [16:37] ohh I haven't merged with trunk yet [16:37] I didn't want to introduce more issues yet :) [16:37] only login route should be there [16:38] hatch: so no logout route [16:38] nope [16:38] k [16:39] hey, who's leaving the slider assets around the test suite :P [16:40] yeah I noticed that too - I was going to look into fixing that after I got this branch landed [16:43] hatch: guichat? [16:45] yup [16:59] * rick_h_ yells "not me!" and runs away from failing test [17:00] lol [17:00] thanks for looking :) [17:17] hi hatch, quick chat? [17:25] hatch: you got a sec? [17:26] sure whats up? [17:43] hatch: this Go login thing isn't intermittent. I've gotten it 10 straight times. [17:44] rick_h_, it depends on the speed it runs it with [17:44] it's ok I know what that issue is ;) [17:45] hatch: ok, just trying to poke at this some more. Depending on what I comment out I get all kinds of diff errors [17:48] yeah something is right messed up with these tests [17:54] updated card on "export UI" with a review branch when people have time [17:56] rick_h_, I think I solved it [17:56] hatch: orly? [17:56] hatch: legit issue or just the test suite hating us? [17:57] I think it was an issue with how the tests were written combined with the long instantiation procedure for app [17:57] might have to put some thought into restructuring app [17:58] hatch: well I'm all for restructing the test suite :P If app passes the tests then so be it imo. [17:59] well I was thinking about breaking the app instantiation into a number of extensions which we can turn on/off for testing [17:59] that's my 5s worth of thought on the matter [17:59] :) [17:59] hatch: but you still need tests with it all turned on. [18:00] hatch: so if that'll fail then at least let's make sure we know that's what failed vs something 100 tests later [18:00] thats kind of my thoughts - I am also working with a migraine so I'm sure there are also some other issues associated with it that I'm missing :) [18:01] hatch: I guess at some point I just wonder if we're fixing the symptoms vs the real problem. If the code's not broken the tests need fixing not the code. [18:01] hatch: ah, well go take some meds for that. hate those evil things [18:01] true but there is something to be said about 'testable code' [18:02] so it could be that the app is becoming to large to instantiate [18:02] for tests [18:03] hatch: k, well if you found something all good and I'm all for making app easier to maintain/etc. I just don't want to add complexity by flagging app features purely because the test suite hates us. [18:03] not that it's my decision or anything, but my input since I heard someone ask me on the wind over here in my coffee shop :P === deryck is now known as deryck[lunch] [18:03] haha so true so true - well once I finish modifying the tests if it works then we can look at it in more detail [18:04] it's windy IN the coffee shop? [18:05] ;) [18:05] hatch: or maybe it was just the voices in my head. I can never tell [18:16] haha [18:27] I wonder when the service page got too big and required scrolling :-/ [18:28] sometimes [18:28] mm all the time [18:28] but sometimes it works for the first few seconds [18:30] gary_poster, I thought we were ignoring that because of the new UX? [18:30] not my intent [18:30] oh ok sorry :) [18:32] we got a new radio station, all 80's and 90's hits [18:32] w000t [18:37] hey bcsaller I'm trying out your export branch. shift d works great. I can't get what I believe be the help key to work (shift /, or simply "?" AFAICT). From your branch it looks like I should be able to drag the environment name at the top of the page but that is not working for me. Finally and most trivially, the "esc" callback throws errors when #shortcut-help is not around. Can you correct me to the proper [18:37] help key and the proper drag mechanism? [18:38] that was some strange English [18:38] ...what I believe to be... [18:38] ...Can you correct my understanding of the help key and the drag mechanism? [18:39] gary_poster: Shift-/ or '?' works for me on that branch, odd. I also don't see an error pressing escape as shortcut help is always there (just not visible) [18:39] huh [18:39] I'll reload page after clearing appcache [18:39] the word 'Environment' is the drag target (but I didn't change the cursor on hover as I don't think we should promote this feature yet) [18:40] gary_poster: when you start the drag however it does change [18:40] bcsaller, duh, looks like I just needed to clear appcache. sorry for false alarm [18:42] * bcsaller shakes his fist at appcache one final time [18:42] :-) [18:46] bcsaller, shift d works great, but if I export a larger environment (like http://ubuntuone.com/3dl0I8k9YsG52dvmzFdiOH) with drag-drop I get an error ("Error opening file '/home/gary/Desktop/{"meta":{"exportFormat":1},"services":[{"displayName":"cassandra","name":"cassandra","charm":"cs:precise/cassandra-3","config".txt': No such file or directory") [18:46] it looks like the name is the content when you drag-drop? [18:47] gary_poster: it shouldn't be, maybe I botched the merge, my quick testing seemed to work before, checking now [18:48] bcsaller, fwiw I merged your branch into trunk for review. Maybe that's the problem [18:48] no conflicts though [18:48] I did that this morning as well before the CR push [18:50] gary_poster: there are two import paths, the file reader one which is the drag from file manager to browser case, the other is from the clipboard. The clipboard case will put the JSON (if it fits) in the clipboard [18:50] AFAIK it can't set a filename associated with that clip though [18:50] so nautilus sees the drag and tries to name the file its contents [18:51] ack, on call back soon [18:51] however dragging to another gui instance is fine as it tries to import that data directly [18:51] ok === deryck[lunch] is now known as deryck [19:00] my cobzr setup got corrupted :| [19:04] Makyo: kill cobzr [19:05] * Makyo gets out the knife :/ [19:06] Makyo: seriously, did you read tim's suggestions in juju-core/docs/bazaar* ? [19:06] rick_h_, yeah looks like I found a good workaround [19:06] it was because of multiple app instantiations with such a long init cycle [19:06] bac, re: switching to pipelines? [19:07] Makyo: you don't have to go all the way to pipelines but just use a sane set up for lightweight checkouts that allows you to get rid of cobzr [19:07] Something just fell off the roof. Back in a sec. [19:10] Oh well. [19:10] I see m.jc.com just through a wobbly when someone was looking at the juju-gui charm [19:10] I'll read up on it, bac. [19:11] * sinzui reports bug [19:18] hatch: cool [19:19] of course I am trying to solve some edge cases now [19:22] bcsaller: you guys have a running GUI charm on prodstack right? It's just a raw IP port right now? [19:22] rick_h_: I'm not sure the status of that [19:22] bcsaller: asking because abentley noticed that the charm installs apache, but prodstack rules say you must go through the apache charm from them and curious if there's a branch/etc to look at for the latest/greatest [19:23] hmm, afaik they accepted what we delivered [19:24] there was no additional work to support a remote apache. Currently the server is static files though so they might have let it in because of that [19:24] bcsaller: ok cool. [19:33] rick_h_, still around? [19:41] hatch: what's up? [19:41] wondering if you could pull down the latest version of my auth branch and see if that Go error pops up [19:41] hatch: k, sec [19:41] thanks [19:44] hatch: all tests pass [19:44] righteous [19:45] hatch: just testing something else out quick, sec [19:46] hatch: so if I comment out the test_app (which I was doing to help debug the test issue) it happens every time [19:47] ok let me try that [19:49] darn I still can't repro [19:49] are you on your desktop? [19:50] hatch: laptop [19:50] desktop arrives tomorrow [19:50] hatch: sec, let me breakpoint there and peek [19:51] I attended Juju vUDS session. Took some notes from GUI perspective, fwiw: http://pad.ubuntu.com/uds-1305-juju-core-development [19:51] big take away: we need even more of a machine perspective than I thought [19:51] rick_h_, ok I was able to reproduce it once - I was asking about the desktop because maybe it was a speed issue - looking into the test now [19:52] hatch: yea, understand. [19:52] rick_h_, bcsaller yes they accepted the apache because GUI needs to be behind haproxy to merge websocket (juju) and normal web resources (apache). If we were a subordinate, we would still need our own apache, or something like that. [19:53] not sure if we could have our own apache within another apache. don't see how that would work [19:53] gary_poster, mongo works better in HA with odd numbers? lol [19:53] have to admit that's pretty funny :) [19:53] hatch: https://speakerdeck.com/mitsuhiko/a-year-of-mongodb ;) [19:53] hatch, :-P :-) [19:54] hatch: hmm, so they 'look' the same to me [19:54] hatch: just the order is diff from what I can tell [19:54] hatch: maybe the test can just compare multiple properties expected to match instead of the deepequal? [19:55] rick_h_, no the deep eql is necessary - the issue is a race condition...now I need to figure out how to fix that [19:56] that guys slides are wrong.....mongo doesn't use JSON records :P [19:56] I will read more after I fix this test [19:57] hatch: http://paste.mitechie.com/show/959/ [19:57] mongodb needs 3 so you can always vote for a new master. Also you usually want sharding, and 3 of each shard...so enjoy the number of machines [19:58] ohh that's why it needs 3...I guess that makes sense [19:58] yea, you want to have a vote to promote else some out of date second can just become master and oh well to any data that didn't get there yet [19:59] hatch: so yea, I don't know. When I debugger into that test and check each property I'm golden. Then again if it's a race the delay in getting at the object must be cool and fix it [20:01] yeah - I know how to fix it....just trying to figure out how without rewriting all of the tests [20:01] :) [20:01] hatch: ok, then I can quit poking at this and EOD [20:01] have fun :) [20:02] thanks for your help [20:03] hatch: heh, happy to just yell "it's broke" :) [20:04] oo new radio station is playing Oasis [20:04] fixed....but yuck [20:05] hatch: what was that? I stopped reading at 'fixed' :P [20:06] https://gist.github.com/hatched/3ec63ac042ad698c6ea6 [20:06] ln 2 to 11 [20:06] feel free to try that in your branch :) [20:06] hatch: now turn that into a method resetGoEnv() and it's pretty again [20:07] sure I still think it's a hack :) [20:08] hatch: yay tests pass [20:08] and I thought that the login/logout routes would be a simple fix :) [20:09] hatch: ok, color me confused. What you added is just a pass through beforeEach/afterEach? [20:09] the before/after each still run as normal, so that's why I am destroying the env that the before created [20:09] clobbered the method causing issues [20:10] then reset it back after [20:10] gary_poster: I don't understand why you would need your own apache if it was a subordinate. The subordinate relation could make the charmed apache serve your static files. [20:15] abentley, the GUI's haproxy would need to proxy the apache, so the haproxy needs to have control over the external port that serves the GUI--80 and 443 in our case. I could imagine a setup that had the GUI served from apache in one charm, and then fronted by an haproxy service that was specially configured to serve the Juju API properly. That haproxy would probably require custom development and unusual configurat [20:15] ion, and would be antithetical to my desire to make deploying the GUI very easy (a single deploy statement and a single expose statement). If we could make the GUI charm support both the easy deploy and the subordinate deploy story then that would be fine in theory. However, [20:16] that is only interesting with the jujucharms.com/sandbox story. Until convinced otherwise, I prefer to have a single charm that is configured to handle the different cases. [20:16] That was a bit convoluted, sorry. :-/ [20:25] I noticed that the featured flags route is at the end of the route list - shouldn't that be at the start? [20:26] so that the other routes can rely on that code? [20:26] gary_poster: I'm not familiar with the haproxy+websockets issues. Do I understand correctly that juju-gui's charm installs both juju-gui and haproxy? [20:26] gary_poster: And apache? [20:26] abentley, yes. want to have a chat? [20:26] gary_poster: sure. [20:27] abentley, guichat is open (https://plus.google.com/hangouts/_/7fb7c30f3a232db57dd8549738fb98e723d90d4a) [20:33] jujugui - anyone available for a QA and review? https://codereview.appspot.com/9415043/ [20:35] hatch: I can review that [20:35] thanks - any chance I could get a QA too? sorry QA'ing this kind of sucks :/ [20:37] yes [20:38] u da man [20:54] hey bcsaller. so, I can drag and drop into another GUI, or...what else? [20:55] I guess a text editor. [20:55] trying [20:55] sinzui: Have you seen my explanation of the deeper cause in https://bugs.launchpad.net/charmworld/+bug/1179942 ? [20:55] <_mup_> Bug #1179942: Max retries exceeded with url: /charms/_search?size=10 [20:55] another gui is really the target, the export hotkey is the download story as its not size limited [20:55] ES was not up [20:55] text editor does not work. ah ok [20:56] hm [20:56] ^ abentley ES was not up, so the app tried until it hit the max [20:57] sinzui: Right. I'll copy the explanation to 1176901, but please don't mark *that* as a dupe :-P [20:57] bcsaller, so what's the best way to clear out the namespaces? [20:58] abentley, It is the older bug and I think it is the same issue. It is about the time we discovered that ES timesout on start [20:58] hatch: look at showRootView [20:58] ok I was thinking override myself thanks [21:02] hmm not working [21:02] to the investigator! [21:03] sinzui: I'm sorry if I didn't communicate that clearly to you earlier. I thought I had. [21:06] gary_poster: do you need different behavior for export? Our choices are limited w/o the server generating a URL for the Download. If it does then we can be more sophisticated. [21:06] generating the blob for the S-d export works because it doesn't need to be referenced apart from the download, but passing a URL (the other mode of DnD) can't reference such a file. [21:07] there is a possibility to request local file access, generate the file there, but its was not clear it was worth the effort [21:08] bcsaller, ok. had to think a bit about that. I am concerned about the drag and drop UX because I think it gives the wrong idea of what you can do. I realize that this must be demonstrated to someone for them to find it, but I want to make it super explicit that this is experimental. Could you put the drag and drop behind a "gui.experimentaldndexport.enable" flag, or similar? (you could delete the "experimental, [21:08] " for instance :-). Then when we demo, it will be clear that this is not released and should not necessarily be expected in the future. [21:08] drag out being a strange story to being with. Store interaction for example would make more sense [21:08] sorry, reading what you are saying now [21:08] yeah agree [21:09] basically I think we ought to be able to show off what you have done, so people like Luca can get a feel for possibilities, while being clear that this is not actually released [21:09] it sounds like you are on the same page [21:09] again, I realize the feature flag simply adds to the hidden nature of what you already had [21:10] bcsaller, you ok with featureflag? if so will LGTM [21:10] btw, who updated the background for the gui blog? I meant to say thank you! [21:11] gary_poster: yes, fine with that, though I'd make it quite short if you're ok with it /:flags:/dnd or something [21:12] bcsaller, prefer to make it explicit. In approval to Matt's branch I pointed to Launchpad feature flag names. As I quoted them I thought they might be too heavy, but "dnd" is IMO an example of what we don't want: a feature flag that does not clarify what it does, and that will encourage naming conflicts [21:13] fair enough [21:14] so, I'd be fine with a naming convention that was more trusting, and more trying to state the intent rather than the letter: "choose a name that clearly indicates what it does, both for docs and for name clashes" [21:14] we need to share this though [21:14] right now the rule is the LP rule [21:16] gary_poster: right now its only enabled with sandbox (except for the hotkey, which I think is fine?) I will add the flag. I think always saying gui. and experimental can both be dropped and presence indicates enable implicitly, no? So 'dndexport'? [21:18] if you feel strongly I can go with the whole thing though [21:18] * gary_poster hates xchat sometimes [21:19] bcsaller, ok with dumping gui (was in contrast with charmbrowser. or inspector. or whatever) for now until we change our minds. The other element is supposed to be a verb [21:19] dndexport.enable [21:20] ok [21:20] the contrast is supposed to be "disable" or a particular flavor of approach [21:20] bcsaller, you can argue against that too and say YAGNI until proven otherwise [21:21] seems like presence is on, as you'd never have to turn off a feature flag given our current plans? [21:21] they will all say .enable [21:21] maybe so bcsaller . go for it. have to run. :-P [21:21] ha, ok [21:21] :-) [21:43] bcsaller, the fix is being proposed [21:46] bcsaller, ok the changes are up - should QA properly now [21:46] you might need to appcache-force [21:46] hatch: I'll check it again in a few minutes, thanks [21:47] yep no rush thanks again [22:08] thanks for the qa and review bcsaller - I'll add that note into hacking [22:08] anyone else still working? :) [22:08] * hatch wants to land this [22:26] bcsaller, I created a new unit-tests.rst file to document unit test gotchas and added it to the branch [22:35] morning huwshimi [22:40] hatch, looking at your branch because sick of bzr. [22:40] switch to git? [22:40] :P [22:41] * hatch is just trolling [22:41] HAh. [22:42] lol I have only found a few things that git is actually better at [22:42] but they are used so infrequently it's hardly worth it [22:43] Yeah. There's a lot of stuff that bzr does or can be made to do that make the transition relatively easy. I just screwed up my local stuff. Was going to rebuild, but I need a break. [22:43] * rick_h_ sneaks up behind hatch to snuff out that nonsense he's spewing [22:43] haha sounds good [22:43] rick_h_, lol I think you're more pro-git than I am :) [22:43] hatch: it definitely sounds so [22:54] Makyo, is there more recent documentation for juju charm development than https://juju.ubuntu.com/docs/getting-started.html this hasn't been updated since november [22:55] hatch: check with marco in #juju and ask about juju create and such [22:56] hatch: there's some stuff in the works but not sure where/what state it's at [22:56] hatch, Don't know, but yeah, check with marcoceppi. [22:56] Or m_3, I think? [22:56] that name has a ring to it [22:56] You talked with both of them about the node charm. [22:56] marcoceppi......marcoCeppi......maaaaarcoCEPPI [22:57] heh [23:05] hatch, lost track of time. Will do a code review now and try to do QA after dinner. [23:05] sure np - bcsaller did a QA so you probably don't have to if you don't want to [23:06] but 2x is always better :) [23:07] hatch, will leave it up to you, but yeah, more is better [23:08] maybe because it's such an integral part you should probably do another [23:08] I am not sure if he tested with the go back end [23:08] do we have a fake go back end? [23:08] :) [23:29] Makyo, thanks for the review - I was also curious about the story for requiring the login [23:29] I'll create a friday ticket [23:32] hatch, cool, thanks. [23:32] hatch, I know a lot of sites that lose your current goal when you log in, so it's not unusual by any stretch, but still. [23:32] Some keep it in a ?next= [23:34] yeah I am just thinking that if that happens and then they paste the url again they will need to log in again [23:34] *might need to* [23:34] I'd like to see a ?redirect I think... [23:34] or yeah... a ?next or something along those lines [23:34] should be pretty easy to implement [23:34] stick it in localstorage and clear it out post-login [23:35] avoid url/router bits [23:35] that might be more work [23:35] hatch, yeah. I mean, pasting the URL again, they have the creds in local storage. [23:35] yeah if they have allowed the local storage [23:35] True. [23:35] or session storage or whatever we use. [23:35] who doesn't allow localstorage? it's pretty darn built in [23:35] rick_h_, it asks for permission - people click no out of habit haha [23:36] hatch: it doesn't for localstorage [23:36] hatch: you're thinking offline cache access, I just mean sticking the url to redirect to in the key/value store [23:36] http://caniuse.com/namevalue-storage [23:36] hatch: they don't ask until after 5MB I think [23:37] http://dev.w3.org/html5/webstorage/#disk-space [23:41] oh right [23:43] that would probably be the cleanest but using the query params would be the easiest to implement [23:43] although probably not by mjuch [23:44] hatch: yea, just an idea as it's more invisible. I'm with Makyo that it'd be nice to implement url saving on login for sure [23:44] ok well there is a ticket for Friday to discuss [23:44] I'm sure that it will pass pretty easily