[00:06] <SpamapS> FYI, there's a new charm-tools in the PPA now
[00:07] <SpamapS> includes 'unpromulgate'
[00:20] <SpamapS> imbrandon: did you get your newrelic-php charm to deploy?
[00:20] <SpamapS> imbrandon: the metadata is a bit confusing
[00:20] <SpamapS> imbrandon: no interface: juju-info ..
[00:20] <imbrandon> SpamapS: i was about to try in in just a few minutes
[00:20] <imbrandon> no i did it blind so far
[00:20] <imbrandon> untill a few ago no to deploy it
[00:20] <SpamapS> imbrandon: I think you need interface: juju-info
[00:20] <imbrandon> i thought i put it
[00:21]  * imbrandon looks
[00:21] <imbrandon> SpamapS: i can give you a valid key
[00:21] <imbrandon> if you wanna try it too
[00:21] <imbrandon> the one i use for brandonholtsclaw.com so the numbers dont matter if a little skewed
[00:21] <imbrandon> etc
[00:22] <SpamapS> well I'd think juju would just refuse
[00:23] <lifeless> newrelic have a free account for low traffic sites IIRC, so you can get a key easy.
[00:23] <SpamapS> yeah that should go in the README of the charm :)
[00:23] <imbrandon> lifeless: yea for the system monitor only
[00:23] <imbrandon> lifeless: not the lang ones like php
[00:24] <imbrandon> this is a php one
[00:24] <lifeless> imbrandon: wait, what ?
[00:24] <lifeless> that sucks
[00:24] <SpamapS> imbrandon: copyright: This charm is not endorsed or affiliated with the Locker project and the Locker source is the respective work of its author.
[00:24] <imbrandon> yea the free only does like cpu memory and disk and like that
[00:24] <lifeless> $pointless
[00:24] <imbrandon> SpamapS: whoop
[00:24] <imbrandon> SpamapS: sounds like an old push
[00:24] <imbrandon> SpamapS: let me make sure bzr is uptodate
[00:25] <SpamapS> bzrhater
[00:25] <imbrandon> subordinate: true
[00:25] <imbrandon> requires:
[00:25] <imbrandon>   juju-info:
[00:25] <imbrandon>     scope: container
[00:25] <imbrandon> provides:
[00:25] <imbrandon>   logging:
[00:25] <imbrandon>    interface: newrelic-php
[00:25] <imbrandon> is that not right ?
[00:25] <SpamapS> nope
[00:25] <SpamapS> at the same level as scope: container, you need 'interface: juju-info'
[00:25] <SpamapS> at least, thats how I read the docs
[00:25] <imbrandon> ok and leave the other too
[00:26] <imbrandon> so two juju-infos
[00:26] <imbrandon> ?
[00:26] <SpamapS> same level as scope
[00:26] <SpamapS> requires:
[00:26] <SpamapS>   juju-info:
[00:26] <imbrandon> right but do i leave the other
[00:26] <SpamapS>     interface: juju-info
[00:26] <imbrandon> ok
[00:26] <SpamapS>     scope: container
[00:26] <imbrandon> kk yea thats what i was asking if i left both
[00:26]  * imbrandon fixes
[00:27] <SpamapS> no files dir either
[00:27] <imbrandon> lifeless: yea "system" monitoring is free for unlimited servers, "application" monitoring is now
[00:27] <imbrandon> not*
[00:28] <imbrandon> yea bzr was out dates
[00:28] <imbrandon> bholtsclaw@ares:~/Projects/local/charms/precise/newrelic$ bzr add .
[00:28] <imbrandon> adding files
[00:28] <imbrandon> adding files/548C16BF.gpg
[00:28] <imbrandon> doh
[00:28]  * SpamapS suspends review
[00:28] <lifeless> imbrandon: I think you are wrong
[00:28] <imbrandon> 3 seconds and i'll have it pushed
[00:28] <lifeless> http://newrelic.com/pricing/details
[00:28] <lifeless> lite
[00:28] <lifeless> free
[00:29] <imbrandon> right but thats for the newrelic-sysmon
[00:29] <lifeless> includes basic db and app monitoring
[00:29] <lifeless> anyhow
[00:29] <imbrandon> ahh yea
[00:29] <imbrandon> when theysay basic they mean BASIC
[00:29] <lifeless> oops gathers more data :)
[00:29] <imbrandon> as in is it running
[00:30] <lifeless> and is always free
[00:30] <imbrandon> but yea
[00:30]  * imbrandon will add a bit about that in the readme
[00:30] <SpamapS> imbrandon: you need a start/stop hook
[00:30] <SpamapS> contrary to popular belief, having an init.d installed in runlevel 2 is not enough
[00:31] <imbrandon> SpamapS: k
[00:31] <SpamapS> eventually juju will use stop/start to support migrating services, and possibly snapshotting.
[00:32] <imbrandon> SpamapS: also if you do grab a lite key while i push this, and the "deploy" it to test the charm, they count that as a depooy and will send ya a data-nerd t-shirt :_
[00:32] <SpamapS> I am starting to think more and more that we should take the debhelper 7 approach and try to get this all down to one hook file that just calls out to various helpers
[00:32] <imbrandon> heh
[00:32] <SpamapS> 99% of charms are doing the same things
[00:33] <SpamapS> No revisions or tags to pull.
[00:34] <imbrandon> push
[00:34] <imbrandon> ed
[00:34] <imbrandon> should be rev 3
[00:34] <imbrandon> on bzr
[00:37] <imbrandon> SpamapS: PM with key if you wanna try without hassle of signing up, just a convience
[00:40] <imbrandon> just added a line in the readme too about getting a ( free ) newrelic account
[00:40] <imbrandon> ty lifeless , i mis-understood
[00:40] <SpamapS> oh nice , I get a data nerd shirt
[00:40] <imbrandon> yup yup, i got two from them , nice shirts actually
[00:41] <imbrandon> and i got a book "The Lean Startup" hard cover they was giviing away a few weeks ago
[00:41] <imbrandon> they are always giving some kinda swag out to twitter followers
[00:42] <SpamapS> Ok I'm going to point it at my thinkup instance
[00:42] <imbrandon> kk
[00:43] <imbrandon> i'm after testing and prom etc i'm gonna deploy it to omg instead of how its done by hand now
[00:43] <imbrandon> omg is using cloudflare now too
[00:43] <imbrandon> :)
[00:44] <SpamapS> 2012-05-01 17:43:44,651 unit:newrelic-php/0: hook.output ERROR: /var/lib/juju/units/newrelic-php-0/units/newrelic-php-0/charm/hooks/install: line 13: syntax error near unexpected token `else'
[00:44] <imbrandon> crap
[00:44]  * imbrandon looks
[00:44] <SpamapS> forgot ; after ]
[00:44] <imbrandon> damn i was gonna say this is like the simplest chamr
[00:44] <imbrandon> lol
[00:45] <imbrandon> pushed
[00:45] <SpamapS> yeah I just haxored it in and I'm rerunning the install hook now
[00:45] <imbrandon> kk
[00:45] <imbrandon> :)
[00:45]  * SpamapS hugs juju resolved --retry
[00:45] <SpamapS> I think we should just alias that to 'juju retry'
[00:46] <SpamapS> I almost always want --retry anyway
[00:46] <SpamapS> 2012-05-01 17:46:09,907 unit:newrelic-php/0: hook.output ERROR: /var/lib/juju/units/newrelic-php-0/units/newrelic-php-0/charm/hooks/install: line 10: md5: command not found
[00:46] <SpamapS> ha-ha
[00:46] <SpamapS> md5sum
[00:46] <SpamapS> imbrandon: man u suck at this! ;-)
[00:46]  * SpamapS hides
[00:46] <imbrandon> i am so gonna make the error and info functions in juju to be "ohai = info " "ohnoe = warn" "ohpoo = error"
[00:46] <imbrandon> wow
[00:46] <lifeless> imbrandon: misunderstood what ?
[00:47] <imbrandon> lifeless: the free leel
[00:47] <imbrandon> level
[00:47] <imbrandon> SpamapS: no md5sum on base install ?
[00:47] <imbrandon> frak
[00:47] <SpamapS> no *md5*
[00:47] <SpamapS> md5sum is there
[00:47] <SpamapS> well, it might be
[00:47] <SpamapS> not entirely sure actually
[00:47] <imbrandon> ph, frakin osx thin
[00:48] <imbrandon> there is here
[00:48] <imbrandon> not sure on linux
[00:48] <lifeless> imbrandon: ah, so it does do more than you thought ?
[00:48] <imbrandon> bholtsclaw@ares:~/Projects/local/charms/precise/newrelic$ md5 -q files/548C16BF.gpg
[00:48] <imbrandon> be9704aa1e7001d855a60c4c05d7598b
[00:48] <imbrandon> bholtsclaw@ares:~/Projects/local/charms/precise/newrelic$
[00:48] <SpamapS> md5sum is in coreutils
[00:48] <imbrandon> lifeless: yup, not a lot , i'd still pay,. but yea
[00:49] <SpamapS> imbrandon: realistically, that check doesn't add any security. If a bad actor could change that, it could change install
[00:49] <imbrandon> true
[00:49]  * imbrandon just drops it
[00:49] <SpamapS> 2012-05-01 17:49:21,939 unit:newrelic-php/0: hook.output ERROR: /var/lib/juju/units/newrelic-php-0/units/newrelic-php-0/charm/hooks/config-changed: line 12: /ect/newrelic.cfg: No such file or directory
[00:49] <imbrandon> jesus i am bad
[00:49] <SpamapS> imbrandon: I am your debugger
[00:50] <SpamapS> imbrandon: perhaps consider variables rather than repetitive hard coding as a strategy to mitigate mt. dew induced type-o impact
[00:50] <SpamapS> imbrandon: or maybe Mavis Beacon? :)
[00:51]  * SpamapS will stop going all alpha-dog on imbrandon now :)
[00:51] <imbrandon> all pushed
[00:51] <imbrandon> heheh
[00:51] <imbrandon> np
[00:51] <imbrandon> i deserve it most of the time :)
[00:51] <imbrandon> including now
[00:51] <SpamapS> 2012-05-01 17:51:24,404 unit:newrelic-php/0: hook.output INFO: Starting New Relic Proxy Daemon: newrelic-daemon
[00:51] <SpamapS> 2012-05-01 17:51:25,412 unit:newrelic-php/0: hook.output INFO:  FAILED
[00:51] <imbrandon> no lic key
[00:51] <imbrandon> likely
[00:52] <SpamapS> I did set one, I think
[00:52] <SpamapS> perhaps not in the confusion
[00:52] <bkerensa> SpamapS: Would you like to share some examples of your ninja variables work in a charm? :D
[00:52] <bkerensa> examples accepted
[00:53] <SpamapS> A=speling
[00:53] <imbrandon> lol
[00:53] <SpamapS> echo "I suck at $A even when I'm competing in a $A bee"
[00:54] <SpamapS> Starting New Relic Proxy Daemon: newrelic-daemon OK
[00:54] <imbrandon> shaweet
[00:55] <SpamapS> imbrandon: one weakness..
[00:55] <SpamapS> imbrandon: it doesn't restart apache
[00:55] <imbrandon> yea i thought about that
[00:55] <SpamapS> imbrandon: seems like you could just restart any that are running.
[00:55] <imbrandon> i would need tro know any way php could be installed and start apache nginx php-fom
[00:55] <imbrandon> etc
[00:56] <SpamapS> imbrandon: thats what the scope: container relationships are for
[00:56] <imbrandon> ?
[00:56] <imbrandon> it stil dont help me to know the type i need to restart
[00:56] <SpamapS> imbrandon: you can have one interface: php-app-server ... and then the charms that implement it can feed back things like what service to restart
[00:56] <imbrandon> oh yea
[00:56] <imbrandon> that way
[00:57] <imbrandon> yea that was the "comming soon" thing we mentioned
[00:57] <imbrandon> btw you should be able to refresh the page once or twice and it start feeding data
[00:58] <imbrandon> its almost realtime
[01:00] <SpamapS> I don't see any data yet
[01:00] <SpamapS> but, it appears to be working basically
[01:01] <imbrandon> make sure your on the apps tab
[01:01] <imbrandon> and not the system one
[01:01] <imbrandon> at the top left
[01:01] <SpamapS> imbrandon: thats pretty impressive
[01:01] <imbrandon> :) the sysmon one will fill in the system tab
[01:01] <imbrandon> etc
[01:02] <imbrandon> then ruby and python
[01:02] <imbrandon> et al
[01:02] <SpamapS> imbrandon: I wonder if we shouldn't just make a "newrelic" subordinate and have each different app type installable via relation or config
[01:02] <imbrandon> well i thought about that for the apps but figured it would be configin
[01:03] <imbrandon> confusing*
[01:03] <SpamapS> the reason I like doing it that way is that you can have one place for your key.. one place to upgrade
[01:03] <SpamapS> oh also, I'd recommend calling the config option just 'key'
[01:03] <imbrandon> stil all uses /etc/newrelic.cfg
[01:03] <imbrandon> or whatever
[01:03] <imbrandon> kk
[01:04] <SpamapS> no reason to prefix it when it is already namespaced into the charm
[01:04] <imbrandon> k
[01:04] <imbrandon> so in theory
[01:04] <imbrandon> then as long as i do them all the same
[01:04] <imbrandon> if you installed the python one now
[01:04] <imbrandon> you would not need to mess with the key
[01:04] <imbrandon> since i put it in the if/else
[01:05] <imbrandon> on config-change only
[01:05] <SpamapS> right
[01:05] <imbrandon> so kinda the same just not said expliositly
[01:05] <imbrandon> bah
[01:05] <SpamapS> Interesting, it seems like it held off feeding back the massive spike that my siege created until I let the load drop
[01:05] <imbrandon> its a little behind
[01:06] <imbrandon> not 1000% realtime
[01:06] <imbrandon> but almost
[01:06] <SpamapS> damn tho
[01:06] <SpamapS> drilling down now
[01:06] <SpamapS> We'd have been able to fire 3 people at my last place w/ this
[01:06] <imbrandon> :)
[01:06] <SpamapS> not because they wouldn't have work to do
[01:06] <imbrandon> yea dude it rocks, and thats just the default settings
[01:06] <SpamapS> but we'd finally be able to prove that their code was causing all the suck
[01:07] <imbrandon> if you get into the api you can set some treally cooll stuff
[01:07] <imbrandon> https://newrelic.com/docs/php/the-php-api
[01:08] <SpamapS> wow
[01:08] <SpamapS> what a PoS thinkup is
[01:08] <imbrandon> https://newrelic.com/docs/php/php-agent-phpini-settings#inivar-tt-top100
[01:08] <SpamapS> every hit to index.php does show tables like '?'
[01:09] <imbrandon> heh nice
[01:09] <SpamapS> this app wouldn't even work on mysql 5.0 .. it takes a table lock (briefly) to do that
[01:09] <imbrandon> good thing for mysql query cache
[01:09] <imbrandon> lol
[01:09] <SpamapS> bunch of lazy load insanity here
[01:10] <imbrandon> newrelic.framework = ""
[01:10] <imbrandon> Scope: PERDIR
[01:10] <imbrandon> Type: String
[01:10] <imbrandon> New Relic tries hard to automatically detect the frameworks it supports, but it can get it wrong if you are using experimental new versions or you have customized the framework. This setting can be used to manually set the framework if the auto-detection fails. This must be one of "cakephp", "codeigniter", "drupal", "joomla", "kohana", "magento", "mediawiki", "symfony", "wordpress", "yii", "zend" or "no_framework" to force no framework even if one was detec
[01:10] <imbrandon> ^^ very nice
[01:10] <SpamapS> imbrandon: the mysql QCache is also a problem.. though they've finally got it working ok by splitting it up into multiple mutexes
[01:11] <imbrandon> SpamapS: yea an ppl often make it huge thinking it will help
[01:11] <imbrandon> and iit  burries them
[01:13] <SpamapS> yeah, I went through the thrashing up and down for a while at my last place before I realized turning it *OFF* actually made things better :)
[01:13] <imbrandon> and yea in like a day or so you'll get an email from $sales saying "we sent ya a tshirt, enjoy" but then takes like 2 weeks to show :)
[01:13] <imbrandon> just fyi
[01:13] <SpamapS> I didn't give them an address yet
[01:13] <SpamapS> but thats cool
[01:13] <imbrandon> ahh ok
[01:13] <SpamapS> I'll gladly wear it, this is cool stuff
[01:13] <imbrandon> :)
[01:14] <SpamapS> SET time_zone = '?'
[01:14] <imbrandon> HAHAHA
[01:14] <SpamapS> theres one that just runs into concurrency problems
[01:14] <SpamapS> 1,483 ms
[01:14] <imbrandon> wow
[01:15] <SpamapS> imbrandon: here's one thought. What about just restarting apache2 and php5-fpm .. those two would cover 99.9% of the cases where a daemon is serving PHP
[01:15] <imbrandon> good call
[01:15] <imbrandon> untill something better
[01:15] <imbrandon> is done
[01:15]  * imbrandon adds it
[01:16] <imbrandon> is the service apache or aoache2 ( /me dont have it installed )
[01:16] <SpamapS> apache2
[01:16] <imbrandon> k
[01:16] <SpamapS> and use the service command
[01:16] <SpamapS> that way it works even if we move it to upstart
[01:16] <imbrandon> yea i do
[01:16] <SpamapS> actually, /etc/init.d/apache2 works that way too.. so.. :-P
[01:16] <imbrandon> cuz php5-fpm will restart its self that way
[01:16] <SpamapS> but, service > /etc/init.d/oldcrap
[01:17] <imbrandon> yea i like upstart works liek god
[01:17] <imbrandon> god == the bomb tho
[01:18] <SpamapS> imbrandon: ok, so thats my review. Change the name of the config option to 'key' and restart the services. Everything else can stay as a TODO for the future. Well done. :)
[01:19] <imbrandon> ty ty and i'm pushing herer in a 30 seconds
[01:19] <SpamapS> also what do you think about calling it newrelic
[01:20] <imbrandon> nah, its the php one , there is another that will be just newrelic
[01:20] <SpamapS> Ok
[01:20] <imbrandon> this installs the newrelic.so
[01:20] <imbrandon> sysmon will be just newrelic
[01:20] <SpamapS> We need to grow 'replaces' and 'provides' like capabilities for charms so when we consolidate those or rename something users can get it on an upgrade-charm
[01:20] <imbrandon> as i needs absolutely nothing else
[01:20] <SpamapS> heh, 'juju dist-upgrade'
[01:20] <imbrandon> lol
[01:20]  * SpamapS is not sure he likes the implications there
[01:21] <SpamapS> Ok time to go
[01:21] <SpamapS> imbrandon: will promulgate later tonight
[01:21] <imbrandon> brew upgrade all
[01:21] <SpamapS> family is home
[01:21] <imbrandon> SpamapS: ty ty
[01:21] <imbrandon> kk
[01:25] <imbrandon> SpamapS: ok pushed, for when you do get back round
[01:25]  * imbrandon grabs some late dinner
[01:29] <nathwill> is there a no-cache option to forcibly reload a charm from the repository?
[01:29] <nathwill> when doing a deployment ^
[01:30] <imbrandon> hrm not sure, i think it just looks at the revision
[01:31] <nathwill> ok. too bad, that would be handy
[02:06] <imbrandon> SpamapS: how far behind is the go client, as in is it useable _at all_ now and not upto feature parady or ...
[02:47] <imbrandon> SpamapS: zomg sexy .... love; why cant this be unity .... me want .... https://plus.google.com/u/0/100530892038948253747/posts
[03:40] <SpamapS> imbrandon: as I understand it, a week or two ago the go client was able to spin up ec2 instances
[03:40] <SpamapS> imbrandon: and some details about how the bootstrap will differ from the python client are being worked out
[03:40] <SpamapS> imbrandon: so, its still quite far behind, but the foundations are laid
[03:40] <SpamapS> imbrandon: FYI, there is a --upgrade option to deploy that satisfies what nathwill was asking earlier
[03:43] <imbrandon> ahh
[03:44] <imbrandon> SpamapS: kk, i was thinkning about compiling the go here local and trying to kick the tires a bit , nothing serious really just see what works and dont
[03:51] <SpamapS> I tried that about 2 months ago and there was nothing, but I'm told there is at least something to play with now
[03:51] <SpamapS> imbrandon: you can also start up your own charm store ;)
[03:59] <imbrandon> oh ?>\
[03:59] <imbrandon> with go or ?
[03:59] <imbrandon> just in general ?
[04:17] <SpamapS> imbrandon: the charm store backend is written in go
[04:17] <SpamapS> and is in lp:juju/go/store
[04:28] <SpamapS> imbrandon: still have that bit about Locker in the copyright
[04:28] <SpamapS> oh wait no
[04:28] <SpamapS> it says newrelic now, never mind :)
[04:29] <imbrandon> :)
[04:29] <SpamapS> imbrandon: so, the provides ..
[04:29] <SpamapS> that needs to go
[04:29] <SpamapS> unless you're going to add a hook, or explain who will require: that
[04:29] <imbrandon> ... um i wantthat later
[04:29] <SpamapS> is it going to be purely for private-address/public-address ?
[04:30] <imbrandon> probably
[04:30] <imbrandon> and unit names
[04:31] <SpamapS> imbrandon: so you don't actually have to do anything on the newrelic side of things?
[04:31] <imbrandon> and the ability to have other svc change its configs
[04:31] <imbrandon> huh ?
[04:32] <SpamapS> imbrandon: I'm asking if its possible w/o hooks
[04:32] <imbrandon> if what is
[04:32] <imbrandon> your not clear at all
[04:32] <SpamapS> imbrandon: that relation
[04:32] <imbrandon> i'm still very lost
[04:32] <SpamapS> You have a relation
[04:32] <SpamapS> with no hooks
[04:32] <imbrandon> yes
[04:32] <SpamapS> I'm questioning the value of such a thing
[04:33] <imbrandon> its for later so names and other config bits can easily be set
[04:33] <imbrandon> from peers
[04:33] <SpamapS> There is an *implied* juju-info relation in all charms. https://juju.ubuntu.com/docs/implicit-relations.html
[04:33] <SpamapS> imbrandon: until you have actual hooks, just use that.
[04:33] <imbrandon> right but it wont always be juju-info that was a hack till i get php-app in all others
[04:34] <imbrandon> no then i got to go back and change it yet again
[04:34] <imbrandon> why
[04:34] <SpamapS> step back, this is the provides, not the requires
[04:34] <imbrandon> yes , it proviodes a php logging interfae
[04:34] <imbrandon> it does
[04:35] <SpamapS> so, the only way an interface: can be defined is by an implementation (currently). I'm hesitant to have an interface w/o an implementation.
[04:35] <SpamapS> Oh, does it like, listen on a port or something?
[04:35] <imbrandon> what does it hurt, and it helps by making things very clear
[04:35] <imbrandon> yes
[04:35] <imbrandon> the daemon does
[04:35] <SpamapS> this is uncharted territory
[04:36] <SpamapS> so tell me to F off all you want. :)
[04:36] <imbrandon> right
[04:36] <SpamapS> I'll take it well
[04:36] <imbrandon> heheh well i'm looking at it more like i'll probably use it so good to have it from the get go and it dont hurt
[04:36] <SpamapS> So at this point, interface: newrelic-php , listens on a given port on the private-address.
[04:36] <imbrandon> instead of doing like juju-info and then changing later
[04:37] <imbrandon> right, well right now its 127.0.0.1/unix/sockt
[04:37] <SpamapS> *doh*
[04:37] <imbrandon> but i will have it just use one daemon and a tcp port
[04:37] <imbrandon> when ther is more than one
[04:37] <imbrandon> i'm still missing what why its bad to have
[04:38] <imbrandon> and i see it as good even witout a implmntation as it makes it very clear
[04:38] <imbrandon> even in the status
[04:38] <SpamapS> It still sounds like its a broken interface at this point.
[04:38] <SpamapS> no documentation for it..
[04:38] <SpamapS> no partner implementation
[04:38] <SpamapS> Not saying "NO"
[04:38] <SpamapS> just asking for a good reason to keep it
[04:39] <imbrandon> and i'm asking for a good reason to ditch it
[04:39] <SpamapS> when it sounds like you'll have to change things in the charm to make it actually work anyway
[04:39] <SpamapS> cause its broken
[04:39] <imbrandon> no it works fine
[04:39] <imbrandon> in telling me that via the meta info its a logging php infterface
[04:39] <SpamapS> there's nothing that can relate to it
[04:40] <imbrandon> that cant be the *only* reason for the meta info otherise why have it
[04:40] <imbrandon> and just go on whatever interfaces ahve implentations
[04:40] <SpamapS> It is *definitely* the only reason
[04:40] <imbrandon> then just enumerate the implmented interfaces
[04:40] <imbrandon> and ditch all the meta info
[04:40] <SpamapS> Otherwise somebody goes off and writes themselves a thing that wants to log to newrelic-php
[04:40] <SpamapS> and then they get really annoyed that it won't work
[04:40] <SpamapS> and they have no example to follow from the author
[04:41] <imbrandon> if if exposes no info for them to do so
[04:41] <imbrandon> then they wont
[04:41] <imbrandon> and i linked the docs in the readme
[04:41] <SpamapS> So, it doesn't say 'will-provide' logging, it says 'provides' logging. And yet, it listens on no ports.
[04:41] <imbrandon> logging dosent have to mean it provieds to all
[04:41] <imbrandon> or on a port
[04:42] <imbrandon> it does to the app
[04:42] <imbrandon> and only the app
[04:42] <imbrandon> but it still does
[04:42] <imbrandon> and its still an interface
[04:42] <SpamapS> thats scope: container then
[04:42] <imbrandon> its in container
[04:42] <SpamapS> Yeah, so thats not relatable over the network
[04:42] <SpamapS> so add scope: container
[04:42] <imbrandon> omg
[04:42] <imbrandon> yes it is and no
[04:42] <imbrandon> it is not setup that way
[04:43] <imbrandon> there is not a config opetion
[04:43] <imbrandon> so it is not there
[04:43] <imbrandon> for public use
[04:43] <imbrandon> but it IS there
[04:43] <SpamapS> Well since you can't show me how its setup, because you haven't implemented it, I stand by my -1, if for no other reaosn than primal fear of the unknown. :)
[04:43] <imbrandon> look in the only config
[04:44] <SpamapS> thats not -1 as in, NACK for cs:
[04:44] <SpamapS> just, -1
[04:44] <SpamapS> you're good to go for cs:
[04:44] <imbrandon> ... >.<
[04:44] <SpamapS> though I'm going to open a bug in the charm as a reminder to fix it or drop it. :)
[04:44] <imbrandon> ok then i'm truely missing something
[04:45] <imbrandon> and i'll mark as wontfix unless you can tell me what the hell you mean
[04:45] <SpamapS> relations define *network* service relationships. There is no logging network interface exposed by the installed/configured software.
[04:45] <SpamapS> so it is effectively broken
[04:45] <imbrandon> that is not explisit
[04:45] <imbrandon> and if its 100% then we need a local relations speeled out too
[04:45] <imbrandon> more than container
[04:46] <SpamapS> container == local
[04:46] <imbrandon> right this is both
[04:46] <imbrandon> now what ?
[04:46] <SpamapS> that would be two relations
[04:46] <imbrandon> ...
[04:46] <imbrandon> really?
[04:46] <SpamapS> one for relating via the socket
[04:46] <imbrandon> thats broken
[04:46] <SpamapS> one for relating over the network
[04:46] <imbrandon> no only one is active
[04:46] <imbrandon> at a time
[04:46] <imbrandon> or can be
[04:46] <SpamapS> Thats fundamental to the way subordinates work.
[04:47] <SpamapS> Think it through
[04:47] <imbrandon> no or the thing would not work now
[04:47] <imbrandon> if that was the case
[04:47] <imbrandon> it DOES work like the way i did it
[04:47] <imbrandon> and does imply the way it is
[04:47] <imbrandon> but if i put two
[04:47] <imbrandon> one will always be wrong
[04:47] <SpamapS> if its "both", how do you direct juju to install the charm subordinate to any given service *and* let other things log to that particular daemon? you can't because the scope defines where the charm ends up running.
[04:48] <imbrandon> because it installs both a php nrerelic.so that talks to a running daemon
[04:48] <imbrandon> that so can be on any machine
[04:48] <imbrandon> one one daemon is needed
[04:48] <imbrandon> but aman can be runniung
[04:48] <imbrandon> right now its made where many are
[04:48] <imbrandon> weach has their own
[04:49] <imbrandon> thats how its both
[04:49] <SpamapS> that all makes sense
[04:50] <SpamapS> but for juju, you can't have one relation that is both container scope, and not container scope
[04:50] <imbrandon> i do right now :)
[04:50] <imbrandon> or you mean i'm not intended to ?
[04:51] <SpamapS> Could be the latter.
[04:51] <imbrandon> hehe
[04:51] <imbrandon> i do think thats wrong though, for other thingas like the LB
[04:51] <imbrandon> that might have a webserver local and remote
[04:51] <imbrandon> etc
[04:51] <imbrandon> and more not on the top of my head
[04:51] <imbrandon> container/not container should be a hint not restriction
[04:52] <SpamapS> It should work, to relate the local one to the same service it is deployed on. Thats fine, I'd encourage that sort of thing. But you can't use the unix socket without doing backflips to figure out if you are local or not.
[04:52] <imbrandon> brb more soda
[04:52] <SpamapS> 8 min, I have to go :p
[04:52] <imbrandon> okies
[04:53] <imbrandon> ok so for real
[04:53] <imbrandon> add container ? imho thats just crust
[04:53] <imbrandon> but i will and then bitch later
[04:53] <imbrandon> very not in line with DRY
[04:54] <SpamapS> no actually I think you should just remove it still, until you can actually make it work across the network. :)
[04:54] <imbrandon> well even if i dont i still want it there so its explisit in the metadata
[04:54] <imbrandon> i dont think that metadat should only be for implmented services or then why have it
[04:55] <imbrandon> s/servicecs/interfaces
[04:55] <SpamapS> its explicitly lying about its capabilities. Stubs are generally kept private while they're being worked on.
[04:55] <imbrandon> thats it its not a stuf
[04:55] <imbrandon> stub
[04:55] <imbrandon> bah
[04:56] <SpamapS> Yeah I get it, you can force it to work by only relating it to services it is already deployed on top of
[04:57] <SpamapS> But, you can see where I'd think that sounds a whole lot like a scope: container relationship, right?
[04:57] <imbrandon> yea i do see that
[04:57] <imbrandon> but then thats a real limitation
[04:57] <imbrandon> where as if i leave it off  its not
[04:57] <imbrandon> its only a "would be better" kinda thing that is debateable
[04:58] <imbrandon> but i DO see your point
[04:59] <SpamapS> I think eventually, I'd rather see this charm have 2 requires, and 1 provides...
[04:59] <imbrandon> ugh i do gotta run a few and you'll likely be gone when i get back ( just a few minutes ) so catch ya in the morning man, openweek tomarrow with the OMG story :)
[04:59] <imbrandon> hrm that might be ok
[04:59] <SpamapS> the 2 requires are both scope container, one is the generic juju-info .. and the other is for services which implement the php-app interface.
[05:00] <imbrandon> yea
[05:00] <SpamapS> The provides is for network based logging into the daemon
[05:00] <imbrandon> well then the top php need not be container
[05:00] <imbrandon> but other than that yea
[05:01] <SpamapS> it does, because you need a way to pass local aspects
[05:01] <imbrandon> but i need a way to gather network ones too
[05:01] <SpamapS> without haveing to pass the hostname, and compare it to your own, so you know you are local and not remote, and can do things like restart services.
[05:02] <imbrandon> i was thinking about making all the service restarts config options anyhow
[05:02] <imbrandon> and doing it in config-changes
[05:02] <imbrandon> that would solve some othert issues as well
[05:02] <SpamapS> The network ones would be via the provides interface. I assume what you want is to deploy the daemon to only one app server service, but then log to it from many other services.
[05:03] <SpamapS> That would create issues though. The more config options that are needed to make the system work, the more one has to think about how to automate.
[05:03] <imbrandon> defaults
[05:03] <SpamapS> much better if it works well for 99% of use cases w/o configs
[05:03] <imbrandon> sure sane defaults
[05:03] <imbrandon> it would be more like protected class vars
[05:03] <SpamapS> does newrelic have any other interesting local-only data that it needs to know about your app?
[05:04] <imbrandon> is how it would be used
[05:04] <imbrandon> hrm yea
[05:04] <imbrandon> well
[05:04] <SpamapS> I assume most of it can be gleaned from the PHP modules, so just knowing how to configure that is all you need
[05:04] <imbrandon> hrm
[05:04] <imbrandon> alot of it is set in the actualy app booptstrap code
[05:04] <imbrandon> its self
[05:05] <imbrandon> other than that it guesses or you can manualy overidse in the newrelic.ini
[05:05] <imbrandon> really the main thing that NEEDS to be local is the app group anme and the app server uniq name
[05:06] <imbrandon> so like onthe omg webheads all have   "OMG-ALL;OMG-1"   "OMG-ALL;OMG-2"
[05:06] <imbrandon> etc
[05:06] <imbrandon> where N is $JUJU_MACHINE_ID
[05:06] <SpamapS> yeah
[05:06] <SpamapS> juju has a nice logical model for that :)
[05:07] <bkerensa> pah
[05:07] <imbrandon> they all agrogate to one and each ahve their own
[05:08] <imbrandon> in this i set it to JUJU-ALL;$JUJU_MACHINE_NAME
[05:08] <imbrandon> i think
[05:08] <imbrandon> but i wanna make that a config as well
[05:08] <SpamapS> this is wher ethe juju-info relation would come in handy
[05:08] <SpamapS> what you really want is OMG
[05:09] <SpamapS> so add a hook that records $JUJU_REMOTE_UNIT
[05:09] <SpamapS> since 'omg/0' is way more interesting than 'newrelic/0'
[05:09] <imbrandon> hrm, good idea
[05:09] <SpamapS> must be my lucky day :)
[05:09] <imbrandon> hehehe
[05:10] <imbrandon> yea i'll do thhat before i sack out, doing got a lot more left in me
[05:10] <imbrandon> but ok so is it in the store now ?
[05:10] <imbrandon> and ty ty btw
[05:10] <imbrandon> and how do i do updates ? more bugs ?
[05:10] <SpamapS> Yeah I'm pushing it now as-is
[05:10] <imbrandon> sweet ty
[05:11] <imbrandon> yea i'll make a few small changes to ngiht and also try to get the other newrelic ones ( minimum python and ruby )
[05:11] <SpamapS> imbrandon: if you want to own it, I'd be good with that. We can create a team which has you + charmers in it. Or you can get some other ~charmers person to +1 you and start reviewing charms too.. :)
[05:11] <imbrandon> thte latter is what i plan
[05:11] <imbrandon> just everyone been busy with releases
[05:11] <imbrandon> so i kinda held back
[05:12] <SpamapS> well is this your first promulgate? I can't believe that
[05:12] <imbrandon> drupal should ahve been many
[05:12] <imbrandon> weeks ago
[05:12] <imbrandon> but omg hit the fan
[05:12] <imbrandon> :)
[05:13] <imbrandon> and not that subs are out ( yea its been that long ) i wanna change it up some
[05:13] <imbrandon> now*
[05:13] <SpamapS> Yeah, subs are fun
[05:13] <imbrandon> but yea i got nginx and mysql ndb
[05:13] <imbrandon> local
[05:13] <imbrandon> and on github
[05:13] <imbrandon> but not ready
[05:14] <imbrandon> drupal and these newrelic ones and the omg playground
[05:14] <imbrandon> :)
[05:14] <imbrandon> ok gonna run a few, youll ber gone so i'll catchg ya tom man
[05:14] <imbrandon> ty ty
[05:15] <imbrandon> gotta do openweek tom
[05:15] <imbrandon> heheh
[05:15] <imbrandon> makin a slick graphic for it now
[05:15] <imbrandon> turning out much better than i had hoped
[05:16] <SpamapS> cool!
[05:16] <_mup_> Bug #993027 was filed: 'juju get' needs an option to produce the same yaml that 'juju set --config' will consume <juju:New> < https://launchpad.net/bugs/993027 >
[05:21] <imbrandon> SpamapS:
[05:21] <imbrandon> still round ?
[05:21] <imbrandon> http://cl.ly/GIxf
[05:22] <imbrandon> still needs work, but nice graffic to go along with Juju: the OMG!Ubuntu story :)
[05:23] <SpamapS> sparklies
[05:27] <imbrandon> lol
[05:28]  * imbrandon hugs photoshop
[05:32] <_mup_> Bug #993034 was filed: lxc deployed units don't support https APT repositories <juju:New> < https://launchpad.net/bugs/993034 >
[08:10] <mrevell> i
[08:36] <koolhead17> marcoceppi, ping
[10:13] <mgz> is there some way in juju to make it ssh to the instance IP rather than the hostname?
[10:17] <mgz> ...seems not, ProviderMachine takes dns_name and private_dns_name only
[11:10] <m_3_> mgz: for some providers you might get away with adding .ssh/config that includes entries to a.) get to the bootstrap node, and b.) proxy through the bootstrap node for other instances
[11:11] <mgz> m_3_: so, my immediate problem is canonistack doesn't seem to work unless I manually edit my .ssh/config with the details of the bootstrap node
[11:12] <mgz> if that's the current expected state, I guess that's okay.
[11:12] <m_3_> mgz: yeah, afaik that's the current state of affairs with openstack installs
[11:13] <m_3_> mgz: or drive juju from "inside" the openstack cloud itself... provided you can route to the endpoint urls
[14:04] <_mup_> Bug #993288 was filed: Provide an option to specify creation of a new instance upon deployment <juju:New> < https://launchpad.net/bugs/993288 >
[14:12] <SpamapS> bbcmicrocomputer: Confirmed your bug, good idea. :)
[14:45] <bbcmicrocomputer> SpamapS: ah cool :)
[14:53]  * flepied is happy to have a working mongodb charm using his own configuration engine and having the change port test working
[15:01] <SpamapS> bbcmicrocomputer: just finished a review of your solr charm. REALLY nice work. You can ping me in here as soon as you address the issues.
[15:01] <SpamapS> flepied: Is this an evolution of the existing one, or a total rewrite?
[15:01] <bbcmicrocomputer> SpamapS: ok thanks
[15:01] <flepied> SpamapS, it's based on the mongodb one
[15:02] <SpamapS> flepied: cool. :) If you want to propose it as a merge into the existing one we'll review that just like we review new charms.
[15:02]  * SpamapS points in a circle at all the other ~charmers members *YOU* will all review it, right?! RIGHT
[15:04] <flepied> SpamapS, I don't think it can be used by anyone else at this point as it uses my adminkit config engine and adminkit needs to be preloaded on the image before beeing used
[15:05] <m_3_> SpamapS: right
[15:06] <flepied> but if someone is curious, just look at https://code.launchpad.net/~flepied/charms/precise/mongodb/adminkit
[15:27] <m_3_> argh... leaking security groups in autotesting
[15:28] <m_3_> gonna start having to use eucatools and ec2 tools to avoid things like 'cross-fingers; destroy-environment; sleep 120; destroy-environment; pray'
[15:29] <SpamapS> m_3_: something cares if there's already a group?
[15:30] <SpamapS> m_3_: perhaps you need to bump the env name
[15:31] <m_3_> yeah, that would work... but then I'd be leaking them longer-term
[15:31] <m_3_> didn't think about tmp-envs tho... good idea
[15:31] <m_3_> might be just lagging cleanup of sec grps
[15:33] <SpamapS> m_3_: its probably worth adding an option to bootstrap like --nuke-from-orbit to make sure the old env is gone before bootstrapping
[15:34] <jimbaker> m_3_, security group reuse along the lines of what was done in the go port is probably a good idea
[15:34] <m_3_> SpamapS: yeah, I did that with local providers (mostly remove data_dir)
[15:34] <m_3_> jimbaker: yeah, we've been informed that the current way we use groups will need to be limited in ec2
[15:35] <m_3_> jimbaker: simply not enough available to really scale
[15:35] <jimbaker> m_3_, right
[15:35] <SpamapS> OH, does ec2 actually hvae a limit?
[15:36] <m_3_> SpamapS: but I'll have to do something different to nuke envs in ec2/openstack... hence the ec2tools/eucatools... perhaps
[15:36] <m_3_> SpamapS: longer quiet periods between tests don't seem to suffice
[15:36] <SpamapS> m_3_: sounds like a job for jitsu :)
[15:36] <m_3_> SpamapS: yup!
[15:37] <m_3_> SpamapS: all this stuff's going into jitsu
[15:37] <SpamapS> werd
[15:37] <SpamapS> I need to finish getting the stable releases -> ppa automated
[15:41] <lynxman> jcastro: ping
[15:50] <_mup_> Bug #993372 was filed: terminate-machine should accept an option for --all-unused <juju:New> < https://launchpad.net/bugs/993372 >
[17:15] <AlanBell> hi all, I am having a problem with juju bootstrap, I have rebooted, but I still get error: internal error Network is already in use by interface virbr0
[17:15] <AlanBell> I do have virtualbox installed if that is relevant
[17:18] <AlanBell> I just added myself to the libvirtd group and it worked \o/
[17:18] <AlanBell> maybe it should do that automatically?
[17:19] <koolhead17> AlanBell, file a bug if you think something is missing :)
[17:19] <SpamapS> AlanBell: when you install libvirt-bin, all administrators are added to that group
[17:20] <AlanBell> I am an administrator (single user default precise desktop installed yesterday)
[17:20] <SpamapS> AlanBell: though it sounds like juju needs to explicitly check for that group membership.
[17:23] <AlanBell> hmm, so running juju with no arguments should create ~/.juju/environment.yaml?
[17:23] <AlanBell> it doesn't
[17:30] <AlanBell> I set up the environment.yaml manually, it seems to run without error but very very fast and I don't think it is doing anything http://paste.ubuntu.com/962806/
[17:31] <AlanBell> here is my environments.yaml http://paste.ubuntu.com/962809/
[17:34] <SpamapS> AlanBell: it takes a long time to build the first container
[17:34] <AlanBell> then again, it may have actually worked
[17:34] <AlanBell> gosh, it did
[17:34] <SpamapS> AlanBell: has to bootstrap mini-ubuntu .. and then install juju on top of that
[17:35] <AlanBell> I installed an SSD yesterday, not used to the speed and silence, didn't realise it was doing stuff!
[17:35] <AlanBell> I appear to have a working wordpress install
[17:37] <SpamapS> Yeah SSD's suddenly rob you of the scratchy sound of "I'm Busy"
[17:37] <SpamapS> AlanBell: woot
[17:41] <AlanBell> so where are these virtual machines it created? they are not in ~/.juju or the environment working directory ~/Projects/juju
[17:41] <AlanBell> there is stuff in there, but only 264k
[17:41] <SpamapS> /var/lib/lxc
[17:42] <AlanBell> 2GB of stuff there, that sounds about right
[17:46] <SpamapS> yeah, I think its about 600MB per container usually
[19:08] <jcastro> SpamapS: can you review and promulgate something? We're 1 away from 70. :)
[19:29] <_mup_> Bug #993492 was filed: Wrong error message when calling remove-relation with a subordinate charm <juju:New> < https://launchpad.net/bugs/993492 >
[19:37] <SpamapS> jcastro: I'm reviewing dokuwiki right now actually
[19:37] <SpamapS> jcastro: and solr is very close :)
[20:03]  * SpamapS rings the bell
[20:03] <SpamapS> dokuwiki promulgated
[20:03] <SpamapS> jcastro: ^^
[20:06] <marcoceppi> I thought we had a glouster charm?
[20:06] <SpamapS> I think somebody was messing with that
[20:06] <SpamapS> It really needed subs
[20:07] <SpamapS> Same w/ ceph really. I need to write a ceph-client sub
[20:07] <SpamapS> we should probably start slow w/ an NFS-client sub
[20:08] <SpamapS> I really just want to sit and rewrite half the old charms I wrote to be way more awesomer w/ subs.
[20:09] <marcoceppi> SpamapS: that's kind of what I need now
[20:10] <marcoceppi> a Glouster like sub
[20:10] <marcoceppi> I guess it's about time it gets written
[20:11] <marcoceppi> SpamapS: can subs open ports yet?
[20:15] <SpamapS> marcoceppi: no :(
[20:20] <marcoceppi> SpamapS: it's too bad, Glouster would be really easy to charm if I could just open those ports
[20:21] <marcoceppi> I wonder why it doesn't actually work
[20:22] <SpamapS> marcoceppi: wait, why do you need to open ports?
[20:22] <SpamapS> marcoceppi: thats only for *external* access
[20:22] <marcoceppi> DUH
[20:22]  * marcoceppi is so silly
[20:23] <SpamapS> marcoceppi: for a client.. you don't need anybody accessing their local gluster daemons :)
[20:24] <marcoceppi> So, next question, if a charm is a sub, and I juju add-unit to the parent of the sub, will the sub be re-deployed on the new unit (I assume yes) and if so will the peer relation be fired?
[20:28] <SpamapS> marcoceppi: yes
[20:29] <SpamapS> marcoceppi: do you believe in magic? :)
[20:29] <marcoceppi> SpamapS: http://i.imgur.com/f2qPJ.jpg
[20:30]  * SpamapS lols, like, literally
[20:42] <marcoceppi> I think I'm going to end up writing three charms just to author this one charm
[20:45] <SpamapS> marcoceppi: awww yeah thats how the sexy charmers do it, http://on.mtv.com/IYDYWJ
[20:47] <marcoceppi> awwww yeah
[20:51] <nathwill> i... this falls under the category of "can't unsee"
[20:51]  * nathwill shudders
[20:56] <SpamapS> :-D
[20:56] <SpamapS> nathwill: awwwwwwwwwyeah
[21:01] <_mup_> Bug #993552 was filed: Charm store should automatically close any bugs marked using '--fixes' when charm is published. <juju:New> < https://launchpad.net/bugs/993552 >
[21:08] <_mup_> Bug #993557 was filed: Charm store should delete charms that have been removed. <juju:New> < https://launchpad.net/bugs/993557 >
[22:42] <gmb> Hi folks. juju deploy is telling me that a charm doesn't exist in a local repository. AFAICT, it does - and juju was working before an update & reboot. How can I debug this problem?
[22:42] <gmb> s/and juju/this juju deploy command/
[22:46] <SpamapS> gmb: pastebin?
[22:48] <gmb> SpamapS, http://pastebin.ubuntu.com/963475/
[22:48] <SpamapS> gmb: and I assume under /home/graham/launchpad/workspace/juju-charms/precise , you have a dir named 'launchpad-clinic' ?
[22:49] <SpamapS> gmb: whose metadata.yaml also has name: launchpad-clinic ?
[22:50] <gmb> Oh, big hairy arse.
[22:50] <gmb> SpamapS, I forgot I'd renamed the charm but not updated metadata.yaml. Thanks :)
[22:50] <SpamapS> that name: bit will bite you ever time. I just added a charm proof rule to warn people
[22:50] <gmb> Awesome, ta.
[22:53] <_mup_> Bug #993616 was filed: We should ship a boilerplate environments.yaml. <juju:New> < https://launchpad.net/bugs/993616 >
[23:23] <SpamapS> marcoceppi: hey, been reading a few of your reviews. start/stop are not just for the here and now of charms. They're separate hooks from install because they are meant to be run when units are migrated between hosts or rebooted.
[23:23] <SpamapS> marcoceppi: at the moment, they're not used, but I'd like to see new charms implement them as their own, independent entities that can be run at any time.