Step-by-Step
1. Adds step-by-step section to the AppDev guide (based on ApacheHTTPServer application) 2. Adds some dependent files: 3 images for step-by-step and prepare_lab.rst to the Admin guide for prerequisites. Change-Id: I4c57214a0bd37f04a093221597b72c1c5e560f16
This commit is contained in:
OlgaGusarenko
parent
67589c7c12
commit
7304043c9c
226
doc/source/draft/admin-guide/prepare_lab.rst
Normal file
226
doc/source/draft/admin-guide/prepare_lab.rst
Normal file
@ -0,0 +1,226 @@
|
||||
..
|
||||
Copyright 2015-2016 Mirantis, Inc.
|
||||
|
||||
Licensed under the Apache License, Version 2.0 (the "License"); you may
|
||||
not use this file except in compliance with the License. You may obtain
|
||||
a copy of the License at
|
||||
|
||||
http://www.apache.org/licenses/LICENSE-2.0
|
||||
|
||||
Unless required by applicable law or agreed to in writing, software
|
||||
distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
|
||||
WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
|
||||
License for the specific language governing permissions and limitations
|
||||
under the License.
|
||||
|
||||
========================
|
||||
Prepare A Lab For Murano
|
||||
========================
|
||||
This section provides basic information about lab's system requirements.
|
||||
It also contains a description of a test which you may use to check if
|
||||
your hardware fits the requirements. To do this, run the test and
|
||||
compare the results with baseline data provided.
|
||||
|
||||
|
||||
.. _system_prerequisites:
|
||||
|
||||
System prerequisites
|
||||
~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Supported Operation Systems
|
||||
---------------------------
|
||||
|
||||
* Ubuntu Server 12.04 LTS
|
||||
* RHEL/CentOS 6.4
|
||||
|
||||
**System packages are required for Murano**
|
||||
|
||||
*Ubuntu*
|
||||
|
||||
* gcc
|
||||
|
||||
* python-pip
|
||||
|
||||
* python-dev
|
||||
|
||||
* libxml2-dev
|
||||
|
||||
* libxslt-dev
|
||||
|
||||
* libffi-dev
|
||||
|
||||
* libmysqlclient-dev
|
||||
|
||||
* libpq-dev
|
||||
|
||||
* python-openssl
|
||||
|
||||
* mysql-client
|
||||
|
||||
* python-mysqldb
|
||||
|
||||
Install all the requirements on Ubuntu by running::
|
||||
|
||||
# apt-get install gcc python-pip python-dev \
|
||||
libxml2-dev libxslt-dev libffi-dev libmysqlclient-dev \
|
||||
libpq-dev python-openssl mysql-client python-mysqldb
|
||||
|
||||
*CentOS*
|
||||
|
||||
* gcc
|
||||
|
||||
* python-pip
|
||||
|
||||
* python-devel
|
||||
|
||||
* libxml2-devel
|
||||
|
||||
* libxslt-devel
|
||||
|
||||
* libffi-devel
|
||||
|
||||
* postgresql-devel
|
||||
|
||||
* pyOpenSSL
|
||||
|
||||
* mysql
|
||||
|
||||
* MySQL-python
|
||||
|
||||
Install all the requirements on CentOS by running::
|
||||
|
||||
# yum install gcc python-pip python-devel libxml2-devel \
|
||||
libxslt-devel libffi-devel postgresql-devel pyOpenSSL \
|
||||
mysql MySQL-python
|
||||
|
||||
.. _lab_requirements:
|
||||
|
||||
Lab Requirements
|
||||
----------------
|
||||
|
||||
+------------+--------------------------------+----------------------+
|
||||
| Criteria | Minimal | Recommended |
|
||||
+============+================================+======================+
|
||||
| CPU | 4 core @ 2.4 GHz | 24 core @ 2.67 GHz |
|
||||
+------------+--------------------------------+----------------------+
|
||||
| RAM | 8 GB | 24 GB or more |
|
||||
+------------+--------------------------------+----------------------+
|
||||
| HDD | 2 x 500 GB (7200 rpm) | 4 x 500 GB (7200 rpm |
|
||||
+------------+--------------------------------+----------------------+
|
||||
| RAID | Software RAID-1 (use mdadm as | Hardware RAID-10 |
|
||||
| | it will improve read | |
|
||||
| | performance almost two times) | |
|
||||
+------------+--------------------------------+----------------------+
|
||||
|
||||
`Table: Hardware requirements`
|
||||
|
||||
There are a few possible storage configurations except the shown above.
|
||||
All of them were tested and were working well.
|
||||
|
||||
* 1x SSD 500+ GB
|
||||
|
||||
* 1x HDD (7200 rpm) 500+ GB and 1x SSD 250+ GB (install the system onto
|
||||
the HDD and mount the SSD drive to folder where VM images are)
|
||||
|
||||
* 1x HDD (15000 rpm) 500+ GB
|
||||
|
||||
|
||||
Test Your Lab Host Performance
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
We have measured time required to boot 1 to 5 instances of Windows
|
||||
system simultaneously. You can use this data as the baseline to check if
|
||||
your system is fast enough.
|
||||
|
||||
You should use sysprepped images for this test, to simulate VM first
|
||||
boot.
|
||||
|
||||
Steps to reproduce test:
|
||||
|
||||
#. Prepare Windows 2012 Standard (with GUI) image in QCOW2 format. Let's
|
||||
assume that its name is ws-2012-std.qcow2
|
||||
|
||||
#. Ensure that there is NO KVM PROCESSES on the host. To do this, run
|
||||
command:
|
||||
|
||||
::
|
||||
|
||||
># ps aux | grep kvm
|
||||
|
||||
#. Make 5 copies of Windows image file:
|
||||
|
||||
::
|
||||
|
||||
># for i in $(seq 5); do \
|
||||
cp ws-2012-std.qcow2 ws-2012-std-$i.qcow2; done
|
||||
|
||||
#. Create script start-vm.sh in the folder with .qcow2 files:
|
||||
|
||||
::
|
||||
|
||||
#!/bin/bash
|
||||
[ -z $1 ] || echo "VM count not provided!"; exit 1
|
||||
for i in $(seq $1); do
|
||||
echo "Starting VM $i ..."
|
||||
kvm -m 1024 -drive file=ws-2012-std-$i.qcow2,if=virtio -net user -net nic,model=virtio -nographic -usbdevice tablet -vnc :$i & done
|
||||
|
||||
#. Start ONE instance with command below (as root) and measure time
|
||||
between VM’s launch and the moment when Server Manager window
|
||||
appears. To view VM’s desktop, connect with VNC viewer to your host
|
||||
to VNC screen :1 (port 5901):
|
||||
|
||||
::
|
||||
|
||||
># ./start-vm.sh 1
|
||||
|
||||
#. Turn VM off. You may simply kill all KVM processes by
|
||||
|
||||
::
|
||||
|
||||
># killall kvm
|
||||
|
||||
#. Start FIVE instances with command below (as root) and measure time
|
||||
interval between ALL VM’s launch and the moment when LAST Server Manager
|
||||
window appears. To view VM’s desktops, connect with VNC viewer to your
|
||||
host to VNC screens :1 thru :5 (ports 5901-5905):
|
||||
|
||||
::
|
||||
|
||||
># ./start-vm.sh 5
|
||||
|
||||
#. Turn VMs off. You may simply kill all KVM processes by
|
||||
|
||||
::
|
||||
|
||||
># killall kvm
|
||||
|
||||
|
||||
Baseline Data
|
||||
~~~~~~~~~~~~~
|
||||
|
||||
The table below provides baseline data which we've got in our
|
||||
environment.
|
||||
|
||||
+----------------+--------------------------+---------------------+
|
||||
| | Boot 1 instance | Boot 5 instances |
|
||||
+================+==========================+=====================+
|
||||
| Avg. Time | 3m:40s | 8m |
|
||||
+----------------+--------------------------+---------------------+
|
||||
| Max. Time | 5m | 20m |
|
||||
+----------------+--------------------------+---------------------+
|
||||
|
||||
``Avg. Time`` refers to the lab with recommended hardware configuration,
|
||||
while ``Max. Time`` refers to minimal hardware configuration.
|
||||
|
||||
|
||||
Host Optimizations
|
||||
~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Default KVM installation could be improved to provide better
|
||||
performance.
|
||||
|
||||
The following optimizations may improve host performance up to 30%:
|
||||
|
||||
* change default scheduler from ``CFQ`` to ``Deadline``
|
||||
* use ``ksm``
|
||||
* use ``vhost-net``
|
||||
BIN
doc/source/draft/appdev-guide/logo.png
Normal file
BIN
doc/source/draft/appdev-guide/logo.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 33 KiB |
BIN
doc/source/draft/appdev-guide/step_1.png
Normal file
BIN
doc/source/draft/appdev-guide/step_1.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 44 KiB |
BIN
doc/source/draft/appdev-guide/step_2.png
Normal file
BIN
doc/source/draft/appdev-guide/step_2.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 76 KiB |
@ -1,8 +1,597 @@
|
||||
.. _step-by-step:
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
|
||||
============
|
||||
Step-by-Step
|
||||
============
|
||||
|
||||
The goal of this manual is to walk you through the steps
|
||||
that should be taken while composing an application package
|
||||
to get it ready for uploading to Murano.
|
||||
|
||||
This tutorial uses a demo application named ApacheHTTPServer
|
||||
to demonstrate how you can create your own Murano application
|
||||
from scratch. We will walk you through its source code and
|
||||
explain how to upload it.
|
||||
|
||||
ApacheHTTPServer is a simple Murano application that spawns
|
||||
a virtual machine and installs Apache HTTP Server on it.
|
||||
It may also install php if a user wants to.
|
||||
|
||||
The source code of ApacheHTTPServer is available at `github
|
||||
<https://github.com/openstack/murano-apps/tree/master/ApacheHTTPServer/package>`_.
|
||||
|
||||
ApacheHTTPServer's source code is written in MuranoPL.
|
||||
This programming language is object-oriented, and we will
|
||||
see classes, objects and object instances. The detailed
|
||||
explanation of its syntax can be found in the :ref:`MuranoPL
|
||||
reference <murano-pl>`.
|
||||
|
||||
.. warning::
|
||||
Before you start the Murano application creation process, please consider
|
||||
the :ref:`System prerequisites <system_prerequisites>` and
|
||||
:ref:`Lab requirements <lab_requirements>` in order you do not risk
|
||||
starting with a wrong environment
|
||||
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
|
||||
|
||||
Step 1. Create the structure of the package
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
You should structure an application package very neatly in order
|
||||
the application could be managed and deployed in the catalog
|
||||
successfully.
|
||||
|
||||
The package structure of ApacheHTTPServer package is::
|
||||
|
||||
..
|
||||
|
||||
|_ Classes
|
||||
| |_ ApacheHttpServer.yaml
|
||||
|
|
||||
|_ Resources
|
||||
| |_ scripts
|
||||
| |_runApacheDeploy.sh
|
||||
| |_ DeployApache.template
|
||||
|
|
||||
|_ UI
|
||||
| |_ ui.yaml
|
||||
|
|
||||
|_ logo.png
|
||||
|
|
||||
|_ manifest.yaml
|
||||
|
||||
The detailed information regarding the package structure can be found
|
||||
in the `Murano packages structure <package_structure>`_ section.
|
||||
|
||||
|
||||
Step 2. Create the manifest file
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
The application manifest file contains general application metadata.
|
||||
It is an entry-point for each Murano application, and is very similar
|
||||
to the manifest of a jar archive. It has a fixed format based on YAML.
|
||||
|
||||
The ApacheHTTPServer's manifest file:
|
||||
|
||||
.. code-block:: yaml
|
||||
:linenos:
|
||||
|
||||
Format: 1.0
|
||||
Type: Application
|
||||
FullName: io.murano.apps.apache.ApacheHttpServer
|
||||
Name: Apache HTTP Server
|
||||
Description: |
|
||||
The Apache HTTP Server Project is an effort to develop and maintain an
|
||||
open-source HTTP server for modern operating systems including UNIX and
|
||||
Windows NT.
|
||||
...
|
||||
Author: Mirantis, Inc
|
||||
Tags: [HTTP, Server, WebServer, HTML, Apache]
|
||||
Classes:
|
||||
io.murano.apps.apache.ApacheHttpServer: ApacheHttpServer.yaml
|
||||
|
||||
Now, let's inspect ``manifest.yaml`` line-by-line.
|
||||
|
||||
Format
|
||||
------
|
||||
|
||||
Specifies the version of the format for manifest.yaml to track
|
||||
the syntax changes. Format key presents in each manifest file.
|
||||
Currently, ``1.0`` is the only available version:
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
Format: 1.0
|
||||
|
||||
Type
|
||||
----
|
||||
|
||||
Specifies the type of the package:
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
Type: Application
|
||||
|
||||
.. note::
|
||||
``Application`` starts with the capital letter.
|
||||
This is the naming convention for all the pre-defined values
|
||||
in Murano code.
|
||||
|
||||
FullName
|
||||
--------
|
||||
|
||||
Stands for the unique service application name. That name
|
||||
allows to easily recognize to which scope an application
|
||||
belongs. All other applications can address to the Apache
|
||||
application methods by this name.
|
||||
|
||||
To ensure the global uniqueness, the same naming
|
||||
convention as the naming convention of Java packages and
|
||||
classes is followed. The ``io.murano.apps.apache.`` part
|
||||
is the "package" part of the name, while ``ApacheHttpServer``
|
||||
stands for the "class" part of the name:
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
FullName: io.murano.apps.apache.ApacheHttpServer
|
||||
|
||||
.. note::
|
||||
It is not necessary that all applications belong to one domain.
|
||||
This naming allows to determine an application group by its name.
|
||||
Openstack-related applications may have full names, started with
|
||||
``org.openstack.apps``, for example, ``org.openstack.apps.Rally``
|
||||
|
||||
|
||||
Name
|
||||
----
|
||||
|
||||
Stands for the display name of the application. You will be able to reset a display name
|
||||
when you upload ApacheHTTPServer package to Murano:
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
Name: Apache HTTP Server
|
||||
|
||||
Description
|
||||
-----------
|
||||
|
||||
Contains the application decription rendered under the application title:
|
||||
|
||||
.. code-block:: yaml
|
||||
:linenos:
|
||||
|
||||
Description: |
|
||||
The Apache HTTP Server Project is an effort to develop and maintain an
|
||||
open-source HTTP server for modern operating systems including UNIX and
|
||||
Windows NT. The goal of this project is to provide a secure, efficient and
|
||||
extensible server that provides HTTP services in sync with the current HTTP
|
||||
standards.
|
||||
Apache httpd has been the most popular web server on the Internet since
|
||||
April 1996, and celebrated its 17th birthday as a project this February.
|
||||
|
||||
Lets's take a closer look at the syntax:
|
||||
|
||||
The vertical line ``|`` symbol comes from YAML syntax.
|
||||
The ``>`` symbol can be used interchangeably.
|
||||
These are the `YAML block style indicators <http://yaml.org/spec/current.html#id2537921>`_,
|
||||
which mean that all the leading indents and new line symbols should be preserved.
|
||||
This is very useful for long, multi-line descriptions, because this affects how
|
||||
they are desplayed on the UI.
|
||||
|
||||
.. warning::
|
||||
Avoid tab symbols inside YAML files. If YAML contains the tab symbol, it will not
|
||||
be parsed correctly. The error message may be cryptic or misleading.
|
||||
We recommend that you check the YAML syntax before composing the application
|
||||
package using any of the available online tools.
|
||||
|
||||
|
||||
Author
|
||||
------
|
||||
|
||||
Contains the name of the author of an application, it is only displayed
|
||||
in the application details and does not affect anything.
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
Author: Mirantis, Inc
|
||||
|
||||
.. note::
|
||||
Single quotes usage is optional here: ``Author: 'Mirantis, Inc'``,
|
||||
thus they are omitted in the code extract below.
|
||||
|
||||
|
||||
Tags
|
||||
----
|
||||
|
||||
Is an array of tags. You can search an application by its tag.
|
||||
You may want to specify several tags for one application:
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
Tags: [HTTP, Server, WebServer, HTML, Apache]
|
||||
|
||||
Besides, YAML allows tag specification using another syntax,
|
||||
which is an equivalent to the one given above:
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
Tags:
|
||||
- HTTP
|
||||
- Server
|
||||
- WebServer
|
||||
- HTML
|
||||
- Apache
|
||||
|
||||
Classes
|
||||
-------
|
||||
|
||||
Is a mapping between all classes present in ApacheHttpServer application
|
||||
and the file names where these classes are defined in. This is one-to-one relatioonship,
|
||||
which means that there is one and the only class per a single file.
|
||||
|
||||
The line ``io.murano.apps.apache.ApacheHttpServer: ApacheHttpServer.yaml`` says that the class ``io.murano.apps.apache.ApacheHttpServer`` is defined in the file ``ApacheHttpServer.yaml``:
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
Classes:
|
||||
io.murano.apps.apache.ApacheHttpServer: ApacheHttpServer.yaml
|
||||
|
||||
|
||||
Step 3. Create the execution plan template
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
The execution plan template contains the instructions understandable to the murano
|
||||
agent on what should be executed to deploy an application. It is the file with the
|
||||
``.template`` extension located in the ``/APP_NAME/resources`` directory.
|
||||
|
||||
The ApacheHTTPServer's DeployApache.template:
|
||||
|
||||
.. code-block:: yaml
|
||||
:linenos:
|
||||
|
||||
FormatVersion: 2.0.0
|
||||
Version: 1.0.0
|
||||
Name: Deploy Apache
|
||||
|
||||
Parameters:
|
||||
enablePHP: $enablePHP
|
||||
|
||||
Body: |
|
||||
return apacheDeploy('{0}'.format(args.enablePHP)).stdout
|
||||
|
||||
Scripts:
|
||||
apacheDeploy:
|
||||
Type: Application
|
||||
Version: 1.0.0
|
||||
EntryPoint: runApacheDeploy.sh
|
||||
Files: []
|
||||
Options:
|
||||
captureStdout: true
|
||||
captureStderr: true
|
||||
|
||||
As it can be viewed from the source code, besides specifying versions of different items,
|
||||
ApacheHTTPServer execution plan accepts the ``enablePHP`` parameter. This parameter is
|
||||
an input parameter to the ``apacheDeploy.sh`` script. This script initiates ``runApacheDeploy.sh``
|
||||
execution, witch is also located at the ``Resources`` directory and installs apache app and php
|
||||
if selected.
|
||||
|
||||
For the detailed information regarding the execution plan template, its sections and syntax,
|
||||
please refer to the :ref:`Execution plan template <exec_plan>`.
|
||||
|
||||
|
||||
Step 4. Create the dynamic UI form definition
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
ApacheHTTPServer's ui.yaml source code:
|
||||
|
||||
.. code-block:: yaml
|
||||
:linenos:
|
||||
|
||||
Version: 2
|
||||
|
||||
Application:
|
||||
?:
|
||||
type: io.murano.apps.apache.ApacheHttpServer
|
||||
name: $.appConfiguration.name
|
||||
enablePHP: $.appConfiguration.enablePHP
|
||||
instance:
|
||||
?:
|
||||
type: io.murano.resources.LinuxMuranoInstance
|
||||
name: generateHostname($.instanceConfiguration.unitNamingPattern, 1)
|
||||
flavor: $.instanceConfiguration.flavor
|
||||
image: $.instanceConfiguration.osImage
|
||||
keyname: $.instanceConfiguration.keyPair
|
||||
availabilityZone: $.instanceConfiguration.availabilityZone
|
||||
assignFloatingIp: $.appConfiguration.assignFloatingIP
|
||||
|
||||
Forms:
|
||||
- appConfiguration:
|
||||
fields:
|
||||
- name: license
|
||||
type: string
|
||||
description: Apache License, Version 2.0
|
||||
hidden: true
|
||||
required: false
|
||||
- name: name
|
||||
type: string
|
||||
label: Application Name
|
||||
initial: 'ApacheHttpServer'
|
||||
description: >-
|
||||
Enter a desired name for the application. Just A-Z, a-z, 0-9, dash and
|
||||
underline are allowed
|
||||
- name: enablePHP
|
||||
label: Enable PHP
|
||||
type: boolean
|
||||
description: >-
|
||||
Add php support to the Apache WebServer
|
||||
initial: false
|
||||
required: false
|
||||
widgetMedia:
|
||||
css: {all: ['muranodashboard/css/checkbox.css']}
|
||||
- name: assignFloatingIP
|
||||
type: boolean
|
||||
label: Assign Floating IP
|
||||
description: >-
|
||||
Select to true to assign floating IP automatically
|
||||
initial: false
|
||||
required: false
|
||||
widgetMedia:
|
||||
css: {all: ['muranodashboard/css/checkbox.css']}
|
||||
- name: dcInstances
|
||||
type: integer
|
||||
hidden: true
|
||||
initial: 1
|
||||
|
||||
...
|
||||
|
||||
Now, let's inspect it line-by-line.
|
||||
|
||||
Application
|
||||
-----------
|
||||
|
||||
Defines the object model by which engine deploys the ApacheHTTPServer
|
||||
application, and includes YAQL expressions.
|
||||
|
||||
The section contains the reference to the Apache class,
|
||||
the one that is provided in the manifest, named with the `?`
|
||||
symbol. This indicates system information:
|
||||
|
||||
.. code-block:: yaml
|
||||
:linenos:
|
||||
|
||||
Application:
|
||||
?:
|
||||
type: io.murano.apps.apache.ApacheHttpServer
|
||||
|
||||
For ApacheHTTPServer application it is defined that the user should input the application name,
|
||||
some instance parameters and decide whether PHP should be enabled or not:
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
enablePHP: $.appConfiguration.enablePHP
|
||||
|
||||
The `instance` section assumes that the value, entered by the user in the first form
|
||||
named ``appConfiguration`` is stored in an application object module. The same applies
|
||||
for the instance parameter. Providing the question mark with the defined type
|
||||
``io.murano.resources.LinuxMuranoInstance`` indicates an instance of MuranoPl object.
|
||||
|
||||
.. code-block:: yaml
|
||||
:linenos:
|
||||
|
||||
instance:
|
||||
?:
|
||||
type: io.murano.resources.LinuxMuranoInstance
|
||||
|
||||
.. note::
|
||||
This parameter is named ``instance`` here because its class definition
|
||||
property has the ``instance`` name. You can specify any name in
|
||||
the :ref:`class definition file <step_5_class_definition>`,
|
||||
and then use it in the UI form definition.
|
||||
|
||||
Forms
|
||||
-----
|
||||
|
||||
Contains UI forms prototypes that are merged to the application
|
||||
creation wizard.
|
||||
|
||||
Each form field will be translated to the Django field and most of
|
||||
the parameters correspond to parameters in the Django form field.
|
||||
All fields are required by default. Hidden fields are used to print
|
||||
extra information in the form description.
|
||||
|
||||
After the upload, the section content will be browsed on the left
|
||||
side of the form and its description on the right.
|
||||
|
||||
Please take a look at the :guilabel:`Configure Application: Apache HTTP Server` dialog:
|
||||
|
||||
.. image:: step_1.png
|
||||
|
||||
.. note::
|
||||
The :guilabel:`assignFloatingIP` and :guilabel:`enablePHP`
|
||||
boolean fields are shown as checkboxes.
|
||||
|
||||
Here is how the second dialog looks like:
|
||||
|
||||
.. image:: step_2.png
|
||||
|
||||
|
||||
.. _step_5_class_definition:
|
||||
|
||||
Step 5: Define MuranoPL class definitions
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
All application classes are located in the ``Classes`` folder. As ApacheHttpServer
|
||||
uses only one class, just one file can be found in this directory.
|
||||
|
||||
Here is how it looks like:
|
||||
|
||||
.. code-block:: yaml
|
||||
:linenos:
|
||||
|
||||
Namespaces:
|
||||
=: io.murano.apps.apache
|
||||
std: io.murano
|
||||
res: io.murano.resources
|
||||
sys: io.murano.system
|
||||
|
||||
Name: ApacheHttpServer
|
||||
|
||||
Extends: std:Application
|
||||
|
||||
Properties:
|
||||
name:
|
||||
Contract: $.string().notNull()
|
||||
|
||||
enablePHP:
|
||||
Contract: $.bool()
|
||||
Default: false
|
||||
|
||||
instance:
|
||||
Contract: $.class(res:Instance).notNull()
|
||||
|
||||
Methods:
|
||||
initialize:
|
||||
Body:
|
||||
- $._environment: $.find(std:Environment).require()
|
||||
|
||||
deploy:
|
||||
Body:
|
||||
- If: not $.getAttr(deployed, false)
|
||||
Then:
|
||||
- $._environment.reporter.report($this, 'Creating VM for Apache Server.')
|
||||
- $securityGroupIngress:
|
||||
...
|
||||
- $._environment.securityGroupManager.addGroupIngress($securityGroupIngress)
|
||||
- $.instance.deploy()
|
||||
- $resources: new(sys:Resources)
|
||||
- $template: $resources.yaml('DeployApache.template').bind(dict(enablePHP => $.enablePHP))
|
||||
- $._environment.reporter.report($this, 'Instance is created. Deploying Apache')
|
||||
- $.instance.agent.call($template, $resources)
|
||||
- $._environment.reporter.report($this, 'Apache is installed.')
|
||||
- $.setAttr(deployed, true)
|
||||
|
||||
Now, let's inspect it line-by-line.
|
||||
|
||||
Namespaces
|
||||
----------
|
||||
|
||||
Can be named *shortcuts* since this is an additional section
|
||||
which enables short names instead of the long ones:
|
||||
|
||||
.. code-block:: yaml
|
||||
:linenos:
|
||||
|
||||
Namespaces:
|
||||
=: io.murano.apps.apache
|
||||
std: io.murano
|
||||
res: io.murano.resources
|
||||
sys: io.murano.system
|
||||
|
||||
.. note::
|
||||
``=:`` refers to the *current* namespace
|
||||
|
||||
Name
|
||||
----
|
||||
|
||||
Contains the class name that is defined in this file.
|
||||
So full class name will be current namespace and name, provided by corresponding key: ``io.murano.apps.apache.ApacheHttpServer``:
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
Name: ApacheHttpServer
|
||||
|
||||
.. note::
|
||||
One .yaml file should contain only one class definition.
|
||||
|
||||
Extends
|
||||
-------
|
||||
|
||||
Determines inheritance, and ``io.murano.Application`` should be a parent
|
||||
for all the murano applications.
|
||||
|
||||
This class has defined deploy method and only instances of that class can be used in Environment class.
|
||||
Environment class, in its turn, is responsible for the deployment configurations. Definition of both
|
||||
classes are located at meta/io.murano folder of murano repository.
|
||||
|
||||
Thus, if you want to have some modifications of ApacheHttpServer, you can set io.murano.apps.apache.ApacheHttpServer
|
||||
in the Extends section of a new Application class:
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
Extends: std:Application
|
||||
|
||||
Properties
|
||||
----------
|
||||
|
||||
Defines the dictionary.
|
||||
Apache HTTP Server application has three properties: ``name``, ``enablePHP`` and ``instance``.
|
||||
For each of them certain ``Contract`` is defined.
|
||||
|
||||
Only ``enablePHP`` is optional, and its default value equals to ``false``.
|
||||
|
||||
``Instance`` is the required parameter and should be an instance of the predefined in core library ``io.murano.resources.Instance`` class.
|
||||
|
||||
Methods
|
||||
-------
|
||||
|
||||
The ``initialize`` method is like ``__init__`` in Python, and executes together with properties
|
||||
initialization.
|
||||
|
||||
It accesses the environment, which the application belongs to, and is used only for
|
||||
sending reports about the deployment state.
|
||||
|
||||
Private variable ``_environment`` is defined as follows:
|
||||
|
||||
.. code-block:: yaml
|
||||
:linenos:
|
||||
|
||||
initialize:
|
||||
Body:
|
||||
- $._environment: $.find(std:Environment).require()
|
||||
|
||||
The ``deploy`` method sets up instance spawning and configuration. This method should be executed
|
||||
only once. So in the first order deployed variable is checked to be false in the
|
||||
current scope.
|
||||
|
||||
It performs the following actions:
|
||||
|
||||
* configures securityGroups;
|
||||
* initiates new virtual machine spawning: ``$.instance.deploy()``
|
||||
* loads the execution plan template, located in the ``Resources`` directory to the
|
||||
instance of resources class: ``$resources.yaml('DeployApache.template')``
|
||||
* updates the plan with parameters taken from the user: ``bind(dict(enablePHP => $.enablePHP))``
|
||||
* sends ready-to-execute-plan to murano agent: ``$.instance.agent.call($template, $resources)``
|
||||
|
||||
|
||||
Step 6. Add the application logo (optional)
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Download or create your own ``.png`` image associated with your application.
|
||||
|
||||
The recommended size is 70x70 px, and the square shape is preferable.
|
||||
There are no limits regarding the image filename. In Apache HTTP Server we
|
||||
use the default name ``logo.png``:
|
||||
|
||||
.. image:: logo.png
|
||||
|
||||
|
||||
Step 7. Compose a zip archive
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Select all the files prepared for the package and create an archive in zip format.
|
||||
If the command is executed from the console, do not forget to add the ``-r`` option
|
||||
to include all the attachments.
|
||||
|
||||
.. note::
|
||||
The manifest file should not contain the root folder. In other words, the manifest
|
||||
should be located in the archive root directory.
|
||||
|
||||
|
|
||||
|
||||
**Congratulations! Your application is ready to be uploaded to the application catalog.**
|
||||
|
||||
.. TODO: add links to "How to upload a package" (OG)
|
||||
|
||||
|
||||
@ -39,6 +39,7 @@ Admin User Guide
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
|
||||
admin-guide/prepare_lab
|
||||
admin-guide/installation
|
||||
admin-guide/manage_images
|
||||
admin-guide/manage_categories
|
||||
|
||||
Loading…
Reference in New Issue
Block a user