Jump to: navigation, search


What is Dasiy?

Daisy,Meaning: Daisy, a wonderful thing.

Daisy is a sub project of Openstack, for the deployment of centos+openstack on bare metal. Daisy provides standard RestFul interface, with interface, users can complete the configuration operation with dashboard, then click cluster deployment button, greatly simplify the configuration for user, the deployment process without manual intervention, to achieve the operating system and the Openstack of fully automatic deployment, enhances ease of use.

development future: as a deployment tool, Daisy will support the subsequent deployment of different back-end.

interface: Daisy provide two interfaces,:CLI and Restful ,so it is also determined that the Daisy can be achieved through the command line or dashboard page to achieve the deployment capabilities.

About services:

Daisy's installation package contains the following services:

1. Daisy

1) daisy-api: Responsible for providing external interface calls.

2) daisy-registry: responsible for database related operations. (the required parameters are written to the MariaDB database through the daisy command, when deployed, to implement).

3) daisy-orchestration: whether there is a new blade in the monitoring cluster, to achieve the automatic expansion of the computing node


In the process of automatic deployment , Daisy  need to install the blade automatically reported their information, so use the ironic function, so the bin Daisy package is also integrated with the ironic related services.

1) ironic-discoverd: responsible for the host to find and report the hardware information of the node.

2) ironic-api and ironic-conductor: responsible for providing the interface to the reported data written to the ironic database.

3. keystone openstack-keystone:Used to provide authentication and authentication functions, Daisy dashboard interface log in with the user of keystone.

4. Apache service(httpd)

The dashboard of Daisy integration by Apache service , before login dashboard , you can first check the systemctl status httpd, dashboard page login address is http://IP. Here the IP is the IP address of the server Daisy blade installation.

5. mariadb

Before the deployment of the cluster, all the settings of the cluster (cluster) parameters are stored in the MariaDB database.

Configuration file, log file and version to be installed path Daisy all configuration file path: /etc/daisy/ Daisy log path: /var/log/daisy/ version to be installed path: /var/lib/daisy/tecs PXE deployment configuration file path: /home/daisy_install install

About support scenarios 1) The application scenario of Daisy currently only supports HA+LB +Compute, HA and LB can be deployed (deployed on the same piece of blade), also can separate deployment.

2) The daisy Version deployment ha, only support local mount database and glance , (DRDB) mode, support glance using magnetic array sharing mode.

About the deployment of the application of Daisy

support deployment of three ways:

1) CGSL-VPLAT (operating system): only the deployment of CGSL-VPLAT (not assigned roles)

2) OPENSTACK: only the deployment of Openstack (need to be found through the SSH host this step)

3) CGSL-VPLAT (operating system)+TECS: deployment of CGSL-VPLAT +TECS . Special note: if you want to deploy first and third ways , the blade server to be deployed must support IPMI hardware environment. Because only supports ironic hardware environment, can realize the automatic discovery of blade.

Daisy deployment of HA+LB in a networking scene

Daisy 01.png

User guide

Daisy install guide

1) Download Daisy bin package, ie:DAISY_V01.01.10_I680.bin

2) Add executable permissions:chmod +x DAISY_V01.01.10_I680.bin

3) Install:

Execute ./DAISY_V01.01.10_I680.bin, And select 5 exit

then you will find daisy_install folder in the path /home , enter the folder, open the daisy.conf configuration file to configure the PXE server configuration. Configuration is as follows:

  [root@host125 daisy_install(daisy_admin)]$ vi daisy.conf 

[DEFAULT] daisy_management_ip= [BACKEND]

  1. Default backend type for Daisy

default_backend_types=tecs [PXE] build_pxe=yes eth_name=bond0.18





[root@host125 file(daisy_admin)]$ ./DAISY_V01.01.10_I680.bin install Verifying archive integrity... All good. Uncompressing tecs........................................................................................................................................................................................

   ZTE DAISY Installation Wizard

creating yum repo, please wait for several seconds... Loaded plugins: fastestmirror, product-id, subscription-manager …… build pxe server Daisy Install Successfull... ------------------When you see this sentence, indicates that Daisy has been installed to complete

