Hello everyone,
I wanted to write this mail to let everyone know the current status of
SUSE's ALP (Adaptable Linux Platform) efforts and hopefully get the ball
rolling with openSUSE making use of these efforts.
This is a long mail, but I've done my best to be brief and shift the
more esoteric technical detail as an appendix for those most interested
in contributing.
First, I want to clear up "What is SUSE ALP?"
SUSE ALP is not a single new product by SUSE, in the same way that SLE
isn't a single product.
Just like now where SUSE has SLES, SLED, SLE Micro, SLE for SAP and
more, SUSE ALP is a 'platform' that is going to produce whole families
of products.
The key defining difference between SLE and ALP though is that SUSE is
building ALP with "Adaptability" being an absolute core aspect.
This should reduce or eliminate the situation we often see with SLE,
where products are 'stuck' using the same versions of core components
like glibc and python for the whole lifespan of a codebase.
With ALP, SUSE will be building things in a way where different ALP
products can have different versions of core components, be supported
for different lengths of times, and with old versions of those
components be removed when they're no longer needed.
This is also why you do not hear about a singular ALP 'codebase',
because the way ALP Products are built they potentially could draw from
multiple codebases, potentially with very different lifecycles; eg. One
ALP Product may be what most would call a very 'stable' distribution,
another could be 'rolling', and a third could be a hybrid between the
two.
I feel this is the most exciting thing about ALP, and it's the most
interesting engineering aspect of ALP as it dramatically changes HOW we
build these products in OBS. See the appendix for details.
So, if ALP is not a single product, what is SUSE building?
SUSE's current efforts are focused on two SUSE ALP products, which you
can currently see in OBS as SUSE:ALP:Products:Bedrock and :Micro.
These names are unlikely to be final, but they are expected to be
server-focused products, heavily leaning on transactional-updates and
containerisation to even further push the core "Adaptability" goals of
ALP; It's far easier to shift and swap what versions of libaries are in
play when (almost) everything using them is containerised and the OS is
being thought of as a cohesive unit that is updated in atomic operations
These will not be the only two products SUSE builds from ALP, but it's a
starting point.
Going forward, just like for the SLE family of products, the primary
build environment for these products is going to have to be SUSE's
internal build service. This is so SUSE can have these commercial ALP
offerings certified the way they are required to be.
However, we want ALP, both the code AND the different way of building
things, to be available to openSUSE and ideally reused/adapted for
openSUSE's own offerings. We still want to build ALP in the _open_ in
addition to what we need to do for SUSE's commercial offerings.
Therefore, the current working plan is as follows:
- All SUSE ALP Products will be built in SUSE's Internal Build Service,
using sources that originated from openSUSE:Factory
- All packages used to build SUSE ALP Products will be copied to
openSUSE's Open Build Service without alteration
- All SUSE ALP Products will be copied from SUSE's IBS to openSUSE's
OBS with the only alterations being the obvious necessary rebranding
- Any future changes to the SUSE's ALP development workflow (eg. the
possible future introduction of a git-based workflow for submitting
changes into IBS/OBS) would be also introduced for any openSUSE ALP
Products
This should all sound very familiar because it's very similar in concept
to what we already do with Leap Micro
I would like to make the following suggestion to openSUSE on the next
steps it could take to extend the above.
Any new openSUSE distribution, such as the ones discussed as
https://en.opensuse.org/Portal:16.0 or
https://en.opensuse.org/openSUSE:ALP/Workgroups/GrassyKnoll should be
built as seperate "Products" using the new ALP way of building things.
The ALP concept should be flexible enough that these openSUSE Products
will be able to leverage all the stuff SUSE is doing for SUSE's ALP
Products, but then we (community) can add anything we want. If we find
it is not flexible enough, then we (SUSE) will work to adapt it to make
it possible for the community to build what it wants.
So, if we the community want to build something like old Leap, that
should be totally technically feasible.
I can certanly imagine the community building something with a stable
release cadence and that doesn't use transactional-updates and
containers to run everything.
If that's the direction we as a community want to go, we should be able
to get started soon when the above is in place in OBS.
The biggest challenge I forsee would be ensuring we have enough people
to maintain all the packages in that 'old fashioned' way of doing
things, especially with SUSE going in a different direction...but that
has always been an aspect of openSUSE's way of doing things.
I could also see a future where we take this opportunity to try
something like an ALP-based take on the MicroOS Desktop, more polished,
opinionated and less 'tinkering friendly' than old Leap. I'd imagine
that would certainly be possible; also, maybe in parallel, if people
want to build it.
This approach would also tie in nicely with all the awesome work the
Agama (formerly known as 'D-Installer') team have been doing, as we
should be able to offer a single installation ISO that offers all the
combined "openSUSE ALP" offerings, including the 1:1 openSUSE copies of
SUSE's Products as well as any additional ones built purely by openSUSE.
This would potentially cut out a lot of the work needed for the
openSUSE-only Products as (speaking from experience), creating and
maintaining installation media is often the biggest pain.
What does everyone think?
---
Richard Brown
Distributions Architect @ SUSE
---
APPENDIX Below
---
Brief technical details about how ALP is currently built.
If the above proposal is widely accepted then openSUSE would mimic the
below, just obviously replacing SUSE: with openSUSE:
SUSE:ALP:Workbench: