Hi Sylvain, I think the idea is that anyone making changes to the db data model has to make changes to the corresponding object and that is captured in the data model implications of nova-specs (or it should be). Then reviewers check it is done. Tests on the objects will necessarily exercise the database fields by writing to and reading form them I think.
In the case of ComputeNode, it is still just getting there. I should be putting fields in as part of the resource-tracker-objects work track, and you will have seen by now that there are patches up for review doing that. Any help making it complete is welcome. The philosophy is to only add fields that are being used - so as it is being built out, the existence of a field in db model does not necessarily imply it should be added to the ComputeNode object. It is easy to remove an unused field from the db, but more complicated to remove it from the object. Likewise for fields that want to change their format. So for my part, the fields that were not added yet are fields that were not used in the resource tracker - even if they are used in the scheduler. The one exception is the pci_stats - which was undergoing change. Paul. -----Original Message----- From: Sylvain Bauza [mailto:sba...@redhat.com] Sent: 06 June 2014 08:52 To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [Nova] Thoughts about how to enforce DB and object models mapping Hi, By working on providing a new scheduler client for compute nodes, I began to use the ComputeNode object instead of placing a call to conductor directly. Unfortunately, I recently discovered that some changes have been done in the DB model for ComputeNode that haven't been populated on the corresponding Object model. As there is no current code in Nova using ComputeNode objects, I can understand that, as the first user of the object, I have to find the lacks and fix them, so I'm OK with that. That said, I'm thinking about how we could make sure that any change in a DB model would have to be also done on the corresponding Object model. A possible approach would be to create a test class for each object and provide a check against the DB model to make sure that at least the fields are all there. Does that sound reasonable to you ? Should we provide another way for gating this ? Thanks, -Sylvain _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
