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