From 4696f82af307836548e66daf0ae08ab5a755d9ea Mon Sep 17 00:00:00 2001 From: "github-actions[bot]" Date: Mon, 11 Nov 2024 00:07:52 +0000 Subject: [PATCH] Updates --- community/core/community/README.md/index.html | 2 +- community/core/community/SUPPORT_POLICY.md/index.html | 2 +- community/core/community/governance.md/index.html | 2 +- community/core/community/help-wanted.md/index.html | 2 +- community/core/community/liaisons.md/index.html | 2 +- community/core/community/sig-devsecops/README.md/index.html | 2 +- community/core/community/sig-devsecops/charter.md/index.html | 4 ++-- .../core/community/sig-observability/README.md/index.html | 4 ++-- .../core/community/sig-observability/charter.md/index.html | 2 +- .../core/community/sig-stack-guidance/README.md/index.html | 4 ++-- .../core/community/sig-stack-guidance/charter.md/index.html | 2 +- .../core/community/sig-user-experience/README.md/index.html | 4 ++-- .../core/community/sig-user-experience/charter.md/index.html | 2 +- community/core/community/wg-cnbi/README.md/index.html | 2 +- community/core/community/wg-cnbi/charter.md/index.html | 2 +- community/core/docs/ROADMAP.md/index.html | 4 ++-- .../index.html | 2 +- .../core/docs/adr/0001-use-gpl3-as-license.md/index.html | 4 ++-- community/core/docs/adr/0002-release-policy.md/index.html | 4 ++-- .../core/docs/adr/0003-decommision-qeb-hwt.md/index.html | 4 ++-- .../core/docs/adr/0004-naming-convention-images.md/index.html | 4 ++-- .../index.html | 2 +- .../core/docs/adr/0005-obtimizing-keb-runs.md/index.html | 2 +- .../core/docs/adr/0006-thoth-github-action.md/index.html | 2 +- community/core/docs/adr/0007-scorecard-metrics.md/index.html | 2 +- community/core/docs/adr/template.md/index.html | 2 +- .../index.html | 4 ++-- .../index.html | 4 ++-- .../detecting-lincenses-of-python-modules.md/index.html | 2 +- .../generate-prescription-from-text.md/index.html | 2 +- .../intern-projects/prescriptions-bootstrap.md/index.html | 2 +- community/core/docs/sprint-demos/35.md/index.html | 2 +- community/core/docs/sprint-demos/37.md/index.html | 4 ++-- community/core/docs/sprint-demos/38.md/index.html | 2 +- community/core/docs/sprint-demos/39.md/index.html | 2 +- community/core/docs/sprint-demos/README.md/index.html | 2 +- community/index.html | 4 ++-- index.html | 4 ++-- metrics/index.html | 2 +- page-data/sq/d/1276261476.json | 2 +- support/faq/overview.mdx/index.html | 2 +- support/faq/thoth_yaml.mdx/index.html | 2 +- support/index.html | 2 +- support/issue_tracker.mdx/index.html | 2 +- 44 files changed, 58 insertions(+), 58 deletions(-) diff --git a/community/core/community/README.md/index.html b/community/core/community/README.md/index.html index 0c64a99219..a554eee84f 100644 --- a/community/core/community/README.md/index.html +++ b/community/core/community/README.md/index.html @@ -14,7 +14,7 @@ - }
Thoth Logo

Project Thoth

Repository configuration

The github-config.yaml file contains the details of the + }

Thoth Logo

Project Thoth

Repository configuration

The github-config.yaml file contains the details of the GitHub configuration for our organization.

This file is used by Peribolos to apply the configuration to the various repositories. Check the Peribolos diff --git a/community/core/community/SUPPORT_POLICY.md/index.html b/community/core/community/SUPPORT_POLICY.md/index.html index 58a47a6b87..51bf528517 100644 --- a/community/core/community/SUPPORT_POLICY.md/index.html +++ b/community/core/community/SUPPORT_POLICY.md/index.html @@ -14,7 +14,7 @@ - }

Thoth Logo

Project Thoth

Support Policy

This document outlines the support policy for Project Thoth. For general information how and where to contact us, + }

Thoth Logo

Project Thoth

Support Policy

This document outlines the support policy for Project Thoth. For general information how and where to contact us, please see our help page.

Supported Runtime Environments

When adding new content to Thoth’s Knoweldge Graph, we follow (roughly) the following policy:

  1. what runtime is used by RHODS/Open Data Hub? Right now most data science work is based on ubi8-py38
  2. what runtime is the latest release and maintained by Red Hat? ubi9-py39
  3. based on our research (py311 due to perf incr.), see also https://www.phoronix.com/review/python-311-performance

End of Life

We will disable solvers and the corresponding Python versions when they reach end of life. The data aggregated by Project Thoth will be kept in the Knowledge Graph for as long as possible. We will not delete data from the Ceph storage, but might disable its use for advises.

Contribute to this page
\ No newline at end of file diff --git a/community/core/community/governance.md/index.html b/community/core/community/governance.md/index.html index f386fb05d7..1812e7b3a5 100644 --- a/community/core/community/governance.md/index.html +++ b/community/core/community/governance.md/index.html @@ -14,7 +14,7 @@ - }
Thoth Logo

Project Thoth

Principles

The Thoth Station community adheres to the following principles:

  • Open: Project Thoth is open source. See repository guidelines, below.
  • Welcoming and respectful: See Code of Conduct, below.
  • Transparent and accessible: Work and collaboration should be done in public. See SIG governance, below.
  • Merit: Ideas and contributions are accepted according to their technical merit and alignment with project objectives, [scope], and [design principles].

