Wrong container name in devstack "All-In-One Single LXC Container" manual.
Link: http://docs.openstack.org/developer/devstack/guides/lxc.html
After creating "devstack" container with below command
sudo lxc-create -n devstack -t ubuntu -f devstack-lxc.conf -- --packages=bsdmainutils,git
The name should be 'devstack' instead of 'p2' in the below command
ssh ubuntu@$(sudo lxc-info -n p2 | awk '/IP/ { print $2 }')).
Change-Id: I7a84b97b03b2dd4338f1d946b7eafb8ec6e3767d
Closes-bug: #1582248
This patch replaces Q_L3_ENABLED with is_service_enabled q-l3.
Both of them idicates wherever Neutron L3 agent is enabled or not.
Change-Id: I33f0f5a6174d1d170bc2ac1c2e3a096d88d17cc1
the referenced file was removed with the following change
Ie7f4b265368f1d10a8908d75e11d625b2cc39e7c
Change-Id: I0e25b1f38e0969037d1c8af367432da56bb12e92
If the variable SWIFT_STORAGE_IPS contains a space-separated list of
IPs, we can use this to create consistent rings across all proxy and
storage nodes.
Change-Id: If9307196dc7e74e4a842c95503958ae2d7f7acc7
This is a fairly opinionated change to do some spring cleaning on the
documentation.
The current output of shocco as rendered at [1] is completely broken.
I can not see that it is worth us maintaining this. Honestly, the
github page does a better job at showing the scripts with a bit of
formatting. The "changes" page is similarly useless today. cgit or
github show allow browsing of changes in the repo better. Both are
removed along with support scripts.
When you currently hit the first page, it gives no clue as to what
DevStack actually is. Add a paragraph explaining that, and link to
the cgit for easy source browsing.
stackrc.rst is not necessary; the stuff about database backends is
already discussed in configuration.rst; move the things about service
repos into a section of configuration.rst.
The discussion in openrc.rst is moved into the configuration.rst file.
localrc.conf.rst was just a paragraph pointing back to
configuration.rst; this is removed.
The variables described in exercise.rst are moved into a separate
section of configuration.rst
[1] http://docs.openstack.org/developer/devstack/#scripts
Change-Id: Ie7f4b265368f1d10a8908d75e11d625b2cc39e7c
In stack.sh, REGION_NAME is used to set environment variable
OS_REGION_NAME before using OpenStack client to configure accounts
for services. OpenStack client will try to find Keystone endpoint
in REGION_NAME to send the requests.
However, in the case of deploying multiple DevStack instances in
different regions with shared Keystone, Keystone is only running
in one the of region. When installing DevStack for the region that
does not host Keystone, OpenStack client will fail to find the
Keystone endpoint and thus DevStack fails to start.
This patch fixes this bug by introducing KEYSTONE_REGION_NAME for
user to specify which region Keystone is running in. Document of
multi-region setup is also updated.
Change-Id: I3e82c7ff69326d4171623299ffecea103d40c80d
Closes-Bug: #1540802
Fix the table with a bottom border. Regenerate the plugin list using
the script to make sure it works this time.
Change-Id: Iab3eb3879fd6017c55259e470477e4a9e34514e2
Neutron had a lot of work done during the Mitaka cycle to fix MTU
issues, so let's see if Neutron can stand on its own.
This commit reverts 06cfce37560243d22cd05b2c620be6702528a0b1
Neutron patches:
I6ffc8973c9b8f46cc19922ff04fdd2d23646b878
I4096a3e7704032fa4aa5c3aa8bcaec4e38d0d06d
I6a10c4dfc1f2198667f3d02528e2ca8020cb5bb8
Ic091fa78dfd133179c71cbc847bf955a06cb248a
Idf6221fee2c7da86123b330ad3c235ecc6868242
I6859ebdde1f7e3a8163b49d705620e522ada606a
Change-Id: Ie88c7ebb29adadde530217c95e2f38aacb119dc8
Since commit 7580a0c3e37932a8fc03750d35ccd4e13e18f8c4, openrc
print a WARNING message to stdout, it will break the zsh script
in faq.rst. This patch redirect openrc output to /dev/null.
Change-Id: Iaba03634d7a234cd4d120477f91ef56d0595cdf6
Closes-Bug: #1563940
Apparently this is intentional as a joke on devstack leaking
passwords, but the dual meaning of the word confuses people. Let's
change it before we get yet another review fixing it.
Change-Id: I3bee03612f6ea197362aab04a37f81043f77f235
After reviewing I5b1d49be8d9e3e331826e30182fba70f099b5e7f and
I161a157895b4ed0c9ea5a7a00302e30f4ad75ed3 - I have come to the
determination that this really should be in a DevStack plugin.
If both of the patches under review were to merge, we would be blessed
with at least the following variables:
OVS_NICS_FROM_BRIDGES
OVS_NIC_MAPPINGS
OVS_BRIDGE_MAPPINGS
OVS_PHYSICAL_BRIDGE
PHYSICAL_NETWORK
PUBLIC_PHYSICAL_NETWORK
Which really is not good. Let's just push this into a plugin, I don't
want to deal with it.
This reverts commit 3095ff51320291b3622cacc3bf2fb1043bff8d31.
Change-Id: I746022f5db93d3333101a014692fbdcd790a0004
This all started with an investigation into Fedora's use of ecua2ools
package. This package is a bit of a nightmare because it pulls in a
lot of other system-python packages.
For Ubuntu, this package was removed in
I47b7e787771683c2fc4404e586f11c1a19aac15c. However, it is not
actually a "pure python" package as described in that change, in that
it is not installable from pypi. I can't see how you could actually
run exercises/euca.sh on Ubuntu unless you installed euca2ools by hand
-- ergo I suggest it is totally unused, because nobody seems to have
reported problems.
In the mean time, ec2 api has moved to a plugin [1] anyway where the
recommendation in their README is to use the aws cli from amazon.
Thus remove all the parts related to EC2 and ecua2ools from base
devstack.
[1] https://git.openstack.org/cgit/openstack/ec2-api
Change-Id: I8a07320b59ea6cd7d1fe8bce61af84b5a28fb39e
Running OpenStack in a container can be a useful workflow for developers.
The primary benefits are faster performance and lower memory overhead
while still providing a suitable level of isolation.
The guide walks the user through procedure for configuring an LXC container
and deploying OpenStack in it using devstack. It also discusses the limitations
of this setup - particularly related to cinder.
Change-Id: I2e0921fd118cfe98cef86ba110a94b3edccf9a29
This is just another code path for little benefit in devstack which is
going to rot out. We should be opinionated here and only support the
dynamic catalog.
Change-Id: I4e5c7e86aefe72fc21c77d423033e9b169318fec
Allows the definition of the global variable OVS_BRIDGE_MAPPINGS (e.g.
in local.conf) to automatically trigger the creation of multiple OVS
bridges. For example:
OVS_BRIDGE_MAPPINGS=physnet1:br-br-enp0s20f1,physnet2:br-enp0s20f2
should automatically yield the creation of two bridges, respectively
associated to the two physical networks declared,
by simply running DevStack with the OVS agent enabled.
Documentation has also been added to doc/source/guides/neutron.rst.
Change-Id: I79dc0213c9d70ba628621c4c0f65481783590085
Closes-Bug: #1535835