=== hatch__ is now known as hatch [00:36] hi, can someone tell me the purpose of admin-secret for openstack config? [00:37] * davechen1y looks in the source [00:37] hmm, it's not openstack specific [00:37] * davechen1y looks in the base config [00:38] ok, its the admin password for your environment [00:38] you should leave it unset [00:39] ok [00:39] when i did generate-config, it automatically inserted a default [00:40] it put an admin-secret and control-bucket. i am using 12.04 lts for my host os, and installed juju with https://juju.ubuntu.com/install/ instructions for ubuntu [00:43] mischief61507: oh sorry [00:43] yes [00:43] it's been so long [00:44] admin-secret is a passphrase for your environment [00:44] it should be private [00:44] and unique [00:44] control bucket is the name of the storage bucket [00:44] which will hold stuff about your environment [00:44] if you have two ec2 environments, say, then the control bucket must be unique [00:44] otherwise shit will get crazy [00:44] is admin-secret something i have to set on the openstack side or is that used to bootstrap it [00:45] mischief61507: it is the root password to your juju environment [00:46] it applies for all juju environments [00:46] it's not openstack specific [00:46] so has no relation to any other openstack credentials [00:53] looks like i forgot to set up swift on my openstack haha === thumper-gym is now known as thumper [01:55] mischief: yea, you need some kind of object storage to put juju stuff in [01:55] specifically the tools and charms tarballs === vladk|offline is now known as vladk === vladk is now known as vladk|offline [03:00] marcoceppi: hi === timrc is now known as timrc-afk [03:17] is there any firewall between unites in juju [03:23] themonk: depends on the provider [03:24] its lxc container on my local machine [03:25] davechen1y: its lxc container on my local machine [03:27] themonk: what is your question [03:28] themonk: are you asking why you cannot connect to lxc machines remotely ? [03:30] davechen1y: is there any firewall between unites in juju? that means that if /0 has a server running with a open port XXXX will /0 can make request it? is there any sort of firewall? [03:31] themonk: yes and no [03:31] in this case, no [03:31] that means no firewall ryt [03:32] davechen1y: i can't give you a clearer answer [03:32] can you explain more abou the problem you have [03:32] ok i will [03:36] i have 2 charm, one of them is server, it take request from other charm, problem is server charm is not getting any request, before i file a bug I wanted to make sure that juju is not blocking it. [03:40] mattyw: ping, this current user branch thing landing. What's this mean for real user authentication? [03:40] mattyw: I'm worried about the GUI falling a chunk behind and not being usable [03:40] themonk: if you are using the local provider there will most likely _not_ be a firewall between units [03:40] however your charms may be using the wrong address to talk to each other [03:41] davechen1y: thanks :) [03:42] davechen1y: is ec2 has any firewalls between units? [03:42] themonk: generally no [03:43] davechen1y: thanks a lot man :) much appreciated [03:43] np [03:48] HA! [03:48] func uploadFakeTools(stor storage.Storage) error { versions := []version.Binary{version.Current} toolsVersion := version.Current [03:48] ^ ja'cuse [03:48] version.Current is always the arch of the local machine !!! [03:50] davechen1y: yes... yes it is [03:50] booo [03:50] mattyw: all good thanks [03:51] mattyw: seems like the network hates you for the moment [03:51] rick_h_, we're very much off and on === vladk|offline is now known as vladk === vladk is now known as vladk|offline === vladk|offline is now known as vladk === vladk is now known as vladk|offline === CyberJacob|Away is now known as CyberJacob === CyberJacob is now known as CyberJacob|Away === vladk|offline is now known as vladk === vladk is now known as vladk|offline === psivaa_ is now known as psivaa === vladk|offline is now known as vladk === timrc-afk is now known as timrc === lazyPower-travel is now known as lazypower-conf [13:00] rogpeppe, natefinch : can either you glance at wallyworld's MP to fix tests that prevent the release of 1.18. https://code.launchpad.net/~wallyworld/juju-core/fix-tools-tests-1.18/+merge/214159 [13:00] sinzui: sadly i have to rework them [13:00] because [13:01] the current code disallows upload-tools for released juju versions [13:01] which is sensible [13:01] but apparently people depend on it [13:02] so i need to reinstate the dumb behaviour, but there's a several tests which fail (existing tests) [13:02] so at some point certain code paths were run [13:03] it messy :-( === tvan-afk is now known as tvansteenburgh [13:14] wallyworld, Are you intimating that 1.18.0 will be releasable next week? [13:14] sinzui: i hope to have a fix proposed soon, within an hour maybe [13:15] Well I don't think the version blocks cmars and jhobbs. I can merge those now. [13:15] wallyworld, If something looks grim. I can release everything as 1.17.8...a beta for 1.18.0 that is just a rename next week [13:16] sinzui: ok, im hopeful so give me a little more time === roadmr is now known as roadmr_afk === Ursinha-afk is now known as Ursinha [15:03] marcoceppi: niedbalski is working on a but on the nrpe charm that may be tied to the 'old' shell version of the helpers [15:04] marcoceppi: though I have doubt as it seems to be the same code in the mysql charm & the behavior only happen with maas === Ursinha is now known as Ursinha-afk === Ursinha-afk is now known as Ursinha === roadmr_afk is now known as roadmr === hatch__ is now known as hatch [15:50] https://juju.ubuntu.com/docs/howto-privatecloud.html [15:50] fresh new docs folks! [15:55] nice [16:18] marcoceppi I tried to open a bug for discourse charm but I got this error from launchpad: (Error ID: OOPS-48eaf11d28efcb274bb49c42de5f2ae2) [16:18] basically is impossible to find the discourse charm submitting the big [16:18] bug* === vladk is now known as vladk|offline === roadmr is now known as roadmr_afk === roadmr_afk is now known as roadmr [17:09] ~2 hours until our Charm School on Juju plugins [17:09] marcoceppi, ^^ [17:11] overm1nd: the charm is on gh [17:12] overm1nd: https://github.com/marcoceppi/discourse-charm [17:26] is there a property in the local provider to force juju to use an explicit ssh user? [17:28] lemao: is that local or manual? [17:29] local [17:30] lemao: may I ask why? because afaik the local provider creates LXC for each machine [17:30] jose: This is a Vagrant JujuBox with a vagrant user by default. It seems that juju show-log is trying to ssh into current box with user ubuntu [17:30] ah [17:30] gotcha [17:30] jose: and jujubox provisions the authorized_keys in the vagrant user [17:30] lemme try and see if I get something [17:31] jose: I can work around by copying the authorized_keys to the ubuntu user, but it would be nice to have it working smoothly [17:33] I don't seem to find something useful [17:42] lemao, that seems to be a bug in the box to me [17:42] we should make it like autogen keys or something [17:55] jcastro: the vagrant user does have the key generated [17:56] jcastro: but juju show-log is trying to ssh into ubuntu@10.0.3.1 instead of vagrant@10.0.3.1 [17:56] * jcastro nods [17:57] jcastro: my first thought was that there may be a property I can add to the local env file to change this default [18:11] jcastro, jose: https://bugs.launchpad.net/juju-core/+bug/1202682 [18:12] <_mup_> Bug #1202682: debug-log doesn't work with lxc provider

[18:12] yeah that one is in progress [18:12] I just pinged them about it yesterday [18:12] lemao, tail the log in ~.juju/local/logs is the workaround there [18:13] jcastro: thanks. [18:14] all-machines.log is quite handy [18:14] jcastro: humm, I don't see all-machines.log there. [18:14] jcastro: 1.16.6-precise-amd64 [18:15] jcastro: only machine-0.log [18:15] oh, after you deploy something [18:15] right now you just have the one machine [18:18] jcastro: I see. I do have machine-1 with juju-gui, but that came with the JujuBox afaik. Ok, not important. Thanks. [18:19] I do have a more general question, though, if I may ask, that is bugging me for a couple of days. [18:21] I would like to support RDS machines. It seems like an alternative machine to the amazon provider. How does one support that in juju as it seems that the amazon always creates EC2 instances. === CyberJacob|Away is now known as CyberJacob [18:22] After searching around, I realized that subordinate services may be the answer here. However, what about identity of the RDS instance that may be shared among multiple services across different machines? [18:23] yeah we haven't really done anything wrt. RDS [18:23] like, it'd be nice to just connect a mediawiki charm to an RDS instance instead of EC2/Mysql [18:24] ~30 minutes until our charm school on Juju Plugins! ^^ marcoceppi [18:25] jcastro: right. It seems that each provider has a single 'type' of machine. In the amazon's provider, that is an EC2 instance. It would be nice if I could specify a machine type that is required (constraint?) and that would mean the charm is provider specific. [18:26] jcastro: and the amazon provider would specify the default machine type and additional machines such as RDS [18:27] \o/ [18:27] jcastro: right now, it seems I can fake this with a subordinate service but to share instances I would have to assign a unique id/label to connect to the same RDS instance [18:28] that would be cool if it worked [18:29] jcastro: is my thinking correct or are there ways/approaches I am not aware off? [18:29] lemao, I think provider-specific options in a charm are fine [18:30] lemao, I think so; though I'd confirm on the list as well [18:30] though it would be cool to have provider-specific subordinates for things [18:30] aws-s3-backup, etc. === BradCrittenden is now known as bac [18:35] jcastro: is it possible to override the machine creation logic when a charm is deployed? I.e. let my charm take over the machine creation to manually instantiate an RDS instance. [18:37] lemao, I need to bail for a bit to run this charm school [18:38] jcastro: ok. Thanks for the help [18:52] Ok we're going to be doing a videocast in about 10 minutes on http://ubuntuonair.com [18:52] the Topic is Juju Plugins! [18:52] we'll be taking and answering questions from this channel [19:03] o/ === roadmr is now known as roadmr_afk [19:15] questions? [19:18] any plans on the juju test plugin supporting all of the manual provider ??? ;) [19:19] I use juju test, it's quite useful. I've only used it with EC2 providers. After watching the presentation, i don't mind taking a crack at some of the bugs i've found with the plugin. Perhaps making some MPs to it [19:20] ;) [19:20] ;) to the trolling comment [19:20] sfeole, well, you're being ignored atm so... [19:20] cool [19:20] ;) [19:23] is there a juju/charm hangout today? [19:24] axisys: http://ubuntuonair.com/ [19:25] do I need to connect to the irc on the web to see the hangout? it is a black screen for me [19:25] sfeole: ^ [19:25] axisys: try reloading the page? [19:25] I see it now [19:25] kewl [19:25] thanks [19:33] thanks guys! [19:33] thanka lot [19:33] fun stuff [19:35] hi all, is it possible to read environment properties from a charm? E.g. the amazon has the access/private keys that I would like to use in a charm. [19:37] lemao: you should be able to open the environments.yaml file and find that info [19:38] lemao: not from a charm not [19:38] no* [19:39] jose: yeah, that would be an option. It has a couple of drawbacks though: every charm would have to perform the same exact work and it is a bit error prone if I don't select the current environment right. [19:40] marcoceppi, jose: I am trying to create an RDS subordinate service hence the question. It would be a bummer if I have to reenter the keys in the charm configuration [19:40] lemao: there's already an RDS charm, and it is a bummer [19:40] marcoceppi: this one? https://code.launchpad.net/~hazmat/charms/precise/aws-rds/trunk [19:41] lemao: yeah, that one [19:43] marcoceppi: it is using 'awsjuju.services.rds'. Do you know what is that and how it is installed? [19:43] lemao: no idea [19:43] lemao, its a package that gets installed [19:43] hazmat: $CHARM_DIR/bin/pip install awsjuju I see [19:43] lemao, most of the logic for my aws charms is in a python package that gets bootstrapped in install [19:43] hazmat: what about the keys? [19:44] lemao, keys? [19:44] hazmat: access/private aws keys [19:44] ec2 keys [19:44] lemao, go into the service config [19:44] lemao, i don't consider my aws charms production grade fwiw [19:44] hazmat: sorry for the obvious question, I am getting up to speed with juju [19:45] hazmat: I have the impression that juju-core needs a few additional changes to make this a bit smoother [19:45] lemao, https://github.com/kapilt/awsjuju is the backend logic, unit tests, etc for aws rds, aws elb, tagging, etc [19:45] lemao, you mean aws access key management ? [19:46] lemao, in particular rds implementation is here https://github.com/kapilt/awsjuju/blob/master/awsjuju/services/rds.py [19:46] hazmat: something like 'env-get access-key' [19:46] lemao, that would be rather a bad idea think.. [19:47] hazmat: how so? [19:47] lemao, you want to pass your credentials to third-party code ? [19:47] hazmat: yes, that is indeed a problem is you don't trust the charms. [19:47] lemao, i recommend iam for all such cases [19:47] hazmat: what would be the ideal solution? [19:48] hazmat: expand the amazon provider? [19:48] lemao, create an iam for each third-party charms that give them the exact access they need.. or an iam broker charm that can do the same.. [19:49] lemao, i tried to include iam policies needed for each of my aws charms.. but doesn't look like the rds charm got one.. here's the elb charm iam policy for comparison http://bazaar.launchpad.net/~hazmat/charms/precise/aws-elb/trunk/view/head:/elb-policy.json [19:49] hazmat: does RDS has support for IAM roles? [19:50] hazmat: oh, I see. [19:50] lemao, this isn't quite iam roles.. this is create an iam identity with perms and hand those to the charm via service config [19:50] hazmat: you create a individual user for each charm with their own access keys. [19:50] lemao, yeah [19:54] hazmat: I don't see subordinate: true there in the aws-rds. Won't that create a new machine for this service when deployed? [19:55] lemao, use --to=0 [19:56] hazmat: I see. That smells like a unavoidable hack :-) [19:56] lemao, you can place workloads wherever you want [19:56] lemao, you don't have to create new machines for them [19:56] lemao, if you want it to run isolated do --to=lxc:0 [19:57] lemao, using a subordinate would mean distributing access keys and creating extra units.. its a proxy charm.. only needs 1 unit. [19:58] lemao, yes there could be some simple notion of doing that for you based on metadata, but it amounts to the same, you need the charm to run somewhere. [19:59] and yes.. all the aws charms support running multiple units for ha .. they use dynamodb for coordination [20:00] it has happen with me a few times but some services fail to start they can't be deleted. I wonder if there is a flag like a force option [20:00] hazmat: yes, makes sense. the rds service is a proxy service that interfaces with an external machine and it has to run somewhere in the current environment. Machine-0 is the most obvious place or so it seems === roadmr_afk is now known as roadmr [20:02] hazmat: how are you handling things like smtp service (e.g. exim4)? [20:02] hazmat: is that a plain service with subordinate: true? [20:03] lemao, smtp -> non subordinate charm.. ala postfix.. connect all the things that need it up. [20:04] saas email service might be better for aws though [20:04] marcoceppi if you're ever looking for a broken charm again I wrote one which was designed to fail http://fromanegg.com/post/67488243238/a-juju-charm-designed-to-fail [20:04] hazmat: yes, but SES has some mime restrictions that don't work for me [20:04] lemao, mailgun.. sendgrid.. etc [20:04] hatch: awesome, thanks! [20:04] np, we use it in the GUI to test the failure paths :) [20:04] lemao, postfix/exim are going to run afoul of the spam blocks aws ip ranges [20:04] ^on [20:05] hazmat: I see so if I want to use postfix I am basically creating a dedicated machine for it and have all the nodes connect to it [20:05] s/connect/relate/ [20:06] lemao, doesn't need to be dedicated.. you can place multiple workloads together if their compatible on the same machine [20:06] lemao, hence the --to syntax on deploy or add-unit [20:06] hazmat: using --to I guess? [20:06] lemao, yeah.. juju deploy --help [20:07] hazmat: which makes the order of deployment important [20:07] lemao, not really [20:07] lemao, which service goes onto the machine first doesn't matter.. the services communicate config via relations [20:08] and a good charm doesn't assuming ordering to relation creation [20:08] hazmat: humm, but if I want to have postfix running on the same machine as ServiceA I will need to hard code a machine # [20:08] pretty much none of them assume ordering [20:10] lemao, that's unfortunate ... there's a feature request out there for --to=service for co-located services.. i've added a --to=service/a syntax in some tools i've built ontop of juju .. but thats not built-in.. http://pythonhosted.org/juju-deployer/config.html#placement [20:10] its a simple dsl for capturing env topologies/deployments into a yaml file. [20:12] hazmat: yes, that would be nice. is this topology/deployment dsl being considered to be included in juju-core? It would be nice to be able to describe a set of machines and then assign services to them [20:13] hazmat: (actually remember going through juju-deployer) [20:14] lemao, eventually.. lots of other tools build on deployer for bundle/dsl support.. [20:15] hazmat: finally, do you have apps in production using juju on AWS? [20:18] hazmat: actually juju-gui could support first class machines along side services. Place a service in an empty canvas you get a machine wrapping a service. Place a machine you get just an empty machine. Place a service on an existing machine and then add the service there. This visual model would be easily translated to your dsl [20:25] lemao, personally no.. i do on digital ocean using https://github.com/kapilt/juju-digitalocean [20:26] lemao, gui is currently working on a machine view of the environment for placement as well [20:27] lemao, the pricing model on ec2 is a bit much for me to do personal projects there minus reserved instances.. i'm looking forward to gce getting ubuntu images.. cause their pricing is pretty nice basically baking usage discounts without the reserved instance pricing up front cost. [20:30] is juju supposed to support deploying (for example) a trusty lxc to a precise bootstrap node with --to lxc:0 cs:trusty/ubuntu? Seems it always ends up as a precise container. [20:32] dpb1`, it definitely should be a trusty container [20:33] hazmat: :( [20:33] dpb1`, file a bug pls [20:33] hazmat: never used digital ocean. Have been using AWS for 5+ years. [20:33] hazmat: on it [20:33] lemao, fair enough. aws has lots going for it. [20:34] lemao, i maintain a few prod non juju aws envs.. their feature iteration is pretty impressive [20:35] hazmat: yes, not the cheapest but they have been improving on it non-stop [20:36] hazmat: looking at kapilt/awsjuju I was wondering: it would be quite nice if it was possible to create provides in the same way one creates charms (i.e. hooks, any language, etc) [20:36] hazmat: s/provides/providers/ [20:37] hazmat: set of key events (install, create-unit, etc, etc) [20:37] lemao, yup.. its been discussed.. smoser is a fan.. the shell-script provider.. [20:38] lemao, its sort of possible now.. that's basically how the juju digital ocean provider works.. it layers on top of the manual provider.. to do client side provisioning. [20:38] hazmat: it may be a temporary win until there is a stable provider that everyone can reuse and covers all features [20:38] hazmat: https://bugs.launchpad.net/juju-core/+bug/1302820 [20:38] <_mup_> Bug #1302820: juju deploy --to lxc:0 cs:trusty/ubuntu creates precise container

[20:38] lemao, the issue with doing it server side is thats its problematic wrt to software install and upgrades across architectures.. [20:39] lemao, yup.. that's exactly the goal i have with making client-side providers.. also works in the case where providers don't nesc offer all the features nesc for a core implementation (userdata etc). [20:40] hazmat: nice to hear that these things are being worked on, or discussed. Was looking for some docs/info on juju directions... [20:41] lemao, just filed bug 1302825 for it [20:41] <_mup_> Bug #1302825: juju roadmap in the docs [20:42] hazmat: thanks! [20:43] hazmat: I find that juju provides a devops in-the-large that is much more interesting. Working with ansible, for instance, I end up slowly creating a framework on top of ansible to be able to quickly creating stacks etc. Juju provides that framewokr for me out of the box [21:00] ls [21:00] ls [21:00] l [21:18] hazmat: is there a repo for this shell-script provide by smoser? I could not find in his launchpad account. [21:22] lemao, that's funny.. i'm using ansible and juju together atm.. [21:23] hazmat: that makes sense to me ... juju in the large and ansible in the small [21:23] lemao, the shell script provider doesn't exist.. an extant client side provisioning plugin is the juju digital ocean provider. [21:23] hazmat: I see. I will look at that then [21:23] lemao, well ansible in charms is supported as well. there's a couple of helpers we have to make it fairly seamless as an experience. [21:23] ie. single yaml file charm, with the rest just as generic support [21:24] hazmat: I don't particularly care about ansible it just seemed a better option (simpler) than chef/puppet. But at the end of the day a charm may need to perform a few idempotent operations [21:24] lemao, juju has a built-in ansible light.. sort of thing.. juju run .. let's you run stuff/shell on selective sets of machine [21:24] hazmat: interesting [21:24] lemao, yup.. also easy to review/audit [21:25] lemao, actually ansible light. is not accurate.. better is parallel ssh [21:30] hazmat: I am actually evaluating juju for our company. So I appreciate the information and feedback. I will be getting more hands on in the next couple of weeks and see how that goes. [21:34] when we have issues with particular charms ( gitlab in this case ) [21:34] should I be reporting the bugs ? [21:42] ghartmann: yes! [21:43] how is the best way ? [21:43] ghartmann: on launchpad! [21:43] btw, I am really happy with juju ! great work [21:44] ghartmann: https://bugs.launchpad.net/charms/+source/gitlab/+filebug [21:44] ghartmann: thanks! I know someone was working on fixing up the gitlab charm, I think it's lazypower-conf [21:45] great, if we have a bugfix how can we push the code in for review ? [21:46] ghartmann: so, you'll want to run `charm get gitlab` if you haven't already, to branch the code. Then apply your fix and push to lp:~YOURLPUSERNAME/charms/precise/gitlab/trunk [21:46] then run `bzr lp-propose lp:charms/gitlab` that will start the merge proposal process [21:46] after you complete that it'll show up in our review-queue! [21:47] gitlabs.. very cool [21:48] that sounds great, do you have the instructions on a webpage ? [21:49] ghartmann: yes, for the most part, https://juju.ubuntu.com/docs/authors-charm-store.html#submitting_fix [21:52] thanks, I will set it up now [22:21] found the issue that I was facing .. and got to a new one related with ruby [22:22] bundle install modernizer seems to be removed