Change repo links to from Azure/DASH to sonic-net/DASH (#321)

* Update config file

* Changed GitHub URLs per move from Azure/DASH to sonic-net/DASH.
grep -rnl --include=*.py  --include=*.md --include=*.svg 'github.com/Azure/DASH'|xargs sed -i -e  's.Azure/DASH.sonic-net/DASH.g'

README.md

@@ -1,5 +1,5 @@
-[![DASH-bmv2-CI](https://github.com/Azure/DASH/workflows/DASH-BMV2-CI/badge.svg?branch=main)](https://github.com/Azure/DASH/actions/workflows/dash-bmv2-ci.yml)
-[![Spellcheck](https://github.com/Azure/DASH/actions/workflows/dash-md-spellcheck.yml/badge.svg)](https://github.com/Azure/DASH/actions/workflows/dash-md-spellcheck.yml) 
+[![DASH-bmv2-CI](https://github.com/sonic-net/DASH/workflows/DASH-BMV2-CI/badge.svg?branch=main)](https://github.com/sonic-net/DASH/actions/workflows/dash-bmv2-ci.yml)
+[![Spellcheck](https://github.com/sonic-net/DASH/actions/workflows/dash-md-spellcheck.yml/badge.svg)](https://github.com/sonic-net/DASH/actions/workflows/dash-md-spellcheck.yml) 
 
 # SONiC-DASH - Disaggregated API for SONiC Hosts - DRAFT/Work in Progress
 

dash-pipeline/README-dash-as-submodule.md

@@ -15,10 +15,10 @@
   - [Third-Party CI Pipeline Automation (Git Actions)](#third-party-ci-pipeline-automation-git-actions)
 # Importing the DASH project into another project
 
-The [Azure/DASH project](https://github.com/Azure/DASH) can be used as a resource within other projects, such as third-party, commercial or open-source DASH implementations. For example, a commercial DPU vendor can incorporate the DASH project into a private Git repository and utilize many of the components, providing consistency with the community implementation and definition, reusing test-cases, and avoiding duplication of efforts.
+The [sonic-net/DASH project](https://github.com/sonic-net/DASH) can be used as a resource within other projects, such as third-party, commercial or open-source DASH implementations. For example, a commercial DPU vendor can incorporate the DASH project into a private Git repository and utilize many of the components, providing consistency with the community implementation and definition, reusing test-cases, and avoiding duplication of efforts.
 
 # Quick-Start
-This will show you how to import the [Azure/DASH project](https://github.com/Azure/DASH) project into your own Git project.
+This will show you how to import the [sonic-net/DASH project](https://github.com/sonic-net/DASH) project into your own Git project.
 
 A minimal sample project created using this recipe can be found here: https://github.com/chrispsommers/dashsubmodule
 
@@ -31,7 +31,7 @@ A minimal sample project created using this recipe can be found here: https://gi
      ```
 4. Import the DASH repository as a submodule using the following command. Modify the final parameter to match the relative directory in your project where you want the submodule to be cloned into:
     ```
-    git submodule add -b main --name DASH [[email protected]:Azure/DASH.git](https://github.com/Azure/DASH.git) DASH
+    git submodule add -b main --name DASH [[email protected]:sonic-net/DASH.git](https://github.com/sonic-net/DASH.git) DASH
     ```
 5. Commit the changes now or later, see [DASH as a Git Submodule](#dash-as-a-git-submodule)
 6. To verify the dash submodule was imported correctly and crucial steps function properly, execute the following. (If you rename the file to `Makefile` you can omit the `-f` option.)
@@ -55,7 +55,7 @@ A minimal sample project created using this recipe can be found here: https://gi
 A third-party project can import the DASH project as a Git Submodule. See [about-git-submodules](README-dash-workflows.md#about-git-submodules) for background. In this example, DASH is imported at the top-level of the project using the following command. (See the documentation for `git submodule add` for other options.)
 
 ```
-git submodule add -b main --name DASH [[email protected]:Azure/DASH.git](https://github.com/Azure/DASH.git) DASH
+git submodule add -b main --name DASH [[email protected]:sonic-net/DASH.git](https://github.com/sonic-net/DASH.git) DASH
 ```
 
 The effects of this command are:
@@ -64,7 +64,7 @@ The effects of this command are:
   ```
   [submodule "DASH"]
 	path = DASH
-	url = [email protected]:Azure/DASH.git
+	url = [email protected]:sonic-net/DASH.git
 	branch = main
   ```
 - Store the imported repository git index/database under the parent project's `.git/modules` directory
@@ -100,7 +100,7 @@ The resulting Git structure is as follows. DASH is imported as a submodule. Furt
 ## Recap: DASH bmv2 workflow
 The figure below shows the traditional bmv2-based workflow and is described in [README-dash-workflows](README-dash-workflows.md).
 
-![dash-p4-bmv2-thrift-workflow](https://github.com/Azure/DASH/raw/main/dash-pipeline/images/dash-p4-bmv2-thrift-workflow.svg
+![dash-p4-bmv2-thrift-workflow](https://github.com/sonic-net/DASH/raw/main/dash-pipeline/images/dash-p4-bmv2-thrift-workflow.svg
 )
 ## Custom DASH Workflow
 The reference project contains a `Makefile.3rdpty` to serve as a starting point. It has make targets which are just wrappers to invoke predefined Makefile targets in the DASH repository (e.g. using `make -C...`). It also has placeholder make targets where third-party customization is required. You can modify it arbitrarily. The intent was to reuse as much as possible from DASH.
@@ -138,7 +138,7 @@ The community DASH bmv2 test workflow includes SW traffic-generators connected t
 
 If test ports other than `veth0/1` and `veth2/3` are used, some modifications of setup scripts may be required:
 * PTF tests using scapy for SW traffic generation can be parameterized to specify logical-to-physical port mappings.
-* Pytests using ixia-c SW traffic generator are set up using docker-compose topology files under [DASH/test/third-party/traffic_gen/deployment](https://github.com/Azure/DASH/tree/main/test/third-party/traffic_gen/deployment)
+* Pytests using ixia-c SW traffic generator are set up using docker-compose topology files under [DASH/test/third-party/traffic_gen/deployment](https://github.com/sonic-net/DASH/tree/main/test/third-party/traffic_gen/deployment)
 
 ## Custom Tests
 You can use the tests under DASH by calling the appropriate DASH make targets from the parent project. You can also have private tests in your own project repository which you invoke from your Makefiles. We recommend if you write new tests which are generally applicable that you consider upstreaming to the Community repository.

dash-pipeline/README-dash-workflows.md

@@ -433,7 +433,7 @@ Since we haven't gone through this process yet, it is subject to more clarificat
 
 The sections below discuss version control of critical components.
 ## DASH Repository Versioning
-The DASH GitHub repo, i.e. [https://github.com/Azure/DASH](https://github.com/Azure/DASH) is controlled by Git source-code control, tracked by commit SHA, tag, branch, etc. This is the main project and its components should also be controlled.
+The DASH GitHub repo, i.e. [https://github.com/sonic-net/DASH](https://github.com/sonic-net/DASH) is controlled by Git source-code control, tracked by commit SHA, tag, branch, etc. This is the main project and its components should also be controlled.
 ## Submodules
 As discussed in [About Git Submodules](#about-git-submodules), submodules are controlled by the SHA commit of the submodule, which is "committed" to the top level project (see [About Git Submodules](#about-git-submodules). The versions are always known and explicitly specified.
 ## Docker Image Versioning

documentation/README.md

@@ -4,7 +4,7 @@ Documentation comprises system descriptions, High-level design (HLD) documents a
 
 The testing framework, methodology, documentation and testing artifacts are stored in the [DASH/test](../test) directory
 
-See also DASH [FAQ](https://github.com/Azure/DASH/wiki/FAQ) and [Glossary](https://github.com/Azure/DASH/wiki/Glossary). 
+See also DASH [FAQ](https://github.com/sonic-net/DASH/wiki/FAQ) and [Glossary](https://github.com/sonic-net/DASH/wiki/Glossary). 
 
 # Contents
 
@@ -63,7 +63,7 @@ Some of the guiding principles for this approach are:
 
 ## References
 
-- [Glossary](https://github.com/Azure/DASH/wiki/Glossary)
-- [FAQ](https://github.com/Azure/DASH/wiki/FAQ)
+- [Glossary](https://github.com/sonic-net/DASH/wiki/Glossary)
+- [FAQ](https://github.com/sonic-net/DASH/wiki/FAQ)
 
 

documentation/general/dash-high-level-design.md

@@ -119,22 +119,22 @@ networking services for the cloud. The 7 initial services (in draft) describe
 this in more detail. We will also work with cloud and enterprise providers to
 further extend DASH to meet their specific needs.
 
-1. [VNET-to-VNET](https://github.com/Azure/DASH/tree/main/documentation/vnet2vnet-service).
+1. [VNET-to-VNET](https://github.com/sonic-net/DASH/tree/main/documentation/vnet2vnet-service).
 This scenario is the starting point to design, implement and test the core DASH
 mechanisms. In particular it allows the following features: VM to VM
 communication in VNET, route support, LPM support, ACL support. This is to
 verify the following performance properties: CPS, flow, PPS, and rule scale. 
 1. [VNET
-   Peering](https://github.com/Azure/DASH/tree/main/documentation/vnet-peering-service).
+   Peering](https://github.com/sonic-net/DASH/tree/main/documentation/vnet-peering-service).
    Virtual network peering connects two virtual networks
    seamlessly. Once peered, for connectivity purposes, the virtual networks
    appear as one. For background information, see [Virtual network
    peering](https://docs.microsoft.com/en-us/windows-server/networking/sdn/vnet-peering/sdn-vnet-peering).
 1. [High Availability
-   (HA)](https://github.com/Azure/DASH/tree/main/documentation/high-avail).
+   (HA)](https://github.com/sonic-net/DASH/tree/main/documentation/high-avail).
    Useful for failure and failover events
 1. [Load
-   Balancer](https://github.com/Azure/DASH/tree/main/documentation/load-bal-service).
+   Balancer](https://github.com/sonic-net/DASH/tree/main/documentation/load-bal-service).
    The feature that switches traffic from using VIP-to-VIP connectivity (which
    involves transiting SLB MUXes), into using a direct path between VMs (direct
    PA to PA path).
@@ -146,9 +146,9 @@ verify the following performance properties: CPS, flow, PPS, and rule scale.
    public facing shared services via their private IP addresses within their
    VNET.
 1. [Encryption
-   Gateway](https://github.com/Azure/DASH/tree/main/documentation/encrypt-gw-service).
+   Gateway](https://github.com/sonic-net/DASH/tree/main/documentation/encrypt-gw-service).
 1. [Express Route
-   Gateway](https://github.com/Azure/DASH/tree/main/documentation/express-route-service).
+   Gateway](https://github.com/sonic-net/DASH/tree/main/documentation/express-route-service).
 
 ## Azure provisioning example
 
@@ -163,7 +163,7 @@ directed to our Appliance, which processes the first packet in hardware.
 
 In parallel, from a DASH perspective we are developing a common programming
 interface to agnostically configure hardware for the scenarios outlined in the
-[Documentation folder](https://github.com/Azure/DASH/tree/main/documentation):
+[Documentation folder](https://github.com/sonic-net/DASH/tree/main/documentation):
 
 > [!NOTES] We just capture the gist of these scenarios and then we link to the
 > related documentation.
@@ -205,7 +205,7 @@ section.
   describe the behaviors per scenario and document them in a repeatable format.
   From there we will be able to auto-generate the APIs. The implementation
   itself is not required to be P4. For more information, see the [Behavioral
-  model](https://github.com/Azure/DASH/tree/main/dash-pipeline/bmv2) section.
+  model](https://github.com/sonic-net/DASH/tree/main/dash-pipeline/bmv2) section.
 - **DASH programmable hardware**. With the help of network hardware technology
 providers, we are collaborating to create an open forum capitalizing on the use
 of programmable hardware including **SmartNICs**, **SmartSwitches**, and
@@ -221,7 +221,7 @@ For more information,see the [Scenarios](#scenarios) section.
   requirements. For more information about test documentation, test scripts,
   test configurations and other artifacts required to test a DASH device or
   devices, see [Performance
-  testing](https://github.com/Azure/DASH/tree/main/test). 
+  testing](https://github.com/sonic-net/DASH/tree/main/test). 
 
 ## Logical architecture (software stack) 
 
@@ -274,7 +274,7 @@ Scale](../high-avail/high-availability-and-scale.md) document.
 ### gNMI container
 
 The SDN controller communicates with a DASH device through a
-**[gNMI](https://github.com/Azure/DASH/wiki/Glossary#gnmi) endpoint** served by
+**[gNMI](https://github.com/sonic-net/DASH/wiki/Glossary#gnmi) endpoint** served by
 a new DASH SDN agent **running inside a new SONiC DASH container**.  
 
 In summary:
@@ -297,7 +297,7 @@ A **gNMI schema** will manage the following DASH components:
 - Other  
 
 > [!NOTE] See also work in progress PR [doc-ref-config-example
-> #93](https://github.com/Azure/DASH/pull/93).
+> #93](https://github.com/sonic-net/DASH/pull/93).
 
 #### Multiple DPUs device
 
@@ -342,7 +342,7 @@ combination of traditional SAI headers and new DASH pipeline-specific *extension
 Technology suppliers must implement this interface for their DASH devices. This
 is the primary integration point of DASH devices and the SONiC stack. It will be
 rigorously tested for performance and conformance. See [DASH Testing
-documentation](https://github.com/Azure/DASH/tree/main/test).
+documentation](https://github.com/sonic-net/DASH/tree/main/test).
 
 SAI "schema" are represented as fixed c-language header files and derived
 metadata header files. The **underlay** and **overlay** schema have different origins:
@@ -352,7 +352,7 @@ metadata header files. The **underlay** and **overlay** schema have different or
   **hand-generated** and **maintained**. DASH uses a subset of these to manage "**underlay**"
   functions, e.g. device management, Layer 3 routing and so forth. For more information, see [SWSS Lite (Underlay)](dash-sonic-hld.md#333-swss-lite-underlay). 
 - DASH SAI **overlay** objects. They are derived from a [P4 Behavioral
-  Model](https://github.com/Azure/DASH/tree/main/dash-pipeline). A script
+  Model](https://github.com/sonic-net/DASH/tree/main/dash-pipeline). A script
   reads the P4 model and generates SAI header files. For more information, see [DASHOrch (Overlay)](dash-sonic-hld.md#332-dashorch-overlay).
 
 For more information see the [SAI README](../../../SAI/README.md) file.
@@ -541,23 +541,23 @@ DASH devices satisfy the standard **DASH conformance and performance
 requirements**. For more information about test documentation, test scripts,
 test configurations and other artifacts required to test a DASH device, see
 [DASH conformance and performance
-testing](https://github.com/Azure/DASH/tree/main/test). 
+testing](https://github.com/sonic-net/DASH/tree/main/test). 
 
 > [!NOTE] TBD - We just capture he basic info and then link to the related
 > test area. 
 
 - [High-Level Description (HLD) Test
-  Specification](https://github.com/Azure/DASH/blob/main/test/docs/dash-test-HLD.md).
+  Specification](https://github.com/sonic-net/DASH/blob/main/test/docs/dash-test-HLD.md).
   High-level design for the testing of devices which conform to the DASH
   requirements.
 - [Dash Test Maturity
-  Stages](https://github.com/Azure/DASH/blob/main/test/docs/dash-test-maturity-stages.md).
+  Stages](https://github.com/sonic-net/DASH/blob/main/test/docs/dash-test-maturity-stages.md).
   Describes a progressive approach to DASH testing.
 - [DASH SAI-Thrift Test
-  Workflow](https://github.com/Azure/DASH/blob/main/test/docs/dash-test-workflow-saithrift.md).
+  Workflow](https://github.com/sonic-net/DASH/blob/main/test/docs/dash-test-workflow-saithrift.md).
   DASH test workflow with SAI-thrift.
 - [DASH P4 SAI-Thrift Test
-  Workflow](https://github.com/Azure/DASH/blob/main/test/docs/dash-test-workflow-p4-saithrift.md).
+  Workflow](https://github.com/sonic-net/DASH/blob/main/test/docs/dash-test-workflow-p4-saithrift.md).
   Use of P4-based simulators or SW data planes to verify DASH behavior, using
   saithrift API.
 
@@ -566,7 +566,7 @@ testing](https://github.com/Azure/DASH/tree/main/test).
 ### A day in the life of a DASH packet
 
 > [!NOTE] TBD - Engineering help needed. 
-> Add link to the SDN packet pipeline document when ready. See PR [dash-sdn-and-packet-transform-documentation-update](https://github.com/Azure/DASH/pull/125).
+> Add link to the SDN packet pipeline document when ready. See PR [dash-sdn-and-packet-transform-documentation-update](https://github.com/sonic-net/DASH/pull/125).
 
 ### A day in the life of a DASH SDN controller
 
@@ -578,11 +578,11 @@ testing](https://github.com/Azure/DASH/tree/main/test).
 
 ## References
 
-- [FAQ](https://github.com/Azure/DASH/wiki/FAQ)
-- [Glossary](https://github.com/Azure/DASH/wiki/Glossary)
+- [FAQ](https://github.com/sonic-net/DASH/wiki/FAQ)
+- [Glossary](https://github.com/sonic-net/DASH/wiki/Glossary)
 - [SAI headers](../sai/README.md)
 - [DASH pipeline](../../dash-pipeline/README.md)
-- [DASH conformance and performance testing](https://github.com/Azure/DASH/tree/main/test)
+- [DASH conformance and performance testing](https://github.com/sonic-net/DASH/tree/main/test)
 - [SONiC DASH HLD](dash-sonic-hld.md)
 - [SONiC System Architecture](https://github.com/Azure/SONiC/wiki/Architecture#sonic-system-architecture)
 - [P4 as a Single Source of Truth for SONiC DASH -  2022 P4 Workshop](https://www.youtube.com/watch?v=mT7-t_aDozM)

documentation/general/dash-sonic-hld.md

@@ -483,7 +483,7 @@ The [figure below](#schema_relationships) illustrates the various schema and the
 * gNMI northbound API, which uses YANG to specify schema
 * Redis APP_DB, which uses [ABNF](https://github.com/Azure/SONiC/blob/master/doc/mgmt/Management%20Framework.md#12-design-overview) schema definition language. Redis objects can be directly manipulated using [SAI-redis](https://github.com/Azure/sonic-sairedis) clients.
 * JSON import/export formats
-* [SAI](https://github.com/Azure/DASH/tree/main/SAI) table and attribute objects
+* [SAI](https://github.com/sonic-net/DASH/tree/main/SAI) table and attribute objects
 
 #### Canonical Test Data and schema transformations
 For testing purposes, it is convenient to express test configurations in a single canonical format, and use this to drive the different API layers to verify correct behavior. A tentative JSON format for representing DASH service configurations is described in [Reference configuration example (JSON)](../gnmi/dash-reference-config-example.md). Test drivers can accept this input, transform it into different schemas and drive the associated interfaces. For example, a JSON representation of an ACL rule can be transformed into gNMI API calls, SAI-redis calls, SAI-thrift calls, etc.

test/docs/dash-test-sai-challenger.md

@@ -38,7 +38,7 @@ Install dependencies listed [**here**](../../dash-pipeline/README.md#prerequisit
 
 ## Install and build
 ```
-git clone https://github.com/Azure/DASH.git
+git clone https://github.com/sonic-net/DASH.git
 cd DASH/dash-pipeline
 make clean
 make all

test/docs/dash-test-workflow-saithrift.md

@@ -45,7 +45,7 @@ The previous figure highlights the following important test work-flow concepts:
 
 The GitHub repositories can be found at these locations:
 
-- [dash/test](https://github.com/Azure/DASH/tree/main/test)
+- [dash/test](https://github.com/sonic-net/DASH/tree/main/test)
 - [opencompute/SAI](https://github.com/opencomputeproject/SAI)
 
 The descriptions below are listed in rough order of dependency, culminating in the test script itself.

test/docs/testbed/README.testbed.software.md

@@ -86,7 +86,7 @@
 
 - clone the `DASH` repository into your working directory:
     ```
-    git clone https://github.com/Azure/DASH
+    git clone https://github.com/sonic-net/DASH
     ```
 
 - build container

test/environments/README.md

@@ -3,7 +3,7 @@ do the steps in [Prepare Testbed Server](../docs/testbed/README.testbed.software
 
 # build container
 ```
-git clone https://github.com/Azure/DASH
+git clone https://github.com/sonic-net/DASH
 docker build --no-cache --tag dash/keysight:latest ./DASH/test/environments/keysight
 docker tag dash/keysight:latest dash/keysight:1.0.0
 ```

test/test-cases/functional/saic/tutorial/README.md

@@ -39,7 +39,7 @@ All tests must be run from within a `dash-saichallenger-client` container. You c
 ### Preparation: Build and Run bmv2 and saithrift-server
 Fetch and build bmv2 and collaterals. You may skip if you've already done this.
 ```
-git clone https://github.com/Azure/DASH.git
+git clone https://github.com/sonic-net/DASH.git
 cd dash-pipeline
 make clean && make all
 ```