[00:01] is there any timeline on the release of 1.23? [00:01] i thought it was out? [00:01] i was wrong. [00:05] jrwren: its still in devel ppa, close to release however [00:05] moqq: I cannot offer a hard ETA - but its rounding the final phase of Q/A and poking, i would imagine we'll see it land next week [00:06] great, thank you [00:06] lazyPower: that is what confused me. [00:06] jrwren: come at me and my actions bro https://github.com/chuckbutler/docker-charm/commit/e72fd0d5b21071806e661b8c0e548884e26d3f60 ;) [00:07] lazyPower: why me? [00:07] * jrwren runs away [00:07] because I like tormenting you when you're around? :D [00:07] hahaha. fair! [00:07] lazyPower: you should see some of the terrible things I've done lately :) [00:07] * lazyPower eyes narrow [00:08] lazyPower: foregone logstash-forwarder for beaver, because its easier. [00:08] oh yeah?! [00:08] bro, we need to talk about logstash server. [00:08] I've got a branch thats getting fairly mature, that needs third party eyes [00:09] lazyPower: we definitely need to talk, because I too have a branch. we need to come together. [00:09] are you running my branch for trusty in the UIX prodstack? [00:09] or did you fork it and cycle on your own stuff? [00:09] not yet [00:09] i forked your branch and hacked it up. [00:09] ok, so my thought is this [00:09] i just landed a big merge from IS that adds some nice goodies in there [00:10] think you can port those to your branch, and we can do a review on tests+polish+actions [00:10] https://github.com/CanonicalLtd/beaver-charm and https://code.launchpad.net/~evarlast/charms/trusty/logstash/trunk [00:10] adn then make a proposal for trusty? [00:10] I'll take a look. [00:10] oh man [00:10] you like, neutered half the relations [00:10] did i? [00:10] oh yeah. [00:10] major rework. remove ampq and redis, add raw tcp [00:10] we can put those back. [00:11] running redis server seems overkill. [00:11] just add raw tcp, and block config sections with jinja [00:11] well, are you running a 30 node cluster? [00:11] if gonna use redis, shouldn't i use the redis charm? [00:11] 30 node cluster + redis queueing = kinda the reference arch for this stack. [00:11] we shoudl be yeah [00:11] I found no evidence of any reference arch for this stack :) [00:12] hate me all you want - i got it from here: http://www.logstashbook.com/ [00:12] hey me too! [00:12] <3 [00:12] i got the paper copy [00:12] I'm really impressed with the typesetting. [00:12] Its really a pleasure to read. [00:13] so anywho - if your charm operates more reliably than the franken-java-monster we have now [00:13] lets converge on that - get IS to test it in staging and see how it goes [00:13] yeah, lets do that. [00:13] or OIL actually, they would probably be interested in this as well [00:13] see also, the warning on page 193 :p [00:15] I'm in malta starting Sunday - can you feesably look at this sometime in the next 2 weeks? I'll lend some later-workday-hours to pair [00:15] after the malta sprint, and we'll go from there [00:15] that timing matches us reasonably well. [00:15] i got poked by IS to get this thing in the CS sooner rather than later, and i'm doing one of these numbers @_@ [00:15] we are JUST getting this into a std. dev env. [00:15] another week we may have it into our staging env [00:15] ok sweet, so timing works then. [00:16] Take a look at this MP, and see if this makes sense to you - as this was the big feature branch they wanted landed pre-store-inclusion. http://bazaar.launchpad.net/~lazypower/charms/trusty/logstash/trunk/revision/47 [00:17] ha! ssl [00:17] kind of important really :) [00:17] so... SSL was a reason I went beaver isntead of logstash-forwarder [00:17] <3 them for contributing that [00:17] its entirely unimportant if you aren't accepting logs from outside. [00:18] all the comms from LS to ES are entirely unencrypted. [00:18] its faux security [00:18] and much added complexity [00:18] but cool that they did it as config. [00:19] before I gave up on it I was considering self signed generation and serving that to LSF on relation get [00:19] there's charmhelpers to take care of SSL generation/consumption [00:19] nice. [00:19] you know about this right? [00:19] i've not seen that part of helpers [00:19] 1 sec, fishing link [00:20] so far this patch is +10 [00:20] http://bazaar.launchpad.net/~charm-helpers/charm-helpers/devel/files/head:/charmhelpers/contrib/ssl/ [00:22] very cool. [00:22] http://bazaar.launchpad.net/~charmers/charms/trusty/nagios/trunk/revision/12 [00:22] line88 = consuming of that code, and generating self signed certs [00:22] er, line88 of upgrade-charm hook [00:23] so those may help you moving forward when you need SSL certs [00:23] and you can use self-signed certs [00:23] i nkow there are many cases where that ignites fire, and causes headaches. Namely when dealing with anything on the consuming end that expects a valid CA Signed SSL certificate [00:24] yeah, so that works for that use case. [00:24] in term so flogstash - you could push to /usr/local/share/ssl/ca-certificates/ and run update-ca-certificates, and the self signed would no longer raise alarms. [00:24] *push the ca cert [00:25] and that could be done w/ base64 encoding over a relationship [00:25] logstash-forwarder has a ca config line [00:25] so perfect [00:25] yes, exactly what I was considering [00:25] \o/ [00:25] but now I don't need it :p [00:25] i find your lack of encryption disturbing ;) [00:25] *shrug* [00:25] i worked at a security company :p [00:26] it get... complecated. [00:26] for example, what do you do when you add more units to the logstash service? [00:27] in terms of ssl? [00:28] the way i see it, you have 2 options. hand over all the keys in a peer relationship and install them or 2) go nuts generating keys and do key management [00:30] you'll have to do 2 [00:30] because with 1 your CN no longer matches the address to which you are connecting [00:32] fair, i had not thought about CN based rejections. Stinking common name validation [00:34] so you have to use subject alternative names [00:34] which is not so easy to automate in openssl command lien [00:35] I would love to see it done :) [00:35] heck, at that point, someone could write up a very nice "run your own CA" charm :) [00:37] so all that said, I see great value in both solutions, hence our building of that beaver charm last week. [00:40] fair enough - i can see/understand the need to GSD before you tackle the wall [00:50] jrwren: i forgot about UOS coming week after the sprint. if we get slammed lets touch base at least and see where we're at in terms of time/exploration. [00:50] and with that note, i'm goign to head out for the evening. Cheers o/ [00:51] gnight lazyPower travel safely [01:03] this is correct?: JUJU_DEV_FEATURE_FLAG=actions juju bootstrap [01:05] ahhhgg. juju destroy-environment appears to leave the vagrant box image in an unusable state. after i destroy the initial environment and try to bootstrap again, i only get “ ERROR juju.cmd supercommand.go:430 cannot initiate replica set: cannot get replica set configuration: cannot get replset config: not authorized for query on local.system.replset” === kadams54-away is now known as kadams54 === kadams54 is now known as kadams54-away [03:27] * thumper frowns [03:27] wallyworld: you around? [03:27] yeah [03:28] so I'm trying to upgrade my ec2 env [03:28] it is currently using 1.20.14 [03:28] my client is 1.22.1 [03:28] juju upgrade-juju says: "no upgrades available" [03:28] any idea why? [03:29] um [03:30] do you have a tools-url setting in use? [03:30] * thumper looks [03:30] just saw this in the code :-( [03:30] // No tools found and we shouldn't upload any, so if we are not asking for a [03:30] // major upgrade, pretend there is no more recent version available. [03:31] why oh why [03:31] juju get-env tools-url says nothing [03:31] ? [03:31] might be tools-metadata-url [03:31] 2015-04-24 03:16:00 DEBUG juju.cmd.juju upgradejuju.go:367 found more recent current version 1.20.14 [03:31] 2015-04-24 03:16:00 INFO juju.cmd cmd.go:113 no upgrades available [03:31] so that comment was from the upgrade code [03:31] that is from the log [03:32] this is a very vanilla ec2 deploy [03:32] I'm wondering why we are telling people there are no upgrades available when there obviously are [03:33] me too [03:33] ok, what about juju metadata validate-tools (i think) [03:33] i’m glad i wasn’t going crazy then [03:33] i thought that was strange too [03:34] wallyworld: what does the validate tools do? [03:34] if prints the available tools and where it finds them [03:34] or more accurately, the tools it would use [03:34] http://paste.ubuntu.com/10876012/ [03:35] so... WTF? [03:35] ok so that's good [03:35] good in that your client can fin the expected tol [03:35] tools [03:35] bad in that it refuses to use them [03:35] so we can narrow down where to look for the issue [03:36] i'll read the code a bit to see if anything jumps out === scuttlemonkey is now known as scuttle|afk [03:36] wallyworld: also, (since I'm not working today) can you file a bug about the help text for upgrade-juju? [03:36] wallyworld: it still says minor numbers are dev versions [03:36] sure [03:37] wallyworld: I did 'juju upgrade-juju --version 1.22.1' and it worked [03:38] hmmm, so the automatic new version selection fails [03:38] the relevant comment [03:38] // No explicitly specified version, so find the version to which we [03:38] // need to upgrade. If the CLI and agent major versions match, we find [03:38] // next available stable release to upgrade to by incrementing the [03:38] // minor version, starting from the current agent version and doing [03:38] // major.minor+1. If the CLI has a greater major version, [03:38] // we just use the CLI version as is. [03:38] anyone know how you get a charm added to trusty? bip is currently only in precise, I followed what looked to be the instructions at https://jujucharms.com/docs/stable/authors-charm-store#recommended-charms and filed LP#1401774, but there is literally no movement. [03:39] bradm: marcoceppi_ would be one person to ask, i have NFI [03:40] I filed this bug about 4 months ago now.. [03:40] marcoceppi_: can you have a look at LP#1401774 when you're about and have time? trying to get the bip charm into trusty. [03:41] thumper: one guess i have quickly looking at the code is that we still seem to expect to only upgrade from x.y to x.y+1 [03:42] that's if we don't specify an explicit version [03:42] so in your case, it was looking for 1.21 [03:42] hmm... [03:42] not sure why it couldn't find that [03:42] and anyway, that's wrong [03:42] * thumper nods [03:42] * thumper goes to make a coffee [03:42] i'll file a bug [03:47] hey i can’t find in the docs anything detailing exactly what ports/routes are needed between the juju client and the rest of the cluster. is it ssh from the client machine to every machine in the cluster? [03:47] and what the “tools storage” port 8040 is exactly used for / by whom [03:50] moqq: tools storage port is no longer used for new installs [03:50] oh excellent [03:51] the main port is 17070 used to connect the client to the state servers [03:51] and ssh [03:51] the 17070 is a mongodb port? [03:51] the client can ssh to each node, but it can proxy via the state server i think [03:51] ah ok [03:52] no, mongo uses 37017 [03:52] but only the state server connects to that [03:52] okay. and there is only one state server per cluster? [03:52] per ‘environment’ * [03:53] by default, but there is high availability also so a cluster of state servers is supported [03:53] ah ok [03:53] 1, 3, 5, 7 etc [03:53] odd numbers because it uses a mongo replicaset [03:53] yep [03:53] so, to issue commands to an environemnt (like deploy or actions), the machine running the juju client needs only to be able talk the master server(s) via tcp 37017 [03:53] correct? [03:53] 17070 [03:54] erm* [03:54] yes [03:54] yes [03:54] excellent, thank you [03:54] sure, np [03:54] i can't recall if ssh proxy is enabled by default [03:55] if it is, you can also ssh to worker nodes via the state server also, so 17070 should be all you need the client to connect to [03:55] yeah that makes sense. neat [03:55] just curious, what protocol is it carrying over 17070? [03:57] proxy-ssh is true by default for new environments [03:57] websocket [03:57] over https? [03:57] https based [03:57] awesome [03:57] when an env is bootstrapped, certs are generated [03:57] i saw those in there, that makes sense. [03:59] thanks again for the info. getting this into production with a handful of custom charms over the coming week and a half so i will likely have a few more inquiries! [04:02] moqq: sure, np. there's more people in #juju-dev so you will have most luck asking in there [04:02] ask any questions and we'll try and help [04:02] there's also the mailing list [04:02] good luck with the roll out [04:07] awesome, thank you [04:22] bradm: Updates to trusty are predicated by test inclusion - if you can contribute some amulet tests to the bip charm it would expedite the process [04:22] ah disregard, i made that statement while still reading backlog and not looking @ the bug [04:22] * lazyPower stands in teh corner [04:36] lazyPower: ayup. as far as I can tell there's tests there. I might need to update the branch from precise trunk since its been filed so long ago [04:37] bradm: sorry about that - i dont see it in our RevQ, and id ont know why thats the case [04:37] status new + linked branch should have pulled it in [04:37] lazyPower: I'm planning to rewrite it in services framework, it should be pretty simple [04:37] :thumbsup: I look forward to seeing that :) [04:37] lazyPower: no worries, I couldn't see it in the review queue either, so I finally got time to go looking [04:37] lazyPower: I have a couple of thruk charms to throw charmers way once I get tests added [04:38] lazyPower: those are all in the services framework [04:39] lazyPower: anyway, for the bip charm push up to trusty, if we can get it on someones radar to see whats going on, that'd be awesome. its not a hugely high priority, bip is kind of my play charm that I push along when I get a chance === urulama__ is now known as urulama [08:14] I thought I'd give juju a go on my freshly installed 15.04 server, but juju-quickstart fails. It seems to assume the system is using upstart (it fails on start juju-db) [09:09] hmm, can I file/reassign a bug to a specific charm? Seems I can only assign to "charms" project [09:19] marcoceppi_, hey - how do I see why the charm release yesterday has not ingested into the store? [09:20] jamespage: great question, no idea anymore. If it passes proof it should be ingested. Are you not seeing it in the gui or not deployable? [09:21] marcoceppi_, https://jujucharms.com/cinder/ [09:21] vs the branch on launchpad [09:21] https://store.juju.ubuntu.com/charm-info?charms=cs:trusty/cinder [09:21] seems revision 18 is in the store [09:22] this is a charmstore api thing, you'll need to ping rick_h_ & co to investigate [09:23] jamespage: actually, they do seem to be the same [09:23] so this might be a larger issue [09:24] * marcoceppi_ investigates [09:25] jamespage: it seems that what's in lp:~openstack-charmers/charms/trusty/cinder/trunk is in the charmstore proper [09:25] the gui seems to have the same revision, but the revision history is off [09:26] which makes sense, I think the api is mid-transision away from tracking dvcs info [09:26] rick_h_ and the ui team would know more [10:54] jamespage: marcoceppi_ there's a bug with the new charmstore not getting the up to date changelog and the guys on are it. The charm itself, the readme, etc is all good but it's missing the latest revisions in the changelog. [11:07] rick_h_: that's what it seemed like, I figured we were just going to drop that in a juju publish world [11:07] marcoceppi_: well our goal will be to try to keep it if we can tell but yea. Might end up being a link to the homepage/etc [11:09] rick_h_: ack, thanks for the clarification [11:18] Hey, guys,. I run `juju run --service myservice "someSuperDuperStuff.sh`, and that fails with timeout for some units. But at the same time I'm able to do 'juju ssh myservice/{0,1,2,3...}' with no problem(s) [11:19] how is juju run implemented, and why whould it time out, how do I start debugging this? [11:28] Mmike: juju run is run as a hook context, so if you have hooks running or is someSuperDuperStuff.sh never exits [11:28] it'll timeout [11:43] marcoceppi_: aaaa, makes sense! [11:43] marcoceppi_: thnx! :) [11:43] i do have hooks still running [11:48] Mmike: so the juju run is queued [11:49] Mmike: you'd probalby be interested in actions, which is like run with some structure and async nature [11:51] marcoceppi_: for now I can really do 'juju ssh' in a for loop [11:51] marcoceppi_: is there a document(ation) describing how to use juju actions? [11:53] Mmike: yes, there is: https://jujucharms.com/docs/stable/authors-charm-actions [11:53] oh [11:53] neat! [11:53] marcoceppi_++ thnx [12:08] jamespage: is this the proper cinder now? https://jujucharms.com/cinder === kadams54 is now known as kadams54-away === kadams54-away is now known as kadams54 === scuttle|afk is now known as scuttlemonkey === 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 === mattgrif_ is now known as mattgriffin === liam_ is now known as Guest67926 === SR is now known as Guest89666 === urulama is now known as urulama__ [17:30] Hi - is there a way to specify a revision of the launchpad branch for a charm in deployer bundles? === kadams54 is now known as kadams54-away === kadams54-away is now known as kadams54 === mattgrif_ is now known as mattgriffin === kadams54 is now known as kadams54-away [20:23] is there any way to expose a port on a unit from the juju CLI? [20:25] nope [20:25] ok how about any way to expose a port besides the hook context [20:27] doesn't look like I cna change it from the aws console [20:29] yeah, you can, edit the security group. [20:32] hatch: juju run --service "open-port 80" [20:33] Anon hook context == hook context. I use this when developing and i forget to set an open-port statement. [20:33] lazyPower: very cool trick! Thanks! [20:33] been looking for that for a year(almost) is it documented? [20:34] (not that I could find) heh [20:34] well juju run is [20:34] so this is just a really cool technique :) [20:36] the key there is that the unit tools path is in PATH when using --service. That is great! [20:38] bah, its right there in the juju run help. Now I feel stupid. [20:38] haha I didn't even think to try juju run so... :) [20:39] Tricks of the trade [20:44] thanks again lazyPower [20:44] cheers === scuttlemonkey is now known as scuttle|afk === kadams54-away is now known as kadams54 === kadams54 is now known as kadams54-away