Running Automotive Stream Distribution (AutoSD) images in AWS

Red Hat is on a journey to build a functionally safe Linux, targeting the automotive industry with multiple partners. On this journey, Red Hat is committed to working transparently for this new in-vehicle operating system in the same way it does for RHEL. This commitment has led to the creation of the CentOS Automotive Special Interest Group (SIG).

The CentOS Automotive SIG produces three artifacts:

• An RPM repository named AutoSD (Automotive Stream Distribution), which is the upstream, in-development version of the future Red Hat product Red Hat In-Vehicle Operating System. AutoSD can be considered to be the CentOS Stream of Red Hat's in-vehicle OS.
• An RPM repository for the Automotive SIG serving as a dedicated space for conducting experiments, incorporating new packages, or making available newer package versions to AutoSD before they are in CentOS Stream or AutoSD itself.
• A set of OSBuild manifests for building sample images from the repositories above (and possibly others). These manifests can produce sample/proof-of-concept images in various formats (.qcow2, ext4 filesystem, oci tarball, rootfs, and so on). You can use these manifests to get started, but you would create your own to adjust the images you want to build as you need.

We've created automation to build the developer sample image in the form of an Amazon Machine Image (AMI) that is then automatically uploaded into AWS and made available for anyone to use. That automation happens nightly, so you'll be able to get bug fixes and new features quickly and find issues early, should you have any!

If you're curious about what AutoSD looks like, or you want to test something with it quickly, or to build automation on top of it, and have access to AWS, then have a look at these images.

Manual provisioning from the AWS Console

At the time of this writing, developer images are only available in us-east-2 regions.

From the AWS Console menu, go to Services -> Compute -> EC2:

Click on the Launch Instance button:

Set a name of your choice and then click on Browse More AMIs:

Select Community AMIs, type "auto-osbuild" in the search field, and choose an architecture of your choice (x86_64 or aarch64 at the time of this writing):

You can then follow with the usual EC2 setup, pick a machine type, keypair, and so on. 

Automated provisioning with Terraform

It's also possible to quickly provision an AutoSD machine in AWS using any infrastructure/configuration as code tool.

The following sample code demonstrates how to do it with Terraform:

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 4.16"
    }
  }

  required_version = ">= 1.2.0"
}

provider "aws" {
  region  = "us-east-2"
}

resource "aws_vpc" "autosd_demo_vpc" {
  cidr_block = "10.0.0.0/16"

  tags = {
    Name = "autosd-demo-vpc"
  }
}

resource "aws_subnet" "autosd_demo_subnet_public" {
  vpc_id            = aws_vpc.autosd_demo_vpc.id
  cidr_block        = "10.0.1.0/24"
  availability_zone = "us-east-2a"

  tags = {
    Name = "autosd-demo-subnet-public"
  }
}

resource "aws_subnet" "autosd_demo_subnet_private" {
  vpc_id            = aws_vpc.autosd_demo_vpc.id
  cidr_block        = "10.0.2.0/24"
  availability_zone = "us-east-2a"

  tags = {
    Name = "autosd-demo-subnet-private"
  }
}

resource "aws_internet_gateway" "autosd_demo_ig" {
  vpc_id = aws_vpc.autosd_demo_vpc.id

  tags = {
    Name = "autosd-demo-ig"
  }
}

resource "aws_route_table" "autosd_demo_rt" {
  vpc_id = aws_vpc.autosd_demo_vpc.id

  route {
    cidr_block = "0.0.0.0/0"
    gateway_id = aws_internet_gateway.autosd_demo_ig.id
  }

  route {
    ipv6_cidr_block = "::/0"
    gateway_id      = aws_internet_gateway.autosd_demo_ig.id
  }

  tags = {
    Name = "autosd-demo-rt"
  }
}

resource "aws_route_table_association" "public_1_rt_a" {
  subnet_id      = aws_subnet.autosd_demo_subnet_public.id
  route_table_id = aws_route_table.autosd_demo_rt.id
}

resource "aws_security_group" "autosd_demo_sg" {
  name   = "autosd-demo-sg"
  vpc_id = aws_vpc.autosd_demo_vpc.id

  ingress {
    from_port   = 22
    to_port     = 22
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

  egress {
    from_port   = 0
    to_port     = 0
    protocol    = -1
    cidr_blocks = ["0.0.0.0/0"]
  }
}

resource "aws_instance" "autosd_demo" {
  ami           = "ami-0dec5dbda62a236b3"
  instance_type = "t3a.nano"  
  key_name      = "autosd-demo"

  subnet_id                   = aws_subnet.autosd_demo_subnet_public.id
  vpc_security_group_ids      = [aws_security_group.autosd_demo_sg.id]
  associate_public_ip_address = true

  tags = {
    Platform = "AutoSD"
  }
}

output "autosd_demo_public_ip" {
  value = ["${aws_instance.autosd_demo.*.public_ip}"]
}

You can get the instance's raw public IP by running the following command:

terraform output -json autosd_demo_public_ip | jq '.[0][0]' | tr -d \"

Here are a few notes when using automation tools to deploy an AutoSD developer machine:

• The AMI is only available in the us-east-2 region.
• Some machine types will return an error because they are not compatible with UEFI booting.
• Deploying in such a way requires extra VPC configuration, and some of those recipes need to be allocated in us-east-2 "sub-regions" such as us-east-2a, us-east-2b, or us-east-2c.
• The above code requires a keypair (pem file) to already exist as it references one by its name. Use the name to SSH into the VM using the ec2-user username.

Wrap up

Once built, you're able to SSH into your instance (using a keypair) and check the kernel (spoiler: these images have a different kernel than the one available in CentOS stream and RHEL). Run Podman, BlueChi, and QM to see how these AutoSD images meet your needs.

These developer images have about 40GB of storage available. Let us know if you need more.