This Confluence has been LDAP enabled, if you are an ASF Committer, please use your LDAP Credentials to login. Any problems file an INFRA jira ticket please.

Child pages
  • KNOX-379: Custom behavior for services based on version
Skip to end of metadata
Go to start of metadata

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;
// An extension to base interface for backward compatibility with existing contributors.
// Service located and loaded via the base interface.
public interface VersionedServiceDeploymentContributor extends ServiceDeploymentContributor {
  // The versions supported by this contributor.
  // Formatted according to the Maven Enforcer plugin syntax.
  // 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.

Toplogy File

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

  • No labels