ISGC 2019 Submission Deadline Extended

The International Symposium on Grids and Clouds (ISGC) 2019 will take place from 31 March to 5 April 2019 at Academia Sinica, in Taipei, Taiwan.

This year, the event’s theme is “Efficient and Safe Processing of FAIR Open Data”. The goal of ISGC 2019 is to create a face-to-face venue where individual communities and national representatives can present and share their contributions to the concepts of Open Data and Open Science.

The call for papers has been extended to 19 November, apply now!

Important dates and information:

• On-line Submission
• Submission Deadline: Monday, 19 November 2018
• Abstract Word Limit: 400 (minimum)~600 (maximum) words

Find out more about the event.

Workshop: Success Patterns of Data-driven Business

BDVA / BDVe is organising a one-day workshop for business champions, entrepreneurs and interested „techies“ of the BDVA PPP to gain practical experiences of how to explore data-driven business opportunities. The workshop will take place on 15 November 2018 and will be co-located to the EBDVF 2018 at Siemens Conference Center (same venue that EBDVF 2018 Day 3). The workshop is free-of-charge for BDVA PPP entrepreneurs, however registration is mandatory.

There is a limited number of free seats left, so register soon.

Please see more information and how to register.


3rd edition of the ASTERICS-OBELICS workshop

The 3rd edition of the ASTERICS-OBELICS workshop will take place at the Postdoc Centre-Eddington, University of Cambridge, Cambridge, UK from 23 to 26 October 2018.

The workshop will be focused on:

  • an overview of the OBELICS achievements to the Astronomy and astroparticle physics community. In particular, the open software and services repository developed within OBELICS as well as other solutions created within OBELICS in cooperation with industries will be presented.
  • the developments of new software analysis approaches (e.g. Bayesian statistics, AI and Machine Learning) developed within the ASTERICS partner ESFRI and other world-class research infrastructures in Astronomy, Astrophysics and Astroparticle Physics.
  • an overview of the developments in the implementation of European Open Science Cloud (EOSC), with presentations from EOSC-hub, EOSCpilot as well as Astronomy ESFRI projects. The objective of this session will be to identify how astronomy and astroparticle physics community can support EOSC.

See more details on the workshop and how to register. 

10th European Innovation Summit

The 10th European Innovation Summit will take place from 26 to 29 November 2018 in and around the European Parliament in Brussels, and will mark its 10 year anniversary.

The programme will address hot topics currently on the policy agenda, developments in sectors crucial for Europe’s competitiveness as well as a deep dive into emerging technologies. A special session will be dedicated to European elections and how MEPs play the innovation card during campaign.

The summit will also host the EUtop50 founders and tech festival, providing a unique setting in terms of relevant stakeholders and information for start-ups to move their venture to the next level. Find out more on the event’s website.

Topics of the 10th European Innovation Summit:

A. Horizontal topics

  • Horizon Europe, the next Framework Programme for Research & Innovation
  • EU-Cohesion programmes  supporting innovation policy implementation in all regions
  • MFF, the Multiannual Financial Framework post 2020

B. Emerging and Breakthrough Technologies

Artificial Intelligence, Big Data, Blockchain, Quantum Technologies, Next Generation Computing, Internet of Things/5G mobile, Sunthetic Cells/Genome Editing, Augmented/Virtual/Reality

C. Across industry and sectors 

Digital Transformation/Industry 4.0, Climate Change, Clean Energy, Food for all, Healthcare for a better life, Materials/Chemicals for sustainability, Urban Mobility/Carbon free transport, FinTech/Financial services, Education: adapting curricula to reality, Smart Cities, Circular Economy, Security/Cyber security, Space technology and more.

D. European Elections 2019: putting innovation on top of the campaign 

E. Celebrating 10 years of European Innovation Summit

Summit partners have the opportunity to organize their own event as part of the summit programme on a topic of their choice and contribute to the plenary and other conference sessions.

FitSM goes global through APMG

APMG International, a global accreditation body and examination institute, is the newest Certification Partner set to support the leading lightweight IT Service Management standard – FitSM – through a recently signed agreement with the FitSM non-profit license holder ITEMO (IT Education Management Organization).

