lp:~frankban/juju-core/trial

Created by Francesco Banconi and last modified
Get this branch:
bzr branch lp:~frankban/juju-core/trial
Only Francesco Banconi can upload to this branch. If you are Francesco Banconi please log in for upload directions.

Branch merges

Related bugs

Related blueprints

Branch information

Owner:
Francesco Banconi
Project:
juju-core
Status:
Development

Recent revisions

1730. By Gavin Panella

[r=jameinel] Improve build tooling.

Some build targets - build, check, install and clean - can only run
when the tree is in the right place on GOPATH. The Makefile now guards
this and provides useful errors.

The system package dependencies are now more readably listed.

The ~juju PPAs are not added on Saucy; they do not work there.

A new clean target removes test executables and other detritus. *.test
files are also now ignored.

1729. By Roger Peppe

[r=rogpeppe] environs: move stuff to provider

The environs package currently serves two very
different purposes - it is designed to be called into
by external packages (and then it calls into the
registered providers), but it is also used
as a repository for common code shared between
provider implementations.

This dual purpose makes it confusing to see
what's what in the documentation, and also
makes it easy to get the layering abstractions wrong.

This change moves some (probably not all yet)
of the latter code into the provider package,
to make the boundaries more clear.
There was some similar code in the
provider package already.

https://codereview.appspot.com/13269045/

1728. By Dave Cheney

[r=dave-cheney] doc: update release procedure

1727. By Roger Peppe

[r=rogpeppe],[bug=1217760] state/apiserver: make ServerError work properly

It didn't work if the error type was non-comparable.

https://codereview.appspot.com/13336043/

1726. By Roger Peppe

[r=rogpeppe] testing: make LoggingSuite work during SetUpSuite

When trying to debug some code, I found that
log messages were not being printed
during SetUpSuite or TearDownSuite.

This patch fixes LoggingSuite in that respect.

https://codereview.appspot.com/13351043/

1725. By Frank Mueller

[r=themue] charm: reverted empty string branch

Reverted the branch allowing empty string values
in charm configurations due incompatability with
the API.

https://codereview.appspot.com/13349043/

1724. By Roger Peppe

[r=rogpeppe] api/watcher: return interface

This means that worker implementations cannot
return a nil value masquerading as a non-nil
interface. It's difficult to know how to test
this properly without mocking the API.

Also couldn't resist a drive-by simplification of the
worker MustErr test logic.

https://codereview.appspot.com/13326044/

1723. By John A Meinel

[r=jameinel],[bug=1216285] environs/tools: print out the correct version

Bug #1216285 is because we were miss-formatting a line about what
version we were filtering. It turns out that while we were printing out
an int as "%s" we were also not priting out what the filter would
actually match. (If you pass a version in that field, we match the exact
version, not just the major version.)

In the process, I realized we don't have much infrastructure for testing
what log messages we are writing, so I added a LogMatches checker. I
think it is something that actually fits better inside the loggo
package, but I wanted to give it some real experience before I tried to
get it into upstream.

https://codereview.appspot.com/12744051/

1722. By John A Meinel

[r=jameinel] cmd/juju/get: Use the API

Change "juju get" to call api.Client().ServiceGet() instead of
statecmd.ServiceGet(). Then I moved all the tests and implementation
over to state/apiserver/client/get*

I actually kept the code out of client.go because as we move things,
that file will get *huge* if all API calls end up in one file. It also
meant that the test for get.go end up in get_test.go which is nice and
straightforward.

The tests are just moving the existing tests (and changing the suite)
except for one change which I want to highlight. ServiceGet over the API
is returning float64(0) for skill-level, when the direct state call was
returning int64(0). I'm guessing that YAML and BSON are preserving the
int64 type, while JSON is not. (It is also possible that it was just
preserving the content in memory and returning it again, and if it
actually did a full DB round trip it would have lost the type.) Anyway,
I'm guessing we aren't strict with types, otherwise we'd have to change
our JSON api to send type information for all entries in a
map[]interface{}. But I did want us to be clear that type changing was
happening.

https://codereview.appspot.com/12744053/

1721. By John A Meinel

[r=jameinel] juju: juju.NewAPIClientFromName

Rather than exposing APIConn and its associated Environ object, William asked
if we could expose something smaller. We really don't want CLI code to be
directly needing provider credentials, etc. The only thing the current caller
did with APIConn was ask for the conn.State.Client() anyway.

This should give us more focused thoughts that the CLI only thinks about
stuff via the API calls it makes, as the only thing it *has* is a thing to
make API calls.

https://codereview.appspot.com/12943045/

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.