[00:00] i did some chaos monkey'ing around in here, it seems to be in order [00:00] achievement unlocked: chaos monkey! [00:00] lazyPower: fairy nuff [00:01] sarnold: thats my middle name ;D [00:01] lazyPower: hahaha [00:01] or was it murphys law.... [00:01] i forget, either way :P [00:10] hey lazyPower [00:10] did we test tomcat on trusty too? [00:23] jcastro: nope [00:23] just precise [00:23] its a good candidate for trusty though, it has a really extensive suite of tests [00:24] yeah, I'll ask tomorrow [00:24] might be a nice one to kick it off [00:25] guys, after config-changed the service isn't stopped/started, right? [00:27] jose: no [00:27] good then, thanks! [01:06] jcastro: I just kicked off a test, fyi [01:07] against trusty [01:11] hum, so we don't have trusty images in hpcloud [01:12] sinzui: is CI testing juju-core against trusty? === timrc is now known as timrc-afk [01:53] haha, so you can deploy a subordinate charm, ie: cs:trusty/unattended-updates and relate it to a precise deployed service [01:54] marcoceppi: urk [01:54] that's bad [01:54] haha [01:54] ¯\_(ツ)_/¯ [01:54] series, what series [01:54] shhhhhh, just relate [01:55] marcoceppi: nice find :) [01:55] sarnold: we're entering a world where we have more that one series [01:55] this is new stuff [01:55] a wholleee newwww worrrllddd [01:56] davecheney: yeah, the fact that it hasn't been in issue for two years means it could run some pretty deep ruts in the brain :) [01:56] http://www.tickld.com/cdn_image_thing/662763.jpg [01:56] * davecheney has lost sleep over this [01:58] http://i.imgur.com/L2ASIya.gif [02:01] the dutch uzi queen [02:01] boom chakalaka [02:02] mmm, dutch uzi [02:03] I got some mysterious networking issues trying to run lxc on a virtualbox and expose that to my physical host [02:04] hobbyBobby: i can see how that wouldn't work out of the box [02:04] -ETOOMANYNATS [02:04] saw the tutorials on exposing containers to my network, but I think there's a second level of indirection I must follow [02:05] hobbyBobby: so, you've got your machine, running virtualbox, with ubuntu inside, and inside that are some lxc containers ? [02:05] yep [02:05] davecheney: i was mistaken [02:06] davecheney: trying to access from host [02:06] cannot add relation principal and subordinate services series must match [02:06] hobbyBobby: which host [02:06] marcoceppi: \o/ [02:06] writing software for the win! [02:06] davecheney: the virtualbox host [02:06] hobbyBobby: the host inside virtualbox, or the host hosting virtual box [02:06] sorry to be a pedant [02:06] when it comes to networking [02:07] this matters [02:07] davecheney: its ok, it's confusing, the physical honest to goodness metal [02:08] davecheney: verified juju-gui comes up when I don't try to change networking [02:08] davecheney: but when I do, it bootstraps ok but juju-gui fails to start [02:08] hobbyBobby: change networking ? [02:09] davecheney: using this as a guide http://askubuntu.com/questions/281530/how-do-i-run-juju-on-a-local-server [02:09] hobbyBobby: hat guide assumes your running ubuntu on the ohst [02:10] not inside virtual box [02:10] davecheney: and using a bridged network inside the juju vm. I kinda figured that as soon as we started chatting [02:10] still won't help i'm afraid [02:10] all the local machines will have 10/8 addresses [02:10] and there is no routining from your host to those [02:10] even if they are on a bridged network [02:12] davecheney: so no way to say bridge the guest network to the guest lxc network [02:12] *host [02:13] hobbyBobby: in theory yes, in practice, not [02:13] no [02:14] davecheney: wow, bad times, there goes my dream of a self-contained cluster I can show off [02:15] hobbyBobby: you could try adding a route to 10/8 from your host to the bridge network that virtual box sets up [02:15] that might work [02:15] not tested [02:16] is anyone else having problems conecting to bazaar? [02:16] davecheney: ok, yea, I definitely could try that, thanks [02:24] hobbyBobby: do you need it exposed beyond the dev cycle? [02:24] sshuttle would be a good ansewr to this problem [02:24] marcoceppi: jose is. he just opened an is ticket [02:24] not actually an IS ticket, but reported and they're investigating the issue [02:24] ugh, all I want to do is work [02:24] I was so happy branching and pushing :( [02:25] its all these mp's i just acked [02:25] fwiw, it's back [02:25] lp knew something was up and went away to force us to take a break [02:25] [02:25] lazyPower: not just now, but I would like it to be able to run off of windows [02:25] apparently, marcoceppi is magic [02:25] hobbyBobby: sshuttle is not a permanent fix then. The idea behind sshuttle is a cheap VPN bridge into the remote network. [02:26] davecheney lazyPower second trusty charm promulgated, tomcat [02:26] and works wonders when just doing dev work or securing the odd hotel-wifi connection. [02:26] marcoceppi: AWESOME! [02:26] matt's going to be jazzed [02:26] marcoceppi: maybe follow up on my email :3 [02:26] lazyPower: going forward, new charms should be trusty tested and considered for promotion at promulgation time [02:26] be like "and this is how easy it is to get acked to trusty with good tests" [02:27] well, I found a million problems in amulet [02:27] * lazyPower flips tables [02:27] as in, without a lot of gental but forceful massaging it doesn't play nice with trusty [02:27] but that's because we don't have a lot of trusty charms [02:27] and it tries really hard [02:27] but it's just not good enough [02:28] probably need to map out that fix during our sprint [02:28] hopefully next cycle we can get some more resources on charm-tools and amulet [02:28] lazyPower: thanks, maybe that kind of thinking will bring me out of the box [02:28] i'd love to pick up the banner on that... but i dont think i'm ever going to get out of the queue at the rate its going. [02:29] which is an awesome problem to have... dont get me wrong [02:57] marcoceppi: would chef-server be considered an application-server or an application? I'm leaning towards application... but i could also just be pedantic.... [02:58] lazyPower: does it matter? [02:58] well, its nto really serving anything [02:59] so it doesnt make sense to be an application-server... and if we want the categories to be clean cut with whats put in there.. i mean you dont want postgres living in misc do you? [03:00] marcoceppi: i'm getting picky... dont mind me === vladk|offline is now known as vladk === cmagina_ is now known as cmagina === vladk is now known as vladk|offline === vladk|offline is now known as vladk === CyberJacob|Away is now known as CyberJacob === CyberJacob is now known as CyberJacob|Away === timrc-afk is now known as timrc === timrc is now known as timrc-afk [13:05] marcoceppi, CI tests that trusty deploys and upgrades. It runs the unit tests on trusty too [13:12] sinzui: yeah, I realized there was a default-series key, but I couldnt' get a bootstrap on HP Cloud [13:13] marcoceppi, HP doesn't support trusty yet [13:13] sinzui: cool, just wanted to make sure [13:13] marcoceppi, I have not gotten trusty to work on it, though I last tried 2 weeks ago [13:13] well, didnt' work last night [13:20] mbruzek, hey so what's the workflow for the tomcat charm [13:20] like .... let's say I have a war file [13:20] juju deploy tomcat [13:21] juju deploy openmrs [13:21] juju add-relation tomcat openmrs [13:21] juju deploy mysql [13:21] juju add-relation openmrs:db mysql:database [13:21] profit! [13:21] ok so it basically deploys other charms that use tomcat? [13:22] does it do like, my tomcat apps? [13:22] openmrs is a subordinate [13:22] got it [13:22] so the apps need to be made into subordinates to use it? [13:22] Robert Aryers had a j2eedeployer charm in his personal space where you could put a random war in and deploy [13:23] I haven't scoped that one out yet, but that is a good idea to add to the list [13:23] ok [13:23] so this charm is for people who want to charm up their tomcat apps [13:23] j2ee-deployer is the charm name. [13:24] Yes. My thought is the j2ee-deployer charm may be too generic [13:24] :) mbruzek congrats on that awesome charm [13:24] Thanks lazyPower [13:24] hey so j2ee-deployer is a sub [13:24] could you plop your war file in there and then relate that to tomcat? [13:25] In my opinion the j2ee-deployer charm was too generic though. Often WAR files (such as openmrs) need a database connection, and it is very difficult to do "generic" database relations for j2ee-deployer [13:25] * jcastro nods [13:25] ok so let's say I have my app I wrote, myapp [13:25] how does this charm help me [13:25] jcastro, Yes that is the model for j2ee-deployer, but only if the WAR file does not need a db or other relations, if it does they need to charm up their own charm [13:26] * jcastro nods [13:26] The tomcat charm offers some more advanced configuration options, for clustering, JNDI, and a robust container for subordinate charms that want to deploy inside it [13:27] ok I have pretty much given up us ever having nice URLs [13:27] so I am linking to the manage pages. :( === timrc-afk is now known as timrc [13:29] mbruzek: j2ee-deployer can deploy custom web apps with DB relations fine [13:30] should we demote tomcat6 and tomcat7 now in the charm store or .... ? [13:30] Well you wrote it so you would know [13:30] ok, so if people want to just deploy a war file, then j2ee-deployer is for them [13:30] that sound right? [13:30] jcastro, that was my plan to demote the other 2. [13:32] jcastro: sure, if they work within the framework of the charm, then they can deploy their custom apps fine [13:32] ok [13:32] we should likely finish that up and put that in the store [13:33] bbcmicrocomputer, how's your time these days? :) [13:33] jcastro: j2ee-deployer works where the user just wants to drop their existing app in a Juju environment, but doesn't want to write a charm [13:33] ok so we've got both use cases covered then, [13:33] jcastro: anything more specific and they can roll their own charm [13:33] jcastro: sure [13:36] jcastro: I have no time atm unfortunately [13:37] jcastro: would love to finish off my work on the Java charm eco-system [13:37] Is there a charmhelper to temporarily change the current directory (ideally, a context manager)? [13:52] cory_fu: not that I know of [13:52] cory_fu: you would write one :) [13:52] cory_fu: there is an os.environ['CHARM_DIR'] [13:52] cory_fu: so you can always find your way home [13:53] cory_fu, probably, but it's just as fast to write one [13:54] Yeah, it was pretty simple. I'll probably still add it to charmhelpers, though, because it seems useful. [13:54] there's no place like os.environ['CHARM_DIR'] [13:54] cory_fu, save cwd, mkdtemp, chdir td [13:54] ba dum psh [13:55] cory_fu, try this, http://stackoverflow.com/questions/169070/python-how-do-i-write-a-decorator-that-restores-the-cwd [13:55] oh nm, path is a new module [13:55] just roll your own [14:00] Is anyone else having issues creating machines using a local provider? I'm running on trusty with latest lxc and juju-core/local... machines sit in an indefinite pending state [14:00] no action in /var/lib/lxc (e.g. the containers are not actually being created) [14:00] lxc 1.0.3-0ubuntu3 and juju-core/local 1.19.0-0ubuntu1~14.04.1~juju1 [14:03] timrc: that could be a myriad of reasons why its not booting. Hav eyout ried removing the cached image file and starting from a pure scratch? [14:03] also, is there any output in the all-machines/machine-0 log? [14:04] lazyPower, yeah plenty of output.. machine 0 seems to "start" fine... there is no log that I can find not even the cloud-init log in the .local file that even mentions any of the other machines its suppose to be starting [14:04] well machine 0 isn't an lxc machine [14:04] it occupies space on the host [14:04] I have tried removing everything from /var/cache/lxc as well as /var/lib/lxc [14:05] lazyPower, Right, I'm just saying that there is plenty of logging for machine 0 and absolutely no mention of any other system even though juju status shows them all "Pending" [14:05] but it should tell you more information about whats going on under the radar - like "Unit failed address assignment, not booting" is what i nromally see since my network setup is ridonk [14:05] I'm going to try to teardown apparmor and try again [14:05] ok sorry i wasn't more help :( [14:14] * timrc yearns for the day when this Just Works (tm) longer than a week before it breaks [14:14] * timrc switched back to a older "known good" version of juju-core/local and still having the issue, so I'm thinking it might be an issue with lxc. Will try switching back to an older version of that now [14:24] lazyPower, do you have any objection to me pushing and promulgating the rabbitmq charm for trusty? [14:24] try to get a full openstack deploy from charmstore on 14.04 for release tomorrow [14:24] jamespage: I dont have a problem with it, you're known for testing and stressing charms [14:25] if there's an outcry for blood do you mind if i signpost them to you? [14:25] jamespage: there's a series of tests that mbruzek wrote for rabbitmq i believe [14:26] if you could get those included, then there wouldn't be any extra special need for that - it would satisfy the store reqs. I don't think those tests made it into the charm yet though [14:27] lazyPower, not yet no [14:28] hmm - I have the same issue with mysql and mongodb [14:29] i can tell you the mongodb tests i wrote will fail - it worked prior to a merge in the charm [14:29] and i haven't had a chance to get back to triage those tests [14:29] jamespage: if you've got some high priority stuff you need me to expedite just ping me with the MP and i'll take a look [14:29] jamespage: I'm writing tests for MySQL [14:29] jamespage: they should be in before trusty [14:30] and MySQL in trusty charm is a priority for me in general [14:49] Why does charm test continue if 00-setup fails? Is there any way to prevent that? [14:50] Ah, --set-e. Seems like 00-setup should be a special case that always implies --set-e [14:58] https://juju.ubuntu.com/docs/reference-release-notes.html [14:58] hey so I found out this exists ^^^^ [15:07] jcastro: evilnick emailed the list about that on monday [15:07] cory_fu: not necessarily. Its predeps for the host env running the tests. [15:30] can someone help me get my local provider working? [15:30] ERROR state/api: websocket.Dial wss://10.0.3.1:17070/: x509: certificate signed by unknown authority (possibly because of "crypto/rsa: verification error" while trying to verify candidate authority certificate "juju-generated CA for environment \"local\"") [15:30] I keep getting this [15:31] I've tried every trick reseting the local environment I can think of === vladk is now known as vladk|offline [16:17] marcoceppi, coolio [16:18] marcoceppi, do you know if anyone is working on mongodb for trusty? [16:18] jamespage: not that I'm aware [16:18] it works ok on trusty albeit in a single node [16:19] jamespage: the clustering is only protocol stuff, so it should be bueno if it works single node. I'd be game to work with the scaled bundle for testing after my current work queue is complete [16:19] lazyPower, cool [16:27] hazmat: hey, i am hitting an issue similar to bug 1287718 in the cts cloud. curious if there is any workaround? [16:27] <_mup_> Bug #1287718: jujud on machine 0 stops listening to port 17070/tcp WSS api

