[00:01] <hazmat> m_3, all the build links on the #charmtbot-test channel are broken
[00:01] <hazmat> is that to be expected?
[01:17] <hazmat> m_3, its the cyclical dependency between hadoop-master and hadoop-mapreduce that's throwing it off i think
[01:17] <hazmat> m_3, hadoop-master shouldn't be depending on hadoop-mapreduce
[01:20] <hazmat> yup.. removing that and it works fine
[01:23] <hazmat> the planner is a nice lint on charm metadata semantics ;-)
[03:25] <_mup_> juju/enhanced-relation-support r14 committed by<EMAIL_ADDRESS>[03:25] <_mup_> Use cases
[03:35] <_mup_> juju/upgrade-sym-link r468 committed by<EMAIL_ADDRESS>[03:35] <_mup_> support extracting bundle symlinks in place over an existing charm for upgrades
[03:35] <hazmat> jimbaker, its probably worthwhile to send an email to the list re the relation support
[03:36] <jimbaker> hazmat, that's what i'm working on :)
[03:36] <hazmat> jimbaker, awesome.. i should have mentioned that earlier
[03:36] <jimbaker> it's taking a while to get the proposed api change in place
[03:36] <hazmat> jimbaker, its probably better to do the email first, just in case..
[03:36] <jimbaker> given the number of bugs and interlocking concepts
[03:36] <hazmat> yeah.. its got a hit a few places
[03:36] <jimbaker> hazmat, i have not worked on impl. just the spec
[03:37] <hazmat> jimbaker, ah.. cool
[03:37] <hazmat> jimbaker, i'm probably going to take over on that purge-queue-hook thing then
[03:37] <jimbaker> hazmat, sounds cool
[03:37] <hazmat> great
[03:38] <jimbaker> hazmat, i expect at least 6 branches will be needed for this work
[03:38] <hazmat> jimbaker, sounds about right
[03:39] <hazmat> jimbaker, the most important i think is just getting unambigious relation identities
[03:39] <jimbaker> hazmat, yes, that's the first branch
[03:39] <hazmat> jimbaker, after that hook cli mods, and status.. what else?
[03:39] <jimbaker> hazmat, out of band hook command execution
[03:40] <hazmat> oh.. yeah.. and the hook context as well
[03:40] <jimbaker> yes, that's the second branch :)
[03:40] <jimbaker> i'm not planning to do any changes for juju status, i think it's possible to do everything with an enhanced relation-list
[03:41] <jimbaker> trying to keep the changes as small as possible
[03:41] <hazmat> jimbaker, there's a problem with status relating to it.. say for example you have mysql with relations to wordpress and mediawiki..
[03:41] <jimbaker> hazmat, yes, that's a reasonable scenario
[03:41] <hazmat> jimbaker, status only shows the one rel because its using a dict by rel name, instead of identity
[03:43] <jimbaker> hazmat, i see what you mean. well... i was going to delete the juju status changes from the proposed spec because i couldn't show a use case from the bug reports/mailing list, but it looks like you have a reasonable one here
[03:44] <jimbaker> that's at least one more branch then
[03:44] <jimbaker> hazmat, on the same vein: do you see a need for a juju-status (a version of juju status that can be run from a hook)?
[03:45] <jimbaker> right now, i cannot justify it, so it's pending deletion...
[03:45] <jimbaker> but that would be 2 more branches for that support
[03:46] <hazmat> jimbaker, huh.. hooks and status are on remote ends
[03:47] <hazmat> i don't follow
[03:47] <jimbaker> hazmat, indeed they are... might be useful for a brain. so i guess we can delete.
[03:47] <jimbaker> it can always be done in some subsequent api change, just trying to keep this work reasonably limited
[03:49] <hazmat> bcsaller, jimbaker .. for small branches, i'm thinking we should just  move to approved on one review, if the original reviewer feels the change is small/simple..
[03:50] <jimbaker> hazmat, +1 on that
[03:50] <bcsaller> hazmat: I'm good with that
[03:50] <hazmat> the review queue has been flooded for a while it feels like
[03:50] <hazmat> cool
[03:50] <hazmat> flacoste, suggested it
[03:51] <hazmat> he mentioned lp did an experiment with no reviews (ie. self-reviews), and then went back after a cycle and looked back over the commits, to see if they would have benefited from a review.. for the most part they didn't.. i'm not quite feeling that one yet ;-)
[03:53] <jimbaker> hazmat, ;)
[03:58] <_mup_> juju/enhanced-relation-support r15 committed by<EMAIL_ADDRESS>[03:58] <_mup_> Removed juju-status, other cleanup
[03:58] <hazmat> interesting.. first 'real' google go project i've seen http://code.google.com/p/vitess/
[04:01] <jimbaker> hazmat, definitely good to see, especially the pros/cons of go discussed http://code.google.com/p/vitess/wiki/ProjectGoals
[04:02] <jimbaker> i naively thought they were using a better gc, but guess the project just needs work on that
[04:05] <hazmat> jimbaker, gc at scale is dark arts
[04:05] <hazmat> a generational gc would work for a cache
[04:07] <hazmat> i just hope they don't get into the  thousand gc  knobs of java.. looking at all the gc hints in programs like cassandra or elasticcache needs a book to reference
[04:09] <jimbaker> hazmat, well that's certainly a perverse result of large market share
[04:10] <jimbaker> and of course the fact that java code is not necessarily written by top notch devs...
[04:11] <hazmat> or what scale your using it at
[04:37] <hazmat> fwereade, g'morning
[16:19] <matsubara> hello there. I'm having problem starting an precise instance on ec2 using juju. I'm trying to deploy the oneiric jenkins charm on a precise instance. The problem is that the ec2 instance doesn't seem to come up online
[16:20] <matsubara> as in, I can't ssh into it to debug what's wrong with the deployment
[16:35] <hazmat> matsubara, do the ec2 tools show the instance is running? did you have problems with bootstrapping or just the charm?
[16:35] <matsubara> hazmat, not sure where the problem is
[16:36] <matsubara> hazmat, and yes, ec2 console shows the instance as running and with a public ip assigned
[16:36] <hazmat> matsubara, okay.. why don't we walk through the steps.. you bootstrapped, and then deployed a charm?
[16:36] <matsubara> hazmat, I had a environment bootstrapped previously
[16:36] <hazmat> ah
[16:36] <matsubara> where I deploys a jenkins instance on oneiric
[16:36] <matsubara> I deployed, I mean
[16:37] <hazmat> matsubara, how old is the environment?
[16:37] <matsubara> then, using the same bootstrapped environment, I tried to deploy the precise jenkins instance
[16:37] <matsubara> not older than 2 weeks
[16:37] <matsubara> should I have bootstrapped another environment?
[16:37] <hazmat> matsubara, we had an incompatible change in the ppa version of juju about a little over a week ago
[16:38] <hazmat> fwereade__, we probably should have sent an email out about that one
[16:38] <fwereade__> hazmat, damn, yes we should :(
[16:38] <matsubara> hazmat, is there a workaround? what do I need to do?
[16:38] <hazmat> matsubara, are you using the ppa?
[16:38] <matsubara> AFAICT, no
[16:40] <matsubara> hazmat, ii  juju                          0.5+bzr457-0ubuntu1           next generation service orchestration system
[16:45] <hazmat> matsubara, do you have any value specified for juju-origin in environments.yaml
[16:46] <hazmat> matsubara, i think that implies your using the ppa
[16:46] <hazmat> oh.. maybe not.. sorry
[16:46] <SpamapS> hazmat: is that the version of juju on your bootstrapped machine too?
[16:47] <SpamapS> hazmat: juju-origin defaults to distro if you are using the distro version. :)
[16:47] <hazmat> matsubara, can you pastebin the console output of the instance, it should be available from the ec2 console or and also via the ec2 cli tools
[16:47] <hazmat> SpamapS, just wanted to check that's the latest version in precise.. and it appears to be
[16:48] <hazmat> the restart support started landing right after 457
[16:48] <SpamapS> hazmat: DOH
[16:49] <SpamapS> hazmat: whats really going to break things is when people try to deploy an older version of juju with juju-origin: distro .. as in.. an oneiric instance.. that will be r398
[16:49] <SpamapS> hazmat: I'm convinced now, we can't do it this way anymore. We have to start storing juju in file storage and distributing it to the nodes.
[16:50] <hazmat> SpamapS, agreed, its insane as it is
[16:50] <hazmat> SpamapS, would you mind bringing it up on the list? if not i can
[16:50] <SpamapS> hazmat: I've been holding off applying for a FFe because of subordinates landing.. would rather not bother the release team with 2
[16:50] <SpamapS> hazmat: I'll email the list, I've been thinking about this for a while.
[16:51] <hazmat> SpamapS, thanks
[17:34] <flaviamissi> hey! I'm writing a charm for django, and I want to export some environment variables in the `db-relation-changed` hook, but when I try to access this from a django app, after relating the service with mysql, the environment variables exported by the hook are not available, I could just write them to a file, but I like the approach of using environment variables for that... some one has any tip for this problem?
[17:54] <SpamapS> flaviamissi: you really *should* be writing them to disk, in a place where your django app's startup can read them.
[17:54] <SpamapS> flaviamissi: if you reboot, or have to restart the service manually, you won't have access to the environment that the charm had access to.
[17:58] <flaviamissi> SpamapS: yeah, you're absolutely right. Do you know how Heroku solves that issue? because they use environment variables for database informations..
[18:02] <SpamapS> flaviamissi: I don't think Heroku has the same structure as Juju.. perhaps those are stored somewhere and re-executed every time?
[18:05] <flaviamissi> SpamapS: that's what I thought, I think you're right, the best approach with Juju is writing those to a file.
[18:05] <SpamapS> flaviamissi: right, juju is just an event framework with a conduit for sharing configuratino.
[18:05] <flaviamissi> SpamapS: but the environment variables are so clean... :~
[18:06] <flaviamissi> SpamapS: thank's for the clarification :)
[18:06] <SpamapS> flaviamissi: sounds to me like Heroku requires you to give up more control though.
[18:06] <flaviamissi> SpamapS: yeah, I have that impression too.
[18:07] <SpamapS> flaviamissi: care to share your charm? I'd be happy to suggest a clean way to do what you're intending.
[18:07] <flaviamissi> SpamapS: Sure! https://github.com/timeredbull/charms
[18:07] <flaviamissi> SpamapS: we are integrating Juju with openstack
[18:09] <SpamapS> flaviamissi: great start, it looks nicely organized
[18:09] <SpamapS> flaviamissi: juju_charm="/var/lib/juju/units/${juju_unit}/charm"
[18:09] <SpamapS> flaviamissi: thats a no-no
[18:09] <SpamapS> flaviamissi: $CHARM_DIR will always be set
[18:10] <flaviamissi> SpamapS: great!
[18:10] <SpamapS> flaviamissi: also the cwd when charms are run will always be the root of the charm
[18:10] <SpamapS> flaviamissi: in some cases, that may not be the right path. :)
[18:10] <SpamapS> rather, the one you've explicitly chosen, may not be the right path
[18:10] <flaviamissi> SpamapS: hmmmmm, changing it now
[18:11] <flaviamissi> SpamapS: thanx :)
[18:11] <SpamapS> flaviamissi: Other than that, you should move *all* of joined into changed.
[18:12] <SpamapS> flaviamissi: and instead of just exporting them, just write them to a file that 'start_gunicorn' sources.
[18:12] <flaviamissi> SpamapS: hmmm
[18:13] <SpamapS> flaviamissi: I'd also recommend putting start_gunicorn and stop_gunicorn in /usr/local/bin so you can use them without the charms.
[18:13] <flaviamissi> SpamapS: great! I'll do that.
[18:14] <flaviamissi> SpamapS: but... why should start_gunicorn source the file with the variables?
[18:14] <flaviamissi> SpamapS: sorry if it's a noob question.. :/
[18:14] <SpamapS> flaviamissi: I assume that the django app running inside gunicorn is the bit that needs those variables.
[18:14] <flaviamissi> SpamapS: that's right
[18:15] <flaviamissi> SpamapS: oooh, right, I got it :)
[18:16] <flaviamissi> SpamapS: you've helped I *lot*! thank you ^^
[18:16] <SpamapS> flaviamissi: I'd just put it in the helloworld root.. 'settings.sh' or something.. and then just 'source /home/app/helloworld/settings.sh'
[18:16] <SpamapS> flaviamissi: no, thank you. :)
[18:16] <flaviamissi> SpamapS: xD
[18:16] <SpamapS> we appreciate that juju is new and weird, and that you are willing to play with us. :)
[18:17] <flaviamissi> SpamapS: it has been a great experience
[18:19] <flaviamissi> SpamapS: are you a juju developer?
[18:19] <SpamapS> flaviamissi: heh.. sort of. :)
[18:20] <SpamapS> flaviamissi: I'm not in the core dev team, more of a power user. :)
[18:20] <flaviamissi> SpamapS: great, i've been thinking in send a patch
[18:20] <frankban> hey SpamapS: do you have a minute? I was looking at juju-jitsu, it seems that a shell alias is used to override the juju command. AFAICT this sure works well for tests using bash, but not so easily for python tests.
[18:20] <frankban> I've seen the proposal to use env vars to set up charms repository and namespace, and IMHO that should solve the problem. In the meanwhile, what do you suggest? I could just continue using the juju_wrapper script.
[18:20] <flaviamissi> SpamapS: because we use proxy here, and juju doesn't seems to work properly behind one
[18:21] <matsubara> hazmat, hey there, you were helping me up with that juju issue on precise. it seems I'm using the packaged version rather than the ppa's.
[18:21] <matsubara> would the console output of the instance help debug the problem?
[18:24] <SpamapS> frankban: I have been thinking about that..
[18:25] <SpamapS> frankban: I think just need to create a temporary PATH override until the env vars are available. So just put 'juju-jitsu-wrapper' in $PATH somewhere as juju
[18:25] <SpamapS> flaviamissi: I think there may already be a bug report. Its a common request. :)
[18:26] <flaviamissi> SpamapS: I saw it :)
[18:27] <hazmat> matsubara, yes.. very much so..
[18:28] <frankban> SpamapS: thanks.
[18:29] <SpamapS> frankban: I'd expect the environment variables to land quite soon though. :)
[18:29] <frankban> SpamapS: great!
[18:30] <matsubara> hazmat, https://pastebin.canonical.com/61266/
[18:31] <matsubara> hazmat, machine 6 is the first one I started where I noticed the problem. machine 7 is the second one but that one didn't have any output in the system log
[18:32] <hazmat> matsubara, this appears to the libc6 upgrade problem when installing juju
[18:32] <hazmat> matsubara, at the moment the work around is to manually specify a machine image to use
[18:32] <hazmat> ie. picking one of the latest nightlies
[18:33] <hazmat> from http://cloud-images.ubuntu.com/precise/current/
[18:33] <hazmat> and putting it in ~/.juju/environments.yaml for the ec2 environment as default-image-id
[18:34] <matsubara> hazmat, cool. thank you. let me try that
[18:36]  * hazmat hopes it works
[18:45] <matsubara> hazmat, do I need to choose the one ebs root? (or it doesn't matter?)
[18:45] <matsubara> s/one/one with/
[18:50] <matsubara> looks like the daily build images don't even start
[18:58] <jcastro> hazmat: do we handle Amazon spot instances in juju?
[19:05] <m_3> hazmat: re: build links...yes broken until I flick the switch on publishing
[19:05] <m_3> hazmat: thanks, I'll fix the hadoop cycle
[19:16] <hazmat> matsubara, after the environments.yaml change, it takes a moment for the provisioning agent to notice the change
[19:16] <hazmat> jcastro, no
[19:16] <mchenetz> good afternoon…
[19:17] <matsubara> hazmat, does it matter that the bootstrapped environment was bootstraped with oneiric now that I changed the environment.yaml file for the precise release?
[19:22] <hazmat> matsubara, at the moment it shouldn't.. as those versions should be compatible. otoh you wouldn't be having these problems if you had a fresh environment
[19:22] <hazmat> the next upload to precise will be incompatible with the oneiric version
[19:23] <matsubara> right
[19:23] <hazmat> at the moment the best option to utilize a single version of juju across multiple distro releases is to utilize the ppa
[19:24] <SpamapS> hazmat: or use a branch
[19:24] <hazmat> but even that's not a guarantee as the ppa is a trunk build, SpamapS and i were discussing this earlier right before you left, namely that juju should be distributing itself to all machines
[19:25] <hazmat> SpamapS, yes, using a stable branch would work well (juju-origin: lp:branch_location)
[19:25] <matsubara> hazmat, right. I'm bootstrapping a new env to test.
[19:25] <hazmat> but in terms of moving towards juju upgrading itself, having juju distribute itself would work a bit better
[19:28] <SpamapS> hazmat: indeed
[19:50] <_mup_> juju/enhanced-relation-spec r16 committed by<EMAIL_ADDRESS>[19:50] <_mup_> Rework juju status output, consistency guarantees, and other finalization
[19:52] <_mup_> juju/enhanced-relation-spec r17 committed by<EMAIL_ADDRESS>[19:52] <_mup_> Merged docs trunk
[19:59] <matsubara> hazmat, bootstrapping a new environment work, but I lost access to the old bootstrapped environment. Is there a way to access that one? Even if I change back my environment.yaml back to what it was, it still refuses connection to the oneiric bootstrapped env
[20:00] <marcoceppi> o/ hi everyone
[20:01] <hazmat> matsubara, ? if you want to have multiple environments, you should have multiple entries in environments.yaml one per environment.. if you change the details of an environment (things like control bucket or name) then juju won't know how to contact the original environment.. if you need to destroy a previous environment you can make sure it has the same name and do juju destroy-environment.
[20:02] <hazmat> matsubara, ie.. when you say you bootstrapped a new environment, did you destroy the old one or use a new entry in environments.yaml.. if you need to reference a non-default environment pass -e env_name on the cli after the subcommand
[20:02] <hazmat> marcoceppi, greetings!
[20:02] <matsubara> hazmat, that's what I did (and I didn't change the control bucket, access-key, secret-key for them) just created a new environment with the same values plus the ami type and series
[20:02] <matsubara> then I bootstrapped this new one and lost access to the old one
[20:03] <matsubara> when I try juju -e $env it says it can't connect to the environment
[20:03] <matsubara> so, I think I kinda broke everything
[20:05] <matsubara> is there any way to find the key used to log into the ec2 instance?
[20:06] <hazmat> matsubara, it sniffs a public key from the ~/.ssh/  if one isn't specified in environments.yaml
[20:13] <hazmat> matsubara, the previous one was working, so its not clear why access would have been lost
[20:14] <matsubara> hazmat, yeah, it's unclear to me as well. I'm trying to connect to the instance to get the data but the instance is not accepting my ssh key
[20:24] <matsubara> hazmat, managed to connect to the instance. I was using the wrong username.
[20:24] <hazmat> ah
[20:24] <matsubara> (it's still unclear why juju can't see both environments...)
[20:24] <SpamapS> matsubara: do they have the same control-bucket ?
[20:29] <hazmat> that would be bad
[20:39] <SpamapS> like crossing the streams
[20:40] <matsubara> yep
[20:40] <matsubara> SpamapS, where do I get that value from?
[20:43] <SpamapS> matsubara: that has to be unique to every environment
[20:43] <SpamapS> matsubara: it stores the seed information that tells clients where to find the bootstrap node
[20:43] <matsubara> SpamapS, right. that makes sense. how do I generate a new one?
[20:44] <SpamapS> matsubara: lately I attach the date to the environment name when I bootstrap.
[20:49] <matsubara> SpamapS, so it's just a random string? it's not a hashed value from somewhere else?
[20:50] <matsubara> btw, isn't it a bug that juju doesn't tell me I have two environments with the same control-bucket value?
[20:53] <hazmat> matsubara, hmm.. yeah.. it is
[20:53] <hazmat> matsubara, its just a random string
[20:53] <matsubara> cool. I'll file the bug once I'm done with my experiments
[20:53] <matsubara> thanks for all the help hazmat and SpamapS
[20:54] <hazmat> matsubara, incidentally even with the control bucket change, destroy-environment will do the right thing (it works by env name)
[20:55] <matsubara> right. I was being careful to not run destroy-environment before I can get my data out of it
[21:35] <_mup_> juju/enhanced-relation-spec r18 committed by<EMAIL_ADDRESS>[21:35] <_mup_> Finish TODOs
[21:41] <_mup_> Bug #943610 was filed: Specification for enhanced relation support <juju:In Progress by jimbaker> < https://launchpad.net/bugs/943610 >
[21:43] <jimbaker> with that and the merge proposal, about to generate the corresponding proposed api change email to juju mailing list... hold on please :)
[21:44] <hazmat> jimbaker, cool
[21:44] <jimbaker> hazmat, hopefully it will delight everybody. fingers crossed ;)
[21:45] <ejat> ping jcastro
[21:47] <SpamapS> ejat: its usually safest to start with somebody's name, like
[21:47] <SpamapS> jcastro: ping ^^
[21:47] <jcastro> hi
[21:47] <jcastro> oh sorry I was burning AWS CPU time with boinc
[21:48] <ejat> SpamapS owh okie
[21:49] <ejat> just want to check .. i just at the bugs at the charm target list
[21:49] <ejat> line 125
[21:50] <jimbaker> and email sent on the proposed api change. time to walk the dog! :)
[21:52] <jcastro> ejat: that's symfony right?
[21:53] <jcastro> that's in review right now right?
[21:53] <ejat> jcastro : not sure .. but i already tag new-charm
[21:54] <jcastro> ah right
[21:54] <jcastro> SpamapS: marcoceppi: review?
[21:54] <jcastro> who else is around ...
[21:56]  * ejat trying to write another charm … go go go ..
[21:56] <SpamapS> ejat: whats the status of the new-charm tagged bug?
[21:56] <SpamapS> I only look at New/Confirmed/Triaged
[21:57] <SpamapS> In Progress and Incomplete I ignore since they usually mean its not ready for review
[21:57] <ejat> so i need to change to confirm / triaged ?
[21:57] <m_3> hazmat: snapshot restore is hanging about 5-10% of the time ( http://ec2-107-22-3-212.compute-1.amazonaws.com:8080/job/oneiric-local-charm-cloudfoundry-server-dea/1/console )
[21:58] <SpamapS> ejat: bug #?
[21:58] <m_3> hazmat: changing it to use verbose and catch stderr properly... hopefully I'll catch more info next time
[21:58] <ejat> bug #940140
[21:58] <_mup_> Bug #940140: Charm needed: Symfony <new-charm> <Juju Charms Collection:In Progress by fenris> < https://launchpad.net/bugs/940140 >
[21:58] <m_3> hazmat: (just fyi)
[21:58] <hazmat> m_3, i think i see the issue, can you file a bug against charmrunner
[21:58] <m_3> sure
[21:59] <ejat> since m_3 already help me to debug and test
[21:59] <hazmat> m_3, i'm in the middle of a problematic relation bug atm
[21:59] <m_3> np... thanks!
[22:00] <ejat> brb
[22:01] <jcastro> nice he got that one
[22:01] <marcoceppi> jcastro: o/
[22:01] <jcastro> he was stuck on some java thing before that wasn't packaged and it was generally not fun
[22:01] <jcastro> marcoceppi: https://launchpad.net/bugs/940140
[22:01] <_mup_> Bug #940140: Charm needed: Symfony <new-charm> <Juju Charms Collection:Confirmed for fenris> < https://launchpad.net/bugs/940140 >
[22:01] <jcastro> We know you love php dude
[22:03] <marcoceppi> and I <3 Symfony
[22:06] <matsubara> is it possible to pass the instance-type to juju deploy at run time?
[22:06] <ejat> SpamapS: so i need to change to confirm / triaged?
[22:07] <marcoceppi> jcastro: looking at it now
[22:08] <ejat> thanks marcoceppi
[22:08] <jcastro> SpamapS: see if we could sort merge proposals we wouldn't have this bug status confusion
[22:08] <jcastro> just sayin'
[22:08] <SpamapS> jcastro: what confusion?
[22:09] <SpamapS> jcastro: In Progress would be like Work In Progress in a merge proposal.. same problem. :)
[22:11] <ejat> is it something in juju school mentioning about the status ....
[22:12] <SpamapS> ejat: no, it was not clear, so I have updated https://juju.ubuntu.com/Charms to make it more clear.
[22:12] <ejat> \0/
[22:13] <SpamapS> ejat: also just noted that you need to point reviewers to your charm.. no mention of it in the bug
[22:14] <ejat> noted + thanks
[22:19] <ejat> updated the branch
[22:30] <marcoceppi> Any idea if PEAR uses HTTPS?
[22:30] <marcoceppi> Or does payload verification?
[22:31] <SpamapS> marcoceppi: it does not do either
[22:31] <SpamapS> marcoceppi: I looked into it at one point. :(
[22:31] <SpamapS> neither pecl nor pear do anything to protect the user
[22:31] <marcoceppi> onedayiwillwriteabetterphpdeploymentservice
[22:32] <SpamapS> "pear is a dev tool"
[22:32] <marcoceppi> "pear is a pos"
[22:32] <SpamapS> marcoceppi: better to just dump any unpackaged PEAR modules you need into the charm.
[22:32] <marcoceppi> I agree, considering how tedious the update and release cycle is for module owners
[22:33] <SpamapS> "pear don't care, pear don't give a s***"
[22:35]  * marcoceppi concludes review
[22:39] <marcoceppi> Is there an idea of "optional interfaces"
[22:39] <marcoceppi> It's been a while :)
[22:40] <marcoceppi> Would that be a peer?
[22:42] <ejat> :)
[22:45] <ejat> pear fruit :)
[22:57] <SpamapS> marcoceppi: all requires are actually optional
[22:57] <marcoceppi> SpamapS: I noticed that actually
[22:58] <SpamapS> marcoceppi: at some point we may provide some mechanism for hardening or softening that
[22:58] <SpamapS> marcoceppi: we're seeing some ordering problems because they're optional... so a  discussion needs to happen.
[22:58] <marcoceppi> I think that responsibility should lye within the charm/hooks itself though
[22:59] <marcoceppi> Or, if there are problems, then a conversation should happen
[23:00] <SpamapS> marcoceppi: for instance, there are times where you want to store your data locally in sqlite, and others where you want mysql. That shouldn't be two charms IMO, we should be able to have that choice declared, and a simple way to change the default behavior.
[23:00] <hazmat> SpamapS, re ordering around relations, outside of them being established, notional ordering supposes a steady state/goodness, where as dependency fufillment is done by existance.
[23:00] <marcoceppi> SpamapS: I agree, and am struggling with that ATM
[23:00] <marcoceppi> But that's something that happens in the config-changed hook, nothing related to interfaces, correct?
[23:02] <SpamapS> hazmat: somehow you always manage to make me go cross eyed
[23:02] <hazmat> SpamapS, sometimes i have that effect, in english just because  a relation is established and thus a dependency satisified doesn't imply that's its ready to use.
[23:03] <SpamapS> marcoceppi: thats how you deal with it today.. but it would be a better experience if there were a uniform way to say "don't serve X until you have saitsifed Y"
[23:03] <marcoceppi> SpamapS: interesting idea
[23:03] <hazmat> yeah.. a nice way for a charm to say.. i don't provide anything till X
[23:03] <SpamapS> hazmat: right, I'm looking for a better answer than the one that I proposed since my proposal requires steady state.
[23:04] <SpamapS> as hazmat pointed out to me yesterday, if we make disk storage a 1st class abstraction in juju, that may handle the whole thing properly
[23:04] <SpamapS> since you could, in theory, declare that you need disk storage | mysql storage..
[23:05] <SpamapS> but, forget what I'm saying, I get off in the weeds sometimes.
[23:14] <jimbaker> SpamapS, i'd appreciate if you'd take a look at the proposal i sent to the mailing list, it should satisfy this need
[23:14] <SpamapS> jimbaker: ooo I didn't know it was something actively being looked at. Will read ASAP :)
[23:14]  * SpamapS is only about 6 hours behind on email ATM.. woot
[23:14] <jimbaker> also, i'm curious if the potential tongue twister of `juju do` will be what end up implementing ;)
[23:15] <jimbaker> any hook command from anywhere juju runs would seem to be some goodness
[23:16]  * jimbaker understands email backlog, for sure
[23:25] <jimbaker> hazmat, can you respond to the api change email re your observation "juju do is out of scope and dangerous"? i guess the stmt mysql has multiple relations is complex may be overstating these types of scenarios. certainly more complex than 1 instance of a wordpress blog + mysql
[23:26] <jimbaker> just trying to keep the discussion in the appropriate channel, per api changes


