Dulwich.io dulwich / 1c53c47
More md => rst. Jelmer Vernooń≥ 26 days ago
4 changed file(s) with 137 addition(s) and 137 deletion(s). Raw diff Collapse all Expand all
00 include NEWS
11 include AUTHORS
2 include README.md
3 include README.swift.md
2 include README.rst
3 include README.swift.rst
44 include Makefile
55 include COPYING
6 include CONTRIBUTING.md
6 include CONTRIBUTING.rst
77 include TODO
88 include setup.cfg
99 include dulwich/stdint.h
+0
-133
README.swift.md less more
0 Openstack Swift as backend for Dulwich
1 ======================================
2 Fabien Boucher <fabien.boucher@enovance.com>
3
4 The module dulwich/contrib/swift.py implements dulwich.repo.BaseRepo
5 in order to being compatible with Openstack Swift.
6 We can then use Dulwich as server (Git server) and instead of using
7 a regular POSIX file system to store repository objects we use the
8 object storage Swift via its own API.
9
10 c Git client <---> Dulwich server <---> Openstack Swift API
11
12 This implementation is still a work in progress and we can say that
13 is a Beta version so you need to be prepared to find bugs.
14
15 Configuration file
16 ------------------
17
18 We need to provide some configuration values in order to let Dulwich
19 talk and authenticate against Swift. The following config file must
20 be used as template:
21
22 [swift]
23 # Authentication URL (Keystone or Swift)
24 auth_url = http://127.0.0.1:5000/v2.0
25 # Authentication version to use
26 auth_ver = 2
27 # The tenant and username separated by a semicolon
28 username = admin;admin
29 # The user password
30 password = pass
31 # The Object storage region to use (auth v2) (Default RegionOne)
32 region_name = RegionOne
33 # The Object storage endpoint URL to use (auth v2) (Default internalURL)
34 endpoint_type = internalURL
35 # Concurrency to use for parallel tasks (Default 10)
36 concurrency = 10
37 # Size of the HTTP pool (Default 10)
38 http_pool_length = 10
39 # Timeout delay for HTTP connections (Default 20)
40 http_timeout = 20
41 # Chunk size to read from pack (Bytes) (Default 12228)
42 chunk_length = 12228
43 # Cache size (MBytes) (Default 20)
44 cache_length = 20
45
46
47 Note that for now we use the same tenant to perform the requests
48 against Swift. Therefor there is only one Swift account used
49 for storing repositories. Each repository will be contained in
50 a Swift container.
51
52 How to start unittest
53 ---------------------
54
55 There is no need to have a Swift cluster running to run the unitests.
56 Just run the following command in the Dulwich source directory:
57
58 $ PYTHONPATH=. python -m dulwich.contrib.test_swift
59
60 How to start functional tests
61 -----------------------------
62
63 We provide some basic tests to perform smoke tests against a real Swift
64 cluster. To run those functional tests you need a properly configured
65 configuration file. The tests can be run as follow:
66
67 $ DULWICH_SWIFT_CFG=/etc/swift-dul.conf PYTHONPATH=. python -m dulwich.contrib.test_swift_smoke
68
69 How to install
70 --------------
71
72 Install the Dulwich library via the setup.py. The dependencies will be
73 automatically retrieved from pypi:
74
75 $ python ./setup.py install
76
77 How to run the server
78 ---------------------
79
80 Start the server using the following command:
81
82 $ python -m dulwich.contrib.swift daemon -c /etc/swift-dul.conf -l 127.0.0.1
83
84 Note that a lot of request will be performed against the Swift
85 cluster so it is better to start the Dulwich server as close
86 as possible of the Swift proxy. The best solution is to run
87 the server on the Swift proxy node to reduce the latency.
88
89 How to use
90 ----------
91
92 Once you have validated that the functional tests is working as expected and
93 the server is running we can init a bare repository. Run this
94 command with the name of the repository to create:
95
96 $ python -m dulwich.contrib.swift init -c /etc/swift-dul.conf edeploy
97
98 The repository name will be the container that will contain all the Git
99 objects for the repository. Then standard c Git client can be used to
100 perform operations against this repository.
101
102 As an example we can clone the previously empty bare repository:
103
104 $ git clone git://localhost/edeploy
105
106 Then push an existing project in it:
107
108 $ git clone https://github.com/enovance/edeploy.git edeployclone
109 $ cd edeployclone
110 $ git remote add alt git://localhost/edeploy
111 $ git push alt master
112 $ git ls-remote alt
113 9dc50a9a9bff1e232a74e365707f22a62492183e HEAD
114 9dc50a9a9bff1e232a74e365707f22a62492183e refs/heads/master
115
116 The other Git commands can be used the way you do usually against
117 a regular repository.
118
119 Note the daemon subcommands starts a Git server listening for the
120 Git protocol. Therefor there is no authentication or encryption
121 at all between the cGIT client and the GIT server (Dulwich).
122
123 Note on the .info file for pack object
124 --------------------------------------
125
126 The Swift interface of Dulwich relies only on the pack format
127 to store Git objects. Instead of using only an index (pack-sha.idx)
128 along with the pack, we add a second file (pack-sha.info). This file
129 is automatically created when a client pushes some references on the
130 repository. The purpose of this file is to speed up pack creation
131 server side when a client fetches some references. Currently this
132 .info format is not optimized and may change in future.
0 Openstack Swift as backend for Dulwich
1 ======================================
2 Fabien Boucher <fabien.boucher@enovance.com>
3
4 The module dulwich/contrib/swift.py implements dulwich.repo.BaseRepo
5 in order to being compatible with Openstack Swift.
6 We can then use Dulwich as server (Git server) and instead of using
7 a regular POSIX file system to store repository objects we use the
8 object storage Swift via its own API.
9
10 c Git client <---> Dulwich server <---> Openstack Swift API
11
12 This implementation is still a work in progress and we can say that
13 is a Beta version so you need to be prepared to find bugs.
14
15 Configuration file
16 ------------------
17
18 We need to provide some configuration values in order to let Dulwich
19 talk and authenticate against Swift. The following config file must
20 be used as template::
21
22 [swift]
23 # Authentication URL (Keystone or Swift)
24 auth_url = http://127.0.0.1:5000/v2.0
25 # Authentication version to use
26 auth_ver = 2
27 # The tenant and username separated by a semicolon
28 username = admin;admin
29 # The user password
30 password = pass
31 # The Object storage region to use (auth v2) (Default RegionOne)
32 region_name = RegionOne
33 # The Object storage endpoint URL to use (auth v2) (Default internalURL)
34 endpoint_type = internalURL
35 # Concurrency to use for parallel tasks (Default 10)
36 concurrency = 10
37 # Size of the HTTP pool (Default 10)
38 http_pool_length = 10
39 # Timeout delay for HTTP connections (Default 20)
40 http_timeout = 20
41 # Chunk size to read from pack (Bytes) (Default 12228)
42 chunk_length = 12228
43 # Cache size (MBytes) (Default 20)
44 cache_length = 20
45
46
47 Note that for now we use the same tenant to perform the requests
48 against Swift. Therefor there is only one Swift account used
49 for storing repositories. Each repository will be contained in
50 a Swift container.
51
52 How to start unittest
53 ---------------------
54
55 There is no need to have a Swift cluster running to run the unitests.
56 Just run the following command in the Dulwich source directory::
57
58 $ PYTHONPATH=. python -m dulwich.contrib.test_swift
59
60 How to start functional tests
61 -----------------------------
62
63 We provide some basic tests to perform smoke tests against a real Swift
64 cluster. To run those functional tests you need a properly configured
65 configuration file. The tests can be run as follow::
66
67 $ DULWICH_SWIFT_CFG=/etc/swift-dul.conf PYTHONPATH=. python -m dulwich.contrib.test_swift_smoke
68
69 How to install
70 --------------
71
72 Install the Dulwich library via the setup.py. The dependencies will be
73 automatically retrieved from pypi::
74
75 $ python ./setup.py install
76
77 How to run the server
78 ---------------------
79
80 Start the server using the following command::
81
82 $ python -m dulwich.contrib.swift daemon -c /etc/swift-dul.conf -l 127.0.0.1
83
84 Note that a lot of request will be performed against the Swift
85 cluster so it is better to start the Dulwich server as close
86 as possible of the Swift proxy. The best solution is to run
87 the server on the Swift proxy node to reduce the latency.
88
89 How to use
90 ----------
91
92 Once you have validated that the functional tests is working as expected and
93 the server is running we can init a bare repository. Run this
94 command with the name of the repository to create::
95
96 $ python -m dulwich.contrib.swift init -c /etc/swift-dul.conf edeploy
97
98 The repository name will be the container that will contain all the Git
99 objects for the repository. Then standard c Git client can be used to
100 perform operations against this repository.
101
102 As an example we can clone the previously empty bare repository::
103
104 $ git clone git://localhost/edeploy
105
106 Then push an existing project in it::
107
108 $ git clone https://github.com/enovance/edeploy.git edeployclone
109 $ cd edeployclone
110 $ git remote add alt git://localhost/edeploy
111 $ git push alt master
112 $ git ls-remote alt
113 9dc50a9a9bff1e232a74e365707f22a62492183e HEAD
114 9dc50a9a9bff1e232a74e365707f22a62492183e refs/heads/master
115
116 The other Git commands can be used the way you do usually against
117 a regular repository.
118
119 Note the daemon subcommands starts a Git server listening for the
120 Git protocol. Therefor there is no authentication or encryption
121 at all between the cGIT client and the GIT server (Dulwich).
122
123 Note on the .info file for pack object
124 --------------------------------------
125
126 The Swift interface of Dulwich relies only on the pack format
127 to store Git objects. Instead of using only an index (pack-sha.idx)
128 along with the pack, we add a second file (pack-sha.info). This file
129 is automatically created when a client pushes some references on the
130 repository. The purpose of this file is to speed up pack creation
131 server side when a client fetches some references. Currently this
132 .info format is not optimized and may change in future.
8383 setup_kwargs['test_suite'] = 'dulwich.tests.test_suite'
8484 setup_kwargs['tests_require'] = tests_require
8585
86 with io.open(os.path.join(os.path.dirname(__file__), "README.md"),
86 with io.open(os.path.join(os.path.dirname(__file__), "README.rst"),
8787 encoding="utf-8") as f:
8888 description = f.read()
8989