Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Both days include sandwich lunch.

 

Location:

SWITCH:

http://www.switch.ch/about/contact/

...

09:15-10:30 Improving the eduGAIN service online portal. (notes available here)

Actions:

...

tech.edugain.org and user/customer facing docs - current status, gaps, problems.

...

12:00-13:00 Lunch, adieu. 

Documents

f2f-wallplan.xls - Summary of key deliverables and milestones, to be extended during the meeting.

...

- shared VM estimate,  600e for managed VM  per year. Non managed VM  ?

-

 

Notes on Operations handover

1st service going through the process is FaaS. Mandeep and Marina's knowledge on this has been key. The aim is to complete this by October 2015.

The next services to go through the process will be eduGAIN, eduroam and Moonshot, and will be able to use the templates developed through the FaaS process. The dates of these transitions have not been finalised, but could be between January - May 2016.

1st step of process: Testing and validation, both of service documentation and technical elements. Improvements may be identified and suggestions returned to the project task, before being accepted into Operations.

2nd step: Acceptance and handover to Alessandra's area. Identification of KPIs against the service, production operation and optimisation and assessing possibilities of integration with other services.

Documentation for operating services is being developed into templates Mandeep has draft versions, but there is some possible duplication in them, so are not final documents yet. They can be found at

https://wiki.geant.org/display/gn41sa5/Service+Transition+Initiation+Template

https://wiki.geant.org/display/gn41sa4/Template 

The purpose of the templates is to outline the minimum set of requirements for operating the service. These will include things like infra requirements, availability and back-up, monitoring (network and services), IPv4 addresses and DNS records, who should have access to machines, KPIs, support models, clearly defined operational procedures.

For existing services, SA4 will take over existing VMs/servers which are in use, unless it makes more sense to do a refresh at the time of transition.

As this process evolves and embeds, formalisation of service documentation and production processes will be key. There will also be the goal of seeking to reduce duplication across different services, e.g. monitoring.

Some of Marina's experience from FaaS:

  • Worked closely with test and validation, and Ops teams.
  • Made a transition mailing list for co-ordination.
  • Clarified with the test team exactly what needed to be tested.
  • There were 5 groups of test/validation relating to various aspects of the service; many questions were raised so a lesson learned is to keep some resource back for this engagement.
  • A report will be produced by the test and validation team once the process is fully completed.

Considerations:

  • A plan for IPv6.
  • Engage with Ops early so as service requirements can be understood as soon as possible.
  • A "Service Manager" single point of contact for transitions is useful.
  • eduGAIN transition needs some thought; in this year the focus will be on building a plan for transition.
  • Moonshot needs the Dynamic Trust Router code delivered before its service can be fully operational; but the transition plan and templates can be completed from now.
  • Eduroam CAT could be a trial migration from January 2016.

 

Notes on Special operations focus - monitoring

FedLab: Interoperability testing between SAML entities

  • Not just SAML, also OpenID Connect
  • Quite wide interest in it
  • Currently in planning of what it could do as a service
  • Nicole's team's involvement is largely in testing
  • Decisions are needed on where a service could be hosted and operated from

Monitoring tools are currently being investigated: what's available? What are they used for? Can things be consolidated?

The EC review asked why the number of eduGAIN authentications was not being provided.

  • Considered installing RAPTOR on a wider basis, but that would be a lot of work and co-ordination required
  • Could take information that is already known to provide some estimates; e.g. gather all hub and spoke data and estimate based on that
  • Keep hold of the long-term goal of wider RAPTOR roll-out
  • Ask for stats/reports from WAYF owners
  • Consider other data which is not number of authentications but appeases the EC

This year plan:

  • Write a paper on the provision of stats
  • Get s tats from hub and spoke sites
  • Consider what other stats could be useful and realistically collected

Note: Services going to SA4 will need to consider how stats will be gathered.