Minutes from 2018-08-10 Cloudstack meeting
OMP Cloudstack meeting August 10th, 2018
Attendees: Russ H, Len S, Neale, John A, Tony N, John M, Mike F, Alex K
The zoom meeting was recorded: https://sourceforge.net/projects/system-zoom/files/2018-08-10-Cloudstack-Meeting.mp4/download
1. Russ Herold presented PM Man
2. Review the RESTful API document
GitHub vs. Google Docs => OK to stick with Google docs for now
John: This document is being developed under the Create Common License
(DCO) Developers Certificate of Origin: https://developercertificate.org/
Lightweight way of validating that all contributions are permitted
If anyone wants to copy the latest google doc and check it in to GitHub, they are welcome to
Russ: Using Markdown is easy to learn
Mike F: Using GitHub and checking code/documents in is some work, but not too difficult
There are markup viewers - Atom - atom.io is the website
Solutions need a method of updating stale data that has been changed "out of band".
Mike F: People can add APIs at https://github.com/mfcloud/python-zvm-sdk
John M: GitHub project that Mike mentions above is down the path of delivering an API
Mike M's comments on the latest document:
All of the sections should not have been moved to an Appendix. At least the sections
"Private cloud solution high level goals" and "Private cloud specific goals"
should be put back so there are high level introductory words.
Should a Glossary be added? Here is a start:
Guest – A virtual machine running an OS – usually Linux
Guest definition – z/VM User directory entry
Host – A hypervisor – usually z/VM
Image – A copy of an OS that can be copied to and run on a virtual machine
Pause – CP Stop CPU
UnPause – CP Begin CPU
Start – Power on
Stop – Power off
Vswitch – A virtual switch as it behaves on z/VM
VLANID – An IEEE Virtual Lan identifier
Comments to specific sections:
7.4.6. Get Guests stats including cpu and memory and 7.4.7. Get Guests interface stats – should “Performance Data” be a separate section?
7.4.10. Delete Guest – I believe we agreed last meeting a “two phase delete” is best so guests accidentally deleted can be restored.
7.4.11. Get Guest info – should we start to list attributes. Here is “a stake in the ground”:
This will allow CP commands to be run on any z/VM system in the "cluster" – add these APIs?
query-chpids [chanPath] Query z/VM channel paths
query-dasd [rdevRange] Query z/VM DASD
query-direntry entry Query a z/VM USER, PROFILE or IDENTITY
query-fcp [rdevRange] Query z/VM FCP devices
query-osa Query z/VM OSA devices
query-pav [rdevRange] Query z/VM PAV devices
query-rdev [rdevRange] Query z/VM real devices
7.next Commands – => Mike F: these functions are perhaps outside the scope of this standard
There should be RESTful APIs to run commands on:
run-command nodeList,command Run a command on Linux systems
run-cp-command system-IDs,command Run a CP command on z/VM systems
Will there be the concept of Job UUIDs? The idea here is that “long running jobs” as RESTful API calls should not take many tens of minutes to return (e.g. reboot 200 guests). Rather those calls should be passed a “job UUID” and then that ID can be monitored with subsequent RESTful APIs such as:
list-job jobID List the status of the specified job
monitor-job jobID,[iters] Monitor the specified job until complete or timeout
Should APIs be added for chargeback (as in Russ H’s PMMAN demo)?
7.N Backup and restore
Should APIs be added for backup and restore (as in Russ H’s PMMAN demo)?
Next meeting: 2018-08-24