I've addressed most of the feedback, but there is a problem lurking.
When config.LatestLtsSeries() == "trusty", some of the tests are failing
due to tools availability. I was able to resolve some of them, but not
all. Could really use some advice.
To reproduce the failures, this will simulate a post-trusty release
scenario in the proposed branch:
go test -ldflags "-X
launchpad.net/juju-core/environs/config.latestLtsSeries trusty" ./...
https://codereview.appspot.com/80280043/diff/60001/cmd/juju/addmachine.go#newcode129
cmd/juju/addmachine.go:129: series = conf.PreferredSeries()
On 2014/04/01 07:10:07, fwereade wrote:
> mm, I rather liked the PreferredSeries(conf) spelling, especially if
it were
> using an interface with just the DefaultSeries method. This doesn't
feel
> fundamental to a config -- does that seem sane?
https://codereview.appspot.com/80280043/diff/60001/environs/config/config.go#newcode230
environs/config/config.go:230: return DefaultSeries
On 2014/04/01 15:05:12, cmars wrote:
> On 2014/04/01 07:10:07, fwereade wrote:
> > How do we determine the value of this? I'm feeling like it really
ought to
> > actually *be* the latest LTS, rather than just some global var set
by
> > who-knows-who.
> I can try to get this from 'distro-info --lts'. If that fails to exec,
I'll use
> a hard-coded fallback (named as such). What do you think?
> Client is a dog's dinner in this regard, and can only gradually and
> incrementally improve, but the internal APIs are generally written as
I want
> them, and should be used as a model. The core idea is that bulk APIs
can be used
> for single calls, but single APIs can't be used in bulk; as humans we
are bad at
> predicting the future, and I'd rather just do everything bulk-style so
as to
> avoid needless churn.
https://codereview.appspot.com/80280043/diff/60001/state/apiserver/client/client_test.go#newcode1980
state/apiserver/client/client_test.go:1980: comment :=
gc.Commentf("defaultSeries:%s charmName:%s", test.defaultSeries,
test.charmName)
On 2014/04/01 07:10:07, fwereade wrote:
> This comment should be pretty much redundant now, with the logging.
Break a test
> and look at the output with/without the comment -- and then use
whichever you
> prefer, but do look at them :).
I've addressed most of the feedback, but there is a problem lurking. LatestLtsSeries () == "trusty", some of the tests are failing
When config.
due to tools availability. I was able to resolve some of them, but not
all. Could really use some advice.
To reproduce the failures, this will simulate a post-trusty release
scenario in the proposed branch:
go test -ldflags "-X net/juju- core/environs/ config. latestLtsSeries trusty" ./...
launchpad.
These are the failures:
FAIL: bootstrap_ test.go: 506: TestAutoUploadA fterFailedSync test.go: 555: TestMissingTool sUploadFailedEr ror test.go: 301: UpgradeJujuSuit e.TestUpgradeJu ju test.go: 141: ite.TestImageMe tadataFilesDefa ultSeries
BootstrapSuite.
FAIL: bootstrap_
BootstrapSuite.
FAIL: upgradejuju_
FAIL: imagemetadata_
ImageMetadataSu
Everything passes when the latest LTS is precise.
Please advise,
Casey
https:/ /codereview. appspot. com/80280043/ diff/60001/ cmd/juju/ addmachine. go addmachine. go (right):
File cmd/juju/
https:/ /codereview. appspot. com/80280043/ diff/60001/ cmd/juju/ addmachine. go#newcode129 addmachine. go:129: series = conf.PreferredS eries() (conf) spelling, especially if
cmd/juju/
On 2014/04/01 07:10:07, fwereade wrote:
> mm, I rather liked the PreferredSeries
it were
> using an interface with just the DefaultSeries method. This doesn't
feel
> fundamental to a config -- does that seem sane?
Done.
https:/ /codereview. appspot. com/80280043/ diff/60001/ cmd/juju/ common. go
File cmd/juju/common.go (right):
https:/ /codereview. appspot. com/80280043/ diff/60001/ cmd/juju/ common. go#newcode82 common. go:82: logger. Warningf( `ResolveCharm not supported by
cmd/juju/
the API server, falling back to default series "precise".`)
On 2014/04/01 07:10:07, fwereade wrote:
> PreferredSeries should surely be guaranteed to return non-""?
Done.
https:/ /codereview. appspot. com/80280043/ diff/60001/ environs/ config/ config. go config/ config. go (right):
File environs/
https:/ /codereview. appspot. com/80280043/ diff/60001/ environs/ config/ config. go#newcode230 config/ config. go:230: return DefaultSeries
environs/
On 2014/04/01 15:05:12, cmars wrote:
> On 2014/04/01 07:10:07, fwereade wrote:
> > How do we determine the value of this? I'm feeling like it really
ought to
> > actually *be* the latest LTS, rather than just some global var set
by
> > who-knows-who.
> I can try to get this from 'distro-info --lts'. If that fails to exec,
I'll use
> a hard-coded fallback (named as such). What do you think?
Done.
https:/ /codereview. appspot. com/80280043/ diff/60001/ state/api/ params/ params. go params/ params. go (right):
File state/api/
https:/ /codereview. appspot. com/80280043/ diff/60001/ state/api/ params/ params. go#newcode338 params/ params. go:338: URLs []charm.URL
state/api/
On 2014/04/01 07:10:07, fwereade wrote:
> I think we need an error per-result here, don't we?
Done.
https:/ /codereview. appspot. com/80280043/ diff/60001/ state/apiserver /client/ client. go /client/ client. go (right):
File state/apiserver
https:/ /codereview. appspot. com/80280043/ diff/60001/ state/apiserver /client/ client. go#newcode963 /client/ client. go:963: return ResolveCharmRes ults{}, err
state/apiserver
params.
On 2014/04/01 07:10:07, fwereade wrote:
> sorry for the hassle, but we should always return one result per
request, and
> that result should contain either the answer or the error.
> Client is a dog's dinner in this regard, and can only gradually and
> incrementally improve, but the internal APIs are generally written as
I want
> them, and should be used as a model. The core idea is that bulk APIs
can be used
> for single calls, but single APIs can't be used in bulk; as humans we
are bad at
> predicting the future, and I'd rather just do everything bulk-style so
as to
> avoid needless churn.
Done.
https:/ /codereview. appspot. com/80280043/ diff/60001/ state/apiserver /client/ client_ test.go /client/ client_ test.go (right):
File state/apiserver
https:/ /codereview. appspot. com/80280043/ diff/60001/ state/apiserver /client/ client_ test.go# newcode1980 /client/ client_ test.go: 1980: comment := "defaultSeries: %s charmName:%s", test.defaultSeries,
state/apiserver
gc.Commentf(
test.charmName)
On 2014/04/01 07:10:07, fwereade wrote:
> This comment should be pretty much redundant now, with the logging.
Break a test
> and look at the output with/without the comment -- and then use
whichever you
> prefer, but do look at them :).
Done.
https:/ /codereview. appspot. com/80280043/ diff/60001/ state/apiserver /client/ client_ test.go# newcode2158 /client/ client_ test.go: 2158: machines[ 2].Series( ), gc.Equals, "non-default")
state/apiserver
c.Assert(
On 2014/04/01 07:10:07, fwereade wrote:
> would be pretty nice to dupe this test with an empty default-series. I
know it's
> not your code originally, but... :)
I'm not quite clear on where I'd set it.
https:/ /codereview. appspot. com/80280043/