You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@thrift.apache.org by "James E. King III (JIRA)" <ji...@apache.org> on 2019/02/14 00:06:00 UTC

[jira] [Commented] (THRIFT-4802) Automatic library deployment on online CDN/Repository services

    [ https://issues.apache.org/jira/browse/THRIFT-4802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16767721#comment-16767721 ] 

James E. King III commented on THRIFT-4802:
-------------------------------------------

We would likely use a special build job in Travis CI that hands credentials to the build job to be able to publish.  Each package manager has a different set of instructions and criteria for getting things published.  Some of them (like maven) require manual steps, where you first publish to a staging area and then you have to commit it.  I don't think it can be entirely automated for a while but it is definitely a good goal to look forward to.  When we go through the next release I have a task to thoroughly document the steps required for each external package manager.  Then we'll have a better sense for what will be involved.


> Automatic library deployment on online CDN/Repository services
> --------------------------------------------------------------
>
>                 Key: THRIFT-4802
>                 URL: https://issues.apache.org/jira/browse/THRIFT-4802
>             Project: Thrift
>          Issue Type: Improvement
>          Components: Deployment
>    Affects Versions: 0.12.0
>            Reporter: Thibault Piana
>            Priority: Critical
>              Labels: cdn, deploy,deployment, library
>         Attachments: Workflow.png
>
>
> Hello everyone,
> This thread follows some other threads dealing with concerns about online libraries (THRIFT-4688, THRIFT-4687), as well as emails being sent to the user mailing list about the Docker container on DockerHub.
> If I understand the situation correctly, at the moment, with each new version of the software, you must prepare and update each library on each website independently.
> In addition, each of those libraries is managed by different people, with whom contact is not always easy.
> Also, I would like to propose here a system that would offer the following advantages:
>  - No more worrying about who is maintaining each platform/CDN/Repositories...
>  - No more manual uploading on each platform at each release
>  - Allow anyone to develop an extension to put a Thrift package online on a particular site (For example, a version for Yocto as I requested in a recent email), and be sure this package will be updated at each new release.
> I will try to explain my idea in the following.
> h2. Vocabulary
>  * *CDN :* Content delivery network
>  * *Manager :* An algorithm to upload content to a CDN/online repository
>  * *Orchestrator :* The algorithm that orchestrates the execution of managers, provides credentials, manages manager feedback, and generates the final report
>  * *Package* : The library/component we want to upload on the CDN
> In the following, all online resources providers/repositories (like Pypi, NPMJs, DockerHub ...) will be called "CDN"
> h2. General principle
> The idea would be to develop a single interface for module deployment, with an orchestrator to automatically configure and perform these deployments. 
> The organization would be like this :
>  * A Keepass database will store all passwords/identifiers required for each platform (NPMJS, Pypi, DockerHub, ...) :
>  ** Each module will specify what credentials it needs from this database.
>  ** This database could be committed directly on the repo, to be sure each committers have the most recent version.
>  ** The master password of this database will only be known by committers (or project chair).
> I think KeePass is quite perfect for this, Keepass databases are very lightweight, highly secure, and almost impossible to brute-force.
>  * For each CDN, a manager is in charge of bundling (create the package to upload from Thrift current release sources), uploading and checking the package on the CDN :
>  ** First, the orchestrator load required IDs from the KeePass database
>  ** The orchestrator creates a temporary directory where the manager will be able to bundle everything it needs.
>  *** The manager receives credentials, a path to a temporary directory and a path to Thrift sources
>  *** The manager checks online if the current version of the package already exists online. If not, it will upload it
>  *** The manager prepares the bundled package, upload it and check if everything went well.
> All these steps could be executed in a dedicated Docker/Vagrant environment containing all needed libraries to bundle the package (So that the person/commiter executing the script does not have to download 500 dependencies).
> The algorithm diagram is provided in attached (it's a draft)
> The directory structure of this solution could be something like this (I chose Python arbitrarily here):
> {code:java}
> root
> └── deployment/
>     ├── access.kdbx
>     ├── deploy.py
>     ├── libraries # Some managers
>     │   ├── javascript
>     │   │   ├── npm.py
>     │   │   ├── bower.py
>     │   │   └── a_random_cdn.py
>     │   ├── nodejs
>     │   │   └── npm.py
>     │   └── python
>     │   └── pypi.js
>     │   └── ...
>     └── miscellaneous # Some other managers
>         ├── docker
>         │   └── docker.py
>         └── yocto
>         └── yocto.py
>         └── ...{code}
> I am not a regular contributor on open source projects. So I don't know if I'm making my proposal in the best way. But I really like this project and I would like to help improve it
> I had this idea based on what had been put in place in a project I was recently leading. It is not perfect but does the job properly, and it's a solution I find quite elegant because we don't have to worry about the credentials of each site.
> If you find this idea interesting, I could propose a prototype in a personal repository with some examples of managers for Npm, Pypi, and DockerHub (for example) in several weeks.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)