On Thu, Jul 22, 2010 at 10:03:21AM -0400, Perry Myers wrote:
What this means is that we have the follow architecture:
- On Linux:
- matahari is an SRPM that has several binary RPM subpackages:
matahari-net, matahari-host, matahari-pkg, matahari-services, etc
- The matahari binary RPM might just be common libraries that are
shared between the various other RPMs/daemons
- Each other RPM has it's own:
- daemon that connects to QMF bus as an agent
- init script to start stop that particular daemon
- selinux policy specific to what that portion of matahari needs to do
- On Windows:
- init script == Windows Service, so one Windows Service for each of
matahari-net, matahari-host, etc
- Each of these Windows Services is an independent QMF agent
- We don't want 'n' Windows installers, since they don't have nice RPM
and yum functionality. So where Linux will have matahari-* for each service, we'll have a single 'matahari installer' for Windows that installs all of the services. Admin can deactivate services they don't want to use
Questions: Do we have each Agent connect to a single qpid broker installed on the guest, and then all we need to do is connect that broker to an external broker outside of the guest? This would make configuration much easier, all of the various matahari daemons/services could connect to a static configuration for the local broker, and then the only place with custom config would be chaining the local broker to the other external brokers?
Can the single guest broker that we have connect to both an external network broker and also connect over virtio-serial to the host broker? Or do we need two guest brokers, one to handle network based QMF and one to handle virtio-serial based QMF?
If we use a broker inside the guest I think we should have a dedicated broker by default, otherwise we'll significantly increase our install time complexity. eg what happens of the broker already present is too old for our agent's needs. also complicates access controls & routing to reuse the same broker.
Fortunately from a Matahari code POV this decision doesn't have any real impact. We'll just code it against qpid APIs and which broker it connects to will just be a config param. So we don't have to worry about this decision too much until we get to writing the installer for Win32/RPM %post setup.
So I'd aim for a dedicated broker in the guest to talk over virtio to host and connect guest agents to that. If we want to change this later to make guest agents talk directly to host broker it won't be any code changes, just config parameter tweaks.
Regards, Daniel