Dear Alessandra,
thanks for your input. I'll answer you in more detail later, I just
see the need to comment on the VO-BOX to avoid misunderstandings there.
I can fully understand that the VO -BOX worries you, the alternative
scares me more.
The VO-BOX was asked for by the experiments and accepted by the Tier
1s that participate in the Service Challenge (Ask Jamie Shiers for
the minutes of the meeting). They are not seen as a temporary fix. It
is expected that the experiments will run some VO specific services
for the foreseeable future.
The VO-BOX as a well defined platform is the only way to handle this
in a somewhat controlled way, this is why we try to expand what is
already there on the
VO-BOX. I am convinced that it is more secure to provide some common
services on these boxes and reduce the need for VO specific components.
markus
On Sep 5, 2005, at 9:01 PM, Alessandra Forti // EOJ wrote:
> Dear Markus,
>
> I like very much the idea of having a release every 3 months with
> minor updates in between, where updates are defined as those
> changes that do not
> affect the configuration and can be picked up by apt/yum/.....
>
> As far as the list goes from my (sys admin) point of view the
> priorities are as follows:
>
> 1) Any improvement of the robustness of the services. (i.e. 2. 5.
> 12. 22.
> in your list).
>
> 2) This is not in the list BUT it is important to me: anything that
> makes
> traceability of a job easier: a tool that for example puts together
> that mess that is in the log files on the CE and RB (god know
> why there
> can't be a unique JOBID that one can followed through) would be
> extremely useful both from the security point of view and purely
> for
> maintainance of the system.
>
> 3) I'm a bit worried about the introduction of gLite components all
> in one
> block. Is this the plan? I played a little bit with VOMS server
> and gLite
> UI and I have to say I find gLite configuration extremely
> painful. So I'm
> not against their introduction, however I don't want to know
> ANYTHING about
> touching those xml files by hand. In other words to me YAIM is a
> priority.
>
> 4) Cleanup of the infor providers to make full use of the new schema
>
> 5) YAIM VO managment I'm interested in having only dteam VO enabled in
> site-info.def. I go through the pain of removing the VOs I don't
> want
> and to add the one I want. However the latter should be the only
> action
> required. The WEB based tool you talk about seems eccessive to me.
> If the necessary information about a VO is available it doesn't
> take
> long to add the VO to YAIM. The most painful part is to find
> that information. However if you really want to create a tool
> please create
> a command line that can be scripted. If you were thinking of
> browsers
> forget about it.
>
> 6) Removing jobmanager-fork and gridftp on the CE. I can't say I
> disagree
> from the security point of view, however they are great tools to
> debug
> the situation other people machines without having direct access to
> them. So I think that a restricted usage policy would be preferable
> than complete elimination.
>
> 7) Security (your 17.) I'm surprised there are not more things listed.
>
> 8) Jeff Templon ETT. I don't know anything about it, hoever I think an
> algorithm (any decent algorithm?) has been waited forever now.
>
> 9) Back up mechanism for mission critical T2 DBs.... I have dcache and
> to be honest tar works perfectly. Up to one year ago it was working
> also with mysql (no need of complicated things).
>
> 10) The other thing that makes me a bit nervous is the progressive
> importance that the VO-BOX seems to be acquiring. I'm not sure
> if any
> of the sys admin has had any say in this but I'm sure I echo
> the thought
> of many when I say that it shouldn't have been introduced in
> the first
> place. And even if I accept the introduction of a box to cover
> for the
> hopefully temporary shortcomings of the middleware, I know by
> experience
> that temporary solutions become permanent.
>
> 11) What about dcache configuration? This also is not on the list.
> We need
> some sort of configuration tool (YAIM is not of much use for the
> configuration).
>
> The points that I haven't included have a lesser priority for me
> because I haven't installed those particular services and therefore
> am not affected.
>
> thank you
>
> cheers
> alessandra
>
> On Tue, 30 Aug 2005, Markus Schulz wrote:
>
>
>> Dear ROC, CIC, Site-mangers, and EIS link persons,
>>
>> on July 29th we released LCG-2_6_0. This release is now out since
>> more than 30 days and there are over 69 sites that have been
>> upgraded
>> and several additional where the client libs of 2_6_0 have been
>> provided via the user level software installation mechanism.
>>
>> The release has seen 2 upgrades, mainly related to YAIM problems.
>>
>> On August 3rd we did a local post mortem of the release. A rough
>> summary can be seen here:
>>
>> https://uimon.cern.ch/twiki/bin/view/LCG/LCG-2_6_0
>>
>> we then started collecting input for "wish list" for LCG-2_7_0, this
>>
> list is
>
>> not complete and not prioritized, just a draft.
>> The list can be seen here:
>>
>> https://uimon.cern.ch/twiki/bin/view/LCG/LCG-2_7_0
>>
>> Assuming the regular release cycle the release date should be 1st
>> of October.
>> With the time it takes to push the release through the local and
>> remote tests we have to keep in mind that the integration and
>> initial testing phase
>> has to come to an end on Friday the 9th of September.
>> This is rather soon now and we need a better understanding on the
>> relative priorities of the different tasks and additional
>> components that we might need to add.
>>
>>
>> Please have a look at the list and sent me suggestions and
>> describe your priorities.
>>
>>
>>
>> markus
>>
>>
>
> --
> ********************************************
> * Dr Alessandra Forti *
> * Technical Coordinator - NorthGrid Tier2 *
> * http://www.hep.man.ac.uk/u/aforti *
> ********************************************
>
|
