README.swift 4.6 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132
  1. Openstack Swift as backend for Dulwich
  2. ======================================
  3. The module dulwich/swift.py implements dulwich.repo.BaseRepo
  4. in order to being compatible with Openstack Swift.
  5. We can then use Dulwich as server (Git server) and instead of using
  6. a regular POSIX file system to store repository objects we use the
  7. object storage Swift via its own API.
  8. c Git client <---> Dulwich server <---> Openstack Swift API
  9. This implementation is still a work in progress and we can say that
  10. is a Beta version so you need to be prepared to find bugs.
  11. Configuration file
  12. ------------------
  13. We need to provide some configuration values in order to let Dulwich
  14. talk and authenticate against Swift. The following config file must
  15. be used as template:
  16. [swift]
  17. # Authentication URL (Keystone or Swift)
  18. auth_url = http://127.0.0.1:5000/v2.0
  19. # Authentication version to use
  20. auth_ver = 2
  21. # The tenant and username separated by a semicolon
  22. username = admin;admin
  23. # The user password
  24. password = pass
  25. # The Object storage region to use (auth v2) (Default RegionOne)
  26. region_name = RegionOne
  27. # The Object storage endpoint URL to use (auth v2) (Default internalURL)
  28. endpoint_type = internalURL
  29. # Concurrency to use for parallel tasks (Default 10)
  30. concurrency = 10
  31. # Size of the HTTP pool (Default 10)
  32. http_pool_length = 10
  33. # Timeout delay for HTTP connections (Default 20)
  34. http_timeout = 20
  35. # Chunk size to read from pack (Bytes) (Default 12228)
  36. chunk_length = 12228
  37. # Cache size (MBytes) (Default 20)
  38. cache_length = 20
  39. Note that for now we use the same tenant to perform the requests
  40. against Swift. Therefor there is only one Swift account used
  41. for storing repositories. Each repository will be contained in
  42. a Swift container.
  43. How to start unittest
  44. ---------------------
  45. There is no need to have a Swift cluster running to run the unitests.
  46. Just run the following command in the Dulwich source directory:
  47. $ PYTHONPATH=. nosetests dulwich/tests/test_swift.py
  48. How to start functional tests
  49. -----------------------------
  50. We provide some basic tests to perform smoke tests against a real Swift
  51. cluster. To run those functional tests you need a properly configured
  52. configuration file. The tests can be run as follow:
  53. $ DULWICH_SWIFT_CFG=/etc/swift-dul.conf PYTHONPATH=. nosetests dulwich/tests_swift/test_smoke.py
  54. How to install
  55. --------------
  56. Install the Dulwich library via the setup.py. The dependencies will be
  57. automatically retrieved from pypi:
  58. $ python ./setup.py install
  59. How to run the server
  60. ---------------------
  61. Start the server using the following command:
  62. $ dul-daemon -c /etc/swift-dul.conf -l 127.0.0.1 --backend=swift
  63. Note that a lot of request will be performed against the Swift
  64. cluster so it is better to start the Dulwich server as close
  65. as possible of the Swift proxy. The best solution is to run
  66. the server on the Swift proxy node to reduce the latency.
  67. How to use
  68. ----------
  69. Once you have validated that the functional tests is working as expected and
  70. the server is running we can init a bare repository. Run this
  71. command with the name of the repository to create:
  72. $ dulwich init-swift -c /etc/swift-dul.conf edeploy
  73. The repository name will be the container that will contain all the Git
  74. objects for the repository. Then standard c Git client can be used to
  75. perform operations againt this repository.
  76. As an example we can clone the previously empty bare repository:
  77. $ git clone git://localhost/edeploy
  78. Then push an existing project in it:
  79. $ git clone https://github.com/enovance/edeploy.git edeployclone
  80. $ cd edeployclone
  81. $ git remote add alt git://localhost/edeploy
  82. $ git push alt master
  83. $ git ls-remote alt
  84. 9dc50a9a9bff1e232a74e365707f22a62492183e HEAD
  85. 9dc50a9a9bff1e232a74e365707f22a62492183e refs/heads/master
  86. The other Git commands can be used the way you do usually against
  87. a regular repository.
  88. Note the swift-dul-daemon start a Git server listening for the
  89. Git protocol. Therefor there ins't any authentication or encryption
  90. at all between the cGIT client and the GIT server (Dulwich).
  91. Note on the .info file for pack object
  92. --------------------------------------
  93. The Swift interface of Dulwich relies only on the pack format
  94. to store Git objects. Instead of using only an index (pack-sha.idx)
  95. along with the pack, we add a second file (pack-sha.info). This file
  96. is automatically created when a client pushes some references on the
  97. repository. The purpose of this file is to speed up pack creation
  98. server side when a client fetches some references. Currently this
  99. .info format is not optimized and may change in future.