Bug 753302

Summary: Tools for allowing integration of 3rd party 'plugins'
Product: [Retired] oVirt Reporter: Perry Myers <pmyers>
Component: ovirt-nodeAssignee: Joey Boggs <jboggs>
Status: CLOSED CURRENTRELEASE QA Contact:
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: unspecifiedCC: ovirt-bugs, ovirt-maint
Target Milestone: ---Keywords: FutureFeature
Target Release: 3.4.3   
Hardware: Unspecified   
OS: Unspecified   
URL: http://ovirt.org/wiki/Node_plugins
Whiteboard:
Fixed In Version: 2.5.0 Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-08-09 11:47:54 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 753309, 759504    
Bug Blocks: 754781    

Description Perry Myers 2011-11-11 20:34:18 UTC 
Description of problem:
Provide tools that can inject 'plugins' into oVirt Node ISO images.  This feature/design right now are rpm/livecd specific, since the only oVirt Node right now is rpm/livecd based.  Other distros (when they have created their own derivative oVirt Node distribution mechanisms/formats) can implement similar features but with different implementation/design.

A few requirements are:

1. The plugins need to be installed into an area of the filesystem that will not interfere with normal oVirt Node operations
2. Multiple plugins should be able to coexist and not step on each other
3. Plugins should be packaged in such a way that they can be validated via a digital signature so that only reviewed/approved plugins are permitted to be installed (we can provide an override of course to ignore the signature process)
4. Plugin installation should be logged in a manifest that is stored on the node so that there is a record of what was installed, where and when
5. The plugin installation tool should have restrictions on what it will allow plugins to do (i.e. what types of files, what types of config changes, etc) so that we can prevent plugins from breaking other plugins and/or the core system
6. Plugins should be self-contained (all dependencies contained in the bundle).  Though there might be some benefit to allowing a plugin to pull dependencies from an upstream yum repository?  (i.e. libvirt-cim plugin might pull tog-pegasus rather than having to package tog-pegasus and all deps)

Some design thoughts:
1. A plugin bundle could be simply a tarball with a set of RPMs and some metadata about the bundle.
2. Initial thought is to use the edit-livecd tooling in the livecd-tools package and to wrap it with a script called edit-node that provides things like: signature verification, manifest generation, etc

Additional thoughts on this feature should be posted here as comments, or put up on the ovirt.org wiki and linked to from here.
Comment 1 Perry Myers 2011-12-02 17:44:49 UTC 
http://ovirt.org/wiki/Node_plugins
Comment 2 Joey Boggs 2012-07-24 19:58:53 UTC 
1. --install-kmod and --install-plugin have whitelisted areas of where they can write to. --install is not blocked by those

2. up to plugin writer to pick directories

3.  gpgcheck for installations, --nogpgcheck can override this verification as well as depending on the yum repo configuration file

4. manifests stored in /isolinux/ for current manifests and for deltas between every revision

5. same as #1

6. same as #1 and #3 yum repo file can supply any combination of repo options/settings

Section 2:

edit-node strips edit-livecd to bare essentials and builds on top of it, so we maintain full control of what is allowed to happen to the iso.  Plugins can be a single rpm file, an rpm pulled from a yum repo + dependencies or a package pulled from RHN if the editing machine is registered.