ODS 3.0 Work Packages - opendevstack/PMC GitHub Wiki

Release timeline: Early July 2020.

Table of Contents:

Work Packages with owners

Provide modern SPA user interface

Owner(s): @netzartist, @stitakis / Size: L / Benefit: Improve overall user experience + better maintainability through modern tech stack / **Ticket(s): #518 / Status: in progress

Revamp both look & feel (using modern usability best practices) and code (using Angular v9, Typescript + modern CSS implementations).

ODS Dev Env and E2E Test

Owners(s): @georgfedermann and @stitakis / Size: XL / Benefit: High increase of consistency & developerment productivity / Details: https://github.com/opendevstack/PMC/wiki/ODS-3.0-Dev-Env-and-E2E-Tests / Status: in-progress

Full automated creation of a virtual machine with full installed ODS version + dependencies (Atlassian stack)

E2E Tests will assure that the ODS installation is done properly and is fully functional

Completed Work Packages

Separate quickstarter config in prov-app from application properties

Owner(s): @stitakis / Size: M / Benefit: Easier installation and use of own quickstarters / Ticket(s): #363 / Status: Done

Quickstarters are configured in the application.properties ConfigMap, which makes it hard to compare the contents of this resource, and therefore makes it hard to configure your own, local, quickstarters. The configuration should be elsewhere (options are: other ConfigMap, mounted file, reading from Git repo)

Refactor provisioning app authentication

Owner(s): @oalyman, @stitakis / Size: L / Benefit: Better security / **Ticket(s): #424, #375,#376, #365, #444 / Status: Done

Users should not need to enter their password in the prov-app, but rather authenticate via OpenID Connect. Further, the prov-app should use a technical user to communicate with other services such as Jira, Bitbucket, etc. if possible

QS code coverage reporting (especially important for SQ)

Owner(s): @michaelsauter / Size: M / Benefit: Consistency / Ticket(s): #213

Testing Image Build

Owner(s): @henrjk, @oalyman, @michaelsauter / Size: M / Benefit: Reliable images, more confidence in changes / Ticket(s): ?

Write automated tests for all images (Jenkins master/slave/webhook-proxy, SonarQube). Ideally for CentOS and RHEL. Run e.g. in Travis or Github Actions.

Tailor deploy in component pipeline

Owner(s): @michaelsauter / Size: M / Benefit: Aligned with MRO, allow infrastructure-as-code / Ticket(s): #96

Allow to build multiple deployments / one deployment with multiple containers from one repository.

Provide prebuilt images of provisioning app and documentation generation service

Owner(s): @oalyman / Size: M / Benefit: Simplify ODS installation / Ticket(s): #419

Allows user to consume them without building. Done already for prov-app. Investigate if possible for other things like Jenkins master/slave.

Move provisioning app to central CD namespace

Owner(s): @oalyman / Size: M / Benefit: Simplify ODS installation / Ticket(s): ?

Most ODS users do not develop on the provisioning app, therefore ODS should ship with just one provisioning app, located in the central CD namespace by default. That would also mean we have one running Jenkins in the central CD namespace which will make it easier to build custom images (such as docgen) easily. Users who also want to develop the provisioning app should be provided an alternative way to still develop on the prov app. This change requires a modification of the shared library as well to allow deployment into the cd namespace. We should also think about using this opportunity to rename the central namespace from cd to ods.

Merge MRO in shared lib

Owner(s): @michaelsauter / Size: M / Benefit: Consistency / Ticket(s): ?

Monorepo support

Owner(s): @clemensutschig / Size: L / Benefit: Support typical use case better / Ticket(s): #222

Documentation re-organisation, extension, cleanup ...

Owner(s): @michaelsauter / Size: M / Benefit: Easier to find relevant information; clearer for contributors / Ticket(s): #20, #25, #24, ...

The documentation has actually three main target groups: users (people who create projects and build components using quickstarters), administrators (maintaining an OpenDevStack installation) and contributors (developers working on OpenDevStack itself). The documentation should reflect this. Further, where documentation is written (location of the files, how they are linked etc.) is still a bit unclear and can be improved.

SonarQube Pull Request integration

Owner(s): @michaelsauter / Size: M / Benefit: Improve code quality, bring SonarQube closer into feedback loop / Ticket(s): #174

Annotate pull requests with feedback from SonarQube.

Quickstarter Pipeline

Owner(s): @michaelsauter / Size: M / Benefit: Improve consistency, make it easier to author quickstarters / Ticket(s): #230

Proper Quota Support for build environment pods

Owner(s): @michaelsauter / Size: S / Benefit: Less resources used, easier to adapt to different needs for users / Ticket(s): #173

Build slaves should have CPU and memory constraints assigned (fitting to the requirements of the language/framework used). The shared library should expose an easy way to customise those constraints.

Good Scala quickstarter

Owner(s): @oalyman / Size: S / Benefit: More useful Scala quickstarter / Ticket(s): #115

Using Play framework. Retirement of Akka based quickstarter.

Project Provisioning Testing

