This is a mechanically generated change to replace openstack.org
git:// URLs with https:// equivalents.
This is in aid of a planned future move of the git hosting
infrastructure to a self-hosted instance of gitea (https://gitea.io),
which does not support the git wire protocol at this stage.
This update should result in no functional change.
For more information see the thread at
http://lists.openstack.org/pipermail/openstack-discuss/2019-March/003825.html
Change-Id: I086112adc18d8accfcfbc1fd3198dbdfae302c57
We will manage the eventlet version using constraints now. See the
thread starting at
http://lists.openstack.org/pipermail/openstack-dev/2018-April/129096.html
for more details.
Change-Id: Icdfe7679df3cc7c97685d11d81de3af791cb87c0
Co-Authored-By: Michel Peterson <michel@redhat.com>
Co-Authored-By: Chuck Short <chucks@redhat.com>
In case artifact's field is defined to be
nullable=false and also doesn't have any
default, we had a problem:
While creating new artifact of this type
with a value for this field we got:
"BadRequest <artifact_name> field: <field_name>.
value: [None]. Exception.
That happened although a field value was provided.
This kind of error is expected if the field does
not get any value at creation, but not expected
if value is provided.
The following patch suggest a fix for that.
closes-bug: #1775502
Change-Id: I642249f067ab853b4b7d56a8da4db5809ee414c6
In case artifact's field is defined to be
nullable=false and also doesn't have any
default, we had a problem:
While creating new artifact of this type
with a value for this field we got:
"BadRequest <artifact_name> field: <field_name>.
value: [None]. Exception.
That happened although a field value was provided.
This kind of error is expected if the field does
not get any value at creation, but not expected
if value is provided.
The following patch suggest a fix for that.
closes-bug: #1775502
Change-Id: I642249f067ab853b4b7d56a8da4db5809ee414c6
In case Artifact does not have tags associated and query
constain tags/tags-any condition with any other base artifact
field or custom field condition. It used to fail because of
INNER JOIN between glare_artifacts and glare_artifact_tags table.
Replaced "join" with "outerjoin" to rectify this issue.
Change-Id: Ie03520a38d2c726117195ea92c7fbd88c04bff18
While re-uploading blob if pre_upload_hook or store_api throws
exception, Existing content needs to be retained.
Change-Id: I51effe4c76de9a353dec99c634c173840c792198
In case of more than one tags values in request query with other
condition it was not using separate alias name for artifact_tag table
to join with glare_artifacts table. To rectify this we have created
aliases beforehand and using it updating the tag search condition.
Change-Id: Ic7afe47fcf8f23a694f2c3d99dbdbd7797d506dd
closes-bug: #1765338
If artifact data has multiple properties other than base
artifact properties i.e. which needs to be stored in
glare_artifact_properties table. In that case providing limit will
always result in less no of artifacts then limit.
This issue is not available in sqllite database, therefore no additional
testcase is added.
Change-Id: I933783cabb5b71d92b4d645d340bd9d1c9f6f8b5
closes-bug: #1766537
In case that "artifact data" does not contain properties other
than base artifact properties, query will return no records.
That because of INNER JOIN usage between glare_artifacts and
glare_artifact_properties tables (as there are no rows in
glare_artifact_properties corresponding to that artifact_id).
Therefore INNER JOIN needed to be added only if there is
any glare_artifact_properties based condition.
Change-Id: Icfcbeb41703771145db5405ffc2609dbb6ca1741
updating the value of source location in move operation
as part of artifact update.
Change-Id: Ic6912fa9c714762e38ba01793a7a8da1a70a12ba
Closes-bug: #1743971
when glare requests are failing with "401 Unauthorized"
against keycloak, more data can be added to the logs,
to understand the reason better.
In case keycloak return 401 it must provide the www-Authenticate
response header with the reason:
https://www.w3.org/Protocols/HTTP/1.0/spec.html#WWW-Authenticate
This code take care of it by adding the WWW-Authenticate value to
glare api-log.
Change-Id: Ia3966ad00868b559874610f552c8e491d8a01acd
With the new changes it is be possible to search tags based on or query.
it can be used with both tags and tags-any filter parameters.
Change-Id: Ib7a0054cb7e220e64d19839d79367b1ac180ea94
Implements: blueprint glare-search-artifact-query-update
Provides an option to specify query combiner ("and/or")
for attribute based filters in query parameter.
So if user wants to search artefact a based on filters :
field1 = value1 and (field2 = value2 or field3 = value3)
it can be specified in query like :
field1=eq:value1&field2=or:eq:value2&field3=or:eq:value3
"and" is the default value of combiner in case it is not specified.
Change-Id: I16c7c7fecefab5d615fa9e933234725249c5d97a
Implements: blueprint glare-search-artifact-query-update
default filter for name and type_name does not
allow to use like operator by default due to performance issue,
therefore we have added filters_ops for name in base_artifact
and type_name in all.py
Change-Id: Ib6c5f0d249c33f52858c03c454a0a7a0859e9301
display_type_name provides admin a facility to
define a more user friendly type_name for artifact.
Change-Id: I8b1b08e4fa647c87c65f7af94f8f49d6269e03cf
Currently in order to list artifacts from all tenants,
keyclock token must include 'admin' role.
The same goes for getting artifact from different realms,
or download blob of artifact from different realm.
The following changes enable more flexbility:
to list artifacts from all tenants, user can define
artifact:list_all_artifacts in policy.yaml with his
own choice for role.
E.G.
"artifact:list_all_artifacts": "role:su_role"
^ this will allow any user with role "su_role" to
list artifacts from any realm.
The same logic holds for getting artifact from other
realm (get_any_artifact), or download blob from artifact
in any realm (download_from_any_artifact)
Change-Id: Iaaa7f4b366230e0c5e4bee136bcdf9d072d498d8
Currently there was no way to get the total number
of records available during pagination until user
reaches the last page. And still he has to keep the
track of previous number of records.
To overcome this issue we have provided total_count
attribute in response structure which provides total
number of records available for the given filter.
Affected API :
GET /artifacts/{artifacts_type} artifact API.
For above API our updated response structure contains
a new json attribute "total_count" and value will
be of integer type.
Change-Id: I7608a80a70e90a4be24ebae7961346810d2f3a70