[04:34] <weblife> @marcoceppi Do you want me to send you my patch at least?
[04:34] <weblife> It works well from my experience...
[07:14] <den_sheleh> Is it possible to read somewhere draft of article 'AppArmor and charms' ?  Early was on this page https://juju.ubuntu.com/AppArmor
[08:29] <_mup_> Bug #1206412 was filed: Can't access the WordPress Server deployed using MAAS-JUJU. Web page access ends up with Error "502 Bad Gateway (nginx/1.2.6 (Ubuntu)" <charms> <juju> <maas> <wordpress> <juju:New> <https://launchpad.net/bugs/1206412>
[08:58] <alok__> hie there
[11:31] <bloodearnest> heya folks - I am using the new juju-core lxc provider, and am getting an error about git not being in $PATH that loops every 3 seconds
[11:31] <bloodearnest> http://paste.ubuntu.com/5928665/
[11:32] <bloodearnest> this worked fine on friday, fwiw
[11:33] <bloodearnest> my charms just retry installing every 3s until the deployment timesout
[11:35] <bloodearnest> juju version is  1.11.4-1~1514~raring1 from ppa
[11:52] <marcoceppi> bloodearnest: if you `juju ssh u1-psearch-app/0` can you verify git is actually installed?
[11:54] <pavel> hm... I'm not sure, but seems that when I add subordinate relation it triggers container relation install hook
[11:55] <bloodearnest> marcoceppi, not installed
[11:56] <marcoceppi> bloodearnest: so it looks like the charm requires git but it isn't/wasn't installed. Adding git-core to the list of packages installed during hooks/install should resolve this
[11:59] <bloodearnest> marcoceppi, yeah, I'm looking at that, but AFAICS, it doesn't require git. And this happens on every charm (~7) from the stack I'm trying to deploy
[12:00] <marcoceppi> bloodearnest: that's interesting.
[12:00] <bloodearnest> marcoceppi, and the error came from git.go line 177, so I thought it might be juju related
[12:00] <marcoceppi> bloodearnest: file a bug, it sounds like something that was changed in core
[12:00] <bloodearnest> marcoceppi, kk
[12:04] <bloodearnest> marcoceppi, am going to try with pyjuju/lxc -if it fails there, it likley the charm(s) at fault
[12:07] <bloodearnest> marcoceppi, hmm, seems I can't hit archive.ubuntu.com from the lxc, so that's likely the issue
[12:07] <marcoceppi> bloodearnest: ah, that would make sense
[12:11] <bloodearnest> marcoceppi, yeah, some iptables rules to expose lxc to the world gone awry
[12:29] <rick_h> marcoceppi: ping, morning
[12:29] <marcoceppi> rick_h: morning
[12:30] <rick_h> marcoceppi: so I'm poking at https://bugs.launchpad.net/juju-gui/+bug/1202636 for the gui
[12:30] <_mup_> Bug #1202636: Charm Details Page Under Providers Change Openstack to HP Cloud <juju-gui:Triaged> <https://launchpad.net/bugs/1202636>
[12:30] <rick_h> marcoceppi: and basically we're going to start reporting that the HP tests are HP. However, the tests data we import says it's openstack.
[12:30] <marcoceppi> rick_h: yeah, it's testing openstack provider against hp-cloud
[12:30] <rick_h> marcoceppi: for now I'm going to rename it in the Gui and carry on, but at some point it'd be cool to coordinate a move to call it hp throughout
[12:31] <marcoceppi> rick_h: ack, I'll add a work item to the charmtester stuff and ping you to pick a time to switch
[12:31] <rick_h> marcoceppi: just to put on your radar and heads up that the gui changes is giong to go through so we'll see local/ec2/hp as the provider test results
[12:31] <rick_h> marcoceppi: thanks
[13:44] <Tantor> Hello. This morning around 7:00 (It's 16:43 here now) I started some juju deploy tasks. These tasks are still pending. Is this normal?
[13:44] <Tantor> Output of juju status: http://pastebin.com/dF5gn6GY
[13:45] <Tantor> I also notice that of my two servers the agent state is on not-started, which sounds strange to me
[14:02] <Tantor> On one machine juju-machine-agent refuses to start and give this error: Failure: zookeeper.NodeExistsException: node exists
[14:02] <Tantor> I cant find a clear explanation and solution when I search on this error with google
[14:16] <freeflying> I tried to destroy-service/unit, juju status shows dying, is there anything I can do? I want to destroy the machine, and redeploy it
[14:17] <ahasenack> freeflying: what is the status of the unit/service now? Is it in error?
[14:17] <ahasenack> freeflying: if it is in error, then you need to juju resolved <unit>, and then you will be able to destroy it probably
[14:18] <freeflying> ahasenack: life: dying
[14:18] <ahasenack> freeflying: what about the rest of the lines?
[14:19] <freeflying> ahasenack: agent-state is error, so I can use resolved?
[14:19] <ahasenack> freeflying: yeah, try it, and then destroy-unit, and then terminate-machine
[14:20] <freeflying> ahasenack: hah, resolved, thanks
[14:22] <ahasenack> good
[16:49] <scuttlemonkey> so how is the ec2 api for deploying charms on an openstack environment?
[16:49] <scuttlemonkey> I have used ec2 native, but haven't had a chance to play on a pure openstack setup yet
[17:02] <marcoceppi> scuttlemonkey: we don't use the ec2 compatibility api anymore for openstack deployments. We use the straight openstack api and it works rather well
[17:02] <scuttlemonkey> marcoceppi: ahh, right on...didn't see much doc on that front
[17:02] <scuttlemonkey> looked like mostly s3-specific stuff, guess I'll keep digging
[17:03] <marcoceppi> scuttlemonkey: for the most recent stuff, I'd recommend looking at the juju-core code if you aren't already
[17:03] <scuttlemonkey> marcoceppi: yeah that's the next stop. I generally like to parse human-readable stuffs first if I can :)
[17:15] <xmltok> has anyone done a comparison of juju to something like cloudformation? I like juju for a lot of things but being able to configure VIPs is a nice feature. they look to be pretty similar solutions in a lot of ways
[17:24] <marcoceppi> xmltok: CloudFormation is AWS Only, Juju is cloud agnostic*
[17:31] <xmltok> i suppose cloudformation on openstack (heat) probably just builds out an haproxy node, which could easily be done through juju
[17:35] <sidnei> yes, that's quite accurate in fact
[17:58] <xmltok> WRT juju in a large production environment, can a team share a bootstrap node? I get how an engineer can build out their platform but i'm not sure how ops would share the management of a bunch of deployments. does each charm configuration set require a different bootstrap node, or can i have one bootstrap node for each production colo?
[18:08] <marcoceppi> xmltok: So you can specify who has access to a deployment in the environments.yaml by including their ssh public keys as one of the options. From there, as long as each user has proper credentials to access the cloud environment they can use juju from the command line. There's also a juju-gui charm you can deploy which allows users to log in via a web interface and manage that envrionment/deployment from a browser
[18:09] <marcoceppi> Each environment only needs one bootstrap node to operate. So that one node runs orchestration for the entire deployment
[18:28] <xmltok> cool
[18:29] <xmltok> ive been planning on implementing a similar enviroment sharing solution for teams of engineers, so it sounds like this would solve that problem too
[18:30] <xmltok> if I wanted to write a web interface to modifying the environment (changing relationships, adding charms) is there an API to the bootstrap node or is it all via juju command line options?
[18:33] <marcoceppi> xmltok: there already is one. juju-gui is that web interface
[18:33] <marcoceppi> but yes it uses an so in the bootstrap node
[18:40] <xmltok> ok, i didn't realize that gui was deployable internally, it looked so good i figured it was some kind of pay solution
[18:41] <xmltok> so i could in effect have a gui server set up and engineers could log in and point it at their different environment bootstrap nodes to modify them as needed, or ops could point them at the different prod environments. that is pretty cool
[18:51] <marcoceppi> it's one GUI per environment ATM xmltok
[18:51] <xmltok> can the GUI run on the bootstrap node?
[19:00] <marcoceppi> xmltok: yup
[19:02] <marcoceppi> xmltok: https://jujucharms.com/precise/juju-gui/#bws-readme
[19:48] <webbrandon> Does default-series stand for the juju version being installed?
[19:53] <webbrandon> Or the image it is going to be deployed?
[19:54] <webbrandon> ubuntu image that is
[20:04] <marcoceppi> webbrandon: Ubuntu series, ie: precise, quantal, raring, etc
[20:05] <marcoceppi> We recommend, and it defaults to, precise (the current LTS)
[20:39] <weblife> Okay found something that describes it in more depth.  Think I will submit a more detailed description of the setting in the docs since it doesn't describe it well.
[21:01] <marcoceppi> weblife: what's that?
[21:02] <weblife> default-series
[21:04]  * thumper waves
[21:05] <weblife> also updating the AWS setup getting started page
[21:20] <marcoceppi> weblife: it shouldn't be needed with the latest juju unless you something other than LTS
[21:22] <weblife> @marcoceppi Whats that the default-series option or the AWS page(https://bugs.launchpad.net/juju-core/+bug/1201833)?
[21:22] <_mup_> Bug #1201833: AWS instructions need an update <juju-core:In Progress by evilnick> <juju-core docs:In Progress by evilnick> <Juju Website:New> <https://launchpad.net/bugs/1201833>
[21:30] <marcoceppi> weblife: precise, for all clouds
[21:33] <weblife> so there is no more setting specific environments like 'oneiric'?
[21:34] <marcoceppi> weblife well I don't think you can use oneiric any more with juju
[21:35] <weblife> I was about to write this into the AWS setup along with the security changes:
[21:37] <weblife> Environments can currently be configured with a default-series option, which controls the Ubuntu series to be ran on new machines (where available) and the repository collection from which to get charms (always).  You can find available Ubuntu AMI versions that are supported with AWS in the AWS Marketplace at aws.amazon.com/marketplace.  You can also find a list of the different Ubuntu series at http://en.wikipedia.org/wiki/List_of_
[21:37] <weblife> Ubuntu_releases if you decide to setup your own EBS-backed AMI.
[21:37] <weblife> following what I read here: https://bugs.launchpad.net/juju/+bug/865163
[21:37] <_mup_> Bug #865163: default-series option has surprising behaviour <juju:Fix Released by fwereade> <https://launchpad.net/bugs/865163>
[21:44] <aimatt> halo, when I desploy a new charm on say, openstack, it spawns up a whole vm for it?
[21:46] <sarnold> aimatt: yeah, that's a large part of juju's cause to exist :)
[21:47] <aimatt> sarnold: ok, I'm just trying to think of how I would make a charm for a particular service that depends on a service, such as memcache, running locally
[21:48] <aimatt> I would guess that I would just include apt-get install memcached in that services, charm
[21:48] <aimatt> right?
[21:48] <sarnold> aimatt: or you could use a subordinate service
[21:49] <sarnold> aimatt: https://juju.ubuntu.com/docs/authors-subordinate-services.html
[21:50] <sarnold> aimatt: I have a feeling that might not be the best solution for memcache. I've got a feeling you might want to be able to scale those separate from the other services, and you might want its cache to serve for more than the one service unit it would be deployed with, as a subordinate
[21:51] <aimatt> we would have a separate memcache cluster too, this is used for things like locks
[21:51] <sarnold> ah okay :)
[21:51] <aimatt> local stuff only
[21:52] <aimatt> thanks for the link, I'm wrapping my head around it
[21:53] <marcoceppi> weblife: So, that's not entirely accurate. So simplestream data determines which AMI or image to use for juju, you just supply the series data
[21:59] <aimatt> sarnold: that looks perfect. thank you
[22:00] <sarnold> aimatt: cool! :)
[22:00] <aimatt> I think the indentation of the YAML there is borked though
[22:01] <aimatt> but I get it
[22:03] <sarnold> heh, so it is, html source has it correctly though
[22:04]  * marcoceppi fixes html structure
[22:05] <sarnold> marcoceppi: 1206704
[22:06] <marcoceppi> sarnold: thanks!
[22:08] <sarnold> marcoceppi: I _love_ the "file a bug" link on the bottom of the page. that's just friendly. :)
[22:11] <weblife> @marcoceppi Okay I will leave that part out then.
[22:54] <weblife> I don't know what to do... I am told I need to get experience in "charm contributors" to submit patches and repairs.  So I assign myself to a bug with them: https://bugs.launchpad.net/juju-core/+bug/1201833 but I can't submit my repair because "charmers" requires the same.  So I uploaded my repair to: https://code.launchpad.net/~web-brandon/juju-core/juju-core.  Am I missing a step because I am feeling pretty defeated for simply try
[22:54] <weblife> ing to help make things better.
[22:54] <_mup_> Bug #1201833: AWS instructions need an update <juju-core:In Progress by web-brandon> <juju-core docs:In Progress by evilnick> <Juju Website:New> <https://launchpad.net/bugs/1201833>
[23:45] <weblife> Thank you jcastro
[23:54] <aimatt> another question: if I use juju, what do I really need openstack for?
[23:55] <sarnold> aimatt: you need something to create VMs for you -- or, in the case of MAAS, actual machines :)
[23:56] <sarnold> aimatt: juju just knows how to ask openstack or ec2 or azure or hp cloud or .. for a new machine instance
[23:56] <aimatt> sarnold: oh, so the openstack charm is primarily for maas?
[23:58] <sarnold> aimatt: that's where my knowledge gets thin -- as I understand it, you'd have two jujus in place -- one to control the openstack environment itself, one to control the things you -run- on openstack