Have questions? Stuck? Please check our FAQ for some common questions and answers.

This page should be removed!

Brigade Leads:

Brigade Members:

Contact the brigade:

Scope:

  • Make sure that ONOS code-base(s) can be built efficiently, reliably and consistently into a small set of distributable artifacts to make it easy to distribute and deploy ONOS

  • Make sure that ONOS SDK can be built and released efficiently, reliably and consistently as a set of published artifacts on Maven Central and ONOS project site

  • Maintenance of the build and release process documentation

  • Maintenance of the corresponding user (network administrator) documentation

  • Maintenance of the corresponding developer SDK documentation

  • Development and maintenance of the build, test and run-time tool kits for developers, testers and users (network administrators)

  • Development and maintenance of the CI process and release process and supporting tools and working with the team managing the infrastructure

  • Integration of CI with basic functionality tests (STC) as part of the build & release processes

  • Maintenance and upstreaming of Gerrit plugins (Module Owner, Stats, Project Lock)

  • Maintenance of Shared Cells Warden

  • Investigation (and later execution) of how to disaggregate the ONOS code-base, while continuing the ability to build & release with regular (and frequent) cadence

  • Development and maintenance of the ONOS archetypes (Maven + Buck)

  • Deprecation and removal of the legacy build framework

  • Move artifacts versions to follow semantic versioning


Work week ( Apr 24 ~ 26, 2017 )

Priority Tasks

Pre-ONS

  • Continue deprecation of legacy build framework

    • Scrub Wiki documentation

    • Update affected screencasts (in progress)

    • Prune CI jobs

  • Investigate code-base disaggregation

    • Propose workspace / workflow management tools (e.g. Repo)

    • Propose specific repository divisions

    • Propose workspace directory structure

    • Produce timeline for transition, solicit feedback, present to TST

      • Including draining or migration of existing code review backlog

    • Experiment with snapshot/subset of codebase for experience

  • Investigate build tool deficiencies

    • Look into Buck deficiencies and ONOS’ fork diffs

    • Look into build in the context of multiple/different workspaces (i.e. full code, standalone app)

    • Investigate other Blaze-related tools to see if they overcome limitations more easily

    • Produce build framework recommendation, solicit feedback, present to TST

    • Start developing fixes for any deficiencies or new features for proposed build tool

    • Experiment with snapshot/subset of codebase for experience

Post-ONS

  • Fix build framework as per suggestions of investigation

  • Execute code-base disaggregation plan

  • Document workflow for development and release

    • Including full code (build apps, drivers, core together) and standalone (build part against release artifacts)

  • Complete deprecation of legacy build framework

    • Remove all but the top-level pom.xml files

  • Consider moving publish to entirely standalone Python script (away from Buck)

  • Begin work on distribution-specific packages (e.g. deb, RPM, Docker container, tutorial and release VMs, etc.)



Notes


Run-Time Distribution Artifacts & Formats

  • platform neutral onos.tar.gz, onos-test.tar.gz

  • various platform specific packages and/or recipes

    • e.g. deb, rpm, Docker, snap, Ansible, Puppet

SDK Distribution Artifacts

  • API jar bundles (+javadocs, +tests)

  • Libraries & Utilities jar bundles (+javadocs, +tests)

  • Java API docs on api.onosproject.org

  • REST API docs on rest.onosproject.org - later

  • Archetypes for developing external ONOS apps buildable by Maven and Buck


Document capturing initial thoughts : https://docs.google.com/document/d/1Hdl-ZsttECXZEucskoPNghwsv_H68dtnTnRZrDWgVsg/edit


How to get involved:

  • No labels