Update patch set 7

Patch Set 7:

(7 comments)

Patch-set: 7
Attention: {"person_ident":"Gerrit User 4393 \u003c4393@4a232e18-c5a9-48ee-94c0-e04e7cca6543\u003e","operation":"REMOVE","reason":"\u003cGERRIT_ACCOUNT_4393\u003e replied on the change"}
Attention: {"person_ident":"Gerrit User 4690 \u003c4690@4a232e18-c5a9-48ee-94c0-e04e7cca6543\u003e","operation":"ADD","reason":"\u003cGERRIT_ACCOUNT_4393\u003e replied on the change"}
This commit is contained in:
Gerrit User 4393 2024-03-28 18:28:18 +00:00 committed by Gerrit Code Review
parent 75e88677a3
commit 95582f71d3
1 changed files with 126 additions and 0 deletions

View File

@ -244,6 +244,24 @@
"revId": "6940b7f76b9e415fd0ab75cbea9c0b001a68272a",
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
},
{
"unresolved": true,
"key": {
"uuid": "9130ba67_29576256",
"filename": "specs/2024.2/approved/ephemeral-storage-encryption.rst",
"patchSetId": 7
},
"lineNbr": 260,
"author": {
"id": 4393
},
"writtenOn": "2024-03-28T18:28:18Z",
"side": 1,
"message": "Aha, I see. So the answer to the question of who we\u0027re going to charge is \"everyone.\" So the secret for the base image will be duplicated for everyone that uses it. If the user goes into barbican and says \"wtf, this isn\u0027t mine\" and deletes it, they will effectively break their instance\u0027s ability to reboot, and likely end up with data loss right? Or maybe a migration will fix it I guess, since we don\u0027t send the base image and would re-download/re-construct it on the destination?\n\nNot sure where I asked but I don\u0027t think I saw an answer... What indication does the user have in barbican what each thing is for? They can see the consumer, which we\u0027re setting to something right? Just trying to think about how we can make this not a foot gun.",
"parentUuid": "4c2915d4_64199dff",
"revId": "6940b7f76b9e415fd0ab75cbea9c0b001a68272a",
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
},
{
"unresolved": true,
"key": {
@ -315,6 +333,24 @@
"revId": "6940b7f76b9e415fd0ab75cbea9c0b001a68272a",
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
},
{
"unresolved": true,
"key": {
"uuid": "a92299e5_a2382c07",
"filename": "specs/2024.2/approved/ephemeral-storage-encryption.rst",
"patchSetId": 7
},
"lineNbr": 280,
"author": {
"id": 4393
},
"writtenOn": "2024-03-28T18:28:18Z",
"side": 1,
"message": "Yep, just MHO\u0027ing. Maybe we can get some feedback from others.",
"parentUuid": "8747c928_4433dd4b",
"revId": "6940b7f76b9e415fd0ab75cbea9c0b001a68272a",
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
},
{
"unresolved": true,
"key": {
@ -491,6 +527,24 @@
"revId": "6940b7f76b9e415fd0ab75cbea9c0b001a68272a",
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
},
{
"unresolved": false,
"key": {
"uuid": "5a87d834_9352f152",
"filename": "specs/2024.2/approved/ephemeral-storage-encryption.rst",
"patchSetId": 7
},
"lineNbr": 317,
"author": {
"id": 4393
},
"writtenOn": "2024-03-28T18:28:18Z",
"side": 1,
"message": "Acknowledged",
"parentUuid": "38fa7986_5d886567",
"revId": "6940b7f76b9e415fd0ab75cbea9c0b001a68272a",
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
},
{
"unresolved": true,
"key": {
@ -631,6 +685,24 @@
"revId": "6940b7f76b9e415fd0ab75cbea9c0b001a68272a",
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
},
{
"unresolved": false,
"key": {
"uuid": "129354ca_6335c02e",
"filename": "specs/2024.2/approved/ephemeral-storage-encryption.rst",
"patchSetId": 7
},
"lineNbr": 441,
"author": {
"id": 4393
},
"writtenOn": "2024-03-28T18:28:18Z",
"side": 1,
"message": "Acknowledged",
"parentUuid": "85ea9e7c_bcfdb7e5",
"revId": "6940b7f76b9e415fd0ab75cbea9c0b001a68272a",
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
},
{
"unresolved": true,
"key": {
@ -842,6 +914,24 @@
"revId": "6940b7f76b9e415fd0ab75cbea9c0b001a68272a",
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
},
{
"unresolved": true,
"key": {
"uuid": "8bf5e820_45864935",
"filename": "specs/2024.2/approved/ephemeral-storage-encryption.rst",
"patchSetId": 7
},
"lineNbr": 591,
"author": {
"id": 4393
},
"writtenOn": "2024-03-28T18:28:18Z",
"side": 1,
"message": "Yeah, sorry I was just trying to make a point, but I *did* say the `image_` one. What I meant was the unfortunate proliferation of all the various prefixes we\u0027ll get there, which I detailed above by saying:\n\n\u003e {rescue,image,shelve,migrate}_ephemeral_encryption_{secret_uuid,format}_{root,swap,ephemeral}\n\nBut should have linked with one of the new prefixes here for clarity, sorry.",
"parentUuid": "7a7a2833_2f97c351",
"revId": "6940b7f76b9e415fd0ab75cbea9c0b001a68272a",
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
},
{
"unresolved": true,
"key": {
@ -913,6 +1003,24 @@
"revId": "6940b7f76b9e415fd0ab75cbea9c0b001a68272a",
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
},
{
"unresolved": true,
"key": {
"uuid": "4b2d2a54_b7edfb1c",
"filename": "specs/2024.2/approved/ephemeral-storage-encryption.rst",
"patchSetId": 7
},
"lineNbr": 615,
"author": {
"id": 4393
},
"writtenOn": "2024-03-28T18:28:18Z",
"side": 1,
"message": "My suggestion is what I said above, that we should enumerate the allowed values right now and object if we see any that we don\u0027t know about. That could be done by making this *not* an unversioned dict, or with just some sanity checking when we load/traverse them.\n\nThe rest of what I\u0027m saying is just that I think we need to consider both the migrate and upgrade cases and not just punt until later. For example, if I enable FIPS on my host and reboot, a bunch of ciphers that were allowed before are suddenly not available in the libraries below us. It would certainly be unfortunate if the only way we report that to the operator is \"qemu failed to start\" or worse, qemu starting but the instance doesn\u0027t boot because we can\u0027t read the disk. That probably won\u0027t happen for a while for the defaults we\u0027re going to choose here, but because it results in unreadable disks, I think it\u0027s worth the extra diligence.\n\nSimilarly, I think the recent spate of live migration-with-* features have left us with situations where we have to add a bunch of info to the migration objects later to enable such migration, because we don\u0027t know what is supported. Maybe that\u0027s not as big of a deal in this case because the actual attributes we\u0027re worried about are stored in the DB, and we could abort during a pre migrate phase on either end. But, having the \"this is the list of cipher/format/keysize/etc\" in a list makes it easy to just go ahead and check for that in those kinds of places. I do think that re-encrypting the disk if we resize to a different setup is what the user will expect, but we\u0027ll probably need a way for the destination to tell us what it requires, which goes back to the enum thing.",
"parentUuid": "b5fe6095_de85ec87",
"revId": "6940b7f76b9e415fd0ab75cbea9c0b001a68272a",
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
},
{
"unresolved": true,
"key": {
@ -1072,6 +1180,24 @@
"revId": "6940b7f76b9e415fd0ab75cbea9c0b001a68272a",
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
},
{
"unresolved": true,
"key": {
"uuid": "7bf42818_330b68a8",
"filename": "specs/2024.2/approved/ephemeral-storage-encryption.rst",
"patchSetId": 7
},
"lineNbr": 785,
"author": {
"id": 4393
},
"writtenOn": "2024-03-28T18:28:18Z",
"side": 1,
"message": "Yeah, understand, and not having another format helps this be an obvious place to limit the initial scope. My point is that we really already have two formats, luks and none, so the problem isn\u0027t just a future one.\n\nGiven the potential that after this series is merged we don\u0027t come back and fill in these details, it does become one of those things where \"oh that diagonal cross section of features don\u0027t work when X is enabled\" and resize being out of scope is a bummer, that\u0027s all.",
"parentUuid": "9061ca0d_c49132c9",
"revId": "6940b7f76b9e415fd0ab75cbea9c0b001a68272a",
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
},
{
"unresolved": true,
"key": {