| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change finds a node with the same name as the allocation and
moves it to the beginning of the shuffled candidate list so that node
is the first allocation attempt.
It is common for node naming scheme to match the node's role (such as
compute-1, compute-2). Also this often matches the hostname
(allocation name) scheme. Without this change, this scenario will
generally result in swapped names (node compute-1 having hostname
compute-2, etc).
By preferring matching names this situation can be avoided in the
majority of cases, while not otherwise affecting the candidiate
allocation approach.
Change-Id: Ie990bfc209959d58852b9080778602eab5aa30af
|
|
|
|
| |
Change-Id: I31e128f5273cc50bf7662a62080251d8f226f6c5
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We are replacing all usages of the 'retrying' package with
'tenacity' as the author of retrying is not actively maintaining
the project.
Unit tests will be added/removed where applicable.
Tenacity [1] is a fork of retrying, but has improved the
interface and extensibility.
Our end goal here is removing the retrying package from our
requirements.
Tenacity provides the same functionality as retrying, but has the
following major differences to account for:
- Tenacity uses seconds rather than ms as retrying did.
- Tenacity has different kwargs for the decorator and
Retrying class itself.
- Tenacity has a different approach for retrying args by
using classes for its stop/wait/retry kwargs.
- By default tenacity raises a RetryError if a retried callable
times out; retrying raises the last exception from the callable.
Tenacity provides backwards compatibility here by offering
the 'reraise' kwarg.
- For retries that check a result, tenacity will raise if the retried
function raises, whereas retrying retried on all exceptions.
[1] https://github.com/jd/tenacity
Co-Authored-By: Dmitry Tantsur <dtantsur@protonmail.com>
Co-Authored-By: Riccardo Pittau <elfosardo@gmail.com>
Story: #1635390
Task: #10528
Change-Id: Ie5eb3ddc196505e8f58ed14de9952284598586fb
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change adds a `lessee` field to nodes, and exposes it
to policy. It also updates the non-admin node list API
to match for both owner and lessee; and updates the
allocation conductor to match owner allocations with nodes
with the appropriate lessee.
Change-Id: Ib31b49c7143ec8fd6cb486fc24038215b197c418
Story: 2006506
Task: 37930
|
|
|
|
|
|
|
|
|
|
| |
Add an owner to allocations. Depending on policy, a non-admin
can then create an allocation and have the owner set to their
project. Allocation processing then respects the owner.
Change-Id: I2965a4a601b9fa2c0212097da37b104a3e5514df
Story: #2006506
Task: #37540
|
|
|
|
|
|
| |
This is a normal situation and should not report a traceback.
Change-Id: I497d3aaae91e8aa87649323874121eb6e81c5fd8
|
|
|
|
|
|
|
|
|
| |
This feature addresses the case of moving the already deployed nodes
under the allocation API.
Change-Id: I29d0bd3663e0d1b27727a700c0f0e0fb6ceac1d9
Story: #2005014
Task: #29491
|
|
This change introduces the two RPC calls required for the allocation
API: create_allocation and destroy_allocation.
The nodes RPC is updated to:
* Prevent instance_uuid deletion if a node has an allocation and is
not in an updatable state.
* Delete allocation when instance_uuid is deleted and the node is
in an updatable state.
* Delete allocation when a node is unprovisioned and instance_uuid
is thus cleared.
Change-Id: I45815727f970c3d7fe51bb78d8e162a374d12e04
Story: #2004341
Task: #27987
|