[00:10] <m_3> SpamapS: omg that's funny
[00:10] <m_3> like a piano pedal
[00:11] <m_3> imbrandon: ok, I think I'm done polluting your bugspace with comments
[00:11] <imbrandon> np :) can i prom it too ? hehe
[00:11] <imbrandon> actually i need dinner, bbiab
[00:12] <m_3> imbrandon: just test running charm-tools 'review' from vim
[00:12] <imbrandon> m_3: btw what were ya testing ?
[00:12] <imbrandon> ahh
[00:13] <imbrandon> if someone wants to +1 it too would be cool to get into the store :)
[00:13] <imbrandon> but for now, off to get fooooood
[00:14] <m_3> imbrandon: me too
[05:19] <SpamapS> so, am I evil because I created a charm to scale out john the ripper?
[05:20] <SpamapS> EvilMog: ^^
[05:20] <SpamapS> EvilMog: its.. alive
[05:20] <SpamapS> EvilMog: lp:~clint-fewbar/charms/precise/john/trunk
[05:20] <SpamapS> needs a README I suppose
[05:26] <SpamapS> and now for something completely different...
[05:26] <SpamapS> sleep
[05:37] <EvilMog> awesome
[05:38] <EvilMog> I'll give that a shout in the morning :)
[05:39] <EvilMog> shot
[05:39] <EvilMog> also I'll get the corelan and metasploit guys to try it out
[07:01] <_mup_> txzookeeper/trunk r49 committed by kapil.foss@gmail.com
[07:01] <_mup_> update changelog
[08:08] <jml> is there standard copyright for Canonical written charms?
[08:08] <jml> this is for an AGPL service
[08:25] <jml> SpamapS: why did you lie to me?
[09:02] <jml> SpamapS: never mind.
[12:01] <lifeless> how do you tell juju to use a proxy server for apt ?
[12:01] <lifeless> And
[12:02] <lifeless> how can you tell juju to use the ip address of started instances, rather than the hostname
[12:19] <hazmat> lifeless, we don't have support for it yet re proxy.
[12:20] <hazmat> lifeless, the ip inspection is specific to the provider being used. typically its using hostname -f output
[12:25] <hazmat> re apt proxy support its bug 897645
[12:25] <_mup_> Bug #897645: juju should support an apt proxy or alternate mirror for private clouds <cloud-init:Fix Released> <juju:Confirmed for hazmat> < https://launchpad.net/bugs/897645 >
[13:04] <jml> http://code.mumak.net/2012/06/unfiltered-reflections-on-my-first-juju.html
[13:35] <m_3> jml: great info in the write-up thanks!
[13:36] <jml> m_3: my pleasure
[13:39] <m_3> we need to update the django-based charms to check status of applied puppet manifests... I missed that
[13:40] <m_3> debug-hooks might be worth your time checking out... only problem is you can't catch the install hook.  That often makes me wanna put more logic in config-changed so I can catch it
[13:42] <m_3> jml: which branches are you referring to when saying you should prefer http://code.launchpad.net/ over lp:?
[13:44] <m_3> jml: also, your typical dev iteration might include terminate-machine on ec2... as it's sometime nice to try again with a pristine instance.  destroy-service does this in lxc, but not ec2
[13:46] <m_3> anyways... awesome... I'm excited to see how pkgme gets structured
[13:52] <jml> m_3: any branch on Launchpad. e.g. lp:libdep-service
[13:53] <jml> m_3: I don't want to say http://bazaar.launchpad.net/~libdep-service-committers/libdep-service/trunk because it's not what I mean.
[14:04] <m_3> jml: ah, ok... thought you meant when checking out the charms into a local repo.  was wondering where juju was complaining about that
[14:05] <jml> m_3: it's not juju there, it's bzr moaning about not having launchpad-login set, which is always going to be the case in any automated deploy
[14:06] <jml> m_3: it's really important that all displayed errors actually be errors, and that all actual errors are displayed as such
[14:08] <hazmat> m_3, that's fixed incidentally but it timing dependent
[14:08] <hazmat> its
[14:08] <hazmat> ie debug-log and debug-hooks both can catch install
[14:09] <hazmat> actually that shouldn't be timing dependent
[14:09]  * hazmat verifies
[14:11] <hazmat> jml, hooks already run with dpkg env vars to set frontend to noninteractive and list changes frontend to none.
[14:12] <jml> hazmat: yeah, I thought my list mentioned that, and that 'sudo' masks that env var
[14:12] <jml> because sudo does that
[14:12] <hazmat> jml but why sudo when one is already root
[14:13] <hazmat> but good to note agreed
[14:13] <jml> hazmat: because I didn't know hooks were run as root when I started
[14:13] <hazmat> gotcha
[14:13] <jml> and also, it's nice to note what bits I'm doing in the install that _have_ to be root
[14:15] <hazmat> jml, alternatively sudo -E for env preservation
[14:24] <hazmat> m_3, just verified you can run debug hooks on install hooks now
[14:39] <m_3> hazmat: whoohoo!!
[14:53] <SpamapS> Yeah I've been using debug-hooks to *write* install hooks for a while now
[14:54] <SpamapS> i.e., start with empty charm, deploy, debug-hooks (quickly!) and then iterate, then juju scp the hook back into the bzr branch :)
[14:54] <SpamapS> I'd love an option to make juju use bzr rather than the zip file to grab the charm, so it would be easy to push changes back
[14:55] <marcoceppi> +1
[14:55] <SpamapS> jml: great brain dump. These definitely help to focus our efforts.
[15:01] <jml> SpamapS: thanks. I might follow up with something that's a bit more reflective
[15:04]  * jml submits a super-naïve patch
[15:14] <bloodearnest> hey all - so I'm attempting to write a hook in python, but calls to subprocess seem to blow up
[15:16] <bloodearnest> is there a better way to do relation/config-set/get in a python hook? If not how can I interact with the shell relation-get et al?
[15:18] <SpamapS> bloodearnest: there are lots of cases of python hooks which use subprocess to call relation-* and such
[15:19] <SpamapS> hostname = subprocess.check_output(['unit-get','private-address']).strip()
[15:19] <SpamapS> bloodearnest: for instance
[15:23] <bloodearnest> SpamapS, right - so I'm doing something wrong then
[15:24] <SpamapS> bloodearnest: are you perhaps trying to call these hooks outside of the actual juju agent?
[15:33] <bloodearnest> SpamapS, nah - my bad missed the /usr of  /bin/env :(
[15:57] <hazmat> bcsaller, jimbaker ping
[15:57] <bcsaller> hazmat: whats up?
[15:57] <hazmat> need to have a trivial vetted
[15:57] <bcsaller> link?
[15:58] <hazmat> see msg
[15:59] <sidnei> uhm, trying to juju bootstrap on precise and seems to be hanging on virsh net-list --all, known issue?
[16:05] <m_3> sidnei: not sure... wow, actually _hanging_ on virsh net-list... you might make sure you either rebooted since installing libvirt-bin and/or are in the libvirtd group
[16:06] <sidnei> checked both yes. also, i had lxc working before doing this, with cgroups-lite and such, lxcbr0 already present, and juju prompted me to install libvirtd-bin
[16:07] <sidnei> maybe this is one for hazmat per https://blueprints.launchpad.net/ubuntu/+spec/servercloud-q-juju-charm-best-practices (hi!)
[16:09] <m_3> sidnei: yeah, lxcbr0 isn't used unfortunately... juju local provider uses lxc containers but libvirt networking
[16:09] <m_3> sidnei: sidnei sometimes you can clear out lxc networking hangs by a `juju destroy-environment`
[16:09] <sidnei> maybe they are stomping on each other
[16:09] <m_3> sidnei: also look in `lxc-ls` and /var/lib/lxc
[16:10] <m_3> sidnei: possible... but they default to totally different nets... you can see with `ps auwx | grep dnsmasq` which nets are really active
[16:10] <sidnei> as i said above, i was already using lxc, there's a couple envs under /var/lib/lxc all from before juju
[16:14] <m_3> sidnei: gotcha
[16:19] <jcastro> negronjl: ping me when you're home
[16:20] <jcastro> I'd like to find out how your demo went
[16:25] <negronjl> 'morning all
[16:25] <negronjl> jcastro: I'm here
[16:25] <jcastro> mind if we G+? I just need to grab lunch real quick
[16:31] <negronjl> jcastro: sure .. invite me when ready
[16:33] <jml> I'm writing up documentation for my project for contributors and potential users
[16:34] <jml> I'm saying, "The easiest way to run libdep-service is with Juju"
[16:34] <jml> what landing page should I point them at for getting the initial EC2 and/or LXC stuff set up?
[16:40] <jcastro> jml: https://juju.ubuntu.com/docs/getting-started.html
[16:57] <jcastro> negronjl: hangout started!
[16:57] <newz2000> I have some very nice improvements to the Varnish charm that I'm about to push.
[16:57] <newz2000> Improvement #1: It works now. :-)
[16:57] <newz2000> (on LXC, it might have worked on EC2 before)
[16:59] <SpamapS> newz2000: \o/
[17:01] <_mup_> juju/trunk r543 committed by kapil@canonical.com
[17:01] <_mup_> [trivial] local provider disables password auth on containers [r=bcsaller]
[17:12] <newz2000> Hi, got my first charm mp posted: https://code.launchpad.net/~newz/charms/precise/varnish/fix-lxc-deployment/+merge/111648 Would love feedback, going to use this to try and make a squid charm.
[17:12] <SpamapS> newz2000: heh.. squid.. because.. varnish is just too awesome for you? ;)
[17:13] <newz2000> SpamapS: well, Varnish is awesome but we use Squid in ISD, the team I work on.
[17:14] <SpamapS> newz2000: actually squid should be good.. you can then run a test and see just how much better varnish is. :)
[17:14] <newz2000> You're talking to the wrong guy on this. I just write the code. Someone else deploys it.
[17:16] <SpamapS> newz2000: thats not the devops way! ;)
[17:16] <SpamapS> we all write it
[17:16] <SpamapS> we all deploy it
[17:16] <newz2000> I would *love* to do it the devops way
[17:16] <SpamapS> and we all wear a pager from time to time if things are really being fair
[17:16] <newz2000> we don't do it that way though. :-)
[17:17] <SpamapS> newz2000: well anyway, I believe Dustin Kirkland took a stab at squid at some point
[17:17] <newz2000> oh
[17:17] <SpamapS> newz2000: so maybe dig in https://code.launchpad.net/~kirkland
[17:17] <newz2000> Apparently there is more than one place to look for charms
[17:17] <SpamapS> its not official tho.. so just do a fork of varnish if thats easier :)
[17:17] <newz2000> k
[17:31] <jml> jcastro: thanks.
[17:32] <jml> does this read right? http://paste.ubuntu.com/1054642/
[17:32] <jml> anything I can do to make life easier for my contributors?
[17:36] <bloodearnest> the docs say that config-get with no args will output json, but when calling it from python I get python a dictionary repr rather than json
[17:37] <bloodearnest> *a python dictionary repr
[17:39] <SpamapS> bloodearnest: indeed, its a known bug
[17:39] <SpamapS> bloodearnest: --format json
[17:39] <bloodearnest> SpamapS, I tried that, but got empty string#
[17:39] <SpamapS> marcoceppi: hey, how's wordpress coming along?
[17:41] <pindonga> hi there... so, in my charm I need to setup access to a private ppa so I can install some custom packages... I was thinking of somehow passing the credentials in so I can customize a template for the apt config, any suggestions?
[17:42] <m_3> pindonga: pass it in config
[17:42] <imbrandon> SpamapS: any word from isd ?
[17:42] <imbrandon> err is
[17:43] <pindonga> m_3, got any examples around?
[17:43] <SpamapS> imbrandon: they've ACK'd the ticket
[17:43] <imbrandon> :(
[17:43] <SpamapS> imbrandon: but not sure when it will be ready
[17:45] <imbrandon> SpamapS: i had wordpress running on rails last night :) phrake , kinda amusing ... for 5 minutes
[17:46] <m_3> pindonga: lemme look.  thinking pass the key and/or key_id in yaml and then pass the $(config-get key) to apt-key
[17:46] <pindonga> m_3, ah
[17:46] <pindonga> k, could work
[17:46]  * pindonga tries
[18:01] <jml> ping again re patch: https://code.launchpad.net/~jml/juju/stderr-as-info/+merge/111609
[18:08] <jml> also, feedback requested on short doc snippet for users of a project that recommends using juju to deploy it: http://paste.ubuntu.com/1054642/
[18:09] <marcoceppi> jml: the readme should assume the charm is in the store, IIRC
[18:09] <SpamapS> marcoceppi: not necessarily
[18:09] <jml> marcoceppi: I'm not sure this project belongs in the store, tbh.
[18:10] <SpamapS> there are plenty of cases where a charm will be highly useful, but never be in the store
[18:10] <jml> marcoceppi: and atm, the charm is included in trunk
[18:10] <SpamapS> just like some things don't make any sense being in a distro's archive
[18:10] <jml> (does that make it the Juju equivalent of "native package"?)
[18:11] <m_3> jml: I'd make sure it's clear that your --repository is a path... `juju deploy --repository ~/charms local:libdep-service`
[18:11] <jml> m_3: good point (although it's "./charms" in this case)
[18:11] <m_3> jml: and then also don't forget `juju expose`... it won't be available over the web until after that's done
[18:11] <m_3> jml: lxc is an exception (no security)
[18:11] <jml> ahhh
[18:12] <jml> m_3: I was about to disagree with you :)
[18:13] <m_3> jml: I like to point people to entire deployment/spinup scripts... like https://gist.github.com/2050525 or https://gist.github.com/1406018
[18:13] <SpamapS> Can people please try the latest version of the PPA with the local provider? I'd like to tag r543 as 0.5.1
[18:14] <jml> m_3: yeah, I think I'll do that in a future iteration.
[18:14] <m_3> SpamapS: sure... trying now
[18:14] <m_3> jml: awesome README example is lp:charms/hadoop
[18:14] <jml> m_3: I guess I'm slightly disappointed that writing wrapper scripts seems appealing
[18:14] <m_3> ha
[18:14] <m_3> yes
[18:15] <m_3> jml: it's only for spinup... note that juju maintains the "model" going forward... you make changes directly using the juju cli
[18:15] <m_3> jml: but it's often handy to start things off with a script
[18:15] <m_3> jml: keep your eyes peeled for "stacks" going forward... (juju can serialize/deserialize its model)
[18:16] <jml> Yeah, I remember talking about stacks in Capetown.
[18:18] <sidnei> uhm, seems like virsh is stuck polling /var/run/libvirt/libvirt-sock
[18:20] <jml> And, you know what, two blog posts in one day: http://code.mumak.net/2012/06/further-reflections-on-my-first-juju.html
[18:20] <jml> don't ever say I don't care about you guys
[18:22] <SpamapS> jml: I don't care about you guys
[18:22] <jml> I don't want to be harshing on you guys. It's great work.
[18:22] <jml> I really do hope these posts help.
[18:24] <SpamapS> jml: hey, have you tried this, I do it sometimes and its surprisingly nice and interactive: watch 'juju status | ccze -A'
[18:25] <SpamapS> wait thats not right
[18:26] <jml> SpamapS: I didn't know about ccze.
[18:26] <jml> cool.
[18:26] <SpamapS> yeah its fairly smart
[18:27]  * jml has to go. I've got to pack & head out to Canterbury.
[18:27] <SpamapS> at one point I had it showing without flickering.. can't recall how now tho
[18:28] <SpamapS> jml: anyway, debug-log | ccze -A helps with the colorizing a lot
[18:28] <jml> SpamapS: yeah, I'll bet.
[18:29] <SpamapS> (using -A just makes it scrollable)
[18:29] <SpamapS> jml: I too worry about the feedback loop a lot.. its just hard to correct that one because apt-get installing stuff will never be "zippy"
[18:30] <SpamapS> jml: but anywa, go away, enjoy Canterbury, and bring us their Tales when you're done
[18:30] <jml> SpamapS: right. perhaps it could be cleaner though.
[18:30] <jml> SpamapS: I think I'm obliged to tell tales on my way there. Not 100% sure though.
[18:30]  * jml is gone
[18:33] <SpamapS> "Oh, I should mention that I got stuck for a while at the very outset, redeploying the same version of my charm because I forgot to update the revision file and didn't realize that I actually wanted to run deploy with the --upgrade option."
[18:34] <SpamapS> And yet.. we still require this nonsense. :-/
[18:34] <SpamapS> I don't think a single new user has been able to avoid that problem.
[18:34] <SpamapS> niemeyer: ^^ we need to think long and hard about the revision file.. again.
[18:39] <jcastro> "#juju is heaps better when America is awake"
[18:39] <jcastro> heh
[18:40] <imbrandon> lol, who said that
[18:40] <SpamapS> do we have EU charmers? James Page, but he's like, too busy holding up the pillars of ubuntu server and QA...
[18:41] <sidnei> SpamapS, would you have any clue about virsh just plain hanging?
[18:41] <imbrandon> there are a few that are "unknowns" that are regualrs overnight
[18:41] <imbrandon> but i couldent tell ya their names
[18:41] <jcastro> it'd be jim baker and lynxman
[18:41] <SpamapS> sidnei: hanging? no.
[18:42] <imbrandon> i see them night after night tho
[18:42] <jcastro> those would be the other two .eu people I can think of
[18:42] <SpamapS> jcastro: Jim is in Colorado
[18:42] <jcastro> oh, right
[18:42] <jcastro> sorry, I meant will
[18:42] <jcastro> but he's Golanging isn't he?
[18:43]  * m_3 _hates_ lxc
[18:43] <imbrandon> ^5 m_3
[18:43] <sidnei> SpamapS, turning the question around, is it possible to use juju in lxc mode without libvirt-bin installed?
[18:43] <SpamapS> sidnei: no
[18:43] <m_3> sidnei: not with out some code munging on your own
[18:43] <SpamapS> sidnei: it uses libvirt's network management
[18:43]  * sidnei < between a rock and a hard place
[18:45] <SpamapS> sidnei: is it possible that your libvirt 'default' network is broken?
[18:45] <sidnei> SpamapS, well, even just running 'virsh' hangs, and i tried purging and rm -rf 'ing my way around a couple times already
[18:46] <SpamapS> sidnei: oh weird
[18:46] <m_3> sidnei: oh, one other thing... does your default use virbr0 as well as 122.0/24?
[18:46] <SpamapS> sidnei: sudo service libvirt-bin restart maybe?
[18:47] <m_3> virbr0 is explicitly required (at least was)
[18:47] <sidnei> restart no luck, virbr0 is up on 122.0/24
[18:48] <m_3> crap
[18:48] <m_3> with dnsmasq bound there as well?
[18:48] <sidnei> yup
[18:48] <sidnei> /usr/sbin/dnsmasq -u libvirt-dnsmasq --strict-order --bind-interfaces --pid-file=/var/run/libvirt/network/default.pid --conf-file= --except-interface lo --listen-address 192.168.122.1 --dhcp-range 192.168.122.2,192.168.122.254 --dhcp-leasefile=/var/lib/libvirt/dnsmasq/default.leases --dhcp-lease-max=253 --dhcp-no-override
[18:49] <m_3> and `virsh net-list --all` still hangs?
[18:50] <sidnei> yup
[18:51] <jcastro> anyone have ideas for fixing our US-centric responses? Other than "hey if you are not in the US pay more attention"?
[18:51] <m_3> so that's sounding like a more fundamental problem
[18:51] <m_3> jcastro: send me and taylor to paris for part of the year :)
[18:51] <sidnei> uhm
[18:51] <sidnei> http://askubuntu.com/questions/141720/why-is-sudo-virsh-hanging-in-the-console
[18:52] <sidnei> and then killing dmidecode makes virsh work
[18:53] <sidnei> SpamapS, m_3 ^
[18:53] <m_3> nice...
[18:53] <m_3> resource contention
[18:54] <m_3> actually net-list should be any easy one to debug that on
[18:56] <jimbaker> SpamapS, i plan to merge in the charm-format-2 shortly, now that the issues around that are worked out (whether or not _JUJU_CHARM_FORMAT was the sticking point, it remains as an impl detail). the point of it is that it's fully backwards compatible, and there are a substantial number of tests verifying that, so it should be good for galapagos
[18:57] <SpamapS> jimbaker: you're late man.. VERY late
[18:57] <SpamapS> I sent a message over a week ago
[18:57] <sidnei> Error processing 'cs:precise/ubuntu': entry not found
[18:57] <sidnei> 2012-06-22 15:55:07,739 ERROR Error processing 'cs:precise/ubuntu': entry not found
[18:57] <sidnei> shouldn't this work? ^
[18:58] <SpamapS> sidnei: no, its broken
[18:58] <SpamapS> sidnei: sadly. :-/
[18:58] <SpamapS> sidnei: the importer can't import that particular charm for some reason
[18:58] <sidnei> looks like i picked a bad day to start :)
[18:58] <jimbaker> SpamapS, sorry, i misunderstood that. well it goes in the next release then
[18:58] <imbrandon> SpamapS: i sumited the int64 bug to the golang guys
[18:58] <pindonga> is there any wiki page with tricks/idioms for writing juju charms?
[18:58] <pindonga> I'd like to share a way to setup private ppa access in a charm
[18:58] <SpamapS> imbrandon: I don't believe thats the issue with the ubuntu charm
[18:58] <SpamapS> imbrandon: I think its because bzr prints extra stuff
[18:59] <imbrandon> SpamapS: so hopefully it will be fixed soonish
[18:59] <imbrandon> ahh
[18:59] <SpamapS> pindonga: we've been discussing the best way to collect best practices. No consensus yet.
[18:59] <SpamapS> pindonga: a wiki is as good a place as any. Unfortunately the juju wiki is locked down... :-/
[18:59] <SpamapS> jimbaker: yeah, no big deal
[19:00] <SpamapS> jimbaker: we just release whatever is merged, we still have the PPA building the trunk. :)
[19:00] <imbrandon> SpamapS: also i have a new tool i want to unveil monday "hiabu" possibly as part of jitsu ( but its in node so i dunno if you want it in there _
[19:00] <m_3> pindonga: also charm-tools if it's something that makes sense in a helper script
[19:00] <imbrandon> )
[19:00] <SpamapS> imbrandon: I want it
[19:00] <imbrandon> k
[19:00] <SpamapS> imbrandon: juju-jitsu is for all things crazy
[19:00] <jimbaker> SpamapS, sounds like a plan, this is really to help as a bridge for the go port, as well as fix bugs like this one, bug 979859
[19:00] <_mup_> Bug #979859: Unable to set boolean config value via command line <juju:In Progress by therve> < https://launchpad.net/bugs/979859 >
[19:00] <SpamapS> imbrandon: which is why I'm surprised you haven't dominated it ;)
[19:01] <m_3> ouch
[19:01] <imbrandon> SpamapS: its an external dependancy manager
[19:01] <SpamapS> jimbaker: sure. I'm thinking honolulu should actually be shorter. Maybe 4 weeks, so we catch up
[19:01] <imbrandon> SpamapS: hahaha i've been busy with hiabu secretly
[19:01] <imbrandon> is why
[19:01] <imbrandon> :)
[19:02] <imbrandon> but yea hiabu == japaneese for hive, manage "groups" of juju service as one hive, eg. an external dependancy manager
[19:02] <imbrandon> SpamapS: ^
[19:02] <SpamapS> imbrandon: nice
[19:02] <shazzner> hiabu sounds like romanji
[19:03] <imbrandon> :0
[19:03] <m_3> SpamapS: 543 spun up fine using ec2 to host a lp:charms/juju local container... still not up on my laptop, but that's not really expected :(
[19:04] <imbrandon> still needs lotas of work but i can "hibau deploy juju.com" and it figures out that wordpress and mysql etc are needed and spins them all up and scales etc, basicly its just calling out to the correct juju comannds tho
[19:04] <_mup_> Bug #776426 was filed: Add debug hook cli flag for deploy and and add-unit. <juju:Triaged> < https://launchpad.net/bugs/776426 >
[19:05] <imbrandon> i want to work that jitsu watch into it and make it smarter tho
[19:05] <imbrandon> too
[19:05] <shazzner> imbrandon: sounds pretty rad :)
[19:06] <shazzner> my stupid point in mentioning Romanji is that, if true, hiabu isn't strictly 'japanese' :v
[19:06] <imbrandon> ok need to go afk a few, back in ~45 min
[19:06] <imbrandon> ahhh :)
[19:06] <imbrandon> i just couldent think of a nother name to play off the jitsu name :)
[19:06] <imbrandon> and mean group
[19:07] <shazzner> no it's cool, I like it :)
[19:08] <SpamapS> m_3: sweet thanks. I'll give it another 2 hours to settle and then tag.
[19:21] <shazzner> just cause I got curious, Jisho.org tells me Su is the japanese word for hive
[19:21] <shazzner> Hachisu means beehive
[19:22] <shazzner> well, the kanji for hive, is pronounced Su but Su can have differen't meanings
[19:22] <shazzner> sorry I'll shutup
[19:22] <lifeless> hazmat: is there a hack for the proxy?
[19:23] <lifeless> hazmat: on the host side, I have a local openstack install, which isn't integrated with dns, so lookups for e.g. server-45 fail
[19:23] <lifeless> hazmat: is there a config option ?
[19:23] <lifeless> hazmat: Using the ec2 provider.
[19:29] <SpamapS> lifeless: /etc/hosts ?
[19:32] <hazmat> lifeless, re hack, i've got a wip branch but it probably needs some finishing.. lp:~hazmat/juju/apt-proxy-support
[19:32] <hazmat> outside of that going for a dns setup is probably the best option..
[19:33] <hazmat> lifeless, actually the simplest hack.. is pretty straightforward
[19:33] <imbrandon> shazzner: i used google translate, hehe , likely wrong
[19:33] <hazmat> modify juju/providers/common/utils.py  format_cloud_init and cloud_config dict to include  an apt-proxy-url key and value
[19:34] <hazmat> er. cloud_config dict in that method
[19:34] <shazzner> imbrandon: check out jisho.org
[19:34] <imbrandon> kk
[19:34] <shazzner> best online japanese dictionary
[19:34] <imbrandon> rockin, good thing before i released it too :)
[19:34] <imbrandon> ty
[19:34] <shazzner> oh and be sure to tick the Kana as romaji
[19:35] <shazzner> imbrandon: np :) :)
[19:45] <lifeless> hazmat: SpamapS: thanks
[19:45] <lifeless> SpamapS: /etc/hosts doesn't set http_proxy :)
[19:47] <lifeless> hazmat: is there a similar code tweak I could do to get ip usage?
[19:49] <hazmat> lifeless, yes, the relevant bit is in juju/unit/address.py
[19:50] <hazmat> the implementation class used varies by provider
[19:52] <lifeless> hazmat: ah, I wasn't clear
[19:53] <lifeless> hazmat: *bootstrap* is the thing that is using an unresolvable address
[19:53] <lifeless> hazmat: the client node code can't talk to the metadata service.
[19:53] <hazmat> ah
[19:53] <lifeless> I have no idea whether the metadata service will be handing out crapola or not
[19:53] <hazmat> lifeless, so the client resolves the instance id to the ip address
[19:53] <lifeless> hazmat: *how* ?
[19:54] <lifeless> like, does it call the ec2 API to get node details ?
[19:54] <hazmat> lifeless, it queries out the server via the api using the instance id
[19:54] <hazmat> lifeless, yes
[19:54] <lifeless> right, its ending up with 'Server-NNN' atm, not an ip.
[19:54] <lifeless> point me at the code :>
[19:54] <hazmat> lifeless, if you do euca-describe-instances at your endpoint do you see the same?
[19:55] <lifeless> I can't answer that right now
[19:55] <lifeless> server is in weekend mode :P
[19:57] <imbrandon> SpamapS / hazmat : HAHA i wasent going to let it get the best of me, check out http://api.websitedevops.com/juju-docs/operating-systems.html ( then look at the footer for the sphinx version )
[19:57] <hazmat> lifeless, fair enough.. but the client can't really correct for provider errors about addresses. for the client we need an accessible/routable public address for the machine to reach it.
[19:58] <hazmat> lifeless, have a good weekend (in case you follow your server :-)
[19:58] <lifeless> hazmat: we do, but it has one
[19:58] <lifeless> hazmat: I mean, I'll cross check the api results
[19:58] <lifeless> hazmat: but if thats ok, where in the code is this called ?
[19:59] <hazmat> lifeless, that part is a little more.. twisted let's say ;-)  juju/providers/common/findzookeepers.py
[20:00] <imbrandon> SpamapS / hazmat : only one more little quark i need to workout before putting up a MP that should work on 0.6.4 ( all pages TOC is "correct" ) except for the langing page , so there is hope
[20:00] <hazmat> lifeless, basically for ec2 it gets an instance map from provider storage (s3), and then does describe instances on it and returns the public address associated to the instance as the place to tunnel an ssh connection to for zk access.
[20:00] <imbrandon> i got the major issue worked out tho, it dident like :hidden: in the old version
[20:00] <lifeless> hazmat: there is a 1:M mismatch in that code too, room for optimising it looks like
[20:00] <hazmat> imbrandon, nice
[20:01] <hazmat> lifeless, definitely.. although i'm not sure exactly which part your referencing
[20:01] <lifeless> for instance_id in instance_ids: <- synchronous, one loop per instance id.
[20:02] <lifeless> then collects multi-machine errors from the get_machine call, which took one id
[20:02]  * hazmat nods
[20:02] <hazmat> that was my next target on the scaling branch we used for the 2k nodes
[20:03] <lifeless> I would have written it as
[20:03] <lifeless>     machines, missing_instance_ids = yield provider.get_machines(instance_ids)
[20:03] <hazmat> we do it something similiarly dense in status when querying out info
[20:03]  * hazmat checks
[20:05] <lifeless> ah
[20:05] <hazmat> lifeless, right now the provider.get_machines call errors out on missing ids
[20:05] <lifeless> the contract for def get_machines(self, instance_ids=()): isn't conduicive to that approach
[20:05] <lifeless> I'd fix that first :)
[20:05] <lifeless> in set based processing, exceptions need to be super rare
[20:06] <lifeless> because otherwise - well, you know - the successes get crushed.
[20:07] <hazmat> yeah.. in eventually consistent distributed systems, some inconsistencies around the state need to be handled with more grace
[20:08] <imbrandon> lifeless: mind if i pick your brain for a sec on bzr, you work with its internals a bit right ?
[20:08] <lifeless> I played a developer on TV once.
[20:08] <imbrandon> heh
[20:08] <lifeless> (some stupidly large % of bzr is my code, yes I know its internals)
[20:09] <imbrandon> well i'm totally ignorant about the internals of vcs's but really just was wondering the fesability of a git<->bzr bridge thats like the git<->svn bridge on github, where either client can work with the same repo, not a copy of it, at the same time
[20:10] <lifeless> hazmat: hahaha
[20:10] <lifeless>         instance.private_dns_name,
[20:10] <lifeless> hazmat: ^ that is whats used, *not* the ip address.
[20:10]  * lifeless checks to see if there is a more useful field
[20:11] <hazmat> lifeless, ? for what
[20:11] <lifeless> hazmat: using private-ip-address would be better I think
[20:11] <lifeless> hazmat: rather than private-dns-address
[20:11] <imbrandon> ( or even a bzr<->svn bridge etc ) basicly working with multi vcs natively at the same time and keeping the commits/logs in sync transparently
[20:12] <lifeless> imbrandon: you mean like 'bzr-git' ?
[20:12] <hazmat> lifeless, econtext used for what
[20:12] <imbrandon> well kinda, that works on a copy
[20:12] <hazmat> imbrandon, maybe checkout tailor
[20:12] <lifeless> 07:52 < lifeless> hazmat: ah, I wasn't clear
[20:12] <lifeless> 07:53 < lifeless> hazmat: *bootstrap* is the thing that is using an unresolvable address
[20:12] <lifeless> 07:53 < lifeless> hazmat: the client node code can't talk to the metadata service.
[20:12] <imbrandon> hazmat: yea, i have been looking into that
[20:12] <lifeless> hazmat: I followed the pointers you gave me, get_machine -> ec2's get_machines -> machine_from_instance
[20:13] <imbrandon> lifeless: i mean more server side tho, like i can use `git clone https://github.com/myname/myrepo.git` or `svn co https://github.com/myname/myrepo` both r/w tansparently
[20:13] <lifeless> hazmat: jujumachine wants private_dns_name, but that depends on resolvability, whereas taking the ip address in the front end wouldn't
[20:14] <imbrandon> something more like that
[20:14] <hazmat> lifeless, when you say the client node can't talk to the metadata service.. that's unclear.
[20:14] <hazmat> lifeless, the private dns name is used for inter unit internal communication
[20:14] <hazmat> ie. relations
[20:14] <lifeless> hazmat: its also used to talk to the bootstrap node
[20:14] <lifeless> from the juju CLI
[20:15] <lifeless> hazmat: or something; when I run 'juju status', its grabbing the private dns name, and trying to resolve it from outside the cloud.
[20:15] <imbrandon> hazmat: i was wondering why we do that too since split dns takes care of if we use the public dns name
[20:15] <imbrandon> and then its uniform
[20:15] <lifeless> imbrandon: there might not be public ip or pblic dns names.
[20:15] <lifeless> imbrandon: private* is the only guaranteed thing
[20:16] <imbrandon> hrm true, split dns dont help there
[20:16] <hazmat> lifeless, the client isn't using the private address to talk to zk, its using the public dns name given by the api server.
[20:17] <lifeless> hazmat: I beg to differ :)
[20:17] <hazmat> lifeless, i'm confused where you think you see it using the private dns name to facilitate that
[20:17] <lifeless> juju bootstrap-> stuff happens
[20:17] <lifeless> juju status ->
[20:17] <lifeless> 'ssh: Server-32 is not a valid somethingorother to forward via\n\n'
[20:17] <lifeless> loops
[20:18] <hazmat> lifeless, juju/providers/common/connect.py      .. using dns_name not private_dns_name
[20:18] <hazmat> lifeless, we'd never be able to connect to a machine in ec2 otherwise
[20:18] <hazmat> or any other public cloud
[20:20] <lifeless> hazmat: ok, so s/private/public and my whinge still applies; we're depending on dns resolvability, which is lacking for developer installs of e.g. openstack
[20:20] <lifeless> I have no sane way of making the public names resolvable
[20:20] <lifeless> or the private names for that matter
[20:21] <lifeless> I'm on a different machine, having my machine poke via dnsmasq on the cloud server will break my network when I roam, for instance.
[20:25] <lifeless> hazmat: added to that, juju bootstrap isn't requesting a floating ip, so we're only getting flat-network addresses allocated the machines *anyway* (10.0.0.2 for instance)
[20:25] <hazmat> its reasonable to use ips, but their's a tension to have names for hosts for users and for charms that want to configure against names (although some also want to use ips). we should probably capture all.
[20:25] <lifeless> hazmat: I'll have a poke around mondayish
[20:25] <hazmat> lifeless, floating by default can be enabled
[20:25] <lifeless> this has been very helpful, thanks.
[20:25] <lifeless> hazmat: its one more thing for users to get right
[20:25] <hazmat> lifeless, mgz's ostack provider also does the assignment
[20:26] <lifeless> hazmat: and consider how hard canonicloud is to work with ;)
[20:26] <lifeless> (for juju, not in general)
[20:26] <hazmat> lifeless, its only gotten worse since i hacked out the support for it..
[20:26] <hazmat> i did it all without a chinstrap account previously..
[20:26] <imbrandon> i was just about to try the ostack provider today on hpcloud
[20:27] <imbrandon> is it not working ?
[20:27] <lifeless> hazmat: so, perhaps it would be a great exercise for you devs to do all your smoke-and-above testing using canonicloud; without canoniclod-specific hacks.
[20:27] <lifeless> hazmat: :)
[20:27] <lifeless> have a good weekend
[20:29] <hazmat> lifeless, cheers, have a good one.. and no thanks re fool's errand... i'd be willing to talk to the canonicloud folks though if their willing to fix some of the pain points, we can accomodate some change as well (not hacks)
[20:30] <hazmat> but its felt like a very slow moving progression, that's been in the wrong direction as far usability, and afaik still lacking swift
[20:31] <hazmat> openstack isn't a product, its a toolkit for building your own cloud.. i mean snowflake
[20:35] <imbrandon> hehe
[20:36] <imbrandon> hazmat: so should i grab your branch for the ostack provider or ... ? i'm a little confused on what one to use for testing ( and has the higest probablility to work on hpcloud )
[20:36] <imbrandon> i'm starting fresh today with it
[20:37] <imbrandon> and / or rs next gen ostack cloud too, got that activated yesterday
[20:37] <imbrandon> but i think they have ec2 and s3 compat on
[20:37] <hazmat> imbrandon, its a sharp edge.. and not my branch, but if you want to play with it.. lp:~gz/juju/openstack_provider
[20:38] <hazmat> imbrandon, they don't have s3 compat on
[20:38] <imbrandon> kk, yea nothing production but i wanna put those 3 months to use a little and try soem things
[20:38] <imbrandon> i know there will be lots of breakage probably
[20:39] <hazmat> imbrandon, you have to use that for your client and specify juju-origin: lp:~gz/juju/openstack_provider  for the env
[20:39] <imbrandon> k , is there an example env.y in the code ? i hope
[20:40] <hazmat> there aren't any docs for it yet.. but the config keys are at juju/environment/config.py ...
[20:40] <imbrandon> rockin that will workj
[20:40] <imbrandon> yea i figured docs was out of the question for now
[20:41] <imbrandon> btw sometime this evening i'll have the normal docs building again if they upgrade to 12.04 or not
[20:41] <imbrandon> i found a few workarounds that arent too hackish , just one last bit to workout
[20:41] <imbrandon> well arent hackish at all just have better ways in the newer version :)
[20:42] <imbrandon> and really only like a 5 line delta so far, so not like alot of code either, just learning all the quarks
[20:44] <pindonga> hi, I've read I can just include a repositories: section in my environments.yaml to configure my preferred repos
[20:44] <pindonga> however I cannot get it to work, so I assume I edited the wrong place
[20:44] <pindonga> is this actually supposed to be working with the precise version of juju?
[20:44] <imbrandon> pindonga: that was never implmented, its in the draft docs
[20:44] <pindonga> imbrandon, ok, touch luck then
[20:44] <pindonga> thx
[20:44] <imbrandon> pindonga: unless you see it somewhere else , please tell so i can correct it
[20:45] <pindonga> no, I saw it in the drafts
[20:45] <pindonga> some drafts include stuff that works right now
[20:45] <imbrandon> pindonga: you can use JUJU_REPOSITORY env varable to set the local path though
[20:45] <pindonga> so that's why i tried: )
[20:45] <pindonga> yep
[20:45] <pindonga> this was nicer though
[20:45] <pindonga> don't have to do it every tim
[20:45] <imbrandon> that is implmented , yea i wish it was personally, i love that idea, but sadly its not
[20:46] <imbrandon> set the env varable in your bash_profile
[20:46] <pindonga> yep
[20:46] <pindonga> no worries
[20:46] <pindonga> thx
[20:46] <imbrandon> like "export JUJU_REPOSITORY /var/lib/charms"
[20:46] <imbrandon> kk
[20:47] <imbrandon> SpamapS / hazmat : do you all know if that feature got axed or just not done yet, i wanna put a note on it in the docs, cuz i ran into that exact same thing
[20:47] <imbrandon> if its axed i'll just remove it, if not done yet i'll make a note: saying so
[20:48] <hazmat> imbrandon, its implemented
[20:48] <hazmat> you still have to prefix with local:charm_name
[20:49] <imbrandon> no i mean the environments.yaml
[20:49] <imbrandon> part
[20:49] <imbrandon> https://juju.ubuntu.com/docs/drafts/charm-namespaces.html
[20:49] <hazmat> no that's very old
[20:49] <imbrandon> right, i was gonna brush it up a little
[20:50] <imbrandon> but yea i like that idea but i think its axed
[20:50] <imbrandon> the env.y part
[20:50] <hazmat> i wrote that like the first week of juju dev..
[20:50] <hazmat> we can probably just yank the doc
[20:51] <imbrandon> actualy m_3 did alot of moving drafts out and cleaning up yesterday, let me check if he did this too
[20:51] <imbrandon> kk
[20:51] <hazmat> i guess it has some useful info..
[20:51] <hazmat> i think he killed dups and moved stuff that was done out
[20:51] <imbrandon> ill see if he did, if not i will see about adding the few bits that are relevant to other docs and yank that one
[20:52] <imbrandon> all as a MP obviously since i'm not intimately familar etc etc
[21:02] <_mup_> Bug #1016740 was filed: local provider bootstrap should create an actual working environment if none exists <juju:New> < https://launchpad.net/bugs/1016740 >
[21:06] <m_3> imbrandon: no, I didn't take the time to go through all the drafts... just did the obvious ones at the time
[21:07] <imbrandon> m_3: sweet, kk, i'll snag this one then
[21:08] <m_3> imbrandon: cool
[21:10] <imbrandon> m_3: also re: our quest for bzr-git harmony :) checkout the second paragraph here http://developer.github.com/v3/git/ , just more to add to the $someday list if no one else does it
[21:31] <hazmat> have a good weekend folks
[21:32] <m_3> hazmat: u2 man
[22:12] <imbrandon> l8tr hazmat
[22:13] <imbrandon> m_3 / SpamapS : so many subordiantes , i think of the few in the repo i'm running all but one http://api.websitedevops.com/juju-status.txt
[22:13] <imbrandon> :)
[22:25] <hazmat> imbrandon, nice
[23:14] <SpamapS> imbrandon: haha cool!
[23:14] <SpamapS> imbrandon: so is omg using ELB now?
[23:14] <imbrandon> yea
[23:14] <SpamapS> sweet
[23:14] <imbrandon> has been for like a month or so
[23:15] <imbrandon> ever since it went down the last time cuz joey rebooted the bootstrap node and the one with the eip
[23:15] <imbrandon> i put it on elb , and the charm just added instances that are up to the elb with a special check that wordpress is actually runnning ( manually configured )
[23:16] <imbrandon> so littraly just juju add-unit and then the elb associates with the new omgweb that comes up and add's it to the elb, elb checks every minute to see if its serving wp and if so it adds it to the rotation
[23:16] <SpamapS> imbrandon: well done on getting things working w/ 0.6.4.. I have not seen any activity on the IS ticket yet
[23:17] <imbrandon> yea, i got it all working except the front page
[23:17] <imbrandon> took a little break then was gonna crack at that
[23:17] <imbrandon> the front page only lists the local toc
[23:17] <imbrandon> with the other fix
[23:17] <SpamapS> imbrandon: we should add an optional 'check_url' and 'check_string' to the http interface.
[23:17] <imbrandon> i'm sure there is a way around that tho
[23:18] <imbrandon> SpamapS: yea, i have a couple of sugestions for it, that being one
[23:18] <imbrandon> and the other being that the name of the elb isnt tied to the relation
[23:18] <imbrandon> but is an option
[23:18] <SpamapS> actually I really think its time we ditch 'http' for 'http2' and start doing things with the Host header that make sense.
[23:18] <imbrandon> like i had the elb running before i used your charm, so i had to do some fnaggling
[23:19] <imbrandon> yea, hold on ,i'll see what the check is
[23:19] <imbrandon> i have in the elb
[23:20] <imbrandon> HTTP:80/fpm.www.ping
[23:21] <imbrandon> but yea, i basicly wanted to get it to a place i could hand it to joey and say "go" and it not be a big deal
[23:21] <imbrandon> and its at that place now, has been a few weeks, he does his own code deploys etc etc etc
[23:21] <imbrandon> i havent HAD to touch anything in almost a month
[23:21] <imbrandon> now i
[23:22] <imbrandon> still have done a few things like the shortcode plugin etc, but thats purely fun etc
[23:23] <imbrandon> and nothing to do with juju or preformance etc ( the shortcode plugin where he can do [download4ubuntu url="http://apps.ubuntun.com/some/app"] and it puts my pretty css button in place :)
[23:25] <imbrandon> but yea, he now handles all the code deploys and juju updates and such, i just kinda keep an eye on things from a-far, and awser any questions he has but its not many, he picked it up quickly and solid grasp of it, may not be a coder but definately isnt a hands off as he's put up to be sometimes
[23:26] <imbrandon> he is also using a small aws_rds tooo, if you notice there was no mysql charm
[23:27] <imbrandon> but its not charmed, it is just set as a config option for now , omgweb charm has a config option of db_user db_pass db_host db_name , and sets those on config change
[23:27] <imbrandon> but it would be nice to charm that too
[23:28] <imbrandon> but seperate like that not only is it cheaper, but nightly backups are done without extra scripting that could possibly fail and is acutally cheaper ( only by like 1c an hour )
[23:29] <imbrandon> but also allows the whole env to be rebuilt on the fly without thought of the db
[23:31] <imbrandon> great for those "oh shit" moments. now just juju bootstrap a new env or juju deploy omgweb some-other-service-name and then once up and config set to the db, destroy the old service without a second thought
[23:31] <imbrandon> perfect for handing off to less tech ppl
[23:31] <imbrandon> :)
[23:32] <SpamapS> imbrandon: so basically, omg has become a custom thing that is nothing like anything in the charm store.
[23:32] <SpamapS> fail
[23:32] <SpamapS> but its using juju for great stuff
[23:32] <SpamapS> WIN
[23:32] <imbrandon> so its beutifully handled by juju still,  but all he needs to handle is the scaling of webhead units
[23:32] <SpamapS> imbrandon: its also EC2 specific
[23:32] <SpamapS> he can't move to HP
[23:33] <SpamapS> or RAX
[23:33] <SpamapS> bummer
[23:33] <imbrandon> SpamapS: well kinda, nothing from the store directly but parts from it are in alor of other charms
[23:33] <imbrandon> yea he can
[23:33] <imbrandon> infact he was just looking at moving to rack
[23:33] <imbrandon> maybe
[23:33] <SpamapS> imbrandon: this is like the early days when people built servers from Slackware... install slack, cd /usr/local/src .. and start building the box.
[23:33] <imbrandon> now HP dont have everything, but rack does
[23:33] <SpamapS> RAX doesn't have *RDS*
[23:33] <imbrandon> yea
[23:33] <SpamapS> you'd have to manually do that
[23:33] <imbrandon> it does
[23:33] <SpamapS> and ELB
[23:33] <imbrandon> nah
[23:34] <imbrandon> it has rds
[23:34] <SpamapS> which you'd have to do manually
[23:34] <imbrandon> and elb i;m not certain but it has a lb of come kind
[23:34] <SpamapS> because there's no charm is what I'm saying
[23:34] <SpamapS> a big part of juju's promise is cloud agnosticism
[23:34] <SpamapS> Now, OMG doesn't really *need* that
[23:34] <imbrandon> well the rds bit is manual right now anyhow, i want to charm it but its not yet, but yea they would need charmed
[23:34] <imbrandon> but the aws ones needed charmed too
[23:35] <SpamapS> but its sad to see how fast it blew off the rails into EC2 lock in
[23:35] <imbrandon> to begin with :)
[23:35] <imbrandon> well thats what i'm saying its not as locked in as it looks
[23:35] <imbrandon> because i'm not using any of the special features and its all charmed cept db backup
[23:36] <imbrandon> so it can be abstracted out into a rackspace_elb solution or a rackspace_rds one
[23:36] <imbrandon> now hp it would need to use a mysql one, but it still has those interfaces ( optional now ) so it could without change
[23:36] <imbrandon> if needed
[23:37] <SpamapS> Well I'd hope you'd charm RDS before attempting that, so you can charm RAX's db as a service, so you could then actually do the migration just that way
[23:37] <imbrandon> soh for sure
[23:37] <imbrandon> oh*
[23:37] <SpamapS> We need some more sites playing with juju
[23:37] <SpamapS> I'll be interested to see how the next one goes
[23:37] <imbrandon> yea, that was another reason to get it into joeys hands so i could possibly do "the next one"
[23:38] <imbrandon> etc :)
[23:38] <imbrandon> but yea, it LOOKS like its tied to aws but really its not, or only very very very slightly untill rds is charmed
[23:39] <imbrandon> even then not really cuz there is still sql dumps to the bootstrap node and it has the mysql relations in place
[23:39] <imbrandon> but yea
[23:39] <imbrandon> tried to make its as hands off as possible but still use juju for everything that it possibly can
[23:39] <imbrandon> to make it easy on him, me or anyone else
[23:40] <imbrandon> and it may not use stuff from the store, but its a guiney pig and large chunks of what we learn/learned with it are going to many charms, like the elb sugestions
[23:40] <imbrandon> from a bit ago
[23:40] <imbrandon> etc
[23:42] <imbrandon> that and when shit breaks the only "custom" code really is the webheads we designed, the rest can be pointed to aws ( or other cloud provider ) for outages
[23:42] <imbrandon> if needed, but honestly, its been more stable the last month since that last big breakdown that made me take these measures
[23:42] <imbrandon> than ever
[23:43] <imbrandon> ( and still 98% juju hehehe )
[23:44] <imbrandon> and the webheads still rev proxy with a microcache just the same , all to each other etc, they just have an elb infront of them now as well
[23:44] <imbrandon> preventing one webhead die'ing and taking the whole site
[23:45] <imbrandon> ( or getting rebooted )
[23:45] <SpamapS> imbrandon: Its making me question my vision of juju users actually contributing back the stuff that makes their websites go though.
[23:46] <imbrandon> and thinks like the uptime.u.co.uk and newrelic etc etc all are great cya now instead of hearsay :)
[23:46] <SpamapS> imbrandon: I had thought it would be simpler than this. :-/
[23:46] <imbrandon> SpamapS: heh, thats what i've been trying to say from the start
[23:46] <imbrandon> SpamapS: there will be contributors but "custom" will be very common too,
[23:46] <imbrandon> esp when legacy sites are migrated
[23:47] <imbrandon> and not some new service
[23:47] <imbrandon> but yea, really there is very very little, if any that isnt contributed back
[23:47] <SpamapS> but for our first known live site to be custom, is sad.
[23:48] <imbrandon> just not in the clean fashion of a single commit etc
[23:48] <SpamapS> imbrandon: you're not using mysql, you're not using haproxy, or even an nginx lb charm, and wordpress seems to have stymied you *and* marco to get it into production shape.
[23:48] <imbrandon> SpamapS: nah, dont think of it like that, think of it like its still 100% juju even after the dust settles and not because it needs to be adn #2
[23:49] <imbrandon> that it IS the first, their are bound to be hiccups
[23:49] <imbrandon> :)
[23:49] <SpamapS> imbrandon: I knew that production would bring radical change to the charm store. I just haven't seen *any* of that change in lp:charms yet
[23:49] <imbrandon> its using nginx lb
[23:49] <SpamapS> not from the charm store
[23:49] <SpamapS> and what its using has not been submitted
[23:49] <imbrandon> well only becuase i haveent cleaned it up enough to push
[23:50] <SpamapS> thats what I'm lamenting
[23:50] <imbrandon> i've been lazy in that respance
[23:50] <SpamapS> that it takes that much effort from you to clean it up
[23:50] <imbrandon> respect, but thats me
[23:50] <SpamapS> lazy is what I want
[23:50] <imbrandon> no not really, like i said its more of me lazy on that front
[23:50] <SpamapS> I want you to be *so* lazy that you never want to repeat this again
[23:50] <imbrandon> of just not doing it and doing other things
[23:51] <SpamapS> perhaps on the second site, you guys will get off your butts and submit things
[23:51] <imbrandon> SpamapS: sure, i totaly understand and agreee 10000% , but i mean a diff kind of lazy
[23:51] <imbrandon> nah
[23:51] <imbrandon> i need to do it now
[23:51] <SpamapS> and actually you *are* using your newrelic stuff, right?
[23:51] <SpamapS> so, WIN there.
[23:51] <imbrandon> infact i'm going to finish up this doc stuff to get it working and not work on other projects untill i have it at leaste up for revirew
[23:51] <imbrandon> haha yea
[23:51] <imbrandon> newrelic , elb ( from you )
[23:52] <imbrandon> cs:~clint-fewbar/precise/elb
[23:52] <SpamapS> haha cs?
[23:52] <SpamapS> brave man
[23:52] <imbrandon> heh, when i deployed it dns wasent pointing to the elb yet :)
[23:53] <imbrandon> heh
[23:53] <SpamapS> yeah but you can't fix that charm
[23:53] <SpamapS> you can't do anything with it actually
[23:53] <SpamapS> because subordinates can't be removed
[23:53] <SpamapS> so if you find a bug, or want to change it.. oops.. you're stuck, nothing you can do
[23:56] <imbrandon> yea , i dident think of that till you brought it up the other dat
[23:56] <imbrandon> day*
[23:57] <imbrandon> but i could have swore i have "juju deploy mysql" then "juju upgrade-charm --repository /var/lib/charms mysql" and it grabs the upgrade from local
[23:57] <imbrandon> wasent mysql, but still, a "charm"
[23:57] <imbrandon> as long as the revision was higher, but maybe not, probably mistaken
[23:59] <SpamapS> imbrandon: that won't work no, because the charm is cs: not local: