EXECUTIVE SUMMARY

It is well known that modern research builds on extensive scientific dialogue
and advances by improving earlier work made public. Following the FAIR Data
Principles: Findable, Accessible, Interoperable, and Re-Usable is to pave the
way towards this over-arching objective.

The purpose of this document is to deliver the first version of the Data
Management Plan. FAIR Principles have been applied

The approach taken for this document was to consult all key documents made
available by the EU to create a Data Management Plan: H2020 Programme
Guidelines to the Rules on Open Access to Scientific Publications and Open
Access to Research Data in Horizon 2020 (V3.2 21 March 2017) ,

H2020 AGA — Annotated Model Grant Agreement (V2.2 25 November 2016) ,
Guidelines on FAIR Data Management in Horizon 2020 (V3.0- 26 July 2016) along
with ANNEX 1- Horizon 2020 FAIR DMP template and issues highlighted to be
covered in the DMP, and lastly the online tool, DMP Online which was suggested
in the section “Further support in developing your DMP.”

This is a living document and therefore as information is made available the
document will be updated to reflection a finer level of granularity.

#  Introduction

CloudPerfect is a part of the Open Research Data Pilot (ORD pilot) which aims
to encourage good data management, and maximise access to and re-use of
research data generated by Horizon 2020 projects. As part of this ORD pilot,
the objective of this document is to deliver an initial Data Management Plan,
from here forward referred to as DMP.

The DMP intends to ensure FAIR data management, meaning research data should
be Findable, Accessible, Interoperable, and Re-useable. The principles have
guided the DMP, to its ultimate goal of managing research data encourage
knowledge discovery and innovation and therefore data and knowledge
integration and re-use.

This document is delivered under WP 1- Project & Innovation Management and
Technical Coordination. The DMP will be delivered also in a second version,
D1.4 Final Data Management Plan, at project month 22\.

The document begins with a Chapter 2 – Background. This Chapter describes the
documents objective, scope and approach.

Chapter 3- Data Summary, addresses what data is collected or created, what the
utility of this data may be for others, and its purpose in relation to the
project objectives, what data will be opened or closed (with rationale).

Chapter 4- Responsibilities and Resources addresses responsibilities regarding
data management, questions about resources/costs for making the data FAIR, and
aspects of data quality assurance.

Furthermore, Chapter 5- Ethics and Legal Compliance addresses how the project
would manage any ethical issues, how copyright and Intellectual Property
Rights (IPR) issues will be managed. Moreover, other questions addressed: who
will own the copyright and IPR of any existing data as well as new data that
will be generated, and an outline of any restrictions needed on data sharing.

Chapter 6- Data Set Information will address the following areas for each type
of Data-Set: data collection, documentation and metadata, data sharing and re-
use, storage and backup, preservation and data security.

To conclude, the final Chapter- Next steps addresses the approach taken to
keep the Data Management updated and reflect information made available as the
project progresses.

#  Background

##  Objective

The specific objective of this document is to deliver a DMP.

The CloudPerfect intends to fulfil the requirements of the Open Research Data
Pilot by following the steps below:

  1. Creating a DMP by closely following all guidelines, templates and suggestions provided by the EC (see Section 2.3- Approach). This document represents the initial version. A second version will be delivered at project month 22. 

  

  2. Deposit research data in a research data repository  1  . The CloudPerfect project KPI, as far as DPM is concerned, is to deposit data in at least 3 repositories, aim for >200 downloads, and communicate this to wider scientific communities. 

  

  3. As for as possible, take measures to enable third parties to access, mine, exploit, reproduce and disseminate (free of charge for any user) the research data. Also, provide information/instruments themselves via the chosen repository about the tools available to the beneficiaries that are needed to validate the results, such as specialised software, algorithms and analysis protocols. 

  

  

##  Scope

The project understands that the DMP does not concern publications, only
research data. The below figure, taken from the H2020 Programme Guidelines on
the Rules on Open Access to Scientific Publications and Open Access to
Research Data in Horizon 2020, gives an overall picture.

_Figure 1- Open access to scientific publication and research data in the
wider context of dissemination and exploitation_

As of the H2020 Programme AGA – Annotated Model Grant Agreement  2  , the
types of research data are:

  1. The 'underlying data' (the data needed to validate the results presented in scientific publications), including the associated metadata (i.e. metadata describing the research data deposited) 

  

  2. Any other data (for instance curated data not directly attributable to a publication, or raw data), including the associated metadata, as specified in the DMP – that is, according to the individual judgement by each project/grantee. For example: Examples: curated data not directly attributable to a publication or raw data. 

  

  

