master
stable/2023.1
stable/wallaby
stable/zed
stable/ussuri
stable/victoria
stable/xena
stable/yoga
stable/train
23.0.0.0b2
23.0.0.0b1
xena-em
19.7.0
22.0.0
22.0.0.0rc2
21.1.0
20.3.0
19.6.0
22.0.0.0rc1
19.5.0
stein-eol
rocky-eol
queens-eol
wallaby-em
18.6.0
21.0.0
21.0.0.0rc2
21.0.0.0rc1
20.2.0
19.4.0
18.5.0
20.1.0
19.3.0
18.4.0
pike-eol
victoria-em
17.4.1
19.2.0
18.3.0
17.4.0
20.0.0
20.0.0.0rc2
20.0.0.0rc1
18.2.0
17.3.0
19.1.0
ussuri-em
16.4.2
19.0.0
19.0.0.0rc2
19.0.0.0rc1
18.1.1
17.2.1
16.4.1
18.1.0
17.2.0
16.4.0
ocata-eol
train-em
17.1.2
16.3.2
15.3.4
18.0.0
18.0.0.0rc2
18.0.0.0rc1
17.1.1
16.3.1
15.3.3
15.3.2
17.1.0
16.3.0
15.3.1
stein-em
14.4.2
14.4.1
17.0.0
17.0.0.0rc2
16.2.0
15.3.0
14.4.0
17.0.0.0rc1
14.3.1
16.1.0
15.2.0
14.3.0
14.2.0
15.1.0
16.0.0
16.0.0.0rc2
16.0.0.0rc1
rocky-em
13.0.7
16.0.0.0b1
14.1.0
15.0.2
15.0.1
14.0.4
13.0.6
queens-em
12.1.1
13.0.5
14.0.3
15.0.0
15.0.0.0rc2
15.0.0.0rc1
15.0.0.0b1
12.1.0
14.0.2
13.0.4
pike-em
11.0.8
14.0.1
ocata-em
12.0.6
13.0.3
11.0.7
14.0.0
14.0.0.0rc1
14.0.0.0b3
14.0.0.0b2
14.0.0.0b1
12.0.5
11.0.6
13.0.2
12.0.4
13.0.1
13.0.0
13.0.0.0rc2
13.0.0.0rc1
13.0.0.0b3
10.0.7
11.0.5
12.0.3
13.0.0.0b2
10.0.6
12.0.2
11.0.4
13.0.0.0b1
12.0.1
11.0.3
10.0.5
12.0.0
12.0.0.0rc2
12.0.0.0rc1
12.0.0.0b3
12.0.0.0b2
11.0.2
12.0.0.0b1
newton-eol
11.0.1
10.0.4
11.0.0
10.0.3
9.4.1
11.0.0.0rc3
11.0.0.0rc2
11.0.0.0rc1
11.0.0.0b3
mitaka-eol
11.0.0.0b2
10.0.2
9.4.0
11.0.0.0b1
9.3.1
10.0.1
9.3.0
10.0.0
10.0.0.0rc2
liberty-eol
10.0.0.0rc1
8.4.0
9.2.0
10.0.0.0b3
10.0.0.0b2
9.1.1
10.0.0.0b1
9.1.0
8.3.0
7.2.0
9.0.0
9.0.0.0rc3
9.0.0.0rc2
9.0.0.0rc1
9.0.0.0b3
8.2.0
7.1.2
9.0.0.0b2
8.1.2
7.1.1
9.0.0.0b1
7.1.0
8.1.1
kilo-eol
2015.1.4
8.1.0
8.0.0
8.0.0.0rc3
7.0.4
8.0.0.0rc2
8.0.0.0rc1
8.0.0.0b3
7.0.3
7.0.2
2015.1.3
8.0.0.0b2
juno-eol
7.0.1
8.0.0.0b1
2014.2.4
7.0.0
7.0.0.0rc3
2015.1.2
7.0.0.0rc2
7.0.0.0rc1
7.0.0.0b3
2015.1.1
7.0.0.0b2
icehouse-eol
7.0.0.0b1
2014.1.5
7.0.0a0
2015.1.0
2015.1.0rc3
2015.1.0rc2
2014.2.3
2015.1.0rc1
2015.1.0b3
2014.1.4
2014.2.2
2015.1.0b2
2015.1.0b1
2014.2.1
2014.2
2014.2.rc3
2014.2.rc2
2014.2.rc1
2014.1.3
havana-eol
2013.2.4
2014.2.b3
2014.1.2
2014.2.b2
2014.2.b1
2014.1.1
2014.1
2014.1.rc2
2013.2.3
2014.1.rc1
grizzly-eol
2013.1.5
2014.1.b3
2013.2.2
2014.1.b2
2013.2.1
2014.1.b1
folsom-eol
2013.1.4
2013.2
2013.2.rc3
2013.2.rc2
2013.2.rc1
2013.2.b3
2013.1.3
2013.2.b2
2013.1.2
2013.2.b1
2013.1.1
essex-eol
diablo-eol
2012.2.4
2013.1
2013.1.rc3
2013.1.rc2
2013.1.rc1
2013.1.g3
2012.2.3
grizzly-2
2012.2.1
grizzly-1
2012.2
folsom-rc3
folsom-rc2
folsom-rc1
folsom-3
folsom-2
folsom-1
2012.1
essex-rc2
essex-rc1
2011.3
essex-1
essex-2
essex-3
essex-4
${ noResults }
5 Commits (cb60d0bb4e0cc0cba68f59fdf5f4e89d6ec52950)
Author | SHA1 | Message | Date |
---|---|---|---|
![]() |
1bed055efc |
Adopt rpc_api devref to new oslo_messaging namespace
Change-Id: Ib6f58cffae882652da52962c9e61298193b50d62 |
8 years ago |
![]() |
b35c004204 |
DHCP agent restructuring
Wrap dhcp agent into its own module and break out configurations and entry point for better seperation. This lead to some test cleanup that revealed that options were registered unnecessarily. When/if the dhcp agent goes through a restructuring along the same lines of the L3 agent's, this would be the step to start from. Related-blueprint: restructure-l3-agent Related-blueprint: core-vendor-decomposition Change-Id: I87d9f1079ed4e71c731984ec00e2f785024fd5f8 |
9 years ago |
![]() |
9a276e05a2 |
Update rpc_api docs with example version update
Update the rpc api devref docs to include an example of what a change that includes a minor version increment looks like. I hope this will help clarify for people what all is included in an API change that requires a version bump. Part of blueprint rpc-docs-and-namespaces. Change-Id: I9c53d3518b200412701b19958d7cbf1ed03d643e |
9 years ago |
![]() |
c52840e516 |
Add some basic rpc api docs
The devref docs had a placeholder file for rpc API docs. Now that both a client side and server side interface have been converted from the rpc compat layer to oslo.messaging APIs, add some docs that give an overview of what the client and server sides look like. Also include a section that describes the code layout of where you can find client and server api implementations in the neutron code base. It starts by discussing the DHCP agent related APIs. Part of blueprint drop-rpc-compat. Change-Id: Ib391958252077365a81bcb881ab27a078f71fdec |
9 years ago |
![]() |
72398f1f69 |
Developer documentation
* Turns TESTING into a rst file, that we include in the developer documentation, for instructions on how to run the unit tests. * Link to a Vagrant project that sets up Neutron inside a VM. * Adds a section for how to debug with Nose * Add new section for Neutron Internals * Neutron L2 Agent documentation - currently only OVS * Make the Security Group API extension an example of how an API extension is implemented Implements bp developer-documentation Change-Id: I9b452abc9da3b1a41ae65cff727967de0eab12fe |
9 years ago |