2. Atlas Architecture tenets
• Database is the source of truth
– Configuration on devices is enforced to match DB
• LBaaS APIs that change state are
asynchronous
– Operations return as soon as DB is updated
– Devices are updated in the background
• Scaling in Atlas is achieved through
– Use of async operations through ActiveMQ
– Use of Cluster of Atlas servers
4. Atlas infrastructure dependency
• Atlas infrastructure is based on:
– Any Java Server (Jetty, Tomcat, Glassfish, JBOSS, etc.)
– Spring framework (IoC, annotations, xml config)
– JAXB (for generating API objects and mapping to REST)
– Dozer (utility to map between Java classes)
– Abstraction of persistence providers (JPA) => DB, ORM
and Transactions
– Abstraction of message queueing (JMS) => Message
Queues
– Unit testing framework (SureFire)
5. Tenant API specification
• Multi-Tenant API
• Specification: wiki.openstack.org/Atlas-LB
• Follows OpenStack API design recommendations
• Determined after careful research into the common
capabilities of open source and commercial load balancers.
• Specified using XML Schema file (XSD)
– API POJO classes generated from spec.
• Supports both JSON and XML
– JSON payload generated from XML schema
– ATOM support skeleton is there
• Can list active extensions
• Support account limits
6. Atlas Plugins and extensions
Core
API A
D
Core
A
P
Extension T
API E
Extension R
14. Adapter Tasks
• Minimum sharing with Core
– Only what is specified in the interface
• Translates Atlas APIs and semantics to device API or
configuration
• Manages IPv4 and IPv6 address pools
• Manages devices. Could include onboarding and failure
detection
• Manages rollback on failure to ensure device config
stays correct
• Decides on device placement for each load balancer
• Reports back any errors to core
23. Atlas Extension Structure
• Extend the core XSD to specify new APIs or
extension into existing APIs
• Extend the resource layer
• Extend the Service Layer
• Extend the Repository layer
• Extend the Async layer
• Extend the adapter layer