warning: environments.yaml schema change

[Mark Shuttleworth]

On 21/03/12 01:40, William Reade wrote:
> On Tue, 2012-03-20 at 08:35 -0700, Clint Byrum wrote:
>> However, I don't think we can keep breaking peoples' existing installs
>> anymore.  There has to be some kind of stability, or we'll chase beta
>> testers and early adopters away.
> Good point, well made.
>
>> Can I suggest that instead of making these keys invalid, that they are
>> marked as deprecated, and we simply warn users about that?
> As a first step I am adding instability warnings to default-series [0],
> default-instance-type, and default-image-id. The latter two share a
> detailed message explaining what should be done to make it go away; the
> first one is merely a warning that the feature will go away soon but
> there is no replacement yet (this replacement is the first priority
> after informing people).
>
> This should warn any PPA users who don't read the lists of the upcoming
> changes, and hopefully mitigate the impact of the breakage we will sadly
> have to enforce.
>
>> So if I have one of them, I'd expect something like this on any juju
>> command:
>>
>> 2012-03-20 08:32:00,123 WARNING default-image-id is deprecated. Use --constraints instead.
>>
>> And then keep the old behavior at least until after we ship a version
>> of juju in the 12.04 release of Ubuntu?
> My heart says that we should indeed retain these, with warnings, until
> 12.04.1; I understand that the removal of an option is a seriously
> annoying thing to inflict.
>
> However, I feel that default-image-id is enough of an evil dangerous
> hack that it really really must not land in 12.04; and, if we're going
> to have to break environments.yaml, we should be absolutely sure to
> break it once and only once, and remake it precisely as we need.
>
> So, I think, we have no realistic choice but to land all these changes
> (which range from "essential" to "highly desirable") in one fell swoop,
> very soon; but having still made our best effort to inform people.
>

Let's warn very loudly of the pieces that are deprecated, and as Gustavo
suggests, have the tool itself tell the user how to fix things to avoid
the warnings. We don't have to break existing docs / installations in
order to send a very strong signal where things are going, and we should
certainly send that signal pre-release.

Mark