Thanks Ian!
[ OpenStack :: API ]
- API Guide .. the concepts in the API - API Ref .. a reference for the API Can we prioritize one over the other?
We should do the concepts and the ref at the same time. The new OpenStack approach allows for tags to go in the code. Let's start with this work.
Understood.
[ StarlingX :: API ]
It seems we can categorize the StarlingX APIs in 2: - Brand New APIs from StarlingX projects - Existing APIs from OpenStack projects
StarlingX should not document other OpenStack API's, would their documentation not the source of truth?
They are :) let's prioritize Flock.
[ StarlingX :: API :: Brand New ]
The projects falling into this category are the following:
- [0] NFVI Orchestration - [1] High Availability/Process Monitoring/Service Management - [2] StarlingX System Configuration Management - [3] Horizon plugins for new StarlingX services - [4] Installation/Update/Patching/Backup/Restore
Can we considered all the above to be included in this API documentation effort? Are we missing any other?
All projects in the Flock should be included. I think there is a dependency on some of the code restructuring activities that are underway, we need to make sure these activities don't collide.
Yep! As discussed in the thread [Starlingx-discuss] Restructuring round 2 [0] [0] http://lists.starlingx.io/pipermail/starlingx-discuss/2018-August/000499.htm...