Performed in 2019, the below is a census of what documentation exists, where it lives at the time of the census, and its condition (up to date, out of date, etc).
The most visible entry point for documentation is the "Documentation" navigation entry on https://tungsten.io/, which directs the user to https://tungstenfabric.github.io/website/.
On the https://tungstenfabric.github.io/website/ site, there are the following components:
- Getting started with:
- Deployment option not represented at the top level on this page:
- Ansible Deployer for Kubernetes
- Will Stevens : I have not validated the state of this documentation, but I believe it should be added as a top level deployment option.
- Darien Hirotsu : Our GSoC intern (Nishita) and I have been working on the Ansible Deployer extensively testing against the bare metal provider. Here are some items we have discovered that might be of interest and that may help understand some of the other deployment options
- The appropriate branch must be used to deploy the appropriate version of Tungsten Fabric
- To deploy TF 5.0.1, you must use the 5.0 branch from GitHub of the Ansible playbooks (in our experience, we cannot install 5.1 from the 5.0 playbooks since container names have changed)
- I would guess this also applies to the existing currently maintained manifest process (i.e. you must deploy from the appropriate branch)
- The Ansible deployer does not use the currently maintained manifest
- I'm a little concerned this means we may end up with different behavior depending on the path a person takes when building out Tungsten Fabric
- Instead it uses a docker service command
- There are a few bugs to work out
- The example README shows the deployment in the incorrect order
- The playbooks should be run in the order of: configure_instances.yml, install_k8s.yml, install_contrail.yml
- There are issues with various versions that may be preventing us from deploying applications
- tungstenfabric/tf-devstack
- Will Stevens : I have not validated the state of this documentation, but I believe it should be added as a top level deployment option.
- Gary Greenberg would you be willing to add some sub-points to this section to provide some details on the experience of using `tf-devstack` and potentially document issues you feel should be addressed?
- tungstenfabric/tf-dev-env
- Will Stevens : I have not validated the state of this repo.. I am unclear to me how this repo compares with the `tungstenfabric/tf-devstack` and which should be the preferred dev environment. It is worth pointing out that this repo is a fork of the juniper/contrail-dev-env repo. It is unclear how these repos are maintained and what support the user can expect when using these repositories. From what I can tell, the juniper/contrail-dev-env repository was used to build the actual release. What is the plan for these repositories?
- A major challenge today is that the manifests which are tracked in this repo are not versioned, so it is impossible to know what are the appropriate manifests for a specific version of TF.
- Tungsten Fabric Architecture
- Becoming a contributor:
- In general, the details on this page are very focused on the process to contribute to the Juniper repositories and their Gerrit (https://review.opencontrail.org). Given the fact that the actual code repos are still in Juniper, it is painfully confusing what should be documented for contributing to the code today. We have a mix of both Juniper specific details and Tungsten Fabric assets on this page, and it is extremely unclear what is relevant and what is not.
- I (Will Stevens) recommend that we clearly call out the fact that the code is in the process of moving and the process and location of the different assets and processes associated with them are documented separately.
- Current code location, OpenContrail (Juniper Repos)
- Target code location, Tungsten Fabric (LF Repos)
- New features are introduced to the TF community through use of Blueprints.
- Blueprints are tracked in Jira here: https://jira.tungsten.io/projects/TFP (which will redirect you to one of the blueprints)
- Blueprints should be associated with a Spec. The spec is a detailed technical document which outlines the technical details associated with the feature/function change.
- Specs are tracked in this repo: https://github.com/Juniper/contrail-specs
- While the Blueprints track the intent, the actual work is tracked in Jira in the following section: https://jira.tungsten.io/projects/TFB (again, this will redirect to a specific issue)
- Despite the Specs being tracked in Github, all the contribution is expected to be done through Gerrit. This is likely a point of confusion...
- The Contribution Process
- All the code is managed through Gerrit (either the old or new Gerrit), despite all of the repositories being published on Github.
- In order to contribute, you must first sign one of the CLAs. The CLA must be associated with the contributors account in Gerrit as a CLA is a gating function for being able to accept contribution.
- ICLA - Is the 'Individual' contributor license agreement and is used when your organization does not have a CCLA which you can be associated with.
- CCLA - Is the 'Corporate' contributor license agreement and is used to associate many contributors within an organization to a single legal agreement.
- Once you have a CLA, you will need to install git-review to properly format and submit merge requests against the repositories in Gerrit.
- While somewhat outdated and very OpenContrail specific, the best documentation I have found which describes the contribution process is this: https://github.com/Juniper/contrail-community-docs/blob/master/Contributor/GettingStarted/getting-started-with-opencontrail-development.md
- Additional Documentation Resources
Work In Progress... Please contribute if you know of documentation which is not represented here...