[06:51] <blahdeblah> Re: "Juju on multiple public clouds" thread on the mailing list a couple of weeks back, what's the current recommendation if we need to communicate in an environment which is a roughly 50/50 split between two different providers (in my case openstack + bare metal maas)
[06:51] <blahdeblah> ?
[06:57] <stub> blahdeblah: Your choices are using 2 environments without relations between it, or bringing up a single environment and using manual provisioning for the other provider (where we have done this, it is OpenStack environment with the MaaS provisioned servers plugged in with the manual provider)
[06:58] <blahdeblah> stub: And if using the former, then work out some sort of manual replacement for relations that passes the required data?
[06:59] <stub> yeah, which is why the latter is usually the better options I think.
[07:00] <stub> With the latter you just have to handle the firewall stuff yourself.
[07:04] <blahdeblah> cool - thanks
=== frobware_ is now known as frobware
[09:00] <blahdeblah> lazypower: there seem to be 3 versions of the dns charm in jujucharms.com - any plans to make one of them official at some point?
[09:01] <blahdeblah> lazypower: also, what are your plans for autogeneration?
=== rcj` is now known as rcj
[13:59] <sg> I want to use apache http server for load balancing, can any one tell me how to configure apache server for loadbalancing using apche2 charm?
[14:13] <sg> I want to use apache http server for load balancing, can any one tell me how to configure apache server for loadbalancing using apche2 charm?
[14:19] <jamespage> gnuoy`, morning
[14:20] <gnuoy`> hi jamespage
[14:21] <jamespage> gnuoy`, thanks for the reviews and merging of my charm branches fro mover the weekend
[14:21] <gnuoy`> np, thanks for the mps!
[14:21] <jamespage> gnuoy`, :)
[17:28] <bdx> openstack-charmers, charmers, core, dev: hows it going everyone? Can someone give a little feedback on whether or not I am going about parsing the network-interfaces yaml/string/dict in a sane way? I feel like it could be done cleaner, but am having a trouble understanding how the input could be parsed in a cleaner fashion...Thanks!
[17:28] <bdx> heres the MR I'm referencing: https://code.launchpad.net/~jamesbeedy/charms/trusty/nova-compute/add-iface-support/+merge/274159
[17:40] <bdx> jamespage: ^^
[17:54] <jamespage> bdx, hey - I have you on my TODO for today re that merge proposal
[17:55] <jamespage> bdx, completely ack the requirement, but I need to fill you in on where that feature will come from
[17:55] <jamespage> (i.e. its not the charm)
[17:55] <jamespage> bdx, in meetings all day so it will be a few hours before i respond in full
[17:56] <bdx> jamespage: ok, no worries...I'll leave her rest then
[17:58] <jamespage> bdx, please - don't want you to waste cycles on this when its going to be resolved in a different way
[18:11] <bdx> jamespage: ok, thanks!
[18:22] <lazypower> blahdeblah, i'm not sure if my last messages sent. so i'll repeat:  It will get official once we have some actual tests around it that properly validate the charm. It presently requires the ability to store and ship with secrets in order to do that (infra keys for rt53) - and we dont have an answer for storing secrets. I've been toying with the idea of charming up vault and adding relations between CI and Vault to do secret storage/recovery/co
[18:22] <lazypower> nfiguration  but thats pie in the sky atm
[18:23] <lazypower> In terms of the bind provider, thats stable enough that we could probably omit that, depreciate the current namespace charm across the board, and move to a generation pattern. The charm is constructed in a way that would lend itself nicely to that.
[18:23] <lazypower> all the "providers" are plugin based, and fairly arbitrary
[21:40] <blahdeblah> lazypower: I didn't understand a single thing in that line about the bind provider. :-(
[21:40] <blr> Have an issue with juju deployer - if a deployment fails for any reason, before payloads are copied to /var/lib/juju/agents/unit-foo-0/files subsequent runs will not recopy payloads to the unit afaict
[21:40] <blahdeblah> lazypower: So is your version of the DNS charm the closest thing to official at present?
[21:48] <blr> ok possibly not juju deployer, but juju rather.
[21:59] <blr> nevermind, a problem with my understanding, rather than mojo/juju.
[22:48] <nottrobin> you know when you do "juju bootstrap" it asks for sudo password? what command is it actually trying to run? I'd like to use the sudoers file to allow a user to bootstrap juju but nothing else
[23:03] <rick_h__> nottrobin: it's starting the lxc that needs it. lxc-create?
[23:10] <nottrobin> rick_h__: hmm I got "sudo lxc-create" to work without password, but "juju bootstrap" still asks for password. Also when I look in auth.log I see "command not allowed ; .. COMMAND=/bin/bash -s". Which suggests I'd need to let that user run bash as sudo. Which is obviously too permissive. Maybe there's no solution.
[23:11] <rick_h__> nottrobin: what version of juju?
[23:11] <rick_h__> nottrobin: and lxc?
[23:12] <rick_h__> nottrobin: there was a point where that switched over to not need sudo perms but not sure when that flipped
[23:12] <nottrobin> rick_h__: juju: 1.22.6-trusty-amd64. lxc: 1.0.7
[23:12] <nottrobin> maybe if I was on utopic?
[23:12] <rick_h__> nottrobin: looking
[23:13] <rick_h__> nottrobin: https://github.com/juju/docs/blob/master/src/en/config-LXC.md#bootstrapping-and-destroying
[23:15] <nottrobin> rick_h__: Isn't that about "juju bootstrap" itself needing to be run with sudo, which was a long time ago. I don't need that. This is a completely clean install of juju-local on an up-to-date version of trusty.