It was hardcoded to x86_64, but we build Alpine images for more platforms, let's
be dynamical here.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
configure: error: in `/src':
configure: error: protobuf requested but protoc-c not found. Install protobuf-c.
See `config.log' for more details
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
Update the READMEs, and give example of a full parallel topotest run with
result extraction for analyze.py
Signed-off-by: Christian Hopps <chopps@labn.net>
This commit adds user documentation for the new MGMT daemon and
new FRR Management Framework.
Co-authored-by: Yash Ranjan <ranjany@vmware.com>
Co-authored-by: Abhinay Ramesh <rabhinay@vmware.com>
Co-authored-by: Ujwal P <ujwalp@vmware.com>
Signed-off-by: Pushpasis Sarkar <pushpasis@gmail.com>
Docker image based on ubi8-minimal are smaller in size than previous
ones built with ubi8 as base. Also, due to proper cleanup of caches, the
final image is about 400MB in size (down from ~630MB using the older
ubi8 builder).
This Dockerfile also uses packages built for RHEL (instead of CentOS),
and updates dependencies so that it can compile latest FRR versions.
Signed-off-by: Juan Vidal Allende <juan.vidal1@ibm.com>
The builder for docker images based on ubi-8 images is broken, and it
generates docker images that are heavy and contain more artifacts than
they need to.
It also installs RPM packages from CentOS that, although seem to be
compatible with ubi-8, may diverge at some point (remember that CentOS
now does not track RHEL closely).
Signed-off-by: Juan Vidal Allende <juan.vidal1@ibm.com>
- Create frr docker container based in new Red Hat Universal Base
Images.
- This build a docker container based in ubi-8.
- Need to get the devel packages from centos-8 stream repos.
- Centos-8 stream repos added : base, appstream, powertools and epel
Signed-off-by: Javier Garcia <javier.martin.garcia@ibm.com>
Add ability to set your own env for the version of the docker
container alpine image. This is useful for applications like GNS3
who pin a specific version to look for when they boot up. When you build
locally to test your code you can just set the version to 0 so you don't
have to update configs/scripts looking for a specific image version.
Also fix a shebang in docker start for alpine.
Signed-off-by: Stephen Worley <sworley@nvidia.com>
Alpine images have been broken for some time because libyang2 is not
available in Alpine. This patch updates our Dockerfile to build a
libyang2 APK and install it into the image to satisfy FRR's libyang2
dependency.
Unfortunately, libyang2 erroneously includes an internal header from
glibc, making it dependent on glibc to build. FRR's official Docker
images are based on Alpine, which only offers musl libc. Until libyang2
fixes this problem, the libyang2 source that is installed in this image
is a patched version that is compatible with musl libc and not an
official version.
Signed-off-by: Quentin Young <qlyoung@nvidia.com>
tini is a hyper-minimal PID 0 which spawns a child process (watchfrr.sh
in our case), reaps zombies and forwards signals to the script. Starting
watchfrr.sh directly instead of through the old `tail /dev/null` or
`sleep 365d` helps keep things clean too :)
While tini was previously only used in the Alpine container it is useful
to apply this PID 0 to all containers except the special CI ones.
Fixes: #8788
Signed-off-by: Wesley Coakley <w@wesleycoakley.com>
Test uses staticd which required some C++ header protections.
Additionally, the test also runs in the ubuntu20 docker container as
grpc is supported there by the packaging system.
Signed-off-by: Christian Hopps <chopps@labn.net>
Compile with v2.0.0 tag of `libyang2` branch of:
https://github.com/CESNET/libyang
staticd init load time of 10k routes now 6s vs ly1 time of 150s
Signed-off-by: Christian Hopps <chopps@labn.net>
Specifying watchfrr as CMD instead of ENTRYPOINT allows one to easily
override this command when starting a docker container. This allows
simple, manual testing via (e.g.) bash. With ENTRYPOINT only the
container will simply explode with an exit code if watchfrr exits.
For instance one could start a shell session in this container via:
```
docker run --name test --rm -i -t <frr-container> bash
```
The default behavior (`docker run <frr-container>` with no command
specified) is not changed.
Signed-off-by: Wesley Coakley <wcoakley@nvidia.com>
Bump libyang version in centos containers to 1.0.184 and (1) change
"PowerTools" repository to "powertools" to accomodate CentOS Stream
changes
(1) https://bugs.centos.org/view.php?id=17920
Signed-off-by: Wesley Coakley <wcoakley@nvidia.com>
Building with alpine:edge caused some weirdness with our build
scripts, switching to the stable branch seems to have aleviated this.
We can also ditch the "edge" repositories as the main and community
repositories provide all packages we need
Signed-off-by: Wesley Coakley <wcoakley@nvidia.com>
If we can chown /etc/frr then fine, but there's circumstances where we
won't be able to - for instance, if running FRR in Kubernetes where
/etc/frr/* is actually a virtual filesystem.
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
