Difference between revisions of "Poppy/Provider - Getting Started"
< Poppy
Amit Gandhi (talk | contribs) |
Amit Gandhi (talk | contribs) (→Building a Provider Driver) |
||
(18 intermediate revisions by 2 users not shown) | |||
Line 1: | Line 1: | ||
− | * [[ | + | == Contributing == |
+ | * Read the [http://docs.openstack.org/infra/manual/developers.html Developer's Guide] on how to contribute | ||
+ | |||
+ | == Readiness == | ||
+ | ==== What limits exist within your CDN? ==== | ||
+ | * Max number of services per account? | ||
+ | ** Poppy will provision all services under one operator account. Depending on the operator, this could result in hundreds of thousands of services provisioned for a single account. | ||
+ | ** Poppy basically encourages a Reseller Model. Poppy currently does not have support for a Master/Sub Account model. | ||
+ | * Purge restrictions/limits | ||
+ | ** Poppy does not limit how many purges a customer can perform. | ||
+ | * CNAME restrictions | ||
+ | ** A poppy operator may choose to CNAME from operatorcdn.com -> providercdn.net, and have their customers CNAME to operatorcdn.com. | ||
+ | * SSL conditions | ||
+ | ** Are there certain authorities that an SSL cert must be issued from for your CDN to accept it? | ||
+ | |||
+ | ==== Logging and Billing ==== | ||
+ | * Where are detailed logs sent to (e.g. S3 Buckets, Swift Container, etc) | ||
+ | * Do you have a method to identify services provisioned via Poppy as an OpenStack account for operator billing purposes? | ||
+ | ** This could be as simple as one operator account and all services under that account are provisioned via Poppy. | ||
+ | |||
+ | == Getting Started with your Provider Driver == | ||
+ | |||
+ | # Understand how the Poppy API is [[Poppy/Server_Architecture|architected]] | ||
+ | # Understand the [https://github.com/stackforge/poppy/tree/master/poppy/provider/mock Mock CDN Provider] for an basic example of what a provider implementation looks like. | ||
+ | # Understand the Provider Driver interface ([https://github.com/stackforge/poppy/tree/master/poppy/provider/base abstract base classes]) that must be conformed to, so that you know what features need to be implemented to interact with your own API's. | ||
+ | # Investigate some of the [https://github.com/stackforge/poppy/tree/master/poppy/provider other provider implementations] to get an idea of how to implement yours. | ||
+ | # Get familiar with the [https://github.com/stackforge/poppy/blob/master/poppy/model/service.py Service Object]. This object is what is passed to the provider driver when creating/updating a configuration. The provider driver will need to parse through these properties and make the appropriate API calls to your API to create the configuration on your end. | ||
+ | # Get familiar with the [https://github.com/stackforge/poppy/blob/master/poppy/provider/base/responder.py Responder functions]. These functions are called to create the response back into the Poppy system from your provider extension. | ||
+ | # Start building your provider driver. | ||
+ | ## Make frequent and small commits and patches. | ||
+ | ## Add unit tests and functional tests for your driver. | ||
+ | ## For each [https://github.com/stackforge/poppy/tree/master/poppy/provider/base provider function], map the appropriate calls to your API. For a matrix of terms, please [http://poppy.readthedocs.org/en/latest/provider_details.html read here]. | ||
+ | |||
+ | |||
+ | ==== Building a Provider Driver ==== | ||
+ | |||
+ | # [[Poppy/Provider - Getting Started/Poppy Features|Poppy Features]] you need to implement | ||
+ | # Step by Step Instructions on [[Poppy/Provider - Getting Started/Building a Provider|Building a Provider]] (with Examples) | ||
+ | # [[Poppy/Provider - Getting Started/Configuration|Configuring your Provider Driver]] to be available for use | ||
+ | # Building a [[Poppy/Provider - Getting Started/Mimic Driver|Mimic Driver]] to mock your Provider API | ||
+ | # Running [[Poppy/Provider - Getting Started/Poppy Conformance Tests|Conformance Tests]] against your new provider | ||
+ | # Running [[Poppy/Provider - Getting Started/Poppy API Tests|API Tests]] using your new provider | ||
+ | # Running [[Poppy/Provider - Getting Started/Poppy End to End Tests|End to End Tests]] with your new provider | ||
+ | |||
+ | ==== Technical Requirements ==== | ||
+ | |||
+ | * The provider driver must be compatible with OpenStack. That means it must support py27,py34,pypy,pep8. | ||
+ | * Any third party library used must be available via the Pypi server. | ||
+ | |||
+ | == Participating in the API Design Process == | ||
+ | |||
+ | * Join the #openstack-poppy channel where the team hangs out and participate in design discussions | ||
+ | * Join and participate in the weekly Poppy meeting every Thursday : [[Meetings/Poppy]] | ||
+ | * Contribute [https://launchpad.net/poppy Blueprints] for potential features that you think need to be incorporated into the Poppy API |
Latest revision as of 18:42, 29 January 2015
Contents
Contributing
- Read the Developer's Guide on how to contribute
Readiness
What limits exist within your CDN?
- Max number of services per account?
- Poppy will provision all services under one operator account. Depending on the operator, this could result in hundreds of thousands of services provisioned for a single account.
- Poppy basically encourages a Reseller Model. Poppy currently does not have support for a Master/Sub Account model.
- Purge restrictions/limits
- Poppy does not limit how many purges a customer can perform.
- CNAME restrictions
- A poppy operator may choose to CNAME from operatorcdn.com -> providercdn.net, and have their customers CNAME to operatorcdn.com.
- SSL conditions
- Are there certain authorities that an SSL cert must be issued from for your CDN to accept it?
Logging and Billing
- Where are detailed logs sent to (e.g. S3 Buckets, Swift Container, etc)
- Do you have a method to identify services provisioned via Poppy as an OpenStack account for operator billing purposes?
- This could be as simple as one operator account and all services under that account are provisioned via Poppy.
Getting Started with your Provider Driver
- Understand how the Poppy API is architected
- Understand the Mock CDN Provider for an basic example of what a provider implementation looks like.
- Understand the Provider Driver interface (abstract base classes) that must be conformed to, so that you know what features need to be implemented to interact with your own API's.
- Investigate some of the other provider implementations to get an idea of how to implement yours.
- Get familiar with the Service Object. This object is what is passed to the provider driver when creating/updating a configuration. The provider driver will need to parse through these properties and make the appropriate API calls to your API to create the configuration on your end.
- Get familiar with the Responder functions. These functions are called to create the response back into the Poppy system from your provider extension.
- Start building your provider driver.
- Make frequent and small commits and patches.
- Add unit tests and functional tests for your driver.
- For each provider function, map the appropriate calls to your API. For a matrix of terms, please read here.
Building a Provider Driver
- Poppy Features you need to implement
- Step by Step Instructions on Building a Provider (with Examples)
- Configuring your Provider Driver to be available for use
- Building a Mimic Driver to mock your Provider API
- Running Conformance Tests against your new provider
- Running API Tests using your new provider
- Running End to End Tests with your new provider
Technical Requirements
- The provider driver must be compatible with OpenStack. That means it must support py27,py34,pypy,pep8.
- Any third party library used must be available via the Pypi server.
Participating in the API Design Process
- Join the #openstack-poppy channel where the team hangs out and participate in design discussions
- Join and participate in the weekly Poppy meeting every Thursday : Meetings/Poppy
- Contribute Blueprints for potential features that you think need to be incorporated into the Poppy API