Code of Conduct

The Thoth Station community abides by [out code of conduct]:

As contributors and maintainers of this project, and in the interest of fostering an open and welcoming community, we pledge to respect all people who contribute through reporting issues, posting feature requests, updating documentation, submitting pull requests or patches, and other activities.

As a member of the project, you represent the project and your fellow contributors. + }

Thoth Logo

Project Thoth

Principles

The Thoth Station community adheres to the following principles:

  • Open: Project Thoth is open source. See repository guidelines, below.
  • Welcoming and respectful: See Code of Conduct, below.
  • Transparent and accessible: Work and collaboration should be done in public. See SIG governance, below.
  • Merit: Ideas and contributions are accepted according to their technical merit and alignment with project objectives, [scope], and [design principles].

Code of Conduct

The Thoth Station community abides by [out code of conduct]:

As contributors and maintainers of this project, and in the interest of fostering an open and welcoming community, we pledge to respect all people who contribute through reporting issues, posting feature requests, updating documentation, submitting pull requests or patches, and other activities.

As a member of the project, you represent the project and your fellow contributors. We value our community tremendously and we’d like to keep cultivating a friendly and collaborative environment for our contributors and users. We want everyone in the community to have [positive experiences].

Community groups

The project is comprised of the following types of subgroups:

  • Special Interest Groups, SIGs
    • Subprojects

SIGs

The project is organized primarily into Special Interest diff --git a/community/core/community/help-wanted.md/index.html b/community/core/community/help-wanted.md/index.html index e5cca88510..fc8633e769 100644 --- a/community/core/community/help-wanted.md/index.html +++ b/community/core/community/help-wanted.md/index.html @@ -20,7 +20,7 @@ - }Help Wanted and Good First Issue Labels | Thoth Station Help

Thoth Logo

Project Thoth

Help Wanted and Good First Issue Labels

Overview

We use two labels to identify issues that have been specifically created or selected for new contributors: help wanted and good first + }Help Wanted and Good First Issue Labels | Thoth Station Help

Thoth Logo

Project Thoth

Help Wanted and Good First Issue Labels

Overview

We use two labels to identify issues that have been specifically created or selected for new contributors: help wanted and good first issue. The good first issue label is a subset of the help wanted label, indicating that members have committed to providing extra assistance for new contributors. All good first issue items also have the help wanted diff --git a/community/core/community/liaisons.md/index.html b/community/core/community/liaisons.md/index.html index a419d30781..dce3f9f8f8 100644 --- a/community/core/community/liaisons.md/index.html +++ b/community/core/community/liaisons.md/index.html @@ -14,7 +14,7 @@ - }

Thoth Logo

Project Thoth

Liaisons

Each community group or SIG of Project Thoth assigned a Steering Committee + }

Thoth Logo

Project Thoth

Liaisons

Each community group or SIG of Project Thoth assigned a Steering Committee liaison. Liaisons act as a point of contact from steering, engage with their respective community groups to ensure they are healthy and facilitate communication.

Liaisons do not make decisions for the community group or on behalf of diff --git a/community/core/community/sig-devsecops/README.md/index.html b/community/core/community/sig-devsecops/README.md/index.html index b7f5ff2be3..c9e416e914 100644 --- a/community/core/community/sig-devsecops/README.md/index.html +++ b/community/core/community/sig-devsecops/README.md/index.html @@ -14,7 +14,7 @@ - }

Thoth Logo

Project Thoth

DevSecOps Special Interest Group

HIBERNATION NOTICE: This SIG is currently hibernating. If you are interested in reviving this SIG, please reach out to the Thoth team via an issue in the the core or support repository. + }

Thoth Logo

Project Thoth

DevSecOps Special Interest Group

HIBERNATION NOTICE: This SIG is currently hibernating. If you are interested in reviving this SIG, please reach out to the Thoth team via an issue in the the core or support repository. This SIG covers all the tools and supporting container images that deliver Thoth-Station applications, as well as the build pipelines and Continuous Integration systems that enable the automated builds. This includes the discussion related to the release process of the Thoth-Station applications, the build pipelines themselves, supporting container images, tooling, and architectural decisions.

The charter defines the scope and governance of the DevSecOps Special Interest Group.

Leadership

Chairs

The Chairs of the SIG run operations and processes governing the SIG.

Technical Leads

The Technical Leads of the SIG establish new subprojects, decommission existing subprojects, and resolve cross-subproject technical issues and decisions.

Contact

Subprojects

The following subprojects are owned by sig-devsecops:

Notebooks

A set of base images that are useful for Data Science work

Pipelines

A set of base images and pipelines to build application container images

Services

Tooling and configuration to manage the releases of various Thoth services and components

Contribute to this page
\ No newline at end of file diff --git a/community/core/community/sig-devsecops/charter.md/index.html b/community/core/community/sig-devsecops/charter.md/index.html index f77af98d90..d1a4825cf4 100644 --- a/community/core/community/sig-devsecops/charter.md/index.html +++ b/community/core/community/sig-devsecops/charter.md/index.html @@ -14,8 +14,8 @@ - }
Thoth Logo

Project Thoth

SIG DevSecOps Charter

This charter adheres to the conventions described in the Kubernetes Charter README and uses the Roles and Organization Management outlined in sig-governance. For all things taken from the Kubernetes community, we use scaled down variants, Kubernetes documents are references.

