lp:~rogpeppe/juju-core/559-fix-err-deepequals

Created by Roger Peppe on 2014-04-20 and last modified on 2014-04-20
Get this branch:
bzr branch lp:~rogpeppe/juju-core/559-fix-err-deepequals
Only Roger Peppe can upload to this branch. If you are Roger Peppe please log in for upload directions.

Branch merges

Related bugs

Related blueprints

Branch information

Owner:
Roger Peppe
Project:
juju-core
Status:
Development

Recent revisions

2654. By Roger Peppe on 2014-04-20

merge trunk

2653. By Roger Peppe on 2014-04-20

various: fix error deepequal comparisons in tests

2652. By Roger Peppe on 2014-04-17

[r=rogpeppe] cmd/jujud: enable HA

Let's see what happens...

https://codereview.appspot.com/87860047/

2651. By Roger Peppe on 2014-04-17

[r=rogpeppe] worker/peergrouper: maintain HasVote better

We observed that HasVote was not being properly
maintained when SetHasVote failed on a previous
iteration.

https://codereview.appspot.com/88000050/

2650. By John A Meinel on 2014-04-17

[r=jameinel],[bug=1308487] state/api: save the connection as the first addr

When we connect to the API, we eventually will try all addresses listed.
We also will always save the value that we managed to connect with. This
change addresses bug #1308487, which has us move the address we
successfully connected to as the first server and address we should try
next time.

This doesn't quite give us a priority, because if we ever fail this one,
we'll go back to the default sort order except for one entry. However, I
think it still helps.

In my testing, I had to bump up the DialAddressInterval all the way up
to 500ms before we really wouldn't try most of the addresses. This is
because the time here *includes* the TLS handshake (though not the Login
round trip).

I would be happy to see the value bumped up a bit, but I don't have a
solid feeling for what is a great value there.
But since we always move the successful connection to the front, we
can expect that even if we wait a while to fall back, that will be the
uncommon case, as whatever address succeeded in the past is the most
likely to succeed the next time.

https://codereview.appspot.com/88470043/

2649. By Dimiter Naydenov on 2014-04-17

[r=dimitern] state: Networking improvements, missed before

In this CL https://codereview.appspot.com/86010044/,
some of the suggestions regarding implementation
details of AddNetwork and AddNetworkInterface were
not included in time. This adds these suggestions.

https://codereview.appspot.com/87470044/
R=rogpeppe

2648. By Dimiter Naydenov on 2014-04-17

[r=dimitern] errors: Improve tests, unify interfaces, wrapping

The errors package is refactored so that for all
errors defined there are 3 functions with consistent
names:
 * Is<type>(error) bool
 Returns true if the error satifies <type> (i.e.
 it was created with one of the two constructors
 below for <type>.
 * New<type>(error, string) error
 Creates an error of <type> wrapping the given error
 and adding the prefix to the message.
 * <type>f(string, ...interface{}) error
 Creates an error of <type> with a message, formatted
 like fmt.Sprintf.

Dropped "Error" from type and function names (as they
already are in the "errors" package).
Moved utils.ErrorContextf in here, renaming it to
Maskf. A new helper called Contextf is added, which works
similarly to Maskf, but preserves the original error when
wrapping (if it's one of the known types), so that the
Is<type>() satifiers will work on the wrapped error as
well.

Added automatic exhaustive testing for each error
type in a way that makes it easier to add new types.

Few drive-by fixes made while fixing the rest of the
code base to use the new function names.

I realize we should use errgo for such things, but
we can easily change the errors package to use errgo
internally later.

https://codereview.appspot.com/87560043/

R=rogpeppe

2647. By John A Meinel on 2014-04-17

[r=jameinel],[bug=1268470] cmd/juju/endpoint: return cached api-endpoints

We already do all the work of caching the information, just return it
rather than looking things up in the provider again. The main win here
is that "juju api-endpoints" no longer needs provider credentials.

There are 2 other bits changing which I'm happy to revert if we feel we
don't want to change it at this time.

 1. Our code for caching the first time *only* caches the value that we
 found by looking up the APIInfo in the provider. However, since we just
 connected to the API we can just use that information. I kept the old
 code for backwards compatibility with servers that didn't return
 HostPorts. Though that might not be 1.18, in which case we *could* rip
 out all that logic.

 2. 'juju api-endpoints' used to always lookup the information from the
 provider. Now it defaults to just spitting out what was cached, though
 you can supply --refresh to make it connect first.

 Time wise:
 3.396s juju-1.18.1 api-endpoints
 1.363s juju-proposed api-endpoints --refresh
 0.140s juju-proposed api-endpoints

I went ahead and left it with no refresh by default, because we honestly
don't think these things are going to be changing much. But I could live
with always connecting, and it would simplify the code slightly. (Takes
out approximately 1 if() clause and the commandline parameter.)

https://codereview.appspot.com/88410043/

2646. By John A Meinel on 2014-04-17

[r=jameinel] agent/mongo: log version of mongo

Just before we start mongo, log the version so we know what we're
running. This is mostly just to aid us in debugging log files from
other people.

https://codereview.appspot.com/87570043/

2645. By John A Meinel on 2014-04-17

[r=jameinel] agent/mongo: log version of mongo

Just before we start mongo, log the version so we know what we're
running. This is mostly just to aid us in debugging log files from
other people.

https://codereview.appspot.com/87570043/

Branch metadata

Branch format:
Branch format 7
Repository format:
Bazaar repository format 2a (needs bzr 1.16 or later)
Stacked on:
lp:~go-bot/juju-core/trunk
This branch contains Public information 
Everyone can see this information.

Subscribers