Skip to content

Commit cc85715

Browse files
author
Anurag Palsule
authored
Merge pull request #2968 from vmware/rc-clone_vs_refactoring
Updates to clone_vs.py script
2 parents 01e8e06 + eedc9ec commit cc85715

File tree

2 files changed

+309
-79
lines changed

2 files changed

+309
-79
lines changed

Diff for: python/avi/sdk/samples/clone_vs.md

+38-6
Original file line numberDiff line numberDiff line change
@@ -72,18 +72,20 @@ Specify the VIP as a subnet/mask. This must match an auto-allocation subnet in I
7272

7373
If the source VIP was auto-allocated, the target can simply inherit the auto-allocation network:
7474

75-
> -v *
75+
> -v auto (or -v *)
76+
77+
(Note: On Linux/Unix/Mac systems, use the `auto` option as `*` would need to be escaped to prevent it being treated as a filename glob)
7678

7779
### Specifying public/elastic/floating IP for clouds that support this (e.g. public clouds, OpenStack)
7880

79-
Separate the public/floating IP using a `;`. A static public/floating IP can be specified explicitly, or o auto-allocate a public IP, use the `auto` keyword:
81+
Separate the public/floating IP using a `;`. A static public/floating IP can be specified explicitly, or to auto-allocate a public IP, use the `auto` keyword:
8082

8183
> -v 10.10.10.0/24;203.0.113.100
8284
> -v 10.10.10.0/24;auto
8385
8486
### Avi Internal IPAM
8587

86-
When using Avi Internal IPAM for auto-allocation, it may be necessary in some clouds (e.g. NSX-T Cloud) to supply the `-int` parameter to ensure the VsVip is populated with all the correct fields. Other clouds (e.g. vCenter Cloud) are more forgiving and usually work without specifying this parameter.
88+
When using Avi Internal IPAM for auto-allocation, it may be necessary in some clouds (e.g. NSX-T Cloud) to supply the `-int` parameter to ensure the VsVip is populated with all the correct fields. Other clouds (e.g. vCenter Cloud) are more forgiving and generally work without specifying this parameter if there is only a single IPAM subnet specified.
8789

8890
## Special flags
8991

@@ -212,17 +214,17 @@ If cloning a Virtual Service between Controllers or to a different tenant, the d
212214

213215
A WAF Policy and its referenced PSM groups can be forced cloned using the -fc flag. This supports the scenarios where the cloned VS should have its own WAF Policy rather than sharing the same WAF policy (including the case where learning is enabled).
214216

215-
In this case, if learning is enabled in the source WAF Policy, it will remain enabled in the cloned WAF Policy resulting in indepdent learning for the cloned VS.
217+
In this case, if learning is enabled in the source WAF Policy, it will remain enabled in the cloned WAF Policy resulting in independent learning for the cloned VS.
216218

217219
The below example clones a VS and forces cloning of the WAF Policy and any PSM groups also.
218220

219-
> clone_vs.py -c controller1.acme.com -fc vs-wafpolicy,positive-security-model vs example cloned-example -v *
221+
> clone_vs.py -c controller1.acme.com -fc vs-wafpolicy,positive-security-model vs example cloned-example -v auto
220222
221223
### Disabling learning in the cloned WAF Policy
222224

223225
It may desirable to disable learning for the cloned WAF Policy and its referenced PSM groups, for example if the source Virtual Service was used for learning and the cloned Virtual Service will be an instance of the same application, but independent learning is not desired. This can be achieved with the option `-flags disablelearning`:
224226

225-
> clone_vs.py -c controller1.acme.com -fc vs-wafpolicy,positive-security-model -flags disablelearning vs example cloned-example -v *
227+
> clone_vs.py -c controller1.acme.com -fc vs-wafpolicy,positive-security-model -flags disablelearning vs example cloned-example -v auto
226228
227229
This flag can also be used when cloning a WAF Policy individually:
228230

@@ -300,3 +302,33 @@ Changelog:
300302
2.0.2:
301303

302304
* Added support for flexibly handling specification of pool placement networks for cloned pools
305+
306+
2.0.3:
307+
308+
* Added some additional reference handling for less-common DataScript and WAF Profile configurations
309+
310+
2.0.4:
311+
312+
* Fixed VRF handling for cloning to/from NSX-T Cloud in certain scenarios
313+
314+
2.0.5:
315+
316+
* Fixed VRF handling with manual VsVip
317+
318+
2.0.6:
319+
320+
* Changed handling of Pool and PoolGroup references in VsDataScriptSet
321+
* Will now try to preserve the names of Pools and PoolGroups when cloning a VsDataScriptSet if possible (e.g. when cloning to a different tenant/Controller)
322+
* If name preservation is not possible, unique names will now be generated from the old Pool/PoolGroup name (previous behaviour was to generate names based on VsDataScript name)
323+
* Will generate a warning that DataScript code changes may be needed, for example because a Pool or PoolGroup name could not be preserved
324+
* Changed handling of PoolGroup cloning
325+
* Will now try to preserve the names of Pools when cloning a PoolGroup if possible (e.g. when cloning to a different tenant/Controller)
326+
* If name preservation is not possible, unique names will now be generated from the old Pool name (previous behaviour was to generate names based on PoolGroup name)
327+
328+
2.0.7:
329+
330+
* Add support for cloning HealthMonitors with SSL attributes or authentication attributes (authentication attributes must be manually re-entered)
331+
* Add support for cloning AuthProfiles for OAuth2
332+
* Add support for cloning VS with OAuth2 SSO configuration
333+
* Add support for cloning VS with service-level network/application profile overrides
334+
* Add support for cloning DNS VS with Topology Policies

0 commit comments

Comments
 (0)