[06:44] <jose> lazypower: hey, thanks for reviewing! I was checking and don't see a MP on the branch atm
[06:51] <jose> oh, there we go
[07:09] <lazypower> Yeah, I was still composing :)
[07:09] <lazypower> There's a few things I had to do to bring it up to spec for continued review, most of which was mentioned previously by Ben
[07:10] <lazypower> If you like i can include those in the MP for you to use as a baseline for the fixes
[07:12] <jose> lazypower: what are those? I can try and fix them now
[07:12] <jose> (already merged the branch)
[07:14] <lazypower> in config-changed you compare using =! instead of -n
[07:14] <lazypower> it should read if [ -n "$SSL" ]; then
[07:14] <jose> fixed that
[07:14] <jose> (fixed everything that's on the comment already)
[07:14] <lazypower> and your PWDIR variable is unbound
[07:14] <lazypower> ah then you should be up to snuff for the charm-run completing, just validate the intent is being performed :)
[07:15] <jose> lemme check then :)
[07:16] <lazypower> I'm going to head out and get some sleep. I'll be around closer to 9AM EST for a review update if its ready
[07:17] <jose> sure, I should be pushing in a minute :)
[09:59] <noodles775> rogpeppe: Hi there. RE you question last Friday, yes requests is a python library you'd need to install. Sorry, I didn't mention that in my paste. I saw you were able to repro the issue in the end though...(with the other persons steps). Great!
[10:00] <rogpeppe> noodles775: the issue should be fixed in trunk now
[10:00] <noodles775> woot :)
[10:29] <eagles0513875_> hey all :)
[10:29] <eagles0513875_> hey fwereade
[10:38] <eagles0513875_> fwereade: are you around?
[10:38] <fwereade> eagles0513875_, yeah, but meeting in a mo
[10:38] <eagles0513875_> fwereade: ok hit me up when you return then it can wait.
[10:39] <fwereade> eagles0513875_, better to ask
[10:39] <eagles0513875_> fwereade: just a quick question for using lxc containers or using juju on my vas i need to use manual provisioning right
[10:39] <fwereade> eagles0513875_, I might see and answer, so might someone else
[10:40] <fwereade> eagles0513875_, those are different things really -- you can experiment locally with lxc/kvm in the local provider, you can experiment on arbitrary machines with manual provisioning
[10:41] <eagles0513875_> ok fwereade but is it going to be a bit tricky though to ensure that even though I'm using manual provisioning that it won't spawn another instance?
[10:41] <eagles0513875_> or want to spawn another instance
[10:46] <fwereade> eagles0513875_, if you're using a manual environment juju never provisions any other instances itself
[10:46] <fwereade> eagles0513875_, you have to add-machine them manually
[10:46] <eagles0513875_> fwereade: ahh ok
[10:47] <eagles0513875_> so basically if i need to deploy another instance of lets say wordpress on a different vps i would need to add the machine but then would it ask me which machine I would like to put it on?
[10:48] <fwereade> eagles0513875_, if you care in detail about placement, you should probably specify it by hand with --to
[10:49] <fwereade> eagles0513875_, otherwise we'll put new units onto clean empty machines hat match the service/environment constraints
[10:49] <eagles0513875_> got it
[10:50] <eagles0513875_> fwereade: it should i think allow you to specify which machine you want to deploy it on even if you already have an instance on it
[10:59] <eagles0513875_> hey all is it possible to install juju on debian?
[11:02] <jamespage> marcoceppi, not having 'default' config is no longer acceptable?
[11:03] <fwereade> eagles0513875_, there's a --to param for deploy/add-unit
[11:03] <eagles0513875_> fwereade: ?
[11:03] <eagles0513875_> oh ok
[11:03] <fwereade> eagles0513875_, that's how you specify what machine to deploy a unit to
[11:03] <eagles0513875_> ahh ok
[11:04] <bloodearnest> heya all, finally figured out my local lxc issuesm in case anyones interested: https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1205086
[11:04] <eagles0513875_> fwereade: you can't really do that from the web interface can you
[11:04] <_mup_> Bug #1205086: lxc-net dnsmasq --strict-order breaks dns for lxc non-recursive nameserver <libvirt (Ubuntu):Expired> <lxc (Ubuntu):Expired> <https://launchpad.net/bugs/1205086>
[11:04] <eagles0513875_> fwereade: also is it possible to work with juju on debian
[11:04] <fwereade> eagles0513875_, yeah, I don't think that's exposed there
[11:04] <eagles0513875_> fwereade: which is a shame tbh
[11:04] <fwereade> eagles0513875_, work on machines in the gui is ongoing
[11:04] <eagles0513875_> everything you do on the command line imho should be exposed and usable on the web interface
[11:05] <fwereade> eagles0513875_, they're separate projects, they don't completely lockstep
[11:05] <eagles0513875_> btw fwereade  sorry if I'm interrupting your meeting
[11:05] <fwereade> eagles0513875_, but yeah I understand that position and generally support it ;)
[11:05] <eagles0513875_> fwereade: what would be interesting to see is if juju would become platform agnostic meaning will work on debian or ubuntu
[11:05] <fwereade> eagles0513875_, depends which bits tbh
[11:06] <fwereade> eagles0513875_, you can currently only deploy to ubuntu, but can deploy *from* from win/mac as well
[11:06] <fwereade> eagles0513875_, you never know, the `juju` binary might just work unmodified on debian
[11:11] <eagles0513875_> fwereade: what the person I'm talking to is interested in knowing is if we can deploy stuff to debian based machines.
[11:11] <eagles0513875_> it would be great if that could be done
[11:11] <eagles0513875_> tbh
[11:12] <fwereade> eagles0513875_, it can surely be done, but not without some work
[11:12] <eagles0513875_> fwereade: would be  more then willing to help out with that but i guess i should get familiar with the code first
[11:32] <eagles0513875> fwereade: what would be the best and first steps to get things goign with contributing plus working towards joining your team
[11:33] <fwereade> eagles0513875_, I would start by dpeloying an environment and fiddling with the charm
[12:29] <eagles0513875> fwereade: regarding the above as i just saw this would you recommend I do it with the local provider?
[12:30] <eagles0513875> fwereade: out of curiosity to get juju to work on an ubuntu private cloud
[12:30] <eagles0513875> ubuntu server would need to be setup as MAAS right
[12:36] <eagles0513875> fwereade: i think there is an issue with the documentation for the local provider
[12:36] <eagles0513875> getting an error when i try to bootstrap to the local provider about an ssh key
[12:37] <eagles0513875> and there in the documentation there is no mention of generating an ssh key there
[12:37] <eagles0513875> fwereade: https://juju.ubuntu.com/docs/config-LXC.html
[12:51] <fwereade> eagles0513875, https://juju.ubuntu.com/docs/ has it right at the top
[12:51] <fwereade> eagles0513875, but fwiw the trunk version generates one for you if it can't find one
[12:52] <eagles0513875> in terms of the juju site where would i file a suggestion
[12:52] <eagles0513875> getting started the way it is i wouldnt think to click it as it seems to be a section name for the menu
[12:53] <eagles0513875> i would put getting started as a first menu
[12:53] <eagles0513875> fwereade: brb
[13:17] <marcoceppi> jamespage: yes, if you want a "null" default just use a empty string `default: ""`
[13:17] <marcoceppi> jamespage: It's a W so it's not a critical Juju error, but rather it affects juju tools (ie: GUI, deployer, etc)
[13:17]  * marcoceppi should document what each level of error is for proof
[13:43] <jamespage> marcoceppi, that does not work
[13:43] <jamespage> "" != None with config-get --format=json
[13:47] <jamespage> marcoceppi, btw do you have a mysql charm for trusty yet? we're still using a butchered one in the openstack test lab
[14:05] <eagles0513875> fwereade: i find it a bit strange if one is using a local provider an SSH key is required
[14:06] <eagles0513875> fwereade: it make sense if you are testing on a remote server but in my case i am not
[14:06] <eagles0513875> i guess it should be presented as an option to the user when setting up the local provider
[14:28] <eagles0513875> hey guys is it possible if im running the local provider on my laptop to bypass the need for ssh keys
[14:36] <fwereade> eagles0513875, it's not really -- every difference between the local provider and the others is a source of potential nastiness, and adding a special case to allow people not to use ssh isn't worth it
[14:37] <fwereade> eagles0513875, is there a problem with just running ssh-keygen, or setting authorized-keys[-path] directly?
[14:37] <eagles0513875> fwereade: non no i just find it a bit useless if im running the local provider on the same laptop im on now
[14:37] <eagles0513875> here is the use case im thinking of
[14:38] <eagles0513875> fwereade: what im trying to get at is why not provide users the ability if they are using the local provider to use local host which doesntn require ssh
[14:38] <eagles0513875> and if they want to use the local provider obviously they would need ssh there
[14:38] <fwereade> eagles0513875, because you're not sshing tolocalhost? you're sshing to the containers
[14:39] <eagles0513875> ahhh ok
[14:39] <eagles0513875> that isnt that clear in the documentation
[14:39] <fwereade> eagles0513875, "you need a keypair" is pretty clear, I think
[14:39] <eagles0513875> sorry for the confusion
[14:39] <fwereade> eagles0513875, no worries :)
[14:39] <eagles0513875> fwereade: what isnt clear is what its used for. it just says generate a key pair
[14:40] <fwereade> eagles0513875, the reasons could be better explained, but IMO that's not really appropriate for step-0 introduction
[14:40] <eagles0513875> just have to figure out a way to keep my production private key seperate from the one im going to be generated
[14:40] <fwereade> eagles0513875, what's the concern there?
[14:41] <eagles0513875> with the id_rsa file be appended to?
[14:41] <fwereade> eagles0513875, I don't follow -- you have a private key set up already but haven't got the public key there?
[14:41] <eagles0513875> i think my mind is just out to confuse me today
[14:42] <fwereade> eagles0513875, is it that you have id_rsa in ~/.ssh, but not id_rsa.pub
[14:42] <fwereade> ?
[14:42] <eagles0513875> fwereade: correct
[14:42] <fwereade> eagles0513875, hmm, why would you do that?
[14:43] <eagles0513875> fwereade: i have my private key in there so when i ssh into the vps's i have in production i just have to give the key's password
[14:43] <fwereade> eagles0513875, sure, but where do you get the public key from when you're setting up one of those machines?
[14:43] <eagles0513875> i have the public key saved in a secure location so i then upload it to the server
[14:44] <fwereade> eagles0513875, it's the public key
[14:44] <fwereade> eagles0513875, you can hand it out willy-nilly
[14:44] <eagles0513875> fwereade: ok i have my mind in knots today lol
[14:44] <fwereade> eagles0513875, it's the private key you need to take care of ;p
[14:44] <eagles0513875> id_rsa the private key
[14:44] <fwereade> eagles0513875, yeah
[14:44] <eagles0513875> ok
[14:44] <eagles0513875> i have one of those already in there the public key is on the servers
[14:45] <eagles0513875> if i generate another one will it apend the new private key to the already existing id_rsa
[14:45] <fwereade> eagles0513875, no, I would recommend sshing into one of your servers and extracting your pubkey from authorized_keys
[14:46] <fwereade> eagles0513875, I don't think it's very meaningful to have a private key appended to another?
[14:48] <eagles0513875> fwereade: ok i have both my public and private key pair for my prodcution servers in a secure location
[14:48] <eagles0513875> let me see what happens
[14:48] <fwereade> eagles0513875, so you've got an id_rsa.pub right next to the matching id_rsa now? cool
[14:49] <eagles0513875> ya
[14:49] <fwereade> eagles0513875, note: first time you spin up a local provider will take a long time
[14:49] <eagles0513875> fwereade: whats not making much sense for me is that with out it and just the private key on my laptop ssh keys work fine im just trying to understand why i should have the .pub key there
[14:49] <eagles0513875> especially if i have two private keys in .ssh
[14:50] <fwereade> eagles0513875, I can't see a reason offhand *not* to keep your public key alongside your private one
[14:50] <eagles0513875> fwereade: i dunno why im worrying it gives you a default but also allows you to specify a different file name for the private key when generating
[14:50] <eagles0513875> good point
[14:51] <eagles0513875> also fwereade
[14:52] <eagles0513875> im an idiot lol
[14:52] <eagles0513875> i didnt notice the path when generating the key from within .juju is that it creates the pair in .juju
[14:52] <eagles0513875> and not in .ssh
[14:52] <fwereade> eagles0513875, oh, did we already release a version that creates a keypair?
[14:52] <eagles0513875> fwereade: seems like it
[14:53] <fwereade> eagles0513875, hmm, in that case we ought to be using it
[14:53] <eagles0513875> fwereade: its 1.16
[14:53]  * fwereade grumbles a bit
[14:53] <eagles0513875> fwereade: Installed: 1.16.5-0ubuntu1~ubuntu13.10.1~juju1
[14:53] <eagles0513875> thats whats showing up in my apt-cache policy
[14:53] <eagles0513875> fwereade: probably because im using the ppa
[14:53] <fwereade> eagles0513875, weird, I'm sure that was before we added that, let me take a look
[14:53] <eagles0513875> and installed from the ppa instead of directly from the repo
[14:53] <eagles0513875> anyway i gave it a name to differentiate between the two anyway if it did land in .ssh
[14:54] <fwereade> eagles0513875, just a mo, what did you do? didn't you just get the pubkey from your servers?
[14:55] <eagles0513875> fwereade: no no i was just worried of the key being overwritten when i generated the key for the juju local provider
[14:56] <fwereade> eagles0513875, sure, I'm just wondering why you'd need to generate a new one when you have one already
[14:56] <eagles0513875> good point just like keeping my testing and production stuff seperate
[14:58] <eagles0513875> fwereade: there is something missing in the documentation
[14:59] <eagles0513875> fwereade: do i need to add the pub key to the environments.yaml file for local cuz im getting this error ERROR error parsing environment "local": no public ssh keys found
[15:00] <fwereade> eagles0513875, please tell me exactly what you did
[15:00] <eagles0513875> sudo juju bootstrap
[15:00] <eagles0513875> it doesnt seem to pick up the keys
[15:00] <fwereade> no, what you did to your ssh setup
[15:00] <eagles0513875> fwereade: for juju
[15:02] <eagles0513875> fwereade: when generating the keypair should it end up in .juju if you dont use the default path to .ssh
[15:03] <fwereade> eagles0513875, AFAICT you should not be generating a keypair at all
[15:03] <eagles0513875> ok
[15:03] <fwereade> eagles0513875, you should have got your pubkey and saved it in ~/.ssh/id_rsa.pub
[15:03] <eagles0513875> ok
[15:09] <eagles0513875> fwereade: when one learns to untangle their complex mind setting up juju as the local provider is very very simple
[15:10] <lazypower> I managed to remove my lbox authentication from launchpad in haste, and I'm not positive where it caches its copy of the oauth token. Can someone point me where I need to look to clear its cached authorization?
[15:11] <fwereade> lazypower, I think it's ~/.lpad_oauth?
[15:11] <fwereade> eagles0513875, glad it worked out -- I hadn't considered the private-key-only situation
[15:11] <lazypower> that was it, thank you
[15:11] <fwereade> lazypower, yw
[15:12] <eagles0513875> fwereade: should i file something on launchpad
[15:12] <fwereade> eagles0513875, yes please, that would be very helpful
[15:12] <eagles0513875> fwereade: under juju core?
[15:12] <fwereade> eagles0513875, please
[15:12] <eagles0513875> ok fwereade also any bugs i can help or work on in terms of fixing?
[15:16] <eagles0513875> fwereade: should i run a test on what we just discussed
[15:16] <eagles0513875> and maybe its something i could be mentored in fixing
[15:16] <eagles0513875> fwereade: if you are interested in following this bug https://bugs.launchpad.net/juju-core/+bug/1270858
[15:17] <_mup_> Bug #1270858: possibility of .ssh not having a public key with the private key <juju-core:New> <https://launchpad.net/bugs/1270858>
[15:18] <fwereade> eagles0513875, so, I think the fix is to scan for files with/without .pub suffixes, ignore the ones that don't, and complain about the lack of a keypair (rather than just of a public key)
[15:18] <eagles0513875> fwereade: wouldnt it be good i test with out having the public key first
[15:18] <eagles0513875> to see if it works or does not work cuz right now the issue i filed seems rather vague and not useful
[15:19] <lazypower> fwereade, if lbox fails to propose due to a non existant [branch|repository] is this a sign of a larger problem?
[15:19] <fwereade> eagles0513875, well, the ideal bug report is generally along the lines of "what I did; what I expected; what actually happened"
[15:20] <eagles0513875> fwereade: ok will get more information when i relocate for my ccna class
[15:20] <fwereade> lazypower, hmm, nothing really springs to mind there
[15:20] <eagles0513875> anyway im out for now just deploying wordpress to try things out :)
[15:21] <fwereade> lazypower, is it saying the source or the target doesn't exist?
[15:21] <eagles0513875> fwereade: i have any idea for a really good charm setup. how can I see lets say what the apache charm installs for the web server as apache has about 4 different versions
[15:21] <lazypower> fwereade, http://paste.ubuntu.com/6786390/
[15:22] <lazypower> eagles0513875, that would be in the install hook of the charm you're looking at.
[15:22] <fwereade> lazypower, hmm, I'm not completely sure there -- marcoceppi, have you ever seen that?
[15:22] <fwereade> eagles0513875, lazypower: or more generally inferrable from a variety of hooks, and/or from the config file
[15:22] <eagles0513875> ok
[15:23] <lazypower> Fair enough :)
[15:23] <eagles0513875> fwereade: lazypower not to but in here but could it be the directory /charms/ was moved and the path you are looking for doesnt exist anymore
[15:23] <fwereade> eagles0513875, lazypower: several charms let you choose  different versions to run
[15:24] <lazypower> Its complaining about the remote. My charm is still here locally, but i believe its trying to push to the wrong remote.
[15:24] <eagles0513875> lazypower: check which branch you are on
[15:24] <fwereade> lazypower, hmm, should you be pushing to ~lazypower/charms/mediawiki/trunk perhaps?
[15:25] <lazypower> yeah, i've got an open MP that I was trying to get on codereview
[15:25] <fwereade> marcoceppi, do yu have an immediate answer for lazypower by any chance?
[15:25] <lazypower> thats why i include the parent branch in the config, and i think marco is afk for now.
[15:25] <lazypower> s/config/output listing on pastebin
[15:25] <eagles0513875> fwereade: i have some enhancement suggestions but will need to discuss those with you when i return
[15:27] <fwereade> lazypower, ah, hold on, surely you just need to push to that branch before you first lbox propose -- right?
[15:27] <lazypower> fwereade, https://code.launchpad.net/~lazypower/charms/precise/mediawiki/tests
[15:29] <lazypower> ah ok, now i've got additional legwork. My MP branch and local copy have diverged
[15:29] <fwereade> lazypower, ok, that's pretty unambiguous :)
[15:29] <lazypower> sarcasm? :)
[15:30] <lazypower> and i apologize for my ineptness, i'm still getting comfortable with the toolchain
[15:30] <fwereade> lazypower, no, not at all, the existence of your branch is 100% clear
[15:30] <fwereade> eagles0513875, if I was digging at anyone it was myself ;)
[15:31] <lazypower> haha
[15:31] <fwereade> lazypower, er^
[15:31] <lazypower> You get my seal of approval gustavo
[15:31] <fwereade> lazypower, I'm not gustavo, but I do observe that your error message doesn't include the "precise" I'd expect
[15:31] <niemeyer> lazypower: Heya
[15:32] <fwereade> lazypower, and I was just about to direct you towards the man himself :)
[15:32] <lazypower> O_O
[15:32] <niemeyer> lazypower: Thanks, I suppose :)
[15:32] <lazypower> mind=blown
[15:32] <lazypower> i ran across a post somewhere from you that referenced gustavo and made the mental note it was you... whooops!
[15:33] <lazypower> clearly i need to go back downstairs and not return until i've finished my first cup of coffee
[15:34] <lazypower> niemeyer, gustavo i presume?
[15:38]  * marcoceppi reads scroll back fwereade lazypower
[15:39] <marcoceppi> lazypower fwereade use the -for flag
[15:39] <marcoceppi> lazypower:  lbox propose -cr -for lp:charms/mediawiki
[15:39] <lazypower> marcoceppi, lbox propose -for lp:~blah blah
[15:39] <niemeyer> lazypower: Yeah :)
[15:39] <lazypower> ooohh
[15:40] <lazypower> and good morning
[15:40]  * marcoceppi still has reservations about using lbox for charm reviews, but those are on hold
[15:40] <fwereade> huh, I hadn't read that paste as a problem with the target
[15:41] <marcoceppi> lazypower: can you run bzr info as well?
[15:41] <jose> lazypower: hey, got to fix the postfix charm
[15:42] <marcoceppi> fwereade: I re-read it looks like it's trying to push to lp:~lazypower/charms/mediawiki instead, so maybe the -for flag isn't the issue
[15:42] <marcoceppi> maybe he doesn't have a push branch in bzr yet?
[15:43] <lazypower> jose, great news. Did you put it back in the rev queue? I'll fish it out after i've solved my lbox issue.
[15:43] <jose> lazypower: yeppers! marked it as new
[15:43] <lazypower> marcoceppi, http://paste.ubuntu.com/6786495/
[15:44] <marcoceppi> lazypower: okay, looks good to me. did the -for flag fix this? If not just do `bzr lp-propose lp:charms/mediawiki` and we'll look at lbox for charm reviews tomorrow
[15:45] <lazypower> marcoceppi, i'm working on getting my branch undiverged from whats open as the MP - one moment. Reading up on bzr
[15:46] <eagles0513875> fwereade: will ping you veyr soonn
[15:46] <eagles0513875> i have some nutty but useful ideas :)
[16:10] <eagles0513875> hey fwereade im back
[16:28] <teknico> hi all, got a problem with 1.17 and MAAS, br0 isn't being brought up by Juju when adding a new MAAS machine
[16:44] <marcoceppi> teknico: is the juju agent running on these new machines though?
[16:54] <teknico> marcoceppi, at the end I got this: https://pastebin.canonical.com/103229/
[16:57] <marcoceppi> teknico: is that from cloud-init log?
[17:00] <teknico> marcoceppi, nope, it's the end of the output from trying to start the container manually with "sudo lxc-start --name juju-machine-1-lxc-0"
[17:01] <teknico> in the log there was nothing more than the original error itself
[17:01] <teknico> which was: agent-state-info: '(error: error executing "lxc-start": command get_init_pid failed to receive response)'
[17:02] <teknico> which in turn was caused by br0 missing, at least according to bbcmicrocomputer :-)
[17:03] <marcoceppi> teknico: makes sense, can you paste the cloud-init log file?
[17:03] <marcoceppi> it should be done during lxc install tbh
[17:05] <teknico> marcoceppi, the whole of cloud-init.log? it's 45KB, it'll take a while pasting it :-)
[18:07] <dpb1> marcoceppi: I had a question on that swap charm before I proceed with fixing the review feedback.  You want me to document config options in the readme *and* in the config.yaml?  Seems like I would just be cut-and-pasting descriptions?  Or am I missing what I should be doing there?
[18:33] <marcoceppi> dpb1: config.yaml should have a brief description, readme should have a more detailed explaination as to what the config options does and provide example values
[18:37] <dpb1> marcoceppi: OK
[18:37] <dpb1> thx
[19:52] <dpb1> marcoceppi: in amulet, how do I make use of an existing deployer file?
[19:53] <mgz> dpb1: you can load a deployer config in your script
[19:53] <mgz> it's something like... sec
[19:53] <dpb1> mgz... thx.
[19:53]  * dpb1 waits
[19:54] <mgz> d = amulet.Deployment()
[19:54] <mgz> with open(path):
[19:55] <mgz>   script = yaml.safe_load(f.read) # as f above, whoops
[19:55] <mgz> d.load(script)
[19:55] <mgz> d.setup()
[19:55] <mgz> dpb1: hope that helps
[19:59] <dpb1> mgz: thx, trying now
[20:54] <jose> lazypower: hey, did you get to review the charm?
[20:57] <lazypower> jose: I did not, i was sidetracked upvoting on askubuntu and their rowdy crowd. Let me promote this in my queue and have a look
[20:58] <lazypower> apologies for not getting to it sooner
[20:58] <jose> sure :)
[20:58] <jose> no worries
[21:53] <lazypower> Great work on the revisions jose, I'm going to add my +1 to this charm and place it in another charmers rev queue
[21:54] <jose> awesome, thanks!
[21:59] <lazypower> hey thats good info to have handy mgz, that loads a deployment yaml, ergo a bundle, into amulet?
[22:05] <marcoceppi> lazypower: yeah, if you have a deployer file already in your tests dir, you can bypass all the d.add() stuff and just do d.load()
[22:05] <lazypower> amazingness
[22:05] <jose> hey marcoceppi, if you could also take a look at the postfix charm it'd be great
[22:05] <jose> there you pop up :P
[22:05] <lazypower> I'm writing up my +1 review right now, give me another 5 and i'll have it complete
[22:06] <jose> cool!
[22:06] <marcoceppi> jose: technically a day off today, I'll be in th queue still since lazypower is +1 reviewing it as a "jr charmer"
[22:06] <marcoceppi> so someone from ~charmers will cycle on to it sometime this week
[22:06] <jose> cool thanks!
[22:48] <lazypower> Does juju/maas use a special configuration for DHCP IP Assignment? I know that the local provider allows me to assign a network interface in the environments.yaml if i've opted into configuring my own bridge device.
[22:54] <marcoceppi> lazypower: maas has it's own DHCP server