CLOUD INFRASTRUCTURE - Ningapi.ning.com/files/ys89Oj1AWQ8jnPo7W7qPycGyrXzt0... · includes an...
Transcript of CLOUD INFRASTRUCTURE - Ningapi.ning.com/files/ys89Oj1AWQ8jnPo7W7qPycGyrXzt0... · includes an...
CLOUD INFRASTRUCTURE
TCBL 646133 DELIVERABLE 6.2
31st March 2016
Co-funded by
Horizon 2020
DELIVERABLE
PROJECT ACRONYM: TCBL
GRANT AGREEMENT N.: 646133
PROJECT TITLE: Textile & Clothing Business Labs
D 6.2: Cloud infrastructure
V5, 31.05.2016
AUTHORS: Brecht Vermeulen (iMinds) Dieter De Paepe (iMinds)
Jesse Marsh (City of Prato)
REVIEWERS: Paolo Guarnieri (City of Prato) Marc Boonstra (Waag Society)
Francesco Molinari (CCA)
CO-FUNDED BY THE EUROPEAN COMMISSION IN H2020 TCBL: TEXTILES & CLOTHING BUSINESS LABS, GRANT AGREEMENT N. 646133
Dissemination Level
PU Public
Co-funded by
Horizon 2020
3
EXECUTIVE SUMMARY This deliverable reports about the Cloud Infrastructure design and implementation activities
carried forward during the first nine months of the TCBL project (until March 2016). It consists
of three main parts:
A discussion of the envisaged role of the Cloud environment in the economy of the
project, as per the DoA provisions – namely to embed all of the ICT enabled services
supporting the TCBL ecosystem, particularly, but not limited to, the Knowledge
Spaces and the Business Services1;
An overview of the actual implementation process of the TCBL Cloud Infrastructure
and its early results;
A description of the software enablers that should be used in TCBL and have
therefore been evaluated by the host organisation iMinds.
These three parts represent the core sections (2, 3 and 4) of this Deliverable, which also
includes an Introduction (section 1) and some Conclusions (section 5). Section 2 details the
vision of TCBL on the usage of Cloud infrastructure for running its services. The services will
be run on the iMinds Cloud which is located in Ghent, Belgium and operated according to the
TCBL principles of data privacy, etc. (also outlined therein). iMinds personnel is administering
this Cloud.
Section 3 further describes the three different Cloud environments supported by iMinds:
The VMware environment, which is fully redundant and targeted towards production
services. Fully administered and supported by iMinds.
The Virtual Wall environment, which is targeted towards testing out software and
services. Fully administered and supported by iMinds.
The FIWARE node environment which is an implementation of a FIWARE node at
iMinds. iMinds follows only the FIWARE guidelines and can only support in a very
limited way users on this. FIWARE also does not support Windows™ operating
systems.
Network wise, the three Clouds are connected to Belnet, the Belgian NREN (research network
provider) which is connected to Geant, the EU research network. Up to 10Gb/s bandwidth is
available.
Section 4 identifies two software enablers that can take benefit from existing implementations:
namely Log event logging and central authentication. For Log event logging the FIWARE
Orion pub-sub software can be used or one of the implementations of the Tin Can API (xAPI).
On due time, the developers should evaluate further what is exactly needed for event logging.
The other evaluated enabler ‘identity provider’ is much more complex and depends on how the
TCBL services and user management will be structured. An Oauth2 provider implementation
seems the most straightforward to implement single-sign-on.
Due to the iterative path of development of the TCBL services, this deliverable chooses not to
specify the related interoperability requirements (APIs, data models, etc.) top down, as was
originally stated in the DoA. To fill in this gap, the following strategy is going to be followed:
add an interoperability section to the relevant technical deliverables as they become ready, in
particular D 1.2 and D 5.2 in month 18.
1 A Glossary of Used Terms is provided in the following page.
D 6.2: Cloud infrastructure
646133 - TCBL Textile & Clothing Business Labs
4
GLOSSARY OF USED TERMS
Term Definition and source
API Application Programming Interface allows to access a specific
application in a pre-determined way to allow another service or
application to exchange data and/or operations with it.
Authentication Verification of a user’s identity, i.e. through an Identity
Management function, generally accompanied but the
provision of certain profile information, in order to allow access
to one or more on-line services.
bpSquare2 A TCBL Business Service (see definition below) dedicated to
the exploration of the innovative business models depicted in
the Pilot Scenarios (see below) and to the improvement of
learning literacy of T&C industry players on selected software
solutions available on the market.
Context Broker A specific FIWARE Generic Enabler, the “Orion” Context
Broker is a publish-consumer service that organises the
subscriptions of producers and consumers in channels,
combined with a database to store the information
Event logging Automatic capture of system events, normally specific or pre-
defined types of user activity, and storage in log files that can
be accessed for analysis and use by other systems and
services (e.g. analytics, gamification, etc.).
FIWARE or FI-WARE3 A middleware platform, driven by the European Union, for the
development and global deployment of applications for Future
Internet.
Generic Enabler A general-purpose software component (sometimes in the
form of an API) that performs a task that can typically be used
by several applications, e.g. authentication, visualisation, etc.
Production Services Services that are running in their fully operational mode with
their final user base, as compared to services still in a testing
2 Adapted from TCBL DoA, various pp., modified after discussions during WP6 Brussels meeting (22nd –
23rd February 2016).
3 See https://en.wikipedia.org/wiki/FIWARE
D 6.2: Cloud infrastructure
646133 - TCBL Textile & Clothing Business Labs
5
Term Definition and source
phase.
TCBL Associates
Programme4
TCBL aims to gradually populate the ecosystem with T&C
actors covering the entire value chain by means of yearly calls
for expression of interest. Three types of Associates will be
looked for:
Business Labs (Design, Making, and Place)
Business Systems (Laboratories and Factories)
Business Service Providers.
TCBL Business Labs5 Physical and/or virtual spaces in which actors involved in
TCBL can draw on existing and emerging business models to
freely experiment with new ways of designing, making,
producing within specific locations in the countries covered by
the TCBL partnership. TCBL includes three types of labs:
Design Labs, Making Labs and Place Labs.
TCBL Business Services
(also known as Process
Support Services)6
Training and performance support facilities linked to innovative
business process models and other third party services
facilitating Business Labs and Business Systems in accessing,
assimilating and adapting the new knowledge created through
the Knowledge Spaces and in valorising it to enable new ways
of working in T&C to be developed and implemented.
TCBL Business Systems
(also known as Pilots)7
Pilot activities within TCBL based on existing and concrete
supply and value chains including social enterprises, primarily
in, but not limited to the T&C manufacturing sector, to
establish methodologies for “innovation transfer” of business
model elements.
TCBL Cloud Cloud environment, provided by iMinds, in which TCBL and
third party ICT enabled services can be installed and providing
generic software enablers to be used by different services.
TCBL Data Policy Application of the TCBL Principles to specific policies for the
management of data, including security, privacy,
confidentiality, value chain information, etc.
TCBL Gamification Tool8 Application of gamification methodologies - the use of game
4 Adapted from TCBL DoA, part B, pp. 13-14.
5 Adapted from TCBL DoA, various pp.
6 Adapted from TCBL DoA, various pp.
7 Adapted from TCBL DoA, Part B, p. 8 and p. 35.
D 6.2: Cloud infrastructure
646133 - TCBL Textile & Clothing Business Labs
6
Term Definition and source
thinking and game mechanics in non-game contexts to engage
users - to the TCBL business experimentation framework to
foster the engagement of the eco-system stakeholders.
TCBL Knowledge Spaces9 An online, interactive business model repository that hosts and
links to embedded and emergent materials and manufacturing
knowledge for T&C, as well as market, technology, economic
and social trend observations and policy watching.
Knowledge Spaces capture knowledge related to the practice
of T&C production, such as individual needs and desires, and
other aspects that define market conditions, analysing the
social interactions with that knowledge in order to
suggest/identify trends and options for the Business Labs and
Systems.
TCBL Pilot Scenario10 Innovative business process model to be explored by a
selected number of TCBL Pilots. TCBL Pilots can work
together to generate a Pilot Scenario, and then test it in a non-
public (confidential) section of the bpSquare platform.
Tin Can Tin Can is an API (similar to the Experience API or xAPI) that
captures [actor] [verb] [object] ‘Statements of Experience’ and
publishes them in a Learning Record Store (LRS).
8 Adapted from TCBL DoA, p. 14.
9 TCBL DoA, p. 14 and part B, p. 8.
10 Definition created during discussions in WP6 Brussels meeting (22nd – 23rd February 2016).
7
TABLE OF CONTENTS
EXECUTIVE SUMMARY ............................................................................................................ 3
GLOSSARY OF USED TERMS ................................................................................................. 4
TABLE OF CONTENTS ............................................................................................................. 7
1. INTRODUCTION TO WP6 AND TASK 6.2 ........................................................................ 9
2. ROLE OF THE CLOUD IN TCBL ..................................................................................... 11
2.1 A SECURE AND TRUSTED ENVIRONMENT FOR THE TCBL ECOSYSTEM ............................. 11
TCBL data policy ............................................................................................................... 11
RESPONSIBILITY .................................................................................................................... 12
2.2 A PLATFORM EMPOWERING THE TCBL COMMUNITY ....................................................... 12
TCBL hosting policy .......................................................................................................... 13
RESPONSIBILITY .................................................................................................................... 14
Main Cloud enablers ......................................................................................................... 14
3. THE TCBL CLOUD ENVIRONMENT ............................................................................... 16
3.1 CHOICE OF THE CLOUD PLATFORM ............................................................................... 16
3.2 INFRASTRUCTURE SETUP AND FUNCTIONALITIES ............................................................ 16
iMinds VMware platform .................................................................................................... 16
iMinds Virtual Wall ............................................................................................................. 17
FIWARE node ................................................................................................................... 19
iMinds Networking and Services ....................................................................................... 23
The TCBL Cloud Strategy ................................................................................................. 23
3.3 INSTALLATION REQUIREMENTS OF TCBL COMPONENTS ................................................ 23
vDiscover ........................................................................................................................... 24
bpSquare ........................................................................................................................... 24
TCBL.io ............................................................................................................................. 25
4. KEY TCBL ENABLERS ................................................................................................... 26
4.1 AUTHENTICATION ......................................................................................................... 26
4.2 EVENT LOGGING .......................................................................................................... 27
The Orion Context Broker ................................................................................................. 27
The Learning Locker ......................................................................................................... 29
5. CONCLUSIONS AND FUTURE STEPS .......................................................................... 31
LIST OF TABLES ..................................................................................................................... 32
LIST OF FIGURES ................................................................................................................... 33
DOCUMENT INFORMATION ................................................................................................... 34
Revision History ................................................................................................................ 34
D 6.2: Cloud infrastructure
646133 - TCBL Textile & Clothing Business Labs
8
Statement of originality ...................................................................................................... 34
Copyright ........................................................................................................................... 34
Disclaimer .......................................................................................................................... 34
Acknowledgements ........................................................................................................... 35
9
1. INTRODUCTION TO WP6 AND TASK 6.2
The description of WP6 “Scaling up and Sustainability” in the DoA reads as follows:
Work package six adopts a systemic and multidisciplinary approach in structuring
and modelling the TCBL ecosystem as a whole. Its overarching aim is to secure
the sustainability of project results in the long-term and to transform such results
into pivotal pillars in the quest for positive and lasting impact on EU businesses and
society. Taking a longer-term perspective, the activities will be oriented at creating
the conditions for a successful exploitation of both knowledge and technological
assets after the grant period. The activities conducted in this work package focus
on aspects that are complementary to the business planning activities that will be
carried out on homogeneous sub-systems in work package seven.
In this context, one of the main infrastructural elements considered key to the value
proposition of the TCBL ecosystem is an open Cloud environment that supports the integration
of different services. This is the purpose of Task 6.2, described in the DoA as follows:
This activity provides a common Cloud infrastructure for all of the ICT services
supporting the TCBL ecosystem, based on the FI-PPP’s FI-WARE Cloud, which
allows to host and experiment with Generic Enabler services. In an initial phase,
the task will collect the TCBL Cloud infrastructure requirements as to be able to
provide the best possible experimentation infrastructure. Based on the requirement
analysis and the state of the art of FI-WARE components, a (part of) the iMinds
iLab.t server infrastructure will be configured to support TCBL in the best fitting
way, which is expected to be either (i) maintaining and operating a native FI-WARE
node, to be accessed via the official FI-Lab portal, or (ii) realizing and operating a
dedicated common Cloud infrastructure, based on and compatible with FI-WARE
components, ran in isolation from the FI-Lab. Once the infrastructure is set up, this
task will provide the needed monitoring and technical support to keep the provided
infrastructure operational.
This deliverable D6.2 describes the setup of this Cloud infrastructure, including the following
key steps:
1. Choice of the actual platform and services on which to deploy the Cloud environment.
2. Configuration of the Cloud and installation of the first software components.
3. Identification of the key enablers to deploy for the TCBL Cloud environment.
On a less technical level, this activity has also in parallel consisted in the definition of how the
Cloud concept relates to the TCBL approach and the defining elements for Cloud services in
the eyes of its users. This includes the definition of a data policy for TCBL and some of the
main principles for hosting, as described in the following section.
The original view of the development path for Task 6.2 as set forth in the TCBL DoA foresaw
an evaluation based on the requirement analysis and the state of the art of FI-WARE
components. And after evaluation, a (part of) the iMinds iLab.t server infrastructure would be
configured to support TCBL in the best fitting way, which was expected to be either (i)
maintaining and operating a native FI-WARE node, to be accessed via the official FI-Lab
portal, or (ii) realizing and operating a dedicated common cloud infrastructure, based on and
compatible with FI-WARE components, ran in isolation from the FI-Lab.
D 6.2: Cloud infrastructure
646133 - TCBL Textile & Clothing Business Labs
10
As early as the project kickoff meeting, it became clear that FIWARE as such did not offer the
ideal Cloud solution for TCBL, when compared to other specific platform environments that
iMinds could make available.
Besides that, it soon became clear that the concrete configurations and interoperability
solutions (APIs, data models, etc.) related to each prospective TCBL service could not be
defined upfront (because a simple adoption of Generic Enablers does not solve this) and
turned into technical specifications of universal nature, but were to be seamlessly and
collaboratively identified for each service installation ‘ad hoc’, with and by the TCBL Partners
and Associates interested in forming Closed User Groups for that installation. The result is that
the prospects for interoperability now reside in the flexibility and adaptiveness of the TCBL
Cloud and its software enablers, rather than the ‘a priori’ definition of data models and
specification of APIs11.
Due to the immature stage of development of the TCBL services, this deliverable cannot
specify the interoperability requirements (APIs, data models, etc.) related to them, as was
originally stated in the DoA. To fill in this gap, the following strategy is going to be followed:
Add an interoperability section to each technical deliverable due in the project (which include
D6.1, D5.1 and D1.1)
11 A summary of the installation requirements of the key TCBL components is provided in section 3.3
below.
11
2. ROLE OF THE CLOUD IN TCBL
2.1 A SECURE AND TRUSTED ENVIRONMENT FOR THE TCBL
ECOSYSTEM
The Cloud is generally considered as a technical ICT infrastructure: an efficient way to provide
computing services by installing applications on remote servers and running them through
apps and browsers on multiple devices. In addition, the Cloud allows to store and share
documents and information, both at the workplace and on the move. The FI-WARE paradigm
further introduces the concept of the Cloud as a Europe-wide service infrastructure with a set
of Generic Enablers, allowing for the creation of local or application-specific instances of the
Cloud with several basic software components already installed and active.
In the minds of many businesses and users – of the sort that will be using TCBL services – the
Cloud also raises a series of issues together with its convenience of use. The advantage of
ubiquitous computing is offset by a lack of clarity of exactly where information and software is
being stored and who is managing it. Wikileaks raises additional questions of the jurisdiction
over Cloud services and the possibility for governments to access data which is otherwise
considered private. This growing suspicion is paralleled by the commercial use of personal
information, with the accuracy of digital marketing giving the impression of monitoring every
step we take. An increasing number of services allow to log in using Facebook, Twitter,
Google, or Linkedin, but despite the warnings and features users are left with the sensation of
a lack of control over what information is being passed from one service to the next.
TCBL addresses these issues as the necessary first step before looking at any of the technical
advantages offered. The TCBL Cloud must first and foremost provide a safe, secure, and
trusted environment within which to carry out on-line interaction in the TCBL ecosystem. This
cannot be achieved through the necessary technical and operational measures alone, but
must also occur through visible evidence coupled with effective communication, associating
the TCBL Cloud with the very identity and principles of the TCBL ecosystem as a whole. This
approach guides the management policies outlined in the following sections.
TCBL DATA POLICY
TCBL is a multi-platform environment that, among other objectives, aims to attain a broad
impact through diffused social media platforms such as Facebook and Twitter on the one
hand, and provide services based on analytics of user interaction (gamification, trending, etc.)
on the other. In addition, the TCBL Cloud aspires to host services that will be managing critical
and confidential information of participating businesses. Each of these issues pulls in different
directions as concerns privacy and data policies, leading to the need for a common data policy
for TCBL as a whole.
This issue is linked to discussions elsewhere in the project (for instance to define evaluation
criteria for Labs and Pilots) related to the need for a common set of principles that define the
TCBL community. The principles identified at the project level, i.e. the general principles on
which the identity of the TCBL brand are based, are as follows: Curiosity (exploration and
innovation), Viability (business soundness, added value to the community), Durability
(environmental sustainability and reduction of waste), Multiplicity (value of diversity and
multiple approaches), Openness (trust, sharing, participation, transparency), Respect (privacy
and authorship, dignity of the people and places), and Responsibility (reliability, accountability,
D 6.2: Cloud infrastructure
646133 - TCBL Textile & Clothing Business Labs
12
and professionality). From there, the key elements of a TCBL data policy have been identified,
as follows.
Principle Data Policy
curiosity Data is a common scientific good, and should have clear licensing to facilitate access from external sources.
viability Data services should be part of viable business models and maintenance policies clearly stated.
durability Data services should rely on energy-efficient storage and transmission infrastructures.
multiplicity Interoperability should facilitate the use of different formats and standards while promoting convergence.
openness Data should be open by default and data services available to the community.
respect Data services should respect the confidentiality and privacy interests of those who provide or generate data.
responsibility Data services should embed accountability to guarantee privacy, security and service quality.
Table 1. The TCBL Data Policy
These principles are applied to the management of the TCBL Cloud as well as all TCBL
services, in particular those dealing with personal data and/or supply chain information.
2.2 A PLATFORM EMPOWERING THE TCBL COMMUNITY
Once an appropriate data policy is established for the TCBL Cloud, we can better explore the
Cloud paradigm from a functional point of view. TCBL does not intend to propose a tightly
integrated “do-it-all” platform that aspires to satisfy all of their needs. It rather favours the
Cloud as an open platform that can progressively integrate a range of both ‘internal’ (to the
project) and ‘external’ platforms and services through “light”, API-based interoperability (rather
than deep integration of functions and unique data models). This has several advantages:
Different user types can pick and choose the services that fit them best, much like a
user selects apps on a smartphone and selects those to appear on the home screen.
The TCBL platform can bring in new services when the need arises; for instance, it is
possible that in the future we will need a logistics planning service.
This approach avoids lock-in to a particular solution or approach to solving a need,
since we can easily have competing services in the ecosystem and focus on those
that work best.
The “glue” holding together the different applications and providing a common environment is
basically the Cloud itself, for those who wish to install their services on it, and common
authentication and profile-passing APIs for those wishing to remain outside. Functional
interoperability can be determined on a case-by-case basis, using Cloud data stores if and
when necessary.
D 6.2: Cloud infrastructure
646133 - TCBL Textile & Clothing Business Labs
13
Since those having access to the TCBL Cloud consist of a Closed User Group (CUG) (namely
the set of project partners plus the Associate Labs and Pilots), it is also possible to experiment
with a distributed usage of services that were originally conceived for large corporations. In
this case, different participating Labs and Businesses can be considered as different
departments of a company, or the partnerships participating in specific value chain scenarios
can be considered as different companies within a holding group. Whatever the parallel, in this
sense the Cloud is the company, in the sense that it provides a centralised but open point of
reference for managing data flows, access permissions, etc. across a broad range of
participating enterprises.
This allows for small-scale artisans and SMEs to gain access to software environments that
are normally precluded to them, and thus provides a new level of empowerment to both the
participating enterprises and the composite value chains they form within TCBL. Conversely,
and perhaps more interesting from a business development standpoint, this approach has the
potential to significantly extend the market for the participating ICT service providers. There is
currently a gap between mass distribution of generic productivity software (e.g. Microsoft
Office), often ‘personalised’ by local software houses, and the sophisticated platforms that
target large corporations (e.g. ERP and CRM). The related licensing policies reflect that
market structure.
In addition, relatively closed and specific markets, such as the textile and fashion industries,
tend to be dominated by a few software providers who attempt to cover the entire business
cycle as a means of locking in customers, with software suites piecing together different
functionalities and business models that have failed to open up due to a low degree of
competition. Cloud based SaaS approaches have begun to appear, offering broader licensing
options, but this is still an immature market dominated by the logic of vendor lock-in. Needless
to say, these comprehensive platforms also tend to support and promote the fast fashion
business model that most enterprises attracted to TCBL are trying to break away from.
TCBL thus offers an interesting opportunity for software providers to experiment new markets
and solutions. The set of Associate Business Labs and Pilots constitutes a closed user group
(in the sense of an identifiable set of users) that covers entire supply chains in emerging
market spaces, and can thus be used to capture emergent requirements for the services that
will be required to support sustainable manufacturing in the future. TCBL MoUs with providers
and users can include specific Non Disclosure Agreements (NDA) on the side of TCBL
Associates as well as delimited time frames for experimentation. It is then in the interests of
the TCBL community to co-define, together with the ICT service provider, the best licensing
strategy that allows for uptake in new markets while guaranteeing long-term sustainability and
support for the vendor.
TCBL HOSTING POLICY
All services in the Cloud run on the iMinds infrastructure, located in Gent, Belgium in two
datacenters about 5 km from each other (for redundancy). The Cloud is administered fully
(bare metal servers, network, firewalls, datacentre) by iMinds personnel. The TCBL project
website will allow ecosystem participants to view these facilities (without being too specific, for
obvious security reasons) and see the people who work there, including staff photos and
quotes from interviews regarding the kinds of measures they take to ensure security and
reliability. In addition, iMinds policies with respect to EU and Belgian law for privacy and data
security will also be published, within a possible of maximum transparency.
D 6.2: Cloud infrastructure
646133 - TCBL Textile & Clothing Business Labs
14
iMinds thus takes a leading role, on behalf of TCBL, in compliance with the TCBL principles
and data policy, enacting the measure highlighted in the table below:
Principle iMinds measures for compliance
curiosity The services running on the iMinds Cloud are not publicly announced. Activity log is individually licensed by the end user and, unless otherwise specified, openly accessible.
viability The iMinds Cloud is a production environment for running services, already operational as a sustainable service.
durability iMinds takes care to ensure state-of-the-art measures for energy efficiency and minimum environmental impact of its hosting infrastructure.
multiplicity The core enablers of authentication and activity log, together with the availability of shared data stores, aim to attain frugal yet effective interoperability across an open and unknown range of services. In addition, multiple services can be run, even multiple instantiations of the same service, e.g. for testing.
openness All TCBL Partners as well as TCBL Associate Service Providers can run services on the iMinds Cloud.
respect iMinds runs the services of TCBL with the same guarantees of security as all its other services. Protection of individual data will be further explored during the project, according to the “entitlement” approach.
responsibility iMinds personnel is responsible for the hardware, network and operating system. Part of the Cloud is fully redundant.
Table 2. iMinds Policy Compliance
Throughout the TCBL project, iMinds will also ensure, together with the TCBL technical
partners, the compliance of all platforms and services installed on the TCBL Cloud with the
TCBL data policy. The long-term management of these issues will be one of the elements for
development in Task 6.5 “Business ecosystem governance”.
MAIN CLOUD ENABLERS
In line with the above logic, two key enablers have been identified that contribute to the
branding of the TCBL Cloud as a secure and trusted environment as well as enabling the kind
of open, multi-platform environment described above. They are:
Authentication
The authentication services allow users to Log in with TCBL on platforms and services
that participate in the TCBL Cloud environment, whether or not they are actually
installed on the Cloud itself, in a similar way that today one can log in to many
services through the user’s Facebook or Google account. This has the obvious benefit
of simplifying the use of multiple platforms, but also provides a common brand: ICT
service providers using our Log in with TCBL feature will also be checked for
compliance with the TCBL data policy. In addition, the TCBL authentication feature will
include the ability for users to identify what profile information can be passed on to
D 6.2: Cloud infrastructure
646133 - TCBL Textile & Clothing Business Labs
15
another application both by default and on a case by case basis. Log in with TCBL is
therefore an important identity feature for the Cloud, providing the user with a
reassuring experience and reinforcing the benefits of belonging to a value-based
community.
Event logging
Services in TCBL will often use or require event logging for purposes of gamification,
data harvesting for analytics, user profiling, etc. TCBL will provide this facility as a
Cloud enabled one, making sure the end user has the maximum control over his or
her data. The concept of Entitlement, as espoused by Usman Haque12, together with a
form of data licensing, as explored in the CIP ICT PSP Citadel… on the Move
project13, will be explored. In addition, we will also be exploring issues related to group
data ownership, as will likely be the case for supply chain data in TCBL value chains.
With the control of event logging in the hands of end users, it will then be up to
applications and services to demonstrate the benefits of opening up users’ own data
and reassure them of the appropriate use that will be made of it.
Issues regarding the technical implementation of these core enablers are discussed in
Chapter 4 of this document.
12 https://hbr.org/2015/02/managing-privacy-in-the-internet-of-things
13http://ilmiolibro.kataweb.it/libro/informatica-e-internet/119315/the-citadel-open-data-commons/
16
3. THE TCBL CLOUD ENVIRONMENT
3.1 CHOICE OF THE CLOUD PLATFORM
At iMinds there are different platforms for hosting and testing services, each with its own
features and specifics. In the following section these services are described in more detail,
together with the criteria for selection of the most appropriate components for the TCBL Cloud.
VMware platform, fully redundant (compute, storage, network), redundant cooling in
the datacentre, UPS and generator fed and possible to run all operating systems
(including Windows Server). Administrator help is needed for initial setup of machines.
IPv4 and IPv6 supported.
The Virtual Wall platform, which is more oriented towards temporary (Linux) test
setups but on which scaling can be tested and which is fully automated. IPv4 and IPv6
supported.
A FIWARE node which is running on the Virtual Platform and which is compatible with
FIWARE; as such it supports only Linux (limited range of distributions) virtual
machines and only IPv4. Authentication is not administered by iMinds but by FIWARE
central services.
3.2 INFRASTRUCTURE SETUP AND FUNCTIONALITIES
IMINDS VMWARE PLATFORM
The VMware setup is the most versatile and most redundant setup of the iMinds platforms. All
computing, networking and storage is redundant and there is a passive offline backup in a 2nd
datacentre 5km away.
In total the VMware setup has 72 CPU cores, 900GB RAM and 80TB storage. RAM usage is
guaranteed to be not oversubscribed (as memory oversubscription significantly limits
performance because of swapping to disk).
The VMware setup makes it possible to run all operating systems (e.g. including Windows
Server). iMinds system administrators need to do the initial installation of new machines.
D 6.2: Cloud infrastructure
646133 - TCBL Textile & Clothing Business Labs
17
Figure 1. The iMinds VMware Platform
IMINDS VIRTUAL WALL
The Virtual Wall consists out of about 400 physical servers that can be used in an automated
and remote way to test out or benchmark services. There is also a variation of hardware
available (see http://doc.ilabt.iminds.be/ilabt-documentation/virtualwallfacility.html in such a
way that e.g. vertical or horizontal scaling can be investigated). This facility is not fully
redundant and is also not UPS powered. The most important features are that there is access
to physical servers (versus virtual), that a multitude of servers is available and that no system
administrator is needed to configure the servers.
Figure 2. The iMinds Virtual Wall
The hardware available is summed up in the following table:
D 6.2: Cloud infrastructure
646133 - TCBL Textile & Clothing Business Labs
18
Type Number of nodes Description
PC gen 1 100 2x Dual core AMD opteron 2212 (2GHz) CPU, 8GB RAM, 4x 80GB harddisk, 4-6 gigabit nics per node
PC gen 2 100 2x Quad core Intel E5520 (2.2GHz) CPU, 12GB RAM, 1x 160GB harddisk, 2-4 gigabit nics per node
PC grid 22 2x Dual Core AMD opteron 270 (2GHz) CPU, 4GB RAM, 1x 80GB harddisk , 1 gigabit nic per node
PC gen 3 110 2x Hexacore Intel E5645 (2.4GHz) CPU, 24GB RAM, 1x 250GB harddisk, 1-5 gigabit nics per node
PC gen 4 28 2x 8core Intel E5-2650v2 (2.6GHz) CPU, 48GB RAM, 1x 250GB harddisk, gigabit and 10gigabit connections
GPU 10 1x 6core Intel E5645 (2.4GHz), 12GB RAM, 4x 1TB disk in RAID5, 4x Nvidia Geforce GTX 580 (1536MB).
PC gen 5 25 1x 4 core E3-1220v3 (3.1GHz), 16GB RAM, 1x 250GB harddisk, 2-10 gigabit connections
Table 3. iMinds Virtual Wall Hardware Configuration.
A graphical user interface is present to configure the Virtual Wall (and similar testbeds around
the world, e.g. in Europe, the US, South Korea, Brazil, and Japan), as shown below:
Figure 3. Virtual Wall Configuration Interface.
The map below shows similar and compatible testbeds around the world:
D 6.2: Cloud infrastructure
646133 - TCBL Textile & Clothing Business Labs
19
Figure 4. Virtual Wall Compatible Testbeds in the World.
FIWARE NODE
As can be seen in the picture below, FIWARE (https://www.fiware.org) is a complex EU-
funded programme consisting of different parts:
FIWARE lab is a distributed infrastructure which can run Linux based virtual
machines. It provides a Cloud platform for developing and testing applications (“a
sandbox for non-commercial use”).
Generic enablers are essentially software components and APIs that can be used in
applications. They provide an open, public, royalty-free set of open specifications and
reusable software components allow fast and easy prototyping and development of
future internet applications. (see http://catalogue.fiware.org/ )
A specific Accelerator programme funds SME and start-up companies to support
innovative application development using FIWARE and thus create economic impact.
FIWARE LAB(federated openstack cloud)
GENERICENABLERS
ACCELERATORPROGRAMME
D 6.2: Cloud infrastructure
646133 - TCBL Textile & Clothing Business Labs
20
Figure 5. Elements of the FIWARE Programme.
FIWARE LAB
The most relevant elements for TCBL, and in fact the elements that are mentioned in the DoA,
are the FIWARE Lab (to be used as the Cloud environment) and the generic enablers (to
promote interoperability between TCBL services and platforms). At the TCBL Kickoff meeting
in July 2016, however, it immediately appeared that FIWARE Lab misses some key features
that are needed for TCBL services, the most important being support for Windows Server
images. An additional drawback, this time a critical one for the reliability of TCBL services, is
the lack of access for node owners such as iMinds to some centralised services such as
authentication, also important for instance for debugging issues. The figure below illustrates
these limitations more clearly.
Figure 6. Administration Rights in the FIWARE Lab Platform.
GENERIC ENABLERS
The second element from FIWARE mentioned in the TCBL DoA are the Generic Enablers,
which are a set of software components and APIs that are to some degree independent of the
FIWARE Platform itself but contribute to offering a flexible service for the development of
other, specific applications. Indeed, they are generally reusable Open Source modules that
have been validated for compatibility with FIWARE and each other. This means that TCBL can
make use of the FIWARE Generic Enables independently of whether or not it uses the
FIWARE Lab infrastructure as its Cloud platform.
Central (portal, keystone authentication, image distribution,
platform choice, platform upgrades, etc)
Infrastructure owner
(iMinds iLab.t)
Infrastructure owner
Infrastructure owner
Accelerator projects marketing and funding
Software(generic
enablers)
SoftwareInstallers
(blueprints)
D 6.2: Cloud infrastructure
646133 - TCBL Textile & Clothing Business Labs
21
The Generic Enablers in FIWARE14 are grouped according to a general classification as
shown in the figure on the following page.
Figure 7. Classes of FIWARE Generic Enablers.
As one can see, the generic enablers are very versatile and cover a broad spectrum of
functionality. On the other hand, a closer inspection of the Generic Enablers available on the
FIWARE website reveals an uneven state of development, with some important elements at
an immature stage of development or with a limited user base. This would make it difficult to
follow the implementation path foreseen in the DoA, i.e. identify the appropriate enablers,
install them in the TCBL instance of the Cloud, and then distribute the related specifications
and APIs to interested partners and parties.
The strategy adopted is therefore a more interactive co-design approach towards defining the
most appropriate set of TCBL Generic Enablers. This involves a process whereby a TCBL or
14 http://www.fiware.org/tour-guide
D 6.2: Cloud infrastructure
646133 - TCBL Textile & Clothing Business Labs
22
Associate Service software developers first identify Generic Enablers that could be useful for
the services they intend to provide to TCBL. From there, the iMinds team can then identify the
best approach to have that specific functionality deployed on the Cloud.
This approach is best illustrated with a concrete example. Let us suppose that there is a need
for big data analysis (and we are already aware that there is this need in the context of Task
1.4 for instance). FIWARE has a Generic Enabler called Cosmos15 that appears to carry out
the required functionality. On the other hand, Cosmos only supports batch processing through
the standard Hadoop16 framework. The iMinds environment, through the Tengu platform17
which instead supports a multitude of frameworks including Hadoop but also Spark, Storm,
MongoDB, Cassandra and others.
Figure 8. The iMinds Tenqu Platform.
In addition, Tengu also supports batch and streaming big data analysis. The choice of the path
to follow thus depends on the exact needs of the specific service environment.
15 http://catalogue.fiware.org/enablers/bigdata-analysis-cosmos
16 http://hadoop.apache.org/
17 http://tengu.intec.ugent.be
D 6.2: Cloud infrastructure
646133 - TCBL Textile & Clothing Business Labs
23
IMINDS NETWORKING AND SERVICES
For all of the above-mentioned platforms, the iMinds networking specifications and services
are the same:
Redundant connection to Belnet, the Belgian NREN which is connected to Geant.
Available bandwidth of 10Gb/s from the iMinds Cloud towards the Internet. From the
Internet to the iMinds Cloud available bandwith is 10Gb/s from research networks and
700Mb/s from the commercial Internet.
IPv4 and IPv6 public IP addresses (Note that IPv6 is not available through FIWARE)
Possibility to sign SSL certificates for free when the domain name ends in
ilabt.iminds.be (thus a paid for option for most TCBL services).
All the above mentioned infrastructure is maintained by iMinds personnel and is located in
Ghent (BE), hosted in buildings of the Ghent University.
THE TCBL CLOUD STRATEGY
On the basis of the above options and considerations, the following strategy for the TCBL
Cloud environment has been defined:
TCBL will, for the foreseeable future, aim to maintain compatibility with the FIWARE
Lab Cloud environment, but not use its services directly due to limitations of platform
support and administration access.
TCBL production services (i.e. operational to the public) run on the iMinds VMware
cluster. The main reason for this is the level of redundancy available in order to
guarantee service reliability.
The iMinds Virtual Wall is used for testing software, due to its flexibility and ease of
configuration.
While TCBL continues to support the concept and available suite of FIWARE Generic
Enablers, it does so with a critical eye. Selection and installation of Generic Enablers
(including the CKAN Open Data portal and the FIWARE Context Broder, specifically
mentioned in the DoA) will take place on a case-by-case basis, on-demand as required by
TCBL and third party service providers, with the option to adopt alternative approaches where
appropriate.
The means that the specification of interoperability requirements related to the ICT
components that make up the Knowledge Spaces and the Business Services, as well as
potential future services, is carried out as needs arise in a co-design approach, rather than in
a top-down fashion. The on-going results of this interaction between the iMinds Cloud
responsibles and the other technical TCBL partners will be reporting in the future deliverables
of the specific activities, notably for WP 1 “Knowledge Spaces, WP 5 “Business Process
Support” and Task 7.4 “Service SME Engagement”.
3.3 INSTALLATION REQUIREMENTS OF TCBL COMPONENTS
Activities in Task 6.2 have included an exploration of the specific options and requirements for
installation of the key service components on the TCBL Cloud environment. The main
components addressed to date have included:
vDiscover (DITF) is the core component of the TCBL Knowledge Spaces
D 6.2: Cloud infrastructure
646133 - TCBL Textile & Clothing Business Labs
24
bpSquare (Skillaware) is the core platform for the TCBL Business Services
TCBL.io (Waag) is a platform (not foreseen in the DoA) supporting interaction
between the Business Labs
The following summarises the requirements identified for each component and the state of
advancement of installation.
VDISCOVER
vDiscover requires an Apache web server + PHP + MySQL or MariaDB as a basis. This can
be hosted in any virtual machine, and as a consequence on any of the Cloud environments
available to TCBL. The vDiscover production site will be hosted on VMware, while the test
sites for the components currently under development in WP1 are currently being installed on
the iMinds Virtual Wall.
BPSQUARE
bpSquare is a more complex service environment, with the following requirements.
Hardware Recommendations Software Requirements
Front-End Server CPU Speed: 2.0 GHz 64-bit
processor.
# of CPU: 8 core.
RAM: 16 GB.
HDD: 80 GB (depending on the
space required for the contents
stored into the internal Storage).
Windows Server 2012 R2.
IIS 8.5.
.Net Framework 4.6.
Windows Service CPU Speed: 2.0 GHz 64-bit
processor.
# of CPU: 8 core.
RAM: 32 GB.
HDD: 60 GB.
Windows Server 2012 R2.
.Net Framework 4.6.
Database Server As indicated in Microsoft website
for the installation of SQL Server
2012.
Windows Server 2012 R2.
Microsoft SQL Server 2012
Standard or Enterprise (Full Text
not required) including Data Base
Services, Integration Services,
Analysis Services.
Microsoft SQL Server
Management Studio.
Table 4. bpSquare Cloud Requirements
The main issue encountered for installation of bpSquare on the TCBL Cloud is the licensing
costs for Windows Server and, above all, the SQL server.
Currenly, the Front End Server and Windows Service are being installed on VMware (required
to host Windows), while other more feasible options are being explored for the database
D 6.2: Cloud infrastructure
646133 - TCBL Textile & Clothing Business Labs
25
server, including a possible porting to a more economical platform (using Microsoft SQL
express server).
TCBL.IO
The TCBL.io platform is an adaptation of the fablabs.io platform, a Ruby on Rails web
application developed by Fablab Barcelona to support the global network of Fab Labs. The
work is being carried out by TCBL partner Waag as an instantiation of the Business Lab
Framework of WP3.
Being a native Open Source platform, TCBL.io can be hosted on Ubuntu Linux 14.04 on all
Cloud platforms. As the on-going work under way at Waag becomes ready, it will be hosted
according to the general TCBL Cloud strategy: production site on VMware and test sites on
the Virtual Wall.
26
4. KEY TCBL ENABLERS
The two core General Enablers described in Chapter 2 were identified at the project Technical
Task Force meeting in Brussels on 22-23 February, 2016. Since then, in coherence with the
strategy for the Generic Enablers described previously, various options have been identified
for implementation.
4.1 AUTHENTICATION
The goal is to have a central repository of user profiles, with the necessary hooks for other
services to use these profiles. OpenID and OAuth are the two main candidates for this.
FIWARE Keyrock18 is Generic Enabler providing these functionalities as an Identity
Management tool, described as follows:
“Identity Management covers a number of aspects involving users' access to
networks, services and applications, including secure and private authentication
from users to devices, networks and services, authorization & trust management,
user profile management, privacy-preserving disposition of personal data, Single
Sign-On (SSO) to service domains and Identity Federation towards applications.
The Identity Manager is the central component that provides a bridge between
IdM systems at connectivity-level and application-level. Furthermore, Identity
Management is used for authorising foreign services to access personal data
stored in a secure environment. Hereby usually the owner of the data must give
consent to access the data; the consent-giving procedure also implies certain
user authentication.”
Keyrock is also used for FIWARE authentication and services. Keyrock can in theory be
installed stand-alone19, but the requirements are so wide (depends on keystone and horizon
which is typically used by openstack) that installation problems are likely to arise.
Other Oauth2 provider implementations are available,20 that can blend in with an existing
identity manager/portal and provide only the needed Oauth2 services. Different options can be
appropriate for specific requirements (e.g. where and how will the accounts and profiles be
stored, which profile attributes are needed), and depending on the language of the IdM/portal
implementation (e.g. internal LDAP, database or others), the specific implementation can be
selected and installed.
18 http://catalogue.fiware.org/enablers/identity-management-keyrock
19 http://fiware-idm.readthedocs.io/en/latest/setup.html#production-guide
20 http://oauth.net/2/
D 6.2: Cloud infrastructure
646133 - TCBL Textile & Clothing Business Labs
27
4.2 EVENT LOGGING
The TCBL meeting in Brussels also expressed the need for a central service to log events of
users in the different TCBL services. An important requirement was also that individual users
are able to directly decide what kind of information is to be logged and which services can
access that information, which in turn means that the event log would need to filter access to
stored logs on the basis of user permissions.
THE ORION CONTEXT BROKER
One of the candidates for event logging is the FIWARE “Orion” Context Broker as originally
mentioned in the TCBL DoA. The Orion context broker works as shown in the figure below
which is the scheme of a typical publish-consumer service. On the left, you see context
producers and on the right context consumers. In the middle, the service organises the
subscriptions of producers and consumers in channels, combined with a database to store the
information.
Figure 9. The Orion Context Broker.
Orion implements the OMA (Open Mobile Alliance) NGSI (Next Generation Service Interfaces) 9 and 10
interfaces. The NGSI architecture is shown below to show the context of NGSI 9 and 10:
D 6.2: Cloud infrastructure
646133 - TCBL Textile & Clothing Business Labs
28
Figure 10. The NGSI Service Architecture.
The functions of NGSI 9 (Context Entity Discovery Interface) and 10 (Context Information
Interface) are as follows:
Interface Functions Operations
NGSI9 Register
Search and
Subscribe for context sources
registerContext
discoverContextAvailability
subscribeContextAvailability
updateContextAvailabilitySubscription
unsubscribeContextAvailability
NGSI10 Query
Update and
Subscribe to context elements
updateContext
queryContext
subscribeContext
updateContextSubscription
unsubscribeContextSubscription
Table . NGSI Context Interfaces.
Orion can be installed in several ways, all compatible with the iMinds Cloud models described
above.
Install the packages with yum on Centos 6.x21. The MongoDB database can be
installed separately if needed.
Orion can also be installed using Docker containers.22 This is more oriented towards
temporary testing.
21 http://fiware-orion.readthedocs.io/en/develop/admin/install/index.html#installing-orion
22 http://fiware-orion.readthedocs.io/en/develop/user/docker/index.html
D 6.2: Cloud infrastructure
646133 - TCBL Textile & Clothing Business Labs
29
Orion appears to be a fairly mature enabler from FIWARE.23 It is not specifically targeted
towards user’s event tracking on multiple services, but it can be used in that way by
augmenting the services to publish data towards Orion.
THE LEARNING LOCKER
Another option for event logging, suggested in the Brussels workshop, is the
LearningLocker24, which proposes to ‘Store, Sort and Share Learning Data with our Open
Source Learning Record Store’. For this, the Experience API (xAPI)25, very similar to the Tin
Can API26 is used. The Learning Locker is specifically targeted to track:
Mobile Learning
Serious Games
Simulations
Informal Learning
Real World Performance
So-called ‘Statements of Experience’ are published in a Learning Record Store (LRS), e.g.
implemented in a MongoDB database. The web service allows clients to read and write
experiential data in the form of “statement” objects.
Simple Tin Can statements take the general form of “[actor] [verb] [object]”. These labels
coincide with the field names on a statement object. So, in conveying the information that
“Sally experienced ‘Solo Hang Gliding’”, we can quickly spot “Sally” as the actor,
“experienced” as the verb, and “Solo Hang Gliding” as the activity. Ignoring the structure of the
specific parts, the statement object itself would take this structure in JSON format:
{
"actor": "Sally",
"verb": "experienced",
"object": "Solo Hang Gliding"
}
Tin Can also provides facilities for more complex statement forms, a built in query API to help
filter statement streams, and a state API that allows for a sort of “scratch space” for consuming
applications. All communication may be done securely via SSL or OAuth.
On first sight, both Orion and xAPI can be useful in the TCBL context (‘log events of users in
the different TCBL services’) while xAPI fits probably better the limited use case.
Implementations of Tin Can are more commercial - several vendors offering products27
23 http://fiware-orion.readthedocs.io/en/develop/index.html
24 http://learninglocker.net
25 https://learninglocker.net/xapi/
26 https://tincanapi.com/
27 https://learninglocker.net/customers/
D 6.2: Cloud infrastructure
646133 - TCBL Textile & Clothing Business Labs
30
including Learning Locker. Tin Can has both an Open Source and an enterprise version,28 so it
needs to be seen if the Open Source version has enough features to do the job.
This will require a concerted effort between WPs 1 and 5, which both intend to make use of
event logging. In the coming months, a more detailed listing of current and future requirements
for this service will allow to evaluate the most appropriate option between the Open Source
Tin Can / xAPI, the Learning Locker implementation, or the Orion publish-subscribe service.
.
28 https://learninglocker.net/get-started/
31
5. CONCLUSIONS AND FUTURE STEPS
Deliverable 6.2 completes the round of M9 reports of ongoing technical work within the TCBL
WP6, with the global aim of delivering the necessary infrastructure for enabling seamless and
fruitful interactions within the T&C actors belonging to our ecosystem.
In this context, the short-term goal for Task 6.2 (realizing and operating a dedicated common
cloud infrastructure) can be said to have been achieved.
However, as a completion of the global aim of WP6, we will need to closely follow the planned
development phases of WPs 1 and 5, with the key milestone at project month 18 (D 1.2 and D
5.2.1). Here, the final configuration of the authentication and event logging services will need
to be fully operational together with the service environments they are to support. From there,
Task 6.2 will continue to accompany the development and instantiation of TCBL services,
adapting to the requirements of enabling services on-demand as defined in the strategy set
forth in this document.
32
LIST OF TABLES
Table 1. The TCBL Data Policy................................................................................................. 12 Table 2. iMinds Policy Compliance ........................................................................................... 14 Table 3. iMinds Virtual Wall Hardware Configuration. .............................................................. 18 Table 4. bpSquare Cloud Requirements ................................................................................... 24
33
LIST OF FIGURES
Figure 1. The iMinds VMware Platform ..................................................................................... 17 Figure 2. The iMinds Virtual Wall .............................................................................................. 17 Figure 3. Virtual Wall Configuration Interface. .......................................................................... 18 Figure 4. Virtual Wall Compatible Testbeds in the World. ........................................................ 19 Figure 5. Elements of the FIWARE Programme. ...................................................................... 20 Figure 6. Administration Rights in the FIWARE Lab Platform. ................................................. 20 Figure 7. Classes of FIWARE Generic Enablers. ..................................................................... 21 Figure 8. The iMinds Tenqu Platform. ....................................................................................... 22 Figure 9. The Orion Context Broker. ......................................................................................... 27 Figure 10. The NGSI Service Architecture. ............................................................................... 28
34
DOCUMENT INFORMATION
REVISION HISTORY
REVISION DATE AUTHOR ORGANISATION DESCRIPTION
v1 04.03.2016 Brecht Vermeulen iMinds Table of Contents (ToC)
v2 19.03.2016 Jesse Marsh City of Prato Chapter 2, minor edits
v3 20.05.2016 Brecht Vermeulen iMinds Full draft
v4
v5
29.05.2016
30.05.2016
Jesse Marsh
Francesco
Molinari
Taco Van Dijk
Brecht Vermeulen
City of Prato
CCA
WAAG
iMinds
Incorporation of Paolo
Guarnieri review
comments, integration of
contents, layout and
graphics, glossary
Final version
STATEMENT OF ORIGINALITY
This deliverable contains original unpublished work except where clearly indicated otherwise.
Acknowledgement of previously published material and of the work of others has been made
through appropriate citation, quotation or both.
COPYRIGHT
This work is licensed by the TCBL Consortium under a Creative Commons
Attribution-ShareAlike 4.0 International License, 2015. For details, see
http://creativecommons.org/licenses/by-sa/4.0/
The TCBL Consortium, consisting of: Municipality of Prato (PRATO) Italy; German Institutes
for Textile and Fiber Research - Center for Management Research (DITF) Germany; Istituto
Superiore Mario Boella (ISMB) Italy; Skillaware (SKILL) Italy; The Open University (OU) UK;
iMinds (iMINDS) Belgium; Tavistock Institute (TAVI) UK; Materials Industrial Research &
Technology Center S.A. (MIRTEC) Greece; Waag Society (WAAG) Netherlands; Huddersfield
& District Textile Training Company Ltd (TCOE) UK; eZavod (eZAVOD) Slovenia; Consorzio
Arca (ARCA) Italy; Unioncamere del Veneto (UCV) Italy; Hellenic Clothing Industry
Association (HCIA) Greece; Sanjotec - Centro Empresarial e Tecnológico (SANJO) Portugal;
Clear Communication Associates Ltd (CCA) UK.
DISCLAIMER
All information included in this document is subject to change without notice. The Members of
the TCBL Consortium make no warranty of any kind with regard to this document, including,
but not limited to, the implied warranties of merchantability and fitness for a particular purpose.
The Members of the TCBL Consortium shall not be held liable for errors contained herein or
direct, indirect, special, incidental or consequential damages in connection with the furnishing,
performance, or use of this material.
D 6.2: Cloud infrastructure
646133 - TCBL Textile & Clothing Business Labs
35
ACKNOWLEDGEMENTS
The TCBL project has received funding from the European Union's Horizon 2020 Programme
for research, technology development, and innovation under Grant Agreement n. 646133.