Re: SOAFEE R2 Release Planning - Status

[Girish Shirasat]

++

 

 

From: Daniel Bernal <Daniel...@arm.com>
Date: Monday, August 22, 2022 at 3:10 PM
To: jefro.os...@soafee.io <jefro.os...@soafee.io>, Robert Day <Rober...@arm.com>
Cc: Estela Rey Ramos <Estela....@ARM.com>, Girish Shirasat <Girish....@arm.com>, Matt Spencer <Matt.S...@arm.com>
Subject: SOAFEE R2 Release Planning - Status

Hi Folks,

 

Following up on Girish’s e-mail from a couple weeks ago on SOAFEE R2 release planning:

 

I have captured some planning details a presentation that can be found in the Reference Implementation WG shared drive:

 

SOAFEE R2 Release Planning

 

You may have attended the 16 August 2022 Ref Implementation WG meeting (minutes here).   The plan was announce in August the next iteration/release of the SOAFEE Reference Implementation.   Naturally, since we named the previous release “R1” we always assumed that we would call this the “R2” release.  During this release planning someone asked the question if we should have a release number, i.e. “R2” with the announcement.  This is a good question and we felt it was appropriate for the MSC to make this decision, so we get it right going forward.   This ties into a larger roadmap discussion around SOAFEE architecture releases/announcements, reference implementations, and blueprints.

 

If we get back to the basics and consider the SOAFEE high level messaging:  

 

“The initiative intends to deliver a cloud-native architecture enhanced for mixed-criticality automotive applications with corresponding open-source reference implementations to enable commercial and non-commercial offerings.”

 

There is some work we can do to ensure that our messaging is easy to understand.  If I break down the messaging into the two things the SIG intends to deliver it comes down to the following:

 

• Cloud-Native Architecture
• Open-Source Reference Implementations

 

The R2 Announcement Addresses these two items in the following way:

 

Cloud-Native Architecture – The features and capabilities in the R2 release include the following: Operating System distro that is scalable, flexible, proven to run in the Cloud and the Edge. Standards Compliant Container Runtime Container Orchestration Client Native OS Architecture Type-1 Hypervisor for Multi-Partition (multi-OS) Architectures

Daniel Bernal’s Comments:  This begs the question about an architecture document that we can refer to as a version of the SOAFEE architecture.  The Reference Implementation WG has an open action item to create a document, i.e. SAOFEE Architecture Specification.  That was targeted for completion in Sept 2022.

Open-Source Reference Implementation – SOAFEE cloud-native architecture reference implementation: Edge Workload Abstraction & Orchestration Layer (EWAOL) - Version 1.0 Yocto Linux based distro: Linux Operating System distro that is scalable, flexible to run in the Cloud and the Edge. Container Runtime: Open Container Initiative (OCI) Container Engine & Runtime Container Orchestration Client: K3S Container Orchestration Client Baremetal Architecture (Native Linux) Virtualization Architecture (Xen Hypervisor) On-target Development Support Validation Support Build Support Tools (image, documentation, and QA)

Daniel Bernal’s Comments: This is the instantiation of SOAFEE in code form. I think this is self-explanatory.

 

We will be in a position to make this SOAFEE R2 announcement at the soonest later this week but it might make sense to delay the announcement, so we get the messaging correct.  This is gating the final documentation & messaging on the announcement.  It is high priority to make a decision but it’s more important to make the right decision so we properly set the stage going forward.

 

Do we need a meeting to discuss?  If so, when is a good time over the next couple days?

Thanks,

 

Daniel

-- 

Daniel L. Bernal Principal Solutions Architect Automotive & IoT Email: daniel...@arm.com Address:  3075 West Ray Road, Suite 500, Chandler, AZ 85226 Direct Dial:  +1 602 648 5541 Mobile: +1 480 319 2931 www.arm.com

 

 

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

[Jeffrey Osier-Mixon]

Hi Daniel - I think the main issue is to clarify what R2 refers to. The table in this email seems to do that, i.e. shows that this is R2 of the architecture while the reference implementation(s) will have their own release cycles. 

