)]}'
{"specs/stein/approved/bi-directional-traits.rst":[{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"356d078415fa1763d44cecf0f64b38e1cb4f9957","unresolved":false,"context_lines":[{"line_number":5,"context_line":" http://creativecommons.org/licenses/by/3.0/legalcode"},{"line_number":6,"context_line":""},{"line_number":7,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":8,"context_line":"Bi-directional enforcement of traits"},{"line_number":9,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":10,"context_line":""},{"line_number":11,"context_line":"https://blueprints.launchpad.net/nova/+spec/bi-directional-traits"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_a6899975","line":8,"range":{"start_line":8,"start_character":0,"end_line":8,"end_character":36},"updated":"2018-08-24 13:37:06.000000000","message":"This really isn\u0027t a particularly good description of what you desire :) It\u0027s describing a proposed implementation instead of describing the feature.\n\nSomething like \"Isolate Windows images on Windows hosts\" would be more representative of what this feature request is about.","commit_id":"50809764cdffc0929c84766a0eba0a03c8503784"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"7bcda7a909475e6361032d64014fbbdbf373eb37","unresolved":false,"context_lines":[{"line_number":16,"context_line":"Problem description"},{"line_number":17,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":18,"context_line":""},{"line_number":19,"context_line":"If any flavor or image doesn\u0027t contain any ``required`` or ``forbidden``"},{"line_number":20,"context_line":"traits, then all resource providers will be eligible to be returned in the"},{"line_number":21,"context_line":"``GET /allocation_candidates`` API call depending on the availability of the"},{"line_number":22,"context_line":"requested resources. Some of the resource providers (compute host) could be"},{"line_number":23,"context_line":"special ones like `Licensed Windows Compute Host`, meaning any VM booted on"},{"line_number":24,"context_line":"this compute host will be considered as licensed Windows image and depending"},{"line_number":25,"context_line":"on the usage of VM, operator will charge it to the end-users. As an operator,"},{"line_number":26,"context_line":"I want to avoid booting images/volumes other than Windows OS on"},{"line_number":27,"context_line":"`Licensed Windows Compute Host`."},{"line_number":28,"context_line":""},{"line_number":29,"context_line":"Use Cases"},{"line_number":30,"context_line":"---------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_8ac80255","line":27,"range":{"start_line":19,"start_character":0,"end_line":27,"end_character":32},"updated":"2018-08-27 09:55:35.000000000","message":"i brought up a similar usecase with a completly different sollution in the past.\n\nwhat is proposed in this spec would mean we could not reuse standard traits. what i had discussed on irc was allow a set of \"mandataory\" traits to be associated with a resouce provider.\nthis would be a seperate field on the resouce provider allowing all traits to be reused without any prefix.\n\ni was going to hold off on proposing it formally as a spec until i personaly had more time to work on placement but\nif you want to enable this usecase in stein i think that might be a better solution so i will write it up.","commit_id":"50809764cdffc0929c84766a0eba0a03c8503784"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"356d078415fa1763d44cecf0f64b38e1cb4f9957","unresolved":false,"context_lines":[{"line_number":30,"context_line":"---------"},{"line_number":31,"context_line":""},{"line_number":32,"context_line":"1. End-users can create new images without required/forbidden traits which"},{"line_number":33,"context_line":"   could land VMs on `wrong compute hosts` if `inject metadata properties`_ is"},{"line_number":34,"context_line":"   not enabled in the glance service."},{"line_number":35,"context_line":"2. End-users can boot images in ISO format with required/forbidden traits set"},{"line_number":36,"context_line":"   on it and install it on secondary volume attached to the VM. During"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_0b609800","line":33,"range":{"start_line":33,"start_character":21,"end_line":33,"end_character":42},"updated":"2018-08-24 13:37:06.000000000","message":"I\u0027m glad you put this in quotes, because it indicates you understand that these aren\u0027t actually \"wrong\". The placement service simply returns matches for the constraints that are requested of it.","commit_id":"50809764cdffc0929c84766a0eba0a03c8503784"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"808149fc7c3cbd53424682d6a9f3f34b26bccb92","unresolved":false,"context_lines":[{"line_number":31,"context_line":""},{"line_number":32,"context_line":"1. End-users can create new images without required/forbidden traits which"},{"line_number":33,"context_line":"   could land VMs on `wrong compute hosts` if `inject metadata properties`_ is"},{"line_number":34,"context_line":"   not enabled in the glance service."},{"line_number":35,"context_line":"2. End-users can boot images in ISO format with required/forbidden traits set"},{"line_number":36,"context_line":"   on it and install it on secondary volume attached to the VM. During"},{"line_number":37,"context_line":"   installation, nova doesn\u0027t copy glance image metadata properties to the"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_ac0f3b2c","line":34,"updated":"2018-08-24 14:05:24.000000000","message":"What if the admin puts \u0027trait:CUSTOM_WINDOWS_LICENSE\u0027: \u0027forbidden\u0027 to the flavor extra_specs for non-windows-flavors? If the end user wants to boot a non-windows VM he needs to use a non-windows-flavor or he will be charged with the extra cost of using the more expensive host. I expect that the admin would well document this in the documentation of the given flavor.\n\nAt the same time any windows-only-flavor would need trait:CUSTOM_WINDOWS_LICENSE\u0027: \u0027required\u0027 in the flavor extra_spec.","commit_id":"50809764cdffc0929c84766a0eba0a03c8503784"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"356d078415fa1763d44cecf0f64b38e1cb4f9957","unresolved":false,"context_lines":[{"line_number":32,"context_line":"1. End-users can create new images without required/forbidden traits which"},{"line_number":33,"context_line":"   could land VMs on `wrong compute hosts` if `inject metadata properties`_ is"},{"line_number":34,"context_line":"   not enabled in the glance service."},{"line_number":35,"context_line":"2. End-users can boot images in ISO format with required/forbidden traits set"},{"line_number":36,"context_line":"   on it and install it on secondary volume attached to the VM. During"},{"line_number":37,"context_line":"   installation, nova doesn\u0027t copy glance image metadata properties to the"},{"line_number":38,"context_line":"   volume. Later, users can make volume as bootable and use it to boot new VMs"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_cb2aa08f","line":35,"range":{"start_line":35,"start_character":4,"end_line":35,"end_character":42},"updated":"2018-08-24 13:37:06.000000000","message":"I\u0027m not sure what \"in ISO format\" means in this context? I think you can remove that part of the phrasing without losing any meaning.","commit_id":"50809764cdffc0929c84766a0eba0a03c8503784"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"356d078415fa1763d44cecf0f64b38e1cb4f9957","unresolved":false,"context_lines":[{"line_number":33,"context_line":"   could land VMs on `wrong compute hosts` if `inject metadata properties`_ is"},{"line_number":34,"context_line":"   not enabled in the glance service."},{"line_number":35,"context_line":"2. End-users can boot images in ISO format with required/forbidden traits set"},{"line_number":36,"context_line":"   on it and install it on secondary volume attached to the VM. During"},{"line_number":37,"context_line":"   installation, nova doesn\u0027t copy glance image metadata properties to the"},{"line_number":38,"context_line":"   volume. Later, users can make volume as bootable and use it to boot new VMs"},{"line_number":39,"context_line":"   which could land on `Licensed Windows Compute Hosts`."}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_a6043916","line":36,"range":{"start_line":36,"start_character":13,"end_line":36,"end_character":43},"updated":"2018-08-24 13:37:06.000000000","message":"do you mean create a bootable volume from a running server that was booted from an image?","commit_id":"50809764cdffc0929c84766a0eba0a03c8503784"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"808149fc7c3cbd53424682d6a9f3f34b26bccb92","unresolved":false,"context_lines":[{"line_number":36,"context_line":"   on it and install it on secondary volume attached to the VM. During"},{"line_number":37,"context_line":"   installation, nova doesn\u0027t copy glance image metadata properties to the"},{"line_number":38,"context_line":"   volume. Later, users can make volume as bootable and use it to boot new VMs"},{"line_number":39,"context_line":"   which could land on `Licensed Windows Compute Hosts`."},{"line_number":40,"context_line":""},{"line_number":41,"context_line":""},{"line_number":42,"context_line":"Proposed change"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_6c15a33c","line":39,"updated":"2018-08-24 14:05:24.000000000","message":"This could be also solved with proper flavors.","commit_id":"50809764cdffc0929c84766a0eba0a03c8503784"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"356d078415fa1763d44cecf0f64b38e1cb4f9957","unresolved":false,"context_lines":[{"line_number":89,"context_line":"    IMG4: Expected_result [RP1, RP2]"},{"line_number":90,"context_line":"    {"},{"line_number":91,"context_line":"        traits_required: []"},{"line_number":92,"context_line":"    }"},{"line_number":93,"context_line":""},{"line_number":94,"context_line":"As you can see in the above example, IMG1 and IMG4  will not return RP3 and"},{"line_number":95,"context_line":"RP4 because `SPECIAL_WINDOWS_LICENSE` trait is not assigned to it and in case"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_669aa162","line":92,"updated":"2018-08-24 13:37:06.000000000","message":"Couldn\u0027t this be solved already using placement request filters?\n\nIn other words:\n\n1) decorate the image with a property, let\u0027s call it aggregate_isolate_metadata_filter\u003dWindows\n\n2) add all the Windows hosts into a Nova host aggregate\n\n3) add a metadata item such as \"aggregate_isolate_metadata_filter\u003dWindows\" to the Nova host aggregate\n\n4) nova-conductor sees the image property called \"aggregate_isolate_metadata_filter\u003dWindows and looks up the Nova host aggregates that have this particular metadata item. When calling placement, nova-scheduler passes along member_of\u003d$AGG_UUID.","commit_id":"50809764cdffc0929c84766a0eba0a03c8503784"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"8fed1315a017da16a2a939eb5e0cf415ea876d06","unresolved":false,"context_lines":[{"line_number":89,"context_line":"    IMG4: Expected_result [RP1, RP2]"},{"line_number":90,"context_line":"    {"},{"line_number":91,"context_line":"        traits_required: []"},{"line_number":92,"context_line":"    }"},{"line_number":93,"context_line":""},{"line_number":94,"context_line":"As you can see in the above example, IMG1 and IMG4  will not return RP3 and"},{"line_number":95,"context_line":"RP4 because `SPECIAL_WINDOWS_LICENSE` trait is not assigned to it and in case"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_09f299e4","line":92,"in_reply_to":"3f79a3b5_26f7c98d","updated":"2018-09-10 14:26:11.000000000","message":"\u003e 2) Decorate your non-Windows images with traits_forbidden\u003dCUSTOM_WINDOWS\n \u003e image property\n\nThis is the part that seems overly laborious to me. Even with the injecting of default metadata into images, managing this long-term seems like it\u0027s going to be a mess. Whether you manually decorate all images, or have those values injected at upload time automatically, it becomes very difficult to evolve your special classes (or whatever you want to call them) over time.\n\nI think that the absence of any class-specifying trait on an image should be enough to indicate that it should land on a provider without a specific class trait.\n\nI definitely think that this is a nova-side thing and not a placement one.\n\nWhat about a request filter where we read a nova config file value of \"class_prefixes\" or something, which would look like this:\n\n class_prefixes \u003d CUSTOM_LOCAL_OS_, CUSTOM_LOCAL_SPECIAL_HW\n\nThen in the request filter, we can list the traits via placement, and any of them that start with one of the declared prefixes which aren\u0027t specified on the image/flavor are placed into forbidden traits on the allocation_candidates query to placement?\n\nThe problem with that is if you have many traits under some class prefix you will end up with a longish query to placement, but I\u0027m not sure that\u0027s a huge problem. This makes it a nova thing, and uses the existing forbidden traits thing in placement to do the very nova-specific thing of looking for any providers that aren\u0027t declared as having a trait underneath a specific prefix.","commit_id":"50809764cdffc0929c84766a0eba0a03c8503784"},{"author":{"_account_id":1011,"name":"Tushar Patil","email":"tushar.vitthal.patil@gmail.com","username":"tpatil"},"change_message_id":"da7a223b846a704fe62462ffd078d80ba2537dfc","unresolved":false,"context_lines":[{"line_number":89,"context_line":"    IMG4: Expected_result [RP1, RP2]"},{"line_number":90,"context_line":"    {"},{"line_number":91,"context_line":"        traits_required: []"},{"line_number":92,"context_line":"    }"},{"line_number":93,"context_line":""},{"line_number":94,"context_line":"As you can see in the above example, IMG1 and IMG4  will not return RP3 and"},{"line_number":95,"context_line":"RP4 because `SPECIAL_WINDOWS_LICENSE` trait is not assigned to it and in case"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_8993184f","line":92,"in_reply_to":"3f79a3b5_26f7c98d","updated":"2018-08-28 07:10:49.000000000","message":"As per use-case #2, once you create a bootable volume from a running server which was booted from image (any image) as per steps specified in [1], all image properties/traits assigned to that particular image are lost, meaning these image properties/traits are not copied in volume glance image metadata. If user uses this bootable volume to boot any instances, it can land on any resource providers including Windows providers with the CUSTOM_WINDOWS trait as the required:traits or forbidden:traits are empty.\n\nThe same issue exists with placement request filters.\n\n\n[1] : https://docs.openstack.org/nova/latest/user/launch-instance-using-ISO-image.html","commit_id":"50809764cdffc0929c84766a0eba0a03c8503784"},{"author":{"_account_id":1011,"name":"Tushar Patil","email":"tushar.vitthal.patil@gmail.com","username":"tpatil"},"change_message_id":"e388ae02dfe2bd398535fb57d1cfcae25a16cb3e","unresolved":false,"context_lines":[{"line_number":89,"context_line":"    IMG4: Expected_result [RP1, RP2]"},{"line_number":90,"context_line":"    {"},{"line_number":91,"context_line":"        traits_required: []"},{"line_number":92,"context_line":"    }"},{"line_number":93,"context_line":""},{"line_number":94,"context_line":"As you can see in the above example, IMG1 and IMG4  will not return RP3 and"},{"line_number":95,"context_line":"RP4 because `SPECIAL_WINDOWS_LICENSE` trait is not assigned to it and in case"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_89e9bfb8","line":92,"in_reply_to":"3f79a3b5_2e7e8269","updated":"2018-08-29 02:41:33.000000000","message":"Use-case #1 can be handled using \"inject metadata properties in glance\", but use-case2 cannot be handled.\n\nLet\u0027s me elaborate more on use-case #2.\n\nIn public/private cloud, end users with \u0027member\u0027 role are allowed to create images.\nOperator has configured \"inject metadata properties in glance\" which will add required/forbidden traits to images as per operator\u0027s requirements at the time of image creation if end-user has \u0027member\u0027 role. End user adds an image of format \"ISO Optical Disk Image\".\n\nNow, if end-user follows steps as mentioned here [1], these required/forbidden traits assigned to the image are lost after OS is installed on volume attached to the server. End-user can  make this volume as bootable using \"os-set_bootable\" volume action API and use this volume to boot new VMs which could land on any resource providers. It is also possible to upload volume to image and boot VMs from images.\n\nThe existing \"AggregateImagePropertiesIsolation\" nova scheduler filter also cannot handle this use-case #2.\n\n[1] : https://docs.openstack.org/nova/latest/user/launch-instance-using-ISO-image.html","commit_id":"50809764cdffc0929c84766a0eba0a03c8503784"},{"author":{"_account_id":5754,"name":"Alex Xu","email":"hejie.xu@intel.com","username":"xuhj"},"change_message_id":"123a1425f6a57f9a6d8e4bedb9e1b8f94188b0b2","unresolved":false,"context_lines":[{"line_number":89,"context_line":"    IMG4: Expected_result [RP1, RP2]"},{"line_number":90,"context_line":"    {"},{"line_number":91,"context_line":"        traits_required: []"},{"line_number":92,"context_line":"    }"},{"line_number":93,"context_line":""},{"line_number":94,"context_line":"As you can see in the above example, IMG1 and IMG4  will not return RP3 and"},{"line_number":95,"context_line":"RP4 because `SPECIAL_WINDOWS_LICENSE` trait is not assigned to it and in case"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_247490fd","line":92,"in_reply_to":"3f79a3b5_669aa162","updated":"2018-08-25 10:24:03.000000000","message":"My initial thought is about request filter also. We can have a request filter to add a forbidden trait to the request in the default, except the request required that trait explicitly. \n\nFor example, operator can set a config opt exclusive_traits\u003dCUSTOM_WINDOW.\nThen a request filter will add that CUSTOM_WINDOW as forbidden trait to the any request, except the request specify the CUSTOM_WINDOW as required trait.\n\nThis can resolve the use-case #2.","commit_id":"50809764cdffc0929c84766a0eba0a03c8503784"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"a3bb4d761a841c286218491fff87c42bdec371b0","unresolved":false,"context_lines":[{"line_number":89,"context_line":"    IMG4: Expected_result [RP1, RP2]"},{"line_number":90,"context_line":"    {"},{"line_number":91,"context_line":"        traits_required: []"},{"line_number":92,"context_line":"    }"},{"line_number":93,"context_line":""},{"line_number":94,"context_line":"As you can see in the above example, IMG1 and IMG4  will not return RP3 and"},{"line_number":95,"context_line":"RP4 because `SPECIAL_WINDOWS_LICENSE` trait is not assigned to it and in case"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_26f7c98d","line":92,"in_reply_to":"3f79a3b5_669aa162","updated":"2018-08-24 13:41:42.000000000","message":"Note that you could also do something with forbidden traits instead of encoding things like SPECIAL_* into the trait interface.\n\nAssume the goal is to prevent a non-Windows image from landing on a \"Windows  host\".\n\n1) Decorate all your Windows providers with the CUSTOM_WINDOWS trait\n\n2) Decorate your non-Windows images with traits_forbidden\u003dCUSTOM_WINDOWS image property\n\n3) Decorate your Windows images with traits_required\u003dCUSTOM_WINDOWS image property\n\ndone.","commit_id":"50809764cdffc0929c84766a0eba0a03c8503784"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"e9ea9cfd4f154ae010cea327853b99e2021bb4cc","unresolved":false,"context_lines":[{"line_number":89,"context_line":"    IMG4: Expected_result [RP1, RP2]"},{"line_number":90,"context_line":"    {"},{"line_number":91,"context_line":"        traits_required: []"},{"line_number":92,"context_line":"    }"},{"line_number":93,"context_line":""},{"line_number":94,"context_line":"As you can see in the above example, IMG1 and IMG4  will not return RP3 and"},{"line_number":95,"context_line":"RP4 because `SPECIAL_WINDOWS_LICENSE` trait is not assigned to it and in case"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_2e7e8269","line":92,"in_reply_to":"3f79a3b5_8993184f","updated":"2018-08-28 12:18:50.000000000","message":"@tpatil: but you addressed that with https://specs.openstack.org/openstack/glance-specs/specs/queens/approved/glance/inject-automatic-metadata.html","commit_id":"50809764cdffc0929c84766a0eba0a03c8503784"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"cb8b07b0c8ec30c038e87d470cda476b6954ed42","unresolved":false,"context_lines":[{"line_number":102,"context_line":"optional."},{"line_number":103,"context_line":""},{"line_number":104,"context_line":""},{"line_number":105,"context_line":"Alternatives"},{"line_number":106,"context_line":"------------"},{"line_number":107,"context_line":""},{"line_number":108,"context_line":"The above use-case #1 can be resolved using `inject metadata properties`_"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_2cfffc01","line":105,"updated":"2018-08-21 22:03:28.000000000","message":"So if Placement didn\u0027t exist, you\u0027d be looking for the AggregateMultiTenancyIsolation filter to deal with this exclusivity issue, right? That filter has the same problem though. If your tenant request is in the isolated host aggregates group, you can only land on the hosts in that aggregate. However, any other tenant not isolated to that group can also land in that group of host aggregates. I don\u0027t really know how projects like blazar deal with this for their dedicated host feature, because it seems like an issue. So having mentioned AggregateMultiTenancyIsolation, couldn\u0027t an alternative being fixing the AggregateMultiTenancyIsolation filter so that we actually add a special metadata key which makes the hosts in a given aggregate exclusive to the isolated tenants within? Also, for the dedicated host problem in blazar, I would think they could, using placement 1.26, reserve all of the inventory on a compute node resource provider until the time comes for scheduling to a given host and then free up the resources when a given reservation is being scheduled to that host - not really the same thing you\u0027re talking about in this spec, but it\u0027s a semi-related problem with host exclusivity.","commit_id":"50809764cdffc0929c84766a0eba0a03c8503784"},{"author":{"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"},"change_message_id":"76c166c4d8902b53c3fa1a89bb871d7fb7109fcc","unresolved":false,"context_lines":[{"line_number":102,"context_line":"optional."},{"line_number":103,"context_line":""},{"line_number":104,"context_line":""},{"line_number":105,"context_line":"Alternatives"},{"line_number":106,"context_line":"------------"},{"line_number":107,"context_line":""},{"line_number":108,"context_line":"The above use-case #1 can be resolved using `inject metadata properties`_"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_978fed21","line":105,"in_reply_to":"3f79a3b5_0970ab07","updated":"2018-08-24 09:22:09.000000000","message":"\u003e Actually, blazar team was about to write this kind of \"exclusive\n \u003e trait\" spec, but we haven’t because A.) in Stein cycle we will\n \u003e focus on blazar-placement integration for *instance* reservation,\n \u003e which can be achieved without any additional feature in placement,\n \u003e and because B.) placement may go into spec freeze as Chris\n \u003e suggested.\n\nTo clarify my earlier comments a bit more: I don\u0027t have a problem with the concept of being able to express a traits as \"exclusive\" in a request to /allocation_candidates or /resource_providers (like required or forbidden).\n\nMy issue is with traits being treated specially on the backend, by virtue of their value or a fragment of their value when the \"specialness\" was not expressed in the query.\n\nIn the description above we have the phrase \"if these special traits are not requested in flavor or images\" then do some special processing. That\u0027s problematic _unless_ there is a shim between the flavor or images and the scheduler\u0027s request to placement, probably a request filter, which adds the \"special\" trait to the query.\n\nI hope I\u0027m making some sense.\n\nAlso on B) above: It\u0027s not a given that the freeze will happen, it was simply an idea to help make sure that backlogs are processed before we take on more work. If people think it is a good idea, I\u0027m all for it, but we need to decide as a group.","commit_id":"50809764cdffc0929c84766a0eba0a03c8503784"},{"author":{"_account_id":25625,"name":"Tetsuro Nakamura","email":"tetsuro.nakamura.bc@hco.ntt.co.jp","username":"tetsuro0907"},"change_message_id":"df7ee6f0010df128032098d0b6bdd7e8e50e5a31","unresolved":false,"context_lines":[{"line_number":102,"context_line":"optional."},{"line_number":103,"context_line":""},{"line_number":104,"context_line":""},{"line_number":105,"context_line":"Alternatives"},{"line_number":106,"context_line":"------------"},{"line_number":107,"context_line":""},{"line_number":108,"context_line":"The above use-case #1 can be resolved using `inject metadata properties`_"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_0970ab07","line":105,"in_reply_to":"3f79a3b5_2cfffc01","updated":"2018-08-24 05:27:21.000000000","message":"\u003e I don\u0027t really know how projects like blazar deal with this for their dedicated host feature\n\nBlazar has its own scheduler filter and its own aggregate named \"free_pool”. Operators should first put hosts in the \"free_pool\" aggregate via \n\n  $ blazar host-create \u003chostname\u003e\n\nReservation host candidates are picked from hosts in this \"free_poll\". A requested instance without the scheduler hint will land on hosts that are *out* of blazar’s “free_pool”. See the blazar filter[1] for this point. \n\n[1] https://github.com/openstack/blazar-nova/blob/master/blazarnova/scheduler/filters/blazar_filter.py#L104-L105 \n\nIf this spec is merged, blazar will use this feature for host reservation deprecating the aggregate approach. There will be no need to segregate “blazar’s host pool for reservation” from normal hosts pool, which is nice.\n\nActually, blazar team was about to write this kind of \"exclusive trait\" spec, but we haven’t because A.) in Stein cycle we will focus on blazar-placement integration for *instance* reservation, which can be achieved without any additional feature in placement, and because B.) placement may go into spec freeze as Chris suggested.\n\nAnyway, we are happy to see this spec has been proposed out of the blazar team. I’m willing to help make PoC and find out the risks before the spec is merged.\n\n\u003e for the dedicated host problem in blazar, reserve all of the inventory until the time comes\n\u003e and then free up the resources when a given reservation is being scheduled to that host\n\nAh, we haven’t thought about that, cool, but let me think…, who “frees up the resources” is blazar, right? Then how can blazar be notified from nova that the end-user has created an instance with that host reservation? And blazar should know how much resource the instance uses because it shouldn’t free up more than the created instance uses.... It sounds more difficult and more complex than this \"exclusive trait\" approach, doesn\u0027t it?","commit_id":"50809764cdffc0929c84766a0eba0a03c8503784"}]}