[16:29] psivaa_, it should auto restart, ie transient issue [16:29] psivaa_, if its not restarting.. please attach /var/log/juju/machine-0.log to the ticket [16:30] hazmat: ack, it's not for me. i'll attach the log to the bug === hatch__ is now known as hatch [16:35] psivaa_, re workaround.. you can restart the juju agent on that machine [16:36] ie. sudo service jujud-machine-0 restart [16:41] hazmat: tried restarting the machine, mongodb, and jujud-machine-0 but without any improvement :/ [16:41] i've commented on the bug [16:43] psivaa_, that's strange [16:43] * hazmat takes a look at the log [16:46] hazmat: 1.18.1-0ubuntu1~14.04.1~juju1 is my juju version, if that matters === psivaa_ is now known as psivaa [16:50] hazmat: http://paste.ubuntu.com/7262521/ contains the logs after juju agent restart. [16:51] i'll attach that too to the bug [16:51] psivaa, thanks. sorry helping someone else right now.. free in 15m [16:52] hazmat: np, i'll wait :) [16:55] psivaa, back [16:56] hazmat: 10.230.21.113 is the ip of the bootstrap machine, in cts lab [16:57] psivaa, what architecture are you on? [16:57] hazmat: amd64 on both local and the instance [16:59] psivaa, ic the restarts but only one case where there's a panic.. what exactly are you symptoms ? [16:59] psivaa, ie you can't run juju status? [17:00] hazmat: i keep getting 'ERROR state/api: websocket.Dial wss://192.168.1.2:17070/: dial tcp 192.168.1.2:17070: connection timed out' [17:01] psivaa hmm. that's odd.. is there a network firewall between you and the state server? [17:01] psivaa, ic the state server listening on all ip addresses on that machine [17:03] hazmat: there are some additional restrictions for the instances. let me pm the details pls [17:11] psivaa, so let's verify connectivity to the state server from the host, and then verify off host.. [17:11] ie. from the machine.. telnet 192.168.1.2 17070 [17:11] and then do the same from off host [17:11] hazmat: http://pastebin.ubuntu.com/7262626 is the netstat [17:11] psivaa, if your going through firewalls/bastions to get to your machine [17:12] you may need to sshuttle into it to create a pseudo vpn for connectivity [17:12] psivaa, yup.. so its doing the right thing and trying to listen on all net addresses [17:12] hazmat: i am able to telnet to that ip [17:12] psivaa, from outside of the machine? [17:13] hazmat: no, one sec pls. i misunderstood [17:14] psivaa, wanted to try both.. so its good to know it can be connected from on machine as well. [17:15] hazmat: should i be able to telnet to 192.168.1.2 from my local host [17:15] hazmat: i dont have anyother instances in that network to try within it [17:15] psivaa, if you expect juju client to be able to talk to it.. yes [17:16] psivaa, ie. underlying issue your having is network connectivity.. sshuttle can help you bridge the connectivity [17:16] hazmat: ack, let me try that. thanks === roadmr is now known as roadmr_afk [17:48] hazmat: sorry to bother you again.. the same issue is present even after sshuttling in to the instance: http://pastebin.ubuntu.com/7262777/ === psivaa is now known as psivaa-afk [18:03] psivaa-afk, your not sshuttling the correct address range [18:03] ie you need 192.168.2.0/24 [18:04] your shuttling 10.x addresses, when its clearly connecting to 192.168.x addresses === roadmr_afk is now known as roadmr === CyberJacob|Away is now known as CyberJacob [19:02] ahoy! I've deployed postgresql using juju, and I'm trying to get connected, but I don't think I have a user or a database yet. Can I create those without connecting another charm to postgres? [19:05] nuclearbob: it creates those for you at time of relationship creation [19:05] and provides it via the relationship hooks [19:06] lazyPower: since I don't have any other instances, how do I create that relationship? [19:06] nuclearbob: of? [19:06] lazyPower: I want to connect using psql on my workstation [19:06] ahhhh ok. [19:06] I'm fairly certain there's some administrative credentials in the log after deployment.. marcoceppi ^ insight? [19:08] nuclearbob: check the README and ask stub [19:08] marcoceppi: is this the README, or something else: https://manage.jujucharms.com/charms/precise/postgresql [19:09] nuclearbob: the README is on that page [19:09] nuclearbob: there's also a psql charm, that is a service you can deploy to attach to [19:09] marcoceppi: I [19:10] 'd like to avoid deploying more instances than I need to since my openstack provider is chronically oversubscribed, but I can try the psql charm if it comes to that [19:10] nuclearbob: yeah, stub the author wouuld be able to help you out [19:11] marcoceppi: thanks, I'll see if stub replies === mattgriffin is now known as mattgriffin-afk [20:02] I've got a deployed jenkins instance (1.16.6 on precise) and the log file repeating this: juju runner.go:220 worker: exited "uniter": failed to initialize uniter for "unit-jenkins-0": listen unix /var/lib/juju/agents/unit-jenkins-0/run.socket: bind: address already in use [20:02] how do I go about resetting/restarting the agents? [20:05] rharper: you can ssh to the machine, juju ssh jenkins/0; then run `sudo restart jujud-unit-jenkins-0` [20:06] marcoceppi: yeah -- I did that; it still complains with the same error; I guess something else has that socket file open ? [20:06] rharper: but, 1.18.1 has been released, which is a much newer stable release [20:06] maybe [20:06] marcoceppi: yeah; I tried an upgrade-juju, but it jus says WARNING juju 1.17.0 compat mode [20:07] interesting [20:07] possibly because it was bootstrapped with upload-tools... but that's just a guess [20:08] marcoceppi: any idea what happens if I nute the run.socket in the agent dir ? [20:08] s/nute/nuke [20:08] rharper: I'd stop the agents first [20:08] right, I have it stopped now [20:08] since it's just generating that message I had about 1G of it; didn't know it was doing that [20:09] that seems to have helped ; stop agent; rm run.socket; restart jujud for the service === Ursinha is now known as Ursinha-afk === Ursinha-afk is now known as Ursinha === Ursinha is now known as Ursinha-afk [21:03] hazmat: ohh? i couldn't sshuttle to 192.168.2.1, ssh'ing to it does not work. === psivaa-afk is now known as psivaa [21:06] psivaa, how did you bootstrap? [21:06] psivaa, it should be picking the floating ip address by default [21:06] hazmat: 'juju bootstrap --metadata-source /home/sivatharman/mthood-metadata --constraints=mem=1G --debug --upload-tools' [21:06] psivaa, you can manually mod the env state cache to point to the public ip [21:07] psivaa, are you attaching the ip address after the instance boot? [21:07] hazmat: i am using 'use-floating-ip: true' in the environments.yaml [21:07] hazmat: and the floating ip is attached by default [21:08] hazmat: 2010cf3b-dc41-49b9-b0b1-8c0d77a84fe0 | juju-mthood-machine-0 | ACTIVE | None | Running | int_net=192.168.1.2, 10.230.21.113 [21:08] psivaa, i'd file a bug on that then, the client should be using the floating ip address for communication back to the state server. [21:10] hazmat: ack, thanks. would help if you could pls let me know the bug no for ref === Ursinha-afk is now known as Ursinha [21:32] hazmat: reported bug #1308767 for this [21:32] <_mup_> Bug #1308767: juju client is not using the floating ip to connect to the state server [21:33] hazmat: i was promted about a possible dupe bug #1248674 for the above though [21:33] <_mup_> Bug #1248674: setting a floating address on the state server prevents new agent connections