As many of our readers know, FitSM is an open, lightweight standard for professionally managing services that has been a growing reference framework for many research and e-infrastructures dating back to its inception via the FedSM project funded by the European Commission between 2012-2015. Though there have been more than 1000 certificates issued to date and more than 15 accredited organizations delivering FitSM training commercially, it has been mostly limited to German speaking countries with the main exception of the EGI Foundation.

Through APMG, FitSM can now expand internationally through its global network of accredited, quality training organizations. APMG assesses trainers and training organizations around the globe to establish their suitability to meet the high standards required to become APMG accredited.

Richard Pharro, CEO of APMG International, stated in the recent announcement: “With high-quality training options, the FitSM suite of standards is an exceptional offering to the market, thanks to original funding from the European Commission through the ‘FedSM’ project. The standard can be freely downloaded, which includes open source course materials where candidates can develop their knowledge by learning lightweight IT Service Management, at pace, starting today”.

Robert Kuhlig, Chairman of ITEMO, also complemented these sentiments: “We are delighted to be partnering with APMG who have a proven track record for professional accreditation and examination. It is this rigorous and trusted assessment history that we are engaging to ensure all our training, trainers and course materials meet the very high standards required. Moreover, with a global footprint, APMG can help spread the benefit of FitSM to organizations around the world.”

I personally was involved in the development of FitSM through the FedSM project, first as a client partner needing to implement service management within the EGI Federation, to moving into more of a consultant and trainer role over the course of the years. I cannot express how excited and proud I am to have been a part of this journey and to see FitSM taken to a place it truly deserves. All to think that this was a result of an EC funded project!

CGW’18 Workshop: call for papers

The CGW’18 workshop will take place in Krakow, from 22 to 24 October 2018 and is organised by ACC Cyfronet AGHAGH University of Science and Technology and the AGH Department of Computer Science.

The CGW’18 workshop will address the following topics:

  • e-Science and collaborative applications
  • models, methods and tools for collaborative applications development
  • virtual laboratories and problem solving environments
  • big data analysis and machine learning
  • distributed data management
  • software engineering aspects with industrial and social implications

And more. The call of papers is open until 30 September 2018.

See all the details of the workshop.


Call for abstracts: International Symposium on Grids and Clouds (ISGC 2019)

The International Symposium on Grids and Clouds (ISGC) 2019 will take place from 31 March to 5 April 2019 at Academia Sinica, in Taipei, Taiwan.

This year, the event’s theme is “Efficient and Safe Processing of FAIR Open Data”. The goal of ISGC 2019 is to create a face-to-face venue where individual communities and national representatives can present and share their contributions to the concepts of Open Data and Open Science.

The call for papers is now open!

Important dates and information:

On-line Submission
• Submission Deadline: Monday, 5 November 2018
• Abstract Word Limit: 400 (minimum)~600 (maximum) words
• Acceptance Notification to Authors: Wednesday, 12 December 2018

Find out more about the event.

Presentation on European Helix Nebula Science cloud

As part of the Helix Nebula initiative the European Helix Nebula Science cloud project, for the last two years has done a Pre-Commercial Procurement for the establishment of an European hybrid cloud platform to support the deployment of high-performance computing and big-data capabilities for scientific research. From the beginning of this project, SURFsara has been one of the ten European institutes acting as a buyers group to make selections between the four vendor consortia throughout the project based on technical and economical reviews. The project has gone through a design and prototype type phase, both reducing the number of eligible consortia to the two now left in the current pilot phase.

As part of the pilot phase representatives of the two remaining consortia, T-Systems and RHEA, will go to the buyers group institutes for demos and presentations of their offerings. On September the 11th they will be at SURFsara for an afternoon of presentations ending with drinks.

In addition to the presentations of the consortia and oneData, there will be a presentation from three of the SURFsara test cases from the project: WeNMR (with reservation), LOFAR and from Nikhef Stoomboot scale out. The discussion will end with a session about what the Helix Nebula Science cloud might mean for current or future SURF services.

