Hi Markus,
I think the VO-BOXES details should be discuss at some length at the
operations meeting at the end of the month. Is there any documentation
available about it?
thanks
cheers
alessandra
On Tue, 6 Sep 2005, Markus Schulz wrote:
> 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 *
>> ********************************************
>>
>
--
********************************************
* Dr Alessandra Forti *
* Technical Coordinator - NorthGrid Tier2 *
* http://www.hep.man.ac.uk/u/aforti *
********************************************
|