[00:46] <axw> noodles775: I couldn't say, sorry. I'm not sure who prioritises things like that... maybe check with sinzui?
[00:49] <noodles775> axw: yep, will do. Thanks.
[00:49] <axw> noodles775: probably also a good idea to create a bug in launchpad.net/juju-core, so it's on his radar
[00:52] <noodles775> axw: ack, will do too :)
[00:55] <thumper> jlondon: how are you creating the lxc containers?
[00:55]  * thumper wanders off for a bit, bbs
[00:55] <jlondon> 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] <jlondon> and then the containers just get stuck in the 'pending' state with no network information that I could see.
[01:04] <thumper> jlondon: hmm...
[01:04] <thumper> jlondon: using juju to create the containers? or ssh'ing in and doing it by hand?
[01:05] <jlondon> thumper: juju. I'm trying to avoid doing anything on the server manually :)
[01:05] <thumper> hmm...
[01:06] <jlondon> Should I try kvm instead?
[01:08] <thumper> that probably wouldn't help
[01:08] <jlondon> k
[01:09] <thumper> can you ssh into the machine and look at /var/lib/juju/containers/<containername>/lxc.conf?
[01:10] <thumper> look for network config in there
[01:11] <jlondon> thumper: K. One second I'm spinning them back up with fresh installs.
[01:15] <jlondon> thumper: huh, okay, it appears to be setting the network to juju-br0 in the container level config file.
[01:16] <thumper> jlondon: ok, it is something else then
[01:16] <thumper> I did see a bug fix land recently that disabled the networking worker because it was screwing up lxc containers
[01:16] <thumper> jlondon: which version of juju?
[01:18] <jlondon> thumper: stable: 1.20.14
[01:20] <jlondon> 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] <jlondon> looking at the logs further for one, it doesn't appear to be getting an IP at all.
[01:31] <jlondon> dhcp is running on the network for sure though (maas provided)
[01:35] <thumper> hmm... not sure sorry
[01:37] <jlondon> thumper: No worries. I'll keep playing around with it.
[10:10] <lazyPower> seal: o/
[10:11] <seal> lazyPower: o/
[10:12] <lazyPower> how goes the exploring?
[10:12] <seal> great work on http://chuckbutler.github.io/flannel-docker-charm/user/getting-started.html
[10:12] <lazyPower> Thanks :)
[10:13] <lazyPower> 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] <seal> great
[10:13] <lazyPower> https://github.com/mbruzek/docker-bundle
[10:15] <lazyPower> 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] <lazyPower> also, the charms + bundle are up for review in the queue so you should see them landing in the store soon'ish
[10:18] <seal> I need to look into bundles more. I haven't has much joy getting it to work on my machine
[10:19] <seal> Will be looking out for the bundles release
[10:33] <lazyPower> seal: oh? anything i can help with on the bundles?
[10:33] <mwak> hi
[10:33] <lazyPower> o/ mwak
[10:33] <mwak> how are you lazyPower
[10:33] <mwak> ?
[10:34] <lazyPower> Good, preparing for talks over the next few days
[10:34] <lazyPower> how about yourself mwak?
[10:34] <mwak> fosdem?
[10:34] <mwak> ping jcastro
[10:35] <lazyPower> mwak: FLOSSCommunity Metrics, FOSDEM, and ConfigurationManagementCamp
[10:35] <mwak> great!
[10:36] <seal> 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] <lazyPower> i'm familiar with this bundle
[10:37] <mwak> I didn't get time to fix the haddop charm for arm yet, should try to get some time to investigate :/
[10:37] <lazyPower> you can also fetch it and deploy from the CLI with juju quicksstart
[10:37] <seal> 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] <lazyPower> sure thing seal
[10:37] <mwak> lazyPower: you personally will be at FOSDEM?
[10:38] <lazyPower> mwak: indeed. I'm running a talk track there
[10:38] <mwak> great!
[10:38] <mwak> topic?
[10:38] <lazyPower> https://fosdem.org/2015/schedule/event/juju_orchestration/
[10:39] <lazyPower> 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] <lazyPower> SURPRISE, its lazy :D
[11:02] <axw> 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] <lazyPower> axw: i'm working on refactoring that to work with rbenv vs rvm (which is consistently the reason its breaking)
[11:03] <lazyPower> i have some WIP if ou want to pick up the torch on it and help :)
[11:03] <lazyPower> i'm nearly complete, refactoring out the rvm localized commands has been the lions share of the work
[11:04] <axw> lazyPower: I don't think I'd be of much help, I don't know ruby
[11:04] <lazyPower> 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] <axw> I can test if it's usable tho
[11:04] <axw> lazyPower: okey dokey
[11:05] <lazyPower> well its close, but not bullet proof yet, i think there are still some cases with localized ruby versions that need addressing
[11:05] <lazyPower> meaning, your app says "i want ruby 2.2.1"
[11:05] <lazyPower> and i'm installing 2.0.0 as system ruby
[11:05] <lazyPower> but other than that, it was working well iirc
[11:05] <lazyPower> let me get you a link 1 sec
[11:06] <lazyPower> https://github.com/chuckbutler/rails-charm/tree/rbenv_migration
[11:06] <axw> lazyPower: thanks
[11:06] <lazyPower> ymmv - i haven't tested it in ~ a month - so the ground may have shifted again under whats there
[11:06] <lazyPower> lmk if you get success/failure with that and i'll go from there. issues welcome :)
[11:07] <axw> lazyPower: will do
[11:17] <axw> lazyPower: gtg, but it still fails. http://paste.ubuntu.com/9934923/
[11:17] <axw> lazyPower: I'm using https://github.com/pavelpachkovskij/sample-rails
[11:19] <lazyPower> 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] <lazyPower> if you need it for a priority deployment i can try and escalate this
[11:20] <axw> lazyPower: it's cool. was hoping to use it to demo a new storage feature, but we can find something else
[11:20] <axw> enjoy the conference
[11:21] <lazyPower> thanks axw, sorry about the inconvenience
[11:21] <axw> no worries
[14:43] <johnny_shieh_> 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] <johnny_shieh_> limitation?  workaround?
[14:52] <marcoceppi> johnny_shieh_: LXC containers created by/with juju have certain apparmor limitations to prevent potentally bad things from occuring
[14:53] <johnny_shieh_> sure, but if the charm (app) needs certain values set in order to work.......
[15:06] <lazyPower> 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] <lazyPower> 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] <lazyPower> 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] <johnny_shieh_> yeah, hmm, extra effort...and we could always document it...but any other option?  Alter file via brute force?
[15:14] <lazyPower> if your deployment is juju managed, it makes sense to have it represented in juju.
[15:14] <jrwren> if only there was a way to execute actions with juju. :)
[15:14] <lazyPower> 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] <lazyPower> jrwren: not sure how your charm would break out of LXC to modify the hosts apparmor profile
[15:15] <lazyPower> 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] <jrwren> lazyPower: it wouldn't. Run the action on the host.
[15:17] <johnny_shieh_> 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] <johnny_shieh_> Isn't there a standard way of changing the limitations within the container?  Maybe I'm missing the point here.
[15:45] <jcastro> alexisb, if someone on your team is looking for something to charm, check this out: http://gogs.io/
[15:46] <jcastro> that would be a nice charm, and packages/docker containers are already available, looks pretty straightforward
[16:24] <arosales> niedbalski: Hello
[16:25] <arosales> 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?
[16:33] <mbruzek> niedbalski: I am going through the unmaintained process an am on rsyslog.
[16:34] <mbruzek> 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] <mup> Bug #1388274: The rsyslog Makefile test target has errors <audit> <auto-test> <rsyslog (Juju Charms Collection):Triaged by niedbalski> <rsyslog (Charms Precise):Triaged by niedbalski> <rsyslog (Charms Trusty):Triaged> <https://launchpad.net/bugs/1388274>
[16:35] <mbruzek> 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] <skay> 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] <skay> how expensive is the call, and why wouldn't I always call it versus checking cached data?
[16:58] <skay> 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] <skay> hence I'm learning more about how/whether to pass the information to the website-relation-joined/changed
[17:00] <skay> config info is mutable so I would want to check it anytime the relation changes, right?
[17:06] <skay> hmm, maybe it's a bad idea to add support for that
[17:09] <skay> 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] <skay> sure, I could set Debug or have allowed hosts be '*' or something
[17:27] <roadmr> skay: does "*" mean that joe random could access the django server directly, given knowledge of its IP and port?
[17:27] <skay> roadmr: yes, so you'd only want to do that in a Debugging type of situation on a deserted island
[17:28] <roadmr> skay: my thought exactly... my concern was one of scalability, it would be easier to DoS the poor gunicorn
[17:42] <catbus1> 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] <coreycb> 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] <dimitern> 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:<machine-id> or --to kvm:<machine-id> (argument to deploy)
[17:58] <dimitern> coreycb, please note though, lxc-in-lxc or kvm-in-lxc might not work out of the box
[17:59] <coreycb> dimitern, ok so just to verify, if container type is kvm then any lxc containers have to be nested in kvm?
[18:28] <mmcc> 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] <mmcc> this is used in our openstack installer, so if it's not really supported well, we need to pull it out
[18:55] <marcoceppi> mmcc: it is very well tested
[18:56] <marcoceppi> mmcc: those errors are from juju version mismatches
[18:56] <marcoceppi> the environment has 1.21.1 installed
[18:56] <marcoceppi> which was released earlier today
[18:56] <marcoceppi> you have 1.20.14
[18:56] <marcoceppi> upgrade to 1.21 using ppa:juju/stable and you won't have any issues
[19:00] <mmcc> 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] <marcoceppi> mmcc: it sounds like the cloud installer installed and used the latest version of juju
[19:01] <marcoceppi> 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] <marcoceppi> either way, that's the issue, you can see that in the tree output of the tools directory
[19:02] <mmcc> marcoceppi: ah, ok. I do see what's going on here. thanks for your help.
[19:53] <mbruzek> Hello jose are you out there?
[20:25] <flakrat> 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] <flakrat> I've gone through the process of releasing the node and running through the whole process again, same results
[20:26] <flakrat> where whould I look to find out what's causing the hang up
[20:39] <flakrat> 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
[21:02] <arosales_> 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] <arosales_> "Resource Warning"
[21:03] <arosales> tvansteenburgh: but consistantly happens across all our clouds
[21:05] <tvansteenburgh> arosales: that can be ignored for now, it's a warning from a python lib. - no correlation with actual failures
[21:07] <tvansteenburgh> the actual failure in that case is that the deployment didn't stand up in time
[21:07] <arosales> ok, seems like the charm is valid and isn't candidate for removal from the store
[21:07] <arosales> tvansteenburgh: thanks for taking alook
[21:08] <arosales> mbruzek: https://bugs.launchpad.net/charms/+source/nagios/+bug/1403574
[21:08] <mup> Bug #1403574: The nagios charm fails automated testing <audit> <auto-test> <nagios (Juju Charms Collection):Triaged> <https://launchpad.net/bugs/1403574>
[21:08] <arosales> sounds like we need to fix this in the test
[21:18] <arosales> 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] <tvansteenburgh> 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] <arosales> tvansteenburgh: ack, and thanks for looking
[21:21] <tvansteenburgh> arosales: certainly
[22:03] <thumper> 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] <thumper> lazyPower, marcoceppi: ping
[22:03] <thumper> trying to install the wordpress trusty charm
[22:03] <thumper> and getting install hook failed
[22:03] <thumper> log sias ppa forbidden
[22:03] <thumper> say what?
[22:04] <thumper> lazyPower: you really there?
[22:04] <lazyPower> thumper: marcoceppi is travelling and i managed to part when i was trying to respond
[22:04] <thumper> kk
[22:04] <lazyPower> can you re-state the issue for me?
[22:04] <thumper> wordpress trusty charm install hook fails with apt ppa error
[22:04] <thumper> 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] <thumper> I just want a couple of charms to use in a demo
[22:05] <thumper> and went for the old standby mysql/wordpress
[22:05] <thumper> happy to use something else
[22:05] <lazyPower> thumper: how impressive do you want it to look?
[22:05] <thumper> doesn't have to be too impressive
[22:05] <lazyPower> and re: mysql - ty for pointing that out, def worth a bug. seems like a PPA archive went missing on us
[22:06] <thumper> just showing charms actually working
[22:06] <lazyPower> http://fosdem.juju.solutions
[22:07] <thumper> lazyPower: what I'm trying to demo is MESS
[22:07] <thumper> lazyPower: so two different environments inside one state server
[22:07] <thumper> each serving different things
[22:11] <lazyPower> ah ok, so simple it is
[22:11] <lazyPower> try the Elasticsearch/kibana bundle w/ a mediawiki/mysql bundle
[22:12] <lazyPower> minimal on machines, and i've deployed both wihtin the last 48 hours with success
[22:12] <lazyPower> http://imgur.com/CYPpORc
[22:12] <lazyPower> is what i was about to set you up with
[22:14] <thumper> lazyPower: that would be way more than I need :)
[22:14] <thumper> lazyPower: forgive me for being dumb, but how do I deploy the bundles?
[22:15] <lazyPower> https://jujucharms.com/mediawiki-single/7
[22:15] <thumper> lazyPower: not sure that gui is going to work
[22:15] <lazyPower> juju quickstart should
[22:15] <lazyPower> right?
[22:15] <thumper> um...
[22:15] <thumper> I'm not sure
[22:15]  * lazyPower rolls the dice
[22:15] <lazyPower> lets find out!
[22:16] <thumper> hmm... I don't have quickstart
[22:17] <lazyPower> apt-get install juju-quickstart
[22:21] <lazyPower> 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] <thumper> $ juju switch another
[22:23] <thumper> $ juju quickstart bundle:mediawiki/single
[22:23] <thumper> well... it is doing something
[22:24]  * lazyPower makes overly dramatic music while thumper waits to intensify the feeling of success 
[22:24] <thumper> retrieving the environment status
[22:24] <thumper> that is where it is stuck
[22:24] <thumper> rick_h_: you around?
[22:24] <lazyPower> thumper: is the env status coming back with different/new keys now?
[22:24] <thumper> wat?
[22:25] <lazyPower> afaics thats just the status return. as in the json dump of whats running
[22:25] <thumper> I can do a status in another shell
[22:25] <rick_h_> thumper: yep
[22:25] <lazyPower> or what the state server knows about - to be more accurate
[22:25] <thumper> and it return fine
[22:25] <rick_h_> thumper: packing time
[22:25] <thumper> rick_h_: got a few minutes to talk api connections and quickstart?
[22:25] <thumper> lazyPower: quickstart is just hanging
[22:25] <rick_h_> thumper: quick ones sure
[22:26] <thumper> rick_h_: kk
[22:26] <thumper> rick_h_: https://plus.google.com/hangouts/_/gtonfe6y7vs6is7p6npawkge3ea?hl=en