)]}'
{"specs/newton/approved/fpga-device-management.rst":[{"author":{"_account_id":13692,"name":"Roman Dobosz","email":"gryf73@gmail.com","username":"gryf"},"change_message_id":"dca322ba765272f13de8c9419c6093e13a2c4e23","unresolved":false,"context_lines":[{"line_number":63,"context_line":"device on a compute node, and do the FPGA reloading before it returns the"},{"line_number":64,"context_line":"VM to user."},{"line_number":65,"context_line":""},{"line_number":66,"context_line":"The resource tracker in Nova Compute code will be changed to support the FPGA"},{"line_number":67,"context_line":"device definition and detection. It reports the architecture information to"},{"line_number":68,"context_line":"Nova database."},{"line_number":69,"context_line":""},{"line_number":70,"context_line":"New filters in Nova scheduler will be provied to filter the compute nodes for"},{"line_number":71,"context_line":"VMs with a requirement of FPGA device or FPGA accelerator."}],"source_content_type":"text/x-rst","patch_set":1,"id":"9abb7d3a_e29a786d","line":68,"range":{"start_line":66,"start_character":0,"end_line":68,"end_character":14},"updated":"2016-05-31 11:42:25.000000000","message":"Are you proposing to change current implementation of resource tracker? Are you aware of ongoing work around resources?","commit_id":"2910fdb1159bb5db303d0cdf9962ef2d450bdf2e"},{"author":{"_account_id":22063,"name":"Fei Chen","email":"uchen@cn.ibm.com","username":"chenfei"},"change_message_id":"71ff4d58db918338ace0f3a235ddb1346b622c1d","unresolved":false,"context_lines":[{"line_number":63,"context_line":"device on a compute node, and do the FPGA reloading before it returns the"},{"line_number":64,"context_line":"VM to user."},{"line_number":65,"context_line":""},{"line_number":66,"context_line":"The resource tracker in Nova Compute code will be changed to support the FPGA"},{"line_number":67,"context_line":"device definition and detection. It reports the architecture information to"},{"line_number":68,"context_line":"Nova database."},{"line_number":69,"context_line":""},{"line_number":70,"context_line":"New filters in Nova scheduler will be provied to filter the compute nodes for"},{"line_number":71,"context_line":"VMs with a requirement of FPGA device or FPGA accelerator."}],"source_content_type":"text/x-rst","patch_set":1,"id":"9abb7d3a_f6f04893","line":68,"range":{"start_line":66,"start_character":0,"end_line":68,"end_character":14},"in_reply_to":"9abb7d3a_9032bb5d","updated":"2016-06-01 05:08:52.000000000","message":"I aware that thread. The referenced proposal focus on bare metal use case but not considering container case. When in container case, we do not pass-through the PCI device, but we attach one or more Linux devices which are abstracted by host driver. Only after the Linux is launched and driver is loaded, you know the device list.","commit_id":"2910fdb1159bb5db303d0cdf9962ef2d450bdf2e"},{"author":{"_account_id":13692,"name":"Roman Dobosz","email":"gryf73@gmail.com","username":"gryf"},"change_message_id":"28309ba588fa1c86671ae374603b397a8cdbf00e","unresolved":false,"context_lines":[{"line_number":63,"context_line":"device on a compute node, and do the FPGA reloading before it returns the"},{"line_number":64,"context_line":"VM to user."},{"line_number":65,"context_line":""},{"line_number":66,"context_line":"The resource tracker in Nova Compute code will be changed to support the FPGA"},{"line_number":67,"context_line":"device definition and detection. It reports the architecture information to"},{"line_number":68,"context_line":"Nova database."},{"line_number":69,"context_line":""},{"line_number":70,"context_line":"New filters in Nova scheduler will be provied to filter the compute nodes for"},{"line_number":71,"context_line":"VMs with a requirement of FPGA device or FPGA accelerator."}],"source_content_type":"text/x-rst","patch_set":1,"id":"9abb7d3a_9032bb5d","line":68,"range":{"start_line":66,"start_character":0,"end_line":68,"end_character":14},"in_reply_to":"9abb7d3a_b7242360","updated":"2016-05-31 17:07:17.000000000","message":"I see. So I think this particular spec will conflict with this one: https://review.openstack.org/#/c/312696/","commit_id":"2910fdb1159bb5db303d0cdf9962ef2d450bdf2e"},{"author":{"_account_id":22063,"name":"Fei Chen","email":"uchen@cn.ibm.com","username":"chenfei"},"change_message_id":"9a288b70a574f5b25378e83f1e480ec9814e1c55","unresolved":false,"context_lines":[{"line_number":63,"context_line":"device on a compute node, and do the FPGA reloading before it returns the"},{"line_number":64,"context_line":"VM to user."},{"line_number":65,"context_line":""},{"line_number":66,"context_line":"The resource tracker in Nova Compute code will be changed to support the FPGA"},{"line_number":67,"context_line":"device definition and detection. It reports the architecture information to"},{"line_number":68,"context_line":"Nova database."},{"line_number":69,"context_line":""},{"line_number":70,"context_line":"New filters in Nova scheduler will be provied to filter the compute nodes for"},{"line_number":71,"context_line":"VMs with a requirement of FPGA device or FPGA accelerator."}],"source_content_type":"text/x-rst","patch_set":1,"id":"9abb7d3a_b7242360","line":68,"range":{"start_line":66,"start_character":0,"end_line":68,"end_character":14},"in_reply_to":"9abb7d3a_e29a786d","updated":"2016-05-31 13:42:00.000000000","message":"The architecture of the resource tracker is not changed. The FPGA device detection is treated as a plugin for extra resource. Like the proposed DB changed mentioned bellow, the existing extra_resource field is used to keep the information. The extra_resource field is originally designed as key-value dictionary so it can be scaled to any future device. So this method can be reused.","commit_id":"2910fdb1159bb5db303d0cdf9962ef2d450bdf2e"},{"author":{"_account_id":13692,"name":"Roman Dobosz","email":"gryf73@gmail.com","username":"gryf"},"change_message_id":"e5c28394f040a96dbfd50871eb797c6d12a8a860","unresolved":false,"context_lines":[{"line_number":63,"context_line":"device on a compute node, and do the FPGA reloading before it returns the"},{"line_number":64,"context_line":"VM to user."},{"line_number":65,"context_line":""},{"line_number":66,"context_line":"The resource tracker in Nova Compute code will be changed to support the FPGA"},{"line_number":67,"context_line":"device definition and detection. It reports the architecture information to"},{"line_number":68,"context_line":"Nova database."},{"line_number":69,"context_line":""},{"line_number":70,"context_line":"New filters in Nova scheduler will be provied to filter the compute nodes for"},{"line_number":71,"context_line":"VMs with a requirement of FPGA device or FPGA accelerator."}],"source_content_type":"text/x-rst","patch_set":1,"id":"9abb7d3a_f86c65d2","line":68,"range":{"start_line":66,"start_character":0,"end_line":68,"end_character":14},"in_reply_to":"9abb7d3a_f6f04893","updated":"2016-06-02 16:57:52.000000000","message":"Referenced proposal focus on bare metal and FPGA, as a first step for providing a way to bring resources beyond CPU/memory/disk space. It describes how such resources are modeled and used. For sure this spec might collide how resources are modeled. IMHO going the same way for adding another resource (and its tracker) as it was done before in Nova is not good idea.","commit_id":"2910fdb1159bb5db303d0cdf9962ef2d450bdf2e"},{"author":{"_account_id":22063,"name":"Fei Chen","email":"uchen@cn.ibm.com","username":"chenfei"},"change_message_id":"68d442d98a1936b0e94c4089c8ba325eb85ee7fa","unresolved":false,"context_lines":[{"line_number":63,"context_line":"device on a compute node, and do the FPGA reloading before it returns the"},{"line_number":64,"context_line":"VM to user."},{"line_number":65,"context_line":""},{"line_number":66,"context_line":"The resource tracker in Nova Compute code will be changed to support the FPGA"},{"line_number":67,"context_line":"device definition and detection. It reports the architecture information to"},{"line_number":68,"context_line":"Nova database."},{"line_number":69,"context_line":""},{"line_number":70,"context_line":"New filters in Nova scheduler will be provied to filter the compute nodes for"},{"line_number":71,"context_line":"VMs with a requirement of FPGA device or FPGA accelerator."}],"source_content_type":"text/x-rst","patch_set":1,"id":"9abb7d3a_55642148","line":68,"range":{"start_line":66,"start_character":0,"end_line":68,"end_character":14},"in_reply_to":"9abb7d3a_f86c65d2","updated":"2016-06-03 04:31:57.000000000","message":"I see some collide since I think the referenced proposed miss some use cases which I explains in other comments.\nWhat is your suggestion when you think it is not a good idea? Even in bare metal case, when using SR-IOV, you don\u0027t get the VF list until you load the driver for PF. As I proposal, the best way is to provide a detect_bin to do the device list outside Nova. The manual way is just for compatibility.","commit_id":"2910fdb1159bb5db303d0cdf9962ef2d450bdf2e"},{"author":{"_account_id":13692,"name":"Roman Dobosz","email":"gryf73@gmail.com","username":"gryf"},"change_message_id":"28309ba588fa1c86671ae374603b397a8cdbf00e","unresolved":false,"context_lines":[{"line_number":89,"context_line":""},{"line_number":90,"context_line":"This spec proposes the following changes to Nova:"},{"line_number":91,"context_line":""},{"line_number":92,"context_line":"#. In Nova DB, the ``extra_resources`` column in the ``compute_nodes`` table"},{"line_number":93,"context_line":"   is used to store the FPGA device information on each compute node::"},{"line_number":94,"context_line":""},{"line_number":95,"context_line":"     {"}],"source_content_type":"text/x-rst","patch_set":1,"id":"9abb7d3a_bf15084a","line":92,"range":{"start_line":92,"start_character":3,"end_line":92,"end_character":76},"updated":"2016-05-31 17:07:17.000000000","message":"extra_resources is not used in context of ComputeNode object due to deprecation of extensible resource tracker.","commit_id":"2910fdb1159bb5db303d0cdf9962ef2d450bdf2e"},{"author":{"_account_id":22063,"name":"Fei Chen","email":"uchen@cn.ibm.com","username":"chenfei"},"change_message_id":"71ff4d58db918338ace0f3a235ddb1346b622c1d","unresolved":false,"context_lines":[{"line_number":89,"context_line":""},{"line_number":90,"context_line":"This spec proposes the following changes to Nova:"},{"line_number":91,"context_line":""},{"line_number":92,"context_line":"#. In Nova DB, the ``extra_resources`` column in the ``compute_nodes`` table"},{"line_number":93,"context_line":"   is used to store the FPGA device information on each compute node::"},{"line_number":94,"context_line":""},{"line_number":95,"context_line":"     {"}],"source_content_type":"text/x-rst","patch_set":1,"id":"9abb7d3a_f69168f2","line":92,"range":{"start_line":92,"start_character":3,"end_line":92,"end_character":76},"in_reply_to":"9abb7d3a_bf15084a","updated":"2016-06-01 05:08:52.000000000","message":"I accept your opinion. Adding a new field can be an alternative. I will update the spec.","commit_id":"2910fdb1159bb5db303d0cdf9962ef2d450bdf2e"},{"author":{"_account_id":22063,"name":"Fei Chen","email":"uchen@cn.ibm.com","username":"chenfei"},"change_message_id":"3fad8dfd2ebb9b4b4f20469e5157e1ff170c0e02","unresolved":false,"context_lines":[{"line_number":89,"context_line":""},{"line_number":90,"context_line":"This spec proposes the following changes to Nova:"},{"line_number":91,"context_line":""},{"line_number":92,"context_line":"#. In Nova DB, the ``extra_resources`` column in the ``compute_nodes`` table"},{"line_number":93,"context_line":"   is used to store the FPGA device information on each compute node::"},{"line_number":94,"context_line":""},{"line_number":95,"context_line":"     {"}],"source_content_type":"text/x-rst","patch_set":1,"id":"9abb7d3a_36a2cb4b","line":92,"range":{"start_line":92,"start_character":3,"end_line":92,"end_character":76},"in_reply_to":"9abb7d3a_f69168f2","updated":"2016-06-01 05:55:49.000000000","message":"Done","commit_id":"2910fdb1159bb5db303d0cdf9962ef2d450bdf2e"},{"author":{"_account_id":13692,"name":"Roman Dobosz","email":"gryf73@gmail.com","username":"gryf"},"change_message_id":"28309ba588fa1c86671ae374603b397a8cdbf00e","unresolved":false,"context_lines":[{"line_number":109,"context_line":""},{"line_number":110,"context_line":"#. In Nova DB, a new ``fpga_ref`` column is added to ``instances`` table to"},{"line_number":111,"context_line":"   persist the FPGA device attachment information for each VM instance::"},{"line_number":112,"context_line":""},{"line_number":113,"context_line":"     ["},{"line_number":114,"context_line":"       {"},{"line_number":115,"context_line":"         \"name\":\"fpga_device_name1\","}],"source_content_type":"text/x-rst","patch_set":1,"id":"9abb7d3a_9bbc9707","line":112,"updated":"2016-05-31 17:07:17.000000000","message":"JSON field is a bad idea with relational DB.","commit_id":"2910fdb1159bb5db303d0cdf9962ef2d450bdf2e"},{"author":{"_account_id":22063,"name":"Fei Chen","email":"uchen@cn.ibm.com","username":"chenfei"},"change_message_id":"71ff4d58db918338ace0f3a235ddb1346b622c1d","unresolved":false,"context_lines":[{"line_number":109,"context_line":""},{"line_number":110,"context_line":"#. In Nova DB, a new ``fpga_ref`` column is added to ``instances`` table to"},{"line_number":111,"context_line":"   persist the FPGA device attachment information for each VM instance::"},{"line_number":112,"context_line":""},{"line_number":113,"context_line":"     ["},{"line_number":114,"context_line":"       {"},{"line_number":115,"context_line":"         \"name\":\"fpga_device_name1\","}],"source_content_type":"text/x-rst","patch_set":1,"id":"9abb7d3a_d649c4b8","line":112,"in_reply_to":"9abb7d3a_9bbc9707","updated":"2016-06-01 05:08:52.000000000","message":"I am following the existing OpenStack coding style. For example  CPU information is stored in Nova DB as JSON format.","commit_id":"2910fdb1159bb5db303d0cdf9962ef2d450bdf2e"},{"author":{"_account_id":13692,"name":"Roman Dobosz","email":"gryf73@gmail.com","username":"gryf"},"change_message_id":"dca322ba765272f13de8c9419c6093e13a2c4e23","unresolved":false,"context_lines":[{"line_number":122,"context_line":"         ..."},{"line_number":123,"context_line":"       }"},{"line_number":124,"context_line":"     ]"},{"line_number":125,"context_line":""},{"line_number":126,"context_line":"#. ``nova.conf`` and the resource tracking code of Nova compute need to be"},{"line_number":127,"context_line":"   changed. FPGA device list is added to ``nova.conf``. An example of the"},{"line_number":128,"context_line":"   device list is::"}],"source_content_type":"text/x-rst","patch_set":1,"id":"9abb7d3a_9955dbfb","line":125,"updated":"2016-05-31 11:42:25.000000000","message":"I\u0027m not sure, if this is the best approach for storing information about FPGA and its potential accelerators. From my point of view, accelerator which might be programmed on FGPA is the resource by itself, and depend on couple of things.\n\nUser can request a feature, which might map to specific or minimal version of accelerator. That way it might be mapped to several different FPGA devices or even slots if there are available binaries for them.\n\nIn particular point of time, accelerator may not exist on FPGA, or be unused. In that case whole FPGA device can be used as a resource or provide available slots for accelerators at the same time.\n\nI see such resource as a tree structure, where FPGA device is a root of such, slots are leafs for it. Slots can be occupied by accelerators, which can have 1 or more contexts (which means, that single accelerator might be assigned to several VMs)","commit_id":"2910fdb1159bb5db303d0cdf9962ef2d450bdf2e"},{"author":{"_account_id":13692,"name":"Roman Dobosz","email":"gryf73@gmail.com","username":"gryf"},"change_message_id":"28309ba588fa1c86671ae374603b397a8cdbf00e","unresolved":false,"context_lines":[{"line_number":122,"context_line":"         ..."},{"line_number":123,"context_line":"       }"},{"line_number":124,"context_line":"     ]"},{"line_number":125,"context_line":""},{"line_number":126,"context_line":"#. ``nova.conf`` and the resource tracking code of Nova compute need to be"},{"line_number":127,"context_line":"   changed. FPGA device list is added to ``nova.conf``. An example of the"},{"line_number":128,"context_line":"   device list is::"}],"source_content_type":"text/x-rst","patch_set":1,"id":"9abb7d3a_1ea37501","line":125,"in_reply_to":"9abb7d3a_92eacdaa","updated":"2016-05-31 17:07:17.000000000","message":"I understand the idea, I just simply don\u0027t like the json fields and \"old\" way of modeling resources. Please see my comment below for further explanation.","commit_id":"2910fdb1159bb5db303d0cdf9962ef2d450bdf2e"},{"author":{"_account_id":22063,"name":"Fei Chen","email":"uchen@cn.ibm.com","username":"chenfei"},"change_message_id":"9a288b70a574f5b25378e83f1e480ec9814e1c55","unresolved":false,"context_lines":[{"line_number":122,"context_line":"         ..."},{"line_number":123,"context_line":"       }"},{"line_number":124,"context_line":"     ]"},{"line_number":125,"context_line":""},{"line_number":126,"context_line":"#. ``nova.conf`` and the resource tracking code of Nova compute need to be"},{"line_number":127,"context_line":"   changed. FPGA device list is added to ``nova.conf``. An example of the"},{"line_number":128,"context_line":"   device list is::"}],"source_content_type":"text/x-rst","patch_set":1,"id":"9abb7d3a_92eacdaa","line":125,"in_reply_to":"9abb7d3a_9955dbfb","updated":"2016-05-31 13:42:00.000000000","message":"Here the extra_resource in Nova DB is inherent for the FPGA card unless you replace the card or upgrade the firmware depending on you use full-configuration or partial configuration. The information must be used to filtering compatible binary to keep the hardware safe.\n\nThe new fpga_ref field DB is describing the current status of what accelerator binary is already loaded. I don\u0027t mean it is unchangeable in the life cycle of VM instance. And the fpga_ref structure do not stop you scheduling a group of accelerator binaries with same \"name\" but different glance_image_id. But no matter how you do the filtering, you can finally have one selected binary loaded into FPGA. That\u0027s the information stored in the fpga_ref field. Here I decouple the Nova DB and the filter.","commit_id":"2910fdb1159bb5db303d0cdf9962ef2d450bdf2e"},{"author":{"_account_id":13692,"name":"Roman Dobosz","email":"gryf73@gmail.com","username":"gryf"},"change_message_id":"dca322ba765272f13de8c9419c6093e13a2c4e23","unresolved":false,"context_lines":[{"line_number":138,"context_line":"     firmware \u003d 6723-1234"},{"line_number":139,"context_line":"     device \u003d /dev/fpga0,dev/fpga_ctl"},{"line_number":140,"context_line":"     passthrough \u003d docker"},{"line_number":141,"context_line":""},{"line_number":142,"context_line":"   Nova resource tracking code is changed to do resource detection according"},{"line_number":143,"context_line":"   to the ``fpga_devices`` section in ``nova.conf``. Some FPGA binary tool can"},{"line_number":144,"context_line":"   be specified in ``nova.conf`` to help device detection and accelerator"}],"source_content_type":"text/x-rst","patch_set":1,"id":"9abb7d3a_b97b7f27","line":141,"updated":"2016-05-31 11:42:25.000000000","message":"This particular config is malformed, or will behave differently than you expected. You override options here, like chip and board.","commit_id":"2910fdb1159bb5db303d0cdf9962ef2d450bdf2e"},{"author":{"_account_id":13692,"name":"Roman Dobosz","email":"gryf73@gmail.com","username":"gryf"},"change_message_id":"28309ba588fa1c86671ae374603b397a8cdbf00e","unresolved":false,"context_lines":[{"line_number":138,"context_line":"     firmware \u003d 6723-1234"},{"line_number":139,"context_line":"     device \u003d /dev/fpga0,dev/fpga_ctl"},{"line_number":140,"context_line":"     passthrough \u003d docker"},{"line_number":141,"context_line":""},{"line_number":142,"context_line":"   Nova resource tracking code is changed to do resource detection according"},{"line_number":143,"context_line":"   to the ``fpga_devices`` section in ``nova.conf``. Some FPGA binary tool can"},{"line_number":144,"context_line":"   be specified in ``nova.conf`` to help device detection and accelerator"}],"source_content_type":"text/x-rst","patch_set":1,"id":"9abb7d3a_4b1c2b6a","line":141,"in_reply_to":"9abb7d3a_0d51a0d8","updated":"2016-05-31 17:07:17.000000000","message":"Okay, but spec doesn\u0027t have that information. Also, as I said, on line 133 and 137 you\u0027re defining \u0027chip\u0027 config option, which will be overridden by the latter.\n\nHow to deal with multiple cards on single servers?","commit_id":"2910fdb1159bb5db303d0cdf9962ef2d450bdf2e"},{"author":{"_account_id":22063,"name":"Fei Chen","email":"uchen@cn.ibm.com","username":"chenfei"},"change_message_id":"71ff4d58db918338ace0f3a235ddb1346b622c1d","unresolved":false,"context_lines":[{"line_number":138,"context_line":"     firmware \u003d 6723-1234"},{"line_number":139,"context_line":"     device \u003d /dev/fpga0,dev/fpga_ctl"},{"line_number":140,"context_line":"     passthrough \u003d docker"},{"line_number":141,"context_line":""},{"line_number":142,"context_line":"   Nova resource tracking code is changed to do resource detection according"},{"line_number":143,"context_line":"   to the ``fpga_devices`` section in ``nova.conf``. Some FPGA binary tool can"},{"line_number":144,"context_line":"   be specified in ``nova.conf`` to help device detection and accelerator"}],"source_content_type":"text/x-rst","patch_set":1,"id":"9abb7d3a_fc530715","line":141,"in_reply_to":"9abb7d3a_4b1c2b6a","updated":"2016-06-01 05:08:52.000000000","message":"I will update it in next patch. For multiple card, there are organized as list. They have different name like \"Dragon0\" and \"Dragon1\", but still have same other hardware information. One highlight here is for container use case and this is an important reason I say current PCI base resource tracker is insufficient. Two cards in Linux can be presented as \"fpgactrl\", \"fpga0\" and \"fpga1\". The \"fpgactl\" is common for all cards. You have to explicit define here \"fpgactl,fpga0\" as \"Dragon0\" and \"fpgactl,fpga1\" as \"Dragon1\".","commit_id":"2910fdb1159bb5db303d0cdf9962ef2d450bdf2e"},{"author":{"_account_id":22063,"name":"Fei Chen","email":"uchen@cn.ibm.com","username":"chenfei"},"change_message_id":"9a288b70a574f5b25378e83f1e480ec9814e1c55","unresolved":false,"context_lines":[{"line_number":138,"context_line":"     firmware \u003d 6723-1234"},{"line_number":139,"context_line":"     device \u003d /dev/fpga0,dev/fpga_ctl"},{"line_number":140,"context_line":"     passthrough \u003d docker"},{"line_number":141,"context_line":""},{"line_number":142,"context_line":"   Nova resource tracking code is changed to do resource detection according"},{"line_number":143,"context_line":"   to the ``fpga_devices`` section in ``nova.conf``. Some FPGA binary tool can"},{"line_number":144,"context_line":"   be specified in ``nova.conf`` to help device detection and accelerator"}],"source_content_type":"text/x-rst","patch_set":1,"id":"9abb7d3a_0d51a0d8","line":141,"in_reply_to":"9abb7d3a_b97b7f27","updated":"2016-05-31 13:42:00.000000000","message":"Some information here has priority. For example, if there is a valid \"detect_bin\", then other information is optional because the detect_bin is provided by FPGA manufacture and it returns expected information. For some device which don\u0027t has such \"detect_bin\", we allow the cloud provider manually input the information.\n\nThe chip and board are not override. Some user\u0027s might want to see the board name in dashboard like \"Dragon\", but he don\u0027t want to see a name like \"Dragon-with-chip_xxx_speed2\". By using both chip and board name, it meets both the accelerator binary compatibility checking and also the display name requirement.","commit_id":"2910fdb1159bb5db303d0cdf9962ef2d450bdf2e"},{"author":{"_account_id":22063,"name":"Fei Chen","email":"uchen@cn.ibm.com","username":"chenfei"},"change_message_id":"6bcf9e82733eba9be620fdc37e23d4c0e1fb3cca","unresolved":false,"context_lines":[{"line_number":138,"context_line":"     firmware \u003d 6723-1234"},{"line_number":139,"context_line":"     device \u003d /dev/fpga0,dev/fpga_ctl"},{"line_number":140,"context_line":"     passthrough \u003d docker"},{"line_number":141,"context_line":""},{"line_number":142,"context_line":"   Nova resource tracking code is changed to do resource detection according"},{"line_number":143,"context_line":"   to the ``fpga_devices`` section in ``nova.conf``. Some FPGA binary tool can"},{"line_number":144,"context_line":"   be specified in ``nova.conf`` to help device detection and accelerator"}],"source_content_type":"text/x-rst","patch_set":1,"id":"9abb7d3a_9698d7c1","line":141,"in_reply_to":"9abb7d3a_fc530715","updated":"2016-06-01 05:29:20.000000000","message":"Done","commit_id":"2910fdb1159bb5db303d0cdf9962ef2d450bdf2e"},{"author":{"_account_id":13692,"name":"Roman Dobosz","email":"gryf73@gmail.com","username":"gryf"},"change_message_id":"dca322ba765272f13de8c9419c6093e13a2c4e23","unresolved":false,"context_lines":[{"line_number":161,"context_line":"   VM or attach FPGA device to container VM. It also executes the accelerator"},{"line_number":162,"context_line":"   reloading. It is a simple extension of existing PCI pass through code in"},{"line_number":163,"context_line":"   KVM instance driver."},{"line_number":164,"context_line":""},{"line_number":165,"context_line":""},{"line_number":166,"context_line":"Alternatives"},{"line_number":167,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"9abb7d3a_b4942643","line":164,"updated":"2016-05-31 11:42:25.000000000","message":"I can also imagine provisioning bare metal with FPGA via ironic driver.","commit_id":"2910fdb1159bb5db303d0cdf9962ef2d450bdf2e"},{"author":{"_account_id":22063,"name":"Fei Chen","email":"uchen@cn.ibm.com","username":"chenfei"},"change_message_id":"68d442d98a1936b0e94c4089c8ba325eb85ee7fa","unresolved":false,"context_lines":[{"line_number":161,"context_line":"   VM or attach FPGA device to container VM. It also executes the accelerator"},{"line_number":162,"context_line":"   reloading. It is a simple extension of existing PCI pass through code in"},{"line_number":163,"context_line":"   KVM instance driver."},{"line_number":164,"context_line":""},{"line_number":165,"context_line":""},{"line_number":166,"context_line":"Alternatives"},{"line_number":167,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"9abb7d3a_95ecc990","line":164,"in_reply_to":"9abb7d3a_38d0adf7","updated":"2016-06-03 04:31:57.000000000","message":"You are right. The scheduler still the same, and it is the job of bare metal driver.","commit_id":"2910fdb1159bb5db303d0cdf9962ef2d450bdf2e"},{"author":{"_account_id":22063,"name":"Fei Chen","email":"uchen@cn.ibm.com","username":"chenfei"},"change_message_id":"71ff4d58db918338ace0f3a235ddb1346b622c1d","unresolved":false,"context_lines":[{"line_number":161,"context_line":"   VM or attach FPGA device to container VM. It also executes the accelerator"},{"line_number":162,"context_line":"   reloading. It is a simple extension of existing PCI pass through code in"},{"line_number":163,"context_line":"   KVM instance driver."},{"line_number":164,"context_line":""},{"line_number":165,"context_line":""},{"line_number":166,"context_line":"Alternatives"},{"line_number":167,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"9abb7d3a_9c747b68","line":164,"in_reply_to":"9abb7d3a_6b65afb3","updated":"2016-06-01 05:08:52.000000000","message":"If it is a risk we accept, that\u0027s right. Though there is no sentence and work item here mentioning bare metal because I have the safety concern, the proposal here is compatible when working with the bare metal driver. I would like to accept the bare metal idea if we accept the risk.","commit_id":"2910fdb1159bb5db303d0cdf9962ef2d450bdf2e"},{"author":{"_account_id":13692,"name":"Roman Dobosz","email":"gryf73@gmail.com","username":"gryf"},"change_message_id":"e5c28394f040a96dbfd50871eb797c6d12a8a860","unresolved":false,"context_lines":[{"line_number":161,"context_line":"   VM or attach FPGA device to container VM. It also executes the accelerator"},{"line_number":162,"context_line":"   reloading. It is a simple extension of existing PCI pass through code in"},{"line_number":163,"context_line":"   KVM instance driver."},{"line_number":164,"context_line":""},{"line_number":165,"context_line":""},{"line_number":166,"context_line":"Alternatives"},{"line_number":167,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"9abb7d3a_38d0adf7","line":164,"in_reply_to":"9abb7d3a_9c747b68","updated":"2016-06-02 16:57:52.000000000","message":"I would make it configurable through appropriate flavors or config option or both. Cloud admin would make the decision based of the actual needs and cloud type.","commit_id":"2910fdb1159bb5db303d0cdf9962ef2d450bdf2e"},{"author":{"_account_id":22063,"name":"Fei Chen","email":"uchen@cn.ibm.com","username":"chenfei"},"change_message_id":"9a288b70a574f5b25378e83f1e480ec9814e1c55","unresolved":false,"context_lines":[{"line_number":161,"context_line":"   VM or attach FPGA device to container VM. It also executes the accelerator"},{"line_number":162,"context_line":"   reloading. It is a simple extension of existing PCI pass through code in"},{"line_number":163,"context_line":"   KVM instance driver."},{"line_number":164,"context_line":""},{"line_number":165,"context_line":""},{"line_number":166,"context_line":"Alternatives"},{"line_number":167,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"9abb7d3a_cd01583a","line":164,"in_reply_to":"9abb7d3a_b4942643","updated":"2016-05-31 13:42:00.000000000","message":"Good suggestion. Actually the proposed Spec don\u0027t touch much detail about the driver layer because we know different \"hypervisor\" driver has much different mechanism.\n\nFor bare metal provision, I have the concern that how you make sure the safety of the FPGA devices because you allow the user control the hardware directly. We know downloading a bad binary to FPGA may cause un-recoverable physical damage.","commit_id":"2910fdb1159bb5db303d0cdf9962ef2d450bdf2e"},{"author":{"_account_id":13692,"name":"Roman Dobosz","email":"gryf73@gmail.com","username":"gryf"},"change_message_id":"28309ba588fa1c86671ae374603b397a8cdbf00e","unresolved":false,"context_lines":[{"line_number":161,"context_line":"   VM or attach FPGA device to container VM. It also executes the accelerator"},{"line_number":162,"context_line":"   reloading. It is a simple extension of existing PCI pass through code in"},{"line_number":163,"context_line":"   KVM instance driver."},{"line_number":164,"context_line":""},{"line_number":165,"context_line":""},{"line_number":166,"context_line":"Alternatives"},{"line_number":167,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"9abb7d3a_6b65afb3","line":164,"in_reply_to":"9abb7d3a_cd01583a","updated":"2016-05-31 17:07:17.000000000","message":"Yup, that\u0027s right. The same goes for allowing VM to program FPGA. However in private cloud I can easily imagine a need for such scenario.","commit_id":"2910fdb1159bb5db303d0cdf9962ef2d450bdf2e"},{"author":{"_account_id":13692,"name":"Roman Dobosz","email":"gryf73@gmail.com","username":"gryf"},"change_message_id":"dca322ba765272f13de8c9419c6093e13a2c4e23","unresolved":false,"context_lines":[{"line_number":240,"context_line":""},{"line_number":241,"context_line":"    JSON schema definition for the response body data: Unchanged"},{"line_number":242,"context_line":""},{"line_number":243,"context_line":""},{"line_number":244,"context_line":"Security impact"},{"line_number":245,"context_line":"---------------"},{"line_number":246,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"9abb7d3a_48bd5eb6","line":243,"updated":"2016-05-31 11:42:25.000000000","message":"As stated above, I wouldn\u0027t hardcode device with specific binary - I\u0027d rather a list of binaries, which match required accelerator (for example JPG decompression) so that scheduler can choose between several different types of FPGAs, not the specific one. This is important from operator perspective, where it should prepare a lot of flavors for every device-binary part.","commit_id":"2910fdb1159bb5db303d0cdf9962ef2d450bdf2e"},{"author":{"_account_id":13692,"name":"Roman Dobosz","email":"gryf73@gmail.com","username":"gryf"},"change_message_id":"e5c28394f040a96dbfd50871eb797c6d12a8a860","unresolved":false,"context_lines":[{"line_number":240,"context_line":""},{"line_number":241,"context_line":"    JSON schema definition for the response body data: Unchanged"},{"line_number":242,"context_line":""},{"line_number":243,"context_line":""},{"line_number":244,"context_line":"Security impact"},{"line_number":245,"context_line":"---------------"},{"line_number":246,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"9abb7d3a_7624f4c5","line":243,"in_reply_to":"9abb7d3a_47ea40ad","updated":"2016-06-02 16:57:52.000000000","message":"\u003e Let\u0027s decouple the discussion. First, assuming in future we have the service\n\u003e or API to do matching on \"accelerator_name\" to\n\u003e \"accelerator_somewhere_binary_id\", no matter this service is in  Nova or\n\u003e other reliant service, the proposal here still works. What you have to\n\u003e change in this API is changing the \"accelerator_glance_id\" to\n\u003e \"accelerator_name\".\n\nWell. It will work, but again, it\u0027s more like a hack, not a real solution.\n\n\u003e Then in Nova scheduler, it calls the service API like\n\u003e return_ture_or_not(accelerator_name, host_name) so that the Nova scheduler\n\u003e know whether we can find a compatible accelerator binary for the host\n\u003e machine. Before or when we do accelerator binary reloading, we call the\n\u003e service API like get_binary_id (accelerator_name, FPGA_device).\n\nI have an impression, that from your point of view, mapping between accelerator\nand VM is like 1:1, while the situation, where only single/several context of\nan accelerator is/are exposed to the single vm is somehow …\n\n\u003e Second, let\u0027s discuss whether we should put this service in Nova. Assuming\n\u003e it is in Nova, when a user upload a binary to OpenStack for the accelerator\n\u003e \"jpg_decoder\" which already have multiple binaries implementation like\n\u003e \"jpg_decoder_binary1\" and \"jpg_decoder_binary2\". It is not Nova\u0027s job to do\n\u003e the binaries storage right?\n\nNo, glance will hold images. Although I would be very careful about binaries,\nwhich users may provide - this might be hazard situation just like\nprovisioning entire host with FPGA.\n\n\u003e so the user is calling a Glance (let\u0027s to the assumption here) API to do the\n\u003e uploading. However, to provide the service mentioned above in Nova, Nova\n\u003e have to keep the information like \"jpg_decoder : [xxx_glance_id1,\n\u003e xxx_glance_id2, ...] inside Nova DB. Do we really wan\u0027t to couple the DB\n\u003e relationship between Glance and Nova?\n\nTo keep control what-goes-where it might be good idea, don\u0027t you think?. What\nyou are proposed here is to keep information about hardware in DB and than\nselect this hardware through scheduler, and program something from glance,\nwhich doesn\u0027t necesairy have to be the right binary for this hardware.\n\nIn the spec I cannot see where is decision making entity for matching hardware \nand the binary. Or what exactly will prepare POST/PUT data and send it to Nova \nthrough REST API?\n\n\u003e So I guess we still want to keep such relationship inside Glance DB(if we\n\u003e proposal a patch to Glance). Then my proposal here will call the new Glance\n\u003e API like I explain above.\n\nHm. So where again should logic for programming/reloading be placed in your\nopinion?","commit_id":"2910fdb1159bb5db303d0cdf9962ef2d450bdf2e"},{"author":{"_account_id":22063,"name":"Fei Chen","email":"uchen@cn.ibm.com","username":"chenfei"},"change_message_id":"9a288b70a574f5b25378e83f1e480ec9814e1c55","unresolved":false,"context_lines":[{"line_number":240,"context_line":""},{"line_number":241,"context_line":"    JSON schema definition for the response body data: Unchanged"},{"line_number":242,"context_line":""},{"line_number":243,"context_line":""},{"line_number":244,"context_line":"Security impact"},{"line_number":245,"context_line":"---------------"},{"line_number":246,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"9abb7d3a_d1dbb24d","line":243,"in_reply_to":"9abb7d3a_48bd5eb6","updated":"2016-05-31 13:42:00.000000000","message":"I agree with you that it provides better user experience to provide an alias for a group of accelerator binaries. However, the compatibility of FPGA binaries is much complicated to CPU. For example, when using partial configuration, the compatibility is not only sensitive with the FPGA chip, it even not compatible in twice compilation even you are using exact the same source code and the same compiler in the same environment.\nI don\u0027t think it is a good idea to throw this work to OpenStack. It should be some other service that work with or on-top of OpenStack. We should decouple it with OpenStack, especially with Nova.","commit_id":"2910fdb1159bb5db303d0cdf9962ef2d450bdf2e"},{"author":{"_account_id":22063,"name":"Fei Chen","email":"uchen@cn.ibm.com","username":"chenfei"},"change_message_id":"68d442d98a1936b0e94c4089c8ba325eb85ee7fa","unresolved":false,"context_lines":[{"line_number":240,"context_line":""},{"line_number":241,"context_line":"    JSON schema definition for the response body data: Unchanged"},{"line_number":242,"context_line":""},{"line_number":243,"context_line":""},{"line_number":244,"context_line":"Security impact"},{"line_number":245,"context_line":"---------------"},{"line_number":246,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"9abb7d3a_f0a28399","line":243,"in_reply_to":"9abb7d3a_7624f4c5","updated":"2016-06-03 04:31:57.000000000","message":"It is not a hack. There is no such accelerator naming service yet so I can only make the design based on existing code. What I need to consider is giving the reason why I do not invoke the  naming service and keeping the scalability for future extension.\n\nFor mapping accelerator with VM, it is dependent what FPGA resource do you attached. First, it allows user to attached multiple accelerator binary or devices into one VM in parallel as you see it is a list in the API. Second it allows users to reload other accelerator function into the device if it is compatible. Third, before the accelerator naming service inside OpenStack comes true, yes it is the users responsibility to specify a accelerator_binary_id if he uses Nova restful API, or it is the responsibility of dashboard UI to do the filtering for user and let user make the final decision. I am not against the advantage of accelerator naming service. The propose here are only based on existing code, and based on the explanation of why I don\u0027t think the naming service should be in Nova.\n\nMy proposal dose not only support provisioning entire FPGA to VM. Like the first comments I reply in patch set 3, regions or slot can be exposed as VF in SR-IOV, or even a separated PCI device. It is transparent to OpenStack. Whether to use the entire FPGA is controlled by the accelerator binary itself. There is no technical method to allow you to specify a binary to be loaded to somewhere inside FPGA.\n\nOf course we need to check it is a right binary for the hardware. As I proposed, extra information is added with the binary when uploaded to Glance. It is cloud provider\u0027s job to make it correct.\n\nIn my spec, there are two places to matching the hardware and binary. First it is explicitly list in a Nova scheduler filter. It read Nova DB and read accelerator binary properties from Glance and do the matching. Second it is in the proposed Nova server update API. Inside the implementation, it dose the matching using same method above.\n\nThe logic for the executing the programming/reloading is in the VM instance driver. The Nova server update API not only change the Nova DB, but also call a function in the instance driver to do the programming. In nova.conf, we have specified a programming executor binary to do the accelerator binary programming.","commit_id":"2910fdb1159bb5db303d0cdf9962ef2d450bdf2e"},{"author":{"_account_id":22063,"name":"Fei Chen","email":"uchen@cn.ibm.com","username":"chenfei"},"change_message_id":"71ff4d58db918338ace0f3a235ddb1346b622c1d","unresolved":false,"context_lines":[{"line_number":240,"context_line":""},{"line_number":241,"context_line":"    JSON schema definition for the response body data: Unchanged"},{"line_number":242,"context_line":""},{"line_number":243,"context_line":""},{"line_number":244,"context_line":"Security impact"},{"line_number":245,"context_line":"---------------"},{"line_number":246,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"9abb7d3a_47ea40ad","line":243,"in_reply_to":"9abb7d3a_a6cd0eb9","updated":"2016-06-01 05:08:52.000000000","message":"Let\u0027s decouple the discussion. First, assuming in future we have the service or API to do matching on \"accelerator_name\" to \"accelerator_somewhere_binary_id\", no matter this service is in  Nova or other reliant service, the proposal here still works. What you have to change in this API is changing the \"accelerator_glance_id\" to \"accelerator_name\". \n\nThen in Nova scheduler, it calls the service API like return_ture_or_not(accelerator_name, host_name) so that the Nova scheduler know whether we can find a compatible accelerator binary for the host machine. Before or when we do accelerator binary reloading, we call the service API like get_binary_id (accelerator_name, FPGA_device).\n\nSecond, let\u0027s discuss whether we should put this service in Nova. Assuming it is in Nova, when a user upload a binary to OpenStack for the accelerator \"jpg_decoder\" which already have multiple binaries implementation like \"jpg_decoder_binary1\" and \"jpg_decoder_binary2\". It is not Nova\u0027s job to do the binaries storage right? so the user is calling a Glance (let\u0027s to the assumption here) API to do the uploading. However, to provide the service mentioned above in Nova, Nova have to keep the information like \"jpg_decoder : [xxx_glance_id1, xxx_glance_id2, ...] inside Nova DB. Do we really wan\u0027t to couple the DB relationship between Glance and Nova? So I guess we still want to keep such relationship inside Glance DB(if we proposal a patch to Glance). Then my proposal here will call the new Glance API like I explain above.","commit_id":"2910fdb1159bb5db303d0cdf9962ef2d450bdf2e"},{"author":{"_account_id":13692,"name":"Roman Dobosz","email":"gryf73@gmail.com","username":"gryf"},"change_message_id":"28309ba588fa1c86671ae374603b397a8cdbf00e","unresolved":false,"context_lines":[{"line_number":240,"context_line":""},{"line_number":241,"context_line":"    JSON schema definition for the response body data: Unchanged"},{"line_number":242,"context_line":""},{"line_number":243,"context_line":""},{"line_number":244,"context_line":"Security impact"},{"line_number":245,"context_line":"---------------"},{"line_number":246,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"9abb7d3a_a6cd0eb9","line":243,"in_reply_to":"9abb7d3a_d1dbb24d","updated":"2016-05-31 17:07:17.000000000","message":"I agree, that another service or just a library for interaction with FPGA software should exists on compute node.\n\nI disagree, there should not exists any kind of abstraction layer for matching binary (IP) with device (or slot/region). There should be a way to tell Nova scheduler: \"Hey, give me all hosts capable of (potentially) accelerating JPG!\", which means more or less a possible host capability named \"fpga\" or already reported existence of needed accelerator resource named i.e. \"fpga_jpg_v2\" (or whatever convention we would agree on) with available context.\n\nThe latter case is straightforward, and IMO should take precedence, so that other accelerators can be programmed on unused slots.\n\nAs for the first case, filter would look for \"jpg\", \"jpg_v2\" or \"jpg_v3\" (again, this is just an example), and get list of all images from glance which match that metadata, and match it up with corresponding images (also stored in metadata). That way it is possible to select wider range of possible candidates to program binary to, than just the exactly one by creating flavor with metadata \"device_name:accelerator_glance_id\". This pattern can be also used for slots - so that right binary can be selected in case of partial reconfiguration.\n\nIf we can match specific accelerator binary with specific device, it is not so hard to make it a little bit more flexible, IMHO.","commit_id":"2910fdb1159bb5db303d0cdf9962ef2d450bdf2e"},{"author":{"_account_id":22118,"name":"Harm Sluiman","email":"harm.sluiman@gmail.com","username":"HarmSluiman"},"change_message_id":"9e09d69294586183a6edea09be9f42b6bcde3023","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"9abb7d3a_e7caf819","updated":"2016-06-02 13:04:26.000000000","message":"This is a great initiative and I am glad to see it.\n\nThere is a use case that needs to be considered however that is missing, and that is when the FPGA is partitioned or virtualized. We can have a discussion off line if you like for more detail than is appropriate for a review comment, but let me give two examples to consider. I think they can be easily handled from a specification point of view.\n\nThe first is an SR-IOV scenario where the device PCI attached device can be divided into several logical functions and each accessed like a separate PCI device.This is a common use case but is more about function access management and configuration.\n\nThe second and more interesting here (IMO) is that the FPGA can be loaded with a kernel or shell that maintains isolation etc. and supports separate bitstream being loaded in each logical region. Similar to a hypervisor loading multiple VM images. This scenario is often call Partial Reconfiguration and impacts your support for specifying the bitstream to be used at PUT or POST time. So the shell may be loaded when a hypervisor is deployed, perhaps by IRONIC, and the functional bitstream you are thinking about here are loaded as discussed here through Nova.\n\nPerhaps not all FPGA devices or configurations can support this and this will have to be considered when defining the device meta data.","commit_id":"db1af73d5a20a90e5737b0d1605ae5ef51b6adfa"},{"author":{"_account_id":22063,"name":"Fei Chen","email":"uchen@cn.ibm.com","username":"chenfei"},"change_message_id":"2979a6ec2e011fe1e19ca0779bc8ffa683a6f2aa","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"9abb7d3a_da5afe4f","in_reply_to":"9abb7d3a_e7caf819","updated":"2016-06-03 03:30:17.000000000","message":"That are good points and you are right they are shining points of FPGA. Actually the proposal do not stop using SR-IOV and partial reconfiguration. It is just to say not support partial reconfiguration like some expectation. I use partial reconfiguration for a long long time, and would like to have more discussion with you offline.\n\nFor SR-IOV, normally only the VF is pass through to the KVM instance. In host it can be treated as a normally PCI device because the VF has its own PCI function number. After resource detection (manually configure the Nova.conf or provide a detecting binary like I explain bellow), it is transparent to OpenStack to deal with the PCI device. Their is existing code in OpenStack to do the PCI pass through. What I need is just to provide some extra information to Nova to say it is a fpga device. That\u0027s why I don\u0027t think my proposal have to deal with the SR-IOV.\n\nFor partial reconfiguration, since the region/slot information is not exposed to Linux if you don\u0027t map the region/slot as a separated PCIe device, PF or VF. In this case, you have to use extra service to do the region/slot management. Technically you can but you have to consider whether to put it into OpenStack.\n\nIf you map the re-configurable region as a device, PF or VF, like I explain above, it is transparent to OpenStack so the proposal don\u0027t have to deal with it specially.\n\nIf you manage the regions with other service, for example, I combine one accelerator function but different binaries for different regions in one FPGA onto one big xxx_binary. Inside this xxx_binary, there is enough extra information embedded to provide to the FPGA-binary-loader to decide which region is used. I only need to upload the big xxx_binary to Glance. Anyway, in my opinion, all this should be transparent to Nova.","commit_id":"db1af73d5a20a90e5737b0d1605ae5ef51b6adfa"},{"author":{"_account_id":13692,"name":"Roman Dobosz","email":"gryf73@gmail.com","username":"gryf"},"change_message_id":"f3f05d6e12901696513cd38935cee10038509fe1","unresolved":false,"context_lines":[{"line_number":141,"context_line":"   The above information has priority. For example, when the \"detect_bin\" is"},{"line_number":142,"context_line":"   valid, \"chip\" and \"firmware\" are not needed because it can return all"},{"line_number":143,"context_line":"   necessary information. Some information is optional in some case. For"},{"line_number":144,"context_line":"   example the \"device\" is needed for container use case but not needed for"},{"line_number":145,"context_line":"   PCI pass through in KVM use case. Nova resource tracking code is changed"},{"line_number":146,"context_line":"   to do resource detection according to the ``fpga_devices`` section in"},{"line_number":147,"context_line":"   ``nova.conf``. Some FPGA binary tool can be specified in ``nova.conf`` to"}],"source_content_type":"text/x-rst","patch_set":3,"id":"9abb7d3a_4a394441","line":144,"range":{"start_line":144,"start_character":38,"end_line":144,"end_character":56},"updated":"2016-06-02 14:30:36.000000000","message":"Saying \"container use case\" what exactly do you have in mind? I\u0027m not aware of any officially supported container drivers by Nova…","commit_id":"db1af73d5a20a90e5737b0d1605ae5ef51b6adfa"},{"author":{"_account_id":22063,"name":"Fei Chen","email":"uchen@cn.ibm.com","username":"chenfei"},"change_message_id":"2979a6ec2e011fe1e19ca0779bc8ffa683a6f2aa","unresolved":false,"context_lines":[{"line_number":141,"context_line":"   The above information has priority. For example, when the \"detect_bin\" is"},{"line_number":142,"context_line":"   valid, \"chip\" and \"firmware\" are not needed because it can return all"},{"line_number":143,"context_line":"   necessary information. Some information is optional in some case. For"},{"line_number":144,"context_line":"   example the \"device\" is needed for container use case but not needed for"},{"line_number":145,"context_line":"   PCI pass through in KVM use case. Nova resource tracking code is changed"},{"line_number":146,"context_line":"   to do resource detection according to the ``fpga_devices`` section in"},{"line_number":147,"context_line":"   ``nova.conf``. Some FPGA binary tool can be specified in ``nova.conf`` to"}],"source_content_type":"text/x-rst","patch_set":3,"id":"9abb7d3a_5fbe00d5","line":144,"range":{"start_line":144,"start_character":38,"end_line":144,"end_character":56},"in_reply_to":"9abb7d3a_4a394441","updated":"2016-06-03 03:30:17.000000000","message":"I understand Nova do not officially support container case like Novadocker anymore. While as I explain, the proposal dose not touch much detail about hypervisor driver but want to keep sufficient scalability. Here not all information is mandatory if the responding hypervisor do not support the architecture.\n\nWhile multiple devices being attached as one group of device still need to be supported. You know sometimes one FPGA is configured with multiple PCI device number and/or multiple PCI function number. From Linux perspective, they are multiple PCI device. In the case to provide one entire function with multiple devices, like in SR-IOV you want to attach a common VF for binary reloading and separated VF for accelerator function, you have to tell Nova they are a group of devices.","commit_id":"db1af73d5a20a90e5737b0d1605ae5ef51b6adfa"},{"author":{"_account_id":22118,"name":"Harm Sluiman","email":"harm.sluiman@gmail.com","username":"HarmSluiman"},"change_message_id":"c8ce0123c29ccccac2c58ef6084642a6fdce65c1","unresolved":false,"context_lines":[{"line_number":216,"context_line":"    URL for the resource: Unchanged"},{"line_number":217,"context_line":"    Parameters which can be passed via the url: None"},{"line_number":218,"context_line":"    JSON schema definition for the request body data:"},{"line_number":219,"context_line":"    \"fpgaRef\":[{\"device_name\":\"xxxx\", \"binary\":\"glance_id\"},]"},{"line_number":220,"context_line":"    JSON schema definition for the response body data: Unchanged"},{"line_number":221,"context_line":""},{"line_number":222,"context_line":"#. FPGA reload API - Nova update server API is reused to reload a FPGA"}],"source_content_type":"text/x-rst","patch_set":3,"id":"9abb7d3a_806e6d94","line":219,"range":{"start_line":219,"start_character":12,"end_line":219,"end_character":13},"updated":"2016-06-02 14:49:05.000000000","message":"minor point but I guess since it is an array fpgaRefs might be a better label","commit_id":"db1af73d5a20a90e5737b0d1605ae5ef51b6adfa"},{"author":{"_account_id":22063,"name":"Fei Chen","email":"uchen@cn.ibm.com","username":"chenfei"},"change_message_id":"2979a6ec2e011fe1e19ca0779bc8ffa683a6f2aa","unresolved":false,"context_lines":[{"line_number":216,"context_line":"    URL for the resource: Unchanged"},{"line_number":217,"context_line":"    Parameters which can be passed via the url: None"},{"line_number":218,"context_line":"    JSON schema definition for the request body data:"},{"line_number":219,"context_line":"    \"fpgaRef\":[{\"device_name\":\"xxxx\", \"binary\":\"glance_id\"},]"},{"line_number":220,"context_line":"    JSON schema definition for the response body data: Unchanged"},{"line_number":221,"context_line":""},{"line_number":222,"context_line":"#. FPGA reload API - Nova update server API is reused to reload a FPGA"}],"source_content_type":"text/x-rst","patch_set":3,"id":"9abb7d3a_fa2422c7","line":219,"range":{"start_line":219,"start_character":12,"end_line":219,"end_character":13},"in_reply_to":"9abb7d3a_806e6d94","updated":"2016-06-03 03:30:17.000000000","message":"Yes. multiple FPGA device can be attached to one VM instance. I will update it.","commit_id":"db1af73d5a20a90e5737b0d1605ae5ef51b6adfa"},{"author":{"_account_id":22118,"name":"Harm Sluiman","email":"harm.sluiman@gmail.com","username":"HarmSluiman"},"change_message_id":"43445a21217fcb282713aba8a40e840d7e192e7b","unresolved":false,"context_lines":[{"line_number":237,"context_line":""},{"line_number":238,"context_line":"      {"},{"line_number":239,"context_line":"        \"server\":{"},{"line_number":240,"context_line":"          \"device_name\":\"new_fpga_accelerator_glance_id\""},{"line_number":241,"context_line":"        }"},{"line_number":242,"context_line":"      }"},{"line_number":243,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"9abb7d3a_523f69b3","line":240,"range":{"start_line":240,"start_character":9,"end_line":240,"end_character":56},"updated":"2016-06-01 20:24:20.000000000","message":"Shouldn\u0027t this be spelled more like the POST?   {\"device_name\":\"xxxx\", \"binary\":\"new_fpa_accelerator_glance_id\"}\n\nor even inside an fpgaref array element?","commit_id":"db1af73d5a20a90e5737b0d1605ae5ef51b6adfa"},{"author":{"_account_id":22118,"name":"Harm Sluiman","email":"harm.sluiman@gmail.com","username":"HarmSluiman"},"change_message_id":"c8ce0123c29ccccac2c58ef6084642a6fdce65c1","unresolved":false,"context_lines":[{"line_number":237,"context_line":""},{"line_number":238,"context_line":"      {"},{"line_number":239,"context_line":"        \"server\":{"},{"line_number":240,"context_line":"          \"device_name\":\"new_fpga_accelerator_glance_id\""},{"line_number":241,"context_line":"        }"},{"line_number":242,"context_line":"      }"},{"line_number":243,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"9abb7d3a_a0c3b189","line":240,"range":{"start_line":240,"start_character":9,"end_line":240,"end_character":56},"in_reply_to":"9abb7d3a_0e0e50e4","updated":"2016-06-02 14:49:05.000000000","message":"Just a suggestion but perhaps something like this\n{\n\"server\":{\n    \"fpgaRefs\":[\n        {\"device_name\":\"xxxx\", \"binary\":\"update_glance_id\"}\n\n               ]\n         }\n}","commit_id":"db1af73d5a20a90e5737b0d1605ae5ef51b6adfa"},{"author":{"_account_id":22063,"name":"Fei Chen","email":"uchen@cn.ibm.com","username":"chenfei"},"change_message_id":"f30e67d3cb082d28424a34e01c240bf593ee0b2d","unresolved":false,"context_lines":[{"line_number":237,"context_line":""},{"line_number":238,"context_line":"      {"},{"line_number":239,"context_line":"        \"server\":{"},{"line_number":240,"context_line":"          \"device_name\":\"new_fpga_accelerator_glance_id\""},{"line_number":241,"context_line":"        }"},{"line_number":242,"context_line":"      }"},{"line_number":243,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"9abb7d3a_df919548","line":240,"range":{"start_line":240,"start_character":9,"end_line":240,"end_character":56},"in_reply_to":"9abb7d3a_523f69b3","updated":"2016-06-02 02:27:28.000000000","message":"Current OpenStack update server API is a PUT API, I plan to reused it. Here the device_name is variable but not a constant. So it means reloading the device with a new binary from Glance.","commit_id":"db1af73d5a20a90e5737b0d1605ae5ef51b6adfa"},{"author":{"_account_id":22063,"name":"Fei Chen","email":"uchen@cn.ibm.com","username":"chenfei"},"change_message_id":"2979a6ec2e011fe1e19ca0779bc8ffa683a6f2aa","unresolved":false,"context_lines":[{"line_number":237,"context_line":""},{"line_number":238,"context_line":"      {"},{"line_number":239,"context_line":"        \"server\":{"},{"line_number":240,"context_line":"          \"device_name\":\"new_fpga_accelerator_glance_id\""},{"line_number":241,"context_line":"        }"},{"line_number":242,"context_line":"      }"},{"line_number":243,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"9abb7d3a_1a2c86aa","line":240,"range":{"start_line":240,"start_character":9,"end_line":240,"end_character":56},"in_reply_to":"9abb7d3a_a0c3b189","updated":"2016-06-03 03:30:17.000000000","message":"I will update it.","commit_id":"db1af73d5a20a90e5737b0d1605ae5ef51b6adfa"},{"author":{"_account_id":22063,"name":"Fei Chen","email":"uchen@cn.ibm.com","username":"chenfei"},"change_message_id":"c6bfb0db6de8d03ea5524088b28322f37506ba7e","unresolved":false,"context_lines":[{"line_number":237,"context_line":""},{"line_number":238,"context_line":"      {"},{"line_number":239,"context_line":"        \"server\":{"},{"line_number":240,"context_line":"          \"device_name\":\"new_fpga_accelerator_glance_id\""},{"line_number":241,"context_line":"        }"},{"line_number":242,"context_line":"      }"},{"line_number":243,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"9abb7d3a_0e0e50e4","line":240,"range":{"start_line":240,"start_character":9,"end_line":240,"end_character":56},"in_reply_to":"9abb7d3a_df4cf59f","updated":"2016-06-02 03:26:24.000000000","message":"Since the device_name is unchangeable when it is attached, so the action has unique meaning. But you are right, to make the coding style more clear, it is better to use more key-value to describe the action, and use more structure to describe when dealing with multiple devices. I will update the Spec in next patch.","commit_id":"db1af73d5a20a90e5737b0d1605ae5ef51b6adfa"},{"author":{"_account_id":22118,"name":"Harm Sluiman","email":"harm.sluiman@gmail.com","username":"HarmSluiman"},"change_message_id":"33837faf88d17d6bd5749947f0c7291d7160de4b","unresolved":false,"context_lines":[{"line_number":237,"context_line":""},{"line_number":238,"context_line":"      {"},{"line_number":239,"context_line":"        \"server\":{"},{"line_number":240,"context_line":"          \"device_name\":\"new_fpga_accelerator_glance_id\""},{"line_number":241,"context_line":"        }"},{"line_number":242,"context_line":"      }"},{"line_number":243,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"9abb7d3a_df4cf59f","line":240,"range":{"start_line":240,"start_character":9,"end_line":240,"end_character":56},"in_reply_to":"9abb7d3a_df919548","updated":"2016-06-02 02:38:17.000000000","message":"Certainly agree to use PUT. That is the correct restful semantic.\nYour POST allows for an array of devices, each with a name and potentially unique bitstream and all associated with one VM\nso\nyour PUT needs to identify which device in the range and the appropriate bitstream\nperhaps I am reading your JSON syntax wrong but your current example says update the service component that has a device name of the new glance id.","commit_id":"db1af73d5a20a90e5737b0d1605ae5ef51b6adfa"}]}