Hi Daniel,
Great fix.
Sorry for the hacky solution, I was not aware of the existing way the properties were passed.
Cheers,
Nayan
--------- Original Message ---------
Sender : ROSE, DANIEL V <dr6...@att.com>
Date : 2017-07-01 05:29 (GMT+9)
Title : RE: RE: Re: [onap-discuss] Robot vm script automation
To : null<frank.obr...@amdocs.com>, Nayan Deshmukh<n.deshm...@samsung.com>, null<jf9...@att.com>, null<josef.reisin...@de.ibm.com>, null<plata...@research.att.com>
CC : null<onap-discuss@lists.onap.org>, null<ajay.priyadar...@ril.com>
Sounds good, thank you for following up on this (same to Nayan also)
Daniel Rose ECOMP / ONAP com.att.ecomp 732-420-7308 |
|
Sounds good, I was only going to patch our Rackspace so we can bring up more than one vFW. Released branch repos should be static.
/michael
|
I have submitted a patch https://gerrit.onap.org/r/#/c/5625/ and https://gerrit.onap.org/r/#/c/5627/ which implements what you are requesting in the existing way. I will leave it to Steve / Jerry/ the rest of team to review and test it as I am going on vacation for 3 weeks after today.
Thanks,
Daniel Rose ECOMP / ONAP com.att.ecomp 732-420-7308 |
|
That is not a very robust fix, that property filename can change and is different than the mechanism we use to pass everything else into robot from the heat template. Also because that property file is checked into git, you would be confusing people who look at git and see one property file structure and then at run time see a different one. CLOUD_ENV != "rackspace" ] is also not very generic (why wouldn’t it apply to Rackspace?). I will be in #onap-int if you want to discuss but now that I get what you want to do I think we can add it to our regular mechanism for passing in values.
I would be careful about back porting to 1.0 also since it’s a change to existing behavior (which even if better overall that should be avoided in a release branch).
Thanks,
Daniel Rose ECOMP / ONAP com.att.ecomp 732-420-7308 |
|
Nayan,
Nice fix – thank you. I’ll pull and backport it to our 1.0.0-RELEASE demo
https://gerrit.onap.org/r/gitweb?p=demo.git;a=commitdiff;h=408e5ba68e74c9c8fe642f6b06a5581a6761a344
https://jira.onap.org/browse/UCA-17
/michael
|
done and merged :)
--------- Original Message ---------
Sender : ROSE, DANIEL V <dr6...@att.com>
Date : 2017-06-30 00:44 (GMT+9)
Title : RE: Re: [onap-discuss] Robot vm script automation
To : Nayan Deshmukh<n.deshm...@samsung.com>, null<jf9...@att.com>, null<frank.obr...@amdocs.com>, null<josef.reisin...@de.ibm.com>, null<plata...@research.att.com>
CC : null<onap-discuss@lists.onap.org>, null<ajay.priyadar...@ril.com>
Feel free to submit, we will give feedback but anything that enhances is genrally welcome
Daniel Rose ECOMP / ONAP com.att.ecomp 732-420-7308 |
|
Fixing integration_preload_parameter.py for multiple VNFs won't be straight forward thing, but in the mean time we can at least fix the integration_robot_properties.py to not use harcoded values. When I deployed ONAP with a different network cidr for private net, the robot vm was the only place where I had to fix value, other than there were no hardcoded values in the stack. I'll try to send in a patch to avoid hardcoded values as is done in dns-server vm later today.
Regards,
Nayan
--------- Original Message ---------
Sender : FLOOD, JERRY <jf9...@att.com>
Date : 2017-06-28 07:03 (GMT+9)
Title : Re: [onap-discuss] Robot vm script automation
To : null<dr6...@att.com>, null<frank.obr...@amdocs.com>, null<josef.reisin...@de.ibm.com>, null<plata...@research.att.com>
CC : null<onap-discuss@lists.onap.org>, null<ajay.priyadar...@ril.com>
Ajay
Michael
The preload values for the demo VFW originate from the following section of the integration_preload_parameters.py.
# heat template parameter values for heat template instances created for hands on demo test case
"Demo" : {
"vfw_preload.template": {
"unprotected_private_net_id" : "demofwl_unprotected",
"unprotected_private_net_cidr" : "192.168.110.0/24",
"protected_private_net_id" : "demofwl_protected",
"protected_private_net_cidr" : "192.168.120.0/24",
"vfw_private_ip_0" : "192.168.110.100",
"vfw_private_ip_1" : "192.168.120.100",
"vfw_private_ip_2" : "10.1.${ecompnet}.11",
"vpg_private_ip_0" : "192.168.110.200",
"vpg_private_ip_1" : "10.1.${ecompnet}.12",
"vsn_private_ip_0" : "192.168.120.250",
"vsn_private_ip_1" : "10.1.${ecompnet}.13",
'vfw_name_0':'demofwl01fwl',
'vpg_name_0':'demofwl01pgn',
'vsn_name_0':'demofwl01snk',
The values here were not intended to support more than 1 simultaneous instance of the demo vFW. Changing network ids and host names (in red) should enable simultaneous instantiations.
Note that the automated ETE configurations use a dynamically generated ${hostid} to uniquely identify network ids and host names (in red) to enable simultaneous instantiations. This pattern may be used for the “Demo” section as well
# heat template parameter values for heat template instances created during Vnf-Orchestration test cases
"Vnf-Orchestration" : {
"vfw_preload.template": {
"unprotected_private_net_id" : "vofwl01_unprotected${hostid}",
"unprotected_private_net_cidr" : "192.168.10.0/24",
"protected_private_net_id" : "vofwl01_protected${hostid}",
"protected_private_net_cidr" : "192.168.20.0/24",
"vfw_private_ip_0" : "192.168.10.100",
"vfw_private_ip_1" : "192.168.20.100",
"vfw_private_ip_2" : "10.1.${ecompnet}.1",
"vpg_private_ip_0" : "192.168.10.200",
"vpg_private_ip_1" : "10.1.${ecompnet}.2",
"vsn_private_ip_0" : "192.168.20.250",
"vsn_private_ip_1" : "10.1.${ecompnet}.3",
'vfw_name_0':'vofwl01fwl${hostid}',
'vpg_name_0':'vofwl01pgn${hostid}',
'vsn_name_0':'vofwl01snk${hostid}',
},
A note about the ${ecompnet} parameter. This is GLOBAL_BUILD_NUMBER%255 (-v GLOBAL_BUILD_NUMBER:1928 from the example below). These IPs are part of the ONAP OAM network defined by the ONAP heat template (subnet 10.0.0.0/8). Use of ${ecompnet} minimizes the potential for conflict on these network resources.
For complete control of preload values, you can modify the network ids, host names and ${ecompnet} in the “Demo” section for each instantiation or you can update the “Demo” section to follow the “Vnf-Orchestration” pattern using ${hostid} and ${ecompnet} to enable simultaneous instantiations with generated host and network ids.
Later
Jerry
|
Good find, can you look at this jerry or marco?
Daniel Rose ECOMP / ONAP com.att.ecomp 732-420-7308 |
|
Ajay,
Yes, there is an open jira on these hardcoded values (changes to your env have no effect over the sample values). Until this is fixed you can only have one instance of the vFW or vLB up.
https://jira.onap.org/browse/UCA-17
/michael
|
You can certainly change anything, just make sure they all sync up. Look at the heat templates for each demo vnf, and as long as the new parameters work it is fine. Since we use a private network for everything there shouldn’t be an ip conflict.
Thanks,
Daniel Rose
ECOMP / ONAP
com.att.ecomp
732-420-7308
From: Josef Reisinger [mailto:josef.reisin...@de.ibm.com]
Sent: Monday, June 26, 2017 10:27 AM
To: ROSE, DANIEL V <dr6...@att.com>
Cc: ajay.priyadar...@ril.com;
onap-discuss@lists.onap.org
Subject: Re: [onap-discuss] Robot vm script automation
Daniel,
if "preload parameters are hard coded", does it mean I should not change them? On one of my environments, I have a conflict with 10.0.0.0/8 network space and configured a 10.0.0.0/16 net, which
created some conflict when trying to spin up vFW. To overcome the issues, I move some IP addresses to 10.0.150.X and reran demo.sh preload <my-module>. Even the VMs start (more or less), does this break the demo?
Mit freundlichen Grüßen / Kind regards
Josef Reisinger
From: "ROSE, DANIEL V" <dr6...@att.com>
To: "ajay.priyadar...@ril.com"
<ajay.priyadar...@ril.com>, "onap-discuss@lists.onap.org"
<onap-discuss@lists.onap.org>
Date: 26.06.2017 16:18
Subject: Re: [onap-discuss] Robot vm script automation
Sent by: onap-discuss-boun...@lists.onap.org
The properties in robot come from a few places. The first way is the heat template (that’s dynamic properties in your terms) and they are saved as vm_properties.py. You can certainly make a script
to generate these in a different way if you wanted. The preload parameters are hard coded because they are defined by the demo use case. The robot properties defines the topology of the onap installation and openstack install etc. The microservice bus will
render most of these properties useless and they can be removed at that time.
Thanks,
Daniel Rose
ECOMP / ONAP
com.att.ecomp
732-420-7308
From: onap-discuss-boun...@lists.onap.org
[mailto:onap-discuss-boun...@lists.onap.org]
On Behalf Of ajay.priyadar...@ril.com
Sent: Monday, June 26, 2017 5:29 AM
To: onap-discuss@lists.onap.org
Subject: [onap-discuss] Robot vm script automation
Hi,
The below configuration files used for demo script uses hardcoded values.
Example : /var/opt/OpenECOMP_ETE/runTags.sh -V /share/config/vm_properties.py -V /share/config/integration_robot_properties.py -V /share/config/integration_preload_parameters.py -v GLOBAL_BUILD_NUMBER:1928 -d
/share/logs/ETE_1928 -i InitDemo --display 88
The above command uses three config files.
1. integration_robot_properties.py
2. integration_preload_parameters.py
3. vm_properties.py
Only 3rd one(vm_properties.py) get populated by environment value, Rest both uses preconfigured values. These two files should also maintain dynamic values (eg. Private IP addresses).
Regards,
Ajay
"Confidentiality Warning: This message and any attachments are intended only for the use of the intended recipient(s), are confidential and may be privileged. If you are not the intended recipient, you are hereby notified that any review, re-transmission,
conversion to hard copy, copying, circulation or other use of this message and any attachments is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return email and delete this message and any attachments from
your system.
Virus Warning: Although the company has taken reasonable precautions to ensure no viruses are present in this email. The company cannot accept responsibility for any loss or damage arising from the use of this email or attachment."
onap-discuss@lists.onap.org
This message and the information contained herein is proprietary and confidential and subject to the Amdocs policy statement,
|
_______________________________________________
onap-discuss mailing list
https://lists.onap.org/mailman/listinfo/onap-discuss
This message and the information contained herein is proprietary and confidential and subject to the Amdocs policy statement,
|
This message and the information contained herein is proprietary and confidential and subject to the Amdocs policy statement,
|
|
|
rcptInfo.txt
Description: Binary data
_______________________________________________ onap-discuss mailing list onap-discuss@lists.onap.org https://lists.onap.org/mailman/listinfo/onap-discuss
