Merge pull request #3 from nokia/add-readme

Add readme

README.md

@@ -0,0 +1,21 @@
+# Anuket Reference Implementation based on RA1 specifications (RI1)
+
+This repo contains the source for the
+[Reference Implementation based on RA1 specifications (RI1)](https://cntt.readthedocs.io/projects/ri1/en/latest/index.html).
+
+## Issues
+
+Issues for this repo are handled in the
+[anuket-project/anuket-specifications](https://github.com/anuket-project/anuket-specifications/issues) repository. 
+
+# Pull Requests
+
+Pull requests are welcome in [this repository](https://github.com/anuket-project/RI1/pulls). For the contribution guide
+please follow [this](https://github.com/anuket-project/anuket-specifications/blob/master/CONTRIBUTING.rst) link.
+
+# Terms of Reference & License
+
+-  [Terms of Reference](https://github.com/anuket-project/anuket-specifications/blob/master/doc/GSMA_CNTT_Terms_of_Reference.pdf)
+-  [Code of Conduct](https://github.com/anuket-project/anuket-specifications/blob/master/doc/CODE_OF_CONDUCT.rst)
+-  License of the Anuket Specifications project is [Creative Commons Attribution 4.0 International](https://creativecommons.org/licenses/by/4.0/legalcode)
+

doc/ref_impl/cntt-ri/chapters/chapter04.rst

@@ -69,7 +69,7 @@ Lab Use Guidelines
 
 OPNFV will facilitate the need for lab procurement, as required, for projects which come into their front door for verification and validation.
 
-Individual companies that donated a lab would be responsible for setup and maintenance of a community lab. Labs, once setup, will be shared and posted in a wiki https://wiki.opnfv.org/display/pharos/Community+Labs.
+Individual companies that donated a lab would be responsible for setup and maintenance of a community lab. Labs, once setup, will be shared and posted in a wiki https://wiki.anuket.io/display/HOME/Community+Labs.
 
 The wiki will contain information such as:
 

doc/ref_impl/cntt-ri/chapters/chapter08.rst

@@ -148,7 +148,7 @@ The below table summarizes the configurable parameters under PDF. Most of these
 +------------------------------------------------+
 | type: {production, development}                |
 +------------------------------------------------+
-| link: http://wiki.opnfv.org/                   |
+| link: https://wiki.anuket.io                   |
 +------------------------------------------------+
 | \*\* #node*\*                                  |
 +------------------------------------------------+
@@ -279,7 +279,7 @@ The manifests are divided into three layers: global, type, and site. They are hi
 
 The global and type manifests can be used *as is* unless any major differences from a reference deployment are required. In the latter case, this may introduce a new type, or even contributions to the global manifests.
 
-The site manifests are specific for each site and are required to be customized for each new deployment. The specific documentation for customizing these documents is located here - https://wiki.opnfv.org/display/AIR/Airship+Manifest+Creation+For+New+Sites
+The site manifests are specific for each site and are required to be customized for each new deployment. The specific documentation for customizing these documents is located here - https://wiki.anuket.io/display/HOME/Airship+Manifest+Creation+For+New+Sites
 
 Mainly, the customization is done for the following categories:
 
@@ -345,7 +345,7 @@ After Installation, perform the following:
 Install
 '''''''
 
-As Airship is tooling to declaratively automate site deployment, the automation from the installer side is light. See `deploy.sh <https://github.com/opnfv/airship/blob/master/tools/deploy.sh>`__. User will need to export environment variables that correspond to the new site (keystone URL, node IPs, and so on). All these are captured in the site environment file - as described in the `wiki page <https://wiki.opnfv.org/display/AIR/Airship+Manifest+Creation+For+New+Sites>`__
+As Airship is tooling to declaratively automate site deployment, the automation from the installer side is light. See `deploy.sh <https://github.com/opnfv/airship/blob/master/tools/deploy.sh>`__. User will need to export environment variables that correspond to the new site (keystone URL, node IPs, and so on). All these are captured in the site environment file - as described in the `wiki page <https://wiki.anuket.io/display/HOME/Airship+Manifest+Creation+For+New+Sites>`__
 Once the Genesis node is setup, and the manifests are created, user can execute deploy.sh that supports (Shipyard) actions: deploy_site and update_site. Along with the action, the deploy script also take the site name (ex: intel-pod10). The deploy.sh script is part of the opnfv-airship repository. The steps to run the deploy script are as follows.
 
 .. code:: bash
@@ -413,7 +413,7 @@ Once the software is successfully deployed, and the deploy.sh script terminates
 In addition to that, users can also use these links to track the metrics and logs, respectively:
 
 Steps and procedures for installing and setting up the RI.
-Start pulling in content from: https://wiki.opnfv.org/display/AIR/Airship+Installer+Deployment+Guide
+Start pulling in content from: https://wiki.anuket.io/display/HOME/Airship+Installer+Deployment+Guide
 
 .. code:: bash
 

doc/ref_impl/cntt-ri/chapters/chapter09.rst

@@ -153,7 +153,7 @@ Traffic Generators & NIC
 
 Performance, or load testing, may (will) require specific NICs to achieve desired throughput (TPS, kbps, etc) to properly validate an instance-types (e.g. Basic(B)) stability when subject to traffic.
 
-For example, the OPNFV project, `NFVBench <https://wiki.opnfv.org/display/nfvbench/NFVbench>`__, utilizes the `TRex <https://trex-tgn.cisco.com/>`__ traffic generator. While TRex offers stateful and stateless testing, achieves 200-400 Gb/sec, and captures latency/jitter measurements, there is a dependency on the type of NICs to be utilized to achieve optimal results:
+For example, the now archived Anuket project, `NFVBench <https://wiki.anuket.io/display/HOME/NFVbench>`__, utilizes the `TRex <https://trex-tgn.cisco.com/>`__ traffic generator. While TRex offers stateful and stateless testing, achieves 200-400 Gb/sec, and captures latency/jitter measurements, there is a dependency on the type of NICs to be utilized to achieve optimal results:
 
 -  Recommended NICs to utilize when adopting the NFVBench project (& TRex) include Intel X710 (10G), XXV710 (25G) and XL710 (40G).