Guys,
I hate to break this to you, but deploying and managing Juju is still
too hard and too unreliable.
I hear this in the market, and my own experience confirms it. The two
times I tried, once on my local system, once on Azure, it didn't work.
My Juju t-shirt lists Azure first, so I
On 22/09/14 03:29, Michael Schwartz wrote:
Guys,
I hate to break this to you, but deploying and managing Juju is still
too hard and too unreliable.
I hear this in the market, and my own experience confirms it. The two
times I tried, once on my local system, once on Azure, it didn't
Hey Mike,
I am sorry that you are having a hard time with Juju.
As Tim said, it would be awesome if you could go a little bit more
in-depth about the issues that you are experiencing, so we can
understand what's going on and file bugs if necessary.
Also, I see that you are testing Juju on a
Its sort of misses the point on why we're doing client side transactions.
Mongodb has builtin atomic operations on an individual document. We use
client side txns (multiple order of magnitude slower) for multi-document
txns *and/or* things we want to observe for watches.
-k
--
Juju-dev mailing
Hi Kapil,
I'm sure that the 'put everything in a transaction' pattern is applied
unilaterally.
Do you have some specific operations in mind ?
Dave
On Mon, Sep 22, 2014 at 7:46 AM, Kapil Thangavelu
kapil.thangav...@canonical.com wrote:
Its sort of misses the point on why we're doing client
There is one that I talked with Kapil about this morning.
When a user connects over the client api, we record the last login time.
Currently this uses a transaction, but doesn't need to. In fact using a
transaction here takes an order of magnitude longer, and wakes up
watchers when it doesn't
On Mon, Sep 22, 2014 at 3:00 AM, Tim Penhey tim.pen...@canonical.com
wrote:
There is one that I talked with Kapil about this morning.
When a user connects over the client api, we record the last login time.
Currently this uses a transaction, but doesn't need to. In fact using a
transaction
