Merge "Use NOVA_BIN_DIR / SWIFT_BIN_DIR for binaries"
diff --git a/.zuul.yaml b/.zuul.yaml
index ad5eb0a..a979fa4 100644
--- a/.zuul.yaml
+++ b/.zuul.yaml
@@ -194,9 +194,48 @@
- ^.*/locale/.*po$
- job:
- name: devstack
+ name: devstack-minimal
parent: devstack-base
description: |
+ Minimal devstack base job, intended for use by jobs that need
+ less than the normal minimum set of required-projects.
+ nodeset: openstack-single-node
+ required-projects:
+ - openstack/requirements
+ vars:
+ devstack_localrc:
+ # Multinode specific settings
+ SERVICE_HOST: "{{ hostvars['controller']['nodepool']['private_ipv4'] }}"
+ HOST_IP: "{{ hostvars['controller']['nodepool']['private_ipv4'] }}"
+ PUBLIC_BRIDGE_MTU: "{{ external_bridge_mtu }}"
+ devstack_services:
+ # Shared services
+ dstat: true
+ etcd3: true
+ mysql: true
+ peakmem_tracker: true
+ rabbit: true
+ group-vars:
+ subnode:
+ devstack_services:
+ # Shared services
+ dstat: true
+ peakmem_tracker: true
+ devstack_localrc:
+ # Multinode specific settings
+ HOST_IP: "{{ hostvars[inventory_hostname]['nodepool']['private_ipv4'] }}"
+ SERVICE_HOST: "{{ hostvars['controller']['nodepool']['private_ipv4'] }}"
+ PUBLIC_BRIDGE_MTU: "{{ external_bridge_mtu }}"
+ # Subnode specific settings
+ DATABASE_TYPE: mysql
+ RABBIT_HOST: "{{ hostvars['controller']['nodepool']['private_ipv4'] }}"
+ DATABASE_HOST: "{{ hostvars['controller']['nodepool']['private_ipv4'] }}"
+
+
+- job:
+ name: devstack
+ parent: devstack-minimal
+ description: |
Base devstack job for integration gate.
This base job can be used for single node and multinode devstack jobs.
@@ -226,7 +265,6 @@
- openstack/keystone
- openstack/neutron
- openstack/nova
- - openstack/requirements
- openstack/swift
timeout: 7200
vars:
@@ -240,10 +278,6 @@
NOVA_VNC_ENABLED: true
VNCSERVER_LISTEN: 0.0.0.0
VNCSERVER_PROXYCLIENT_ADDRESS: "{{ hostvars[inventory_hostname]['nodepool']['private_ipv4'] }}"
- # Multinode specific settings
- SERVICE_HOST: "{{ hostvars['controller']['nodepool']['private_ipv4'] }}"
- HOST_IP: "{{ hostvars['controller']['nodepool']['private_ipv4'] }}"
- PUBLIC_BRIDGE_MTU: "{{ external_bridge_mtu }}"
devstack_local_conf:
post-config:
$NEUTRON_CONF:
@@ -334,16 +368,9 @@
# integrated gate, so specifying the services has not effect.
# ceilometer-*: false
devstack_localrc:
- # Multinode specific settings
- HOST_IP: "{{ hostvars[inventory_hostname]['nodepool']['private_ipv4'] }}"
- SERVICE_HOST: "{{ hostvars['controller']['nodepool']['private_ipv4'] }}"
- PUBLIC_BRIDGE_MTU: "{{ external_bridge_mtu }}"
# Subnode specific settings
- DATABASE_TYPE: mysql
GLANCE_HOSTPORT: "{{ hostvars['controller']['nodepool']['private_ipv4'] }}:9292"
Q_HOST: "{{ hostvars['controller']['nodepool']['private_ipv4'] }}"
- RABBIT_HOST: "{{ hostvars['controller']['nodepool']['private_ipv4'] }}"
- DATABASE_HOST: "{{ hostvars['controller']['nodepool']['private_ipv4'] }}"
- job:
name: devstack-multinode
diff --git a/doc/source/faq.rst b/doc/source/faq.rst
index ed9b4da..efb315c 100644
--- a/doc/source/faq.rst
+++ b/doc/source/faq.rst
@@ -18,6 +18,57 @@
Your best choice is probably to choose a `distribution of OpenStack
<https://www.openstack.org/marketplace/distros/>`__.
+Can I use DevStack as a development environment?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Sure, you can. That said, there are a couple of things you should note before
+doing so:
+
+- DevStack makes a lot of configuration changes to your system and should not
+ be run in your main development environment.
+
+- All the repositories that DevStack clones when deploying are considered
+ volatile by default and thus are subject to hard resets. This is necessary to
+ keep you in sync with the latest upstream, which is what you want in a CI
+ situation, but it can result in branches being overwritten and files being
+ removed.
+
+ The corollary of this is that if you are working on a specific project, using
+ the DevStack project repository (defaulted to ``/opt/stack/<project>``) as
+ the single master repository for storing all your work is not recommended.
+ This behavior can be overridden by setting the ``RECLONE`` config option to
+ ``no``. Alternatively, you can avoid running ``stack.sh`` to redeploy by
+ restarting services manually. In any case, you should generally ensure work
+ in progress is pushed to Gerrit or otherwise backed up before running
+ ``stack.sh``.
+
+- If you use DevStack within a VM, you may wish to mount a local OpenStack
+ directory, such as ``~/src/openstack``, inside the VM and configure DevStack
+ to use this as the clone location using the ``{PROJECT}_REPO`` config
+ variables. For example, assuming you're using Vagrant and sharing your home
+ directory, you should place the following in ``local.conf``:
+
+ .. code-block:: shell
+
+ NEUTRON_REPO=/home/vagrant/src/neutron
+ NOVA_REPO=/home/vagrant/src/nova
+ KEYSTONE_REPO=/home/vagrant/src/keystone
+ GLANCE_REPO=/home/vagrant/src/glance
+ SWIFT_REPO=/home/vagrant/src/swift
+ HORIZON_REPO=/home/vagrant/src/horizon
+ CINDER_REPO=/home/vagrant/src/cinder
+ HEAT_REPO=/home/vagrant/src/heat
+ TEMPEST_REPO=/home/vagrant/src/tempest
+ HEATCLIENT_REPO=/home/vagrant/src/python-heatclient
+ GLANCECLIENT_REPO=/home/vagrant/src/python-glanceclient
+ NOVACLIENT_REPO=/home/vagrant/src/python-novaclient
+ NEUTRONCLIENT_REPO=/home/vagrant/src/python-neutronclient
+ OPENSTACKCLIENT_REPO=/home/vagrant/src/python-openstackclient
+ HEAT_CFNTOOLS_REPO=/home/vagrant/src/heat-cfntools
+ HEAT_TEMPLATES_REPO=/home/vagrant/src/heat-templates
+ NEUTRON_FWAAS_REPO=/home/vagrant/src/neutron-fwaas
+ # ...
+
Why a shell script, why not chef/puppet/...
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
diff --git a/doc/source/guides.rst b/doc/source/guides.rst
index c2c7b91..82e0dd6 100644
--- a/doc/source/guides.rst
+++ b/doc/source/guides.rst
@@ -20,6 +20,7 @@
guides/devstack-with-nested-kvm
guides/nova
guides/devstack-with-lbaas-v2
+ guides/devstack-with-ldap
All-In-One Single VM
--------------------
@@ -66,3 +67,8 @@
--------------------------------
Guide to working with nova features :doc:`Nova and devstack <guides/nova>`.
+
+Deploying DevStack with LDAP
+----------------------------
+
+Guide to setting up :doc:`DevStack with LDAP <guides/devstack-with-ldap>`.
diff --git a/doc/source/guides/devstack-with-lbaas-v2.rst b/doc/source/guides/devstack-with-lbaas-v2.rst
index 7dee520..df3c7ce 100644
--- a/doc/source/guides/devstack-with-lbaas-v2.rst
+++ b/doc/source/guides/devstack-with-lbaas-v2.rst
@@ -15,7 +15,7 @@
Install devstack
- ::
+::
git clone https://git.openstack.org/openstack-dev/devstack
cd devstack
@@ -23,7 +23,7 @@
Edit your ``local.conf`` to look like
- ::
+::
[[local|localrc]]
# Load the external LBaaS plugin.
@@ -60,7 +60,7 @@
Run stack.sh and do some sanity checks
- ::
+::
./stack.sh
. ./openrc
@@ -69,7 +69,7 @@
Create two nova instances that we can use as test http servers:
- ::
+::
#create nova instances on private network
nova boot --image $(nova image-list | awk '/ cirros-.*-x86_64-uec / {print $2}') --flavor 1 --nic net-id=$(openstack network list | awk '/ private / {print $2}') node1
@@ -83,7 +83,7 @@
Set up a simple web server on each of these instances. ssh into each instance (username 'cirros', password 'cubswin:)') and run
- ::
+::
MYIP=$(ifconfig eth0|grep 'inet addr'|awk -F: '{print $2}'| awk '{print $1}')
while true; do echo -e "HTTP/1.0 200 OK\r\n\r\nWelcome to $MYIP" | sudo nc -l -p 80 ; done&
@@ -91,7 +91,7 @@
Phase 2: Create your load balancers
------------------------------------
- ::
+::
neutron lbaas-loadbalancer-create --name lb1 private-subnet
neutron lbaas-loadbalancer-show lb1 # Wait for the provisioning_status to be ACTIVE.
diff --git a/doc/source/guides/devstack-with-ldap.rst b/doc/source/guides/devstack-with-ldap.rst
new file mode 100644
index 0000000..ec41141
--- /dev/null
+++ b/doc/source/guides/devstack-with-ldap.rst
@@ -0,0 +1,174 @@
+============================
+Deploying DevStack with LDAP
+============================
+
+The OpenStack Identity service has the ability to integrate with LDAP. The goal
+of this guide is to walk you through setting up an LDAP-backed OpenStack
+development environment.
+
+Introduction
+============
+
+LDAP support in keystone is read-only. You can use it to back an entire
+OpenStack deployment to a single LDAP server, or you can use it to back
+separate LDAP servers to specific keystone domains. Users within those domains
+will can authenticate against keystone, assume role assignments, and interact
+with other OpenStack services.
+
+Configuration
+=============
+
+To deploy an OpenLDAP server, make sure ``ldap`` is added to the list of
+``ENABLED_SERVICES``::
+
+ enable_service ldap
+
+Devstack will require a password to set up an LDAP administrator. This
+administrative user is also the bind user specified in keystone's configuration
+files, similar to a ``keystone`` user for MySQL databases.
+
+Devstack will prompt you for a password when running ``stack.sh`` if
+``LDAP_PASSWORD`` is not set. You can add the following to your
+``local.conf``::
+
+ LDAP_PASSWORD=super_secret_password
+
+At this point, devstack should have everything it needs to deploy OpenLDAP,
+bootstrap it with a minimal set of users, and configure it to back to a domain
+in keystone::
+
+ ./stack.sh
+
+Once ``stack.sh`` completes, you should have a running keystone deployment with
+a basic set of users. It is important to note that not all users will live
+within LDAP. Instead, keystone will back different domains to different
+identity sources. For example, the ``default`` domain will be backed by MySQL.
+This is usually where you'll find your administrative and services users. If
+you query keystone for a list of domains, you should see a domain called
+``Users``. This domain is set up by devstack and points to OpenLDAP.
+
+User Management
+===============
+
+Initially, there will only be two users in the LDAP server. The ``Manager``
+user is used by keystone to talk to OpenLDAP. The ``demo`` user is a generic
+user that you should be able to see if you query keystone for users within the
+``Users`` domain. Both of these users were added to LDAP using basic LDAP
+utilities installed by devstack (e.g. ``ldap-utils``) and LDIFs. The LDIFs used
+to create these users can be found in ``devstack/files/ldap/``.
+
+Listing Users
+-------------
+
+To list all users in LDAP directly, you can use ``ldapsearch`` with the LDAP
+user bootstrapped by devstack::
+
+ ldapsearch -x -w LDAP_PASSWORD -D cn=Manager,dc=openstack,dc=org \
+ -H ldap://localhost -b dc=openstack,dc=org
+
+As you can see, devstack creates an OpenStack domain called ``openstack.org``
+as a container for the ``Manager`` and ``demo`` users.
+
+Creating Users
+--------------
+
+Since keystone's LDAP integration is read-only, users must be added directly to
+LDAP. Users added directly to OpenLDAP will automatically be placed into the
+``Users`` domain.
+
+LDIFs can be used to add users via the command line. The following is an
+example LDIF that can be used to create a new LDAP user, let's call it
+``peter.ldif.in``::
+
+ dn: cn=peter,ou=Users,dc=openstack,dc=org
+ cn: peter
+ displayName: Peter Quill
+ givenName: Peter Quill
+ mail: starlord@openstack.org
+ objectClass: inetOrgPerson
+ objectClass: top
+ sn: peter
+ uid: peter
+ userPassword: im-a-better-pilot-than-rocket
+
+Now, we use the ``Manager`` user to create a user for Peter in LDAP::
+
+ ldapadd -x -w LDAP_PASSWORD -D cn=Manager,dc=openstack,dc=org \
+ -H ldap://localhost -c -f peter.ldif.in
+
+We should be able to assign Peter roles on projects. After Peter has some level
+of authorization, he should be able to login to Horizon by specifying the
+``Users`` domain and using his ``peter`` username and password. Authorization
+can be given to Peter by creating a project within the ``Users`` domain and
+giving him a role assignment on that project::
+
+ $ openstack project create --domain Users awesome-mix-vol-1
+ +-------------+----------------------------------+
+ | Field | Value |
+ +-------------+----------------------------------+
+ | description | |
+ | domain_id | 61a2de23107c46bea2d758167af707b9 |
+ | enabled | True |
+ | id | 7d422396d54945cdac8fe1e8e32baec4 |
+ | is_domain | False |
+ | name | awesome-mix-vol-1 |
+ | parent_id | 61a2de23107c46bea2d758167af707b9 |
+ | tags | [] |
+ +-------------+----------------------------------+
+ $ openstack role add --user peter --user-domain Users \
+ --project awesome-mix-vol-1 --project-domain Users admin
+
+
+Deleting Users
+--------------
+
+We can use the same basic steps to remove users from LDAP, but instead of using
+LDIFs, we can just pass the ``dn`` of the user we want to delete::
+
+ ldapdelete -x -w LDAP_PASSWORD -D cn=Manager,dc=openstack,dc=org \
+ -H ldap://localhost cn=peter,ou=Users,dc=openstack,dc=org
+
+Group Management
+================
+
+Like users, groups are considered specific identities. This means that groups
+also fall under the same read-only constraints as users and they can be managed
+directly with LDAP in the same way users are with LDIFs.
+
+Adding Groups
+-------------
+
+Let's define a specific group with the following LDIF::
+
+ dn: cn=guardians,ou=UserGroups,dc=openstack,dc=org
+ objectClass: groupOfNames
+ cn: guardians
+ description: Guardians of the Galaxy
+ member: cn=peter,dc=openstack,dc=org
+ member: cn=gamora,dc=openstack,dc=org
+ member: cn=drax,dc=openstack,dc=org
+ member: cn=rocket,dc=openstack,dc=org
+ member: cn=groot,dc=openstack,dc=org
+
+We can create the group using the same ``ldapadd`` command as we did with
+users::
+
+ ldapadd -x -w LDAP_PASSWORD -D cn=Manager,dc=openstack,dc=org \
+ -H ldap://localhost -c -f guardian-group.ldif.in
+
+If we check the group membership in Horizon, we'll see that only Peter is a
+member of the ``guardians`` group, despite the whole crew being specified in
+the LDIF. Once those accounts are created in LDAP, they will automatically be
+added to the ``guardians`` group. They will also assume any role assignments
+given to the ``guardians`` group.
+
+Deleting Groups
+---------------
+
+Just like users, groups can be deleted using the ``dn``::
+
+ ldapdelete -x -w LDAP_PASSWORD -D cn=Manager,dc=openstack,dc=org \
+ -H ldap://localhost cn=guardians,ou=UserGroups,dc=openstack,dc=org
+
+Note that this operation will not remove users within that group. It will only
+remove the group itself and the memberships any users had with that group.
diff --git a/doc/source/plugin-registry.rst b/doc/source/plugin-registry.rst
index 01ba9d1..c21e0ef 100644
--- a/doc/source/plugin-registry.rst
+++ b/doc/source/plugin-registry.rst
@@ -75,7 +75,6 @@
karbor-dashboard `git://git.openstack.org/openstack/karbor-dashboard <https://git.openstack.org/cgit/openstack/karbor-dashboard>`__
keystone `git://git.openstack.org/openstack/keystone <https://git.openstack.org/cgit/openstack/keystone>`__
kingbird `git://git.openstack.org/openstack/kingbird <https://git.openstack.org/cgit/openstack/kingbird>`__
-kolla-cli `git://git.openstack.org/openstack/kolla-cli <https://git.openstack.org/cgit/openstack/kolla-cli>`__
kuryr-kubernetes `git://git.openstack.org/openstack/kuryr-kubernetes <https://git.openstack.org/cgit/openstack/kuryr-kubernetes>`__
kuryr-libnetwork `git://git.openstack.org/openstack/kuryr-libnetwork <https://git.openstack.org/cgit/openstack/kuryr-libnetwork>`__
kuryr-tempest-plugin `git://git.openstack.org/openstack/kuryr-tempest-plugin <https://git.openstack.org/cgit/openstack/kuryr-tempest-plugin>`__