You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If an error occurs (outside of replacing parameters) a generic error is printed
[root@ip-10-10-11-100 [OpenFlight Hub] ~]# flight cloud aws deploy testnode01 /opt/flight/opt/cloud/examples/aws/node.yaml -p 'securitygroup=SOMETHING network1SubnetID=STUFF keyname=AKEY'
Deploying: /opt/flight/opt/cloud/var/aws/clusters/default/var/deployments/testnode01.yaml
[┌] Deploying resources... Done
error: An error has occured. Please see for further details:
`flight cloud aws list deployments --verbose`.
With the expanded error (in this case - connection timing out reaching AWS API endpoints)
Error
NOTE: This is aws's raw error message
Refer to their documentation for further details
execution expired
Thoughts/Improvements
The deploy command could give the user a bit more to identify where the issue arises. The thinking here is that, if the command fails due to an error with the platform command, that this is outside of flight-cloud's scope.
In the example given above, the error wouldn't necessarily need to identify what kind of AWS error but could give something a bit more useful on the deploy command:
An error occurred with the aws tool - check your internet connection and network setup
Depending on how AWS and Azure throws errors we may be able to identify what generally has gone wrong. Whether it be an issue with the template (post flight-cloud replacements), with the connection to the cloud provider or any other general categories of error message.
The text was updated successfully, but these errors were encountered:
Current Errors
If an error occurs (outside of replacing parameters) a generic error is printed
With the expanded error (in this case - connection timing out reaching AWS API endpoints)
Thoughts/Improvements
The deploy command could give the user a bit more to identify where the issue arises. The thinking here is that, if the command fails due to an error with the platform command, that this is outside of flight-cloud's scope.
In the example given above, the error wouldn't necessarily need to identify what kind of AWS error but could give something a bit more useful on the deploy command:
Depending on how AWS and Azure throws errors we may be able to identify what generally has gone wrong. Whether it be an issue with the template (post flight-cloud replacements), with the connection to the cloud provider or any other general categories of error message.
The text was updated successfully, but these errors were encountered: