Module Stream "Expansion"

[Ralph Bean]

This is a writeup on a problem we’re facing with modularity, and some ideas on
how to resolve it.

# The "Problem"

Imagine I have an **httpd module**.  To simplify things, let’s say that this
module has only one stream: **2.4**. Today, in the modulemd for this module, I
declare build and runtime dependencies like this:

    dependencies:
        buildrequires:
            platform: f26
        requires:
            platform: f26

This works.

Now, imagine that Fedora 27 comes along. I want the httpd module to be
installable on f27, so I update those streams to point to f27.  But now I can’t
ship updates to f26 anymore!  Uh oh.

## Just use more streams?

We could just ask packagers to create more streams to deal with this.  httpd
wouldn’t have a 2.4 stream.  It would need to have a f26-2.4 stream and a
f27-2.4 stream.

But, this gets us exactly back into the place we were **before** we had
arbitrary branching!  You need to have as many branches for *every component*
as you have releases of the distro (or, as you have "products").  Noooo!

## Solution: "Input" Modulemd Syntax Changes

We’re going to extend the modulemd syntax to allow specifying multiple
dependencies in an "input" modulemd (the one that packagers modify).  When
submitted to the build system, the module-build-service (MBS) will *expand*
these values under the hood, and submit **multiple** module builds to
itself based on the expansion.

Here are some examples of modulemd files (maintained by humans) that might be
submitted to the MBS.

Build on **all** active streams of the platform module.
    dependencies:
        buildrequires:
            platform: []

Build on **only** the f27 and f26 platform streams.
    dependencies:
        buildrequires:
            platform: [ f27, f26 ]

Build on all active streams of platform **except** for the f26 stream.
    dependencies:
        buildrequires:
            platform: [ -f26 ]

The following syntax, which builds on **only** the f26 stream, will still be supported:
    dependencies:
        buildrequires:
            platform: f26

--

Take the following example (described above):
    dependencies:
        buildrequires:
            platform: [ f27, f26 ]

Submitting this modulemd to the MBS would in turn generate **two** module
builds: one of our httpd module against the f27 stream and another against the
f26 stream.  Each module build would be associated with its own unique
"flattened" *output* modulemd file that specifies exactly which platform stream
it was built against.

# New Problems

Having **multiple** module builds for a single dist-git commit of a modulemd
file poses new implementation problems.

## NSV uniqueness

Today, we uniquely identify a module build in *a variety of systems* with
**<name>-<stream>-<version>** (NSV) where version is derived from the
dist-git
commit timestamp.  Here we’ll have an httpd-2.4 module built on f26 and an
http-2.4 module built on f27: two different module builds with the same name,
stream, and version.  How can we tell them apart?

We will introduce a new value called the **context** of a built module and
include it in the modulemd metadata that gets carried with the built module.

* For user facing cases (dnf installation) it will generally be hidden.  The
  old NSV value will still appear.  If a user ever needs to surface the value,
  client tooling can find it in the modulemd metadata.  The additional
  identifier will give users access to explicit pointers to the content that is
  installed:
    * For cloning a machine.
    * For comparing two installed hosts.
    * For reporting bugs.
* Some build and compose time systems will have to be modified to use the
  context as part of a new unique identifier.  **NSVC** will be the
  **<name>-<stream>-<version>-<context>**.  The systems in
question are PDC,
  koji/brew, pungi, and bodhi.

The context value will be a **hash**, generating as the first step in the build
process (but after expansion).  Consider what metadata needs to be hashed:  we
think that hashing the whole modulemd is problematic, because the modulemd can
and will be modified after build time.

Therefore, the *context_hash* value will need to be derived from only the stuff
that uniquely identifies the build and runtime context of the module -- name,
stream, version and crucially, its dependencies

## Buildtime/Runtime Dep Correlation

Another problem.  We now have input modulemd files for a single stream that can
expand buildtime dependencies to ‘f27’ and ‘f26’, but what about the
runtime dependencies?

Consider the following yaml file:

 dependencies:
    buildrequires:
        platform: [f28, f27, f26]
    requires:
        platform: [f28, f27, f26]