Scope

This SIG covers all the tools and supporting container images that deliver Thoth-Station + }

Thoth Logo

Project Thoth

SIG DevSecOps Charter

This charter adheres to the conventions described in the Kubernetes Charter README and uses the Roles and Organization Management outlined in sig-governance. For all things taken from the Kubernetes community, we use scaled down variants, Kubernetes documents are references.

Scope

This SIG covers all the tools and supporting container images that deliver Thoth-Station applications, as well as the build pipelines and Continuous Integration systems that enable the automated builds.

This includes the discussion related to the release process of the Thoth-Station applications, the build pipelines themselves, supporting container images, tooling, -and architectural decisions.

In scope

  • Pipelines to build and publish application container images
  • Supporting container images
  • End-user oriented content about Thoth pipelines and supporting images
  • GitOps configurations to deploy the services
  • Release management for Thoth-Station

Out of scope

  • Operation of the clusters that host the services

Roles and Organization Management

This sig follows adheres to the Roles and Organization Management outlined in sig-governance.

Subproject Creation

SIG Chairs can create subprojects without requiring member votes.

Contribute to this page
\ No newline at end of file +and architectural decisions.

In scope

  • Pipelines to build and publish application container images
  • Supporting container images
  • End-user oriented content about Thoth pipelines and supporting images
  • GitOps configurations to deploy the services
  • Release management for Thoth-Station

Out of scope

  • Operation of the clusters that host the services

Roles and Organization Management

This sig follows adheres to the Roles and Organization Management outlined in sig-governance.

Subproject Creation

SIG Chairs can create subprojects without requiring member votes.

Contribute to this page
\ No newline at end of file diff --git a/community/core/community/sig-observability/README.md/index.html b/community/core/community/sig-observability/README.md/index.html index 26ed1f3d64..163fe01a26 100644 --- a/community/core/community/sig-observability/README.md/index.html +++ b/community/core/community/sig-observability/README.md/index.html @@ -14,6 +14,6 @@ - }
Thoth Logo

Project Thoth

Observability Special Interest Group

HIBERNATION NOTICE: This SIG is currently hibernating. If you are interested in reviving this SIG, please reach out to the Thoth team via an issue in the the core or support repository. + }

Thoth Logo

Project Thoth

Observability Special Interest Group

HIBERNATION NOTICE: This SIG is currently hibernating. If you are interested in reviving this SIG, please reach out to the Thoth team via an issue in the the core or support repository. Work on all things that concern Observability! This includes the definition of metrics, monitoring, reporting and alerting.

The charter defines the scope and governance of the Observability Special Interest Group.

Leadership

Chairs

The Chairs of the SIG run operations and processes governing the SIG.

Technical Leads

The Technical Leads of the SIG establish new subprojects, decommission existing -subprojects, and resolve cross-subproject technical issues and decisions.

Contact

Subprojects

The following subprojects are owned by sig-observability:

Monitoring

Contribute to this page
\ No newline at end of file +subprojects, and resolve cross-subproject technical issues and decisions.

Contact

Subprojects

The following subprojects are owned by sig-observability:

Monitoring

Contribute to this page
\ No newline at end of file diff --git a/community/core/community/sig-observability/charter.md/index.html b/community/core/community/sig-observability/charter.md/index.html index 6cba99001d..37db7a5b47 100644 --- a/community/core/community/sig-observability/charter.md/index.html +++ b/community/core/community/sig-observability/charter.md/index.html @@ -14,6 +14,6 @@ - }
Thoth Logo

Project Thoth

SIG Observability Charter

This charter adheres to the conventions described in the Kubernetes Charter README and uses + }

Thoth Logo

Project Thoth

SIG Observability Charter

This charter adheres to the conventions described in the Kubernetes Charter README and uses the Roles and Organization Management outlined in sig-governance. For all things taken from the Kubernetes community, we use scaled down variants, Kubernetes documents are references.

Scope

Work on all things that concerns Observability! This includes the definition of metrics, monitoring, reporting and alerting.

Roles and Organization Management

This sig follows adheres to the Roles and Organization Management outlined in sig-governance.

Subproject Creation

SIG Chairs can create subprojects without requiring member votes.

Contribute to this page
\ No newline at end of file diff --git a/community/core/community/sig-stack-guidance/README.md/index.html b/community/core/community/sig-stack-guidance/README.md/index.html index 94ab3d906f..7517bb87dc 100644 --- a/community/core/community/sig-stack-guidance/README.md/index.html +++ b/community/core/community/sig-stack-guidance/README.md/index.html @@ -14,5 +14,5 @@ - }
Thoth Logo

Project Thoth

Stack Guidance Special Interest Group

HIBERNATION NOTICE: This SIG is currently hibernating. If you are interested in reviving this SIG, please reach out to the Thoth team via an issue in the the core or support repository. -Work on recommending the most effective, performant and secure software stack for user applications and on actively creating prescriptions and security related information

The charter defines the scope and governance of the Stack Guidance Special Interest Group.

Leadership

Contact

Subprojects

The following subprojects are owned by sig-stack-guidance:

adviser

prescriptions

solver

storages

Contribute to this page
\ No newline at end of file + }
Thoth Logo

Project Thoth

Stack Guidance Special Interest Group

HIBERNATION NOTICE: This SIG is currently hibernating. If you are interested in reviving this SIG, please reach out to the Thoth team via an issue in the the core or support repository. +Work on recommending the most effective, performant and secure software stack for user applications and on actively creating prescriptions and security related information