Check if server PXE is set up successfully: 1) Ifconfig to see if there is a bond0.18:100 network port, IP for the IP sever, such as 2) systemctl status dhcpd View service is active or not。

Daisy deployment guide

Dashboard login
Daisy dashboard is accomplished through the integration of through Apache service, you can check the httpd service status before login . Enter http://ip/dashboard in the browser to login Daisy dashboard, the user name and password are admin/keystone by default. Note: IP is the address of the daisy server.

Version upload
Daisy dashboard provides version upload feature. In the Daisy dashboard page, version --- browse --- select the local file --- upload, tips to upload files successfully.

Host list query and operation
You can query all host status through the host page, and the hosts page also provide the "join the cluster" and "out of clusters" function, add and remove the cluster operation can be easily.

Create cluster

Cluster is the basic unit of Daisy Automated Deployment Management, and the host should be added to the cluster before the host is deployed automatically. After landing dashboard, click create cluster.

Role allocation and distribution
The host role of Daisy includes the following four types: CONTROLLER_LB、 CONTROLLER_HA、 COMPUTER 、 DOCTOR(No support yet) A host can carry a role, but also can carry multiple roles. the configuration of roles, will ultimately affect the deployment of the host which TECS component services installed.

Daisy has been defined the correspondence between Role and TECS components by default. User does not need to care about.

Network plane configuration
When you create a cluster, you create six network planes in the same time.

Host discovery
After the cluster created, the blade (host) to be installed is required to be added to the cluster, depending on the installation method. There are two types of host discovery: the way the OS has not been installed and the way it has been installed in the OS.


After join the cluster, set the network connection, Allocation roles, you can begin the deployment. In the host configuration page, click the deployment to start the deployment. When OS installation progress and TECS installation progress are both 100%,the installation is success.

Developer Guide


How to add a new component

Installing a new component of OPENSTACK with Daisy

1,Process of Installing a component of OPENSTACK with Daisy Daisy generates the related configuration items based on the role type. When the backend to be deployed is OPENSTACK, there are CONTROLLER_HA, CONTROLLER_LB, and COMPUTER roles available, and CONTROLLER role will be added soon. If you want to install a new component of OPENSTACK with Daisy, you need to determine which services are included in the component, as well as the types of services. Daisy divides the services into different roles according to the type of service, and then generates the related component configuration items.

2,Then, add configuration items of this component to the template file tecs.conf, \daisy\backend\tecs\tecs.conf. CONFIG_XXX_INSTALL= CONFIG_XXX_HOST=

3,Edit daisy code for installing a component of OPENSTACK You can edit your new add tecs.conf with config.py in directory \daisy\code\daisy\daisy\api\backends\tecs according the services belong to. For example, you can use command services[XXX].append(IP) to edit CONFIG_XXX_HOST, and use command self.components.append(CONFIG_XXX_INSTALL) to edit CONFIG_XXX_INSTALL.

4,After modifying the code, compile the code and generate the Daisy artifacts. OPENSTACK that deployed by this artifacts should includes the newly added component.

5,Attention, if Daisy supports the installation of the component, but OPENSTACK does not contain the component, can not be properly deployed.

How to contribute

Join the Daisycloud team

Read the Developer's Guide and learn how to setup the accounts and git. Clone the repositories: git clone git clone https://github.com/openstack/daisycloud-core.git Please note that OpenStack Infra uses strict checks on your git commit messages. The most important rules are:

  • Keep your commit title short (<80 symbols). It must not end with dot.
  • Body of commit message should be separated from title by one empty line
  • If patch closes bug, then it must have in a body "Closes-Bug: #12345", where 12345 is your LP bug number
  • If patch relates to bug, but doesn't completely solve an issue, then you must use "Related-Bug: #12345"

See the [commit messages] wiki page for more details.

How to get help

