Hi all, Before submitting a formal proposal for Quantum API v1.1, I think it might be worth discussing it with all the parts involved.
In earlier meeting we agreed (please correct me if I'm wrong) that the we aimed at delivering a production-ready version for Quantum in the Essex release cycle. Of course, in the case of Quantum this implies that we need both a production-ready service interface as well as at least a production ready plugin. In this thread I would like to focus on the improvements we need to make to the Quantum API for making it production ready. I also think AuthN/AuthZ deserves a separate discussion thread, so I'm not going to discuss them here. In my opinion, in order to achieve a production-ready API we need: 1. Ensure the Quantum service interface satisfies reliability, efficiency and scalability requirements Defining these requirements is probably the most important part of the job here. However, IMHO, the following might represent some general guidelines to achieve these goals: * Set up a CI system with "real" plugins in order to find ensure the API and the plugin interface are bug free; * Implement HA for Quantum; * Profile Quantum API calls in order to understand which ones might be made more efficient either by improving the code, adding mechanisms such as caches, or re-architecting them; * Perform stress testing aimed at identifying scalability bottlenecks in the Quantum API 2. Improve the Quantum API in a way that it would be easier for client application to consume it Putting this in another way, we could say that we want to bring Quantum API on a par with the Openstack API, possibly in the following way: * Provide the capability of specifying filters on API requests * Support paginated collections on responses * Provide ATOM links to resources on response o Also make them permanent and version-independent * Add a Rate Limiting middleware layer What are your opinions. Do you think it would make sense to focus on reliability, efficiency, and scalability as well as ensuring the Quantum API can be easily consumed by client applications? Also, the other topic I reckon we need to discuss is whether we want to extend the core of the Quantum API. This will revert us back to the discussion of core vs. extensions that we had before the Diablo design summit. For Diablo, we agreed to start with smallest possible core and then starting to "expand it". That decision made completely sense for Diablo; we should now decide whether we want to expand it or keep it small for the Essex release cycle. As usual, there are pro and cons to be weighted. Here's my first attempt to them on a scale: In Favour of extending core: * If Essex will be "production-ready" we might prefer to have a larger core with some non-implemented API rather than a smaller core which would be extended for F,G, and so on. A small core with a high number of extension will be probably not ideal for production ready releases, as most clients will need to explicitly use plugin-specific extensions. * Some of the currently implemented extensions, such as QoS, and in some form the port-profile as well, could easily be integrated into the core API, as they are general enough; it is therefore possible to assume it is something most plugins will implement. * The APIs for bridging Quantum networks with other Quantum networks or with networks running outside of Quantum, initially proposed for Diablo, were dropped. It might be worth re-considering them for Essex,given the fact that they are representative of a very important use case. Against extending core: * Before adding a feature into the core API, the feature itself and the APIs for using it should be thoroughly reviewed and agreed by the community. A feature should therefore first spend some time "incubating" as an extension before being "approved" for core. * We don't want the API to bloat with many new features for a release which is supposed to be stable. The smaller the core API, the easier stabilisation will be. Regards, Salvatore
-- Mailing list: https://launchpad.net/~netstack Post to : netstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~netstack More help : https://help.launchpad.net/ListHelp
