everything in src for packaging purposes

This commit is contained in:
gwen
2012-07-13 09:40:48 +02:00
parent 3411efc873
commit ddef37ed2a
54 changed files with 6071 additions and 0 deletions

View File

@ -0,0 +1,12 @@
SRC=$(wildcard *.tex)
OBJ=$(subst .tex,.pdf,$(SRC))
pdf: $(OBJ)
%.pdf: %.tex
pdflatex $<
clean:
rm -f $(OBJ)
rm -f *.aux *.log *.toc *.snm *.out *.nav

View File

@ -0,0 +1,69 @@
\begin{frame}
\frametitle{Comparaison entre le noyau de Créole et Tiramisu}
\begin{itemize}
\item \emph{Tiramisu} a pour objectif de
\begin{itemize}
\item remplacer le noyau \emph{Creole} (\texttt{EoleDict}) de manière transparente ;
\item résoudre les problèmes inhérents à \texttt{CreoleServ} ;
\end{itemize}
\item au niveau du code, il y a enfin une vraie séparation du c\oe ur et du fonctionnel ;
\item valide le type \emph{et la structure}, l'ajout de types est aisé.
\item \emph{Creole} : \texttt{EoleDict, EoleVars} $ \Leftrightarrow $ \texttt{Config, Option}\\
cf \texttt{tiramisu/doc/build/pydoc/index.html}
\item intégré à \texttt{gen\_config}, \texttt{cheetah}, \texttt{DTD Creole}, syntaxe \texttt{Creole} \dots
\item \texttt{eole-report/D02CoherenceVariables.pdf}
\end{itemize}
\end{frame}
\begin{frame}
\frametitle{Gestionnaire de configuration existants}
\begin{itemize}
\item Le gestionnaire de conf de Victor Stinner $\Rightarrow$ \emph{NuFw};
\item puppet, cfgengine... $\Rightarrow$ intéressant, de nombreux comportements peuvent être repris, mais tel quel difficilement compatible avec \emph{Creole};
\item \emph{Creole} $\Leftrightarrow$ \texttt{tiramisu/doc/build/glossary.html}
\end{itemize}
\end{frame}
\begin{frame}
\frametitle{Un "vrai" serveur de config}
\begin{itemize}
\item un serveur de données de configuration ;
\item $1^{ere}$ méthode : exportation (snapshot) d'un état de la config $ \Rightarrow $ Créole ;
\item $2^{eme}$ méthode : JIT (just in time) calculation, une modification
de l'état de la configuration est possible \emph{pendant} la manipulation et l'utilisation de la conf $ \Rightarrow $ Tiramisu.
\item \texttt{doc/getting-started.html}
\end{itemize}
\end{frame}
\begin{frame}
\frametitle{Qu'est-ce qu'un gestionnaire de conf moderne ?}
\begin{itemize}
\item c'est une organisation arborescente des données (les données sont imbriquées) ;
\item c'est un accès facile aux données (typiquement une interface de type \emph{dictionnaire}) ;
\item clefs-valeurs, mais quelles valeurs exactement ? $ \Rightarrow $ calcul JIT (just in time) ;
\item \texttt{eole-report/D01AccesVariables.pdf}
\end{itemize}
\end{frame}
\begin{frame}
\frametitle{Définition d'un gestionnaire de configuration}
\begin{itemize}
\item les families, groups, master \dots~ ce sont des \emph{schémas} de données (\texttt{OptionDescription}) ;
\item c'est la configuration (\texttt{Config}) qui est responsable de l'accès aux valeurs ;
\item la configuration est aisément manipulable, et a un point d'entrée unique ;
\item l'accès aux valeurs des \texttt{Options} de configuration ne peut se faire \emph{que} depuis la conf racine.
\item \texttt{eole-report/D01AccesVariables.pdf}
\end{itemize}
\end{frame}
\begin{frame}
\frametitle{Organisation en espace de nommage}
\begin{itemize}
\item dans \emph{tiramisu} l'accent est mis sur l'organisation arborescente des données ;
\item la validation des options de configuration se fait par l'appartenance aux groupes (families, master/slaves \dots) ;
\item l'organisation en groupes est unifiée par l'espace de nommage ;
\item \texttt{eole-report/D03ReglesEtats.pdf}
\item lisibilité d'une config : \texttt{tiramisu/report/build/index.html} rapport html d'une config
\end{itemize}
\end{frame}

View File

@ -0,0 +1,61 @@
\begin{frame}
\frametitle{Etats ("status") de la configuration}
\begin{itemize}
\item système d'états de la configuration par \emph{droits d'accès} ;
\item \texttt{read write}, \texttt{read only} ;
\item correspond à \texttt{freeze}, \texttt{hidden}, \texttt{disabled} \dots ;
\item \texttt{doc/status.html} ;
\item \texttt{eole-report/D03ReglesEtats.pdf} ;
\end{itemize}
\end{frame}
\begin{frame}
\frametitle{hidden if in, hidden if not in}
\begin{itemize}
\item les hidden if in, disabled if, \dots sont généralisés
\item dans tiramisu, ce sont des pré-requis sur une (des) variables
\item \texttt{eole-report/D03ReglesEtats.pdf}
\item \texttt{doc/consistency.html}
\end{itemize}
\end{frame}
\begin{frame}
\frametitle{un peu de mathématiques : prévenir les deadlocks}
\begin{itemize}
\item sûreté : prévention des deadlocks ;
\item dans tiramisu, le modèle est suffisamment abstrait pour que son exploitation mathématique soit
réalisable par les techniques de \emph{Model Checking} ;
\item soit on a besoin de ne connaître que l'ensemble des états, pas leurs liens $\Rightarrow$ espace d'états ;
\item soit on a besoin de connaître toutes les relations $\Rightarrow$ graphe d'accessibilité ;
\item la configuration est modélisable en une structure de \emph{Kripe} ;
\item déjà le parsing de la conf est facile, la preuve : \texttt{tiramisu/report/build/index.html}
\end{itemize}
\end{frame}
\begin{frame}
\frametitle{un peu de mathématiques (suite) CreoleLint}
\begin{itemize}
\item exemple : $ P = 3 \wedge Q = 1 \triangleleft \langle P = 1 \hookleftarrow Q = 0 \rangle$
\item la propriété \og dans aucun état on a $P = 3$ et $Q = 1$ \fg~ est-elle vraie ?
Pour vérifier cette propriété, on a besoin de connaître l'espace d'états ;
\item la propriété \og chaque chemin débutant dans un état accessible $P=1$ passe par un état où $Q=3$ et $P=2$ \fg~
est-elle vraie ? Cela demande de connaître le graphe d'accessibilité ;
\item les structures de \emph{Kripe} sont des machines à états étiquetées par les valuations de toutes les variables propositionnelles ;
\item une compliation statique devient possible dans \emph{CreoleLint} \dots
\end{itemize}
\end{frame}
\begin{frame}
\frametitle{compatibilité Créole : ce qui reste à faire}
\begin{itemize}
\item les options spéciales sont implémentées (auto, fill, obligatoire, \dots) reste la librairie des fonctions pour les variables automatiques \texttt{eosfunc} ;
\item tous les états sont implémentés (hidden, disabled, mode (normal/expert), \dots), il faut fixer les comportement \texttt{read write} ;
\item les "valprec" (valeur précédentes) et une mémoire de \emph{tous} les états antérieurs ;
\item fixer les comportement des hides (sous-groupes récursifs, \dots) ;
\item validations master/slaves, validations globales au regard de la configuration entière puisque c'est possible maintenant.
\end{itemize}
\end{frame}

View File

@ -0,0 +1,36 @@
%%presentation
\documentclass{beamer}
\usepackage{beamerthemetree}
%%impression
%\documentclass[a4paper,9pt]{extarticle}
%\usepackage{beamerarticle}
%%
% class FR
\usepackage[T1]{fontenc}
\usepackage[utf8]{inputenc}
\usepackage[frenchb]{babel}
% image
%% \usepackage{graphicx}
\usepackage{alltt}
\usecolortheme{crane}
\beamertemplatetransparentcovered
%\logo{\includegraphics[height=1cm]{ban.png}}
\title{Tiramisu}
\subtitle{gestionnaire de configuration}
\author{Gwen}
\institute{\texttt{git clone git://git.labs.libre-entreprise.org/tiramisu.git} \\
\texttt{firefox tiramisu/doc/build/index.html}}
\date{\today}
\begin{document}
\frame{\titlepage}
\include{definition}
\include{statut}
\end{document}