Instead of broadcasting service request to all regions, IMS service
will now send request to only affected regions. Un-affected regions
will not receive request to perform a no-op.
Change-Id: I4008739676ce8ccd71f72bca57fb33dd05f001bc
Instead of broadcasting service request to all regions, FMS service
will now send request to only affected regions. Un-affected regions
will not receive request to perform a no-op.
This patch also catches exceptions from flavor logic which has
been missed.
Change-Id: Id285ba98b8a53f11cada05a7fb380f6facf69594
Instead of broadcasting service request to all regions, CMS service
will now send request to only affected regions. Un-affected regions
will not receive request to perform a no-op.
This patch also catches exceptions from customer logic which has
been missed.
Change-Id: Id86886fcb80329582baa596c1faa1d4126b0764d
Continuing to improve error message
catching with regard to the recent
overhaul of error base code.
Change-Id: I1635647ad7edc5ebb3021c421a82cc81ee976256
Some error types were updated to recommendations
which better fit their use cases, providing
better information. Heat errors are now
logged when seen in rds status checking,
to make debugging of heat errors such
as stack validation more readily apparent.
Change-Id: Ifd11edaead65bf2fcd6d828e397bf41ba0816b63
Ranger errors are split out
unecessarily in the code base
and need to be refactored for
python 3.6 best practice
Change-Id: I06b1e2679ff2f0d7cadf7eab4ab0a7cc61e138ca
Ram, vcpus, disk, and ephemeral storage values
provided in error messages will allow team
to better debug output when rare out of bounds
defect occurs. This will allow us to determine
if the problem is the number calculated for
testing or the ranger formula in the code that
is responsible for this defect.
Change-Id: I8aedefa757b48319f90ac97c1dfd3495218ad4d2
Ranger-agent may take a longer time to process IMS resource request from Ranger.
This ps allows Ranger to wait for Ranger-agent response an extended period of time
compared to other service requests such as FMS or CMS.
Change-Id: Ie4ab9944d9636b62b76b87b093a31724177e767e
Updated pep8 requirements and fixed resulting
codes to fix broken pep8 job.
Updated docker image build process to use roles
to ensure docker rather than using manual docker
install process to fix broken ranger image job.
Co-Authored-By: Jeremy Houser <jeremyhouser@protonmail.com>
Co-Authored-By: Chi Lo <cl566n@att.com>
Change-Id: I28df0a27e4b354dd53c17fbb1a9468cb7ff5bc16
When CMS API call is made for either create and update customer, a
A new optional customer domain field is introduced for CMS API call
to create or update customer. The customer domain value will be used
by Rds to set the customer and users domain value when generating the
heat template. In the event customer domain is not provided by the
CMS API call, a default value will be retrieved from the config file.
Change-Id: I58dbae760d56b756b72c5d9eaf7c0b61cf193847
RMS can access database to verify if customer, flavor, and image
recources exist for a particular region. This avoids the need
to invoke an api call to CMS, FMS, and IMS services while these
services also making api call to RMS itself.
Change-Id: Ic64e848b03a8fd8f078162f59a148b2dfb3322df
When a user with a domain different than
the domain of the user authorizing heat
to create the resources that ranger defines
is added to a customer template, heat returns
stack validation as the user cannot be found
in the domain of the authorizing user.
Updated to check if use match auth user and
if not, use ranger conf domain as previous
Change-Id: I1406b61c695a5d9a3d94e732b95c2b683c94852b
Heat must have the domain of the user
in order to validate the user for role
assignment. Regardless of if roles are being
changed or assigned, heat always requires
and validates this data when heat receives
a project template. This work persists the user
domain when calls are made to CMS so that
RDS can add this data to project heat templates.
Change-Id: I5a8e72241e68dac730c3522d820a17d926fa3be8
Changed ranger rms authentication to use
auth of site in request rather than site
of the ranger region when authorizing
updating the site
Change-Id: I85899e319b47eb70b1a5569894097a21b57e92c0
This commit provides the following uuid management:
(1) Remove uuid record from database after the uuid owned by
a Ranger service (cms, fms, ims) resource is deleted.
(2) Remove stale uuid record from database when such
record is inadvertently created during unsuccessful Ranger
service resource creation.
(3) Add authentication for uuidgen service delete uuid API.
Change-Id: Ifebd68851ff6c0996e7b19d331f4dd99682bd7d2
RMS has three rules which were not included into
the top level policy.json. These rules have been
moved to the top level in order to fix 403 against
uuid server. RMS specific policy.json was not
pointed at by any code, so with this fix
the file has been removed.
Change-Id: I8bf507a6336b8b07885e3e11490f1324bf29c5d4
add_tenants logic:
a) allow add tenant only if flavor already assigned to region(s)
b) each tenant in the request will be validated against the
regions assigned to flavor - at least ONE tenant must
pass validation:
i. if NO tenant in tenant list is associated with any of the
regions assigned to the flavor, Ranger will reject the
request entirely and user will be prompted to submit new
request with valid tenants.
ii. only the tenants in tenant list that pass validation will
be kept in flavor tenant list; those that failed
validation will be DROPPED from the tenant list.
delete_region logic (only for flavors with tenants):
a) if a tenant is associated only with the deleted region, the
delete_region logic will delete the tenant from fms table
and the tenant is dropped from the tenant list.
However, if the tenant is associated with other regions still
assigned to the flavor, the tenant stays in the list.
Change-Id: I31935477733c8597741cf7c7c57350ab1e2b4452
changed ranger policy.json to allow
use of expected project when running
tempest tests against ranger
Change-Id: I1319404899a68140443517a818497ac0856746f5
When an image is created with a url that is in excess
of 240 characters, the transacations table in ranger
audit database throws error "sqlalchemy.exc.DataError:
(MySQLdb._exceptions.DataError) (1406, "Data too long
for column 'event_details' at row 1")". By removing
this url from the log, we prevent this error while
maintaining other important data. Also restored ranger
to allowed projects in ranger policy.json
Change-Id: I4af73beed9bd40054f8d1e7281bc6f9216fdd243
Added update statement which will update
old ranger deployment databases to add
ranger region domain name
Change-Id: If0020b8d3e9c5ff2cabfa5d8d6f9656806f2bc6c
Ranger region now includes a field which declares
which openstack domain a resource should be deployed
in. This change updates rds to create resources in
that domain via the heat template
Change-Id: I43144eb75a34661fae15399b9d32842d65327621
This patch removes RDS service call to retreive resource status by
CMS, FMS, and IMS Ranger services. These services retrieve the
status by accessing the resource status database directly.
Change-Id: I7695eb5dca697f3326fa2d19aa45681e4b5fc2ce
This patch also removed transaction id hooks when calling
RootController default get. As a result, uuids record will
not be created.
Change-Id: I2ca0be02256ec62c8f9d48266867cc44121c1c4b
Refactor ranger to allow domain
for resource deployment to be
defined in create region api call,
rather than only being retrieved
from ranger configuration.
Change-Id: I1b481c49d4402438c8aa91a8ebd8b6dbe797997b
Chi Lo