=== CyberJacob is now known as zz_CyberJacob [00:46] noodles775: I couldn't say, sorry. I'm not sure who prioritises things like that... maybe check with sinzui? [00:49] axw: yep, will do. Thanks. [00:49] noodles775: probably also a good idea to create a bug in launchpad.net/juju-core, so it's on his radar [00:52] axw: ack, will do too :) [00:55] jlondon: how are you creating the lxc containers? [00:55] * thumper wanders off for a bit, bbs [00:55] thumper: Just via juju+maas. Juju is spinning up a physical host in maas and then attempting to create them inside that host. [00:57] and then the containers just get stuck in the 'pending' state with no network information that I could see. [01:04] jlondon: hmm... [01:04] jlondon: using juju to create the containers? or ssh'ing in and doing it by hand? [01:05] thumper: juju. I'm trying to avoid doing anything on the server manually :) [01:05] hmm... [01:06] Should I try kvm instead? [01:08] that probably wouldn't help [01:08] k [01:09] can you ssh into the machine and look at /var/lib/juju/containers//lxc.conf? [01:10] look for network config in there [01:11] thumper: K. One second I'm spinning them back up with fresh installs. [01:15] thumper: huh, okay, it appears to be setting the network to juju-br0 in the container level config file. [01:16] jlondon: ok, it is something else then [01:16] I did see a bug fix land recently that disabled the networking worker because it was screwing up lxc containers [01:16] jlondon: which version of juju? [01:18] thumper: stable: 1.20.14 [01:20] seeing this in the console.log file for one of the containers (over and over): lxc_commands - commands.c:lxc_cmd_handler:888 - peer has disconnected [01:30] looking at the logs further for one, it doesn't appear to be getting an IP at all. [01:31] dhcp is running on the network for sure though (maas provided) [01:35] hmm... not sure sorry [01:37] thumper: No worries. I'll keep playing around with it. === jlondon_ is now known as jlondon === kadams54 is now known as kadams54-away === zz_CyberJacob is now known as CyberJacob === JoseeAntonioR is now known as jose === anthonyf is now known as Guest44978 === CyberJacob is now known as zz_CyberJacob [10:10] seal: o/ [10:11] lazyPower: o/ [10:12] how goes the exploring? [10:12] great work on http://chuckbutler.github.io/flannel-docker-charm/user/getting-started.html [10:12] Thanks :) [10:13] we've actually vendored a bundle to make getting started quickly very easy with our charms. Let me fish up that link fo ryou [10:13] great [10:13] https://github.com/mbruzek/docker-bundle [10:15] best part is, its got a suite of amulet tests with it so if you're interested in how we're running the deployments and validating you can inspect the test(s) in the test directory [10:15] also, the charms + bundle are up for review in the queue so you should see them landing in the store soon'ish [10:18] I need to look into bundles more. I haven't has much joy getting it to work on my machine [10:19] Will be looking out for the bundles release [10:33] seal: oh? anything i can help with on the bundles? [10:33] hi [10:33] o/ mwak [10:33] how are you lazyPower [10:33] ? [10:34] Good, preparing for talks over the next few days [10:34] how about yourself mwak? [10:34] fosdem? [10:34] ping jcastro [10:35] mwak: FLOSSCommunity Metrics, FOSDEM, and ConfigurationManagementCamp [10:35] great! [10:36] lazyPower: yes please! for example I can deploy theis bundle via gui https://demo.jujucharms.com/bundle/web-infrastructure-in-a-box-10/?text=bundles [10:36] * lazyPower nods [10:36] i'm familiar with this bundle [10:37] I didn't get time to fix the haddop charm for arm yet, should try to get some time to investigate :/ [10:37] you can also fetch it and deploy from the CLI with juju quicksstart [10:37] however, I get some errors where I attempt to deploy locally. If you have a moment I can clean up my environment and post the exact error [10:37] sure thing seal [10:37] lazyPower: you personally will be at FOSDEM? [10:38] mwak: indeed. I'm running a talk track there [10:38] great! [10:38] topic? [10:38] https://fosdem.org/2015/schedule/event/juju_orchestration/ [10:39] crap i forgot to get in touch with them and let them know i'd be taking marco's place.... so its still got his name on there [10:39] SURPRISE, its lazy :D [11:02] lazyPower: is there a trick to getting the rails charm to work? I've tried a few revs, and they all fail to install with an error about installing the json gem [11:03] axw: i'm working on refactoring that to work with rbenv vs rvm (which is consistently the reason its breaking) [11:03] i have some WIP if ou want to pick up the torch on it and help :) [11:03] i'm nearly complete, refactoring out the rvm localized commands has been the lions share of the work [11:04] lazyPower: I don't think I'd be of much help, I don't know ruby [11:04] axw: however, i am aware of the latest breakage, and unfortunatley haven't had a large swath of time to dedicate to refactoring and fixing :( really sorry to report that. [11:04] I can test if it's usable tho [11:04] lazyPower: okey dokey [11:05] well its close, but not bullet proof yet, i think there are still some cases with localized ruby versions that need addressing [11:05] meaning, your app says "i want ruby 2.2.1" [11:05] and i'm installing 2.0.0 as system ruby [11:05] but other than that, it was working well iirc [11:05] let me get you a link 1 sec [11:06] https://github.com/chuckbutler/rails-charm/tree/rbenv_migration [11:06] lazyPower: thanks [11:06] ymmv - i haven't tested it in ~ a month - so the ground may have shifted again under whats there [11:06] lmk if you get success/failure with that and i'll go from there. issues welcome :) [11:07] lazyPower: will do [11:17] lazyPower: gtg, but it still fails. http://paste.ubuntu.com/9934923/ [11:17] lazyPower: I'm using https://github.com/pavelpachkovskij/sample-rails [11:19] axw: 10-4, i'll circle back as quickly as i can, it may be a little over a week - depending on time with me being booked for conferences this week/next week [11:19] if you need it for a priority deployment i can try and escalate this [11:20] lazyPower: it's cool. was hoping to use it to demo a new storage feature, but we can find something else [11:20] enjoy the conference [11:21] thanks axw, sorry about the inconvenience [11:21] no worries === kadams54-away is now known as kadams54 [14:43] A question: on the juju master, able to do "sudo sysctl -w fs.file-max=". However, on container created for charm, this same command fails with the message: sysctl: permission denied on key 'fs.file-max' [14:43] limitation? workaround? === kadams54 is now known as kadams54-away [14:52] johnny_shieh_: LXC containers created by/with juju have certain apparmor limitations to prevent potentally bad things from occuring [14:53] sure, but if the charm (app) needs certain values set in order to work....... === kadams54-away is now known as kadams54 [15:06] johnny_shieh_: chicken and egg with that scenario. AppArmor tuning would have to be deployed to the parent machine which may or may not have a representation on the canvas. What I could suggest here is the following [15:07] deploy the ubuntu charm to get a machine representation on the gui, then deploy a subordinate unit that has the app armor tweaks you're looking to make before you deploy the LXC workload [15:07] the downside to this is you have an order-dependency that isn't very apparent to outsiders looking at the bundle - so ensure you have that callout documented somewhere. [15:08] yeah, hmm, extra effort...and we could always document it...but any other option? Alter file via brute force? [15:14] if your deployment is juju managed, it makes sense to have it represented in juju. [15:14] if only there was a way to execute actions with juju. :) [15:14] and the only way presently to do that would be to either make a charm that does it or a subordinate that is co-located with the parent that is getting the deploy --to lxc:# [15:15] jrwren: not sure how your charm would break out of LXC to modify the hosts apparmor profile [15:15] johnny_shieh_: if you dont want to write a charm to do it and just want a one-off you can juju run any sed/echo/etc. commands to make the modifications, but ymmv if the command is not well formed [15:16] lazyPower: it wouldn't. Run the action on the host. [15:17] A bit confused, surely you have had other apps that required changes to default OS (container) settings that needed variables changed. i.e. number of threads, number of files, file sizes. [15:17] Isn't there a standard way of changing the limitations within the container? Maybe I'm missing the point here. === kadams54 is now known as kadams54-away === kadams54-away is now known as kadams54 [15:45] alexisb, if someone on your team is looking for something to charm, check this out: http://gogs.io/ [15:46] that would be a nice charm, and packages/docker containers are already available, looks pretty straightforward [16:24] niedbalski: Hello [16:25] niedbalski: you mentioned that a new jenkins charm is on the way. Is that a complete rewrite or an MP against the existing one. Also any timelines on this? === kadams54 is now known as kadams54-away [16:33] niedbalski: I am going through the unmaintained process an am on rsyslog. [16:34] niedbalski: There has been no comment on the bug in over a month. https://bugs.launchpad.net/charms/precise/+source/rsyslog/+bug/1388274 [16:34] Bug #1388274: The rsyslog Makefile test target has errors

