=== Makyo is now known as Makyo|out [13:03] hazmat: thanks for the subordinate addition. it works now. [13:04] bac, cool [13:30] teknico, everything good with bug 1074425? Just checking since this was the first trans-Atlantic handoff we've had on the GUI team. [13:30] <_mup_> Bug #1074425: Make charm turn off console and any other debug code

< https://launchpad.net/bugs/1074425 > [13:43] just deployed wordpress + mysql on ec2 using juju-gui charm! \o/ that's awesome, good work guys ;-) http://ec2-54-234-19-148.compute-1.amazonaws.com/ [13:44] juju-gui inception: http://ec2-50-17-135-112.compute-1.amazonaws.com:8888/ [13:54] cool [14:04] That's awesome frankban :-) [14:05] frankban, ready for call anytime [14:05] I'm in hangout from calendar [14:05] gary_poster: joining [14:05] * teknico is back from lunch [14:06] gary_poster, yep, got Makyo|out's email, working on it [14:06] cool teknico [14:06] \o/ [14:06] Rock on, frankban. [14:06] * Makyo|out back to cooking breakfast. [14:41] gary_poster: submitted those doc changes, working on the next branch [14:41] great bcsaller thanks. === Makyo|out is now known as Makyo [15:10] Makyo, quick call before the daily? [15:10] teknico, sure [15:10] Makyo, https://tinyurl.com/see-emily-code [15:14] teknico, there [15:16] Makyo, up and running: :-) http://ec2-54-242-61-222.compute-1.amazonaws.com:8888/ [15:18] teknico, Maybe we should have our call after the call marathon? [15:18] gary_poster, oh, right, on a call with Makyo now [15:18] cool [15:21] bcsaller, dragged the bug 1077067 into prototype lane. Good, or coding? [15:21] <_mup_> Bug #1077067: Simple topology integration into environment view < https://launchpad.net/bugs/1077067 > [15:22] gary_poster: I think coding is fine [15:22] cool, did it [15:29] gary_poster, are our daily meetings at 3:30 from now on or just that time on Wednesday? [15:29] goodspud from now on, assuming it is 3:29 for you :-) [15:29] Why yes, it is 3:29.... tick tick tick [15:29] bac bcsaller benji frankban goodspud hazmat jovan2 Makyo teknico call in 1 [15:30] bcsaller, team call now in juju-ui [15:31] benji hazmat starting without you [15:44] arosales, you about? [15:44] we'd like to start the other call [15:45] gary_poster: coming [15:45] cool thanks [15:47] gary_poster: G+? [15:48] arosales, check in canonical IRC [15:48] gave you a link [15:50] * arosales apologies I had this meeting starting at the top of the hour [16:05] hangout failure [16:06] gary_poster, so advisory.. is word fraught with connotation.. [16:06] the gui has a single point of communication with the backend [16:07] if that point is precluded from write operations [16:08] * hazmat senses a disturbance in the force [16:40] Hi all, I've updated the Upload of Config File wireframes, if you'd like to review again: https://docs.google.com/a/canonical.com/document/d/1Wpvj8Kykcqx-aa8Alq8tsU_dbkoE8o4EBYh3ZBWmbCo/edit [16:41] jovan2, I don't have permission to comment [16:45] gary_poster: should be able to comment now [16:47] hazmat, I ran into an issue getting the charm up and running on canonistack. Who would be a good person to ask about that? === teknico_ is now known as teknico [17:06] Makyo, just grabbing some lunch.. but what's the issue? [17:07] Makyo, canonistack has a limited set of ip addresses, in the absence of using that you need an ssh proxy [17:07] unit_get('public-address') is returning the server-.canonistack address, even with an allocated IP assigned to that machine. [17:08] hazmat, ^^^ [17:09] hazmat, That's how the websocket url is set, so even though I can access the gui, it can't access the web socket. [17:09] But I can set up a proxy. [17:10] Makyo, 2 options.. use-floating-ip: true ... in environments.yaml.. which may or may not work..depending on how many free ip addresses are available.. or the proxy [17:11] my understanding is that there is a dearth of public ip addrs.. [17:11] hazmat, alright [17:11] uhm, I'm trying to change the EC2 region in environments.yaml, but I get: [17:11] error: Environments configuration error: /home/nl/.juju/environments.yaml: environments.ec2.region: expected 'us-east-1', got 'eu-west-1b' [17:14] (when running "juju bootstrap") [17:14] I wonder whether I need to set something on AWS [17:17] I haven't seen that and don't know, sorry. Ben or Kapil might be good to ask teknico [17:17] jovan2, commented [17:18] gary_poster, thanks, I'll take a look. [17:18] bcsaller, hazmat, ^^ any idea on what's needed to change the EC2 region? [17:19] teknico, region: us-west-2 in enviornments.yaml [17:19] teknico, 1b is not region its an az [17:19] teknico, try eu-west-1 [17:19] teknico: juju/environment/config.py shows the list of valid regions [17:19] hazmat, oh, I see, thanks [17:20] az can be specified via constraint [17:20] yep, it worked :-) [17:22] hazmat, you have mentioned to bac that the JS YAML parsers kinda suck. I encountered that yesterday. One is relatively robust in my limited tests but says it has problems working in the browser. The other one I found works in the browser but is very limited in what it can understand (it didn't know about > or |, for instance). Is there a known subset of YAML that juju relies on that we could test with, to see if [17:22] jovan2's design work might actually pan out, or does juju really effectively say "any YAML is good by us"? If that's the case, the "parse YAML in the browser" may be a non-starter without more energy than we probably want to throw at it [17:23] gary_poster, we shouldn't be doing it. i thought we had discussed it b4 [17:23] yes.. there is a subset.. but.. its better to avoid it entirely if possible [17:24] gary_poster, for completeness.. this one looks good https://github.com/nodeca/js-yaml [17:25] http://nodeca.github.com/js-yaml/ [17:25] demo link [17:25] that's a big pile of javascript though [17:25] for very little value [17:26] hazmat, this is coming from UX. Depends on how strongly they believe in this then as to how much we should push back/explore... [17:26] I saw that one [17:26] In fact am using considering it in a branch on the server side [17:26] but it says [17:26] gary_poster, its not reasonable.. the server can barf on it, and we can present the error to theuser [17:26] "Browser support is still buggy, and mostly done to run online demo. If you can help to improve browser compatibility and AMD support - rise pull request." [17:27] we're not loading 100k of js to validate some yaml [17:27] hazmat, ok. jovan2 ^^^ [17:28] sorry we didn't nail that down harder sooner jovan2 [17:28] hazmat, fwiw this is https://docs.google.com/a/canonical.com/document/d/1Wpvj8Kykcqx-aa8Alq8tsU_dbkoE8o4EBYh3ZBWmbCo/edit [17:28] which is second draft of something from earlier [17:29] 68k in fact [17:30] gary_poster, we can have the server come up with a more fielded/strucutured error message for the ux.. but ux is not implementation [17:30] more than one way to skin a cat [17:31] hazmat, UX shows loading values and then letting people decide when to submit, after possibly mutating (or discarding!) [17:31] gary_poster, good error message support is something i'm comfortable with pushing on to the server fwiw [17:32] unless juju supports parsing yaml without acting on it [17:32] gary_poster, the ux can do things optimistically but in the end the server is the src of truth.. [17:32] ie.. that name is already taken.. [17:32] gary_poster, it parses the yaml b4 doing mods to the sys [17:32] ie. validates inputs [17:33] hazmat, my point is that the UX as given cannot be implemented with juju validating and then acting on YAML [17:33] So either the UX gives [17:33] or we do it on the client or we add a "validation/parsing" only story to client [17:34] s/to client/to juju/ [17:34] still confusing. this is what I meant: "or we do it on the client or we add a "validation/parsing" only story to Juju" [17:35] gary_poster, or we only validate that field when the user submits the action, and given them in context / form field error message from the server [17:36] that doesn't need a validation/parse only story [17:36] that's still not the given UX. Which, again, is fine. But we aren't talking about how to implement the UX story, we are talking about how to change it. [17:38] fair enough [17:38] I'm fine with however UX and you reconcile this. It sounds like variations on the current UX for this feature are the only technical acceptable ones. [17:38] if we had metrics on how often its an issue.. it would be worth discussing the cost of adding the js to do the front end work [17:38] but as it is.. our js is very large.. we should be slimming [17:39] another good reason to have separate files for framework/templates/app/libs [17:39] so we can monitor see growth [17:40] gary_poster, ic. the ux calls for the parsed values to field fill the form [17:41] i thought it was just validate for the file error message field [17:41] er file field [17:41] right [17:42] right now the aggregate draws down at 674k of js.. [17:42] we should user tgz on that [17:42] we can when we switch to apche or similar [17:42] benji, that's the skin loading stuff in the combo loader i think.. [17:43] re css combo [17:43] gary_poster, user tgz? [17:43] sorry use gzip [17:43] gary_poster, transfer size speed is good/helpful with gz.. but the browser still has to parse/interpret [17:43] that's a boatload of js [17:44] * hazmat wonders how much smaller it would be dropping the widgets.. [17:44] hazmat, if that's actually a success metric then we should establish goals and start measuring [17:44] I suspect it is low on the scale of priorities but maybe I'm wrong [17:45] gary_poster, i'm evaluating it as part of the eventual mobile/tablet usage goal [17:46] ok cool. [17:47] oh teknico you around? [17:47] gary_poster, yep [17:47] teknico, quick call in juju-ui? [17:48] gary_poster, ok [18:13] benji, thanks for the review. The docs only mentioned string and int. However, when I tried boolean, I got consoleEnabled: False, a la python, not JS. Would you say just do a lower case on that, or stick with string? [18:21] Makyo: in my branch a boolean config type works using True/False [18:26] hazmat do you happen to be available for a quick talk with teknico and myself about how we can configure the GUI files to be served over HTTPS and other related topics? [18:26] gary_poster, sure [18:26] thanks hazmat we are in juju-ui [18:40] Makyo: when you retrieved the configuration you got a string "False"? [18:41] benji, Yes, because that's the string representation of that value in python. [18:41] But in javascript, it's false. [18:42] benji, sorry, misunderstood. The string happens when translating the boolean value in the template. [18:42] I did get a boolean. [18:42] cool [18:43] So should I just do a str(config['juju-gui-console-enabled']).lower(), or use a string? [18:43] Or is there something I can do int he template? [18:47] Makyo: I don't understand the question. Why do you need a string? Is it to present it to the user? If so, I bet it would be nicer to construct a sentence: "Console messages are disabled." instead of something like "Console messages enabled: False". [18:49] benji, It's building the config.js file from a template using values from config.yaml. If I pass in the boolean config value to the template, python translates it into the string representation of it, which has a capital F. This is an error in javascript because False is an invalid token. [18:51] Ah! Gotcha. Since you are building a JSON value, I would look at the json module. [18:51] * benji looks [18:52] >>> import json [18:52] >>> json.dumps(False) [18:52] 'false' [18:52] Makyo: ^^^ [18:52] benji, aha, gotcha. [18:54] benji, That adds the line import json, and changes the line in question to: 'console_enabled': json.dumps(config['juju-gui-console-enabled']) [18:55] yep, looks good [18:55] benji, Cool, thanks. [18:55] my pleasure [19:07] hazmat, do you have a plan on how to attack https://bugs.launchpad.net/juju-gui/+bug/1074419 given the chrome basic auth problem? If you don't we can investigate, but if you already have a plan we should follow it. [19:07] <_mup_> Bug #1074419: Enable simple user & password login to rapi-rollup websocket