With our thinking caps on, this should obviously generate three module builds
(one that buildrequires f28 and run requires f28, a second that buildrequires
f27 and run requires f27, and a third for f26).  The naive cross-product of all
streams is not valuable; the MBS needs some logic to **correlate** the build
time requirements with the run-time requirements.  That logic will contain
assumptions about how this will be used, and it needs to be well-defined.

Let’s try to define that.  Consider a more complicated yaml file that depends
on both multiple streams of platform and on multiple hypothetical streams of a
"shared-userspace" module:

 dependencies:
    buildrequires:
        platform: [f28, f27, f26]
        shared-userspace: [fancy, nonfancy]
    requires:
        platform: [f28, f27, f26]
        shared-userspace: [fancy, nonfancy]

Here are some rules the MBS should obey:

* If a build-time dep contains an expansion, that dep **does not** have to also
  appear as a run-time dep.
* If a build-time dep contains an expansion, and if that dep *also appears* as
  a runtime dep, the runtime expansion **must** match the buildtime expansion
  exactly.

Now that the streams from build-time and runtime *can be mapped one-to-one*,
the cross-product of the deps is taken to produce a set of modules builds.  In
our example here, we get:

1. One build with platform f28 and shared-userspace fancy.
2. One build with platform f27 and shared-userspace fancy.
3. One build with platform f26 and shared-userspace fancy.
4. One build with platform f28 and shared-userspace nonfancy.
5. One build with platform f27 and shared-userspace nonfancy.
6. One build with platform f26 and shared-userspace nonfancy.

We like this.

--

But, a new** corner case** emerges!  What if the *nonfancy* branch of
shared-userspace is only compatible with f27 and f28, but not with f26?
Build #6 will always fail - or, if it doesn’t fail it will be unusable.

We thought through a number of ways that corner cases like these could be
handled automatically, and are still working through them.  At the moment, we
are *leaning towards* suggesting that a failing corner **requires** a new
stream of the module in question to handle the exclusion.  I.e., no convenient
syntax to say "all combinations except for this one".

In this case, you would have two streams of the httpd-2.4 module:
httpd-2.4 and httpd-2.4_f26.  The first modulemd file in the
2.4 stream would be nice, like this:

 dependencies:
    buildrequires:
        platform: [f28, f27]
        shared-userspace: [fancy, nonfancy]
    requires:
        platform: [f28, f27]
        shared-userspace: [fancy, nonfancy]

The second in the 2.4_f26 stream would exist only to support the desired
corner case:

 dependencies:
    buildrequires:
        platform: [f26]
        shared-userspace: [fancy]
    requires:
        platform: [f26]
        shared-userspace: [fancy]

--

We’re still working through more details, especially on this last part (and how
it may affect upgrades), but figured its best to share now.  Any help
appreciated!

Yours-
-Ralph

[Petr Šabata]

On Tue, Aug 08, 2017 at 01:39:45PM -0400, Ralph Bean wrote:
>  This is a writeup on a problem we’re facing with modularity, and some
> ideas on
>  how to resolve it.
>  
>  # The "Problem"
>  
>  Imagine I have an **httpd module**.  To simplify things, let’s say that this
>  module has only one stream: **2.4**. Today, in the modulemd for this module, I
>  declare build and runtime dependencies like this:
>  
>      dependencies:
>          buildrequires:
>              platform: f26
>          requires:
>              platform: f26
>  
>  This works.
>  
>  Now, imagine that Fedora 27 comes along. I want the httpd module to be
>  installable on f27, so I update those streams to point to f27.  But now I can’t
>  ship updates to f26 anymore!  Uh oh.
>  
>  ## Just use more streams?
>  
>  We could just ask packagers to create more streams to deal with this.  httpd
>  wouldn’t have a 2.4 stream.  It would need to have a f26-2.4 stream and a
>  f27-2.4 stream.
>  
>  But, this gets us exactly back into the place we were **before** we had
>  arbitrary branching!  You need to have as many branches for *every component*
>  as you have releases of the distro (or, as you have "products").  Noooo!
>  
>  ## Solution: "Input" Modulemd Syntax Changes
>  
>  We’re going to extend the modulemd syntax to allow specifying multiple
>  dependencies in an "input" modulemd (the one that packagers modify).  When
>  submitted to the build system, the module-build-service (MBS) will *expand*
>  these values under the hood, and submit **multiple** module builds to
>  itself based on the expansion.
>  
>  Here are some examples of modulemd files (maintained by humans) that might be
>  submitted to the MBS.
>  
>  Build on **all** active streams of the platform module.
>      dependencies:
>          buildrequires:
>              platform: []
>  
>  Build on **only** the f27 and f26 platform streams.
>      dependencies:
>          buildrequires:
>              platform: [ f27, f26 ]
>  
>  Build on all active streams of platform **except** for the f26 stream.
>      dependencies:
>          buildrequires:
>              platform: [ -f26 ] 
Maybe it should be explicitly mentioned that combining the two
variants above will be forbidden.

