warning: environments.yaml schema change

William Reade william.reade at canonical.com
Wed Mar 21 01:40:08 UTC 2012

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.

If anyone can suggest any improvements to this approach, please do so.


[0] This was scheduled for removal in a related change I hadn't been
thinking about directly before. Forces in play are similar, with one
notable addition: until we have reimplemented environment setting
storage, we have no way to replace it, and can only spew unresolvable
doom at our users, and they might not like that. Benefit of warning IMO
just barely outweighs cost; very open to counterarguments.

More information about the Juju mailing list