Skip to content
Snippets Groups Projects
ds_cloud_c.tex 10.4 KiB
Newer Older
Doina Cristina Duma's avatar
Doina Cristina Duma committed
\documentclass[a4paper]{jpconf}
\usepackage{graphicx}
\begin{document}
\title{Cloud@CNAF Management and Evolution: placeholder}

\author{C. Duma$^1$, A. Costantini$^1$, D. Michelotto$^1$ and D. Salomoni$^1$}

\address{$^1$INFN Division CNAF, Bologna, Italy}
%\address{$^2$IFCA, Consejo Superior de Investigaciones Cientificas-CSIC, Santander, Spain}

\ead{ds@cnaf.infn.it}

\begin{abstract}

Cloud@CNAF is  a  project  aiming  to  offer  a  production  quality  Cloud  Infrastructure, based on open source solutions to serve the different CNAF use cases.  
The project is the resultof  the  collaboration  of  a  transverse  group  of  people  from  all  CNAF  departments:   network, storage, farming, national services, distributed systems.  
If 2016 was for the Cloud@CNAF IaaS (Infrastructure as a Service) based on OpenStack [1], a period of consolidation and 
improvement, 2017 was the year of the flood, when an aqueduct pipe located inthe street nearby CNAF, went broke causing the down of the entire datacenter.
This paper presents the activity carried out throughout the year in the migration 


from the point of view of stabilityand  reliability,  in  which  the  activities  were  focused  on  the  support  of  the  operation  of  theinfrastructure, definition of monitoring 
checks, dashboards and notifications, integration in thegeneral CNAF provisioning and monitoring system. During this period the number of supportedusers and uses cases has increased,  
and as a consequence,  the infrastructure saw a grouth ofthe resources allocated.  Work on the preparation of a parallel cloud infrastructure also started,infrastructure dedicated to the 
testing of OpenStack upgrade procedures, usually a complex anddifficult task.  This paper presents the activity carried out throughout the year in the directionsmentioned and gives also a 
vision on the future evolution foreseen for the cloud infrastructureat CNAF.
Doina Cristina Duma's avatar
Doina Cristina Duma committed
\end{abstract}

\section{Introduction}
The main goal of Cloud@CNAF project is to provide a production quality
Cloud Infrastructure for CNAF internal activities as well as national and
international projects hosted at CNAF:
\begin{itemize}
  \item Internal activities
    \begin{itemize}
    \item Provisioning VM for CNAF departments and staff members
    \item Provisioning of VM for CNAF staff members
    \item Tutorial and courses
    \end{itemize}
  \item National and international projects
    \begin{itemize}
      \item Providing VMs for experiments hosted at CNAF, like CMS, ATLAS, EEE
      \item testbeds for testing the services developed by projects like the OpenCityPlatform \& INDIGO-DataCloud
    \end{itemize}
\end{itemize}

The infrastructure made available is based on OpenStack, version Juno, with all the
services deployed using a High-Availability (HA) setup or in a
clustered manner (for ex. for the DBs used). During  2016 the infrastructure has been
enhanced, by adding new resources, compute and network, and its operation has been improved and guaranteed by
adding the monitoring part, improving the support, automating the maintenance activities.





Doina Cristina Duma's avatar
Doina Cristina Duma committed
\section{First section}
Doina Cristina Duma's avatar
Doina Cristina Duma committed
\label{sec:release}

TOCHANGE
The software development lifecycle (SDL) process (Figure~\ref{fig:1}) in INDIGO has been supported by a continuous 
software improvement process that regarded the software quality assurance, software maintenance, 
including release management, support services, and the management of pilot infrastructures 
needed for software integration and acceptance testing.

%\begin{figure}
%  \centering
%  \includegraphics[width=\textwidth]{Figure5.pdf}
%  \caption{Software development lifecycle implementation}
%  \label{fig:1}
%\end{figure}


Preview releases are made available for evaluation by user communities and
resource providers through the pilot infrastructures. Release
candidates are subjected to integration testing, which may include the

%\subsection{Software development lifecycle management}

Software lifecycle management is performed mostly via automated actions orchestrated.

In Figure we depict the project's software lifecycle management services and 
activities and their interdependencies:
\begin{itemize}
\item Version Control System (VCS) - Source Code is made available through public VCS 
        repositories, hosted externally in GitHub repositories, guaranteeing in this 
        way the software openness and visibility, simplifying the exploitation beyond the 
        project lifetime. The INDIGO-DataCloud software is released under the Apache 2.0 
        software license and can be deployed on both public and private Cloud infrastructures.
\item Software quality assurence criteria and control activities and services to enable them: 
\begin{itemize}
\item Continuous Integration service using {\bf Jenkins}: Service to automate the building, 
        packaging (where applicable) and execution of unit and functional tests of software components.
\item Code review service using GitHub: Code review of software source code is one integral part of the SQA\@. This service facilitates the code review proces. It records the 
        comments and allows the reviewer to verify the software modification.
\item Code metrics services using {\bf Grimoire}: To collect and visualize several metrics about the software components.
\end{itemize}
\item Software release and maintenance activities, services and supporting infrastructures
\begin{itemize}
\item A project management service using {\bf openproject.org} is made available by the 
        project: It provides tools such as an issue tracker, wiki, a placeholder for documents and a project management timeline.
\item Artifacts repositories for RPM and Debian packages, and Docker Hub for containers: 
        In INDIGO-DataCloud there are two types of artifacts, packaged software and virtual images. 
        The software can be downloaded from our public repository\footnote{http://repo.indigo-datacloud.eu}.
\item Release notes, installation and configuration guides, user and development manuals are made 
        available on {\bf GitBook}\footnote{https://indigo-dc.gitbooks.io/indigo-datacloud-releases}.
\item Bug trackers using GitHub issues tracker: Services to track issues and bugs of INDIGO-DataCloud software components.
\item Integration infrastructure: this infrastructure is composed of computing resources to support directly 
        the Continuous Integration service. It's the place where building and packaging of software 
        occurs as well as the execution of unit and functional tests. These resources are provided by INDIGO partners.
\item Testing infrastructure: this infrastructure aims to provide several types of environment. A stable environment 
        for users where they can preview the software and services developed by INDIGO-DataCloud, prior to its public release. 
\item Preview infrastructure: where the released artifacts are deployed and made available for testing and validation by the use-cases.
\end{itemize}

\end{itemize}


The first INDIGO-DataCloud major release (codename {\tt MidnightBlue}) was released 1st of August 2016 (see table~\ref{tab:1} for the fact sheet). The 
second INDIGO-DataCloud major release (codename {\tt ElectricIndigo}) was made publicly available on April 14th  2017 (see table~\ref{tab:2} for the fact sheet).


\section{DevOps approach in INDIGO}

Progressive levels of automation were adopted throughout the different phases of 
the INDIGO-DataCloud project software development and delivery processes.

\subsection{Services for continuous integration and SQA}

The INDIGO-DataCloud CI process is schematically shown
in Figure~\ref{fig:3}. The process, in its different steps, reflects some of
the main and important achievements of the software integration team, such as:

\begin{itemize}
    \item New features are developed independently from the
          production version in \textit{feature branches}. The creation of
          a pull request for a specific feature branch marks the start of
          the automated validation process through the execution of the
          SQA jobs.

    \item The SQA jobs perform the code style verification and calculate unit
        and functional test coverage.
        \begin{itemize}
            \item The tools necessary for tackling these tests are packaged in
                Docker images, available in DockerHub.
            \item Each test then initiates a new container that provides a
                clean environment for its execution.
            \item This is an innovative approach that provides the flexibility
                needed to cope with the INDIGO-DataCloud software diversity.
        \end{itemize}

    \item The results of the several SQA jobs are made available in the Jenkins
        service which notifies back to GitHub their exit status.
        \begin{itemize}
            \item Only if the tests have succeeded, the source code is
                validated and is ready to be merged into the production branch.
        \end{itemize}

    \item The last step in the workflow is the code review, where a human
        review of the change is performed. After code review the source code
                can be merged and becomes ready for integration and later release.
\end{itemize}



As a general rule, the described CI process must be followed by all the PTs
contributing code to INDIGO-DataCloud. However there are exceptions to this rule that fall into two main categories:

\subsection{Continuous delivery}
Continuous delivery adds, on top of the software development chain, a seamless
manufacturing of software packages ready to be deployed into production
services. Therefore, fast, frequent and small releases can be taken over thus
promoting the reliability of the software.

\subsection{DevOps adoption from user communities}

The experience gathered throughout the project with regards to the adoption of different DevOps 
practices is not only useful and suitable for the software related to the core services in the 
INDIGO-DataCloud solution, but also applicable to the development and distribution of the applications coming from the user communities.

\section{Conclusions}

Thanks to the new common solutions developed by the INDIGO project, teams of first-line 
researchers in Europe are using public and private Cloud resources to get new results in Physics, Biology, Astronomy, Medicine, Humanities and other disciplines.


%\section*{Acknowledgments}
%eXtreme-DataCloud has been funded by the European Commision H2020 research and innovation program under grant agreement RIA XXXXXXX.


\end{document}