context: introduction to virtualiztion

src/docs/glossary.tex

@@ -28,6 +28,20 @@
     },
 }
 
+\newglossaryentry{hypervisor}{
+    name = Hypervisor,
+    description = {
+        TODO
+    },
+}
+
+\newglossaryentry{VM}{
+    name = Virtual Machine,
+    description = {
+        TODO
+    },
+}
+
 \newglossaryentry{Linux}{
     name = Linux,
     description = {
@@ -36,6 +50,14 @@
     },
     plural=Linuces
 }
+
+\newglossaryentry{OBSD}{
+    name = OpenBSD,
+    description = {
+        TODO
+    }
+}
+
 \newglossaryentry{computer}{
     name = Computer,
     description = {

src/docs/parts/context/context.tex

@@ -20,28 +20,64 @@ The technology that is currently available to form \glspl{sac} reuses different
 These problems are all related to software deployment and system operation and can be represented by the following questions.
 Only a subset of these problems and attempted solutions will be subject to research for this thesis.
 \begin{enumerate}
-    \item How do we maximize the utilization of our hardware systems without compromising security?
+\item How do we maximize the utilization of our hardware systems without compromising security? 
-    \item How do we guarantee that the application works on every target machine the same as on the developer machine?
+
-    \item How do we build multiple variants and/or versions of an application, install and run them simultaneously on the same target machine without exhibiting conflicts?
+    This question is about isolating system resources and fine-grained resource control, which is not in the research scope of this thesis.
-    \item How do we verify that an application runs on the target system has not been altered maliciously at one point in the deployment chain?
+    It is nonetheless briefly explained under the section \ref{sect:sac-osvirt}, to form a complete view on the scope of \glspl{sac} technology.
+
+\item How do we guarantee that the application works on every target machine the same as on the developer machine?
+\item How do we build multiple variants and/or versions of an application, install and run them simultaneously on the same target machine without exhibiting conflicts?
+
+\item How do we verify that an application runs on the target system has not been altered maliciously at one point in the deployment chain?
 \end{enumerate}
-The first question is about isolating system resources and fine-grained resource control, which is not in the research scope of this thesis.
+Questions 2 - 4 are in the research scope of this thesis, while the concern of the last question is declared optional.
-It is nonetheless briefly explained under the section \ref{sect:sac-osvirt}, to form a complete view on the scope of \glspl{sac}.
+These questions are very important to the ideology of \glspl{sac}, and they have their origin in the conventional methods of software deployment.
+More thorough examination of these question is done in section \ref{sect:sd-challenges} of this chapter.
 
-The other questions are in the research scope of this thesis, while the concern of the last question is declared optional.
+\subsection{Introduction to Virtualization}
-They are very important to the ideology of \glspl{sac}, and they have their origin in the conventional methods of software deployment.
-Therefore they are examined further in section \ref{sect:sd-challenges} later in this chapter.
-
-\section{A facet of \gls{osvirt}}
-\label{sect:sac-osvirt}
 % Background of the Problem 
 % This section is critically important as it must contain some mention of all the subject matter in the following Chapter 2 Review of the Literature 2 and the methodology in Chapter 3. Key words should abound that will subsequently be used again in Chapter 2. The section is a brief  two to four page summary of the major findings in the field of interest that cites the most current finding in the subject area. A minimum of two to three citations to the literature per paragraph is advisable. The paragraphs must be a summary of unresolved issues, conflicting findings, social concerns, or educational, national, or international issues, and lead to the next section, the statement of the problem. The problem is the gap in the knowledge. The focus of the Background of the Problem is where a gap in the knowledge is found in the current body of empirical (research) literature.
+Virtualization has been an important field, both in research and in the industry.
+It has been subject to constant development, improvement, and adoption.
+The basics of virtualization in computer sciences boil down to one simple principle.
+It is the principle of modifying the view of the soft- and hardware resources for applications and systems.
 
-based on \gls{osvirt}\cite{Reshetova2014}, which has been available on \gls{Linux} and under continuous development for many years.
+\subsubsection{\glspl{VM}}
+The modern techniques for virtualization can be grouped in two categories: \glspl{hypervisor} and \gls{osvirt}.
+Hypervisor is synonymous with \gls{VM} Monitor, which is slightly more self-explanatory.
+Virtual machines are monitored applications which are presented with a set of virtual hardware resources that might not even exist on the underlying hardware machine they are being executed on.
+This principle is easy to understand, because one can simply picture one or many virtual computers running on a real computer.
+
+The virtual machines require a full \gls{OS} to boot the virtual hardware and run services.
+This \gls{OS} typically consists of a kernel and a set of files, or virtual-disk-drives containing a set of files, containing the operating and application software to be executed on the virtual machine.
+The virtual machine boots the kernel which then executes the operating system, typical to a machine boot process.
+It allows to run a different OS, within the virtual machine than what is running on the host machine.
+Further it allows to create heterogeneous scenarios like running \gls{OBSD} virtual machine on \gls{Linux}, or vice versa.
+The big downside is that this requires a full-fledged \gls{OS} to be installed and configured once upfront, and booted upon every execution.
+
+However, there are cases when solely the application running on top of the virtualized \gls{OS} is ideologically the subject to virtualization, and it is technically not necessary to have a separate \gls{OS} for every virtualized application.
+This is one of the main scenarios for the use of \gls{osvirt} which is better suited, because it doesn't require a full-fledged \glspl{OS} to virtualize an application, as explained in the following section \ref{sect:sac-osvirt}.
+
+\subsubsection{\gls{osvirt}}
+\label{sect:sac-osvirt}
 % TODO: explain generically what APC is and compare to Hypervisors
-% TODO: explain difference to hypervisors: effort, performance and resource allocation flexibility
+This technology has been under active development for about decade now\cite{Reshetova2014}, and is becoming more and more popular.
+The popularity has exploded with one specific implementation named \gls{Docker}, which targets the \gls{Linux}-platform.
+More about this historical and technological development is explained in its own section \ref{virt-advent-sac-docker}.
+
+The idea behind \gls{osvirt} is to virtualize applications on the \gls{OS} level instead of on the machine level.
+On \gls{Linux}, features that implement this are a part of the kernel itself, providing features that allow a low-overhead isolation and resource-control for user-space processes, in short: virtualization.
 % TODO: refer to Linux Namespaces and Cgroups
 
+\subsection{The Advent of \gls{sac}}
+\label{virt-advent-sac}
+Even though the underlying technology \gls{osvirt} had been available for a relatively long time, \gls{Docker}\cite{Fink2014}, since its release in 2014\footnote{http://blog.docker.com/2014/06/its-here-docker-1-0}, has brought \glspl{sac} to the attention and hands of the masses in the \gls{OSS} community.
+From a psychological standpoint this is not surprising, as it has abstracted most of complexities of the technology, adding ease of deployment, a platform for hosting the \gls{saci} in a Docker specific format, as well as a very convenient way for building the like using Dockerfiles(TODO reference).
+Its popularity has come to a point where the term \textit{Docker} is being used interchangeably with the \gls{sac} technology itself.
+% TODO: references for this claim
+
+% TODO introduce \gls{LXC}, \gls{systemd-nspawn}, \gls{Docker}, and \gls{rkt}.
+
 \section{Challenges of Software Development \& Deployment}
 \label{sect:sd-challenges}
 Software is typically developed on a workstation or laptop, brought to a format that is understood by the target machine to which it must be is transfered, and where it is configured and finally executed to serve its purpose.
@@ -62,17 +98,6 @@ Another challenge is to be able to verify that software hasn't been altered to d
 To analyze the current state of the art, different implementations of this technology.
 The first part of this section analyzes the \gls{sacr} aspects of the implementations, while the second part demonstrates currently popular approaches to assemble \glspl{saci}.
 
-\subsection{\glspl{sacr}}
-\label{ctx:sd-challenges-sor-sacr}
-The most popular \gls{osvirt} applications that are available on \gls{Linux} today include, \gls{LXC}, \gls{systemd-nspawn}, \gls{Docker}, and \gls{rkt}.
-%TODO: why LXC, Docker, rkt
-In this part, they are briefly compared with a highlight on architectural differences and intentional use-cases.
-
-\subsubsection{Docker: The Advent of \gls{sac}}
-Even though the underlying technology \gls{osvirt} had been available for a relatively long time, \gls{Docker}\cite{Fink2014}, since its release in 2014\footnote{http://blog.docker.com/2014/06/its-here-docker-1-0}, has brought \glspl{sac} to the attention and hands of the masses in the \gls{OSS} community.
-From a psychological standpoint this is not surprising, as it has abstracted most of complexities of the technology, adding ease of deployment, a platform for hosting the \gls{saci} in a Docker specific format, as well as a very convenient way for building the like using Dockerfiles(TODO reference).
-Its popularity has come to a point where the term \textit{Docker} is being used interchangeably with the \gls{sac} technology itself.
-% TODO: references for this claim
 
 \subsection{No proved methods to declare, reproduce, and trust the builds of \glspl{saci}}
 % Statement of the Problem