>  The following syntax, which builds on **only** the f26 stream, will
> still be supported:
>      dependencies:
>          buildrequires:
>              platform: f26 
And this is not only for backwards compatibility -- it's also
what the expanded variant will look like.

>  Take the following example (described above):
>      dependencies:
>          buildrequires:
>              platform: [ f27, f26 ]
>  
>  Submitting this modulemd to the MBS would in turn generate **two** module
>  builds: one of our httpd module against the f27 stream and another against the
>  f26 stream.  Each module build would be associated with its own unique
>  "flattened" *output* modulemd file that specifies exactly which platform
> stream
>  it was built against.
>  
>  # New Problems
>  
>  Having **multiple** module builds for a single dist-git commit of a modulemd
>  file poses new implementation problems.
>  
>  ## NSV uniqueness
>  
>  Today, we uniquely identify a module build in *a variety of systems* with
>  **<name>-<stream>-<version>** (NSV) where version is derived from the
> dist-git
>  commit timestamp.  Here we’ll have an httpd-2.4 module built on f26 and an
>  http-2.4 module built on f27: two different module builds with the same name,
>  stream, and version.  How can we tell them apart?
>  
>  We will introduce a new value called the **context** of a built module and
>  include it in the modulemd metadata that gets carried with the built module.
>  
>  * For user facing cases (dnf installation) it will generally be hidden.  The
>    old NSV value will still appear.  If a user ever needs to surface the value,
>    client tooling can find it in the modulemd metadata.  The additional
>    identifier will give users access to explicit pointers to the content that is
>    installed:
>      * For cloning a machine.
>      * For comparing two installed hosts.
>      * For reporting bugs.
>  * Some build and compose time systems will have to be modified to use the
>    context as part of a new unique identifier.  **NSVC** will be the
>    **<name>-<stream>-<version>-<context>**.  The systems in
> question are PDC,
>    koji/brew, pungi, and bodhi. 
Perhaps a side note:

The exact way of encoding all the module identifiers into a
string is still being discussed.  I would very much prefer if
we used the same format in all systems that have to deal with
modules -- not only the infrastructure services listed above
but dnf, for instance, as well.

Some proposals and comments:
https://pagure.io/modularity/pull-request/43

>  The context value will be a **hash**, generating as the first step in
> the build
>  process (but after expansion).  Consider what metadata needs to be hashed:  we
>  think that hashing the whole modulemd is problematic, because the modulemd can
>  and will be modified after build time.
>  
>  Therefore, the *context_hash* value will need to be derived from only the stuff
>  that uniquely identifies the build and runtime context of the module -- name,
>  stream, version and crucially, its dependencies
>  
>  ## Buildtime/Runtime Dep Correlation
>  
>  Another problem.  We now have input modulemd files for a single stream that can
>  expand buildtime dependencies to ‘f27’ and ‘f26’, but what about the
>  runtime dependencies?
>  
>  Consider the following yaml file:
>  
>   dependencies:
>      buildrequires:
>          platform: [f28, f27, f26]
>      requires:
>          platform: [f28, f27, f26]
>  
>  With our thinking caps on, this should obviously generate three module builds
>  (one that buildrequires f28 and run requires f28, a second that buildrequires
>  f27 and run requires f27, and a third for f26).  The naive cross-product of all
>  streams is not valuable; the MBS needs some logic to **correlate** the build
>  time requirements with the run-time requirements.  That logic will contain
>  assumptions about how this will be used, and it needs to be well-defined.
>  
>  Let’s try to define that.  Consider a more complicated yaml file that depends
>  on both multiple streams of platform and on multiple hypothetical streams of a
>  "shared-userspace" module:
>  
>   dependencies:
>      buildrequires:
>          platform: [f28, f27, f26]
>          shared-userspace: [fancy, nonfancy]
>      requires:
>          platform: [f28, f27, f26]
>          shared-userspace: [fancy, nonfancy] 
Yes, all this repetition looks ugly.  Fortunately, YAML lets
you reference and include previously defined blocks, so in
practice we could replace the above with:

  dependencies:
    buildrequires: &deps
      platform: [f28, f27, f26]
      shared-userspace: [fancy, nonfancy]
    requires: *deps

