Display the VCH Management API version on plugin summary page

As described in vmware/vic-product#1952, display the version of the VCH Management API the plugin is communicating with on the plugin's "summary" page, near where the plugin version is displayed.

As the user is not able to select which API server to use (#572), providing this information may greatly aid debugging when multiple versions of API servers are available.

@zjs, Do you mean the version of this api: https://10.193.25.225/ui/vic/rest/services/get-vic-appliances

@zjs Is my understanding correct? @lweitzman , is this design ok?
Or call it :
VCH Versions:
XXX
XXX

Do you mean the version of this api: https://10.193.25.225/ui/vic/rest/services/get-vic-appliances

I'm not sure where that API sources its data from. If it's from the metadata on the VM, I worry that there are cases where it might be inaccurate.

I think the safest way to get the API server version is from the API server itself (from the /version API endpoint).

The code would be equivalent to this, but would call /container/version instead of /container/hello:

vic-ui/h5c/vic/src/vic-webapp/src/app/create-vch-wizard/create-vch-wizard.service.ts

Lines 573 to 601 in 3a0295a

    
           public verifyVicMachineApiEndpoint(): Observable<any | null> { 
        
             return this.getVicApplianceIp() 
        
               .catch((err: Error) => { 
        
                 return Observable.throw({ 
        
                   type: 'vm_not_found' 
        
                 }); 
        
               }) 
        
               .switchMap(ip => { 
        
                 return this.http.get(`https://${ip}:8443/container/hello`) 
        
                   .catch((err: Response) => { 
        
                     console.error(err); 
        
                     // network error. details are not visible in the browser level 
        
                     // however, we are fairly confident in most cases that this is caused by the 
        
                     // self-signed SSL certificate being blocked by the browser 
        
                     if (err.status === 0) { 
        
                       return Observable.throw({ 
        
                         type: 'ssl_cert', 
        
                         payload: ip 
        
                       }); 
        
                     } 
        
                     // handle http response status codes such as 404, 500, etc. 
        
                     return Observable.throw({ 
        
                       type: 'other', 
        
                       payload: err 
        
                     }); 
        
                   }) 
        
                   .map(response => ip); 
        
               }); 
        
           }

I suspect there's a simple refactoring that would avoid duplication between verifyVicMachineApiEndpoint and the new method (getVicApplianceVersion?).

VIC Appliance Version

Strictly speaking, this is the VCH Management API endpoint version. The VIC OVA (aka VIC Appliance) actually has a separate version number.

Marking as need info: we need to confirm whether this is required for 1.4.3.

fixed by:#598

	public verifyVicMachineApiEndpoint(): Observable<any \| null> {
	return this.getVicApplianceIp()
	.catch((err: Error) => {
	return Observable.throw({
	type: 'vm_not_found'
	});
	})
	.switchMap(ip => {
	return this.http.get(`https://${ip}:8443/container/hello`)
	.catch((err: Response) => {
	console.error(err);
	// network error. details are not visible in the browser level
	// however, we are fairly confident in most cases that this is caused by the
	// self-signed SSL certificate being blocked by the browser
	if (err.status === 0) {
	return Observable.throw({
	type: 'ssl_cert',
	payload: ip
	});
	}
	// handle http response status codes such as 404, 500, etc.
	return Observable.throw({
	type: 'other',
	payload: err
	});
	})
	.map(response => ip);
	});
	}