> 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 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 __________________________________________________________________________ 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
