[09:18] <gnuoy> jamespage, I've updated https://code.launchpad.net/~gnuoy/charms/trusty/percona-cluster/respect-the-vip/+merge/239010
[09:18] <gnuoy> and here are the neutron db migration mps:
[09:18] <gnuoy> https://code.launchpad.net/~gnuoy/charms/trusty/nova-cloud-controller/make-neutron-db-authority/+merge/239172
[09:18] <gnuoy> https://code.launchpad.net/~gnuoy/charms/trusty/neutron-api/remove-db-migrations/+merge/239171
[09:19] <jamespage> gnuoy, +1
[09:19] <jamespage> looks goot
[09:19] <gnuoy> jamespage, thanks
[09:20] <jamespage> gnuoy, so for those 2nd two, nova-cc will always handle the migration right?
[09:20] <gnuoy> jamespage, right
[09:21]  * jamespage thinks
[11:30] <ayr-ton> marcoceppi, That wordpress-mu charm does exist? http://askubuntu.com/questions/256759/deploy-multiple-wordpress-sites-with-juju
[15:28] <dpb1> If I'm on trusty, how do I launch utopic local-provider containers?  I get tools errors by default.
[15:34] <natefinch> dpb1: I'm not sure we have utopic tools deployed in streams yet.  sinzui ?
[15:36] <sinzui> what? We testing and build the ubuntu devel series from the week it was created. we even say in the announcements that we created juju for utopic, and backported to trusty and precise.
[15:40] <natefinch> sinzui: sorry, I don't always read the announcements that carefully
[16:04] <dpb1> sinzui, natefinch: an extra parameter to bootstrap perhaps?
[16:04] <dpb1> ah, maybe --series or upload-series?
[16:05] <dpb1> seems weird though
[16:05] <dpb1> let me try again to confirm
[16:06] <dpb1> interesting
[16:06] <dpb1> dpb@helo:slaves$ juju bootstrap -v
[16:06] <dpb1> uploading tools for series [precise trusty]
[16:06] <natefinch> dpb1: you can add default-series to your environments.yaml
[16:06] <sinzui> dpb1, juju does not fully support non-lts series. juju lts clients will only provide tools for lts series. non-lts clients are designed to provide tools for itself and the lts
[16:07] <dpb1> so, when bootstrapping the local env, it always uses upload tools?
[16:09] <sinzui> dpb1, juju is a punk https://bugs.launchpad.net/juju-core/+bug/1302119
[16:09] <mup> Bug #1302119: sync-tools ignores tools-metadata-url <ci> <sync-tools> <juju-core:Triaged> <https://launchpad.net/bugs/1302119>
[16:11] <dpb1> interesting.
[16:12] <sinzui> dpb1, I think you can bootstrap, then run juju sync-tools which will get all the combinations for the version of the state server
[16:13] <dpb1> sinzui: doing 'juju --upload-tools --upload-series utopic,trusty,precise' worked it seems
[16:13] <sinzui> excellent
[16:13] <dpb1> sinzui: I'd still like to understand if the local provider uses upload-tools by default.  I guess I've never noticed that?
[16:18] <dpb1> sinzui: I guess it's this question: http://askubuntu.com/questions/486542/upload-all-release-versions-of-tools-with-jujus-local-lxc-provider
[16:20] <sinzui> dpb1, yep, except we changed the name of the option to --upload-series
[16:45] <mattyw> dimitern, this is how I ended up wording it: https://bugs.launchpad.net/juju-core/+bug/1384336
[16:45] <mup> Bug #1384336: juju resolved reports already resolved on a unit in error state if a hook is still running <juju-core:New> <https://launchpad.net/bugs/1384336>
[16:45] <dimitern> mattyw, +1 sgtm
[17:36] <jcastro> evilnickveitch, thanks for that doc merge
[18:11] <natefinch> rick_h_, jcastro, anyone else.... do we have a canonical bundle that the tosca guys can try out?  The guy working on the tosca->juju translator is having trouble with bundle proof not liking anything he throws at it.
[18:11] <rick_h_> natefinch: https://jujucharms.com/bundle/elasticsearch/15/cluster/ https://jujucharms.com/bundle/mongodb/5/cluster/ are two that we know are good/on the front page
[18:12] <natefinch> rick_h_: what's with the random number in the url?
[18:13] <jcastro> hah!
[18:13] <rick_h_> revision
[18:13] <rick_h_> :)
[18:13] <natefinch> disapprove
[18:16] <rick_h_> natefinch: it's changing :)
[18:16] <natefinch> :)
[18:18] <natefinch> how the hell do I get help on a plugin subcommand?  i.e. help on juju bundle proof?  juju help bundle proof  doesn't work, juju bundle help proof  doesn't work, juju-bundle help proof  doesn't work
[18:20] <natefinch> all of them just return "usage: charm-help subcommand" and then a list of subcommands
[18:20] <natefinch> charm-help bundle  and charm-help proof also don't work
[18:21] <natefinch> jcastro: ^?
[18:22] <jcastro> no clue
[18:23] <jcastro> `juju-bundle proof .` is the only way I use it
[18:23] <jcastro> `juju-bundle proof <target>` rather
[18:23] <rick_h_> and charm prooof works
[18:23] <rick_h_> it auto detects a bundle
[18:24] <jcastro> do we use bundle for anything else?
[18:25] <rick_h_> not that I can recall
[18:25] <jcastro> seems like we could just sunset that command if we're not?
[18:25] <natefinch> heh
[18:28] <jrwren> natefinch: depends on the subcommand, but  juju charm add -h   just worked for me.
[18:29] <natefinch> yeah, I figured that out eventually.... it just is infuriating that "help" is a valid subcommand but doesn't actually do anything useful except print out the subcommands
[18:30] <natefinch> this happened the last time I tried to get help on charm-proof (which is evidently what juju-bundle is, just renamed... which means the help says "usage: charm-proof" even though I'm invoking it using "juju bundle"
[18:30] <jrwren> natefinch: juju is amazing. :)
[18:33] <natefinch> jrwren: well, to be fair, it's the plugin's fault, not juju's :)
[18:33] <natefinch> pretty sure I already filed a bug about this on charm-proof...
[18:34] <natefinch> found it - https://bugs.launchpad.net/charm-tools/+bug/1327179
[18:34] <mup> Bug #1327179: charm help should show how to get help about a specific command <Juju Charm Tools:New> <https://launchpad.net/bugs/1327179>
[18:45] <marcoceppi> ayr-ton: no, not yet
[19:08] <bloodearnest> hazmat: heya, another small deployer MP for you: https://code.launchpad.net/~bloodearnest/juju-deployer/annotate-branches/+merge/239270
[19:08] <bloodearnest> going to start work on improving diff capabilities next
[19:53] <lazyPower> marcoceppi: setting default isntance type for AWS in ~/.juju/environments/yaml is "default-instance-type: m1.medium" - for example, right?
[19:53] <lazyPower> i'm going to plug this into teh docs as well - since it appears to be missing from the amazon provider docs.
[19:53] <marcoceppi> that's a super depriciated field that probably doesn't work anymore
[19:53] <marcoceppi> juju bootstrap --constraints is the way to set this stuff
[19:54] <lazyPower> oh! i didn't know it was depreciated. ta!
[19:54] <marcoceppi> where did you find that?
[19:54] <lazyPower> well, it was from memory
[19:54] <marcoceppi> I'm like 90% sure it's depreciated from pyjuju days
[19:55] <lazyPower> its now been depreciated from my memory
[19:55] <marcoceppi> you might want to double check
[19:55] <marcoceppi> maybe thumper knows
[19:55] <lazyPower> i'd rather tell people to use --constraints myself....
[19:55] <lazyPower> it keeps it consistent across providers
[19:55] <marcoceppi> right
[19:55] <marcoceppi> that, I believe, was the idea
[19:58] <lazyPower> marcoceppi: yeah, that combined with set-constraints seems to be what i was looking for
[19:58] <lazyPower> why bother knowing what instance types per provider.
[19:58] <lazyPower> ta, again. ya kept me from spreading FUD