This is an attempt to sketch out the admin and developer visible changes that could be used to support version specific contributors.  This type of mechanism is required for two reasons:

1. Knox should prevent attempts to use REST APIs that do not exist in older versions of services.
2. Not all services maintain strict backward compatibility between versions and as such required different Knox behavior per version.

Below is a sample of how the ServiceDeploymentContributor contract could be enhanced to declare support for particular versions.

package org.apache.hadoop.gateway.deploy;
import org.apache.hadoop.gateway.topology.Service;
public// An extension to base interface ServiceDeploymentContributor {
  for backward compatibility with existing contributors.
// TheService located roleand ofloaded thisvia servicethe deploymentbase contributorinterface.
public interface e.g. WEBHDFS
  String getRole();VersionedServiceDeploymentContributor extends ServiceDeploymentContributor {
  // The versions namesupported ofby this service deployment contributor.  Not used yet contributor.
  // Formatted according to the Maven Enforcer plugin syntax.
  String getName();// http://maven.apache.org/enforcer/enforcer-rules/versionRanges.html
  // CalledReturning null afterindicates providerthat initializeContributionall methodsversions andare insupported arbitraryand orderis relativeequivalent to other service contributors."[0,)"
  voidString initializeContributiongetVersions( DeploymentContext context ););
}

Below is a sample of how version could be added to the topology file.

<topology>
  // Called per<gateway>
 service based on the service's role ...
  // Returns a</gateway>
 list of resources it....
 added to the descriptor.<service>
  void  contributeService( DeploymentContext context, Service service<role>HIVE</role>
 ) throws Exception;
  // Called after all contributors and before provider finalizeContribution methods.
  void finalizeContribution( DeploymentContext context );
} <version>0.13.0</version>
        <url>http://localhost:10001/cliservice</url>
    </service>
</topology>

Contributor Selection

1. In general the contributor declaring the latest explicit version support that includes the required version is selected.
2. In the case of a tie selection will continue with the next latest explicit version support
3. This will continue until a single contributor is selected.
4. If this is not possible an arbitrary selection will be made from the remaining candidates.

Open Questions

• Should ServiceDeploymentContributors be able to specify version ranges?
• How can a contributor that will likely work for every future version of a service declare that fact?
• How can a more contributor supporting a more specific version take precedence over a more generic?
• What happens during rolling upgrade where for example NameNodes of different versions are running?
• Should versions be specified as they are in Maven and probably the way the Enforcer Maven plugin as defined? 
  • http://maven.apache.org/enforcer/enforcer-rules/versionRanges.html
  • http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict+Resolution#DependencyMediationandConflictResolution-DependencyVersionRanges