odcs

Clone

#394 doc: describe how ODCS determines the latest modules
Merged 3 years ago by lsedlar. Opened 3 years ago by ktdreyer.
ktdreyer/odcs doc-latest-modules  into  master

file modified
+1 -1 
@@ -165,7 +165,7 @@ 
 

      Number defining the type of ``source`` giving it particular meaning:
 

  

      - 1 (``tag``) - The ``source`` is name of Koji tag to take the builds from. Additional Koji builds can be added by when the ``builds`` option is set.
 

-     - 2 (``module``) - The ``source`` is the list of modules in ``N:S``, ``N:S:V`` or ``N:S:V:C`` format. When using ``N:S`` format, the latest version found in MBS is used. When using ``N:S`` or ``N:S:V``, the module needs to be in the ``ready`` state in the MBS. When using ``N:S:V:C``, the module can be even in the ``done`` state in the MBS.
 

+     - 2 (``module``) - The ``source`` is the list of modules in ``N:S``, ``N:S:V`` or ``N:S:V:C`` format. When using ``N:S`` format, ODCS queries MBS to find the latest build of the module for that stream. ODCS will query MBS for the latest module in the ``ready`` state unless the user sets the ``include_done_modules`` flag. When using ``N:S:V:C``, the module can be even in the ``done`` state in the MBS.
 

      - 3 (``repo``) - The ``source`` is full path to repository from which the packages are taken. This is often disabled source type by deployed ODCS servers.
 

      - 4 (``pulp``) - The ``source`` is the list of Pulp content-sets. Repositories defined by these content-sets will be included in the compose.
 

      - 5 (``raw_config``) - The ``source`` is string in the ``name#commit`` hash format. The ``name`` must match one of the raw config locations defined in ODCS server config as ``raw_config_urls``. The ``commit`` is commit hash defining the version of raw config to use. This config is then used as input config for Pungi.

file modified
+10 
@@ -48,6 +48,16 @@ 
 

  make composes unnecessary big. You can use "hybrid" compose described
 

  later in this doc.
 

  

+ Selecting modules
 

+ -----------------
 

+ 

+ If you specify a ``name:stream`` without specifying a ``version:context``,
 

+ ODCS will query MBS to find the very latest ``version:context`` build. For
 

+ example, if you specify ``go-toolset:rhel8``, ODCS will query MBS for the
 

+ latest ``go-toolset`` module build for the ``rhel8`` stream, whereas if you
 

+ specify ``go-toolset:rhel8:8020020200128163444:0ab52eed``, ODCS will compose
 

+ that exact module instead.
 

+ 

  Generating compose with cherry-picked Koji builds
 

  =================================================

My team and I had trouble understanding OSBS and ODCS behavior when building a container using modules. This pull request updates the documentation to clarify how ODCS chooses a module to compose.

Specifically, this clarifies that ODCS will choose whatever latest module happens to be present in the buildsystem for a given NAME:STREAM.

rebased onto 12980102ad8b6b50b83866927445a50a68d94c6e
3 years ago

I have a similar pull request lined up for the OSBS docs as well (branch is https://github.com/ktdreyer/osbs-docs/commits/modules). I'll submit the PR for that one after this one merges.

I would add change it to this: "... the module needs to be in the "ready" state (unless include_done_modules flag is specified) ..."

Otherwise +1.

I agree with Jan's suggestion, mentioning that might be helpful.

I agree with Jan's suggestion, mentioning that might be helpful.

@ktdreyer thanks for sending this MR. We were struggling with modules in the last 2 weeks and this addition helps to understand better how it works. +1

I'm ok with mentioning the ready state thing, but this leads into another problem: It is very hard to know what the "ready" state means. In order to understand this sentence, users must learn MBS' build states (which are different than Koji's build states!)

For example, does "ready" mean "the module is gold-signed, shipped to users and customers, and ready for layered products to use"?

2 new commits added

  • doc: clarify API behavior with ODCS querying MBS
  • doc: describe how ODCS determines the latest modules
3 years ago

I've updated this pull request to say "ODCS will query MBS for the latest module in the ready state unless the user sets the include_done_modules flag."

I've opened a few tickets to make MBS state information easier to understand,
https://pagure.io/fm-orchestrator/issue/1628, https://pagure.io/fm-orchestrator/issue/1629

:thumbsup: Thanks a lot!

rebased onto b021f6d
3 years ago

Pull-Request has been merged by lsedlar
3 years ago
Changes Summary 2
+1 -1
file changed
docs/api.rst
+10 -0
file changed
docs/client.rst
Powered by Pagure 5.13.3
Documentation • File an Issue • About • SSH Hostkey/Fingerprint
© Red Hat, Inc. and others.