vmware-tanzu / service-installer-for-vmware-tanzu

Service Installer for VMware Tanzu is a one-click automation solution that enables VMware field engineers to easily and rapidly install, configure, and operate VMware Tanzu services across a variety of cloud infrastructures.

Service Installer for VMware Tanzu

Service Installer for VMware Tanzu seeks to provide a one-click automation solution to enable our VMware engineers and field teams to install and configure Tanzu Services across a variety of cloud infrastructures easily and rapidly, and in conformance with prescribed Tanzu Reference Architecture

​Service Installer for VMware Tanzu:

1. This project focuses on building reference architectures for Multiple Cloud Endpoints
2. Simplifies adaption of Tanzu Solutions by automating the deployment of TKO validated architecture
3. TKO Reference Architectures and automation adapts the best practices of Tanzu
4. Integrates with multiple SaaS endpoints(TMC, TO and TSM), and Marketplace which brings whole set of new features OOB
5. Deploys and configures the shared services (Contour, Harbor, FluentBit, Prometheus, Grafana) which is critical for day-day operations
6. Deploy, configure and integrate with AVI to support advanced load-balancing capabilities

Before you begin

• Check out the contribution guidelines to learn more about how to contribute
• Check out this support process document here to learn more about the process.

Roadmap

Check out the project Roadmap and consider contributing!

Contributing

The service-installer-for-vmware-tanzu project team welcomes contributions from the community. Before you start working with service-installer-for-vmware-tanzu, please read our Developer Certificate of Origin. All contributions to this repository must be signed as described on that page. Your signature certifies that you wrote the patch or have the right to pass it on as an open-source patch. For more detailed information, refer to CONTRIBUTING.

Important Links

1. Getting started with Service Installer for VMware Tanzu

• Product Documentation
• TKGm on vSphere backed by VDS
• TKGs on vSphere backed by VDS
• TKGm on vSphere backed by NSX-T
• TKGm on VMC

2. Service Installer for VMware Tanzu download link

Containerizing arcas

• Check out this document here to learn more about Containerizing arcas .

service-installer-for-vmware-tanzu's Issues

SIVT fails to deploy AVI SE in a secured/restricted RBAC vSphere/vCenter environment

Bug description

IHAC that provides managed vSphere environment, which will not provide the level of permissions that AVI LB requires currently in the normal vCenter/vSphere mode.

In the normal vSphere model right now it seems we have 2 issues we have seen so far:

• AVI controllers require network to ESXi connectivity which is not provided/allowed.
• AVI Automation process tries to create vSwitch/portgroups on the ESXi hosts directly which is not allowed.

That said we saw that the VMC deployment model seems to mitigate the issue but can't be used right now for VCPP SPs.

Affected product modules (please put an X in all that apply)

• SIVT APIs
• SIVT UI
• SIVT CLI
• Docs

Expected behavior

It would be great that SIVT provides a choice for the ALB deployment method as many VMware SDDC Managed offerings from SP will have the same security/constraints applied.

This would be on Step 6 actually as shown below

[ ] vSphere
[x] No Orchestrator

Steps to reproduce the bug

I Provided access to the environment for VMware analysis.

Version (include the SHA if the version is not obvious)

SIVT 1.2.0

Environment where the bug was observed (vSphere+VMC, vSpshere+DVS, vSphere+NSXt, etc)

• SIVT version: 1.2.0
• vSphere version: 6.7u3
• vCenter version: 6.7u3
• Kubernetes version: (use kubectl version):
• Kubernetes installer & version:
• Cloud provider or hardware configuration:
• OS (e.g. from /etc/os-release):
• Sonobuoy tarball (which contains * below)

Relevant Debug Output (Logs, manifests, etc)

ESXi access