The below section describes the approach taken for the creation of
CloudPerfect DMP.

##  Approach

The approach taken for the creation of the DMP was to consult key documents:
H2020 Programme Guidelines to the Rules on Open Access to Scientific
Publications and Open Access to Research Data in Horizon 2020 (V3.2 21 March
2017)  3  , H2020 AGA — Annotated Model Grant Agreement (V2.2 25 November
2016)  4  , Guidelines on FAIR Data Management in Horizon 2020 (V3.0- 26 July
2016)  5  along with ANNEX 1- Horizon 2020 FAIR DMP template and issues
highlighted to be covered in the DMP,

2

http://ec.europa.eu/research/participants/data/ref/h2020/grants_manual/amga/h2020-

amga_en.pdf 3

http://ec.europa.eu/research/participants/data/ref/h2020/grants_manual/hi/oa_pilot/h2020-hi-

oa-pilot-guide_en.pdf 4

http://ec.europa.eu/research/participants/data/ref/h2020/grants_manual/amga/h2020-

amga_en.pdf 5

http://ec.europa.eu/research/participants/data/ref/h2020/grants_manual/hi/oa_pilot/h2020-hioa-
data-mgt_en.pdf

and lastly the online tool, DMP Online  2  which was suggested in the section
“Further support in developing your DMP.”

All resources were considered and represented in the document. All the
questions said to be answered (with a level appropriate to the project), and
issues highlighted in the templates are found in the deliverable in the
different Chapters and left in their original form.

Data Sets decided to be open were grouped by type and assigned to a project
team member who then provided answers to the questions. All answers are in
Chapter 6-Data Set Information.

The DMP is a living document. As mentioned in the Guidelines, detailed answers
to all the questions (suggested to be answered) are not required in the
initial version.

#  Data Summary

This section is organized by stating the question and answer immediately
after.

**Question: What data will you collect or create? What Research Data is
open?**

**Which data are of long-term value and should be retained, shared, and/or
preserved?**

The data collected/created can be grouped in three different Data Sets. The
following data sets would be of value of the envisioned spin-off at project-
end.

  1. Data Set: CloudPerfect Software 

  

  

This dataset includes the source code and the binary packages of the software
produced within the scope of CloudPerfect. Namely, Cloudiator code and
Benchmark code.

  2. Data Set: Monitoring and Profiling Data 

  

  

This dataset provides two types of data: the one kind of data is raw
monitoring data collected from virtual or physical infrastructures including
application metrics. The second type is derived data, these data are created
from raw data through mathematical and statistical means. Namely, Cloudiator
Application Level Monitoring Data, Infrastructure Monitoring Data, Profiling
Vectors, Performance Models, Benchmark Data on Providers, and SLA data.

  3. Data Set: CFD Use Case models and methods 

  

  

The data comes from Phitec Ingegneria srl research activity on Computational
Fluid Dynamics (CFD) Use Cases (UC) within the CloudPerfect environment
testing activity. Namely, CFD Use case benchmark data.

**Question: What is the purpose of the data collection/generation and its
relation to the objectives of the project?**

CloudPerfect relates to ICT-06-2016 and more specifically to the
Experimentation scope and covers also a significant part of the scope on
“Cloud Computing for SMEs and Public Sector Innovation.” Therefore, the
purpose of the data collection/generation is to be able to fulfil the
objectives set part of the project scope, which are the following:

Objective 1: Enhance Cloud provider resource management practices that lead to
improved stability of offered services and QoE for end users.

Objective 2: Enhance Cloud services behaviour measurability, predictability
and auditability in order to increase operational trust, thus enabling their
use in more critical applications and minimizing procurement time for SMEs
targeting Cloud environments.

Objective 3: Enable a set of abstraction layers on top of existing tools that
will aid increased uptake of the produced artefacts and their ability to be
launched against multiple providers/services without differences.

Objective 4: Define and apply sets of metrics that are meaningful to the end
users for QoE and QoS Levels.

Objective 5: Enhance cloud-based application’s competitiveness through
minimizing the per user cost, via optimizing the resource selection process
based on application categorization and provider benchmarking on the same
categories for creation of multi-tier SLAs.

Objective 6: Pilot and demonstrate the applicability and scalability of the
tools on large scale Cloud infrastructures and for applications that typically
need specialized oversized infrastructures.

Objective 7: Enable the extension of the Cloud business model and consulting
roles.

**Question: Will existing data be reused and how?**

