Jump to: navigation, search

Poppy/Provider - Getting Started

< Poppy
Revision as of 20:20, 26 January 2015 by Amit Gandhi (talk | contribs) (Technical Requirements)

Contributing

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

  1. Understand how the Poppy API is architected
  2. Understand the Mock CDN Provider for an basic example of what a provider implementation looks like.
  3. 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.
  4. Investigate some of the other provider implementations to get an idea of how to implement yours.
  5. 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.
  6. Get familiar with the Responder functions. These functions are called to create the response back into the Poppy system from your provider extension.
  7. Start building your provider driver.
    1. Make frequent and small commits and patches.
    2. Add unit tests and functional tests for your driver.
    3. For each provider function, map the appropriate calls to your API. For a matrix of terms, please read here.


Building a Provider Driver

  1. Provider Driver Features you need to implement
  2. Step by Step Instructions on Building a Provider (with Examples)
  3. Configuring your Provider Driver to be available for use
    1. Add an entry point in setup.cfg so that Poppy recognizes your wonderful new driver and operators can start to use it.
  4. Building a Mimic Driver to mock your Provider API
  5. Running Poppy Conformance Tests against your new provider
  6. Running Poppy API Tests using your new provider
  7. Running Poppy 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