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
Every AMI creation currently involves yum upgrade in bash provisioner.
While it serves a value by updating packages to latest and greatest, it also serves a problem by having a different (newer) version of packages compared to the ones defined in the source AMI, specially when it's a security requirement to control the package versions inside an SOE AMI.
e.g. SOE AMI might contain package xyz to have version 123, but yum upgrade might then upgrade the version to 124 .
In this kind of environment, xyz package is expected to be upgraded inside the SOE AMI first, before then consumed by the child AMIs.
So rather than enforcing everyone to upgrade when they create the AMI, its better to provide a configuration value to control whether to upgrade the packages or not.
The text was updated successfully, but these errors were encountered:
Every AMI creation currently involves
yum upgrade
in bash provisioner.While it serves a value by updating packages to latest and greatest, it also serves a problem by having a different (newer) version of packages compared to the ones defined in the source AMI, specially when it's a security requirement to control the package versions inside an SOE AMI.
e.g. SOE AMI might contain package xyz to have version 123, but
yum upgrade
might then upgrade the version to 124 .In this kind of environment, xyz package is expected to be upgraded inside the SOE AMI first, before then consumed by the child AMIs.
So rather than enforcing everyone to upgrade when they create the AMI, its better to provide a configuration value to control whether to upgrade the packages or not.
The text was updated successfully, but these errors were encountered: