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

[Justin Y. <ju...@sk...>]

On Wed, 18 Feb 2004 23:42:44 +0100
"C. Gatzemeier" <c.g...@tu...> wrote:

> 
> 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? ;-)

I think there were 2 main reasons for putting it right in.  First, we don't want to depend on Xerces anymore.  Second, if we used another XML library, then we'd essentially be generating XML in our bottom/middle layer, converting it to WBEM/CIM, which in turn would convert it to XML for remote communication, and then it would be converted back to WBEM/CIM for the client programs (which could optionally re-convert it to XML again).  

That may not be a huge performance hit, and WBEM does a lot of the converting for us, we'd really only need to do the XML -> WBEM/CIM conversion which might not be too hard.  Also, we didn't want to have the C++ <-> perl communication as only very recent gcc compilers don't have a bug that causes issues w/ it.

If the bottom/middle layer were written entirely in perl and used a common, perl-based XML library, I think these issues could be addressed.  This solution is actually more or less exactly a solution I proposed, and could probably do the job.

> 
> 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.

Well, we'd need our CFG type-definition meta-data objects to be created & maintained and we'd also need CIM object definitions to be created and somehow maintained.  If fiddling with the CIM object definitions required any regular human interaction, it would be a huge resource drain.  If we could get a good conversion script to make CIM objects for our type definitions, then this isn't an issue.  I'm sure it'd be possible.


> 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?

That would be a good alternate remote system in addition to WBEM.  I could certainly see a need to add capability underneath our WBEM providers to grab remote machine's configuration if they don't have WBEM/CFG installed.  This would be a *very* nice feature for some people managing large numbers of PCs, some of which may not support CFG for one reason or another (although if the bottom of CFG was written purely in perl and the WBEM system we choose supports their OS...) .


In the end, I'm really not sure which way is better & easier as far as development goes.  The solution you propose seems more elegant and I think retains maybe a little more of the original CFG design.  I don't know if thats necessarily a good thing or not.  It would definitely provide more flexibility with only some minor adjustments in the overall architecture, and remove a complete dependence on WBEM.  

Actually, I could see an eventual need for some sort of original CFG-based XML system to allow scripted tasks to run (i.e., during OS installation) without requiring a functional WBEM server & the whole works.  You certainly raise some good points.


-- 
SkiingYAC
Custom Solutions
http://www.SkiingYAC.com