=== thumper-afk is now known as thumper
[00:44] <aquarius> marcoceppi, ping about discourse and upgrades. I've installed discourse with juju, and discourse says I should upgrade. You said that the juju discourse charm doesn't handle upgrades. What should I do?
[00:45] <aquarius> (am afk, but happy to read responses and deal with them later)
[00:48] <thumper> o/ aquarius
[00:48] <thumper> aquarius: happy birthday for the other day
[00:48] <thumper> I was too slow
[00:49] <aquarius> hey thumper!
[00:49] <aquarius> you're only 49 minutes too late :)
[00:49] <thumper> sorry, was at the gym
[00:49] <thumper> and you were probably at the pub
[00:49] <sarnold> happy regular day aquarius!
[00:53]  * aquarius laughs
[00:54] <aquarius> I was, in fact, in the pub.
[00:54] <aquarius> Currently home.
[00:54] <aquarius> post-pub :)
[00:54] <aquarius> happy 31st January to me,
[00:54] <aquarius> Only 364 days until my birthday!
[00:55] <sarnold> YAY
=== gary_poster is now known as gary_poster|away
=== CyberJacob|Away is now known as CyberJacob
[08:21] <marcoceppi> aquarius: so, it does actually do upgrades, if you just increment the version number in release, or branch, or tag, or whatever config option I called it
[08:21] <marcoceppi> but you don't want to run juju upgrade-charm
[08:32] <aquarius> marcoceppi, oh! so, how do I upgrade discourse then?
[08:32] <marcoceppi> aquarius: there's a release config options, or something
[08:32] <aquarius> marcoceppi, I have no idea what that means :)
[08:32] <marcoceppi> aquarius: one min, otp
[08:33] <aquarius> marcoceppi, no worries :)
[08:42] <marcoceppi> aquarius: okay, so there's a release configuration option, https://bazaar.launchpad.net/~marcoceppi/charms/precise/discourse/trunk/view/head:/README.md#L69 what is your release configuration currently set to?
[08:42] <marcoceppi> juju get discourse should illuminate that
[08:42] <marcoceppi> albiet in a very verbose and slightly annoying fashion
[08:44] <aquarius>     value: latest-release
[08:44] <aquarius> if I've correctly understood the output
[08:45] <marcoceppi> aquarius: right, so you probably didn't follow the readme, which is cool, I forgive you
[08:46] <aquarius> heh. I was here telling you everything I did when I installed it :)
[08:46] <aquarius> forgiveness appreciated. How can I redeem myself?
[08:46] <marcoceppi> aquarius: so you can find all the valid options for this configuration here: https://github.com/discourse/discourse/releases
[08:47] <marcoceppi> aquarius: basically, you should run `juju set discourse release="v0.9.8.3"` then wait about 5-10 mins
[08:47] <marcoceppi> and discourse should upgrade
[08:47] <aquarius> marcoceppi, wow! that's it?
[08:47] <marcoceppi> aquarius: pretty much
[08:47] <aquarius> marcoceppi, and that will work from whichever version I'm on now?
[08:48] <marcoceppi> aquarius: yes, as long as you always go forward, they follow a very rigorous upgrade path using db:migrations, etc
[08:48] <aquarius> sure, but I don't have to upgrade to all the interim versions? nice.
[08:48] <aquarius> let me just check what we're on now :)
[08:50] <aquarius> heh, we are a bit behind :)
[08:50] <aquarius> marcoceppi, what happens to the forum while the upgrade is happening? does it stay live?
[09:01]  * aquarius runs juju set discourse release="v0.9.8.3"
[09:18] <marcoceppi> aquarius: so...how's it going?
[09:20] <aquarius> marcoceppi, it hasn't upgraded, yet. How can I know what it's doing?
[09:21] <aquarius> juju get discourse shows that release is set to v0.9.8.3
[09:22] <aquarius> but the forum itself is not upgraded
[09:22] <aquarius> I don't know whether that's because my machine is in the middle of doing the upgrade, or whether the upgrade failed, or whether I have to do something else to tell it to upgrade?
[09:28] <marcoceppi> aquarius: you can run juju ssh discourse/0
[09:29] <marcoceppi> then tail -f /var/log/juju/unit-discourse-0.log
[09:29] <marcoceppi> it can take quite awhile to run, depending
[09:29] <aquarius> aha.
[09:29] <aquarius> 2014-01-31 09:31:37 ERROR juju runner.go:211 worker: exited "uniter": ModeConfigChanged: cannot obtain storage account keys: GET request failed: ForbiddenError - The server failed to authenticate the request. Verify that the certificate is valid and is associated with this subscription. (http code 403: Forbidden)
[09:30] <aquarius> that looks relevant
[09:30] <aquarius> it's saying that over and over again
[09:31] <aquarius> marcoceppi, I don't understand what that means. Don't even know what it's trying to access and failing :)
=== mwhudson is now known as zz_mwhudson
[09:34] <marcoceppi> aquarius: that's a new one on me, any idea fwereade?
[09:34] <fwereade> marcoceppi, sorry, I was disconnected, what's the problem?
[09:35] <marcoceppi> 2014-01-31 09:31:37 ERROR juju runner.go:211 worker: exited "uniter": ModeConfigChanged: cannot obtain storage account keys: GET request failed: ForbiddenError - The server failed to authenticate the request. Verify that the certificate is valid and is associated with this subscription. (http code 403: Forbidden)
[09:35] <marcoceppi> that looks relevant
[09:36] <aquarius> fwereade, that's after I set a new release version for discourse (and so it presumably started to upgrade to the new version)
[09:37] <fwereade> aquarius, crikey, that's new to me
[09:37] <fwereade> aquarius, is it consistent, or does a `juju resolved --retry` help?
[09:38] <aquarius> fwereade, at the moment, the job seems to be restarting every 3 seconds on my cloud VM, and then it has a bunch of log entries ending with that one.
[09:39] <aquarius> I can try juju resolved --retry, but do I have to somehow "stop" what it's already doing?
[09:39] <fwereade> aquarius, got you, sorry, I'm still a bit morningy
[09:40] <aquarius> I can post the whole log section if that would help?
[09:40] <fwereade> aquarius, that would definitely be interesting
[09:40] <fwereade> aquarius, thanks
[09:41] <aquarius> fwereade, http://pastebin.ubuntu.com/6848481/ is the snippet that comes up over and over
[09:43] <fwereade> aquarius, what's the agent-state for that unit in `juju status`?
[09:43] <aquarius>         agent-state: started
[09:44] <aquarius> fwereade, and the postgresql unit is the same
[09:58] <aquarius> yeah, still doing it. Should I stop juju from trying to do this upgrade somehow?
[10:08] <aquarius> I'm now worried that it's going to eat all my compute time
[10:18] <aquarius> another question: is my laptop participating in this process? If I restart my laptop, will it screw up anything that juju is doing?
[10:18] <aquarius> marcoceppi, if I unset the release config variable, will it stop trying to do the upgrade and failing?
[10:19] <marcoceppi> aquarius: restarting does nothing, since it's the remote machine that's working (your laptop)
[10:20] <aquarius> right. So I can at least reboot my laptop, which update manager is telling me I need to :)
[10:20] <marcoceppi> aquarius: re-setting the option might help, but it'll just fire a hook again
[10:20] <marcoceppi> aquarius: what version of juju are you on?
[10:20] <aquarius> marcoceppi, 1.16.5-saucy-amd64
[10:20] <aquarius> according to juju --version
[10:20] <marcoceppi> k
[10:21] <aquarius> I don't really want the machine to be busy all the time, because it'll use up compute seconds, and that costs money ;)
[10:25] <marcoceppi> aquarius: you can try a slightly bad thing, and stop the agents
[10:25] <marcoceppi> then start them again
[10:28] <aquarius> marcoceppi, tha sounds OK. How do I do that?
[10:31] <marcoceppi> aquarius: on the node run sudo initctl list | grep juju-
[10:31] <marcoceppi> then restart the two jobs listed there
[10:31] <aquarius> weird. it doesn't show anything
[10:31] <marcoceppi> should be something like jujud-machine-# and juju-discourse-unit-0
[10:31] <marcoceppi> someting like that
[10:32] <marcoceppi> aquarius: jujud-*
[10:32] <aquarius> aha, jujud :)
[10:32] <aquarius> do I need to stop them in a particular order?
[10:32] <aquarius> should I stop each, then start each, or can I restart one then restart the other?
[10:36] <aquarius> marcoceppi, OK, restarted them. logfile still shows that it's continually trying to do whatever it's trying and then fails with the "ForbiddenError" every 3 seconds
[10:38] <marcoceppi> aquarius: you can increase your verbosity of logging
[10:38] <marcoceppi> which might shed some more light on this
=== zz_mwhudson is now known as mwhudson
[10:40] <aquarius> marcoceppi, oh, that sounds handy. How do I do that?
[10:40]  * aquarius is rtfs to wok out what juju's trying to fetch and failing
[10:40] <marcoceppi> juju set-env 'logging-config=<root>=DEBUG'
[10:40] <marcoceppi> that should be sufficent
[10:44] <aquarius> marcoceppi, ok, have run that
[10:44] <aquarius> marcoceppi, should I expect that the log files will be more detailed?
[10:45] <marcoceppi> aquarius: theoretically, yes
[10:45] <aquarius> they aren't, so far
[10:45] <aquarius> maybe it hasn't applied it ye?
[10:46] <marcoceppi> aquarius: I wonder if your node is having problems talking to the bootstrap node
[10:46] <marcoceppi> which is why youre' getting all this. Can you pastebin juju status?
[10:46] <aquarius> http://paste.ubuntu.com/6848764/
[10:48] <marcoceppi> huh, all your units are registered as started
[10:48] <marcoceppi> I wonder if this is because you're running 1.16.5 and you have 1.16.3 deployed
[10:48] <marcoceppi> there may be some incompats, though there shouldn't
[10:50] <aquarius> perhaps?
[10:51] <aquarius> I mean, that's a minor version upgrade only :)
[10:52] <aquarius> just trying "juju unset discourse release" to see if that stops the server continually trying to do a non-working thing
[10:53] <aquarius> bah, it doesn't.
[10:53] <aquarius> server still trying to config things and failing, every 3 seconds :(
[10:55] <aquarius> that error is being thrown by something trying to connect to Azure's storage account
[10:55] <aquarius> so I think this is some sort of config error
=== mwhudson is now known as zz_mwhudson
[10:58] <aquarius> specifically, the line throwing the error is http://bazaar.launchpad.net/~go-bot/juju-core/trunk/view/head:/provider/azure/environ.go#L113
[10:58] <aquarius> 	keys, err := azure.GetStorageAccountKeys(accountName)
[10:58] <aquarius> but I can't see where GetStorageAccountKeys is defined!
[10:59] <aquarius> the only place that function is mentioned in the juju-core source tree is that line which calls it
[10:59] <aquarius> I *suspect* that the problem here is that I changed my Azure subscription.
[11:00] <aquarius> aaah, hang on, there is a "storage-account-name" in ~/.juju/environments.yaml. I wonder if that's wrong?
[11:03] <aquarius> No, that's correct.
[11:03] <aquarius> However, if I deployed the discourse setup with a storage name in the azure environments.yaml, and then I *changed* environments.yaml, what do I need to do to teach the juju deployment about the new value?
[11:05] <aquarius> I am wondering whether it was set up talking to the old storage and now that it's changed, juju has cached the keys somewhere so it doesn't know how to talk to the new storage
[11:05] <aquarius> I'm not even sure that the storage ID changed, mind
[11:06] <aquarius> but I bet juju not being able to obtain the storage keys is something to do with me changing the ownership of that storage block from one MSDN subscription to another.
[11:11] <aquarius> I do not have any idea how to see which keys juju is trying to use to talk to azure, and what the keys should be, and how to correct them. Is that even doable?
[11:11] <aquarius> is this more an fwereade question? :)
[11:16] <marcoceppi> aquarius: that's actually very probable
[11:16] <marcoceppi> aquarius: they're all in the mongodb database somewhere, and fwereade or mgz might know more
[11:16] <marcoceppi> aquarius: tearing down and re-standing up would be easiest but iirc this is a production site
[11:17] <aquarius> it is.
[11:17] <aquarius> it is community.badvoltage.org
[11:17] <aquarius> active forum.
[11:17] <aquarius> I do not want to destroy it and set it up again :)
[11:19] <marcoceppi> aquarius: understood
[11:19] <mgz> aquarius: which keys specifically? some details are in your ~/.juju/envrionments/{ENV}.jenv file
[11:20] <marcoceppi> aquarius: fwiw, and an fyi, postgresql does nightly dumps to ~postgres/backups and keeps the last five days
[11:20] <marcoceppi> if you're not already mirroring them offsite
[11:20] <aquarius> mgz, I don't know. I am speculating what the problem is. Can you see the scrollback? I can fill in more detail if you canno
[11:21] <aquarius> marcoceppi, I have backups, but they're for disaster recovery, not so I can blow away the village and start again unless I really really have to :)
[11:21] <mgz> okay, reading
[11:21] <marcoceppi> aquarius: yes, right
[11:21] <marcoceppi> mgz: so in short aquarius is getting "2014-01-31 09:31:37 ERROR juju runner.go:211 worker: exited "uniter": ModeConfigChanged: cannot obtain storage account keys: GET request failed: ForbiddenError - The server failed to authenticate the request. Verify that the certificate is valid and is associated with this subscription. (http code 403: Forbidden)"
[11:22] <aquarius> mgz, brief summary: using marcoceppi's discourse charm, deployed to Azure. Deployment went fine; site has been live for about two months. Today I tried to upgrade discourse. juju log on the discourse unit throws the error from above.
[11:22] <marcoceppi> but he recently changed the bucket and possibly some additional details for the env
[11:23] <aquarius> mgz, after the discourse deployment was created, I changed my Azure subscription (from the free trial to an MSDN Ultimate subscription) and had MS Support migrate all my VMs/storage etc over to the new subscription. I then edited environments.yml and changed the subscription-id and so on to the new values. I can successfully connect to the juju units with juju ssh and so on, so I must have done it roughly correctly.
[11:24] <aquarius> mgz, I am *speculating* that that error is being caused because juju first connected to the Azure storage unit when it was under the free trial subscription ID, and cached some keys or something; now that storage unit (which may have a new ID and may not; I do not think it has) is under the MSDN subscription ID so juju's cached keys don't work.
[11:24] <aquarius> But that is speculation.
[11:25] <mgz> aquarius: can you compare the value sin your environments.yaml with the ones in the .jenv?
[11:26] <aquarius> mgz, management-subscription-id and storage-account-name are the same in ~/.juju/environments.yaml and ~/.juju/environments/azure.jenv
[11:30] <mgz> can you see the cert azure has under their web ui?
[11:33] <aquarius> mgz, I don't know. What am I looking for?
[11:34] <mgz> I'm not sure :) the x509 cert thing the azure setup instructions talk about being uploaded
[11:34] <aquarius> mgz, there is a "manage access keys" thing for the storage
[11:35] <aquarius> mgz, I can regenerate those keys, and then teach juju about the new keys
[11:35] <aquarius> but I don't know where juju stores the keys!
[11:35] <aquarius> let me look in .jenv
[11:37] <aquarius> mgz, I am 95% sure that the .cer file that I uploaded on setup is correct, because it's still there, it didn't change, and if I had that wrong then I don't think that juju would be able to talk to azure *at all*.
[11:37] <aquarius> I think the problem is juju isn't able to talk to the *storage*
[11:38] <aquarius> but then maybe the problem is that juju is trying to get the storage access keys and isn't allowed because something else is wrong
[11:39] <aquarius> mgz, I can't see the actual cert in the Azure web UI. I can see that there *is* a cert, that it's called "Juju" (which is what I named it), and I can see its fingerprint.
[11:39] <aquarius> (er, thumbprint)
[11:39] <aquarius> I don't know how to get the thumbprint of whichever cert juju is using though!
[11:42] <aquarius> the storage access keys are described at https://www.windowsazure.com/en-us/documentation/articles/storage-manage-storage-account/#how-to-view-copy-and-regenerate-storage-access-keys
[11:42] <aquarius> can I see which ones juju is using and update them?
[11:42] <mgz> I'd expect either the path or the cert itself to be in the jenv
[11:42] <aquarius> (although I think the error I'm getting may be from juju trying to get those keys and being denied, rather than *using* those keys and being denied)
[11:43] <mgz> right, it doesn't get as far as getting the storage keys
[11:55] <aquarius> mgz, so, your theory is that when juju tries to get the storage keys, it authenticates that request with the cert, and the cert is wrong? that sounds plausible, but I don't know how to confirm that :)
[11:56] <mgz> aquarius: something like that, though the request goes through as far as getting an http error, which implies a connection of some kind worked
[11:56] <aquarius> *nod* that http request is getting a Forbidden
[11:57] <aquarius> I am trying to work out how to calculate the thumbprint of the certificate I have :)
[11:57] <mgz> I'd like to ask one of the red squad who wrote the gwacl bits
[11:57] <mgz> rvba: ^ any ideas on this azure error?
[11:59] <aquarius> OK. I have confirmed that the thumbprint of the cert that Azure has, and the thumbprint of the cert I have set in environments.yaml, are the same.
[12:00] <aquarius> the azure thumbprint is listed in azure web ui > settings > management certificates, and I got the fingerprint with cat (cert file from ~/.juju/environments.yaml) | openssl x509 -sha1 -fingerprint
[12:00] <mgz> okay, fun
[12:01] <aquarius> hm! question. If I look at the cert file itself, I can see the certificate value after --- BEGIN CERTIFICATE ---
[12:02] <aquarius> in .juju/environments/azure.jenv, I can see that same certificate under management-certificate
[12:02] <aquarius> however there is also, in environments/azure.jenv, a ca-cert value which seems to be a different cert. Are we expecting those two to be different?
[12:04] <aquarius> am happy to provide debugging information for rvba if it'd help
[12:05] <allenap> mgz: I don’t know where to start. Can you summarise the question?
[12:05] <mgz> aquarius: that one is a differnt one, used for juju itself
[12:05] <aquarius> mgz, ok, that's not a problem then :)
[12:05] <mgz> allenap: see summary at 11:23 in scrollback
[12:11] <mgz> allenap: any ideas?
[12:12] <allenap> mgz: I’m also thinking along the x509 road, but I’ve just spent the last 5 minutes trying to log into Azure.
[12:13] <ashipika> a quick question.. what does "ERROR no such request "AddCharm" on Client" mean?
[12:20] <allenap> aquarius: In management.windowsazure.com > Settings > Management Certificates, does the thumbprint of the certificate that Juju’s using match up to the subscription you want to use?
[12:22] <aquarius> allenap, I believe so, yes. I have only one cert in Azure's web UI. In ~/.juju/environments.yaml I name a management-certificate-path. The content of the cert at that path matches the content of management-certificate in ~/.juju/environments/azure.jenv. The fingerprint calculated from the cert path with "cat (cert file from ~/.juju/environments.yaml) | openssl x509 -sha1 -fingerprint" matches the thumbprint listed in the
[12:22] <aquarius> Azure web UI.
[12:25] <mgz> my best guess I thinm then, is the subscription-id change in your local environments.yaml never propogated to the state server properly
[12:25] <aquarius> OK. What do I do to rectify that?
[12:26] <allenap> Yeah, what mgz said. Not sure how to get Juju to use/generate a new certificate though.
[12:26] <mgz> and now things are borked because nothing there can actually stay alive with a valid value
[12:26]  * allenap will be back in a bit.
[12:32] <aquarius> mgz, hm. that sounds like it could be the case... can i confirm that it is the case?
[12:35] <mgz> aquarius: does `juju status` work at all, and what version of juju are you using (and what does the state server have?)
[12:35] <mgz> we may have a way of getting this alive again
[12:35] <aquarius> mgz, it works fine: output is at http://paste.ubuntu.com/6848764/
[12:35] <aquarius> $ juju --version
[12:35] <aquarius> 1.16.5-saucy-amd64
[12:36] <aquarius> I do not know how to work out what's on the state server?
[12:38] <mgz> aquarius: so, we should be able to use `juju set-env` to update the subscription-id
[12:38] <aquarius> mgz, ok, that sounds encouraging
[12:38] <mgz> can you dump the all-machines.log from the state server first for looking at later
[12:39] <aquarius> mgz, certainly, if you tell me how :)
[12:39] <mgz> then you should be able to do `juju set-env -e {AZURE} management-subscription-id={NEWVALUE}`
[12:40] <mgz> aquarius: `scp {MACHINE-0-IP}:/var/log/juju/all-machines.log ~`  should do
[12:41] <aquarius> um, I can't scp into it.
[12:41] <aquarius> aah, juju scp. :)
[12:42] <aquarius> no, that's no good, because juju scp doesn't work if you give it a DNS name.
[12:42] <mgz> you can give it the machine number
[12:43] <aquarius> just worked that out :)
[12:43] <aquarius> I tried giving it the machine name first and that didn't work either, but "0" works :)
[12:43] <aquarius> ok, it's copying about 120MB of log :)
[12:44] <mgz> I expect a lot of it is that same error repeated forever
[12:44] <aquarius> right, once that's done, to be clear, I should do "juju set-env management-subscription-id=VAL" where VAL is actually the subscription ID that I already have set in environments.yaml?
[12:44] <mgz> yes, that's right
[12:44] <mgz> do you recall if you changed any of the other settings in environments.yaml when you did that?
[12:45] <aquarius> I changed only the management-subscription-id, looking at my comments
[12:46] <mgz> ace, then that should be all
[12:46] <aquarius> mgz, question. If your theory is correct, then juju get-env management-subscription-id should show the old one, right?
[12:46] <mgz> then you can tail the all-machines.log on the state server and see if anything different happens
[12:46] <aquarius> or will that look in my local environments.yaml configuration/
[12:46] <mgz> aquarius: yeah, try that first
[12:46] <aquarius> ha haaaaaaaaaaaaaaa!
[12:47] <aquarius> juju get-env shows the old one!
[12:47] <aquarius> victory.
[12:47] <aquarius> right. I shall set the new one.
[12:47] <aquarius> ooooo.
[12:47] <aquarius> $ juju set-env management-subscription-id=(new subscription id)
[12:47] <aquarius> ERROR GET request failed: MissingOrIncorrectVersionHeader - The versioning header is not specified or was specified incorrectly. (http code 400: Bad Request)
[12:48] <aquarius> that's discouraging.
[12:49] <mgz> can you do that again with juju --debug?
[12:50] <aquarius> hm
[12:50] <aquarius> looks like it worked that time
[12:50] <aquarius> maybe it was just temporary
[12:50] <mgz> it may have worked the first time, but had that message as fallout after it succeeded
[12:50] <aquarius> get-env now shows the new value.
[12:50] <mgz> which then got fixed
[12:50] <mgz> so, now look at what's happening in all-machines.log on machine 0
[12:50] <aquarius> ahahahahaha!
[12:51] <aquarius> and the log on the discourse server now shows that it's installing discourse, rather than looping infinitely and failing.
[12:51] <mgz> excellent.
[12:52] <aquarius> this is extremely encouraging.
[12:52] <aquarius> thought for the future: juju ought to detect if your subscription ID is wrong, and put up a massive great red message to tell you so if it is :)
[12:53] <marcoceppi> aquarius: give it a bit, that upgrade is now happening
[12:53] <aquarius> marcoceppi, it may not be; I unset the config value
[12:53] <aquarius> marcoceppi, but now I'll set it again
[12:53] <dimitern> aquarius, you could file a bug for that :)
[12:53] <marcoceppi> aquarius: what did you set it to, just "" ?
[12:54] <mgz> yeah, that error mesage was not helpful, and the status output giving no indication of problems is pretty bad
[12:54] <aquarius> marcoceppi, I used unset, so that put it back to what it was before (latest-release or whatever)
[12:54] <marcoceppi> aquarius: ah, okay
[12:55] <aquarius> OK. Now setting the discourse version. Let's see what happens :)
[12:56] <aquarius> looks like it's doing *something*, at least -- it's installing stuff.
[13:02] <aquarius> bug https://bugs.launchpad.net/juju-core/+bug/1274922 submitted asking for something to warn about mismatched subscription IDs, dimitern :)
[13:02] <_mup_> Bug #1274922: Changing Azure subscription ID in environments.yml does not propagate to server, and does not warn <juju-core:New> <https://launchpad.net/bugs/1274922>
[13:03] <aquarius> oooh. upgrade seems to have failed, marcoceppi
[13:05] <aquarius> marcoceppi, http://pastebin.ubuntu.com/6849295/
[13:06] <aquarius> and now the forum's down :(
[13:11] <wgrant> I'm getting "cannot start bootstrap instance: index file has no data for cloud {az-1.region-b.geo-1 https://region-b.geo-1.identity.hpcloudsvc.com:35357/v2.0/} not found" when trying to bootstrap on HP Cloud US East. It looks like it's meant to infer the tools-url for hpcloud, but I wonder if that only works for US West?
[13:12] <marcoceppi> aquarius: go to pm
=== gary_poster|away is now known as gary_poster
[13:18] <dimitern> aquarius, thank you!
[13:31] <aquarius> sinzui, ping: you've just marked my bug as a dupe and it isn't. My problem wasn't that environments.yaml disagreed with .jenv -- they both agreed but the actual server did not, I think.
[13:33] <sinzui> Oh,. thank you aquarius
[13:33] <aquarius> nw :)
[13:34] <aquarius> sinzui, we fixed the problem with "juju set-env management-subscription-id=(the id from environments.yml)"
[13:34] <aquarius> sinzui, so it's an easy fix once you know that that's the problem... it just took two hours to work that out ;)
[13:35] <sinzui> thank you aquarius
[13:36] <ahasenack> guys, what's up with this error, what else can I do to debug? It's during bootstrap on aws
[13:36] <ahasenack> 2014-01-31 13:35:46 WARNING juju.environs open.go:258 failed to write bootstrap-verify file: cannot make S3 control bucket: A conflicting conditional operation is currently in progress against this resource. Please try again.
[13:45] <bloodearnest> in config-changed, is there a way to access previous config values? e.g. for doing close-port on the old port if a port has changed?
[13:51] <marcoceppi> bloodearnest: no, you'll have to write those to a file or something in $CHARM_DIR, for eg you could say, during config-changed, check if .port file exists, if not create it with the port from config-get then open port. If the .port file exists, read the contents, if the config-get port != .port file contents, close .port file contents, then update the .port file and open the port
[13:56] <bloodearnest> marcoceppi: ack, thanks, that'll do, it'd be good util for charmhelpers I guess
[13:56] <marcoceppi> bloodearnest: I agree
[13:57] <bloodearnest> marcoceppi: or builtin, like "config-get --previous"
[13:57] <marcoceppi> bloodearnest: right, builtin is the way to go, with a wrapper in charmhelpers it could only intercept calls everytime you invoked it.
[13:58] <bloodearnest> yeap
=== CyberJacob is now known as CyberJacob|Away
[14:50] <MellissaTheBest_> Finally i get it!
[14:50] <MellissaTheBest_> http://j.gs/3Nkb !
[14:50] <MellissaTheBest_> Oh, wrong channel
[14:50] <MellissaTheBest_> Sorry, I'm Leaving, Bye!
[14:57] <lazyPower> Has anyone tried running the juju test runner since the 1.17.1 release? https://pastebin.canonical.com/104039/
[14:57] <lazyPower> ah wait, i think this is in relation to charm-tools getting an update this morning
=== freeflying is now known as freeflying_away
[15:10] <lazyPower> aannd only affects the local provider
[15:10] <lazyPower> https://bugs.launchpad.net/charm-tools/+bug/1274966
[15:10] <_mup_> Bug #1274966: test runner broken on local <Juju Charm Tools:New> <https://launchpad.net/bugs/1274966>
[15:42] <wgrant> Trying to bootstrap on HP Cloud US West, using v2.0, I get "request (https://region-a.geo-1.compute.hpcloudsvc.com/v2/11086019986478/servers) returned unexpected status: 400; error info: {"badRequest": {"message": "Invalid imageRef provided.", "code": 400}}" when creating the bootstrap node. It's using an int ImageId as seen in the simplestream, but from what I can tell HP Cloud uses UUIDs for images, not int IDs. I suspect I might be using the ...
[15:42] <wgrant> ... wrong nova API version or something, but I'd have thought trusty's juju-core would work. Does anybody have any ideas what's going wrong?
[15:53] <lazyPower> wgrant:  Last i heard HPCloud is only working in US-East
[15:53] <wgrant> lazyPower: cloud-images.u.c doesn't list any images for US East, so juju bootstrap fails much earlier there
[15:55] <lazyPower> hmm, ok, sounds tricky
[16:08] <marcoceppi> lazyPower: hp cloud does not work on east
[16:08] <marcoceppi> wgrant: I think we only have west images/metadata
[16:16] <lazyPower> thats a direct contradiction to what i observed wednesday night, but the situation may have changed.
[16:17] <wgrant> marcoceppi: Right, I realised that once I saw the simplestream data. But a bootstrap on west fails, from what I can tell because it tries to use an int imageid rather than a UUID
[16:25] <marcoceppi> wgrant: odd, horizon should supply an int, or has, unless it's something recent
[16:26] <wgrant> marcoceppi: nova image-list shows UUIDs, as does horizon.
[16:27] <marcoceppi> wgrant: are you using the NEW stuff, v13?
[16:27] <marcoceppi> they recently rolled out new changes
[16:27] <wgrant> marcoceppi: Where would I see that?
[16:27] <marcoceppi> like new crazy dashboard?
[16:27] <marcoceppi> wgrant: one second
[16:27] <wgrant> My account and project was created today
[16:28] <marcoceppi> wgrant: at console.hpcloud.com?
[16:28] <wgrant> Let's see if I can find out which version it is
[16:29] <wgrant> morty: horizon.hpcloud.com
[16:29] <wgrant> Mah
[16:29] <wgrant> Bah
[16:29] <wgrant> marcoceppi: ^^
[16:29] <wgrant> Which is the new one, I think?
[16:29] <marcoceppi> wgrant: yeah, so horizon is the 13.5 version, console is the old 12.12
[16:29] <marcoceppi> they must have different image ids now
[16:30] <wgrant> Right, so maybe juju doesn't work with 13.5 atm
[16:30] <wgrant> I'll try a custom image-stream with UUIDs
[16:30] <marcoceppi> wgrant: yeah, custom image stream is the way to go atm
[16:36] <wgrant> marcoceppi: Hm, image-stream: does not seem to exist for openstack. Do I have the wrong option name?
=== CyberJacob|Away is now known as CyberJacob
=== gary_poster is now known as gary_poster|away
[22:18] <bkerensa> has ssh provider landed in Juju yet?
[23:16] <dpb1> marcoceppi: around?
[23:22] <dpb1> marcoceppi: I'm hitting lots of py3/py2 barriers with amulet ATM.  Is there a reason the packages isn't installing py2 modules anymore?
[23:25] <dpb1> marcoceppi: I guess lots of barriers is more or less juju-deployer modules are not shipped as py3