Hi Michal and David,
Thanks for your clarification for this.
I have tested KVM scenario with VLAN in our LAB and it works fine. Nearly all
the **health check** items are passed excepted the bottom severals. If you can
remove explicit definition of net_segment_type from scenario file, I can
specify it in lab files.
Absolutely, I don't want to introduce any new scenario files.
I have deployed the POD with all the nodes with Ceph except the MongoDB node.
Ceph work find in the POD, please refer to the part of my test logs:
I allocate 2 VM and 2 cinder volume. Each volume is attached to one VM. I fdisk
and write some data in it.
You also can find that the control node uses the normal kernel and the compute
node uses the KVM kernel.
root@node-4:~# cinder create --name example 50
+--------------------------------+--------------------------------------+
| Property | Value |
+--------------------------------+--------------------------------------+
| attachments | [] |
| availability_zone | nova |
| bootable | false |
| consistencygroup_id | None |
| created_at | 2016-08-09T13:06:54.000000 |
| description | None |
| encrypted | False |
| id | 9353d164-4b65-4029-bba6-22a29eb7470e |
| metadata | {} |
| migration_status | None |
| multiattach | False |
| name | example |
| os-vol-host-attr:host | rbd:volumes@RBD-backend#RBD-backend |
| os-vol-mig-status-attr:migstat | None |
| os-vol-mig-status-attr:name_id | None |
| os-vol-tenant-attr:tenant_id | 2544b47d38c548908184a351350f05cd |
| replication_status | disabled |
| size | 50 |
| snapshot_id | None |
| source_volid | None |
| status | creating |
| updated_at | 2016-08-09T13:06:54.000000 |
| user_id | e272861491eb45a9a7658f162db937a2 |
| volume_type | None |
+--------------------------------+--------------------------------------+
root@node-4:~# nova list
+--------------------------------------+-----------+--------+------------+-------------+------------------------------------------------+
| ID | Name | Status | Task State |
Power State | Networks |
+--------------------------------------+-----------+--------+------------+-------------+------------------------------------------------+
| cf978b12-50ef-48fe-a7b6-5af56b904447 | testkvm-1 | ACTIVE | - |
Running | admin_internal_net=192.168.111.5, 172.10.0.132 |
| cef2fb34-53fa-48ec-973e-e4027cc90c96 | testkvm-2 | ACTIVE | - |
Running | admin_internal_net=192.168.111.4, 172.10.0.131 |
+--------------------------------------+-----------+--------+------------+-------------+------------------------------------------------+
$ sudo chown cirros:cirros -R /mnt
$ touch /mnt/test.txt
$ echo "just a test" | tee -a /mnt/test.txt
just a test
$ cat /mnt/test.txt
just a test
$ df -h
Filesystem Size Used Available Use% Mounted on
/dev 240.0M 0 240.0M 0% /dev
/dev/vda1 986.7M 32.9M 912.5M 3% /
tmpfs 244.9M 0 244.9M 0% /dev/shm
tmpfs 244.9M 128.0K 244.8M 0% /run
/dev/vdc1 49.1G 51.8M 46.5G 0% /mnt
$ exitConnection to 172.10.0.132 closed.
root@node-4:~# cinder list
+--------------------------------------+-----------+----------+------+-------------+----------+--------------------------------------+
| ID | Status | Name | Size | Volume
Type | Bootable | Attached to |
+--------------------------------------+-----------+----------+------+-------------+----------+--------------------------------------+
| 9353d164-4b65-4029-bba6-22a29eb7470e | in-use | example | 50 | -
| false | cf978b12-50ef-48fe-a7b6-5af56b904447 |
| aa27f861-89d5-4f9a-9604-0b6eb2aa3646 | available | example2 | 50 | -
| false | |
+--------------------------------------+-----------+----------+------+-------------+----------+--------------------------------------+
root@node-4:~# ceph status
cluster d4da1797-0cc7-4cb3-8239-3058274d7055
health HEALTH_WARN
too many PGs per OSD (432 ＞ max 300)
monmap e3: 3 mons at
{node-3=192.168.12.1:6789/0,node-4=192.168.12.4:6789/0,node-6=192.168.12.2:6789/0}
election epoch 8, quorum 0,1,2 node-3,node-6,node-4
osdmap e59: 4 osds: 4 up, 4 in
pgmap v4963: 576 pgs, 5 pools, 937 MB data, 445 objects
10901 MB used, 1103 GB / 1114 GB avail
576 active+clean
client io 8266 kB/s wr, 5 op/s
root@node-4:~# uname -a
Linux node-4.zte.com.cn 3.13.0-92-generic #139-Ubuntu SMP Tue Jun 28 20:42:26
UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
root@node-4:~# ssh node-2
Warning: Permanently added 'node-2,192.168.11.3' (ECDSA) to the list of known
hosts.
Welcome to Ubuntu 14.04.4 LTS (GNU/Linux 4.4.6-rt14nfv x86_64)
* Documentation: https://help.ubuntu.com/
Last login: Fri Aug 5 06:33:48 2016 from 10.20.0.2
root@node-2:~# uname -a
Linux node-2.zte.com.cn 4.4.6-rt14nfv #1 SMP PREEMPT RT Thu Jul 21 11:41:29 UTC
2016 x86_64 x86_64 x86_64 GNU/Linux
BR,
Julien
NFV Architect
Controller System Design Dept./Wireless Product R＆D Institute/Wireless Product
Operation
D206(D2028), R&D Building, ZTE Plaza, #889, Bibo RD,
Pudong District, Shang Hai, P.R.China, 201203
T: +86 21 68897791 M: +86 21 15317680806
E: zhang.ju...@zte.com.cn
www.zte.com.cn
Original Mail
From: MichalSkalski
To: ZhangJun10013968
CC: Fedor Zhadaev ＜fzhad...@mirantis.com＞MichalSkalski,
yunhong.ji...@linux.intel.com, opnfv-tech-discuss@lists.opnfv.org
＜opnfv-tech-discuss@lists.opnfv.org＞Chou, David J ＜david.j.c...@intel.com＞
Subject: Re: [opnfv-tech-discuss] [fuel] How to override parameters defined in
scenario files
Date: 2016/08/09 19:55
Hi Julien,
I agree with what Fedor wrote. I would like to avoid changing scenario workflow
before C-release since proposed change will impact more than one scenario.
Regarding this specific scenario can you confirm with David (in Cc) if this
scenario is suppose to work with vlan segmentation? If there is no obstacles I
would remove explicit definition of net_segment_type from scenario file,
so you would be able to override this in pod configuration but bear in mind
that this also require different transformation.
Regarding number of ceph-osd nodes it is reduced because ceph does not work
with kernel provided by the kvm plugin which is used on compute nodes.
We will try address pod specific requirements, actually there are already
changes like this one proposed by armband team
https://gerrit.opnfv.org/gerrit/#/c/16863/, there is also ongoing work with
template mechanism.
Regards,
Michal
＞ On 09 Aug 2016, at 13:12, Fedor Zhadaev ＜fzhadaev©mirantis.com＞ wrote:
＞
＞ Hi, Julien
＞
＞ As you're said scenario file has the highest priority so you cannot override
it. The changes that you've mentioned totally change scenario logic, so
actually you've described another scenario.
＞ There are two options for your situation - modify existing scenario file to
meet your needs or create new one.
＞
＞ Michal, please correct me if I wrong.
＞
＞ On Tue, Aug 9, 2016 at 12:55 PM 张军10013968 ＜zhang.jun3g©zte.com.cn＞ wrote:
＞ Hi all,
＞
＞
＞
＞ Refer to code in fule/deploy-config.py, parameter defined in scenario file
has the highest priority.
＞
＞ # Generate final dea.yaml by merging following config files/fragments in
revers priority order:
＞
＞ # "dea-base", "dea-pod-override", "deplyment-scenario/module-config-override"
＞
＞ # and "deployment-scenario/dea-override"
＞
＞
＞
＞ Such parameters as: net_segment_type, role, which are related with each
Pharos Lab.
＞
＞ For example, in file ha_nfv-kvm_heat_ceilometer_scenario.yaml:
＞
＞ • it uses tun as net_segment_type, and we expect to use vlan in our lab
＞
＞ • it only has one node for ceph-osd, and we expected to use 4 nodes
except mongo+controller
＞
＞ • for contoller node, there are 3 different types: mongo+controller,
ceph+controller, and controller, and we expect only 2 types: mongo+contoller
and ceph+controller
＞
＞ The first one is the main issue, and the latter 2 can be overcomed.
＞
＞
＞
＞ some choices:
＞
＞ • change the sequece of load the yaml files and set the parameters
defined in dea-pod-override loaded lastly.
＞
＞ • keep current sequence, and reload nodes information in dea-pod-override
if it exists at the last and merge these parameters.
＞
＞
＞
＞ BR,
＞ Julien
＞
＞
＞
＞ NFV Architect
＞ Controller System Design Dept./Wireless Product R＆D Institute/Wireless
Product Operation
＞
＞
＞
＞ D206(D2028), R&D Building, ZTE Plaza, #889, Bibo RD,
＞ Pudong District, Shang Hai, P.R.China, 201203
＞ T: +86 21 68897791 M: +86 21 15317680806
＞ E: zhang.jun3g©zte.com.cn
＞ www.zte.com.cn
＞
＞
＞
＞
＞
＞ _______________________________________________
＞ opnfv-tech-discuss mailing list
＞ opnfv-tech-discuss©lists.opnfv.org
＞ https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss
＞ --
＞ Kind Regards,
＞ Fedor Zhadaev
＞
＞ skype: zhadaevfm
＞ IRC: fzhadaev
＞ _______________________________________________
＞ opnfv-tech-discuss mailing list
＞ opnfv-tech-discuss©lists.opnfv.org
＞ https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss_______________________________________________
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss
