DOCSLIB.ORG

Understanding Slapos Architecture Table of Content

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Understanding Slapos Architecture Table of Content Understanding SlapOS Architecture Details SlapOS is a general purpose operating system usable on distributed POSIX infrastructures (Linux, xBSD) to provide and manage software services focussing on cloud orchestration and edge computing. It allows to automate devops including deployment, monitoring and billing of software usage on arbitrary clould infrastructures. SlapOS can be used to act as cloud provider selling software as a service (SaaS), to offer platform as a service (PaaS) solutions or also basic infrastructure as a service (IaaS). SlapOS can be run on private hardware and data centers or any public/cloud infrastructure. This design document explains the concepts underlying the SlapOS architecture. Table of Content Master and Slave Computer Partitions Networking Details Master and Nodes Details SlapOS uses a Master (referred to as COMP-ROOT) and Slave (COMP-0,1,2,3...) design. This section explains the role of the Master and other nodes in a network as well as the software components on which they depend to operate in a distributed cloud. Overview Details The Master contains a catalog of available Software Releases. Slave nodes request from the Master which software to install and to supply to users. Users then request services (called hosting subscriptions), which are instances of the supplied software. These are instantiated inside computer partitions available on a node. The node reports back the usage of all running instances over time to the Master who keeps track of node capacity and available software. The Master also acts as web portal providing web services in order for users or other software to request new software instances which are instantiated and run on nodes. It does so using services provided by COMP-0 which therefore has somewhat of a special status, as it's not a standard node similar to COMP-1,2,3 providing services to users. Details Master nodes are stateful. Slave nodes are stateless. More precisely, all information required to rebuild a Slave node is stored in the Master. This may for example include the url of a backup service which maintains an online copy of data so that in case of a node failure, a replacement node can be rebuilt with the same data. It is thus very important to ensure that state data present on the Master is well secured. This can be achieved by hosting the Master node on a trusted 3rd party IAAS infrastructure with redundant resources or better by hosting multiple Master nodes on many Slave nodes located in different regions of the world based on an appropriate data redundancy heuristic. This describes the first reflexive nature of SlapOS: A SlapOS Master is usually a running instance of a SlapOS Master software (!) instantiated on a collection of Slave nodes, which together form a trusted hosting infrastructure. In other words, SlapOS is used to host SlapOS or SlapOS is self-hosted. Master Node - Functional Role Details The Master node keeps track of the identity of all parties involved in (a) requesting cloud resources as well as (b) their monitoring and (c) usage billing. It therefore also includes end users and organisations which can be suppliers and/or consumers of cloud resources. The Master manages computer partitions on all nodes. These "containers" are used to run a single software instance each which can be requested fully autonomous or through user interaction. SlapOS generates X509 certificates for each type of identity: for users who login, for each server that contributes to the resources of SlapOS and for each running software instance that has to request/notify the Master. A SlapOS Master with a single Slave node, one user and ten computer partitions will thus generate up to 12 X509 certificates: 1 for the slave, 1 for the user and 10 for the computer partitions provided on the node. Details Any user, software or Slave node with a valid X509 certificate may request resources from the SlapOS Master which acts like a back office or marketplace. Requests are recorded as if they were a resource trading contract in which a resource consumer is requesting a given resource under certain conditions. A resource could be a NoSQL storage, a KVM virtual machine, an ERP system or similar. The conditions include price, region (eg. China) or a specific hardware setup (eg. 64bit CPU). Conditions are sometimes called Service Level Agreements (SLA) in other architectures but in SlapOS they are considered more as trading specifications than hard guarantees. By default, SlapOS Master acts as automatic marketplace. Requests are processed by trying to find a node which meets all specified conditions. The SlapOS Master thus needs to know which resources are available at a given time, at what price and with what specifications, including which software can be installed on a node and under what conditions. However, it is also possible to manually define a specific node rather than relying on the automatic marketplace logic of SlapOS Master to determine the computer to use when allocating resources. Slave Node - Functional Role Details SlapOS Slave nodes are more simple compared to the Master node. They only need to run software requested by the Master. It is thus on the Slave nodes that software is installed. To save disk space, Slave nodes install only the software which they actually need. Slave nodes are divided into a certain number of so-called computer partitions (Slappart[0-x]). A computer partition can be seen as a lightweight, secure container, but based on Unix users and directories rather than on virtualization. A typical barebone PC can easily provide 100 computer partitions and can thus run 100 Wordpress blogs or 100 e-commerce sites, each of them with its own independent database. A larger server can contain 200-500 computer partitions. The concept of computer partitions in SlapOS was designed to reduce costs drastically compared to other approaches relying on a disk image and virtualization while at the same time also allowing to run virtualization software - but inside a computer partition. This makes SlapOS at the same time cost efficient and compatible with legacy software. Master Node - Software Details At its core, the SlapOS Master is a regular node with the SlapOS "Kernel" installed. During initial installation of the SlapOS Master, a SlapProxy ("mini"-Master) is used to setup the future SlapOS Master. In relation to the SlapProxy, the SlapOS Master is a normal node on which two softwares are installed and instantiated: ERP5 "Cloud Engine" and a Frontend (Apache) for accessing ERP5. This describes the second reflexive nature of SlapOS: SlapOS is used to deploy SlapOS. This implementation of SlapOS Master originates from anE RP5 implementation for a Central Bank across eight african countries. The underlying idea was that currency clearing and cloud resource clearing are similar and should therefore be implemented with the same software. Besides that, ERP5 had also demonstrated its scalability for large CRM applications as well as its trustability for accounting. Thanks to NEO, the distributed NoSQL database ERP5 is using, the transactional nature and scalability which is required for a stateful marketplace could be implemented in ERP5. Details Developing SlapOS Master on top of ERP5 also was a direct application of ERP5's Universal Business Model (UBM), a model which unifies all sciences of management and which has been acknowledged by numerous IEEE publications as a major shift in enterprise application design. In the UBM, each computer is represented by an Item while allocation requests, resource deliveries and resource accounting are represented by a Movement. The movement resource can be software hosting, CPU usage, disk usage, network usage, RAM usage, login usage, etc. Software hosting movements start whenever the running software starts in the computer partition and stop whenever the running software stops. Resource usage movements start and stop for accounting during each period of time, independently of the running software's state. The software release which is run on a computer partition is an Item in UBM, just like the subscription contract identifier. The parties (client, supplier) are represented as Node. More surprisingly, each Network is also considered a Node in the same way a storage cell is represented as Node in logistics. Slave Node - Software Details SlapOS Slave software consists of a POSIX operating system, SlapGRID, Supervisord and Buildout and is designed to run on any OS that supports GNU's GlibC and Supervisord (eg. GNU/Linux, FreeBSD, MacOS/X, Solaris, AIX et al.) At the time of writing, Microsoft Windows was partially supported (node only) through a GlibC implementation on Windows and a port of Supervisord to Windows. SlapGRID SlapGRID acts as the "glue" between the SlapOS Master and both Buildout and Supervisord. SlapGRID requests to SlapOS Master which software should be installed and executed. It uses Buildout to install software and Supervisord to start and stop software processes. SlapGRID also collects the usage data produced by each running software and transmits it to the SlapOS Master. Details Supervisord Supervisord is a process control daemon. It can be used to programmatically start and stop processes with different users, handle their output, log files, errors, etc. It is sort of an improved init.d which can be remotely controlled. Supervisord is lightweight and old enough to be really mature (i.e. no memory leaks). Buildout Buildout is a Python-based system for creating, assembling and deploying applications from multiple parts, some of which may be non Python-based. It allows to create Buildout configurations from which the same software can (later) be reproduced. Buildout originated from the Zope/Plone community to automate deployment of customized instances of their own software and has become a stable and mature software over the years. Please refer to understanding Buildout for a more detailed analysis of Buildout and why it is critical to the architecture of SlapOS.
Load more

