=== cherylj_ is now known as cherylj
=== aluria` is now known as aluria
[11:43] <gennadiy> Hi everybody. could you help me with my bundle again? https://code.launchpad.net/~dataart.telco/charms/bundles/dataart-telco-demo/bundle
[12:09] <neiljerram> gennadiy, what help do you need?
[12:09] <gennadiy> i know that somebody could check error log
[12:10] <gennadiy> my bundle is not bublished yet. so i think there are some errors
[12:10] <gennadiy> *published
[12:11] <neiljerram> Have you posted the error log somewhere?
[12:11] <magicaltrout> I think gennadiy means errors to the charm store
[12:11] <gennadiy> yes, you are right
[12:12] <gennadiy> i reviewed my bundle manually and run bundle proof, seems everything is ok
[12:13] <gennadiy> anyway do we have some mechanism to get publish error? maybe by email or web portal?
[12:13] <neiljerram> gennadiy, OK - I'm sorry then, because I have not reached that stage myself yet :-)
[12:13] <gennadiy> before pushing i checked bundle on local env. i imported it to juju-gui.
[12:14] <magicaltrout> there's nothing that is publicly published gennadiy
[12:14] <magicaltrout> its all magic behind the scenes stuff
[12:15] <magicaltrout> i'm not sure how bundles are deployed though gennadiy as I've just done single charms
[12:15] <magicaltrout> but you don't have a a ubuntu version in your charm push path, dunno if that has any impact or not
[12:16] <magicaltrout> ah i see it in the docs
[12:16] <magicaltrout> ignore me
[12:17] <magicaltrout> although looking at the requirement to file a bug
[12:17] <magicaltrout> it might be a manual process unlike general charm deployment
[12:17] <magicaltrout> so you might just be sat in the queue gennadiy
[12:17] <magicaltrout> https://jujucharms.com/docs/1.25/charms-bundles
[12:17] <magicaltrout> step 4, 5, 6 and then
[12:17] <magicaltrout> "
[12:17] <magicaltrout> Someone will come along and review your bundle for inclusion."
[12:17] <magicaltrout> looks like you just need to wait it out
[12:19] <gennadiy> there are 2 different types of bundles: with public namespace(like official version) and user space(with user name prefix in path). so i use user space bundles. the should be deployed automatically
[12:20] <gennadiy> generally it takes 40 min
[12:20] <gennadiy> if you have not got result during this time your bundle has error :)
[12:20] <gennadiy> a few people in this chat has access to error log.
[12:32] <magicaltrout> well I dunno, for charms thats certainly true
[12:33] <magicaltrout> those docs seem to suggest bundles are different
[12:33] <magicaltrout> but I have no idea :)
[13:12] <gennadiy> is anybody joined who has access to publish error logs?
[13:19] <jrwren> gennadiy: we don't exactly, but i can look at other things.
[13:33] <gennadiy> jrwren: do you have possibility to check why bundle is not published yet?
[13:36] <jrwren> i don't.
[13:42] <stub> Starting from the example at https://github.com/cmars/nrpe-external-master-interface, do I also need an upgrade-charm hook wired up to initialize or reintialize the nrpe-external-master.available handlers?
[13:56] <dweaver> Hi All, I have a Juju environment on 1.25.0 and I am getting a service constantly reconfigured.  I have 3 cinder units working fine, but then it starts to run cluster-relation-changed, says unit is ready, and then does it again, and again .....  Restarting the services constantly in the process, nagios is detecting it as down.  The cluster relations have not changed, so I am wondering how you tell why Juju is running this constantly in a loop?  Debug-l
[13:56] <dweaver> og doesn't seem to tell me what triggers hooks.
[13:58] <dweaver> Is there somewhere I can dig further to find out?
[14:24] <jrwren> gennadiy: bundle verification failed: ["cannot validate service \"drop-conference\": configuration option \"DID_DOMAIN\" not found in charm \"cs:~dataart.telco/trusty/drop-conference-1\"","cannot validate service \"drop-conference\": configuration option \"PHONE_NUMBER\" not found in charm \"cs:~dataart.telco/trusty/drop-conference-1\""]
[14:25] <magicaltrout> I know we touched on some of this stuff in Ghent, are things like that --^ going to become available to developers without having to prod you guys in Juju 2.... and the new review queue etc
[14:27] <magicaltrout> a feedback mechanism about what your charm/bundle is upto in the deployment process at least
[14:28] <jrwren> magicaltrout: yes, there will be no ingestion and you will be able to upload directly to charmstore yourself.
[14:28] <magicaltrout> boom
[14:29] <magicaltrout> good to know
=== natefinch is now known as natefinch-afk
[14:53] <lazyPower> axino o/ heyo
[14:54] <axino> hey lazyPower
[14:54] <axino> o/
[14:54] <lazyPower> axino i have it on good authority you guys have a bomb-diggity logstash charm over in IS
[14:54]  * axino gives lazyPower a Chouffe
[14:54] <lazyPower> Woo
[14:54] <lazyPower> this early?
[15:00] <rick_h_> lazyPower: maybe hit up jrwren as well. I know we were playing with one
[15:00] <lazyPower> rick_h_ i'm already all over that one :)
[15:00] <lazyPower> rick_h_ - its claimed as abandoned, but i think its about to get some TLC
[15:01] <rick_h_> lazyPower: gotcha
[15:01] <neiljerram> Anyone know why 'juju deployer -b ...' would fail to download code from a launchpad branch?
[15:02] <neiljerram> Here's the transcript:
[15:02] <neiljerram> root@calico14:~/md4# rm -rf trusty/
[15:02] <neiljerram> root@calico14:~/md4# juju deployer -b -c liberty.yaml
[15:02] <neiljerram> 2016-02-24 14:59:49 Using deployment envExport
[15:02] <neiljerram> 2016-02-24 14:59:49 Starting deployment of envExport
[15:02] <neiljerram> 2016-02-24 15:00:50 Could not branch lp:~project-calico/charms/trusty/neutron-api/liberty to trusty/neutron-api
[15:02] <neiljerram>  bzr: ERROR: [Errno 2] No such file or directory
[15:02] <neiljerram> 2016-02-24 15:00:50 Deployment stopped. run time: 61.54
[15:03] <neiljerram> And in .bzr.log I have:
[15:03] <neiljerram> 0.097  bazaar version: 2.7.0dev1
[15:03] <neiljerram> 0.097  bzr arguments: [u'co', u'--lightweight', u'lp:~project-calico/charms/trusty/neutron-api/liberty', u'trusty/neutron-api']
[15:03] <neiljerram> 0.104  looking for plugins in /home/ubuntu/.bazaar/plugins
[15:03] <neiljerram> 0.104  looking for plugins in /usr/lib/python2.7/dist-packages/bzrlib/plugins
[15:03] <neiljerram> 0.129  encoding stdout as sys.stdin encoding 'UTF-8'
[15:03] <neiljerram> 0.242  ssh implementation is OpenSSH
[15:03] <neiljerram> 15.043  creating branch reference in file:///home/ubuntu/md4/trusty/neutron-api/
[15:03] <neiljerram> 17.685  trying to create missing lock '/home/ubuntu/md4/trusty/neutron-api/.bzr/checkout/dirstate'
[15:03] <neiljerram> 17.719  opening working tree '/home/ubuntu/md4/trusty/neutron-api'
[15:03] <neiljerram> 18.766  Traceback (most recent call last):
[15:03] <neiljerram>   File "/usr/lib/python2.7/dist-packages/bzrlib/commands.py", line 930, in exception_to_return_code
[15:03] <neiljerram>     return the_callable(*args, **kwargs)
[15:03] <neiljerram>   File "/usr/lib/python2.7/dist-packages/bzrlib/commands.py", line 1121, in run_bzr
[15:03] <neiljerram>     ret = run(*run_argv)
[15:03] <mgz> neiljerram: please, pastebin
[15:03] <neiljerram>   File "/usr/lib/python2.7/dist-packages/bzrlib/commands.py", line 673, in run_argv_aliases
[15:03] <neiljerram>     return self.run(**all_cmd_args)
[15:03] <neiljerram>   File "/usr/lib/python2.7/dist-packages/bzrlib/commands.py", line 697, in run
[15:03] <neiljerram>     return self._operation.run_simple(*args, **kwargs)
[15:03] <neiljerram>   File "/usr/lib/python2.7/dist-packages/bzrlib/cleanup.py", line 136, in run_simple
[15:03] <neiljerram>     self.cleanups, self.func, *args, **kwargs)
[15:03] <neiljerram>   File "/usr/lib/python2.7/dist-packages/bzrlib/cleanup.py", line 166, in _do_with_cleanups
[15:03] <neiljerram>     result = func(*args, **kwargs)
[15:03] <neiljerram>   File "/usr/lib/python2.7/dist-packages/bzrlib/builtins.py", line 1667, in run
[15:03] <neiljerram>     accelerator_tree, hardlink)
[15:03] <neiljerram>   File "/usr/lib/python2.7/dist-packages/bzrlib/branch.py", line 1469, in create_checkout
[15:03] <neiljerram>     hardlink=hardlink)
[15:04] <neiljerram>   File "/usr/lib/python2.7/dist-packages/bzrlib/bzrdir.py", line 907, in create_workingtree
[15:04] <neiljerram>     accelerator_tree=accelerator_tree, hardlink=hardlink)
[15:04] <neiljerram>   File "/usr/lib/python2.7/dist-packages/bzrlib/workingtree_4.py", line 1565, in initialize
[15:04] <neiljerram>     delta_from_tree=delta_from_tree)
[15:04] <neiljerram>   File "/usr/lib/python2.7/dist-packages/bzrlib/transform.py", line 2543, in build_tree
[15:04] <neiljerram>     del
[15:04] <magicaltrout> neiljerram: let me introduce you to pastebin or gist! ;)
[15:04] <neiljerram> Sure, sorry!
[15:04] <neiljerram> So here's the .bzr.log: http://pastebin.com/rMuqrLsL
[15:05] <neiljerram> (Have I done that right?)
[15:07] <mgz> neiljerram: yes. and the branch just has a borked symlink
[15:07] <mgz> neiljerram: and you're the last commit on it
[15:07] <mgz> so... just fix that?
[15:08] <neiljerram> mgz, You mean there's a broken symlink somewhere in the working tree?
[15:12] <neiljerram> mgz, I'm sorry, I'm not seeing the problem.  So if you are, please do say more!
[15:13] <neiljerram> However, it occurs to me that I should be able to use strace to see the failing symlink call...
[15:14] <mgz> that's not super useful
[15:14] <mgz> because it's just a limbo name
[15:14] <mgz> neiljerram: so, just get the branch with `bzr branch --no-tree lp:...`
[15:14] <mgz> then you can do `BZR_PDB=1 bzr reconfigure --tree` and drop in at the error site
[15:15] <neiljerram> I guess these are the relevant calls: http://pastebin.com/8Bmt9axy
[15:15] <mgz> but getting the borked filename out is mildly annoying
[15:15] <magicaltrout> don't ya just love bzr weirdness! ;)
[15:15] <neiljerram> 'limbo'?  I see that in the strace too, but I have no idea what it means here.
[15:16] <mgz> bzr stages files when creating trees
[15:16] <mgz> doesn't overwrite in place
[15:17] <magicaltrout> reminds me of how sad perforce used to make me ;)
[15:17] <neiljerram> I'm still not understanding a lot of the terminology here.
[15:17] <neiljerram> But I think you're saying that the bzr history includes a commit somewhere that added a broken symlink.
[15:18] <neiljerram> And because of that, bzr is always going to fail for me with this branch.  Is that right?
[15:18] <neiljerram> Anyway, I will try the commands you recommended!
[15:19] <magicaltrout> thats basically it, and you need to extract a copy without a working tree to unbork it
[15:19] <magicaltrout> not that i'm any more clued up on bzr either
[15:19] <mgz> neiljerram: hooks/install
[15:19] <mgz> neiljerram: the target is "" - which is bogus
[15:20] <neiljerram> magicaltrout, thanks
[15:20] <neiljerram> mgz, thanks also!
[15:21] <mgz> I can just fix this, might even have push rights to the branch
[15:21] <mgz> commit 142 "unknown <james.page@ubuntu.com>" dunno what he did to screw this, but goodjob
[15:23] <mgz> history rewriting gone wrong? something else?
=== natefinch-afk is now known as natefnich
=== natefnich is now known as natefinch
[15:23] <mgz> jamespage: your git switch breaking things? ^
[15:24] <neiljerram> Here's what I see with the bzr reconfigure session: http://pastebin.com/XWG7LFsG
[15:24] <neiljerram> Does 'new-15' mean that the problem was introduced in revision 15 ?
[15:24] <jamespage> mgz, not yet
[15:25] <mgz> neiljerram: nope, it's just a placeholder name in the stagin area
[15:25] <mgz> neiljerram: it's actually more useful to do `bzr diff -r0..-1 and grep the diff for the symlink lines
[15:26] <neiljerram> OK...
[15:26] <mgz> jamespage: I am confused as to how a change from september that made it impossible to checkout a tree wasn't seen till today
[15:26] <mgz> without history rewriting
[15:27] <jamespage> I don't even know how todo that :-)
[15:28] <mgz> jamespage: well, I guess the branches don't have push overwrite protection on lp? any one or any bot could have changed it?
[15:28] <jamespage> mgz, we've not done any push --overwrites for a while now
[15:31] <beisner> mgz, jamespage - afaik, 15.04 was the last push --overwrite on ~openstack-charmers space
[15:36] <neiljerram> Do you already know whether the upstream openstack-charmers branch has the same problem?  I wonder if something went wrong when I pushed my fork of that to lp:~project-calico/charms/trusty/neutron-api/liberty
[15:45] <neiljerram> Hmm; I don't see the same problem if I use lp:~openstack-charmers/charms/trusty/neutron-api/next instead of my fork.  So I guess there was a problem in how I pushed my fork.  I'll try killing and recreating my fork.
[15:45] <jamespage> neiljerram, you might be please to know that as of next week, openstack charm development should be under the openstack project so git/gerrit rather than bzr/launchpad....
[15:46] <neiljerram> jamespage, Yes, I will be very pleased about that!  Thanks for your work on this.
[15:53] <gennadiy> jrwren: thanks. i have to disable copy/paste functionality
=== natefinch is now known as natefinch-lunch
[17:34] <jose> mbruzek: so, Ryan's in? :D
[17:36] <neiljerram> Hi all, now seeing a problem with bootstrap, I wonder if anyone might help?
[17:36] <jose> neiljerram: sure!
[17:36] <jose> neiljerram: what's going on?
[17:36] <neiljerram> Appears problem is that machine-0 doesn't manage to bring up juju-br0
[17:37] <neiljerram> And when that happens, I can't ping the machine; the logs that I can see in the vSphere console indicate that it has lost its IP address.
[17:38] <neiljerram> If I deploy the same machine using just MAAS, it's fine.
[17:38] <neiljerram> (Using Trusty)
[17:38] <jose> what substrate are you deploying on?
[17:39] <neiljerram> Not sure what 'substrate' is - MAAS?
[17:39] <jose> yep, what are you deploying on (aws, maas)
[17:39] <neiljerram> Yes, MAAS then.
[17:39] <jose> ^those are just examples
[17:40] <neiljerram> And if I just use MAAS to deploy the same machine, it's fine.
[17:40] <jose> hmmk. I'm not too much into maas, but maybe there's something missing in Juju, so let's take a look!
[17:40] <neiljerram> I.e. it has an IP and I can log in via ssh.
[17:40] <jose> can you please execute `juju bootstrap --debug` and paste the results on paste.ubuntu.com?
[17:40] <neiljerram> Sure...
[17:40] <jose> thanks :D
[17:42] <neiljerram> By the way, what is meant by the juju "tools" ?
[17:44] <jose> the juju tools are basically what enables juju on the machines
[17:44] <jose> all the binaries
[17:45] <neiljerram> Here's `juju bootstrap --debug`: http://pastebin.com/cVJP56EN
[17:47] <lazyPower> neiljerram - which version of maas are you using?
[17:47] <neiljerram> MAAS Version 1.8.3+bzr4053-0ubuntu1 (trusty1)
[17:48] <neiljerram> (that's what it says at the bottom of my MAAS web page)
[17:48] <lazyPower> yep, just making sure it wasnt 1.9, i dont think 1.9 works with 1.25 - but dont hold me to that.
[17:48]  * lazyPower hasn't investigated lately
[17:49] <jose> hmm, from what I read juju is not creating anything, but assuming the bridge is already there
[17:52] <neiljerram> can you see that in those logs?
[17:54] <neiljerram> BTW, I should add, bootstrapping was working for me yesterday, and AFAIK I haven't changed anything relevant.
[17:55] <neiljerram> Between yesterday and today, I've worked on and resolved another problem to do with the exact charm code that I am trying to deploy.  But I would not expect that to be relevant to the bootstrap phase.
[17:55] <neiljerram> So it's quite mysterious why it has stopped working.
[17:57] <neiljerram> Is there a way I can see the complete log of what Juju did to the machine after it had MAAS-booted?
[18:00] <neiljerram> Or can I configure a password for 'root' or 'ubuntu' on that machine (instead of an SSH key), so that I can log in to its console?
[18:02] <jose> sorry, I had to run do something but I'm back around
[18:03] <jose> hmm, let me remember where those logs are stored
[18:05] <neiljerram> No worries - thanks for looking at this!
[18:05] <jose> happy to help :)
[18:05] <neiljerram> I do have to run in about 5 minutes, though - so no pressure :-)
[18:06] <jose> ok, so the machine is actually created, but juju cannot connect, right?
[18:06] <neiljerram> correct
[18:06] <neiljerram> I can't ping or connect with SSH, either
=== natefinch-lunch is now known as natefinch
[18:10] <jose> ok, so can you please ssh into the machine?
[18:10] <neiljerram> No, I can't.
[18:11] <neiljerram> (I guess because the Juju post-boot setup on the machine has removed the IP address from eth0.)
[18:12] <jose> oh, oh, you can't
[18:13] <jose> hmm... so the bridge is missing. I'd say we have to manually create the bridge
[18:13] <jose> I don't know if someone around knows how to do it, I don't tbh
[18:14] <neiljerram> ok - well I have to go now, but thanks for looking at this!
[18:15] <jose> no prob! let us know when you're back and I'll see what I can do
[20:00] <lazyPower> cory_fu - if you have a minute, can you help me wrap my head around why i'm getting a scope error on handling relationship data/states here? http://pastebin.ubuntu.com/15190366/
[20:01] <cory_fu> lazyPower: It must be that the scope value you're passing in to self.conversation() isn't valid
[20:01] <cory_fu> OH wait
[20:02] <cory_fu> You're using RelationBase.get_remote()
[20:02] <lazyPower> its on an interface that is scope: global on provides, scope: service on requires
[20:02] <lazyPower> should i refactor those self.get_remotes() to conv = self.conversation() conv.get_remote('thing')?
[20:02] <cory_fu> You're using self.get_remote() in the requires, which you can't use for anything but global scope
[20:02] <lazyPower> interesting nuance
[20:03] <cory_fu> lazyPower: If you're scope is service, it means you can have multiple conversations (one per connected service) so you have to iterate over them
[20:03] <cory_fu> *your
[20:04] <cory_fu> lazyPower: https://github.com/chuckbutler/interface-etcd/blob/master/requires.py is GLOBAL scope.  I assume you're changing it to support multiple services?
[20:04] <lazyPower> nope
[20:04] <lazyPower> i clearly misunderstood scopes again :)
[20:04] <lazyPower> and just reverted back to global from service
[20:13] <cory_fu> lazyPower: Comment added to your PR on the etcd interface layer
[20:16] <cory_fu> lazyPower: And another comment
[20:17] <jamespage> beisner, hey - are you ok for a quick +1 on https://code.launchpad.net/~james-page/charms/trusty/neutron-gateway/tox8-test-refactor/+merge/286933
[20:17] <jamespage> all passing now...
[20:19] <lazyPower> cory_fu - added a response
[20:19] <cory_fu> lazyPower: Responded to your response.  ;)
[20:20] <lazyPower> gah sniped me
[20:20] <lazyPower> i mean i'm fine refactoring i'm not married to this, just exhausted after trying to get a working cluster after that refactor :|
[20:21] <cory_fu> The important bit is that the interface layer shouldn't put restrictions on how the charm layer implements things.  Someone might want to create an alternate etcd charm that didn't use a peer relation, or got the port from somewhere other than config, or... something
[20:22] <cory_fu> Also, you tend to end up with much cleaner code when you properly separate your concerns
[20:27] <beisner> jamespage, definitely good with the tox8 changes.  passing tests are good.  i don't see anything offensive in the other bits. ^
=== scuttle` is now known as scuttle|afk
[20:51] <stokachu> https://www.irccloud.com/pastebin/81w6oO7Q/
[20:51] <stokachu> am i missing something with juju2 and lxd?
[20:58] <rick_h_> stokachu: what ubuntu release?
[20:58] <stokachu> rick_h_: oh, on trusty
[20:58] <stokachu> guessing that wont work
[20:58] <rick_h_> stokachu: there's a few issues with lxd and beta1 and on the email through with the beta notice
[20:58] <rick_h_> stokachu: yes, trusty among them
[20:58] <stokachu> ok
[20:59] <rick_h_> stokachu: also doesn't work with lxd beta3 that just came out due to an api break the team is working on
[20:59] <stokachu> rick_h_: and also doesn't work with beta4 just fyi
[20:59] <stokachu> (just found out)
[21:00] <rick_h_> stokachu: yea, jam is working with tose folks to get it working with master
[21:00] <rick_h_> stokachu: juju has to play catch up with api changes happening in lxd between beta releases
[21:00] <stokachu> rick_h_: ok cool, im anxious to mess with it
[21:00] <rick_h_> stokachu: +1
=== scuttle|afk is now known as scuttlemonkey
[22:42] <lazyPower> rick_h_ - btw days later response to  your statement of cloud credentials - foudn it in the rel notes https://lists.ubuntu.com/archives/juju/2016-February/006618.html
[22:58] <lazyPower> tvansteenburgh - got another minute?
[22:59] <lazyPower> tvansteenburgh - pushed ~ 20 minutes ago the working charmbox branch i've cooked up. LMK if theres anything blatantly missing in there you need for QA/CI purposes. bugs as required and i'll get it fixed up
[22:59] <tvansteenburgh> lazyPower: about the charmbox pr?
[22:59] <tvansteenburgh> lazyPower: roger, will look in a bit, maybe tomorrow am, in the middle of something atm
[22:59] <lazyPower> but this should get you on 2.0-beta1 faster than cat in a hat :)
[22:59] <tvansteenburgh> cool
[22:59] <lazyPower> understood. thanks mang
[22:59] <tvansteenburgh> np
[23:12] <nagyz> is there a way to tell juju-deployer to just use the "normal" (upstream?) charms?
[23:12] <nagyz> instead of trying to find them locally?
[23:15] <tvansteenburgh> nagyz: prefix them with 'cs:'
[23:15] <mux> hey - I'm new to this... I'm interested in the 'storage' charm, but I'm getting "ERROR cannot resolve charm URL "cs:trusty/storage": charm not found"
[23:17] <mux> I'm sure that's something really simple, like "the charm doesn't exist for this version", but like I said, I'm new
[23:17] <mux> where can I find details?
[23:17] <nagyz> tvansteenburgh, ah, stupid me. :) what does cs stand for actually?
[23:17] <tvansteenburgh> nagyz: charmstore
[23:18] <tvansteenburgh> mux: looks like the 'storage' charm exists only for precise
[23:18] <mux> tvansteenburgh: where do I look to find that?
[23:18] <tvansteenburgh> mux: there are other options though: https://jujucharms.com/q/storage
[23:19] <nagyz> tvansteenburgh, thanks
[23:19] <tvansteenburgh> nagyz: np
[23:19] <tvansteenburgh> mux: i just went to jujucharms.com and searched for 'storage'
[23:19] <nagyz> one more question: when deploying something using juju-deployer and I have the machines listed in the yaml, is there really a need for +1 machine (for the bootstrapping node)?
[23:19] <lazyPower> nagyz - juju wont function without the model controller
[23:20] <lazyPower> so yeah, that +1 is pretty mandatory
[23:20] <lazyPower> you dont need to define it in the yaml though, as that node is special to juju and its implied
[23:20] <nagyz> ok so that's something that's always assumed and is outside of whatever I have described in my yaml
[23:20] <nagyz> right
[23:20] <lazyPower> yep yep
[23:20] <nagyz> cheers
[23:21] <lazyPower> cory_fu - thanks for the interface pointers
[23:21] <cory_fu> np
[23:21] <lazyPower> looks a lot cleaner after refactoring to your suggestion(s).
[23:21] <lazyPower> so, when i get a chance, i really want to pair with you on realtion scopes, and get something put together for a reference
[23:21] <lazyPower> even if its just a video of you re-telling me the same things you've told me five times that i've forgotten
[23:21] <cory_fu> Yeah
[23:21] <lazyPower> it'll keep me from bugging you regardless
[23:22] <lazyPower> irrespectively
[23:22] <lazyPower> irregardlessly
[23:22] <lazyPower> kwmonroe'ly
[23:22] <cory_fu> 9_9
[23:44] <magicaltrout> okay random question
[23:45] <magicaltrout> if I wanted to add more useful mysql backup, like automysqlbackup or something that shunted semi-directly to s3, would it make sense to create a subordinate so as not to pollute the existing charm?
[23:45] <magicaltrout> I'm thinking about charms like mysql where people have their own preference of backup ideas