State should not depend on the API server

[roger peppe]

On 1 September 2014 06:40, David Cheney <david.cheney at canonical.com> wrote:
> Hello,
>
> This is an introductory email to explain my upcoming series of pull requests.
>
> The theme is simple: state must not depend on the api server.
>
> This is currently not true, state depends on api/params because some
> of the api types have leaked into the state package and are being
> directly stored in mongo.
>
> Please speak up if you disagree with this proposal.

Sorry for not replying earlier. I'm just back from a week's holiday.

I'm not sure I agree with the thrust of this proposal.

The api/params package is not the API server - it's a leaf package
defining types that may be used by the API server.  Thus state does not
in fact depend on the api server.

Furthermore, I am not convinced that redefining the same types in
different places is a great help. It means there's more maintenance,
and more chance of getting things wrong when writing the code to convert
between them.

Go makes it easy to define a single type that defines the marshaling
format for both client and server sides. This seems to me to be a Good
Thing. Within a single code base, surely a given version of the API can
define the parameters for the client and server side in the same way,
for example?

What we really want to do here, IMHO, is guard against incompatible
changes made to types that are persistently used, whether that's because
they're stored in mongo or used to communicate with other versions of
the API server.

I have thought for a while that, rather than writing more error-prone code
(at > 17k LOC, surely the API code is big enough as it is?), it would
be good to create a tool that helps us with the underlying problem -
incompatible changes made to marshaled types.

This would not be too hard - the Go language already has such a tool
(see http://golang.org/cmd/api/ ), although it is not currently generally
applicable.

This could make it possible to provide a much stronger assurance about
compatibility, including compatibility between types not defined inside
juju-core itself, while keeping the code natural and simple.

  cheers,
    rog.