Re: [onap-discuss] Robot vm script automation
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:bf1...@att.com]
Sent: Monday, July 24, 2017 08:27
To: FLOOD, JERRY ; ROSE, DANIEL V ; Michael
O'Brien ; Josef Reisinger
; PLATANIA, MARCO
Cc: onap-discuss@lists.onap.org; ajay.priyadar...@ril.com
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:
onap-discuss-boun...@lists.onap.org<mailto:onap-discuss-boun...@lists.onap.org>
[mailto:onap-discuss-boun...@lists.onap.org] On Behalf Of FLOOD, JERRY
Sent: Tuesday, June 27, 2017 6:03 PM
To: ROSE, DANIEL V mailto:dr6...@att.com>>; OBRIEN, FRANK
MICHAEL mailto:frank.obr...@amdocs.com>>; Josef
Reisinger mailto:josef.reisin...@de.ibm.com>>;
PLATANIA, MARCO mailto:plata...@research.att.com>>
Cc: onap-discuss@lists.onap.org<mailto:onap-discuss@lists.onap.org>;
ajay.priyadar...@ril.com<mailto:ajay.priyadar...@ril.com>
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
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: onap-discuss-boun...@lists.onap.org
[mailto:onap-discuss-boun...@lists.onap.org] On Behalf Of FLOOD, JERRY
Sent: Tuesday, June 27, 2017 6:03 PM
To: ROSE, DANIEL V ; OBRIEN, FRANK MICHAEL
; Josef Reisinger ;
PLATANIA, MARCO
Cc: onap-discuss@lists.onap.org; ajay.priyadar...@ril.com
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: onap-discuss@lists.onap.org<mailto:onap-discuss@lists.onap.org>;
ajay.priyadar...@ril.com<mailto:ajay.priyadar...@ril.com>
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: OBRI
Re: [onap-discuss] Robot vm script automation
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 Date : 2017-07-01 05:29 (GMT+9) Title : RE: RE: Re: [onap-discuss] Robot vm script automation To : null, Nayan Deshmukh, null, null, null CC : null, null Sounds good, thank you for following up on this (same to Nayan also) Daniel Rose ECOMP / ONAP com.att.ecomp 732-420-7308 From: OBRIEN, FRANK MICHAEL Sent: Friday, June 30, 2017 2:16 PM To: ROSE, DANIEL V ; n.deshm...@samsung.com; FLOOD, JERRY ; Josef Reisinger ; PLATANIA, MARCO Cc: onap-discuss@lists.onap.org; ajay.priyadar...@ril.com Subject: RE: RE: Re: [onap-discuss] Robot vm script automation 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 From: ROSE, DANIEL V [mailto:dr6...@att.com] Sent: Friday, June 30, 2017 13:22 To: Michael O'Brien <frank.obr...@amdocs.com>; n.deshm...@samsung.com; FLOOD, JERRY <jf9...@att.com>; Josef Reisinger <josef.reisin...@de.ibm.com>; PLATANIA, MARCO <plata...@research.att.com> Cc: onap-discuss@lists.onap.org; ajay.priyadar...@ril.com Subject: RE: RE: Re: [onap-discuss] Robot vm script automation 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 From: ROSE, DANIEL V Sent: Friday, June 30, 2017 9:55 AM To: OBRIEN, FRANK MICHAEL <frank.obr...@amdocs.com>; n.deshm...@samsung.com; FLOOD, JERRY <jf9...@att.com>; Josef Reisinger <josef.reisin...@de.ibm.com>; PLATANIA, MARCO <plata...@research.att.com> Cc: onap-discuss@lists.onap.org; ajay.priyadar...@ril.com Subject: RE: RE: Re: [onap-discuss] Robot vm script automation 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 From: OBRIEN, FRANK MICHAEL Sent: Friday, June 30, 2017 9:34 AM To: n.deshm...@samsung.com; ROSE, DANIEL V <dr6...@att.com>; FLOOD, JERRY <jf9...@att.com>; Josef Reisinger <josef.reisin...@de.ibm.com>; PLATANIA, MARCO <plata...@research.att.com> Cc: onap-discuss@lists.onap.org; ajay.priyadar...@ril.com Subject: RE: RE: Re: [onap-discuss] Robot vm script automation 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 From: Nayan Deshmukh [mailto:n.deshm...@samsung.com] Sent: Thursday, June 29, 2017 20:47 To: ROSE, DANIEL V <dr6...@att.com>; FLOOD, JERRY <jf9...@att.com>; Michael O'Brien <frank.obr...@amdocs.com>; Josef Reisinger <josef.reisin...@de.ibm.com>; PLATANIA, MARCO <plata...@research.att.com> Cc: onap-discuss@lists.onap.org; ajay.priyadar...@ril.com Subject: RE: RE: Re: [onap-discuss] Robot vm script automation 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 From: Nayan Deshmukh [mailto:n.deshm...@samsung.com] Sent: Thursday, June 29, 2017 12:43 AM To: FLOOD, JERRY <jf9...@att.com>; ROSE, DANIEL V <dr6...@att.com>; OBRIEN, FRANK MICHAEL <frank.obr...@amdocs.com>; Josef Reisinger <jos
Re: [onap-discuss] Robot vm script automation
Sounds good, thank you for following up on this (same to Nayan also) Daniel Rose ECOMP / ONAP com.att.ecomp 732-420-7308 From: OBRIEN, FRANK MICHAEL Sent: Friday, June 30, 2017 2:16 PM To: ROSE, DANIEL V ; n.deshm...@samsung.com; FLOOD, JERRY ; Josef Reisinger ; PLATANIA, MARCO Cc: onap-discuss@lists.onap.org; ajay.priyadar...@ril.com Subject: RE: RE: Re: [onap-discuss] Robot vm script automation 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 From: ROSE, DANIEL V [mailto:dr6...@att.com] Sent: Friday, June 30, 2017 13:22 To: Michael O'Brien mailto:frank.obr...@amdocs.com>>; n.deshm...@samsung.com<mailto:n.deshm...@samsung.com>; FLOOD, JERRY mailto:jf9...@att.com>>; Josef Reisinger mailto:josef.reisin...@de.ibm.com>>; PLATANIA, MARCO mailto:plata...@research.att.com>> Cc: onap-discuss@lists.onap.org<mailto:onap-discuss@lists.onap.org>; ajay.priyadar...@ril.com<mailto:ajay.priyadar...@ril.com> Subject: RE: RE: Re: [onap-discuss] Robot vm script automation I have submitted a patch https://gerrit.onap.org/r/#/c/5625/<https://urldefense.proofpoint.com/v2/url?u=https-3A__gerrit.onap.org_r_-23_c_5625_&d=DwMGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=2wwdGZ3YcpSivQ2Kio028A&m=aH88ejv0xofQVfOSC6uIHNMjyLuuZAJzazBP6qsc3BE&s=0dZAP-OiQe8WllYpX1o11zvvptfRo48rtSfH97p5O0k&e=> and https://gerrit.onap.org/r/#/c/5627/<https://urldefense.proofpoint.com/v2/url?u=https-3A__gerrit.onap.org_r_-23_c_5627_&d=DwMGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=2wwdGZ3YcpSivQ2Kio028A&m=aH88ejv0xofQVfOSC6uIHNMjyLuuZAJzazBP6qsc3BE&s=nnxbzo9xIKruudZjXiYBLVfRnEFuMxs1YVoD_jIbciY&e=> 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 From: ROSE, DANIEL V Sent: Friday, June 30, 2017 9:55 AM To: OBRIEN, FRANK MICHAEL mailto:frank.obr...@amdocs.com>>; n.deshm...@samsung.com<mailto:n.deshm...@samsung.com>; FLOOD, JERRY mailto:jf9...@att.com>>; Josef Reisinger mailto:josef.reisin...@de.ibm.com>>; PLATANIA, MARCO mailto:plata...@research.att.com>> Cc: onap-discuss@lists.onap.org<mailto:onap-discuss@lists.onap.org>; ajay.priyadar...@ril.com<mailto:ajay.priyadar...@ril.com> Subject: RE: RE: Re: [onap-discuss] Robot vm script automation 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 From: OBRIEN, FRANK MICHAEL Sent: Friday, June 30, 2017 9:34 AM To: n.deshm...@samsung.com<mailto:n.deshm...@samsung.com>; ROSE, DANIEL V mailto:dr6...@att.com>>; FLOOD, JERRY mailto:jf9...@att.com>>; Josef Reisinger mailto:josef.reisin...@de.ibm.com>>; PLATANIA, MARCO mailto:plata...@research.att.com>> Cc: onap-discuss@lists.onap.org<mailto:onap-discuss@lists.onap.org>; ajay.priyadar...@ril.com<mailto:ajay.priyadar...@ril.com> Subject: RE: RE: Re: [onap-discuss] Robot vm script automation 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://urldefense.proofpoint.com/v2/url?u=https-3A__gerrit.onap.org_r_gitweb-3Fp-3Ddemo.git-3Ba-3Dcommitdiff-3Bh-3D408e5ba68e74c9c8fe642f6b06a5581a6761a344&d=DwMGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=2wwdGZ3YcpSivQ2Kio028A&m=BPpmjLgZEkO3bAMdCJ4cr9H7nTyN2tlSDQpe804ewQs&s=KP9RAiBdZ4x2IrFiQO4N1uLpHDtNLIvVsOaFOTbX7xA&e=> https://jira.onap.org/browse/UCA-17<https://urldefense.proofpoint.com/v2/url?u=https-3A__jira.onap.org_browse_UCA-2D17&d=DwMGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=2wwdGZ3YcpSivQ2Kio028A&m=BPpmjLgZEkO3bAMdCJ4cr9H7nTyN2tlSDQpe804ewQs&s=ER-iYsp0qurXJDez3ZsVYvtd-fO1tCGT8S3HavTtX4w&e=> /michael From: Nayan Deshmukh [mailto:n.deshm...@samsung.com] Sent: Thursday, June 29, 2017 20:47 To: ROSE, DANIEL V mailto:dr6...@att.com>>; FLOOD, JERRY mailto:jf9...@att.com>>; Michael O'Brien m
Re: [onap-discuss] Robot vm script automation
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 From: ROSE, DANIEL V [mailto:dr6...@att.com] Sent: Friday, June 30, 2017 13:22 To: Michael O'Brien ; n.deshm...@samsung.com; FLOOD, JERRY ; Josef Reisinger ; PLATANIA, MARCO Cc: onap-discuss@lists.onap.org; ajay.priyadar...@ril.com Subject: RE: RE: Re: [onap-discuss] Robot vm script automation 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 From: ROSE, DANIEL V Sent: Friday, June 30, 2017 9:55 AM To: OBRIEN, FRANK MICHAEL mailto:frank.obr...@amdocs.com>>; n.deshm...@samsung.com<mailto:n.deshm...@samsung.com>; FLOOD, JERRY mailto:jf9...@att.com>>; Josef Reisinger mailto:josef.reisin...@de.ibm.com>>; PLATANIA, MARCO mailto:plata...@research.att.com>> Cc: onap-discuss@lists.onap.org<mailto:onap-discuss@lists.onap.org>; ajay.priyadar...@ril.com<mailto:ajay.priyadar...@ril.com> Subject: RE: RE: Re: [onap-discuss] Robot vm script automation 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 From: OBRIEN, FRANK MICHAEL Sent: Friday, June 30, 2017 9:34 AM To: n.deshm...@samsung.com<mailto:n.deshm...@samsung.com>; ROSE, DANIEL V mailto:dr6...@att.com>>; FLOOD, JERRY mailto:jf9...@att.com>>; Josef Reisinger mailto:josef.reisin...@de.ibm.com>>; PLATANIA, MARCO mailto:plata...@research.att.com>> Cc: onap-discuss@lists.onap.org<mailto:onap-discuss@lists.onap.org>; ajay.priyadar...@ril.com<mailto:ajay.priyadar...@ril.com> Subject: RE: RE: Re: [onap-discuss] Robot vm script automation 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://urldefense.proofpoint.com/v2/url?u=https-3A__gerrit.onap.org_r_gitweb-3Fp-3Ddemo.git-3Ba-3Dcommitdiff-3Bh-3D408e5ba68e74c9c8fe642f6b06a5581a6761a344&d=DwMGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=2wwdGZ3YcpSivQ2Kio028A&m=BPpmjLgZEkO3bAMdCJ4cr9H7nTyN2tlSDQpe804ewQs&s=KP9RAiBdZ4x2IrFiQO4N1uLpHDtNLIvVsOaFOTbX7xA&e=> https://jira.onap.org/browse/UCA-17<https://urldefense.proofpoint.com/v2/url?u=https-3A__jira.onap.org_browse_UCA-2D17&d=DwMGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=2wwdGZ3YcpSivQ2Kio028A&m=BPpmjLgZEkO3bAMdCJ4cr9H7nTyN2tlSDQpe804ewQs&s=ER-iYsp0qurXJDez3ZsVYvtd-fO1tCGT8S3HavTtX4w&e=> /michael From: Nayan Deshmukh [mailto:n.deshm...@samsung.com] Sent: Thursday, June 29, 2017 20:47 To: ROSE, DANIEL V mailto:dr6...@att.com>>; FLOOD, JERRY mailto:jf9...@att.com>>; Michael O'Brien mailto:frank.obr...@amdocs.com>>; Josef Reisinger mailto:josef.reisin...@de.ibm.com>>; PLATANIA, MARCO mailto:plata...@research.att.com>> Cc: onap-discuss@lists.onap.org<mailto:onap-discuss@lists.onap.org>; ajay.priyadar...@ril.com<mailto:ajay.priyadar...@ril.com> Subject: RE: RE: Re: [onap-discuss] Robot vm script automation done and merged :) - Original Message - Sender : ROSE, DANIEL V mailto:dr6...@att.com>> Date : 2017-06-30 00:44 (GMT+9) Title : RE: Re: [onap-discuss] Robot vm script automation To : Nayan Deshmukhmailto:n.deshm...@samsung.com>>, nullmailto:jf9...@att.com>>, nullmailto:frank.obr...@amdocs.com>>, nullmailto:josef.reisin...@de.ibm.com>>, nullmailto:plata...@research.att.com>> CC : nullmailto:onap-discuss@lists.onap.org>>, nullmailto: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 From: Nayan Deshmukh [mailto:n.deshm...@samsung.com] Sent: Thursday, June 29, 2017 12:43 AM To: FLOOD, JERRY mailto:jf9...@att.com>>; ROSE, DANIE
Re: [onap-discuss] Robot vm script automation
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 From: ROSE, DANIEL V Sent: Friday, June 30, 2017 9:55 AM To: OBRIEN, FRANK MICHAEL ; n.deshm...@samsung.com; FLOOD, JERRY ; Josef Reisinger ; PLATANIA, MARCO Cc: onap-discuss@lists.onap.org; ajay.priyadar...@ril.com Subject: RE: RE: Re: [onap-discuss] Robot vm script automation 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 From: OBRIEN, FRANK MICHAEL Sent: Friday, June 30, 2017 9:34 AM To: n.deshm...@samsung.com<mailto:n.deshm...@samsung.com>; ROSE, DANIEL V mailto:dr6...@att.com>>; FLOOD, JERRY mailto:jf9...@att.com>>; Josef Reisinger mailto:josef.reisin...@de.ibm.com>>; PLATANIA, MARCO mailto:plata...@research.att.com>> Cc: onap-discuss@lists.onap.org<mailto:onap-discuss@lists.onap.org>; ajay.priyadar...@ril.com<mailto:ajay.priyadar...@ril.com> Subject: RE: RE: Re: [onap-discuss] Robot vm script automation 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://urldefense.proofpoint.com/v2/url?u=https-3A__gerrit.onap.org_r_gitweb-3Fp-3Ddemo.git-3Ba-3Dcommitdiff-3Bh-3D408e5ba68e74c9c8fe642f6b06a5581a6761a344&d=DwMGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=2wwdGZ3YcpSivQ2Kio028A&m=BPpmjLgZEkO3bAMdCJ4cr9H7nTyN2tlSDQpe804ewQs&s=KP9RAiBdZ4x2IrFiQO4N1uLpHDtNLIvVsOaFOTbX7xA&e=> https://jira.onap.org/browse/UCA-17<https://urldefense.proofpoint.com/v2/url?u=https-3A__jira.onap.org_browse_UCA-2D17&d=DwMGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=2wwdGZ3YcpSivQ2Kio028A&m=BPpmjLgZEkO3bAMdCJ4cr9H7nTyN2tlSDQpe804ewQs&s=ER-iYsp0qurXJDez3ZsVYvtd-fO1tCGT8S3HavTtX4w&e=> /michael From: Nayan Deshmukh [mailto:n.deshm...@samsung.com] Sent: Thursday, June 29, 2017 20:47 To: ROSE, DANIEL V mailto:dr6...@att.com>>; FLOOD, JERRY mailto:jf9...@att.com>>; Michael O'Brien mailto:frank.obr...@amdocs.com>>; Josef Reisinger mailto:josef.reisin...@de.ibm.com>>; PLATANIA, MARCO mailto:plata...@research.att.com>> Cc: onap-discuss@lists.onap.org<mailto:onap-discuss@lists.onap.org>; ajay.priyadar...@ril.com<mailto:ajay.priyadar...@ril.com> Subject: RE: RE: Re: [onap-discuss] Robot vm script automation done and merged :) ----- Original Message - Sender : ROSE, DANIEL V mailto:dr6...@att.com>> Date : 2017-06-30 00:44 (GMT+9) Title : RE: Re: [onap-discuss] Robot vm script automation To : Nayan Deshmukhmailto:n.deshm...@samsung.com>>, nullmailto:jf9...@att.com>>, nullmailto:frank.obr...@amdocs.com>>, nullmailto:josef.reisin...@de.ibm.com>>, nullmailto:plata...@research.att.com>> CC : nullmailto:onap-discuss@lists.onap.org>>, nullmailto: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 From: Nayan Deshmukh [mailto:n.deshm...@samsung.com] Sent: Thursday, June 29, 2017 12:43 AM To: FLOOD, JERRY mailto:jf9...@att.com>>; ROSE, DANIEL V mailto:dr6...@att.com>>; OBRIEN, FRANK MICHAEL mailto:frank.obr...@amdocs.com>>; Josef Reisinger mailto:josef.reisin...@de.ibm.com>>; PLATANIA, MARCO mailto:plata...@research.att.com>> Cc: onap-discuss@lists.onap.org<mailto:onap-discuss@lists.onap.org>; ajay.priyadar...@ril.com<mailto:ajay.priyadar...@ril.com> Subject: RE: Re: [onap-discuss] Robot vm script automation 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 onl
Re: [onap-discuss] Robot vm script automation
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 From: OBRIEN, FRANK MICHAEL Sent: Friday, June 30, 2017 9:34 AM To: n.deshm...@samsung.com; ROSE, DANIEL V ; FLOOD, JERRY ; Josef Reisinger ; PLATANIA, MARCO Cc: onap-discuss@lists.onap.org; ajay.priyadar...@ril.com Subject: RE: RE: Re: [onap-discuss] Robot vm script automation 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://urldefense.proofpoint.com/v2/url?u=https-3A__gerrit.onap.org_r_gitweb-3Fp-3Ddemo.git-3Ba-3Dcommitdiff-3Bh-3D408e5ba68e74c9c8fe642f6b06a5581a6761a344&d=DwMGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=2wwdGZ3YcpSivQ2Kio028A&m=BPpmjLgZEkO3bAMdCJ4cr9H7nTyN2tlSDQpe804ewQs&s=KP9RAiBdZ4x2IrFiQO4N1uLpHDtNLIvVsOaFOTbX7xA&e=> https://jira.onap.org/browse/UCA-17<https://urldefense.proofpoint.com/v2/url?u=https-3A__jira.onap.org_browse_UCA-2D17&d=DwMGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=2wwdGZ3YcpSivQ2Kio028A&m=BPpmjLgZEkO3bAMdCJ4cr9H7nTyN2tlSDQpe804ewQs&s=ER-iYsp0qurXJDez3ZsVYvtd-fO1tCGT8S3HavTtX4w&e=> /michael From: Nayan Deshmukh [mailto:n.deshm...@samsung.com] Sent: Thursday, June 29, 2017 20:47 To: ROSE, DANIEL V mailto:dr6...@att.com>>; FLOOD, JERRY mailto:jf9...@att.com>>; Michael O'Brien mailto:frank.obr...@amdocs.com>>; Josef Reisinger mailto:josef.reisin...@de.ibm.com>>; PLATANIA, MARCO mailto:plata...@research.att.com>> Cc: onap-discuss@lists.onap.org<mailto:onap-discuss@lists.onap.org>; ajay.priyadar...@ril.com<mailto:ajay.priyadar...@ril.com> Subject: RE: RE: Re: [onap-discuss] Robot vm script automation done and merged :) - Original Message ----- Sender : ROSE, DANIEL V mailto:dr6...@att.com>> Date : 2017-06-30 00:44 (GMT+9) Title : RE: Re: [onap-discuss] Robot vm script automation To : Nayan Deshmukhmailto:n.deshm...@samsung.com>>, nullmailto:jf9...@att.com>>, nullmailto:frank.obr...@amdocs.com>>, nullmailto:josef.reisin...@de.ibm.com>>, nullmailto:plata...@research.att.com>> CC : nullmailto:onap-discuss@lists.onap.org>>, nullmailto: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 From: Nayan Deshmukh [mailto:n.deshm...@samsung.com] Sent: Thursday, June 29, 2017 12:43 AM To: FLOOD, JERRY mailto:jf9...@att.com>>; ROSE, DANIEL V mailto:dr6...@att.com>>; OBRIEN, FRANK MICHAEL mailto:frank.obr...@amdocs.com>>; Josef Reisinger mailto:josef.reisin...@de.ibm.com>>; PLATANIA, MARCO mailto:plata...@research.att.com>> Cc: onap-discuss@lists.onap.org<mailto:onap-discuss@lists.onap.org>; ajay.priyadar...@ril.com<mailto:ajay.priyadar...@ril.com> Subject: RE: Re: [onap-discuss] Robot vm script automation 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 mailto:jf9...@att.com>> Date : 2017-06-28 07:03 (GMT+9) Title : Re: [onap-discuss] Robot vm script automation To : nullmailto:dr6...@att.com>>, nullmailto:frank.obr...@amdocs.com>>, nullmailto:josef.reisin...@de.ibm.com>>, nullmailto:plata...@research.att.com>> CC : nullmailto:onap-discuss@lists.onap.org>>, nullmailto: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
Re: [onap-discuss] Robot vm script automation
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
From: Nayan Deshmukh [mailto:n.deshm...@samsung.com]
Sent: Thursday, June 29, 2017 20:47
To: ROSE, DANIEL V ; FLOOD, JERRY ; Michael
O'Brien ; Josef Reisinger
; PLATANIA, MARCO
Cc: onap-discuss@lists.onap.org; ajay.priyadar...@ril.com
Subject: RE: RE: Re: [onap-discuss] Robot vm script automation
done and merged :)
- Original Message -
Sender : ROSE, DANIEL V mailto:dr6...@att.com>>
Date : 2017-06-30 00:44 (GMT+9)
Title : RE: Re: [onap-discuss] Robot vm script automation
To : Nayan Deshmukhmailto:n.deshm...@samsung.com>>,
nullmailto:jf9...@att.com>>,
nullmailto:frank.obr...@amdocs.com>>,
nullmailto:josef.reisin...@de.ibm.com>>,
nullmailto:plata...@research.att.com>>
CC : nullmailto:onap-discuss@lists.onap.org>>,
nullmailto: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
From: Nayan Deshmukh [mailto:n.deshm...@samsung.com]
Sent: Thursday, June 29, 2017 12:43 AM
To: FLOOD, JERRY mailto:jf9...@att.com>>; ROSE, DANIEL V
mailto:dr6...@att.com>>; OBRIEN, FRANK MICHAEL
mailto:frank.obr...@amdocs.com>>; Josef Reisinger
mailto:josef.reisin...@de.ibm.com>>; PLATANIA,
MARCO mailto:plata...@research.att.com>>
Cc: onap-discuss@lists.onap.org<mailto:onap-discuss@lists.onap.org>;
ajay.priyadar...@ril.com<mailto:ajay.priyadar...@ril.com>
Subject: RE: Re: [onap-discuss] Robot vm script automation
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 mailto:jf9...@att.com>>
Date : 2017-06-28 07:03 (GMT+9)
Title : Re: [onap-discuss] Robot vm script automation
To : nullmailto:dr6...@att.com>>,
nullmailto:frank.obr...@amdocs.com>>,
nullmailto:josef.reisin...@de.ibm.com>>,
nullmailto:plata...@research.att.com>>
CC : nullmailto:onap-discuss@lists.onap.org>>,
nullmailto: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}&quo
Re: [onap-discuss] Robot vm script automation
done and merged :)
- Original Message -
Sender : ROSE, DANIEL V
Date : 2017-06-30 00:44 (GMT+9)
Title : RE: Re: [onap-discuss] Robot vm script automation
To : Nayan Deshmukh, null, null, null, null
CC : null, null
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
From: Nayan Deshmukh [mailto:n.deshm...@samsung.com]
Sent: Thursday, June 29, 2017 12:43 AM To: FLOOD, JERRY ; ROSE, DANIEL V ; OBRIEN, FRANK MICHAEL ; Josef Reisinger ; PLATANIA, MARCO Cc: onap-discuss@lists.onap.org; ajay.priyadar...@ril.com Subject: RE: Re: [onap-discuss] Robot vm script automation
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 co
Re: [onap-discuss] Robot vm script automation
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
From: Nayan Deshmukh [mailto:n.deshm...@samsung.com]
Sent: Thursday, June 29, 2017 12:43 AM
To: FLOOD, JERRY ; ROSE, DANIEL V ; OBRIEN,
FRANK MICHAEL ; Josef Reisinger
; PLATANIA, MARCO
Cc: onap-discuss@lists.onap.org; ajay.priyadar...@ril.com
Subject: RE: Re: [onap-discuss] Robot vm script automation
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 mailto:jf9...@att.com>>
Date : 2017-06-28 07:03 (GMT+9)
Title : Re: [onap-discuss] Robot vm script automation
To : nullmailto:dr6...@att.com>>,
nullmailto:frank.obr...@amdocs.com>>,
nullmailto:josef.reisin...@de.ibm.com>>,
nullmailto:plata...@research.att.com>>
CC : nullmailto:onap-discuss@lists.onap.org>>,
nullmailto: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 ${
Re: [onap-discuss] Robot vm script automation
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
Date : 2017-06-28 07:03 (GMT+9)
Title : Re: [onap-discuss] Robot vm script automation
To : null, null, null, null
CC : null, null
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: onap-discuss@lists.onap.org; ajay.priyadar...@ril.com 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 <dr6...@att.com>; Josef Reisinger <josef.reisin...@de.ibm.com> Cc: onap-discuss@lists
Re: [onap-discuss] Robot vm script automation
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: onap-discuss@lists.onap.org; ajay.priyadar...@ril.com
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 mailto:dr6...@att.com>>; Josef Reisinger
mailto:josef.reisin...@de.ibm.com>>
Cc: onap-discuss@lists.onap.org<mailto:onap-discuss@lists.onap.org>;
ajay.priyadar...@ril.com<mailto:ajay.priyadar...@ril.com>
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:
onap-discuss-boun...@lists.onap.org<m
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 ; Josef Reisinger Cc: onap-discuss@lists.onap.org; ajay.priyadar...@ril.com 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: onap-discuss-boun...@lists.onap.org<mailto:onap-discuss-boun...@lists.onap.org> [mailto:onap-discuss-boun...@lists.onap.org] On Behalf Of ROSE, DANIEL V Sent: Monday, June 26, 2017 10:38 To: Josef Reisinger mailto:josef.reisin...@de.ibm.com>> Cc: onap-discuss@lists.onap.org<mailto:onap-discuss@lists.onap.org>; ajay.priyadar...@ril.com<mailto:ajay.priyadar...@ril.com> 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:josef.reisin...@de.ibm.com] Sent: Monday, June 26, 2017 10:27 AM To: ROSE, DANIEL V mailto:dr6...@att.com>> Cc: ajay.priyadar...@ril.com<mailto:ajay.priyadar...@ril.com>; onap-discuss@lists.onap.org<mailto: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 . Even the VMs start (more or less), does this break the demo? Mit freundlichen Grüßen / Kind regards Josef Reisinger From:"ROSE, DANIEL V" mailto:dr6...@att.com>> To:"ajay.priyadar...@ril.com<mailto:ajay.priyadar...@ril.com>" mailto:ajay.priyadar...@ril.com>>, "onap-discuss@lists.onap.org<mailto:onap-discuss@lists.onap.org>" mailto: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<mailto: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> [mailto:onap-discuss-boun...@lists.onap.org] On Behalf Of ajay.priyadar...@ril.com<mailto:ajay.priyadar...@ril.com> Sent: Monday, June 26, 2017 5:29 AM To: onap-discuss@lists.onap.org<mailto: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 t
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 /michael From: onap-discuss-boun...@lists.onap.org [mailto:onap-discuss-boun...@lists.onap.org] On Behalf Of ROSE, DANIEL V Sent: Monday, June 26, 2017 10:38 To: Josef Reisinger Cc: onap-discuss@lists.onap.org; ajay.priyadar...@ril.com 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:josef.reisin...@de.ibm.com] Sent: Monday, June 26, 2017 10:27 AM To: ROSE, DANIEL V mailto:dr6...@att.com>> Cc: ajay.priyadar...@ril.com<mailto:ajay.priyadar...@ril.com>; onap-discuss@lists.onap.org<mailto: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 . Even the VMs start (more or less), does this break the demo? Mit freundlichen Grüßen / Kind regards Josef Reisinger From:"ROSE, DANIEL V" mailto:dr6...@att.com>> To:"ajay.priyadar...@ril.com<mailto:ajay.priyadar...@ril.com>" mailto:ajay.priyadar...@ril.com>>, "onap-discuss@lists.onap.org<mailto:onap-discuss@lists.onap.org>" mailto: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<mailto: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> [mailto:onap-discuss-boun...@lists.onap.org] On Behalf Of ajay.priyadar...@ril.com<mailto:ajay.priyadar...@ril.com> Sent: Monday, June 26, 2017 5:29 AM To: onap-discuss@lists.onap.org<mailto: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 mailing list onap-discuss@lists.onap.org<mailto:onap-discuss@lists.onap.org> 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=DwMFA
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:josef.reisin...@de.ibm.com] Sent: Monday, June 26, 2017 10:27 AM To: ROSE, DANIEL V 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 . Even the VMs start (more or less), does this break the demo? Mit freundlichen Grüßen / Kind regards Josef Reisinger From:"ROSE, DANIEL V" mailto:dr6...@att.com>> To:"ajay.priyadar...@ril.com<mailto:ajay.priyadar...@ril.com>" mailto:ajay.priyadar...@ril.com>>, "onap-discuss@lists.onap.org<mailto:onap-discuss@lists.onap.org>" mailto: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<mailto: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> [mailto:onap-discuss-boun...@lists.onap.org] On Behalf Of ajay.priyadar...@ril.com<mailto:ajay.priyadar...@ril.com> Sent: Monday, June 26, 2017 5:29 AM To: onap-discuss@lists.onap.org<mailto: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 mailing list onap-discuss@lists.onap.org<mailto:onap-discuss@lists.onap.org> 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=> ___ onap-discuss mailing list onap-discuss@lists.onap.org https://lists.onap.org/mailman/listinfo/onap-discuss
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 . Even the VMs start (more or less), does this break the demo? Mit freundlichen Grüßen / Kind regards Josef Reisinger From: "ROSE, DANIEL V" To: "ajay.priyadar...@ril.com" , "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 mailing list onap-discuss@lists.onap.org https://lists.onap.org/mailman/listinfo/onap-discuss ___ onap-discuss mailing list onap-discuss@lists.onap.org https://lists.onap.org/mailman/listinfo/onap-discuss
Re: [onap-discuss] Robot vm script automation
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 mailing list onap-discuss@lists.onap.org https://lists.onap.org/mailman/listinfo/onap-discuss
