)]}'
{"specs/liberty/approved/ironic-configdrive-extra-data.rst":[{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"3b5f582a74b4db891a2fbd90cc2f05943afd95fe","unresolved":false,"context_lines":[{"line_number":58,"context_line":"------------"},{"line_number":59,"context_line":"Not a very clear alternative, since the configdrive is supposed to be"},{"line_number":60,"context_line":"used when a metadata service is not present in their environment. But, we"},{"line_number":61,"context_line":"could have a metadata service to serve the node this kinda of information."},{"line_number":62,"context_line":""},{"line_number":63,"context_line":"Data model impact"},{"line_number":64,"context_line":"-----------------"}],"source_content_type":"text/x-rst","patch_set":3,"id":"3ab451fb_4faa1dd6","line":61,"updated":"2015-04-17 16:15:35.000000000","message":"So I need to get my head around this.\n\nCurrently config drive and the metadata service (generally) always hold the same data.\n\nI think you should really look at how to get this information into the metadata service, and see how that naturally flows from their into config drive.\n\nI have to admit that is a much complicated patch, but I worry about only implementing the feature for half of our deployment scenarios. Although maybe the metadata services is quite problematic for ironic in most deploy scenarios.\n\nIt would be great to discuss this here, even if we don\u0027t implement this.\n\nI am assuming this is not already available via the metadata service?","commit_id":"699e060fefac8c62e2454c485f0410b09d7f6cc1"},{"author":{"_account_id":6773,"name":"Lucas Alvares Gomes","email":"lucasagomes@gmail.com","username":"lucasagomes"},"change_message_id":"fed6cd658e16ebe9821c680551b3e220b9d4699f","unresolved":false,"context_lines":[{"line_number":58,"context_line":"------------"},{"line_number":59,"context_line":"Not a very clear alternative, since the configdrive is supposed to be"},{"line_number":60,"context_line":"used when a metadata service is not present in their environment. But, we"},{"line_number":61,"context_line":"could have a metadata service to serve the node this kinda of information."},{"line_number":62,"context_line":""},{"line_number":63,"context_line":"Data model impact"},{"line_number":64,"context_line":"-----------------"}],"source_content_type":"text/x-rst","patch_set":3,"id":"dac4157f_8d772302","line":61,"in_reply_to":"3ab451fb_4faa1dd6","updated":"2015-04-20 08:45:14.000000000","message":"Hi John,\n\nYeah it\u0027s not available via the metadata service. This is spec is more a reflect of what I do right now which relies on the configdrive so that\u0027s why the scope was really constrained. But, I understand and even like that nova wants to keep the consistency of the data between the config drive and metadata service, I will look into how I can do this and update the spec accordingly.\n\nThanks for the suggestion","commit_id":"699e060fefac8c62e2454c485f0410b09d7f6cc1"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"f5cf6f55010f336ef5fd1deacbfc7c270f512c41","unresolved":false,"context_lines":[{"line_number":118,"context_line":"Dependencies"},{"line_number":119,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":120,"context_line":""},{"line_number":121,"context_line":"None"},{"line_number":122,"context_line":""},{"line_number":123,"context_line":""},{"line_number":124,"context_line":"Testing"}],"source_content_type":"text/x-rst","patch_set":3,"id":"7aaa499b_39a0e642","line":121,"updated":"2015-04-15 11:23:49.000000000","message":"How does this idea related to the already approved spec:\nhttp://specs.openstack.org/openstack/nova-specs/specs/kilo/approved/use-configdrive-with-ironic.html\n\nand this one:\nhttp://specs.openstack.org/openstack/nova-specs/specs/kilo/approved/metadata-service-network-info.html","commit_id":"699e060fefac8c62e2454c485f0410b09d7f6cc1"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"3b5f582a74b4db891a2fbd90cc2f05943afd95fe","unresolved":false,"context_lines":[{"line_number":118,"context_line":"Dependencies"},{"line_number":119,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":120,"context_line":""},{"line_number":121,"context_line":"None"},{"line_number":122,"context_line":""},{"line_number":123,"context_line":""},{"line_number":124,"context_line":"Testing"}],"source_content_type":"text/x-rst","patch_set":3,"id":"3ab451fb_d446c0be","line":121,"in_reply_to":"7aaa499b_0e015b6a","updated":"2015-04-17 16:15:35.000000000","message":"Ah, thanks for the context. it might be worth adding a note about metadata-service-network-info in the alternatives section.","commit_id":"699e060fefac8c62e2454c485f0410b09d7f6cc1"},{"author":{"_account_id":6773,"name":"Lucas Alvares Gomes","email":"lucasagomes@gmail.com","username":"lucasagomes"},"change_message_id":"ca950fb1d37fddf1bccb2fe12bc2539866398c45","unresolved":false,"context_lines":[{"line_number":118,"context_line":"Dependencies"},{"line_number":119,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":120,"context_line":""},{"line_number":121,"context_line":"None"},{"line_number":122,"context_line":""},{"line_number":123,"context_line":""},{"line_number":124,"context_line":"Testing"}],"source_content_type":"text/x-rst","patch_set":3,"id":"7aaa499b_0e015b6a","line":121,"in_reply_to":"7aaa499b_39a0e642","updated":"2015-04-15 12:27:17.000000000","message":"Hi John, thanks for the review.\n\n* Use-config-drive-with-ironic: This work have been implemented in Kilo (https://review.openstack.org/#/c/144792). This spec is an extension of the Kilo work which allows an operator managing Ironic nodes to inject extra metadata from an Ironic node to the configuration drive, which will then get exposed to the instance and that will be can configure it accordingly to the baremetal node characteristics, if any.\n\n* metadata-service-network-info: This work wasn\u0027t finished in Kilo. This could potentially be extended to do what I\u0027m currently doing for the network use case I have (the one in the Use Cases session). We could have a map between networks and an abstract name for the network interface. But this spec is more than the network use case. It\u0027s suppose to be generic, just like users can do a \"--user-data\" from the nova boot command to get information passed to the configdrive, this spec is meant to have an interface which Ironic operators can also pass information to the configdrive for a particular baremetal machine, so the instance configuration can deal with per-baremetal nodes variations, if any.\n\nThe implementation of this spec is very simple, and it fell into the feature freeze for Kilo in the last cycle. You can take a look at the patch containing the code here: https://review.openstack.org/#/c/145302/\n\nHope this clarifies it a bit,\nLucas","commit_id":"699e060fefac8c62e2454c485f0410b09d7f6cc1"}]}