THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
ServiceDeploymentContributor
package org.apache.hadoop.gateway.deploy; import org.apache.hadoop.gateway.topology.Service; // An extension to base interface for backward compatibility with existing contributors. public interface ServiceDeploymentContributor2 extends ServiceDeploymentContributor { // The list of versions supported by this contributor. // Each element is formatted according to the Maven Enforcer plugin syntax. // Returning null indicates that all versions are supported. String[] getVersions(); }
Toplogy File
<topology> <gateway> ... </gateway> .... <service> <role>HIVE</role> <version>0.13.0</version> <url>http://localhost:10001/cliservice</url> </service> </topology>
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.
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?