Releases: NASA-IMPACT/hls-orchestration
v1.27
v1.26
Update environment to use new LAADS token due to https://ladsweb.modaps.eosdis.nasa.gov/alerts-and-issues/138007.
v1.25
Add deployments to target MCP using OIDC
v1.24
Update operational LAADS Token
Ignore new flake8 linting rule.
v1.23
Refactors Sentinel 2 error processing to use dedicated status fields rather than jsonb queries.
v1.22
Update hls-laads image to use v1.6 of MODIS data due to https://forum.earthdata.nasa.gov/viewtopic.php?t=3780
v1.21
Update hls-sentinel and hls-landsat-tile container versions.
v1.20
Temporary fix for upstream issue with the most recent ECS Optimized AMI release. From the AWS Batch team
Dear Customer,
Upon some further researching, I have some more findings regarding the issue you have encountered.
We are aware of an issue when launching Amazon Linux 2 (AL2) AMIs and passing a cloud-init boot hook via EC2 userdata. If the boot hook attempts to upgrade the chrony package, some instances will fail to boot. The root cause is a faulty update to the chrony package that was pushed to the yum repositories on August 19, 2022. The workaround for this issue is to NOT update the chrony package from the boot hook, by excluding the package as below:
yum update -y --exclude='chrony*'
I could see from the script that has EFS calls included has "cloud-init-per once yum_update yum update -y" commands which could possibly affected by the issue.
Alternatively, you may also consider moving the "yum update" from 'cloud-boothook' section to the 'shellscript' section.
Our ETA for a new ECS optimized AMI to resolve this issue is August 30, 2022.
Notes there was a time where ssh was not possible as "cloud-bookhook" and "cloud-config" are the sections executed by cloud-init before any other script, hence any failure here can lead to subsequent runlevels to be skipped, hence daemons (like ssh) fail to start. [1]
v1.19
Fix deployment issue caused by upstream jsii change.
v1.18
Update hls-landsat-tile container version to use hls-metadata v2.2.