[05:21] <xubuntu863> hello
[05:21] <xubuntu863> im installing xubuntu but it seems stuck how do i know if it is still installing
[05:22] <XubuntuKris> You wait
[05:22] <XubuntuKris> How long has it been
[05:22] <XubuntuKris> "stuck"
[05:22] <XubuntuKris> ?
[05:22] <xubuntu863> maybe 30 mins
[05:22] <XubuntuKris> yeah, it's stuck.
[05:23] <xubuntu863> lol
[05:23] <XubuntuKris> You should be able to have a fully functioning system in less than that.
[05:23] <xubuntu863> if i run tcpdump it seems to be comunicating with other servers
[05:23] <well_laid_lawn> which part did it stick at?
[05:24] <XubuntuKris> i'm off though, sorry I can't help
[05:24] <xubuntu863> the thankj you part
[05:24] <xubuntu863> last part of the presentation
[05:25] <xubuntu863> also had some trouble with apt-get not been able to configure im using a live usb
[05:26] <well_laid_lawn> it's not getting language packs still is it?
[05:26] <xubuntu863> how do i know it doesnt have progress bar
[05:28] <xubuntu863> i think it is downloading stuff cause tcpdump is telling me there is comunication with lithium.canonical
[05:29] <well_laid_lawn> sounds like it is still installing - which xubuntu version is it?
[05:29] <xubuntu863> 11.04
[05:29] <well_laid_lawn> k
[05:29] <xubuntu863> im on a netbook
[05:29] <well_laid_lawn> slow connection?
[05:29] <xubuntu863> not rly
[05:30] <xubuntu863> 3mb
[05:30] <well_laid_lawn> k
[05:30] <xubuntu863> wierd it takes so long
[05:31] <well_laid_lawn> it shouldn't really but I've never installed from usb to netbook
[05:32] <xubuntu863> it is not working very well lol
[05:33] <well_laid_lawn> do you do the iso check ?
[05:33] <well_laid_lawn> !md5
[05:36] <xubuntu863> ok i guess i will have to check them tomorrow cause i got the iso in the office
[05:36] <well_laid_lawn> I'd give it another 1/2 hour and end it if it isn't finished
[05:36] <xubuntu863> k thanks
[05:37] <well_laid_lawn> luck
[06:19] <xubuntu759> ?
[06:19] <knome> !
[06:19] <xubuntu759> is xubuntu faster than ubuntu?
[06:20] <knome> it should use a bit less resources
[06:20] <xubuntu759> what are the drawbacks?
[06:21] <knome> features are pretty close to each other, but xubuntu might not have all the little things here and there
[06:21] <knome> but one might think that's a pro too
[06:22] <xubuntu759> agreed
[06:23] <knome> they both are using the same repositories though, so you can install any application in the repositories in either one
[07:03] <knome> Sysi?
[07:03] <knome> !support
[07:03] <knome> Sysi, is that better now?
[07:03] <knome> Sysi, (was only the last sentence before)
[07:05] <Sysi> looks good
[07:05] <knome> good
[08:36] <cYmen> How do I remove the xfce4-notifyd and use the kde notification daemon instead?
[09:01] <insitu> hello. I am having trouble printing on a ricoh aficio C3500. It is correctly recognized by the system but prints garbage
[09:23] <well_laid_lawn> !print
[10:04] <insitu> thanks.  looks like my printer is not supported...
[10:30] <bittin> Linux cindy 3.0.0-1-powerpc #1 Sat Aug 27 17:07:06 UTC 2011 ppc GNU/Linux yay iam current =)
[13:13] <bittin> got some more ram for my webserver / debian client today :)
[13:32] <madnick> :)
[13:33] <madnick> Upgrade my debian machine a couple of days ago, lost a years uptime :(
[13:35] <Sysi> I now have 98 days (since installation)
[13:37] <madnick> uptime 15:37:10 up 4 days :((
[18:42] <ChristopherNG> Hey! folks!
[18:42] <nikolam> hey


[10:36] <frankban> rogpeppe1: morning. already asked William, but could you please take a look at our comments in https://codereview.appspot.com/7598043 ?
[10:36] <rogpeppe1> frankban: will do. just getting back up to speed.
[10:36] <frankban> rogpeppe1: cool, thanks
[12:21] <teknico> uhm, cannot submit a branch, make beautify stops with this: http://pastebin.ubuntu.com/5610507/
[12:22] <gary_poster> teknico, I wonder if this is another case of " we should specify our versions"
[12:22] <teknico> I removed the virtualenv directory, to no avail
[12:22] <teknico> gary_poster, probably
[12:22] <gary_poster> Let's see if we can figure out what our respective versions of the closure linter are
[12:22] <bac> guihelp: i'm trying to run individual tests in the browser but get this:
[12:22] <bac> Cannot GET /test/index.html/?grep=Go%20Juju%20environment
[12:22] <bac> anyone seen this before?  work-around?
[12:23] <bcsaller__> remove the / after index
[12:23] <gary_poster> yup
[12:24] <gary_poster> hey bcsaller__ (that's a long tail!) would appreciate your thoughts on https://code.launchpad.net/~gary/charms/precise/juju-gui/bug1117896/+merge/152973
[12:24] <bac> thanks bcsaller__
[12:27] <gary_poster> teknico, I ran virtualenv/bin/python, imported closure_linter, called help(closure_linter) and saw in the file that I had closure_linter-<IP_ADDRESS>-py2.7.egg
[12:27] <gary_poster> nowe making sure that it works but pretty sure it does
[12:27] <gary_poster> it does
[12:28] <gary_poster> teknico, another possibility: beautify is encountering a particular case in your code that it barfs on.  You could try running make beautify on trunk
[12:28] <gary_poster> if it is the same version
[12:28]  * gary_poster goes to look on pypi
[12:28] <teknico> gary_poster, same version as mine, yes
[12:28] <bcsaller__> gary_poster: I wrote it with the intention that socket_url when defined would continue to work as before. I thought that would be enough
[12:29] <gary_poster> bcsaller__, it gives backwards compatibility with the GUI but not the charm, do you see what I mean?
[12:29] <gary_poster> If the charm takes advantage of the new functionality, it will break old versions of the GUI
[12:29] <gary_poster> I would like the charm to default to the new, improved behavior whenever possible
[12:30] <teknico> gary_poster, make beautify in trunk works correctly here, so your idea about something in my code is plausible
[12:30] <bcsaller__> gary_poster: I would as well. When would the charm deploy an old version of the GUI?
[12:30] <gary_poster> teknico, does make gjslint succeed in your branch?  If so, you could fix manually
[12:31] <teknico> gary_poster, nope, it stops with the same error
[12:31] <gary_poster> bcsaller__, first answer is "whenever it wanted to" because we allow configuration of this.
[12:32] <gary_poster> teknico, ugh, suck.  I don't know, have not encountered.  You could try putting in a pdb and seeing if you diagnose or at least work around
[12:33] <teknico> gary_poster, I'll try that
[12:33] <gary_poster> bcsaller__, second answer is that the tests ran the 0.2.1 release, and broke.  They only succeeded when I changed it to 0.2.2.  That's what smelled like a problem we ought to address
[12:35] <gary_poster> bcsaller__, corrollary to both of those is that the error condition--the gui spins forever trying to connect to the back end, never succeeding--does not lend itself to knowing what to do to fix the problem
[12:35] <gary_poster> I phrased that poorly, but hopefully you know what I mean
[12:35] <bcsaller__> I do
[12:40] <bcsaller__> I think if anyone saw that I'd rather put it in a FAQ saying redeploy than carrying special code for that case. We already have a screen indicating it can't connect to the backend. If it sits on that screen they will have to read about socket_url anyway so I think it could be solved with docs. *not sure*
[12:40] <bcsaller__> brb
[12:41] <gary_poster> ok
[12:43]  * gary_poster is surprised that no-one erupted in excitement at my discovery of chrome://appcache-internals/ .  Maybe benji or Makyo will give me a half-hearted cheer later. :-)
[12:44] <goodspud> HOooray!
[12:50] <benji> heh, I haven't looked at it yet.  I'm sure it will be fabulous.
[12:50] <frankban> gary_poster: chrome://appcache-internals/ is awesome! :-) and re: the charm proposal: why do we use {{insecure}} to comment out code in a tempita template?
[12:51] <gary_poster> goodspud, benji, frankban thanks! I feel so much better now that my excitement is shared. :-)
[12:52] <gary_poster> frankban, ah! yes!  I knew I didn't like that for some reason.  Duh. :-) I'll fix that, thanks
[12:52] <gary_poster> bcsaller__, I thought about this.  ISTM that we simply need to invert the precedence of the old/new config options
[12:53] <gary_poster> right now, if you provide socket_url, and one of the new variables, socket_url wins
[12:54] <gary_poster> there's no reason for that to be the case AFAIK, and if we invert it, the charm can support old and new trivially
[12:55] <bcsaller__> gary_poster: auto generation with manual override seems right to me. I guess its still like that if you delete reference to _port and _protocol though
[12:56] <gary_poster> bcsaller__, exactly
[12:56] <gary_poster> the question is what does the GUI do if you provide both, and this solution seems reasonable in the abstract, and solves a problem with the specific case of the charm or other automation that wants to support old and new versions of the GUI
[12:59] <teknico> oh wow, this is not good
[12:59] <gary_poster> bcsaller, are you ok with me proceeding with that plan?
[13:00] <teknico> gary_poster,  problem was a missing closing curly+round bracket pair
[13:00] <bcsaller> gary_poster: I think its fine. The other made more sense to me but for the most part people still don't need to define anything for it to work (except in development)
[13:00] <gary_poster> right cool bcsaller thanks
[13:01] <gary_poster> teknico, eek!  sounds like an opprtunity to become a closure contributor :-)
[13:01] <teknico> really weird thing was that tests passed, that syntactically invalid file notwithstanding!
[13:01] <gary_poster> ...wow, that is weird
[13:02] <teknico> and now the test right above fails, so somehow that missing line was causing that test to be skipped
[13:03] <bcsaller> teknico: a failure in a test file like that will usually skip the file
[13:05] <teknico> bcsaller, yeah, if I really look for it, I can see this in the test output: "SyntaxError: Parse error"
[13:05] <teknico> and with no hint of which file is the offending one :-P
[13:05] <bcsaller> chrome's console log should make it clear
[13:06] <teknico> bcsaller, I was running "make test-prod", everything looked hunky dory
[13:24] <rick_h_> so thought it was cool. At my local LUG a guy was demo'ing ceph and used the juju gui to 'visualize' the environment as he created it and added ceph nodes, gateway nodes, haproxy, etc
[13:24] <gary_poster> rock, rick_h_ !
[13:25] <rick_h_> worked pretty nice to translate his juju commands he was running to 'wtf that means' in the big picture
[13:25] <bac> rick_h_, so he did it all by hand and then just viewed via the gui?
[13:25] <rick_h_> bac: right
[13:25] <bac> rick_h_ did you point out the obvious?
[13:26] <rick_h_> he was ssh'ing into the machines to run ceph status, showed some of the config, etc
[13:26] <rick_h_> bac: yea, he mentioned how you *can* do it from the gui, but he was using local charms and had the juju commands scripted out
[13:26] <bac> righto
[13:27] <rick_h_> was still cool to just go to a meeting and be like "Well that looks familiar" :)
[13:27] <rick_h_> he used teh charm to deploy it into his env first
[13:27] <rick_h_> so charm'ing the gui ftw
[13:27] <gary_poster> yay!
[13:28] <frankban> cool
[13:30] <gary_poster> Makyo, when you are around, lemme know and we'll try to arrange a quick call with you, frankban, rogpeppe, fwereade and me to see if we can quickly unblock the annotations thing
[13:52] <Makyo> gary_poster, 8 minutes?
[13:52] <Makyo> Would like a coffee first.
[13:52] <gary_poster> Hey Makyo.  Understood.  :-)  I'll arrange something after that, thanks
[13:53] <gary_poster> teknico, are you available now?
[13:53] <gary_poster> oh duh
[13:53] <gary_poster> today is not Thursday :-)
[13:54] <gary_poster> nm teknico, sorry
[13:59] <gary_poster> Makyo, frankban call in 62 minutes hopefully, if that works with Roger (and Makyo, join #juju-dev :-) )
[14:03] <frankban> gary_poster: ack, thanks
[14:04] <Makyo> gary_poster, got it.  Will be there.
[14:05] <gary_poster> thanks
[14:05] <gary_poster> (still no confirmation from Roger though)
[14:06] <hatch> aww I was deactivated from the gophers group :'(
[14:06] <Makyo> Me too.
[14:06] <hatch> yikes and you're working on Go....I sense a disturbance in the force!
[14:08] <gary_poster> All of us.  Not sure about meaning--seems odd--but not a practical issue.
[14:08] <hatch> maybe it's now an invite only thing - you need to be invited to code Go
[14:08] <hatch> ;)
[14:09] <benji> me too; good, now I can throw away the go code I've been working on ;P
[14:10] <hatch> lol
[14:12] <frankban> me too, this means I will never have one of these: http://www.mikespook.com/wp-content/uploads/2011/05/gopher.jpg
[14:12] <gary_poster> :-)
[14:13] <gary_poster> ah! ~gophers was deactivated entirely
[14:13] <gary_poster> so it's not just us :-)
[14:14] <hatch> oh gary, wrecking the conspiracy theories
[14:14] <benji> my first chance at being an outcast: pfft! it's gone
[14:14] <gary_poster> I know, I'm a spoilsport
[14:14] <gary_poster> :-)
[14:14] <hatch> benji, first chance? You must not have been a geek in school then...lol
[14:15] <benji> I majored in misstating the truth for comedic effect.
[14:15] <Makyo> Well played :)
[14:15] <gary_poster> benji has sarcasm running through his veins, like mello yello, his favorite drink, flowing through...a straw?
[14:15] <benji> LOL
[14:16] <hatch> hahaha
[14:27] <gary_poster> jujugui, call in 2 in guichat
[14:31] <gary_poster> bac goodspud starting without you
[14:31] <gary_poster> rick_h_, miss you too :-)
[14:33] <rick_h_> gary_poster: all good
[14:44] <teknico> bac, shall we hangout, in a few minutes maybe?
[14:44] <bac> teknico: yes, i'll ping you in a few minutes
[14:44] <teknico> ok
[14:51] <hatch> bcsaller, I happened to have the sauce labs account info page open while you were running the tests this am and it was running the FF and Chrome tests at the same time
[14:52] <hatch> so if they are using the same back end that could cause issues no?
[14:53] <bcsaller> hatch: I don't *think* thats is what happens but I can read up on it. Its odd though as the tests wait for the response so they shouldn't be able to run at the same time
[14:54] <hatch> yeah it may have just been spinning the other one up - but there were definitely two 'Running' flags on at the same time
[15:00] <bac> benji: what is wrong with this: tb receive<EMAIL_ADDRESS>[15:00] <benji> bac: are you getting "ValueError: too many values to unpack"?
[15:00] <bac> yep
[15:01] <benji> if you update it should work (a new version was built 31 minutes ago with a fix)
[15:01] <bac> benji: did the cl change?
[15:01] <benji> nope, lack of CI caused me to unleash a bug onto the world
[15:03] <teknico> benji, I'm getting no tb update though
[15:03] <bac> benji: my tb is 0.4.0-1~115~qua and no update is available
[15:04] <benji> hmm, let me double-check
[15:04] <hatch> It doesn't look like the lbox is working so I manually triggered this to need review for merge
[15:04] <hatch> https://code.launchpad.net/~hatch/juju-gui/ci-documentation/+merge/153165
[15:04] <benji> darn, it hasn't been pushed to the PPA yet, https://code.launchpad.net/~benji/+recipe/termbeamer-daily says it will take 30 minutes
[15:06] <benji> you could run it from trunk; other than that I don't know what to do... wait, I could give you a file for you to replace the one with the bug
[15:10] <teknico> benji, thanks, no hurry, we'll work around it for these few minutes
[15:11] <benji> I regret the inconvenience, but am happy that enough people are using it that my screw up was noticed. :)
[15:20] <bac> benji: glad to be part of your vast QA team!
[15:20] <benji> heh
[15:20] <benji> I really have to get CI set up so this doesn't happen again.
[15:22] <bac> so yesterday for my flights AA was $356 and DL was a few hundred more.  today they are both $356.  i guess if you wait long enough they will all reach parity on a given route.
[15:24] <teknico> bac, false alarm,  I was missing those brackets *again*, test still failing :-/
[15:24] <teknico> I'll try with the wsclient
[15:37] <hatch> bcsaller, any idea what the eta on that CI stuff might be? I was thinking I'd jump on the router stuff if you're going to be a while
[15:38] <hatch> just to keep the boat moving :)
[15:38] <bcsaller> hatch: feel free to look at it, I was going to override the afterHistoryChange event and attempt the fix there
[15:40] <hatch> alrighty - did you make any changes from trunk so far?
[15:43] <bcsaller> hatch: I don't see anything important, I'd be happy to talk things over with you if you don't see a way to make progress though and hopefully we could pair on it later, but I want to get the CI stuff working better still
[15:46] <hatch> sounds good! Right now I'll browse through it and reproduce the error to see what I can come up with
[16:20] <hatch> I think we have a bug in the init code for the GUI on the very first load from make devel it doesn't appear to make the websocket request
[16:20] <hatch> it needs to be loaded again to do so
[16:20] <hatch> has anyone else ever seen this?
[16:33] <gary_poster> no
[16:37] <gary_poster> jujugui, I am unable to propose a GUI branch because lbox propose, in the check, fails with the following: Failed to start mocha: Init timeout \n make: *** [test-debug] Error 255 (fuller pastebin http://pastebin.ubuntu.com/5611150/).  Anybody know what is up with this?  It looks liek mocha has some kind of timer that I don't know how to configure.  Note that make test-debug works finr from the commandline
[16:37] <bcsaller> gary_poster: that can be intermittent, usually retrying works
[16:37] <benji> gary_poster: teknico had this problem on Friday at the sprint; we investigated until it went away
[16:38] <teknico> gary_poster, I'm having the same problem, and make test-debug times out too
[16:38] <teknico> benji, it didn't really go away, it just occasionally succeeds :-)
[16:38] <gary_poster> ok will retry bcsaller.  This has happened a few times already.  benji, teknico interesting.  :-/  I'll look a little deeper if I can
[16:38] <benji> s/went away/(temporarily) went away/
[16:39] <teknico> also, in weekly discuss we have a card saying "Remove test-debug from lbox check?" to which I'd emphatically reply "yes" :-)
[16:39] <gary_poster> https://github.com/metaskills/mocha-phantomjs/blob/master/lib/mocha-phantomjs.coffee#L112 ...
[16:39] <gary_poster> I don't agree in theory, but looking forward to the discussion.
[16:40] <teknico> rather than removing it we could swap it out for make test-prod, which works reliably
[16:40] <gary_poster> We do both
[16:40] <gary_poster> which is appropriate if we want both to work after commits
[16:42] <hatch> I have run into that issue before, usually trying again and it works
[16:42] <hatch> :)
[16:43] <rick_h_> yea, I only get that very infrequently. I've only had it once during a local test run and once during an lbox run.
[16:43] <gary_poster> .option('-t, --timeout <timeout>', 'specify the test startup timeout to use', parseInt, 6000)
[16:43] <gary_poster> ...
[16:43] <rick_h_> I'd not thought it so widespread
[16:44] <gary_poster> I have never encountered before.  I assume it is tied to the number of files/amount of code we have
[16:47] <gary_poster> hm, increasing timeout does not help.  we appear to have some kind of intermittent hang?
[16:47] <gary_poster> timeout clearly is being honored
[16:47] <gary_poster> interesting
[16:49] <hatch> faster computers!
[16:50] <hatch> looks like we all need to requisition new computers to be able to do our jobs...
[16:50] <gary_poster> neither phantom nor mocha-phantom have any kind of verbosity flag :-/
[16:50] <gary_poster> as I said, that doesn't seem to be the problem here
[16:50] <gary_poster> it's a hang of some sort
[16:50] <hatch> no...it is...new computers....;)
[16:50] <gary_poster> or something else that takes > 20 seconds
[16:50] <gary_poster> heh
[16:51] <hatch> but yeah, I have nothing to add here other than every time it happens to me I run it again and it works the second time
[16:51] <hatch> I haven't looked into it
[16:51] <gary_poster> virtually consistent for me.  and make test-debug now fails as well, which it was not before
[16:51] <hatch> hmm that's odd
[16:51] <hatch> jcsackett, am i supposed to re-review that branch?
[16:52] <jcsackett> hatch: only if you want to, i was pushing up changes requested for rick_h_.
[16:54] <hatch> jcsackett, hmm - I see that you went away from widget to base but aren't using any base methods....is this going to be expanded at some point?
[16:54] <hatch> or is it pretty much done?
[16:55] <jcsackett> hatch: not sure. there's some work with a view that will use this, and i don't know if it will need to be updated then.
[16:55] <rick_h_> hatch: it'll be wrapped in a Y.View() in the future. It's just a wrapper for prettyprint.js
[16:55] <jcsackett> rick_h_: it's a *little* more than that man, don't go hurting my feelings now. :-P
[16:55] <rick_h_> hatch: the old code needed to be passed an ATTR for the file content and I didn't want to hold onto the file content in JS memory since it's not needed to be reused/etc
[16:56] <rick_h_> jcsackett: trying to simplify for hatch :P
[16:56] <hatch> oh ok - in that case you can probably get away from Y.Base entirely and go with a Object.create() on a constructor fn
[16:56] <hatch> Y.Base is pretty heavy - and if you aren't using any of it's lifecycle methods then there is really no bennefit
[16:56] <jcsackett> hatch: you just like throwing entirely new ways to do things at me.
[16:56] <jcsackett> :-P
[16:56] <hatch> benefit
[16:56] <rick_h_> hatch: yea, that's true. I guess we can go all the way down and then if we do need something once it's wrapped in the view add it back into play.
[16:57] <hatch> jcsackett, haha - best way to learn ;)
[16:57] <jcsackett> so, Object.create syntax is documented where now?
[16:57] <gary_poster> teknico, does this let make test-debug run for you?  http://pastebin.ubuntu.com/5611209/
[16:57] <hatch> jcsackett, one second
[16:58] <teknico> gary_poster, I just lot mo' fancier breakage from our friendly "lbox submit": http://pastebin.ubuntu.com/5611208/
[16:58] <teknico> gary_poster, I'll try
[16:58] <hatch> jcsackett, https://developer.mozilla.org/en-US/docs/JavaScript/Reference/Global_Objects/Object/create
[16:58] <hatch> and it's being used in assets/routing.js
[16:59] <hatch> jcsackett, it's basically the ES5 way of doing Y.Base.create
[16:59] <hatch> and if you want to know the old school manual way of doing it
[16:59] <hatch> http://fromanegg.com/post/41107863511/prototypes-and-class-like-objects-in-javascript
[16:59] <hatch> you can read that blog post, and the previous one
[16:59] <rick_h_> jcsackett: and at this point might as well add it to the prettify wrapper and stick it on a namespace so it's one module vs two.
[16:59] <hatch> I haven't had time to write the followup
[17:00] <jcsackett> right, i'll just kill fileviewer at this point.
[17:00] <rick_h_> jcsackett: basically after the point point, assign a helper to a namespace the module provides and we can use thast
[17:00] <rick_h_> jcsackett: sorry :(
[17:00] <rick_h_> lol, point point...after the "paste point"
[17:00] <teknico> gary_poster, yes, with that change make test-debug worked thrice out of three
[17:00] <jcsackett> rick_h_: so to be clear, we'll just update Y.prettify.prettyPrint to take code and container?
[17:00] <gary_poster> teknico, for your first and last error I'm guessing that's just because you have the test server already running.  For the rest...I dunno.
[17:01] <gary_poster> yay teknico!
[17:01] <jcsackett> hatch, you good with that idea?
[17:01] <teknico> gary_poster, shall I commit to the code? pretty please? :-)
[17:01] <gary_poster> OK, you are trying to submit, right?  see if it works now
[17:01] <gary_poster> teknico, yes :-)
[17:01] <rick_h_> jcsackett: so in https://codereview.appspot.com/7762045/patch/11001/12004 add a helper function on the ns
[17:01] <rick_h_> ns.render_to_node(node, code) kind of thing
[17:02] <jcsackett> rick_h_: ok.
[17:02] <hatch> jcsackett, sure - it wasn't my intention to say your approach was wrong, just pointing out an alternative approach
[17:02] <hatch> I'll let you go whichever approach you feel best suits your task
[17:02] <jcsackett> hatch: well, but if we're going to object.create, there's the questino of do we even need the object.
[17:02] <rick_h_> jcsackett: definitely still check out Object.create though, good stuff :)
[17:02] <jcsackett> when i was thinking we stored the code, we needed an object. i think after rick's suggestion it's clear we just need a fn.
[17:02] <hatch> that's valid - I don't know the end goal of what you're doing :)
[17:03] <hatch> gary_poster, FYI while Ben fights with the CI issues I have taken over the NS router issues - first step is to convert it into an extension, so that's what I'm working on now
[17:05] <gary_poster> cool hatch sounds good
[17:08] <teknico> ooh, branch landed, coool :-)
[17:09] <teknico> I'm buying a faster computer anyway ;-)
[17:10] <rick_h_> teknico: has the right of it. If tests are too slow, need a faster ssd and more ram!
[17:11] <hatch> lol faster ssd
[17:11] <teknico> nope, not OCZ, not going there :-P
[17:11]  * hatch has an OCZ ssd
[17:11] <hatch> it was the cheapest :P
[17:11] <teknico> "OCZ: the MySQL of storage"
[17:11] <hatch> rofl
[17:12] <hatch> so does that mean 'general use and reliable' ? ;)
[17:12] <teknico> not exactly :-)
[17:12] <rick_h_> intel or bust! :P
[17:12] <hatch> haha
[17:12] <teknico> it means "gimme speed now! who cares if your data will be there tomorrow?"
[17:13] <gary_poster> writing to /dev/null is pretty fast, I think
[17:13] <hatch> good thing I have a 3tb synology nas with it's own backup ;)
[17:13] <hatch> gary_poster, lol
[17:27] <gary_poster> hatch, bcsaller would appreciate a review of https://codereview.appspot.com/7703047 when you get a chance.  This is the GUI code needed to get the charm to behave as I think we want.
[17:27]  * gary_poster lunches
[17:28] <hatch> okee
[17:30] <bac> guihelp: anyone have time for a quick review of my gui-only 'get service' branch?  https://codereview.appspot.com/7777045/
[17:31] <bcsaller> bac: on it
[17:31] <bac> thx
[17:31] <bac> i'm reviewing gary_poster's.  don't see a card for it.
[17:33] <hatch> bac, yep I can do that
[17:34] <bac> thanks hatch
[17:40] <hatch> bac, review done!
[17:47] <bac> thanks hatch
[17:48] <hatch> gary_poster, review done!
[17:48] <gary_poster> thanks hatch, bac, and bcsaller!
[17:57] <bac> bcsaller & hatch, thanks for your review comments.  it isn't clear to me what you suggest we do wrt the bind.  if not 'this' then what?
[17:57] <bac> if not now, when?  if not us, who?
[17:58] <bcsaller> bac: I think we should document that 'this' isn't meaningful to the callback, its most likely not whats expected
[18:00] <bac> bcsaller: since the context is not used in the callback, can i just pass null?
[18:01] <bcsaller> bac: I don't think so, no, its just worth noting in the docs I think.
[18:01] <bac> bcsaller: null works...at least in the tests
[18:02] <bcsaller> bac: I guess that would make it clear, this.<anything> will fail for the most part now
[18:02] <bac> yep
[18:02] <bac> i'll document it too
[18:03] <bac> i just thought we needed to bind *something*
[18:04] <gary_poster> bcsaller, the CI tests are with trunk, right?  Not the most recent release?
[18:04] <gary_poster> that would seem like the right place to start :-)
[18:05] <bcsaller> gary_poster: they will be, if you look in the CI config you can see the custom branch we're using pre-merge
[18:05] <gary_poster> bcsaller, ok cool thanks
[18:06] <hatch> lunching
[18:10] <benji> wierd, the go regex library does a "search" when you ask for a "match" and there is no way to actually get a "match"
[18:10] <bcsaller> at least I see whats happening with the CI test now, that too way too long to figure out
[18:10] <bcsaller> benji: it doesn't support ^ at the start?
[18:11] <benji> bcsaller: it does, but that also means that you are forced to use them, making combining regular expressions harder (you have be continually stripping off or adding on ^ and $)
[18:12] <bac> white smoke!
[18:12] <bac> how long until the cathedral bells start up?
[18:13] <bac> guess the bishop here doesn't have the NYT app
[18:14] <benji> bac: I assume that means there is white smoke somewhere in the world.
[18:17] <bcsaller> at least I see whats happening with the CI test now, that too way too long to figure out. Not sure how to properly handle it either
[18:17] <bcsaller> hatch: got a second to talk through this?
[18:17] <bac> and the bells have started
[18:17] <hatch> sure one minute let me get to my comp
[18:18] <hatch> white smoke...bells? what are our CI tests passing? :P
[18:18] <bac> yes, saucelabs is going old school
[18:18] <hatch> lol
[18:18] <hatch> bcsaller, ok in guichat?
[18:18] <bcsaller> I am
[18:19] <rogpeppe> benji: you could always do a FindIndex and check that the returned indexes cover the whole string
[18:19] <benji> rogpeppe: that is a possability.
[18:20] <rogpeppe> benji: unfortunately that assumes that the regexps match with leftmost-longest, which i don't think they do.
[18:20] <rogpeppe> benji: (you can get that functionality in tip, but that won't help much)
[18:21] <rogpeppe> benji: in general, i just add ^ and $ as appropriate
[18:28] <bac> gary_poster: did you check uistage after landing your branch?  it's dead now...one of us did it.  :)
[18:29] <gary_poster> bac, no, thanks and sorry.  almost certainly me, with a conflict in config.  will look
[18:30] <bac> gary_poster: i've done it
[18:30] <bac> restarting now
[18:30] <gary_poster> thank you bac.  conflict?
[18:30] <bac> it was you.  :)  i meant to add a reminder during the review but forgot
[18:30] <gary_poster> :-)
[18:31] <gary_poster> sorry and thanks again.  my "card" was the charm card, since that's what this is for, but should have made another.
[18:31] <bac> happy now
[18:31] <gary_poster> yay
[19:33] <hatch> ugh it's getting warm enough for the door to door sales people
[19:33]  * hatch hopes for -40 again
[19:33] <rick_h_> lol
[19:33] <rick_h_> interesting, -40C == -40F?
[19:33] <hatch> yeah - see at -40 even Americans know to stay the F inside
[19:33] <hatch> rofl
[19:34] <hatch> oh sometimes I crack myself up :P
[19:34] <rick_h_> it was -5C earlier...had some fun ice on the way to day care
[19:34] <hatch> around freezing is the worst because then you get black ice
[19:34] <rick_h_> woot, up to a light and sunny -2.5C
[19:34] <hatch> at least when it's really cold the ice isn't hidden
[19:34] <rick_h_> hatch: yea, right at the end of the subdivision I got to keep on going wheeeee
[19:34] <hatch> haha
[19:35] <rick_h_> I now know the new car can make it in/out of a ditch nicely :)
[19:35] <hatch> lol - no car can get out of a ditch here unfortunately
[19:35] <hatch> usually a couple feet of snow in them
[19:37] <hatch> My real question is....who goes door to door at 1:30PM? Don't they know people work during the day?
[19:43] <benji> casing the joint?  (most home burglaries happen during the day when no one is home)
[19:45] <hatch> entirely possible
[19:47] <hatch> My guess is that they were from one of the many churches in the area
[19:47] <hatch> I think there are 5 different kinds within a mile or so
[19:48] <hatch> actually there are 3 all on the same corner
[19:49] <hatch> well...intersection
[19:53] <benji> hrm, go doesn't have negative indexing (i.e., my_string[:-1])
[19:57] <hatch> that's a good thing...no?
[19:57] <hatch> wait, nm I misread
[19:57] <hatch> :)
[20:12] <bac> gary_poster: i went ahead and moved the "'deploy' in juju-core" card.  if rog wants retroactive changes i'll have to do another card anyway to avoid confusion
[20:12] <gary_poster> +1 bac
[20:17] <hatch> hmm 64 failures after moving the ns routing code into it's own module
[20:17] <hatch> me thinks the tests r broken ;)
[20:18] <hatch> oh 52 this time....
[20:18] <hatch> hmmm
[20:18] <hatch> and now 2
[20:18]  * hatch is confused
[20:19] <hatch> ok it looks like it's decided on 2
[20:32] <hatch> Makyo, did you ever figure out how to get console logs working in mocha?
[20:32] <Makyo> hatch, Didn't have time to look into it, sorry :/
[20:32] <hatch> no problem
[20:35] <hatch> yay they all pass
[20:35] <bac> call me crazy, but i don't think this file should be in our tree: state/api/apiserver.go.THIS
[20:35] <gary_poster> CRAZY!
[20:35] <bac> doh
[20:35] <hatch> you're crazy!
[20:35] <hatch> haha
[20:36] <hatch> oh I was too slow
[20:36] <bac> oh, i know, to regain sanity i'll check in OTHER too
[20:36] <gary_poster> lol
[20:36] <hatch> does the file actually end in an uppercase THIS ?
[20:37] <Makyo> That's how bzr does conflicts.  You get a THIS, OTHER, and BASE
[20:38] <Makyo> But you can bzr revert state/api/apiserver.go.THIS if you get a conflict.  Just ran into that.
[20:38] <Makyo> s/revert/resolve
[20:38] <hatch> ohh I knew that
[20:38] <hatch> I swear!
[20:38] <Makyo> I was gettin "  Conflict adding file state/apiserver/api_test.go.BASE.  Moved existing file to state/apiserver/api_test.go.BASE.moved." and resolve fixed that, FWIW
[20:39] <Makyo> On a bunch of files.
[20:39] <Makyo> Happened when I switched without committing
[20:40]  * Makyo rambles.  Could go on for hours.
[20:41] <hatch> my computer jumps about 15C when I lbox propose haha
[20:44] <hatch> could I get a review of https://codereview.appspot.com/7757046/ plz it's about a 1000+ln diff but most of that is copy/paste
[20:45] <hatch> I lied, I'm that good and wrote 1000 lines of code today
[20:45] <gary_poster> :-)
[20:45] <hatch> haha
[20:45] <gary_poster> I'm looking hatch, while waiting on the charm...again...
[20:46] <hatch> gary_poster, are you deploying it on canonistack?
[20:46] <hatch> and thanks
[20:47] <gary_poster> hatch, no, ec2.  but the tests run, and then they fail, and that took half an hour, and you don't really have diagnostics, so you have to bring the charm up again outside of the tests and investigate, which takes time, and then everything is fine, so you try a different configuration, which takes time...I'm just complaining :-)
[20:47] <hatch> haha yup, that's what we were doing during the sprint
[20:48] <hatch> it takes a toll....mentally
[20:48] <hatch> haha
[21:07] <gary_poster> hey hatch, you up for a call?  I think I understand everything in your branch...well, almost everything :-P...but I want to ask some questions.  guichat?
[21:13] <hatch> yeah sure
[21:25] <hatch> Makyo, ol buddy ol pal.... any chance I could get a review on my nsRouter > extension branch? :-)
[21:25] <Makyo> hatch, need to walkadoggy, can it wait until I get back?  Still have an hour and a half until EOD
[21:25] <hatch> oh yeah for sure
[21:26] <hatch> :) thanks
[21:26] <Makyo> Back in a few, then.
[21:29] <hatch> jcsackett, review done!
[21:29] <jcsackett> hatch: thanks!
[21:32] <hatch> bcsaller, were you successful with the ip caching method?
[21:37] <bcsaller> hatch: I might be, its take a couple rounds to get right, it wasn't passing through the env properly before
[21:52] <hatch> ahh, yeah it's such a slow moving process
[22:08] <hatch> thanks for the review Makyo
[22:08] <Makyo> Thanks for the branch :_
[22:08] <Makyo> :)
[22:40] <hatch> hmm what's the process for resolving lbox merge conflicts? Was it merge in trunk first then submit?
[22:40] <gary_poster> yes hatch
[22:40] <hatch> ok thanks, just wanted to confirm
[22:51] <hatch> does anyone know of any 'build your own website' services that are any good?
[22:51] <hatch> person I know is looking to put together a quick site for a rental
[22:54] <gary_poster> hatch http://www.squarespace.com/ may be more than what the person wants but I had good luck with them for a friend
[22:57] <hatch> great thanks I'll pass that off
[22:57] <hatch> the only thing I had was templatemonster.com + wordpress host
[22:57] <hatch> :)
[22:58] <gary_poster> :-)
[22:59] <gary_poster> hatch, what's the rietveld for your CI doc branch?  Don't see it on card
[22:59] <hatch> it wouldn't rietveld it kept giving me errors about a diff
[22:59] <hatch> I manually requested a merge - I'll grab the link
[23:00] <hatch> https://code.launchpad.net/~hatch/juju-gui/ci-documentation/+merge/153165
[23:00] <hatch> I think I will make a couple small changes though
[23:00] <hatch> I want to add a link to the wiki with our u/p's for the various services
[23:01] <gary_poster> ok hatch, lemme know when that's up and will review.  maybe not tonight. :-)
[23:01] <gary_poster> charm landed btw
[23:01] <hatch> great!


[18:34] <GLAT-agent1> Hello. I am selling GNU/Linux licenses. Contact me if you want one ($99 for single computer, $49 for each computer if purchasing for 25 or more machines).