Is there a reason not to include the release number with the announcement? Perhaps I am misunderstanding the question?

Jeffrey "Jefro" Osier-Mixon  |  je...@redhat.com

Red Hat Office of the CTO  |  Sr. Principal Community Architect, Automotive

[Robert Day]

Hi all,

 

Sorry to be a bit late to the discussion, as I am just back from my CoVacation.

 

Reading the thread, my thoughts are that we need release versions for both the arch and the ref implementation, and that they should somehow tie to each other.

 

So, let’s assume that the architecture gets revved a lot less frequently than the ref implementation, we could stick with the R1, R2 etc for the architecture, and that major revision number feeds into the ref implementation that implements it. But that ref implementation may well have incremental changes (let’s say Linux or Xen or K3S gets updated), which would require a new version that shows this.

 

So Arch revs feed into ref Implementation versions, with the latter having a minor version number to show incremental changes.

 

Arch Rev R2 -> Ref impl Rev 2.0, 2.1, 2.2 etc

Arch Rev R3 -> Ref impl Rev 3.0, 3.1 etc

 

Then it is obvious which ref implements which arch, and also which arch a ref impl is based on.

 

Does this make sense ?

 

Cheers

Robert

[Daniel Bernal]

Hi All,

 

Please see my comments below in RED.

 

From: Robert Day <Rober...@arm.com>
Date: Tuesday, August 23, 2022 at 2:36 PM
To: Jeffrey Osier-Mixon <je...@redhat.com>, Girish Shirasat <Girish....@arm.com>
Cc: Daniel Bernal <Daniel...@arm.com>, "jefro.os...@soafee.io" <jefro.os...@soafee.io>, Estela Rey Ramos <Estela....@ARM.com>, Matt Spencer <Matt.S...@arm.com>, "Barnett, Damian (DXC Luxoft)" <damian....@dxc.com>, Al Stone <ah...@redhat.com>, Anmar Oueja <anmar...@linaro.org>, "m...@soafee.io" <m...@soafee.io>, "t...@soafee.io" <t...@soafee.io>
Subject: Re: SOAFEE R2 Release Planning - Status

 

Hi all,

 

Sorry to be a bit late to the discussion, as I am just back from my CoVacation.

 

Reading the thread, my thoughts are that we need release versions for both the arch and the ref implementation, and that they should somehow tie to each other.

 

So, let’s assume that the architecture gets revved a lot less frequently than the ref implementation, we could stick with the R1, R2 etc for the architecture, and that major revision number feeds into the ref implementation that implements it. But that ref implementation may well have incremental changes (let’s say Linux or Xen or K3S gets updated), which would require a new version that shows this.

[DLB] I agree that the architecture will probably get revised less frequently than a ref implementation.  in principle, this seems great and appropriate.  Although not captured as formal specifications we have defined R1 and R2 as the following:

 

SAOFEE R1	SOAFEE R2
- POSIX Operating System - OCI Compliant Container Engine Runtime - OCI Compliant Container Orchestration Client	- POSIX Operating System - OCI Compliant Container Engine Runtime - OCI Compliant Container Orchestration Client - Virtualization Support w/Type-1 Hypervisor
Reference Implementation is EWAOL 0.2.4	Reference Implementation is EWAOL 1.0

 

 

So Arch revs feed into ref Implementation versions, with the latter having a minor version number to show incremental changes.

 

Arch Rev R2 -> Ref impl Rev 2.0, 2.1, 2.2 etc

Arch Rev R3 -> Ref impl Rev 3.0, 3.1 etc

[DLB] Unfortunately this scheme doesn’t align with our current Ref Implementation Release (EWAOL 1.0).   We could re-tag the EWAOL release as 2.0 so it does match this scheme?

[Robert Day]

Funny it’s blue on my screen, maybe COVID did a number on my sight as well as taste and smell 😊

 

I like the idea of EWAOL following our SOAFEE release numbering – as this will be key going forward when other initiatives (e.g Open AD kit) use the ref implementation.

 

Cheers

Robert

