se unmarshaling unmarshals as bson.M
> which does not preserve key order.
>
> https://play.golang.org/p/_1ZPl7iMyn
>
> On 8 June 2016 at 15:55, Gustavo Niemeyer
> wrote:
> > Is it mgo itself that is changing the order internally?
> >
> > It should not do that.
> &g
Is it mgo itself that is changing the order internally?
It should not do that.
On Wed, Jun 8, 2016 at 8:00 AM, roger peppe wrote:
> OK, I understand now, I think.
>
> The underlying problem is that subdocument searches in MongoDB
> are order-sensitive.
>
> For example, I just tried this in a mo
ngly we are already fairly heavily overcommitted. We have 4GB
> of RAM and 4GB of swap available. And cat /proc/meminfo is saying:
> CommitLimit: 6214344 kB
> Committed_AS:9764580 kB
>
> John
> =:->
>
>
>
> On Wed, Jun 3, 2015 at 9:28 AM, Gustavo Niemeyer
Ah, and you can also suggest increasing the swap. It would not actually be
used, but the system would be able to commit to the amount of memory
required, if it really had to.
On Jun 3, 2015 1:24 AM, "Gustavo Niemeyer" wrote:
> Hey John,
>
> It's probably an overcommit
Hey John,
It's probably an overcommit issue. Even if you don't have the memory in
use, cloning it would mean the new process would have a chance to change
that memory and thus require real memory pages, which the system obviously
cannot give it. You can workaround that by explicitly enabling overc
On Thu, May 14, 2015 at 1:45 AM, John Meinel wrote:
> So one small wrench that we will want to investigate.
>
> While we were trying to cleanup the database, we found a lot of documents
> with transaction ids in txn-queue that references txn documents that were
> already in APPLIED (6) state.
> L
Hey Menno,
I'm copying the list to ensure we have this documented somewhere for future
reference.
You are right that it's not that simple, but it's not that complex either
once you understand the background.
Transactions are applied by the txn package by tagging each one of the
documents that wi
Hi John,
On Thu, Apr 2, 2015 at 8:44 AM, John Meinel wrote:
>
> All of which seems pretty standard. If we find out we are dying while we
> are trying to do something else, return ErrDying. When that bubbles up to
> the top, we just call tomb.Kill() with any error that we got so that if we
> got a
The core state (The State) is the one case where it doesn't matter,
IMO. Everybody knows what it is. It's the other dozen that create the
issue, and they will remain as ambiguous if you just rename the one
State.
On Thu, Mar 12, 2015 at 11:23 AM, Eric Snow wrote:
> On Thu, Mar 12, 2015 at 5:08 AM
When I was new to juju myself, we only had one State, I believe. That
one golden state was supposed to represent the state of the whole
deployment, so it was indeed The State of the system. Having tons of
these indeed sounds awkward.
On Thu, Mar 12, 2015 at 8:08 AM, Michael Foord
wrote:
>
>
> On
Hi Nate,
On Tue, Feb 24, 2015 at 2:24 PM, Nate Finch wrote:
(...)
> To support this, we need a way to say "use the default placement policy".
> For this, we propose the keyword "default". Thus, to fix the above example,
> Bill would type this:
>
>> $ juju ensure-availability --to lxc:1,default
>
On Fri, Feb 13, 2015 at 6:50 PM, Eric Snow wrote:
> Using a fake for that input means you don't have to encode the
> low-level business logic in each test (just any setup of the fake's
> state). You can be confident about the low-level behavior during
> tests as matching production operation (as
On Fri, Feb 13, 2015 at 3:25 PM, Eric Snow wrote:
>> This is a "mock object" under some well known people's terminology [1].
>
> With all due respect to Fowler, the terminology in this space is
> fairly muddled still. :)
Sure, I'm happy to use any terminology, but I'd prefer to not make one
up ju
On Fri, Feb 13, 2015 at 2:05 PM, Eric Snow wrote:
> As for me, by "fake" I mean a struct that implements an interface with
> essentially no logic other than to keep track of method calls and
> facilitate controlling their return values explicitly. For examples
> see the implementations for GCE an
On Wed, Feb 11, 2015 at 4:53 PM, Eric Snow wrote:
> tl;dr Using fakes for testing works well so I wrote a base fake type. [1]
>
> While working on the GCE provider, Wayne and I started taking a
> different approach to unit testing than the usual 1. expose an
> external dependency as an unexported
y
> README and documentation. I also intend to update the interface to
> match the feature as closely as possible as the proposal becomes more
> concrete.
>
> On Wed, Feb 11, 2015 at 2:33 PM, Gustavo Niemeyer
> wrote:
>> Hi Cory,
>>
>> While it's fine and
Hi Cory,
While it's fine and welcome to have such test bed features, it feels
like the proposal and implementation have quite different goals from
the actual resources feature we've been talking about for a while, so
as a very early suggestion and request, I would strongly recommend
renaming the f
On Mon Jan 12 2015 at 1:55:27 PM Eric Snow wrote:
>
> > - Being a tag means it's possible to have a name *and* a UUID
>
> What do you mean by this? Do tags incorporate the env UUID somehow?
>
A tag can be an arbitrary key/value pair, which implies both the name and
the UUID may be stored.
--
Ju
A few quick notes:
- Having an understandable name in a resource useful
- Being a tag means it's possible to have a name *and* a UUID
- It's surprising to have machines destroyed as a side effect of bootstrap
On Mon Jan 12 2015 at 7:24:05 AM roger peppe
wrote:
> On 12 January 2015 at 03:17,
eeling that it won't be
>> necessary given how far we have come without it.
>>
>> I did like the internal packages, however these are only enforced in the
>> Go standard library with 1.4, and other packages with 1.5. Still a good
>> idea though.
>>
>> Ti
Thanks for the write up Katherine, and I agree these are all very nice
improvements.
On this list, the one I find slightly less exciting is "go generate". This
is essentially a standard way to run external processing tools, which might
already be done before anyway via standard practices. For exam
I generally just "hand code" that sort of logic as well:
http://play.golang.org/p/Hvi9t_ZFlw
and yeah, big-endian is the "network byte order". Technically, anything
would work (XOR it with 42!), but it would be surprising.
On Thu Dec 04 2014 at 5:50:13 PM Nate Finch
wrote:
> http://pla
FWIW, *"open-ports --close-others"* feels pretty simple and
uncontroversial, even more when it comes from a core developer that
apparently would be implementing the feature himself to solve his own pain
points. Golden case.
On Sat Nov 01 2014 at 2:58:42 PM John Meinel wrote:
> I believe there
Reminding people of everything they should *not be doing *to get a feature
to be listed in the release notes is very ineffective.
What should they *be doing* instead, and why will the process work in the
future when it clearly has failed before, despite the assumed good
intention we should assume
The source code of mongodump lives at:
https://github.com/mongodb/mongo-tools/tree/master/mongodump
It is now written in Go, using mgo. Should be easy to find out any details
you need there.
On Thu Oct 30 2014 at 12:45:52 PM Eric Snow wrote:
> When running mongodump with the --oplog, you end u
I have never used "upstream" as an actual remote name. I see people
commonly using the term as a wildcard to refer to the "upstream branch"
whatever it is. The term is also used widely in git itself with the same
meaning, including in the command line interface. For example, you set the
upstream br
oday.
>
> I'll start working on this.
>
> --
> John Weldon
>
> On Fri, Oct 24, 2014 at 11:48 AM, Gustavo Niemeyer
> wrote:
>
>> For 2, it doesn't matter much if the timestamp is taken into account. The
>> server may simply enqueue the action a
3. Action IDs should not mislead users by implying sequence that does not
> exist.
> 4. ergo Action id's will probably be reflected back to the user in some
> sort of a manageable hash or hex format
>
>
>
> --
> John Weldon
>
> On Fri, Oct 24, 2014 at 11:38 AM, Gus
On Fri Oct 24 2014 at 4:30:38 PM John Weldon wrote:
> Ordered execution wasn't addressed in the spec, and we haven't had much
> discussion about it.
> I'm not even sure how to enforce ordered execution unless we rely on the
> creation timestamp.
>
Specifications are guidelines. If there are open
y the numbers.
On Fri Oct 24 2014 at 4:21:30 PM John Weldon wrote:
> Forgot to reply-all
>
> -- Forwarded message --
> From: John Weldon
> Date: Fri, Oct 24, 2014 at 11:19 AM
> Subject: Re: Actions :: UUID vs. Tag on command line
> To: Gustavo Niemeyer
>
>
gt; mapping with the relevant tags, that makes life easier in some
> respects, and I certainly won't complain about that.
>
> Cheers
> William
>
> >
> >
> > --
> > John Weldon
> >
> > On Fri, Oct 24, 2014 at 10:58 AM, Gustavo Niemeyer
> > w
gt;
> --
> John Weldon
>
> On Fri, Oct 24, 2014 at 11:07 AM, Gustavo Niemeyer <
> gustavo.nieme...@canonical.com> wrote:
>
>> That might be okay, but is the sequence really respected? In other
>> words, what happens if two independent clients attempt to submit a
how to generate and translate the hash are welcome too.
>
> Cheers,
>
>
> --
> John Weldon
>
> On Fri, Oct 24, 2014 at 10:41 AM, Gustavo Niemeyer <
> gustavo.nieme...@canonical.com> wrote:
>
>> The "tag" (which might be better named "inter
The "tag" (which might be better named "internal id") looks like an
implementation detail which doesn't seem right to expose. I'd suggest
either giving it a proper representation that the user can understand (a
sequential action number, for example), or use a hash. I'd also not use a
UUID, btw, but
On Fri, Sep 12, 2014 at 3:16 PM, Nate Finch wrote:
> In the thread Eric pointed to, Brad Fitzpatrick (one of the core Go
> developers) says they prefer to keep tests in the same package unless forced
> to have them in a different package to avoid circular dependencies. I like
> that.
Brad is a g
On Fri, Sep 12, 2014 at 12:00 PM, Mark Ramm-Christensen
(Canonical.com) wrote:
> I think the two issues ARE related because a bias against mocks, and a
> failure to separate out functional tests, in a large project leads to a test
> suite that has lots of large slow tests, and which developers can
On Fri, Sep 12, 2014 at 7:42 AM, Michael Foord
wrote:
> I agree. I tend to see the need for stubs (I dislike Martin Fowler's
> terminology and prefer the term mock - as it really is by common parlance
> just a mock object) as a failure of the code. Just sometimes a necessary
> failure.
I don't pa
On Thu, Sep 11, 2014 at 10:42 PM, Andrew Wilkins
wrote:
> I basically agree with everything below, but strongly disagree that mocking
> implies you know exactly what the code is doing internally. A good interface
I'm also in agreement about your points. But just so you understand
where Roger is c
On Thu, Sep 11, 2014 at 4:06 PM, Mark Ramm-Christensen (Canonical.com)
wrote:
> But they are not the ONLY reasons why they are valuable.
> There are plenty of others -- performance, test-code cleanliness/re-use,
> result granularity, etc.
Performance is the second reason Roger described, and I di
+1!
On Thu, Sep 11, 2014 at 12:59 PM, roger peppe wrote:
> On 11 September 2014 16:29, Matthew Williams
> wrote:
>> Hi Folks,
>>
>> There seems to be a general push in the direction of having more mocking in
>> unit tests. Obviously this is generally a good thing but there is still
>> value in h
Worth keeping in mind the usual gotcha: the API of syscall is
different for different OSes.
On Tue, Sep 9, 2014 at 5:45 PM, Nate Finch wrote:
> A user just complained that he can't bootstrap because Juju is parsing
> stderr text from flock, and his server isn't in English, so the error
> message
I suggest not updating it. Updates on the same line will conflict, and
cause completely unnecessary headaches. These files are under revision
control, so there are better proofs of when it was changed than just
that header. Then, in a decade or two, if somebody cares, update them
all at once.
On W
On Fri, Aug 29, 2014 at 4:28 PM, Katherine Cox-Buday
wrote:
> Hey all,
>
> I ran into some commented out tests while making a change:
> https://github.com/juju/juju/pull/630/files#r16874739
>
> I deleted them since keeping things around that we might need later is the
> job of source control, not
On Wed, Aug 20, 2014 at 5:05 PM, Nate Finch wrote:
> I think to answer most of these questions, we need more information about
> what the existing charms do, and input from the charmers themselves.
>
> Here's the info from Marco: http://pastebin.ubuntu.com/8100649/
Thanks. Looking at some entries
On Wed, Aug 20, 2014 at 3:45 PM, Nate Finch wrote:
> Here's a proposal that is much simpler: we add a flag to the charm metadata,
> called something like "single_hook". When single_hook is true, all hook
> events run a file called "default-hook" (or whatever we want to call it, I
> don't really c
On Wed, Aug 20, 2014 at 11:16 AM, Nate Finch wrote:
> Anyone who has ever written a switch statement should be used to putting in
> a default clause for "something I don't expect"... I don't think it should
> be a big deal.
Some charms mentioned in this thread miss the switch altogether. Given
th
On Wed, Aug 20, 2014 at 11:08 AM, William Reade
wrote:
> On Wed, Aug 20, 2014 at 10:46 AM, Matthew Williams
> wrote:
>> Gustavo's observation about hooks that the charm might no know about yet
>> means that the else clause is absolutely required, I wonder if that's
>> obvious to someone who's new
On Wed, Aug 20, 2014 at 5:46 AM, Matthew Williams
wrote:
> if JUJU_HOOK_NAME == "start"
> //run start
> else if JUJU_HOOK_NAME == "config-changed"
> //run config-changed
> else if JUJU_HOOK_NAME == "stop"
> //run stop
> else
> //unknown hook
> exit 1
> fi
I'd expect the else to be "exit 0"
On Tue, Aug 19, 2014 at 6:58 PM, Matthew Williams
wrote:
> Something to be mindful of is that we will shortly be implementing a new
> hook for metering (likely called collect-metrics). This hook differs
> slightly to the others in that it will be called periodically (e.g. once
> every hour) with t
On Tue, Aug 19, 2014 at 1:10 PM, Aaron Bentley
wrote:
> True. At that point, the pattern is not a win, but it's not much of a
> loss. Changing the web site relation is extremely uncommon, but
> operations which do require server restarts are quite common. So
> making an exception for the web si
On Tue, Aug 19, 2014 at 12:41 PM, William Reade
wrote:
> (out of interest, if started/stopped state were communicated to you any
> other way, would you still need these?)
If you communicate events in a different way, you obviously won't need
your previous way of communicating events.
gustavo @
On Tue, Aug 19, 2014 at 11:59 AM, Aaron Bentley
wrote:
>> This is actually your website-relation-changed hook:
>>
>> http://paste.ubuntu.com/8089398/
>
> No, it's not:
> http://manage.jujucharms.com/~juju-qa/precise/juju-reports/hooks/website-relation-changed
Sorry, I was looking at your own vers
On Tue, Aug 19, 2014 at 11:00 AM, Aaron Bentley
wrote:
> On 14-08-19 09:42 AM, Gustavo Niemeyer wrote:
>> I have never seen myself a single charm that completely ignores
>> all the action cues to simply re-read the whole state from the
>> ground up,
>
> The cs:~juju-qa
On Tue, Aug 19, 2014 at 9:07 AM, William Reade
wrote:
> On Mon, Aug 18, 2014 at 9:33 PM, Gustavo Niemeyer
> wrote:
>>
>> I don't think I fully understand the proposal there. To have such a
>> "something-changed" hook, we ought to have a better mechanism
I don't think I fully understand the proposal there. To have such a
"something-changed" hook, we ought to have a better mechanism to tell
*what* actually changed. In other words, we have a number of hooks
that imply a state transition or a specific notification ("install",
"start", "config-changed"
Rather than passing it as the first argument, I suggest introducing an
environment variable: $JUJU_HOOK_NAME. This would be set irrespective
of how the hook is being called, so that the same hook can be used
both as a symlink and as a default-hook, unchanged. It also means further
spawned processes
On Thu, Aug 14, 2014 at 3:14 PM, Nate Finch wrote:
> I didn't bring up 12 factor, it's irrelevant to my argument.
Is there someone else sending messages under your name?
On Thu, Aug 14, 2014 at 12:23 PM, Nate Finch wrote:
> The front page of 12factor.net says "offering maximum portability betwe
On Thu, Aug 14, 2014 at 1:35 PM, Nate Finch wrote:
> On Thu, Aug 14, 2014 at 12:24 PM, Gustavo Niemeyer
> wrote:
>>
>> > Why support two things when you can support just one?
>>
>> Just to be clear, you really mean "why support two existing and well
>&g
On Thu, Aug 14, 2014 at 12:23 PM, Nate Finch wrote:
> The front page of 12factor.net says "offering maximum portability between
> execution environments" ... that's exactly what I'm going for.
This can be taken as an excuse to do just about anything.
> We're going to support Windows. Windows doe
On Thu, Aug 14, 2014 at 3:42 AM, Stuart Bishop
wrote:
> Further to just injecting failures, I'm interested in controlling when
> and the order hooks can run. A sort of manual mode, which could be
> driven by a test harness such as Amulet.
This sounds quite heavyweight and intrusive. Introducing d
As a side note, MongoDB offers a "capped collection" mechanism with
the semantics that you can insert rows at will, and it rolls around
automatically by replacing oldest entries with the newest ones. This
tends to be a very convenient way to do structured logging, both on
the writing and on the rea
hard to tell whether the system would know how to retry properly.
Killing or slowing down just sometimes, or perhaps the first 2 times
out of every 3, for example, would enable the system to recover
itself, and an external agent to ensure it continues to work properly.
On Wed, Aug 13, 2014 at 11:25
That's a nice direction, Menno.
The main thing that comes to mind is that it sounds quite inconvenient
to turn the feature on. It may sound otherwise because it's so easy to
drop files at arbitrary places in our local machines, but when dealing
with a distributed system that knows how to spawn its
On 6 August 2014 14:13, Gustavo Niemeyer
> wrote:
> > gustavo @ http://niemeyer.net
> >
> >
> > On Aug 6, 2014 3:03 PM, "roger peppe" wrote:
> >>
> >> On 6 August 2014 13:57, Gustavo Niemeyer wrote:
> >> > Why would any application we
gustavo @ http://niemeyer.net
On Aug 6, 2014 3:03 PM, "roger peppe" wrote:
>
> On 6 August 2014 13:57, Gustavo Niemeyer wrote:
> > Why would any application well designed open thousands of ports
individually
> > rather than a range? Sounds like an unreasonable use cas
ay already presents undefined behavior.
gustavo @ http://niemeyer.net
On Aug 6, 2014 2:53 PM, "roger peppe" wrote:
> On 6 August 2014 10:32, Gustavo Niemeyer wrote:
> > How many port ranges are typically made available? One.. Two? Sounds
> like a
> > trivial pro
, 2014 9:41 AM, "roger peppe" wrote:
> On 5 August 2014 19:34, Gustavo Niemeyer wrote:
> > On Tue, Aug 5, 2014 at 4:18 PM, roger peppe wrote:
> >> close ports 80-110 -> error (mismatched port range?)
> >
> > I'd expect ports to be closed here, and al
wrote:
> agreed. to be clear .. imo, close-port shouldn't error unless there's a type
> mismatch on inputs. ie none of the posited scenarios in this thread should
> result in an error.
> -k
>
>
>
> On Tue, Aug 5, 2014 at 8:34 PM, Gustavo Niemeyer
> wrote:
>>
On Tue, Aug 5, 2014 at 4:18 PM, roger peppe wrote:
> close ports 80-110 -> error (mismatched port range?)
I'd expect ports to be closed here, and also on 0-65536.
gustavo @ http://niemeyer.net
--
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists
Hey all,
I could not find any documentation for that, so I'm sending it to the
list before the context gets lost and becomes unsearchable again.
We were talking today about health checks in the context of a unit,
and my proposal is to have three fundamental fields as part of the
unit state:
1.
xn-revno 2: DONE
Note the first one is "b)" while the second one is "d)", which means
there are two completely independent runners, in different goroutines
(might as well be different machines), collaborating towards the
completion of a single transaction.
So, I believe this i
hard either.
But it's quite late here and it'd be unwise to not get some sleep.
More on this tomorrow.
On Wed, Jul 30, 2014 at 3:21 AM, John Meinel wrote:
> Could this be something where we are getting transactions faster than we can
> finalize them?
>
> John
> =:->
>
We've got a database dump yesterday, which gives me something to
investigate. I'll spend some time on this tomorrow (today) and report back.
On Wed, Jul 30, 2014 at 1:34 AM, Menno Smits wrote:
> All,
>
> Various people have been seeing the machine agents panic with the following
> message:
>
>
On Fri, Jul 25, 2014 at 5:29 AM, Stuart Bishop
wrote:
> On 25 July 2014 12:05, Gustavo Niemeyer
> wrote:
> The bug Ian cites and is trying to work around has sessions failing
> with an i/o error after some time (I'm guessing resource starvation in
> MongoDB or T
On Fri, Jul 25, 2014 at 10:01 AM, Richard Harding
wrote:
(...)
> Give this, the vast majority of bundles are fully qualified. In the JAAS
> scenaraio, where users are building bundles through the webui and they're
> stored directly, we can encourage/enforce qualified names by controlling
> the UI
On Fri, Jul 25, 2014 at 2:37 AM, Ian Booth wrote:
> The tests passed for me every time also, with and without independent
> sessions.
> If I loaded my machine to max out CPU usage to 100%, then the tests (different
> ones each run) would fail intermittently but reproducibly every time with
> sess
On Fri, Jul 25, 2014 at 1:02 AM, Ian Booth wrote:
> We've transitioned to using Session.Copy() to address the situation whereby
> Juju
> would create a mongo collection instance and then continue to make db calls
> against that collection without realising the underlying socket may have
> become
Hey Ian,
On Thu, Jul 24, 2014 at 4:03 AM, Ian Booth wrote:
> However, doing a session.Copy() each time the transaction log collection is
> queried (every 5 seconds) causes a number of test failures when the host
> machine
> is heavily loaded. Either extra events are received or events are missed
Great timing, Kate.
I was recently asked to take care of mup's deployment again, and I'm
about to put live its third incarnation, reviving a hack I started
back in 2011 to port the ancient Erlang bot I wrote too many years ago
into a Go version. My goal, among other things, is to make plugin
writi
On Wed, Jul 23, 2014 at 9:59 AM, roger peppe wrote:
> The charm URL in a bundle means exactly what it would mean if
> you typed it in a juju deploy command. That is, it is dependent
> on the charms available at bundle deploy time.
I would fix that instead.
> I do believe having just URL would be
On Wed, Jul 23, 2014 at 9:13 AM, Richard Harding
wrote:
> This is driven by requirements from ecosystem and users where bundles
> define a 'solution'. A mongodb-cluster bundle doesn't need to be updated
> every time a new revision comes out, or even if a new series comes out. It
> is a usable solu
On Wed, Jul 23, 2014 at 7:35 AM, roger peppe wrote:
> We want to store charm URLs in mongo-db that are agnostic whether
> the series is specified or not. For example, in a bundle, a service
> is free to specify a series in the charm name or not.
That sounds slightly surprising. How do we plan to
On Tue, Jul 15, 2014 at 7:05 PM, Richard Harding
wrote:
> It is listed under known clients in the spec, and we mentioned your request
> down below. What we lack is your specific use cases as no one working on
> the spec is knowledgeable about how you're using the api.
Besides what others have sa
On Wed, Jul 9, 2014 at 12:52 PM, roger peppe wrote:
> On 9 July 2014 16:24, Aaron Bentley wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> On 14-07-09 11:16 AM, roger peppe wrote:
>>> If we need to provide backward compatibility, we could do that in a
>>> separate name space witho
On Wed, Jul 9, 2014 at 12:16 PM, roger peppe wrote:
> On 9 July 2014 15:20, Gustavo Niemeyer wrote:
>> Is there a reason to reinvent the API from the ground up, instead of
>> extending what exists today?
>
> We actually started out by thinking that we'd make somethi
Is there a reason to reinvent the API from the ground up, instead of
extending what exists today?
On Mon, Jul 7, 2014 at 6:14 AM, roger peppe wrote:
> Francesco Banconi and I have produced a possible specification for the
> new charm store API, combining features from the existing charm store
> A
On Mon, Jul 7, 2014 at 10:49 PM, Gustavo Niemeyer wrote:
> On Mon, Jul 7, 2014 at 8:49 PM, David Cheney
> wrote:
>> I don't want to introduce another thing to break CI, we already pull
>> from github which is bad enough, but going via gopkg.in introduces an
>> addi
On Mon, Jul 7, 2014 at 8:49 PM, David Cheney wrote:
> I don't want to introduce another thing to break CI, we already pull
> from github which is bad enough, but going via gopkg.in introduces an
> additional point of failure which can further reduce the already
> bullet ridden credibility of our C
On Mon, Jul 7, 2014 at 7:18 PM, Ian Booth wrote:
> It wasn't mean to be funny. I'm unsure why it's a bad argument. It's quite
> prudent to ensure that critical infrastructure on which our development
> depends
> meets expectations with regard to uptime, reliability etc (a case in point
> being
>
On Mon, Jul 7, 2014 at 6:00 PM, Ian Booth wrote:
> I'm somewhat wary of depending on an another "unknown" third party website
> being
That's hilarious. I haven't been pushing for its usage on juju, and
I'm still not the one actively pushing it, but that's a pretty bad
argument to raise here.
g
On Mon, Jul 7, 2014 at 2:03 PM, roger peppe wrote:
> The latter might turn out to be quite awkward, though there's
> probably a nice solution I don't see.
>
> Suppose we've got three environments, A, B and C.
>
> We have transactions that span {A, B}, {B, C} and {C, A}.
>
> How can we choose a con
On Mon, Jul 7, 2014 at 12:26 PM, roger peppe wrote:
> On 7 July 2014 14:27, Gustavo Niemeyer wrote:
>> On Mon, Jul 7, 2014 at 10:09 AM, roger peppe
>> wrote:
>>> I had assumed that because every client needs to see every transaction
>>> there would likely
On Mon, Jul 7, 2014 at 10:09 AM, roger peppe wrote:
> I had assumed that because every client needs to see every transaction
> there would likely be no benefit to sharding the log, although
> technically you could shard on transaction id. I'd be
Clients don't need to see every transaction. Only t
On Fri, Jul 4, 2014 at 10:32 AM, roger peppe wrote:
> It won't be possible to shard the transaction log.
Why not?
> The thing I'm trying to get across is: until we know one way or
> another, I believe it would be better to choose the (much) simpler
> option and use the (potential weeks of) dev t
On Fri, Jul 4, 2014 at 6:01 AM, roger peppe wrote:
> There is another possiblity: we could just use a different collection
> name prefix for each environment. There is no hard limit on the number
> of collections in mongo (see
> http://docs.mongodb.org/manual/reference/limits/).
For sharding and
On Thu, Jul 3, 2014 at 10:01 PM, Tim Penhey wrote:
> As far as I know (and I may be wrong), if you are adding a document to
> the mongo collection, and you do not specify an _id field, mongo will
> create a unique value for you.
That's right in most cases, and a requirement for replication.
> 1.
+1 to Mark's point. Handling exact matches is much easier, and does
not prevent a fancier feature later, if there's ever the need.
On Thu, Jun 26, 2014 at 3:38 PM, Mark Ramm-Christensen (Canonical.com)
wrote:
> My belief is that as long as the error messages are clear, and it is easy to
> close 8
Hey Eric,
Some comments below, offering a slightly different perspective to be
used as a data point in your quest.
On Thu, Jun 26, 2014 at 1:41 PM, Eric Snow wrote:
> In the interest of understanding juju better and of making the API
> more accessible, I took a little time to investigate possibl
Thanks, John. Several nice ideas there. I especially like the data
backing the first few points.. it provides evidence to something we
intuitively understand.
I also wrote some points about this same topic, but from a slightly
different perspective, last year:
http://blog.labix.org/2013/02/06
Agreed, but for a slightly different reason. The suggestion is to
annotate the patch with the reason for the change, rather than the
code itself, which might indeed lead to a different kind of comment.
While this might be useful, one of the interesting outcomes of code
reviewing is that it forces t
1 - 100 of 148 matches
Mail list logo
