Dremio Cloud unable to start engine instances

Still seeing the same issue with the instance auto-terminating and logs saying “Nessie IP (gw.dremio.cloud) is not a valid IP”. I will message you my new organization ID if you’d like to look at it directly.

Hi @chough ,

The error “opt/dremio/bin/vendor_specific.sh: line 25: local: `=': not a valid identifier” was fixed and I no longer see that in system logs, do you see that part still?

“The Nessie IP (gw.dremio.cloud) is not a valid IP” message seems to show at the end every EC2 system log on my end, however my connection diagnostics succeeds and indicates that my connection to gw.dremio.cloud was indeed successful (on both private and public set ups).

Is it possible you could private message me the full system log for that EC2 instance? I’d like to see if you are getting the “Dremio Node Diagnostics” section. Could you also share how your route tables and security groups are configured?

For security groups, inbound rules for ports 443 and 45678 are required:
https://docs.dremio.com/cloud/appendix/aws-resources/create-security-group/

Thanks,

No, I’m not seeing the “opt/dremio/bin/vendor_specific.sh: line 25: local: `=': not a valid identifier” error, anymore, so it appears that is resolved.

I have private messaged you the system log, as well as my security group rules and route table routes. I have confirmed that the security group has an ingress rule for all traffic (which includes 443 and 45678) from itself as shown in the doc you provided.

Notably, I set one organization up using the “manually configure” method, in which I specified the necessary S3 bucket, IAM role ARNs, VPC, subnets, security group IDs, and VPC Endpoint PrivateLink ID which is the one in which the instance is still self-terminating and is the organization which I have PM’d you the ID of. In addition to that, I setup another organization as a test using CloudFormation instead of the manual method and while the configurations seem essentially identical between the two, the engine EC2 Instance started by the CloudFormation-method org does not self-terminate. Both orgs however are still unable to successfully execute a query, but it seems for different reasons.