[16:35] niedbalski: you are listed as the maintainer of the rsyslog charms. If there is no comment or merge requests I may have to move rsyslog to unmaintained namespace [16:54] charm writing question. in some charms I see that people access config() once to set config_data and thereafter get info from config_data. when should I choose to do that versus check config each time? [16:54] how expensive is the call, and why wouldn't I always call it versus checking cached data? [16:58] I'd like to change the python-django charm to inject a value in to ALLOWED_HOSTS when I add a reverseproxy relation [16:58] hence I'm learning more about how/whether to pass the information to the website-relation-joined/changed [17:00] config info is mutable so I would want to check it anytime the relation changes, right? [17:06] hmm, maybe it's a bad idea to add support for that [17:09] context: I'm relating apache2:reverseproxy to python-django:website and don't have a domain name at the moment to set for hte python-django django_allowed_hosts config, hence would need to set the public IP of the apache2 unit [17:09] sure, I could set Debug or have allowed hosts be '*' or something [17:27] skay: does "*" mean that joe random could access the django server directly, given knowledge of its IP and port? [17:27] roadmr: yes, so you'd only want to do that in a Debugging type of situation on a deserted island [17:28] skay: my thought exactly... my concern was one of scalability, it would be easier to DoS the poor gunicorn [17:42] Hi, in several deployments, there are occasional hook failures, which can be resolved by retrying. Sometime if I went in to check the /var/log/juju/unit-UNITNAME.log, it's usually an error on running a command, and if I ran the command manually, it was success. For example, sudo keystone keystone-manage db_sync. Is it because when the hook script was run, perhaps mysql wasn't ready yet? [17:43] hey all, for the local provider, can I deploy machines to lxc and kvm containers on the host? I have 'container: kvm' set and I'm under the impression that any lxc containers have to be inside a deployed kvm machine. [17:58] coreycb, the container type kvm or lxc defines what containers to use as "machines" in a local environment - either kvm or lxc (not both), however, you can still try to deploy units in lxc or kvm with --to lxc: or --to kvm: (argument to deploy) [17:58] coreycb, please note though, lxc-in-lxc or kvm-in-lxc might not work out of the box [17:59] dimitern, ok so just to verify, if container type is kvm then any lxc containers have to be nested in kvm? === anthonyf is now known as Guest89771 [18:28] hi folks, I'm having issues accessing an environment that was bootstrapped with JUJU_HOME set. is that well tested? details here: http://paste.ubuntu.com/9941188/ [18:29] this is used in our openstack installer, so if it's not really supported well, we need to pull it out [18:55] mmcc: it is very well tested [18:56] mmcc: those errors are from juju version mismatches [18:56] the environment has 1.21.1 installed [18:56] which was released earlier today [18:56] you have 1.20.14 [18:56] upgrade to 1.21 using ppa:juju/stable and you won't have any issues [19:00] marcoceppi: ok, so it sounds like what happened is that I used the 1.20.14 cli to bootstrap, and it installed 1.21.1 and wrote an environment file that the old version can't read? why would it do that? [19:00] mmcc: it sounds like the cloud installer installed and used the latest version of juju [19:01] which is different than what you have installed. The client should always bootstrap with the version of juju that is used to bootstrap it [19:01] either way, that's the issue, you can see that in the tree output of the tools directory [19:02] marcoceppi: ah, ok. I do see what's going on here. thanks for your help. === mwenning is now known as mwenning-rr5 === blr_ is now known as blr === jam1 is now known as Guest8948 [19:53] Hello jose are you out there? === liam_ is now known as Guest91492 [20:25] Howdy, I'm deploying my first compute node using "openstack-install" and after configuring the MAAS info the script goes into "Bootstrapping Juju...". The compute node boots, goes through a bunch of configuring the compute node, the juju process seems to stop advancing with a single ssh connection open from the controller to the compute node "ssh -i /root/.cloud-install/juju ...." [20:26] I've gone through the process of releasing the node and running through the whole process again, same results [20:26] where whould I look to find out what's causing the hang up [20:39] I think I found the issue. On the compute node in /var/log/cloud-init-output.log indicates that DNS isn't working on the node, can't reach streams.canonical.com === kadams54 is now known as kadams54-away === kadams54-away is now known as kadams54 === kadams54 is now known as kadams54-away === kadams54-away is now known as kadams54 === kadams54 is now known as kadams54-away [21:02] tvansteenburgh: does this look like an infrastructure failure to you http://reports.vapour.ws/charm-tests/charm-bundle-test-5021-results/charm/charm-testing-aws/2 [21:03] "Resource Warning" === arosales_ is now known as arosales [21:03] tvansteenburgh: but consistantly happens across all our clouds [21:05] arosales: that can be ignored for now, it's a warning from a python lib. - no correlation with actual failures [21:07] the actual failure in that case is that the deployment didn't stand up in time [21:07] ok, seems like the charm is valid and isn't candidate for removal from the store [21:07] tvansteenburgh: thanks for taking alook [21:08] mbruzek: https://bugs.launchpad.net/charms/+source/nagios/+bug/1403574 [21:08] Bug #1403574: The nagios charm fails automated testing

