=== gary_poster|away is now known as gary_poster [13:26] ok, in addition to having my opinion of System 76 machines reinforced, now my opinion of Dell machines is reinfirced. :-/ [13:32] gary_poster: +1 all the way around [13:32] :-/ [13:33] at least in laptop land [13:33] That was what I was thinking--if I got a desktop I'd be fine [13:33] No such luck this time around, anyway [13:33] yea, I did go with system76 for a desktop and ok. Laptops though I'm still not a fan yet. Seen too many issues and build isn't as solid as I'd like [13:34] I don't know who to use for desktops now. Laptops I'm Apple, and Lenovo otherwise, from here on out until convincing evidence is given. :-) [13:35] that's what I've got written down (reverse order) [13:36] heh [14:01] frankban, hey. replied to Wm's email about the GUI authentication issues. Curious about your thoughts, including whether you'd like to set up a meeting with him to explore more. [14:01] gary_poster: looking [14:02] ty [14:04] morning [14:04] party [14:05] hiya [14:19] is there a way to get askUbuntu to email me every time something happens on a thread I've interacted with? [14:24] This weekend I found myself wanting 'to' functionality in the GUI [14:25] because quickstart is in juju-stable will it be in universe in 14.04? [14:26] it was a goal I thought so that it helps you get juju installed [14:26] I was thinking that it NEEDS to be in there haha, the quickstart story i just too awesome not too [14:27] yea, jcastro showed it off and had some <3 for it end of last week [14:27] `apt-get install juju-quickstart && juju-quickstart ghost-bundle-simple` is an awesome story [14:28] yep [14:58] hatch: I just sent an email about oddities I've found while working on the server side basic HTTP auth for the putCharm functionality. Could you please take a look? [14:59] yup reading it now [15:06] frankban just to clarify - does option 1 work in firefox 100% of the time? [15:06] or does it also fail the first time [15:07] also fails first time, according to email [15:08] gary_poster, hatch: right, also first time [15:08] hmm [15:08] looking into this [15:09] hatch: thank you, it would be nice if you are able to reproduce that [15:09] I'd need the charm, have you uploaded the version where this is happening? [15:10] frankban: looking for bugs. so far only found http://stackoverflow.com/questions/9459017/xmlhttprequest-authentication-not-working-in-firefox : 2012, so old, and no resolution. [15:12] frankban: OPTIONS call? http://stackoverflow.com/questions/19234892/xmlhttprequest-based-cors-call-with-basic-auth-fails-in-firefox-and-chrome [15:13] worth investigating charm log at least [15:13] that should only be required cross domain [15:14] hatch: lp:~frankban/charms/precise/juju-gui/http-proxy is what I have now. It would be nice if we can dupe that excluding the proxy, to ensure this is not a problem on the gui server side. e.g. pointing the GUI directly to the core API server [15:14] frankban I'm pulling down the charm now and will give it a go [15:14] true [15:14] hatch, frankban, but charm log coudl be informative [15:22] frankban the env is spinning up, I'll keep you posted [15:24] hey rick_h_ can you review https://pastebin.canonical.com/103628/plain/ before i submit the RT to see if i forgot anything? [15:24] bac: looking [15:25] rick_h_: i've verified there is no impact on CI so the window where qa and staging point to the same machine is unnecessary [15:25] bac: so we verified we can keep that IP if we have to rebuld staging/qa? [15:25] bac: that's the only part I have questions on in that. Looks good otherwise. [15:26] bac: I don't know how staging. is currently handled with a rebuilt/keeping the IP in canonistack [15:26] rick_h_: we currently control the IP used by staging.j.c. it is assigned in the deploy script to the apache instance. the revno is subsequently updated by using juju, so the FQDN is never used again. [15:26] bac: ah ok then [15:27] so the name can change and no one notices or cares, except those of us who want to hit it [15:27] right [15:27] ok, i'll submit pretty much as is. i just didn't want to file an RT with obvious holes. [15:28] bac: yea, looks like what we talked about here [15:28] simplified [15:28] right, because we control the IP address it makes things easier? [15:29] rick_h_: well because the name 'staging' is not used in any of the CI machinery [15:30] bac: right cool [15:36] gary_poster: do we have a departmental meeting with IS? [15:37] bac, every other thursday. cancelled this week because they are out. Do you have somethng to raise? [15:38] vim's recording 'feature' has to be the under the worst key possible lol [15:38] gary_poster: yeah, i filed an RT for getting staging on prodstack. asked spads what else to do to get it scheduled and he said to raise it in that meeting. [15:38] heh, it has bitten me more than anything else in vi as well, yes, hatch [15:38] gary_poster: i don't think we want to wait 2.5 weeks to get it on the radar [15:39] bac ack. I can ask mramm to escalate to robbiew, who can set priority. gimme rt? [15:39] gary_poster: RT 67257 [15:39] bac, ok. will cc you. [15:40] thanks === arosales_ is now known as arosales [15:41] bac, staging.jujucharms.com is confusing naming IMO and FWIW. staging.manage.jujucharms.com? managestaging.jujucharms.com? ugh, I know, but we will probably want staging for GUI jujucharms also, unless it is wiped out in favor of other sites soon. [15:42] that's not important for me escalating--just a comment/thought [15:42] gary_poster: good point [15:45] gary_poster: I am still debugging. re: GUI/quickstart auth, I like your idea, a command like that can be used also by quickstart. curious to see if they come up with other ideas [15:45] cool frankban thx [15:45] gary_poster: ok, i'll modify to request staging.manage.jujucharms.com and qa.manage.jujucharms.com. what a mouthful. [15:45] frankban ok I finally got this thing up and running and am getting a 400 when trying to upload the charm [15:46] :-) k thanks [15:47] gary_poster: bac in the prioritizing, can we keep the 'move jujucharms to juju-core' above this? [15:47] rick_h_: ack, +1. rt please? [15:47] rick_h_: +1 [15:47] hatch: 400? how did you create the zip? [15:47] gary_poster: 67167 [15:47] thanks [15:48] hatch: FWIW, the charm files must be at the root of the zip, e.g. it does not work if you compress the charm dir [15:48] thanks rick_h_. bac, rick_h_, I suggest making RT links on the kanban cards if you have not already [15:48] gary_poster: yep, full link is there [15:48] ack thanks, soory I missed it [15:48] frankban I downloaded the zip from github for my ghost charm [15:48] frankban I pinged you the url [15:50] hatch: what are the zip contents? does it create a root dir when you decompress it? [15:50] frankban well would that give me a 400 if they weren't? [15:51] what should I look for in the charm to make sure I have the proper one deployed? [15:51] hatch: what's the content of the response body? [15:51] {"Error":"invalid charm archive: bundle file not found: metadata.yaml"} [15:52] well there ya go ;-) [15:52] hatch: exactly, metdata.yaml must be at the zip root level. [15:52] hah [15:52] ok that's not going to work [15:52] hatch: so you need to create another zip to test it [15:52] will do [15:52] buut we will need to allow it to be nested one folder deep [15:53] methinks that dragging a folder (and having us figure out what to zip) will be much less fiddly for users [15:53] +1 [15:53] +1 [15:54] though I think the idea of wget xxx.zip and deploy it will be more adminy-useful. [15:54] kind of like bundles where they're getting sent around via email you can more easily link/share a local/dev charm as a single file [15:55] jujugui call in 5? [15:55] bah thank you [15:56] frankban works with a single request in chrome [15:57] hatch: how do you see that it's a single request? [15:57] just looking in the network tab [15:57] looking in the charm logs now [15:58] hatch: ok [15:58] hatch: /var/log/upstart/guiserver.log [15:58] jujugui call in 2 [16:01] Makyo pingy [16:01] frankban ok I see the two requests in the guiserver logs [16:01] after the call I'll try firefox [16:01] hatch: cool [16:12] frankban unfortunately I can reproduce your issue with Firefox but Chrome works 100% of the time [16:13] hatch: Firefox version? [16:14] frankban OSX 26.0 [16:15] it has the issue, open firebug, works no problem :/ [16:15] hatch: re python gcc errors: try installing libpython-dev, if that fixes the issue please add it o sysdeps [16:15] uable to find package [16:16] hatch: libpython2.7-dev [16:17] ? [16:19] frankban https://gist.github.com/hatched/8651673 these are all the packages I have available [16:20] hatch: just python-dev? [16:21] installing [16:21] hah [16:21] hatch: so, were you able to dupe the problem in FF? [16:21] frankban yes, now trying to track down the issue because clearly this is unacceptable [16:22] hatch: cool thanks, weird the firebug thing [16:22] yeah....and you were saying that the same issue happens with option 2? [16:23] hatch: yes, with option 2 FF just refuses to include the auth header in the first request [16:23] hatch: but you can dupe that too switching to juju-gui-debug=true and applying that diff [16:24] yeah, I'll take your word for it for now, just doing some research [16:24] hatch: I'd be curious to see what's the IE behavior [16:24] I can spin IE up after my next call [16:25] unfortunately I feel like I'm coming down with a cold so brain is moving a little slow haha [16:27] heh [16:28] frankban ok I'm going to apply the diff and see option 2 - firefox strips the auth headers unless the server responds with a 401, it then should make another request with the headers [16:29] hatch: so firefox don't trust us [16:29] it doesn't :) but it SHOULD be making the second response after the guiserver responds with the 401 [16:29] but it doesn't appear to be doing so unless firebug is open [16:31] luca_: https://plus.google.com/hangouts/_/canonical.com/discuss-local ? [16:32] rick_h_: Makyois sick [16:32] gary_poster: thank you :) [16:32] welcome :-) [16:32] frankban I guess a hacky workaround is to have it try twice :/ [16:33] gary_poster: ok, thanks for the heads up [16:43] hatch: I think we are hitting https://bugzilla.mozilla.org/show_bug.cgi?id=901342 [16:45] hatch: if you send a string in place of the zip file, the second request is correctly executed. Also note that the firebug network tab is mentioned in the bug comments too :-/ [16:46] frankban hah, in call, will read in a bit [17:08] frankban ok off call, reading now [17:09] frankban I would agree that's the same bug [17:09] hatch: yeah, tried changing the GUI to send a random string and the second POST request is corretcly sent by firefox [17:09] ok, so....workaround is to try multiple times? [17:10] I'll also add the most recent version of firefox to that bug [17:10] yuck I hate writing hack code to workaround bugs [17:10] bleh [17:11] frankban I'm spinning up a windows 8 vm to test there [17:12] hatch: sending the file contents? [17:12] frankban well we try once, if it doesn't resolve to 200 in x seconds then try again [17:13] that 'should' workaround the firefox issue [17:13] hatch: 200 or 400 or 500... [17:15] hatch: and now IE... at least it seems the proxy works well [17:16] yes we'll need to check those other responses as well. [17:16] yep testing Ie now [17:16] yeah the proxy seems to work just fine :) [17:17] hey juju-gui, is bac likely to be back online today? have some questions about some ingest code of his. [17:18] jcsackett: should be [17:18] jcsackett: his interwebs hate him [17:18] frankban it looks like Windows can only (natively) turn a folder into an archive so if the charm has to be the root in the zip then that's not a very good story in Windows. This was a limitation of the juju-core implementation? [17:18] rick_h_: awesome. i'll shoot him an email then so he and i can link up whenever he's back. [17:18] thanks. [17:21] hatch: yes, we can propose core devs to change the API like the following: if the zip root includes only a directory, assume the charm is included in that directory. the directory name should not be relevant [17:21] right ok good I'll file a bug to that effect [17:21] hatch: cool thnaks [17:22] at the moment I'm having issues with my ie vm connecting to my juju instance [17:22] sorry for the delay [17:22] hatch: np [17:22] * rick_h_ goes to have a lunch shoveling snow while he waits for his snow blower to arrive [17:22] lol [17:24] hatch: FYI I noticed that if an error occurs core returns a 400 code and the details can be found in the response body. we need to handle that case, maybe just adding an error notification [17:24] ok sounds good, I wasn't entirely sure the structure of the response but now that we have it it's easy to check for. [17:24] sure [17:38] ugh I hate Windows [17:38] I can't seem to get this tunnel to work [17:56] yay finally got the tunnel to work [17:56] should have known to just done it in the host [18:06] frankban just FYI it looks like there is an issue with the .zip upload in IE but the inspector is....well it's the IE inspector lol [18:31] frankban here is the error from IE when I try to upload a zip https://gist.github.com/hatched/b80599004f52d3464458 does this look like an error from juju-core/guiserver? The IE inspector is being pretty useless so I'm having a hard time tracking it down [18:34] gary_poster https://bugs.launchpad.net/juju-gui/+bug/1273363 IE11 show non-supported browser window....I'll let you decide if this is an issue or not :) [18:34] <_mup_> Bug #1273363: Non-supported browser warning on IE11 [18:34] hatch: does everything else work? [18:35] hatch, nm: I will add IE 11 support to huw's list, and see if he's willing :-) [18:35] gary_poster nope there are some d3 issues [18:35] at least that's all I've found [18:35] hatch, darn. ok thanks [18:36] so it IS broken so that's a good thing the warning is there [18:36] yup [18:36] though we should maybe suggest IE 10 also :-) [18:38] yeah that's probably a good idea [18:41] frankban ok I've figured out why IE doesn't work for dropping the zip.... IE calls zips "application/x-zip-compressed" not "application/zip" [18:42] Ugh. Alright. Half-here. Will be all-here once meds kick in. [18:43] Makyo: hey, good meds I hope. If you get a sec would appreciate a pointer to the location of the code you reference in the reafctor card for "Finding the real position from canvas coordinates" [18:43] Makyo: my git-fu is failing to find something promising [18:43] rick_h_, sure thing! One sec. [18:44] hatch: uhm, thanks for investigating [18:44] frankban I'll take over getting the fix landed for that [18:45] frankban after adding python-dev I was also able to get make check to run on quickstart thanks [18:45] so-much-multitasking [18:45] hatch: cool, :-) [18:46] frankban maybe 2h before our daily tomorrow you can give me a walk through of the execution order of quickstart? [18:49] 3 vm's running and this thing is still humming along [18:49] vroom vroom [18:49] Oh for pete's sake. [18:58] bac: can you look at https://code.launchpad.net/~jcsackett/charmworld/fix-trigger-test-criteria/+merge/203401 [18:58] jcsackett: sure [18:58] thanks. [19:04] jcsackett: done and thanks. [19:26] rick_h_ it looks like your neighbours across the street are lazy at snow removal :) [19:27] hatch: heh, he's got a giant john deere two stage thrower. I think he waits for it to get high enough to be able to use his beast and then just does 3 passes and calls it a day [19:27] lol [19:28] and when I see him out I beg him to run his giant machine in front of the mailbox [19:28] community mail there? [19:29] ? [19:29] we all have a mailbox and mail person that delivers each day [19:29] not sure what makes community mail or what other options there are [19:30] ohh now I See, sorry I didn't look close enough [19:33] rick_h_ the new areas here have a single mailbox which you have to walk to instead of curbside or at the door mailbox [19:33] is what I meant about a community mail [19:33] ah, yea that would stink [19:33] benji, rick_h_: i've added a note regarding the deployment issue to our google doc with the rollout instructions. please be aware of it if you request a deploy in the near future. [19:34] bac rgr [19:34] k [19:34] rick_h_: sadly deej is not going to be around to work on it this week. :( [19:34] rick_h_ haha I agree it would [19:35] bac: bummer, hate this stuff hanging over our heads [19:36] yep [20:20] I wonder if juju will run in a vagrant instance [20:21] hatch: they've got images for that [20:21] hatch: http://blog.utlemming.org/2013/12/beta-cross-platform-juju-development.html [20:22] cool I'll have to check those out. Until I can get an on-metal version of Ubuntu working vagrant images seem like the most efficient way of working on various juju bits [20:22] actually, even after I do it would probably still be the best [20:24] mdn.microsoft.com now requires you to log in to read the docs.... FAIL [20:24] msdn that is [20:31] jujugui review please https://github.com/juju/juju-gui/pull/87 I think I found the code Makyo was referring to. Makyo if you're up for a review would appreciate your eyes to make 100% sure it's the right things. [20:31] Yep, on it rick_h_ [20:32] man, ignore your trusty vm for a few days and there is hell to pay. so much updating. [20:32] bac: hah, tis true [20:32] it's like one of those damned japanese toys you have to feed [20:32] just hope it didn't die from neglect and now it can't come back to life [20:33] * rick_h_ updated the laptop to trusty this weekend so out of stable machines. Crosses fingers [20:36] rick_h_ you updated your work machine to non-stable env? lol [20:36] rebel! [20:37] hatch: both of them man, it's crazy [20:37] bac what do you use to clean your laptop screen? [20:37] will have to stagger updates [20:37] lol! [20:37] rick_h_, how's it been so far? [20:37] I usually wait months before updating to the newest STABLE version haha [20:37] hazmat: trusty? so so. Just got lxc juju working today with the 'manually create /etc/lxc/auto' trick and latest golxc [20:37] hazmat: other than that been fine [20:38] hatch: hah, i use the squirt bottle i bought from sunglasses hut for $5 b/c they promised free refills and a microfiber. luckily there is SG Hut 1/4 mile from here so i will make them refill that sucker until i get my money's worth. [20:38] rick_h_, cool, good to hear. i'll probably wait few weeks, but planning on diving early [20:39] that said,i think windex and a rag works really well [20:39] haha ok, so some diluted rubbing alcohol it is then! I was going to try the same but I wasn't sure....apple and all haha [20:39] hazmat: yea, laptop was kind of on rarind and ran into some issues with old python so jumped [20:39] raring [20:40] hatch: it's just glass. [20:40] well, sort of [20:40] bac no it's squishy [20:40] I thought it was glass too [20:40] haha [20:40] hatch: it's magic apple glass. You have to take it to an apple store for cleaning or void your warranty :P [20:40] rofl [20:40] I wouldn't put it past them [20:49] rick_h_: is this the problem with lxc/trusty that was supposedly solved: ERROR Get http://10.0.3.1:8040/provider-state: dial tcp 10.0.3.1:8040: connection refused [20:50] bac: no, that's a failed old environment. rm your .juju/environments/local.jenv I think [20:51] i don't have one of those [20:51] bac: also make sure `sudo lxc-ls` is clear of any lingering units [20:51] it is [20:51] :) [20:51] bac: is anything in .juju/environments? [20:51] wait it was local.jenv [20:51] thanks [20:52] cool [20:52] bac: and then sudo mkdir /etc/lxc/auto [20:52] will fix the last issue I had today [20:52] already did that [20:52] k [21:59] Morning [21:59] morning [21:59] ahoy huwshimi [22:13] sweet charm upload now works in IE11 [22:14] that was kind of a pita to debug, but the new IE11 debugger is leagues ahead of it's predecessor [22:14] jujugui looking for a review https://github.com/juju/juju-gui/pull/88 no qa necessary [22:15] cool hatch. any result on the FF issue? I didn't see a resolution [22:15] I will review [22:17] gary_poster we ran into what we think is this bug https://bugzilla.mozilla.org/show_bug.cgi?id=901342 but with the changes to fix IE appear to have fixed FF, I'm going to have to spin up my other ubuntu vm to check there too [22:18] hatch, so you mean the auth headers sem to have fixed FF? [22:18] I find when I open certain vm's together it kernel panics so gota do all this in order haha [22:18] heh\ [22:18] I saw the bug from frankban's email, yeah [22:18] gary_poster yeah, they are now working first time every time in OSX [22:18] OSX FF that is [22:18] awesome [22:18] Chrome always worked [22:19] IE11 required them....even though there is absolutely nothing wrong with how we were doing it before [22:19] :/ IE [22:19] hatch +1 with ultra trivials. Only downside to new setup is that making small changes feels so expensive now. :-( [22:19] but hey....if it works better...yay [22:19] definitely yay [22:21] lots of moving parts for sure - not to mention the required setup to build custom juju, custom charm, custom branch lol [22:21] I wish I had a vm with IE10 still....but it looks like Win 8 just auto updated me to 11 [22:21] maybe that's a good thing, everyone else with IE10 will be running 11 [22:22] heh ok [22:24] so the gui charm is using the tornado web server? [22:24] yes [22:25] well the good news is that it works properly according to the basic auth spec....unfortunately browsers don't haha [22:49] gary_poster the auth headers appear to have fixed it in Ubuntu FF which is odd because Francesco said that wasn't the case....but I'm sure he will test it again while working on the charm