=== natefinch-afk is now known as natefinch [05:18] niedbalski: The NamedTemporaryFile was opened with the default mode ('wb'), but having a string written too it. I fixed the mode to 'w' so writing text to it actually works. [05:25] And lp:charm-helpers got push --overwritten, so ensueing merge headaches and trunk has two broken tests again :-( [05:26] So pretty please everyone, actually run 'make test' [05:30] oic, the openstack fix came in elsewhere and the file fix lost in the confusion === zz_CyberJacob is now known as CyberJacob === CyberJacob is now known as zz_CyberJacob === lukasa is now known as lukasa_away === lukasa_away is now known as lukasa === lukasa is now known as lukasa_away === lukasa_away is now known as lukasa === mmidgett is now known as mTeK === lukasa is now known as lukasa_away === lukasa_away is now known as lukasa [13:02] hazmat: ping [13:06] stub, thanks. [13:28] ddellav, looking now [13:36] ddellav, looks good - a few comments to think about and resolve, but basically 99% done IMHO [13:36] ddellav, I think we need to try to avoid using action_fail in scenarios where the action does not do anything [13:36] git and configuration not set right [13:36] ddellav, some sort of action-set of the outcome seems appropriate [13:36] ddellav, skipped [13:37] ddellav, upgraded === natefinch is now known as natefinch-afk [14:55] jamespage, git and configuration not set right? [14:56] ddellav, sorry of git-install or config-changed managed upgrades are configured [14:56] of/if [14:56] I can't type today either [14:56] and have a tendency to repeat myself so bear with me [14:56] no worries :) [14:59] jamespage, so i'll go back and take out the action_fail lines when the code does nothing and maybe just use juju_log instead? [15:00] ddellav, I'd suggest some sort of 'outcome' output variable to say what action was taken [15:00] 'skipped' 'upgraded' 'upgrade failed' [15:00] and log message is nice as well I guess [15:00] ah ok, that makes sense. [15:00] ddellav, I think 'fail' sends the wrong message back to the end user [15:01] the action did not fail - it just did not do anything!¬ === lukasa is now known as lukasa_away === lukasa_away is now known as lukasa === lukasa is now known as lukasa_away === lukasa_away is now known as lukasa [17:16] alai1: heyo [17:16] whit, hi [17:17] cloud:trusty-updates/juno is not a string I suspect as being in the etcd charm [17:17] as etcd should not be openstack specific in any way [17:17] whit, the etcd charm option source cannot be set [17:18] it always set to cloud:trusty-updates/juno [17:18] alai1: ok let me look at the code [17:21] alai1: how are you testing what it is set to? [17:21] also, where does the charm you are deploying come from? [17:21] and what cloud are you deploying onto? [17:21] whit, juju get etcd [17:22] I feel like I should mention that I'm here right now [17:22] As I suspect this conversation is tangentially about my work. ;) [17:22] and source=" cloud:trusty-updates/juno" [17:22] /cc alai1 whit [17:22] lukasa, hi ;) [17:22] Howdy alai1 =D [17:23] alai1: so that string doesn't exist in the master repo, so I don't see how the charm would be setting it [17:23] alai1: hmmm [17:23] lukasa, any idea why source in etcd charm is set to cloud:trusty-updates/juno ? [17:23] uh...which etcd charm are you using? [17:24] If you were using my old one that might happen, but with whit and lazyPower's it's hard to see how [17:24] that string is totally not something that should be getting set there [17:24] aha [17:25] lukasa, whit : we are using lp:~kubernetes/charms/trusty/etcd/trunk [17:26] lukasa, and got this error http://pastebin.com/dCd53r70 [17:26] alai1: is it possible your environment has another etcd charm cached somehow? === natefinch-afk is now known as natefinch [17:26] That's perplexing [17:28] alai1: that string does not exist in the code you think you are deploying [17:29] whit, good point... I always clear the cache but I may forgot this time ;). Trying it again... [17:29] so I'm guessing either the code you think you are deploying is not... or something external is setting it :( [17:29] alai1: cool === admcleod- is now known as admcleodafk [18:21] whit: its probably set by a bundle [18:21] alai1: check the bundle source [18:22] lazyPower, bundle source doesn't set up [18:22] lazyPower, in fact i added source: https://github.com/coreos/etcd/releases/download/v2.0.11/etcd-v2.0.11-linux-amd64.tar.gz in the bundle and did not help [18:23] lukasa, whit: i still see the same error [18:23] alai1: can you link me to your bundle, as well as steps to reproduce? [18:23] i don't see that string in the charm so must be something external as whit said [18:30] alai1: Thanks for the pastebin - looking this over i see the issue [18:30] there is an overrides: directive at the top - and its declaring any source: option should be could:trusty-updates/juno [18:31] the etcd config option is 'source' - so therefore its getting overridden by the bundle config [18:31] lazyPower, woot [18:32] good catch lazyPower [18:32] :) [18:32] I like to think this is why whit keeps me around. [18:34] i would never thought of the bundle as it is auto generated and we never had any issues with it [18:35] thats the one variable in the equation between upstream and the deployment you're running is the bundle. [18:35] and i had suspicioned since 'source' was at play it got overridden [18:36] alai1: if you dont mind can you file a bug against the ETCD charm so i've got a reference when i propose a fix? [18:37] we normally dont like to break backwords compat like this, and having a bug that references this breaks with openstack deployments will help validate the necessity for the change [18:37] lazyPower, would be glad to do it [18:37] give me few minutes [18:44] trying to add mysql to an lxc, but the lxc fails to start: http://pastebin.com/jZmamds4 [18:44] this is the machine-1.log from /var/log/juju === lukasa is now known as lukasa_away === lukasa_away is now known as lukasa === lukasa is now known as lukasa_away === lukasa_away is now known as lukasa [22:48] bhundven: do you have a proxy in place or restricted access to the outside world? === zz_CyberJacob is now known as CyberJacob [22:54] marcoceppi: there is a nat, but no proxy [22:56] bhundven: try `juju retry-provisioning 1/lxc/0` [22:56] $ juju retry-provisioning 1/lxc/0 [22:56] error: invalid machine "1/lxc/0" retry-provisioning does not support containers [22:57] 1.24.2-trusty-amd64 [22:58] bhundven: terminate-machine 1/lxc/0; then juju remove-unit mysql/0 [22:58] then try to deploy to container again [22:58] it failed to fetch the base image that lxc uses for cloning [22:58] which is stored and created oin teh bootstrap node [23:01] marcoceppi: do you know the logfile this work will be in? I'm guessing on the node the lxc is being deployed to. [23:03] juju add-machine lxc:1 [23:03] 1/lxc/1: [23:03] agent-state-info: 'container failed to start and was destroyed: juju-machine-1-lxc-1' [23:13] yea, I made a new container after that, and still get the same error as the pastebin [23:13] I can wget/curl from sites outside my network from the physical machine through the nat [23:13] so not dns or connectivity. [23:14] afaict [23:19] also weird is that I have done a 'boot-resources import' and click the apply button on the images page of maas, but it still says: "Boot image import process not started. Nodes will not be able to provision without boot images. Visit the boot images page to start the import.", but I have 4 deployed nodes. I tried nuking the /var/lib/maas/boot-resources [23:19] directory, ran the maas command again and watch the images sync in the logs. [23:32] for S&G purposes, I tried to fire up a kvm container... [23:32] containers: [23:32] 3/kvm/0: [23:32] agent-state-info: 'kvm container creation failed: exit status 1' [23:33] am I missing a package or something? === CyberJacob is now known as zz_CyberJacob [23:46] are the templates coming from jujucharms.com? === mup_ is now known as mup === yo61_ is now known as yo61