[12:02] <yolanda> jamespage, btw, were you able to take a look at heat?
[12:30] <mthaddon> if I have an extremely high revision number for a charm is that likely to cause problems when running upgrade-charm? "date +%s > revision && juju upgrade-charm" - my upgrade-charm hook seems to be running for a long time, taking a lot of CPU
[12:57] <marcoceppi> mthaddon: interesting Why are you even changing the revision? Juju should do that for you during upgrade-charm
[13:12] <ashipika> hey all.. just a quick one.. on bootstrap (in a VM): ERROR juju supercommand.go: 282 unrecognised architecture: precise
[13:16] <marcoceppi> ashipika: precise isn't an architecture, it's a series. What bootstrap/deploy command are you running?
[13:17] <ashipika> juju bootstrap --upload-tools --show-log.. null provider..
[13:17] <ashipika> i know it's a series, that's why i'm confused
[13:21] <mthaddon> marcoceppi: this charm doesn't have a revision file in the tree, so I need to manually create it - I realise this is possibly non-standard behaviour, but when you're relying on juju upgrade-charm for code rollouts having that file versioned can be problematic
[13:22] <marcoceppi> mthaddon: interesting concept. I have no idea what would cause juju to hang though. Try increasing the log verbosity for the service and seeing what shows up in the unit/machine log
[13:24] <mthaddon> marcoceppi: upgrade-charm seems to be checking if each previous revision exists for this env somehow
[13:24]  * mthaddon is just going to start from scratch
[13:28] <ashipika> marcoceppi: found an error.. when trying to ssh to the computer it fails to add the host to the know_hosts file (permission issues), so there is an extra line in the output of the detection script.. all lines get shifted by one line down..
[13:29] <ashipika> that is why it fails to properly parse the architecture
[13:29] <ashipika> and gets the series instead
[13:47] <X-warrior> morning
[13:58] <Luca__> marcoceppi: I keep getting this agent-state-info: 'hook failed: "ha-relation-changed"' when trying to add hacluster to mysql...
[13:58] <Luca__> any idea?
[14:17] <jamespage> marcoceppi, I'm helping Luca__ with that issue - worth noting that all of the openstack charms default to using eth0 for HA - but juju now configured a bridge automatically so it needs to be br0
[14:18] <marcoceppi> jamespage: ah, cool
[15:31] <jcsackett> sinzui: fighting g+, be at the 1x1 in a few.
[15:48] <jcastro> jamespage, for the docs, for charm features we have "the service shouldn't run as root"
[15:48] <jcastro> I want to crosslink to upstart docs to give people a clue on how they can do this
[15:48] <jcastro> http://upstart.ubuntu.com/cookbook/#run-a-job-as-a-different-user
[15:48] <jcastro> is this the right section?
[16:02] <jcastro> marcoceppi, do we have a link to something like "how to use amulet" for charm authors?
[16:02] <marcoceppi> jcastro: no, I'm writing that now actually
[16:02] <marcoceppi> in preperation for the release
[16:02] <jcastro> do you know where it will live URL wise?
[16:02] <jcastro> I'd like to crosslink
[16:04] <jamespage> jcastro, yes - thats right
[16:05] <marcoceppi>  jcastro howto-amulet.html probably
[16:06] <jcastro> authors-amulet.html seems to match more?
[16:06] <jcastro> actually howto is fine
[16:06] <jcastro> ok let's do that. :)
[16:17] <jcastro> marcoceppi, hey I think I messed up an MP for docs
[16:17] <jcastro> I just pushed a branch but it appears to have updated another one I had done earlier?
[16:17] <jcastro> https://code.launchpad.net/juju-core
[16:45] <marcoceppi> jcastro: it looks like you did a bzr push twice for two different branches?
[16:47] <jcastro> yeah I dunno why it did that, sent nick a mail and he'll just pull  from the right one
[17:23] <jcastro> hey sinzui
[17:23] <jcastro> I am doing my talk proposal for SCaLE 12x in February.
[17:24] <jcastro> " Any Ubuntu machine with an open SSH port can be managed by Juju." won't be a lie by then right? :)
[17:24] <jcastro> aka how's the manual provider looking these days?
[17:24] <marcoceppi> jcastro: thumper was saying he landed stuff to make it better last night
[17:25] <sinzui> jcastro, buggy and specifically with ssh
[17:25] <marcoceppi> err
[17:25] <jcastro> sinzui, buggy as in bad or buggy as in "I have 2 months worth of work until the talk"
[17:25] <marcoceppi> misspoke
[17:25] <sinzui> jcastro, We do want this production ready in January
[17:25] <jcastro> perfect, so submitting that statement for a February conference won't get my killed by the audience
[17:26] <sinzui> jcastro, or...I use your conference as an excuse to escalate a cluster (F) or ssh bugs
[17:26] <jcastro> that would be fine
[17:26] <jcastro> is there a tag for manual provider specific bugs I can follow along?
[17:27] <sinzui> manual-provider actually
[17:28] <utlemming> Just announced the Juju Quickstart Images: http://blog.utlemming.org
[17:28] <jcastro> oh cool, I'll share that around in a minute utlemming
[17:29] <arosales> utlemming, very nice blog post http://blog.utlemming.org/2013/12/beta-cross-platform-juju-development.html
[17:29] <arosales> utlemming, I think there is a "quickstart" plugin that is different from yours though.  I think your vagrant images is more of a local charm development work flow
[17:29] <arosales> for clearity
[17:30] <arosales> utlemming, but really nice work !
[17:30] <jcastro> yeah you can't call it quickstart
[17:31] <jcastro> unless we start naming various tools and aliases under "quickstart"
[17:31] <jcastro> which is fine by me if they behave the same
[17:32] <utlemming> hrm, I agree. If the effect is the same, Quickstart plugin vs Quickstart images, conveys the same idea: getting quickly started
[17:33] <jcastro> yeah
[17:34]  * marcoceppi is having flashbacks to bundle discussion wrt naming
[17:36] <jcastro> utlemming, you going to announce anywhere else or want me to handle it now? Don't want to douple post if you plan on
[17:37] <utlemming> jcastro: it landed on planet Ubuntu. But seeing as your the man with all the connects, if you would like to spred the message, that'd be great.
[17:40] <jcastro> utlemming, typo "Chose" the box in your header
[17:40] <jcastro> also why not recommend 12.04 by default?
[17:47] <rick_h_> utlemming: jcastro just a heads up that we might want to watch the quickstart branding as we bring the juju quickstart command up to users. https://launchpad.net/juju-quickstart
[18:10] <jcastro> rick_h_, yeah, we should def keep that in mind
[18:17] <lazypower> Hey thats cool. I was experimenting around with vagrant based juju development a while ago and had some marginal success using sshuttle to route the requests into vagrant....
[18:19] <lazypower> marcoceppi: this is basically the route we took when you came up to visit.
[19:26] <mxc> have some juju security questions
[19:27] <mxc> which i haven't been able to answer from reading the docs
[19:30] <mxc> specifically fire walling, creating juju instances, without exposing them (on azure at least) opens up a public port 22 to the world
[19:31] <mxc> is it possible to deploy charms (say mongodb for example) with very strict ufw/iptables configs?
[19:31] <mxc> or, would I have to basically fork the charms to do that?
[19:32] <sarnold> mxc: investigate the subordinate charms
[19:35] <mxc> thanks, but I may be missing something.
[19:36] <mxc> here's my situation, basically i want to have an environment like :
[19:36] <mxc> [ haproxy ] <--> [ app servers ] <--> [mongodb ]
[19:36] <mxc> where the app servers and mongodb are completely unreachable from the outside world
[19:43] <marcoceppi> mxc: by default only port 22 is available to servers
[19:43] <marcoceppi> all other ports are disabled unless you explicitly enable them
[19:44] <marcoceppi> you can supplement this, by creating a firewall charm
[19:44] <marcoceppi> that you can deploy on all of the service you care about, that restrict access by creating ufw, iptables, whatever on that machines
[19:44] <marcoceppi> this is done with a subordinate charm
[19:44] <mxc> aaah ok. now I get how the subordinate charms help
[19:45] <mxc> i create a ufw subordinate charm, add it to my config for the mongo charm etc
[19:45] <mxc> thanks!
[20:44] <med_> marcoceppi, is co-location still called co-location (kind of a meta question)
[20:46] <marcoceppi> med_: you're talking about the --to command, and I assume containerization?
[20:46] <med_> marcoceppi, related: can you have a constraint that only deploys "NEWCHARM" if "OLDCHARM" exists?
[20:46] <med_> marcoceppi, thanks, that's probably what I needed, "--to"
[20:47] <marcoceppi> we have "hulk smash" colocation, where you can just smash two services together with --to, we're making a better container story so you can truly co-locate two services on a physical machine via something like LXC
[20:48] <med_> "hulk smash" is probably more what I was thinking of then. And I'm more worried about "already available to users" vs "coming soon"
[20:48] <marcoceppi> med_: there's no constraint like that, you'd have to codify it yourself
[20:48] <med_> nod, that's what I thought
[20:48] <marcoceppi> med_: but we have plugins, so you could create `juju deploy-only-if`
[20:50] <med_> ah, I've found: https://juju.ubuntu.com/docs/charms-deploying.html#deploying-to-machines
[20:50] <marcoceppi> med_: juju help deploy should also contain a good amout of information
[20:50] <med_> where do I read up on "deploy-only-if" or are you saying that's a plugin I need to write?
[20:51] <med_> I think you are saying I could write that myself in my copious free time.
[20:51] <marcoceppi> med_: yes, you could write that if you so wished to :)
[20:52] <med_> thanks marcoceppi . Fount of knowledge as per usual.
[21:21] <marcoceppi> hey sinzui for the charts on the review-queue how far back do they go?
[21:22] <sinzui> marcoceppi, The data varies. Some only from the moment the feature arrived in production.
[21:22] <marcoceppi> sinzui: anyway to have only show the last X months? Or possibly reset the stats?
[21:23] <sinzui> marcoceppi, not at this moment. jcsackett do you have any thoughts about marcoceppi 's question regarding http://manage.jujucharms.com/tools/review-queue
[21:23] <marcoceppi> sinzui jcsackett it's just defeating that the max wait time is 22 months
[21:23] <marcoceppi> that's not entirely accurate
[21:24] <marcoceppi> and average wait time is more like 5 days now, but because of such outliers it's going to take a long time to drop down
[21:24] <sinzui> I would think a breakdown of week, month, and quarter/year would be more informative
[21:25] <marcoceppi> I'm really just concerned with what the last 30 days have been as an average
[21:25] <marcoceppi> anything past that is just historical
[21:26] <sinzui> marcoceppi, I have some list of metrics to gather. We can definitely tune the sparklines since we need to revisit the data to gather the metrics
[21:26] <marcoceppi> sinzui: thanks! appreciate it
[22:29] <jcsackett> sinzui, marcoceppi: i think we can probably alter the window we're looking at without too much work. but truthfully the problem is i think you're interested in current max, not historical max. which is also probably not too difficult a tweak.
[22:30] <marcoceppi> well, max is one example, Really I just want to see a moving average of how long it takes for us to respond
[22:30] <jcsackett> marcoceppi: is it fair to say that min and max aren't really that useful? we added it in on one mention, but average is all i hear anyone talking about, really.
[22:31] <marcoceppi> I need to know, lets say, in the past X days, our average response time is X (hours hopefully, if not days)
[22:31] <jcsackett> marcoceppi: so i'm hearing a yes. you're not looking at min and max, really.
[22:31] <marcoceppi> Min and max are nice if they follow that same time window, but they're not nearly as important i odnt' think
[22:31] <jcsackett> sinzui, marcoceppi: how do we feel about just dropping display of min and max?
[22:32] <marcoceppi> jcastro: ^
[22:32] <jcsackett> i'd like to keep collecting it in case we need to craft a different report, but on review queue we could just show average.
[22:32] <sinzui> jcsackett, I don't think the min/max are interesting.
[22:33] <jcsackett> well, if jcastro doesn't object, i can whack the display of that and tweak average to only show the last 30 days worth of info in not too much time at all.
[22:33] <marcoceppi> jcsackett: Okay, executive decision, do that
[22:33] <marcoceppi> I dont' think jcastro will object
[22:34] <sinzui> jcsackett, given that the edges are exceptional, we may want to drop them
[23:32] <mxc> marcoceppi: does juju on ec2 use restrictive security group settings?
[23:32] <marcoceppi> mxc: what do you mean by restrictive security group settings?
[23:32] <mxc> well, basically i want to make sure that the mongo instances are only accessible from the app server instances
[23:33] <mxc> and the app servers are only accessible from haproxy
[23:33] <mxc> on azure, juju doesn't set up endpoint ACLs which is why your idea of an iptables subordinate service might have to be the way to go
[23:33] <marcoceppi> mxc: yes, juju on ec2 creates a sec group per unit and applies a restrictive setting. Only when juju expose is run does it open ports
[23:33] <mxc> ah, that was my question
[23:34] <mxc> so that would save me from having to create a separate instance
[23:34] <marcoceppi> mxc: if I understand you correctly, yes
[23:38] <mxc> i mean separate service
[23:38] <mxc> subordinated
[23:39] <marcoceppi> ah, then yes