Policies for Cooperation on t-Infrastructure

t-Infrastructure

Experience in EGEE, ICEAGE & ISSGC has shown that:

1. t-Infrastructure is required, and
2. It takes a lot of effort to provide it

What is t-Infrastructure?

T-Infrastructure is all of the hardware, networks, software, data, documentation and operational support that enable students to learn about e-Infrastructure and the teachers to teach them. We do not consider the methodology to be part of the t-Infrastructure as methodology is included in the curriculum. The t-Infrastructure is the infrastructure required to facilitate the methodology.

Hardware includes the computers running all the grids and services including the example applications, and the data stores providing demonstration and exercise data and holding the results of student work.

Networks includes the local networks between servers, the connections between students and the services they use and the connections to permit support and lone (follow-up) use.

Software includes the middleware stacks, user interfaces and portals, applications used in exercises, services to be used in exercises, demonstrations, skeleton solutions to aid students to complete an exercise, solution testing systems and example solutions for subsequent inspection and use in further stages of some exercises.

Data is the test data needed for exercises, such as sample images, boundary conditions, examples of simulation, experimental and observational data. It is also the data produced as intermediate and final results of students’ attempts at exercises.

Documentation includes the instructions for teachers, instructions for students, help and FAQ material, hints and evaluation procedures. It is also essential to document the software for the developers who have to revise it for a subsequent class.

Operational support includes the usual distributed system support to monitor the operational health of the t-Infrastructure and to fix problems before they have a deleterious impact on the pedagogical processes – both students and teachers a very sensitive to failures that impact a class in progress. It is also provision of advices to those developing other parts of the t-Infrastructure, to teachers planning or executing grid education and to self-paced remote students. It is probably more onerous than supporting a production e-Infrastructure partly because novice users use systems in unexpected ways.

Why do we need t-Infrastructure?

Requirement: Ease of access, including unsupported self-paced learner

Response:

• Light weight and rapid provision of limited certificates.
• Students benefit from the experience of getting a cert
• Other resources may need to trust the cert

Requirement: Good learning experience – demos run during class – exercises can be finished

Response:

• Reservation of sufficient resources & Testing under class loads
• Not always possible to have eough resources at one site, need to borrow resources, etc.
• Must really test under student-like loads, anticipating the actions of inexperienced students can be difficult
• Reliability of t-Infrastructure must be ensured - this could be done by limiting the number of jobs that any user can run, but these limits might need to change depending on the job type or the concept being illustrated (e.g. a workflows or parameter sweeps may require a large number of jobs).

Requirement: Prepare students for production work

Response:

• Availability of production middleware and interoperation with production grids

Requirement: Develop appreciation of concepts and ability to select technologies

Response:

• Expose students to a breadth of grid provisioning and use strategies
• Show different technologies, different concepts, understanding of what technology you might use for different concepts, etc.
• This means multiple technologies must be available - have to run on same machines and interoperate

Requirement: Alert students to imminent technical advances, e.g. prepare developers.

Response:

• Availability of next-generation middleware
• May not always be appropriate, e.g. while Application developers may need to know the latest features of the Grid Middleware so that they can begin to implement support for it early on, the end-users do not. Similarly Grid operations staff want to know what functionality is here now.

Requirement: Permit students to learn by their mistakes

Response:

• Provide a safe environment for students (i.e. effects of students’ behaviour are localised)
• Protect production Grid from Students
• Protect students from eachother so that their data is private and also so that one student can't bring down the whole t-Infrastructure for other students

Requirement: Develop experience of distributed system set up, failure modes and security attacks

Response:

• Provide isolated replicas of production scenarios with extra controls available to the teachers
• need to cause odd problems, security problems, rare conditions, etc. - admin courses...

Requirement: Enable remote, self-paced learners to acquire practical skills

Response:

• Closely couple t-Infrastructure and eLearning services
• t-Infra must be available all the time, can't just be scheduled for training events

• Note that a self-paced learner might interfere with a class if they are using the same resources at the same time, can't assume exclusive use for your class.
• If we implement limits on the number of jobs which can be run then these limits must suit self-paced learners as well as classes, if limitations are flexible for classes (e.g. if the tutor can change the limits depending on the concept to be taught) they should also be flexible for self-paced learners.

Requirement: Staged nature of excercises?? and quality of excercises

Requirement: Ability for teacher and student s to get monitoring and feedback

Requirement: Need a realistic set of services available

Requirement: Licencing - does this belong here as a requirement for t-Infrastructure or should it be addressed in the IPR document?

Requirement: Simple mechanism to provision t-Infrastructure hardware and software - distribution, installation and choosing what software is available for particular learners (based, e.g. on licencing terms).

1. Authorisation, authentication

Acceptable use policies for students and providers (SLA – honour booking/privacy) malicious purpose - ? illegal? Deliberately harmful – existing AUP Universities / Projects knowingly overload - ? Commercial use

AUP in industrial context: example of Platform - in trainings organised, attendees behave nicely

Simple single sign-on required Self-paced learners – no institution? – pooled certificates in a limited number? Anonymous-short-lived) long-lived anonymous – service provision lined to assessment achievement

Light-weight certification vs. anonymous

Load on issuing short-lived certificates

Anonymity vs. targeted support of students

Recognise the realities of the current situations and gaps

Sandboxing – limited domains Protecting the student as well as infrastructure Multiple approaches required

1.1 X509

Features

1.2 Other – role based?

Shibboleth - GridShib

1.3 VOMS?

2. Booking

2.1 Passing and coordinating bookings

Teachers and trainers need to have the guarantee that they will have the resources available hence the bookable infrastructure. Information about resources / availability Virtual currency Reliable service

Balancing input resource and output resource Accounting system (DGAS) but would have to be supported across different middleware

3. Support

3.1 Ticketing

There needs to be an agreed standard for providing support

Local infrastructure might be connected to local helpdesks You don’t want people to move to another helpdesk so how do you integrate helpdesks Hierarchy Good information about levels Publishing of support services Not possible to have a priority response – implement training-specific support – similar to production support Advanced information about events and resources involved

4. Information services

Integrate with testing and support systems

INCA site certification

4.1 GLUE?

4.2 more

5. Submission/User interfaces

5.1 Single Submission system / supporting multiple systems

6. Virtualisation