We want to default to running all tox environments under python 3, so
set the basepython value in each environment.
We do not want to specify a minor version number, because we do not
want to have to update the file every time we upgrade python.
We do not want to set the override once in testenv, because that
breaks the more specific versions used in default environments like
py35 and py36.
Signed-off-by: Doug Hellmann <email@example.com>
This is a mechanically generated patch to complete step 1 of moving
the zuul job settings out of project-config and into each project
Because there will be a separate patch on each branch, the branch
specifiers for branch-specific jobs have been removed.
Because this patch is generated by a script, there may be some
cosmetic changes to the layout of the YAML file(s) as the contents are
See the python3-first goal document for details:
Describe an effort to extend existing clouds.yaml support to all
existing command line clients as well as support to horizon for
providing a downloadable config file snippet.
The OpenStack Client has been the suggested way forward for CLI
applications now for a few cycles however we remain in a limbo where in
some cases we suggest using OpenStack Client and in others we suggest
the project CLI.
Ratify that the OpenStack client is the recommended CLI for OpenStack
projects so that there is a clear direction on this.
Distributed locks, the concept, the problem space, what
has been done, what could be done, what will be done,
what must be done, the journey begins now (weekdays at
Updating due to summit session result, some more small
work and/or tweaks still needed.
In this spec we are proposing to return 'request_id' along with various return
types such as list, dict, resource object etc. from python-clients to return
request id to the user.
These literal blocks show log snippets weren't being formatted
correctly due to a missing newline between the :: and the literal
This change just adds some whitespace to make the formatting come out
as intended; there's no change to the content of the guidelines.
Our current requirements management policy is causing signficant gate
downtime, developer issues and packaging headaches. We can do better.
Using pins rather than open ranges for testing avoids firedrills. Most
of the work involved is a consequence of that key change.
This specification details implementing the W3C's Cross Origin
Resource Sharing specification in openstack's API's. It is intended
to provide additional options to user interface projects, by
permitting the API's to selectively break the single-origin policy
for configurable domains. It makes use of a single, common
middleware implementation already available in oslo_middleware.
This proposes the cross-project spec to eliminate SQL Schema Downgrades
in OpenStack. This is based upon the conversations had on both the
dev and operator mailing lists. In short, SQL Schema Downgrades do not
have a clear use-case where a restore to known-good point would not both
be more appropriate and desired (due to data inconsistency, integrity,
We should consider actually using the TRACE keyword for logging as
something meaningful. Today TRACE is used as a prefix for stack traces
even though it has no logging level definition.
This would provide a deep debug level which many developers have
requested. TRACE is a standard level in other logging systems such as:
and means what we are proposing here.
This means that 3rd party tools are highly likely to understand this
meaning for TRACE (and actually be terribly confused by the current
OpenStack use of TRACE).
Co-Authored-By: Alexis Lee <firstname.lastname@example.org>
This goal of this specification is to define the syntax for client
sorting arguments so that there is consistency across projects.
Note that an API working group guideline for sorting is closely
Proposed final draft.
This attempts to integrate much of the existing feedback, including
clarity around the points that were confusing people regarding the
"unit of work" and when stacktraces are appropriate.
In addition the Security logging section was dropped, because
realistically it was a poor fit for this original document. The wiki
page on it remains. My expectation is that security for logging should
be proposed as a follow on patch by someone that wants to make that
info fit well with this document.
All the open questions are now removed. Hopefully this ends up very
close to an agreed point.
Note: This evolved originally in the nova-specs repo at:
I674966988ed501dee323a106b84b5b6602d846b1 but is now moved over to
cross project specs repo. Some deep history can be seen at the
Part of bp:log-guidelines