When different OpenStack projects need to use each others' services, these are exposed through each project's public API. There is a number of issues that arise form this situation. REST APIs that OpenStack services expose to users are sometimes not best suited for inter-service RPCs. Another issue is that versioned public APIs can be too rigid to evolve with the needs of the codebase. Ultimately, they also usually deal with different levels of abstraction than the user of the service.
There have been several attempts to make this situation better. One of the most notable ones is https://blueprints.launchpad.net/nova/+spec/admin-event-callback-api where we provide an API resource that can be used to notify Nova that something it has requested has happened (or has not happened). Another similar example is qemu-assisted-snapshots introduced in Havana.
In this session, I would like to explore the possible paths from here. It seems that we have already accepted that there is a problem with using public API's for RPC, and there are solutions already in place to make this better. Some ideas: * Have a tiered REST API with different stability guarantees for components (What about upgrades? versioning?) * Is it really REST that we need (cross project RPC? This has probably come up before) * What about clients, do we need a different clinet/SDK
I am proposing this as a Nova session for now, as most of the work around this originated in Nova, and also Nova is usually the central piece that consumes other projects APIs.
