| === waigani_ is now known as waigani | ||
| === freeflying_away is now known as freeflying | ||
| === CyberJacob|Away is now known as CyberJacob | ||
| === rogpeppe1 is now known as rogpeppe | ||
| yolanda | jamespage, btw, were you able to take a look at heat? | 12:02 |
|---|---|---|
| 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:30 |
| marcoceppi | mthaddon: interesting Why are you even changing the revision? Juju should do that for you during upgrade-charm | 12:57 |
| ashipika | hey all.. just a quick one.. on bootstrap (in a VM): ERROR juju supercommand.go: 282 unrecognised architecture: precise | 13:12 |
| marcoceppi | ashipika: precise isn't an architecture, it's a series. What bootstrap/deploy command are you running? | 13:16 |
| 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:17 |
| === gary_poster|away is now known as gary_poster | ||
| 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:21 |
| 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:22 |
| 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:24 | |
| 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:28 |
| ashipika | that is why it fails to properly parse the architecture | 13:29 |
| ashipika | and gets the series instead | 13:29 |
| X-warrior | morning | 13:47 |
| === BradCrittenden is now known as bac | ||
| 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? | 13:58 |
| 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:17 |
| marcoceppi | jamespage: ah, cool | 14:18 |
| === liam_ is now known as Guest41957 | ||
| === freeflying is now known as freeflying_away | ||
| jcsackett | sinzui: fighting g+, be at the 1x1 in a few. | 15:31 |
| 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? | 15:48 |
| 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:02 |
| jamespage | jcastro, yes - thats right | 16:04 |
| marcoceppi | jcastro howto-amulet.html probably | 16:05 |
| jcastro | authors-amulet.html seems to match more? | 16:06 |
| jcastro | actually howto is fine | 16:06 |
| jcastro | ok let's do that. :) | 16:06 |
| 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:17 |
| marcoceppi | jcastro: it looks like you did a bzr push twice for two different branches? | 16:45 |
| jcastro | yeah I dunno why it did that, sent nick a mail and he'll just pull from the right one | 16:47 |
| jcastro | hey sinzui | 17:23 |
| jcastro | I am doing my talk proposal for SCaLE 12x in February. | 17:23 |
| 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:24 |
| 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:25 |
| 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:26 |
| sinzui | manual-provider actually | 17:27 |
| 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:28 |
| 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:29 |
| arosales | utlemming, but really nice work ! | 17:30 |
| jcastro | yeah you can't call it quickstart | 17:30 |
| 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:31 |
| utlemming | hrm, I agree. If the effect is the same, Quickstart plugin vs Quickstart images, conveys the same idea: getting quickly started | 17:32 |
| jcastro | yeah | 17:33 |
| * marcoceppi is having flashbacks to bundle discussion wrt naming | 17:34 | |
| 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:36 |
| 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:37 |
| jcastro | utlemming, typo "Chose" the box in your header | 17:40 |
| jcastro | also why not recommend 12.04 by default? | 17:40 |
| 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 | 17:47 |
| === liam_ is now known as Guest7421 | ||
| jcastro | rick_h_, yeah, we should def keep that in mind | 18:10 |
| 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:17 |
| lazypower | marcoceppi: this is basically the route we took when you came up to visit. | 18:19 |
| mxc | have some juju security questions | 19:26 |
| mxc | which i haven't been able to answer from reading the docs | 19:27 |
| mxc | specifically fire walling, creating juju instances, without exposing them (on azure at least) opens up a public port 22 to the world | 19:30 |
| === mhall119 is now known as mhall119|afk | ||
| 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:31 |
| sarnold | mxc: investigate the subordinate charms | 19:32 |
| mxc | thanks, but I may be missing something. | 19:35 |
| 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:36 |
| 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:43 |
| 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:44 |
| mxc | i create a ufw subordinate charm, add it to my config for the mongo charm etc | 19:45 |
| mxc | thanks! | 19:45 |
| med_ | marcoceppi, is co-location still called co-location (kind of a meta question) | 20:44 |
| 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:46 |
| 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:47 |
| 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:48 |
| 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:50 |
| 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:51 |
| med_ | thanks marcoceppi . Fount of knowledge as per usual. | 20:52 |
| marcoceppi | hey sinzui for the charts on the review-queue how far back do they go? | 21:21 |
| 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:22 |
| 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:23 |
| 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:24 |
| 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:25 |
| 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 | 21:26 |
| === dspiteri is now known as DarrenS | ||
| 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:29 |
| 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:30 |
| 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:31 |
| 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:32 |
| 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:33 |
| sinzui | jcsackett, given that the edges are exceptional, we may want to drop them | 22:34 |
| 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:32 |
| 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:33 |
| mxc | so that would save me from having to create a separate instance | 23:34 |
| marcoceppi | mxc: if I understand you correctly, yes | 23:34 |
| mxc | i mean separate service | 23:38 |
| mxc | subordinated | 23:38 |
| marcoceppi | ah, then yes | 23:39 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!