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; public interface ServiceDeploymentContributor { // The role of this service deployment contributor. e.g. WEBHDFS String getRole(); // The name of this service deployment contributor. Not used yet. String getName(); // The list of versions supported. Each element is a dot separated components of descending significance. String[] getVersions(); // Called after provider initializeContribution methods and in arbitrary order relative to other service contributors. void initializeContribution( DeploymentContext context ); // Called per service based on the service's role. // 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 ); }
Toplogy File
<topology> <gateway> ... </gateway> .... <service> <role>HIVE</role> <url>http://localhost:10001/cliservice</url> <version>0.13.0</version> </service> </topology>
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?