Brian,
Yes, thanks for the info. I was aware that env data is overridden - but
from a design perspective I understood the intent that env should override
preload. However in view of some of the comments and thinking of it some more
- it may be that the env file is actually the template and the preload
overrides per instance (would make sense otherwise we would need to re-zip the
vFW heat/env combo for each instance).
So the current override behavior makes sense - especially for multiple
instances of the vFW.
Thank you
/michael
From: FREEMAN, BRIAN D [mailto:[email protected]]
Sent: Monday, July 24, 2017 08:27
To: FLOOD, JERRY <[email protected]>; ROSE, DANIEL V <[email protected]>; Michael
O'Brien <[email protected]>; Josef Reisinger
<[email protected]>; PLATANIA, MARCO <[email protected]>
Cc: [email protected]; [email protected]
Subject: RE: [onap-discuss] Robot vm script automation
Not sure if folks realize that sdn preload data over rides the .env file.
Openstack merges the .env and the parameters passed into the heat stack create
API so you can either dynamically create the .env or use the parameters from
the sdnc preload (or any other mechanism to create the dyanmic parameters) to
set instance specific data.
Brian
From:
[email protected]<mailto:[email protected]>
[mailto:[email protected]] On Behalf Of FLOOD, JERRY
Sent: Tuesday, June 27, 2017 6:03 PM
To: ROSE, DANIEL V <[email protected]<mailto:[email protected]>>; OBRIEN, FRANK
MICHAEL <[email protected]<mailto:[email protected]>>; Josef
Reisinger <[email protected]<mailto:[email protected]>>;
PLATANIA, MARCO <[email protected]<mailto:[email protected]>>
Cc: [email protected]<mailto:[email protected]>;
[email protected]<mailto:[email protected]>
Subject: Re: [onap-discuss] Robot vm script automation
***Security Advisory: This Message Originated Outside of AT&T ***
Reference http://cso.att.com/EmailSecurity/IDSP.html for more information.
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
From: ROSE, DANIEL V
Sent: Tuesday, June 27, 2017 4:24 PM
To: OBRIEN, FRANK MICHAEL; Josef Reisinger; FLOOD, JERRY; PLATANIA, MARCO
Cc: [email protected]<mailto:[email protected]>;
[email protected]<mailto:[email protected]>
Subject: RE: [onap-discuss] Robot vm script automation
Good find, can you look at this jerry or marco?
Daniel Rose
ECOMP / ONAP
com.att.ecomp
732-420-7308
From: OBRIEN, FRANK MICHAEL
Sent: Monday, June 26, 2017 11:18 PM
To: ROSE, DANIEL V <[email protected]<mailto:[email protected]>>; Josef Reisinger
<[email protected]<mailto:[email protected]>>
Cc: [email protected]<mailto:[email protected]>;
[email protected]<mailto:[email protected]>
Subject: RE: [onap-discuss] Robot vm script automation
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<https://urldefense.proofpoint.com/v2/url?u=https-3A__jira.onap.org_browse_UCA-2D17&d=DwMFAw&c=LFYZ-o9_HUMeMTSQicvjIg&r=2wwdGZ3YcpSivQ2Kio028A&m=FHIeaymRGS1UTjq4KQmpOBIxMMmk90sP9Xugj1JH52o&s=zGaXsbY9PTCxFhwtum44uSL61c7NE1fuudhfK6JzMCw&e=>
/michael
From:
[email protected]<mailto:[email protected]>
[mailto:[email protected]] On Behalf Of ROSE, DANIEL V
Sent: Monday, June 26, 2017 10:38
To: Josef Reisinger
<[email protected]<mailto:[email protected]>>
Cc: [email protected]<mailto:[email protected]>;
[email protected]<mailto:[email protected]>
Subject: Re: [onap-discuss] Robot vm script automation
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:[email protected]]
Sent: Monday, June 26, 2017 10:27 AM
To: ROSE, DANIEL V <[email protected]<mailto:[email protected]>>
Cc: [email protected]<mailto:[email protected]>;
[email protected]<mailto:[email protected]>
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" <[email protected]<mailto:[email protected]>>
To: "[email protected]<mailto:[email protected]>"
<[email protected]<mailto:[email protected]>>,
"[email protected]<mailto:[email protected]>"
<[email protected]<mailto:[email protected]>>
Date: 26.06.2017 16:18
Subject: Re: [onap-discuss] Robot vm script automation
Sent by:
[email protected]<mailto:[email protected]>
________________________________
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:
[email protected]<mailto:[email protected]>
[mailto:[email protected]] On Behalf Of
[email protected]<mailto:[email protected]>
Sent: Monday, June 26, 2017 5:29 AM
To: [email protected]<mailto:[email protected]>
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 mailing list
[email protected]<mailto:[email protected]>
https://lists.onap.org/mailman/listinfo/onap-discuss<https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.onap.org_mailman_listinfo_onap-2Ddiscuss&d=DwMFAw&c=LFYZ-o9_HUMeMTSQicvjIg&r=2wwdGZ3YcpSivQ2Kio028A&m=67rbu-2TYpYrg3TN-sSsjq6jdYUUSf8F2tvzocWGrt4&s=9pEnGuk1lSn_Ck0UTwqUlm8eWzzRhhAzyzTrlGd97vk&e=>
This message and the information contained herein is proprietary and
confidential and subject to the Amdocs policy statement,
you may review at
https://www.amdocs.com/about/email-disclaimer<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.amdocs.com_about_email-2Ddisclaimer&d=DwMFAw&c=LFYZ-o9_HUMeMTSQicvjIg&r=2wwdGZ3YcpSivQ2Kio028A&m=FHIeaymRGS1UTjq4KQmpOBIxMMmk90sP9Xugj1JH52o&s=bbsppCdLfWR_ItyUbIY3OzG9-c4xrq7gy2cV2wIEzPw&e=>
This message and the information contained herein is proprietary and
confidential and subject to the Amdocs policy statement,
you may review at https://www.amdocs.com/about/email-disclaimer
<https://www.amdocs.com/about/email-disclaimer>
_______________________________________________
onap-discuss mailing list
[email protected]
https://lists.onap.org/mailman/listinfo/onap-discuss