Subscribe to mailing lists

   OpenStack developers mailing list. If you are hacking on Daisy, or have technical question about Daisy internals, you are very welcome in this ML with subject containing "[Daisyl]".
   OpenStack users mailing list.Daisy traffic is there with subject containing "[Daisy]". You are welcome to ask questions related to Daisy usage, including errors, etc.
   OpenStack announcements mailing list. Announcements about the OpenStack project like product release information, security advisories, important discussions. This is a low-traffic, read-only list.
   There are even more mailing lists out there, visit MailingLists to see the other OpenStack related lists.



report a bug

  • Go to https://launchpad.net/daisycloud-core
  • Select “Report a bug” on the right
  • Fill in “Summary” field for a bug.
  • Enter “Further information”.
  • Select visibility for the bug under “This bug contains information that is” field. Either leave it as “Public” (default) or set it to “Private” per the above guidance
  • Add attachments under “Extra Options” section
  • After everything is entered, select the “Submit bug report” button

fix a bug The most simple and easy way to contribute code into Daisy is to start with bug fixes.

Verify bugs

This is very easy to get started, but help here is actually very valuable. Especially when it comes to bugfixes which are relevant to only certain types of hardware. When bugfix is merged, bug is automatically moves to "Fix Committed" status. In Daisy, we set "Fix Released" status for a bug only when it was verified by someone else than a developer. You can simple check out all fix committed bugs and start verifying them. It is required to be in daisycloud-bugs LP group to be able to change bug status. However you can leave a comment in bug report, and it will be enough for bug supervisors to change bug status. By your request, you can be included into fuel-bugs team to manage bugs yourself.


Propose enhancements

  • Select "Register a Blueprint". Typically, you’ll find this link on the right side of the launchpad page.
  • Enter a Summary of the blueprint.
  • Propose your blueprint by selecting the milestone in which you plan to complete the blueprint.
  • You won’t need to enter any other fields, so now just choose Register Blueprint.
  • Upload a design specification in the "specs/<release>" folder in fuel-specs
  • In order to get your spec approved, it usually requires to get +1 from the following folks:
       All mandatory design reviewers (it's usually people who familiar with the area of the proposed enhancement)
       Topic expert if any (e.g your enhancement somehow affects Fuel Web UI then you need to get +1 from the Fuel Web UI team)
       For cross-component enhancements, it also requires to have +1 from core of affected components.

  • Once your design specification has been approved and merged into fuel-specs git repo:
       Update your blueprint's specification URL to point to the design specification in fuel-specs git
       Note, this should link to git (as in the template link above), not to the gerrit change

When done, drop an email about the new blueprint to the mailing list to attract attention of Fuel developers, who are likely to provide early feedback and request additional information.

Please read OpenStack Blueprints page for detailed definition of blueprints and their lifecycle.

Example of Daisy CI Environmen

The ci environmen of daisycloud-core was based on Third Party Testing.

There are two blades in daisycloud-core's ci environmen. One works as ci master. The other is working as slaves, which was installed openstack environmen.


  • Rack & Shelf: E9000
  • Blade's CPU: Intel(R) Xeon(R) CPU E5-2620 0 @ 2.00GHz, 24 cores.
  • Blade's Mem: 64 G


Node OS IP Adderss
master Ubuntu 14.00 ----
Slave CentOs 7.0 + OpenStack(All in one) ----

CI Jobs


This job runs flake8.


This job runs 'building', 'installing' and 'tempest testing'.

Log Server

The log server was deployed in master node. When ci jobs were finished, the jenkins would copy the logs to '/srv/static/logs/'.

The log would be published by apache which is running on master node.

About SSH Channel

It needs to use ssh channel to connect review.openstack.org:29418.

Create a channel to review.openstack.org:29418.

       ssh -C -fNg  -L 29418:review.openstack.org:29418 uuu@xx.xx.xx.xx

Check the channel.

       tailf /var/log/zuul/zuul.log

Tempest Test Command

Tempest test code's path: "./test/tempest". Tempest command:

       nosetests -v -s -w ./tempest/api/daisy/v1/ --exe --with-xunit --xunit-file=daisy.xml 

"daisy.xml" is the summary of ci result.