On not copy-pasting state and params struct conversions

[Andrew Wilkins]

On Wed, Feb 11, 2015 at 7:51 PM, William Reade <william.reade at canonical.com>
wrote:

> On Tue, Feb 10, 2015 at 11:35 AM, Andrew Wilkins <
> andrew.wilkins at canonical.com> wrote:
> > Not sure I follow what you're saying about "in terms of the storage
> types",
> > so
> > I'll describe how it is at the moment.
> >
> > The types are in three places:
> >   - juju/juju/storage
>
> ...which contains the types that represent "how juju thinks about storage"
> -- they're the actual model types.
>
> >   - juju/juju/apiserver/params
> >   - juju/juju/state
>
> ...which contain wire/db representations of the juju/juju/storage types to
> insulate the wire/db formats from changes to the above.
>
> > There's a storage.Volume, a params.Volume, and a state.Volume.
> state.Volume
> > is actually an interface, but there's a VolumeInfo which ~correlates to
> the
> > other
> > struct types.
> >
> > I think the conversion from params<->state all needs to be in
> > apiserver/<something>.
>
> I don't think that's right -- surely a state.Volume's VolumeInfo should
> actually be a storage.Volume? i.e. when the apiserver gets volume info over
> the wire it converts it to a storage.Volume at the earliest opportunity,
> and passes that into state where necessary, which only converts again when
> it needs to serialise; and similarly, in the other direction, the apiserver
> gets a storage.Volume directly out of state, and converts that to a
> params.Volume on the way out. Considering that our business logic is
> essentially smeared through state and apiserver, volume manipulation could
> happen in either layer; and we want that behaviour associated with the
> storage.Volume type, so we can move it between layers sanely; so we should
> have something like:
>
>            where               what
>     ============================================
>           <wire>            params.Volume
>     -------------<convert here>-----------------
>          apiserver          storage.Volume
>     --------------------------------------------
>           state             storage.Volume
>     -------------<convert here>-----------------
>            <db>             state.volumeDoc
>

As discussed live, that sounds fine. We'll need a new storage.VolumeInfo
type, which will contain information about a volume excluding its identity.
A Volume is its identity (tag) and VolumeInfo.
In state we have a Volume entity interface which will return
storage.Volume* type values. In general I'm trying to keep the operations
on state.State, to make it all more easily testable. When it comes to Life,
Remove, EnsureDead, etc., I'm not sure there's much choice without
rewriting everything in state.


> > I could live with it, but I don't like the idea of adding dependencies to
> > every domain
> > for every facade that uses it.
>
> I think we really do want domain dependencies in any part of the apiserver
> that contains logic pertaining to that domain, even if the logic is simple
> conversion [0]. Without that, domain logic just gets attached to whatever
> type lies closest to hand and makes it harder to move it to the right place
> as the code evolves.
>
> Cheers
> William
>
> [0] obligatory: http://thecodelesscode.com/case/97
>

:)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20150211/5ab7b765/attachment.html>