The charter defines the scope and governance of the Stack Guidance Special Interest Group.

Leadership

Contact

Subprojects

The following subprojects are owned by sig-stack-guidance:

adviser

prescriptions

solver

storages

Contribute to this page
\ No newline at end of file diff --git a/community/core/community/sig-stack-guidance/charter.md/index.html b/community/core/community/sig-stack-guidance/charter.md/index.html index f65c685f7a..cb3a4e9036 100644 --- a/community/core/community/sig-stack-guidance/charter.md/index.html +++ b/community/core/community/sig-stack-guidance/charter.md/index.html @@ -14,4 +14,4 @@ - }
Thoth Logo

Project Thoth

SIG Stack Guidance Charter

This charter adheres to the conventions described in the Kubernetes Charter README and uses the Roles and Organization Management outlined in sig-governance. For all things taken from the Kubernetes community, we use scaled down variants, Kubernetes documents are references.

Scope

This includes the discussion related to recommending the most effective, performant and secure software stack for user applications and on actively creating prescriptions and security related information.

Roles and Organization Management

This sig follows adheres to the Roles and Organization Management outlined in sig-governance.

Subproject Creation

SIG Chairs can create subprojects without requiring member votes.

Contribute to this page
\ No newline at end of file + }
Thoth Logo

Project Thoth

SIG Stack Guidance Charter

This charter adheres to the conventions described in the Kubernetes Charter README and uses the Roles and Organization Management outlined in sig-governance. For all things taken from the Kubernetes community, we use scaled down variants, Kubernetes documents are references.

Scope

This includes the discussion related to recommending the most effective, performant and secure software stack for user applications and on actively creating prescriptions and security related information.

Roles and Organization Management

This sig follows adheres to the Roles and Organization Management outlined in sig-governance.

Subproject Creation

SIG Chairs can create subprojects without requiring member votes.

Contribute to this page
\ No newline at end of file diff --git a/community/core/community/sig-user-experience/README.md/index.html b/community/core/community/sig-user-experience/README.md/index.html index a63118a3ce..bafd5674aa 100644 --- a/community/core/community/sig-user-experience/README.md/index.html +++ b/community/core/community/sig-user-experience/README.md/index.html @@ -14,6 +14,6 @@ - }
Thoth Logo

Project Thoth

User Experience Special Interest Group

HIBERNATION NOTICE: This SIG is currently hibernating. If you are interested in reviving this SIG, please reach out to the Thoth team via an issue in the the core or support repository. + }

Thoth Logo

Project Thoth

User Experience Special Interest Group

HIBERNATION NOTICE: This SIG is currently hibernating. If you are interested in reviving this SIG, please reach out to the Thoth team via an issue in the the core or support repository. The User Experience SIG focuses on the interaction points between end users and Thoth components.

The charter defines the scope and governance of the User Experience Special Interest Group.

Leadership

Chairs

The Chairs of the SIG run operations and processes governing the SIG.

Technical Leads

The Technical Leads of the SIG establish new subprojects, decommission existing -subprojects, and resolve cross-subproject technical issues and decisions.

Contact

Subprojects

The following subprojects are owned by sig-user-experience:

jupyterlab-requirements

kebechet

s2i-thoth

thamos

user-api

Contribute to this page
\ No newline at end of file +subprojects, and resolve cross-subproject technical issues and decisions.

Contact

Subprojects

The following subprojects are owned by sig-user-experience:

jupyterlab-requirements

kebechet

s2i-thoth

thamos

user-api

Contribute to this page
\ No newline at end of file diff --git a/community/core/community/sig-user-experience/charter.md/index.html b/community/core/community/sig-user-experience/charter.md/index.html index 733c49c50a..76f7e52110 100644 --- a/community/core/community/sig-user-experience/charter.md/index.html +++ b/community/core/community/sig-user-experience/charter.md/index.html @@ -14,7 +14,7 @@ - }
Thoth Logo

Project Thoth

SIG User Experience Charter

This charter adheres to the conventions described in the Kubernetes Charter README and uses + }

Thoth Logo

Project Thoth

SIG User Experience Charter

This charter adheres to the conventions described in the Kubernetes Charter README and uses the Roles and Organization Management outlined in Kuberentes’ sig-governance. For all things taken from the Kubernetes community, we use scaled down variants, Kubernetes documents are references.

Scope

The goal of this SIG is to ensure that the entry points to Thoth provide a great user experience.

This includes the interaction with human users (be it though direct component diff --git a/community/core/community/wg-cnbi/README.md/index.html b/community/core/community/wg-cnbi/README.md/index.html index 264683aac2..d7f1ad1e7e 100644 --- a/community/core/community/wg-cnbi/README.md/index.html +++ b/community/core/community/wg-cnbi/README.md/index.html @@ -14,5 +14,5 @@ - }

Thoth Logo

Project Thoth

CNBi Working Group

HIBERNATION NOTICE: This WG is currently hibernating. If you are interested in reviving this WG, please reach out to the Thoth team via an issue in the the core or support repository. + }

Thoth Logo

Project Thoth

CNBi Working Group

HIBERNATION NOTICE: This WG is currently hibernating. If you are interested in reviving this WG, please reach out to the Thoth team via an issue in the the core or support repository. The goal of this working group is to create a service that implements the backend side of the Custom Notebook Image (CNBi) MVP in the context of Open Data Hub (ODH).

