Open Stack

> On Oct 17, 2016, at 8:45 PM, Jay Pipes <jaypipes at 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 places.

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