MariaDB backups: meaning of backup and restore states returned by Cloud Foundry - swisscomdev

I did not find any documentation about the states of a MariaDB backup and the restore (https://docs.developer.swisscom.com/devguide-sc/services/backups.html).
For example, when I make the API call GET /custom/service_instances/{service-instance-id}/backups, the following JSON is returned as a response. In the response there are the attributes "status" in the entity of a backup, and the entity of a restore.
{
"total_results": 2,
"total_pages": 1,
"prev_url": null,
"next_url": null,
"resources": [
{
"metadata": {
"guid": "95b9108a-1903-4cea-b52e-bbb3b0414986",
"url": "/custom/service_instances/3955ad28-3f47-4f08-8eee-748f6e162d46/backups/95b9108a-1903-4cea-b52e-bbb3b0414986",
"created_at": "2016-10-03T20:52:04Z",
"updated_at": "2016-10-03T20:52:34Z"
},
"entity": {
"service_instance_id": "3955ad28-3f47-4f08-8eee-748f6e162d46",
"status": "CREATE_SUCCEEDED",
"restores": []
}
},
{
"metadata": {
"guid": "4ffff7d4-55a8-4e57-9035-98ed11380991",
"url": "/custom/service_instances/3955ad28-3f47-4f08-8eee-748f6e162d46/backups/4ffff7d4-55a8-4e57-9035-98ed11380991",
"created_at": "2016-10-03T08:50:07Z",
"updated_at": "2016-10-03T08:50:37Z"
},
"entity": {
"service_instance_id": "3955ad28-3f47-4f08-8eee-748f6e162d46",
"status": "CREATE_SUCCEEDED",
"restores": [
{
"metadata": {
"guid": "1a33a385-3703-423d-8052-be7a7a061878",
"url": "/custom/service_instances/3955ad28-3f47-4f08-8eee-748f6e162d46/backups/4ffff7d4-55a8-4e57-9035-98ed11380991/restores/1a33a385-3703-423d-8052-be7a7a061878",
"created_at": "2016-10-03T20:52:38Z",
"updated_at": "2016-10-03T20:53:08Z"
},
"entity": {
"backup_id": "4ffff7d4-55a8-4e57-9035-98ed11380991",
"status": "SUCCEEDED"
}
}
]
}
}
]
}
So, the question is: WHAT are all possible values in the "status" attributes on both cases, and WHEN do they happen?
Thanks in advance,

Just for documentation purposes, I've got to know which are the available statuses:
Backup statuses:
CREATE_IN_PROGRESS
CREATE_SUCCEEDED
CREATE_FAILED
DELETE_IN_PROGRESS
DELETE_SUCCEEDED
DELETE_FAILED
Restore statuses:
IN_PROGRESS
SUCCEEDED
FAILED
Moreover, it is not possible to trigger a restore when there is another backup create or delete, or another restore operation in progress.

Related

How to set/update test run owner in Azure Devops Rest API?

I am creating a test run in Azure Devops with Rest API. A sample POST request I make is like:
{
"name": "Test Run Name",
"automated": true,
"plan": {
"id": 11111111,
"name": null,
"url": null,
"state": null,
"iteration": null
},
"pointIds": [
222222222222
],
"build": {
"id": "2222233455",
"buildNumber": "buildNumberjlkajdlajsldj",
"uri": "vstfs:///Build/Build/2222222222",
"sourceBranch": "refs/pull/22222/merge",
"definition": {
"id": "2222"
}
},
"buildConfiguration": {
"id": 3333333,
"number": "buildNumberjlkajdlajsldj",
"uri": "vstfs:///Build/Build/222222222222"
},
"owner": {
"id": "44444444-2222-bbbb-aaaa-1111111111",
"descriptor": "aad.AAAAAAAAAAAAAAAAAAAAAAAAAA"
}
}
But here owner information is ignored and owner is assigned as authorized user of the requester. The requested account have necessary permissions.
Do I make something wrong or owner information cannot be assigned to another user?

How to check if a changeType is "merge" or "branch" when retrieving git changes through Azure DevOps REST Api

I am fetching Git changes from Azure DevOps REST Api and want to distinguish if a specific commit was a merge/branch operation. The default changeTypes are: add, edit, delete and I couldn't find any reference for "merge" or "branch".
Is there a built in way to achieve this?
My query uses the following syntax from the official doc:
GET https://{instance}/{collection}/_apis/git/repositories/{repositoryId}/commits/{commitId}?api-version=4.1
And the response is like:
{
"parents": [],
"treeId": "7fa1a3523ffef51c525ea476bffff7d648b8cb3d",
"push": {
"pushedBy": {
"id": "8c8c7d32-6b1b-47f4-b2e9-30b477b5ab3d",
"displayName": "Chuck Reinhart",
"uniqueName": "fabrikamfiber3#hotmail.com",
"url": "https://fabrikam:8080/tfs/_apis/Identities/8c8c7d32-6b1b-47f4-b2e9-30b477b5ab3d",
"imageUrl": "https://fabrikam:8080/tfs/_api/_common/identityImage?id=8c8c7d32-6b1b-47f4-b2e9-30b477b5ab3d"
},
"pushId": 1,
"date": "2014-01-29T23:33:15.2434002Z"
},
"commitId": "be67f8871a4d2c75f13a51c1d3c30ac0d74d4ef4",
"author": {
"name": "Chuck Reinhart",
"email": "fabrikamfiber3#hotmail.com",
"date": "2014-01-29T23:32:09Z"
},
"committer": {
"name": "Chuck Reinhart",
"email": "fabrikamfiber3#hotmail.com",
"date": "2014-01-29T23:32:09Z"
},
"comment": "First cut\n",
"changeCounts": {
"Add": 2
},
"changes": [
{
"item": {
"gitObjectType": "blob",
"path": "/.gitattributes",
"url": "https://fabrikam:8080/tfs/_apis/git/repositories/278d5cd2-584d-4b63-824a-2ba458937249/items/.gitattributes?versionType=Commit"
},
"changeType": "add"
},
{
"item": {
"gitObjectType": "blob",
"path": "/.gitignore",
"url": "https://fabrikam:8080/tfs/_apis/git/repositories/278d5cd2-584d-4b63-824a-2ba458937249/items/.gitignore?versionType=Commit"
},
"changeType": "add"
}
],
"url": "https://fabrikam:8080/tfs/_apis/git/repositories/278d5cd2-584d-4b63-824a-2ba458937249/commits/be67f8871a4d2c75f13a51c1d3c30ac0d74d4ef4",
"remoteUrl": "https://fabrikam:8080/tfs/_git/Fabrikam-Fiber-Git/commit/be67f8871a4d2c75f13a51c1d3c30ac0d74d4ef4",
"_links": {
"self": {
"href": "https://fabrikam:8080/tfs/_apis/git/repositories/278d5cd2-584d-4b63-824a-2ba458937249/commits/be67f8871a4d2c75f13a51c1d3c30ac0d74d4ef4"
},
"repository": {
"href": "https://fabrikam:8080/tfs/_apis/git/repositories/278d5cd2-584d-4b63-824a-2ba458937249"
},
"changes": {
"href": "https://fabrikam:8080/tfs/_apis/git/repositories/278d5cd2-584d-4b63-824a-2ba458937249/commits/be67f8871a4d2c75f13a51c1d3c30ac0d74d4ef4/changes"
},
"web": {
"href": "https://fabrikam:8080/tfs/_git/Fabrikam-Fiber-Git/commit/be67f8871a4d2c75f13a51c1d3c30ac0d74d4ef4"
},
"tree": {
"href": "https://fabrikam:8080/tfs/_apis/git/repositories/278d5cd2-584d-4b63-824a-2ba458937249/trees/7fa1a3523ffef51c525ea476bffff7d648b8cb3d"
}
}
}
If there is no built in way to achieve this, should the parent be used as a guidance? Like if it is empty it is a 'branch' operation and if there is two entries in it it is a 'merge'?
Update 1
I can see in the documentation referenced above that there are merge and branch changeTypes, but when I query a change that was merged the result only contains edit or add.
You will have to use the parents collection to determine whether it was a merge. Since normal commits just have 1 parent, more than 1 indicates a merge.
From the git documentation here
A commit object may have any number of parents. With exactly one parent, it is an ordinary commit. Having more than one parent makes the commit a merge between several lines of history. Initial (root) commits have no parents.

Write correct JSON about PlanDefinition and ActivityDefinition on FHIR

I want to write a JSON to create a PlanDefinition resource with some ActivityDefinition resources inside it to persiste on FHIR r4 server these resources.
My sandbox server is Hapi FHIR
Two questions:
The first: How can I write it
The second: When I'll wirte the correct JSON, the result will be the creation of one PlanDefinition resource and some ActivityDefinition resources, or will be created only one PlanDefinition resource with these informations inside it?
This is my JSON to create a simple PlanDefinition, but I donìt know how to add ActivityDefinition inside it
{
"resourceType": "PlanDefinition",
"id": "999999",
"meta": {
"versionId": "1",
"lastUpdated": "2020-04-16T11:10:45.868+00:00",
"source": "#YS2h8QIqvGKHDy4x"
},
"url": "www.myserver.it",
"identifier": [ {
"system": "www.myserver.it",
"value": "jtr-pd1"
} ],
"version": "versione 1",
"status": "active",
"action": [ {
"title": "A",
"definitionCanonical": "#Process_Alex1"
}, {
"title": "B",
"definitionCanonical": "#Process_Alex2"
}, {
"title": "C",
"definitionCanonical": "ActivityDefinition"
} ]
}
Typically in FHIR we don't contain resources inside each other. References instead point to other independently maintained resource instances. For example, multiple PlanDefinitions might point to the same ActivityDefinition because that one activity is a 'step' in multiple protocols/order sets.
If you have a situation where an activity definition is tied to a single PlanDefinition and can't exist independent of that PlanDefinition (e.g. if the PlanDefinition were deleted, the ActivityDefinition would go too; no other PlanDefinition can point to the Activity, any update to the activity would be considered an update to the plan, etc.), you can send the ActivityDefinition as a 'contained' resource. Your instance would look like this:
{
"resourceType": "PlanDefinition",
"id": "999999",
"meta": {
"versionId": "1",
"lastUpdated": "2020-04-16T11:10:45.868+00:00",
"source": "#YS2h8QIqvGKHDy4x"
},
"contained": [ {
"resourceType": "ActivityDefinition",
"id": "Process_Alex1",
...
},
{
"resourceType": "ActivityDefinition",
"id": "Process_Alex2",
...
} ],
{
"url": "www.myserver.it",
"identifier": [ {
"system": "www.myserver.it",
"value": "jtr-pd1"
} ],
"version": "versione 1",
"status": "active",
"action": [ {
"title": "A",
"definitionCanonical": "#Process_Alex1"
}, {
"title": "B",
"definitionCanonical": "#Process_Alex2"
}, {
"title": "C",
"definitionCanonical": "http://somewhere.org/ActivityDefinition/foo"
} ]
}

How to find a TFS release in progress?

I need to fail a build on TFS 2018 if its pipeline is not fully complete. Batching just the build is not enough; the linked release must be finished as well before another build can begin. My idea is to do this in a PowerShell script via the REST API.
I see in the official documentation here that there's a property called TaskStatus. It provides a value of inProgress, presumably for releases that are in progress. This might do the trick, but there's no indication of how to actually use it.
Using the REST API, how can I get the TaskStatus of a given release?
The in process and some other values such as succeeded, canceled just stand for the status of a task in release pipeline.
You could simply use the Rest API to get a release
GET https://fabrikam.vsrm.visualstudio.com/MyFirstProject/_apis/release/releases/{releaseId}?api-version=4.1-preview.6
There should be a value called status:
"id": 18,
"name": "Release-18",
"status": "abandoned",
"createdOn": "2017-06-16T01:36:20.397Z",
"modifiedOn": "2017-06-16T01:36:21.07Z",
"modifiedBy": {
"id": "4adb1680-0eac-6149-b5ee-fc8b4f6ca227",
"displayName": "Chuck Reinhart",
"uniqueName": "fabfiber#outlook.com",
"url": "https://app.vssps.visualstudio.com/A168224e4-29ff-4081-9954-c8780ce81117/_apis/Identities/4adb1680-0eac-6149-b5ee-fc8b4f6ca227",
"imageUrl": "https://fabfiber-inc.visualstudio.com/_api/_common/identityImage?id=4adb1680-0eac-6149-b5ee-fc8b4f6ca227"
},
"createdBy": {
"id": "4adb1680-0eac-6149-b5ee-fc8b4f6ca227",
"displayName": "Chuck Reinhart",
"uniqueName": "fabfiber#outlook.com",
"url": "https://app.vssps.visualstudio.com/A168224e4-29ff-4081-9954-c8780ce81117/_apis/Identities/4adb1680-0eac-6149-b5ee-fc8b4f6ca227",
"imageUrl": "https://fabfiber-inc.visualstudio.com/_api/_common/identityImage?id=4adb1680-0eac-6149-b5ee-fc8b4f6ca227"
},
"environments": [
{
"id": 69,
"releaseId": 18,
"name": "Dev",
"status": "notStarted",
"variables": {},
"preDeployApprovals": [],
"postDeployApprovals": [],
"preApprovalsSnapshot": {
"approvals": [
{
"rank": 1,
"isAutomated": false,
"isNotificationOn": false,
"approver": {
"id": "4adb1680-0eac-6149-b5ee-fc8b4f6ca227",
"displayName": "Chuck Reinhart",
"uniqueName": "fabfiber#outlook.com",
"url": "https://app.vssps.visualstudio.com/A168224e4-29ff-4081-9954-c8780ce81117/_apis/Identities/4adb1680-0eac-6149-b5ee-fc8b4f6ca227",
"imageUrl": "https://fabfiber-inc.visualstudio.com/_api/_common/identityImage?id=4adb1680-0eac-6149-b5ee-fc8b4f6ca227"
},
"id": 0
}
You could fetch the value status in your return json file, and judge if the release succeed or failed. Finally according to this status to trigger another build or not.
Update
A sample of the returned json with task's status info:
"deploymentJobs": [
{
"job": {
"id": 5,
"timelineRecordId": "855ea6d6-9ed0-442d-b921-0c4add8bb068",
"name": "Release",
"dateStarted": "2018-07-04T08:53:05.9133333Z",
"dateEnded": "2018-07-04T08:53:21.34Z",
"startTime": "2018-07-04T08:53:05.9133333Z",
"finishTime": "2018-07-04T08:53:21.34Z",
"status": "succeeded",
"rank": 1,
"issues": [],
"agentName": "DFA00"
},
"tasks": [
{
"id": 1,
"timelineRecordId": "fa3bb635-eab4-4c1b-9cc0-fdccd7ced33f",
"name": "Initialize Job",
"dateStarted": "2018-07-04T08:53:06.5833333Z",
"dateEnded": "2018-07-04T08:53:06.8033333Z",
"startTime": "2018-07-04T08:53:06.5833333Z",
"finishTime": "2018-07-04T08:53:06.8033333Z",
"status": "succeeded",
"rank": 1,
"issues": [],
"agentName": "DFA00",
"logUrl": "http://xxxx:8080/tfs/DefaultCollection/7658559e-6e61-422a-952b-a5fce0b6ca1d/_apis/Release/releases/49/environments/49/tasks/1/logs?releaseDeployPhaseId=54"
},
There should be timelinerecord, starttime, finishtime, status for a task deployment result in a single release.

How to set review for revision using Gerrit REST API

I'm trying to setup Teamcity building and verifying patchsets from Gerrit. The last step should set Verified to -1 if build failed. I'm playing around with Gerrit REST API and I think I found a proper command:
https://gerrit-review.googlesource.com/Documentation/rest-api-changes.html#set-review
The documentation says:
As response a ReviewInfo entity is returned that describes the applied
labels.
My request looks like this:
POST <gerrit-url>/a/changes/I696f00f4968fcb35fa614ce6325499aa15367150/revisions/current/review
{
"message": "Build failed",
"labels": {
"Verified": -1
}
}
As a response I get full revision info:
{
"id": "dev_test~master~<change-id>",
"project": "dev_test",
"branch": "master",
"hashtags": [],
"change_id": "<change-id>",
"subject": "a test",
"status": "NEW",
"created": "2017-04-03 07:53:19.000000000",
"updated": "2017-04-04 08:47:34.000000000",
"submit_type": "MERGE_IF_NECESSARY",
"mergeable": true,
"insertions": 133,
"deletions": 7,
"unresolved_comment_count": 0,
"_number": 381,
"owner": {
"_account_id": 4,
"name": "<my-name>",
"email": "<my-email>",
"username": "<my-username>",
},
"labels": {
"Code-Review": {
"all": [
{
"value": 1,
"date": "2017-04-04 08:47:34.000000000",
"permitted_voting_range": {
"min": -2,
"max": 2
},
"_account_id": 4,
"name": "<my-name>",
"email": "<my-email>",
"username": "<my-username>"
}
],
"values": {
"-2": "This shall not be merged",
"-1": "I would prefer this is not merged as is",
" 0": "No score",
"+1": "Looks good to me, but someone else must approve",
"+2": "Looks good to me, approved"
},
"default_value": 0
},
"Verified": {
"all": [
{
"value": 0,
"permitted_voting_range": {
"min": -1,
"max": 1
},
"_account_id": 4,
"name": "<my-name>",
"email": "<my-email>",
"username": "<my-username>"
}
],
"values": {
"-1": "Fails",
" 0": "No score",
"+1": "Verified"
},
"default_value": 0
}
},
"permitted_labels": {},
"removable_reviewers": [],
"reviewers": {
"REVIEWER": [
{
"_account_id": 4,
"name": "<my-name>",
"email": "<my-email>",
"username": "<my-username>"
}
]
},
"current_revision": "913330441711b067899a664a60c78be518e547b4",
"revisions": {
"913330441711b067899a664a60c78be518e547b4": {
"kind": "REWORK",
"_number": 6,
"created": "2017-04-03 14:08:14.000000000",
"uploader": {
"_account_id": 4,
"name": "<my-name>",
"email": "<my-email>",
"username": "<my-username>"
},
"ref": "refs/changes/81/381/6",
"fetch": {
"ssh": {
"url": "ssh://<url>",
"ref": "refs/changes/81/381/6"
},
"http": {
"url": "http://<url>",
"ref": "refs/changes/81/381/6"
}
}
}
}
}
It's not affected by request. Same response is returned when I send request using GET method or using POST method with invalid JSON in body(!)
Gerrit version is: 2.13.6-3008-gcdc381e
Do I something wrong?
PS. Here is similar question, but it isn't helpful: Gerrit set-review api doesn't work
EDIT:
It seems that I getting response from GET request not POST
I figured it out. It's not gerrit problem. I used http request and our server redirected to https with 301 which the Postman fallowed and returned response for GET request.