Revision 188fbf41

b/doc/design-2.0-os-interface.rst
107 107 
  way to distinguish them. A target/source node and directory will be instead
108 108 
  passed, for the import script to do the correct job. All scripts will get
109 109 
  nothing in input and are supposed to output only user-relevant messages.
110 
- Scripts are not compulsory: if a script is missing the relevant operations
111 
  will be forbidden for instances of that os. This makes it easier to
112 
  distinguish between unsupported operations and no-op ones (if any).
110 
- Some scripts are not compulsory: if such a script is missing the relevant
111 
  operations will be forbidden for instances of that os. This makes it easier
112 
  to distinguish between unsupported operations and no-op ones (if any).
113 113 

  		





  114
  114
  
    

  		





  115
  115
  
    
Input


  		





  ......




  118
  118
  
    
Rather than using command line flags, as they do now, scripts will accept


  		





  119
  119
  
    
inputs from environment variables.  We expect the following input values:


  		





  120
  120
  
    

  		





  
  121
  
    
OS_API_VERSION


  		





  
  122
  
    
  The version of the OS api that the following parameters comply with;


  		





  
  123
  
    
  this is used so that in the future we could have OSes supporting


  		





  
  124
  
    
  multiple versions and thus Ganeti send the proper version in this


  		





  
  125
  
    
  parameter


  		





  121
  126
  
    
INSTANCE_NAME


  		





  122
  127
  
    
  Name of the instance acted on


  		





  123
  128
  
    
HYPERVISOR


  		





  ......




  189
  194
  
    
Other declarative style features


  		





  190
  195
  
    
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


  		





  191
  196
  
    

  		





  192
  
  
    
As for Ganeti 1.2 OS specifications will need to provide a 'ganeti_api_version'


  		





  193
  
  
    
with a number matching the version of the api they implement. Ganeti itself


  		





  194
  
  
    
will always be compatible with one version of the API and may maintain


  		





  195
  
  
    
retrocompatibility if it's feasible to do so.


  		





  
  197
  
    
Similar to Ganeti 1.2, OS specifications will need to provide a


  		





  
  198
  
    
'ganeti_api_version' containing list of numbers matching the version(s) of the


  		





  
  199
  
    
api they implement. Ganeti itself will always be compatible with one version of


  		





  
  200
  
    
the API and may maintain retrocompatibility if it's feasible to do so. The


  		





  
  201
  
    
numbers are one-per-line, so an OS supporting both version 5 and version 20


  		





  
  202
  
    
will have a file containing two lines. This is different from Ganeti 1.2, which


  		





  
  203
  
    
only supported one version number.


  		





  196
  204
  
    

  		





  197
  205
  
    
In addition to that an OS will be able to declare that it does support only a


  		





  198
  206
  
    
subset of the ganeti hypervisors, by declaring them in the 'hypervisors' file.


  		












Also available in:
  Unified diff