Hi Stephen,
[log in to unmask]" type="cite">At
present, the "new system" it is not clear for all to see, it is
not
documented well enough and it is becoming less automatic as yaim
is phased
out. We need to plan around those issues, and it is not obvious to
me yet
how to achieve that in the "new world".
I completely agree and I tried to raise the issues in all the
forums. I'm not going to post any of the emails I sent in defence of
yaim as "lowest common denominator" of all the tools that could be
run by any higher level management tool such as puppet, cfengine,
quattor. There is no funding anymore. Markus Schulz reiterated the
community effort cncept in the post-EMI WLCG software lifecycle
document http://tinyurl.com/cat4aou which might have had other
revisions but hasn't changed in the core. I quote
Sites that support specific configuration tools should be
encouraged to share their work. To limit the
effort for single sharing of the work between sites is
essential. This can be promoted by leaving room in the
GDB and pre-GDB for site admins to present their work.
[log in to unmask]" type="cite">That
could work, but I have to give you the straight guff on this.
I know, and not many of us have puppet experience. So the sharing at
this point is just to see how other sites are doing it and this is
why we have on a per site basis. Perhaps when we are more robust we
can share code that works at all sites. Also I would try as much as
possible where there are puppet modules maintained by the
development team to use those. DPM has puppet modules they are not
publicly distributed yet (I think) but here are Ricardo pointers if
anyone wants to start to give a look
Can you go ahead and try them out?
Please configure this additional repository
(until they get released):
and follow the instructions here:
You should find examples for both head and
disk nodes:
Let us know what you think. Once you feel
comfortable we can give them to a wider audience to start
migrating away from yaim.
They are on my TODO list and Wahid has already given a look at them
(he might want to comment).
cheers
alessandra
[log in to unmask]" type="cite">
1) Puppet classes could only be directly shared in rare
circumstances.
It is much more likely that any given puppet class would need to
be
modified to fit in another context. While it is more likely that
whole suites/hierarchies of puppet classes may be portable
as a "job lot", it is also true that the context of the source
and target
puppet installations involved would have to be quite similar. If
two
sites independently develop their puppet class hierarchies, they
are
quite likely to be incompatible. The problem is quite similar to
trying to
bolt two database schemas together, or two C++ class hierarchies
(it's
engineering - you can't fit a Ford head on a Toyota block).
2) The version of puppet we use here is concerned with installing
"resources" such as files, packages, mounts, services etc.
It is not good for context dependent modifications to
the resources - that is what YAIM is for. I discussed this with
Chris Brew at GridPP30. It is hard for me to envisage how Yaim
logic and the site-info.def/vo.d "configuration database" can be
reworked in puppet. Maybe newer version have much more
whipupability? Or perhaps the YAIM logic will go into rpm post
scripts. None of this is clear yet, so I am wary of the "new
world".
So maybe I'm wrong on this, but it is not obvious to me how
compatible
puppet class hierarchies will spring up from community support
without a head.
Durham has already started to post some,
Birmingham was also on the way but I was a bit slow to respond
(*). Feel free to share Liverpool modules.
Good. I'll try to support this too. Unfortunately, it is only
possible to
properly interpret the Liverpool modules as a job lot, due to
dependencies in the hierarchy tree. They are also very site
specific. I'll try,
time permitting.
Anyway, those are the things to watch out for.
Cheers,
Steve
On 02/04/2013 09:40, Stephen Jones wrote:
On 04/02/2013 09:23 AM, Jeremy Coles
wrote:
Dear All,
I hope everyone had a good Easter.
We will have an ops meeting today to catch any issues from
the last two weeks, review current priorities (removing
EMI-1 components for example) and revisit any topics from
GridPP30 that anyone wants to follow up or discuss further.
The outline agenda is at
http://indico.cern.ch/conferenceDisplay.py?confId=240010.
A direct link to the EVO meeting is:
http://evo.caltech.edu/evoNext/koala.jnlp?meeting=eseieIvnv9aiaeIla8Is
For minutes: Mark=5 Duncan=5 Catalin=5 Andrew=5 Stuart=5
Ewan=5 Matt=6 David=6 Stephen=6 Brian=6.
regards,
Jeremy
Hi,
I know it's late but I'd like to add this to the agenda.
Issue: No YAIM in EMI3 APEL
Reason: Admins should be aware of this departure from the
normal protocol.
IMHO We need to assess the wisdom and viability of phasing out
yaim before
any successor is nominated (i.e. in general, it's best to
plan where the road
leads before we lay the road down!)
Cheers,
Steve
--
Facts aren't facts if they come from the wrong people. (Paul
Krugman)
--
Facts aren't facts if they come from the wrong people. (Paul Krugman)