[node-devel] Rethinking implementation for oVirt Node Plugins

[Joey Boggs]

On 01/31/2012 11:40 AM, Perry Myers wrote:
> On 01/30/2012 12:36 PM, Joey Boggs wrote:
>> On 01/30/2012 11:39 AM, Geert Jansen wrote:
>>> Thanks Perry. I had a look at the Wiki and i think it is mostly very
>>> reasonable. Some comments/questions:
>>>
>>>   - Do i understand it correctly that the plugin<->  OS interface you
>>> propose is "model based" rather than "file based"? All plugins' files
>>> are under a separate root, and they only become enabled once a logical
>>> setting in an XML description file enables it (e.g. services, kernel
>>> modules, etc). I think that is probably the right approach. It will
>>> make it cleaner for sure to manage plugins this way. It also allows
>>> much better reporting of what a plugin does in the GUI.
>> The goal is to have it all separated with minimal overlap such as
>> suggested earlier with a place to register the plugins that are
>> installed on the node visible within the web ui.
>>> The alternative would be a "file based" interface where the plugin
>>> just puts files directly in various system directories. I think the
>>> main requirement to ensure is that with a model based approach our
>>> initial model is rich enough.
> Actually I think this is a hybrid of the two models you describe above.
>
> On the one hand, what is being installed are just 'normal RPMs' and so
> from that perspective the RPM used for vdsm should be no different on
> oVirt Node from Fedora usage.  It should put the files where they
> normally go in directories like /usr/bin, etc.
>
> But on the other hand, being a plugin implies a higher level model.  So
> the 'top level' RPM in a given plugin (like vdsm) should include some
> metadata about itself so that we can do things like 'report which
> plugins are installed' back to oVirt Engine
>
> That being said...  RPM has a rich metadata structure, so can't we use
> some of RPM metadata to identify a particular package (vdsm, cim-plugin,
> etc) as such?
>
> That way the process of finding out 'which plugins are installed' could
> be simply rpm queries looking for which rpms are classified as plugins.
>
> There is other metadata needed like:
> * firewall ports
> * services that need to start
>
> But this is normally handled in RPM %post anyhow.
>
>>>   - One important thing (actually #1 request so far) is to allow VDSM
>>> hooks to be installed. So the XML descriptor would need to support that.
>> Don't see that being an issue, it should be added as a requirement now
>> rather than later
> ack
>
> Do we have an example of a vdsm hook RPM upstream that we can use as a
> test case?
>
>>>   - The signature infrastructure is something that requires a business
>>> process at Red Hat to manage the requests of ISVs, signing keys, etc.
>>> I'm skeptical if we need this for v1 to be honest. Feedback i have
>>> from vendors so far is that they'd prefer, at least initially, to keep
>>> it open. We still maintain list of plugins that are supported, but
>>> initially the overhead of basically runnning a PKI for ISVs is
>>> something that i wonder we want to do on a short time scale. I think
>>> the risks for abuse, for sure initially, is very low.
> Right.  I think even for upstream we should do signature verification.
> Here's a model that should work:
>
> 1. Upstream developer wants to create new oVirt Node plugin foo (and
>     foo is not part of Fedora, if it is, we just leverage normal Fedora
>     package signatures)
>
> 2. Upstream developer has to create a keypair, and they sign their
>     package foo with their private key.  Meanwhile, they need to
>     publicly distribute their public key
>
> 3. The plugin tool should be able to import a new public key into the
>     oVirt Node image
>
> 4. Once this public key is imported, then a subsequent install of foo
>     should work since the signature will be able to be verified
>
>  From a product perspective, perhaps the ability to do step 3) is
> restricted to the company distributing the oVirt Node derivative.  But
> that's not necessarily a topic for upstream to decide :)
>
>>>   - I think the offline merging of plugins with the hypervisor ISO is
>>> good enough for v1, given that a re-install of RHEV-H via RHEV-M is
>>> easy. So doing a live install only in v2 should be fine; however:
> Agreed.  The other thing to consider is that with live installs, because
> oVirt Node is stateless you'd have to completely reinstall all plugins
> on every boot which may end up being a source of additional
> complexity/errors.
>
> So while live plugin installation is theoretically possible, I want to
> avoid it at least for the time being
>
>>>   - We should also allow plugins to be installed on RHEL... Otherwise
>>> ISVs have to maintain two packages for their extensions, one for RHEL
>>> and one for RHEV-H.
>> As long as vdsm looks in the same predefined places this will not be an
>> issue and should be fine for both scenarios
> Actually... if plugins are simply 'the normal Fedora/RhEL package with
> some additional RPM metadata and possibly some additional other
> metadata' then this becomes trivial.  So completely agree
>
> So moving things to be more RPM/yum oriented I think buys us a lot here
> in terms of not reinventing the wheel.
>
> As mburns has pointed out to me, the hard work here is going to be:
>
> * determining what the necessary metadata is that we need to insert
>    into the spec file or other metadata file
>
> * determining how oVirt Node should handle that metadata.  Example:
>    + package foo says it needs port X opened.  It can either do this in
>      %post via smth like lokkit or it can just specify this in the
>      metadata
>    + If done via lokkit, we need oVirt Node to be able to emulate the
>      lokkit command so that we 'do the right thing' in the firewall
>    + If done via metadata we need to have the plugin process that
>      metadata so that it makes the appropriate change to the firewall
>
> * Doing the work associated with tracking filesystem/config changes so
>    that we can audit each change a plugin makes to the system
>
> Perry

Just wanted to check and see if there were any further comments for the 
plugins since it has been a few months. I'm working on the actual plugin 
tool used to modify the node iso and beginning to define what exactly is 
required from a "plugin recipe"

For the first pass the plugin recipe should be lightweight and only 
contain the metadata and repos needed for installation.

At this point we're looking at:
- predetermined kickstart filename(should be created using ksflatten if 
sourced from multiple kickstart files"
- yum repo file that points to an available yum repo.

This could be shorten by including the yum repo within the kicstarts, Is 
there any reason that it should remain available on the node?


This will require adding yum into the node to handle dependency 
requirements. Previous comments suggested disabling all repos as a 
preventative measure and then enabling them only during editing time.

Any comments or suggestions at this point prior to continuing down this 
path?

Joey