Last updated: 2024-11-21 22:06:08.897767 File source: link on GitLab
Context / links:
The goal of the process is to expose all developed functionalities with frozen scope, as described above, to a rigorous internal and community testing via succession of release candidate builds.
In preparation for this release process we will be changing the branching strategy as discussed and agreed in this issue and tracked by this issue. In summary:
We will operate on two branches: main (for trunk development) and release (for minor / final releases and patches).
The public dms binaries will be built from release branch tags in the form of v{version_number}-{suffix}, e.g. v0.5.0-rc1, etc. and released via gitlab release page as usual.
Interim builds between scheduled release candidates will be tagged with suffix -p{patch_number}, e.g. v0.5.0-rc1-p1, etc.
The release process of Device Management Service Version 0.5.x is scheduled to start September 15, 2024 and finish December 15, 2024. It involves the following steps in chronological order:
Feature scope freeze
Specification and documentation system launch
Project management portal launch
Test management system launch (feature environment, CI/CD pipeline and QA visibility)
Release candidates testing and delivering full feature scope
The currently scheduled release candidates are:
v0.5.0-boot -- bootstrap release;
v0.5.0-rc1 -- first release candidate;
v0.5.0-rc2 -- second release candidate;
v0.5.0-rc3 -- third release candidate;
v0.5.0-rc4 -- fourth release candidate;
v0.5.0 -- final release
The internal latest updated document with release process dates and countdown is available to view here. Feature scope management is done via DMS 0.5 pubic issue board.
Feature scope freeze
We first define the final scope of the dms features that we are releasing within this milestone, which is done within this section of the document. The scope of each feature should defined by functional test cases / scenarios associated with each feature and linked in Acceptance tests row of each table. All required test cases and scenarios pertaining to the feature scope freeze shall be written by the time of the last last release candidate release. The work is tracked by the work package dms/tests integrated into the test management system. Until then we will be continuing to implement all the features as they are explained in this document.
Specification and documentation portal launch
Documentation portal was operating internally since end of 2023, but was not fully aligned with the specification and documentation process that involves the whole team and including updates of documentation into acceptance criteria of each pull request. Documentation portal shall be launched in August. The work involving finishing and launching documentation portal are tracked by this issue.
Project management portal has been operating internally since Q4 2023, but was not exposed publicly as of yet. It will be launched publicly by the end of August 2024. The work involved in finishing and launching the project management portal for the dms v.0.5 milestone is tracked by this issue
NuNet test management system consists of three main components, which have been developed for months now and are close to completion, but need to be finally coordinated and aligned in the preparation for the start of the DMS v0.5 release process and release candidate testing internally as well as via the community contributions. The components of the test management system are:
CI/CD pipeline that publishes and makes available for further publishing all testing artifacts and reports; These are further used by developers, QA engineers and shall be exposed to community developers publicly;
Feature environment features a small network of geographically distributed virtual machines connected via public internet, and allows for the execution of selected CI/CD pipeline stages automatically on heterogenous hardware environments -- testing functionality of the fully built DMS; Most of the acceptance tests of the frozen feature scope will be running via the
QA management portal is a web portal (Testmo) which exposes all test artifacts via single interface and provides all information for NuNet QA team to see which test are passing / failing for every built of the DMS.
All three components are tightly coupled and will be internally released in quick succession, the last week of August - first week of September, targeting finalizing the test management system launch at the end of first week of September, so that the quality of release candidates can be fully validated by QA team.
Both feature environment and CI/CD process are instrumental to reach release level quality of the developed features. Both have been in development for months prior to current moment and are close to completion. Both are moving targets as they will develop together with the platform. Nevertheless, we aim to launch them as described above in the first half of August.
Given that all prerequisites are launched and prepared, we aim at starting the release process September 15, 2024 by releasing the first release candidate and exposing it to testing. We will release at least 3/4 release candidates and then final release, but the process will be fluid as explained here and most probably fill feature more minor release candidate releases per the adopted branching strategy.
After testing the frozen feature scope of the release, we aim at releasing the 0.5.0 version of device-management-service during the second half of December 2024. For current / updated schedule and details, see release process kick-start presenatation and constantly updated countdown document.
Feature environment
CI/CD pipeline
Test management
Specification and documentation system
Project management portal
Actor model with Object/Security Capabilities
Object/Security Capabilities (UCAN)
Dynamic method dispatch/invocation
Local access (API and CMD)
Local database interface and implementation
Executor interface and implementation
Machine benchmarking
p2p network and routing
Storage interface
IP over Libp2p
Observability and Telemetry
Definition of compute workflows/recursive jobs
Job deployment and orchestration model
Hardware capability model
Supervision model
Tokenomics interface
Feature name
Bootstrap feature environment composed of geographically distributed machines connected via public internet
Work package
Code reference
https://gitlab.com/nunet/test-suite/-/tree/develop/environments/feature?ref_type=heads
Description / definition of done
1) Selected stages of CI/CD pipeline are automatically executed on the fully functional feature environment consisting of geographically dispersed virtual machines 2) Developers are able to test functionalities requiring more than one machine running code; 3) testing artifacts are collected and made accessible from centralized place (GitLab, Testmo, etc) for all tested scenarios / configurations and machines. 4) Interface / process for configure and manage feature environment configurations and reason about complex scenarios involving multiple machines
Timing
1) Capability exposed to development team as soon as possible along in the preparation of release process (could comply to definition of done partially); 2) Full definition of done met and all impacted funcionalities considered by the September 1, 2024 at the latest
Status
On track
Team
Lead: @gabriel.chamon; Supporting: @sam.lake, @abhishek.shukla3143438
Strategic alignment
1) Enables advanced testing and quality assurance on limited hardware; 2) Enables scaling the testing environment from internally onwed to community developers machines, and eventually into testnet; 3) Builds grounds for release management now and in the future (including release candidates, testnet configurations involving third party hardware, canary releases, etc)
Who it benefits
1) NuNet development team ensuring next level quality of CI/CD process and released software 2) Community testers and early compute providers 3) Solution providers who are already considering using NuNet for their business processes and will start testing in release candidate phase 4) Eventually all platform users will benefit from the quality of software
User challenge
1) Developers want to test software as early as possible and access testing data / different hardware / software configurations in real network setting; 2) Community compute providers want to contribute to the development by providing machines for testnet
Value score
n/a
Design
n/a
Impacted functionality
This does not affect any feature (except possibly ability to launch testnet in the future) but rather deals with quality assurance of the whole platform, therefore indirectly but fundamentally affects quality of all features now and in the future.
Acceptance tests
Developers are able to spawn and tear down testing networks on demand for testing custom platform builds and complex functionalities involving more than one machine; CI/CD pipeline incorporates complex functional and integration tests which run on automatically spawned and teared down small (but geographically distributed) real networks of virtual machines
Feature name
Set the CI/CD pipeline able to run full test suite on all environments as defined in text matrix
Work package
Code reference
https://gitlab.com/nunet/test-suite/-/tree/develop/cicd?ref_type=heads
Description / definition of done
1) CI/CD pipeline is structured as per general test management and test matrix based-approaches and executes the minimal configuration for this milestone; 2) The CI/CD process explained and documented so that it could be evolved further via developers contributions 3) The minimal configuration is: 3.1) unit tests run per each defined test matrix trigger / VCS event; 3.2) functional tests (the ones that require code build, but no network) are executed per each defined test matrix trigger / VCS event 4) Each stage of CI/CD pipeline collects and publishes full test artifacts for 4.1) developers for easy access via GitLab flow; 4.2) code reviewers for easy access via GitLab pull requests; 4.3) QA team via Testmo interface; 5) QA requirements and availabilities provided by CI/CD pipeline are integrated into issue Acceptance Criteria
Timing
1, 2, 3 implemented within first half of August 2024; 4 implemented within August; 5 implemented as soon as all is finished, but not later than first week of September;
Status
On track
Team
Lead: @gabriel.chamon; Supporting: @abhishek.shukla3143438, @ssarioglunn
Strategic alignment
1) CI/CD pipeline integrates to the development process by enabling automatic testing of code against formalized functional requirements / scope of each release / milestone; 2) CI/CD pipeline process integrates into the test management process (of integrating new tests into the pipeline and ensuring that all testing domain is covered with each build) 3) Proper CI/CD pipeline and its visibility is instrumental for reaching our business goals of delivering quality software that is evolvable
Who it benefits
1) NuNet development team ensuring next level quality of CI/CD process and released software 2) Internal QA team having the interface to easily access all built errors / issues and update requirements as needed 3) Eventually all platform users will benefit from the quality of software
User challenge
device-management-service code with the same build will run in diverse scenarios and diverse machine / os configurations while providing robust functionality; CI/CD pipeline process (together with test management process) will need to ensure that a) all QA requirements for implemented functionality scope are properly formalized and placed in correct test stages for exposing each build to them b) updated and/or newly defined functionality scope (during release process), including tests included as a result of community bug reports, are properly integrated into QA scope abd the CI/CD pipeline
Value score
n/a
Design
n/a
Impacted functionality
This does not affect any feature (except possibly ability to launch testnet in the future) but rather deals with quality assurance of the whole platform, therefore indirectly but fundamentally affects quality of all features now and in the future.
Acceptance tests
n/a
Feature name
Set up test management system, visibility tools and integration with CI/CD and Security pipelines
Work package
Code reference
https://gitlab.com/nunet/test-suite
Description / definition of done
As detailed in work package deliverables: https://gitlab.com/nunet/architecture/-/issues/207
Status
With challenges
Team
Lead: @abhishek.shukla3143438; Supporting: @gabriel.chamon, @ssarioglunn
Strategic alignment
1) Test management system will enable 1.1) Define quality requirements and functionalities formally 1.2) Release software that precisely corresponds to the defined quality / functional requirements; 2) Test management system will enable for the functional and quality requirements to evolve together with the code; 3) Test management system implementation will enable for the community developers and testers to be part of the development process and greatly enhance it; 4) Participation of community in test management process will ideally be related to contributors program
Who it benefits
1) NuNet development team ensuring next level quality of the released software 2) Internal QA team having the interface to easily access all built errors / issues and update requirements as needed 3) Eventually all platform users will benefit from the quality of software
User challenge
1) Test management process should be flexible to evolve together with the code and constantly get updated with test vectors / scenarios; These can come both from core team and community developers / testers; Our test management system is fairly complex, involving different stages and frameworks (go for unit tests; Gherkin for other stages) as well as multiple machine environments, simulating real network behavior. In order to reach our goals, careful coordination (fitting together) of all aspects is needed. 2) Special challenge is inclusion of manual tests into the same framework of visibility, but enabling QA team to coordinate manual testing schedules and inclusion of their results into the test artifacts; 3) Community developers and testers should be included into the testing process both by public access to the test suite definitions as well as manual testing process, which is related to contributors programme;
Value score
n/a
Design
as described https://gitlab.com/nunet/test-suite
Impacted functionality
This does not affect any feature (except possibly ability to launch testnet in the future) but rather deals with quality assurance of the whole platform, therefore indirectly but fundamentally affects quality of all features now and in the future.
Acceptance tests
n/a
Feature name
Set up specification and documentation system for all nunet repos
Work package
Code reference
Description / definition of done
1) The documentation process is set up and described, including 1.1) requirement to have README.md files in each package and subpackage, 1.2) general structure and required contents of README.md files; 2) All packages and subpackages contain class diagram written in plantuml and their hierarchy is correctly constructed; 3) Documentation system allows to include package / subpackage specific descriptions or extensions via links in README.md and possibly using additionally files (also in ./specs directory) as needed; 4) Updating specification and documentation of respective packages is included into acceptance criteria of each issue and checked during merge request reviews; 5) Documentation system includes process of requesting and proposing new functionalities and architecture; 6) Regular builds of documentation portal which is based on README.md files
Status
Close to completion
Team
Lead: @0xPravar; Supporting: @kabir.kbr, @janaina.senna
Strategic alignment
As explained in tech discussion 2024/07/25 the goals of specification and documentation system are: 1. Clarity and understanding of: 1.1 architecture; 1.2 functionality; 1.3 tests [i.e. functionality with some emphasis on quality]; 2. [by that enabling/helping] coordination [of development activities] by: 2.1 the core team; 2.2 community; 2.3 integration partners; 3. Making documentation part of the code, i.e. living documentation, which changes with the code and reflects both current status and planned / proposed directions;
Who it benefits
1) NuNet technical board by having space where conceptual architecture and priorities are translated into architectural and functional descriptions 2) Internal platform development team as well as community developers have clearly defined structure architecture and proposed functionality guiding the work and collaboration 4) Internal integrations team (developing use-cases) and third party solution providers have clear documentation of the platform to build solutions on top 5) integration partners, using the system can understand the current and future integration potential on a deep technical level and propose required functionality directly into the development process
User challenge
In order for all stakeholder groups to benefit, the documentation and specification system should be 1) structured enough for all stakeholders to quickly find aspects that are specifically needed for them; 2) flexible enough to express package architecture and implementation specific for maximal clarity and understanding; 3) integrated into development process for easy access by and contribution from internal development team 4) conveniently accessible for communication to community developers, integration partners (for this milestone) and other stakeholders from broader ecosystem (in the future);
Value score
n/a
Design
as described during tech discussion 2024/07/25
Impacted functionality
This does not affect any feature directly but fundamentally enables the quality and integrity of the whole platform functionality, alignment with the business goals, use-case based platform development model and evolvability of the software.
Acceptance tests
Feature name
Actor model and interface; Node and Allocation actors implementations; feature::actor-model; feature::general
Work packages
Code reference
https://gitlab.com/nunet/test-suite/-/tree/develop/environments/feature?ref_type=heads
Description / definition of done
1) Machine onboarded on NuNet via dms act as separate actors (via Node interface); 2) Jobs deployed and orchestrated on the platform act as separate Actors (via Allocation interface); 3) Nodes and Allocations (both implementing the Actor interface) communicate only via the immutable messages (via Message interface and network package's transport layer) and have no direct access to each other private state;
Timing
Actor, Node and Allocation interfaces are correctly implemented at the start of the release process; correct interface implementation means that the send messages to each other, can read and process received messages and initiate arbitrary behaviors via RPC model;
Status
With challenges
Team
Lead: @mobin.hosseini; Supporting: @gugachkr
Strategic alignment
1) Enables the unlimited horizontal scalability of the platform with potentially minimal manual intervention; 2) Enables any eligible entity to join the platform without central control point; 3) Enables concurrency and non-locking by design which is independent of the scale of the platform at any point in time
Who it benefits
1) Solution integrators (providers) who need to use Decentralized Physical Infrastructure; 2) Hardware owners who wish to utilize their infrastructure in a more flexible manner than possible with established orchestration and deployment technologies and without direct involvement with the compute users or building compute marketplaces
User challenge
1) All compute users want to maximize efficient and fast access to optimal hardware for doing a computing job at hand and not to overpay for that; 2) Hardware resource owners want the maximal utilization of their hardware resources without idle time;
Value score
n/a
Design
Impacted functionality
All functionality of the platform is fundamentally affected implementation of actor model; This is especially true for the future projected functionalities involving edge computing, IoT deployments and decentralized physical infrastructure in general.
Acceptance tests
Functional and integration tests defined in node package, dms package related to Actor interface and jobs package related to Allocation interface; tracking issue
Feature name
Implementation of User Controlled Authorization Network (UCAN); DIDs and key management; feature::ucan
Work packages
Code reference
Description / definition of done
Timing
Closely integrated with the Actor system implementation; Every message requires UCAN tokens to be included and verified;
Status
Close to completion
Team
Lead: @vyzo
Strategic alignment
Who it benefits
User challenge
Value score
n/a
Impacted functionality
Implementation of the fundamental zero trust security model.
Acceptance tests
Feature name
Dynamic method dispatch logic for initiating behaviors in actors; feature::remote-invocation
Work packages
Implemented within the scope of Node package
Code reference
issue with minimal description;
Description / definition of done
Methods / functions can be run remotely by sending a message from one Actor to another
Timing
Status
In progress
Team
Strategic alignment
Who it benefits
User challenge
Value score
n/a
Design
Impacted functionality
Fundamental functionality that enables the full realization of the Actor model potential
Acceptance tests
Unit tests of around 90%; Functional / integration tests: sending rpc call from one actor (node or allocation) on different network configuration to another Actor (node or allocation); and initiate chosen method; ; tracking issue
Feature name
Local access to running dms from the machine on which it is running; feature::cli-access
Work packages
Code reference
Description / definition of done
Timing
Status
Almost complete
Team
Strategic alignment
Who it benefits
User challenge
Value score
n/a
Design
Impacted functionality
Configuration of dms; Access to NuNet network from external applications via REST-API;
Acceptance tests
Unit tests of around 90%; Functional / integration tests: api responds to locally issued commands; api does not respond to remotely issued commands; tracking issue
Feature name
Local NoSQL database interface and implementation; feature::local-db
Work packages
Code reference
Description / definition of done
Timing
Status
Almost completed
Team
Strategic alignment
Who it benefits
User challenge
Value score
n/a
Design
Impacted functionality
Configuration management; Local telemetry and logging management (possibly);
Acceptance tests
Unit tests of around 90%; Functional / integration tests: Arbitrary information can be stored, retrieved and searched via the implemented interface; ; tracking issue
Feature name
Executor interface and implementation of docker and firecracker executors; feature::execution-and-resources
Work packages
Code reference
Description / definition of done
Timing
Status
Finished
Team
Strategic alignment
Who it benefits
User challenge
Value score
n/a
Design
Impacted functionality
Definition of generic interface for easy plugging third party developed executables to dms; Full implementation of docker and firecracker executables;
Acceptance tests
Unit tests of around 90%; Functional / integration tests: starting a compute job with docker / firecracker executables; observing the runtime; finishing and receiving results; ; tracking issue
Feature name
Machine [Capability] benchmarking ; feature::machine-benchmarking
Work packages
Code reference
DMS package code and subpackages (mostly node, onboarding and resources subpackages)
Description / definition of done
Timing
Status
In progress
Team
Strategic alignment
Who it benefits
User challenge
Value score
n/a
Design
Impacted functionality
Machine benchmarking is needed for the Capability / Comparison interface implemented in dms.orchestrator.matching subpackage
Acceptance tests
Unit tests; Functional tests: Machines are benchmarked while onboarding, the benchmarking data is stored / accessed via database interface; ; tracking issue
Feature name
p2p network and routing; feature::p2p-network
Work packages
Code reference
Description / definition of done
implemented network package design
Timing
Status
Close to completion
Team
Strategic alignment
Who it benefits
User challenge
Sending and receiving messages directly or via broadcasts;
Value score
n/a
Design
Messages and routing partially explained in research blog on gossipsub, DHT and pull/push mechanisms
Impacted functionality
Fundamental functionality of NuNet -- connecting dms's into p2p neworks and subnetworks;
Acceptance tests
Unit tests; Functional tests: Actors (nodes and allocations) are able to see peers / neighbours; It is possible to send and receive messages from other Actors (nodes and allocations) either directly (addressed) or via gossip routing indirectly; tracking issue
Feature name
Storage interface definition and s3 storage implementation; feature::storage
Work packages
Code reference
Description / definition of done
Timing
Status
Finished
Team
Strategic alignment
Who it benefits
User challenge
Ability for running executors to access data via storage interface and its implementations
Value score
n/a
Design
Impacted functionality
Fundamental functionality of NuNet -- providing input and output data storage for computation processes
Acceptance tests
Unit tests; Functional tests: all executors are able to read and write data to the provided storage, as allowed and via the interface; tracking issue
Feature name
Observability and Telemetry design and implementation; feature::observability
Work packages
Code reference
Description / definition of done
Timing
Status
In progress;
Team
Strategic alignment
Who it benefits
Development team by having full visibility of code logs and traces across the testing networks; Potential integrators and use-case developers for debugging their applications running on decentralized hardware; QA team accessing test logs;
User challenge
Value score
n/a
Design
Impacted functionality
Logging, tracing and monitoring of decentralized computing framework on any level of granularity; Constitutes a part of developer tooling of NuNet, which will be used by both internal team as well as community contributors
Acceptance tests
Unit tests; Functional tests / integration tests: after logging is implemented via telemetry interface and default logging is elasticsearch collector; all telemetry events are stored in elasticsearch database and can be analyzed via API / Kibana dashboard; tracking issue
Feature name
Structure, types and definitions of compute workflows / recursive jobs; feature::workflow-definition
Work packages
Code reference
Description / definition of done
Timing
Status
In progress;
Team
Strategic alignment
Who it benefits
User challenge
Set NuNet job definition format and types in order to be able to orchestrate them via orchestration mechanism
Value score
n/a
Design
Impacted functionality
Used in job orchestration in order to be able to search and match fitting machines that are connected to the network; Related to Capability / Comparison model
Acceptance tests
Unit tests; Functional tests / integration tests: Ability to represent any job that can be represented via kubernetes / nomad in nunet job fomat / convert to inner type and orchestrate its execution; tracking issue
Feature name
Job deployment and orchestration model; feature::job-orchestration
Work packages
Code reference
Description / definition of done
Timing
Status
In progress;
Team
Strategic alignment
Who it benefits
User challenge
Submit a job description and rely on NuNet platform to execute it optimally (including finding fitting machines, connecting them to subnetworks, etc.)
Value score
n/a
Design
Impacted functionality
Related to all sub-packages in the dms package and defines Capability / Comparison model
Acceptance tests
Unit tests; Functional tests / integration tests: Submit a job described in NuNet job description format, observe its deployment and execution and returning results; tracking issue
Feature name
Capability / Comparator model; feature::hardware-capability
Work packages
Part of the orchestrator work package
Code reference
Description / definition of done
Timing
Status
Close to completion
Team
Strategic alignment
Who it benefits
User challenge
Define requested compute Capabilities (included in job definition) and machine Capabilities for searching and matching fitting machines in the network
Value score
n/a
Design
Impacted functionality
(1) Ability to match compute requirements with available Capabilities of machines, considering not only hard (hardware, etc), but also soft requirements (price, time, etc preferences from both sides of matching process); (2) Comparing different machine Capabilities (selecting best machine for a job); (3) Adding / subtracting Capabilities in order to be able to calculate machine usage in real time; See also mentions of Capability model in other functionality descriptions in this document
Acceptance tests
Unit tests; Functional tests / integration tests: via job orchestration integration tests; tracking issue
Feature name
Supervision model; feature::supervision-model
Work packages
Part of the orchestrator work package
Code reference
Description / definition of done
Timing
Status
Not started
Team
Strategic alignment
Who it benefits
User challenge
Value score
n/a
Design
Impacted functionality
Ability to build a 'decentralized' control plane on NuNet; error propagation between Actors participating in the same compute workflow; heartbeat and health-check functionalities; conceptually, supervisor model enables failure recovery and fault tolerance features in the network; related to 'remote procedure calls' functionality;
Acceptance tests
Unit tests; Functional tests / integration tests: build hierarchies of actors (nodes and allocations) that can observe each other; tracking issue
Feature name
Tokenomics interface; feature::tokenomics
Work packages
Code reference
Description / definition of done
Minimal implementation of the interface in order to be able to implement micro-payments layer in the next milestone
Timing
Status
In progress
Team
Strategic alignment
Who it benefits
User challenge
Value score
n/a
Design
Impacted functionality
Ability to conclude peer to peer contracts between machines requesting a job and machines accepting job execution (eventually); Ability to include explicit contract information into each job invocation request, independently of the type of contract and micro-payment channels implementation
Acceptance tests
Unit tests; Functional tests / integration tests as part of job orchestration; tracking issue
Feature name
Prepare and launch project management portal
Work package
There is not specific work package in the current milestone, as project management portal was developed outside its scope;
Code reference
Description / definition of done
1) Project management pages always reflect the latest status of each milestone; 2) Introductory page explains project management portal and process for internal and external users
Status
Close to completion
Team
Lead: @janaina.senna; Supporting: @0xPravar, @kabir.kbr
Strategic alignment
Project management portal is a part of the Critical Chain Project management process that is the basis of our development flow and is integrated into the team process; The aim of CCPM process is to achieve the level where we are able to plan, schedule and implement milestones and releases without delay; The portal is designed to automatically generate and share all important updates about the process with the team as well as external contributors in order to make the process as efficient and transparent as possible; The process is used internally since mid 2023 and shall be included into the contribution program and community developers process;
Who it benefits
1) Development team follows the CCPM process via the project management portal; 2) Marketing team uses project management portal (as well as other internal resources) to shape communications transparently; 3) Operations and business development team can always see the recent status in development process
User challenge
Value score
n/a
Design
As described in project management portal repository readme
Impacted functionality
This does not affect any feature directly but fundamentally enables alignment with the business goals, use-case based platform development model and evolvability of the software.
Acceptance tests
Feature name
IP over Libp2p; feature::ip-over-libp2p
Work packages
Within the scope of network implementation work package; dependent work package in another milestone
Code reference
Description / definition of done
Timing
Status
Close to completion
Team
Strategic alignment
Who it benefits
User challenge
Run programs and frameworks on nunet-enabled machines that need ipv4 connectivity layer
Value score
n/a
Design
Impacted functionality
Acceptance tests
Unit tests; Functional tests / integration tests: (1) spawn a ipv4 network for containers running on different machines to directly interact with each other; (2) Access compute providers via Kubernetes cluster / orchestrate jobs via Kubernetes cluster (advanced); tracking issue
Drive Folder with related working documents and discussions; project management portal repository; ; gitbook public pages
Ability to integrate with third party frameworks for orchestration (e.g. Kubernetes, others) as well as run distributed software (database clusters, etc.); Will be mostly used for the