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 <fzhad...@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.ju...@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.ju...@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
