=== stub` is now known as stub === mwhudson is now known as zz_mwhudson [04:04] marcoceppi_: http://tannerfilip.me/the-status-of-discourse/ === timrc is now known as timrc-afk === timrc-afk is now known as timrc === zz_mwhudson is now known as mwhudson === CyberJacob|Away is now known as CyberJacob === mwhudson is now known as zz_mwhudson === zz_mwhudson is now known as mwhudson === mwhudson is now known as zz_mwhudson === zz_mwhudson is now known as mwhudson === freeflying_away is now known as freeflying [09:05] mhall119: thanks for the info, looks like he has more of an issue with juju than the charm directly [09:05] their loss === bradm1 is now known as bradm === mwhudson is now known as zz_mwhudson === zz_mwhudson is now known as mwhudson === freeflying is now known as freeflying_away === mwhudson is now known as zz_mwhudson === JoseeAntonioR is now known as jose [12:03] Hey all. I'm using juju to deploy my stuff, but would like to add regular backups of my database. I have a script to do it, but I need to shut down the main application while the backup is running. Without adding that code to the database charm, what would be the best way of going about doing that? [12:04] Both charms are running on the same box === beuno_ is now known as beuno === _mup__ is now known as _mup_ === gary_poster|away is now known as gary_poster === timrc is now known as timrc-afk === timrc-afk is now known as timrc [14:05] kenn: you could write a subordinate charm to handle that task. Or write a non-subordinate charm, and deploy it to the same machine using relationships to bind the db details so its portable. === medberry is now known as med_ === freeflying_away is now known as freeflying === freeflying is now known as freeflying_away === freeflying_away is now known as freeflying === freeflying is now known as freeflying_away [15:07] hi, how can i configure juju so that it uses MAAS as a http proxy? === freeflying_away is now known as freeflying [15:33] help w/ the manual provider? bootstrap is giving me an ssh-looking error, though i can ssh just fine [15:33] http://paste.ubuntu.com/6879654/ [15:34] not clear from the logs what is ssh'ing to where [15:48] dannf: have you provisioned with the manual provider before? [15:50] nah [15:50] i worked around it by adding my ssh key to the authorized_key of the ubuntu user that bootstrap created [15:50] now its installing packges === freeflying is now known as freeflying_away [16:03] lazyPower: hm.. next issue. cp: cannot stat ��/var/lib/juju/storage/tools/releases/juju-1.17.0-trusty-amd64.tgz��: No such file or directory [16:03] lazyPower: do u know how can i set the maas-server as a http-proxy for the juju-bootstrap node? [16:03] (from cloud-init-output.log on bootstrap node) [16:03] tomixxx3: I do not sorry [16:03] lazyPower: k, np [16:03] dannf: try bootstrapping with --upload-tools? [16:04] trying [16:05] lazyPower: bingo [16:10] ERROR error detecting hardware characteristics: unrecognised architecture: aarch64 [16:10] well, wanted to see how far i could get - i guess that's it :) [16:13] dannf: yeah Manual provider is still a WIP [16:13] lazyPower: so is aarch64 [16:13] its coming along though, lots of new improvements === mattgriffin1 is now known as mattgriffin [20:22] hey guys , is this https://travis-ci.org/juju/juju-core the official CI? [20:44] Does anyone have experience using Juju with Vagrant for local development [20:44] ? [20:51] nicholaswyoung: i've used it on my mac, what would you like to know specifically? [20:52] lazyPower: That's exactly what I'll be doing. I'm looking to bootstrap a VM with Vagrant, then create a development environment with MongoDB, Ruby, etc on that VM using Juju - much like I would traditionally use Chef or Puppet. [20:52] Is this something Juju is capable of? From reading the docs, I assume so - but I want to make sure I'm using the tool correctly. [20:53] it is, but juju sits a layer above what you're doing. Juju is more about service orchestration - however it does provide you with raw hooks so you can in turn write your own configuration management in say, bash, salt, puppet, chef, ansible, compiled binaries, etc. [20:55] however there is nothing wrong with using juju as your configuration manager if you so choose to do that. [20:55] Gotcha. So for this use case, I'm better off using the traditional configuration management tools. Or at least that's what it sounds like. [20:56] I think I initially saw Juju as a more-powerful successor to those tools -- none of which I like very much. [20:56] again, theres nothing stopping you from charming your development environment [20:56] juju might be a better fit if you were starting several VMs, one or more per service [20:56] ^ [20:57] beat me to it sarnold [20:57] I will be deploying to Ubuntu in the next week or so, and if writing Charms (or downloading them now) will save time then, awesome. [20:58] Would it be reasonable to write charms (or download them), provision via Vagrant, use the charms -- then somehow wire that up to the cloud provider of choice? [20:58] nicholaswyoung: yep! that's the idea behind the vagrant box, is to provide a test bed for developers not running ubuntu full time. [20:58] I mean, eventually the DB, Rails stack, etc will all have their own VM. [20:59] I'm having trouble with the openstack-dashboard charm (the version of django from cloud-tools doesn't work with this version of horizon), anybody had success with this? [21:00] lazyPower: That makes sense. Could I (or should I) just drop Vagrant and use Juju to build virtual dev environments? [21:00] lazyPower: The less complexity and "magic" in my rig, the better. [21:00] nicholaswyoung: yes, that sounds like something juju can help with -- you could do your tests locally, with vagrant, one vm per service, and then turn around and deploy those services on ec2 or azure or hp [21:01] sarnold: But Vagrant is still valuable, correct? Because I'm not attached to it specifically either. If I could use straight-up Juju, so far, it seems to fit my style better. But if I still need Vagrant to provision, so be it. [21:03] lazyPower: I finally understood what you meant by 'full-time'. In other words, those running Ubuntu as the primary, host OS. Your answer makes much more sense in that context. I apologize for being slow. [21:04] nicholaswyoung: I could have been a bit more specific. Since i run juju as my host os, i have the afforded opportunity of using LXC containers which are great for development of charms [21:04] nicholaswyoung: juju just asks a "cloud provider" to provision machines; in your case, that would be vagrant during development, and aws or whatever during deployment [21:05] sarnold: Understood. Then, once a box is provisioned, Juju configures the defined services. [21:05] nicholaswyoung: right [21:05] sarnold: I finally have a clear picture of what Juju is, and how it will help. Thank you! [21:05] lazyPower: and thanks to you too. This is by far the most valuable IRC visit I've ever had. [21:06] nicholaswyoung: cool! have fun :) [21:06] sarnold: I'm certainly going to try!. [21:06] * lazyPower hat tips [21:06] lazyPower: well done :) good tag-team [21:06] * lazyPower hi5's [21:06] * sarnold ^5 [21:06] very nice, great success (devops borat) [21:06] haha [21:55] Is there a way to deploy a charm with multiple config yamls? Specifically I'd like to deploy a charm with all the default config options but override two of them at deploy time rather than after [22:21] timrc: yes [22:22] marcoceppi_, using --config with deploy doesn't seem to be working in my case :( [22:22] timrc: it needs a specific format [22:22] timrc: https://juju.ubuntu.com/docs/charms-config.html#config-deployment [23:26] marcoceppi_, Thanks for the help === freeflying_away is now known as freeflying