https://codereview.appspot.com/80280043/diff/20001/environs/config/config.go#oldcode411
environs/config/config.go:411: func (c *Config) DefaultSeries() string {
On 2014/03/28 10:43:11, fwereade wrote:
> In-band errors squick me out... now that it's possible to have no
> default-series, please add a ,ok return value. And I guess return
false if it
> *is* set, but is set to "".
https://codereview.appspot.com/80280043/diff/20001/state/api/client.go#newcode614
state/api/client.go:614: args := params.CharmURL{URL: ref.String()}
On 2014/03/28 10:43:11, fwereade wrote:
> mmmmm I don't quite like that... can we make this a separate type?
> params.CharmURL now means something different (although I'm surprised,
a
> little... I could have sworn that charm url fields marshalled to
strings without
> any hassle at all [0], and so I'd expect us to be using actual
*charm.URLs, and
> to have to add a new type for a reference anyway.)
> [0] yeah, they should do, they have MarshalJSON and UnmarshalJSON.
Wonder why
> wedon't make use of it...
Done.
https://codereview.appspot.com/80280043/diff/20001/state/api/client.go#newcode616
state/api/client.go:616: if err := c.st.Call("Client", "",
"ResolveCharm", args, result); err != nil {
On 2014/03/28 10:43:11, fwereade wrote:
> Bulk calls please, they don't have to be exposed in api.Client but
it's
> reasonable to expect to be able to resolve a few urls in one go, and
we should
> accommodate that in the interface.
Varying the default series in the mock charm store among the test
conditions helps ensure the value isn't being hard-coded anywhere in the
apiserver, and it's useful for simulating a failure to resolve.
> ...is a reasonably compact way to make the test logs somewhat useful.
> I do really like calling it "test", not "t", though :).
Done.
https://codereview.appspot.com/80280043/diff/20001/state/apiserver/client/client_test.go#newcode1984
state/apiserver/client/client_test.go:1984: c.Assert(err, gc.IsNil,
comment) // All of these should parse
On 2014/03/28 10:43:11, fwereade wrote:
> can we Check and continue, here and below? check returns a bool (false
on
> failure iirc?), and while one piece of test data may have a problem I
think it's
> good to carry on and run the others.
https:/ /codereview. appspot. com/80280043/ diff/20001/ environs/ config/ config. go config/ config. go (left):
File environs/
https:/ /codereview. appspot. com/80280043/ diff/20001/ environs/ config/ config. go#oldcode411 config/ config. go:411: func (c *Config) DefaultSeries() string {
environs/
On 2014/03/28 10:43:11, fwereade wrote:
> In-band errors squick me out... now that it's possible to have no
> default-series, please add a ,ok return value. And I guess return
false if it
> *is* set, but is set to "".
Done.
https:/ /codereview. appspot. com/80280043/ diff/20001/ state/api/ client. go
File state/api/client.go (right):
https:/ /codereview. appspot. com/80280043/ diff/20001/ state/api/ client. go#newcode614 client. go:614: args := params. CharmURL{ URL: ref.String()}
state/api/
On 2014/03/28 10:43:11, fwereade wrote:
> mmmmm I don't quite like that... can we make this a separate type?
> params.CharmURL now means something different (although I'm surprised,
a
> little... I could have sworn that charm url fields marshalled to
strings without
> any hassle at all [0], and so I'd expect us to be using actual
*charm.URLs, and
> to have to add a new type for a reference anyway.)
> [0] yeah, they should do, they have MarshalJSON and UnmarshalJSON.
Wonder why
> wedon't make use of it...
Done.
https:/ /codereview. appspot. com/80280043/ diff/20001/ state/api/ client. go#newcode616 client. go:616: if err := c.st.Call("Client", "",
state/api/
"ResolveCharm", args, result); err != nil {
On 2014/03/28 10:43:11, fwereade wrote:
> Bulk calls please, they don't have to be exposed in api.Client but
it's
> reasonable to expect to be able to resolve a few urls in one go, and
we should
> accommodate that in the interface.
Done.
https:/ /codereview. appspot. com/80280043/ diff/20001/ state/apiserver /client/ client. go /client/ client. go (right):
File state/apiserver
https:/ /codereview. appspot. com/80280043/ diff/20001/ state/apiserver /client/ client. go#newcode959 /client/ client. go:959: ref, series, err := rence(args. URL)
state/apiserver
charm.ParseRefe
On 2014/03/28 10:43:11, fwereade wrote:
> yeah, calling it URL is jarring -- new type OK?
Done.
https:/ /codereview. appspot. com/80280043/ diff/20001/ state/apiserver /client/ client_ test.go /client/ client_ test.go (right):
File state/apiserver
https:/ /codereview. appspot. com/80280043/ diff/20001/ state/apiserver /client/ client_ test.go# newcode1977 /client/ client_ test.go: 1977: store.DefaultSeries =
state/apiserver
t.defaultSeries
On 2014/03/28 10:43:11, fwereade wrote:
> set this outside loop?
Varying the default series in the mock charm store among the test
conditions helps ensure the value isn't being hard-coded anywhere in the
apiserver, and it's useful for simulating a failure to resolve.
https:/ /codereview. appspot. com/80280043/ diff/20001/ state/apiserver /client/ client_ test.go# newcode1979 /client/ client_ test.go: 1979: comment := "defaultSeries: %s charmName:%s", t.defaultSeries,
state/apiserver
gc.Commentf(
t.charmName)
On 2014/03/28 10:43:11, fwereade wrote:
> for i, test := range tests {
> c.Logf("test %d: %#v", i, test)
> ...is a reasonably compact way to make the test logs somewhat useful.
> I do really like calling it "test", not "t", though :).
Done.
https:/ /codereview. appspot. com/80280043/ diff/20001/ state/apiserver /client/ client_ test.go# newcode1984 /client/ client_ test.go: 1984: c.Assert(err, gc.IsNil,
state/apiserver
comment) // All of these should parse
On 2014/03/28 10:43:11, fwereade wrote:
> can we Check and continue, here and below? check returns a bool (false
on
> failure iirc?), and while one piece of test data may have a problem I
think it's
> good to carry on and run the others.
Done.
https:/ /codereview. appspot. com/80280043/