Pod, Service, RC abstraction framework
At present, all of these objects are stored in db and there is a tight coupling. With objects-to-bay work the plan is to fetch the data using k8s REST api. At present Pod, Service, replication controller(RC) resources are specific to Kubernates. Going ahead Docker Swarm, new COE etc might also have these concept so there is a need to have an indirection API layer which can be an entry point and depending on the COE used respective API's can be called. Irrespective of new COE used, using such design pattern can be helpful even in current scenario and will help to simplify code.
This proposal aims to solve this problem.
Blueprint information
- Status:
- Complete
- Approver:
- Adrian Otto
- Priority:
- Low
- Drafter:
- Vilobh Meshram
- Direction:
- Approved
- Assignee:
- Vilobh Meshram
- Definition:
- Obsolete
- Series goal:
- None
- Implementation:
-
Unknown
- Milestone target:
- None
- Started by
- Completed by
- hongbin
Related branches
Related bugs
Sprints
Whiteboard
Please submit an outline of the implementation plan, and level-of-effort estimate (T-Shirt size) for consideration to include this in Mitaka.
According to the decision in Austin design summit, Pod, Service, RC will be removed. Therefore, this BP is not needed anymore -- hongbin 2015-05-01