[22:06] when i deploy a service in an amulet test, am i right to assume that the default config.yaml for the service is used [22:06] ? [22:07] i've added some stuff to config.yaml but i'm not seeing it applied in the amulet test [22:07] although using the same config.yaml to deploy manually (outside of amulet) works as expected [22:08] oh, hrm. i wonder if the test is using the charm from the store instead of my local copy... [22:12] marcoceppi: do i need to explicitly tell amulet to use the local charm? [22:15] tvansteenburgh: if you're running the test directly, without the charm test runner, yes [22:15] tvansteenburgh: sent the environment variable JUJU_TEST_CHARM to the charm name [22:15] which will tell amulet that the cwd that it's running from is the charm and use that to deploy [22:15] marcoceppi: brilliant, tyvm [22:15] tvansteenburgh: you'll also need to run the tests from the CHARM_DIR [22:15] in order for that to work [22:16] ok cool. i'll check the amulet docs and get this stuff added if it's not there [22:16] it's definitely not there [22:16] a lot of the stuff from 1.4 didn't make it in to the docs [22:16] the only reason i'm running the test directly is so i can use ipdb [22:17] * marcoceppi nods === hatch__ is now known as hatch [23:41] lazyPower, ping [23:41] https://bugs.launchpad.net/charms/+bug/1291783 [23:41] can you hit this up first thing manana? [23:41] <_mup_> Bug #1291783: Cisco N1KV VSM charm review process (cwchang) [23:42] jcastro: ackd [23:42] to review first thing