Plans and priorities notes.  16th January 2004


Steve Fisher went through the bugs - he noted all decisions.

A discussion came up on Authorization for inserting tuples, to prevent R-GMA getting overloaded. Various  suggestions were made, e.g. limit how many tuples can be inserted per second, only allowing one producer to take up 90% of a given resource. Amount that can be coped with depends on hardware available, and depends on the consumer. We should think about authorization for inserting information when we carry out the re-engineering.

Priorities

We should check in all that is outstanding, then go into a bug fixing mode for the current version.
We should stop tinkering with the current version of R-GMA.

We should work on the following:--

Schema (including schema replication)
Overall class design – start from existing design and see how it can be changed
Security rule definition. This should include how to define authorization to access a view, as well as  security rules for allowing registration, and allowing for some sort of quota.
Documentation - User guide and Installation Guide initial priority, and as we re-design we should update the Architecture document.
Web Services – we should develop our expertise with this, especially as we need to know what impact web services have on our design.

The first thing we work on for re-design should be registry and schema replication, which we should add to our old system without web services. This should form the new version for LCG.

LCG have talked about backward compatibility between LCG2 and the future – but we don't really know what they mean by this, we should ask for clarification.

There was a discussion as to whether we should go for Registry and Schema Replication prior to re- engineering, Abdelsem thinks no, SF thinks that registry replication could be done quickly, but the schema replication is more difficult.
Difficulties in testing replication were discussed, one possibility was to use the WP3 testbed, by running a cron job over the weekend to destroy processes and see if they come up again.

Andy should think about the mediation design.

We should get together again to thrash out new design.

We again discussed registry and schema replication, and think we should start by doing something simple,  e.g. having a backup schema and backup registry.  We think a network crash is more likely that a machine failing. Could start by having 2 schema, and having a human decision to change which is the master, then moving to automatic recovery later.    This would at least deal with the Single Point Failure, which is what 
is not liked. 

Steve Fisher will draw up a plan for how we proceed, and suggest a date for the next meeting.