Since it's pretty common to see blogposts recommending to mount /opt/stack
remotely or editing inline the code, adding some notes about the potential
risk of a reclone that could impact weeks of work.
Change-Id: I733d40b76fb02d8edf3719533fc8202547771871
Co-Authored-By: Stephen Finucane <sfinucan@redhat.com>
| ... | ... |
@@ -18,6 +18,57 @@ production systems. |
| 18 | 18 |
Your best choice is probably to choose a `distribution of OpenStack |
| 19 | 19 |
<https://www.openstack.org/marketplace/distros/>`__. |
| 20 | 20 |
|
| 21 |
+Can I use DevStack as a development environment? |
|
| 22 |
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
|
| 23 |
+ |
|
| 24 |
+Sure, you can. That said, there are a couple of things you should note before |
|
| 25 |
+doing so: |
|
| 26 |
+ |
|
| 27 |
+- DevStack makes a lot of configuration changes to your system and should not |
|
| 28 |
+ be run in your main development environment. |
|
| 29 |
+ |
|
| 30 |
+- All the repositories that DevStack clones when deploying are considered |
|
| 31 |
+ volatile by default and thus are subject to hard resets. This is necessary to |
|
| 32 |
+ keep you in sync with the latest upstream, which is what you want in a CI |
|
| 33 |
+ situation, but it can result in branches being overwritten and files being |
|
| 34 |
+ removed. |
|
| 35 |
+ |
|
| 36 |
+ The corollary of this is that if you are working on a specific project, using |
|
| 37 |
+ the DevStack project repository (defaulted to ``/opt/stack/<project>``) as |
|
| 38 |
+ the single master repository for storing all your work is not recommended. |
|
| 39 |
+ This behavior can be overridden by setting the ``RECLONE`` config option to |
|
| 40 |
+ ``no``. Alternatively, you can avoid running ``stack.sh`` to redeploy by |
|
| 41 |
+ restarting services manually. In any case, you should generally ensure work |
|
| 42 |
+ in progress is pushed to Gerrit or otherwise backed up before running |
|
| 43 |
+ ``stack.sh``. |
|
| 44 |
+ |
|
| 45 |
+- If you use DevStack within a VM, you may wish to mount a local OpenStack |
|
| 46 |
+ directory, such as ``~/src/openstack``, inside the VM and configure DevStack |
|
| 47 |
+ to use this as the clone location using the ``{PROJECT}_REPO`` config
|
|
| 48 |
+ variables. For example, assuming you're using Vagrant and sharing your home |
|
| 49 |
+ directory, you should place the following in ``local.conf``: |
|
| 50 |
+ |
|
| 51 |
+ .. code-block:: shell |
|
| 52 |
+ |
|
| 53 |
+ NEUTRON_REPO=/home/vagrant/src/neutron |
|
| 54 |
+ NOVA_REPO=/home/vagrant/src/nova |
|
| 55 |
+ KEYSTONE_REPO=/home/vagrant/src/keystone |
|
| 56 |
+ GLANCE_REPO=/home/vagrant/src/glance |
|
| 57 |
+ SWIFT_REPO=/home/vagrant/src/swift |
|
| 58 |
+ HORIZON_REPO=/home/vagrant/src/horizon |
|
| 59 |
+ CINDER_REPO=/home/vagrant/src/cinder |
|
| 60 |
+ HEAT_REPO=/home/vagrant/src/heat |
|
| 61 |
+ TEMPEST_REPO=/home/vagrant/src/tempest |
|
| 62 |
+ HEATCLIENT_REPO=/home/vagrant/src/python-heatclient |
|
| 63 |
+ GLANCECLIENT_REPO=/home/vagrant/src/python-glanceclient |
|
| 64 |
+ NOVACLIENT_REPO=/home/vagrant/src/python-novaclient |
|
| 65 |
+ NEUTRONCLIENT_REPO=/home/vagrant/src/python-neutronclient |
|
| 66 |
+ OPENSTACKCLIENT_REPO=/home/vagrant/src/python-openstackclient |
|
| 67 |
+ HEAT_CFNTOOLS_REPO=/home/vagrant/src/heat-cfntools |
|
| 68 |
+ HEAT_TEMPLATES_REPO=/home/vagrant/src/heat-templates |
|
| 69 |
+ NEUTRON_FWAAS_REPO=/home/vagrant/src/neutron-fwaas |
|
| 70 |
+ # ... |
|
| 71 |
+ |
|
| 21 | 72 |
Why a shell script, why not chef/puppet/... |
| 22 | 73 |
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
| 23 | 74 |
|