Ian Collier wrote:
> the configuration is too complex ...
> I welcome any comments/further suggestions.
Yes - the static config of any node type and the process for generating
it are too complex.
Being practical for the time being: the switch from Glite to EMI (with
new names, directories, repositories, whatnot) will cause waves for a
while yet. Would an interspersed "redisorganisation" cause pileup? I'd
be a coward - unless there is imminent, large new functionality to add
to the middleware, then I'd vote to keep yaim, and maintain it centrally
as the middleware progresses, whatever name the middleware adopts.
It's a standard.
In the longer term (e.g. as old node types are replaced by new ones,
lcg-CE -> CREAM, MON -> APEL), perhaps we should phase YAIM out. We
could do that if we insist (as part of the acceptance test of the node
type) that the new types are shipped with another suitable automation
tool for its configuration. That tool must (a) work with the current
site-info.def or (b) work with a new configuration database or (c)
either. And we should make the maintenance of those tools relate to the
maintenance of the node type software - it's part of the deal.
In short, maintain yaim for legacy purposes, while bringing in new
methods when appropriate. Is there any problem with this way of
separating the problem out? After a few years, YAIM will be gone.
Steve Jones [log in to unmask]
System Administrator office: 220
High Energy Physics Division tel (int): 42334
Oliver Lodge Laboratory tel (ext): +44 (0)151 794 2334
University of Liverpool http://www.liv.ac.uk/physics/hep/