Another point that came up later -- instead of shared-userspace,
imagine different streams of your favorite dynamic language.
That might make it the reasons for this more obvious.

>  Here are some rules the MBS should obey:
>  
>  * If a build-time dep contains an expansion, that dep **does not** have to also
>    appear as a run-time dep.
>  * If a build-time dep contains an expansion, and if that dep *also appears* as
>    a runtime dep, the runtime expansion **must** match the buildtime expansion
>    exactly.
>  
>  Now that the streams from build-time and runtime *can be mapped one-to-one*,
>  the cross-product of the deps is taken to produce a set of modules builds.  In
>  our example here, we get:
>  
>  1. One build with platform f28 and shared-userspace fancy.
>  2. One build with platform f27 and shared-userspace fancy.
>  3. One build with platform f26 and shared-userspace fancy.
>  4. One build with platform f28 and shared-userspace nonfancy.
>  5. One build with platform f27 and shared-userspace nonfancy.
>  6. One build with platform f26 and shared-userspace nonfancy.
>  
>  We like this.
>  
>  --
>  
>  But, a new** corner case** emerges!  What if the *nonfancy* branch of
>  shared-userspace is only compatible with f27 and f28, but not with f26?
>  Build #6 will always fail - or, if it doesn’t fail it will be unusable.
>  
>  We thought through a number of ways that corner cases like these could be
>  handled automatically, and are still working through them.  At the moment, we
>  are *leaning towards* suggesting that a failing corner **requires** a new
>  stream of the module in question to handle the exclusion.  I.e., no convenient
>  syntax to say "all combinations except for this one".
>  
>  In this case, you would have two streams of the httpd-2.4 module:
>  httpd-2.4 and httpd-2.4_f26.  The first modulemd file in the
>  2.4 stream would be nice, like this:
>  
>   dependencies:
>      buildrequires:
>          platform: [f28, f27]
>          shared-userspace: [fancy, nonfancy]
>      requires:
>          platform: [f28, f27]
>          shared-userspace: [fancy, nonfancy]
>  
>  The second in the 2.4_f26 stream would exist only to support the desired
>  corner case:
>  
>   dependencies:
>      buildrequires:
>          platform: [f26]
>          shared-userspace: [fancy]
>      requires:
>          platform: [f26]
>          shared-userspace: [fancy]
>  
>  --
>  
>  We’re still working through more details, especially on this last part (and how
>  it may affect upgrades), but figured its best to share now.  Any help
>  appreciated!
>  
>  Yours-
>  -Ralph 
Thanks for posting this!

P

[Matthew Miller]

On Tue, Aug 08, 2017 at 09:04:40PM +0200, Petr Šabata wrote:
>    dependencies:
>      buildrequires: &deps
>        platform: [f28, f27, f26]
>        shared-userspace: [fancy, nonfancy]
>      requires: *deps
>  
>  Another point that came up later -- instead of shared-userspace,
>  imagine different streams of your favorite dynamic language.
>  That might make it the reasons for this more obvious. 
So, like:

  dependencies:                                                                           
            
    buildrequires: &deps                                                              
                
      platform: [f28, f27, f26]                                                           
            
      python: [2.7, 3.6]                                                              
    requires: *deps    


Hmmm, though. This doesn't really make sense if the module in question
just happens to use python. In that case, why build it for different
dependencies? Just pick one; the user won't care.

If on the other hand, the user *does* care (perhaps the module is a
framework where more stuff is then written in the underlying language,
so the user wants to choose). In that case, wouldn't we *want* that
surfaced into the stream name?

-- 
Matthew Miller
<mattdm(a)fedoraproject.org&gt;
Fedora Project Leader

[Petr Šabata]

