lmarinve
commented
1 month ago Why are the two extra MongoDB instances needed? How do we deploy and use these in a distributed environment?
The N+2 MongoDB instances are part of the Kytos specification and are essential for each kytos OXPO node. These instances ensure redundancy and high availability, which are crucial in a distributed environment. Specifically, the extra MongoDB instances help manage failover scenarios, ensuring the system can maintain its operations without significant disruptions if one or more instances fail.
Deployment: We simulate deploying these MongoDB instances within each OXPO node to establish a local cluster unique to Kytos. This setup ensures that each node operates independently of the others while maintaining high availability and fault tolerance within the node.
Usage: The extra instances replicate data within the node, ensuring consistency and reliability. Other OXPO implementations, such as OESS, may have different requirements and architectures, making this approach unnecessary for Kytos.
Is the extra DB layer inside the NAPP necessary?
The Kytos specification sets it apart from other OXP sites by including an additional database layer inside the NAPP (Network Application). This unique feature serves simulation purposes within the Kytos environment, enhancing its functionality and value. It's important to note that this feature is not a necessity for other OXP sites, as each will have its own database environment.
The internal DB in the NAPP is not just an extra layer. It provides a local data store for the application’s internal operations and simulations, offering a controlled environment for testing and validation. This setup empowers developers to confidently test and validate the NAPP's functionality before deploying it to the actual OXP sites, ensuring a smooth and error-free transition.
Implementation: While this internal DB layer is helpful for development and testing, in a production environment, each OXP site would manage its database independently. This separation ensures that one site's operations do not impact others, preserving the integrity and autonomy of each OXP site.
Solution: A new OXPO wrapper repository, oxpo-api-wrapper, is currently being developed. We designed this wrapper to abstract the conversion and validation code from the specific Kytos specifications. The oxpo-api-wrapper aims to simplify interactions with various OXPO APIs by providing a unified and simplified programming interface. By abstracting the complexities of direct API calls, the wrapper offers a consistent method to interact with different OXPO services, enhancing code readability and maintainability. We will be taking care of the new issues on this repository from the oxpo-api-wrapper repository
italovalcy
There are currently N+2 Mongo DB instances needed for N OXP sites. Then there is internal DB in the NAPP and appeared to have a separate suit of endpoints.
Design review would be healthy to ask:
(1) Why the 2 extra mongo DB are needed? How they are deployed and used in a distributed environment? (2) Is the extra DB layer inside the NAPP necessary?