State should not depend on the API server

[John Meinel]

>
> ...
> 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.
>
>
So that is interesting, and it might be fruitful to explore. I'll just note
that it is actually a pretty small (and reasonably obvious) part of API
compatibility. It *doesn't* tell you

1) If passing an empty string suddenly has a different meaning (see
Client.ServiceSet where we used to treat "" as meaning reset-to-default vs
 Client.NewServiceSetForAPI where we wanted to actually treat "" as meaning
set this value to the empty string.)

2) Returning a new value (Machine.Jobs(), we want to add new Jobs for new
behaviors and don't want to confuse old agents until they have finished
upgrading).

So while something like the above could tell you "has the shape of the API
changed", and what I really like about it is that if it had a collapsed
view (like a simple text representation), it is easy to keep that around in
the source tree and use it for reference.

However, you really do need tests for (1) and (2). (1) we actually broke
accidentally because we changed the code inside of state/*, and then had to
go back and retrofit the API to use a new code path to preserve
compatibility.

And if you need tests, you really still need 2 types to represent the
different versions, and if you already need those types, then I would
recommend having a regular structure for them.

John
=:->
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20140911/23347d94/attachment.html>