Re: [Config4gnu-developer] Re: alternative roadmap proposal

[C. G. <c.g...@tu...>]

Jason wrote:
> 2. Indeed, in my job I administer many servers, of various flavors of
> Linux/Unix and other operating systems. It is my intention to make
> Config4GNU into something I can use on my job, and if I can't do remote
> management with Config4GNU, it's useless. With WBEM, I have a network
> protocol, client/server components, and authentication already built.

Oh, good news that there is a little itch, too ;-) And I am absolutely not 
oposed if you want to use WBEM or any other protocol. I would just be a 
little disappointed if this would need to be done forking away from the CFG 
framework and/or introduce things that would make CFG less appealing for 
standard use in distributions.


What do you guys think of this slightly modified diagram for remote access 
_to_ CFG in this case with WBEM:


+-----------------------+       
|       WBEM Client     |  
+-----------------------+
|  CFG Client Library   |   <--- optionally, is it needed at all? CFG aware
+-----------------------+       clients just request full xml-representation
|     WBEM library      | ---------
+-----------------------+         |
  |                               |
  +--CIM over XML protocol--+     |    is "over XML" necessary?
                            |     |- Existing code (OpenWBEM,
      +-----------------------+   |  OpenPegasus, etc.)
      |         CIMOM         |   |
      +-----------------------+   |
      |   Perl Provider IFC   | ---
      +-----------------------+
      | Perl Provider Scripts | 
      +-----------------------+
      | CFG xml-rep. Parser   | 
      +-----------------------+ 

This way the part above is an optional top layer add-on to the existing CFG 
system:

      +-----------------------+ ---  CFG will provide many
      |  CFG middlelayer      |   |- meta-data driven parsers
      +-----------------------+   |    
      |   Backend Parsers     | ---
      +-----------------------+


A quick "remote features for CFG with WBEM" hack could just tunnel the xml 
representation through the WBEM protocol. Translating CFG entities into 
regular WBEM objects for arbitrary WBEM clients could follow later.

What was the reasoning to slide WBEM right into the heart of CFG? ;-)


Justin wrote:
> From a design perspective, I think the major negative
> on this is that we'd have to maintain *2* copies of meta-data.  One for
> WBEM/CIM and one for our XML system. 

I am not sure why this should be the case, please explain a little more.


I kept thinking a bit about remote fetching from the backend i.e. simple ssh 
fetching (not to replace WBEM only as another way). I find it increasingly 
interersting to have the possibility to let the backend parse remote 
machine's configs through ssh without the need to install anything additional 
on other machines. Remote application specific meta-definitions (if present 
say in /usr/share/cfg-definitions/*.cfg) could override local ones for remote 
files. (Just in case if versions or locations differ (for example on another 
distribution))
And those nodes would again show up in all CFG frontends. 
Same should work with WBEM or LDAP parsers for CFG. What do you think about 
this?

Christian