Alert.png The wiki is deprecated and due to be decommissioned by the end of September 2022.
The content is being migrated to other supports, new updates will be ignored and lost.
If needed you can get in touch with EGI SDIS team using operations @

NGI International Task Review MS109 Latvia

From EGIWiki
Jump to navigation Jump to search

This page contains the assessment of the NGI International Task at year 1 of the EGI-InSPIRE project (one page per NGI). The NGI representatives are required to fill the tables according to the required information. The content will be integral part of the EGI-InSPIRE milestone MS109 "NGI International Task Review"

  • Main page with instructions
  • In order to edit this page, you need to log in with your EGI SSO account and click 'edit' on the tab (top of this page)

User Services

Human Services (Table 1)

Table 1: NGI Assessment: User Services >> Human Services
EGI-InSPIRE EGI_DS Name Assessment Score How to Improve
NA3.3N U-N-3 U-N-13 Requirements Gathering There is no structured or formally operational system for gathering and processing requirements of a local scale. There are no plans to deploy one by own means. Due to relatively small national research community as a whole, requirements of user communities are gathered during direct contacts and evaluated on individual basis. Formal local system would not be sustainable considering small amount of research groups and necessary operational effort overhead. Besides direct contact, Instant Messaging & VoIP (Skype, Jabber) as well as email communications are used, including national grid user mailing list. So far the required features for some user communities were approved and implemented in few selected Latvian NGI sites only. 3 Global requirements submission and processing system could be useful (keeping it non-mandatory), especially one allowing to exchange requirements experience between similar user communities in different NGIs. NGIs should be allowed to keep existing approach of maintaining communications with user communities directly, but the global requirements system should be available for NGI input to propogate these requirements. In case the original NGI of the requesting user community is unable to fulfill the requirements, other NGIs could voluntarily step in and offer necessary resources to these research groups.

Also, greater oppourtunities and financing should be provided for user community members to participate in global EGI User Forum events to exchange ideas on necessary requirements as well as success stories.

NA3.3N U-N-14 U-N-15 Application Database Currently Latvian NGI has not exported any package information to AppDB and is not using any information from it either. Most user communities in Latvian NGI use either their own custom-tailored experiment-specific software, which does not provide reasonable re-usability for other communities, or licensed commercial software like ANSYS, Matlab or GAMESS is run using the licenses available to specific communities, thus these software packages cannot be exported to AppDB as generally available. The use of AppDB in Latvian NGI has not been widespread also due to lack of real use cases when local user communities approach NGI "empty-handed", i.e. - without already working custom-made or commercial/open-source software. Currently, all user communities are under scenario of upscaling their computations from local clusters. In case some generic open-souce software will be used in the future by some research community, it will be exported to AppDB. Also, Latvian NGI needs to convince many user communities that sharing their custom-tailored tools will actually benefit them, since for many of these resarch groups these custom tools are the essence of their expert know-how and ensures they have unique knowledge that is valuable for quality publications. 2 More effort is necessary to try and migrate several user communities from commercial or own custom-written software to generic reusable open-source packages from AppDB. Also, user communities have to be persuaded that publishing and sharing their long-term inhouse developed tools will benefit them and not steal their unique know-how and academic value.
NA3.3N U-N-16 U-N-17 Training Training is organised on request by individual user comunities. Such current system is sustainable. There are no regularly scheduled (i.e. monthly, annual) mandatory training events, nor are any planned. No e-training is available, nor is one planned by local means. Due to small available effort to this task and small user community, the e-training material would require either too much overhead to keep up-to date, or due to very infrequent usage of those tools (when new user group joins) it would constantly be out-of-date. 3 Migration of several sites to desktop-grid compatible ARC/Condor middleware is expected within PQ4 to significantly improve amount of available automated tools for user communities, as well as offer re-usable training and more seamless upscaling from using local Condor based clusters and desktop grids to NGI and EGI scale grid computing. No e-courses or national training events planned (would be inefficient).
NA3.3N U-N-12 U-N-18 U-N-19 Consultancy Due to small number of research communities, highly interactive consultancy is provided to these communities. Consultancy, similarly as training, is mainly provided through direct contact local meetings, phone conferences and Instant Messaging (Skype or Jabber). In case none of previous are available, a slower approach of using problem-specific or general grid user mailing lists is employed. The current system works well and is sustainable. No formal helpdesk and request tracking system is planned, and it would not be sustainable. 4 In the future a possible online archive (FAQ, Wiki or forum) would be usefull for new users who stumble across previously discussed problems. Ideally, such local user support/consultancy resource should be hosted in local language. The main issue to resolve and decide, as in any knowledge dissemination system, is whether to deploy a more interactive and low-latency solution as forum, which has the downside of accumulating a lot of out-dated and version specific info over long-term, or providing less interactive service such as Wiki that has latest current information. A good compromise to provide both low latency response as well as exclude out-of-date info storage could also be user mailing list + Wiki.

Operations Services

Human Services (Table 2)

