)]}'
{"specs/rocky/approved/provider-config-file.rst":[{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"70272da61d4141245a88e48f31137c38c666fa9d","unresolved":false,"context_lines":[{"line_number":76,"context_line":"    # where all $MINOR increments are backwards-compatible with"},{"line_number":77,"context_line":"    # all versions before it in the $MAJOR number"},{"line_number":78,"context_line":"    schema_version: 1.0"},{"line_number":79,"context_line":"    # An optional override for the provider\u0027s UUID. If set, the agent responsible"},{"line_number":80,"context_line":"    # for setting traits and inventory attributes will use this value when"},{"line_number":81,"context_line":"    # creating a new provider record"},{"line_number":82,"context_line":"    uuid: b0d8feb1-1389-4c61-b8a8-52030847da27"},{"line_number":83,"context_line":"    # An optional override for the provider\u0027s unique name. If set, the agent responsible"},{"line_number":84,"context_line":"    # for setting traits and inventory attributes will use this value when"}],"source_content_type":"text/x-rst","patch_set":2,"id":"df7087c5_49637f1b","line":81,"range":{"start_line":79,"start_character":4,"end_line":81,"end_character":36},"updated":"2018-03-08 17:12:21.000000000","message":"How does the agent know _which_ RP this override file is targeting? First I thought it will be the uuid from this file that needs to match with the RP uuid, but the comment says that this uuid will override the RP uuid instead. Or is it something that needs to be handled per agent? \n\nAnyhow it would be nice to see a usage example of this file even if this spec does not target any particular usage of this file.","commit_id":"f8b794020c2549b080076fa513ecaebd1be00b03"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"031184f3256c392d132c366d0a58757d694b5251","unresolved":false,"context_lines":[{"line_number":76,"context_line":"    # where all $MINOR increments are backwards-compatible with"},{"line_number":77,"context_line":"    # all versions before it in the $MAJOR number"},{"line_number":78,"context_line":"    schema_version: 1.0"},{"line_number":79,"context_line":"    # An optional override for the provider\u0027s UUID. If set, the agent responsible"},{"line_number":80,"context_line":"    # for setting traits and inventory attributes will use this value when"},{"line_number":81,"context_line":"    # creating a new provider record"},{"line_number":82,"context_line":"    uuid: b0d8feb1-1389-4c61-b8a8-52030847da27"},{"line_number":83,"context_line":"    # An optional override for the provider\u0027s unique name. If set, the agent responsible"},{"line_number":84,"context_line":"    # for setting traits and inventory attributes will use this value when"}],"source_content_type":"text/x-rst","patch_set":2,"id":"df7087c5_6b92bca0","line":81,"range":{"start_line":79,"start_character":4,"end_line":81,"end_character":36},"in_reply_to":"df7087c5_49637f1b","updated":"2018-03-12 12:29:05.000000000","message":"I looked at the usage example for compute UUID override. It already notes this problem of ambiguity in the general case. I think we have to solve this ambiguity here in the generic spec.  See my comment also in https://review.openstack.org/#/c/551315/1/specs/rocky/approved/override-compute-node-uuid.rst@110","commit_id":"f8b794020c2549b080076fa513ecaebd1be00b03"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"b1a474078ee6b2e2b94aac0cb5a66e2ce2166f35","unresolved":false,"context_lines":[{"line_number":76,"context_line":"    # where all $MINOR increments are backwards-compatible with"},{"line_number":77,"context_line":"    # all versions before it in the $MAJOR number"},{"line_number":78,"context_line":"    schema_version: 1.0"},{"line_number":79,"context_line":"    # An optional override for the provider\u0027s UUID. If set, the agent responsible"},{"line_number":80,"context_line":"    # for setting traits and inventory attributes will use this value when"},{"line_number":81,"context_line":"    # creating a new provider record"},{"line_number":82,"context_line":"    uuid: b0d8feb1-1389-4c61-b8a8-52030847da27"},{"line_number":83,"context_line":"    # An optional override for the provider\u0027s unique name. If set, the agent responsible"},{"line_number":84,"context_line":"    # for setting traits and inventory attributes will use this value when"}],"source_content_type":"text/x-rst","patch_set":2,"id":"df7087c5_4bcb381d","line":81,"range":{"start_line":79,"start_character":4,"end_line":81,"end_character":36},"in_reply_to":"df7087c5_6b92bca0","updated":"2018-03-12 12:48:58.000000000","message":"@gibi: I deliberately did not want to add logic around making the filename need to match the UUID override or name override value. I wanted to leave it up to the agent/driver to determine how best to use the information in the file.\n\nFor libvirt compute hosts, one solution is to have a CONF option called provider_config_path (or provider_descriptor_path or similar) that the virt driver or resource tracker can read for the local host. Another solution for virt drivers that deal with multiple resource nodes would be to have a directory, identified with a CONF.provider_config_dir (or similar) config option that the agent would read all the files in that directory for override information about multiple providers.\n\nI don\u0027t believe the schema of the provider config file needs to change based on these proposed *uses* of the provider config file and I don\u0027t believe it would be wise to decribe more than a single provider in each file.","commit_id":"f8b794020c2549b080076fa513ecaebd1be00b03"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"d764a85c54ef2c9e1ef79d0e13169419bd837e16","unresolved":false,"context_lines":[{"line_number":127,"context_line":"            min_unit: 100"},{"line_number":128,"context_line":"            max_unit: 1000"},{"line_number":129,"context_line":"            step_size: 100"},{"line_number":130,"context_line":"            allocation_ratio: 1.0"},{"line_number":131,"context_line":""},{"line_number":132,"context_line":"    # The traits element describes overrides for the provider\u0027s collection of traits."},{"line_number":133,"context_line":"    traits:"}],"source_content_type":"text/x-rst","patch_set":2,"id":"bf659307_55e2ed30","line":130,"updated":"2018-03-28 14:22:08.000000000","message":"While I like that idea, I think the problem is about operators understanding that YAML file and be able to modify it.\n\nFor example, say my compute node is having multiple nvidia physical GPU devices. How could I say that \u0027this\u0027 PCI device is \u0027that\u0027 RP UUID ?\n\nThat\u0027s why I think we should just leave the virt driver discovering by itself the Resource Providers, but just using a specific YAML file for specific things.","commit_id":"f8b794020c2549b080076fa513ecaebd1be00b03"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"871365272a017ebc4d4bcf81f977407cd30cb6a3","unresolved":false,"context_lines":[{"line_number":127,"context_line":"            min_unit: 100"},{"line_number":128,"context_line":"            max_unit: 1000"},{"line_number":129,"context_line":"            step_size: 100"},{"line_number":130,"context_line":"            allocation_ratio: 1.0"},{"line_number":131,"context_line":""},{"line_number":132,"context_line":"    # The traits element describes overrides for the provider\u0027s collection of traits."},{"line_number":133,"context_line":"    traits:"}],"source_content_type":"text/x-rst","patch_set":2,"id":"bf659307_d0601504","line":130,"in_reply_to":"bf659307_50072583","updated":"2018-03-30 14:40:38.000000000","message":"\u003e While I like that idea, I think the problem is about operators\n \u003e understanding that YAML file and be able to modify it.\n\nI\u0027ll just point out that ops are going to have a much easier time understanding YAML than its equivalent JSON-in-oslo_config.","commit_id":"f8b794020c2549b080076fa513ecaebd1be00b03"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"fc7e94c7a5fa418abe13e9c3adfc5e124321c20a","unresolved":false,"context_lines":[{"line_number":127,"context_line":"            min_unit: 100"},{"line_number":128,"context_line":"            max_unit: 1000"},{"line_number":129,"context_line":"            step_size: 100"},{"line_number":130,"context_line":"            allocation_ratio: 1.0"},{"line_number":131,"context_line":""},{"line_number":132,"context_line":"    # The traits element describes overrides for the provider\u0027s collection of traits."},{"line_number":133,"context_line":"    traits:"}],"source_content_type":"text/x-rst","patch_set":2,"id":"bf659307_50072583","line":130,"in_reply_to":"bf659307_55e2ed30","updated":"2018-03-30 14:22:26.000000000","message":"That\u0027s up to the virt driver. They could look up the resource provider by name (and use, for instance, the PCI address as the name of the resource provider). Or they could simply not use a provider-config YAML file for the devices they only want to auto-discover.\n\nAre you suggesting here that we should add some device_address field or something like that which would allow the virt driver or other subsystem to link a specific host device with a specific resource provider UUID or name?","commit_id":"f8b794020c2549b080076fa513ecaebd1be00b03"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"d764a85c54ef2c9e1ef79d0e13169419bd837e16","unresolved":false,"context_lines":[{"line_number":164,"context_line":"    expressing provider attribute overrides and a separate library for parsing"},{"line_number":165,"context_line":"    this proposed file format. It does **NOT** propose changes to the"},{"line_number":166,"context_line":"    ``nova-compute`` resource tracker, virt driver, PCI manager code or"},{"line_number":167,"context_line":"    anything else. Changes to **use** this new provider YAML file are left to"},{"line_number":168,"context_line":"    other specs if we feel that using a separate provider descriptor file for"},{"line_number":169,"context_line":"    expressing this kind of information is an appropriate path to take."},{"line_number":170,"context_line":""},{"line_number":171,"context_line":"Alternatives"}],"source_content_type":"text/x-rst","patch_set":2,"id":"bf659307_35c0997b","line":168,"range":{"start_line":167,"start_character":19,"end_line":168,"end_character":15},"updated":"2018-03-28 14:22:08.000000000","message":"well, I understand your opinion but I think we still need to discuss how to use that file for understanding what to pass to it.","commit_id":"f8b794020c2549b080076fa513ecaebd1be00b03"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"d764a85c54ef2c9e1ef79d0e13169419bd837e16","unresolved":false,"context_lines":[{"line_number":173,"context_line":""},{"line_number":174,"context_line":"We could continue to use the nova.conf CONF options for allocation ratios and"},{"line_number":175,"context_line":"reserved amounts of CPU/RAM/disk and add new CONF options for overriding a"},{"line_number":176,"context_line":"compute node\u0027s UUID or name."},{"line_number":177,"context_line":""},{"line_number":178,"context_line":"Data model impact"},{"line_number":179,"context_line":"-----------------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"bf659307_95464521","line":176,"updated":"2018-03-28 14:22:08.000000000","message":"sure, but looks like there are other alternatives, like about how the YAML file should be instead.","commit_id":"f8b794020c2549b080076fa513ecaebd1be00b03"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"d764a85c54ef2c9e1ef79d0e13169419bd837e16","unresolved":false,"context_lines":[{"line_number":233,"context_line":"Work Items"},{"line_number":234,"context_line":"----------"},{"line_number":235,"context_line":""},{"line_number":236,"context_line":"* Reach agreement on whether a descriptor file is a good idea at all"},{"line_number":237,"context_line":"* If so, reach agreement on an appropriate schema definition"},{"line_number":238,"context_line":"* Encode the decided schema in the separate ``os-placement`` library"},{"line_number":239,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"bf659307_956f2591","line":236,"updated":"2018-03-28 14:22:08.000000000","message":"I think adding a YAML file is +1 to me. But I\u0027d really want to discuss how to use it by Nova *in the same spec*.","commit_id":"f8b794020c2549b080076fa513ecaebd1be00b03"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"771d91b2e0f6d0bbdeb340a5ce893e943213538f","unresolved":false,"context_lines":[{"line_number":233,"context_line":"Work Items"},{"line_number":234,"context_line":"----------"},{"line_number":235,"context_line":""},{"line_number":236,"context_line":"* Reach agreement on whether a descriptor file is a good idea at all"},{"line_number":237,"context_line":"* If so, reach agreement on an appropriate schema definition"},{"line_number":238,"context_line":"* Encode the decided schema in the separate ``os-placement`` library"},{"line_number":239,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"3f79a3b5_1e4f8669","line":236,"in_reply_to":"bf659307_956f2591","updated":"2018-10-12 13:47:35.000000000","message":"BTW, this is exactly the opposite of what you commented on the combined spec from Konstantinos:\n\nhttps://review.openstack.org/#/c/591037/8/specs/stein/approved/device-placement-model.rst@234","commit_id":"f8b794020c2549b080076fa513ecaebd1be00b03"}]}