Registration is open (access pin: 0303)

Program (September 11th, VK1/2 SURFsara Amsterdam):

  • 14.00 – 14.10 Welcome and introduction to HNSciCloud
  • 14.10 – 14.30 Overview of OneData
  • 14.30 – 15.00 Overview of pilot platforms RHEA
  • 15.00 – 15.30 Overview of pilot platforms T-Systems
  • 15.30 – 16.00 Coffee
  • 16.00 – 17.15 Use case presentations and discussion


The 10th edition of the School on Efficient Scientific Computing (ESC)

The tenth edition of the School on Efficient Scientific Computing (ESC School) will be held from 22 to 27 October 2018, at the University Residential Centre of Bertinoro (Ce.U.B.), in Bertinoro, Italy.

The aim of the ESC school is to offer the participants the opportunity to improve their computing competences, learning from qualified and experienced scientists how to best exploit modern hardware and software technologies in their daily scientific work. The program proposes introductory lectures on trends in hardware architectures and parallel programming, with more in-depth lessons on modern C++, effective memory usage, floating-point computation and programming in a heterogeneous world combining multi-threading, GPUs and clusters.

The school is organised as a small class of about 30 students, alternating lectures, hands-on sessions and self-managed time slots for the best learning experience, with lecturers available during the whole week for insights and discussions.

Applications are now open, please see more information on the event’s website.

Ansible Style Guide in Action

This article was written by Bruce Becker, Senior Operations Officer at the EGI Foundation, and re-posted here with permission. You can also read it on Bruce’s personal blog.


A few weeks ago, I announced a style guide for developing Ansible roles.

The intended audience is the developers of middleware components and the aim of the guide is to improve or ability to collaborate, and to deliver products smoothly and reliably, without breaking the infrastructure in general.

A typical case would be an existing product which performs some specific function e.g., a storage management front-end service. Another case would be the one I want to use as an example here – the so-called “worker-node” function.

Case: Worker Node

The worker node is essentially a composition of clients which interact with infrastructure components:

  • validate user token
  • get data
  • submit workload request to your local resource manager
  • check how that’s going
  • send accounting data

etc. If we were starting out now, these functions might well be built as serverless endpoints, but as with all things infrastructure-related, one has to deal with the legacy of what came before.

The worker node function has typically been distributed as a meta-package in OS repositories – an RPM or DEB which expresses all of the necessary dependencies. A site wishing to provide the worker node function could therefore easily ensure that this was present by simply installing the metapackage. That is, if the prerequisite state is assured.

That’s a big if and a big ask in 2018.

Building the worker node now

If we had the case of a totally new site in the federation wishing to participate by offering compute resources, we would probably want this site to be integrated and functional with a little demand on the site itself. If we start from this position, we might well consider the site resources and the layer of middleware necessary to federate it as separated by a well-defined contract : We (federation) give you a bunch of endpoints to send data to, you (resource provider) send the data. We’ll go one step further and provide you with the functions which send that data, so that you have zero interference with your setup.

This separation of function from platform is why containers were developed.

Modelling services

How would things be different, if we approached this from a 12 factor point of view? We have to deal not only with the installation of binaries and other files, but also the configuration of these, around site-specific setups, procedures and policies. The last thing a product team wants to deliver to an endpoint which will eventually use it, is a product which doesn’t play nicely with the rest of the environment. This could include, for example, hard-coding certain paths, asserting the presence of particular users or, usage of the network in a specific way. All of these would be examples of “bad behaviour”, since the integration of the site into the federation is not done according to a central prescription, but according to an OLA agreed to by both parties.

We therefore need to deliver not only products, but also strategies for deploying those products, which are flexible enough to respect local site policies. If we are to be fluid, we also need a high degree of trust that the final result will not only perform as advertised (i.e., works, and does what it needs to do), but also won’t break local setups. The Ansible Style Guide describes aspects of developing, testing, documenting and delivering the role. It is more about how than what, because the overriding, big-picture goal is to solve problems and have them stay solved.