The charter defines the scope and governance of the CNBi Working Group.

Stakeholder SIGs

  • SIG DevSecOps
  • SIG Stack Guidance
  • SIG User Experience

Organizers

  • Christoph Görn (@goern), Red Hat

Contact

Contribute to this page
\ No newline at end of file diff --git a/community/core/community/wg-cnbi/charter.md/index.html b/community/core/community/wg-cnbi/charter.md/index.html index d3f8e274db..b1034dae4b 100644 --- a/community/core/community/wg-cnbi/charter.md/index.html +++ b/community/core/community/wg-cnbi/charter.md/index.html @@ -14,4 +14,4 @@ - }
Thoth Logo

Project Thoth

WG Custom Notebook Image (CNBi) Charter

The goal of this working group (WG) is to design and implement an MVP for the backend side of the Custom Notebook Image (CNBi) functionality of Open Data Hub (ODH).

The WG is a continuation of the work of the BYON WG. The work produced by the working group aims at meeting the requirements specified in the RHODS epics about the functionality, including:

For reference, deliverables for phase 1 (BYON) were tracked in the byon repository and its corresponding project planning board.

Scope

The focus of this WG is on the backend components that handle the creation, validation, and importing of container images for use into ODH, as well as the software stack guidance service provided to the users of these images.

In scope

  • The CNBi operator
  • Tekton Pipeline definitions that implement the CNBi / BYON functionality
  • Thoth APIs that contribute to the requirements of the CNBi functionality on ODH
  • Coordination with ODH in integrating the funtcionality
  • Deployment of the PoC and coordination with Operate First and OS-Climate on its usage

Out of scope

  • ODH User Interface design and implementation

Stakeholders

  • Thoth SIGs:
    • DevSecOps
    • Stack Guidance
    • User Experience
  • ODH SIGs:
    • ML-DevExp
    • Platform

Deliverables

  • Documentation of the design of the backend, the components involved, the interactions between them, and the interface between ODH and the backend.
  • An evolution of the meteor operator that acts as the main controller for the CNBi functionality.
  • A set of Tekton / OpenShift pipelines definitions that implement the functionality.
  • A working PoC of the operator and pipelines, with ODH integration when available, ready to use by a target group: the OS-Climate project.

Disband criteria

If stakeholder SIGs and the WG decide all features described in the In Scope section are complete and no more discussions and investigations are needed in this WG, they may decide to disband this WG.

Contribute to this page
\ No newline at end of file + }
Thoth Logo

Project Thoth

WG Custom Notebook Image (CNBi) Charter

The goal of this working group (WG) is to design and implement an MVP for the backend side of the Custom Notebook Image (CNBi) functionality of Open Data Hub (ODH).

The WG is a continuation of the work of the BYON WG. The work produced by the working group aims at meeting the requirements specified in the RHODS epics about the functionality, including:

For reference, deliverables for phase 1 (BYON) were tracked in the byon repository and its corresponding project planning board.

Scope

The focus of this WG is on the backend components that handle the creation, validation, and importing of container images for use into ODH, as well as the software stack guidance service provided to the users of these images.

In scope

  • The CNBi operator
  • Tekton Pipeline definitions that implement the CNBi / BYON functionality
  • Thoth APIs that contribute to the requirements of the CNBi functionality on ODH
  • Coordination with ODH in integrating the funtcionality
  • Deployment of the PoC and coordination with Operate First and OS-Climate on its usage

Out of scope

  • ODH User Interface design and implementation

Stakeholders

  • Thoth SIGs:
    • DevSecOps
    • Stack Guidance
    • User Experience
  • ODH SIGs:
    • ML-DevExp
    • Platform

Deliverables

  • Documentation of the design of the backend, the components involved, the interactions between them, and the interface between ODH and the backend.
  • An evolution of the meteor operator that acts as the main controller for the CNBi functionality.
  • A set of Tekton / OpenShift pipelines definitions that implement the functionality.
  • A working PoC of the operator and pipelines, with ODH integration when available, ready to use by a target group: the OS-Climate project.

Disband criteria

If stakeholder SIGs and the WG decide all features described in the In Scope section are complete and no more discussions and investigations are needed in this WG, they may decide to disband this WG.

Contribute to this page
\ No newline at end of file diff --git a/community/core/docs/ROADMAP.md/index.html b/community/core/docs/ROADMAP.md/index.html index 14e1f67429..aa002d867a 100644 --- a/community/core/docs/ROADMAP.md/index.html +++ b/community/core/docs/ROADMAP.md/index.html @@ -14,7 +14,7 @@ - }
Thoth Logo

Project Thoth

Thoth Roadmap

After the current and coordinated release of Thoth’s components, we started this document to outline our + }

Thoth Logo

Project Thoth

Thoth Roadmap

After the current and coordinated release of Thoth’s components, we started this document to outline our current focus areas and the major items we are working on.

For a more detailed overview of our current activities, have a look at our GitHub projects. We use them to plan our sprints.

Informative Advice

Based on a command line tool and our GitHub App we will extend the advice we give to human developers. This @@ -34,4 +34,4 @@ Tekton catalog, and enables Python application developers to integrate Thoth Service consuming tasks (for example a Python module provenance check, or Security report) into their OpenShift and Tekton Pipelines.

Jupyter Requirements Management

Jupyter tools focused on the Data Scientist workflow have been created to help them with dependencies management:

They feature similar functionality as thamos, but embedding the dependencies and the locked dependencies within the meta information -of the Jupyter Notebook file itself together with creating dependencies files in the requested requirement formats.

Contribute to this page
\ No newline at end of file +of the Jupyter Notebook file itself together with creating dependencies files in the requested requirement formats.

Contribute to this page
\ No newline at end of file diff --git a/community/core/docs/adr/0000-use-markdown-architectural-decision-records.md/index.html b/community/core/docs/adr/0000-use-markdown-architectural-decision-records.md/index.html index 04f33e5d1a..7f4bfb276b 100644 --- a/community/core/docs/adr/0000-use-markdown-architectural-decision-records.md/index.html +++ b/community/core/docs/adr/0000-use-markdown-architectural-decision-records.md/index.html @@ -14,4 +14,4 @@ - }
Thoth Logo

Project Thoth

Use Markdown Architectural Decision Records

Context and Problem Statement

We want to record architectural decisions made in Project Thoth. Which format and structure should these records follow?

Considered Options

Decision Outcome

Chosen option: “MADR 2.1.2”, because

  • Implicit assumptions should be made explicit.

    Design documentation is important to enable people understanding the decisions later on.

    See also A rational design process: How and why to fake it.

  • The MADR format is lean and fits our development style.

  • The MADR structure is comprehensible and facilitates usage & maintenance.

  • The MADR project is vivid.

  • Version 2.1.2 is the latest one available when starting to document ADRs.

Contribute to this page
\ No newline at end of file + }
Thoth Logo

Project Thoth

Use Markdown Architectural Decision Records

Context and Problem Statement

We want to record architectural decisions made in Project Thoth. Which format and structure should these records follow?

Considered Options

Decision Outcome

Chosen option: “MADR 2.1.2”, because

  • Implicit assumptions should be made explicit.

    Design documentation is important to enable people understanding the decisions later on.

    See also A rational design process: How and why to fake it.

  • The MADR format is lean and fits our development style.

  • The MADR structure is comprehensible and facilitates usage & maintenance.

  • The MADR project is vivid.

  • Version 2.1.2 is the latest one available when starting to document ADRs.

Contribute to this page
\ No newline at end of file diff --git a/community/core/docs/adr/0001-use-gpl3-as-license.md/index.html b/community/core/docs/adr/0001-use-gpl3-as-license.md/index.html index e3ecf4e928..ba00d25916 100644 --- a/community/core/docs/adr/0001-use-gpl3-as-license.md/index.html +++ b/community/core/docs/adr/0001-use-gpl3-as-license.md/index.html @@ -14,7 +14,7 @@ - }
Thoth Logo

Project Thoth

Use GNU GPL as license

Everything needs to be licensed, otherwise the default copyright laws apply. + }

Thoth Logo

Project Thoth

Use GNU GPL as license

Everything needs to be licensed, otherwise the default copyright laws apply. For instance, in Germany that means users may not alter anything without explicitly asking for permission. For more information see https://help.github.com/articles/licensing-a-repository/.

We want to have all source code related to Project Thoth to be used without any hassle and as free as possible, so that -users can just execute and enjoy the four freedoms.

Considered Options

Decision Outcome

Chosen option: “GNU GPL”, because this license supports a strong copyleft model.

Contribute to this page
\ No newline at end of file +users can just execute and enjoy the four freedoms.

Considered Options

Decision Outcome

Chosen option: “GNU GPL”, because this license supports a strong copyleft model.

Contribute to this page
\ No newline at end of file diff --git a/community/core/docs/adr/0002-release-policy.md/index.html b/community/core/docs/adr/0002-release-policy.md/index.html index 5896f3f5b6..7a2796c882 100644 --- a/community/core/docs/adr/0002-release-policy.md/index.html +++ b/community/core/docs/adr/0002-release-policy.md/index.html @@ -14,9 +14,9 @@ - }
Thoth Logo

Project Thoth

Project Thoth Release Policy

  • Status: proposed
  • Date: 2020-Nov-04

Technical Story: As an Open Source project, we want to document the policies and guideline on how we create a new + }

Thoth Logo

Project Thoth

Project Thoth Release Policy

  • Status: proposed
  • Date: 2020-Nov-04

Technical Story: As an Open Source project, we want to document the policies and guideline on how we create a new release.

Context and Problem Statement

Project Thoth itself consists of many components all having their own release cycles and delivery artifacts such as container image or Python libraries.

Considered Options

  • a monolithic, coordinated release of all components by creating a tag within the thoth-application repository
  • have a rolling release, and no tags on any repository

Decision Outcome

Chosen option: we do a monolithic, coordinated release, because it will enable us to have a release at the project/product level while maintianing freedom of others to update.

Positive Consequences

  • users have a clear base line of versions, these versions have been tested with each other and have undergone integration testing.
  • a release can be referenced from documents, so that operational procedures have a clear relationship with component -versions being used
  • we can maintain sets of different versions for different deployment environments
  • we can provide a version string with each API provided by the project

Negative Consequences

  • A release might not contain the latest versions of components
