Versions Compared

Old Version 2

changes.mady.by.user Will Stevens

Saved on

compared with

New Version Current

changes.mady.by.user Szymon Golebiewski

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

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).

...

On the https://tungstenfabric.github.io/website/ site, there are the following components:

  • Getting started with:
    • AWS - This is the 'Carbide' project.
      • Will Stevens : I have not had a chance to validate this processvalidated the state of this documentation.
    • CentOS
      • Resulting Kubernetes CNI Architecture
        Image Added
      • Will Stevens : I have spent quite a bit of time testing this process.  However, the manifest that is used in this process does not seem to be tied to the currently maintained manifest process.  It is unclear if the manifests documented in this process is maintained..
      • Will Stevens : For my own purposes, such as demos and feature validation, I have been maintaining cloudops/tf-demo, which automates the deployment of TF on cloud.ca.
        Below I outline a few items which I have struggled with when working with this deployment method:
        • The manifests which are maintained here are different from the documented manifests for this approach.  I had to generate the official manifests on a specific VM using this process (which unfortunately is specific to a single environment), then I did a manual diff with the documented manifest to create my own version which I then re-parameterized for my needs.  I would like to be able to dynamically build my manifest from a variables file so my manifest is not tracked separately from the official manifests.
        • I have been using this setup to illustrate cross-region connectivity between two independent K8s clusters.  I do this by creating two different k8s clusters using this deployer and then BGP peer the two environments together.  In order to do this, I needed to ensure that the IP space used for `pod`, `service` and `ip_fabric` are different in the two environments.  Unfortunately, Tungsten Fabric does not inherit the `kubeadm init` parameters of `--pod-network-cidr` and `--service-cidr` (at the time of this writing), so you have to update the config inside TF in order to set the IP ranges to the same as what was used in `kubeadm init`.  Recently, documentation has been added to describe the parameters which are available to be set.  In my case, I had to set the following additional params in the `KUBERNETES_POD_SUBNETS`, `KUBERNETES_SERVICE_SUBNETS` and `KUBERNETES_IP_FABRIC_SUBNETS` in the `kube-manager-config` ConfigMap.
        • By default, the instructions will set the `VROUTER_GATEWAY` parameter to the `K8S_MASTER_IP`, which unfortunately will not work.  Essentially, when the TF comes up it will break the host's networking stack with this config, so you will lose SSH access to the host.  In order to fix this, I set the `VROUTER_GATEWAY` to be the gateway for the network on which the `K8S_MASTER_IP` IP is part of.
        • In order to change the default password for the web UI (since my installs end up on the public internet), I needed to specify the `WEBUI_STATIC_AUTH_PASSWORD` param.
        • Unfortunately, I don't remember the details, but I needed to change one of the default ports for one of the databases deployed by the TF architecture because, by default, two different services were trying to use the same port.  I was able to fix this by reviewing the logs `contrail` logs on the host and then researching the different param options.
    •  Ubuntu
      • Resulting Kubernetes CNI Architecture
        Image Added
      Ubuntu
    • OpenStack
  • Deployment option not represented at the top level on this page:
    • Ansible Deployer for Kubernetes
      • Resulting Kubernetes CNI Architecture
        Image Added
      • 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 : I am still working to validate the documentation for this deployment option (travel and lack of remote access to my lab has slowed my progress... building VPN to address this moving forward).
      • 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
      • `yesac` from the TF Slack community wrote the following script to support his Ubuntu deployments using the Ansible Deployer: https://gist.github.com/csiens/f0457432efc513b44cf5d55ccd1194e7
      • Will Stevens : I have not validated the state of this documentation, but it appears to be actively maintained and should likely be added as a top level deployment option.
    • tungstenfabric/tf-devstack
      • Resulting Kubernetes CNI Architecture (expected, but not confirmed)
        Image Added
      • Will Stevens : I have not validated the state of this documentation had a chance to test this process yet, 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
      • I tried to install tf-devstack multiple times using multiple troubleshooting efforts to get the UI connected to the deployment without success and after repeated efforts to seek support from the associated development team, gave up (last attempt ca. 4 months ago).  I followed the installation instructions exactly as provided to do so on a local lab compute (Intel i7 NUC), but when requesting support, installation on AWS appeared to be the support responses I received.  When additional steps communicated as a fix for my issues did not fix my issue, I gave up as the help always started from zero and never provided a solution.  I was told that others are able to deploy it and no additional fixes were required.
      • 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:

...

  •   Work In Progress...  Please contribute if you know of documentation which is not represented here...