> On Oct 17, 2016, at 8:45 PM, Jay Pipes <jaypi...@gmail.com> wrote:
> On 10/17/2016 11:14 PM, Ed Leafe wrote:
>> Now that we’re starting to model some more complex resources, it seems that
>> some of the original design decisions may have been mistaken. One approach
>> to work around this is to create multiple levels of resource providers.
>> While that works, it is unnecessarily complicated IMO. I think we need to
>> revisit some basic assumptions about the design before we dig ourselves a
>> big design hole that will be difficult to get out of. I’ve tried to
>> summarize my thoughts in a blog post. I don’t presume that this is the only
>> possible solution, but I feel it is better than the current approach.
> I commented on your blog, but leave it here for posterity:
Likewise, responded on the blog, but following your lead by posting in both
You didn't include this in your email, but I think you misunderstood my comment
how "those of us experienced in OOP" might object to having multiple classes
that differ solely on a single attribute. Since you are the one who is doing
the objecting to multiple class names, I was merely saying that anyone with
background in object-oriented programming might have a reflexive aversion to
having slight variations on something with 'Class' in its name. That was the
reason I said that if they had been named 'ResourceTypes' instead, the aversion
might not be as strong. Sorry for the misunderstanding. I was in no way trying
to minimize your understanding of OOPy things.
Regarding your comments on standardization, I'm not sure that I can see the
difference between what you've described and what I have. In your design, you
would have a standard class name for the SR-IOV-VF, and standard trait names
for the networks. So with a two-network deployment, there would need to be 3
standardized names. With multiple classes, there would need to be 2
standardized names: not a huge difference. Now if there might be a more complex
deployment than simply 'public' and 'private' networks for SR-IOV devices, then
things are less clear. For things to be standardized across clouds, the way you
request a resource has to be standardized. How would the various network names
be constrained across clouds? Let's say there are N network types; the same
math would apply. Nested providers would need N+1 standard names and multiple
classes would need N in order to distinguish. If there are no restrictions on
network names, then both approaches will fail on standardization, since a
provider could call a network whatever they want.
As far as NUMA cells and their inventory accounting are concerned, that sounds
like something where a whiteboard discussion will really help. Most of the
people working on the placement engine, myself included, have only a passing
understanding of the intricacies of NUMA arrangements. But even without that, I
don't see the need to have multiple awkward names for the different NUMA
resource classes. Based on my understanding, a slightly different approach
would be sufficient. Instead of having multiple classes, we could remove the
restriction that a ResourceProvider can only have one of any individual
ResourceClass. In other words, the host would have two ResourceClass records of
type NUMA_SOCKET (is that the right class?), one for each NUMA cell, and each
of those would have their individual inventory records. So a request for
MEMORY_PAGE_1G would involve a ResourceProvider seeing if any of their
ResourceClass records has enough of that type of inventory available.
I think the same approach applies to the NIC bandwidth example you gave. By
allowing multiple ResourceClass records representing the different NICs, the
total bandwidth will also be a simple aggregate.
Finally, regarding the SQL complexity, I spent years as a SQL DBA and yet I am
always impressed by how much better your SQL solutions are than the ones I
might come up with. I'm not saying that the SQL is so complex as to be
unworkable; I'm simply saying that it is more complex than it needs to be.
In any event, I am looking forward to carrying on these discussions in
Barcelona with you and the rest of the scheduler subteam.
-- Ed Leafe
OpenStack Development Mailing List (not for usage questions)