[21:08] sounds like we need to fix this in the test [21:18] tvansteenburgh: while I am bothering you do you know if this charm is an issue with the make testing disscussion http://reports.vapour.ws/charm-tests/charm-bundle-test-838-results/charm/charm-testing-hp/2 [21:20] arosales: the test is trying to use an env var that's not set. it's up to the test to ensure that it is. so, it's a problem with the test [21:20] tvansteenburgh: ack, and thanks for looking [21:21] arosales: certainly === beisner- is now known as beisner [22:03] unit-wordpress-0[5078]: 2015-01-29 22:00:47 INFO unit.wordpress/0.install logger.go:40 W: Failed to fetch http://ppa.launchpad.net/charmers/charm-helpers/ubuntu/dists/trusty/main/binary-amd64/Packages 403 Forbidden [22:03] lazyPower, marcoceppi: ping [22:03] trying to install the wordpress trusty charm [22:03] and getting install hook failed [22:03] log sias ppa forbidden [22:03] say what? [22:04] lazyPower: you really there? [22:04] thumper: marcoceppi is travelling and i managed to part when i was trying to respond [22:04] kk [22:04] can you re-state the issue for me? [22:04] wordpress trusty charm install hook fails with apt ppa error [22:04] unit-wordpress-0[5078]: 2015-01-29 22:00:47 INFO unit.wordpress/0.install logger.go:40 W: Failed to fetch http://ppa.launchpad.net/charmers/charm-helpers/ubuntu/dists/trusty/main/binary-amd64/Packages 403 Forbidden [22:05] I just want a couple of charms to use in a demo [22:05] and went for the old standby mysql/wordpress [22:05] happy to use something else [22:05] thumper: how impressive do you want it to look? [22:05] doesn't have to be too impressive [22:05] and re: mysql - ty for pointing that out, def worth a bug. seems like a PPA archive went missing on us [22:06] just showing charms actually working [22:06] http://fosdem.juju.solutions [22:07] lazyPower: what I'm trying to demo is MESS [22:07] lazyPower: so two different environments inside one state server [22:07] each serving different things [22:11] ah ok, so simple it is [22:11] try the Elasticsearch/kibana bundle w/ a mediawiki/mysql bundle [22:12] minimal on machines, and i've deployed both wihtin the last 48 hours with success [22:12] http://imgur.com/CYPpORc [22:12] is what i was about to set you up with [22:14] lazyPower: that would be way more than I need :) [22:14] lazyPower: forgive me for being dumb, but how do I deploy the bundles? [22:15] https://jujucharms.com/mediawiki-single/7 [22:15] lazyPower: not sure that gui is going to work [22:15] juju quickstart should [22:15] right? [22:15] um... [22:15] I'm not sure [22:15] * lazyPower rolls the dice [22:15] lets find out! [22:16] hmm... I don't have quickstart [22:17] apt-get install juju-quickstart [22:21] thumper: quickstart is just fetching the environment state server from the jenv, as i see it quickstart should give you some results. if quickstart doesnt, go to the next common denominator and try juju-deployer (apt-get install juju-deployer) and give that a run (juju deployer -c bundles.yaml, or pass it the store url and it *should just work*) [22:23] * thumper tries [22:23] $ juju switch another [22:23] $ juju quickstart bundle:mediawiki/single [22:23] well... it is doing something [22:24] * lazyPower makes overly dramatic music while thumper waits to intensify the feeling of success [22:24] retrieving the environment status [22:24] that is where it is stuck [22:24] rick_h_: you around? [22:24] thumper: is the env status coming back with different/new keys now? [22:24] wat? [22:25] afaics thats just the status return. as in the json dump of whats running [22:25] I can do a status in another shell [22:25] thumper: yep [22:25] or what the state server knows about - to be more accurate [22:25] and it return fine [22:25] thumper: packing time [22:25] rick_h_: got a few minutes to talk api connections and quickstart? [22:25] lazyPower: quickstart is just hanging [22:25] thumper: quick ones sure [22:26] rick_h_: kk [22:26] rick_h_: https://plus.google.com/hangouts/_/gtonfe6y7vs6is7p6npawkge3ea?hl=en