Solum git integration via push to Solum's git

Registered by Devdatta Kulkarni on 2013-11-22

Enable users to push their code to Solum (via git server(s) hosted by Solum).

Following is the minimum viable use-case:
- A user who is 'registered' with Solum will be able to do git push to their code's remote in Solum.
- Once the code is pushed, it will trigger some set of steps (a workflow) which will generate/update running application.

Blueprint information

Status:
Complete
Approver:
Adrian Otto
Priority:
Medium
Drafter:
Devdatta Kulkarni
Direction:
Needs approval
Assignee:
Julien Vey
Definition:
Approved
Series goal:
Accepted for icehouse
Implementation:
Implemented
Milestone target:
milestone icon juno-2
Started by
Adrian Otto on 2015-06-11
Completed by
Adrian Otto on 2015-06-11

Related branches

Sprints

Whiteboard

In order to implement the above use-case following questions need to be answered:

1) What is the notion of a 'registered user'? Keystone provides abstraction of a tenant/project. How do we tie Keystone's tenant/project with a 'registered user'? Are they the same?

2) How to enable 'git push' access to registered users? Git supports https (username/password) or ssh (public/private keys) based access.
     - One possible approach for supporting ssh-based access would be to provide a API for users to upload their public key as part of registration step. As part of this step we also create a user account on the Git server for that user and set it up for ssh access.
            - Would https://github.com/stackforge/barbican be the service to store user keys?
            - Could we use nova's "nova keypair-add" functionality for this?
      - What are other possible approaches to set this up?

3) How should we provision Git server(s)?
     - Is it a set of load-balanced servers for all Solum users?
     - Do we have one Git server per user?
        - One advantage of this approach:
           - We could use "nova keypair-add" functionality to provision ssh access to the user-specific Git server
        - A disadvantage is that scalability might be an issue
     - Could we use Docker containers for each user's Git server?
          - What are security implications of this design?

4) What are the mechanisms for getting the code from a Git repo to other parts of the Solum system?
     - One option is to use post-receive-hook that sends a tar/zip of the repository via a POST call to the Solum API server.
     - What are other options?

Additional Questions/Considerations:
---------------------------------------------------
1) How do we support a use case of allowing multiple users (developers on a team, for example) pushing to the same git repository in Solum (will be needed for collaborative work).

2) How do we support different levels of accesses to different users (some have read, some have read and write).

3) How do we support RBAC for code access (certain roles may only have read access certain roles may have read and write access).

Following might be useful in developing above capabilities:
[1] http://dl.acm.org/citation.cfm?id=1998460
[2] https://github.com/sitaramc/gitolite/

Gerrit topic: https://review.openstack.org/#q,topic:bp/solum-git-push,n,z

Addressed by: https://review.openstack.org/97550
    Add an autoscaling heat template for the build-farm

Addressed by: https://review.openstack.org/98127
    Add Infrastructure API and db object

Addressed by: https://review.openstack.org/100869
    Add ENTRYPOINT and EXPOSE for Drone

Addressed by: https://review.openstack.org/98128
    Start heat stack when infra stack is created

Addressed by: https://review.openstack.org/101510
    Add images for gitolite

Addressed by: https://review.openstack.org/102868
    Add infrastructure root to have info when GET /infrastructure/

Addressed by: https://review.openstack.org/102869
    Add Marconi client

Addressed by: https://review.openstack.org/104245
    Create marconi queue when infra stack is created

(?)

Work Items

Dependency tree

* Blueprints in grey have been implemented.

This blueprint contains Public information 
Everyone can see this information.