>> b) a compute node could very well have both local disk and shared >> disk. how would the placement API know which one to pick? This is a >> sorting/weighing decision and thus is something the scheduler is >> responsible for.
> I remember having this discussion, and we concluded that a > computenode could either have local or shared resources, but not > both. There would be a trait to indicate shared disk. Has this > changed? I've always thought we discussed that one of the benefits of this approach was that it _could_ have both. Maybe we said "initially we won't implement stuff so it can have both" but I think the plan has been that we'd be able to support it. >>> * We already have the information the filter scheduler needs now >>> by some other means, right? What are the reasons we don't want >>> to use that anymore? >> >> The filter scheduler has most of the information, yes. What it >> doesn't have is the *identifier* (UUID) for things like SRIOV PFs >> or NUMA cells that the Placement API will use to distinguish >> between things. In other words, the filter scheduler currently does >> things like unpack a NUMATopology object into memory and determine >> a NUMA cell to place an instance to. However, it has no concept >> that that NUMA cell is (or will soon be once >> nested-resource-providers is done) a resource provider in the >> placement API. Same for SRIOV PFs. Same for VGPUs. Same for FPGAs, >> etc. That's why we need to return information to the scheduler >> from the placement API that will allow the scheduler to understand >> "hey, this NUMA cell on compute node X is resource provider >> $UUID". Why shouldn't scheduler know those relationships? You were the one (well one of them :P) that specifically wanted to teach the nova scheduler to be in the business of arranging and making claims (allocations) against placement before returning. Why should some parts of the scheduler know about resource providers, but not others? And, how would scheduler be able to make the proper decisions (which require knowledge of hierarchical relationships) without that knowledge? I'm sure I'm missing something obvious, so please correct me. IMHO, the scheduler should eventually evolve into a thing that mostly deals in the currency of placement, translating those into nova concepts where needed to avoid placement having to know anything about them. In other words, I would expect to be able to explain the purpose of the scheduler as "applies nova-specific logic to the generic resources that placement says are _valid_, with the goal of determining which one is _best_". --Dan __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev