steveej/msc-thesis
1
0
Fork 0
Code Issues 1 Pull requests Projects Releases 4 Packages Wiki Activity Actions

thesis: part introduction is now context

Browse source 
Try to be less specific in the beginning of the context part.
This commit is contained in:
steveej 2016-09-12 15:44:11 +02:00
parent af08b82088
commit 8ba9de86fc
4 changed files with 92 additions and 52 deletions
Download patch file Download diff file Expand all files Collapse all files

40
src/docs/glossary.tex
View file

@ -46,29 +46,33 @@
} }
\newglossaryentry{app}{ \newglossaryentry{app}{
name=Application Program, name=Software Application,
description={ description={
TODO TODO
} }
} }
\newglossaryentry{apc}{ \newglossaryentry{sac}{
name=Application Program Container, name=Software Application Container,
description={ description={
The broad term for the technology used to build, package, distribute and run an application program in isolation from the underlying and co-existing systems, wherein the level or technique of isolation can be different depending on the \gls{apcr}. The broad term for the technology used to build, package, distribute and run an application program in isolation from the underlying and co-existing systems, wherein the level or technique of isolation can be different depending on the \gls{sacr}.
The term is nuanced from \gls{appc} defined by the \gls{appcorg}.
The \gls{appcorg} is a community driven effort to create an open, standardized specification for developers and users of \gls{sac} technology.
Such independent standards are required to form interoperability between \gls{sac} implementations made by independent parties.
Some implementations will be subject to more detailed examination in Part \ref{part:research}.
} }
} }
\newglossaryentry{apci}{ \newglossaryentry{saci}{
name=Application Program Container Image, name=Software Application Container Image,
description={ description={
An archive file that contains all of the necessary binaries that are needed to execute an application and a manifest file that that contains metadata about the application. Alternatively to containing all the required binary files, the manifest file can declare dependencies to other application container images, which must then be available at runtime to execute the contained application. An archive file that contains all of the necessary binaries that are needed to execute an application and a manifest file that that contains metadata about the application. Alternatively to containing all the required binary files, the manifest file can declare dependencies to other application container images, which must then be available at runtime to execute the contained application.
} }
} }
\newglossaryentry{apcr}{ \newglossaryentry{sacr}{
name=Application Program Container Runtime, name=Software Application Container Runtime,
description={ description={
An application program (suite) that understands how to run the software inside an \gls{apci}. An application program (suite) that understands how to run the software inside an \gls{saci}.
} }
} }
@ -82,7 +86,21 @@
\newglossaryentry{Docker}{ \newglossaryentry{Docker}{
name=Docker, name=Docker,
description={ description={
A very popular \gls{apc} platform and application suite, providing functionality to build and deploy Docker specific \glspl{apci}. A very popular \gls{sac} platform and application suite, providing functionality to build and deploy Docker specific \glspl{saci}.
}
}
\newglossaryentry{systemd-nspawn}{
name=systemd-nspawn,
description={
TODO
}
}
\newglossaryentry{rkt}{
name=rkt,
description={
TODO
} }
} }
@ -96,6 +114,6 @@
\newglossaryentry{appc}{ \newglossaryentry{appc}{
name=App Container, name=App Container,
description={ description={
Specific variant of an \gls{apc} defined by the \gls{appcorg}. Specific variant of an \gls{sac} defined by the \gls{appcorg}.
} }
} }

86
src/docs/parts/introduction/introduction.tex → src/docs/parts/context/context.tex
View file

@ -6,26 +6,19 @@
% Use plenty of transitional words and sentences from one section to another, as well as subheadings, which allow the reader to follow the writer’s train of thought. Following is an outline of the content of the empirical argument of Chapter 1. Universities often arrange the content in a different order, but the subject matter is the same in all dissertations because it is an empirical “opening statement” as might be found in a court of law. (Note that a dissertation could also be five pages of text and 50 pages of pictures of dragonfly wings and qualify for a Doctor’s degree in entomology.) % Use plenty of transitional words and sentences from one section to another, as well as subheadings, which allow the reader to follow the writer’s train of thought. Following is an outline of the content of the empirical argument of Chapter 1. Universities often arrange the content in a different order, but the subject matter is the same in all dissertations because it is an empirical “opening statement” as might be found in a court of law. (Note that a dissertation could also be five pages of text and 50 pages of pictures of dragonfly wings and qualify for a Doctor’s degree in entomology.)
%State the general field of interest in one or two paragraphs, and end with a sentence that states what study will accomplish. Do not keep the reader waiting to find out the precise subject of the dissertation. %State the general field of interest in one or two paragraphs, and end with a sentence that states what study will accomplish. Do not keep the reader waiting to find out the precise subject of the dissertation.
This thesis is about building and packaging \glspl{app} specifically with the intention to distribute them in form of \glspl{apci} on systems running a \gls{Linux} based \gls{OS}. This thesis is a scientific attempt to analyze and solve the practical problems of packaging and deploying \glspl{app} in the context of \gls{sac} technology.
For a lack of an official definition and common understanding what this technology is, the term \gls{sac} is defined in this chapter as a reference for the rest of the thesis.
The term \gls{apc} is nuanced from \gls{appc} defined by the \gls{appcorg}. The two main drivers for this technology have been long standing problems in information technology: optimal utilization of hardware, and simplification of software deployment to said hardware.
The \gls{appcorg} is a community driven effort to create an open, standardized specification for developers and users of \gls{apc} technology. Because this is a problem in the operation of computers, it is expected that the problem is attempted to be solved on an \gls{OS} level or slightly above.
Such independent standards are required to form interoperability between \gls{apc} implementations of independent parties. The following sections explain the ideologies and also gives a detailed insight to \gls{OS}-specific \gls{sac} technology, focusing on the \gls{Linux} \gls{OS}.
Some of these implementations will be subject to more detailed examination in Part \ref{part:research}.
The term \gls{apc} want to explicitly not refer to the specifications that have been created within the \gls{appcorg}. This is necessary to understand the problem description, given at the end of the chapter.
The primary concern is to find a viable method for declaring and assembling \glspl{apci} deterministically. \section{\glspl{sac}}
As a highly anticipated option, the solution should also be able to reproducible these builds on different computers and different points in time and yield the exact same results. The technology that is currently available to form \glspl{sac} reuses different patterns and techniques to solve a combination of different problems all at once.
The secondary concern is to abstract enough of the method's complexity in order to make it attractive for application developers while still allowing them to specify the exact contents alongside their software within the resulting \gls{apci}.
The choice for this topic was made due to my personal dissatisfaction with currently available methods for building \glspl{apci}, and seeing both the need and the potential of a scientifically substantiated approach.
\section{Problems (attempted) to be solved with \glspl{apc}}
The technology that is currently available to form \glspl{apc} reuses different patterns and techniques to solve a combination of different problems all at once.
These problems are all related to software deployment and system operation and can be represented by the following questions. 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. Only a subset of these problems and attempted solutions will be subject to research for this thesis.
This chapter covers the knowledge that is necessary to understand the problem, starting with the development of the specific technology and the challenges and mindsets of its developers and users.
\begin{enumerate} \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 guarantee that the application works on every target machine the same as on the developer machine?
@ -33,14 +26,14 @@ This chapter covers the knowledge that is necessary to understand the problem, s
\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? \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} \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. The first question is about isolating system resources and fine-grained resource control, which is not in the research scope of this thesis.
It is yet briefly explained under the section \ref{sect:apc-osvirt}, to form a complete view on the scope of \glspl{apc}. It is nonetheless briefly explained under the section \ref{sect:sac-osvirt}, to form a complete view on the scope of \glspl{sac}.
The other questions are in the research scope of this thesis, while the concern of the last question is declared optional. The other questions are in the research scope of this thesis, while the concern of the last question is declared optional.
They are very important to the ideology of \glspl{apc}, and they have their origin in the conventional methods of software deployment. 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. Therefore they are examined further in section \ref{sect:sd-challenges} later in this chapter.
\section{\glspl{apc}: A facet of \gls{osvirt}} \section{A facet of \gls{osvirt}}
\label{sect:apc-osvirt} \label{sect:sac-osvirt}
% Background of the Problem % 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. % 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.
@ -49,27 +42,54 @@ based on \gls{osvirt}\cite{Reshetova2014}, which has been available on \gls{Linu
% TODO: explain difference to hypervisors: effort, performance and resource allocation flexibility % TODO: explain difference to hypervisors: effort, performance and resource allocation flexibility
% TODO: refer to Linux Namespaces and Cgroups % TODO: refer to Linux Namespaces and Cgroups
\section{The Challenges Of Software Development Deployment} \section{Challenges of Software Development \& Deployment}
\label{sect:sd-challenges} \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. 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.
In order to be executable on the target machine, the software needs to be translated into the target-platform specific format before it can be executed on to the target system.
If the software is updated, the cycle has to be repeated.
This introduces a very generic challenge: software updates, or deployments in general, are not supposed to be negatively influenced by any previous version or state that exists on the target machine.
Describing the process with technical terms, software developers write software source code, which is then translated to binary files in specific machine language dependent on the target platform with the help of a compiler toolchain. In order to be executable on the target machine, the software needs to be translated into the target-platform specific format before it can be executed on to the target system.
These binary files are made available as software packages that can be installed in the target machines operating system, typically with the help of a software package manager which itself is a software that is included in most modern operating systems. If the software is changed and updated, the cycle has to be repeated.
This represents a first challenge: software updates, or deployments in general, are not supposed to be negatively influenced by any previous version or state that exists on the target machine.
On the technical, this process starts with software developers who write software source code.
This code is then transformed and stored in executable binary files that contain specific platform-dependent machine-code with.
The translation is done by processing the source code with a compiler toolchain.
The binary files are then made available as software packages that can be downloaded and installed on the target machines operating system.
Typically and ideally, this is done with the help of a software package manager, which itself is a software that is included in most modern operating systems.
The location where the files of the package are installed on the target machine depends on how it is configured at packaging time, but in most popular software package approaches this location is agnostic of software application version changes. The location where the files of the package are installed on the target machine depends on how it is configured at packaging time, but in most popular software package approaches this location is agnostic of software application version changes.
Another challenge is to be able to verify that software hasn't been altered to differ from its intentional behavior at any point of the deployment process. Another challenge is to be able to verify that software hasn't been altered to differ from its intentional behavior at any point of the deployment process.
\subsection{Docker: The Advent of \gls{apc}} \section{State of the Art in \gls{osvirt}}
Even though the underlying technology 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{apc} to the attention and hands of the masses in the \gls{OSS} community. To analyze the current state of the art, different implementations of this technology.
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{apci} in a Docker specific format, as well as a very convenient way for building the like using Dockerfiles(TODO reference). 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}.
Its popularity has come to a point where the term \textit{Docker} is being used interchangeably (TODO: do I need references for this?) with the \gls{apc} technology itself.
\section{No proved methods to declare, reproduce, and trust the builds of \glspl{apci}} \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 % Statement of the Problem
% Arising from the background statement is this statement of the exact gap in the knowledge discussed in previous paragraphs that reviewed the most current literature found. A gap in the knowledge is the entire reason for the study, so state it specifically and exactly. Use the words “gap in the knowledge.” The problem statement will contain a definition of the general need for the study, and the specific problem that will be addressed. % Arising from the background statement is this statement of the exact gap in the knowledge discussed in previous paragraphs that reviewed the most current literature found. A gap in the knowledge is the entire reason for the study, so state it specifically and exactly. Use the words “gap in the knowledge.” The problem statement will contain a definition of the general need for the study, and the specific problem that will be addressed.
\chapter{Scope}
%TODO: explain scope of OSS systems running a \gls{Linux} based \gls{OS}.
\section{Goals}
The primary concern is to find a viable method for declaring and assembling \glspl{saci} deterministically.
As a highly anticipated option, the solution should also be able to reproduce these builds on different computers and different points in time and yield the exact same results.
The secondary concern is to abstract enough of the solution's complexity in order to make it attractive for application developers while still allowing them to specify the exact contents alongside their software within the resulting \gls{saci}.
\section{Motivation}
The choice for this topic was made due to my personal dissatisfaction with currently available methods for building \glspl{saci}, and seeing both the need and the potential of a scientifically substantiated approach.
\section{Purpose of the Study} \section{Purpose of the Study}
% Purpose of the Study % Purpose of the Study
%The Purpose of the Study is a statement contained within one or two paragraphs that identifies the research design, such as qualitative, quantitative, mixed methods, ethnographic, or another design. The research variables, if a quantitative study, are identified, for instance, independent, dependent, comparisons, relationships, or other variables. The population that will be used is identified, whether it will be randomly or purposively chosen, and the location of the study is summarized. Most of these factors will be discussed in detail in Chapter 3. %The Purpose of the Study is a statement contained within one or two paragraphs that identifies the research design, such as qualitative, quantitative, mixed methods, ethnographic, or another design. The research variables, if a quantitative study, are identified, for instance, independent, dependent, comparisons, relationships, or other variables. The population that will be used is identified, whether it will be randomly or purposively chosen, and the location of the study is summarized. Most of these factors will be discussed in detail in Chapter 3.
@ -85,8 +105,10 @@ Its popularity has come to a point where the term \textit{Docker} is being used
\section{Hypotheses} \section{Hypotheses}
% Hypotheses % Hypotheses
% A hypothesis is a testable prediction for an observed phenomenon, namely, the gap in the knowledge. Each research question will have both a null and an alternative hypothesis in a quantitative study. Qualitative studies do not have hypotheses. The two hypotheses should follow the research question upon which they are based. Hypotheses are testable predictions to the gap in the knowledge. In a qualitative study the hypotheses are replaced with the primary research questions. % A hypothesis is a testable prediction for an observed phenomenon, namely, the gap in the knowledge. Each research question will have both a null and an alternative hypothesis in a quantitative study. Qualitative studies do not have hypotheses. The two hypotheses should follow the research question upon which they are based. Hypotheses are testable predictions to the gap in the knowledge. In a qualitative study the hypotheses are replaced with the primary research questions.
The goals described above should be possible to achieve with the help of a package manager that source-based packages, by specifying the container image content by referencing packages in a declarative manner.
This should be possible with the help of a package manager that source-based packages, by specifying the container image content by referencing packages in a declarative manner. %TODO why a package manager?
%TODO why source-based?
%TODO why is declarative?
\section{Research Design} \section{Research Design}
% In Chapter 1 this is a summary of the methodology and contains a brief outline of three things: (a) the participants in a qualitative study or the subjects of a quantitative study (human participants are referred tyo as participants, non-human subjects are referred to as subjects), (b) the instrumentation used to collect data, and (c) the procedure that will be followed. All of these elements will be reported in detail in Chapter 3. In a quantitative study, the instrumentation will be validated in Chapter 3 in detail. In a qualitative study, if it is a researcher-created questionnaire, validating the correctness of the interview protocol is usually accomplished with a pilot study. For either a quantitative or a qualitative study, using an already validated survey instrument is easier to defend and does not require a pilot study; however, Chapter 3 must contain a careful review of the instrument and how it was validated by the creator. % In Chapter 1 this is a summary of the methodology and contains a brief outline of three things: (a) the participants in a qualitative study or the subjects of a quantitative study (human participants are referred tyo as participants, non-human subjects are referred to as subjects), (b) the instrumentation used to collect data, and (c) the procedure that will be followed. All of these elements will be reported in detail in Chapter 3. In a quantitative study, the instrumentation will be validated in Chapter 3 in detail. In a qualitative study, if it is a researcher-created questionnaire, validating the correctness of the interview protocol is usually accomplished with a pilot study. For either a quantitative or a qualitative study, using an already validated survey instrument is easier to defend and does not require a pilot study; however, Chapter 3 must contain a careful review of the instrument and how it was validated by the creator.

