Thanks to lifeless, pip now implicitly has a wheel cache so that it
builds a wheel before every install, and uses that cache. All our
clever attempts at manually doing wheelhouse things is actually
bypassing the existing cache and making things take longer.
We should remove all of this code and just let pip do this thing,
which is does very well, and get out of the way.
Change-Id: Ia140dc34638d893b92f66d1ba20efd9522c5923b
In Tokyo, there was a cross project session on distributed
key locking:
https://etherpad.openstack.org/p/mitaka-cross-project-dlm
In support of the discussion there, we'll need support for
a zookeeper service in Devstack and ability to use libraries
like Tooz for DLM functionality.
In this review, we pick up some configuration files from
monasca-api and copy the lib/template to implement the
zookeeper lifecycle. Those services that need zookeeper
need to add "zookeeper" in ENABLED_SERVICES.
Change-Id: Icef26e5cdaa930a581e27d330e47706776a7f98f
The interactive password prompt currently saves to .localrc.auto
However, this is removed when you re-run stack; that is required as it
is how we source the localrc bits of local.conf, and we want the
users' changes to be picked up.
The passwords, however, should remain constant, because everything has
already been setup with them. So write them to a separate file. Note
we source before localrc so it can still overwrite them.
Some minor flow-changes too
Change-Id: I9871c8b8c7569626faf552628de69b811ba4dac0
Closes-Bug: #1505872
this adds a timing infrastructure to devstack to account for time
taken up by set of operations. The first instance of this is
accounting the time taken up by doing apt_get calls.
Change-Id: I855ffe9c7a75e9943106af0f70cf715c34ae25c5
With the advent of plugins and their settings files it has become
possible to disable_service in local.conf only to have the service
re-enabled in a plugin settings file. This happens because of
processing order.
To get around this the disable_service function now aggregates
service names into a DISABLED_SERVICES variable which is then checked
during enable_service. If something tries to enable something that
was previously disabled, a warning is produced in the log and the
service is not enabled.
Then after all configuration has been sourced a final check is to
done by verify_disabled_services to confirm that something has not
manually adjusted ENABLED_SERVICES to overcome a previously called
disable_service. If something has, the stack dies with an error.
Change-Id: I0f9403f44ed2fe693a46cd02486bd94043ce6b1a
Closes-Bug: #1504304
This lets you specify that devstack should not be run by the user on
the box that you are on. Helps with running commands in the wrong
window.
Change-Id: I7aa26df1a2e02331d596bbfefb0697937787252f
Setup the log output before calling functions like
check_path_perm_sanity that want to write out to
the error log.
Change-Id: I9815965257c399a48f8cf0f344814d954137aecb
Closes-Bug: #1500834
As a follow-on to the issues raised by
I069f46f95656655ae7ba8f3dd929f47eae594b68, rather than a re-write of
create_userrc.sh logic, create a temporary userrc that can be helpful
for debugging until we have the whole system bootstrapped
Change-Id: I3325acffd259cf7f6f4a153c88037cfe8405ca50
This reverts commit f768787bdd6dddf2790f83a884618d29677ca77c.
And sets OS_AUTH_VERSION so swift CLI doesn't fall flat when
not using v2 keystone
Change-Id: If44a7e0d85e48020a3c90d8c5c027513129f0f3b
If `DATABASE_TYPE` is configured in `local.conf`, the database backend
is currently configured with `initialize_database_backends` even if no
database backend is enabled.
On a multi-nodes Devstack environment, such as devstack-vagrant, the
compute node currently fails because it does not have PyMysql. This
compute node has no database backend enabled, but has to connect to
the database on another node.
We should install the python client if DATABASE_TYPE is set, even
if no database backend is enabled.
Closes-Bug: 1501001
Change-Id: Iffd5f7243a0dfdbe56cf6b9a87b96ed7678c81dd
It will report 'unknown locale: UTF-8', when the env is UTF-8.
Default set the LC_ALL to C in the stackrc, instead. And delete
the duplicate option in stack.sh.
Closes-Bug: 1499296
Change-Id: I14121b25ac314a1a93e6dd6811e196ce2a7c0eb5
We can just directly install the latest RDO repo rather than having to
keep this up-to-date. I don't think there is actually much there we
need any more; there was a lot more coming from RDO in the centos6
days. openvswitch is one big one, however.
Change-Id: I42b8bc1aea8ff61770987eecd5fc3b8309c1e210
The commit breaks creation of user rc file.
Now devstack doesn't create certificate for user
(because it's too early to do it) and doesn't react
to changes of EC2/S3 urls if they is recreated by devstack plugins.
So the commit totally broke ec2-api gating for example.
Change-Id: I069f46f95656655ae7ba8f3dd929f47eae594b68
Changeset https://review.openstack.org/#/c/225426/ changed how images
were uploaded into Glance, however the (now) unused TOKEN variable
and function argument to upload_image remained.
These have been removed.
Change-Id: I9910c469f72d52e56111048cc24ea3c992c1d480
There is no reason to use keystone token bootstrapping for image
uploads. Glance is a service, and images can be uploaded to it normally
without special shenanigans.
Depends-On: If7b81c4a6746c8a1eb0302c96e045fb0f457d67b
Change-Id: I7092fb10cbe243e091789134263fab081af0c7f4
If something goes wrong after keystone is running with services
registered, but before credentials are written, it's hard to poke at the
existing half-running state because none of the auth information is
recorded.
Write the files right after we're done bootstrapping keystone.
Change-Id: I2f8ae86e17d26ec4defa16e843faa8987d27fac9
after the glance_store vs. upper-constraints bug, it's probably worth
actually enforcing and sanity checking that devstack is doing what
it's being asked of with LIBS_FROM_GIT. This will hopefully reduce
user generated error.
This *might* not work with the current oslo naming, we'll have to test
and normalize that.
Change-Id: Iffef2007f99a0e932b68c4c897ebbfb748cac2b4
The ceilometer project is moving to using a devstack plugin rather
than having ceilometer in the base devstack. This is to allow
greater control and flexibility.
Change-Id: I413ab159474b7d7231ad66d3a482201f74efe8a8
This change have broke the Ironic tests. Reverting to unblock the Ironic
gate.
This reverts commit 4b115ad526df7e12bbdc71e0280b3c691e53ed04.
Closes-Bug: #1492216
Change-Id: I03acfdf47caf435cede1df08fd79b288a6662435
The commit 05aa3846a0402edc9cc49f4ba36f09592004b273 into devstack exposed a bug
where pip_install is called before the requirements repository is cloned. This
change ensures that the requirements repository exists before pip_install is
called.
Change-Id: I60b157fc98691764a69cf022852e7a95fc50cdd7
Closes-Bug: #1486304
Having behavior on your laptop diverge from behavior in the gate is
confusing. Just use constraints on every devstack run to be consistent.
Users of devstack can edit the requirements repo in order to change
these constraints locally if necessary.
Change-Id: I843208e2e982eb04931b76f5cb4bd219fbcd70de
At this point all our function calls should be using the V3 APIs anyway
so switch the authentication credentials to v3 compatible ones and
remove all the hacks we added to force v3 API calls.
Implements: bp keystonev3
Change-Id: If92d3e11b9a363454f77527783b6d25f4da9c249
With keystone's move to /identity, a conflict in for resources was
created as both keystone and horizon used /identity. The keystone
config took precedence and rendered API output in the horizon UI.
This patch sets the root for horizon to /dashboard and serves all
horizon content from there. Additionally, a RedirectMatch has been added
to the apache config for horizon to redirect '/' to '/dashboard' this
will allow the implementation to change without being immediately
painful to users.
Also made the path '/dashboard/' configurable in stackrc.
Closes-Bug: #1478306
Depends-On: I9a04f936ed6d8c14775a332dc28e903992806c42
for devstack-gate changes to remove hard coded horizon url structure
assumptions.
Change-Id: I6fbca5cea9e44df160afbccc71bd045437657320
We pull the pip constraints from the requirements repo so need to clone
that repo prior to using the constraints. In fixup_stuff.sh devstack
attempts to install packages like prettytable using the constraints. It
is also possible to need constraints before fixup_stuff.sh if tracking
depends. To deal with this clone requirements repo before any possible
use of constraints in pip_install.
Change-Id: I42e981c8c5ce1b8a57b9f6cce213065c72d6af11
I dug back through the history to see why xtrace is enabled where it
is. Originally (like first commit originally), it was somewhat sanely
placed to turn on tracing after it had done the interactive
"read_password" prompt stuff. Over time, it has just shuffled it's
way down as stuff got added around it.
This was noticed this because I was looking for tracing of earlier
commands when looking at the repo setup (see
Iec2ad7b5598fdaefbc2338ade702bc7b08963b96) and couldn't find it.
Putting this at the start means we both capture all output
unconditionally, and avoid needlessly getting this interleaved at some
odd place again.
Change-Id: I441d7eecbab9d204258c18a071ccc1cbf4f7512a
