failure of the deployment report generation with Viya stable 2022.11/K8s 1.23.10
raphaelpoumarede opened this issue · 7 comments
Hello
I have a working deployed stable 2022.11 Viya (running on K8s 1.23.10 with nginx 1.19.9).
The python script fails with :
[cloud-user@pdcesx03181 viya4-ark]$ python3 viya-ark.py deployment-report --namespace gelenv
Generating deployment report......................DONE
Traceback (most recent call last):
File "viya-ark.py", line 139, in <module>
main(sys.argv[1:])
File "viya-ark.py", line 77, in main
command.run(argv[1:])
File "/home/cloud-user/viya4-ark/deployment_report/deployment_report.py", line 48, in run
main(argv)
File "/home/cloud-user/viya4-ark/deployment_report/deployment_report.py", line 139, in main
include_pod_log_snips=args.include_pod_log_snips)
File "/home/cloud-user/viya4-ark/deployment_report/model/viya_deployment_report.py", line 294, in gather_details
ingress_version = ingress_util.get_ingress_version(kubectl)
File "/home/cloud-user/viya4-ark/deployment_report/model/utils/ingress_util.py", line 124, in get_ingress_version
" --field-selector=status.phase==Running" + \
TypeError: must be str, not NoneType
`
@raphaelpoumarede can you make sure you're using the latest code pulled from the default branch, and also provide the following info:
- What is the cloud provider?
- What is the python 3 version? (
python3 -V
)
I use Viya ARK 1.9.0
I'm testing in an opensource K8s env (Rancher)
Python 3.6.8
It was working with previous Viya ARK and K8s versions.
Also when I tried with the -i option, then I get a message that "the nginx namespace can't be found". However I can see it when I list my namespaces with the "kubectl get ns" command.
[cloud-user@pdcesx03181 viya4-ark]$ python3 viya-ark.py deployment-report --ingress-namespace "nginx" -n gelenv
ERROR: The ingress namespace [nginx] was not found in the target environment.
[cloud-user@pdcesx03181 viya4-ark]$ python3 viya-ark.py deployment-report --ingress-namespace nginx -n gelenv
ERROR: The ingress namespace [nginx] was not found in the target environment.
Same result when I'm using the "master" branch instead of 1.9.0
I believe there are two issues that have been found here, both related to PR #174 and PR #175
-
The first issue appears to be due to the
ingress_ns
variable not being set because the expected default namespace name for nginx is "ingress-nginx" (https://github.com/sassoftware/viya4-ark/pull/174/files#diff-a0de9a3ab73c756f11b7ae297c7bedb67b6665be0090d7903ce0e69c4321835bR32)- https://github.com/sassoftware/viya4-ark/pull/174/files#diff-9168b8e158aece114916d22074bcba957da8a0985a18e90561ad887fff9f3d23R97
- A subsequent commit changed to move
getpod_cmd
outside of the if/elif, where it strings together and causes the exception whenkubectl.ingress_ns
is None and being appended to a string - Resolving this issue may involve checking if
kubectl.ingress_ns
is None and safely skipping the code that pulls Ingress info into the report, only providing info that the Ingress was unable to be detected.
-
The second issue for when the actual ingress namespace was provided
--ingress-namespace nginx
, this is due to a regression in an existing function where running kubectl, where it will return a message stub in certain conditions:- https://github.com/sassoftware/viya4-ark/pull/174/files#diff-9168b8e158aece114916d22074bcba957da8a0985a18e90561ad887fff9f3d23R180
- However, the presence of any message length >0 returned by the
kubectl.do
function causes the error shown - Since the call to
self.do
involvedignore_errors=True
andwarning=False
it is unclear why the command failed in the first place, or if its just incorrect logic that got it into that conditional that setstdout = _DO_MSG_
.
As a workaround, one could make the following change in viya_ark_library/k8s/sas_k8s_ingress.py locally after downloading the latest code to match the nginx ingress namespace "nginx" when it differs from the default expected "ingress-nginx":
NS_NGINX = "nginx"
And then run without the --ingress-namespace
override
python3 viya-ark.py deployment-report --namespace gelenv
Thanks to report the issue. I'll check into it.
This issue addressed in Release 1.9.1