2022-07-06 14:40:01,753  INFO [pool-1-thread-11] (vCenterMgrServiceImplementation.java:2936) - ---------------------------------------------
2022-07-06 14:40:01,753  INFO [pool-1-thread-11] (vCenterMgrServiceImplementation.java:2937) -  vICheckHostReachability : OPERATION START Time Stamp 2022-07-06 14:40:01.753
2022-07-06 14:40:01,753  INFO [pool-1-thread-11] (vCenterMgrServiceImplementation.java:2938) - ---------------------------------------------
2022-07-06 14:40:03,755  INFO [pool-1-thread-11] (VC_Mgr.java:235) - Cannot connect to port 443 of IP  172.20.244.54 connect timed out
2022-07-06 14:40:03,755  INFO [pool-1-thread-11] (vCenterMgrServiceImplementation.java:2957) - Host name : 172.20.244.54 Ping failure
2022-07-06 14:40:05,757  INFO [pool-1-thread-11] (VC_Mgr.java:235) - Cannot connect to port 443 of IP  172.20.244.56 connect timed out
2022-07-06 14:40:05,758  INFO [pool-1-thread-11] (vCenterMgrServiceImplementation.java:2957) - Host name : 172.20.244.56 Ping failure
2022-07-06 14:40:07,760  INFO [pool-1-thread-11] (VC_Mgr.java:235) - Cannot connect to port 443 of IP  172.20.244.51 connect timed out
2022-07-06 14:40:07,761  INFO [pool-1-thread-11] (vCenterMgrServiceImplementation.java:2957) - Host name : 172.20.244.51 Ping failure
2022-07-06 14:40:09,763  INFO [pool-1-thread-11] (VC_Mgr.java:235) - Cannot connect to port 443 of IP  172.20.244.53 connect timed out
2022-07-06 14:40:09,763  INFO [pool-1-thread-11] (vCenterMgrServiceImplementation.java:2957) - Host name : 172.20.244.53 Ping failure
2022-07-06 14:40:11,766  INFO [pool-1-thread-11] (VC_Mgr.java:235) - Cannot connect to port 443 of IP  172.20.244.50 connect timed out
2022-07-06 14:40:11,766  INFO [pool-1-thread-11] (vCenterMgrServiceImplementation.java:2957) - Host name : 172.20.244.50 Ping failure
2022-07-06 14:40:13,769  INFO [pool-1-thread-11] (VC_Mgr.java:235) - Cannot connect to port 443 of IP  172.20.244.52 connect timed out
2022-07-06 14:40:13,769  INFO [pool-1-thread-11] (vCenterMgrServiceImplementation.java:2957) - Host name : 172.20.244.52 Ping failure
2022-07-06 14:40:14,013  INFO [pool-1-thread-11] (vCenterMgrServiceImplementation.java:2978) -  vICheckHostReachability : OPERATION STOP Time Stamp 2022-07-06 14:40:14.013

vSwitch creation

2022-07-06 16:39:18,298  INFO [pool-3-thread-3] (VC_Mgr.java:356) - ===========================================================================
2022-07-06 16:39:30,619  INFO [pool-3-thread-4] (VC_Mgr.java:346) - ===========================================================================
2022-07-06 16:39:30,619  INFO [pool-3-thread-4] (VC_Mgr.java:347) - Object Info : RuntimeFault in creating vSwitch0
2022-07-06 16:39:30,619  INFO [pool-3-thread-4] (VC_Mgr.java:348) - com.vmware.vim25.NoPermission
2022-07-06 16:39:30,619  INFO [pool-3-thread-4] (VC_Mgr.java:353) - Message     : null
2022-07-06 16:39:30,619  INFO [pool-3-thread-4] (VC_Mgr.java:354) - StackTrace  : 
2022-07-06 16:39:30,619  INFO [pool-3-thread-4] (VC_Mgr.java:355) - com.vmware.vim25.NoPermission
	at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
	at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
	at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
	at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
	at java.lang.Class.newInstance(Class.java:442)
	at org.doublecloud.ws.gen.XmlGenStream.a(Unknown Source)
	at org.doublecloud.ws.gen.XmlGenStream.fromXML(Unknown Source)
	at com.vmware.vim25.ws.WSClient.invoke(Unknown Source)
	at com.vmware.vim25.ws.VimStub.addVirtualSwitch(Unknown Source)
	at com.vmware.vim25.mo.HostNetworkSystem.addVirtualSwitch(Unknown Source)
	at com.avinetworks.infrastructure.vcenter.VCMgrCreateVMFromOVAParams.retrieveAviInternalNetwork(VCMgrCreateVMFromOVAParams.java:1870)
	at com.avinetworks.infrastructure.vcenter.VCMgrCreateVMFromOVAParams.vmWareCreateAVISEfromOVF(VCMgrCreateVMFromOVAParams.java:581)
	at com.avinetworks.infrastructure.vcenter.vCenterMgrServiceImplementation.vICreateSEVM(vCenterMgrServiceImplementation.java:1292)
	at com.avinetworks.protobuf.vCenterMgr$vCenterMgrService.callMethod(vCenterMgr.java:45550)
	at com.avinetworks.infrastructure.tcp_rpc.TcpRpcRequestProcessor$TcpRpcRequestHandler.handle_request(TcpRpcRequestProcessor.java:270)
	at com.avinetworks.infrastructure.tcp_rpc.TcpRpcRequestProcessor$TcpRpcRequestHandler.run(TcpRpcRequestProcessor.java:190)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
	at java.lang.Thread.run(Thread.java:748)

Broken link to TKO ref architecture

In the first section of the readme.md inside https://github.com/vmware-tanzu/service-installer-for-vmware-tanzu/tree/1.1-1.5.1/azure there is a link 'Based on the Reference Architecture, TKO on Azure Hybrid-Cloud' that is broken.

https://github.com/vmware-tanzu/service-installer-for-vmware-tanzu/blob/src/reference-designs/tko-on-azure-hybrid.md

It seems that the correct URL is this --> https://github.com/gradinDotCom/tanzu-validated-solutions/blob/tko-azure-hybrid/src/reference-designs/tko-on-azure.md.

Thanks, Rodrigo.

Failed to create folder Operation failed

Just after the pre-checks, the installer throws the following error:

ERROR :Failed to create folder Operation failed 'NoneType' object has no attribute 'vmFolder' AVI configuration failed {'responseType': 'ERROR', 'msg': "Failed to create resource pool and folder Failed to create folder Operation failed 'NoneType' object has no attribute 'vmFolder'", 'STATUS_CODE': 500}

No other info available.

Shared cluster deployment fails while trying to find the vCenter address

Bug description

Shared cluster deployment fails while trying to find the vCenter address with the following message:

ERROR :Failed to deploy cluster Failed Error: unable to wait for cluster and get the cluster kubeconfig: error waiting for cluster to be provisioned (this may take a few minutes): cluster creation failed, reason:'VCenterUnreachable', message:'Post "https://vcenter01.syangsao.lab/sdk": dial tcp: lookup vcenter01.syangsao.lab on 100.64.0.10:53: no such host'
Error: exit status 1

Affected product modules (please put an X in all that apply)

• SIVT APIs
• SIVT UI
• SIVT CLI
• Docs

Expected behavior

Shared cluster installation should follow through, using the DNS server that was configured via the SIVT UI. Confirmed the DNS server on the SIVT host does find the vCenter address correctly. The same DNS server is used to confirm the AVI hostname during the initial cluster setup.

Steps to reproduce the bug

This seems to occur constantly during the shared cluster installation. Sometimes the shared cluster installation makes it through but then the same error occurs on the workload cluster installation next. Unsure on how to debug this and check why it is stating that the vCenter address is unreachable.

Version (include the SHA if the version is not obvious)

Environment where the bug was observed (vSphere+VMC, vSphere+DVS, vSphere+NSXt, etc)

vSphere+DVS+AVI

• SIVT version: 1.3
• vSphere version: 7.0.3 Update 3g
• vCenter version: 7.0.3 Update 3g
• Kubernetes version: (use kubectl version):

Client Version: version.Info{Major:"1", Minor:"22", GitVersion:"v1.22.9+vmware.1", GitCommit:"21eeb4527eefb360eb251addc358cea6997e8335", GitTreeState:"clean", BuildDate:"2022-05-04T00:18:36Z", GoVersion:"go1.16.15", Compiler:"gc", Platform:"linux/amd64"}

• Kubernetes installer & version:

• Cloud provider or hardware configuration: Dell

• OS (e.g. from /etc/os-release):

NAME="VMware Photon OS"
VERSION="3.0"
ID=photon
VERSION_ID=3.0
PRETTY_NAME="VMware Photon OS/Linux"
ANSI_COLOR="1;34"
HOME_URL="https://vmware.github.io/photon/"
BUG_REPORT_URL="https://github.com/vmware/photon/issues"

• Sonobuoy tarball (which contains * below)

Relevant Debug Output (Logs, manifests, etc)

SIVT host confirms DNS entry for the vCenter address is valid. Not sure why the installation fails and where to troubleshoot how it is doing the lookups

root@service13 [ ~ ]# ping vcenter01.syangsao.lab
PING vcenter01.syangsao.lab (192.168.40.14) 56(84) bytes of data.
64 bytes from vcenter01.syangsao.lab (192.168.40.14): icmp_seq=1 ttl=64 time=0.139 ms
64 bytes from vcenter01.syangsao.lab (192.168.40.14): icmp_seq=2 ttl=64 time=0.110 ms
^C
--- vcenter01.syangsao.lab ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 3ms
rtt min/avg/max/mdev = 0.110/0.124/0.139/0.018 ms

DNS lookup seems to be valid from the SIVT host.

root@service13 [ ~ ]# dig vcenter01.syangsao.lab

; <<>> DiG 9.16.27 <<>> vcenter01.syangsao.lab
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37332
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: a30569a4c5712f680100000062e300ee1f992de4a8ee1b4b (good)
;; QUESTION SECTION:
;vcenter01.syangsao.lab.		IN	A

;; ANSWER SECTION:
vcenter01.syangsao.lab.	604800	IN	A	192.168.40.14

;; Query time: 4 msec
;; SERVER: 192.168.40.2#53(192.168.40.2)
;; WHEN: Thu Jul 28 16:34:38 CDT 2022
;; MSG SIZE  rcvd: 95

Reverse lookup is valid.

root@service13 [ ~ ]# dig -x 192.168.40.14

; <<>> DiG 9.16.27 <<>> -x 192.168.40.14
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30348
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: a143c14aac8c21d50100000062e300fa89b24f03d95a48f9 (good)
;; QUESTION SECTION:
;14.40.168.192.in-addr.arpa.	IN	PTR

;; ANSWER SECTION:
14.40.168.192.in-addr.arpa. 604800 IN	PTR	vcenter01.syangsao.lab.

;; Query time: 4 msec
;; SERVER: 192.168.40.2#53(192.168.40.2)
;; WHEN: Thu Jul 28 16:34:50 CDT 2022
;; MSG SIZE  rcvd: 119

Local resolver is configured properly on SIVT host

root@service13 [ ~ ]# resolvectl |more
Global
       LLMNR setting: no
MulticastDNS setting: yes
  DNSOverTLS setting: opportunistic
      DNSSEC setting: no
    DNSSEC supported: no
  Current DNS Server: 192.168.40.2
         DNS Servers: 192.168.40.2
Fallback DNS Servers: 8.8.8.8
                      8.8.4.4
[...]

Arcas is looking for AVI VIP IP in the vSphere Env instead of its VM name

Bug description
I'm using the vSphere with VDS deployment -> [TKGm on vSphere backed by VDS]
Arcas is deploying the AVI controllers in the vSphere env.
Arcas is naming the VMs with the domain name provided in the yaml creation wizard.
When configuring the management cluster, Arcas is looking for a VM that has the VIP IP as name. << This is the bug.
Looking at the VMC deployment code, it should look at a VM that has the "Controller 1 fqdn" as name.

To solve it, I had to edit the checkVmPresent sub parameters. I replaced the "ip" field by "avi_fqdn"

src/vsphere/managementConfig/vsphere_management_config.py line 4056.

Replace :
vm_state = checkVmPresent(vcenter_ip, vcenter_username, password, ip)

With :
vm_state = checkVmPresent(vcenter_ip, vcenter_username, password, avi_fqdn)

Affected product modules (please put an X in all that apply)

• SIVT APIs
• SIVT UI
• SIVT CLI
• Docs

Expected behavior
Configuring AVI

Steps to reproduce the bug
Just deploy a TKGm backed by VDS, when configuring the AVI controller, you will have the issue.

Version (include the SHA if the version is not obvious)

root@bootstrap [ /opt/vmware/arcas ]# arcas --version
version: v2.2.0

Environment where the bug was observed (,vSpshere+DVS, etc)

• SIVT version: 2.2.0
• vCenter version: 7.0.3 (20845200)
• Kubernetes version: (use kubectl version): Major:"1", Minor:"25"
• Kubernetes installer & version: N/A
• Cloud provider or hardware configuration: N/A
• OS (e.g. from /etc/os-release):

NAME="VMware Photon OS"
VERSION="3.0"
ID=photon
VERSION_ID=3.0
PRETTY_NAME="VMware Photon OS/Linux"
ANSI_COLOR="1;34"
HOME_URL="https://vmware.github.io/photon/"
BUG_REPORT_URL="https://github.com/vmware/photon/issues"

• Sonobuoy tarball (which contains * below)

