Ewan:
> I’d prefer that we allowed vm or vm_rec for a record (that would give us less
> to fix up, apart from anything else!)
In terms of readability, I think we get more bang for the buck if we stick to a
single standard, 'vm' or 'vm_rec'. This has the side-benefit of making the code
more grep-able and easier to refactor down-the-road.
A couple of extra 'cw' keystrokes in Vim won't kill me :)
Ed:
> it should probably be 'instance'. As we're using 'vm' as an alias for instance
Within the virt-layer code, 'instance' and 'vm' are two distinct concepts.
Instance, what Nova manages, has attributes like 'display_name' and
'internal_id'. 'VM', what the Xen manages, has attributes like 'PV_args' and
'name_label'.
________________________________________
From: Ed Leafe
Sent: Monday, March 07, 2011 10:27 AM
To: Ewan Mellor
Cc: Chris Behrens; Rick Harris; openstack-xenapi@lists.launchpad.net
Subject: Re: [Openstack-xenapi] XenAPI virt-layer Variable Naming-Scheme
On Mar 6, 2011, at 8:29 AM, Ewan Mellor wrote:
> I do use _rec for a record, if I feel that it needs distinguishing
> explicitly. I’d prefer that we allowed vm or vm_rec for a record (that would
> give us less to fix up, apart from anything else!)
In most of the code, the convention is to refer to a modeled object
using the singular form of the table name; in this case, it should probably be
'instance'. As we're using 'vm' as an alias for instance, it would seem that
either 'instance' or 'vm' would be consistent. I don't know of any other
modeled object referred to with the '*_rec' name.
But definitely +1 for distinguishing opaque refs and uuids.
-- Ed Leafe
_______________________________________________
Mailing list: https://launchpad.net/~openstack-xenapi
Post to : openstack-xenapi@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack-xenapi
More help : https://help.launchpad.net/ListHelp
