First components of in-memory juju environment

First components of in-memory juju environment

This branch adds the first part of an in-memory juju environment.  Next steps include machine generation to addUnit, adding configFile support to deploy (js-yaml has made some big strides), adding code that can report changes (for the delta stream/watcher protocols), writing a first cut of the Python wire protocol, and writing a first cut of the Go protocol.  After that we should be able to just add in remaining commands.

This was driven by a prototype by Kapil, and with Benji's help.

https://code.launchpad.net/~gary/juju-gui/fakebackend-1/+merge/152696

(do not edit description out of merge proposal)

[gary.poster, 2013-03-11 15:03:21]

Please take a look.

[bcsaller, 2013-03-11 16:05:18]

LGTM

I don't love the name 'fakebackend', juju-improv or juju-memory-env or something
make read better, but its really up to you. 

The env is simple to follow and a nicely captures the rules around these first
juju interactions. Given that you started with the most involved call (I think)
it should be easy to get the rest working.

Thanks

https://codereview.appspot.com/7641051/diff/1/app/models/charm.js
File app/models/charm.js (right):

https://codereview.appspot.com/7641051/diff/1/app/models/charm.js#newcode45
app/models/charm.js:45: };
Nice cleanup

https://codereview.appspot.com/7641051/diff/1/app/store/env/fakebackend.js
File app/store/env/fakebackend.js (right):

https://codereview.appspot.com/7641051/diff/1/app/store/env/fakebackend.js#ne...
app/store/env/fakebackend.js:42: this.db = new models.Database();
It took some thinking to convince me that we don't want to be able to inject the
database from outside, but I think I've come around now.

https://codereview.appspot.com/7641051/diff/1/test/test_fakebackend.js
File test/test_fakebackend.js (right):

https://codereview.appspot.com/7641051/diff/1/test/test_fakebackend.js#newcode42
test/test_fakebackend.js:42: 'data/' + name + '-charmdata.json', {sync:
true}).responseText });
There is a method for this in test endpoints that should most likely be migrated
to test/utils. loadFixture.

  function loadFixture(url) {
        return Y.JSON.parse(Y.io(url, {sync: true}).responseText);
      }
      sample_env = loadFixture('data/large_stream.json');
      sample_endpoints = loadFixture('data/large_endpoints.json');

I think its better to reuse this even if its a line or two.

[matthew.scott, 2013-03-11 16:38:51]

LGTM

Thanks for this, really good addition.

[gary.poster, 2013-03-11 18:25:25]

On 2013/03/11 16:05:18, bcsaller wrote:
> LGTM
> 
> I don't love the name 'fakebackend', juju-improv or juju-memory-env or
something
> make read better, but its really up to you. 

I agree that it is not fantastic, but I felt "fakebackend" conveyed the intent
better than these or other options I came up with.

My thought is that we can go back and revise this later if desired.  If you made
the argument that "memory-env" or similar gave people a better idea of intended
usage then I'd be happy to come around behind and change it.  ("improv" has
never conveyed the right meaning to me, tbh.  PlaygroundEnv?  SandboxEnv?)

Argue passionately for a name and I'll make a separate branch with the change.
:-)

> The env is simple to follow and a nicely captures the rules around these first
> juju interactions. Given that you started with the most involved call (I
think)
> it should be easy to get the rest working.
> 
> Thanks
> 
> https://codereview.appspot.com/7641051/diff/1/app/models/charm.js
> File app/models/charm.js (right):
> 
> https://codereview.appspot.com/7641051/diff/1/app/models/charm.js#newcode45
> app/models/charm.js:45: };
> Nice cleanup

Thanks.

https://codereview.appspot.com/7641051/diff/1/app/store/env/fakebackend.js
> File app/store/env/fakebackend.js (right):
> 
>
https://codereview.appspot.com/7641051/diff/1/app/store/env/fakebackend.js#ne...
> app/store/env/fakebackend.js:42: this.db = new models.Database();
> It took some thinking to convince me that we don't want to be able to inject
the
> database from outside, but I think I've come around now.

Cool.

https://codereview.appspot.com/7641051/diff/1/test/test_fakebackend.js
> File test/test_fakebackend.js (right):
> 
>
https://codereview.appspot.com/7641051/diff/1/test/test_fakebackend.js#newcode42
> test/test_fakebackend.js:42: 'data/' + name + '-charmdata.json', {sync:
> true}).responseText });
> There is a method for this in test endpoints that should most likely be
migrated
> to test/utils. loadFixture.
> 
>   function loadFixture(url) {
>         return Y.JSON.parse(Y.io(url, {sync: true}).responseText);
>       }
>       sample_env = loadFixture('data/large_stream.json');
>       sample_endpoints = loadFixture('data/large_endpoints.json');
> 
> I think its better to reuse this even if its a line or two.

Yes, I looked at that.  The reason why I didn't reuse it was that I was really
only reusing the Y.io sync call: you parse JSON and pull the responseText out,
and I actually need the full responseText string, because that's what the charm
store expects.  That said, as I was considering your suggestion, I realized that
I could simplify.  If you look at my new branch, you should see a smaller
function that more clearly shows the differences.

Thank you, to both you and Matt!

Gary

[gary.poster, 2013-03-11 18:29:43]

*** Submitted:

First components of in-memory juju environment

This branch adds the first part of an in-memory juju environment.  Next steps
include machine generation to addUnit, adding configFile support to deploy
(js-yaml has made some big strides), adding code that can report changes (for
the delta stream/watcher protocols), writing a first cut of the Python wire
protocol, and writing a first cut of the Go protocol.  After that we should be
able to just add in remaining commands.

This was driven by a prototype by Kapil, and with Benji's help.

R=bcsaller, matthew.scott
CC=
https://codereview.appspot.com/7641051