diff options
Diffstat (limited to 'docs/release')
| -rw-r--r-- | docs/release/configguide/index.rst | 2 | ||||
| -rw-r--r-- | docs/release/configguide/installerconfig.rst | 6 | ||||
| -rw-r--r-- | docs/release/configguide/kollaconfig.rst | 56 | ||||
| -rw-r--r-- | docs/release/installation/bmdeploy.rst | 35 | ||||
| -rw-r--r-- | docs/release/installation/index.rst | 3 | ||||
| -rw-r--r-- | docs/release/installation/recovery.rst | 80 | ||||
| -rw-r--r-- | docs/release/installation/upgrade.rst | 92 | ||||
| -rw-r--r-- | docs/release/installation/vmdeploy.rst | 41 |
8 files changed, 294 insertions, 21 deletions
diff --git a/docs/release/configguide/index.rst b/docs/release/configguide/index.rst index 7b531f45..a4829422 100644 --- a/docs/release/configguide/index.rst +++ b/docs/release/configguide/index.rst @@ -13,4 +13,4 @@ Release notes for Daisy4nfv :maxdepth: 2 installerconfig.rst - + kollaconfig.rst diff --git a/docs/release/configguide/installerconfig.rst b/docs/release/configguide/installerconfig.rst index f6a01b71..a8ef8144 100644 --- a/docs/release/configguide/installerconfig.rst +++ b/docs/release/configguide/installerconfig.rst @@ -10,7 +10,7 @@ Abstract ======== -This document compiles the release notes for the D 2.0 release of +This document compiles the release notes for the E 1.0 release of OPNFV when using Daisy as a deployment tool. @@ -28,9 +28,7 @@ daisy.conf file.Then put the right configured daisy.conf file in the 3. "os_install_type" field just support "pxe" for now. -4. Daisy now use pxe server to install the os, so "build_pxe" must set to "yes". - If the value in daisy.conf in your env of /home/daisy_install/ dir is "no", - you must change this field to "yes" manually before installing Daisy. +4. Daisy now use pxe server to install the os, the "build_pxe" item must set to "no". 5. "eth_name" field is the pxe server interface, and this field is required when the "build_pxe" field set to "yes".This should be set to the interface diff --git a/docs/release/configguide/kollaconfig.rst b/docs/release/configguide/kollaconfig.rst new file mode 100644 index 00000000..6da50ed3 --- /dev/null +++ b/docs/release/configguide/kollaconfig.rst @@ -0,0 +1,56 @@ + +.. This document is protected/licensed under the following conditions +.. (c) Sun Jing (ZTE corporation) +.. Licensed under a Creative Commons Attribution 4.0 International License. +.. You should have received a copy of the license along with this work. +.. If not, see <http://creativecommons.org/licenses/by/4.0/>. + + +OpenStack Configuration Guide +============================= + +Before The First Deployment +--------------------------- + +When executing deploy.sh, before doing real deployment, Daisy utilizes +Kolla's service configuration functionality [1] to specify the following +changes to the default OpenStack configuration which comes from Kolla as +default. + +a) If is it is a VM deployment, set virt_type=qemu amd cpu_mode=none for +nova-compute.conf. + +b) In nova-api.conf set default_floating_pool to the name of the external +network which will be created by Daisy after deployment for nova-api.conf. + +c) In heat-api.conf and heat-engine.conf, set deferred_auth_method to +trusts and unset trusts_delegated_roles. + +Those above changes are requirements of OPNFV or environment's +constraints. So it is not recommended to change them. But if the user +wants to add more specific configurations to OpenStack services before +doing real deployment, we suggest to do it in the same way as deploy.sh +do. Currently, this means hacking into deploy/prepare.sh or +deploy/prepare/execute.py then add config file as described in [1]. + +Notes: +Suggest to pass the first deployment first, then reconfigure and deploy +again. + + +After The First Deployment +-------------------------- + +After the first time of deployment of OpenStack, its configurations can +also be changed and applied by using Kolla's service configuration +functionality [1]. But user has to issue Kolla's command to do it in this +release: + + +.. code-block:: console + cd /home/kolla_install/kolla-ansible/ + ./tools/kolla-ansible reconfigure -i /home/kolla_install/kolla-ansible/ansible/inventory/multinode + + + +[1] https://docs.openstack.org/kolla-ansible/latest/advanced-configuration.html#openstack-service-configuration-in-kolla diff --git a/docs/release/installation/bmdeploy.rst b/docs/release/installation/bmdeploy.rst index 47a8e121..ddb30f22 100644 --- a/docs/release/installation/bmdeploy.rst +++ b/docs/release/installation/bmdeploy.rst @@ -130,13 +130,33 @@ Start Deployment (Bare Metal Deployment) (1) Git clone the latest daisy4nfv code from opnfv: "git clone https://gerrit.opnfv.org/gerrit/daisy" -(2) Download latest bin file(such as opnfv-2017-06-06_23-00-04.bin) of daisy from http://artifacts.opnfv.org/daisy.html and change the bin file name(such as opnfv-2017-06-06_23-00-04.bin) to opnfv.bin +(2) Download latest bin file(such as opnfv-2017-06-06_23-00-04.bin) of daisy from +http://artifacts.opnfv.org/daisy.html and change the bin file name(such as opnfv-2017-06-06_23-00-04.bin) +to opnfv.bin. Check the https://build.opnfv.org/ci/job/daisy-os-odl-nofeature-ha-baremetal-daily-master/, +and if the 'snaps_health_check' of functest result is 'PASS', +you can use this verify-passed bin to deploy the openstack in your own environment + +(3) Assumed cloned dir is $workdir, which laid out like below: +[root@daisyserver daisy]# ls +ci deploy docker INFO LICENSE requirements.txt templates tests tox.ini +code deploy.log docs known_hosts setup.py test-requirements.txt tools +Make sure the opnfv.bin file is in $workdir + +(4) Enter into the $workdir, which laid out like below: +[root@daisyserver daisy]# ls +ci code deploy docker docs INFO LICENSE requirements.txt setup.py templates test-requirements.txt tests tools tox.ini +Create folder of labs/zte/pod2/daisy/config in $workdir + +(5) Move the ./deploy/config/bm_environment/zte-baremetal1/deploy.yml and +./deploy/config/bm_environment/zte-baremetal1/network.yml +to labs/zte/pod2/daisy/config dir. -(3) Make sure the opnfv.bin file is in daisy4nfv code dir - -(4) Create folder of labs/zte/pod2/daisy/config in daisy4nfv code dir - -(5) Move the ./deploy/config/bm_environment/zte-baremetal1/deploy.yml and ./deploy/config/bm_environment/zte-baremetal1/network.yml to labs/zte/pod2/daisy/config dir. +Note: +If selinux is disabled on the host, please delete all xml files section of below lines in dir templates/physical_environment/vms/ + <seclabel type='dynamic' model='selinux' relabel='yes'> + <label>system_u:system_r:svirt_t:s0:c182,c195</label> + <imagelabel>system_u:object_r:svirt_image_t:s0:c182,c195</imagelabel> + </seclabel> (6) Config the bridge in jumperserver,make sure the daisy vm can connect to the targetnode,use the command below: brctl addbr br7 @@ -147,4 +167,5 @@ service network restart (7) Run the script deploy.sh in daisy/ci/deploy/ with command: sudo ./ci/deploy/deploy.sh -b ../daisy -l zte -p pod2 -s os-nosdn-nofeature-noha -(8) When deploy successfully,the floating ip of openstack is 10.20.7.11,the login account is "admin" and the password is "keystone" +(8) When deploy successfully,the floating ip of openstack is 10.20.7.11, +the login account is "admin" and the password is "keystone" diff --git a/docs/release/installation/index.rst b/docs/release/installation/index.rst index 8c5a3da7..20d1e3b7 100644 --- a/docs/release/installation/index.rst +++ b/docs/release/installation/index.rst @@ -15,4 +15,5 @@ OPNFV Daisy4nfv Installation Guide installation_guide.rst bmdeploy.rst vmdeploy.rst - + recovery.rst + upgrade.rst diff --git a/docs/release/installation/recovery.rst b/docs/release/installation/recovery.rst new file mode 100644 index 00000000..7a49e693 --- /dev/null +++ b/docs/release/installation/recovery.rst @@ -0,0 +1,80 @@ +.. This work is licensed under a Creative Commons Attribution 4.0 International Licence. +.. http://creativecommons.org/licenses/by/4.0 + +Deployment Error Recovery Guide +=============================== + +Deployment may fail due to different kinds of reasons, such as Daisy VM creation +error, target nodes failure during OS installation, or Kolla deploy command +error. Different errors can be grouped into several error levels. We define +Recovery Levels below to fulfill recover requirements in different error levels. + +1. Recovery Level 0 +------------------- + +This level restart whole deployment again. Mainly to retry to solve errors such +as Daisy VM creation failed. For example we use the following command to do +virtual deployment(in the jump host): + + +.. code-block:: console + + sudo ./ci/deploy/deploy.sh -b ./ -l zte -p virtual1 -s os-nosdn-nofeature-ha + + + +If command failed because of Daisy VM creation error, then redo above command +will restart whole deployment which includes rebuild the daisy VM image and +restart Daisy VM. + + +2. Recovery Level 1 +------------------- + +If Daisy VM was created successfully, but bugs was encountered in Daisy code +or software of target OS which prevent deployment from being done, in this case, +the user or the developer does not want to recreate the Daisy VM again during +next deployment process but just to modify some pieces of code in it. To achieve +this, he/she can redo deployment by deleting all clusters and hosts first(in the +Daisy VM): + + +.. code-block:: console + + source /root/daisyrc_admin + for i in `daisy cluster-list | awk -F "|" '{print $2}' | sed -n '4p' | tr -d " "`;do daisy cluster-delete $i;done + for i in `daisy host-list | awk -F "|" '{print $2}'| grep -o "[^ ]\+\( \+[^ ]\+\)*"|tail -n +2`;do daisy host-delete $i;done + + + +Then, adjust deployment command as below and run it again(in the jump host): + + +.. code-block:: console + + sudo ./ci/deploy/deploy.sh -S -b ./ -l zte -p virtual1 -s os-nosdn-nofeature-ha + + + +Pay attention to the "-S" argument above, it lets the deployment process to +skip re-creating Daisy VM and use the existing one. + + +3. Recovery Level 2 +------------------- + +If both Daisy VM and target node's OS are OK, but error ocurred when doing +OpenStack deployment, then there is even no need to re-install target OS for +the deployment retrying. In this level, all we need to do is just retry the +Daisy deployment command as follows(in the Daisy VM): + + +.. code-block:: console + + source /root/daisyrc_admin + daisy uninstall <cluster-id> + daisy install <cluster-id> + + + +This basically do kolla-ansible destroy and kolla-asnible deploy. diff --git a/docs/release/installation/upgrade.rst b/docs/release/installation/upgrade.rst new file mode 100644 index 00000000..23b53e21 --- /dev/null +++ b/docs/release/installation/upgrade.rst @@ -0,0 +1,92 @@ +.. This work is licensed under a Creative Commons Attribution 4.0 International Licence. +.. http://creativecommons.org/licenses/by/4.0 + +OpenStack Minor Version Update Guide +==================================== + +Thanks for the Kolla's kolla-ansible upgrade function, Daisy enable to +update OpenStack minor version as the follows: + +1. Get new version file only from Daisy team. +Since Daisy's Kolla images are build by meeting the OPNFV requirements +and have their own file packaging layout, Daisy requires user to +always use Kolla image file built by Daisy team. Currently, it can be +got from http://120.24.17.215/. + +2. Put new version file into /var/lib/daisy/versionfile/kolla/, for +example: +/var/lib/daisy/versionfile/kolla/kolla-image-ocata-170811155446.tgz + +3. Add version file to Daisy's version management database then get the +version ID. + + +.. code-block:: console + + [root@daisy ~]# source /root/daisyrc_admin + [root@daisy ~]# daisy version-add kolla-image-ocata-170811155446.tgz kolla + +-------------+--------------------------------------+ + | Property | Value | + +-------------+--------------------------------------+ + | checksum | None | + | created_at | 2017-08-28T06:45:25.000000 | + | description | None | + | id | 8be92587-34d7-43e8-9862-a5288c651079 | + | name | kolla-image-ocata-170811155446.tgz | + | owner | None | + | size | 0 | + | status | unused | + | target_id | None | + | type | kolla | + | updated_at | 2017-08-28T06:45:25.000000 | + | version | None | + +-------------+--------------------------------------+ + + + +4. Get cluster ID + + +.. code-block:: console + + [root@daisy ~]# daisy cluster-list + +--------------------------------------+-------------+... + | ID | Name |... + +--------------------------------------+-------------+... + | d4c1e0d3-c4b8-4745-aab0-0510e62f0ebb | clustertest |... + +--------------------------------------+-------------+... + + + +5. Issuing update command passing cluster ID and version ID + + + +.. code-block:: console + + [root@daisy ~]# daisy update d4c1e0d3-c4b8-4745-aab0-0510e62f0ebb --update-object kolla --version-id 8be92587-34d7-43e8-9862-a5288c651079 + +----------+--------------+ + | Property | Value | + +----------+--------------+ + | status | begin update | + +----------+--------------+ + + +6. Since step 5's command is non-blocking, the user need to run the +following command to get updating progress. + + + +.. code-block:: console + + [root@daisy ~]# daisy host-list --cluster-id d4c1e0d3-c4b8-4745-aab0-0510e62f0ebb + ...+---------------+-------------+-------------------------+ + ...| Role_progress | Role_status | Role_messages | + ...+---------------+-------------+-------------------------+ + ...| 0 | updating | prechecking envirnoment | + ...+---------------+-------------+-------------------------+ + + + +Notes. The above command returns many fields. User only have to take care +about the Role_xxx fields in this case. diff --git a/docs/release/installation/vmdeploy.rst b/docs/release/installation/vmdeploy.rst index 5da3949b..64d16a96 100644 --- a/docs/release/installation/vmdeploy.rst +++ b/docs/release/installation/vmdeploy.rst @@ -134,20 +134,45 @@ HeartBeat network is selected,and if it is configured in network.yml,the keepali Start Deployment (Virtual Deployment) ------------------------------------- -(1) Git clone the latest daisy4nfv code from opnfv: "git clone https://gerrit.opnfv.org/gerrit/daisy" +(1) Git clone the latest daisy4nfv code from opnfv: "git clone https://gerrit.opnfv.org/gerrit/daisy", +make sure the current branch is master -(2) Download latest bin file(such as opnfv-2017-06-06_23-00-04.bin) of daisy from http://artifacts.opnfv.org/daisy.html and change the bin file name(such as opnfv-2017-06-06_23-00-04.bin) to opnfv.bin +(2) Download latest bin file(such as opnfv-2017-06-06_23-00-04.bin) of daisy from +http://artifacts.opnfv.org/daisy.html and change the bin file name(such as opnfv-2017-06-06_23-00-04.bin) +to opnfv.bin. Check the https://build.opnfv.org/ci/job/daisy-os-odl-nofeature-ha-baremetal-daily-master/, +and if the 'snaps_health_check' of functest result is 'PASS', +you can use this verify-passed bin to deploy the openstack in your own environment -(3) Make sure the opnfv.bin file is in daisy4nfv code dir +(3) Assumed cloned dir is $workdir, which laid out like below: +[root@daisyserver daisy]# ls +ci code deploy docker docs INFO LICENSE requirements.txt setup.py templates test-requirements.txt tests tools tox.ini +Make sure the opnfv.bin file is in $workdir -(4) Create folder of labs/zte/virtual1/daisy/config in daisy4nfv code dir +(4) Enter into $workdir, Create folder of labs/zte/virtual1/daisy/config in $workdir -(5) Move the daisy/deploy/config/vm_environment/zte-virtual1/deploy.yml and daisy/deploy/config/vm_environment/zte-virtual1/network.yml to labs/zte/virtual1/daisy/config dir. +(5) Move the deploy/config/vm_environment/zte-virtual1/deploy.yml and +deploy/config/vm_environment/zte-virtual1/network.yml to +labs/zte/virtual1/daisy/config dir. Note: -zte-virtual1 config file is just for all-in-one deployment,if you want to deploy openstack with five node(1 lb node and 4 computer nodes),change the zte-virtual1 to zte-virtual2 +zte-virtual1 config file deploy openstack with five nodes(3 lb nodes and 2 computer nodes), +if you want to deploy an all-in-one openstack, change the zte-virtual1 to zte-virtual2 + +Note: +If selinux is disabled on the host, please delete all xml files section of below lines in dir templates/virtual_environment/vms/ + <seclabel type='dynamic' model='selinux' relabel='yes'> + <label>system_u:system_r:svirt_t:s0:c182,c195</label> + <imagelabel>system_u:object_r:svirt_image_t:s0:c182,c195</imagelabel> + </seclabel> (6) Run the script deploy.sh in daisy/ci/deploy/ with command: -sudo ./ci/deploy/deploy.sh -b ../daisy -l zte -p virtual1 -s os-nosdn-nofeature-noha +sudo ./ci/deploy/deploy.sh -b ./ -l zte -p virtual1 -s os-nosdn-nofeature-ha + +Note: +The value after -p parameter(virtual1) is get from labs/zte/virtual1/daisy/config/ +The value after -l parameter(zte) is get from labs/ +The value after -s "os-nosdn-nofeature-ha" used for deploy multinode openstack +The value after -s "os-nosdn-nofeature-noha" used for deploy all-in-one openstack -(7) When deploy successfully,the floating ip of openstack is 10.20.11.11,the login account is "admin" and the password is "keystone" +(7) When deploy successfully,the floating ip of openstack is 10.20.11.11, +the login account is "admin" and the password is "keystone" |