> 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.
>> https://blog.leafe.com/virtual-bike-sheds/
> 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)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

Reply via email to