CloudPerfect builds on previous research results from previous and on-going
European projects, increasing the quality of results and helping increase the
progress of the market. Therefore, existing components and functionalities
that have been developed and prototyped in other projects were brought into
CloudPerfect. Here below is a description of the assets, the originating
project and the scope of extension/integration in CloudPerfect.

  1. 3ALib (SLA monitoring library) from the project ARTIST  3  . 

  

  

Integration with QoE DB and extension to analytics queries for identification
of key metrics, improvement of front-ends and multi-user functionality,
improved packaging and deployment process.

  2. Benchmarking Suite (Cloud services benchmarking tool) from project ARTIST 

  

  

Increase benchmarking scope through incorporation of other major categories
(e.g. CFD specific benchmarks, security benchmarks etc.), improved packaging
and deployment process.

  3. Open Reference Model (Metrics and standards specification) from project SLALOM  8  New metrics may be added and applied on top of retrieved data. 

  

  4. CLOUDIATOR (Orchestration, Deployment and App management tool) from project PaaSAge  9 

  

  

Improved packaging and deployment process, increased Modularity,
configurability and integratability, support for software updates and
continuous integration.

  5. Intelligent Services (Overhead Prediction model and IRMOS & Classification tools) from project ARTIST 

  

  

Extension with direct monitoring and acquisition mechanisms, deployment on a
Cloud environment, improved packaging and automation process, and integration
with Cloud management systems.

**Question: What Research Data is closed? Provide rationale for doing so.**

CloudPerfect is aware that, as stated in the H2020 AGA — Annotated Model Grant
Agreement, “beneficiaries may decide not to provide open access to specific
datasets if this would go against other GA obligations (e.g. to protect
results or personal data) or if the action’s main objective…would be
jeopardised by giving open access to those specific datasets.” Furthermore,
“This does not change the obligation to protect results in Article 27, the
confidentiality obligations in Article 36, the security obligations in Article
37 or the obligations to protect personal data in Article 39, all of which
still apply.”

No closed data sets have been listed as of the date of the submission of this
deliverable.

#  Responsibilities and Resources

**Question: Who will be responsible for data management?**

The management of the data set is shared amongst the project partners whom
take part in contributing details about the datasets in the DMP deliverables,
those that take care of the deposition of research data in open research data
repositories, and overall through the Quality Manager, whom oversee the
monitoring of KPI’s, which includes: to deposit data in at least 3
repositories, aim for >200 downloads, and communicate this to wider scientific
communities.

**Question: What resources will you require to deliver your plan? Estimate the
costs for making your data FAIR. Describe how you intend to cover these costs.
Describe costs and potential value of long term preservation.**

As of the date of the submission of this deliverable, CloudPerfect estimates
no costs related to the implementation of the ORD pilot (e.g. costs for
providing open access, related research data management costs, data curation
and data storage costs.)

**Question: What is the data quality assurance process?**

CloudPerfect understands data quality to be the perception/assessment of
data's fitness to serve its purpose in a given context. The project partners
in charge of depositing research data in open research data repositories
ensure the use of the data by individuals who are not involved in the creation
of the data. This would serve as a quality check. Attention is given to
consistency across data sources and appropriate presentation.

To note, CloudPerfect has a Quality Assurance Office (QAO), which is a task
force constituted in to deal with all quality related aspects within the
project. The mandate of the QAO is to ensure that all the activities,
procedures, policies, milestones, deliverables and tools are of high quality
by continuously monitoring and assessing their status and results. The QAO
actively collaborates with all the project management structures to ensure the
quality of project outcomes (i.e. deliverables, milestones, software).

#  Ethics and Legal Compliance

**Question: How will you manage any ethical issues?**

The CloudPerfect DoA declared in Section 5.1 that no ethics issues are
involved in the project.

Article 34- Ethics and Research Integrity in Grant Agreement describes the
obligation to comply with ethical principles and research integrity, and
describes the procedure related to raising an ethical issue:

Before the beginning of an activity raising an ethical issue, each beneficiary
must have obtained:

  1. any ethics committee opinion required under national law and 

  

  2. any notification or authorisation for activities raising ethical issues required under national and/or European law needed for implementing the action tasks in question. 

  

  

The documents must be kept on file and be submitted upon request by the
coordinator to the Commission (see Article 52). If they are not in English,
they must be submitted together with an English summary, which shows that the
action tasks in question are covered and includes the conclusions of the
committee or authority concerned (if available).

**Question: How will you manage copyright and Intellectual Property Rights
(IPR) issues?**

The policy reflects the current state of the consortium agreements on data
management. _Section 8- Results_ and _Section 9-Access Rights_ in the
Consortium Agreement give detailed explanation of this topic, and also details
on when an objection is justified and the procedure to follow:

