)]}'
{"id":"openstack%2Fglance-specs~763574","triplet_id":"openstack%2Fglance-specs~master~Ic467e8fab7c81d0b081c732ab0ea30f9765935ae","project":"openstack/glance-specs","branch":"master","topic":"distributed_image_import","hashtags":[],"change_id":"Ic467e8fab7c81d0b081c732ab0ea30f9765935ae","subject":"Distrbuted Image Import via request proxying","status":"ABANDONED","created":"2020-11-20 14:51:29.000000000","updated":"2021-02-04 14:13:56.000000000","total_comment_count":40,"unresolved_comment_count":25,"has_review_started":true,"meta_rev_id":"09bad1e911708ec8277bd01870f1bab14991f9ee","_number":763574,"virtual_id_number":763574,"owner":{"_account_id":5202,"name":"Erno Kuvaja","email":"jokke@usr.fi","username":"jokke"},"actions":{},"labels":{"Verified":{"recommended":{"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},"all":[{"_account_id":5314,"name":"Brian Rosmaita","email":"rosmaita.fossdev@gmail.com","username":"brian-rosmaita"},{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},{"tag":"autogenerated:zuul:check","value":1,"date":"2021-01-19 13:01:08.000000000","permitted_voting_range":{"min":-2,"max":2},"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]}],"values":{"-2":"Fails","-1":"Doesn\u0027t seem to work"," 0":"No score","+1":"Works for me","+2":"Verified"},"description":"","value":1,"default_value":0,"optional":true},"Code-Review":{"disliked":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"all":[{"value":0,"permitted_voting_range":{"min":-2,"max":2},"_account_id":5314,"name":"Brian Rosmaita","email":"rosmaita.fossdev@gmail.com","username":"brian-rosmaita"},{"value":-1,"date":"2021-01-21 17:31:00.000000000","permitted_voting_range":{"min":-2,"max":2},"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},{"value":0,"permitted_voting_range":{"min":-1,"max":1},"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]}],"values":{"-2":"Do not merge","-1":"This patch needs further work before it can be merged"," 0":"No score","+1":"Looks good to me, but someone else must approve","+2":"Looks good to me (core reviewer)"},"description":"","value":-1,"default_value":0,"optional":true},"Workflow":{"all":[{"_account_id":5314,"name":"Brian Rosmaita","email":"rosmaita.fossdev@gmail.com","username":"brian-rosmaita"},{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},{"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]}],"values":{"-1":"Work in progress"," 0":"Ready for reviews","+1":"Approved"},"description":"","default_value":0,"optional":true}},"removable_reviewers":[],"reviewers":{"REVIEWER":[{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},{"_account_id":5314,"name":"Brian Rosmaita","email":"rosmaita.fossdev@gmail.com","username":"brian-rosmaita"},{"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]}],"CC":[{"_account_id":9303,"name":"Abhishek Kekane","email":"akekane@redhat.com","username":"abhishekkekane"}]},"pending_reviewers":{},"reviewer_updates":[{"updated":"2020-11-23 15:10:08.000000000","updated_by":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"reviewer":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"state":"REVIEWER"},{"updated":"2020-12-10 13:43:02.000000000","updated_by":{"_account_id":5314,"name":"Brian Rosmaita","email":"rosmaita.fossdev@gmail.com","username":"brian-rosmaita"},"reviewer":{"_account_id":5314,"name":"Brian Rosmaita","email":"rosmaita.fossdev@gmail.com","username":"brian-rosmaita"},"state":"REVIEWER"},{"updated":"2021-01-12 14:52:59.000000000","updated_by":{"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},"reviewer":{"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},"state":"REVIEWER"},{"updated":"2021-01-22 14:15:21.000000000","updated_by":{"_account_id":9303,"name":"Abhishek Kekane","email":"akekane@redhat.com","username":"abhishekkekane"},"reviewer":{"_account_id":9303,"name":"Abhishek Kekane","email":"akekane@redhat.com","username":"abhishekkekane"},"state":"CC"}],"messages":[{"id":"15308e75e565522655b800dbe7ebd4677dedccd2","author":{"_account_id":5202,"name":"Erno Kuvaja","email":"jokke@usr.fi","username":"jokke"},"date":"2020-11-20 14:51:29.000000000","message":"Uploaded patch set 1.","accounts_in_message":[],"_revision_number":1},{"id":"ca4426e3370e0a9118df20e176ed457034bab5bb","author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"date":"2020-11-23 15:10:08.000000000","message":"Patch Set 1: Code-Review-1\n\n(21 comments)\n\nThanks for getting this going - I\u0027m looking forward to seeing and or helping with this in 2021 :)\n\nPersonally, I\u0027d like to see more detail in here to make sure we\u0027re all on the same page, and have something that power user operators can read to understand the design. I think what\u0027s here is probably too sparse for someone who doesn\u0027t know anything about these plans to connect the dots.\n\nMost of my comments are grammar nits, because I just can\u0027t help myself. Apologies in advance :)","accounts_in_message":[],"_revision_number":1},{"id":"fcd22805553c7628aa68bb29f2e53c38dd5ad61e","author":{"_account_id":5314,"name":"Brian Rosmaita","email":"rosmaita.fossdev@gmail.com","username":"brian-rosmaita"},"date":"2020-12-10 13:43:02.000000000","message":"Patch Set 1: Code-Review-1\n\n(4 comments)\n\nI agree with the spirit of the proposal, but Dan raises a lot of points that I\u0027d also like to see addressed.","accounts_in_message":[],"_revision_number":1},{"id":"3dae10d528597f90a0b465502d63f17eb3d17389","author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"date":"2021-01-05 19:08:04.000000000","message":"Patch Set 1:\n\n(1 comment)","accounts_in_message":[],"_revision_number":1},{"id":"eec93698d000cb4c8f5e6450dc8058911db3485d","tag":"autogenerated:gerrit:newPatchSet","author":{"_account_id":5202,"name":"Erno Kuvaja","email":"jokke@usr.fi","username":"jokke"},"date":"2021-01-12 14:37:40.000000000","message":"Uploaded patch set 2.","accounts_in_message":[],"_revision_number":2},{"id":"159cb0a5e78579b2158b86e9bfe0efc036b54e99","tag":"autogenerated:zuul:check","author":{"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},"date":"2021-01-12 14:52:59.000000000","message":"Patch Set 2: Verified+1\n\nBuild succeeded (check pipeline).\n\n- openstack-tox-docs https://zuul.opendev.org/t/openstack/build/0b8e73af059641c2a025bcf9fb40e109 : SUCCESS in 6m 07s","accounts_in_message":[],"_revision_number":2},{"id":"d388378bbac4081131654d47ff88f5462e357173","author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"date":"2021-01-12 17:02:41.000000000","message":"Patch Set 2: Code-Review-1\n\n(3 comments)","accounts_in_message":[],"_revision_number":2},{"id":"8cd606fe59d1c376943a5b7423fc79ce4c9fed1c","author":{"_account_id":5202,"name":"Erno Kuvaja","email":"jokke@usr.fi","username":"jokke"},"date":"2021-01-12 22:32:22.000000000","message":"Patch Set 2:\n\n(2 comments)","accounts_in_message":[],"_revision_number":2},{"id":"ec43a8bdec108422c3aac5ed122fc02cfadef17c","author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"date":"2021-01-12 22:52:34.000000000","message":"Patch Set 2:\n\n(2 comments)\n\nI\u0027ll defer to Brian and Abhi on whether or not the location is the right place to store it. It seems like just a transient piece of data we need to stash temporarily to me...","accounts_in_message":[],"_revision_number":2},{"id":"4ba53aa4ecdc64746acb58dbf6aaecca479813a7","tag":"autogenerated:gerrit:newPatchSet","author":{"_account_id":5202,"name":"Erno Kuvaja","email":"jokke@usr.fi","username":"jokke"},"date":"2021-01-19 12:39:09.000000000","message":"Uploaded patch set 3.","accounts_in_message":[],"_revision_number":3},{"id":"0efe3578839b2e8602745c870b8e6596582217bd","author":{"_account_id":5202,"name":"Erno Kuvaja","email":"jokke@usr.fi","username":"jokke"},"date":"2021-01-19 12:39:31.000000000","message":"Patch Set 3:\n\n(2 comments)","accounts_in_message":[],"_revision_number":3},{"id":"bf9685e15656ca9c97ceaedc9a1ed26ddb6daf8c","author":{"_account_id":5202,"name":"Erno Kuvaja","email":"jokke@usr.fi","username":"jokke"},"date":"2021-01-19 12:41:31.000000000","message":"Patch Set 3:\n\n(1 comment)","accounts_in_message":[],"_revision_number":3},{"id":"4c8dcba5d6b972cc218623d78dc11a05699c703e","tag":"autogenerated:zuul:check","author":{"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},"date":"2021-01-19 13:01:08.000000000","message":"Patch Set 3: Verified+1\n\nBuild succeeded (check pipeline).\n\n- openstack-tox-docs https://zuul.opendev.org/t/openstack/build/ae76cab17c4c432583cc18bbb1ec23d4 : SUCCESS in 4m 32s","accounts_in_message":[],"_revision_number":3},{"id":"4acb341e81c64b6aec0445c2e639416619a0ca91","author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"date":"2021-01-21 17:31:00.000000000","message":"Patch Set 3: Code-Review-1\n\n(4 comments)\n\nI\u0027m still -1 on the location based approach until I understand why. Apologies if I\u0027m being daft, but hopefully we can have some other voices in here soon to help push this one way or the other.","accounts_in_message":[],"_revision_number":3},{"id":"a61b38a2591326186f8939789f8e5ff8b189b3fc","author":{"_account_id":9303,"name":"Abhishek Kekane","email":"akekane@redhat.com","username":"abhishekkekane"},"date":"2021-01-22 14:15:21.000000000","message":"Patch Set 3:\n\nI am also thinking adding staging_host as a reserved property will be much easier than adding it to location table;\n1. because we generate location url once data is fully uploaded to backend\n2. once import is complete we delete the data from staging area and then we need to set it to null/none if we added it to location table\n3. We can restrict creation/update of reserved properties (os_glance_*) by which we don\u0027t need to worry about restrictions at CRUD level\n\nBut we also need to make sure that in case of failure while reverting if staging data is deleted then we should delete that reserved property as well.","accounts_in_message":[],"_revision_number":3},{"id":"292d103e616e929638874824e6768bdd799ee6a2","author":{"_account_id":5314,"name":"Brian Rosmaita","email":"rosmaita.fossdev@gmail.com","username":"brian-rosmaita"},"date":"2021-01-22 22:14:12.000000000","message":"Patch Set 3:\n\nI like the overall direction of the spec, namely that the node that receives staged data records itself in the Image object, and when the import is requested, the request gets forwarded to the node that has the data.  As far as where the node url goes, my intuition is that we should only use the locations for \"real\" image data, and using an image property (like we\u0027re doing for the task lock) seems like it fits the purpose.\n\nErno, if you feel strongly about storing the node url in the image locations, let\u0027s set up a quick videoconf among the Glance team so you can explain your thinking.  There may be a point here that we\u0027re missing that hasn\u0027t quite come through in the spec text.","accounts_in_message":[],"_revision_number":3},{"id":"734f9c4eb2b7017baafe453463079b2850f74f57","author":{"_account_id":9303,"name":"Abhishek Kekane","email":"akekane@redhat.com","username":"abhishekkekane"},"date":"2021-01-27 05:27:11.000000000","message":"Patch Set 3:\n\nAfter going through specs I found couple of benefits of storing staging_host in locations table;\n\n1. We should create location entry for staging data with valid location url and setting is_active false which will help us to get rid of dodgy code which we use to load staging store on the fly and delete the staging data, instead we could use locations.pop call(url) which will help us to delete staging data as well. \n\n2. We could use same redirection mechanism to redirect delete image call to the api node where staging data is present, this we could achieve with reserved property approach as well, but if the said glance node is down for maintenance then we don\u0027t have any way to make sure that staging data is deleted but with the help of entry in locations table we have track that there is data present somewhere.\n\nInstead of adding new column to locations table we could add this information as a location metadata and we could also hide this staging data information from displaying to end user.\n\nSo the reserved property approach is easy one and the approach mentioned in this specs is trickier but help us to improve and reuse the glance-store code.","accounts_in_message":[],"_revision_number":3},{"id":"003123791ed8715c1c32071aea38695ae2b10bdc","author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"date":"2021-01-27 15:03:14.000000000","message":"Patch Set 3:\n\n\u003e 1. We should create location entry for staging data with valid location url and setting is_active false which will help us to get rid of dodgy code which we use to load staging store on the fly and delete the staging data, instead we could use locations.pop call(url) which will help us to delete staging data as well. \n\nI don\u0027t understand what benefit this has. Can you explain more?\n\n\u003e 2. We could use same redirection mechanism to redirect delete image call to the api node where staging data is present, this we could achieve with reserved property approach as well, but if the said glance node is down for maintenance then we don\u0027t have any way to make sure that staging data is deleted but with the help of entry in locations table we have track that there is data present somewhere.\n\nI\u0027m already doing this with my property-based implementation, as you note. AFAICT, this is exactly the same with the property approach - we can still harvest that after image delete if we want right? Either way, glance-api already needs to examine its staging store on startup and delete any residue there right? A failed import that was in progress at power fail time, or presumably any failure that happened across a DB cleanup boundary.\n\n\u003e Instead of adding new column to locations table we could add this information as a location metadata and we could also hide this staging data information from displaying to end user.\n\u003e \n\u003e So the reserved property approach is easy one and the approach mentioned in this specs is trickier but help us to improve and reuse the glance-store code.\n\nCan you point specifically to what actually gets reused? It sounds like more change will be needed with this approach, but perhaps I\u0027m missing some store routines that will save massive amounts of time.\n\nIs there any harm in moving forward with the known-to-be-working simple approach, given where we are in the cycle, and then someone following up with a patch to use the store instead? That would give us a way to examine just the delta between the two. If not, I\u0027d still propose that the patch be added on top of mine to show the differences, even if we squash them later.\n\nGetting this fixed in a workable way seems to have been dragging for many releases at this point. I\u0027d hate to see a working implementation further delayed here, as it has already been thus far.","accounts_in_message":[],"_revision_number":3},{"id":"eea14fbf76c1d62968ea091356cd07e6f4866547","author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"date":"2021-01-27 19:57:01.000000000","message":"Patch Set 3:\n\n\u003e I\u0027m already doing this with my property-based implementation, as you note. AFAICT, this is exactly the same with the property approach - we can still harvest that after image delete if we want right? Either way, glance-api already needs to examine its staging store on startup and delete any residue there right? A failed import that was in progress at power fail time, or presumably any failure that happened across a DB cleanup boundary.\n\nI just confirmed using this (and without my patch which proxies delete):\n\nhttps://review.opendev.org/c/openstack/devstack/+/770487\n\nThat if I stage against one worker and delete on the other, it\u0027ll just leave residue in the staging store. So, I think unrelated to whatever we decide here, glance workers should be cleaning (probably at least on startup) their staging repository if they find files there that are related to deleted images, yeah?","accounts_in_message":[],"_revision_number":3},{"id":"8c4761500c48324a37fb1635947b396135002779","author":{"_account_id":9303,"name":"Abhishek Kekane","email":"akekane@redhat.com","username":"abhishekkekane"},"date":"2021-01-28 05:34:23.000000000","message":"Patch Set 3:\n\n\u003e Patch Set 3:\n\u003e \n\u003e \u003e 1. We should create location entry for staging data with valid location url and setting is_active false which will help us to get rid of dodgy code which we use to load staging store on the fly and delete the staging data, instead we could use locations.pop call(url) which will help us to delete staging data as well. \n\u003e \n\u003e I don\u0027t understand what benefit this has. Can you explain more?\n\nI was talking about this call [1]. If you add location entry of staged data then you could use this call which internally uses glance-store code to delete the data from the backend, whereas at the moment we are using [2] to delete the staged data in which we are either using os calls to clear the data or creating location url manually then fetching the store object with that and calling delete method of store.\n\n[1] https://github.com/openstack/glance/blob/master/glance/location.py#L235\n[2] https://github.com/openstack/glance/blob/master/glance/api/v2/image_data.py#L80\n\n\n\u003e \n\u003e \u003e 2. We could use same redirection mechanism to redirect delete image call to the api node where staging data is present, this we could achieve with reserved property approach as well, but if the said glance node is down for maintenance then we don\u0027t have any way to make sure that staging data is deleted but with the help of entry in locations table we have track that there is data present somewhere.\n\u003e \n\u003e I\u0027m already doing this with my property-based implementation, as you note. AFAICT, this is exactly the same with the property approach - we can still harvest that after image delete if we want right? Either way, glance-api already needs to examine its staging store on startup and delete any residue there right? A failed import that was in progress at power fail time, or presumably any failure that happened across a DB cleanup boundary.\n\u003e \n\u003e \u003e Instead of adding new column to locations table we could add this information as a location metadata and we could also hide this staging data information from displaying to end user.\n\u003e \u003e \n\u003e \u003e So the reserved property approach is easy one and the approach mentioned in this specs is trickier but help us to improve and reuse the glance-store code.\n\u003e \n\u003e Can you point specifically to what actually gets reused? It sounds like more change will be needed with this approach, but perhaps I\u0027m missing some store routines that will save massive amounts of time.\n\u003e \n\u003e Is there any harm in moving forward with the known-to-be-working simple approach, given where we are in the cycle, and then someone following up with a patch to use the store instead? That would give us a way to examine just the delta between the two. If not, I\u0027d still propose that the patch be added on top of mine to show the differences, even if we squash them later.\n\u003e \n\u003e Getting this fixed in a workable way seems to have been dragging for many releases at this point. I\u0027d hate to see a working implementation further delayed here, as it has already been thus far.\n\nI am open to move forward with reserved property approach and then in Xena revisiting the same and do it using the locations way.","accounts_in_message":[],"_revision_number":3},{"id":"09bad1e911708ec8277bd01870f1bab14991f9ee","tag":"autogenerated:gerrit:abandon","author":{"_account_id":5202,"name":"Erno Kuvaja","email":"jokke@usr.fi","username":"jokke"},"date":"2021-02-04 14:13:56.000000000","message":"Abandoned","accounts_in_message":[],"_revision_number":3}],"current_revision_number":3,"current_revision":"a6a285bc5015b53febc4a755b76cdae213c73924","revisions":{"b54c1f37b587cceba677a18c4bdbd752b1de32cd":{"kind":"REWORK","_number":1,"created":"2020-11-20 14:51:29.000000000","uploader":{"_account_id":5202,"name":"Erno Kuvaja","email":"jokke@usr.fi","username":"jokke"},"ref":"refs/changes/74/763574/1","fetch":{"anonymous http":{"url":"https://review.opendev.org/openstack/glance-specs","ref":"refs/changes/74/763574/1","commands":{"Checkout":"git fetch https://review.opendev.org/openstack/glance-specs refs/changes/74/763574/1 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.opendev.org/openstack/glance-specs refs/changes/74/763574/1 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.opendev.org/openstack/glance-specs refs/changes/74/763574/1 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.opendev.org/openstack/glance-specs refs/changes/74/763574/1"}}},"commit":{"parents":[{"commit":"d7bbf477959c0bd02f94f4896bc3f224cd313e34","subject":"Create specs directory for Wallaby cycle","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/glance-specs/commit/d7bbf477959c0bd02f94f4896bc3f224cd313e34"}]}],"author":{"name":"Erno Kuvaja","email":"jokke@usr.fi","date":"2020-11-20 14:42:08.000000000","tz":0},"committer":{"name":"Erno Kuvaja","email":"jokke@usr.fi","date":"2020-11-20 14:49:26.000000000","tz":0},"subject":"Distrbuted Image Import via request proxying","message":"Distrbuted Image Import via request proxying\n\nThis spec is split of section from\nhttps://review.opendev.org/#/c/664956/ to specifically\naddress the Interoperable Image Import: glance-direct\nneeds.\n\nChange-Id: Ic467e8fab7c81d0b081c732ab0ea30f9765935ae\n","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/glance-specs/commit/b54c1f37b587cceba677a18c4bdbd752b1de32cd"}],"resolve_conflicts_web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/glance-specs/commit/b54c1f37b587cceba677a18c4bdbd752b1de32cd"}]},"branch":"refs/heads/master"},"5fc98dc86e53f9c0c885767a7918dc48fa10fb5a":{"kind":"REWORK","_number":2,"created":"2021-01-12 14:37:40.000000000","uploader":{"_account_id":5202,"name":"Erno Kuvaja","email":"jokke@usr.fi","username":"jokke"},"ref":"refs/changes/74/763574/2","fetch":{"anonymous http":{"url":"https://review.opendev.org/openstack/glance-specs","ref":"refs/changes/74/763574/2","commands":{"Checkout":"git fetch https://review.opendev.org/openstack/glance-specs refs/changes/74/763574/2 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.opendev.org/openstack/glance-specs refs/changes/74/763574/2 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.opendev.org/openstack/glance-specs refs/changes/74/763574/2 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.opendev.org/openstack/glance-specs refs/changes/74/763574/2"}}},"commit":{"parents":[{"commit":"d7bbf477959c0bd02f94f4896bc3f224cd313e34","subject":"Create specs directory for Wallaby cycle","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/glance-specs/commit/d7bbf477959c0bd02f94f4896bc3f224cd313e34"}]}],"author":{"name":"Erno Kuvaja","email":"jokke@usr.fi","date":"2020-11-20 14:42:08.000000000","tz":0},"committer":{"name":"Erno Kuvaja","email":"jokke@usr.fi","date":"2021-01-12 14:33:24.000000000","tz":0},"subject":"Distrbuted Image Import via request proxying","message":"Distrbuted Image Import via request proxying\n\nThis spec is split of section from\nhttps://review.opendev.org/#/c/664956/ to specifically\naddress the Interoperable Image Import: glance-direct\nneeds.\n\nChange-Id: Ic467e8fab7c81d0b081c732ab0ea30f9765935ae\n","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/glance-specs/commit/5fc98dc86e53f9c0c885767a7918dc48fa10fb5a"}],"resolve_conflicts_web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/glance-specs/commit/5fc98dc86e53f9c0c885767a7918dc48fa10fb5a"}]},"branch":"refs/heads/master"},"a6a285bc5015b53febc4a755b76cdae213c73924":{"kind":"REWORK","_number":3,"created":"2021-01-19 12:39:09.000000000","uploader":{"_account_id":5202,"name":"Erno Kuvaja","email":"jokke@usr.fi","username":"jokke"},"ref":"refs/changes/74/763574/3","fetch":{"anonymous http":{"url":"https://review.opendev.org/openstack/glance-specs","ref":"refs/changes/74/763574/3","commands":{"Checkout":"git fetch https://review.opendev.org/openstack/glance-specs refs/changes/74/763574/3 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.opendev.org/openstack/glance-specs refs/changes/74/763574/3 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.opendev.org/openstack/glance-specs refs/changes/74/763574/3 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.opendev.org/openstack/glance-specs refs/changes/74/763574/3"}}},"commit":{"parents":[{"commit":"6de8257026039e7cc71afea65d459a00beea0f85","subject":"Fix redirects","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/glance-specs/commit/6de8257026039e7cc71afea65d459a00beea0f85"}]}],"author":{"name":"Erno Kuvaja","email":"jokke@usr.fi","date":"2020-11-20 14:42:08.000000000","tz":0},"committer":{"name":"Erno Kuvaja","email":"jokke@usr.fi","date":"2021-01-19 12:38:53.000000000","tz":0},"subject":"Distrbuted Image Import via request proxying","message":"Distrbuted Image Import via request proxying\n\nThis spec is split of section from\nhttps://review.opendev.org/#/c/664956/ to specifically\naddress the Interoperable Image Import: glance-direct\nneeds.\n\nChange-Id: Ic467e8fab7c81d0b081c732ab0ea30f9765935ae\n","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/glance-specs/commit/a6a285bc5015b53febc4a755b76cdae213c73924"}],"resolve_conflicts_web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/glance-specs/commit/a6a285bc5015b53febc4a755b76cdae213c73924"}]},"branch":"refs/heads/master"}},"requirements":[],"submit_records":[],"submit_requirements":[]}