[00:03] <marcoceppi> review queue is about to get a big update, it'll be down for about 20 minutes
[00:51] <marcoceppi> jose: so, the testing button works, but the refresh profile (and refreshing of the queue is broken) so the button still won't work for you yet
[00:52] <jose> marcoceppi: thanks! lemme check
[00:52] <marcoceppi> jose: _won't_ work for you yet still
[00:52] <jose> ah
[00:52] <marcoceppi> yeah, hope to have it resolved soon
[00:53] <jose> no worries
[12:50] <jaywink> hi. any idea if there is any way to set some config values for charms which are not a part of the charm normal config? what I am thinking about is backing up postgresql backup dumps using the jujubackup charm, which relies on the backed up charm to have backup instructions as config. this is difficult in the case of say a charm from the store - would rather not fork all charms just to make them talk to jujubackup
[12:52] <jaywink> or maybe if I add those values to postgresql charm and the correct hooks to interact with jujubackup, wondering if there is any chance of that being accepted into the main charm code?
[12:54] <jaywink> well I guess there is only one way to find out :)
[13:01] <jaywink> btw, added swift storage for jujubackup, works nicely in an openstack environment now for charm backups
[13:27] <marcoceppi> jaywink: well, the postgresq charm already does regular dumps
[13:28] <marcoceppi> and puts them in a standard location
[13:29] <jaywink> marcoceppi, yeah, but would be nice to be able to deploy jujubackup as a subordinate and have the backups be zipped to swift for example .. I know it's easy to add a crontab entry :)
[13:30] <marcoceppi> jaywink: well you could do that as it is, just deploy jujubackup and have jujubackup include logic to sniff out common charms backup procedures
[13:30] <jaywink> but now reading more carefully postgres charm also has some kind of swiftwal backup functionality
[13:31] <jaywink> marcoceppi, yes was thinking about that too. though I guess the idea behind jujubackup was (reading it) that it would not require config and the other charm would instead have the config. but it's a bit heavy for common charms in the store for example
[13:48] <jaywink> any idea what is the risk level of doing a "juju upgrade-charm postgresql --switch --repository="/path"" operation on a postgresql charm deployed from the charm store, if the version of the charm is the same, eg I've branched the code out and just want to start using a local version?
[13:49] <marcoceppi> jaywink: not much, I mean --switch is pretty hulk smashy but if you're using a modified version fot he currently deployed charm not much harm
[13:49] <marcoceppi> it's actually a great way to switch to a patched version of the charm while you wait for the store to be updated
[13:50] <jaywink> ok thanks! I have backups ;)
[14:12] <jaywink> hmm I wonder if anyone uses the SwiftWAL feature of postgresql charm? I don't get the crontab entry installed and looking at the code I can't see how it could work - the configs are never used to init the crontab part OR swiftwal config template. Been trying to look for a development version branch but no luck so far
[21:34] <jaywink> any idea why charm_helpers_sync.py isn't installed as a script when installing charmhelpers from pip for example? I can see from the setup that it isn't, just wondering why - seems like it would be much easier to use :)
[23:24] <lazyPower> jaywink: we *just* got charmhelpers in pip
[23:25] <lazyPower> there's still a lot of work that needs to go into shoring it up. if you file a bug against charmhelpers that will help remind us that there are papercuts left around that are low hanging fruit
[23:25] <lazyPower> http://launchpad.net/charmhelpers
[23:26] <jaywink> lazyPower, ok thanks, figured there was probably no reason for it not being installed :) will file a bug
[23:29] <jaywink> can't quite put my finger to why, but I tried to install some swiftwal requirements in the postgresql charm by adding charmhelpers.contrib.python and using that pip_install command - but it just doesn't do things the same way as I run a subprocess.call for the same packages in the same part of the charm .. but I couldnt' really figure out quickly why, probably due to some versions conflicting which it was not able to solve but pip cli
[23:29] <jaywink>  was able to solve