Support for VPP 23.06 (#96)

Signed-off-by: Daniel Béreš <[email protected]>
Co-authored-by: Daniel Béreš <[email protected]>

Author: Giluerre

Makefile

@@ -52,10 +52,10 @@ RELEASE_VERSION_MAJOR_MINOR = $(shell echo $(RELEASE_VERSION_FULL) | cut -d '.'
 endif
 
 ifeq ($(VPP_VERSION),)
-VPP_VERSION="22.10"
+VPP_VERSION="23.06"
 endif
 ifeq ($(DEV_VERSION),) # for tagging in-development images
-DEV_VERSION="22.10"
+DEV_VERSION="23.06"
 endif
 REPO="ghcr.io/pantheontech"
 STONEWORK_VPP_IMAGE="stonework-vpp"
@@ -253,6 +253,7 @@ generate-binapi: get-binapi-generator
 	@cd plugins/binapi/vpp2106 && VPP_VERSION=21.06 go generate .
 	@cd plugins/binapi/vpp2202 && VPP_VERSION=22.02 go generate .
 	@cd plugins/binapi/vpp2210 && VPP_VERSION=22.10 go generate .
+	@cd plugins/binapi/vpp2306 && VPP_VERSION=23.06 go generate .
 
 generate-descriptor-adapters: get-descriptor-adapter-generator
 	@echo "# generating descriptor adapters"

docker/dev.Dockerfile

@@ -1,6 +1,6 @@
 # syntax = docker/dockerfile:1.2
 
-ARG VPP_IMAGE=vpp:22.10
+ARG VPP_IMAGE=vpp:23.06
 ARG VPPAGENT_IMAGE=ligato/vpp-agent:v3.4.0
 
 FROM $VPP_IMAGE as vpp
@@ -116,8 +116,8 @@ RUN rm /tmp/legacy-nat.conf
 COPY ./docker/vpptrace.sh /usr/bin/vpptrace.sh
 RUN chmod u+x /usr/bin/vpptrace.sh
 
-COPY ./plugins/binapi/vpp2210/api/abx.api.json /usr/share/vpp/api/plugins/
-COPY ./plugins/binapi/vpp2210/api/isisx.api.json /usr/share/vpp/api/plugins/
+COPY ./plugins/binapi/vpp2306/api/abx.api.json /usr/share/vpp/api/plugins/
+COPY ./plugins/binapi/vpp2306/api/isisx.api.json /usr/share/vpp/api/plugins/
 
 CMD rm -f /dev/shm/db /dev/shm/global_vm /dev/shm/vpe-api && \
     mkdir -p /run/vpp /run/stonework/vpp && \

docker/mockcnf/Dockerfile

@@ -14,7 +14,7 @@
 # See the License for the specific language governing permissions and
 # limitations under the License.
 
-ARG VPP_IMAGE=vpp:22.10
+ARG VPP_IMAGE=vpp:23.06
 ARG VPPAGENT_IMAGE=ligato/vpp-agent:v3.4.0
 
 FROM $VPP_IMAGE as vpp

docker/prod.Dockerfile

@@ -14,8 +14,8 @@
 # See the License for the specific language governing permissions and
 # limitations under the License.
 
-ARG VPP_IMAGE=vpp:22.10
-ARG DEV_IMAGE=stonework-dev:22.10
+ARG VPP_IMAGE=vpp:23.06
+ARG DEV_IMAGE=stonework-dev:23.06
 
 FROM $VPP_IMAGE as vpp
 FROM $DEV_IMAGE as dev

docker/vpp-mellanox.Dockerfile

@@ -27,7 +27,7 @@
 # host network_mode (besides making it privileged and mounting /dev volume as
 # ussual with DPDK), to use StoneWork with this VPP under the hood.
 
-ARG VPP_VERSION=22.10
+ARG VPP_VERSION=23.06
 ARG VPP_IMAGE=ligato/vpp-base:$VPP_VERSION
 
 FROM ${VPP_IMAGE} AS base
@@ -60,7 +60,7 @@ RUN cd vpp && yes | make install-dep install-ext-deps && make pkg-deb
 
 #-----------------
 # build ABX plugin
-ARG VPP_VERSION=22.10
+ARG VPP_VERSION=23.06
 COPY vpp/abx /tmp/abx
 RUN VPPVER=$(echo $VPP_VERSION | tr -d ".") && \
     cp -r /tmp/abx/vpp${VPPVER} /opt/dev/abx

docker/vpp-test.Dockerfile

@@ -14,7 +14,7 @@
 # See the License for the specific language governing permissions and
 # limitations under the License.
 
-ARG VPP_IMAGE=vpp:22.10
+ARG VPP_IMAGE=vpp:23.06
 
 FROM ${VPP_IMAGE}
 

docker/vpp.Dockerfile

@@ -14,7 +14,7 @@
 # See the License for the specific language governing permissions and
 # limitations under the License.
 
-ARG VPP_VERSION=22.10
+ARG VPP_VERSION=23.06
 ARG VPP_IMAGE=ligato/vpp-base:$VPP_VERSION
 
 FROM ${VPP_IMAGE}
@@ -76,7 +76,7 @@ RUN set -ex; \
 # there is a bug in VPP 21.06 that api files are not built on standard location
 # for external plugins, to reproduce it is enough to try to build sample-plugin
 RUN set -ex; \
-    if [ "$VPP_VERSION" = "22.10" ] || [ "$VPP_VERSION" = "22.02" ]; \
+    if [ "$VPP_VERSION" = "23.06" ] || [ "$VPP_VERSION" = "22.10" ] || [ "$VPP_VERSION" = "22.02" ]; \
     then \
       cp abx/build/CMakeFiles/vpp-api/vapi/* /usr/include/vapi/; \
     elif [ "$VPP_VERSION" = "21.06" ]; \

docs/UPDATE_PROCEDURE.md

@@ -11,7 +11,7 @@ StoneWork is based on *vpp-agent* and thus supports stable VPP versions, support
 Check whether `ligato/vpp-base`, with your desired version, already exists.
 
 To do so, just look at `ligato/vpp-base` tags on [DockerHub][dockerhub-tags]. Or directly by docker pull command, for example:
-`docker pull ligato/vpp-base:22.10`
+`docker pull ligato/vpp-base:23.06`
 
 If there is no such tagged version, you need to create it.
 
@@ -80,16 +80,16 @@ StoneWork docker images are present on [GitHub Container Registry][ghcr].
 To update images, create and push a git tag into image repository according to
 the following convention:
 `v<VPP-major>.<VPP-minor>.<patch><optional-identifier>` (for example
-`v22.10.0`), where `<patch>` may increase if VPP is updated by its patch version
+`v23.06.0`), where `<patch>` may increase if VPP is updated by its patch version
 or if some change is submitted into the control-plane.
 
 This triggers build of the images in repository and tags StoneWork production
 image as `ghcr.io/pantheontech/stonework` with the following version tags:
 1. Full git tag as-it-is, with trimmed leading '`v`', for example
-   `ghcr.io/pantheontech/stonework:22.10.0`. This tag is fixed
+   `ghcr.io/pantheontech/stonework:23.06.0`. This tag is fixed
    and should never be changed.
 2. `<VPP-major>.<VPP-minor>`, for example
-   `ghcr.io/pantheontech/stonework:22.10`. This tag points to the
+   `ghcr.io/pantheontech/stonework:23.06`. This tag points to the
    latest version with the same major and minor version number.
 3. `latest`, for example `ghcr.io/pantheontech/stonework:latest`.
 
@@ -99,7 +99,7 @@ while keeping the `latest` and `<VPP-major>.<VPP-minor>` tags still updated.
 After that, all three tagged images are automatically pushed into GitHub
 Container Registry.
 
-[dockerhub-tags]: https://hub.docker.com/r/ligato/vpp-base/tags?page=1&ordering=last_updated&name=22.10
+[dockerhub-tags]: https://hub.docker.com/r/ligato/vpp-base/tags?page=1&ordering=last_updated&name=23.06
 [inspiration-pr]: https://github.com/ligato/vpp-base/pull/18
 [agent-instructions]: https://github.com/ligato/vpp-agent/wiki/Guide-for-adding-new-VPP-version
 [ghcr]: https://github.com/orgs/PANTHEONtech/packages/container/package/stonework

docs/USERGUIDE.md

@@ -20,7 +20,7 @@ StoneWork images are publicly available and can be pulled, [as described here](h
 ## Run
 To try out the StoneWork, we can simply run it as a Docker container:
 ```
-$ docker run -d --rm --name stonework -e ETCD_CONFIG="" ghcr.io/pantheontech/stonework:22.10
+$ docker run -d --rm --name stonework -e ETCD_CONFIG="" ghcr.io/pantheontech/stonework:23.06
 ```
 This will run a Docker container named *stonework* in the background. 
 
@@ -129,7 +129,7 @@ TAP Interface
 
 To create tap interface, we need to make the StoneWork container privileged, so running it as:
 ```
-$ docker run -d --rm --name stonework --privileged -e ETCD_CONFIG="" ghcr.io/pantheontech/stonework:22.10
+$ docker run -d --rm --name stonework --privileged -e ETCD_CONFIG="" ghcr.io/pantheontech/stonework:23.06
 ```
 
 Then we will use the configuration as:
@@ -167,7 +167,7 @@ But this tap interface is present only inside our StoneWork container. What if w
 
 Then we need to use host network mode in our docker run one liner:
 ```
-$ docker run -it --rm --name stonework --privileged --network="host" -e ETCD_CONFIG="" ghcr.io/pantheontech/stonework:22.10
+$ docker run -it --rm --name stonework --privileged --network="host" -e ETCD_CONFIG="" ghcr.io/pantheontech/stonework:23.06
 ```
 For more details about tap interfaces and VPP, take a look [at this example][tap-example].
 
@@ -178,7 +178,7 @@ As our Docker run one-liner grows, it becomes better to use docker-compose, in t
 
 Lets rewrite the above mentioned docker run command, i.e.:
 ```
-$ docker run -it --rm --name stonework --privileged --network="host" -e ETCD_CONFIG="" ghcr.io/pantheontech/stonework:22.10
+$ docker run -it --rm --name stonework --privileged --network="host" -e ETCD_CONFIG="" ghcr.io/pantheontech/stonework:23.06
 ```
 into *docker-compose.yaml*:
 ```
@@ -187,7 +187,7 @@ version: '3.3'
 services:
   stonework:
     container_name: stonework
-    image: "ghcr.io/pantheontech/stonework:22.10"
+    image: "ghcr.io/pantheontech/stonework:23.06"
     privileged: true
     network_mode: "host"
     environment:
@@ -258,7 +258,7 @@ version: '3.3'
 services:
   stonework:
     container_name: stonework
-    image: "ghcr.io/pantheontech/stonework:22.10"
+    image: "ghcr.io/pantheontech/stonework:23.06"
     privileged: true
     network_mode: "host"
     environment:
@@ -435,7 +435,7 @@ volumes:                                    # new
 services:
   stonework:
     container_name: stonework
-    image: "ghcr.io/pantheontech/stonework:22.10"
+    image: "ghcr.io/pantheontech/stonework:23.06"
     privileged: true
     network_mode: "host"
     environment:

examples/getting-started/README.md

@@ -66,7 +66,7 @@ The StoneWork container should be present almost immediately:
 ```
 $ docker ps
 CONTAINER ID   IMAGE                                  COMMAND                  CREATED         STATUS         PORTS     NAMES
-83f034b16cd8   ghcr.io/pantheontech/stonework:22.10   "/bin/sh -c 'rm -f /…"   6 seconds ago   Up 5 seconds             stonework
+83f034b16cd8   ghcr.io/pantheontech/stonework:23.06   "/bin/sh -c 'rm -f /…"   6 seconds ago   Up 5 seconds             stonework
 ```
 
 It shouldn't take too long for StoneWork to initialize and apply the "day0"