Recommended publications
  • Zope Documentation Release 5.3
    Zope Documentation Release 5.3 The Zope developer community Jul 31, 2021 Contents 1 What’s new in Zope 3 1.1 What’s new in Zope 5..........................................4 1.2 What’s new in Zope 4..........................................4 2 Installing Zope 11 2.1 Prerequisites............................................... 11 2.2 Installing Zope with zc.buildout .................................. 12 2.3 Installing Zope with pip ........................................ 13 2.4 Building the documentation with Sphinx ............................... 14 3 Configuring and Running Zope 15 3.1 Creating a Zope instance......................................... 16 3.2 Filesystem Permissions......................................... 17 3.3 Configuring Zope............................................. 17 3.4 Running Zope.............................................. 18 3.5 Running Zope (plone.recipe.zope2instance install)........................... 20 3.6 Logging In To Zope........................................... 21 3.7 Special access user accounts....................................... 22 3.8 Troubleshooting............................................. 22 3.9 Using alternative WSGI server software................................. 22 3.10 Debugging Zope applications under WSGI............................... 26 3.11 Zope configuration reference....................................... 27 4 Migrating between Zope versions 37 4.1 From Zope 2 to Zope 4 or 5....................................... 37 4.2 Migration from Zope 4 to Zope 5.0..................................
    [Show full text]
  • The Hitchhiker's Guide to Packaging" Documentation
    The Hitchhiker’s Guide to Packaging" Documentation Release 1.0 Tarek Ziadé Sep 27, 2017 Contents 1 Table of Contents 3 1.1 Quick Start................................................3 1.2 Introduction to Packaging........................................5 1.3 Installing the Package Tools.......................................9 1.4 Using Packages.............................................. 12 1.5 Creating a Package............................................ 13 1.6 Contribute Your Package to the World.................................. 18 1.7 Virtual Environments........................................... 23 1.8 Specifications............................................... 24 1.9 Advanced Topics............................................. 28 1.10 Future of Packaging........................................... 28 1.11 Glossary................................................. 28 1.12 Credits.................................................. 31 1.13 License.................................................. 31 2 Indices and tables 33 Bibliography 35 i ii The Hitchhiker’s Guide to Packaging" Documentation, Release 1.0 Warning: This document is currently under development. Thank you for your interest. Contents 1 The Hitchhiker’s Guide to Packaging" Documentation, Release 1.0 2 Contents CHAPTER 1 Table of Contents Quick Start Here’s how to create a new project, which we’ll call TowelStuff. 1. Lay out your project The smallest python project is two files. A setup.py file which describes the metadata about your project, and a file containing Python code to implement the functionality of your project. In this example project we are going to add a little more to the project to provide the typical minimal layout of a project. We’ll create a full Python package, a directory with an __init__.py file, called towelstuff/. This anticipates future growth as our project’s source code is likely to grow beyond a single module file. We’ll also create a README.txt file describing an overview of your project, and a LICENSE.txt file containing the license of your project.
    [Show full text]
  • Create Book' Link = 'Mkbook' Mclass = 'Nav Buttons'
    Grok 4 Noobs. P R Sephton Grok 4 Noobs. A gentle introduction to using the Grok web framework 2 A gentle introduction to using the Grok web framework Table of Contents: 1: What does Grok do particularly well? ... [7] 1.1: What are the nicest things about Zope & Grok? ... [10] 2: Grok & Zope in a Nutshell ... [13] 3: The Compulsory Part about Installing Grok ... [19] 3.1: Installing Grok from Github ... [21] 3.2: Installation Notes - older projects ... [22] 4: A short introduction to the Zope Component Architecture ... [24] 4.1: The Z-Object Publishing Environment ... [29] 4.2: Interfaces compared to Abstract Bases ... [30] 4.2.1: Interfaces vs. Inheritence: A Real World Example ... [33] 4.3: Traversal and the Context ... [39] 4.4: The amazingly useful Utility ... [41] 4.5: Events Mechanism ... [42] 4.5.1: A quick megrok.rdb (SQLAlchemy) setup howto ... [44] 4.6: Extending existing objects with Annotations ... [46] 5: Designing a site, defining it's layout and implementing the code ... [47] 5.1: How to make applications with Grok ... [49] 5.1.1: Modeling data in an application ... [53] 5.1.1.1: Notes on multithreading ... [55] 5.1.1.2: The Scope of models in Traversal ... [57] 5.1.1.3: Rules of Persistence ... [58] 5.1.1.4: User Session Management ... [59] 5.1.2: Defining an Article and the Application ... [60] 5.1.3: HTML Re-use and site layout ... [62] 5.1.3.1: Macros: an alternative way to re-use HTML ... [67] 5.1.3.2: The full source for the layout.py module ..
    [Show full text]
  • Zope Project and Community Documentation
    Zope Project and Community Documentation The Zope developer community Jun 21, 2021 Contents 1 The World of Zope 3 1.1 Frameworks...............................................3 1.2 Databases.................................................4 1.3 Application Servers...........................................4 1.4 Tools...................................................4 2 Documentation 5 2.1 Documentation..............................................5 3 Community 7 3.1 Community................................................7 3.2 Developer Information..........................................8 i ii Zope Project and Community Documentation Zope is a free and open source web application server written in the object-oriented programming language Python. Since its release in 1998, Zope continues to grow into many distinct applications, frameworks, libraries and tools. The World of Zope highlights the most important components. Zope community projects are hosted in the Zope Foundation organization on GitHub. Contents 1 Zope Project and Community Documentation 2 Contents CHAPTER 1 The World of Zope A Bit of History In 1996 Jim Fulton, now Zope Corporation CTO, was drafted to teach a class on common gateway interface (CGI) programming, despite not knowing very much about the subject. CGI programming is a commonly-used web development model that allows developers to construct dynamic web sites. Traveling to the class, Jim studied all the existing documentation on CGI. On the way back, Jim considered what he didn’t like about traditional CGI- based programming environments. From these initial musings the core of Zope was written while flying back from the CGI class. Zope Corporation (then known as Digital Creations) went on to release three open-source software packages to support web publishing: Bobo, Document Template, and BoboPOS. These packages were written in a language called Python, and provided a web publishing facility, text templating, and an object database, respectively.
    [Show full text]
  • Easybuild: Building Software with Ease
    EasyBuild: Building Software With Ease. Kenneth Hoste, Jens Timmerman, Andy Georges, Stijn De Weirdt HPC team – Unit ICT infrastructure (DICT) – Ghent University Krijgslaan 281, building S9, 9000 Gent, BELGIUM E-mail: fkenneth.hoste, jens.timmerman, andy.georges, [email protected] Abstract—Maintaining a collection of software installations for • Incompleteness. For example, only compilation in the a diverse user base can be a tedious, repetitive, error-prone and source directory is supported and it is a hassle to actually time-consuming task. Because most end-user software packages install the executables, libraries and include files, etc. for an HPC environment are not readily available in existing OS package managers, they require significant extra effort from the • Non-standard procedure. Installation procedures are often user support team. Reducing this effort would free up a large far more involved than a sequence of configure, build and amount of time for tackling more urgent tasks. install steps. For example, the installation procedure can In this work, we present EasyBuild, a software installation be interactive, i.e., requiring human intervention during framework written in Python that aims to support the various the configuration and installation. installation procedures used by the vast collection of software packages that are typically installed in an HPC environment – • Custom-built scripts. On various occasions, custom shell catering to widely different user profiles. It is built on top of scripts need to be used, as opposed to a set of standard existing tools, and provides support for well-established installa- tools such as configure, make, cmake, etc. tion procedures. Supporting customised installation procedures • Hard-coded parameters.
    [Show full text]
  • Grok Community Docs Documentation Release 1.2
    Grok Community Docs Documentation Release 1.2 2010-11, The Grok Community November 16, 2011 CONTENTS 1 About the grok documentation3 1.1 Introduction...............................................3 1.2 Building the docs.............................................3 2 Data Access 5 2.1 Acess content in the static directory from Python code.........................5 2.2 Indexing and Searching Objects in the ZODB..............................6 2.3 Basic ORM with megrok.rdb and SQLAlchemy............................ 11 2.4 Grok ORM with Storm.......................................... 18 2.5 How I Got Grok Talking To CAS.................................... 22 2.6 Navigating To Transient Objects Tutorial................................ 25 2.7 Create simple 1:2 relationship with Megrok.rdb and SqlAlchemy (over MySql)............ 36 2.8 Understanding default values for object database backed attributes................... 41 3 Security and Authentication 45 3.1 Authentication with Grok........................................ 45 3.2 Authentication and authorization in Grok................................ 48 4 Views, Templating, Client Side 55 4.1 Fanstatic resources............................................ 55 4.2 Using a KSS plugin for Drag-and-Drop................................. 56 4.3 Using z3x.form with Grok........................................ 59 4.4 Traversing subpaths in views....................................... 61 4.5 Adding AJAX to Grok with KSS.................................... 63 4.6 Automatic Form Generation......................................
    [Show full text]
  • To Download the PDF of My Presentation
    VA DERS (Q: What does it say?) VA DERS VA DERS (A: ªSpace Invadersº) am U us am U us (A: ªAmbi guousº) convention — configuration convention — configuration (A: ªConvention ov er configurationº) Welcome! A Grok Talk Brandon Craig Rhodes November 2007 What©s a convention? Conventions are traditionally extras. Conventions begin as optional practices to keep code sane “We always capitalize the names of classes in the code we write for this department.” “If you have a class Foo, name its corresponding page template foo.pt.” “We're putting cover sheets on all the TPS reports before they go out.” What if ... ? What if your web framework used conventions rather than config files? A simple example: View “Index” app.config <configure view=”index” class=”Index” template= “index.pt” /> index.pt <html> <body> <h1>Title</h1> </body></html> A class you've View written “Index” app.config <configure view=”index” The configuration class=”Index” template= file you need to “index.pt” hook them up! /> index.pt A page template <html> <body> <h1>Title</h1> you've written </body></html> Conventions are traditionally ignored by the computer But, what if ... ? What if the framework assumed, in the absence of other configuration, that Index goes with index.pt? Result: View “Index” All explicit configuration has disapperaed index.pt <html> <body> <h1>Title</h1> </body></html> Advantages Ensue! Advantages of CoC: 1. Less repetition Advantages of CoC: 1. Less repetition 2. Conventions get used, because they matter Advantages of CoC: 1. Less repetition 2. Conventions
    [Show full text]
  • Buildout Release 1.2.1
    Buildout Release 1.2.1 Jim Fulton Nov 20, 2017 Contents 1 Screencasts 1 1.1 A Brief Introduction to Buildout.....................................1 1.2 Using buildout to install Zope and Plone................................1 2 Talks 3 2.1 How AlterWay releases web applications using zc.buildout.......................3 2.2 Buildout for pure Python projects....................................3 2.3 Buildout lightning talk..........................................3 2.4 Delivering egg-based applications with zc.buildout, using a distributed model.............3 3 Slides 5 3.1 Django & Buildout............................................5 3.2 Delivering applications with zc.buildout and a distributed model....................5 3.3 Buildout and Plone............................................5 3.4 Python eggs, zc.buildout, zopeproject and zope3............................5 3.5 Reaching Deployment Nirvana Using Buildout.............................5 4 What people says about Buildout ?7 5 Overview of the Installation Process9 6 Directory Structure of a Buildout 11 7 Use Case - A Single Module 15 8 Buildout Documentation 17 8.1 Getting Started.............................................. 17 8.2 Tutorials................................................. 17 8.3 Creating Recipes............................................. 17 8.4 List of Recipes.............................................. 17 8.5 Links................................................... 18 9 Buildout Tutorial 19 9.1 What is zc.buildout?..........................................
    [Show full text]
  • Versidad Autonoma De Bucaramanga Unab
    COMPARACION DEL DESARROLLO DE UN APLICATIVO WEB ENTRE LOS LENGUAJES DE PROGRAMACION PYTHON Y JAVA ANDRES FELIPE FOGLIA ARDILA UNIVERSIDAD AUTONOMA DE BUCARAMANGA UNAB FACULTAD DE INGENIERIA DE SISTEMAS GRUPO PRISMA LINEA DE TECNOLOGIA Y SOCIEDAD BUCARAMANGA 2014 COMPARACION DEL DESARROLLO DE UN APLICATIVO WEB ENTRE LOS LENGUAJES DE PROGRAMACION PYTHON Y JAVA ANDRES FELIPE FOGLIA ARDILA ANTEPROYECTO DE PROYECTO DE GRADO DIRECTOR DEL PROYECTO FREDDY MENDEZ ORTIZ , RENE LOBO QUINTERO DOCENTES DE LA FACULTAD DE INGENIERIA DE SISTEMAS UNIVERSIDAD AUTONOMA DE BUCARAMANGA UNAB FACULTAD DE INGENIERIA DE SISTEMAS GRUPO PRISMA LINEA DE TECNOLOGIA Y SOCIEDAD BUCARAMANGA 2014 CONTENIDO 1. Planteamiento del problema y justificación 2. Objetivos 3. Antecedentes 4. Estado del Arte 5. Marco teórico 5.1 Tecnología Java 5.2 Aplicaciones web en Java 5.3 Java Server Pages Technology 5.4 Tecnología Python 5.5 Desarrollo web en Python 6. Diseño metodológico 7. Informe Final 8. Evaluación del modelo de caracterización del aplicativo web 9. Conclusiones 10. Bibliografía 11. Anexos 11.1 QSOS 11.2 Modelo de caracterización del aplicativo web 1. PLANTEAMIENTO DEL PROBLEMA Y JUSTIFICACION En los últimos años se ha venido escuchando sobre Python un lenguaje de programación cada vez más conocido entre los programadores de todo el mundo por su elegante sintaxis, fácil manera de leer además de su gran facilidad que hace que programar no sea complicado, se dice también que este lenguaje va a ser el más utilizado y con el que más se va a trabajar en un futuro no muy lejano. Todas estas razones hacen pensar en por que no empezar a utilizar este lenguaje y para poder saber si todo esto es verdad se va a trabajar con él y hacer un aplicativo de las misma forma que se hace con la tecnología Java.
    [Show full text]
  • Presentation
    open-emv.com The Team Roadmap • Introduction • Solution Overview • Energy Efficiency 101 • Site Tour • Under the Hood • Basic Machine Configuration (AMIs) • Software Configuration • Database Structure • The Web Application The Solution User's Browser jQuery OpenLayers Issue Tracking VCS (FogBugz) (beanstalk) User AWS EC2 m2.xlarge c1.medium (high-memory) (high-CPU) Database Applications Front-End Applications ZEO Zope Client Apache Zope Object Database Server Zope Client Zope Client PG Django PostgreSQL Database Bouncer (mod_wsgi) monitoring monitoring Development Machine zc.buildout mr.developer m1.small Monitoring Dashboard Developer Why CA Energy Efficiency? World Leader • 1.5 Million Jobs • $45 Billion in Payroll How does that compare to the rest of the U.S? California... • ... spends billions less on Electricity • ... has a ratio of GDP to Energy Consumed 68% higher • ... residents, per capita, pay lower utility bills !"#$%&'()*+(,()-+()./0'-,1)./023)4()&5)&-)*(,()$6)(7.&('-)$6)8$2&5/,'&$9:) ;))<9)=/(2)>(,,1?)@('-0,().$A&-$2&6-?)5/0'3(,)/5)=(B-)CD) Energy Efficiency and EMV How Does CA do Energy Efficiency? • CPUC established EE program cycle length and funding level • CPUC provides $ to utilities to implement EE Programs • Utilities report program accomplishments to CPUC How Does CA do Energy Efficiency? • CPUC hires independent EMV contractors to independently evaluate utility savings claims • CPUC awards $ to the utilities based on savings accomplishments • CPUC releases data publicly via website Rinse and Repeat Roadmap • Introduction
    [Show full text]
  • Version + Patches = Buildout
    Understanding Buildout In SlapOS Details Buildout is a Python-based system for creating, assembling and deploying applications from multiple parts, which may or not be Python-based. It allows to create Buildout configuration files from which the exact same software can (later) be reproduced. Buildout originated from the Zope/Plone community to automate the deployment of customized instances of their own software. Lead by Jim Fulton (CTO of Zope Corporation), Buildout has become a stable and mature software over the years (source code). Buildout is an integral part of SlapOS. The following design document explains what Buildout is and how Buildout files are used in SlapOS before discussing advantages and alleged shortcomings of Buildout. For more information on the way Buildout is integrated in the SlapOS ecosystem, refer to the SlapOS architecture introduction. Table of Content Introducing Buildout Simple Buildout Example Buildout.cfg Walkthrough Advantages of Buildout Details Introducing Buildout Details Buildout is a tool for automating software assembly including running build tools to build software and applying software and templates to generate configuration files and scripts Buildout is applicable to all phases of software development and in production deployment. It is based on three core principles: Repeatability, Componentization and Automation. slapos.buildout (Gitlab repository) is a fork of zc.buildout maintained by SlapOS which includes various fixes that may or may not have been merged back into Buildout upstream (see Buildout developer guidelines for how to contribute to Buildout). Why Buildout? Details Buildout is used in SlapOS to define what software to install and instantiate on a node and is therefore key to the architecture of SlapOS.
    [Show full text]
  • BUILDOUT Quick Reference
    Six Feet Up BUILDOUT Quick Reference Configuration (continued) Vocabulary buildout - A set of parts that describe how to assemble an application Clone a part using macros part - A set of options that allow you to build a piece of the application recipe - The software used to create a part based off of its options [original] option1 = foo Getting Started With a Plone Buildout [clone] You can add a default.cfg into your $HOME/.buildout directory to set up some user <= original option2 = bar defaults for any part of the buildout. You will have to manually create each of the directories shown here: Now the cloned part has option 1 and 2. [buildout] eggs-directory = /path/to/home/.buildout/eggs Assignments download-cache = /path/to/home/.buildout/downloads zope-directory = /path/to/home/.buildout/zope Assignments give you the ability to set section options via the command line. extends-cache = /path/to/home/.buildout/extends Assignments are in the form of: NOTE: These only provide defaults, they do not override settings in your buildout! section_name:option_name=value How to get started with a Plone buildout: Here are some examples: To start from scratch, you can use the ZopeSkel collection of templates: Set the log-level of the buildout section (This is equivalent to bin/buildout -vvvvv): $ easy_install -U ZopeSkel $ paster create -t plone4_buildout $ bin/buildout buildout:log-level=50 This will ask you a series of questions about your new buildout. Turn on debug mode for the instance: Once you have your buildout, you can now bootstrap it: $ bin/buildout instance:debug-mode=on $ cd path/to/buildout $ python2.6 bootstrap.py $ bin/buildout Links Now you have everything you’ll need to start your site (assuming the part names are zeoserver and instance).
    [Show full text]