On Tue, Aug 08, 2017 at 03:11:38PM -0400, Matthew Miller wrote:
>  On Tue, Aug 08, 2017 at 09:04:40PM +0200, Petr Šabata wrote:
>  >   dependencies:
>  >     buildrequires: &deps
>  >       platform: [f28, f27, f26]
>  >       shared-userspace: [fancy, nonfancy]
>  >     requires: *deps
>  > 
>  > Another point that came up later -- instead of shared-userspace,
>  > imagine different streams of your favorite dynamic language.
>  > That might make it the reasons for this more obvious.
>  
>  So, like:
>  
>    dependencies:                                                                          
>              
>      buildrequires: &deps                                                             
>                  
>        platform: [f28, f27, f26]                                                          
>              
>        python: [2.7, 3.6]                                                              
>      requires: *deps    
>  
>  
>  Hmmm, though. This doesn't really make sense if the module in question
>  just happens to use python. In that case, why build it for different
>  dependencies? Just pick one; the user won't care. 
If you pick one, you make your module unavailable to people
who chose to install the incompatible other on their system.
Building it (automatically!)  multiple times allows the user to
choose, rather then the developer forcing their choice onto them.

>  If on the other hand, the user *does* care (perhaps the module is a
>  framework where more stuff is then written in the underlying language,
>  so the user wants to choose). In that case, wouldn't we *want* that
>  surfaced into the stream name? 
No.  This allows us to ship the same build in multple
variants and no matter what platform and python (following the
abovementioned example) the user has installed, the right binary
variant of your module will be deployed.

If they decide to switch to another platform or python, your
application will be switched for the variant which is compatible
with those.  The variants will be distinguished by the context
flag, mostly in the background.

P

[Owen Taylor]

On Tue, 2017-08-08 at 13:39 -0400, Ralph Bean wrote:
>  ## Solution: "Input" Modulemd Syntax Changes
>  
>  We’re going to extend the modulemd syntax to allow specifying multiple
>  dependencies in an "input" modulemd (the one that packagers modify).  When
>  submitted to the build system, the module-build-service (MBS) will *expand*
>  these values under the hood, and submit **multiple** module builds to
>  itself based on the expansion. 
That sounds like a very powerful idea! 

I see two different possible motivations for this, one good, and one maybe not
so much.

The good: if you have a component like 'httpd' that's part of your
application,
it's pretty clear that you don't want your choice of httpd version to force you
into a particular Fedora platform and a particular version of all your other
components.

The bad: you have a Fedora system installed with the f27 version of the Host
module. You want to install an application on top of that, so you need to have
the application available built on the f27 runtime.

One reason I don't like the second motivation is that it feeds the thinking that
modules can be arbitrarily combined within the same namespace, and they cannot.
Even if two modules are built against the same runtime, the same version of
Python, they still can have conflicting versions of libraries. That's basically
the point of modularity.

But beyond that, if maintainers think that their application module has to be
built and tested against every active platform version (plus whatever other
combinatorial explosion users ask for), then any simplification that modularity
provides to packagers is gone, and instead people will be constantly fighting
library compatibility and adding conditionals, and generally tearing their hair
out.

So I think we need to be very clear in the expectations that we're setting for
module maintainers - that this is a new tool in the toolbox of a maintainer, not
a hoop that they have to jump through. And if it makes sense to package your
module as a container or a flatpak then that is an entirely satisfactory way to
handle combining your module with modules built on a different platform version.

Owen

[Nick Coghlan]

On 9 August 2017 at 03:39, Ralph Bean <rbean(a)redhat.com&gt; wrote:
>  ## Solution: "Input" Modulemd Syntax Changes
>
>  We’re going to extend the modulemd syntax to allow specifying multiple
>  dependencies in an "input" modulemd (the one that packagers modify).  When
>  submitted to the build system, the module-build-service (MBS) will *expand*
>  these values under the hood, and submit **multiple** module builds to
>  itself based on the expansion.
>
>  Here are some examples of modulemd files (maintained by humans) that might be
>  submitted to the MBS.
>
>  Build on **all** active streams of the platform module.
>      dependencies:
>          buildrequires:
>              platform: [] 
On the Python SIG list, we've recently been discussing how we'd like
the Python module streams to be defined for F28+ (since we don't want
to make any major changes to the F27 plans at this late date), and we
think we've spotted a potential problem with the described approach
(depending on how "active stream" gets defined): it isn't clear how we
would handle introducing new streams that we wanted to be explicitly
opt-in only rather than opt-out.

