MatthewHink d8cd6049ac Initial cut of wwapi.
We need an API for Warewulf in order to automate around it. The initial version of the API will look a lot like wwctl. wwctl will call the API so that we do not need to maintain separate code paths. In this preview wwctl calls the API via direct function call, but we can change that to a gprc or REST call to a Warewulf server in the future.

This commit contains:
wwapid WareWulf API Daemon. A grpc server with mTLS auth.
wwapic WareWulf API Client. A grpc client with mTLS auth. It's just a sample that reads the version from the server.
wwapird WareWulf API Rest Daemon. A http REST reverse proxy to wwapid.
There are also sample insecure and secure curls to test with.

Implemented Functionality:
wwctl node add
wwctl node delete
wwctl node list
wwctl node set
wwctl node status
wwctl container build
wwctl container delete
wwctl container import
wwctl container list
wwctl container show

Some notes on the files:

    Logic that was in wwctl has moved to warewulf/internal/pkg/api. wwctl just calls the API. wwctl functionality is unchanged.
    Everything under the /google directory is copied google proto code to stand up wwapird. It's a bit strange to copy in the code, but that is currently how it's done.
    Everything in warewulf/internal/pkg/api/routes/wwapiv1 is generated code.

There are some loose ends here, such as no service installers. I just ran off the command line for development.
The Makefile could use improvement. I'm building by make clean setup proto all build wwapid wwapic wwapird ; echo $?
I copied the configs from warewulf/etc to /usr/local/etc/warewulf manually.
2022-06-24 08:39:30 -07:00
2022-06-20 14:46:00 +02:00
2022-06-20 14:46:00 +02:00
2022-05-05 03:13:21 +00:00
2022-06-24 08:39:30 -07:00
2022-06-24 08:39:30 -07:00
2022-06-24 08:39:30 -07:00
2022-06-22 14:45:56 +02:00
2020-12-18 19:17:15 -08:00
2021-02-16 11:54:12 -08:00
2022-06-24 08:39:30 -07:00
2022-06-24 09:36:04 +02:00
2022-06-10 08:42:42 +02:00
2022-06-24 08:39:30 -07:00
2022-06-24 08:39:30 -07:00
2020-12-03 18:30:30 -08:00
2022-06-24 08:39:30 -07:00
2022-02-18 09:14:04 +01:00
2020-12-15 21:29:28 -08:00
2022-06-24 08:39:30 -07:00
2021-01-14 20:33:25 -08:00
2022-04-26 15:03:48 +02:00

warewulf v4

Warewulf

About Warewulf

History

For over two decades, Warewulf has powered HPC systems around the world. From simple “under the desk” clusters to large institutional systems at HPC centers as well as enterprises who rely on performance critical computing.

Through the evolution of Warewulf, we have seen various iterations provisioning models starting from CDROM / ISO images to Etherboot (predecessor to PXE), then PXE, and more recently iPXE, but even during these different bootloaders, Warewulf in its heart, has always been first and foremost a stateless provisioning system (e.g. the operating system node image is not written to any persistent storage and rather it boots from the network directly into a runtime system).

Warewulf v3 has been in production for over 6 years now as it has stabilized into a very solid and full featured solution. But over the last few years, there have been many innovations in Enterprise technologies which can (and should) be leveraged as part of Warewulf. Additionally, some of the lessons learned from Warewulf v3 architecture should be rolled into an updated architecture for provisioning management.

Warewulf v4

Leveraging this legacy of provisioning and cluster management brings us to where we are today. The next generation of Warewulf. Warewulf v4 is a complete rewrite in GoLang, taking in the legacy of what we've come to expect with Warewulf, bringing it into the present, and looking out into the future.

Warewulf v4 combines ultra scalability, flexibility, and simplicity with being light weight, non-intrusive, and a great tool for scientists and seasoned system administrators alike. Warewulf empowers you to scalably and easily manage thousands of compute resources.

Architecture

One of the design tenants of Warewulf is how to scalably administrate many thousands of compute nodes. Generally speaking, operating system state introduce a surface for potential discrepancies and version creep between nodes and thus Warewulf has always gone with the "single system image" approach to clustered operating system management. This means that you can have a single management node "image". For the last 20 years, we've been calling this a Virtual Node File System (VNFS), but in hindsight, this is a container.

At its core, Warewulf v4 focuses on what has made Warewulf so widely loved: simplicity, ultra scalable, lightweight, and an easy to manage solution built for both scientists and seasons system administrators to be able to design a highly functional yet easy to maintain cluster no matter how big or small or customized it needs to be.

Description
No description provided
Readme 28 MiB
Languages
Go 94.1%
Shell 4%
Makefile 1.2%
Python 0.4%
Dockerfile 0.3%