This page is to kick off discussion of extension topics and collect different perspectives and ideas.
In this model, the OpenStack SDK is implemented as an extensible core, upon which vendor extensions can be plugged in. While the project must focus first on being an OpenStack SDK, the reality is that vendors offer customizations to their services that require specializations, and the goal of the project is to support users of OpenStack clouds.
Where should extensions live?
Vendor specific extensions could be developed outside of the python-openstacksdk repository.
From an OpenStack perspective, this allows the SDK to stay light, only ever containing the code to make OpenStack work.
From a vendor perspective, this is likely a positive in some aspects, negative in others. For one, living outside of the core SDK gives the vendor ultimate freedom in how they handle the extension, while pushing cross-vendor collaboration to the outside. If two vendors want to collaborate on, e.g., a CDN-enabled object storage extension, they likely need a third extension for their collaboration.
From a user perspective, the key differences are likely in distribution and contribution. As long as it’s possible to seamlessly get a distribution of OpenStack SDK plus the extensions they want without requiring numerous individual packages, this can work. Contribution of code across OpenStack and the vendors is split, so coordination of changes is something to consider.
Vendor specific extensions could be developed inside the python-openstacksdk repository.
From an OpenStack perspective, infrastructure needs could become more complicated, as this would likely require third-party testing to be setup. This requires some amount of process for determining how vendor extensions can get in and what they need to do to stay in.
From a vendor perspective, this is likely positive in some aspects, negative in others. Being integrated keeps the extension code near the core code so both grow together more easily. Perhaps some vendors will want that external freedom of developing on their own with their own infrastructure and processes.
From a user perspective, knowing that vendor code has gone through the same rigors that the core code has gone through likely signals an even and expected quality across the board. Users then have the confidence that using one vendor’s extension will provide an experience similar to others in terms of usability, consistency, and quality, given the same test and code quality requirements.
Perhaps extensions could be available both internally and externally to the OpenStack SDK.
This model could account for different perspectives from the vendors on how their extensions are developed, letting the vendor build on the OpenStack SDK in the way they feel benefits their users the most. If there’s some graduation process, external vendor extensions could move to becoming integrated.
Distribution could be handled several ways.
- OpenStack SDK
This is the ultimate core of the project, so it would be able to be distributed as such: a vanilla OpenStack SDK.
- OpenStack SDK + all vendor extensions
A “everything” package could ship all known vendor extensions as a one-stop shop for end-users. If you want to write a sample application to run on multiple vendors or you have cross-vendor needs, packaging such as this could be attractive.
- OpenStack SDK + one vendor’s extensions
A user of one vendor may want to receive only the code relevant to their vendor.
Using the Extensions
Whether extensions are developed internally or externally, they should ideally be consumed in the same manner.
Extensions could be available via an explicit namespace to identify them, say openstack.extensions
Would extensions then be per-service, or per-vendor?
from openstack.extensions import CloudVendor # Everything for a CloudVendor cloud ob = CloudVendor.ObjectStorage(…) cont = ob.create_container(“blah”) cont.upload_file(“foo.txt”)
from openstack.extensions import CloudVendorStorage # CloudVendor’s storage API ob = CloudVendorStorage(…) cont = ob.create_container(“blah”) cont.upload_file(“foo.txt”)
Extensions could be available without being qualified as such: from openstack import CloudVendor
Per the 2014-02-19 meeting, this method was generally frowned upon as it pollutes the top level namespace and doesn’t display enough separation between OpenStack and its vendors.
Preparing Extensions for Use
How does a vendor extension get into the `openstack` or `openstack.extensions` namespace?
In this model, think of the OpenStack SDK as a base class, and a vendor SDK as a subclass. TODO: more details…