[11:46] <ktosiek> ok, so I'm starting my first charm - are there any good examples of charms written with Ansible?
[11:48] <ktosiek> and BTW do I have to use bzr?
[12:00] <ktosiek> should charm's service start with the system (especially if it's basicaly stateless), or should it be started in config-changed?
[12:09] <ktosiek> oh, I see it should (at least after "start")
[14:19] <ktosiek> now, an architectural question: I want to make a Sentry charm that actually uses relation (the one in store now is pretty simple). Sentry is a server that aggregates errors from other services - the errors are provided by a dedicated (HTTP-based AFAIK) protocol, assigned to an app, and then grouped etc.
[14:19] <ktosiek> how should I provide the application name for a given relation?
[14:20] <ktosiek> should I make it one of relation's options, and make the consumer set it?
[17:03] <jrwren_> plz consider: https://github.com/juju/juju/pull/966
[17:23] <ktosiek> hmm, what should I do about internal app's secrets that users might or might not care about? Like Django's secret key?
[17:27] <ktosiek> Put them on a peer relation?
[20:19] <ktosiek> I have re-added a service after removing it, and now the machine is stuck in "agent-state: pending". What can I do about it? What should I look at?
[20:23] <ktosiek> hmm, and it looks like destroying that machine outside juju didn't help at all... I'll just redo that environment
[23:08] <lazyPower> ktosiek: Good questions - which service was stuck in agent state pending? As that should only happen during the provisioning of a machine
[23:08] <lazyPower> typically it means the machien never fully came online
[23:08] <lazyPower> ktosiek: looks like you've had a day full of juju
[23:09] <ktosiek> yeah, it looks pretty promising. But it would be much easier with more active people here ;-)
[23:10] <ktosiek> it was a service I'm trying to write, and I didn't know about "resolved" or looking at error in "status" when I was asking about that
[23:11] <ktosiek> turned out to be a combination of low RAM and slow HDD (and watching movies from said HDD)
[23:12] <ktosiek> lazyPower: do you use Juju in production?
[23:12] <lazyPower> ktosiek: i sure do
[23:13] <lazyPower> ktosiek: we're usually active mon-fri from ~ 4am EDT to ~ 8pm EDT
[23:13] <ktosiek> how do you store secrets? I mean things like Django's secret key, or SSL keys
[23:13] <lazyPower> we've got a mix of people from Europe and the US working on the project.
[23:13] <lazyPower> ktosiek: using the RAILS charm as an example, there is an ENVIRONMENT export config option
[23:13] <lazyPower> now, that relies on foreman
[23:14] <lazyPower> not sure how its used in the django charm - i dont have extensive hands on experience with it.
[23:14] <ktosiek> oh, so you have foreman next to juju
[23:14] <lazyPower> negative
[23:14] <lazyPower> foreman the ruby gem, puts the exports in teh upstart job it builds.
[23:14] <lazyPower> thats how heroku does it
[23:14] <lazyPower> which i know i know, so many projects with the name foreman its difficult to keep them straight.
[23:15] <lazyPower> however, you can use whatever config management framework you with with juju - so long as you write the underlying scripts in alignment with juju's event driven system, and they are idempotent.
[23:15] <lazyPower> ktosiek: re-using rails as an example, it wraps chef-solo to do the heavy lifting.
[23:15] <ktosiek> hmm, but how do you provide the secrets to new units?
[23:16] <lazyPower> ktosiek: and you asked about a solid ansible charm example - i suggest taking a look at our ElasticSearch charm - its written 100% in ansible
[23:16] <lazyPower> ktosiek: once you set it on the service, and you juju add-unit 'service' - they are distributed amongst the units.
[23:17] <lazyPower> eg: i set the SECRET_KEY_BASE environment variable for my rails app, and every new unit i spin up in that service cluster, automatically receives that SECRET_KEY_BASE
[23:18] <ktosiek> ok, so you set it in service's configuration. Then it's stored in juju state server?
[23:18] <lazyPower> basically
[23:18] <lazyPower> http://i.imgur.com/9dc2jpr.png  -- also you asked about me using juju in production - there's my prodstack
[23:19] <ktosiek> is there a way to impersonate a unit (to peek at some other unit's secrets)? (state server looks like a pretty lucrative attack target...)
[23:19] <lazyPower> just juju debug-hooks on that unit
[23:19] <lazyPower> then you can inspect the data being sent over the wire with relation-get
[23:19] <lazyPower> or config-get
[23:19] <lazyPower> ktosiek: https://juju.ubuntu.com/docs/authors-hook-debug.html
[23:20] <ktosiek> oh, I mean as another unit (like when someone breaks into one of the world-facing servers)
[23:20] <ktosiek> not as an admin
[23:20] <lazyPower> nope
[23:20] <lazyPower> you have to be within the context of juju to query juju information
[23:21] <ktosiek> cool ^_^
[23:21] <lazyPower> i mean its probably possible - if you work hard enough at it. I dont know what would be involved. thats a question better suited for #juju-dev when the core devs are around
[23:21] <lazyPower> much like trying to interrogate a chef-controlled unit, it can be done remotely but takes an unwholly amount of efffort
[23:22] <ktosiek> and about that screenshot... what are those heartbeat icons?
[23:22] <lazyPower> they signify a subordinate service
[23:22] <lazyPower> subordinates are deployed into an existing service machine - they occupy scope: container - so if its in an lxc container ona  node, it lives in that lxc container
[23:22] <lazyPower> if its on the host, it lives on the host
[23:23] <ktosiek> oh, ok. Haven't played with those yet, but I've read that part of manual
[23:23] <lazyPower> hey so you've read docs all day
[23:23] <lazyPower> how do you feel about our documentation - as you've viewed it today. was it helpful?
[23:23] <ktosiek> well...
[23:23] <lazyPower> honesty points count ;)
[23:25] <ktosiek> first thing - navigation is awful. I have to find current site in the menu before I can go to the next one
[23:25]  * lazyPower nods
[23:25] <lazyPower> good feedback - keep it comin
[23:26] <ktosiek> having next/prev links with titles at the bottom would be great :-)
[23:26] <lazyPower> Did anything leap out at you as overly complex in explanation? or anything you had to re-read to understand?
[23:27] <ktosiek> not really, but I had some expectations about the overall workflow already (I've seen a talk about Juju on pycon pl)
[23:28] <lazyPower> Awesome. Thanks for the feedback ktosiek
[23:29] <ktosiek> but there's a lot of info I either missed or hadn't found yet - like how do I destroy things, what's the difference between {remove,destroy}-* commands, any info on resolved --retry
[23:29] <lazyPower> ah, well - lets break it down
[23:30] <lazyPower> remove-relation simply un-relates services. It doesnt' do anything destructive (unless the charm is implicit about how it hands that removal of relation - which depends on the context of the relationship - most subordinates will remove application binaries on relation-removed)
[23:30] <ktosiek> and I'm still not sure what "Added charm "local:trusty/sentry-7" to the environment." means (I mean, "added"? not "replaced ...-6 with ...-7"?)
[23:30] <lazyPower> destroy-service will remove teh service from teh machine, but the machine will be left in your environment
[23:30] <lazyPower> destroy-machine will terminate the machine at the cloud host (or lxc supervisor)
[23:31] <lazyPower> juju resolved is a YOLO brand of "who cares what happened, just go green" - juju resolved --retry will attempt to re-run the failed hook - and will continue to error if the hook exits with a code greater than 0
[23:32] <lazyPower> when it says added, that just means that it was submit to the state server - as it handles pushing the new blob to the agent(s)
[23:33] <lazyPower> at one point and time we used git to do this delivery, but that was problematic when users would edit something on the machine and basically trip git up, so we went to all or nothing blob delivery
[23:33] <ktosiek> oh, ok
[23:34] <lazyPower> but would it be more useful to you to know that instead of 'added' - if we had an existing charm, to say "updated" "upgraded" or "replaced"?
[23:35] <ktosiek> actually, "submitted for redistribution" would be pretty nice (as it would also tell me something about what really happens :-))
[23:35] <lazyPower> i can see how that would be confusing to other users though since the charm store is the primary delivery mechanism for charms
[23:35] <lazyPower> they might think the just inadvertantly published a charm
[23:36] <ktosiek> hmm, that's a good point too
[23:36] <lazyPower> but its good feedback to have regardless (i'm capturing this input to bring up at the next standup i attend)
[23:36] <lazyPower> I just happened by IRC before I sat down to do some more charming of my own network of services :) I'm off on Monday halleluja
[23:37] <ktosiek> haha
[23:38] <ktosiek> thanks for all the info, I'd like to pick your brain a little more but I've got to go to sleep now (it's already past midnight for me)
[23:38] <lazyPower> i'm usually around, feel free to ping me direct if i'm listed as present.
[23:38] <lazyPower> good to meet you ktosiek
[23:38] <ktosiek> see you tomorrow then ;-)