As per 2023.1 testing runtime[1], we need to test on Ubuntu
Jammy (which will be taken care by tempest and devstack patches
to move base jobs to Jammy) and at least single job to run on
Ubutnu Focal (for smooth upgrade). Also, python 3.10 testing is
voting now.
This commit makes python 3.10 functional job as voting and python 3.10
unit test job are voting via generic template. Python 3.8/3.9 jobs are
running on Focal and python 3.10 on Jammy.
[1] https://governance.openstack.org/tc/reference/runtimes/2023.1.html
Change-Id: I97b82399af9a640353ba979965c202afcb224163
This is an automatically generated patch to ensure unit testing
is in place for all the of the tested runtimes for zed.
See also the PTI in governance [1].
I needed to squash in another change that is dropping the py36 and py37
support. We cannot do that separately as those jobs are already failing.
[1]: https://governance.openstack.org/tc/reference/project-testing-interface.html
Change-Id: I378d5c3c1f3e96696670a4865caf5901269a5ee4
Setuptools v54.1.0 introduces a warning that the use of
dash-separated options in 'setup.cfg' will not be supported
in a future version [1].
Get ahead of the issue by replacing the dashes with underscores.
Without this, we see 'UserWarning' messages
like the following on new enough
versions of setuptools:
UserWarning: Usage of dash-separated 'description-file' will not be
supported in future versions. Please use the underscore name
'description_file' instead
[1] https://github.com/pypa/setuptools/commit/a2e9ae4cb
Change-Id: I08a9a737d4c897405ad71b9b900654b716705894
This repo is now testing only with Python 3, so let's make
a few cleanups:
- Remove python 2.7 stanza from setup.py
- Add requires on python >= 3.6 to setup.cfg so that pypi and pip
know about the requirement
- Remove obsolete sections from setup.cfg
- Update classifiers
- Update requirements, no need for python_version anymore
- Switch to using sphinx-build
- Use newer openstackdocstheme version
- Remove install_command from tox.ini, the default is fine
- Update to hacking 3.0, fix warnings
Change-Id: If66a87c519ce82ee7890ac3e133afef13fb35bd2
Adds the "openstack resource provider allocation unset" command which
allows removing resource provider(s) from the set of allocations for
the given consumer. This can be useful when a consumer has allocations
against more than one resource provider and
"openstack resource provider allocation delete" is undesirable as it
removes all allocations for the consumer. The new unset command requires
"--os-placement-api-version 1.12" or greater.
Note that the --provider option can be specified multiple times.
If the resulting allocations are all gone and 1.28 or greater is not
being used, a DELETE is called rather than PUT since
PUT /allocations/{consumer_id} before 1.28 does not allow an empty
"allocations" dict in the request body. In this case nothing is output
similar to the "openstack resource provider allocation delete" command.
Change-Id: I627bfd1ff699d075028da6afafbe7fb9b2f13058
Story: #2006779
Task: #37304
This is useful for installers to be aware of, and prior
to [1] could cause issues for devstack/grenade.
Though osc-placement also works for 3.7, we don't yet
have formal tests for that. When we do we should update
the classifiers.
[1] https://review.openstack.org/649096
Change-Id: I451c2de94c6ed478bd3295978312e4fe3ce36648
The openstack-dev mailing list has been replaced with
the openstack-discuss mailing list (*).
So replace the openstack-dev mailing list with
the openstack-discuss mailing list in setup.cfg.
*: http://lists.openstack.org/pipermail/openstack-dev/2018-September/134911.html
Change-Id: I4b2a390fab54e3fc44cd8b6406ecaa54b1abd7ad
Adds support to "openstack resource provider allocation set"
for microversion 1.8 where --project-id and --user-id are
required (and highly recommended).
Adds a new "openstack resource usage show" command
for microversion 1.9 and GET /usages.
Change-Id: I8ec19c8138611a06b41ec3ad949f45b8f6d7ec17
Partially-Implements: blueprint placement-osc-plugin-rocky
Set method was skipped due to two reason that from version 1.7 it is
not allowed to rename resource classes.
Change-Id: Id18aab2a95849bc60769f2f81c363c17d049b21f
Ghanshyam Mann