Because I don't anticipate being able to make it to the cloud BoF at Debconf, I'm sending this update here. Please feel free to discuss any of the issues; just make sure to record the conversation in the minutes so I can respond.
Current status ============== Stretch --- Stretch images are built using FAI and are actively maintained and kept up to date with content changes, e.g. base system security updates and point releases. Images are published via the AWS Marketplace and directly on the Debian wiki (https://wiki.debian.org/Cloud/AmazonEC2Image/Stretch) As of 2018-07-23, 8882 unique AWS accounts have used the stretch AMIs via the AWS Marketplace. No data is available on the number of actual instances, the instance types in use, or the percentage of those accounts that are actively using the AMIs. No data is available on the use of the instances published on the wiki. Jessie --- Jessie images are built using bootstrap-vz, but are *not* actively maintained. They had previously been maintained by James Bromberger <j...@debian.org>, but he is not actively involved anymore. No updates of any kind since at least January of this year. We should probably try to fix this, but it'd be nice to get help from James to make sure we're building something sufficiently similar to the current AMIs. Volunteers are welcome. Alternatively, we should mark them as "retracted" in the AWS Marketplace, which will let current users continue to use them but will prevent them from showing up in search results. As of 2018-07-23, there are 27891 unique AWS accounts that have used these AMIs via the Marketplace. As with Stretch, there is no data regarding how the images are being used or how actively. Buster --- FAI configs were updated to support buster at the previous cloud sprint hosted by Microsoft last fall, and the resulting images were given cursory testing. They haven't been tested on an ongoing basis. As the release approaches, we should be building and testing more frequently. TODO ==== Network configuration --- We use a hack (https://salsa.debian.org/cloud-team/fai-cloud-images/blob/master/config_space/files/usr/local/sbin/inet6-ifup-helper/EC2) to work around [bug #804396](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=804396) and make ifupdown work without manual configuration in IPv4 and dualstack AWS VPCs. The script could probably be improved, integrated with udev rather than relying on a pre-configured `/etc/network/interfaces`, etc. Additionally, the script isn't even packaged, but it should be if we're going to ship it on the public images. Will buster continue to use ifupdown, or is it switching to systemd-networkd? If the latter, is ifupdown still available? Last time I tried, I was unable to get a single networkd configuration to behave correctly in all of the different VPC network configuration possibilities. cloud-init --- There's a new version available. It should probably be packaged soon to give us time for testing before the buster release. Specialized AMIs? --- Kubernetes, installed using the KOPS cluster management tool, uses our AMIs by default. We should be engaging with them to ensure that things are working as well as possible. AWS publishes some custom Amazon Linux-based AMIs as an optimization for certain use cases. E.g. there's a "minimal" AMI with a reduced set of software, an ECS Optimized AMI pre-configured with Docker and the necessary support software to integrate with the ECS container orchestration software. Do our users want similar AMIs? Even if we don't publish the AMIs, we could accept contributions to our FAI configs allowing users to easily build their own derivative images. AWS Account Ownership --- The main Debian AWS account still lists James Bromberger as the primary owner and contact. I've done preliminary work to get it moved to a Debian role account. We still need to work with AWS and James to get the ownership and contact details updated. The email alias is aws-ad...@debian.org and it's maintained by DSA. Current members are myself, jeb, 93sam, and kula. Special AWS regions --- AWS has reached out to me because (at least) one of their customers have asked them about the availability of our AMIs in the AWS GovCloud region. This is a special region built to support US government customers bound by ITAR regulations, and AWS accounts by default don't have access to it. ITAR requires that people directly interacting with the region in any kind of administrative manner be US citizens within US territory. I meet these requirements and can perform the necessary tasks to make images available in GovCloud, but so far haven't had time to complete the necessary administrative tasks to get set up in that region. Once we have access to GovCloud, integration of that region into our existing AMI publication workflow should be reasonable straightforward. Volunteers to chase down the various administrative loose ends and get us up and running in GovCloud would be appreciated. We need to create a new AWS account, distinct from our main account, and agree to some GovCloud specific terms. Details at https://docs.aws.amazon.com/govcloud-us/latest/UserGuide/getting-started-sign-up.html and https://docs.aws.amazon.com/govcloud-us/latest/UserGuide/govcloud-itar.html There are other special regions as well. E.g. the regions in China require certain permission from the Chinese government before anything can be published there. I do not know the details of these requirements or of the process for gaining the necessary approvals. Ideally we would be able to offer our AMIs to Chinese AWS customers, so help would also be welcome in this area. Build utilities --- There's plenty of room for improvement in the build scripts: https://salsa.debian.org/noahm/ec2-image-builder
signature.asc
Description: PGP signature
