Closed simran3695 closed 4 years ago
@ayasda2003 Please let us know once this feature is available
@simran3695 we are completing the TLS part of the chart usage however still looking into solution(s) in the VLN deployment. Will give updates from time-to-time. Thank you!
Hi Team,
This was one of the agents that I tried enabling TLS plugin for , using the existing helm. It mentions agent+tls is invalid and nothing got created in argocd
PFA the screenshots of requirements.yml and the error that we got for the same.
@AakritiTalwar12 thanks for the feedback. This is expected exception for the time being, we will roll out the TLS update following introducing a security contribution model.
Some update.
The current VLAN plugin was designed for sudoer group to access loopback/netlink interface, available in a container/vm level.
To enable such access to the network interfaces at a k8s cluster would require a special privilege to work with the APIs, of which cannot cover most standalone deployments other than with k8s.
A unified solution is being proposed at the fundamental that is to address the need beyond in k8s. @sheshankgujjari @simran3695 @AakritiTalwar12
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
Hi @ayasuda2OO3 .............Is the vlan helm pkg ready for consumption. Please let me know ill proceed with the enablement and testing of the same on the CI Cluster
@simran3695 there are two approaches for solving the VLAN.
1) modify the loopback with the host file in the spec during the build time. 2) deploy the plugin in the spec also during the build time.
Whilst our approach subsequent to 2) is WIP, 1) is seemingly a cheaper solution. However, both will need to access the spec which may warrant concerns. Please refer to this message in your communication with the stakeholders. @sheshankgujjari
@ayasuda2OO3 Even as per the approach 1, and diagram shared by Prasad we do need EC Client with VLAN helm available as well. Please correct me.
@ayasuda2OO3 Even as per the approach 1, and diagram shared by Prasad we do need EC Client with VLAN helm available as well. Please correct me.
Yes, we will document the VLAN port configuration in the client pod.
Quick update- we are having a glitch in a OCI spec build. Will finalise the helm pkg soon after the fix. @simran3695 @sheshankgujjari @palokam
@ayasuda2OO3 - there was a confusion as there was no comments on issues, @simran3695 and @sheshank are not aware of the PR waiting for them to approve - please alert them next time
@ayasuda2OO3 - there was a confusion as there was no comments on issues, @simran3695 and @sheshank are not aware of the PR waiting for them to approve - please alert them next time
Sorry for the confusions. You may find the comment in this tracker 3 days behind this PR update. However, reviewers or one like yourself @palokam being tagged to this forum will receive up-to-date activity/comments.
FYI the PR had been accepted and close. The helm pkg seems to work as expected based on the feedback @simran3695 @sheshankgujjari
@ayasuda2OO3 We have currently analysed after e2e testing on existing EC VLAN on EKS, that the EC Service name in the /etc/hosts is not able to resolve the target ip as it does not find that ip existing on the cluster and thus the connectivity breaks.
As per the new VLAN architecture we require EC pod to be running as a Sidecar with the TC Application POD. And now the /etc/hosts of the TC POD will have hostaliases which will have hostname as "localhost" which will be resolving all the target (Oracle database) IP's.
@ayasuda2OO3 We have currently analysed after e2e testing on existing EC VLAN on EKS, that the EC Service name in the /etc/hosts is not able to resolve the target ip as it does not find that ip existing on the cluster and thus the connectivity breaks.
As per the new VLAN architecture we require EC pod to be running as a Sidecar with the TC Application POD. And now the /etc/hosts of the TC POD will have hostaliases which will have hostname as "localhost" which will be resolving all the target (Oracle database) IP's.
The solution assumes the components all deployed in same namespace. @palokam IPs resolving from the service is not visible to the pod which implies the EC service does not live with the pod in the same cluster. Can you further verify if this is the case. @simran3695
@ayasuda2OO3 TC Application and EC both are running on the CI Cluster but they are running on their own namespaces.
@ayasuda2OO3 TC Application and EC both are running on the CI Cluster but they are running on their own namespaces.
It seems the scope of the solution can only be covered by the multi-container approach. PR in progress. @simran3695 @sheshankgujjari @palokam
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
PR test remains in progress. Removed stale status.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
Tests in progress. Removed stale status.
@ayasuda2OO3 We are now able to execute EC Vlan, hence closing this issue. Thankyou for all the help andguidance throughout as always.
@ayasda2003 We would like to understand how the EC with plugins are going to work as we are willing to enable TLS and VLAN EC Setup.
The TLS Setup will require endpoint certificate installation so will that be taken care though Helm or we need to have a manual placing of these certificates.
Also where will the plugins file be accomodated.
Please help us understand how th EC with plugins will be layed out.