Owner(s): @hugowschneider, ? / Size: M / Benefit: Reliable provisioning, more confidence in changes / Ticket(s): #342, #343, #341

Write automated tests for project creation. Should probably be E2E tests mostly. Run e.g. in Travis or Github Actions.

Initiate Shared Library Testing

Owner(s): @renedupont / Size: M / Benefit: Reliable pipelines, more confidence in changes / Ticket(s): #149, #146

Initiate Quickstarter Testing

Owner(s): @hugowschneider / Size: M / Benefit: Reliable quickstarters, more confidence in changes / Ticket(s): ?

Should probably be E2E tests mostly, ideally all the way from provisioning through to running component. Run in Github Actions. There are two parts of this:

  1. Test quickstarter provisioning. This is the "easy" part, and should be almost the same for all quickstarters: we need to run the pipeline and ensure that the repo is created and has the expected files in it.
  2. Test quickstarter building. This is the difficult part as it involves lots of services such as Nexus / SonarQube and differs between each quickstarter.

We will focus to get (1) done for now as that already provides huge value.

Gateway quickstarter

Owner(s): @gerardcl / Size: M / Benefit: Plug-and-play gateway quickstarter / Ticket(s): #56

  • Solution provided is based on nginx/openResty + Lua, which was already used within ODS users: be-gateway-nginx
  • More gateways could be added by following agreed naming convention: be-gateway-tech

Suggested Work Packages which did NOT find owners yet

Proper templating for quickstarters

Owner(s): ? / Size: S / Benefit: Easier to write and modify quickstarters / Ticket(s): #15

Instead of sed replacements, use a proper templating approach to render e.g. Jenkinsfile.template or sonar-project.properties.template. This could also benefit other, custom files in quickstarters.

GitHub Changelog Automation

Owner(s): ? / Size: S / Benefit: Quicker to create a release / Ticket(s): #197

The changelog should be auto-generated from pull requests so that no manual process is required.

Component Health Checks

Owner(s): ? / Size: M / Benefit: Zero-downtime rolling deployments / Ticket(s): #11

Add a /health endpoint to each quickstarter and configure a readiness check against it.

Nexus configuration / installation

Owner(s): ? / Size: M / Benefit: Easier installation / Ticket(s): ?

There are some configuration examples / scripts, but they are hard to use (only from outdated VM setup). It would be good to update the scripts, and allow them to be used easily for VM/non-VM setups, e.g. by exposing them as a Makefile target. #423

Revamp local setup

Owner(s): ? / Size: M / Benefit: Easier installation / Ticket(s): ?

It should be easy to install ODS locally - using the new Makefile targets and revamped infrastructure setup.

Revamp infrastructure setup

Owner(s): ? / Size: M / Benefit: Easier installation / Ticket(s): ?

Setting up Atlassian should be brought up-to-date and integrated into the rest of the setup.

Execute MRO on slave

Owner(s): ? / Size: M / Benefit: Less issues with state, fewer hacks in code / Ticket(s): ?

Right now the MRO jumps between slave (for OpenShift interaction) and master. This requires lots of hacks, and is quite brittler. Further, I believe it to be best-practice to do all work in a slave to avoid dealing with lots of state on the master node.

Discussion Points

Merge MRO and shared library

We have two Jenkins shared libraries: ods-jenkins-shared-library and ods-mro-jenkins-shared-library. I propose to have just one repo:

  • Both use the same language and similar dependencies. Having both in one repo makes it easier to manage this.
  • Both should use the same approach (architecture) and style (CodeNarc) to make it easy for developers to understand and contribute
  • ods-jenkins-shared-library already offers two pipelines: one for component, one for quickstarters. We could easily offer a third for orchestration
  • There is lots of duplicated code with minor modifications (e.g. interaction with OpenShift, Bitbucket, ...)
  • There is a huge interdependency between both. Both have an unwritten contract - what the MRO expects of the component pipeline. This leads to brittleness. Evidence: often changes require a PR in both repos, and the versions between both need to be aligned.

Central document generation service

Right now each project gets a generation service when the "release-manager" quickstarter is provisioned.

Pros:

  • Each service only gets requests from one project, so load is low
  • Each project can customise whatever they want (right now the only easy to spot knob is to customise the location of the templates)

Cons:

  • Quickstarter does setup in the *-cd project which no other quickstarter does
  • Uses lots of resources
  • Load is probably not that high given that only requests would only be initiated from developers, which is a relatively low number
  • Updating deployed services is hard because ODS does not reach into projects
  • Customisation (e.g. of templates) might not even be wanted.

Given the list of cons, I propose to go with a centrally deployed service (like SonarQube, Nexus, ...). That still allows people to deploy there own service if really needed, but lifts the burden of everyone who does not want that, and makes it easier for admins to maintain.

Horizon / Potential topics for v4.0

  • Image Scanning and runtime protection (Aqua Security?) -> @rdupont
  • OpenShift 4 support (should come, but no urgent need right now, maybe in second half of 2020)
  • Project specific Nexus and SonarQube access (currently feels like it needs more time/input)