Daisy

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

2.Ironic 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 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] default_backend_types=tecs [PXE] build_pxe=yes eth_name=bond0.18
 * 1) Default backend type for Daisy

ip_address=192.168.1.5

net_mask=255.255.255.0

client_ip_begin=192.168.1.100

client_ip_end=192.168.1.200

[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 192.168.1.1 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.

Deploy

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.

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.

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 [|Git 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.

Bugs
report a bug fix a bug The most simple and easy way to contribute code into Daisy is to start with bug fixes.
 * 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

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.

Enhancements
Propose enhancements 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) QA       For cross-component enhancements, it also requires to have +1 from core of affected components.
 * 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/ " folder in fuel-specs
 * In order to get your spec approved, it usually requires to get +1 from the following folks:

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
 * Once your design specification has been approved and merged into fuel-specs git repo:

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.

Infrastructure

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

CI Jobs
openstack_daisy_flake8

This job runs flake8.

openstack_daisy_tempest

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.