Relevant Debug Output (Logs, manifests, etc)

AWS - hard coded cluster name assumptions prevents terraform module input from taking hold

Bug description
changing cluster names inside ./aws/main.tf as instructed by the readme does not actually do what is intended.

cluster names are hard coded and not able to actually change. changing them results in failed deploys and unexpected errors

Expected behavior
clusters are deployed using intended names

Steps to reproduce the bug
change cluster names in main.tf

Version (include the SHA if the version is not obvious)
main

Environment where the bug was observed (vSphere+VMC, vSpshere+DVS, vSphere+NSXt, etc)
AWS

AWS - 'event not found' error when executing finish-install.sh on jumpbox

Bug description
following the readme, when executing the finish-install.sh on the jumpbox i receive an error
"-bash: !x: event not found"

Expected behavior
the script is executed

Steps to reproduce the bug
create infra, including jumpbox. ssh into box. follow readme and execute finish-install.sh

Version (include the SHA if the version is not obvious)
latest

Environment where the bug was observed (vSphere+VMC, vSpshere+DVS, vSphere+NSXt, etc)
aws

arcas file is empty?

Reference Architecture: TKO on vSphere backed by VDS

What Happened?

I tried to run the command described in the README:

arcas --env vsphere --file /tmp/arcas.json --avi_configuration --tkg_mgmt_configuration --shared_service_configuration --workload_preconfig --workload_deploy --deploy_extentions

but it does nothing because the arcas tool that the command above is using is an empty file:

root@photon-machine [ ~ ]# file $(which arcas)
/usr/bin/arcas: empty

What Was Expected?

For something to happen

How to Reproduce

1. Create an Arcas appliance from the OVA
2. SSH in
3. Run file $(which arcas)

Versions

Version: 1.2.0.50
Build: 19794220

AVI Vault link does not contain reference to 20.1.7 anymore

The instructions for obtaining Avi 20.1.7 says to navigate to vault page, however 20.1.7 is not there anymore. Perhaps direct user to find OVA at https://marketplace.cloud.vmware.com/services/details/nsx-advanced-load-balancer-1?slug=true.

'int is not iterable' when an invalid TMC token is provided

What happened?

I got the message above when I provided an incorrect TMC token with no additional information.

How to reproduce

1. Start the Service Installer UI.
2. Provide a TMC refresh token when prompted that is invalid

What should happen?

The UI should tell me that the token is invalid, or an error message if one is provided.

What actually happens?

int is not iterable

Additional notes

AWS - TMC registration errors on mgmt cluster

Bug description
followed readme, and the registration didn't happen.

figured out the env variable referenced in the readme is incorrect.

once variable was fixed, i was able to register successfully on the initial attempt.

If i cleaned up my clusters (./tkg-install/clean-up.sh) and re-ran the finish-script to redo, TMC would error and not finish the install

You can now access the cluster by running 'kubectl config use-context arobert-default-mgmt-admin@arobert-default-mgmt'
i $TMC_API_TOKEN is set 
√ Successfully created context tkgaws-automation, to manage your contexts run `tmc system context -h`
√ management cluster "arobert-default-mgmt" created successfully
i Follow the steps below to complete registration: Run `kubectl apply -f tmc-mgmt.yaml` to register the cluster 
The connection to the server localhost:8080 was refused - did you specify the right host or port?
Switched to context "arobert-default-mgmt-admin@arobert-default-mgmt".

key part being

The connection to the server localhost:8080 was refused - did you specify the right host or port?

which leaves the cluster showing up pending in TMC.

Expected behavior
TMC registration of all clusters on all runs of script

Steps to reproduce the bug

Version (include the SHA if the version is not obvious)
latest

Environment where the bug was observed (vSphere+VMC, vSpshere+DVS, vSphere+NSXt, etc)
AWS

Relevant Debug Output (Logs, manifests, etc)

Avi DNS validation fails if using a different DNS server than system

What happened?

The Arcas UI fails to validate Avi FQDNs if the records are not present on the system's DNS server regardless of whether a custom DNS server is provided or not.

How to reproduce

1. install dnsmasq on the SIVT appliance (yum -y install dnsmasq)
2. Add the following to /etc/dnsmasq.conf:

listen-address=127.0.0.1,::1,10.220.3.251
server=8.8.8.8
server=8.8.4.4
address=/avi-01.tkg.local/172.16.10.10
address=/avi-02.tkg.local/172.16.10.28
address=/avi-03.tkg.local/172.16.10.29
address=/avi-cluster.tkg.local/172.16.10.30
interface=eth0
expand-hosts
domain=tkg.local

3. Add this line to /etc/systemd/resolved.conf:

DNSStubListener=no

4. Restart dnsmasq and systemd-resolved: systemctl restart systemd-resolved dnsmasq
5. Confirm that avi-01.tkg.local is resolvable locally:

dig @127.0.0.1 avi-01.tkg.local +short
172.16.10.10

6. Confirm that avi-01.tkg.local is NOT resolvable by your system's resolver:

dig avi-01.tkg.local +short

7. Start the Service Installer UI.
8. Set the DNS server to 127.0.0.1
9. Add Avi records as shown in the dnsmasq.conf file above

What should happen?

Validation should pass

What actually happens?

Validation hangs for a few seconds then fails.

Additional notes

• This is happening because you need to append an @ before your DNS server in the line here.

Diagram shows 2 Primary Workload Networks

(This is used to request new product features or an enhancement to existing features)

The reference diagram shows 2 Primary Workload Networks

There should be only one Primary Workload Network. The diagram shows 2 of them. Please relabel the second workload network as a Secondary network. URL containing the diagram is pasted below.

Additional context
https://github.com/vmware-tanzu/service-installer-for-vmware-tanzu/blob/main/docs/product/release/vSphere%20-%20Backed%20by%20VDS/TKGs/TKOonVsphereVDStkgs.md

Vote on this issue!

This is an invitation to the SIVT community to vote on issues, you can see the project's top voted issues listed here.
Use the "reaction smiley face" up to the right of this comment to vote.

• 👍 for "The project would be better with this feature added"
• 👎 for "This feature will not enhance the project in a meaningful way"

wrong AVI ova list in the UI

Bug description
"AVI OVA IMAGE" under "Iaas Provider" in TKGm on vsphere VDS UI has wrong list of OVA Image
it listed similar to "ob-18592554-photon-3-k8s-v1.21.2---vmware.1-tkg.1.ee25d55"

Expected behavior
it should list up ova list from vcenter template.

• avi-controller-21.1.2-9124

Steps to reproduce the bug

1. upload avi ova to vcenter as template.
2. provision service installer ova.
3. http://SERVICE_INSTALER:8888
4. TKGm on vsphere VDS
5. go to "AVI OVA IMAGE" under "Iaas Provider"

Version (include the SHA if the version is not obvious)
N/A

Environment where the bug was observed (vSphere+VMC, vSpshere+DVS, vSphere+NSXt, etc)

• Service Installer for VMware Tanzu version:
• vSpshere version: 7.0.3
• vCenter version: 7.0.3
• Kubernetes version: (use kubectl version):
• Kubernetes installer & version:
• Cloud provider or hardware configuration:
• OS (e.g. from /etc/os-release):
• Sonobuoy tarball (which contains * below)

Relevant Debug Output (Logs, manifests, etc)

"Deploying VMware Tanzu for Kubernetes Operations on vSphere with vSphere Distributed Switch Using Service Installer for VMware Tanzu" page have an internal VMware link

Bug description
https://github.com/vmware-tanzu/service-installer-for-vmware-tanzu/blob/main/docs/product/release/vSphere%20-%20Backed%20by%20VDS/TKGm/TKOonVsphereVDStkg.md#deploying-vmware-tanzu-for-kubernetes-operations-on-vsphere-with-vsphere-distributed-switch-using-service-installer-for-vmware-tanzu

