Open Stack

Hi Paul,

Thanks for replying quickly,

Agreed with the fact it should be managed by a spec, now we have it.
The problem is that we can't guaranttee that an unused field in DB won't
be used someday without approving a blueprint, if there is still a
possibility to directly use the conductor (take a bugfix for example).
How are we sure that a DB field is not in use, and how as reviewers, can
we -1 to someone using it now ?

Once 100% of Nova code will be migrated to Objects, then yes, it will be
easy to track down such changes.
Take the reserved_instances field in compute_nodes. By looking at the
compute manager, we can't find where it is defined so we could think
this DB field is not in use, but that's wrong. This field is being set
somewhere else, and is used by the scheduler in a filter.

So, indeed, I can understand how hard it is to provide new Object
versions, but IMHO we should assume that if no code is using a DB field,
that's a good fit for removing it from DB.

-Sylvain




Le 06/06/2014 12:46, Murray, Paul (HP Cloud) a écrit :
> 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:sbauza at 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 at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev