diff --git a/.gitignore b/.gitignore index 5f775506631..606a4d01b3e 100644 --- a/.gitignore +++ b/.gitignore @@ -12,9 +12,6 @@ neutron.egg-info/ neutron/vcsversion.py neutron/versioninfo pbr*.egg/ -quantum.egg-info/ -quantum/vcsversion.py -quantum/versioninfo setuptools*.egg/ *.log *.mo diff --git a/TESTING.rst b/TESTING.rst index c05018e558d..ca71c0f5762 100644 --- a/TESTING.rst +++ b/TESTING.rst @@ -242,10 +242,7 @@ dependencies as the functional tests, using the configuration script tools/configure_for_func_testing.sh is advised (as described above). When running full-stack tests on a clean VM for the first time, we advise to run ./stack.sh successfully to make sure all Neutron's -dependencies are met. Also note that in order to preserve resources -on the gate, running the dsvm-functional suite will also run all -full-stack tests (and a new worker won't be assigned specifically for -dsvm-fullstack). Full-stack based Neutron daemons produce logs to a +dependencies are met. Full-stack based Neutron daemons produce logs to a sub-folder in /tmp/fullstack-logs (for example, a test named "test_example" will produce logs to /tmp/fullstack-logs/test_example/), so that will be a good place to look if your test is failing. diff --git a/doc/source/devref/callbacks.rst b/doc/source/devref/callbacks.rst index 4c9f5488447..baaa98a83b7 100644 --- a/doc/source/devref/callbacks.rst +++ b/doc/source/devref/callbacks.rst @@ -223,7 +223,7 @@ There are a few options to unsubscribe registered callbacks: resource R, any notification of events related to resource R will no longer be handed over to C, after the unsubscribe_by_resource() invocation. * unsubscribe_all(): say that callback C has subscribed to events A, B for resource R1, - and events C, D for resource R2, any notification of events pertaining resouces R1 and + and events C, D for resource R2, any notification of events pertaining resources R1 and R2 will no longer be handed over to C, after the unsubscribe_all() invocation. The snippet below shows these concepts in action: diff --git a/doc/source/devref/contribute.rst b/doc/source/devref/contribute.rst index 932474e7500..b24366685f6 100644 --- a/doc/source/devref/contribute.rst +++ b/doc/source/devref/contribute.rst @@ -129,7 +129,7 @@ The testing process will be as follow: the vendor to choose what CI system they see fit to run them. There is no need or requirement to use OpenStack CI resources if they do not want to. Having said that, it may be useful to provide coverage for the shim layer in - the form of basic validation as done in `ODL `_ and `LBaaS A10 driver `_. + the form of basic validation as done in `ODL `_ and `LBaaS A10 driver `_. * 3rd Party CI will continue to validate vendor integration with Neutron via functional testing. 3rd Party CI is a communication mechanism. This objective @@ -227,7 +227,7 @@ library, and it leads to the greatest level of flexibility when dealing with Dev dev/test deployments. Having said that, most Neutron plugins developed in the past likely already have -integration with DevStack in the form of `neutron_plugins `_. +integration with DevStack in the form of `neutron_plugins `_. If the plugin is being decomposed in vendor integration plus vendor library, it would be necessary to adjust the instructions provided in the neutron_plugin file to pull the vendor library code as a new dependency. For instance, the instructions below: @@ -247,7 +247,7 @@ vendor library code as a new dependency. For instance, the instructions below: could be placed in 'neutron_plugin_configure_service', ahead of the service configuration. An alternative could be under the `third_party section -`_, +`_, if available. This solution can be similarly exploited for both monolithic plugins or ML2 mechanism drivers. The configuration of the plugin or driver itself can be done by leveraging the extensibility mechanisms provided by `local.conf `_. In fact, since the .ini file for the vendor plugin or driver lives @@ -270,9 +270,9 @@ is strongly encouraged to revise the existing DevStack integration, in order to in an extras.d hooks based approach. One final consideration is worth making for 3rd party CI setups: if `Devstack Gate -`_ is used, it does provide hook +`_ is used, it does provide hook functions that can be executed at specific times of the devstack-gate-wrap script run. -For example, the `Neutron Functional job `_ uses them. For more details see `devstack-vm-gate-wrap.sh `_. +For example, the `Neutron Functional job `_ uses them. For more details see `devstack-vm-gate-wrap.sh `_. Documentation Strategies ------------------------ @@ -291,12 +291,12 @@ The list of steps below are somewhat the tl;dr; version of what you can find on http://docs.openstack.org/infra/manual/creators.html. They are meant to be the bare minimum you have to complete in order to get you off the ground. -* Create a public repository: this can be a personal github.com repo or any - publicly available git repo, e.g. https://github.com/john-doe/foo.git. This +* Create a public repository: this can be a personal git.openstack.org repo or any + publicly available git repo, e.g. ``https://github.com/john-doe/foo.git``. This would be a temporary buffer to be used to feed the StackForge one. * Initialize the repository: if you are starting afresh, you may *optionally* want to use cookiecutter to get a skeleton project. You can learn how to use - cookiecutter on https://github.com/openstack-dev/cookiecutter. + cookiecutter on https://git.openstack.org/cgit/openstack-dev/cookiecutter. If you want to build the repository from an existing Neutron module, you may want to skip this step now, build the history first (next step), and come back here to initialize the remainder of the repository with other files being @@ -312,7 +312,7 @@ be the bare minimum you have to complete in order to get you off the ground. :: - git clone https://github.com/openstack/neutron.git + git clone https://git.openstack.org/openstack/neutron.git cd neutron ./tools/split.sh # Sit and wait for a while, or grab a cup of your favorite drink @@ -357,7 +357,7 @@ be the bare minimum you have to complete in order to get you off the ground. jobs that validate your patches when posted to Gerrit. For instance, one thing you would need to do is to define an entry point for your plugin or driver in your own setup.cfg similarly as to how it is done - `here `_. + `here `_. * Define an entry point for your plugin or driver in setup.cfg * Create 3rd Party CI account: if you do not already have one, follow instructions for @@ -391,7 +391,7 @@ will be removed. The following aspects are captured: effort is not considered justified. Assessment may change in the future. - Absense of an entry for an existing plugin or driver means no active effort + Absence of an entry for an existing plugin or driver means no active effort has been observed or potentially not required. * Completed in: the release in which the effort is considered completed. Code completion can be deemed as such, if there is no overlap/duplication between diff --git a/doc/source/devref/openvswitch_agent.rst b/doc/source/devref/openvswitch_agent.rst index c6f165064a7..a4b2685320a 100644 --- a/doc/source/devref/openvswitch_agent.rst +++ b/doc/source/devref/openvswitch_agent.rst @@ -6,7 +6,10 @@ This Agent uses the `OpenVSwitch`_ virtual switch to create L2 connectivity for instances, along with bridges created in conjunction with OpenStack Nova for filtering. -ovs-neutron-agent can be configured to use two different networking technologies to create tenant isolation, either GRE tunnels or VLAN tags. +ovs-neutron-agent can be configured to use different networking technologies +to create tenant isolation. +These technologies are implemented as ML2 type drivers which are used in +conjunction with the OpenVSwitch mechanism driver. VLAN Tags --------- @@ -23,6 +26,51 @@ GRE Tunneling is documented in depth in the `Networking in too much detail `_ by RedHat. + +VXLAN Tunnels +------------- + +VXLAN is an overlay technology which encapsulates MAC frames +at layer 2 into a UDP header. +More information can be found in `The VXLAN wiki page. +`_ + + +Bridge Management +----------------- + +In order to make the agent capable of handling more than one tunneling +technology, to decouple the requirements of segmentation technology +from tenant isolation, and to preserve backward compatibility for OVS +agents working without tunneling, the agent relies on a tunneling bridge, +or br-tun, and the well known integration bridge, or br-int. + +All VM VIFs are plugged into the integration bridge. VM VIFs on a given +virtual network share a common "local" VLAN (i.e. not propagated +externally). The VLAN id of this local VLAN is mapped to the physical +networking details realizing that virtual network. + +For virtual networks realized as VXLAN/GRE tunnels, a Logical Switch +(LS) identifier is used to differentiate tenant traffic on inter-HV +tunnels. A mesh of tunnels is created to other Hypervisors in the +cloud. These tunnels originate and terminate on the tunneling bridge +of each hypervisor, leaving br-int unaffected. Port patching is done +to connect local VLANs on the integration bridge to inter-hypervisor +tunnels on the tunnel bridge. + +For each virtual network realized as a VLAN or flat network, a veth +or a pair of patch ports is used to connect the local VLAN on +the integration bridge with the physical network bridge, with flow +rules adding, modifying, or stripping VLAN tags as necessary, thus +preserving backward compatibility with the way the OVS agent used +to work prior to the tunneling capability (for more details, please +look at https://review.openstack.org/#/c/4367). + +Bear in mind, that this design decision may be overhauled in the +future to support existing VLAN-tagged traffic (coming from NFV VMs +for instance) and/or to deal with potential QinQ support natively +available in the Open vSwitch. + Further Reading --------------- diff --git a/doc/source/devref/security_group_api.rst b/doc/source/devref/security_group_api.rst index c1e87d3d0e2..750c744f362 100644 --- a/doc/source/devref/security_group_api.rst +++ b/doc/source/devref/security_group_api.rst @@ -10,7 +10,7 @@ API Extension The API extension is the 'front' end portion of the code, which handles defining a `REST-ful API`_, which is used by tenants. -.. _`REST-ful API`: https://github.com/openstack/neutron/blob/master/neutron/extensions/securitygroup.py +.. _`REST-ful API`: https://git.openstack.org/cgit/openstack/neutron/tree/neutron/extensions/securitygroup.py Database API @@ -18,7 +18,7 @@ Database API The Security Group API extension adds a number of `methods to the database layer`_ of Neutron -.. _`methods to the database layer`: https://github.com/openstack/neutron/blob/master/neutron/db/securitygroups_db.py +.. _`methods to the database layer`: https://git.openstack.org/cgit/openstack/neutron/tree/neutron/db/securitygroups_db.py Agent RPC --------- @@ -27,12 +27,12 @@ This portion of the code handles processing requests from tenants, after they ha running on the compute nodes, and modifying the IPTables rules on each hypervisor. -* `Plugin RPC classes `_ +* `Plugin RPC classes `_ - * `SecurityGroupServerRpcMixin `_ - defines the RPC API that the plugin uses to communicate with the agents running on the compute nodes + * `SecurityGroupServerRpcMixin `_ - defines the RPC API that the plugin uses to communicate with the agents running on the compute nodes * SecurityGroupServerRpcMixin - Defines the API methods used to fetch data from the database, in order to return responses to agents via the RPC API -* `Agent RPC classes `_ +* `Agent RPC classes `_ * The SecurityGroupServerRpcApi defines the API methods that can be called by agents, back to the plugin that runs on the Neutron controller * The SecurityGroupAgentRpcCallbackMixin defines methods that a plugin uses to call back to an agent after performing an action called by an agent. @@ -43,8 +43,8 @@ IPTables Driver * ``prepare_port_filter`` takes a ``port`` argument, which is a ``dictionary`` object that contains information about the port - including the ``security_group_rules`` -* ``prepare_port_filter`` `appends the port to an internal dictionary `_, ``filtered_ports`` which is used to track the internal state. +* ``prepare_port_filter`` `appends the port to an internal dictionary `_, ``filtered_ports`` which is used to track the internal state. * Each security group has a `chain `_ in Iptables. -* The ``IptablesFirewallDriver`` has a method to `convert security group rules into iptables statements `_ +* The ``IptablesFirewallDriver`` has a method to `convert security group rules into iptables statements `_ diff --git a/doc/source/devref/sub_projects.rst b/doc/source/devref/sub_projects.rst index 3a32d7a2614..cc422029269 100644 --- a/doc/source/devref/sub_projects.rst +++ b/doc/source/devref/sub_projects.rst @@ -56,24 +56,14 @@ The official source of all repositories that exist under the Neutron project is: http://governance.openstack.org/reference/projects/neutron.html -The sub-projects are also listed here for convenience and as a place to provide -some additional metadata about them: - -+-------------------------------+-----------------------+ -| Name | Functionality | -+===============================+=======================+ -| | | -+-------------------------------+-----------------------+ - Affiliated projects =================== -Affiliated projects are related to Neutron in some way, but are not official -sub-projects of Neutron. - -This table shows the unofficial affiliated projects that integrate with Neutron, -in one form or another. These projects typically leverage the pluggable +This table shows the affiliated projects that integrate with Neutron, +in one form or another. These projects typically leverage the pluggable capabilities of Neutron, the Neutron API, or a combination of both. +This list may contain projects that are already listed in the governance +repo but are summarized here to describe the functionality they provide. +-------------------------------+-----------------------+ | Name | Functionality | @@ -126,6 +116,8 @@ capabilities of Neutron, the Neutron API, or a combination of both. +-------------------------------+-----------------------+ | neutron-powervm_ | ml2 | +-------------------------------+-----------------------+ +| networking-sfc_ | service composition | ++-------------------------------+-----------------------+ | networking-vsphere_ | ml2 | +-------------------------------+-----------------------+ | vmware-nsx_ | core | @@ -150,7 +142,7 @@ Functionality legend Arista ------ -* Git: https://github.com/stackforge/networking-arista +* Git: https://git.openstack.org/cgit/stackforge/networking-arista * Launchpad: https://launchpad.net/networking-arista * Pypi: https://pypi.python.org/pypi/networking-arista @@ -159,7 +151,7 @@ Arista BaGPipe ------- -* Git: https://github.com/stackforge/networking-bagpipe-l2 +* Git: https://git.openstack.org/cgit/stackforge/networking-bagpipe-l2 * Launchpad: https://launchpad.net/bagpipe-l2 * Pypi: https://pypi.python.org/pypi/bagpipe-l2 @@ -168,14 +160,14 @@ BaGPipe BGPVPN ------- -* Git: https://github.com/stackforge/networking-bgpvpn +* Git: https://git.openstack.org/cgit/openstack/networking-bgpvpn .. _networking-bigswitch: Big Switch Networks ------------------- -* Git: https://git.openstack.org/stackforge/networking-bigswitch +* Git: https://git.openstack.org/cgit/stackforge/networking-bigswitch * Pypi: https://pypi.python.org/pypi/bsnstacklib .. _networking-brocade: @@ -183,7 +175,7 @@ Big Switch Networks Brocade ------- -* Git: https://github.com/stackforge/networking-brocade +* Git: https://git.openstack.org/cgit/stackforge/networking-brocade * Launchpad: https://launchpad.net/networking-brocade * PyPI: https://pypi.python.org/pypi/networking-brocade @@ -192,7 +184,7 @@ Brocade Cisco ----- -* Git: https://github.com/stackforge/networking-cisco +* Git: https://git.openstack.org/cgit/stackforge/networking-cisco * Launchpad: https://launchpad.net/networking-cisco * PyPI: https://pypi.python.org/pypi/networking-cisco @@ -201,7 +193,7 @@ Cisco DragonFlow ---------- -* Git: https://github.com/stackforge/dragonflow +* Git: https://git.openstack.org/cgit/openstack/dragonflow * Launchpad: https://launchpad.net/dragonflow * PyPi: https://pypi.python.org/pypi/DragonFlow @@ -210,7 +202,7 @@ DragonFlow Edge VPN -------- -* Git: https://git.openstack.org/stackforge/networking-edge-vpn +* Git: https://git.openstack.org/cgit/stackforge/networking-edge-vpn * Launchpad: https://launchpad.net/edge-vpn .. _networking-hyperv: @@ -218,7 +210,7 @@ Edge VPN Hyper-V ------- -* Git: https://github.com/stackforge/networking-hyperv +* Git: https://git.openstack.org/cgit/stackforge/networking-hyperv * Launchpad: https://launchpad.net/networking-hyperv * PyPi: https://pypi.python.org/pypi/networking-hyperv @@ -227,7 +219,7 @@ Hyper-V Group Based Policy ------------------ -* Git: https://github.com/stackforge/group-based-policy +* Git: https://git.openstack.org/cgit/stackforge/group-based-policy * Launchpad: https://launchpad.net/group-based-policy * PyPi: https://pypi.python.org/pypi/group-based-policy @@ -236,7 +228,7 @@ Group Based Policy IBM SDNVE --------- -* Git: https://github.com/stackforge/networking-ibm +* Git: https://git.openstack.org/cgit/stackforge/networking-ibm * Launchpad: https://launchpad.net/networking-ibm .. _networking-l2gw: @@ -244,7 +236,7 @@ IBM SDNVE L2 Gateway ---------- -* Git: https://github.com/stackforge/networking-l2gw +* Git: https://git.openstack.org/cgit/openstack/networking-l2gw * Launchpad: https://launchpad.net/networking-l2gw .. _networking-metaplugin: @@ -259,7 +251,7 @@ Metaplugin MidoNet ------- -* Git: https://github.com/stackforge/networking-midonet +* Git: https://git.openstack.org/cgit/openstack/networking-midonet * Launchpad: https://launchpad.net/networking-midonet * PyPI: https://pypi.python.org/pypi/networking-midonet @@ -268,7 +260,7 @@ MidoNet Mellanox -------- -* Git: https://github.com/stackforge/networking-mlnx +* Git: https://git.openstack.org/cgit/stackforge/networking-mlnx * Launchpad: https://launchpad.net/networking-mlnx .. _networking-nec: @@ -276,7 +268,7 @@ Mellanox NEC --- -* Git: https://github.com/stackforge/networking-nec +* Git: https://git.openstack.org/cgit/stackforge/networking-nec * Launchpad: https://launchpad.net/networking-nec * PyPI: https://pypi.python.org/pypi/networking-nec @@ -292,7 +284,7 @@ Nuage OpenDayLight ------------ -* Git: https://github.com/stackforge/networking-odl +* Git: https://git.openstack.org/cgit/openstack/networking-odl * Launchpad: https://launchpad.net/networking-odl .. _networking-ofagent: @@ -300,7 +292,7 @@ OpenDayLight OpenFlow Agent (ofagent) ------------------------ -* Git: https://github.com/stackforge/networking-ofagent +* Git: https://git.openstack.org/cgit/openstack/networking-ofagent * Launchpad: https://launchpad.net/networking-ofagent * PyPI: https://pypi.python.org/pypi/networking-ofagent @@ -309,7 +301,7 @@ OpenFlow Agent (ofagent) Open Virtual Network -------------------- -* Git: https://github.com/stackforge/networking-ovn +* Git: https://git.openstack.org/cgit/openstack/networking-ovn * Launchpad: https://launchpad.net/networking-ovn * PyPI: https://pypi.python.org/pypi/networking-ovn @@ -318,7 +310,7 @@ Open Virtual Network Open DPDK --------- -* Git: https://github.com/stackforge/networking-ovs-dpdk +* Git: https://git.openstack.org/cgit/stackforge/networking-ovs-dpdk * Launchpad: https://launchpad.net/networking-ovs-dpdk .. _networking-plumgrid: @@ -326,7 +318,7 @@ Open DPDK PLUMgrid -------- -* Git: https://github.com/stackforge/networking-plumgrid +* Git: https://git.openstack.org/cgit/stackforge/networking-plumgrid * Launchpad: https://launchpad.net/networking-plumgrid * PyPI: https://pypi.python.org/pypi/networking-plumgrid @@ -335,7 +327,7 @@ PLUMgrid PowerVM ------- -* Git: https://github.com/stackforge/neutron-powervm +* Git: https://git.openstack.org/cgit/stackforge/neutron-powervm * Launchpad: https://launchpad.net/neutron-powervm * PyPI: https://pypi.python.org/pypi/neutron-powervm @@ -344,15 +336,22 @@ PowerVM PortForwarding -------------- -* Git: https://github.com/stackforge/networking-portforwarding +* Git: https://git.openstack.org/cgit/stackforge/networking-portforwarding * Launchpad: https://launchpad.net/networking-portforwarding +.. _networking-sfc: + +SFC +--- + +* Git: https://git.openstack.org/cgit/openstack/networking-sfc + .. _networking-vsphere: vSphere ------- -* Git: https://github.com/stackforge/networking-vsphere +* Git: https://git.openstack.org/cgit/stackforge/networking-vsphere * Launchpad: https://launchpad.net/networking-vsphere .. _vmware-nsx: @@ -360,7 +359,7 @@ vSphere VMware NSX ---------- -* Git: https://github.com/stackforge/vmware-nsx +* Git: https://git.openstack.org/cgit/openstack/vmware-nsx * Launchpad: https://launchpad.net/vmware-nsx * PyPI: https://pypi.python.org/pypi/vmware-nsx @@ -369,5 +368,5 @@ VMware NSX Octavia ------- -* Git: https://github.com/stackforge/octavia +* Git: https://git.openstack.org/cgit/openstack/octavia * Launchpad: https://launchpad.net/octavia diff --git a/doc/source/docbkx/docbkx-example/README b/doc/source/docbkx/docbkx-example/README deleted file mode 100644 index e1545671b31..00000000000 --- a/doc/source/docbkx/docbkx-example/README +++ /dev/null @@ -1,14 +0,0 @@ -README - -This docbkx-example folder is provided for those who want to use the maven mojo supplied with the project to build their own documents to PDF and HTML (webhelp) format. It's intended to be a template and model. - -You can edit the src/docbkx/example.xml file using vi, emacs, or another DocBook editor. At Rackspace we use Oxygen. Both Oxygen and XML Mind offer free licenses to those working on open source project documentation. - -To build the output, install Apache Maven (https://maven.apache.org/) and then run: - -mvn clean generate-sources - -in the directory containing the pom.xml file. - -Feel free to ask questions of the openstack-docs team at https://launchpad.net/~openstack-doc. - diff --git a/doc/source/docbkx/docbkx-example/pom.xml b/doc/source/docbkx/docbkx-example/pom.xml deleted file mode 100644 index f281971a5d5..00000000000 --- a/doc/source/docbkx/docbkx-example/pom.xml +++ /dev/null @@ -1,38 +0,0 @@ - - 4.0.0 - my-groupid - my-guide - 1.0.0-SNAPSHOT - jar - OpenStack stand alone documentation examples - - - - - com.agilejava.docbkx - docbkx-maven-plugin - - - - generate-pdf - generate-webhelp - - generate-sources - - - - true - 100 - - - - - - - - - - - - - diff --git a/doc/source/docbkx/docbkx-example/src/docbkx/example.xml b/doc/source/docbkx/docbkx-example/src/docbkx/example.xml deleted file mode 100644 index 96f1c64c10c..00000000000 --- a/doc/source/docbkx/docbkx-example/src/docbkx/example.xml +++ /dev/null @@ -1,318 +0,0 @@ - - Maven Example Documentation - - - - - - - - Badges! We don't need any stinking badges! - - - - 2011 - Timothy D. Witham - - Example v0.1 - Product Name Doesn't Exist - it's an example!™ - 2011-01-01 - - - Copyright details are filled in by the template. Change the value of the role - attribute on the legalnotice element to change the license. - - - - This document is intended for individuals who whish to produce documentation using Maven and having - the same "feel" as the documentation that is produced by the mainline OpenStack projects. - - - - this is a placeholder for the front cover - - - this is a placeholder for the back cover - - - - Overview - Welcome to the getting started with Maven documentation. Congratulations you have - successfully downloaded and built the example. - - For more details on the Product Name service, please refer to http://www.rackspacecloud.com/cloud_hosting_products/product name - - We welcome feedback, comments, and bug reports at support@rackspacecloud.com. -
- Intended Audience - This guide is intended to individuals who want to develop standalone documentation - to use within an OpenStack deployment. Using this tool chain will give you the look and - feel of the mainline OpenStack documentation. - -
-
- Document Change History - This version of the Maven Getting Started Guide replaces and obsoletes all previous versions. The - most recent changes are described in the table below: - - - - Revision Date - Summary of Changes - - - - - July. 14, 2011 - - - - Initial document creation. - - - - - - -
-
- Additional Resources - - - - - Openstack - Cloud Software - - - - - - - Docbook Main Web Site - - - - - - - Docbook Quick Reference - - - - -
- - - Concepts - - Need to put something here. - - - - How do I? - -
- Notes and including images - So I want an note and an image in this section ... - - This is an example of a note. - - - Here's a sample figure in svg and png formats: -
- Sample Image - - - - - - - - -
-
-
- Multiple Related Documents - - What you need to do in order to have multiple documents fit within the - build structure. - -
-
- Using multiple files for a document - - What you need to do in order to have a single document that is made up of multiple - files. - -
-
- Who, What, Where, When and Why of pom.xml - - You will of noticed the pom.xml file at the root directory. - This file is used to set the project parameters for the documentation. Including - what type of documentation to produce and any post processing that needs to happen. - If you want to know more about - - pom.xml - need a link - - then follow the link. - - For the pom.xmlfile that was included in this distribution we will - parse the individual lines and explaine the meaning. - - - - -
- <project> - - What is all of this stuff and why is it important? - -
-
- <modelVersion> - - What goes in here and why? - -
-
- <groupId> - - What goes in here and why? - -
-
- <artifactId> - - What goes in here and why? - -
-
- <version> - - What goes in here and why? - -
-
- <packaging> - - What goes in here and why? - -
-
- <name> - - Name of your document. - -
-
- <build> - - Make some documents. - -
- <plugin(s)> - - What does this do and why? - -
- <groupId> - - What goes in here and why? - -
-
- <artifactId> - - What goes in here and why? - -
-
- <execution(s)> - - What goes in here and why? - -
- <goal(s)> - - Different types of goals and why you use them. - -
-
- <phase> - - What does this section do? What phases can you specify. - -
-
-
- <configuration> - - What does this section do? - -
- <xincludeSupported> - - What does this do and why? - -
-
- <chunkSectionDepth> - - What does this do and why? - -
-
- <postprocess> - - What does this section do? What are possible pieces? - -
- <copy> - - What does this section do? What are possible pieces? - -
- <fileset> - - What does this section do? What are possible pieces? - -
- <include> - - What does this section do? What are possible pieces? - -
-
-
-
-
-
-
-
-
- Who, What, Where, When and Why of build.xml - - You will of noticed the build.xml file at the root directory. - This file is used to set the project parameters for the documentation. Including - what type of documentation to produce and any post processing that needs to happen. - If you want to know more about - - pom.xml - need a link - - then follow the link. - -
- - - Troubleshooting - Sometimes things go wrong... - - diff --git a/doc/source/docbkx/docbkx-example/src/docbkx/figures/example.sdx b/doc/source/docbkx/docbkx-example/src/docbkx/figures/example.sdx deleted file mode 100644 index 3f2d863669f..00000000000 --- a/doc/source/docbkx/docbkx-example/src/docbkx/figures/example.sdx +++ /dev/null @@ -1,79 +0,0 @@ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - diff --git a/doc/source/docbkx/docbkx-example/src/docbkx/figures/example.svg b/doc/source/docbkx/docbkx-example/src/docbkx/figures/example.svg deleted file mode 100644 index 58b98232d40..00000000000 --- a/doc/source/docbkx/docbkx-example/src/docbkx/figures/example.svg +++ /dev/null @@ -1,523 +0,0 @@ - - - - -Creator: Quick Sequence Diagram Editor Producer: org.freehep.graphicsio.svg.SVGGraphics2D Revision: 12753 Source: Date: Monday, May 2, 2011 2:44:33 PM CDT - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - diff --git a/doc/source/docbkx/quantum-api-1.0/common.ent b/doc/source/docbkx/quantum-api-1.0/common.ent deleted file mode 100644 index 67e512af571..00000000000 --- a/doc/source/docbkx/quantum-api-1.0/common.ent +++ /dev/null @@ -1,112 +0,0 @@ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - '> - - - - - - '> - - - - - - '> - - - - - - '> - - - - - - '> - - - - - - - - -