Reusing old features to build new ones Step by Step Reusing old features to build new ones Allon Mureinik amureini@redhat.com / @mureinik Supervisor, RHEV Storage Red Hat DevConfCZ, Feb 2015
Old school software development We go through a rigorous process of defining the full scope of the requirements, designing to answer every need, implement it, test, re-test, test again until we have a perfect feature...
And when you're all set and done … And you end up with a white elephant, which is too expensive to maintain, and usually serves no useful purpose.
An alternative approach I intend to show the step-by-step approach, where insurmountable features are broken down to smaller parts, and each part has it's own benefits.
Case study – oVirt Live Merge
What Is oVirt? Large scale, centralized management for server and desktop virtualization Based on leading performance, scalability and security infrastructure technologies Provide an open source alternative to vCenter/vSphere Focus on KVM for best integration/performance Focus on ease of use/deployment
oVirt: Not a Single Project Incubation Projects MOM moVirt Test Projects … your contributions are welcome! See http://ovirt.org for details oVirt-Engine VDSM oVirt-Node ovirt-Engine-SDK oVirt-Engine-CLI oVirt-Guest-Agent oVirt-Image-Uploader oVirt-iso-Uploader oVirt-Log-Collector oVirt-DWH oVirt-Reports
Some architecture...
Live Snapshot Capture disks and memory at a point in time Implemented using qcow2 volume chains Usages Save the state before a major change Can be previewed or reverted VM live backup Live Storage Migration What is it? - a consistent point in time Implementation: - currently Qcow2, looking forward to Qcow3.
The next logical step... Bug 647386 - Support live deletion of a snapshot / live-merge Reported against RHEVM 2.3.0 (Oct. 2010) 27 customer tickets http://www.ovirt.org/Features/Live_Merge So what's the big deal?
An actual conversation...
An actual conversation...
An actual conversation...
An actual conversation...
Problem 1 – What if a merge fails?
Problem 1 – What if a merge fails?
Solution 1 – Single Disk Snapshots http://www.ovirt.org/Features/Single_Disk_Snapshot
Problem 2 – long running tasks... Up to 3.5.0, oVirt has two kinds of verbs to communicate with VDSM: Synchronous verbs Finish in under 3 minutes Give result immediately Asynchronous May take a long time to complete Return a task to be monitored Only run on SPM Engine commands have up to 3 stages executeAction() - Synchronous database + VDSM Poll the task until it completes (or fails) endSuccefully() / endWithFailure()
Solution 2 - SEAT A mechanism was added for Serial Execution of Asyncronous Tasks http://wiki.ovirt.org/Features/Serial_Execution_of _Asynchronous_Tasks Allows creating chains of actions: execute poll for a task move to the next execution... ... or rollback everything
Solution 2 – Why would I even... Live Storage Migration http://www.ovirt.org/Features/Design/StorageLive Migration Utilizes SEAT for a series of tasks: [Live Snapshot – not mandatory] Clone image structure Start syncing active image Sync backing chain Stop sync Remove (and wipe) source
Problem 3 – Still only SPM tasks Up to 3.5.0, only SPM can run asynchronous tasks This is due to the requirement to persist task info on the master domain
Solution 3 – HSM “Tasks” Separate the coordination code from the polling code http://www.ovirt.org/Features/Design/CommandC oordinator Report the progression of the block job on the pooled VM stats Now the HSM that runs the VM can run the merge verb The basis for rewriting VM migration The basis for removing the SPM completely Come here all about it in DevConfCZ 2016!
A quick shoutout
THANK YOU! Feedback appreciated: http://devconf.cz/f/79 Stay in touch: amureini@redhat.com @mureinik https://il.linkedin.com/pub/mureinik Patches welcome: http://www.ovirt.org