As a concrete example, the upstream Python 3.7 alpha & beta cycle will
be running in parallel with the F28 development cycle. It would be
beneficial to be able to create the corresponding module stream once
the first alpha release is available, but we don't really want anyone
else to implicitly start building against that stream until it hits
the release candidate phase (as upstream's typical API and ABI
stability guarantees don't apply until after the last beta release).

Two potential solutions to that occurred to us:

1. Have a stream metadata attribute that controlled whether or not a
branch was considered active for implicit dependency declarations
(e.g. "active: no")
2. Replacing the idea of depending on active streams with the idea of
depending on "stream tags", such that the stream metadata would
include something like "tags: [active]", and you'd depend on all the
streams in a stream tag the same way you currently depend on a single
stream: "platform: active"

Of the two, the second one seems more flexible, and has the added
bonus of offering support for "stream aliases", since you'd be able to
do things like "tags: [f26, f27]" (for example) to indicate that a
stream was the default in particular versions of Fedora.

For ease of adoption of stream expansion, there could also be a notion
of making "active" an implied tag for any non-EOL stream, such that
you'd have to opt-out explicitly to mark a stream *in*active: "tags:
[-active]"

Thoughts?

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan(a)gmail.com   |   Brisbane, Australia

[Matthew Miller]

On Wed, Aug 30, 2017 at 07:43:21PM +1000, Nick Coghlan wrote:
>  As a concrete example, the upstream Python 3.7 alpha & beta cycle
> will
>  be running in parallel with the F28 development cycle. It would be
>  beneficial to be able to create the corresponding module stream once
>  the first alpha release is available, but we don't really want anyone
>  else to implicitly start building against that stream until it hits
>  the release candidate phase (as upstream's typical API and ABI
>  stability guarantees don't apply until after the last beta release). 
I'm missing how this relates to the multiple targets problem here.
Wouldn't you want that alpha (and eventually final) to be available
across the different various bases?

I'd think the solution is simply to mark your module with "Service
Level: alpha" (and then we'd want some tooling where SL-alpha and
SL-beta modules only show up for those who ask for them.)


-- 
Matthew Miller
<mattdm(a)fedoraproject.org&gt;
Fedora Project Leader

[Nick Coghlan]

On 30 August 2017 at 21:56, Matthew Miller <mattdm(a)fedoraproject.org&gt; wrote:
>  On Wed, Aug 30, 2017 at 07:43:21PM +1000, Nick Coghlan wrote:
> > As a concrete example, the upstream Python 3.7 alpha & beta cycle will
> > be running in parallel with the F28 development cycle. It would be
> > beneficial to be able to create the corresponding module stream once
> > the first alpha release is available, but we don't really want anyone
> > else to implicitly start building against that stream until it hits
> > the release candidate phase (as upstream's typical API and ABI
> > stability guarantees don't apply until after the last beta release).
>
>  I'm missing how this relates to the multiple targets problem here.
>  Wouldn't you want that alpha (and eventually final) to be available
>  across the different various bases? 
Yes, but our concern isn't with the Python module's dependencies on
the Platform module, it's with *other* components that depend on the
Python module: if stream expansion were to pick up all non-EOL
branches as being "active", then it would be difficult to safely
bootstrap the streams for new feature releases (since other modules
would then start implicitly trying to build against them before they
were ready).

>  I'd think the solution is simply to mark your module with
> "Service
>  Level: alpha" (and then we'd want some tooling where SL-alpha and
>  SL-beta modules only show up for those who ask for them.) 
If the definition of active stream (for stream expansion purposes)
were to exclude SL-alpha (and maybe SL-beta) streams in addition to
EOL ones, then yes, I think that would handle my/our concerns, as then
there would be a way to indicate that a *new* streams should be
considered inactive without needing to set a misleading EOL date.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan(a)gmail.com   |   Brisbane, Australia

[Matthew Miller]

On Thu, Aug 31, 2017 at 08:11:56PM +1000, Nick Coghlan wrote:
>  Yes, but our concern isn't with the Python module's
> dependencies on
>  the Platform module, it's with *other* components that depend on the
>  Python module: if stream expansion were to pick up all non-EOL
>  branches as being "active", then it would be difficult to safely
>  bootstrap the streams for new feature releases (since other modules
>  would then start implicitly trying to build against them before they
>  were ready). 
From the presentation I saw yesterday, right now, there isn't an
"alpha" service level tag; "rawhide" is probably the closest. But if
we
added one, or even assuming just "rawhide", those SLs should be
inhereted into the downstream modules (and then presumably filtered out
for users who don't want that kind of thing).



>  > I'd think the solution is simply to mark your module with
> "Service
>  > Level: alpha" (and then we'd want some tooling where SL-alpha and
>  > SL-beta modules only show up for those who ask for them.)
>  If the definition of active stream (for stream expansion purposes)
>  were to exclude SL-alpha (and maybe SL-beta) streams in addition to
>  EOL ones, then yes, I think that would handle my/our concerns, as then
>  there would be a way to indicate that a *new* streams should be
>  considered inactive without needing to set a misleading EOL date. 
I think we'd probably _still_ want it active, because even if it fails,
it's nice to know that sooner rather than later. 

-- 
Matthew Miller
<mattdm(a)fedoraproject.org&gt;
Fedora Project Leader

[Nick Coghlan]

On 31 August 2017 at 22:09, Matthew Miller <mattdm(a)fedoraproject.org&gt; wrote:
>  On Thu, Aug 31, 2017 at 08:11:56PM +1000, Nick Coghlan wrote:
> > > I'd think the solution is simply to mark your module with "Service
> > > Level: alpha" (and then we'd want some tooling where SL-alpha and
> > > SL-beta modules only show up for those who ask for them.)
> > If the definition of active stream (for stream expansion purposes)
> > were to exclude SL-alpha (and maybe SL-beta) streams in addition to
> > EOL ones, then yes, I think that would handle my/our concerns, as then
> > there would be a way to indicate that a *new* streams should be
> > considered inactive without needing to set a misleading EOL date.
>
>  I think we'd probably _still_ want it active, because even if it fails,
>  it's nice to know that sooner rather than later. 
The case we're concerned about is the one at the start of
bootstrapping a new Python feature release where some of the virtual
environment management features are missing because the package
management tools haven't been built for that stream yet.

