Re: [openstack-dev] [Openstack] object-oriented design in nova--room for improvement?
On 08/22/2013 11:31 AM, Joshua Harlow wrote: I think that would make sense to. Would u want to try to prototype some code that might do this. That might help the nova core people see what your idea is. Although maybe they should chime in also (since I'm not sure if any other similar efforts are underway). I'd love to, but at the moment we've got other stuff under way. (Yeah, I know...I'm being the guy with the idea that doesn't have time to implement it.) I expect I'll be extending the resources being tracked on the host, so I'll likely end up feeling the pain of having to modify all these different places. That's what prompted me to actually say something. At least doing that might give me a better idea for what would actually be involved in consolidating things a bit... Chris ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Openstack] object-oriented design in nova--room for improvement?
I think that would make sense to. Would u want to try to prototype some code that might do this. That might help the nova core people see what your idea is. Although maybe they should chime in also (since I'm not sure if any other similar efforts are underway). On 8/22/13 9:39 AM, "Chris Friesen" wrote: >On 08/21/2013 09:04 PM, Joshua Harlow wrote: >> There is always room for improvement I hope ;) >> >> +openstack-dev (I think where u wanted this to go). >> >> A question, are u thinking about organizing the 'metadata' associated >>with >> resources? >> >> If so it might be interesting to see if there could be a grand >>unification >> around something like 'ResourceTracker' & 'Stats' that exposes >>'metadata' >> (different types) via an API that all the other classes could use? Is >>that >> inline of what u are thinking?? Sort of like a resource + metadata >> 'database' that everyone uses (and accesses and updates via a single set >> of APIs). > >In my experience it's often a good thing to try and minimize the number >of places that know about the details of something since it reduces the >chances of cut/paste errors or someone changing one area of code but >missing another area. Right now there are a lot of places that know >exactly what resources are exported by the compute node. > >It seems like it should be possible to have a base class for "resource >exported by the compute node" that could be subclassed for each separate >resource. Most places in the code that care about that sort of thing >could iterate over the set of resources and call appropriate member >functions on them. That way they would no longer need hardcoded >knowledge of the exported resources. > >Adding a new resource would likely be simpler too, since most of the >stuff required would be in one place. > >Chris ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Openstack] object-oriented design in nova--room for improvement?
There is always room for improvement I hope ;) +openstack-dev (I think where u wanted this to go). A question, are u thinking about organizing the 'metadata' associated with resources? If so it might be interesting to see if there could be a grand unification around something like 'ResourceTracker' & 'Stats' that exposes 'metadata' (different types) via an API that all the other classes could use? Is that inline of what u are thinking?? Sort of like a resource + metadata 'database' that everyone uses (and accesses and updates via a single set of APIs). I might have misread your idea though. On 8/21/13 7:55 PM, "Chris Friesen" wrote: > >Hi, > >I'm pretty new to OpenStack, so maybe I'm still not grokking the overall >design. Feel free to tell me I'm totally full of it. :) > >Anyways, I've been poking around in the code with an eye towards maybe >extending the set of information exported by the compute nodes for use >in scheduler filters. > >I started putting together a list of areas that would need to be >updated, and it seems like there are quite a few separate chunks of code >all over the codebase that are aware of the details of what is exported: > > >LibvirtDriver class >Claim² class >ComputeNode class >compute_node_statistics() in sqlalchemy/api.py >ServiceCommands class (to show host resources) >ResourceTracker class (to track used/free resources) >Stats class >FakeDriver class >HostState class in libvirt/driver.py >json/xml stuff in nova/doc/api_samples >HostController class >make_hypervisor() in compute/plugins/v3/hypervisors.py >HypervisorStatisticsTemplate API class >HypervisorsController API class >HostController API class >SchedulerManager class > > >I've probably missed some, the above was generated looking for cases of >"vcpus_used". > >Maybe I'm dreaming, but it seems like there should be a way to do this >more efficiently rather than manually copying knowledge into different >parts of the code. > >Thoughts? > >Chris > >___ >Mailing list: >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack >Post to : openst...@lists.openstack.org >Unsubscribe : >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
