Update patch set 1

Patch Set 1:

(5 comments)

Patch-set: 1
Attention: {"person_ident":"Gerrit User 9708 \u003c9708@4a232e18-c5a9-48ee-94c0-e04e7cca6543\u003e","operation":"REMOVE","reason":"\u003cGERRIT_ACCOUNT_9708\u003e replied on the change"}
Attention: {"person_ident":"Gerrit User 16207 \u003c16207@4a232e18-c5a9-48ee-94c0-e04e7cca6543\u003e","operation":"ADD","reason":"\u003cGERRIT_ACCOUNT_9708\u003e replied on the change"}
This commit is contained in:
Gerrit User 9708 2024-04-04 13:54:19 +00:00 committed by Gerrit Code Review
parent 7df27a3f36
commit a236b7f7f7
1 changed files with 107 additions and 0 deletions

View File

@ -0,0 +1,107 @@
{
"comments": [
{
"unresolved": true,
"key": {
"uuid": "24de3a66_dae1477e",
"filename": "specs/2024.2/approved/libvirt-virtiofs-attach-manila-shares.rst",
"patchSetId": 1
},
"lineNbr": 185,
"author": {
"id": 9708
},
"writtenOn": "2024-04-04T13:54:19Z",
"side": 1,
"message": "How nova will signal the failure?\n\n* Will nova reject the start API request if the sharemapping state is not inactive?\n* Compared to the case when the mount fails on the compute side during start where the start API request already returned (the start_instance RPC is a cast). Will the instance be put into ERROR state or only the start instance action will be marked unsuccessful and the instance is set back to STOPPED?",
"revId": "8d5d8f050480e0f97fba27a7d9662f3fdb799a4d",
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
},
{
"unresolved": true,
"key": {
"uuid": "43cd7e33_71790df5",
"filename": "specs/2024.2/approved/libvirt-virtiofs-attach-manila-shares.rst",
"patchSetId": 1
},
"lineNbr": 302,
"author": {
"id": 9708
},
"writtenOn": "2024-04-04T13:54:19Z",
"side": 1,
"message": "is it the state of the sharemapping?",
"range": {
"startLine": 301,
"startChar": 52,
"endLine": 302,
"endChar": 13
},
"revId": "8d5d8f050480e0f97fba27a7d9662f3fdb799a4d",
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
},
{
"unresolved": true,
"key": {
"uuid": "35ce6233_49ab34ec",
"filename": "specs/2024.2/approved/libvirt-virtiofs-attach-manila-shares.rst",
"patchSetId": 1
},
"lineNbr": 356,
"author": {
"id": 9708
},
"writtenOn": "2024-04-04T13:54:19Z",
"side": 1,
"message": "is the the state of the sharemapping?",
"range": {
"startLine": 355,
"startChar": 50,
"endLine": 356,
"endChar": 10
},
"revId": "8d5d8f050480e0f97fba27a7d9662f3fdb799a4d",
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
},
{
"unresolved": true,
"key": {
"uuid": "b630af72_2cbb1856",
"filename": "specs/2024.2/approved/libvirt-virtiofs-attach-manila-shares.rst",
"patchSetId": 1
},
"lineNbr": 360,
"author": {
"id": 9708
},
"writtenOn": "2024-04-04T13:54:19Z",
"side": 1,
"message": "I think we can and should deny access to the share from the compute right after the share is unmounted during the VM shutdown.\n\nAlso I thought the check that the share is used by another instance on the same compute should be done before umount. Or do we mount the share to independent locations if multiple VMs using it on the same compute?",
"range": {
"startLine": 358,
"startChar": 0,
"endLine": 360,
"endChar": 55
},
"revId": "8d5d8f050480e0f97fba27a7d9662f3fdb799a4d",
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
},
{
"unresolved": true,
"key": {
"uuid": "dcafc470_cba274e1",
"filename": "specs/2024.2/approved/libvirt-virtiofs-attach-manila-shares.rst",
"patchSetId": 1
},
"lineNbr": 571,
"author": {
"id": 9708
},
"writtenOn": "2024-04-04T13:54:19Z",
"side": 1,
"message": "This is the diff between 2024.1 and 2024.2: https://paste.opendev.org/show/bkhDRGFhlBtXx5HPgG87/",
"revId": "8d5d8f050480e0f97fba27a7d9662f3fdb799a4d",
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
}
]
}