While the stream is in that state (which is only temporary, but still
a non-zero amount of time if we want to avoid relying on binaries
built from a previous stream), other build failures are reasonably
likely to be due to the bootstrapping being incomplete, which means
higher level module builds won't provide useful compatibility
information until the bootstrapping is complete and the stream is in a
"OK, this is expected to work normally now" state.

I believe this problem technically already exists with Rawhide today,
but hitting it requires folks to be submitting new Rawhide builds for
Python packages precisely while the Rawhide Python stack is in the
middle of being rebased.

If I correctly understand how it's going to work, the potential ripple
effect with the module build system is much worse, as the sequence of
events will be:

* partial build gets published while bootstrapping a new stream
* stream expansion detects a whole lot of higher level modules now
missing and submits builds for them
* those automatic builds all fail because the new stream wasn't ready
for them yet

So the request is for there to be a way to indicate that a stream is
available for explicit dependencies, but *shouldn't* be taken into
account for implicit stream expansion yet. Then, once the low level
stream is stable, *then* its maintainers can flick the switch to say
"OK, this looks healthy, start building new variants of all the
modules that depend on this one".

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan(a)gmail.com   |   Brisbane, Australia

[Matthew Miller]

On Fri, Sep 01, 2017 at 09:25:22PM +1000, Nick Coghlan wrote:
>  So the request is for there to be a way to indicate that a stream is
>  available for explicit dependencies, but *shouldn't* be taken into
>  account for implicit stream expansion yet. Then, once the low level
>  stream is stable, *then* its maintainers can flick the switch to say
>  "OK, this looks healthy, start building new variants of all the
>  modules that depend on this one". 
Okay, I get it now. :) I still think the Service Level field would be
useful here; maybe by policy dependent modules wouldn't be
auto-expanded against streams tagged as "alpha".

-- 
Matthew Miller
<mattdm(a)fedoraproject.org&gt;
Fedora Project Leader