[00:22] <evilnickveitch> arosales, hatch, gary_poster  thanks !
[00:46] <arosales> we'll catch you tomorrow evilnick
[01:27] <hatch> rick_h_: looks like parallels 9 supports 13.10 so i'll need to upgrade if I want to use it on there...just fyi
[03:36] <rick_h_> hatch: coolio
[11:01] <gary_poster> hey frankban.  thanks for charm branch.  sorry again for bad qa.  trying out your branch
[11:01] <frankban> gary_poster: I was going to reply to your email, it does not seem a bad qa IMHO, it seems just a network connection problem, the environment setup exited with an error
[11:01] <gary_poster> oh!
[11:02] <frankban> gary_poster: so the charm is good, the less good thing is that when setup exits with an error we should call setup again when the user runs, e.g. make unittest
[11:03] <frankban> gary_poster: so the branch I proposed is just a fix for that (remove the activate file if setup fails, so that next time setup is called, pip install is re-executed))
[11:04] <gary_poster> frankban, oh, so when no dists were found for lazr.authentication for some reason, which I missed because I was moving too fast, then everything above it (yaml and mock) were effetively aborted?
[11:06] <frankban> gary_poster: yes, I checked with a fresh lxc, and the dependencies are all correctly installed (I just found the missing rsync sysdep, added in the branch). so it seems pip install -r is transactional, so you were starting the test suite without any dependencies
[11:07] <frankban> gary_poster: also proposed a similar quickstart branch. the logic si the same: "Remove the activate file if the requirements installation process fails."
[11:09] <gary_poster> cool
[11:09] <gary_poster> trying charm build again
[11:09] <frankban> gary_poster: so good news, the charm does not introduce bugs in the testing infrastructure. bad news: PIP_DOWNLOAD_CACHE prevented my to find this problem earlier
[11:13] <gary_poster> frankban, ack.  Don't see a way around that unless we make the download cache shared. what do you think of having a PIP_DOWNLOAD_CACHE as a branch that the makefile checks out?
[11:13] <gary_poster> (or bzr ups)
[11:16] <gary_poster> frankban, lazr.authentication reliably fails for me. :-( http://pastebin.ubuntu.com/6415348/ investigating
[11:16] <frankban> gary_poster: with the branch I proposed, at least "pip install -r ..." is retried in case of previous errors. So, for example, the first "make" failed yesterday for you, and the subsequent "make test", instead of showing import errors, retries the requirements download.
[11:16] <gary_poster> ack, definite improvement
[11:22] <gary_poster> interesting.  https://pypi.python.org/pypi/lazr.authentication is only owned by leonard.  he didn't transfer. but...yeah.  I can't downoad that, for some reason.
[11:33] <frankban> gary_poster: here is the full verbose log of "pip install lazr.authentication" without cache in my local machine, if it can help: http://pastebin.ubuntu.com/6415408/
[11:34] <frankban> gary_poster: generated using "pip install -v --log lazrauth.log lazr.authentication"
[11:34] <gary_poster> ack thx looking at charm pip log too
[11:36] <gary_poster> frankban, charm log excerpt very diff: http://pastebin.ubuntu.com/6415421/
[11:37] <gary_poster> Could not fetch URL https://launchpad.net/lazr.authentication (from https://pypi.python.org/simple/lazr.authentication/): <urlopen error [Errno -2] Name or service not known>
[11:37] <gary_poster> !
[11:37] <gary_poster> https://launchpad.net/lazr.authentication loads fine in browser
[11:39] <frankban> Could not fetch URL https://launchpad.net/lazr.authentication/+download (from https://pypi.python.org/simple/lazr.authentication/): <urlopen error [Errno -2] Name or service not known>
[11:39] <frankban> oh, yeah
[11:40] <frankban> gary_poster: the same for https://launchpad.net/lazr.authentication/+download I guess
[11:41] <gary_poster> frankban, yes. and http://pastebin.ubuntu.com/6415433/
[11:42] <frankban> hum...
[11:42] <gary_poster> and http://pastebin.ubuntu.com/6415437/
[11:49] <gary_poster> frankban, what do you think of having a PIP_DOWNLOAD_CACHE as a branch that the makefile checks out, or ups?
[11:50] <gary_poster> lp:~juju-gui/juju-gui/charm-download-cache or something.
[11:53] <gary_poster> frankban, bizarrely, worked that time. :-/
[11:54] <gary_poster> still think download cache would be a good idea
[11:56] <frankban> gary_poster: huh? does it work now? yes I agree re the separate branch, medium priority? It's just for the tests and I'd like to understand why lazr.auth failed for you
[11:58] <gary_poster> frankban, yes it works now.  no idea why.  it can now access those pages when it could not before. :-/
[11:58] <gary_poster> frankban, separately https://codereview.appspot.com/26530043/LGTM
[11:58] <gary_poster> https://codereview.appspot.com/26530043/ LGTM
[11:58] <gary_poster> (with comment)
[12:00] <frankban> gary_poster: confused about the comment, how do you use $ACTIVATE to diagnose?
[12:00] <gary_poster> frankban, you can source the file and then use the venv's python to see if you can dupe the problem
[12:01] <frankban> gary_poster: aha! good suggestion, changing also the other quickstart branch then
[12:01] <gary_poster> cool
[12:04] <gary_poster> frankban, https://codereview.appspot.com/26540043/ also LGTM with trivial
[12:06] <frankban> gary_poster: great, thank you
[12:06] <gary_poster> welcome frankban.  replying to my own email about this.
[12:38] <frankban> gary_poster: both branches landed, thanks for the reviews and for the email! 
[12:39] <frankban> trying to build new quickstart packages now
[13:36] <gary_poster> rick_h_, will ping soon, sorry, still talking
[13:36] <rick_h_> gary_poster: np
[13:42] <jcastro> frankban, heya, so what's the plan for putting quickstart in the normal juju ppa?
[13:57] <gary_poster> benji, will be late sorry.  rick_h_ joining now
[13:58] <benji> gary_poster: no worries
[14:05] <jcastro> rick_h_, hey if you have time today, when the stuff lands in prod on jujucharms.com I'd like to write it up, maybe talk me through it over g+ later?
[14:06] <rick_h_> jcastro: rgr
[14:23] <frankban> jcastro: not sure about the plan, gary_poster can give a better answer when he's free from calls
[14:23]  * jcastro nods
[14:26] <bac> hi frankban, can you give me some advice on how to use and test @gen.coroutine?
[14:26] <frankban> bac: 1min
[14:31] <bac> frankban: grab this branch when you get a chance lp:~bac/charms/precise/juju-gui/increment-deployments
[14:49] <frankban> bac: looking
[14:54] <bac> frankban: clearly i'm not returning the values correctly.
[14:54] <frankban> bac: gen.Return is something you have to raise
[14:55] <bac> frankban: and then is it a real exception or is that a return mechanism?
[14:56] <frankban> bac: when you have a coroutine, you can either exit without values (without returning or just with "return" without values) or you can raise a gen.Return, that will be treated as a return value. This is a workaround to python2 not being able to use return in a generator.
[14:57] <gary_poster> jujugui, I need helpfrom someone who can test the charm upgrade.  I was going to try and do it but am swamped in calls.  You would set up charm r76 the way IS has it (https://wiki.canonical.com/InformationInfrastructure/WebOps/CDO/JujuGui) and then upgrade to the newest version of the charm and document what needs to be done
[14:57] <frankban> bac: in general, when you have a function decorated with gen.coroutine, the test is easier to write using the tornado.testing.gen_test decorator.
[14:57] <gary_poster> for webops
[14:58] <gary_poster> bac or benji, I can talk now with one of you, and move the other to the afternoon.  preference?
[14:58] <bac> gary_poster: same/same
[14:58] <gary_poster> ack
[14:58] <bac> gary_poster: so now or later?  :)
[14:59] <gary_poster> bac, benji's not responding, so let's do it now
[14:59] <bac> frankban: ok, i'll look for gen_test
[14:59] <benji> gary_poster: that's fine, we can go this afternoon
[15:00] <gary_poster> thanks benji
[15:00] <benji> gary_poster: but I do need a quick pre-imp on a card after you're done though
[15:00] <gary_poster> benji heh ok.  not a lot of time.  will squeeze in
[15:01] <frankban> bac: the idea with gen_test is that the test itself can use yield in order give the execution control back to the ioloop and wait for the result
[15:03] <bac> frankban: ok, on a call with gary_poster atm.  be back shortly.
[15:10] <frankban> gary_poster: I'll test the charm upgrade. So bzr revno 76 of lp:charms/juju-gui, juju-core environment and builtin-server=false, correct?
[15:10] <gary_poster> thank you frankban !  yes
[15:10] <frankban> cool
[15:10] <gary_poster> frankban, also note the ga-key instructions on that page
[15:12] <frankban> gary_poster: oh, so currently we are not using ga... ok so the new options are ga and builtin-server
[15:12] <gary_poster> yes
[15:12] <frankban> cool
[15:21] <hatch> Dart 1.0 was released today http://news.dartlang.org/2013/11/dart-10-stable-sdk-for-structured-web.html
[15:22] <hatch> so now we can port to Dart?
[15:22]  * hatch runs
[15:25] <hatch> Makyo: OneTab needs the ability to 'store' a single/group of tabs
[15:26] <hatch> It says it supports that but I can't figure out how :)
[15:31] <hatch> jujugui can I search commits on launchpad? I'm trying to find the commit to juju-core which added the unit details object
[15:33] <bac> hatch: much easier with bzr locally, no?
[15:33] <frankban> gary_poster: the old charm downloaded the gui release file v0.10.1. Is this surprising or am I missing something. I expected the old charm to download the last release. oh, maybe it was the last to be tgz?
[15:33] <hatch> bac: it's looking like it
[15:34] <frankban> yes it was
[15:34] <bac> hatch: do you know what file?
[15:35] <hatch> bac: well it was a series of them
[15:35] <bac> hatch:  you can do 'bzr log <path-to-file>' and it'll only show you commits that changed that file
[15:35] <hatch> if I could find the bug that would help either
[15:35] <gary_poster> frankban, yeah probably last tgz
[15:35] <frankban> gary_poster: do I have to simulate latest version, or just proceed with the upgrade?
[15:36] <frankban> gary_poster: maybe it's better to just go on. let's see
[15:36] <gary_poster> frankban, I think proceed is fine
[15:36] <frankban> ok cool
[15:37] <hatch> found it https://bugs.launchpad.net/juju-core/+bug/1224568
[15:37] <_mup_> Bug #1224568: Improve hook error reporting <juju-core:Fix Released by themue> <https://launchpad.net/bugs/1224568>
[15:37] <hatch> jeesh that took forever
[15:50] <Makyo> jujugui call in 10.
[15:51] <frankban> gary_poster: so revno76 does not work in juju-core (apache returns a 403, I guess it is related to the fact the gui was served from inside the charm directory.
[15:51] <gary_poster> frankban, so what they told us must be wrong?
[15:52] <frankban> gary_poster: they either fixed this issue or used another, less restrictive, version of juju-core
[15:53] <frankban> gary_poster: juju-core is another viarable now, but I remember we had a fix for the permission problem...
[15:53] <frankban> variable even
[15:53] <gary_poster> we did
[15:55] <gary_poster> frankban, you saw #webops?
[15:55] <frankban> gary_poster: yes, and confirmed, solved giving +ar to /var/lib/juju/agents/unit-juju-gui-0/charm
[15:55] <gary_poster> ack
[15:56] <frankban> gary_poster: so I think it worked at the time with an older juju-core, but then they introduced this restriction
[15:56] <gary_poster> ok
[15:56] <gary_poster> that rings a bell
[15:58] <Makyo> jujugui call in 2
[16:00] <gary_poster> rick_h_, pingy ping
[16:04] <adeuring> benji: could you have another look at my MP? The changes are big enough to need another review...
[16:05] <benji> adeuring: sure (I'm on a call now, but will as soon as I can)
[16:05] <adeuring> thanks!
[16:13] <hatch> frankban: is there a way I can inspect the web socket traffic from the juju-core side?
[16:16] <hatch> ahah I finally got it sending the information
[16:18] <frankban> hatch: if you bootstrap with --debug all the ws traffic is in the debug-log
[16:19] <rick_h_> hatch: or Makyo can I get one of you to do a first pass reviews on https://codereview.appspot.com/26290043/ w/o QA and just one for now. I've got to qa it all in a live env and I'll write up QA instructions once I make sure it all works right. Then I'll bug for two real reviews and a QA. 
[16:19] <Makyo> Sure
[16:19] <hatch> I'll take a quick glance
[16:20] <rick_h_> Makyo: thanks
[16:20] <hatch> oh Makyo you're on it
[16:20] <bac> hey frankban, i want to mock AsyncHttpClient.fetch() so that it returns a response with a non-200 code.  what thing should i actually return?  a Future?
[16:21] <hatch> rick_h_: don't like composition hey? ;)
[16:21] <rick_h_> hatch: what do you mean? 
[16:21] <hatch> I just had app.js open, you removed the mixin in favour of a utils file
[16:21] <rick_h_> hatch: oh, I don't like tools that don't need any access to object state and require building into a dummy object just to test :P
[16:21] <frankban> bac: yes, a concurrent.futures.Future (with a result already set)
[16:22] <rick_h_> hatch: right, but it meant that it was spread across views/utils, app, the extension, the topology, etc
[16:22] <hatch> yeah that was all over the place
[16:23] <rick_h_> hatch: but yea, I felt this cleans things up as I needed to be able to wrap all places that deploy a bundle into one path I could test and add a watcher to
[16:23] <rick_h_> and an extension didn't get me anything
[16:24] <hatch> yeah true true
[16:30] <Makyo> rick_h_, yeah, first pass looks good.
[16:30] <rick_h_> Makyo: cool, appreciate making sure there's nothing crazy while I get the QA stuff in order. 
[16:31] <hatch> rick_h_: do websocket frames wrap for you? It looks like it's broken in chrome
[16:32] <hatch> I'm asking because you're on dev :)
[16:32] <rick_h_> hatch: I'll have to look in a few. My charm is in progrerss of re-working due to changing the source 
[16:33] <hatch> sure no rush https://code.google.com/p/chromium/issues/detail?id=286419 claims it was fixed in chromium but it would be too bad if that wasn't back ported
[16:35] <hatch> ahh looks like they just have some bad css in the inspector now
[16:35] <hatch> I wonder if I can provide a patch...
[16:46] <benji> adeuring: I've finished looking at the branch.  I supplied a diff that you can use to add some comments to the new tests if you like.
[16:46] <adeuring> benji: thanks!
[16:47] <rick_h_> frankban: still around?
[16:50] <frankban> rick_h_: yes
[16:50] <rick_h_> frankban: nvm, found it. Case mis-match in grep 
[16:50] <frankban> ok
[16:55] <rick_h_> jcastro: your bundles for jenkins and mediawiki still have the cpu= constrints
[16:56] <jcastro> ack, I'll blow em away in a minute
[16:56] <rick_h_> jcastro: thanks
[16:59] <frankban> gary_poster: juju upgrade-charm + juju set juju-gui ga-key=UA-1018242-44 builtin-server=false run ok. to be noted that in the process the latest (local) release of the GUI was also installed
[16:59] <hatch> does anyone know of any broken charms or a way I can cause an error in a real env?
[16:59] <rick_h_> hatch: how so? We try not to ingest broken charms 
[16:59] <rick_h_> hatch: how are you looking to trigger an error?
[16:59] <gary_poster> hatch, mediawiki broke for me yesterday :-/
[17:00] <hatch> trying mediawiki
[17:02] <gary_poster> frankban, yay, thank you. so, looking at https://wiki.canonical.com/InformationInfrastructure/WebOps/CDO/JujuGui at bottom... sorry, on call, one sec...
[17:04] <hatch> I think we need to write some broken charms to test hook failures and the like
[17:04] <gary_poster> frankban, I am going to edit the instructions and then ask you to approve diff
[17:04] <frankban> gary_poster: ack
[17:05] <gary_poster> thx
[17:13] <hatch> unfortunately mediawiki worked just fine :/ hah
[17:19] <gary_poster> sorry :-)
[17:19] <gary_poster> hatch make a charm and break it?  use an old revision of the juju gui charm that doesn't support juju core?
[17:20] <hatch> I'd really like a testing charm which allows us to test failures
[17:20] <hatch> I have the string format of the StatusInfo
[17:20] <hatch> but StatusData is implementers choice :)
[17:21] <gary_poster> frankban, http://paste.ubuntu.com/6416799/ has ballpark side-by-side diff, which omits chars over 80.  http://paste.ubuntu.com/6416801/ is new.  http://paste.ubuntu.com/6416811/ is original.
[17:21] <frankban> gary_poster: looking
[17:21] <gary_poster> hatch, so make a testing charm! :-) or use an old revision of the charm you made that was broken at one point, or introduce a new error in a branch of it
[17:22] <gary_poster> I can push it up if you want :-)
[17:22] <gary_poster> thank you
[17:25] <hatch> pssht, I don't write broken anything
[17:25] <hatch> :P
[17:25] <gary_poster> :-)
[17:25] <hatch> yeah I'll write a broken one
[17:27] <frankban> gary_poster: the new instructions look good. the only thought I have is that currently they have juju-gui-source set to something (a url IIRC). maybe we want them to switch to local? 
[17:28] <gary_poster> frankban, ah!  yes, thank you.
[17:28] <gary_poster> great catch
[17:29] <frankban> gary_poster: in my test, I did not set juju-gui-source, so my test worked well with stable. I'd assume it should work also fi they switch on the fly from url: to local.
[17:29] <gary_poster> ok thanks
[17:30] <frankban> np
[17:41] <bac> frankban: hey got a sec still?
[17:41] <frankban> bac: on call, will ping you
[17:41] <bac> ok, thanks
[17:56] <gary_poster> charmworld update starting now-ish. eek
[17:58] <rick_h_> charmworld? or the jujucharms.com?
[17:58]  * rick_h_ looks again
[18:01] <bac> wow, condesation from my cup fell on my MBP track pad and it went crazy with fantom events.
[18:01] <bac> s/condesation/condensation/
[18:03] <jcastro> rick_h_, oh bummer, in the jenkins bundle the constraints are blank
[18:03] <jcastro> does that still mess stuff up?
[18:04] <rick_h_> jcastro: that's ok, but the cpu one gets rejected
[18:04] <rick_h_> so you can't deploy it
[18:04] <jcastro> oh right!
[18:04] <jcastro> it's cpu-cores
[18:04] <jcastro> on it
[18:08] <hatch> evilnickveitch: can you pm me your email and I can get you the list which was made 2 weeks ago
[18:08] <hatch> then I can expand on it later
[18:12] <frankban> bac: ping
[18:12] <bac> hi frankban
[18:13] <bac> frankban: can you look at this real quick http://paste.ubuntu.com/6416921/
[18:13] <frankban> bac: sure
[18:14] <bac> frankban: i expected calls to increment_deployment_counter to return a boolean but instead i'm getting a tornado.concurrent.TracebackFuture
[18:16] <frankban> bac: ok = yield utils.increment_deployment_counter(bundle_id, cw_url)
[18:17] <frankban> bac: it seems yield is missing: each gen.coroutine returns a future
[18:18] <bac> frankban: ah, right!
[18:19] <frankban> bac: also you can use mock.Mock(return_value=BadResponse) instead of defining your own mock function. <shrug>, but then you can take advantage of assert_called_once_with
[18:20] <evilnickveitch> hatch, ok
[18:21] <frankban> (and IIRC FakeResponse can also be mock.Mock(code=404)) etc...
[18:22] <gary_poster> frankban, jujugui, jujucharms has new stuff.  yay!
[18:23] <rick_h_> gary_poster: woot!
[18:23] <frankban> great!
[18:23] <rick_h_> gary_poster: now to send the email "STAY OFF COMINGSOON IN FRONT OF CUSTOMERS" :)
[18:23] <rick_h_> or large tech conference gatherings 
[18:24] <frankban> gary_poster: so from now on updating jc.com will also mean updating the GUI there. sounds cool
[18:24] <gary_poster> frankban, you mean 'cause the tarball is there, yeah
[18:24] <frankban> gary_poster: yes
[18:25] <frankban> cool, time to go, bac: is everything ok?
[18:26] <bac> frankban: yes!  i may ask someone here to review it but ask you to do a 2nd tomorrow.
[18:26] <frankban> bac: ok
[18:30] <gary_poster> hatch, you have been volunteered to brainstorm about Le Web. :-) if you have any ideas, please follow up with that mail from Sally
[18:30] <hatch> on it
[18:31] <gary_poster> thanks
[18:40] <rick_h_> oh oh oh, it's working finally!
[18:45] <frankban> gary_poster: just noticed bundles don't work in jc.com: Object #<PythonEnvironment> has no method 'deployerImport' . we might want to ask for an apiBackend change in config js and/or applying a patch like this http://pastebin.ubuntu.com/6417214/ to the charm (not tested)
[18:46] <gary_poster> frankban, ah frak :-/ thanks will pursue
[18:48] <frankban> gary_poster: ok thanks, have a nice evening
[18:48] <gary_poster> tahnks frankban !
[18:48] <gary_poster> you too!
[18:49] <rick_h_> jcastro: does the discourse charm take a while to setup in a live deploy?
[18:52] <rick_h_> jcastro: nvm, github goes boom and this charm goes with it :/
[19:16] <jcastro> rick_h_, yeah, about 20 minutes
[19:16] <jcastro> rick_h_, it doesn't do much until it relates to postgres
[19:16] <jcastro> then it does a bunch of stuff
[19:16] <rick_h_> jcastro: yea, one of it's deps hit github which was 500'ing and it took a LONG time to timeout and die
[19:16] <rick_h_> jcastro: yea, just testing it as a bundle and making sure my in-progress/bundle complete notifcations are working
[19:16] <jcastro> yeah, well, it's rails, the entire platform depends on the right dice roll of servers being up
[19:17] <rick_h_> yea
[19:19] <gary_poster> jujugui, looking for quick charm review of https://codereview.appspot.com/26430044/
[19:19] <bac> i will
[19:19] <gary_poster> thank you
[19:20] <gary_poster> hey benji.  ready any time.  sorry.  lemme know when you are ready
[19:20] <bac> gary_poster: quick enough?
[19:20] <benji> gary_poster: sure, one minute
[19:20] <gary_poster> bac :-) thank you yes
[19:21] <gary_poster> Makyo, approved swap
[19:21] <Makyo> gary_poster, ty :)
[19:22] <gary_poster> it was a hard choice ;-)
[19:22]  * gary_poster moving all releasable kanban cards to done...leankit is working hard...
[19:22] <gary_poster> heh, "An error occurred while cards moving."
[19:23] <gary_poster> Our massive card mountain proved too much for the poor little kanban board...
[19:24] <benji> heh
[19:26] <gary_poster> jujugui, the releasable lane is clear :-) (much rejoicing etc.)
[19:37] <rick_h_> hatch: Makyo ok, I think I've fixed the final issue. QA instrucitons noted in the MP now https://codereview.appspot.com/26290043/ if you guys can start review
[19:38] <rick_h_> hatch: Makyo I'm running my hopefully finally fresh QA from scratch, but the code is near enough final and ready for full review and such. Only need one QA if hatch wants to bribe Makyo to do it for him :)
[20:02] <bac> benji: i manually hit some URLs on staging yesterday to increment metrics and saw them work by getting the 'total'.  today they are back to zero.  is that expected?
[20:03] <hatch> rick_h_: ok I'll do the review first and see where that gets us
[20:03] <bac> hatch: man, that mayor in toronto is getting classier by the day!
[20:04] <hatch> bac: hah, I don't really follow it but it sure sounds like he likes to party
[20:05] <rick_h_> bah, one more thing to fix
[20:06] <rick_h_> jcastro: so nope, can't have the empty constraint values. Thave have to be legit
[20:15] <jcastro> rick_h_, .... so basically, you need me to remove them entirely?
[20:15] <jcastro> rick_h_, is this a deployer bug?
[20:16] <rick_h_> jcastro: it's a mix I think. Yes, we should remove them as that'll update in 15min vs a production deploy
[20:16] <rick_h_> jcastro: the thing is that Go won't accept an empty value for the key
[20:16] <jcastro> ok so you want me to do it now?
[20:16] <rick_h_> jcastro: so we should probably rip empty ones out along the path to juju-core before it gets them
[20:17] <rick_h_> jcastro: yes please, they're up in the store for people to see and they won't work
[20:17] <rick_h_> and we've been telling sales folks to use them to demo, but if they do it in a live env, it'll die
[20:17] <jcastro> wait, what?
[20:18] <rick_h_> right now, is someone were to bootstrap an ec2 env, and deploy your bundle, it'll fail silently
[20:19] <jcastro> done!
[20:19] <rick_h_> jcastro: ty much kind sir
[20:21] <bac> rick_h_: did you say jcastro's cloudfoundry bundle was super slow to deploy?
[20:21] <rick_h_> bac: yea, takes about an hour to finish I think
[20:21] <bac> grrr
[20:22] <bac> i used it for a test since it only has one service
[20:22] <jcastro> bac, it takes an hour
[20:22] <jcastro> if you want a fast one do mediawiki
[20:22] <bac> jcastro: yours?
[20:22] <jcastro> mediawiki-simple to be precise
[20:22] <rick_h_> bac: lol, looks can be deceptive
[20:22] <jcastro> yea
[20:22] <hatch> rick_h_: is putting each param on a new line some python thing? :P
[20:22] <bac> jcastro: mediawiki bundle?
[20:23] <rick_h_> hatch: :P it's a reads nice thing when you can't fit on one line to start 
[20:23] <bac> ah, mediawiki-simple
[20:23] <hatch> haha
[20:23] <jcastro> bac, if you have it locally please bzr pull, I just updated it about 2 minutes ago
[20:24] <bac> jcastro: i need to deploy from staging for my test
[20:31] <benji> gary_poster: ooh, one other thought I had in my notes: the "connect to a local juju environment from the GUI" feature doesn't have to be limited to the LXC provider, therefore we can let people manage their own EC2 (or private cloud) from a hosted GUI
[20:32] <gary_poster> true, benji
[20:32] <gary_poster> thanks
[20:37] <rick_h_> gary_poster: heads up, filing this on the charm, but might be a deployer fix, not sure atm. https://bugs.launchpad.net/charms/+source/juju-gui/+bug/1251420
[20:37] <_mup_> Bug #1251420: reporting an error from the environment isn't formatted well <juju-gui (Juju Charms Collection):Triaged> <https://launchpad.net/bugs/1251420>
[20:38] <gary_poster> ack rick_h_ thx
[20:38] <rick_h_> gary_poster: going to move forward with my branch as is, it shows that poor error message to the user for now since it's not my branch's fault? Is that ok or would you prefer I hide the message for now?
[20:40] <gary_poster> rick_h_, go forward, thx.  what you see is <Env Error - Details:\n { u'Error': u'json: cannot unmarshal string into Go value of type uint64',\n u'RequestId': 1,\n u'Response': { }}\n > ?
[20:40] <rick_h_> gary_poster: yea, you see "The deployment errored: xxxxxxxxxxxx"
[20:40] <rick_h_> in the notification dropdown
[20:41] <rick_h_> jcastro's bundles working all my code paths in QA so well :)
[20:41] <jcastro> rick_h_, I am debating stealing maarten's and putting them in there
[20:41] <gary_poster> jcastro, I copied quickstart to https://launchpad.net/~juju/+archive/stable
[20:41] <rick_h_> jcastro: cool, gary has a working version of a couple of them I think
[20:41] <jcastro> but I don't want to just shove them in there because
[20:41] <jcastro> I'd rather have "real" ones that people actually use
[20:42] <jcastro> instead of "here's what I think big data should look like even I know nothing about big data."
[20:42] <jcastro> gary_poster, \o/
[20:42] <gary_poster> yeah jcastro I put some of Maarten's in "demo".  Can add more if you like.  https://jujucharms.com/sidebar/search/?text=demo
[20:42] <jcastro> rick_h_, wanna sync up on G+ wrt. quickstart? I'd like to write it up now that everything is landed
[20:42] <rick_h_> jcastro: sure thing
[20:43] <gary_poster> ok quitting time.  ttyl
[20:43] <rick_h_> gary_poster: have fun
[20:43] <gary_poster> thanks you too
[20:43] <jcastro> https://plus.google.com/hangouts/_/7ecpjr7uvbg386q48qdcdnf7qc?hl=en
[20:55] <bac> jcastro: on ec2 how long should it take to see some action when deploying your mediawiki-simple bundle?  i got nothing.
[20:56] <jcastro> it's about 7 minutes for the bootstrap
[20:56] <jcastro> and then after that they should come up quicklyish. 
[20:57] <rick_h_> bac: wait on ingest cycle, it's got a constraints bug in it atm
[20:57] <bac> jcastro: that's deploying from the gui?  i've hit the deploy button, it was acknowledged, but nothing
[20:57] <bac> rick_h_: should it give feedback?
[20:57] <rick_h_> bac: yea, there's empty constraints that it fails on
[20:57] <rick_h_> bac: welcome to my branch :)
[20:57] <bac> rick_h_: ok, good time to walk the dog
[20:58] <bac> rick_h_: but shouldn't it give feedback if it fails with constraint errors?  or does it just silently slink away?
[20:59] <rick_h_> bac: well, is this in sandbox or real env?
[20:59] <bac> ec2
[20:59] <rick_h_> bac: in a real env, it hits Go and Go up and dies. and my branch is working on displaying that Go error back to the user
[20:59] <bac> ah, gotcha
[20:59] <rick_h_> bac: so right now, there's an error thrown, but the gui isn't listening for it and my branch is working on that atm
[21:00] <bac> rick_h_: i've also changed charmworld-url to point to staging.  lots of things to go wrong.
[21:00] <rick_h_> bac: he's updated his bundle so once it ingests the constraints should go away 
[21:00] <rick_h_> so that bundle should work shortly
[21:00] <bac> ok great
[21:01] <Makyo> jujugui trying to QA in an lxc, anyone have experience with this? lxc-start: command get_init_pid failed to receive response
[21:02] <rick_h_> Makyo: no, never seen it. I know quickstart doesn't support lxc if you're trying quickstart?
[21:02] <Makyo> rick_h_, just trying to get an environment without juju so I can qa quickstart installing it.
[21:12] <hatch> rick_h_: ok almost done the review - am I missing why we can't process deltas for these updates instead of longpolling?
[21:12] <rick_h_> hatch: ok, heading out. I landed one small change to fix using the import button
[21:12] <rick_h_> hatch: we're not longpolling are we? I'm not sure how deltas work tbh. This was the api spelled out in the card from frankban
[21:13] <hatch> Note: This returns once the server has something to update on. It might wait a while.
[21:13] <rick_h_> hatch: see http://bazaar.launchpad.net/~juju-gui-charmers/charms/precise/juju-gui/trunk/view/head:/server/guiserver/bundles/__init__.py#L127
[21:13] <rick_h_> hatch: true
[21:13] <rick_h_> hatch: so no idea, this is what I had for instructions to work from
[21:14] <hatch> ok maybe I'll let this sit for tonight and ask him in the morning
[21:14] <rick_h_> hatch: I dont' think there'sa way in the delta to tell is a change was from a bundle request or just a command
[21:14] <rick_h_> hatch: so just watching the delta as it exists will do me much good tbh
[21:14] <rick_h_> hatch: especially since you can run multiple bundle deploys at once and have several running around at once until they complete
[21:15] <hatch> right but can't we send the data down the delta that's being returned from this rpc call
[21:15] <hatch> I don't know, I'm curious as to why that's not the case
[21:15] <rick_h_> hatch: probably because this is run by the guiserver and the delta is proxied through it, but not part of it
[21:15] <rick_h_> hatch: so the guiserver could mix up requestid and such if it tried to use the same channel
[21:16] <hatch> right so we should be able to send a fake delta
[21:16] <rick_h_> hatch: possibly I guess, I'm not sure if that's feasible from the guiserver/deployer side to generate fake deltas that look legit/work from the go env side
[21:16] <hatch> I'm sure there is a valid reason why we aren't doing that but curious as to what that is
[21:16]  * rick_h_ doesn't know enough about the delta stream
[21:16] <hatch> would simplify this :)
[21:17] <hatch> crap half my notes are on one rev and half are on the other
[21:17] <rick_h_> hatch: :P well now you tell me on day 3 of working on it 
[21:17] <hatch> you'll have to decode them :P
[21:17] <rick_h_> hatch: all good
[21:17] <rick_h_> hatch: hopefully not that many notes :P
[21:17] <hatch> haha no - I am probably goign to lgtm it
[21:17] <hatch> i havent' decided yet
[21:17] <hatch> lol
[21:18] <rick_h_> heh, well feel free to hold off. I'm going to EOD and do another round of QA in the morning. Kept finding 'one more small thing' each fresh deploy today
[21:18] <rick_h_> and still need the second review and a 3rd party QA so won't go anywhere until later tomorrow
[21:18] <hatch> sure thing I'll get the review finished for sure
[21:18] <hatch> but not sure about qa today
[21:18] <rick_h_> rgr, all godod
[21:18] <hatch> I'm probably going to go back to lying down
[21:18] <rick_h_> all good
[21:18] <rick_h_> just mean no hurry
[21:19] <rick_h_> yea, cool. Go medicate and such. I'm out of here. Will push this boulder farther up the hill tomorrow
[21:38] <bac> rick_h_: this time it popped right up
[21:42] <rick_h_> bac: cool