The way to do this is, as with most engineering problems, to factor out the big problem into smaller ones in some logical way. Doing things in this way, we come to have a sort of “dependency tree” of roles, so that infrastructure engineers can separate problems and solve them permanently.

This has the happy consequence however that end users (typically, site administrators) can re-use these products with confidence at their site, know where to go for support and understand how to contribute back. Looking at the simple case of building a User Interface, shown in Figure 1, this is quite easy to understand. We can even link the roles themselves to various actions and outputs as shown in Figure 2.


Figure 2: Representation of the expression of the Ansible role and the resulting product – container images in EGI’s Quay Organisation. The vertical axis describes the dependency graph of the Ansible roles for UMD products, while the horizontal axis shows how these are expressed in various environments by applying them. The final products (container images in this case) are immediately re-usable.

In this way, we can continue modelling individual roles and map events in source code to artifacts in production. The final touches to our modelling flow are added in Figure 3, where we add the links to the respective GitHub repositories and the all-important testing phase – more on that in a later section.

Figure 3: Schematic diagram of the full continuous integration and delivery of UMD configurations, as well as dependency tree respective Ansible roles, for the simple case of the User Interface. In this case, we deliver pre-built and Docker images to the Quay registry. Testing is done with TestInfra, a python-based infrastructure spec tool.


Now that we have a clear idea of how to go about modelling our roles, and putting the tools in place for our continuous integration and delivery pipeline, we can take a closer look at using the EGI Ansible Style Guide to get started.

Getting started

The first thing you need to do is get the style guide, and use it to create a new Ansible role. Ansible roles are usually generated with the Ansible Galaxy CLI command init, but this uses a role skeleton which doesn’t cover many of EGI’s bases. We therefore use the egi-galaxy-template in the Style Guide repo to generate a better one:

git clone
ansible-galaxy init --role-skeleton=ansible-style-guide/egi-galaxy-template ansible-role-wn`

We now have a shiny new Ansible role : ansible-role-wn. Before we go about implementing it, we need to have a means for implementing tests and generating test scenarios. Typically we use Molecule for this, which is great for generating a full set of test scenarios and strategies.

Install Molecule with pip, and generate a scenario, using a virtualenv^[VEnv]:

$ virtualenv style
$ source style/bin/activate
(style)$ pip install molecule
(style)$ molecule init scenario -r ansible-role-wn

Initial Commit

At this point we have an empty (but stylish) role in a clean environment and a default testing scenario.

Running the test strategy should result in all of it passing2:

molecule lint
molecule dependency
molecule create
molecule converge
molecule verify

This means absolutely nothing, of course – we need to start adding some failing tests !

Tests and Development of Roles

The EGI UMD follows something similar to an Acceptance Test Driven Development pattern.

There are several products, each of which are testing independently upstream by their owners, and candidates for inclusion in the distribution are then communicated to the release co-ordination team. This team then checks whether the UMD Quality Criteria are respected by the product, and whether the new version breaks anything already in production. There are several strategies for doing this, and the one which makes the most sense varies from product to product. Then of course, there is the expected functionality of the product as it would be in production. Finally, there is the consideration that we expect these roles to be deployed into production, which means that the configurations should be hardened and secure by design. Deploying faulty configurations into production environments – even with fully-patched software – can lead to serious degradation in operational security.

We therefore need to implement tests for each of these, as far as we can.

Test-Driven Development3, from Extreme Programming4 suggests that engineering proceed on a “Red, Green, Refactor” cadence.


Considering we are developing the functionality of a worker node here, the first thing we could check for is that the relevant packages are actually present. Using TestInfra’s package module, we can write this assertion.

def test_packages(host, pkg):
        assert host.package(pkg).is_installed

Seems simple, right? All we need to do is pass the correct fixtures to the function test_packages, to see whether the host we will provision with molecule is in the desired state.

It is important to remember what we are testing for here. We are not testing whether the Ansible playbook has run correctly – or even whether an Ansible playbook has run at all – we are simply making assertions about the host. These assertions should be true no matter how the host arrived at its current state, and of course should reflect the desired state in production environments.

We therefore need to consult the source of truth5 for the worker node package requirements – the same repository that the product team is maintaining which the UMD team has tested and done the QC tests on – to write the fixtures for this test.

We can still converge the role with no problems (nothing has been implemented yet), but when it comes to running the tests (molecule verify), we will be duly informed that they are all FAILING

Great success. Go ahead and add that test to the scenario:

git add molecule/default/
git commit -m "Added failing test for packages"
git push

Note: using the EGI Ansible Style Guide, there is a .travis.yml already set up for you if you want to do CI on Travis. All you need to do is enable the repository and Travis will take care of the rest.


The next step in TDD is to implement just enough code to make that test pass. With Ansible, this is amost too easy:

First, create a variable in defaults/main.yml to hold the packages that need to be present, taking into account differences across operating systems and OS releases:

# defaults/main.yml
      - wn_pkg_1
      - wn_pkg_2
      - WN_1
      - WN_2
      - worker_node
      - worker_node

Next, add a task which ensures that those packages are present:

# tasks/main.yml
- name: Ensure worker node packages are present
    name: "{{ item }}"
    state: present
  loop: "{{ packages[ansible_os_family|lower][ansible_os_distribution_major] }}"

Here, we take advantage of the facts gathered by Ansible identifying the host OS and version – which of course is why we crafted the variable packages in the way we did.

Of course, these tasks need to be applied in an actual playbook. Molecule creates the simplest possible playbook for the scenario for you:

# molecule/default/playbook.yml
- name: Converge
  hosts: all
  - role: ansible-role-wn

This playbook is used during the converge stage. If there are any dependencies which are required (which are now clear from our dependency tree!), they can be added before the application of the role you are working on :

# molecule/default/playbook.yml
- name: Converge
  hosts: all
    - {role: EGI-Foundation.umd, release: 4, tags: "UMD" }
    - {role: EGI-Foundation.voms-client, tags: "VOMS" }
    - {role: ansible-role-wn, tags: "wn"}

Once we have implemented the functionality, we repeat the converge and verify until the tests are passing.


Figure 4: Schematic representation of a Test-Driven Development of an Ansible role.

Once the tests are passing, we take another look over our code and tests and try to ascertain whether the tests are really doing what we want them to do and whether that part of the role has been implemented in the best possible way. Figure 4 shows a general workflow of how this should be done.


Clearly, we are not done with the development of the worker node role. However we can be sure that application of this role to any production site will not break the site – a very important point! We now have a solid base from which to step to the next iteration, adding tests for desired behaviour and functionality to achieve it as we go. We also have the means to express this role in arbitrary environments – be they bare metal, hypervisor virtualisation, or Linux containers – all from a single well-maintained role.

As discusssed above The worker node needs to be able to perform many functions – we should try to implement tests for as many of these functions as we can. Similarly, as many of the EGI Quality Criteria should be included in our test coverage, so that we can ensure sites that by applying these roles off-the-shelf, they will be increasing the stability of their site and decreasing their day-to-day operations load.

Furthermore, by using a common style guide for developing these roles, we make it easier to get started for others who want to contribute. The style guide helps peers and collaborators do code review when features or development is proposed via pull request, and gives clear guidelines for how these contributions should be recognised.

All in all, this is a small step towards improving the stability of sites in the EGI federation, without compromising agility and quality, and reducing the friction in the middleware delivery pipeline.

References and Footnotes
  1. “Developers of middleware components” is an EGI-federation-specific way of thinking of this audience. What I have in mind is maintainers or product owners who want their products to live in the EOSC ecosystem. Even products which may live at the boundary of this ecosystem may be relevant. ↩
  2. This is long-hand for molecule test, which will execute the full testing strategy. ↩
  3. A good overview of test-driven development was written buy Martin Fowler ↩
  4. Beck, K., & Andres, C. (2015). Extreme programming explained: Second edition, embrace change. Boston: Addison-Wesley. ↩
  5. In this case, it’s the  WN Metapackage repository ↩