An objection is justified if:

  1. the protection of the objecting Party's Results or Background  4  would be adversely affected 

  

  2. the objecting Party's legitimate interests in relation to the Results or Background would be significantly harmed. 

  

  

The objection has to include a precise request for necessary modifications.

  1. If an objection has been raised the involved Parties shall discuss how to overcome the justified grounds for the objection on a timely basis (for example by amendment to the planned publication and/or by protecting information before publication) and the objecting Party shall not unreasonably continue the opposition if appropriate measures are taken following the discussion. 

  

  2. The objecting Party can request a publication delay of not more than 90 calendar days from the time it raises such an objection. After 90 calendar days the publication is permitted. 

  

  

Furthermore, outlined in the Consortium Agreement, decisions regarding
intellectual property rights shall be taken by the Project Management Board.
For example: proposals for changes to Annexes 1 and 2 of the Grant Agreement
to be agreed by the Funding Authority, changes to the Consortium Plan,
modifications to Attachment 1 (Background Included) and additions to
Attachment 3 (List of Third Parties for simplified transfer according to
Section 8.3.2.)

Section- Governance structure covers voting rules and quorum, and veto rights,
where a Member which can show that its intellectual property rights or other
legitimate interests would be severely affected by a decision of a Consortium
Body may exercise a veto with respect to the corresponding decision or
relevant part of the decision.

**Who will own the copyright and IPR of any existing data as well as new data
that will be generated?**

All partners are aware that Access Rights to background have to be granted in
principle, but Parties must identify and agree amongst them on the Background
for the project. As of the date of the submission of this deliverable, no
partners have described background for which there are Specific limitations
and/or conditions for implementation (Article 25.2 Grant Agreement) or
Specific limitations and/or conditions for Exploitation (Article 25.3 Grant
Agreement.) Article 26 — Ownership of results in the Grant Agreement states
that results are owned by the beneficiary that generates them.

#  Data Set Information

As mentioned in the Chapter-Approach, all resources made available by the EU
about creating a DMP are represented in this document. All the questions said
to be answered (with a level appropriate to the project) and issues
highlighted in the templates are found here and left in their original form.
Therefore, the format is question(s) and the answer(s) immediately after.

##  Data Set - CFD Use Case Models and Methods

The data comes from Phitec Ingegneria srl research activity on Computational
Fluid Dynamics (CFD) Use Cases (UC) within the CloudPerfect environment
testing activity.

###  Data Collection

The following questions are addressed.

What is the origin of the data?

How will the data be collected or created?

To whom might it be useful?

What is the size of the data?

What is the type(s) and format(s) of data?

####  **Response**

The CFD Use Case models and methods dataset will be based on report (pdf
format), software settings (raw text files), geometry (stl format) and scripts
for connecting different software in a complete CFD simulation or CFD based
optimization loop.

Although the precise size of the data will vary during the project, it will
stay in the scale of a few hundreds of megabytes.

The data collected can be useful to:

  * researches/organization working in the field of applied CFD and optimization for products performance improvements. 

  

  * Researches/organization working in the field of High Performance Computing (HPC) or cloud computing solution testing or optimization as the data provided will give the possibility to perform computational intensive test on HPC systems 

  

###  Documentation and Metadata

The following questions and points are addressed below.

What documentation and metadata will accompany the data? Specify standards for
metadata creation (if any). If there are no standards in your discipline
describe what type of metadata will be created and how.

_Making data findable, including provisions for metadata_

Outline the discoverability of data (metadata provision).

Outline the identifiability of data and refer to standard identification
mechanism. Do you make use of persistent and unique identifiers such as
Digital Object Identifiers?

Outline naming conventions used

Outline the approach towards search keyword

Outline the approach for clear versioning

#####  Response

The collected data will be accompanied by a usage manual that will explain the
dataset purpose and the basic instructions to use it. This manual can be
distributed within the distribution packages directly or available online.

Concerning metadata and discoverability, the dataset will be published on the
Zenodo  5  portal. This will guarantee:

  * A unique DOI assigned to each version of the software; 

  

  * A rich set of metadata associated to the software including description, authors and maintainers, version, release date, free keywords, grant number of funding projects, links to additional location for data and documentation; 

  

  * Discoverability of metadata through the portal search functionality and programmatically using the OAI-PMH protocol; 

  

The data will adopt the Semantic Versioning 2.0  12  scheme to assign a unique
version to each release of the data.

No particular naming conventions are in place for the software at the time of
writing.

The approach towards search keyword is not defined yet at the time of writing.

###  Data Sharing and Re-use

The following questions and points are addressed.

_Making data openly accessible_

