)]}'
{"specs/wallaby/approved/glance/distributed-image-import.rst":[{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"ca4426e3370e0a9118df20e176ed457034bab5bb","unresolved":true,"context_lines":[{"line_number":12,"context_line":""},{"line_number":13,"context_line":"https://blueprints.launchpad.net/glance/+spec/cluster-awareness"},{"line_number":14,"context_line":""},{"line_number":15,"context_line":"With Interoperable Image Import and new edge usecases introducing asynchronous"},{"line_number":16,"context_line":"tasks we cannot expect users always hitting the specific node where data is"},{"line_number":17,"context_line":"located or that needs to do the work. Thus it\u0027s essential that we implement a"},{"line_number":18,"context_line":"way for the glance-api nodes to communicate with eachother and provide the"}],"source_content_type":"text/x-rst","patch_set":1,"id":"e68528cd_99597056","line":15,"range":{"start_line":15,"start_character":45,"end_line":15,"end_character":53},"updated":"2020-11-23 15:10:08.000000000","message":"use-cases","commit_id":"b54c1f37b587cceba677a18c4bdbd752b1de32cd"},{"author":{"_account_id":5314,"name":"Brian Rosmaita","email":"rosmaita.fossdev@gmail.com","username":"brian-rosmaita"},"change_message_id":"fcd22805553c7628aa68bb29f2e53c38dd5ad61e","unresolved":true,"context_lines":[{"line_number":12,"context_line":""},{"line_number":13,"context_line":"https://blueprints.launchpad.net/glance/+spec/cluster-awareness"},{"line_number":14,"context_line":""},{"line_number":15,"context_line":"With Interoperable Image Import and new edge usecases introducing asynchronous"},{"line_number":16,"context_line":"tasks we cannot expect users always hitting the specific node where data is"},{"line_number":17,"context_line":"located or that needs to do the work. Thus it\u0027s essential that we implement a"},{"line_number":18,"context_line":"way for the glance-api nodes to communicate with eachother and provide the"}],"source_content_type":"text/x-rst","patch_set":1,"id":"b186e313_4be8b823","line":15,"range":{"start_line":15,"start_character":45,"end_line":15,"end_character":53},"in_reply_to":"e68528cd_99597056","updated":"2020-12-10 13:43:02.000000000","message":"or \"use cases\"","commit_id":"b54c1f37b587cceba677a18c4bdbd752b1de32cd"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"ca4426e3370e0a9118df20e176ed457034bab5bb","unresolved":true,"context_lines":[{"line_number":13,"context_line":"https://blueprints.launchpad.net/glance/+spec/cluster-awareness"},{"line_number":14,"context_line":""},{"line_number":15,"context_line":"With Interoperable Image Import and new edge usecases introducing asynchronous"},{"line_number":16,"context_line":"tasks we cannot expect users always hitting the specific node where data is"},{"line_number":17,"context_line":"located or that needs to do the work. Thus it\u0027s essential that we implement a"},{"line_number":18,"context_line":"way for the glance-api nodes to communicate with eachother and provide the"},{"line_number":19,"context_line":"request to the correct worker."}],"source_content_type":"text/x-rst","patch_set":1,"id":"6b4a1182_d3b6b78f","line":16,"range":{"start_line":16,"start_character":23,"end_line":16,"end_character":43},"updated":"2020-11-23 15:10:08.000000000","message":"\"user HTTP requests to always hit\"","commit_id":"b54c1f37b587cceba677a18c4bdbd752b1de32cd"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"ca4426e3370e0a9118df20e176ed457034bab5bb","unresolved":true,"context_lines":[{"line_number":15,"context_line":"With Interoperable Image Import and new edge usecases introducing asynchronous"},{"line_number":16,"context_line":"tasks we cannot expect users always hitting the specific node where data is"},{"line_number":17,"context_line":"located or that needs to do the work. Thus it\u0027s essential that we implement a"},{"line_number":18,"context_line":"way for the glance-api nodes to communicate with eachother and provide the"},{"line_number":19,"context_line":"request to the correct worker."},{"line_number":20,"context_line":""},{"line_number":21,"context_line":"This proposal is now split to two parts. Where the Interoperable Image Import"}],"source_content_type":"text/x-rst","patch_set":1,"id":"f52e8c41_1fc85f30","line":18,"range":{"start_line":18,"start_character":49,"end_line":18,"end_character":58},"updated":"2020-11-23 15:10:08.000000000","message":"\"each other\"","commit_id":"b54c1f37b587cceba677a18c4bdbd752b1de32cd"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"ca4426e3370e0a9118df20e176ed457034bab5bb","unresolved":true,"context_lines":[{"line_number":15,"context_line":"With Interoperable Image Import and new edge usecases introducing asynchronous"},{"line_number":16,"context_line":"tasks we cannot expect users always hitting the specific node where data is"},{"line_number":17,"context_line":"located or that needs to do the work. Thus it\u0027s essential that we implement a"},{"line_number":18,"context_line":"way for the glance-api nodes to communicate with eachother and provide the"},{"line_number":19,"context_line":"request to the correct worker."},{"line_number":20,"context_line":""},{"line_number":21,"context_line":"This proposal is now split to two parts. Where the Interoperable Image Import"}],"source_content_type":"text/x-rst","patch_set":1,"id":"fdf015bb_1b7f9e6c","line":18,"range":{"start_line":18,"start_character":63,"end_line":18,"end_character":70},"updated":"2020-11-23 15:10:08.000000000","message":"I would say \"direct\" or \"forward\". The _user_ is \"providing\" the request.","commit_id":"b54c1f37b587cceba677a18c4bdbd752b1de32cd"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"ca4426e3370e0a9118df20e176ed457034bab5bb","unresolved":true,"context_lines":[{"line_number":26,"context_line":"Problem description"},{"line_number":27,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":28,"context_line":""},{"line_number":29,"context_line":"Glance local is good example of image-import call that will currently require"},{"line_number":30,"context_line":"the import call to be received by the node that has access to the data, either"},{"line_number":31,"context_line":"via shared filesystem or the data being local on the node receiving the call."},{"line_number":32,"context_line":"We cannot expect this to be te case long term and specially not when Edge is"}],"source_content_type":"text/x-rst","patch_set":1,"id":"a239054c_bbbd09b7","line":29,"range":{"start_line":29,"start_character":0,"end_line":29,"end_character":12},"updated":"2020-11-23 15:10:08.000000000","message":"Are you referring to the glance-direct import method?","commit_id":"b54c1f37b587cceba677a18c4bdbd752b1de32cd"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"ca4426e3370e0a9118df20e176ed457034bab5bb","unresolved":true,"context_lines":[{"line_number":29,"context_line":"Glance local is good example of image-import call that will currently require"},{"line_number":30,"context_line":"the import call to be received by the node that has access to the data, either"},{"line_number":31,"context_line":"via shared filesystem or the data being local on the node receiving the call."},{"line_number":32,"context_line":"We cannot expect this to be te case long term and specially not when Edge is"},{"line_number":33,"context_line":"bringing new challenges with geographically distributed nodes. We need to have"},{"line_number":34,"context_line":"a mechanism to reroute the requests to the nodes that are actually able to"},{"line_number":35,"context_line":"process them."}],"source_content_type":"text/x-rst","patch_set":1,"id":"f84de301_0144ac58","line":32,"range":{"start_line":32,"start_character":50,"end_line":32,"end_character":59},"updated":"2020-11-23 15:10:08.000000000","message":"\"especially\"","commit_id":"b54c1f37b587cceba677a18c4bdbd752b1de32cd"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"ca4426e3370e0a9118df20e176ed457034bab5bb","unresolved":true,"context_lines":[{"line_number":29,"context_line":"Glance local is good example of image-import call that will currently require"},{"line_number":30,"context_line":"the import call to be received by the node that has access to the data, either"},{"line_number":31,"context_line":"via shared filesystem or the data being local on the node receiving the call."},{"line_number":32,"context_line":"We cannot expect this to be te case long term and specially not when Edge is"},{"line_number":33,"context_line":"bringing new challenges with geographically distributed nodes. We need to have"},{"line_number":34,"context_line":"a mechanism to reroute the requests to the nodes that are actually able to"},{"line_number":35,"context_line":"process them."}],"source_content_type":"text/x-rst","patch_set":1,"id":"d84ce5f5_8e6c8672","line":32,"range":{"start_line":32,"start_character":28,"end_line":32,"end_character":30},"updated":"2020-11-23 15:10:08.000000000","message":"\"the\"","commit_id":"b54c1f37b587cceba677a18c4bdbd752b1de32cd"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"ca4426e3370e0a9118df20e176ed457034bab5bb","unresolved":true,"context_lines":[{"line_number":35,"context_line":"process them."},{"line_number":36,"context_line":""},{"line_number":37,"context_line":"Another set of problems that are introduced by distributed nodes is how do we"},{"line_number":38,"context_line":"provide best possible user experience to avoid users needing to explicitely"},{"line_number":39,"context_line":"select node for specific request (say initiating image precaching or"},{"line_number":40,"context_line":"image data migration between stores)."},{"line_number":41,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"efe4727d_2450a87b","line":38,"range":{"start_line":38,"start_character":64,"end_line":38,"end_character":75},"updated":"2020-11-23 15:10:08.000000000","message":"\"explicitly\"","commit_id":"b54c1f37b587cceba677a18c4bdbd752b1de32cd"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"ca4426e3370e0a9118df20e176ed457034bab5bb","unresolved":true,"context_lines":[{"line_number":36,"context_line":""},{"line_number":37,"context_line":"Another set of problems that are introduced by distributed nodes is how do we"},{"line_number":38,"context_line":"provide best possible user experience to avoid users needing to explicitely"},{"line_number":39,"context_line":"select node for specific request (say initiating image precaching or"},{"line_number":40,"context_line":"image data migration between stores)."},{"line_number":41,"context_line":""},{"line_number":42,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"eb1d0e98_403db943","line":39,"range":{"start_line":39,"start_character":0,"end_line":39,"end_character":15},"updated":"2020-11-23 15:10:08.000000000","message":"\"select a node for a\"","commit_id":"b54c1f37b587cceba677a18c4bdbd752b1de32cd"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"ca4426e3370e0a9118df20e176ed457034bab5bb","unresolved":true,"context_lines":[{"line_number":45,"context_line":""},{"line_number":46,"context_line":"As discussed in the Wallaby PTG it might make more sense to record which node"},{"line_number":47,"context_line":"has staged the data and just proxy the http-request for import to that node"},{"line_number":48,"context_line":"instead of do all this fanout dance with Rabbit and put the extra load on the"},{"line_number":49,"context_line":"system."},{"line_number":50,"context_line":""},{"line_number":51,"context_line":"This approach will require additional expanding migration to our database and"}],"source_content_type":"text/x-rst","patch_set":1,"id":"a0e8b526_4dc70302","line":48,"range":{"start_line":48,"start_character":11,"end_line":48,"end_character":13},"updated":"2020-11-23 15:10:08.000000000","message":"\"doing\"","commit_id":"b54c1f37b587cceba677a18c4bdbd752b1de32cd"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"ca4426e3370e0a9118df20e176ed457034bab5bb","unresolved":true,"context_lines":[{"line_number":45,"context_line":""},{"line_number":46,"context_line":"As discussed in the Wallaby PTG it might make more sense to record which node"},{"line_number":47,"context_line":"has staged the data and just proxy the http-request for import to that node"},{"line_number":48,"context_line":"instead of do all this fanout dance with Rabbit and put the extra load on the"},{"line_number":49,"context_line":"system."},{"line_number":50,"context_line":""},{"line_number":51,"context_line":"This approach will require additional expanding migration to our database and"}],"source_content_type":"text/x-rst","patch_set":1,"id":"d21a7562_97346633","line":48,"range":{"start_line":48,"start_character":52,"end_line":48,"end_character":55},"updated":"2020-11-23 15:10:08.000000000","message":"\"putting\"","commit_id":"b54c1f37b587cceba677a18c4bdbd752b1de32cd"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"ca4426e3370e0a9118df20e176ed457034bab5bb","unresolved":true,"context_lines":[{"line_number":48,"context_line":"instead of do all this fanout dance with Rabbit and put the extra load on the"},{"line_number":49,"context_line":"system."},{"line_number":50,"context_line":""},{"line_number":51,"context_line":"This approach will require additional expanding migration to our database and"},{"line_number":52,"context_line":"possibly config additions as well but will simplify the overall solution."},{"line_number":53,"context_line":""},{"line_number":54,"context_line":"Alternatives"}],"source_content_type":"text/x-rst","patch_set":1,"id":"9e6ccecf_54aa5863","line":51,"range":{"start_line":51,"start_character":27,"end_line":51,"end_character":57},"updated":"2020-11-23 15:10:08.000000000","message":"I think just saying \"a schema change\" would be better.","commit_id":"b54c1f37b587cceba677a18c4bdbd752b1de32cd"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"ca4426e3370e0a9118df20e176ed457034bab5bb","unresolved":true,"context_lines":[{"line_number":49,"context_line":"system."},{"line_number":50,"context_line":""},{"line_number":51,"context_line":"This approach will require additional expanding migration to our database and"},{"line_number":52,"context_line":"possibly config additions as well but will simplify the overall solution."},{"line_number":53,"context_line":""},{"line_number":54,"context_line":"Alternatives"},{"line_number":55,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"a419d42c_e92c650b","line":52,"updated":"2020-11-23 15:10:08.000000000","message":"Can you describe the schema change more specifically? What details will we be recording? Hostname? Hostname and port? URL? A reference to an entry in a nodes table which may have all of these things?","commit_id":"b54c1f37b587cceba677a18c4bdbd752b1de32cd"},{"author":{"_account_id":5314,"name":"Brian Rosmaita","email":"rosmaita.fossdev@gmail.com","username":"brian-rosmaita"},"change_message_id":"fcd22805553c7628aa68bb29f2e53c38dd5ad61e","unresolved":true,"context_lines":[{"line_number":49,"context_line":"system."},{"line_number":50,"context_line":""},{"line_number":51,"context_line":"This approach will require additional expanding migration to our database and"},{"line_number":52,"context_line":"possibly config additions as well but will simplify the overall solution."},{"line_number":53,"context_line":""},{"line_number":54,"context_line":"Alternatives"},{"line_number":55,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"166df691_dd725f85","line":52,"in_reply_to":"a419d42c_e92c650b","updated":"2020-12-10 13:43:02.000000000","message":"Agree with Dan that this is an important design decision that we should think about up front, so please outline what you\u0027re thinking here.","commit_id":"b54c1f37b587cceba677a18c4bdbd752b1de32cd"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"ca4426e3370e0a9118df20e176ed457034bab5bb","unresolved":true,"context_lines":[{"line_number":55,"context_line":"------------"},{"line_number":56,"context_line":""},{"line_number":57,"context_line":"We could leave the glance-api nodes operating independently without any"},{"line_number":58,"context_line":"communication between eachother and push the burden of managing the target API"},{"line_number":59,"context_line":"requirements to the user."},{"line_number":60,"context_line":""},{"line_number":61,"context_line":"We could also stick with the original plan to handle this usecase also via"}],"source_content_type":"text/x-rst","patch_set":1,"id":"20e4e64c_4fa5dd2e","line":58,"range":{"start_line":58,"start_character":22,"end_line":58,"end_character":31},"updated":"2020-11-23 15:10:08.000000000","message":"\"each other\"","commit_id":"b54c1f37b587cceba677a18c4bdbd752b1de32cd"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"ca4426e3370e0a9118df20e176ed457034bab5bb","unresolved":true,"context_lines":[{"line_number":62,"context_line":"the RabbitMQ based RPC to be implemented based on the needs of [0]."},{"line_number":63,"context_line":""},{"line_number":64,"context_line":"Or we could look into some other mechanism of the nodes communicating with"},{"line_number":65,"context_line":"eachother, for example calling directly the RestFul API, this would likely"},{"line_number":66,"context_line":"need unacceptable firewall rules to allow distributed calls between the nodes"},{"line_number":67,"context_line":"rather than centralized solution that is already deployed."},{"line_number":68,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"44bd9b42_ce9a6336","line":65,"range":{"start_line":65,"start_character":44,"end_line":65,"end_character":51},"updated":"2020-11-23 15:10:08.000000000","message":"\"RESTful\"","commit_id":"b54c1f37b587cceba677a18c4bdbd752b1de32cd"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"ca4426e3370e0a9118df20e176ed457034bab5bb","unresolved":true,"context_lines":[{"line_number":62,"context_line":"the RabbitMQ based RPC to be implemented based on the needs of [0]."},{"line_number":63,"context_line":""},{"line_number":64,"context_line":"Or we could look into some other mechanism of the nodes communicating with"},{"line_number":65,"context_line":"eachother, for example calling directly the RestFul API, this would likely"},{"line_number":66,"context_line":"need unacceptable firewall rules to allow distributed calls between the nodes"},{"line_number":67,"context_line":"rather than centralized solution that is already deployed."},{"line_number":68,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"bcddebbb_d20a02c0","line":65,"range":{"start_line":65,"start_character":0,"end_line":65,"end_character":9},"updated":"2020-11-23 15:10:08.000000000","message":"\"each other\"","commit_id":"b54c1f37b587cceba677a18c4bdbd752b1de32cd"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"ca4426e3370e0a9118df20e176ed457034bab5bb","unresolved":true,"context_lines":[{"line_number":64,"context_line":"Or we could look into some other mechanism of the nodes communicating with"},{"line_number":65,"context_line":"eachother, for example calling directly the RestFul API, this would likely"},{"line_number":66,"context_line":"need unacceptable firewall rules to allow distributed calls between the nodes"},{"line_number":67,"context_line":"rather than centralized solution that is already deployed."},{"line_number":68,"context_line":""},{"line_number":69,"context_line":"Data model impact"},{"line_number":70,"context_line":"-----------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"95a9578c_c6d47827","line":67,"updated":"2020-11-23 15:10:08.000000000","message":"So, I\u0027m confused, because this last \"alternative\" sounds like what I suggested and we discussed at the PTG. In the \"proposed change\" section, you only describe the act of recording which node has stored a staged image, but you don\u0027t describe what we\u0027ll do when a request comes into a node that isn\u0027t the \"right\" one. Then, in this \"alternatives\" section, this last paragraph seems to be the other half of the solution, which is the proxy.\n\nJust recording the node that has staged the image doesn\u0027t solve the problem, it\u0027s only half of the solution. Can you explain what the whole proposed solution is, if it does not include the request proxy part?\n\n...reading the rest of the spec here, it sure seems like we\u0027re on the same page, so maybe this paragraph just belongs up in the \"proposed change\" section?\n\nEither way, I\u0027d personally like to see a little more detail about the proposed change. Specifically what database change we need, where and how we\u0027re going to grab the import call and redirect, how we\u0027re going to handle the various error cases, etc.","commit_id":"b54c1f37b587cceba677a18c4bdbd752b1de32cd"},{"author":{"_account_id":5314,"name":"Brian Rosmaita","email":"rosmaita.fossdev@gmail.com","username":"brian-rosmaita"},"change_message_id":"fcd22805553c7628aa68bb29f2e53c38dd5ad61e","unresolved":true,"context_lines":[{"line_number":64,"context_line":"Or we could look into some other mechanism of the nodes communicating with"},{"line_number":65,"context_line":"eachother, for example calling directly the RestFul API, this would likely"},{"line_number":66,"context_line":"need unacceptable firewall rules to allow distributed calls between the nodes"},{"line_number":67,"context_line":"rather than centralized solution that is already deployed."},{"line_number":68,"context_line":""},{"line_number":69,"context_line":"Data model impact"},{"line_number":70,"context_line":"-----------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"60299664_0b128da7","line":67,"in_reply_to":"95a9578c_c6d47827","updated":"2020-12-10 13:43:02.000000000","message":"Agree with Dan that the proposed solution section needs to explain how when a request gets to the \"wrong\" glance-api node it will be forwarded to the \"correct\" one.  I guess that\u0027s in the fanout-rpc spec, but I don\u0027t remember exactly what that other spec proposes.","commit_id":"b54c1f37b587cceba677a18c4bdbd752b1de32cd"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"ca4426e3370e0a9118df20e176ed457034bab5bb","unresolved":true,"context_lines":[{"line_number":70,"context_line":"-----------------"},{"line_number":71,"context_line":""},{"line_number":72,"context_line":"The glance-api service staging image needs to be able to record it\u0027s details"},{"line_number":73,"context_line":"to the database so the icoming import call can be rerouted accordingly."},{"line_number":74,"context_line":""},{"line_number":75,"context_line":"REST API impact"},{"line_number":76,"context_line":"---------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"5c2c9b0e_22468b2c","line":73,"updated":"2020-11-23 15:10:08.000000000","message":"In Nova, we actually describe the change we expect to make, not just say we\u0027ll make one. Can you provide a little more detail here? Are you proposing a new column on image? Somewhere else? A new table?\n\nTBH, I was kinda expecting to just use image metadata to do this, since it should suffice and because altering the data model in glance is _so_ laborious. I can see some reasons we might go beyond that, but it would help if you could call them out here so it\u0027s clear.","commit_id":"b54c1f37b587cceba677a18c4bdbd752b1de32cd"},{"author":{"_account_id":5314,"name":"Brian Rosmaita","email":"rosmaita.fossdev@gmail.com","username":"brian-rosmaita"},"change_message_id":"fcd22805553c7628aa68bb29f2e53c38dd5ad61e","unresolved":true,"context_lines":[{"line_number":70,"context_line":"-----------------"},{"line_number":71,"context_line":""},{"line_number":72,"context_line":"The glance-api service staging image needs to be able to record it\u0027s details"},{"line_number":73,"context_line":"to the database so the icoming import call can be rerouted accordingly."},{"line_number":74,"context_line":""},{"line_number":75,"context_line":"REST API impact"},{"line_number":76,"context_line":"---------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"7cf48454_9b3dc20e","line":73,"in_reply_to":"5c2c9b0e_22468b2c","updated":"2020-12-10 13:43:02.000000000","message":"@Dan: it\u0027s dangerous to use image metadata for anything really important because it\u0027s both user visible and user mutable, unless we propose using property protections to restrict some fields by default in Glance.  We\u0027d just have to make sure that those fields could be admin-only (that is, there would be no context in which they\u0027d need to be read by an entity acting with project-scope (or domain-scope) credentials.\n\nI agree that if we\u0027re going to modify the DB we need a bit more detail about whether this will modify any current tables or simply add a new one.","commit_id":"b54c1f37b587cceba677a18c4bdbd752b1de32cd"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"3dae10d528597f90a0b465502d63f17eb3d17389","unresolved":true,"context_lines":[{"line_number":70,"context_line":"-----------------"},{"line_number":71,"context_line":""},{"line_number":72,"context_line":"The glance-api service staging image needs to be able to record it\u0027s details"},{"line_number":73,"context_line":"to the database so the icoming import call can be rerouted accordingly."},{"line_number":74,"context_line":""},{"line_number":75,"context_line":"REST API impact"},{"line_number":76,"context_line":"---------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"191d958f_4c20668d","line":73,"in_reply_to":"7cf48454_9b3dc20e","updated":"2021-01-05 19:08:04.000000000","message":"Well, we\u0027re using it for the import lock now, but by marking it as invisible and immutable, and namespaced. It would work the same way for this and I think be just fine, although I understand the desire not to pollute the metadata. Making the change formally in the DB is also fine (of course), but it\u0027s just so hard to do that in glance. Since this is really just a temporary scratch pad, it sucks to have to do all that work for it. In Nova, we have \"system_metadata\" which is not user-visible for things like this, where we stash things like an instance\u0027s original state during migration, and clear it later.","commit_id":"b54c1f37b587cceba677a18c4bdbd752b1de32cd"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"ca4426e3370e0a9118df20e176ed457034bab5bb","unresolved":true,"context_lines":[{"line_number":103,"context_line":"Other deployer impact"},{"line_number":104,"context_line":"---------------------"},{"line_number":105,"context_line":""},{"line_number":106,"context_line":"None"},{"line_number":107,"context_line":""},{"line_number":108,"context_line":"Developer impact"},{"line_number":109,"context_line":"----------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"86bc838c_b3426f4f","line":106,"updated":"2020-11-23 15:10:08.000000000","message":"The nodes need to know what their externally-resolvable names are, so they can record them in the database. Does glance already have some notion of this? If not, we probably need to determine how we\u0027re going to grab that, and it would be good to record that here. Assuming nothing else currently exists, I would suggest that we have a new config option for each worker that defines the hostname by which the node is reachable. If unset, we use socket.gethostname(). We might also want to provide a config option for an URL template, so that if each worker is behind a proxy or in a container, we can ensure that the remote nodes use that (as is the case in devstack, by the way). Something like:\n\nmyhostname \u003d some.other.hostname\nmyurl \u003d https://%(hostname)s:123/path/to/","commit_id":"b54c1f37b587cceba677a18c4bdbd752b1de32cd"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"ca4426e3370e0a9118df20e176ed457034bab5bb","unresolved":true,"context_lines":[{"line_number":137,"context_line":"  the staged data."},{"line_number":138,"context_line":""},{"line_number":139,"context_line":"* Implementing the request rerouting functionality and checks before executing"},{"line_number":140,"context_line":"  the import. This includes waiting the response from the actual executor and"},{"line_number":141,"context_line":"  relaying it back to the client."},{"line_number":142,"context_line":""},{"line_number":143,"context_line":"* Implementing a mechanism to fail gracefully if we indeed staged the image"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3efcf5ee_450a4b13","line":140,"range":{"start_line":140,"start_character":36,"end_line":140,"end_character":39},"updated":"2020-11-23 15:10:08.000000000","message":"\"for the\"","commit_id":"b54c1f37b587cceba677a18c4bdbd752b1de32cd"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"ca4426e3370e0a9118df20e176ed457034bab5bb","unresolved":true,"context_lines":[{"line_number":141,"context_line":"  relaying it back to the client."},{"line_number":142,"context_line":""},{"line_number":143,"context_line":"* Implementing a mechanism to fail gracefully if we indeed staged the image"},{"line_number":144,"context_line":"  in the first place but the data is not to be found in the staging store."},{"line_number":145,"context_line":""},{"line_number":146,"context_line":""},{"line_number":147,"context_line":"Dependencies"}],"source_content_type":"text/x-rst","patch_set":1,"id":"cc22c735_f7d4ec69","line":144,"updated":"2020-11-23 15:10:08.000000000","message":"I\u0027m not sure what this means, can you expand? If we relay to the actual node that claimed to have staged the image, but the image isn\u0027t really staged there, won\u0027t that node return an error suitable for us to relay back to the client?\n\nOr do you mean making sure that if a request to import comes in prior to a node having staged it, that we return some suitable error message, like we would today if we don\u0027t find it locally?","commit_id":"b54c1f37b587cceba677a18c4bdbd752b1de32cd"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"d388378bbac4081131654d47ff88f5462e357173","unresolved":true,"context_lines":[{"line_number":13,"context_line":"https://blueprints.launchpad.net/glance/+spec/cluster-awareness"},{"line_number":14,"context_line":""},{"line_number":15,"context_line":"With Interoperable Image Import and new edge use cases introducing"},{"line_number":16,"context_line":"asynchronous tasks we cannot expect user request to always hit the specific"},{"line_number":17,"context_line":"node where data is located or that needs to do the work. Thus it\u0027s essential"},{"line_number":18,"context_line":"that we implement a way for the glance-api nodes to communicate with"},{"line_number":19,"context_line":"each other and provide the request to the correct worker."}],"source_content_type":"text/x-rst","patch_set":2,"id":"3bdd3a68_41768979","line":16,"range":{"start_line":16,"start_character":41,"end_line":16,"end_character":48},"updated":"2021-01-12 17:02:41.000000000","message":"\"requests\u0027","commit_id":"5fc98dc86e53f9c0c885767a7918dc48fa10fb5a"},{"author":{"_account_id":5202,"name":"Erno Kuvaja","email":"jokke@usr.fi","username":"jokke"},"change_message_id":"0efe3578839b2e8602745c870b8e6596582217bd","unresolved":false,"context_lines":[{"line_number":13,"context_line":"https://blueprints.launchpad.net/glance/+spec/cluster-awareness"},{"line_number":14,"context_line":""},{"line_number":15,"context_line":"With Interoperable Image Import and new edge use cases introducing"},{"line_number":16,"context_line":"asynchronous tasks we cannot expect user request to always hit the specific"},{"line_number":17,"context_line":"node where data is located or that needs to do the work. Thus it\u0027s essential"},{"line_number":18,"context_line":"that we implement a way for the glance-api nodes to communicate with"},{"line_number":19,"context_line":"each other and provide the request to the correct worker."}],"source_content_type":"text/x-rst","patch_set":2,"id":"59638b9a_fce568ec","line":16,"range":{"start_line":16,"start_character":41,"end_line":16,"end_character":48},"in_reply_to":"3bdd3a68_41768979","updated":"2021-01-19 12:39:31.000000000","message":"Done","commit_id":"5fc98dc86e53f9c0c885767a7918dc48fa10fb5a"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"d388378bbac4081131654d47ff88f5462e357173","unresolved":true,"context_lines":[{"line_number":51,"context_line":"This approach will require additional expanding migration to our database. By"},{"line_number":52,"context_line":"adding \u0027staging_host\u0027 to our \u0027image_locations\u0027 table and recording staging as"},{"line_number":53,"context_line":"entry to that we can also keep track of the staged data for the cases where"},{"line_number":54,"context_line":"the image gets deleted before the import happens."},{"line_number":55,"context_line":""},{"line_number":56,"context_line":"This column will only be populated for the staging location, which will not"},{"line_number":57,"context_line":"transition the image to \"active\". The value will be defined in a new config"}],"source_content_type":"text/x-rst","patch_set":2,"id":"622ff987_fa6c7f53","line":54,"updated":"2021-01-12 17:02:41.000000000","message":"Can you explain why you think we should do this, instead of just using an extra_properties entry? AFAIK, the staging host information will generally need to live only for a very short period of time, between stage and import. After that, it\u0027s useless to store it. A new column is more work and potentially wasteful to store for each image (granted it\u0027s not a huge amount of data).\n\nMy implementation already stores it in a hidden and reserved os_glance_stage_host item. Is there a compelling reason to do it differently?","commit_id":"5fc98dc86e53f9c0c885767a7918dc48fa10fb5a"},{"author":{"_account_id":5202,"name":"Erno Kuvaja","email":"jokke@usr.fi","username":"jokke"},"change_message_id":"bf9685e15656ca9c97ceaedc9a1ed26ddb6daf8c","unresolved":false,"context_lines":[{"line_number":51,"context_line":"This approach will require additional expanding migration to our database. By"},{"line_number":52,"context_line":"adding \u0027staging_host\u0027 to our \u0027image_locations\u0027 table and recording staging as"},{"line_number":53,"context_line":"entry to that we can also keep track of the staged data for the cases where"},{"line_number":54,"context_line":"the image gets deleted before the import happens."},{"line_number":55,"context_line":""},{"line_number":56,"context_line":"This column will only be populated for the staging location, which will not"},{"line_number":57,"context_line":"transition the image to \"active\". The value will be defined in a new config"}],"source_content_type":"text/x-rst","patch_set":2,"id":"284cc701_5bf82397","line":54,"in_reply_to":"3c82442f_6174ed1f","updated":"2021-01-19 12:41:31.000000000","message":"Added the extra_properties approach to the alternatives.","commit_id":"5fc98dc86e53f9c0c885767a7918dc48fa10fb5a"},{"author":{"_account_id":5202,"name":"Erno Kuvaja","email":"jokke@usr.fi","username":"jokke"},"change_message_id":"8cd606fe59d1c376943a5b7423fc79ce4c9fed1c","unresolved":true,"context_lines":[{"line_number":51,"context_line":"This approach will require additional expanding migration to our database. By"},{"line_number":52,"context_line":"adding \u0027staging_host\u0027 to our \u0027image_locations\u0027 table and recording staging as"},{"line_number":53,"context_line":"entry to that we can also keep track of the staged data for the cases where"},{"line_number":54,"context_line":"the image gets deleted before the import happens."},{"line_number":55,"context_line":""},{"line_number":56,"context_line":"This column will only be populated for the staging location, which will not"},{"line_number":57,"context_line":"transition the image to \"active\". The value will be defined in a new config"}],"source_content_type":"text/x-rst","patch_set":2,"id":"9f650709_bfdfd07f","line":54,"in_reply_to":"622ff987_fa6c7f53","updated":"2021-01-12 22:32:22.000000000","message":"Consistency of use to start with. Using the extra_properties, we would need to lock down yet another key on the image properties and make sure it can be set only internally and make sure we clean it out once we don\u0027t need etc. With multistore having our staging store already configured as store we can use the existing store/locations tools to manage the staging data existence including deletion with minimal modifications. As of now we already have a need for rpc on delete where the deleting node does not have access to all the stores in the locations list, which would allow us to clean up the staging data on image deletion before import without needing to have extra special sauce for it. Now if the host is different column or part of the location uri is another thing I have no strong opinion about, but if it\u0027s on it\u0027s own column it makes finding the node where that data is bit easier. If we just pop the staging entry from the locations, we get rid of the data, entry tracking it and the staging host info all in one go.","commit_id":"5fc98dc86e53f9c0c885767a7918dc48fa10fb5a"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"ec43a8bdec108422c3aac5ed122fc02cfadef17c","unresolved":true,"context_lines":[{"line_number":51,"context_line":"This approach will require additional expanding migration to our database. By"},{"line_number":52,"context_line":"adding \u0027staging_host\u0027 to our \u0027image_locations\u0027 table and recording staging as"},{"line_number":53,"context_line":"entry to that we can also keep track of the staged data for the cases where"},{"line_number":54,"context_line":"the image gets deleted before the import happens."},{"line_number":55,"context_line":""},{"line_number":56,"context_line":"This column will only be populated for the staging location, which will not"},{"line_number":57,"context_line":"transition the image to \"active\". The value will be defined in a new config"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3c82442f_6174ed1f","line":54,"in_reply_to":"9f650709_bfdfd07f","updated":"2021-01-12 22:52:34.000000000","message":"\u003e Consistency of use to start with. Using the extra_properties, we would need to lock down yet another key on the image properties and make sure it can be set only internally and make sure we clean it out once we don\u0027t need etc.\n\nBrian suggested we just lock down os_glance_* in general, which I think is a good idea. We still have to pop out the data from the locations either way, so I\u0027m not sure I see why it\u0027s harder to do that with extra_properties. We already have the synchronized image save in the import stuff after the work to fix the race, so it slots in there pretty nicely.\n\n\u003e As of now we already have a need for rpc on delete where the deleting node does not have access to all the stores in the locations list, which would allow us to clean up the staging data on image deletion before import without needing to have extra special sauce for it. Now if the host is different column or part of the location uri is another thing I have no strong opinion about, but if it\u0027s on it\u0027s own column it makes finding the node where that data is bit easier. If we just pop the staging entry from the locations, we get rid of the data, entry tracking it and the staging host info all in one go.\n\nI\u0027m not groking this, but I\u0027m sure it\u0027s just something I\u0027m missing. We just need to proxy delete as well as import, so that the staged host will do the delete and clean up its staging store, right? If that host is down, we can delete on that local worker instead of raising an error (as in the case of import). API workers need to clean up their staging residue on startup or periodically anyway, yeah?","commit_id":"5fc98dc86e53f9c0c885767a7918dc48fa10fb5a"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"d388378bbac4081131654d47ff88f5462e357173","unresolved":true,"context_lines":[{"line_number":55,"context_line":""},{"line_number":56,"context_line":"This column will only be populated for the staging location, which will not"},{"line_number":57,"context_line":"transition the image to \"active\". The value will be defined in a new config"},{"line_number":58,"context_line":"option \u0027cluster_access\u0027 under \u0027DEFAULT\u0027 section. In a case where \u0027bind_host\u0027"},{"line_number":59,"context_line":"is set to a single IP value, that can be used instead by just omitting the"},{"line_number":60,"context_line":"new config option."},{"line_number":61,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"4a04c615_7cf84144","line":58,"range":{"start_line":58,"start_character":8,"end_line":58,"end_character":22},"updated":"2021-01-12 17:02:41.000000000","message":"Brian suggested \"worker_self_reference_url\" which, although slightly wordy, I think actually makes a lot of sense. To me, \"cluster access\" refers more to the \"whole cluster\" which is the opposite of what we want. I also think that bind_host isn\u0027t enough, for several reason:\n\n- It doesn\u0027t work for native wsgi mode\n- We need to include bind_port\n- It won\u0027t work for cases where we have a TLS proxy in front of us\n- It won\u0027t work for cases where we have a service-unifying proxy in front of us where we\u0027re reachable under a /image/... sub-path\n\nAll of the above apply to a default devstack deployment, and at least the TLS/proxy ones apply to our own RedHat-style deployments.","commit_id":"5fc98dc86e53f9c0c885767a7918dc48fa10fb5a"},{"author":{"_account_id":5202,"name":"Erno Kuvaja","email":"jokke@usr.fi","username":"jokke"},"change_message_id":"8cd606fe59d1c376943a5b7423fc79ce4c9fed1c","unresolved":true,"context_lines":[{"line_number":55,"context_line":""},{"line_number":56,"context_line":"This column will only be populated for the staging location, which will not"},{"line_number":57,"context_line":"transition the image to \"active\". The value will be defined in a new config"},{"line_number":58,"context_line":"option \u0027cluster_access\u0027 under \u0027DEFAULT\u0027 section. In a case where \u0027bind_host\u0027"},{"line_number":59,"context_line":"is set to a single IP value, that can be used instead by just omitting the"},{"line_number":60,"context_line":"new config option."},{"line_number":61,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"fea5f0f7_74054a35","line":58,"range":{"start_line":58,"start_character":8,"end_line":58,"end_character":22},"in_reply_to":"4a04c615_7cf84144","updated":"2021-01-12 22:32:22.000000000","message":"I really don\u0027t have strong opinion what the option is called. The \"worker_self_reference_url\" is pretty much as vague as the \"cluster_access\", both will need read of a help text to figure out why it\u0027s there. Any suggestions of concise name would be great.\n\n\"\"\"that can be used instead by just omitting the new config option.\"\"\" I see none of your reasoning being why that statement couldn\u0027t be still true for any deployment that doesn\u0027t need to specifically set it for any of those reasons.","commit_id":"5fc98dc86e53f9c0c885767a7918dc48fa10fb5a"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"4acb341e81c64b6aec0445c2e639416619a0ca91","unresolved":true,"context_lines":[{"line_number":55,"context_line":""},{"line_number":56,"context_line":"This column will only be populated for the staging location, which will not"},{"line_number":57,"context_line":"transition the image to \"active\". The value will be defined in a new config"},{"line_number":58,"context_line":"option \u0027cluster_access\u0027 under \u0027DEFAULT\u0027 section. In a case where \u0027bind_host\u0027"},{"line_number":59,"context_line":"is set to a single IP value, that can be used instead by just omitting the"},{"line_number":60,"context_line":"new config option."},{"line_number":61,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"1ef1a4bc_8ea58fda","line":58,"range":{"start_line":58,"start_character":8,"end_line":58,"end_character":22},"in_reply_to":"5546c7c6_2d2b926d","updated":"2021-01-21 17:31:00.000000000","message":"Because you think \"worker\" means the actual process we spawn instead of the collection of processes that we spawn for a given node? I guess I use them interchangeably. Cluster means all of the computers (to me) and if \"worker\" means the process what about \"node\"? I\u0027d be fine with \"node_self_reference_url\".","commit_id":"5fc98dc86e53f9c0c885767a7918dc48fa10fb5a"},{"author":{"_account_id":5202,"name":"Erno Kuvaja","email":"jokke@usr.fi","username":"jokke"},"change_message_id":"0efe3578839b2e8602745c870b8e6596582217bd","unresolved":true,"context_lines":[{"line_number":55,"context_line":""},{"line_number":56,"context_line":"This column will only be populated for the staging location, which will not"},{"line_number":57,"context_line":"transition the image to \"active\". The value will be defined in a new config"},{"line_number":58,"context_line":"option \u0027cluster_access\u0027 under \u0027DEFAULT\u0027 section. In a case where \u0027bind_host\u0027"},{"line_number":59,"context_line":"is set to a single IP value, that can be used instead by just omitting the"},{"line_number":60,"context_line":"new config option."},{"line_number":61,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"5546c7c6_2d2b926d","line":58,"range":{"start_line":58,"start_character":8,"end_line":58,"end_character":22},"in_reply_to":"a9d2f1f1_9bda48cc","updated":"2021-01-19 12:39:31.000000000","message":"I think my biggest problem with the \"worker_self_reference_url\" is overloading the worker part for another meaning. As the value does not refer to the worker (we have pool of workers in each service instance). On top of being mouthful for config option key.","commit_id":"5fc98dc86e53f9c0c885767a7918dc48fa10fb5a"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"ec43a8bdec108422c3aac5ed122fc02cfadef17c","unresolved":true,"context_lines":[{"line_number":55,"context_line":""},{"line_number":56,"context_line":"This column will only be populated for the staging location, which will not"},{"line_number":57,"context_line":"transition the image to \"active\". The value will be defined in a new config"},{"line_number":58,"context_line":"option \u0027cluster_access\u0027 under \u0027DEFAULT\u0027 section. In a case where \u0027bind_host\u0027"},{"line_number":59,"context_line":"is set to a single IP value, that can be used instead by just omitting the"},{"line_number":60,"context_line":"new config option."},{"line_number":61,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"a9d2f1f1_9bda48cc","line":58,"range":{"start_line":58,"start_character":8,"end_line":58,"end_character":22},"in_reply_to":"fea5f0f7_74054a35","updated":"2021-01-12 22:52:34.000000000","message":"\u003e I really don\u0027t have strong opinion what the option is called. The \"worker_self_reference_url\" is pretty much as vague as the \"cluster_access\"\n\nWell, it includes \"url\", which I think is important, and \"worker\" because it refers directly to a worker and not \"the cluster\". And \"self_reference\" because it\u0027s the \"url by which the worker can refer to itself\". Really, it has everything going for it :P","commit_id":"5fc98dc86e53f9c0c885767a7918dc48fa10fb5a"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"4acb341e81c64b6aec0445c2e639416619a0ca91","unresolved":true,"context_lines":[{"line_number":51,"context_line":"This approach will require additional expanding migration to our database. By"},{"line_number":52,"context_line":"adding \u0027staging_host\u0027 to our \u0027image_locations\u0027 table and recording staging as"},{"line_number":53,"context_line":"entry to that we can also keep track of the staged data for the cases where"},{"line_number":54,"context_line":"the image gets deleted before the import happens."},{"line_number":55,"context_line":""},{"line_number":56,"context_line":"This column will only be populated for the staging location, which will not"},{"line_number":57,"context_line":"transition the image to \"active\". The value will be defined in a new config"}],"source_content_type":"text/x-rst","patch_set":3,"id":"595b4294_a24615b9","line":54,"updated":"2021-01-21 17:31:00.000000000","message":"So I went off and looked at the location stuff after the previous discussion on this. I think I\u0027m more convinced that this is the wrong approach. We\u0027d effectively be putting a mostly-empty location in for an image, with a special link to say \"but this worker has it in its staging repo, which we can\u0027t actually point at directly.\"\n\nI would expect that to appear confusing to anything that can see that location without the normal stuff that goes with it, and potentially be confused about why an image has a weird not-complete location but also isn\u0027t active yet.\n\nIt\u0027s also a piece of data we\u0027d store (or reserve space) forever in the DB, when it really only needs to live for the time between image create and completion of import. If there was any affinity to the actual store or location where it resides such that another worker with access to a shared store could hit it, that would be one thing, but it really doesn\u0027t, and AFAIK, the staging store really can\u0027t ever be something like a ceph repo. Even though the staging area is implemented as a store in code, the staging activity is more affined to the API node and thus tying the API node URL to the location-in-a-store concept does not seem to match up to me.\n\nSo I\u0027m still not sure what this heavier approach gets us, or why the properties approach is for some reason problematic. I\u0027ve already got the latter implemented and tested. Are you suggesting that we re-write that part of my implementation before landing, or could we maybe list the locations approach as the alternative, with the primary plan to go with the property approach? If there\u0027s something to be gained later by storing this in a location, then it would be trivial to do that later and just honor the property, if set, for a cycle or something.","commit_id":"a6a285bc5015b53febc4a755b76cdae213c73924"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"4acb341e81c64b6aec0445c2e639416619a0ca91","unresolved":true,"context_lines":[{"line_number":58,"context_line":"option \u0027worker_self_reference_url\u0027 or something among those lines under"},{"line_number":59,"context_line":"\u0027DEFAULT\u0027 section. In a case where \u0027bind_host\u0027 is set to a single IP value,"},{"line_number":60,"context_line":"that can be used in combination with \u0027bind_port\u0027 instead by just omitting"},{"line_number":61,"context_line":"the new config option."},{"line_number":62,"context_line":""},{"line_number":63,"context_line":"Alternatives"},{"line_number":64,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":3,"id":"556a85b4_09e148a5","line":61,"updated":"2021-01-21 17:31:00.000000000","message":"I don\u0027t think we should do this, because we don\u0027t know the scheme, and we don\u0027t know if the remote side would be able to reach us on this bind_host:bind_port. If we\u0027re running in container, for example, this could be a 172.16.x.x address which is clearly not reachable from the outside.\n\nThis is why I fall back to public_endpoint, since that\u0027s a URL and worst cast, it just points to the same thing for every node. I\u0027d rather fall back to just not doing anything if the specific url isn\u0027t set than trying to calculate it.","commit_id":"a6a285bc5015b53febc4a755b76cdae213c73924"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"4acb341e81c64b6aec0445c2e639416619a0ca91","unresolved":true,"context_lines":[{"line_number":73,"context_line":""},{"line_number":74,"context_line":"Instead of using locations table for tracking the image data we could utlize"},{"line_number":75,"context_line":"\"os_glance_*\" property namespace and store the host information in extra"},{"line_number":76,"context_line":"properties. This approach needs filtering on all CRUD levels to prevent"},{"line_number":77,"context_line":"users to manipulate the field and would leave tracking of the image data"},{"line_number":78,"context_line":"to the administrators. POC available at [1]. Both approaches would require"},{"line_number":79,"context_line":"glance to proxy the delete of staged image to the correct node in the case"}],"source_content_type":"text/x-rst","patch_set":3,"id":"d805b45f_761e1414","line":76,"range":{"start_line":76,"start_character":12,"end_line":76,"end_character":60},"updated":"2021-01-21 17:31:00.000000000","message":"This is not unique to this spec, needs to be (and is being) done in parallel in a general way. Certainly not a reason not to do it I think.","commit_id":"a6a285bc5015b53febc4a755b76cdae213c73924"}]}