Contribute to this page
\ No newline at end of file +versions being used
  • we can maintain sets of different versions for different deployment environments
  • we can provide a version string with each API provided by the project

    • Negative Consequences

    • A release might not contain the latest versions of components
    Contribute to this page
    \ No newline at end of file diff --git a/community/core/docs/adr/0003-decommision-qeb-hwt.md/index.html b/community/core/docs/adr/0003-decommision-qeb-hwt.md/index.html index 1e5d284e2f..ff88b8588d 100644 --- a/community/core/docs/adr/0003-decommision-qeb-hwt.md/index.html +++ b/community/core/docs/adr/0003-decommision-qeb-hwt.md/index.html @@ -14,7 +14,7 @@ - }
    Thoth Logo

    Project Thoth

    Decommission Qeb-Hwt GitHub App

    Technical Story: Decommision Qeb-Hwt GitHub App

    Context and Problem Statement

    Qeb-Hwt is a GitHub Application which adds thamos advise based output to + }

    Thoth Logo

    Project Thoth

    Decommission Qeb-Hwt GitHub App

    Technical Story: Decommision Qeb-Hwt GitHub App

    Context and Problem Statement

    Qeb-Hwt is a GitHub Application which adds thamos advise based output to Pull Requests as a check. This functionality could be integrated into https://github.com/marketplace/khebhut and complexity and maintain costs.

    Decision Drivers

    • cost of maintaining Qeb-Hwt code and app
    • redundancy of infrastructure

    Considered Options

    • keep and maintain Qeb-Hwt
    • merge function into Khebhut

    Decision Outcome

    Chosen option: “merge function into Khebhut”, because we can reduce the cost of maintaining our software infrastructure -by reducing redundancy.

    Contribute to this page
    \ No newline at end of file +by reducing redundancy.

    Contribute to this page
    \ No newline at end of file diff --git a/community/core/docs/adr/0004-naming-convention-images.md/index.html b/community/core/docs/adr/0004-naming-convention-images.md/index.html index c32d5f6b26..955fd58e0c 100644 --- a/community/core/docs/adr/0004-naming-convention-images.md/index.html +++ b/community/core/docs/adr/0004-naming-convention-images.md/index.html @@ -14,11 +14,11 @@ - }
    Thoth Logo

    Project Thoth

    Project Thoth Naming Convention Schema for Images

    • Status: proposed
    • Date: 2021-Jun-17

    Technical Story: As Thoth goal to provide curated stack and images, it would be nice to have a convention for naming of the images.

    Context and Problem Statement

    Image names are important for branding and let others identify easily a specific image they need. For example “I want to work on computer vision project with Tensorflow, what stack and image should I use?” Having a trusted well maintained source of images with clean naming convention can help on that.

    Considered Options

    • s2i-{application} standard name currently, but not everyone knows what S2I is.
    • odh-{application} for branding/marketing having ODH in front seems to be the best solution, in this way the name will be shorter as well.
    • ps-{application} as it shows what our intention is: we want to provide a curated/predictable software stack, it might be used by ODH or RHODS or others, it might use S2I or other technology. Moreover helps from pipeline creation point of view, because the length of repo name on quay can crate issues.

    These names are for the core repository name, then overlays will allow for combinations of libraries based on other criteria, for example ml_framework and/or hardware:

    `ps-nlp`
+      }
    Thoth Logo
    Project Thoth
    Project Thoth Naming Convention Schema for Images
    • Status: proposed
    • Date: 2021-Jun-17
    Technical Story: As Thoth goal to provide curated stack and images, it would be nice to have a convention for naming of the images.
    Context and Problem Statement
    Image names are important for branding and let others identify easily a specific image they need. For example “I want to work on computer vision project with Tensorflow, what stack and image should I use?” Having a trusted well maintained source of images with clean naming convention can help on that.
    Considered Options
    • s2i-{application} standard name currently, but not everyone knows what S2I is.
    • odh-{application} for branding/marketing having ODH in front seems to be the best solution, in this way the name will be shorter as well.
    • ps-{application} as it shows what our intention is: we want to provide a curated/predictable software stack, it might be used by ODH or RHODS or others, it might use S2I or other technology. Moreover helps from pipeline creation point of view, because the length of repo name on quay can crate issues.
    These names are for the core repository name, then overlays will allow for combinations of libraries based on other criteria, for example ml_framework and/or hardware:
    `ps-nlp`
 ├── overlays                    # Overlays structure for builds
 │   ├── ps-nlp-tensorflow          # NLP image with TensorFlow ML framework
 │   ├── ps-nlp-tensorflow-gpu      # NLP image with TensorFlow ML framework for GPU
 │   ├── ps-nlp-pytorch             # NLP image with Pytorch ML framework
 │   ├── ps-nlp-pytorch-gpu         # NLP image with Pytorch ML framework for GPU
 │   └── ps-nlp-scikit-learn        # NLP image with Scikit-learn ML framework
-└── ...
    Decision Outcome
    Selected option: ps-{application} as it shows what our intention is: we want to provide a curated/predictable software stack, it might be used by ODH or RHODS or others, it might use S2I or other technology. Moreover helps from pipeline creation point of view, because the length of repo name on quay can crate issues.
    Positive Consequences 
    • users can immediately select an image based on the application they want.
    • using overlays we can have a variety of combination, not just for ml_framework
    Negative Consequences 
    • N/A
    Contribute to this page
    
