)]}'
{"/COMMIT_MSG":[{"author":{"_account_id":5371,"name":"Mathew Odden","email":"locke105@gmail.com","username":"locke105"},"change_message_id":"4fa9b8024205d50c48fb7fe67bbc1421ef3f5fda","unresolved":false,"context_lines":[{"line_number":7,"context_line":"Move baremetal API tests to an /admin subdir"},{"line_number":8,"context_line":""},{"line_number":9,"context_line":"To avoid confusion, move all baremetal API tests to api/baremetal/admin and"},{"line_number":10,"context_line":"add a README.rst explaining that the API provided by Ironic is meant an"},{"line_number":11,"context_line":"admin and service level API."},{"line_number":12,"context_line":""},{"line_number":13,"context_line":"Change-Id: Ib49b6d5937da6eedc3028a1f831552cf02d9f69e"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":2,"id":"baada198_45e6db45","line":10,"updated":"2014-07-08 22:59:29.000000000","message":"did you mean \u0027meant to be used as an\u0027 ?","commit_id":"19158390edc133d7a09c8ebe4df69de790cd1a33"}],"tempest/api/baremetal/README.rst":[{"author":{"_account_id":5196,"name":"Matthew Treinish","email":"mtreinish@kortar.org","username":"treinish"},"change_message_id":"08d3a0769d9891abfc608dae6e7b6fb101bc8fa6","unresolved":false,"context_lines":[{"line_number":23,"context_line":"inventory.  They do not actually perform hardware provisioning and rely on the"},{"line_number":24,"context_line":"\u0027fake\u0027 driver being exposed in Ironic.  It is important to note that all Ironic"},{"line_number":25,"context_line":"API actions are admin operations meant to be used either by cloud operators or"},{"line_number":26,"context_line":"other OpenStack services (i.e., Nova)."}],"source_content_type":"text/x-rst","patch_set":1,"id":"1ae5cdf2_51a3929d","line":26,"updated":"2014-06-18 18:59:40.000000000","message":"I have concerns about this paragraph. Tempest is designed to work against any openstack deployment. Tying the tests to a single driver is generally a no-go. I\u0027m not entirely comfortable saying the Ironic API tests only work in one configuration that doesn\u0027t actually do anything.\n\nThe fake driver is fine for the gate, but as an operator or deployer if I want to have functional verification of my OpenStack deployment with Ironic how is this going to work. I understand by it\u0027s nature Ironic will be very deployment specific because everyone\u0027s hardware is a special snowflake. But, we need to have a better story here even that means only running a subset of verification, if the driver isn\u0027t the \u0027fake driver\u0027. Or we add a million config options to define the criteria for the API request and response being generated by tempest and ironic. (something like testscenarios might be able to be leveraged here)","commit_id":"5be21f718b7fbcd87cc5a683c9cf3df4dbc0366c"},{"author":{"_account_id":2889,"name":"Aeva Black","email":"aeva.online@gmail.com","username":"tenbrae"},"change_message_id":"07f64ad38fa0910f095de97bef7386e8e1ebe829","unresolved":false,"context_lines":[{"line_number":23,"context_line":"inventory.  They do not actually perform hardware provisioning and rely on the"},{"line_number":24,"context_line":"\u0027fake\u0027 driver being exposed in Ironic.  It is important to note that all Ironic"},{"line_number":25,"context_line":"API actions are admin operations meant to be used either by cloud operators or"},{"line_number":26,"context_line":"other OpenStack services (i.e., Nova)."}],"source_content_type":"text/x-rst","patch_set":1,"id":"1ae5cdf2_f4fe8c05","line":26,"in_reply_to":"1ae5cdf2_51a3929d","updated":"2014-06-25 00:13:53.000000000","message":"@mtreinish: \n\nSo \"functional verification of my OpenStack deployment with Ironic\" is not done by interacting directly with Ironic at all. Perhaps that is the misunderstanding here -- we have to use scenario tests for any functional testing with real hardware, because testing that a deployment works requires several other services. That environment is prepared by enrolling hardware with Ironic, then interacting with other services (nova, glance, etc) to provision an instance on that hardware -- and the scenario tests can and should be validatable against a cloud without requiring admin credentials, or talking to Ironic\u0027s API at all.\n\nAs I understand it, the existing baremetal API tests are similar to other service\u0027s functional tests in that they do not (and should not) depend on other services\u0027 existence, while still exercising functions such as create, retrieve, update, and delete. These are all achievable with the fake driver, and those functions operate irrespective of the driver.\n\nAny ironic-api-only functional testing against real hardware would be limited to operations such as \"power on\" and \"power off\". While that is a functional hardware test, it\u0027s very limited.\n\nAdditionally, such tests will actively interfere with a production environment, if that environment has any users in it. Firstly, tempest would need to be given hardware management credentials for a discrete, accessible unit of hardware, which is not already part of the cloud being tested but which is accessible by the Ironic service within that cloud. Secondly, such hardware, once added to Ironic, would be available as a resource for Nova to schedule instances upon (assuming Nova is running, which, again, if this is a production deployment, it should be). Should Nova choose to do this (eg, in response to a user, or to Heat) then Nova and Tempest will conflict with each other, leading to non-deterministic test failures.","commit_id":"5be21f718b7fbcd87cc5a683c9cf3df4dbc0366c"}]}