[00:13] <lazypower> Has the testing framework for juju been finalized?
[00:13] <lazypower> *juju charms
[01:18] <marcoceppi> lazypower: basically, yes
[01:23] <marcoceppi> there's a new release of a testing tool, amulet, coming out next week. But the structures of tests are essentially the same. files in tests/ are run and need to exit with either 0 (OK), 1 (FAIL), or 100 (SKIP)
[01:25] <lazypower> Can you point me to the documentation for this? none of the example charms I chose have a tests/ directory.
[01:26] <lazypower> Oh, nevermind its on github where it should be: https://github.com/marcoceppi/amulet
[01:26] <marcoceppi> lazypower: the documentation is out of date, that's being updated too :)
[01:26] <lazypower> well thats handy
[01:27] <lazypower> Ok, i'll continue hacking in rinse/repeat mode until notification that amulet is up2date
[01:32] <marcoceppi> lazypower: should be up around Tuesday
[01:37] <marcoceppi> lazypower: here's an example of a test using amulet: https://gist.github.com/marcoceppi/7727543
[01:43] <lazypower> marcoceppi: I've got a prototype subordinate charm written for papertrail thats working for rsyslog integration. There's another unit provided by papertrail for arbitrary file tailing and logshipping. Is there a preferred method for adding multiple resources like this in configuration?
[01:44] <lazypower> Or would a smarter approach be to split the charm into 2 flavors, one for rsyslog, and another charm that would house the path for this arbitrary log resource, and deploy multiple subordinates to accomplish the logshipping?
[01:46] <marcoceppi> lazypower: there's a few ways to tackle this one. The easiest is to make it a configuration option, something like "additional-logs" and then have a user pass in a comma seperated list. The next would be to have the interface specify this, but that would require either a new interface or a change to the existing one (if there is one). Another option would be to have the interface change, but also have the charm do some basic checking. Like
[01:46] <marcoceppi> instead of just rsyslog, have a config options for "all-logs" as a boolean, where it will automatically do everything in /var/log/*
[01:46] <lazypower> What if i'm running a local resource that doesn't log to /var/log?
[01:46] <marcoceppi> lazypower: I wouldnt' split the charms. I would instill both logics in one charm and switch based on context (either relationship, configuration, etc)
[01:47] <marcoceppi> lazypower: configuration option. This might actually be available in the logging interface, let me check
[01:47] <lazypower> http://manage.jujucharms.com/charms/precise/logstash-agent - seems to achieve this with an array type.
[01:49] <lazypower> ok, i like how logstash did it. I'll add the boolean flag for all logs, and a sibling config value for specific log files.
[01:49] <marcoceppi> lazypower: that's actually pretty janky. It's abusing type casting within YAML and Juju
[01:49] <lazypower> oh
[01:49] <lazypower> well nevermind then
[01:49] <marcoceppi> lazypower: the idea is good, the implementaiton is a bit..not user friendly
[01:50] <lazypower> It looked really nice though, having an array type
[01:50] <marcoceppi> lazypower: yeah, except we don't have a true array type in juju configruation, it's basically a string representation of a json array
[01:50] <marcoceppi> then it's coercing that in to an array during the hook, not exactly user friendly (dev friendly, sure)
[01:51] <lazypower> if I cleary document that, with a #todo left in the readme, think it'll get enough traction to be useful or would I get dinged during review?
[01:51] <lazypower> *clearly
[01:51] <marcoceppi> a " " space seperated list, or comma delimited list that gets parsed in the hook is much better approach for fomat
[01:51] <lazypower> ok. i can do that.
[01:52] <marcoceppi> lazypower: something else to consider, we don't have a logs interface yet (or a logging one). You could create a spec for one so that charms could reveal where their logs were in addition to having users set it via config
[01:52] <marcoceppi> one less thing for the user to do if charms adopt that new interface
[01:52] <marcoceppi> that's not a requirement, just something to consider
[01:52] <lazypower> hmm... good idea.
[01:52] <lazypower> I'll open a Feature Request on it
[01:52] <marcoceppi> cool
[01:53] <marcoceppi> it might be worth while for us to consider adding "make sure services logs are present in /var/log" as a best practice for charms
[01:56] <lazypower> https://github.com/chuckbutler/papertrail-charm/issues?labels=&state=open
[01:56] <lazypower> i know the upstream version of this needs ot be in bazaar, but if you think of anything ot add to the FR would you add it?
[01:59] <marcoceppi> lazypower: I'd have to look at the charm. I typically do that during reviews ;)
[01:59] <marcoceppi> if I have some time tomorrow I'll poke at it
[02:00] <marcoceppi> lazypower: I recommend running `juju charm proof` in the charm directory, as it'll cover most of the things formatting wise that need to be done to the charm
[02:06] <lazypower> Ok, Thank you.
[10:37] <Luca__> Does anybody know how network are set up on nodes managed by charms? I am having hard time finding documentation about underlying network infrastructure
[10:44] <marcoceppi> Luca__: there's not much that happen there now. A little bit is done by juju on maas, but otherwise the provider is responsible for networking'
[10:48] <Luca__> marcoceppi: would you mind providing few more details or point to some doc? as far as I could see maas nodes gets a br interfaces where eth0 is included, and a lxcbr0 bridge.
[10:50] <Luca__> marcoceppi: I am trying to deploy openstack HA using jamespage documents, but cant fully understand how network interfaces are managed by juju, and looks like the documentation is not quite what I expect
[10:50] <marcoceppi> Luca__: I'm not sure where it's documented, and only recently was some additional networking stuff added
[10:51] <Luca__> marcoceppi: in an usual openstack deployment I would see at least 3 different network, one for management, one for storage and one for public/floating. Not sure how to include all those into the charms
[10:51] <Luca__> marcoceppi; https://wiki.ubuntu.com/ServerTeam/OpenStackHA
[10:56] <Luca__> marcoceppi: there jamespage uses different networks for maas maas and ie. mysql vip however from the example it looks like this address is defined on eth0, which is already used for the maas nodes, therefore it is somehow not very clear
[10:59] <Luca__> marcoceppi: I will be boarding in few minutes but may be online in 3 hours if you are still available
[11:00] <marcoceppi> Luca__: yeah, I've not used the openstack charms so I can't speak to them in a MAAS setup
[11:45] <jamespage> marcoceppi, man - I keep missing him
[11:45] <jamespage> the answer is that the openstack charms currently assume a flat network
[11:46] <jamespage> (multi-network support is in dev - but not beta or GA yet)
[14:04] <marcoceppi> jamespage: cool, he said he'll be online in a few hours, hopefull you can catch him again!
[14:54] <aquarius> marcoceppi, how do I set "host names" in discourse's database.yml? That file says "this was created by juju, do not edit"
[14:55] <marcoceppi> aquarius: oh, that's something I need to fix still. You can't at the moment. You'll need to manually edit it for the time being
[14:55] <aquarius> I should edit that file even though it says in big letters not to? :)
[14:55] <aquarius> if I deploy a new version of the charm, won't it get overwritten?
[14:55] <marcoceppi> aquarius: yes ;)
[14:55] <marcoceppi> aquarius: it will, but I'll have a hostname configuration option by then
[14:56]  * aquarius laughs
[14:56] <aquarius> OK :)
[14:56] <aquarius> when Bad Voltage's discourse stops working, I'm going to blame you ;-)
[14:56] <aquarius> on the other hand you *did* make it so I could deploy in 4 lines of code, which has earned you a sizeable block of credit ;)
[14:57] <aquarius> do I have to restart discourse somehow to make it pick up changes to that file?
[15:00] <aquarius> marcoceppi, ^
[15:00] <marcoceppi> aquarius: just the webs, `sudo stop discourse-webs; sudo start discourse-webs` should do it
[15:01] <aquarius> I don't have a discourse-webs?
[15:01] <aquarius> just discourse and discourse-sidekiq?
[15:01] <marcoceppi> aquarius: what's `initctl list | grep discourse` show?
[15:01] <marcoceppi> aquarius: odd, you should have a ton of upstart scripts
[15:01] <aquarius> jujud-unit-discourse-0 start/running, process 9278
[15:01] <aquarius> discourse-sidekiq start/running, process 53655
[15:01] <aquarius> discourse-clockwork stop/waiting
[15:01] <aquarius> discourse start/running
[15:01] <aquarius> discourse-webs stop/waiting
[15:01] <aquarius> discourse-web (3000) start/running, process 53537
[15:01] <aquarius> hrm
[15:01] <aquarius> -webs isn't even running
[15:02] <marcoceppi> aquarius: okay, you have to manually stop discourse-web, then run discourse-webs
[15:02] <marcoceppi> aquarius: that's okay, discourse-webs is like a meta upstart thing
[15:02] <marcoceppi> I don't think I have it coded correctly
[15:02] <marcoceppi> sudo stop discourse-web PORT=3000; sudo start discourse-webs
[15:02] <marcoceppi> and discourse-clockwork is legacy, it should be stopped if you have the latest discourse
[15:03] <aquarius> it is stopped, so that's OK
[15:03] <aquarius> right, we seem to be up and running again :)
[15:05] <marcoceppi> \o/
[15:05] <marcoceppi> aquarius: in versions soon to be coming, you'll be able to restart discourse with 0 downtime :)
[15:05] <aquarius> nice!
[15:14] <marcoceppi> aquarius: keep the feedback coming, happy to implement things for people using the charm in production
[15:14] <aquarius> marcoceppi, if I add a different header, will that also get overwritten on a new deployment?
[15:16] <marcoceppi> aquarius: if you're doing everything either in the customization are or a plugin, then no it'll work between deployments
[15:16] <marcoceppi> so long as you're using the same database (for the admin customizations)
[15:18] <marcoceppi> forgot to mention the database is vital, but it's easy to dump and reimport
[15:19]  * marcoceppi should put instructions in the readme
[15:23] <aquarius> marcoceppi, how can I check whether discorse is sending emails correctly?
[15:24] <marcoceppi> aquarius: there's an email testing screen in the admin panel under "Email"
[15:24] <aquarius> It sent an email yesterday, but I've just tried setting up a new user and it didn't arrive
[15:24] <aquarius> oh, really? brilliant!
[15:24] <marcoceppi> aquarius: how long ago? Emails send about every 5 mins
[15:24] <aquarius> longer ago than that
[15:24] <aquarius> will try the email test thing
[15:25] <marcoceppi> aquarius: you can also check /sidekiq to see what's going on with the periodic jobs
[15:25] <marcoceppi> that will list failed tasks, etc
[15:32] <aquarius> test mail not arriving either :(
[16:01] <aquarius> ok, mail is a problem at my end
[16:02] <marcoceppi> aquarius: if you have a legit smtp server (other than sendmail) you can add those details to /home/discourse/discourse/config/environments/production.rb
[16:02] <aquarius> and you have to restart discourse, not just discourse-webs, to pick up database.yml changes :)
[16:02] <aquarius> nah, mail arrives for jono, so it's my fault ;)
[16:02] <marcoceppi> aquarius: interesting, good to know
[16:02] <marcoceppi> ah
[16:02] <marcoceppi> aquarius: check your spam?
[16:03] <aquarius> gnaaaaah there they are
[16:03] <aquarius> thank you :)
[18:11] <marcoceppi> aquarius: I recommend using a real SMTP server and not just sendmail, or more people may have that problem
[18:14] <aquarius> ya, but that means I have to *have* a real smtp server, which I do not ;)