[Kasper Ornstein Mecklenburg]

Hi everyone,

I'd like to provide some information from a historic perspective, which I hope will help give a bit more context. The first technical output from SOAFEE was back in September 2021, in short, the release contained:

• EWAOL v0.2 on AVA Developer Platform
• Build, flash and boot instructions
  
• Autoware.Auto deployed on AVA Developer Platform as single container using Docker
• Running localization feature
• RViz (ROS visualization) running on an x86 host machine
  

This is the "SOAFEE R1" release. Since this release last year, two important factors have changed:

1. Multiple SOAFEE reference implementations
   1. In September 2021, there was only EWAOL
2. Introduction of SOAFEE Blueprints
1. This initiative aims to materialize the SOAFEE vision by deploying the SOAFEE reference implementations and running relevant applications

These have the following versioning and structure:

EWAOL, which is one of the SOAFEE reference implementations, is versioned and has a changelog, see https://ewaol.docs.arm.com/en/v1.0/changelog.html. This is a standard software development procedure.

The SOAFEE Blueprints are organized as follows:

└── Blueprints

    ├── Blueprint - AWF Open AD Kit

    │   ├── V1

    │   └── V2

    ├── Blueprint - AWS

    │   └── V1

    ├── Blueprint - EB Corbos

    │   └── V1

    ├── Blueprint - Eclipse SDV Charriot

    │   └── V1

    ├── Blueprint - Panasonic IVI@AGL

    │   └── V1

    ├── Blueprint - QNX

    │   └── V1

    └── Blueprint - RHEL In-Vehicle OS

        └── V1

(please note that this list isn't extensive, nor that all of these blueprints yet exist)

As we can see, both SOAFEE reference implementations and blueprints are versioned. My suggestion is that we use SOAFEE to channel and highlight when there are new SOAFEE reference implementation versions released, a new blueprint, or blueprint version, etc., I would encourage us to not have enumerated SOAFEE releases, which in my opinion, only create artificial constraints on ourselves.

Perhaps a SOAFEE announcement could look something like this:

• SOAFEE proudly announces the first release of the "AWF Open AD Kit" blueprint!
• SOAFEE proudly announces a new version of the SOAFEE Reference Implementation EWAOL!
  

If we do decide to go with having SOAFEE R1/R2/R3/..., I think we need more clarity and should answer the following questions:

• What is the actual purpose of having SOAFEE Releases?
• How is what qualifies to be part of a SOAFEE Release determined?
  
• What's the relationship between SOAFEE Releases, reference implementations versioning, and type of blueprint and its version?
• What does the SOAFEE Release structure look like?
• What's the frequency of SOAFEE Releases?

Best regards,

Kasper Ornstein Mecklenburg Staff Performance Analysis Engineer | Arm kasper.ornsteinmecklenburg@arm.com San Jose | Mobile: +1 (408) 533-2960 Automotive and IoT Line of Business www.arm.com

---

From: Robert Day <Rober...@arm.com>
Sent: Tuesday, August 23, 2022 15:20
To: Daniel Bernal <Daniel...@arm.com>; Jeffrey Osier-Mixon <je...@redhat.com>; Girish Shirasat <Girish....@arm.com>
Cc: jefro.os...@soafee.io <jefro.os...@soafee.io>; Estela Rey Ramos <Estela....@ARM.com>; Matt Spencer <Matt.S...@arm.com>; Barnett, Damian (DXC Luxoft) <damian....@dxc.com>; Al Stone <ah...@redhat.com>; Anmar Oueja <anmar...@linaro.org>; m...@soafee.io <m...@soafee.io>; t...@soafee.io <t...@soafee.io>
Subject: SOAFEE TSC: Re: SOAFEE R2 Release Planning - Status

 

--
You received this message because you are subscribed to the Google Groups "SOAFEE TSC" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tsc+uns...@soafee.io.
To view this discussion on the web, visit https://groups.google.com/a/soafee.io/d/msgid/tsc/BA5BAD7D-CC02-4C1B-96F0-D1C925365D14%40arm.com.