4
src/docs/parts/research/research.tex
View file

@ -44,8 +44,8 @@ Spack (\url{https://github.com/LLNL/spack}) is a package manager written in Pyth
\section{Guile Scheme} \section{Guile Scheme}
Guile implements Scheme and extends it with new features. Guile implements Scheme and extends it with new features.
\chapter{Abstraction of \gls{apcr} and \gls{apci}} \chapter{Abstraction of \gls{sacr} and \gls{saci}}
\label{chap:research-abstract-acpr-apci} \label{chap:research-abstract-acpr-saci}
UX: \url{https://logicgrimoire.wordpress.com/2012/08/25/a-first-guile-script} UX: \url{https://logicgrimoire.wordpress.com/2012/08/25/a-first-guile-script}

14
src/docs/thesis.tex
View file

@ -19,7 +19,7 @@
\usepackage[numberedsection,toc,numberline,nopostdot]{glossaries} \usepackage[numberedsection,toc,numberline,nopostdot]{glossaries}
\makenoidxglossaries \makenoidxglossaries
\newcommand{\topic}{A Declarative And Reproducible Approach To Application Deployment Via Container Images} \newcommand{\topic}{A Declarative And Reproducible Approach To The Creation Of Software-Application Container Images}
\newcommand{\authorOne}{Stefan Junker} \newcommand{\authorOne}{Stefan Junker}
\newcommand{\authorOneInit}{SJ} \newcommand{\authorOneInit}{SJ}
@ -29,10 +29,10 @@
\newcommand{\authorOneCountry}{Germany} \newcommand{\authorOneCountry}{Germany}
\newcommand{\authorOneId}{283751} \newcommand{\authorOneId}{283751}
\newcommand{\supervisorOne}{Prof. Dr. Michael Mächtel} \newcommand{\supervisorOne}{Prof. Dr. Michael Mächtel}
\newcommand{\supervisorTwo}{TODO supervisor two} \newcommand{\supervisorTwo}{Jürgen Keppler}
\newcommand{\studies}{TODO studies} \newcommand{\studies}{TODO studies}
\newcommand{\startdate}{TODO startdate} \newcommand{\startdate}{2016/9/1}
\newcommand{\submitdate}{TODO submitdate} \newcommand{\submitdate}{2017/2/28}
\newcommand{\buzzwords}{TODO buzzwords} \newcommand{\buzzwords}{TODO buzzwords}
% Numbered Subsubsections % Numbered Subsubsections
@ -81,8 +81,8 @@
\fancyfoot[R]{\thepage{}} \fancyfoot[R]{\thepage{}}
} }
%\titlespacing*{\chapter}{0pt}{0pt}{0pt} \titlespacing*{\chapter}{0cm}{-1cm}{0.75cm}
%\titleformat{\chapter}[hang]{\normalfont\Large\bfseries}{\thechapter}{10pt}{} \titleformat{\chapter}[hang]{\normalfont\Large\bfseries}{\thechapter}{0.5cm}{}
\makeatletter \makeatletter
@ -127,7 +127,7 @@
\printnoidxglossary \printnoidxglossary
\include{parts/introduction/introduction} \include{parts/context/context}
\part{Research} \part{Research}
\label{part:research} \label{part:research}