P3
Currently Achieved.
16 June
P3 Unit Leader
Haeseung Lee
flows of P3
P3
current "Portals"
including OpenAPIs
current "Products"
current "Backends"
including Database
P3::
API Gateway
& Proxy
P3::Portal
P3::Database
P3::Docker on current OpenStack
bi-directional flow:
"Read" and "Write"
uni-directional flow:
"Read" only
bi-directional flow:
"Read" and "Write" in P3 platform only
P3::Authentication using OpenStack
why is P3 done like this?
P3
- to create an advanced AAA model
- Authentication
- Authorization
- Accounting
- don't rely on and don't interrupt the existing system
- "Read current, Write New One"
- following Agile principles, gradually improving the systems
- currently, P3 are working on
- AAA model
- API frameworks
- Container Orchestration on existing OpenStack
- CI/CD pipelines
- Mock Up/PoC of the Portal
P3 UI
P3


- Authentication
- Roles and permission configuration
- consider RBAC (Role-based Access Control)
- Customer dashboard
- Statistics/Reporting
P3 UI
P3


P3 UI
P3

(you can see this slides as web view for animation)
P3 API
P3

- AAA modeling by RBAC
- Example
- more precisely & accurately for an existing LDAP and permissions
Customer Control Group:
SuperUser Have Control Group C0:
- PAD1, PAD2, PAD3, PAD4, PAD5, PAD6;
- ROLE:
[
PRIVILEGE ( OBJS[PAD1, PAD2, PAD3, PAD4, PAD5], OPS(CA-WRITE)),
PRIVILEGE ( OBJS[PAD5, PAD6], OPS(DWA-WRITE)),
PRIVILEGE ( OBJS[PAD1, PAD2, PAD3, PAD4, PAD5, PAD6], OPS(STAT-ALL)),
PRIVILEGE ( OBJS[USERS], OPS(ADMIN))
]
Product Specific Control Group:
SuperUser Have Product specific Control group:
C1: (CA) with PAD1, PAD2, PAD3, PAD4
Role [
- PRIVILEGE ( OBJS[PAD1, PAD2, PAD3, PAD4], OPS(CA-WRITE))
]
C2: (DWA) with PAD5, PAD6
Role [
- PRIVILEGE ( OBJS[PAD5, PAD6], OPS(DWA-WRITE))
]
P3 API
P3


- API Gateway for Interactive UI
(swagger based)- Automatic Documentation of APIs
- Automatic input validation
- Automatic proxy of valid requests to upstream API microservices
- API (Micro) Services
- Autogeneration of Service Skeleton
- AAA service


P3 CI/CD
P3
-
Infrastructure
- basic HEAT template to init OpenStack docker swarm cluster
- persistence support (Cinder + Rexray)
- Swarm monitoring
- Nexus repo on top of Swarm
-
Pipelines
- have a setup to run pipelines in GitLab
- have standalone runner & swarm runners (as Docker Stack)
- ApiSync & Swaggerfile-Merger
P3 CI/CD
P3


P3 CI/CD
P3

P3 CI/CD
P3
P3 CI/CD
P3
Source Code
. new coded
. edited
. test code
Merged to GitLab
. running pipeline
API definition
. Swagger file
Build on Nexus
. Repository
. Repo UI provide
Build Docker
. on Docker Swarm - OpenStack
. automatically deployed to
- Swagger Merger
- API Gateway
Nexus Repo(failed)
. persistent volume
. re-build repo automatically
Pipelines (on GitLab)
. APISync - automatic update & review
. Swagger Merger - for micro service API
Portainter
. Swarm Monitoring
P3 UI
. OUI admin features
. AURORA CA/DWA Stats/Report
API Gateway
. Autogeneration of Services skeleton
-test case generation(unit/functional)
-Dockerfile creation
.Generation of setup tools
.static analysis
.coverage reports
. AAA Service
-Authentication on existing LDAP
-AAA model for P3(newly build)
Currently Achieved by P3
P3
Major Toolchains for DevOps, Agile Migration of Platform
- P3 API Gateway
- gitlab-runner-minio
- infra-docker-registry-frontend
- infra-nginx-proxy
- infra-portainer
- logging-elsticsearch
- logging-kibana
- logging-logstash
- monitoring-alertmanager
- monitoring-grafana
- monitoring-prometheus
- portal
- swagger-ui
- aaa-service
- ldap with Authentication-Authorization
further step
P3
. P3 API Gateway
- to connect legacy APIs
- to integrate AAA Model with existing LDAP and Portal
- to make AAA model precisely and practically
. P3 UI
- to build mockup / fast prototyping with toggle and/or dark launching
- to improve data visualizations and user experience
. P3 CI/CD with Infrastructure
- to make stabilize cluster in OpenStack and plan to move
- to make everything fully automated
- to have monitoring of infrastructure and services
- to manage sub domains
. Recruiting
- Rhio & Michael's retirements - back fill needed for front-end developers
. Stakeholders, and each products
- to provide feature/function requests from 'real' customers
- to provide each APIs for connection API-centric architecture
- to support scope & goals, technically
P3 - POC
By Lee, Haeseung
P3 - POC
- 121