Open Stack

On Thu, 8 Nov 2012, Sean Dague wrote:

> A discussion arose in the following review -
> https://review.openstack.org/#/c/14550/ which I think needs some broader
> discussion so we at least are all on the same page.
>
> We now have openstack specific metadata in the system. The first piece was
> versioned like the ec2 metadata, with the date when it was added (2012-08-10).
> There is now a second proposed piece, with a proposed metadata version of
> 2013-04-04.
>
> We've started getting into the habbit of versioning lots of things at a git
> commit level, so that running on trunk is actually something folks can do. RPC
> versioning bumps many times in the middle of a development series, for
> instance.
>
> It seems to me that we should be trying to apply this standard as much as
> possible. Which would mean that we'd want this change to come in with a
> metadata version that looks more like 2012-11-08, not just versioning on
> release boundaries, but inherently versioning in the code when changes happen.
> This is towards the goal of the code always being in a releasable state.

The problem with a new metadata version for each change is that each entry
would then be rendered to config drive, and also (less annoying) when
listing the versions from the http metadata service.  This is unnecessary
duplication and messiness.

I'd like to keep at least the goal of one metadata service api bump per
development release.  If the concern is that people deploying trunk
would expose their users to changing metadata api information, then I
suggest a flag like 'expose_development_metadata', that could be turned
off in those deployments.

The current development metadata could be hidden either through code that
would have to be changed just prior to release, or a date based check.
 * code change path, pseudo code like:
   development_metadata = "2012-11-08"  # change me before release
   if not FLAGS.expose_development_metadata:
      API_VERSIONS = API_VERSIONS - [development_metadata]

 * date based check psuedo code like:
   if not FLAGS.expose_development_metadata:
      API_VERSIONS = [v for v in API_VERSIONS if date_newer_than(v, today)]

The default for expose_development_metadata would be True, but if you were
running trunk but did not want to expose change to your users you'd turn
it off.

> I'll let Scott or someone else put forward the alternative point of view, as
> this does add some extra to config drive.
>
> Regardless of the agreement, this seems like it's something we should have a
> pretty standard approach on so that reviews in the future can be consistent
> here.