)]}'
{"specs/tempest-library.rst":[{"author":{"_account_id":6167,"name":"Ken\u0027ichi Ohmichi","email":"ken1ohmichi@gmail.com","username":"oomichi"},"change_message_id":"634ec7a3d0c275ea1b23b1d600593e3df7db5a68","unresolved":false,"context_lines":[{"line_number":156,"context_line":"     glance, cinder and neutron. And proxying client class names are conflict"},{"line_number":157,"context_line":"     with the other projects like NetworksClientJSON and NetworkClientJSON."},{"line_number":158,"context_line":"     If merging all nova service clients into a single ComputeClientJSON, this"},{"line_number":159,"context_line":"     kind of conflicts will never happen."},{"line_number":160,"context_line":""},{"line_number":161,"context_line":"   * Rename service client classes"},{"line_number":162,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"fa81d914_2350dd5d","line":159,"updated":"2015-01-29 02:03:26.000000000","message":"I found a problem related to the above change.\nNow volume proxy client of compute is passed to build_timeout/interval values of cinder(not nova).\nso at least, we need to separate the proxy client is necessary to be separate from ComputeClientJSON.\nmaybe it is better to separate all proxy clients from ComputeClientJSON.","commit_id":"71cee0b5c57b8f18f99540b360162333836cab14"},{"author":{"_account_id":8859,"name":"Daisuke Morita","email":"morita.daisuke@ntti3.com","username":"morrisson"},"change_message_id":"fbd6dad3d46a2d302c9031d6a2355980542c46d5","unresolved":false,"context_lines":[{"line_number":166,"context_line":"     rule is also inconsistent. As the above mentioned, multiple clients should"},{"line_number":167,"context_line":"     be merged into a single client by each project and the class name should"},{"line_number":168,"context_line":"     be \"\u003cProject name\u003eClientJSON\" like ComputeClientJSON, NetworkClientJSON,"},{"line_number":169,"context_line":"     VolumeClientJSON etc."},{"line_number":170,"context_line":""},{"line_number":171,"context_line":"   * Stop cutting out the top key of a response"},{"line_number":172,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"1a930d6b_da404709","line":169,"updated":"2015-01-27 11:50:30.000000000","message":"IMHO, it is not necessary to end a class name with the suffix \"JSON\" because almost all projects now support only json format and Swift now supports three formats, plain text, json and xml.\n\nHowever, this is non-core task so if removing \"JSON\" suffix is troublesome, it looks OK to me.","commit_id":"71cee0b5c57b8f18f99540b360162333836cab14"},{"author":{"_account_id":6167,"name":"Ken\u0027ichi Ohmichi","email":"ken1ohmichi@gmail.com","username":"oomichi"},"change_message_id":"e25e30d65e4e46f2c9c2ace7b9960682e3d1dbf8","unresolved":false,"context_lines":[{"line_number":166,"context_line":"     rule is also inconsistent. As the above mentioned, multiple clients should"},{"line_number":167,"context_line":"     be merged into a single client by each project and the class name should"},{"line_number":168,"context_line":"     be \"\u003cProject name\u003eClientJSON\" like ComputeClientJSON, NetworkClientJSON,"},{"line_number":169,"context_line":"     VolumeClientJSON etc."},{"line_number":170,"context_line":""},{"line_number":171,"context_line":"   * Stop cutting out the top key of a response"},{"line_number":172,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"1a930d6b_f1e369d6","line":169,"in_reply_to":"1a930d6b_da404709","updated":"2015-01-27 12:02:54.000000000","message":"That is a very nice point.\nCurrent directories of service clients already contain \"json\" in the path:\n\n $ find . -name json\n ./tempest/services/orchestration/json\n ./tempest/services/compute/json\n ./tempest/services/messaging/json\n ./tempest/services/image/v2/json\n ./tempest/services/image/v1/json\n ./tempest/services/telemetry/json\n ./tempest/services/volume/v2/json\n ./tempest/services/volume/json\n ./tempest/services/database/json\n ./tempest/services/baremetal/v1/json\n ./tempest/services/network/json\n ./tempest/services/identity/json\n ./tempest/services/identity/v3/json\n\nI feel now we need to remove suffix \"JSON\" or/and \"json\" path at least.","commit_id":"71cee0b5c57b8f18f99540b360162333836cab14"},{"author":{"_account_id":8859,"name":"Daisuke Morita","email":"morita.daisuke@ntti3.com","username":"morrisson"},"change_message_id":"fbd6dad3d46a2d302c9031d6a2355980542c46d5","unresolved":false,"context_lines":[{"line_number":198,"context_line":""},{"line_number":199,"context_line":"     Some service clients are verifying a response with JSON-Schema definitions"},{"line_number":200,"context_line":"     for each API and Tempest contains these definitions. There is a concern"},{"line_number":201,"context_line":"     where is the best repogitory(Tempest or each project?) for maintaining the"},{"line_number":202,"context_line":"     definitions [1]_, but we cannot build a consensus about it yet. At this"},{"line_number":203,"context_line":"     time, we need to separate the definitions from service clients because"},{"line_number":204,"context_line":"     tempest-lib is not the best place for keeping the definitions."}],"source_content_type":"text/x-rst","patch_set":2,"id":"1a930d6b_2e0f5089","line":201,"updated":"2015-01-27 11:50:30.000000000","message":"repository?","commit_id":"71cee0b5c57b8f18f99540b360162333836cab14"},{"author":{"_account_id":6167,"name":"Ken\u0027ichi Ohmichi","email":"ken1ohmichi@gmail.com","username":"oomichi"},"change_message_id":"e25e30d65e4e46f2c9c2ace7b9960682e3d1dbf8","unresolved":false,"context_lines":[{"line_number":198,"context_line":""},{"line_number":199,"context_line":"     Some service clients are verifying a response with JSON-Schema definitions"},{"line_number":200,"context_line":"     for each API and Tempest contains these definitions. There is a concern"},{"line_number":201,"context_line":"     where is the best repogitory(Tempest or each project?) for maintaining the"},{"line_number":202,"context_line":"     definitions [1]_, but we cannot build a consensus about it yet. At this"},{"line_number":203,"context_line":"     time, we need to separate the definitions from service clients because"},{"line_number":204,"context_line":"     tempest-lib is not the best place for keeping the definitions."}],"source_content_type":"text/x-rst","patch_set":2,"id":"1a930d6b_71f69990","line":201,"in_reply_to":"1a930d6b_2e0f5089","updated":"2015-01-27 12:02:54.000000000","message":"nice catch, will fix it after the above point is solved.","commit_id":"71cee0b5c57b8f18f99540b360162333836cab14"},{"author":{"_account_id":8859,"name":"Daisuke Morita","email":"morita.daisuke@ntti3.com","username":"morrisson"},"change_message_id":"fbd6dad3d46a2d302c9031d6a2355980542c46d5","unresolved":false,"context_lines":[{"line_number":201,"context_line":"     where is the best repogitory(Tempest or each project?) for maintaining the"},{"line_number":202,"context_line":"     definitions [1]_, but we cannot build a consensus about it yet. At this"},{"line_number":203,"context_line":"     time, we need to separate the definitions from service clients because"},{"line_number":204,"context_line":"     tempest-lib is not the best place for keeping the definitions."},{"line_number":205,"context_line":""},{"line_number":206,"context_line":"   * Copy the service client code to tempest-lib repository"},{"line_number":207,"context_line":"   * Switch Tempest to use the service client code of tempest-lib"}],"source_content_type":"text/x-rst","patch_set":2,"id":"1a930d6b_4e61fc03","line":204,"updated":"2015-01-27 11:50:30.000000000","message":"I think it is OK now because the first priority is moving core functionalities out of tempest tree.","commit_id":"71cee0b5c57b8f18f99540b360162333836cab14"},{"author":{"_account_id":8556,"name":"Ghanshyam Maan","display_name":"Ghanshyam Maan","email":"gmaan.os14@gmail.com","username":"ghanshyam"},"change_message_id":"f084647f0fc959631e03741581dc0a6132177b61","unresolved":false,"context_lines":[{"line_number":152,"context_line":"     be easy to be used and maintained. For that, we will make one client class"},{"line_number":153,"context_line":"     for each service like neutron basically. That means a nova service client"},{"line_number":154,"context_line":"     class will be big, but it would be easy to maintain without thinking about"},{"line_number":155,"context_line":"     separation of extensions."},{"line_number":156,"context_line":"     Nova contains proxying features for the other projects like glance, cinder"},{"line_number":157,"context_line":"     and neutron. Now Tempest passes cinder-specific timeout values to cinder"},{"line_number":158,"context_line":"     proxying client of nova, so we need to separate a cinder proxying client"}],"source_content_type":"text/x-rst","patch_set":3,"id":"da86d52c_524e6f97","line":155,"updated":"2015-02-03 10:26:24.000000000","message":"Nice idea but when i looked more on each clients(compute), there are method like is_resource_deleted (i think this method only) which should have different implementation by each concrete clients and used by rest_client-\u003ewait_for_resource_deletion() generic method.\n\none way can be to take the resource type as input in is_resource_deleted and merge the is_resource_deleted() of all clients. or any other better idea?","commit_id":"3aec8cb0137d2494c1a740b3185f01006a9f749f"},{"author":{"_account_id":5196,"name":"Matthew Treinish","email":"mtreinish@kortar.org","username":"treinish"},"change_message_id":"1e5736da9725b288e8249945bfd16a63be34e0ce","unresolved":false,"context_lines":[{"line_number":152,"context_line":"     be easy to be used and maintained. For that, we will make one client class"},{"line_number":153,"context_line":"     for each service like neutron basically. That means a nova service client"},{"line_number":154,"context_line":"     class will be big, but it would be easy to maintain without thinking about"},{"line_number":155,"context_line":"     separation of extensions."},{"line_number":156,"context_line":"     Nova contains proxying features for the other projects like glance, cinder"},{"line_number":157,"context_line":"     and neutron. Now Tempest passes cinder-specific timeout values to cinder"},{"line_number":158,"context_line":"     proxying client of nova, so we need to separate a cinder proxying client"}],"source_content_type":"text/x-rst","patch_set":3,"id":"da86d52c_a9bd07da","line":155,"updated":"2015-02-05 17:43:50.000000000","message":"So from my point of view we\u0027ve always done separate client classes per endpoint/resource type for all the clients. The neutron one is the outlier here. Ghanshyam brings up a good point that a lot of assumptions we make about client code assumes at least an attempt to split classes on resource types.\n\nI think it\u0027ll probably be less work to just split the neutron up to be like the other clients. Instead of converting everything to be like the neutron one.","commit_id":"3aec8cb0137d2494c1a740b3185f01006a9f749f"},{"author":{"_account_id":6167,"name":"Ken\u0027ichi Ohmichi","email":"ken1ohmichi@gmail.com","username":"oomichi"},"change_message_id":"d2066c69ad4f5280e07ed65cebe0e56cc3431609","unresolved":false,"context_lines":[{"line_number":152,"context_line":"     be easy to be used and maintained. For that, we will make one client class"},{"line_number":153,"context_line":"     for each service like neutron basically. That means a nova service client"},{"line_number":154,"context_line":"     class will be big, but it would be easy to maintain without thinking about"},{"line_number":155,"context_line":"     separation of extensions."},{"line_number":156,"context_line":"     Nova contains proxying features for the other projects like glance, cinder"},{"line_number":157,"context_line":"     and neutron. Now Tempest passes cinder-specific timeout values to cinder"},{"line_number":158,"context_line":"     proxying client of nova, so we need to separate a cinder proxying client"}],"source_content_type":"text/x-rst","patch_set":3,"id":"da86d52c_6d5696cf","line":155,"in_reply_to":"da86d52c_382322a8","updated":"2015-02-13 05:26:16.000000000","message":"As a library, we should avoid backwards incompatible changes as possible.\nand current interfaces of each client are so different and inconsistent. So now it is difficult to make consistent interfaces as this spec.\n\nTempest is one big API consumer in OpenStack, and these APIs also are inconsistent between projects.\nWe can know it during Tempest development and are trying to fix it on nova-api microversions.\n\nduring this experience, I felt both inconsistency and backwards incompatibility are heavy burden. So I don\u0027t want to provide premature interfaces on a library even if blocking some development on Neutron.\n\nSo for moving forward, I\u0027d like to consider/design here.\nI tend to make a single service client for each project still because from PoV of consumer, I guess they would not consider resources intentionaly in a request.\nTechnically, the reason why we need the separation is wait_for_resource_deletion(). so if we can find the way we use the similar mechanism for multiple resources in a single client, we can merge them.\nSo I\u0027d like to investigate this direction.","commit_id":"3aec8cb0137d2494c1a740b3185f01006a9f749f"},{"author":{"_account_id":6167,"name":"Ken\u0027ichi Ohmichi","email":"ken1ohmichi@gmail.com","username":"oomichi"},"change_message_id":"e5a0c565f176eae5a6d7f23b668ee8d2bdc8b947","unresolved":false,"context_lines":[{"line_number":152,"context_line":"     be easy to be used and maintained. For that, we will make one client class"},{"line_number":153,"context_line":"     for each service like neutron basically. That means a nova service client"},{"line_number":154,"context_line":"     class will be big, but it would be easy to maintain without thinking about"},{"line_number":155,"context_line":"     separation of extensions."},{"line_number":156,"context_line":"     Nova contains proxying features for the other projects like glance, cinder"},{"line_number":157,"context_line":"     and neutron. Now Tempest passes cinder-specific timeout values to cinder"},{"line_number":158,"context_line":"     proxying client of nova, so we need to separate a cinder proxying client"}],"source_content_type":"text/x-rst","patch_set":3,"id":"da86d52c_05a48506","line":155,"in_reply_to":"da86d52c_524e6f97","updated":"2015-02-04 02:37:49.000000000","message":"Nice point, and that is really difficult point.\nI\u0027d like to investigate some code for this, and now I mark this as WIP.","commit_id":"3aec8cb0137d2494c1a740b3185f01006a9f749f"},{"author":{"_account_id":5196,"name":"Matthew Treinish","email":"mtreinish@kortar.org","username":"treinish"},"change_message_id":"e8e6e89d2987a6403650ff0d6716ace587f3ba0c","unresolved":false,"context_lines":[{"line_number":152,"context_line":"     be easy to be used and maintained. For that, we will make one client class"},{"line_number":153,"context_line":"     for each service like neutron basically. That means a nova service client"},{"line_number":154,"context_line":"     class will be big, but it would be easy to maintain without thinking about"},{"line_number":155,"context_line":"     separation of extensions."},{"line_number":156,"context_line":"     Nova contains proxying features for the other projects like glance, cinder"},{"line_number":157,"context_line":"     and neutron. Now Tempest passes cinder-specific timeout values to cinder"},{"line_number":158,"context_line":"     proxying client of nova, so we need to separate a cinder proxying client"}],"source_content_type":"text/x-rst","patch_set":3,"id":"da86d52c_382322a8","line":155,"in_reply_to":"da86d52c_64bdf601","updated":"2015-02-05 20:15:55.000000000","message":"I don\u0027t know about heat (I would believe it if they just copied what neutron client did), but for the image client there is only one resource type images hence one client. This was definitely how the client classes were originally supposed to be separated.\n\nI don\u0027t think we need external approval from a project before migrating a client that seems like an unnecessary burden without much benefit. The tempest-lib stuff is supposed to be just a straight export of common functionality from tempest into a stable api to enable external consumption. Projects are under no obligation to use it in their testing, and honestly I wouldn\u0027t expect that many to end up using it. We\u0027re also not just moving the service clients to the library solely for the use of each projects\u0027 api thats being consumed.\n\nIf anyone who ends up consuming tempest-lib for the clients wants to make changes to the interface they can go through the normal dev workflow, just like we\u0027re doing here to try and figure out how to how best to do the initial migration.\n\nAlso, this kinda restructure is part of why I\u0027m hesitant to try and get this part landed in kilo and why I was originally only planning for the RestClient in my original spec. The interface around the service clients still goes through a bit of churn so it\u0027s not as simple as other migrations we\u0027ve done up until this point.\n\nThat being said you do have a point about not necessarily needing consistency between all the services. My only concern with taking that approach is once we move things to tempest-lib it is much harder to pivot and change the interfaces. So I think it\u0027ll be better if we try and make things consistent before we migrate.","commit_id":"3aec8cb0137d2494c1a740b3185f01006a9f749f"},{"author":{"_account_id":6167,"name":"Ken\u0027ichi Ohmichi","email":"ken1ohmichi@gmail.com","username":"oomichi"},"change_message_id":"9804473d0e0ea2cbf7bc11e772f2526faabff25b","unresolved":false,"context_lines":[{"line_number":152,"context_line":"     be easy to be used and maintained. For that, we will make one client class"},{"line_number":153,"context_line":"     for each service like neutron basically. That means a nova service client"},{"line_number":154,"context_line":"     class will be big, but it would be easy to maintain without thinking about"},{"line_number":155,"context_line":"     separation of extensions."},{"line_number":156,"context_line":"     Nova contains proxying features for the other projects like glance, cinder"},{"line_number":157,"context_line":"     and neutron. Now Tempest passes cinder-specific timeout values to cinder"},{"line_number":158,"context_line":"     proxying client of nova, so we need to separate a cinder proxying client"}],"source_content_type":"text/x-rst","patch_set":3,"id":"da86d52c_dc5e1a79","line":155,"in_reply_to":"da86d52c_6d5696cf","updated":"2015-02-16 02:50:29.000000000","message":"During the above investigation, I found the other inconsistency..\n\nneutron client uses method prefix like \"list_\", \"delete_\", \"show_\", \"create_\", \"update_\" and get a method by adding resource name to the prefix.\n\n eg. list_networks, delete_network\n\nThe other clients like nova contain inconsistent methods like\n\n show_intarface, get_image, get_flavor_details\n\nfor getting the detail of resource because of adding the methods without any hacking checks.\n\nThe neutron mechanism can make function names consistent, but the mechanism is a little difficult to debug and that seems disadvantage as Tempest(test suite).\n\nSo I\u0027d like to add hacking checks for avoiding inconsistent methods.","commit_id":"3aec8cb0137d2494c1a740b3185f01006a9f749f"},{"author":{"_account_id":1192,"name":"David Kranz","email":"dkranz@redhat.com","username":"david-kranz"},"change_message_id":"750a86c69aeba33854174fb73019d3d3e1140587","unresolved":false,"context_lines":[{"line_number":152,"context_line":"     be easy to be used and maintained. For that, we will make one client class"},{"line_number":153,"context_line":"     for each service like neutron basically. That means a nova service client"},{"line_number":154,"context_line":"     class will be big, but it would be easy to maintain without thinking about"},{"line_number":155,"context_line":"     separation of extensions."},{"line_number":156,"context_line":"     Nova contains proxying features for the other projects like glance, cinder"},{"line_number":157,"context_line":"     and neutron. Now Tempest passes cinder-specific timeout values to cinder"},{"line_number":158,"context_line":"     proxying client of nova, so we need to separate a cinder proxying client"}],"source_content_type":"text/x-rst","patch_set":3,"id":"da86d52c_64bdf601","line":155,"in_reply_to":"da86d52c_a9bd07da","updated":"2015-02-05 18:04:52.000000000","message":"This is not completely true. Both image and orchestration use a single client. But I am not sure absolutely uniformity is a necessary goal here. What is good for a giant api like nova may not be best for others. In any event, since the point of moving the clients to tempest-lib is to allow their use by in-project tests, I suggest we consult each project and have them \"approve\" their client before moving to tempest-lib. There might be other issues they have that should also be changed before moving.","commit_id":"3aec8cb0137d2494c1a740b3185f01006a9f749f"},{"author":{"_account_id":1192,"name":"David Kranz","email":"dkranz@redhat.com","username":"david-kranz"},"change_message_id":"750a86c69aeba33854174fb73019d3d3e1140587","unresolved":false,"context_lines":[{"line_number":171,"context_line":"     In addition, now Tempest supports JSON only. So the suffix \"JSON\" of class"},{"line_number":172,"context_line":"     names and client paths(tempest/services/identity/json, etc) are redundant."},{"line_number":173,"context_line":"     Then the class name should be \"\u003cProject name\u003eClient\" like ComputeClient,"},{"line_number":174,"context_line":"     NetworkClient, VolumeClient etc. And \"json\" in paths will be removed."},{"line_number":175,"context_line":""},{"line_number":176,"context_line":"   * Stop cutting out the top key of a response"},{"line_number":177,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"da86d52c_64197621","line":174,"updated":"2015-02-05 18:04:52.000000000","message":"The refstack folks are going to get hurt by this. At the last summit I think we agreed that we would implement some test id feature before massive renamings.","commit_id":"3aec8cb0137d2494c1a740b3185f01006a9f749f"},{"author":{"_account_id":5196,"name":"Matthew Treinish","email":"mtreinish@kortar.org","username":"treinish"},"change_message_id":"e8e6e89d2987a6403650ff0d6716ace587f3ba0c","unresolved":false,"context_lines":[{"line_number":171,"context_line":"     In addition, now Tempest supports JSON only. So the suffix \"JSON\" of class"},{"line_number":172,"context_line":"     names and client paths(tempest/services/identity/json, etc) are redundant."},{"line_number":173,"context_line":"     Then the class name should be \"\u003cProject name\u003eClient\" like ComputeClient,"},{"line_number":174,"context_line":"     NetworkClient, VolumeClient etc. And \"json\" in paths will be removed."},{"line_number":175,"context_line":""},{"line_number":176,"context_line":"   * Stop cutting out the top key of a response"},{"line_number":177,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"da86d52c_c46942fa","line":174,"in_reply_to":"da86d52c_64197621","updated":"2015-02-05 20:15:55.000000000","message":"He\u0027s not talking about the test classes here, just the service client class names. That would have no effect on refstack or any other project that consumes tempest test results. It\u0027s strictly an internal interface thing.","commit_id":"3aec8cb0137d2494c1a740b3185f01006a9f749f"},{"author":{"_account_id":8556,"name":"Ghanshyam Maan","display_name":"Ghanshyam Maan","email":"gmaan.os14@gmail.com","username":"ghanshyam"},"change_message_id":"f084647f0fc959631e03741581dc0a6132177b61","unresolved":false,"context_lines":[{"line_number":197,"context_line":"            body \u003d json.loads(body)"},{"line_number":198,"context_line":"            self.validate_response(schema.show_host_detail, resp, body)"},{"line_number":199,"context_line":"        -   return service_client.ResponseBodyList(resp, body[\u0027host\u0027])"},{"line_number":200,"context_line":"        +   return service_client.ResponseBodyList(resp, body)"},{"line_number":201,"context_line":""},{"line_number":202,"context_line":"   * Move JSON-Schema checks of a response to Tempest from service clients"},{"line_number":203,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"da86d52c_b25ecb43","line":200,"updated":"2015-02-03 10:26:24.000000000","message":"This is good point.","commit_id":"3aec8cb0137d2494c1a740b3185f01006a9f749f"},{"author":{"_account_id":5196,"name":"Matthew Treinish","email":"mtreinish@kortar.org","username":"treinish"},"change_message_id":"1e5736da9725b288e8249945bfd16a63be34e0ce","unresolved":false,"context_lines":[{"line_number":197,"context_line":"            body \u003d json.loads(body)"},{"line_number":198,"context_line":"            self.validate_response(schema.show_host_detail, resp, body)"},{"line_number":199,"context_line":"        -   return service_client.ResponseBodyList(resp, body[\u0027host\u0027])"},{"line_number":200,"context_line":"        +   return service_client.ResponseBodyList(resp, body)"},{"line_number":201,"context_line":""},{"line_number":202,"context_line":"   * Move JSON-Schema checks of a response to Tempest from service clients"},{"line_number":203,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"da86d52c_c9a79bbb","line":200,"in_reply_to":"da86d52c_b25ecb43","updated":"2015-02-05 17:43:50.000000000","message":"+1","commit_id":"3aec8cb0137d2494c1a740b3185f01006a9f749f"},{"author":{"_account_id":5196,"name":"Matthew Treinish","email":"mtreinish@kortar.org","username":"treinish"},"change_message_id":"e8e6e89d2987a6403650ff0d6716ace587f3ba0c","unresolved":false,"context_lines":[{"line_number":197,"context_line":"            body \u003d json.loads(body)"},{"line_number":198,"context_line":"            self.validate_response(schema.show_host_detail, resp, body)"},{"line_number":199,"context_line":"        -   return service_client.ResponseBodyList(resp, body[\u0027host\u0027])"},{"line_number":200,"context_line":"        +   return service_client.ResponseBodyList(resp, body)"},{"line_number":201,"context_line":""},{"line_number":202,"context_line":"   * Move JSON-Schema checks of a response to Tempest from service clients"},{"line_number":203,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"da86d52c_31a25d4b","line":200,"in_reply_to":"da86d52c_c4bce2bd","updated":"2015-02-05 20:15:55.000000000","message":"Again, I don\u0027t think this is something we need to worry about. If there is a new version of the api that changes the response structure then we can handle it for that version. Whether that be with a new client for that major api version, or whatever our microversion handling ends up looking like. (which is a whole other can of worms)","commit_id":"3aec8cb0137d2494c1a740b3185f01006a9f749f"},{"author":{"_account_id":1192,"name":"David Kranz","email":"dkranz@redhat.com","username":"david-kranz"},"change_message_id":"750a86c69aeba33854174fb73019d3d3e1140587","unresolved":false,"context_lines":[{"line_number":197,"context_line":"            body \u003d json.loads(body)"},{"line_number":198,"context_line":"            self.validate_response(schema.show_host_detail, resp, body)"},{"line_number":199,"context_line":"        -   return service_client.ResponseBodyList(resp, body[\u0027host\u0027])"},{"line_number":200,"context_line":"        +   return service_client.ResponseBodyList(resp, body)"},{"line_number":201,"context_line":""},{"line_number":202,"context_line":"   * Move JSON-Schema checks of a response to Tempest from service clients"},{"line_number":203,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"da86d52c_c4bce2bd","line":200,"in_reply_to":"da86d52c_c9a79bbb","updated":"2015-02-05 18:04:52.000000000","message":"We would not need ResponseBodyList if we did this. But this is another case where I think we need to consult with projects. I think in some projects they consider the extra needed dereference to be a wart in the api and hope to remove it in a new version at some point. For such projects it might make sense to keep things the way they are.","commit_id":"3aec8cb0137d2494c1a740b3185f01006a9f749f"},{"author":{"_account_id":8556,"name":"Ghanshyam Maan","display_name":"Ghanshyam Maan","email":"gmaan.os14@gmail.com","username":"ghanshyam"},"change_message_id":"f084647f0fc959631e03741581dc0a6132177b61","unresolved":false,"context_lines":[{"line_number":206,"context_line":"     where is the best repository(Tempest or each project?) for maintaining the"},{"line_number":207,"context_line":"     definitions [1]_, but we cannot build a consensus about it yet. At this"},{"line_number":208,"context_line":"     time, we need to separate the definitions from service clients because"},{"line_number":209,"context_line":"     tempest-lib is not the best place for keeping the definitions."},{"line_number":210,"context_line":""},{"line_number":211,"context_line":"   * Copy the service client code to tempest-lib repository"},{"line_number":212,"context_line":"   * Switch Tempest to use the service client code of tempest-lib"}],"source_content_type":"text/x-rst","patch_set":3,"id":"da86d52c_0d45b6b2","line":209,"updated":"2015-02-03 10:26:24.000000000","message":"As per your initial idea, schema definition can be removed from service clients and  take those as input in service client function and perform the validation if schema is passed. So it will good if you can mention that here with one example.","commit_id":"3aec8cb0137d2494c1a740b3185f01006a9f749f"},{"author":{"_account_id":6167,"name":"Ken\u0027ichi Ohmichi","email":"ken1ohmichi@gmail.com","username":"oomichi"},"change_message_id":"e5a0c565f176eae5a6d7f23b668ee8d2bdc8b947","unresolved":false,"context_lines":[{"line_number":206,"context_line":"     where is the best repository(Tempest or each project?) for maintaining the"},{"line_number":207,"context_line":"     definitions [1]_, but we cannot build a consensus about it yet. At this"},{"line_number":208,"context_line":"     time, we need to separate the definitions from service clients because"},{"line_number":209,"context_line":"     tempest-lib is not the best place for keeping the definitions."},{"line_number":210,"context_line":""},{"line_number":211,"context_line":"   * Copy the service client code to tempest-lib repository"},{"line_number":212,"context_line":"   * Switch Tempest to use the service client code of tempest-lib"}],"source_content_type":"text/x-rst","patch_set":3,"id":"da86d52c_25cee9b4","line":209,"in_reply_to":"da86d52c_0d45b6b2","updated":"2015-02-04 02:37:49.000000000","message":"OK, will do :-)","commit_id":"3aec8cb0137d2494c1a740b3185f01006a9f749f"},{"author":{"_account_id":5196,"name":"Matthew Treinish","email":"mtreinish@kortar.org","username":"treinish"},"change_message_id":"1e5736da9725b288e8249945bfd16a63be34e0ce","unresolved":false,"context_lines":[{"line_number":209,"context_line":"     tempest-lib is not the best place for keeping the definitions."},{"line_number":210,"context_line":""},{"line_number":211,"context_line":"   * Copy the service client code to tempest-lib repository"},{"line_number":212,"context_line":"   * Switch Tempest to use the service client code of tempest-lib"},{"line_number":213,"context_line":""},{"line_number":214,"context_line":" * Add documentation and examples for using the libraries interfaces"},{"line_number":215,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"da86d52c_c995db33","line":212,"updated":"2015-02-05 17:43:50.000000000","message":"I think we can do this gradually. With one client class at a time. Although, I\u0027m probably overlooking some detail, but doing it piecewise seems like it would be easier given the number of clients there are in tempest.","commit_id":"3aec8cb0137d2494c1a740b3185f01006a9f749f"}]}