Table 2: NGI Assessment: Operations Services >> Human Services
EGI-InSPIRE EGI_DS Name Assessment Score How to Improve
SA1.4N O-N-9 Requirements Gathering Since there are currently only three sites in Latvian NGI, no specific requirements gathering task/service is necessary. Two of the sites and site admin are in the same building as NGI staff, the third site is also in the same city. Thus, site admins use local communications to discuss requirements with NGI staff. Requirements arise from daily operations and, if necessary, are propagated through NGI staff to OMB meetings. 4 Specific training about EMI middleware and its detailed architecture / possibilities should be provided to site admins, since feedback on service level improvements can be provided only in case of deep knowledge and expertise on grid middleware internals.
SA1.1N O-N-9 Operations Coordination Coordination is very easy due to very small NGI and all sites located in the same city, two sites in same building as NGI. Coordination mostly consists of direct contact through phone/IM and face to face meetings between NGI staff and admins of all sites.

NGI members attend OMB meetings. Also, some operations are coordinated with NDGF_NGI, where Latvian NGI plans to take part in an Operator rotation schedule in the future.

4 Be more proactive in coordination and integrate in NDGF_NGI operations as much and soon as possible.
SA1.2N O-N-9 Security Latvian NGI has a good collaboration with head of security in NDGF and information about vulnerabilities is propagated appropriately. Local site admins implement security updates as soon as possible. Due to small NGI size and relatively small amount of effort available for security monitoring and software rollout, Latvian NGI has kept policy of not being early adopter of more buggy/vulnerable software and historically prolonged SL3/SL4 services as long as possible, which meant in most of the cases security vulnerabilities did not apply to several of the sites. 3 Since the allocated effort is quite small, one of solutions how to improve security is by minimizing amount of different services that run in the NGI. For this, Latvian NGI has decided to migrate to ARC middleware, which has fewer and more lightweight components, thus, theoretically, reducing security risks.

Infrastructure Services (Table 3)

Table 3: NGI Assessment: Operations Services >> Infrastructure Services
EGI-InSPIRE EGI_DS Name Assessment Score How to Improve
SA1.3N O-N-9 Software Rollout Due to small available effort, Latvian NGI does not participate in any Early Adopters tasks for middleware components. Also, updates and rollout of approved updates is usually carried out towards the end of allowed deadlines to have the least possibility of being held back by still buggy updates that have passed EA Staged-Rollout tests. One of the sites has started migration from gLite to ARC to reduce effort necessary for site upkeep in the long term, as well as due to the fact that NDGF_NGI offers official support for ARC middleware, and it's not the case for gLite. 2 Latvian NGI sites plan to migrate to ARC to get middleware support from NDGF_NGI, as well as simplify the site upkeep in general.
SA1.4N O-N-3 Monitoring National Nagios monitoring as well as NDGF_NGI based monitoring are operational. NDGF Nagios & OoD staff provide sufficient level of monitoring and notification in case site admins miss any alerts. 3 Encourage site admins to be more proactive in checking and engaging Nagios alerts instead of relying on notifications from NDGF OoD staff.
SA1.5N O-N-2 Accounting From the three sites in the NGI, one has migrated to ActiveMQ, and the other two sites started migration from gLite to ARC and are still in migration process. Once sites migrate to ARC, relevant statistics will be transferred through NDGF_NGI to central APEL database. 3 Migrate sites to ARC as soon as possible and start publishing accounting data through SGAS to NDGF.
SA1.4N O-N-1 O-N-4 Configuration Repository and Operations Portal Latvian NGI is using central Operations Portal/Dashboard and GOCDB services. There are no plans to deploy regional or national versions, nor is there any available effort or justification for that. 4 none
SA1.6N SA1.7N O-N-6 O-N-7 Helpdesk Latvian NGI has no national helpdesk interfaces with GGUS and we do not plan to deploy one. We currently use the central GGUS and find it satisfactory. 5 none
SA1.8N O-N-5 O-N-8 Core Services One of the sites has gLite3.2, CREAM, DPM, as well as hosts national WMS, LFC and Top-BDII. Latvian NGI still uses MyProxy and VOMS maintained by legacy BalticGrid project partners in Lithuania and Estonia. Service availability is sufficient, but there is no redundancy apart from alternative WMS in Lithuania. The other two sites are currently being migrated from the legacy SL4/gLite3.1 to ARC. If migration is successful, the remaining gLite3.2 site and core grid services most probably will also be migrated to ARC equivalents. Most services on all sites run virtualized. Latvian NGI also has its national CA. 3 Finish migration of sites to ARC as soon as possible and switch from Estonian/Lithuanian MyProxy and VOMS services to ones provided by NDGF.

Other (Table 4)

Table 4: NGI Assessment: Other
EGI-InSPIRE EGI_DS Name Assessment Score How to Improve
NA2.3N Policy Development Due to small available effort Latvian NGI participates in Policy Development on a best effort basis. Latvian NGI also participates in EUGridPMA events. 3 Due to currently available effort Latvian NGI can only try to keep up with policy implementation as good as possible, as well as continue participate in policy development (mainly reviews, suggestions) on a best effort basis.
NA2.2N E-N-2 Dissemination Current available dissemination effort and funding is less than what would be required. Within the available resources, however, reasonable amount of seminars and dissemination can be achieved, mainly using web page announcements and news reports through mailing lists. Presentations and papers on grid computing have been submitted in national scientific conferences as well. 3 Visibility of Latvian NGI should be improved both nationally as well as regionally.