-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2013-10-30 21:49, Jorge O. Castro wrote:
> A very spooky charm status!!
>
> ## General Info - [Pad](http://pad.ubuntu.com/7mf2jvKXNa) - [Status
> Board](https://trello.com/board/charmers-board/4ec1696da3f94bd2ea5b2b01)
>
>
- - [Juju.u.c Meeting
>
All I can tell you is from my experience that Precise and the local
provider are not tested and not known to work. You _may_ try the HWE
raring kernel on your precise host, but I recommend Raring or later if
you want to use the local provider.
On Thu, Oct 31, 2013 at 8:11 AM, Serge E. Hallyn wrot
I'm told that's for a network (veth nic?) performance issue? FWIW
my main build+test box is running on 3.2 precise kernel with
ubuntu-lxc daily ppa. overlayfs and lvm clones work perfectly out
of the box, and btrfs (which i'm using now) only have the fsync
performance issue, which I work around b
A very spooky charm status!!
## General Info
- [Pad](http://pad.ubuntu.com/7mf2jvKXNa)
- [Status
Board](https://trello.com/board/charmers-board/4ec1696da3f94bd2ea5b2b01)
- [Juju.u.c Meeting
Site](https://juju.ubuntu.com/community/weekly-charm-meeting/)
- [Video of Meeting](http://youtu.be/HnNwRUA
On Wed, Oct 30, 2013 at 7:50 AM, Marco Ceppi wrote:
> You can't make that assumption and we really frown upon it in charm reviews.
> I've seen cases where `juju deploy -n 5 service` results in unit 2 or really
> unit > 0 being first up. There's also scenarios where there might not
> actually be a
On Wed, Oct 30, 2013 at 10:47 AM, Gustavo Niemeyer wrote:
> On Wed, Oct 30, 2013 at 7:35 AM, Kapil Thangavelu
> wrote:
> > Just thinking outloud, but In the active-active db scenario, there's an
> > available db for the charm to store this info. ie. the charm could keep
> some
> > bookeeping tabl
On Wed, Oct 30, 2013 at 7:35 AM, Kapil Thangavelu
wrote:
> Just thinking outloud, but In the active-active db scenario, there's an
> available db for the charm to store this info. ie. the charm could keep some
> bookeeping tables/db instead of using files on disk (a shared key via peer
> relation
On Wed, Oct 30, 2013 at 4:58 AM, James Page wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> On 29/10/13 17:12, Kapil Thangavelu wrote:
> > fwiw, the mysql charm tries to address this with a shared-db
> > interface, and a separate admin interface. ie the shared-db
> > interface shar
Hi James,
What is the inconsistency problem with trying to share the password
via relations?
On Wed, Oct 30, 2013 at 4:58 AM, James Page wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> On 29/10/13 17:12, Kapil Thangavelu wrote:
>> fwiw, the mysql charm tries to address this with a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 29/10/13 17:12, Kapil Thangavelu wrote:
> fwiw, the mysql charm tries to address this with a shared-db
> interface, and a separate admin interface. ie the shared-db
> interface shares out the same db user/password to multiple
> services, and then
10 matches
Mail list logo