THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
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:
- Knox should prevent attempts to use REST APIs that do not exist in older versions of services.
- 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.
| Code Block | ||||||
|---|---|---|---|---|---|---|
| ||||||
package org.apache.hadoop.gateway.deploy; import org.apache.hadoop.gateway.topology.Service; public interface ServiceDeploymentContributor { // TheAn roleextension ofto thisbase serviceinterface deploymentfor contributor.backward compatibility e.g. WEBHDFS String getRole(); // The name of this service deployment contributor. Not used yet. String getName();with existing contributors. // Service located and loaded via the base interface. public interface VersionedServiceDeploymentContributor extends ServiceDeploymentContributor { // CalledThe afterversions providersupported initializeContributionby methods and in arbitrary order relative to other service contributorsthis contributor. void initializeContribution( DeploymentContext context ); // CalledFormatted peraccording serviceto basedthe onMaven theEnforcer service'splugin rolesyntax. // Returns a list of resources it added to the descriptor. void contributeService( DeploymentContext context, Service service ) throws Exception; // Called after all contributors and before provider finalizeContribution methods. void finalizeContribution( DeploymentContext context ); }http://maven.apache.org/enforcer/enforcer-rules/versionRanges.html // Returning null indicates that all versions are supported and is equivalent to "[0,)" String getVersions(); } |
Below is a sample of how version could be added to the topology file.
| Code Block | ||||||
|---|---|---|---|---|---|---|
| ||||||
<topology>
<gateway>
...
</gateway>
....
<service>
<role>HIVE</role>
<version>0.13.0</version>
<url>http://localhost:10001/cliservice</url>
</service>
</topology> |
Contributor Selection
- In general the contributor declaring the latest explicit version support that includes the required version is selected.
- In the case of a tie selection will continue with the next latest explicit version support
- This will continue until a single contributor is selected.
- 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?