When using manila's devstack plugin, we pull down the latest manila testing image created with the manila-image-elements project, and upload it to the stack's Glance/Image service. Glance's V2 API no longer needs g-reg which was a legacy database proxy service for the older glance API. Our devstack plugin should not have a hard dependency on this service. [1] http://lists.openstack.org/pipermail/openstack-dev/2016-May/094773.html [2] https://specs.openstack.org/openstack/glance-specs/specs/newton/approved/glance/deprecate-registry.html Change-Id: I58603032fb215ac0be2f76c8cd9fbce775be41dd Closes-Bug: #1859847
8.5 KiB
Setting up a development environment with devstack
This page describes how to setup a working development environment
that can be used in deploying manila
and
manila-ui
on latest releases of Ubuntu, Fedora or CentOS.
These instructions assume you are already familiar with git.
We recommend using devstack to develop and test code changes to
manila
and/or manila-ui
, in order to simply
evaluate the manila and/or project. Devstack is a shell script to build
complete OpenStack development environments on a virtual machine. If you
are not familiar with devstack, these pages can give you context:
Be aware that manila
and manila-ui
are not
enabled in devstack by default; you will need to add a few lines to the
devstack local.conf
file to let devstack deploy and
configure manila
and manila-ui
on your virtual
machine.
Note
If you do not intend to deploy with the OpenStack Dashboard (horizon)
service, you can ignore instructions about enabling
manila-ui
.
Getting devstack
Start by cloning the devstack repository:
git clone https://opendev.org/openstack/devstack
Change to devstack directory:
cd devstack/
You're now on master
branch of devstack, switch to the
branch you want to test or develop against.
Sample local.conf files that get you started
Now that you have cloned the devstack repository, you need to
configure devstack before deploying it. This is done with a
local.conf
file. For manila, the local.conf file can also
determine which back end(s) are set up.
Caution
When using devstack with the below configurations, be aware that you will be setting up fake storage. The LVM, Generic, ZFSOnLinux drivers have not been developed for production use. They exist to provide a vanilla development and testing environment for manila contributors.
DHSS=False (driver_handles_share_servers=False) mode:
This is the easier mode for new contributors. Manila share back-end
drivers that operate in driver_handles_share_servers=False
mode do not allow creating shares on private project networks. On the
resulting stack, all manila shares created by you are exported on the
host network and hence are accessible to any compute resource (e.g.:
virtual machine, baremetal, container) that is able to reach the
devstack host.
LVM driver <samples/lvm_local.conf>
ZFSOnLinux driver <samples/zfsonlinux_local.conf>
CEPHFS driver <samples/cephfs_local.conf>
DHSS=True (driver_handles_share_servers=True) mode:
You may use the following setups if you are familiar with manila, and
would like to test with the project (tenant) isolation that manila
provides on the network and data path. Manila share back-end drivers
that operate in driver_handles_share_servers=True
mode
create shares on isolated project networks if told to do so. On the
resulting stack, when creating a share, you must specify a share network
to export the share to, and the share will be accessible to any compute
resource (e.g.: Virtual machine, baremetal, containers) that is able to
reach the share network you indicated.
Typically, new contributors take a while to understand OpenStack
networking, and we recommend that you familiarize yourself with the
DHSS=False
mode setup before attempting
DHSS=True
.
Generic driver <samples/generic_local.conf>
Container driver <samples/container_local.conf>
Building your devstack
Copy the appropriate sample local.conf file into the devstack folder on your virtual machine, make sure to name it
local.conf
Make sure to read inline comments and customize values where necessary
If you would like to run minimal services in your stack, or allow devstack to bootstrap tempest testing framework for you, see
more-customization
Finally, run the
stack.sh
script from within the devstack directory. We recommend that your run this inside a screen or tmux session because it could take a while:./stack.sh
After the script completes, you should have manila services running. You can verify that the services are running with the following commands:
$ systemctl status devstack@m-sch $ systemctl status devstack@m-shr $ systemctl status devstack@m-dat
By default, devstack sets up manila-api behind apache. The service name is
httpd
on Red Hat based systems andapache2
on Debian based systems.You may also use your "demo" credentials to invoke the command line clients:
$ source DEVSTACK_DIR/openrc admin demo $ manila service-list
The logs are accessible through
journalctl
. The following commands let you query logs. You may use the-f
option to tail these logs:$ journalctl -a -o short-precise --unit devstack@m-sch $ journalctl -a -o short-precise --unit devstack@m-shr $ journalctl -a -o short-precise --unit devstack@m-dat
If running behind apache, the manila-api logs will be in
/var/log/httpd/manila_api.log
(Red Hat) or in/var/log/apache2/manila_api.log
(Debian).Manila UI will now be available through OpenStack Horizon; look for the Shares tab under Project > Share.
More devstack customizations
Testing branches and changes submitted for review
To test a patch in review:
enable_plugin manila https://opendev.org/openstack/manila <ref>
If the ref is from review.opendev.org, it is structured as:
refs/changes/<last two digits of review number>/<review number>/<patchset number>
For example, if you want to test patchset 4 of https://review.opendev.org/#/c/614170/,
you can provide this in your local.conf
:
enable_plugin manila https://opendev.org/openstack/manila refs/changes/70/614170/4
ref can also simply be a stable branch name, for example:
enable_plugin manila https://opendev.org/openstack/manila stable/train
Limiting the services enabled in your stack
Manila needs only a message queue (rabbitmq) and a database (mysql, postgresql) to operate. Additionally, keystone service provides project administration if necessary, all other OpenStack services are not necessary to set up a basic test system.12
You can add the following to your local.conf
to deploy
your stack in a minimal fashion. This saves you a lot of time and
resources, but could limit your testing:
ENABLED_SERVICES=key,mysql,rabbit,tempest,manila,m-api,m-sch,m-shr,m-dat
Optionally, you can deploy with Manila, Nova, Neutron, Glance and Tempest:
ENABLED_SERVICES=key,mysql,rabbit,tempest,g-api
ENABLED_SERVICES+=n-api,n-cpu,n-cond,n-sch,n-crt,n-cauth,n-obj,placement-api,placement-client
ENABLED_SERVICES+=q-svc,q-dhcp,q-meta,q-l3,q-agt
ENABLED_SERVICES+=tempest
You can also enable tls-proxy
with
ENABLED_SERVICES
to allow devstack to use Apache and setup
a TLS proxy to terminate TLS connections. Using tls-proxy secures all
OpenStack service API endpoints and inter-service communication on your
devstack.
Bootstrapping Tempest
Add the following options in your local.conf
to set up
tempest:
ENABLE_ISOLATED_METADATA=True
TEMPEST_USE_TEST_ACCOUNTS=True
TEMPEST_ALLOW_TENANT_ISOLATION=False
TEMPEST_CONCURRENCY=8