Versions Compared

Old Version 5

changes.mady.by.user Ann Harding

Saved on

compared with

New Version Current

changes.mady.by.user Nicole Harris

Saved on

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.

...

When/how are timelines going, when should eduGAIN prepare to engage the community, breakdown of responsibilities.

12:00-13:00 Lunch, adieu.

Documents

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

Notes

Cost Benefit Analysis

-Domenico’s introduction: New in gn4, needed to formalize what we are doing . It addresses when it is appropriate to develop, operate service and how to manage user expectations. EC likes us to make more a business like model. We have to show that we are providing value and benefit to the users.  

-CBA is between  NIF and SA phase – when it leaves JRA or NIF, and before starting an SA we need to prove that there is a business case for doing it.

-There is a template available, as well as Business case example.

-Domenico role is to support us, also in writing the CBA.

-The goal of CBA is to show to EC that the investment was worth it. The approval of the CBA is done internally by GÉANT, and presented to  EC as a part of review ?

 - Challenge: Show in the CBA that the service is saving money to the project

- Stefan: CBA also have the part where the non-money benefits can be expressed -  for example prestige  for NREN doing eduroam etc..

- Domenico’s answer to Lukas: relationships: 1. NIF and then 2. CBA.  If CBA is accepted, then the service is assigned to SA. 3. PID is more like a project plan with some additional risk assessment etc.  

- Domenico: templates for the documents are still a work in progress

- Ann:CBA is a living document. Should be revised regularly, for example once a year

-Ann: CBA should be used from this project year and should exist for every product from service catalogue, so it could be a cross activity responsibility to manage CBA.

 - Ann: for now product managers are in SA5, but this can change in the future in regards to the SA4.

-? Chapter- compelling reasons why users should use the service

- Rhys: Costs?  VMs? – SA7 should offer a list of reasonable costs.

- Ann and Domenico: CBA should be done consistently within GÉANT - so that different tasks should have similar costs for VMs. The idea is to build it in to the template as currently template is network oriented.

- Ann answer to Brook: for manpower rate to judge the costs, the mean manpower rate for the project should be used.

-Stefan: can we express in the CBA, how much a service would cost if this would be a payed service, so that we can express how much a service is “saving ” money. We can have it calculated in different levels: users, institutions, NRENs -  how much would each of them pay. For example for end users it would be easy to calculate how much they would pay for eduroam, but it would be difficult to charge end users for eduGAIN.

- Christos: we have to understand who are users, and who are paying customers.

- Stefan:  there are payments and benefits at each level. We can present as a franchise, where for example NRENs are reselling the services.  

 Goal for the work groups:

-3 year CBA

- 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.