On 07/23/2013 12:02 PM, Alex Glikson wrote: > Russell Bryant <rbry...@redhat.com> wrote on 23/07/2013 05:35:18 PM: >> >> #1 - policy associated with a host aggregate >> >> >> >> This seems very odd to me. Scheduling policy is what chooses hosts, so >> >> having a subset of hosts specify which policy to use seems backwards. >> > >> > This is not what we had in mind. Host aggregate is selected based on >> > policy passed in the request (hint, extra spec, or whatever -- see >> > below) and 'policy' attribute of the aggregate -- possibly in >> > conjunction with 'regular' aggregate filtering. And not the other way >> > around. Maybe the design document is not clear enough about this point. >> >> Then I don't understand what this adds over the existing ability to >> specify an aggregate using extra_specs. > > The added value is in the ability to configure the scheduler accordingly > -- potentially differently for different aggregates -- in addition to > just restricting the target host to those belonging to an aggregate with > certain properties. For example, let's say we want to support two > classes of workloads - CPU-intensive, and memory-intensive. The > administrator may decide to use 2 different hardware models, and > configure one aggregate with lots of CPU, and another aggregate with > lots of memory. In addition to just routing an incoming provisioning > request to the correct aggregate (which can be done already), we may > want different cpu_allocation_ratio and memory_allocation_ratio when > managing resources in each of the aggregates. In order to support this, > we would define 2 policies (with corresponding configuration of > filters), and attach each one to the corresponding aggregate.
I understand the use case, but can't it just be achieved with 2 flavors and without this new aggreagte-policy mapping? flavor 1 with extra specs to say aggregate A and policy Y flavor 2 with extra specs to say aggregate B and policy Z >> >> >> #2 - via a scheduler hint >> >> How about just making the scheduling policy choice as simple as an item >> >> in the flavor extra specs? >> > >> > This is certainly an option. It would be just another implementation of >> > the policy selection interface (implemented using filters). In fact, we >> > already have it implemented -- just thought that explicit hint could be >> > more straightforward to start with. Will include the implementation >> > based on flavor extra spec in the next commit. >> >> Ok. I'd actually prefer to remove the scheduler hint support >> completely. > > OK, removing the support for doing it via hint is easy :-) > >> I'm not even sure it makes sense to make this pluggable. I >> can't think of why something other than flavor extra specs is necessary >> and justifies the additional complexity. > > Well, I can think of few use-cases when the selection approach might be > different. For example, it could be based on tenant properties (derived > from some kind of SLA associated with the tenant, determining the > over-commit levels), or image properties (e.g., I want to determine > placement of Windows instances taking into account Windows licensing > considerations), etc Well, you can define tenant specific flavors that could have different policy configurations. I think I'd rather hold off on the extra complexity until there is a concrete implementation of something that requires and justifies it. >> I think some additional examples would help. It's also important to >> have this laid out for documentation purposes. > > OK, sure, will add more. Hopefully few examples above are also helpful > to clarify the intention/design. -- Russell Bryant _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