< https://launchpad.net/bugs/1074419 > [19:40] gary_poster, its not basic auth [19:40] gary_poster, its a login dialog from the gui [19:40] hazmat, which we just sent over the ws after establishing the connection? [19:40] send [19:41] as a juju command, effectively? [20:04] gary_poster, yes.. the login is a command on the websocket.. with auth enabled it rejects other commands on the conn without the auth [20:05] hazmat, ah! this is already implemented, also? [20:05] or this is the plan you want to have implemented? [20:10] gary_poster, its to be done [20:10] gary_poster, that can wait till after the initial deploy story is complete [20:10] gary_poster, the gui will need a login, and the websocket do auth [20:11] hazmat, it would be great to have that sooner because otherwise we are blocked, one card after the other. Also, without it, the deploy story is still security via obscurity, and not much of that, right? [20:12] in fact, it is one of probably two cards that are ready to start right now [20:12] maybe three tops [20:12] gary_poster, huh.. [20:12] how is it a blocker.. its orthogonal to deployment? [20:13] the goal is easy charm based deployment for users to use, hazmat. I don't think people will want to actually use this without some password protection, do you? [20:14] or your saying its orthogonal as well [20:14] I have two threads to the deployment story. I define the goal of the deployment story as having a way to deploy the GUI and actually want to use it [20:14] gary_poster, that's not the point i'm trying to make.. just saying its not a blocker to getting deployment working. and frankly considering the fairly sad nature of juju auth.. [20:15] but fair enough.. its ready to start [20:15] ok [20:15] so the story is: [20:16] when auth config is turned on for juju (with commandline, I guess?)... [20:16] then you can connect to the ws [20:16] but it will send nothing [20:17] and only accept an auth command [20:17] once the auth command happens [20:17] it will proceed with handshake [20:17] and then accept other commands [20:17] as it does now [20:17] close.. accept the send nothing bit [20:17] it sends server greeting on connect [20:17] s/accept/except [20:18] but without the usual bits of info [20:18] like the default series [20:18] right? [20:19] * hazmat looks over greeting info [20:20] gary_poster, yeah.. we could switch the extended info (type, series) to the login success response. [20:20] instead of the existing connect [20:21] the connect should continue to response with 'version', 'extensions', 'ready' flags [20:21] right, ok [20:21] is there an obvious point in rapi to be the stranglehold over the other commands? [20:21] gary_poster, its probably more useful to do this at the gui level first [20:22] gary_poster, its a state ful protocol. [20:22] yes [20:22] more useful to do at gui level first: don't understand why yet [20:22] for pyjuju the gui will need to md5 checksum [20:23] gary_poster, relative time and effort [20:23] gary_poster, the backend can't go live till the front end is done [20:23] gary_poster, the backend effort here is on the order of an 1-2hr.. the front end is more like 1-2 days [20:23] I guess they are not blocking one another [20:23] backend effort for you :-) [20:24] the connect would also ideally explicitly clarify whether we were in an authentication situation [20:25] backend effort for you: I mean we can do it but I expect it would be a day for someone else, not 1-2 hours [20:25] so what would gui need... [20:26] * bac reboots [20:26] it would change the connect handshake to be able to handle the new authentication possibility [20:26] it would need a new authentication command [20:27] it would need to show a login on the connect handshake that specifies authentication is required [20:28] and not much of anything should be rendered or hooked up until the authentication is successful [20:28] hm...losing the websocket connection will be much more painful... [20:28] we'll need to disable any changes and show the login immediately [20:28] or stash the password [20:30] gary_poster: let me know when you're ready for our call [20:30] benji I am in hangout from calendat [20:30] r [20:31] gary_poster, re gui.. first thing is login dialog [20:31] as interceptor to dispatch rulz [20:31] conditional on presence of authenticated websocket [20:31] gary_poster, we can store user name password in browser session [20:32] use name password: ok [20:32] the interceptor stuff is basically a route match to "*" that doesn't let the next rule match proceed [20:32] if login isn't there.. it will just do the login dialog display [20:32] interceptor to dispatch rules: which ones? oh, you mean in app. yeah ok, +1, I like it [20:33] hazmat, you agree that backend will explicitly say in connection that it wants authentication, yeah? [20:34] gary_poster, sure.. it can do a challenge [20:34] imap style [20:38] hazmat, show me what you want that to look like over the wire to juju, starting with the initial connection, and (even though I feel this one is more obvious) what the command looks like, and we can start with the gui part. do you want to write the juju/rapi part or do you want us to? [20:39] gary_poster, i'll do it. [20:40] cool hazmat thanks. can you give us the wire spelling today--at least high approximation--so we can start with the gui before then? [20:41] gary_poster, sure working on it now [20:41] awesome thank you [20:51] gary_poster, something along these lines.. http://paste.ubuntu.com/1397723/ [20:51] ack hazmat, will run with it. thanks [20:52] there's an odd bug in the gui atm.. it requests get_endpoints like 5 times in the initial render.. [20:52] with the same parameters.. quite odd [20:53] hazmat, will take a look. [20:54] Makyo, thanks [21:46] running away [21:46] never took lunch [21:46] will do some work later in the evening anyway [21:46] bye all [21:52] gary_poster, cheers [22:53] hazmat, get_endpoints is requested whenever a service is added to the db (which happens 5 times with the first delta on the default improv script). [22:55] Could move it to on_delta and only call if a service has been added, perhaps? [22:55] Oops, little late, I suppose. [23:03] Makyo, it should get moved from add_service to delta evt sub [23:03] hmm [23:04] well that helps initially but subsequently it needs some better logic.. [23:04] i think i had a proposal on the merge proposal for it.. [23:04] Makyo, that sounds reasonable re on_delta w/ service add [23:08] hazmat, Alright, I'll look into it. [23:08] Makyo, yup that should be perfect.. move 2 on_delta subscriber, and compare endpoint map to service map break on new svc in service_map [23:08] and update [23:09] Delta should have whether or not a new service was added, right? [23:09] there's some gc stuff there as well, but that doesn't need the rpc [23:10] Makyo, in the delta subscriber.. (on_database_changed i think?) .. you'll need to compare the endpoint map (svc name keys) to the services in the db (key iteration).. if any adds, request the endpoints.. if dels remove from svc map, else pass. [23:11] s/svc map/endpoint map [23:13] hazmat, oh, I was figuring it'd be easier to see if there was a service add in the delta received since that would mean less matching-up of services. Can do either. [23:16] Makyo, i was just trying to keep the logic in the same place in the app.js.. the other needs the endpoint map/app ref to move into the db.. its pretty reasonable to consider this a db function though.. your choice [23:16] hmm [23:16] currently the db doesn't ref the env connection [23:17] given that its probably simpler to just update the logic in app.js .. since it has all the pieces needed (db, env) [23:17] Alright. [23:19] we've tried hard not to get spaghetti references from various components.. but it feels a bit torturous when we have to move responsibilities out of their obvious location. [23:21] i'm curious what folks would think about we need to have some form of global(ish) resolving/addressing function.. ala zope's getUtility.. a resolve method that can lookup components.. so we could do resolve('app') .. resolve('db') instead of reference passing. [23:24] Makyo, hmm.. another way that matches well with what you referenced.. is to just do it the delta processor.. and fire an event up to the app after processing all new svcs to update the endpoint map [23:25] hazmat, oh, like fire a service_added event that the app could listen for and update endpoints? [23:25] Makyo, its a bulk event or we end up in the same place we are today [23:25] its got new svc names, old svc names... the old names are nesc to gc the old entries from the svc endpoint map [23:25] hazmat, yeah, do it alongside firing update (which is what triggers on_database_changed) [23:28] gc can take place in the db, though, correct? That doesn't need rpc. [23:28] right. it doesn't rpc.. but the endpoint map would need to move to the db.. [23:30] looking at the db code.. its not clear there is a good place for this logic.. [23:30] on_delta there would need to grow service obj specific code and keep a set.. [23:31] which feels a bit icky.. given how generic and clean it is atm [23:31] and the list class just gets a single delta.. [23:34] Makyo, i'd recommend just doing it in app.js for now .. afaics its the simplest thing that works.. moving it to models.js is just going to complicate the sync logic.. which is nice to keep simple for now.. hopefully at some point we'll have some indexed db logic in there for some 3 way merge fun. [23:35] Alright