Update harbor-satellite-proposal.md

proposals/new/harbor-satellite-proposal.md

@@ -6,20 +6,14 @@ Authors: Vadim Bauer / [Vad1mo](https://github.com/Vad1mo), Csaba Almasi, Philip
 
 ## Abstract
 
-[A short summary of the proposal.]
-
 Harbor Satellite aims to bring Harbor container registries to edge locations, ensuring consistent, available, and integrity-checked images for edge computing environments. This proposal outlines the development of a stateful, standalone satellite that can function as a primary registry for edge locations and as a fallback option if the central Harbor registry is unavailable.
 
 ## Background
 
-[An introduction of the necessary background and the problem being solved by the proposed change.]
-
 In recent years, containers have extended beyond their traditional cloud environments, becoming increasingly prevalent in remote and edge computing contexts. These environments often lack reliable internet connectivity, posing significant challenges in managing and running containerized applications due to difficulties in fetching container images. To address this, the project aims to decentralize container registries, making them more accessible to edge devices. The need for a satellite that can operate independently, store images on disk, and run indefinitely with stored data is crucial for maintaining operations in areas with limited or no internet connectivity.
 
 ## Proposal
 
-[A precise statement of the proposed change.]
-
 The proposed change is to develop "Harbor Satellite", an extension to the existing Harbor container registry. This extension will enable the operation of decentralized registries on edge devices.
 
 Harbor Satellite will synchronize with the central Harbor registry, when Internet connectivity permits it, allowing it to receive and store images. This will ensure that even in environments with limited or unreliable internet connectivity, containerized applications can still fetch their required images from the local Harbor Satellite.
@@ -28,14 +22,10 @@ Harbor Satellite will also include a toolset enabling the monitoring and managem
 
 ## Non-Goals
 
-[Anything explicitly not covered by the proposed change.]
-
-?
+T.B.D.
 
 ## Rationale
 
-[A discussion of alternate approaches and the trade offs, advantages, and disadvantages of the specified approach.]
-
 Deploying a complete Harbor instance on edge devices in poor/no coverage areas could prove problematic since :
 
 - Harbor wasn't designed to run on edge devices.(e.g. Multiple processes, no unattended mode)
@@ -47,14 +37,10 @@ Harbor Satellite aims to be resilient, lightweight and will be able to keep func
 
 ## Compatibility
 
-[A discussion of any compatibility issues that need to be considered]
-
 Compatibility with all container registries or edge devices can't be guaranteed.
 
 ## Implementation
 
-[A description of the steps in the implementation, who will do them, and when.]
-
 Harbor Satellite will run in a single container and will be divided in the following components :
 
 - **Satellite Core** : pulling/pushing images from/to Harbor (using go-libp2p?) and pulling/pushing images from/to the local registry (using Skopeo and/or Crane?).
@@ -66,8 +52,6 @@ Harbor Satellite will run in a single container and will be divided in the follo
 
 ## Open issues (if applicable)
 
-[A discussion of issues relating to this proposal for which the author does not know the solution. This section may be omitted if there are none.]
-
 Harbor Satellite aims to manage, coordinate and schedule containers using a Kubernetes cluster.
 
 Harbor Satellite also aims to use and benefit from Spegel, a registry mirror designed to optimize the pulling of container images within a Kubernetes cluster.