oracle / oracle/oracle-database-operator
NameError: global name 'random' is not defined sharded deployement
Nobody has claimed this yet.
- Dominant language
- Go
- Stars
- 192
- Forks
- 69
- Avg merge
- 16h 13m
- Merged PRs (30d)
- 1
Description
Hello
I m trying to deploy a sharded configuration
i see the below error to the shards
p', 'OLDPWD': '/home/oracle', 'ORACLE_HOME': '/opt/oracle/product/21c/dbhome_1', 'KUBERNETES_PORT_12250_TCP_PROTO': 'tcp', 'PWD': '/opt/oracle/scripts/sharding'}
01/17/2023 12:31:31 PM INFO: orafactory.py - get_ora_objs :Checking the OP_TYPE and Version to begin the installation
01/17/2023 12:31:31 PM INFO: orafactory.py - get_ora_objs :OP_TYPE variable is set to primaryshard.
01/17/2023 12:31:31 PM INFO: orafactory.py - get_ora_objs :Creating and calling instance to setup primary shard
01/17/2023 12:31:31 PM INFO: oramachine.py - setup :Machine setup completed sucessfully!
01/17/2023 12:31:31 PM INFO: orapshard.py - ohome_check :ORACLE_HOME variable is set. Check Passed!
01/17/2023 12:31:31 PM INFO: orapshard.py - ohome_check :ORACLE_HOME /opt/oracle/product/21c/dbhome_1 dirctory exist. Directory Check passed!
01/17/2023 12:31:31 PM WARNING: orapshard.py - passwd_check :SECRET_VOLUME passed as an env variable and set to /mnt/secrets
01/17/2023 12:31:31 PM WARNING: orapshard.py - passwd_check :COMMON_OS_PWD_FILE passed as an env variable and set to common_os_pwdfile.enc
01/17/2023 12:31:31 PM WARNING: orapshard.py - passwd_check :PWD_KEY passed as an env variable and set to pwd.key
Traceback (most recent call last):
File "main.py", line 150, in <module>
main()
File "main.py", line 146, in main
obj.setup()
File "/opt/oracle/scripts/sharding/orapshard.py", line 87, in setup
self.db_checks()
File "/opt/oracle/scripts/sharding/orapshard.py", line 125, in db_checks
self.passwd_check()
File "/opt/oracle/scripts/sharding/orapshard.py", line 198, in passwd_check
password = "".join(random.sample(s,passlen ))
NameError: global name 'random' is not defined
The databases are up
the command is not reporting any external-ip is this an error ?
I have deployed the sharding config to a 3 nodes OCI cluster , with public endpoints
kubectl get all -n operator-sharding
NAME READY STATUS RESTARTS AGE
pod/catalog-0 1/1 Running 0 27m
pod/gsm1-0 1/1 Running 1 27m
pod/gsm2-0 1/1 Running 0 27m
pod/shard1-0 1/1 Running 0 27m
pod/shard2-0 1/1 Running 0 27m
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/catalog ClusterIP None <none> 1521/TCP,6234/TCP,6123/TCP,8080/TCP 27m
service/gsm1 ClusterIP None <none> 1522/TCP,6234/TCP,6123/TCP,8080/TCP 27m
service/gsm2 ClusterIP None <none> 1522/TCP,6234/TCP,6123/TCP,8080/TCP 27m
service/shard1 ClusterIP None <none> 1521/TCP,6234/TCP,6123/TCP,8080/TCP 27m
service/shard2 ClusterIP None <none> 1521/TCP,6234/TCP,6123/TCP,8080/TCP 27m
NAME READY AGE
statefulset.apps/catalog 1/1 27m
statefulset.apps/gsm1 1/1 27m
statefulset.apps/gsm2 1/1 27m
statefulset.apps/shard1 1/1 27m
statefulset.apps/shard2 1/1 27m
kubectl get nodes -o wide
NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME
10.0.10.106 Ready node 49m v1.25.4 10.0.10.106 <none> Oracle Linux Server 8.6 5.4.17-2136.314.6.2.el8uek.x86_64 cri-o://1.25.1-111.el8
10.0.10.176 Ready node 49m v1.25.4 10.0.10.176 <none> Oracle Linux Server 8.6 5.4.17-2136.314.6.2.el8uek.x86_64 cri-o://1.25.1-111.el8
10.0.10.76 Ready node 49m v1.25.4 10.0.10.76 <none> Oracle Linux Server 8.6 5.4.17-2136.314.6.2.el8uek.x86_64 cri-o://1.25.1-111.el8
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start in orapshard.py at passwd_check(), called from db_checks() during shard setup, and inspect the module imports and the random.sample call shown in the traceback. Reproduce the sharded deployment and verify that setup progresses past password generation without the NameError.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- kubernetes, python
- Domain
- cloud, databases, devops
- Issue type
- Bug
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Activity status
- Stale
- Clarity
- Clearly specified
- Newbie friendliness
- 35/100