=== kadams54 is now known as kadams54-away === kadams54-away is now known as kadams54 === rcjenn is now known as rcj === kadams54 is now known as kadams54-away === kadams54-away is now known as kadams54 === kadams54 is now known as kadams54-away [02:02] axw: You were right about the access to s3, I can access the url from other machines. On another machine using the same creds, it still fails to bootstrap, this time with: [02:03] 2015-01-28 02:00:39 ERROR juju.cmd supercommand.go:323 cannot determine if environment is already bootstrapped.: The authorization mechanism you have provided is not supported. Please use AWS4-HMAC-SHA256. [02:03] but I can create a separate bug for that (assuming it's not something obvious) [02:03] noodles775: cool. yep, I think that needs a bug - not sure if that's a Juju or goamz one, probably the latter === kadams54-away is now known as kadams54 === kadams54 is now known as kadams54-away === kadams54-away is now known as kadams54 === kadams54 is now known as kadams54-away === wolsen_ is now known as wolsen === zz_CyberJacob is now known as CyberJacob === CyberJacob is now known as zz_CyberJacob === mthaddon` is now known as mthaddon [10:11] I'm trying to upgrade a running juju environment from 1.16 (!) to 1.18 (so we can later upgrade it to 1.2x). When I run juju upgrade-juju I get "WARNING running in 1.16 compatibility mode". juju --version reports 1.18.4-precise-amd64 === dosaboy_ is now known as dosaboy [10:21] jamespage, https://code.launchpad.net/~gnuoy/charms/trusty/neutron-openvswitch/fis-amqp-ssl/+merge/247806 if you have a moment [10:22] gnuoy`, +1 [10:23] thanks [10:29] jamespage, do you have any time to test a network splits deploy with the next charms today ? [10:29] gnuoy`, I can mnake some [10:29] jamespage, that would be great, thank you [10:30] jamespage, I have a keystone ssl fix from dosaboy to land, I'll let you know when that's done. [10:45] turns out I needed to add --upload-tools to the command, for those following along at home [10:58] mthaddon: that may and probalby will yield odd behavior down the road [10:58] --upload-tools is only intended to be used by developers working on client code. There's a rather long thread on this over on the mailing list from ~ 5 days ago [10:58] lazyPower|Travel: orly? what kinds of things? [10:59] mthaddon: YMMV - its chunking up a custom client based on whats in your local environment, doesn't follow the semantic versioning of the existing client releases, and hasn't been tested with long running environments. [10:59] the response i got when asking about that was 'there be dragons there, that command should never be used by mier mortals" [11:00] lazyPower|Travel: is there some other way of upgrading from such an old version of juju? <-- dimitern, you may be interested in this given you helped me with that [11:00] mthaddon: you're going from .16 to .18 right? [11:00] lazyPower|Travel: yep [11:00] juju upgrade-juju should have done the trick [11:00] lazyPower|Travel: yeah, but it didn't unfortunately :) [11:00] which will lockstep the deployed release in the environment to the one you have locally from streams. [11:01] are you running -beta? [11:01] er -devel [11:01] lazyPower|Travel, it didn't unfortunately - not without --upload-tools [11:01] 1.18.4-precise-amd64 [11:01] weird [11:01] seems like there's a problem there in upgrade-juju tbh [11:02] i would most def follow up with sinzui about this, as that upgrade path should have been tested and blessed (not sure if 1.18.4 specifically was tested, we might have broken it) [11:02] mthaddon: this is a production env yes? [11:02] I'd be happy to follow up with sinzui - we have a lot of envs (staging and production) to upgrade, so I'd like to figure out whatever the "blessed" path is [11:03] lazyPower|Travel: this particular env was a staging one (always start with staging if you can... ) [11:03] 1.18 is not tested anymore [11:03] yeah, i think thats where my thought process is going. I don't want to gaslight you if thats the only wya to upgrade the env, but i've been told that its not recommended. [11:03] yeah, understood - I'm certainly happy to wait for confirmation either way - thx [11:03] * lazyPower|Travel hattips [11:04] dimitern: good to know. did we drop testing 1.18 after the 1.20 rel? [11:07] jamespage, dosaboys keystone change has landed [11:08] lazyPower|Travel, AFAIK 1.18 never went into automated upgrades testing [11:09] those tests weren't in place at that time [11:17] gnuoy`, ack on it now [11:17] thank you, much appreciated [11:47] gnuoy`, urgh - frustratingly juju-core 1.21 decided to ignore all my existing machines when deploying charms [11:47] ... [11:47] ahhh /o\ [11:51] gnuoy`, checking to see if that's a change since 1.20 [11:57] gnuoy`, it does indeed seem to be different === gnuoy` is now known as gnuoy [12:16] dimitern: ah ok. I thought we had those in place ~ 1.16 - i was sorely mistaken. === lazyPower|Travel is now known as lazyPower [12:40] gnuoy, generally looing ok === roadmr is now known as roadmr_afk [15:46] Hello. I was wondering if anyone had a working yaml for the hacluster charm? I can't seem to get it to work with percona-mysql as it doesn't ever seem to modify the corosync config file with the proper interface name. [15:48] hey guys! o/ [15:49] I found some strange behaviors in the juju gui at the demo site [15:49] here's an screenshot [15:49] http://awesomescreenshot.com/0024ae5f3e [16:30] sebas5384: dump cache and reload - thats how i resolved the tiny icons [16:30] rick_h_: ^ [16:30] lazyPower: hey! o/ [16:30] o/ [16:30] lazyPower: hmmm I'll check that out [16:31] sebas5384: seems that there's some weirdness with the asset caching that causes the icon issues :( [16:32] heya [16:33] lazyPower: nope :( still having the bug after clearing the cache [16:33] sebas5384: can you file a bug targeted at juju-gui so we can track it? [16:34] lazyPower: https://bugs.launchpad.net/juju-gui/+bug/1415550 [16:34] Bug #1415550: Charm's SVG icons with wrong size in Chrome