How are you calling the yaml files here ?

[baba-dude]

The terraform script looks fine ..! Could you please advise how you are triggering the yaml files ?

[erdincka]

yaml files are used for cloud-init, it is uploaded to each host as custom data via terraform:
custom_data = file(pathexpand(var.cloud_init_file))

It is then automatically run by cloud-init in initial boot.

[baba-dude]

Hi @erdincka ,

Thanks for the response. We are trying to use a binary file which is in one of our AWS storage account.
https://bluedata-installer.s3.amazonaws.com/bluedata-epic-entdoc-minimal-release-5.0-3006.bin

the curl command in the yaml file doesn't download the above file. but manually it works fine. Coud you please advise if the file we are using is the right one or not..!?

[erdincka]

This file is not for free distribution and link should be removed. Please contact to BlueData or HPE team to get access to installation bits and licenses.

[erdincka]

@baba-dude, sorry for misunderstanding your question. As far as I know, this binary file is no longer open to public access. So you would need to sign before the download. Within cloud-init, it might be possible to install aws cli and use presign command.
Since I am not familiar with AWS concepts here, I cannot help to test it. I recommend checking bluedata-demo-env-aws-terraform repository to see the steps before downloading that file.

This might help: https://github.com/bluedata-community/bluedata-demo-env-aws-terraform/blob/master/scripts/bluedata_install.sh
EPIC_DL_URL="$(aws s3 presign ${EPIC_DL_URL_PRESIGN_OPTIONS} ${EPIC_DL_URL})"

[baba-dude]

Hi @erdincka ,
Thanks for the response. I got the bluedata install files now. ut however, these yaml files are not being called here. All the azure resources are deployed and infra is ready, but these yaml files not being called. Are there any additional steps do i need to do ??

[erdincka]

You can check cloud-init logs to see what is going on. It might take some long time as with recent updates there are hundreds of package updates that need to be completed before running these commands. It might be causing race condition. If you can access the controller, why not run package updates and installs manually and continue processing the script? Alternatively, you can try newer tool from here: https://github.com/hpe-container-platform-community/demo-env-azure-notebook

[baba-dude]

Hi @erdincka ,
Thanks for the suggestion , will definitely try this new tool. I have deployed the the resources and installed using a shell script. However the Controller to gateway and Controller to WorkerNodes communication is not working. I have double checked all the possible ways here like sshd_config, network_security_group and etc.! But even ssh is not working here. Have you even faced this kind of issue in your testing.?

[erdincka]

This might happen for various reasons (all happened during testing):

• cloud-init hasn't finished running (especially "package_upgrade: true" takes a lot of time, and you may get scripts run before it is completed)
• cloud-init might reboot while you were running scripts
• script fails for an unhandled error condition
• cloud-init is not properly configured in the image (as of testing, CI images were still in beta at Azure, so things might change and break when there are updates in the images provided by Azure)

I assume you updated yaml files with your public and private key information:
You need to replace this with your public key content (id_rsa.pub) in both cloud-init.yaml and cloud-init-ctr.yaml files (before deployment):
- ssh-rsa ...
You need to replace the content part with your private key content (id_rsa) in cloud-init-ctr.yaml file:
`write_files:

• content: |

  Paste your private key to enable passwordless login (will be cleared once local credentials are configured)`

Please check if you have /home/bluedata/private.key file created with your user private key information (taken from id_rsa of the user running the terraform). If you don't, assuming cloud-init updated "ssh-authorized-keys" file in gateway and worker nodes, you can copy your private key (actually this is not recommended for security reasons, and this pattern was replaced in new repository, but not patched here).
If you copy the content of your id_rsa to controller (to private.key file for example), then you should be able to connect gateway and worker nodes using:
ssh -i private.key worker-ip

Hope this solves connectivity issues to workers and gateway.

[erdincka]

Hi @baba-dude,
Is your issue resolved with that information? Can we close this?
Thanks.