Above page have an internal VMware vault link reference under Pre-requirement section below
Upload the NSX Advanced Load Balancer Controller in Content Library:
Download the NSX Advanced Load Balancer 20.1.7 OVA from [VMware Vault](https://vault.vmware.com/group/nsx/avi-networks-technical-resources).

Expected behavior
We should have an external link as external user can not access them.

Steps to reproduce the bug

• Click on the link below
  https://github.com/vmware-tanzu/service-installer-for-vmware-tanzu/blob/main/docs/product/release/vSphere%20-%20Backed%20by%20NSX-T/tkoVsphereNSXT.md#deploying-vmware-tanzu-for-kubernetes-operations-on-vsphere-with-nsx-t-using-service-installer-for-vmware-tanzu
• Go to Pre-req section and look for text "Download the NSX Advanced Load Balancer 20.1.7 OVA from VMware Vault."

Version (include the SHA if the version is not obvious)
1.1.1

Environment where the bug was observed (vSphere+VMC, vSpshere+DVS, vSphere+NSXt, etc)
NA

• Service Installer for VMware Tanzu version: 1.1.1
• vSpshere version: NA
• vCenter version: NA
• Kubernetes version: (use kubectl version):
• Kubernetes installer & version:
• Cloud provider or hardware configuration:
• OS (e.g. from /etc/os-release):
• Sonobuoy tarball (which contains * below)

Relevant Debug Output (Logs, manifests, etc)

"https://github.com/vmware-tanzu/service-installer-for-vmware-tanzu/blob/main/docs/product/release/vSphere%20-%20Backed%20by%20NSX-T/tkoVsphereNSXT.md#deploying-vmware-tanzu-for-kubernetes-operations-on-vsphere-with-nsx-t-using-service-installer-for-vmware-tanzu" page have an incorrect info

Bug description
Picture shows that the shared services cluster should be on a different network segment but under pre-requirement section (point 1), says that shared services cluster should be on the same management network.

Expected behavior
Pre-requirement should be updated to reflect the picture networking.

Steps to reproduce the bug

• Open page "https://github.com/vmware-tanzu/service-installer-for-vmware-tanzu/blob/main/docs/product/release/vSphere%20-%20Backed%20by%20NSX-T/tkoVsphereNSXT.md#deploying-vmware-tanzu-for-kubernetes-operations-on-vsphere-with-nsx-t-using-service-installer-for-vmware-tanzu" and look for point 1 under pre-requirements

Version (include the SHA if the version is not obvious)
SIVT

Environment where the bug was observed (vSphere+VMC, vSpshere+DVS, vSphere+NSXt, etc)
vSphere with NSXT

• Service Installer for VMware Tanzu version: 1.1.1
• vSpshere version: Na
• vCenter version: NA
• Kubernetes version: (use kubectl version):
• Kubernetes installer & version:
• Cloud provider or hardware configuration:
• OS (e.g. from /etc/os-release):
• Sonobuoy tarball (which contains * below)

Relevant Debug Output (Logs, manifests, etc)

AWS - Readme - has incorrect terraform variables mentioned

Bug description
There are terraform variables mentioned that do not exist in the code

• to_token
• to_url

There are terraform variables mentioned that are not correct

• jb_key

Expected behavior
following the readme does not error

Steps to reproduce the bug
follow readme

Version (include the SHA if the version is not obvious)
main

Environment where the bug was observed (vSphere+VMC, vSpshere+DVS, vSphere+NSXt, etc)
AWS

AWS - 3rd cluster created, but not mentioned...by design or needs adjusted?

Referencing the following:
The goals:
https://github.com/vmware-tanzu/service-installer-for-vmware-tanzu/blob/main/aws/README.md?plain=1#L9-L13

the way the repo is setup

In the main.tf, we create 1 mgmt VPC with a cluster in it and 1 workload VPC with a cluster in it
https://github.com/vmware-tanzu/service-installer-for-vmware-tanzu/blob/main/aws/main.tf#L51-L77

these get created as expected due mgmt cluster explicitly being created and looping over the workload cluster configs in the script.
https://github.com/vmware-tanzu/service-installer-for-vmware-tanzu/blob/main/aws/tkg_vpc/script.sh#L181

the question i have is on this line in the loop when the mgmt config is found.

if [[ "$NO_YAML_NAME" == "vpc-config-mgmt" ]]; then
        setup_cluster $i tkg-wl-aws

we have already created the management cluster based on vpc-config-mgmt.yaml.

this line then creates a 2nd workload cluster with a hard coded name using the mgmt cluster's configuration, which puts the workload cluster in the mgmt cluster's vpc, vs the prior created workload vpc.

My question comes down to the intent and a solve:

1. Did i miss a documented step or ref arch expectation?
2. Should that line be replaced with an echo or similar no-op to remove the extra cluster creation? That cluster currently has a hard coded name that is not configurable without editing the script prior to running the terraform apply.
3. Does the repo need updated to allow creating a cluster and not a new VPC? (Allowing a workload cluster defined for an existing VPC)
4. both 2+3?
5. Does this behavior need documented only?
6. ??

I feel number 2 is appropriate in the near term as it isn't much work and maybe 3 is a future feature enhancement?

what are your thoughts?

SIVT does not fetch vSphere Datastore full path correctly

Bug description

IHAC using Storage Folders in vCenter, and SIVT does not cope with folder path, when configuring TKGm (jinja templates for the key VSPHERE_DATASTORE)

I found 2 places in the code where this is done while testing and this fixed my issue, it's a harcoded fix obviously we need to fetch this properly, and store it.

https://github.com/vmware-tanzu/service-installer-for-vmware-tanzu/blob/main/src/vsphere/managementConfig/vsphere_management_config.py#L2067

https://github.com/vmware-tanzu/service-installer-for-vmware-tanzu/blob/main/src/vsphere/managementConfig/vsphere_management_config.py#L2212

my dirty fix to unstuck us

datastore_path = "/" + datacenter + "/datastore/vSAN Storages/" + datastoreName

Affected product modules (please put an X in all that apply)

• SIVT APIs
• SIVT UI
• SIVT CLI
• Docs

Expected behavior

When using the UI, and being at the vCenter Connection step/credentials:

• It will load all the required information, but for vSphere Datastore it will only keep the datastore name assuming it's at the root level in vCenter.

Steps to reproduce the bug

• Put a vSphere Datastore in any folder
• arcas deployment
• arcas should deploy AVI Controller correctly
• arcas will fail deploying TKGm vSphere VM with an error stating it cannot find the Datastore.

Version (include the SHA if the version is not obvious)

NA

Environment where the bug was observed (vSphere+VMC, vSphere+DVS, vSphere+NSXt, etc)

vSphere+DVS

• SIVT version: 1.2.0
• vSphere version: 6.7u3
• vCenter version: 6.7u3
• Kubernetes version: (use kubectl version): from SIVT-1.2.0
• Kubernetes installer & version: from SIVT-1.2.0
• Cloud provider or hardware configuration: NA
• OS (e.g. from /etc/os-release): from SIVT-1.2.0
• Sonobuoy tarball (which contains * below)

Relevant Debug Output (Logs, manifests, etc)

Description of Network (port groups) does not align with diagram

Please fix the text description of the port groups so that they align with the names in the Diagram.
I notice too that the data network seems to be missing in the diagram. Or maybe it's named differently than I expect.

Additional context
https://github.com/vmware-tanzu/service-installer-for-vmware-tanzu/blob/main/docs/product/release/vSphere%20-%20Backed%20by%20VDS/TKGs/TKOonVsphereVDStkgs.md

Vote on this issue!

This is an invitation to the SIVT community to vote on issues, you can see the project's top voted issues listed here.
Use the "reaction smiley face" up to the right of this comment to vote.

• 👍 for "The project would be better with this feature added"
• 👎 for "This feature will not enhance the project in a meaningful way"

Add additional context needed in TKGs deployment guide explaining two-phase deploy method (WCP then NS & workload cluster)

Describe the feature request

The doc does not add any context explaining why the process is broken into the two phases:

• Enable Workload Control Plane
• Deploy Supervisor Namespace and Workload Clusters

Doc should include rationale for:

• why two phases are better than one single end-to-end deployment model.
• example scenario where you may not want to use SIVT for the second phase

Describe alternatives you've considered

Affected product area (please put an X in all that apply)

• APIs
• UIAddons
• CLI
• Docs

Additional context

Vote on this issue!

This is an invitation to the SIVT community to vote on issues, you can see the project's top voted issues listed here.
Use the "reaction smiley face" up to the right of this comment to vote.

• 👍 for "The project would be better with this feature added"
• 👎 for "This feature will not enhance the project in a meaningful way"

error while downloading with the Tanzu Service Installer 2.4.0 the avi 22.1.4 from the marketplace

INFO :Retrieved solution name ('nsx-advanced-load-balancer-1', 'SUCCESS') from MarketPlace...
INFO :Downloading AVI controller from MarketPlace...
INFO :Downloading AVI controller from MarketPlace...
INFO :Retrieved product ID 8c0452e8-8a3f-4319-be10-cd392a837bc7 from MarketPlace...
INFO :Error in downloading AVI controller from MarketPlace...
AVI configuration failed {'responseType': 'ERROR', 'msg': 'Error in downloading AVI controller from MarketPlace', 'STATUS_CODE': 500}
@sunshetty