Difference between revisions of "2019-bidding/collaboration-tools"
Jump to navigation
Jump to search
(→Effort) |
|||
Line 80: | Line 80: | ||
== Effort == | == Effort == | ||
Bids planning a total effort of about | Bids planning a total effort of about 2 Person Months/year (STC) would allow these services and activities to be addressed appropriately. |
Revision as of 11:47, 6 November 2019
Main | EGI.eu operations services | Support | Documentation | Tools | Activities | Performance | Technology | Catch-all Services | Resource Allocation | Security |
EGI Core services menu: | Services PHASE I • | Services PHASE II • | Services PHASE III • | Bids • | Payments • | Travel procedure • | Performance |
Go back to the Core Activities Bidding page.
(to add requirements on software licenses and FitSM Training & certification)
Service name: collaboration tools (IT Support)
Technical description
The task provides the following services for the EGI collaboration, all the services' authentication must integrate with EGI Check-in:
- EGI Web site hosting and other web servers related to EGI activities.
- EGI SSO, including shibboleth access for third party services using SSO as ID provider.
- Wiki (MediaWiki, Confluence).
- Jira ticketing system.
- Mailing list management.
- Document Repository.
- eduROAM for EGI Foundation employees.
- IdP federated in SURFConext and eduGAIN.
- Agenda management via Indico.
- Community forum using discourse deployed in a VM (operated by Operations team?)
- Actions and requirements tracking (RT). RT must interface with the UMD software provisioning system. Tight cooperation with the provider of the UMD infrastructure is expected.
- Main DNS for egi.eu domain.
- Provisioning of a few VM to allow EGI.eu team to test services and workflows (max. 6cores/6GB RAM total). This service is provided ad-hoc, and therefore it is not subject to monitoring and availability and reliability reporting. Only responses to support requests will be monitored.
- Other collaboration platforms on a need be basis.
Operations
- Hosting and daily operations the services
- Creation of new SSO groups, mailing lists and Wiki namespaces
- Provisioning of usage statistics upon request
- Creation of dedicated web spaces for the main EGI events
- Regular deployment of relevant software patches and new releases in order to keep the services up to date to the newest available version
- Adapt RT Scrips and dashboards upon request
- The services must run on separate machines (or VMs) in order to minimise the risk of incidents affecting multiple services at the same time
- Creating an Availability and Continuity Plan and implementing countermeasures to mitigate the risks defined in the related risk assessment
Maintenance
- Extension of the SSO to be ID provider for new services, upon request (Being deprecated with migration to check-in and usage of federated authentication via EGI Check-in)
- Creation of new queues in RT and new metadata
- Support of new use cases for the capabilities of the collaboration tools, e.g. by creating a new SSO group with mailing list.
Software Compliance
- Unless explicitly agreed, software being used and developed to provide the service should:
- Be licensed under an open source and permissive license (like MIT, BSD, Apache 2.0,...).
- The license should provide unlimited access rights to the EGI community.
- Have source code publicly available via a public source code repository (if needed a mirror can be put in place under the EGI organisation in GitHub.) All releases should be appropriately tagged.
- Adopt best practices:
- Defining and enforcing code style guidelines.
- Using Semantic Versioning.
- Using a Configuration Management frameworks such as Ansible.
- Taking security aspects into consideration through at every point in time.
- Having automated testing in place.
- Using code reviewing.
- Treating documentation as code.
- Documentation should be available for Developers, administrators and end users.
- Be licensed under an open source and permissive license (like MIT, BSD, Apache 2.0,...).
IT Service Management compliance
- Key staff who deliver services should have foundation or basic level ITSM training and certification.
- ITSM training and certification could include FitSM, ITIL, ISO 20000 etc.
- Key staff and service owners should have advanced/professional training and certification covering the key processes for their services.
- Providers should have mature and well maintained ITSM process that are key to support the services they provide.
Support
- Support is provided through the it-support mailing list and the dedicated GGUS support unit.
- Support hours: eight hours a day (for example 9-17 CE(S)T), Monday to Friday – excluding public holidays of the hosting organisation.
Service level targets
EGI collaboration services must have 99% availability over the month
If provided the DNS service must have Availability > 99.99% on a monthly basis.
Support should be provided according to the advanced Quality of Support level described in the GGUS wiki about QoS levels.
Effort
Bids planning a total effort of about 2 Person Months/year (STC) would allow these services and activities to be addressed appropriately.