[02:02] <noodles775> 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] <noodles775> 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] <noodles775> but I can create a separate bug for that (assuming it's not something obvious)
[02:03] <axw> noodles775: cool. yep, I think that needs a bug - not sure if that's a Juju or goamz one, probably the latter
[10:11] <mthaddon> 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
[10:21] <gnuoy`> jamespage, https://code.launchpad.net/~gnuoy/charms/trusty/neutron-openvswitch/fis-amqp-ssl/+merge/247806 if you have a moment
[10:22] <jamespage> gnuoy`, +1
[10:23] <gnuoy`> thanks
[10:29] <gnuoy`> jamespage, do you have any time to test a network splits deploy with the next charms today ?
[10:29] <jamespage> gnuoy`, I can mnake some
[10:29] <gnuoy`> jamespage, that would be great, thank you
[10:30] <gnuoy`> jamespage, I have a keystone ssl fix from dosaboy to land, I'll let you know when that's done.
[10:45] <mthaddon> turns out I needed to add --upload-tools to the command, for those following along at home
[10:58] <lazyPower|Travel> mthaddon: that may and probalby will yield odd behavior down the road
[10:58] <lazyPower|Travel> --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] <mthaddon> lazyPower|Travel: orly? what kinds of things?
[10:59] <lazyPower|Travel> 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] <lazyPower|Travel> the response i got when asking about that was 'there be dragons there, that command should never be used by mier mortals"
[11:00] <mthaddon> 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] <lazyPower|Travel> mthaddon: you're going from .16 to .18 right?
[11:00] <mthaddon> lazyPower|Travel: yep
[11:00] <lazyPower|Travel> juju upgrade-juju should have done the trick
[11:00] <mthaddon> lazyPower|Travel: yeah, but it didn't unfortunately :)
[11:00] <lazyPower|Travel> which will lockstep the deployed release in the environment to the one you have locally from streams.
[11:01] <lazyPower|Travel> are you running -beta?
[11:01] <lazyPower|Travel> er -devel
[11:01] <dimitern> lazyPower|Travel, it didn't unfortunately - not without --upload-tools
[11:01] <mthaddon> 1.18.4-precise-amd64
[11:01] <lazyPower|Travel> weird
[11:01] <lazyPower|Travel> seems like there's a problem there in upgrade-juju tbh
[11:02] <lazyPower|Travel> 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] <lazyPower|Travel> mthaddon: this is a production env yes?
[11:02] <mthaddon> 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] <mthaddon> lazyPower|Travel: this particular env was a staging one (always start with staging if you can... )
[11:03] <dimitern> 1.18 is not tested anymore
[11:03] <lazyPower|Travel> 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] <mthaddon> yeah, understood - I'm certainly happy to wait for confirmation either way - thx
[11:03]  * lazyPower|Travel hattips
[11:04] <lazyPower|Travel> dimitern: good to know. did we drop testing 1.18 after the 1.20 rel?
[11:07] <gnuoy`> jamespage, dosaboys keystone change has landed
[11:08] <dimitern> lazyPower|Travel, AFAIK 1.18 never went into automated upgrades testing
[11:09] <dimitern> those tests weren't in place at that time
[11:17] <jamespage> gnuoy`, ack on it now
[11:17] <gnuoy`> thank you, much appreciated
[11:47] <jamespage> gnuoy`, urgh - frustratingly juju-core 1.21 decided to ignore all my existing machines when deploying charms
[11:47] <jamespage> ...
[11:47] <gnuoy`> ahhh /o\
[11:51] <jamespage> gnuoy`, checking to see if that's a change since 1.20
[11:57] <jamespage> gnuoy`, it does indeed seem to be different
[12:16] <lazyPower|Travel> dimitern: ah ok. I thought we had those in place ~ 1.16 - i was sorely mistaken.
[12:40] <jamespage> gnuoy, generally looing ok
[15:46] <jlondon> 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] <sebas5384> hey guys! o/
[15:49] <sebas5384> I found some strange behaviors in the juju gui at the demo site
[15:49] <sebas5384> here's an screenshot
[15:49] <sebas5384> http://awesomescreenshot.com/0024ae5f3e
[16:30] <lazyPower> sebas5384: dump cache and reload - thats how i resolved the tiny icons
[16:30] <lazyPower> rick_h_: ^
[16:30] <sebas5384> lazyPower: hey! o/
[16:30] <lazyPower> o/
[16:30] <sebas5384> lazyPower: hmmm I'll check that out
[16:31] <lazyPower> sebas5384: seems that there's some weirdness with the asset caching that causes the icon issues :(
[16:32] <mwak> heya
[16:33] <sebas5384> lazyPower: nope :( still having the bug after clearing the cache
[16:33] <lazyPower> sebas5384: can you file a bug targeted at juju-gui so we can track it?
[16:34] <sebas5384> lazyPower: https://bugs.launchpad.net/juju-gui/+bug/1415550
[16:34] <mup> Bug #1415550: Charm's SVG icons with wrong size in Chrome <icon> <svg> <juju-gui:New> <https://launchpad.net/bugs/1415550>
[16:34] <sebas5384> ha!
[16:34] <sebas5384> hatch: told me to do that in the juju-gui channel
[16:35] <lazyPower> :)
[16:43] <whit> mbruzek,  I use: juju set-constraints instance-type="m3.xlarge"
[16:51] <jlondon> I'll ask again now that a few people are around. Are there any known issues with the hacluster (corosync/pacemaker) charm? No matter what configuration options I throw at it, it doesn't seem to change the service configuration to reflect the correct network card and thus startup fails.
[17:09] <beisner> jamespage, jog, sinzui, FYI The 8 currently-supported openstack deploy test targets all pass osci with juju/proposed (1.21.0-0ubuntu1~14.04.1~juju1). [precise-icehouse, trusty-icehouse, trusty-juno, utopic-juno] x [stable, next charms];  We also cycled mojo openstack deploys and amulet tests with this version in osci without issue.
[17:10] <jog> beisner, awesome
[17:10] <sinzui> beisner, \o/
[17:21] <jlondon> So, no one? Please... I'll buy you a beer :D
[17:50] <Guest63482>  i get and error when adding more than one same service
[17:51] <Guest63482> i meant the repetition of command "juju deploy lxc:0 wordpress fails"
[17:51] <Guest63482> i want two wordpress services for two different websites
[17:52] <Guest63482> any suggestions
[17:52] <Guest63482> ?
[17:56] <jlondon> Good luck. Like the other Ubuntu related channels help from the devs seems to be limited :\
[17:56] <beisner> hi jlondon, most of the hacluster devs are super busy working on this week's next release of the openstack charm set (which encompasses the hacluster charm);  it may be worth waiting to get those Fri.  fyi, we do use hacluster and percona-cluster charms, though i don't have an example off-hand.
[17:57] <jlondon> beisner: Appreciate the respone. Thanks for letting me know! I'll wait for those and try again!
[17:57] <beisner> jlondon, yes please do.  you may also find a wider hacluster audience on #ubuntu-server.
[17:57] <Odd_Bloke> Guest63482: I think you have to give Juju a name for the second Wordpress.
[17:58] <Odd_Bloke> Guest63482: By default, it will use 'wordpress', but I guess it's erroring because of the duplicate name.
[17:58] <jlondon> beisner: Okay thanks. Do you know though if hacluster is expecting to be in a container? I am not placing it in one... maybe that's my issue.
[17:58] <Odd_Bloke> Guest63482: (For reference, putting the output you're seeing on http://paste.ubuntu.com makes working out what's going on easier :))
[17:58] <Guest63482> Odd_Bloke:  can you hint me how to do so plz?
[17:59] <Odd_Bloke> Guest63482: The first line of 'juju deploy --help' is "usage: juju deploy [options] <charm name> [<service name>]" ;)
[17:59] <Guest63482> how to deploy wordpress with an other name
[17:59] <Guest63482> ?
[18:00] <Guest63482> k
[18:00] <Guest63482> got it thanks
[18:01] <Guest63482> odd_bloke: is there a way to do so through gui ?
[18:01] <beisner> jlondon, in our deployment, 3 percona-cluster units are in lxc containers; and the hacluster is subordinate-to percona-cluster.   though i do not think that containers are explicitly required(?).
[18:01] <jlondon> beisner: Got it. I'll try containers regardless if that's what you guys have working.
[18:02] <Guest63482> yes i got it it works
[20:31] <arosales> jcastro: really nice post @ https://insights.ubuntu.com/2015/01/28/datacentres-in-containers-and-containers-in-datacentres/
[21:53] <catbus1> Hi, I have juju bootstrapped, is the bootstrap log stored somewhere?
[21:55] <blr> catbus1: are the bootstrap logs consolidated into 'juju debug-log'?
[23:33] <noodles775> axw: do know, if https://github.com/go-amz/amz/issues/22 is fixed, whether it'd be likely to be included in an update to the juju in trusty? (trying to find out if I need to get ask for multiple versions of juju on our deployment machine)
[23:34] <noodles775> s/do know/do you know/
[23:35] <noodles775> We generally only use stable releases (so upgrading environments is supported)
[23:42] <jlondon> Anyone know how to get lxc to use the correct maas provided bridge name? It's defaulting to lxcbr0 and not juju-br0.