How will you share the data? Repository name(s). Specify where the data and
associated metadata, documentation and code are deposited

Are any restrictions on data sharing required? Specify how access will be
provided in case there are any restrictions.

Specify what methods or software tools are needed to access the data? Is
documentation about the software needed to access the data included? Is it
possible to include the relevant software (e.g. in open source code)?

_Making data interoperable_

Assess the interoperability of your data. Specify what data and metadata
vocabularies, standards or methodologies you will follow to facilitate
interoperability.

Specify whether you will be using standard vocabulary for all data types
present in your data set, to allow inter-disciplinary interoperability? If
not, will you provide mapping to more commonly used ontologies?

_Increase Data Re-use (through clarifying licences)_

Specify how the data will be licenced to permit the widest reuse possible

Specify when the data will be made available for re-use. If applicable,
specify why and for what period a data embargo is needed

Specify whether the data produced and/or used in the project is useable by
third parties, in particular after the end of the project? If the re-use of
some data is restricted, explain why

#####  Response

The CFD Use Case models and methods dataset will be published and open
accessible through, at least, two software repositories:

  * The GitHub ( _https://github.com/_ ) platform; 

  

  * The Zenodo ( _https://zenodo.org/_ ) portal; 

  

The location of software in those repositories will be clearly linked in the
CloudPerfect website. New versions of the software will be published as soon
as they become available without applying any embargo periods.

All the formats used both for software settings and scripts are standard in
computing science and compatible with most of existing platforms. This
guarantees a high level of interoperability with other software and runtime
environments.

Open source (eg. OpenFOAM®, Paraview, FreeCAD, etc.) and closed source
software (e.g. iconCFD® Geometry tool, Beta CAE Ansa etc.) are needed to
access the data. Clear indication of what software is needed to access and
reuse every package of data will be provided together with the data
themselves.

The dataset will be released under the MIT license  6  . This will guarantee
the full possibility of reusing the data even for commercial purposes.

###  Storage and Backup, Preservation and Data Security

The following questions are addressed.

How will the data be stored and backed up during the research?

How will you manage access and security?

Address data recovery as well as secure storage and transfer of sensitive data

What is the long-term preservation plan for the dataset? Specify the length of
time for which the data will remain re-usable.

#####  Response

For storage, backup, preservation and security of the dataset, CloudPerfect
relies on the technology and policies provided by the two repositories GitHub
and Zenodo where the software will be made available. They both have very
strong policies for these aspects. For instance, Zenodo metadata database is
backed-up every 12 hours with one backup per-week sent to a tape storage,
while GitHub stores each repository in at least three different locations plus
an off-site backup. More details can be found at
_http://about.zenodo.org/infrastructure/_ and
_https://help.github.com/articles/github-security/_

##  Data Set - Monitoring and Profiling Data

This dataset provides two types of data: the one kind of data is raw
monitoring data collected from virtual or physical infrastructures including
application metrics. The second type is derived data. It is created from raw
data through mathematical and statistical means.

###  Data collection

The following questions are addressed.

What is the origin of the data?

How will the data be collected or created?

To whom might it be useful ('data utility')?

What is the size of the data?

What is the type(s) and format(s) of data?

#####  Response

All data is created and processed in the project. No external data is used.

The raw monitoring data will be created through various means: application-
level data includes resource consumption time series from virtual machines.
This data set is enhanced with applicationlevel metrics. Both of them are
collected by the Cloudiator toolkit. Infrastructure monitoring data comprises
resource consumption time series from the physical infrastructure in the
testbeds. This data is collected by probes in the testbed and made available
through the cloud platform API.

The derived data will be created by interpretation of the raw data through the
tools used in CloudPerfect, mainly Cloudiator, A3lib, Benchmarking suite). It
will be created by applying the respective tools on the raw monitoring data.

Raw data is utilisable for other researchers, namely people intending to apply
new kinds of data analysis to that data. This can be with similar goals in
mind, but could also target different questions such as hardware reliability
or sizing of the hardware infrastructure.

Derived data is of interest for any kind of cloud user and/or data centre
provider that want to compare the performance of different cloud platforms.

Based on previous experience, we expect to collect about 10 GB per month of
raw monitoring data. The amount of data that is intended for publishing will
likely not exceed 10--20 GB in total.

The derived data will reside in the order of maximum several hundreds of
Megabytes.

###  Documentation and Metadata

The following questions and points are addressed.

What documentation and metadata will accompany the data? Specify standards for
metadata creation (if any). If there are no standards in your discipline
describe what type of metadata will be created and how.

_Making data findable, including provisions for metadata_

Outline the discoverability of data (metadata provision).

Outline the identifiability of data and refer to standard identification
mechanism. Do you make use of persistent and unique identifiers such as
Digital Object Identifiers?

Outline naming conventions used

Outline the approach towards search keyword

Outline the approach for clear versioning

#####  Response

Raw data is monitoring data collected from the testbeds and stored in
databases. While many of the 'traditional' meta-data attributes such 'author'
are not applicable for it, there are many other metadata including the origin
of the data, the interval it covers, the description of the testbed and
applications, possibly referring back to models and meta-models. We are
currently not aware of any meta-data standards for monitoring time series
besides Metrics 2.0 that we plan to follow. For derived data no such standards
exist.

In any case, CloudPerfect attempts to provide the necessary meta-data expected
by the Dublin Core standard for all data sets as a lowest common denominator

The Communication and Information Center (kiz) of UULM is running OPARU, an
(amongst others) OpenAire indexed OpenAccess server that provides support for
the publication of research data. In addition, the kiz and OMI (UULM’s
research department involved in CloudPerfect) are involved in a project that
prepare mechanisms that allow an easy and persistent publication of software
artefacts.

With respect to Monitoring and Profiling Data CloudPerfect will, whenever
possible and useful, rely on that repository for publishing their research
data. This will result in DOIs being created for any published data set or
sets of data sets.

The only hindrance we can foresee by now is that the size of some data
collections, in particular of raw data, exceed the maximum allowed size for
OPARU. If this threshold takes effect, other repositories such as Zenodo come
into play. These will be selected on a per-demand basis.

So far, no naming conventions have been decided on. Yet, it is obvious that
the main language being used for describing and naming elements will be
English.

For raw data the description of the data is of importance and the naming
conventions followed depend on the storage format. For instance, in the case
of a CSV file, the column headers will use speaking English names so the
content of each column can be easily identified.

Search Keyword- Openly accessible data sets shall be published through an
online repository and be linked to a DOI. In consequence, each of them will
also be enhanced with a title, the authors, an abstract, and a set of keywords
that describe the data. Where abstracts are not sufficient, data sets shall be
enhanced with a longer, e.g. one to two pages, descriptive text.

Clear Versioning- For raw data traces, the location of the testbed as well as
the time span covered by the traces will be used as an identifier. Where
applicable also the benchmarked application type and the imposed load will be
part of the identifier. Data sets derived from raw data will contain the id
name of the raw data and a timestamp in their name.

###  Data Sharing and Re-use

The following questions and points are addressed.

_Making data openly accessible_

How will you share the data? Repository name(s). Specify where the data and
associated metadata, documentation and code are deposited

Are any restrictions on data sharing required? Specify how access will be
provided in case there are any restrictions.

Specify what methods or software tools are needed to access the data? Is
documentation about the software needed to access the data included? Is it
possible to include the relevant software (e.g. in open source code)?

_Making data interoperable_

Assess the interoperability of your data. Specify what data and metadata
vocabularies, standards or methodologies you will follow to facilitate
interoperability.

Specify whether you will be using standard vocabulary for all data types
present in your data set, to allow inter-disciplinary interoperability? If
not, will you provide mapping to more commonly used ontologies?

_Increase Data Re-use (through clarifying licences)_

Specify how the data will be licenced to permit the widest reuse possible

Specify when the data will be made available for re-use. If applicable,
specify why and for what period a data embargo is needed

Specify whether the data produced and/or used in the project is useable by
third parties, in particular after the end of the project? If the re-use of
some data is restricted, explain why

#####  Response

Data to Share- We believe that it is not necessary nor required to keep all
raw data forever or even to publish all raw monitoring data. This is mainly a
consequence of the large storage requirements in relation to an expected high
similarity of the data at different phases (e.g., nights and weekends).
Instead, the project is considering storing and publishing representative
samples of the collected raw data, e.g. capturing the span of one day. We also
consider publishing thinned-out data of longer periods (e.g. a month). In any
case, such data will be published unless IPR, confidentiality, or exploitation
plans are opposed to this.

Data Location- The Communication and Information Center (kiz) of UULM is
running OPARU, an (amongst others) OpenAire indexed OpenAccess server that
provides support for the publication of research data. CloudPerfect will,
whenever possible, rely on that repository for publishing their research data.
This will result in DOIs being created for any published data set or sets of
data sets.

The only hindrance we can foresee by now is that the size of some data
collections, in particular of raw data, exceed the maximum allowed size for
OPARU. If this threshold takes effect, other repositories such as Zenodo come
into play. These will be selected on a per-demand basis.

Restrictions- It is currently not planned by the consortium to provide data
sets with restricted access. Data will either be made available as OpenAccess
or not at all.

Data Access- All data generated in CloudPerfect is intended to be used by
software and machines. While it is possible to access and manually read raw
data, it is generally not useful. Instead, it is recommended to make use of
software for that purpose. While the CloudPerfect software can be used to read
and evaluate the data, we will also ensure that the data sets and their
formats are sufficiently well documented for others to write their own
software for accessing them.

Interoperability- It is currently unclear to what extent data and metadata
vocabularies, standards, and methodologies are applicable to data sets
collected by CloudPerfect. For time series data as for the raw monitored data,
Metrics 2.0 is an option.

Vocabularies and Ontologies- It is currently unclear to what extent standard
vocabularies and commonly used ontologies are applicable to data sets
collected by CloudPerfect.

License- Whenever possible, the data sets shall be made available under a
Creative Commons "Attribution ShareAlike 4.0 International License". Where
needed more restrictive licenses such as

Creative Commons "Attribution-NonCommercial-ShareAlike 4.0 International" or
Creative Commons "Attribution-NonCommercial-NoDerivates 4.0 International"
will be used. Whenever the release of data conflicts with a partner’s
exploitation strategy, the partner may pick a more restrictive license.

Release- Data will be made available for re-use as soon as possible. This is
at the very earliest the case with the submission of the respective
deliverables. We expect that usually the release of the research data aligned
with the deliverables will take around two months’ time. Where needed project
partners are granted an embargo time of 12 months.

Third Parties- CloudPerfect targets to make produced and published data
available to third parties unless these goals are contradicted by partners'
exploitation plans: this holds particularly for monitoring and profiling data.
With respect to raw data, not all monitored data will be published due to its
mere size, but instead one or multiple representative samples will be used.

###  Storage and Backup, Preservation and Data Security

The following questions are addressed.

How will the data be stored and backed up during the research?

How will you manage access and security?

Address data recovery as well as secure storage and transfer of sensitive data

What is the long-term preservation plan for the dataset? Specify the length of
time for which the data will remain re-usable.

#####  Response

Raw data used during the project will be stored in modern, reliable, and
highly available distributed databases such as MongoDB, Cassandra, and HBase.
These will form the bases of all data mining performed in the project. All
other form of data including meta-information and models will be contained in
data repositories that use a multi-device ZFS storage backend. In addition,
the data is stored in a local backup every hour and in a remote backup once a
day.

So far, we are not considering using, storing, or publishing any secure or
confidential data that needs special requirements with respect to secure
storage. In particular, data that comes from public sources such as production
systems will be anonymised before even introduced to CloudPerfect tools.

Currently, there are no costs for long term storage conceivable. According to
UULM policy, data published through OPARU with a DOI will be kept for at least
ten years (recommendation of the German Research Foundation). The life-span of
other data that will be publicly accessible (e.g. through data repositories)
will be clarified with the project's exploitation plans.

Specify the length of time for which the data will remain re-usable.

No plans exist to restrict the period of time for which the data remains
usable.

##  Data Set - CloudPerfect Software

This dataset includes the source code and the binary packages of the software
tools produced within the scope of CloudPerfect.

###  Data collection

The following questions are addressed.

What is the origin of the data?

How will the data be collected or created?

To whom might it be useful ('data utility')?

What is the size of the data?

What is the type(s) and format(s) of data?

#####  Response

CloudPerfect software is based on four distinct software prototypes inherited
from previous EU research initiatives and developed by different partners in
the consortium:

  * Cloudiator from the PaaSAge project (developed by UULM); 

  

  * 3ALib from the ARTIST project (developed by ICCS); 

  

  * Benchmarking Suite from the ARTIST project (developed by ENG); 

  

  * Profiling and Classification tool from IRMOS and ARTIST projects (developed by ICCS). 

  

Source code of these prototypes will be modified and improved during the
CloudPerfect project in order to increase their TRL level and integrate them
in homogeneous and coherent releases. Binary packages will be generated for
each release of the tools starting from the source code using automated
integration tools.

Although the precise size of the data will vary during the project, it will
stay in the scale of megabytes both for source code and binaries. Source code
consists mostly of raw files in various formats, mainly Java, Python, raw
text, XML and JSON. Binary packages will be installable packages. In order to
support multiple platforms, they will be created in different formats like
zip, rpm, deb, and jar.

The CloudPerfect software can be of interest of different stakeholders:

  * Developers interested in integrating with CloudPerfect tools, inspecting the source code, fixing defects, maintaining and/or evolving it; 

  

  * Cloud Adopters interested in using the CloudPerfect tools to profile their applications; 

  

  * Cloud Providers interested in installing CloudPerfect tools to benchmark their resources and optimize the usage of their hardware resources. 

  

###  Documentation and Metadata

The following questions and points are addressed.

What documentation and metadata will accompany the data? Specify standards for
metadata creation (if any). If there are no standards in your discipline
describe what type of metadata will be created and how.

_Making data findable, including provisions for metadata_

Outline the discoverability of data (metadata provision).

Outline the identifiability of data and refer to standard identification
mechanism. Do you make use of persistent and unique identifiers such as
Digital Object Identifiers?

Outline naming conventions used

Outline the approach towards search keyword

Outline the approach for clear versioning

#####  Response

The CloudPerfect software will be accompanied by a usage manual that will
explain the tool purpose and the basic instructions to use it. This manual can
be distributed within the distribution packages directly or available online.

Concerning metadata and discoverability, the software will be published on the
Zenodo  7  portal. This will guarantee:

  * A unique DOI assigned to each version of the software; 

  

  * A rich set of metadata associated to the software including description, authors and maintainers, version, release date, free keywords, grant number of funding projects, links to additional location for source code, documentation and binaries; 

  

  * Discoverability of metadata through the portal search functionality and programmatically using the OAI-PMH protocol; 

  

CloudPerfect will adopt the Semantic Versioning 2.0  15  scheme to assign a
unique version to each release of the software.

No particular naming conventions are in place for the software at the time of
writing.

The approach towards search keyword is not defined yet at the time of writing

###  Data Sharing and Re-use

The following questions and points are addressed.

_Making data openly accessible_

How will you share the data? Repository name(s). Specify where the data and
associated metadata, documentation and code are deposited

Are any restrictions on data sharing required? Specify how access will be
provided in case there are any restrictions.

Specify what methods or software tools are needed to access the data? Is
documentation about the software needed to access the data included? Is it
possible to include the relevant software (e.g. in open source code)?

_Making data interoperable_

Assess the interoperability of your data. Specify what data and metadata
vocabularies, standards or methodologies you will follow to facilitate
interoperability.

Specify whether you will be using standard vocabulary for all data types
present in your data set, to allow inter-disciplinary interoperability? If
not, will you provide mapping to more commonly used ontologies?

_Increase Data Re-use (through clarifying licences)_

Specify how the data will be licenced to permit the widest reuse possible

Specify when the data will be made available for re-use. If applicable,
specify why and for what period a data embargo is needed

Specify whether the data produced and/or used in the project is useable by
third parties, in particular after the end of the project? If the re-use of
some data is restricted, explain why

#####  Response

The CloudPerfect software will be published and open accessible through, at
least, two software repositories:

  * The GitHub ( _https://github.com/_ ) platform; 

  

  * The Zenodo ( _https://zenodo.org/_ ) portal; 

  

The location of software in those repositories will be clearly linked in the
CloudPerfect website. New versions of the software will be published as soon
as they become available without applying any embargo periods.

All the formats used both for source code (mainly Java, Python, JSON, XML) and
binaries (Java and Python bytecode, zip, deb, rpm) are standard in computing
science and compatible with most of existing platforms. This guarantees a high
level of interoperability with other software and runtime environments.

The CloudPerfect software will be open source and released under the Apache
License 2.0  8  . This will guarantee the full possibility of re-using the
software even for commercial purposes, under the condition of including a copy
of the license and a clear attribution.

###  Storage and Backup, Preservation and Data Security

The following questions are addressed.

How will the data be stored and backed up during the research?

How will you manage access and security?

Address data recovery as well as secure storage and transfer of sensitive data

What is the long-term preservation plan for the dataset? Specify the length of
time for which the data will remain re-usable.

#####  Response

For storage, backup, preservation and security of the software, CloudPerfect
relies on the technology and policies provided by the two repositories GitHub
and Zenodo where the software will be made available. They both have very
strong policies for these aspects. For instance, Zenodo metadata database is
backed-up every 12 hours with one backup per-week sent to a tape storage,
while GitHub stores each repository in at least three different locations plus
an off-site backup. More details can be found at
_http://about.zenodo.org/infrastructure/_ and
_https://help.github.com/articles/github-security/_ .

#  Next steps

The DMP will be updated over the course of the project whenever significant
changes arise, for example when new data is introduced, changes in consortium
policies, changes in consortium composition and external factors. Moreover, as
the DMP is a living document, information will be made available on a finer
level of granularity through updates, also in context of periodic
evaluation/assessment of the project. A second version of this deliverable
will reflect the updates.