[Pacemaker] DRBD Management Console 0.6.0

[Tim Serong]

On 3/2/2010 at 11:12 PM, "Rasto Levrinc" <rasto.levrinc at linbit.com> wrote: 
> On Tue, March 2, 2010 11:41 am, Lars Marowsky-Bree wrote: 
> > On 2010-02-28T12:24:26, Rasto Levrinc <rasto.levrinc at linbit.com> wrote: 
>  
> > cool stuff. It's sad that we end up with a competing thingy ... Maybe we 
> > could keep Tim's pure web-ui for the monitoring and most simple bits and 
> > have drbd-mc replace the python UI. 
>  
> Thanks lmb. I see a place for Hawk as a lightweight tool to quickly make 
> some changes and I could even somehow integrate in the DRBD-MC. I can 
> speed up the DRBD-MC quite a bit still, I did not even try to optimize it 
> till now, but it will never be very fast. 

Yeah, from my perspective I think Hawk and DRBD-MC will each have different
strengths, for example pointing a web browser at a cluster node to see status
is easy/quick/lightweight, whereas visualizing complex dependency relationships
between resources is more straightforward to implement and interact with
in a regular non-web app (although no doubt HTML5 advocates will disagree with
me here :))

> > How does it interact with the CRM shell? Does it issue XML changes 
> > directly? What kind of network connection is required between the UI client 
> > and the servers? 
>  
> DRBD-MC connects itself via SSH and uses mostly cibadmin and crm_resource 
> commands on the host. It could simply use crm shell commands instead, but 
> it doesn't at the moment, mostly to be compatible with older Heartbeats 
> and there was no reason to change it. 

By comparison, Hawk doesn't need SSH, as it's running on the cluster nodes.
Internally it also uses cibadmin, a couple of crm_* commands and the crm shell,
so currently only works with Pacemaker 1.x.  It /reads/ XML from cibadmin,
but I wasn't planning on having it change the XML directly, rather any changes
are (and will be) made through existing CLI tools.

Side point: I have it in the back of my mind that I may end up wanting to
communicate directly with libcib if the CLI tools ever become a performance
bottleneck, but this isn't a problem yet (earlier, Hawk was running
crm_resource to get the status of each resource, so the more resources,
the more execs: yuck.  Now it just figures everything out from a single
run of cibadmin).

> > 
> > Is there a chance to share more code between the various UIs that, I 
> > think, we are going to keep going forward? (I'm pretty sure the crm shell, 
> > the web-ui and yours are going to remain actively maintained.) 
> > 
>  
> Yes, I like that. 
>

I'm also keen on duplicating as little as possible, but I think there's more
scope for sharing of underlying tools (crm shell etc.), or perhaps developing
new scaffolding as necessary, than for sharing pieces of higher-level GUI
implementation.

Regards,

Tim


-- 
Tim Serong <tserong at novell.com>
Senior Clustering Engineer, OPS Engineering, Novell Inc.