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
_______________________________________________
node-devel mailing list
[email protected]
http://lists.ovirt.org/mailman/listinfo/node-devel
