store migration

[Richard Harding]

On Tue, 20 May 2014, David Cheney wrote:

> > A possible plan is as follow:
> >
> > 1) Migrate juju-core/thirdparty to juju/thirdparty (Github).
> > Since there are no dependencies here, this seems to be a good first candidate.
>
> nac, these are out horrors. The code we forked should either be pushed
> back upstream, and/or captured by godeps. I think the whole thirdparty
> thing happened before we had godeps.

Good to know, we can investigate.


> > 4) Migrate juju-core/charm. This has some pre-requisites. Basically IIUC charm defines config and meta and those definitions are tangled with the underlaying Mongo documents. William suggested to decouple that, implementing separate data structures to be used to (de)serialize data. This way, changes to charm database structure can be detected earlier and core developers are able to react accordingly. Soon this could also involve actions data.
>
> I don't see the value in splitting off this repo unless you need it
> for the store.

I think we'll want it as we'll be doing validation and such. This one will
take the most care and investigation as what a charm is to the store should
match what core expects from the charm.

Thanks for the feedback.

--

Rick Harding