That was an issue on our end, this is fixed now and I can confirm it works. Please try again!
Hi @johan,
I’ve just tried to setup an new environment and am getting this error for v2.15.4 running Go 1.14.3. It looks like this deprecated in favour of v2.15.5 running Go 1.14.4.
“No Solution Stack named ‘64bit Amazon Linux 2018.03 v2.15.4 running Go 1.14.3’ found”
Can you advise when the CF stack will be updated please?
TIA!
Matt…
Thanks, this is now fixed and you can get the CFT in about 10 minutes
Greetings, I guess there is a slight mismatch in CF stack for ThingSyncInterval.
SyncIntervalMap:
“30s”:
Ticks: 3000000000
“1m”:
Ticks: 6000000000
“10m”:
Ticks: 60000000000
“30m”:
Ticks: 180000000000
“1h”:
Ticks: 360000000000
While the section above states
ThingSyncInterval:
Type: String
Description: "Interval for AWS IoT things synchronization"
Default: "10m"
AllowedValues:
- "5m"
- "10m"
- "30m"
- "1h"
Hence you can't do 5m option, that is supposed to be 30sec I would say.
PavelHi Johan,
You are probably fed up with updating this template, but I think it may be out of date again. Please can you check.
Yes, indeed. But no problem, I updated the template once again. Expect ~10 minutes CI.
If things fail, let me know, as I now switched to 64bit Amazon Linux 2 v3.1.0 running Go 1 (which seems like a more stable version number to use).
Hello @johan I think it’s out of date again I’m getting the error ‘‘No Solution Stack named ‘64bit Amazon Linux 2018.03 v2.15.5 running Go 1.14.4’ found. (Service: AWSElasticBeanstalk; Status Code: 400; Error Code: InvalidParameterValue; )’’
I think now its updated to " *64bit Amazon Linux 2018.03 v2.15.6 running Go 1.14.5"
It looks like the last update didn’t succeed. It should now be resolved. Please retry and report back if it doesn’t work.
Looks like it isn’t updated to proper version. Current template shows the version as 64bit Amazon Linux 2 v3.1.2 running Go 1…Can you please update the template. Thanks in advance
Are you getting an error or do you expect something else?
Hello. Im also having trouble creating this integration through cloudformation.
First of all. im getting this error:
Unable to download from S3 location (Bucket: thethingsnetwork-eu-north-1 Key: builds/integration-aws/dist/integration-aws-v2.0.30.zip). Reason: Forbidden: S3Bucket=thethingsnetwork-eu-north-1, S3Key=builds/integration-aws/dist/integration-aws-v2.0.30.zip (Service: AWSElasticBeanstalk; Status Code: 400; Error Code: InvalidParameterCombination; Request ID: ???-26fb-???-a95b-33872c???; Proxy: null)
To sum things up i copied the template URL - it seemed to be the same for all regions so I assumed you can create the resources on any region. We are hosting our things in stockholm at the moment.
What would be super useful in the tutorial is also if you explain if there are any limitations that has to be followed - for example that you have to host it in a certain region.
Would also be good to be clear if the integration works for all versions or certain versions.
We are currently running the open source version. But have plans to move on to the hosted amazon version later. However; we need to test everything and make sure it all works before we go to enterprise edition.
@Johannes_Nylund I’m afraid that AWS made these regions available after we set up the continuous integration pipeline for this integration.
We now added eu-north-1, eu-south-1, eu-west-3, af-south-1 and ap-east-1 that were missing. We’re now deploying to all current and public AWS regions.
This is version 2.0.31.
There shouldn’t be.
It should work for all AWS regions.
For The Things Industries Cloud Hosted, we actually have a brand new integration which is really great (and serverless) and also available in all AWS regions. See https://www.thethingsindustries.com/docs/integrations/cloud-integrations/aws-iot/
Hello johan. That sounds great. Got another error on the standard integration. This time that the instance type is not allowed:
2020-10-09 09:27:24 UTC+0200 TTNIntegrationEnvironment CREATE_FAILED Configuration validation exception: Invalid option value: ‘t2.micro’ (Namespace: ‘aws:autoscaling:launchconfiguration’, OptionName: ‘InstanceType’): Value is not one of the allowed values: [c5.12xlarge, c5.18xlarge, c5.24xlarge, c5.2xlarge, c5.4xlarge, c5.9xlarge, c5.large, c5.metal, c5.xlarge, c5d.12xlarge, c5d.18xlarge, c5d.24xlarge, c5d.2xlarge, c5d.4xlarge, c5d.9xlarge, c5d.large, c5d.metal, c5d.xlarge, d2.2xlarge, d2.4xlarge, d2.8xlarge, d2.xlarge, g4dn.12xlarge, g4dn.2xlarge, g4dn.4xlarge, g4dn.xlarge, i3.16xlarge, i3.2xlarge, i3.4xlarge, i3.8xlarge, i3.large, i3.xlarge, m5.12xlarge, m5.16xlarge, m5.24xlarge, m5.2xlarge, m5.4xlarge, m5.8xlarge, m5.large, m5.metal, m5.xlarge, m5d.12xlarge, m5d.16xlarge, m5d.24xlarge, m5d.2xlarge, m5d.4xlarge, m5d.8xlarge, m5d.large, m5d.metal, m5d.xlarge, r5.12xlarge, r5.16xlarge, r5.24xlarge, r5.2xlarge, r5.4xlarge, r5.8xlarge, r5.large, r5.metal, r5.xlarge, r5d.12xlarge, r5d.16xlarge, r5d.24xlarge, r5d.2xlarge, r5d.4xlarge, r5d.8xlarge, r5d.large, r5d.metal, r5d.xlarge
Alright, so AWS discontinued those instance types and didn’t make them available in the new regions.
Version 2.0.32 is currently building, which uses m5.large by default, which is a currently supported instance type. I tested this in eu-west-1 and that works.
It will take another 10 minutes for 2.0.32 to be available.
@johan Im getting a bit confused here. Stockholm supports alot of instances other than large. We are currently running our server on a t3.medium. It seems very weird that one we would require a m5.large just for the integration?
I was thinking either a micro or small for the integration. (escpecially since they were selectable in the list)
|t3.micro|2|Variable|1 GiB|EBS Only|$0.0108 per Hour|
|t3.small|2|Variable|2 GiB|EBS Only|$0.0216 per Hour|
|t3.medium|2|Variable|4 GiB|EBS Only|$0.0432 per Hour|
|t3.large|2|Variable|8 GiB|EBS Only|$0.0864 per Hour|
I don’t know exactly what the integration requires from the virtual machine but it feels overscaled with a large. Seems impossible that the integration should be more demanding than the network and device management server.
Am i misunderstanding something?
Okay, so where is this all documented? I’m getting a bit lost here. Anyway I’m glad it worked.
FYI the V3 integration is serverless.
@johan We have not set up the integration yet. What im trying to say is that there are many smaller instances available for stockholm region. I don’t understand why I can only select a large instance for the integration through cloudformation? It should be quite easy for you too see which instance types that are available for each region.
In the previous message i wrote “I was thinking either a micro or small for the integration. (escpecially since they were selectable in the list)”
I should have written “since it were selectable in the OLD list” Because you could previously select them before you updated to the new version of the config file for cloud formation.
Smaller servers then large can not be choosen now. Which is why we have not started up the integration yet.
There are, but we have to find the common denominator of instances that are available in all AWS regions. I suppose t3.{nano,micro,small,medium,large,xlarge} are available in all regions that I tried so far, so I settled for that in version 2.0.33.
Now it works @johan. Thank you. The integration could successfully be created through cloudformation with with a micro server.
As far as I can tell the integration should be functional now. Only issue I have is that our existing sensors are not added to AWS IOT.
Do you have to add existing sensors manually if they were created before the integration was made? Or is there some other issue at play here.
Edit: is there any way to check whats failing with the integration?
Great. For troubleshooting see https://www.thethingsnetwork.org/docs/applications/aws/troubleshooting.html and consult the forums here otherwise.