)]}'
{"nova/objects/fields.py":[{"author":{"_account_id":1063,"name":"Ed Leafe","email":"ed@leafe.com","username":"ed-leafe"},"change_message_id":"d18297465e2beb77495150ced0cac79f3c2ef24a","unresolved":false,"context_lines":[{"line_number":35,"context_line":""},{"line_number":36,"context_line":""},{"line_number":37,"context_line":"# Import fields from oslo.versionedobjects"},{"line_number":38,"context_line":"Boolean \u003d fields.Boolean"},{"line_number":39,"context_line":"BooleanField \u003d fields.BooleanField"},{"line_number":40,"context_line":"UnspecifiedDefault \u003d fields.UnspecifiedDefault"},{"line_number":41,"context_line":"IntegerField \u003d fields.IntegerField"}],"source_content_type":"text/x-python","patch_set":6,"id":"dab17558_05352745","line":38,"range":{"start_line":38,"start_character":0,"end_line":38,"end_character":24},"updated":"2016-05-13 17:39:09.000000000","message":"This (and String below) should be in the section below, where the different types are defined.","commit_id":"25eff94d32f029db0f77320429db26061cecc2c8"},{"author":{"_account_id":8213,"name":"Claudiu Belu","email":"claudiu.belu@canonical.com","username":"claudiub"},"change_message_id":"2492150e4da3cbd28ef2cb1cb074eaf430d6e5d1","unresolved":false,"context_lines":[{"line_number":35,"context_line":""},{"line_number":36,"context_line":""},{"line_number":37,"context_line":"# Import fields from oslo.versionedobjects"},{"line_number":38,"context_line":"Boolean \u003d fields.Boolean"},{"line_number":39,"context_line":"BooleanField \u003d fields.BooleanField"},{"line_number":40,"context_line":"UnspecifiedDefault \u003d fields.UnspecifiedDefault"},{"line_number":41,"context_line":"IntegerField \u003d fields.IntegerField"}],"source_content_type":"text/x-python","patch_set":6,"id":"dab17558_d4358e46","line":38,"range":{"start_line":38,"start_character":0,"end_line":38,"end_character":24},"in_reply_to":"dab17558_05352745","updated":"2016-05-13 20:03:06.000000000","message":"yeah, you\u0027re right, I have no idea why I\u0027ve put them here.","commit_id":"25eff94d32f029db0f77320429db26061cecc2c8"}],"nova/objects/host_capabilities.py":[{"author":{"_account_id":1779,"name":"Daniel Berrange","email":"berrange@redhat.com","username":"berrange"},"change_message_id":"cae8ca0c227631739dae5a7cbb9b0c1a89ff1c0e","unresolved":false,"context_lines":[{"line_number":36,"context_line":"            fields.Boolean(), nullable\u003dTrue),"},{"line_number":37,"context_line":""},{"line_number":38,"context_line":"        \u0027hw_machine_type\u0027: fields.ListSingleCapabilityField("},{"line_number":39,"context_line":"            fields.List(fields.String()), nullable\u003dTrue),"},{"line_number":40,"context_line":""},{"line_number":41,"context_line":"        # host is SR-IOV enabled."},{"line_number":42,"context_line":"        \u0027hw_sriov\u0027: fields.CapabilityField("}],"source_content_type":"text/x-python","patch_set":4,"id":"7af24918_2931580c","line":39,"range":{"start_line":39,"start_character":55,"end_line":39,"end_character":57},"updated":"2016-03-01 16:45:15.000000000","message":"The list of valid machine types various according to the guest architecture. The supported_hv_specs field enumerates multiple possible guest architectures. ie qemu can run aarch64 guests on an x86_64 host via its emulation facility. So we really need to associate the machine types with the architecture.\n\nFor that matter a number of the other features you lists here against the host, will potentially differ per guest architecture, so I think we need a much more structured format here. The HostCapabilities should only list things that are truly specific to the host.  We should have a GuestCapabilities which lists things that can vary per guest type","commit_id":"5bbe18983ff90dc11d7ccdd2b50cc3da1bb5ccc2"},{"author":{"_account_id":1779,"name":"Daniel Berrange","email":"berrange@redhat.com","username":"berrange"},"change_message_id":"a4c48732c972686ffc56f2e4f91f0e2bf758d73a","unresolved":false,"context_lines":[{"line_number":36,"context_line":"            fields.Boolean(), nullable\u003dTrue),"},{"line_number":37,"context_line":""},{"line_number":38,"context_line":"        \u0027hw_machine_type\u0027: fields.ListSingleCapabilityField("},{"line_number":39,"context_line":"            fields.List(fields.String()), nullable\u003dTrue),"},{"line_number":40,"context_line":""},{"line_number":41,"context_line":"        # host is SR-IOV enabled."},{"line_number":42,"context_line":"        \u0027hw_sriov\u0027: fields.CapabilityField("}],"source_content_type":"text/x-python","patch_set":4,"id":"7af24918_d6e661b3","line":39,"range":{"start_line":39,"start_character":55,"end_line":39,"end_character":57},"in_reply_to":"7af24918_187944fd","updated":"2016-03-02 09:40:32.000000000","message":"The hw_machine_type really isn\u0027t used in a wildly different way. It really is the same concept on both cases. What is different is that QEMU can support multiple architectures, where as hyperv can only support a single architecture per host.  This is already taken into account in the way compute drivers report that capabilities via the HVSpecs data.\n\nEven for hyperv this proposed HostCapabilities is not good enough. Per your spec, the vTPM feature is *only* usable if you have set hw_machine_type\u003dhyperv-gen2.  We really need to express that constraint properly in this capabilities information. The only way todo this is as I suggested with a GuestCapabilities object assocaition.\n\neg, I suggest we need\n\n\nclass GuestCapabilities(VersionedOjbject)\n   fields \u003d {\n        \u0027arch\u0027: fields.ArchitectureField(),\n        \u0027hv_type\u0027: fields.HVTypeField(),\n        \u0027vm_mode\u0027: fields.VMModeField(),\n        \u0027os_vtpm\u0027: fields.OptionalCapabilityField(\n            fields.Boolean(), nullable\u003dTrue),\n        \u0027os_secure_boot\u0027: fields.OptionalCapabilityField(\n            fields.Boolean(), nullable\u003dTrue),\n         ...other guest specific fields...\n    }\n\nclass HostCapabilties(VersionedObject)\n   fields \u003d {\n        \"guests\": fields.ListOfObjectsField(\"GuestCapabilties\")\n\n        \u0027hw_sriov\u0027: fields.CapabilityField(\n            fields.Boolean(), nullable\u003dTrue),\n\n        ....other fields independant of guest type...\n   }","commit_id":"5bbe18983ff90dc11d7ccdd2b50cc3da1bb5ccc2"},{"author":{"_account_id":8213,"name":"Claudiu Belu","email":"claudiu.belu@canonical.com","username":"claudiub"},"change_message_id":"bd3e6f617faaae5e580aefa175fa6ab5e5e98473","unresolved":false,"context_lines":[{"line_number":36,"context_line":"            fields.Boolean(), nullable\u003dTrue),"},{"line_number":37,"context_line":""},{"line_number":38,"context_line":"        \u0027hw_machine_type\u0027: fields.ListSingleCapabilityField("},{"line_number":39,"context_line":"            fields.List(fields.String()), nullable\u003dTrue),"},{"line_number":40,"context_line":""},{"line_number":41,"context_line":"        # host is SR-IOV enabled."},{"line_number":42,"context_line":"        \u0027hw_sriov\u0027: fields.CapabilityField("}],"source_content_type":"text/x-python","patch_set":4,"id":"7af24918_187944fd","line":39,"range":{"start_line":39,"start_character":55,"end_line":39,"end_character":57},"in_reply_to":"7af24918_2931580c","updated":"2016-03-02 00:44:15.000000000","message":"Oh, I see. It seems that \u0027hw_machine_type\u0027 is used by both Hyper-V and libvirt in wildly different ways. Thanks for mentioning it.\n\nOk, so first of all, we have to figure out how to properly define, report and use this capability.\n\nhw_machine_type is currently only used in Hyper-V and libvirt. For Hyper-V, I can say there are only 2 values of interest at the moment: hyperv-gen1 and hyperv-gen2, which basically translated to a Generation 1 VM and Generation 2 VM (gen 2 VMs are more performant + they can have lots of different features: secure boot, shielding, hot plugging NICs and PCIs, etc.). Basically, Hyper-V can report this capability at the moment as [\u0027hyperv-gen1\u0027] or [\u0027hyperv-gen1\u0027, \u0027hyperv-gen2\u0027], depending on the hypervisor version, and the capability is requested as: \"--property hw_machine_type\u003dhyperv-gen2\"\n\nIt seems that hw_machine_type is used in libvirt as a mapping host-arch\u003dmachine-type. For libvirt, it would make a lot more sense if this would a DictSingleCapabilityField, right? (Dict -\u003e capability reported as a dictionary ; Single -\u003e users can request a single capability from the list / dictionary).\n\nNow, what I don\u0027t currently know, is how exactly would libvirt report this feature? Also, how do you \"request\" this capability? (\"--property hw_machine_type\u003d?\")\n\nWorst case scenario, we\u0027ll have to separate the image property and capability into 2, which is troublesome.\n\n\nAs for the second part, you are partly right: almost all capabilities defined here have to be supported by the guest OS, but the hypervisor must also be able to offer that capability. And there are plenty of examples in this category, where the capability must be supported by both hypervisor and guest OS.\n\nFor example os_secure_boot: On Hyper-V, this feature can only be used in Windows / Hyper-V Server 2012 R2 for Windows guests, while in Hyper-V Server 2016, both Windows and Linux guests can start with Secure Boot enabled; while instances with os_shielded_vms enabled can only be spawned on Guarded Hyper-V hosts, and so on. As a rule of thumb, newer features require newer OSes.\n\nWhile GuestCapabilities object models sound like a great idea, I believe it can easily become a complex problem to solve, as the GuestCapabilities can vary wildly from OS to OS, from hypervisor to hypervisor, from hypervisor version to hypervisor version, as it mentioned earlier (e.g. os_secure_boot). And it is outside the scope of this blueprint.","commit_id":"5bbe18983ff90dc11d7ccdd2b50cc3da1bb5ccc2"},{"author":{"_account_id":8213,"name":"Claudiu Belu","email":"claudiu.belu@canonical.com","username":"claudiub"},"change_message_id":"65ed018cd45d1437b4edacf26afc7dbad836d277","unresolved":false,"context_lines":[{"line_number":59,"context_line":"        \u0027os_vram\u0027: n_fields.HyperVRemoteFXVramCapabilityField(),"},{"line_number":60,"context_line":"    }"},{"line_number":61,"context_line":""},{"line_number":62,"context_line":"    request_dependencies \u003d {"},{"line_number":63,"context_line":"        \u0027os_secure_boot\u0027: ["},{"line_number":64,"context_line":"            n_fields.HyperVMachineTypeDependency(\u0027hw_machine_type\u0027)],"},{"line_number":65,"context_line":"        \u0027os_vtpm\u0027: ["}],"source_content_type":"text/x-python","patch_set":5,"id":"dab17558_348503ad","line":62,"updated":"2016-05-09 12:18:13.000000000","message":"alternatively, this can be made as a list, with some changes:\n\n    request_dependencies \u003d [\n        n_fields.HyperVMachineTypeDependency(\n            \u0027os_secure_boot\u0027, \u0027hw_machine_type\u0027),\n        n_fields.HyperVMachineTypeDependency(\n            \u0027os_vtpm\u0027, \u0027hw_machine_type\u0027),\n        n_fields.HyperVSecureBootDependency(\n            \u0027os_vtpm\u0027, \u0027os_secure_boot\u0027),\n        ...\n    }\n\nI prefer having it as a map instead of a list. We won\u0027t have to loop over all the list to check that there aren\u0027t anymore dependency for a capability A. \n\nanother solution would be to define those dependencies on the fields themselves:\n\n    fields \u003d {\n        \u0027os_secure_boot\u0027: n_fields.OptionalCapabilityField(\n            dependencies\u003d[\n                n_fields.HyperVMachineTypeDependency(\n                    \u0027hw_machine_type\u0027)]),\n        \u0027os_vtpm\u0027: n_fields.OptionalCapabilityField(\n            dependencies\u003d[\n                n_fields.HyperVMachineTypeDependency(\n                    \u0027hw_machine_type\u0027),\n                n_fields.HyperVSecureBootDependency(\n                    \u0027os_secure_boot\u0027)]),\n        ...\n    }\n\nBut it looks a bit hard to read, IMO.","commit_id":"b54d6f1ad27a08aae404bfa49a5dfc688fb3c473"}]}