libcloud-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From InAnimaTe <...@git.apache.org>
Subject [GitHub] libcloud pull request #876: New Rancher Container Driver
Date Thu, 29 Sep 2016 03:31:37 GMT
GitHub user InAnimaTe opened a pull request:

    https://github.com/apache/libcloud/pull/876

    New Rancher Container Driver

    ## Rancher Container Driver
    
    ### Description
    
    This is a new Container Driver for [Rancher](http://rancher.com/), the fantastic container
orchestration platform support the likes of Kubernetes, Docker Swarm, and Mesos frameworks.
It provides a fantastic abstraction layer for working with these frameworks on any infrastructure
you'd like! Plus it's [open-source](https://github.com/rancher/rancher)!
    
    Utilizing the v1 API and extensively working with the [docs](http://docs.rancher.com/rancher/v1.2/en/api/),
I've managed to get an initial version of a fairly reliable ContainerDriver for Libcloud.
It follows the normal Container conventions as closely as possible and provides extensive
docstrings for excellent interaction, even without a massive understanding of Rancher itself.
    
    The three main top-level Rancher items are implemented:
    
    * Containers
    * Services (`ex_*`)
    * Environments (`ex_*`)
    
    Although not every possible action is available, the necessities like creation and deletion
plus things like activation, get, and list are included.
    
    > As you review this, please ask questions if you aren't sure about how something is
implemented!
    
    #### Background
    
    With [Arroyo Networks'](https://arroyonetworks.com/) upcoming NaaS platform, [Inflow](https://arroyonetworks.com/#services),
I've been hard at work establishing our Infrastructure assets. Rancher has seemed a clear
choice to help us maintain a nimble platform not tied to any specific back-end Infrastructure
provider. Hence, much of our Python code needs a way to interact with our clusters, so writing
a Libcloud plugin was pretty much a no-brainer.
    
    #### Example
    
    ```
    from libcloud.container.providers import get_driver
    from libcloud.container.types import Provider
    
    driver = get_driver(Provider.RANCHER)
    connection = driver(key="ACCESS_KEY_HERE", secret="SECRET_KEY_HERE", host="172.30.0.100",
port=8080)
    
    image = ContainerImage("hastebin", "hastebin", "rlister/hastebin", "latest", driver=None)

    newcontainer = connection.deploy_container("myawesomepastebin", image, environment={"STORAGE_TYPE":
"file"})
    ```
    
    ### Status
    
    - done, ready for review
    
    I have tested this works appropriately with Rancher Server v1.1.3 (API v1).
    
    Of course, I want persons looking at this to pay attention to the whole PR. However, there
are a few key areas I want some focus on:
    
    * Unnecessary sections (do I really need `parse_body`?)
    * Inefficient handling (is there a better way to do Image parsing or TLS/SSL support?)
    * Error Handling looks/works sanely.
    * Convention adherence (I'm a newer programmer; I may not know well established `*ism's`)
    
    I encourage reviewers to pull my branch and play with this ;)
    
    #### Notes
    
    * Does not support user based API credentials, only Environment API credentials (one env,
no cluster support)
    * Does not support images other than docker formatted images. `docker:` prefix is forced!
        * Images follow a standardized format. See `deploy_container` docstring!
    * Does not support filters for searching/listing. (no `image` or `all` support in `list_containers`)
    * The `launchConfig` for `ex_deploy_service` is actually all defined at the top level.
This is because I easily pass it through `_build_payload` (**kwargs) since the options are
nearly identical to those of a normal container. No reason to duplicate work. This also makes
it easier since most people only generally want to deploy a service with only one container
anyways. This may need to change later when we want >1 container for a service.
    * Passing your own cert/key for SSL/TLS is not presently supported.
    * For SSL/TLS (https) support with newer versions of OpenSSL, the following is necessary
(in your own code): 
    
            import ssl
            import libcloud.security
            libcloud.security.SSL_VERSION = ssl.PROTOCOL_TLSv1_2
    
    
    ### Checklist (tick everything that applies)
    
    - [x] [Code linting](http://libcloud.readthedocs.org/en/latest/development.html#code-style-guide)
(required, can be done after the PR checks)
    - [x] Documentation - See Docstrings
    - [ ] [Tests](http://libcloud.readthedocs.org/en/latest/testing.html) - *Not yet...*
    - [ ] [ICLA](http://libcloud.readthedocs.org/en/latest/development.html#contributing-bigger-changes)
(required for bigger changes) - *Should be done in the next day/two.*
    
    ### Thanks
    
    I have worked closely with [Anthony Shaw](https://github.com/tonybaloney), a core contributor
to Libcloud (especially the Container stuffs) as well as [Vincent Fiduccia](https://github.com/vincent99),
software architect at Rancher Labs. The have been invaluable in helping me establish a solid
driver for Rancher.

You can merge this pull request into a Git repository by running:

    $ git pull https://github.com/ArroyoNetworks/libcloud rancher_driver

Alternatively you can review and apply these changes as the patch at:

    https://github.com/apache/libcloud/pull/876.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

    This closes #876
    
----
commit 3143283f5805b2339489fee05569d2563ca48d39
Author: Mario Loria <mario@arroyonetworks.com>
Date:   2016-09-28T03:12:46Z

    initial push

commit 675cb6b8f77ec466e107eb06c72bbf7e50f70993
Author: Mario Loria <mario@arroyonetworks.com>
Date:   2016-09-29T01:57:39Z

    docstrings, flake8, error handling

----


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---

Mime
View raw message