=== natefinch-afk is now known as natefinch [02:23] isantop: solved? I won't read all your backlog [02:23] jose: nope [02:24] isantop: what was the issue again? (the last one) [02:24] containers aren't being provisioned with networking [02:24] oh [02:24] uh [02:26] initially, we thought it was a firewall issue, as 11371 (I think?) was blocked [02:26] And that prevented me from being able to manually set up a container. But even after fixing that, and being able to manually provision, we still have no dice === urulama_ is now known as urulama === zz_CyberJacob is now known as CyberJacob === CyberJacob is now known as zz_CyberJacob [07:52] beisner, branches linked to bug https://bugs.launchpad.net/charms/+source/neutron-api/+bug/1474030 [07:52] Bug #1474030: amulet _get_proc_start_time has a race which causes service restart checks to fail [07:52] [07:53] merged and landed into charm-helpers/next branches [07:53] neutron-gateway still needs a fix I think? [09:53] jamespage, do you have any feedback on https://code.launchpad.net/~gnuoy/charms/trusty/neutron-openvswitch/local-metadata/+merge/270416 before I go and start thinking about amulet tests? [09:53] * gnuoy braces for thats-an-awful-name-for-a-user-config-value [09:54] gnuoy: The name is clear, at least. [09:54] thanks! [09:56] speaking of which the associated description is sub-optimal [09:59] hi all [09:59] I pushed a new charm bundle to my namespace on launchpad [09:59] http://bazaar.launchpad.net/~jean-deruelle/charms/bundles/mobicents-restcomm-mysql-bundle/bundle/files [09:59] how long does it take to be indexed and available on the charm store at https://jujucharms.com/q/restcomm?type=bundle ? [09:59] and did I do correctly ? [10:55] gnuoy, couple of niggles - but LGTM [10:56] +1 based on resolution of my niggles :-) [12:45] jamespage, thanks & ack, neutron-gateway is wip [12:45] beisner, np [12:45] good to know [12:46] jamespage, 1 wasn't bug-linked, ready for review: https://code.launchpad.net/~1chb1n/charms/trusty/swift-proxy/amulet-update-1508/+merge/268790 [12:47] jamespage, fyi prob not going to link them all to the bug, but all are ultimately affected. just planning to address as i update each for that, and other reasons. [13:00] beisner, https://code.launchpad.net/~james-page/charms/trusty/mongodb/pymongo-3.x/+merge/270525 [13:00] fixup for mongodb if we have a nice way of testing :-) [13:01] jamespage, uosci is shut down re: serverstack upgrade. [13:02] beisner, that's ok - it can wait :-) [13:02] jamespage, i could probably fire off ceilometer's amulet on metal, it pulls in mongo [13:04] jamespage, fyi mongodb's amulet tests deploy trusty 5 times :-/ [13:35] I get the following error when trying to deploy to a OpenStack environment: 2015-09-09 13:28:36 ERROR juju.cmd supercommand.go:430 failed to bootstrap environment: waited for 10m0s without being able to connect: Permission denied (publickey,password). [13:35] I am however able to connect to the machine myself using ssh [14:31] hi marlinc, what is your `juju version` ? also, are you using juju-deployer with a bundle, or a different method to deploy? === natefinch is now known as natefinch-afk [16:35] hi all [16:35] I pushed a new charm bundle to my namespace on launchpad [16:35] http://bazaar.launchpad.net/~jean-deruelle/charms/bundles/mobicents-restcomm-mysql-bundle/bundle/files [16:35] how long does it take to be indexed and available on the charm store at https://jujucharms.com/q/restcomm?type=bundle ? [16:35] and did I do correctly ? [16:38] lazyPower, are you up on how the charmhelpers codebase works? [16:39] jeand: it shouldn't take more than a few hours [16:39] lazyPower, I have a make test failing but I'm not sure where it's coming from [16:39] jeand: when did you last push? [16:39] jeand: Ah, I see the issue, you'll need to name the file "bundle.yaml" === apuimedo is now known as apuimedo|away [16:43] ah ok [16:43] Thanks :D [16:45] jeand: if you have charm-tools installed (https://jujucharms.com/docs/stable/tools-charm-tools) you can run `juju charm proof` against the bundle directory to catch any preliminary issues that would prevent it from showing in the store [16:57] marcoceppi, Thanks for the help [16:57] I fixed it http://bazaar.launchpad.net/~jean-deruelle/charms/bundles/mobicents-restcomm-mysql-bundle/bundle/files [16:58] and charm proofed it [16:58] with no errors [16:58] so will be waiting now to see if it shows up [16:58] cholcombe: a bit, whats goin on? [16:58] lazyPower, i'm modifying the ceph contrib code a little to add erasure coding support [16:59] everything seems fine however the one test is failing [16:59] FAIL: tests.payload.test_execd.ExecDTestCase.test_execd_run_dies_with_return_code [16:59] i didn't think my code touched that though [16:59] nah thats in charmhelpers.fetch i think [16:59] ok [17:00] it worked before i made my change so i think i broke it but i'm not sure how [17:00] oh... maybe not [17:00] welp, i think that pretty much sums up tha ti should be answering zero questions about this :D [17:00] haha [17:01] lazyPower: Still stuck in allocating. :/ [17:02] isantop: i think at this point its prudent to file a bug, as i'm not sure why the lxc nodes are not getting networking [17:03] isantop: https://bugs.launchpad.net/juju-core/+filebug -- include the output from `juju version` `juju status` `ifconfig` `sudo lxc-ls --fancy` and what you've attempted to do so we can try to reproduce it. [17:09] lazyPower: Will do. Will need to wait till lunch [17:10] isantop: can you ping me with the link when its filed? i'll sub and pass it along to the -core team that can lend a hand. [17:10] For sure [17:11] I blame jcastro, but that's just me being silly [17:14] isantop: heh, we do it too ;) [17:51] beisner, I'm using Juju 1.22.1-vivid-amd64 [17:54] marlinc, i generally use the juju version from the stable ppa. see https://launchpad.net/~juju/+archive/ubuntu/stable [17:55] marlinc, fyi the error you indicated isn't really openstack specific, in that the bootstrap has to happen before any services are deployed [17:55] marlinc, so to troubleshoot/confirm, i'd try a couple of juju bootstrap / juju destroy-environment iterations using the later version of juju. [17:55] Isn't Juju supposed to try to reconnect every 5 seconds for example? [17:56] Okay, I'll see what the PPA provides [17:57] marlinc, this was the bootstrap error, right? [17:57] ERROR juju.cmd supercommand.go:430 failed to bootstrap environment: waited for 10m0s without being able to connect: Permission denied (publickey,password). [17:58] marlinc, there are a lot of other variables that i can't presume, such as provider (maas, local, a public cloud), etc., but either way, i'd go to the latest stable juju version and go from there. [17:58] Cool, will try thay [17:58] That* === natefinch-afk is now known as natefinch [18:11] anyone want to give me a hand with my diff: http://bazaar.launchpad.net/~xfactor973/charm-helpers/erasure-coding/revision/446 [18:11] I'm failing some tests but I'm not sure how I broke it === zz_CyberJacob is now known as CyberJacob [18:27] cholcombe, can you put a pastebin of the error you are seeing? [18:27] sure [18:29] https://gist.github.com/cholcombe973/5692a444b02097b3db73 [18:29] tvansteenburgh: ping [18:31] wolsen, seems as though I broke it but I'm not sure how [18:32] wolsen, I think for the function signatures I changed I need to create an indirection layer. I'm not sure who is linked against this library [18:33] cholcombe, since they don't look compatible, you'll want to deprecate the methods before yanking them [18:33] wolsen, yeah that sounds good [18:33] cholcombe, re: the test breakage - it doesn't look related to your change at all... let me see if I get the same errors as you [18:33] ok [18:40] cholcombe, hmm I don't see those errors when running tests against your branch [18:40] wolsen, interesting === arturty is now known as arturt- === arturt- is now known as erazm === natefinch is now known as natefinch-afk === CyberJacob is now known as zz_CyberJacob [22:12] hey — i have an agent which is stuck in the “agent-status: executing, message: running action update” state. for some reason, during the update hook, everything got lodged. i manually killed the lodged processes, but juju is still waiting for the agent sitting in that state. the logs reveal the agent for that unit is shitting out tons of stack traces due to a “panic: runtime error: invalid memory address or nil pointer dereference” [22:12] on version 1.24.5