central agent specifications

gistfile1.txt

Central agent specifications

Central agent is a new archipel module configured in archipel.conf :
[CENTRALAGENT]
centralagent   = "force", "passive", "auto"
force = this hypervisor is the central agent, subscriber of the pubsub
passive = this hypervisor will publish updates to the central agent
auto = will first check if there already is a central agent. If there is none, become central agent, otherwise, be passive. (this can be delayed to later)

There are 2 pubsubs :
- central agent keepalive : in "auto" mode, all hypervisors are subscribed to this one, and when one hypervisor notices there is no central agent sending keepalives, it becomes central agent and start sending keepalives.

- central agent database : pushes database updates to the central agent. The central agent is the only one who can write to the central database (previsously vmparking). This is to prevent locks induced by NFS. Only central agent is subscribed.

pubsub reference  (for manual testing with psi) :

<iq from="admin@archipel-test.archipel.priv/onk" to="pubsub.archipel-test.archipel.priv" 
id="bnx2hd03"
type="set">
<pubsub xmlns="http://jabber.org/protocol/pubsub">
<subscribe node="/archipel/centralagentdatabase" jid="admin@archipel-test.archipel.priv"/>
</pubsub>
</iq>

<iq from="admin@archipel-test.archipel.priv/onk" to="pubsub.archipel-test.archipel.priv" 
id="bnx4hd04"
type="set">
<pubsub xmlns="http://jabber.org/protocol/pubsub">
<subscribe node="/archipel/centralagentkeepalive" jid="admin@archipel-test.archipel.priv"/>
</pubsub>
</iq>

<iq from="admin@archipel-test.archipel.priv/onk" to="pubsub.archipel-test.archipel.priv" 
id="bnxiroe4"
type="set">
<pubsub xmlns="http://jabber.org/protocol/pubsub">
<publish node="/archipel/centralagentkeepalive">
<item>
<event type="keepalive" jid="admin@archipel-test.archipel.priv/onk"/>
</item>
</publish>
</pubsub>
</iq>

<iq from="admin@archipel-test.archipel.priv/onk" to="pubsub.archipel-test.archipel.priv" 
id="bnxiroe4"
type="set">
<pubsub xmlns="http://jabber.org/protocol/pubsub">
<publish node="/archipel/centralagentdatabase">
<item>
<event type="database" command="insert into vms values(:uuid, :parker, :creation_date, :domain, :hypervisor)">
<entry>
<item key="uuid" value="abcfed"/>
<item key="parker" value="john"/>
<item key="creation_date" value="2012"/>
<item key="domain" value="\<blah\/\>"/>
<item key="hypervisor" value="archipel-test.archipel.priv@archipel-test.archipel.priv"/>
</entry>
</event>
</item>
</publish>
</pubsub>
</iq>

Seems to be ok. The only thing is that parking management should be a module of the central agent.

Also, I'm not very agree with hypervisors becoming central agent. The central agent should always be a separate process (then you can install on one hypervisor) with it's own JID (or sets of JIDs).
On hypervisors' archipel.conf you should only declare central_agent_jids or something and the rest should be automatic.

Keep in mind that the central agent can be used to manage parking, but also a lot of other different stuff (like billing).
So it has to have the same modularity system than the archipel agent.

Then it means a lot of extra work is required to have the central agent :

• create xmpp entities on the server
• configure the central agent in the hypervisor
• associate all hypervisor with this central agent

In my approach, the hypervisors are just speaking in one channel and "elect" the central agent responsible to write to the central database. None of the configuration steps listed above are required.

Why make it a different process ? If there is no hypervisor, then the central agent has no purpose anyway. Otherwise, it's a totally different program than archipel-agent.

Why give it a jid ? All things you would want to tell the central agents are better sent through pubsub because there can be several of them (say, one active one and one hot standby)

For billing, you could shout updates on resources consumed by each hypervisor/vm in the same pubsub.

About modularity, there could be several modules archipel-central-agent, archipel-central-agent-billing, archipel-central-agent-vmparking.

I still can't push my code (bad internet) but hopefully you'll have a better understanding of what I'm trying to do once I manage to push.

Then it means a lot of extra work is required to have the central agent :

• create xmpp entities on the server
• configure the central agent in the hypervisor
• associate all hypervisor with this central agent

In my approach, the hypervisors are just speaking in one channel and "elect" the central agent responsible to write to the central database. None of the configuration steps listed above are required.

Why make it a different process ? If there is no hypervisor, then the central agent has no purpose anyway. Otherwise, it's a totally different program than archipel-agent.

Why give it a jid ? All things you would want to tell the central agents are better sent through pubsub because there can be several of them (say, one active one and one hot standby)

For billing, you could shout updates on resources consumed by each hypervisor/vm in the same pubsub.

About modularity, there could be several modules archipel-central-agent, archipel-central-agent-billing, archipel-central-agent-vmparking.

I still can't push my code (bad internet) but hopefully you'll have a better understanding of what I'm trying to do once I manage to push.