\ No newline at end of file
+└── ...

    Decision Outcome

    Selected option: ps-{application} as it shows what our intention is: we want to provide a curated/predictable software stack, it might be used by ODH or RHODS or others, it might use S2I or other technology. Moreover helps from pipeline creation point of view, because the length of repo name on quay can crate issues.

    Positive Consequences

    • users can immediately select an image based on the application they want.
    • using overlays we can have a variety of combination, not just for ml_framework

    Negative Consequences

    • N/A
    Contribute to this page
    \ No newline at end of file diff --git a/community/core/docs/adr/0005-automatically-bump-container-image-versions.md/index.html b/community/core/docs/adr/0005-automatically-bump-container-image-versions.md/index.html index 0cad813325..6d414c565d 100644 --- a/community/core/docs/adr/0005-automatically-bump-container-image-versions.md/index.html +++ b/community/core/docs/adr/0005-automatically-bump-container-image-versions.md/index.html @@ -14,4 +14,4 @@ - }
    Thoth Logo

    Project Thoth

    Automatically bump the version of base images used to generate container images

    • Status: proposed
    • Date: 2022-02-15

    Technical Story: As a maintainer of Thoth, I would like to automatically update the version of the base images used to generate new container images of some components (see: https://github.com/thoth-station/kebechet/issues/991)

    Context and Problem Statement

    When new base image versions used to genereate container images for Thoth components are released on Quay, it would be practical to update them automatically instead of manually opening Bump <component name> to vx.y.z in <environment> pull requests in the concerned repositories (Example: https://github.com/thoth-station/thoth-application/pull/2314).

    Considered Options

    • Implement a simple Python script to bump the base image versions used to deliver container images in .aicoe-ci.yaml, .thoth.yaml or similar files for eventual uses outside of the project.
      • 1) Integrate this script in the AICoE-CI pipeline logic
      • 2) Integrate this script in Kebechet

    Decision Outcome

    Chosen option: 1). For the moment, this script has been integrated in the AICoE-CI pipeline logic, but it could eventually be reused in Kebechet if needed.

    Positive Consequences

    • Keeping the base image versions we use up-to-date for active repositories.
    • Base image version updates are made automatically, which is less error-prone and time-consuming for developers compared to making the update manually.

    Links

    Contribute to this page
    \ No newline at end of file + }
    Thoth Logo

    Project Thoth

    Automatically bump the version of base images used to generate container images

    • Status: proposed
    • Date: 2022-02-15

    Technical Story: As a maintainer of Thoth, I would like to automatically update the version of the base images used to generate new container images of some components (see: https://github.com/thoth-station/kebechet/issues/991)

    Context and Problem Statement

    When new base image versions used to genereate container images for Thoth components are released on Quay, it would be practical to update them automatically instead of manually opening Bump <component name> to vx.y.z in <environment> pull requests in the concerned repositories (Example: https://github.com/thoth-station/thoth-application/pull/2314).

    Considered Options

    • Implement a simple Python script to bump the base image versions used to deliver container images in .aicoe-ci.yaml, .thoth.yaml or similar files for eventual uses outside of the project.
      • 1) Integrate this script in the AICoE-CI pipeline logic
      • 2) Integrate this script in Kebechet

    Decision Outcome

    Chosen option: 1). For the moment, this script has been integrated in the AICoE-CI pipeline logic, but it could eventually be reused in Kebechet if needed.

    Positive Consequences

    • Keeping the base image versions we use up-to-date for active repositories.
    • Base image version updates are made automatically, which is less error-prone and time-consuming for developers compared to making the update manually.

    Links

    Contribute to this page
    \ No newline at end of file diff --git a/community/core/docs/adr/0005-obtimizing-keb-runs.md/index.html b/community/core/docs/adr/0005-obtimizing-keb-runs.md/index.html index cc9441a40d..2d5a0a7419 100644 --- a/community/core/docs/adr/0005-obtimizing-keb-runs.md/index.html +++ b/community/core/docs/adr/0005-obtimizing-keb-runs.md/index.html @@ -14,7 +14,7 @@ - }
    Thoth Logo

    Project Thoth

    {short title of solved problem and solution}

    • Status: proposed
    • Deciders: @KPostOffice @fridex @cgoern
    • Date: 2022-3-15 when the decision was last updated}

    Technical Story: Kebechet#873

    Context and Problem Statement

    Kebechet is being run too often and is eagerly eating resources in cluster. We need to pare down how often we spin up + }

    Thoth Logo

    Project Thoth

    {short title of solved problem and solution}

    • Status: proposed
    • Deciders: @KPostOffice @fridex @cgoern
    • Date: 2022-3-15 when the decision was last updated}

    Technical Story: Kebechet#873

    Context and Problem Statement

    Kebechet is being run too often and is eagerly eating resources in cluster. We need to pare down how often we spin up pods to do repository management.

    Decision Drivers

    • Less pods being spun up.
    • Reduce frequency of reaching GitHub API quota limit

    Considered Options

    • Option 1: Filter web-hooks in thoth-user-api
    • Option 2: Create Kebechet deployment receives web-hooks and only runs specific manager(s) depending on contents
    • Option 3: Create individual repositories and GitHub applications for each manager
    • Option 4: create GitHub app for each repo and choose auth at run time

    Decision Outcome

    Chosen option: “option 3”, because we can use existing bot frameworks and github event handlers such as gidgethub(Python) and probot(JavaScript). This should help reduce cluster load as pods will be shorter lived and less frequent, however, it does require multiple small deployments for handling web-hooks.

    Implementing option 2 and option 4 might be another good solution.

    Positive Consequences

    • Reduced resource consumption
    • More apps means more quota
    • Each app’s behavior is well defined. It’s at times unclear what “Kebechet” is

    Negative Consequences

    • Follow up decisions required: “What technologies do we use?”, “How do we manage configuration?”
    • Transition from maintaining list of managers to installing individual managers

    Pros and Cons of the Options

    Option 1: Filter web-hooks in thoth-user-api