Just to make sure I understand:
There needs to be an instantiation of 'recorded'
CIM_ResourceAllocationSettingData instances to accompany the 'current'
ones we have in place. These recorded instances will get their data
from the domain conf file via the private function get_defined_domain()
which is in xm.c.
What is the best approach in terms of naming conventions? Should we
rename e.g. Xen_DiskSettingData to Xen_DiskSettingDataCurrent and then
have a Xen_DiskSettingDataRecorded class as well? And then, what is the
best name for the connector class I suggested before?
XenDiskSettingDataCurrentRecorded ? Not sure here.
Following along Gareth's and Daniel's suggestion, there needs to be an
IsCurrent=1 flag set in the ElementSettingData association for the
current instance, and IsCurrent=0 for the recorded one.
Does this sound correct?
Luke
-----Original Message-----
From: Daniel Hiltgen [mailto:dhiltgen@xxxxxxxxxx]
Sent: Monday, July 17, 2006 8:34 PM
To: Gareth S Bestor
Cc: Jim Fehlig; Szymanski, Lukasz K; xen-cim@xxxxxxxxxxxxxxxxxxx;
xen-cim-bounces@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Xen-cim] RecordedSettings questions
On Mon, Jul 17, 2006 at 02:07:50PM -0700, Gareth S Bestor wrote:
>
>
>
>
>
> In regards to the current vs recorded settingdata, see pg 32 of the
> Resource Allocation Profile. In particular, both the Recorded (aka
> initial) and Current (aka dynamically modified) SettingDatas for a
> particular resource are associated to the actual CIM_LogicalDevice (eg
> Xen_Memory) via an CIM_ElementSettingData subcless. You can
> distinguish between the two ResourceAllocationSettingData's by the
> fact that the ElementSettingData assocaition to the *current*
> ResourceAllocationSettingData will have its IsCurrent property set to
> true, whereas ny and all other ElementSettingData assoications (to
> other ResourceAllocationSettingData's, eg the recorded
> one) it will be false. So to summarize, the distinction between
> recorded and current SettingData's is made in the *association* (to
> the
> LogicialDevice) as opposed to anything in the SettingData itself.
>
> The CIM_RecordedSetting is a slightly different but related beast,
> which associates all the various ResourceAllocationSettingData's over
> to the one
> *recorded* one. This would enable you to hop from one SettingData for
> some LogicalDevice straight to the one original recorded setting, by
> following the RecordedSetting assoc rather than having to go up to the
> LogicalDevice and then down via its ElementSettingData assoications.
>
> But now that I have to try to explin it to someone else, it does seems
> rather awkward! :-) In particular, there is an emphasis on 'IsCurrent'
> in the ElementSettingData assoications to distinguish differnet types
> of Settings from one another, yet we emphasis the 'recorded' setting
> by having CIM_RecordedSetting between the
> ResourceAllocationSettingData's themselves... Daniel - whaddayahtink?!
IsCurrent is existing modeling, which we were trying to piggy-back on.
'Recorded' was the new modeling we added. We've iterated on this a bit
over the past year, but I believe the current form is the consensus of
the workgroup participants.
> BTW - the IsDefault/IsCurrent/IsActive properties show up in the
> CIM_ElementSettingData.mof, but not in the CIM_EelementSettingData
> table in the profile doc (section 10.15). Is this an ommission?
Yes, at least IsCurrent should be in the table as it's called out in
section 7.3.1.1 and 7.3.1.2, however those are for Simple Resource
Allocation, not virtualization.
As the profile is currently written, it actually doesn't specify how you
disambiguate the association in the virtualization case, which seems
like a flaw to me. It seems reasonable to model both Simple and Virtual
Resource Allocation the same way by using IsCurrent.
Daniel
>
> - Gareth
>
>
>
>
> Jim Fehlig
> <jfehlig@xxxxxxxx
> om>
To
> Sent by: "Szymanski, Lukasz K"
> xen-cim-bounces@l <Lukasz.Szymanski@xxxxxxxxxx>
> ists.xensource.co
cc
> m xen-cim@xxxxxxxxxxxxxxxxxxx
>
Subject
> Re: [Xen-cim] RecordedSettings
> 07/17/06 01:21 PM questions
>
>
>
>
>
>
>
>
>
>
> Szymanski, Lukasz K wrote:
> >
> > Hello -
> >
> > I have been thinking about the whole RecordedSetting approach and
> > came up with the following. I think there should be 4 additional
> > associations: XenDiskSettingRecordedSetting,
> > XenNetworkPortRecordedSetting, XenMemoryRecordedSetting, and
> > XenComputerSystemRecordedSetting.
> >
> > This is what I believe is the mof file for
> > XenDiskSettingRecordedSetting
> >
> > //
> > *******************************************************************
> > // Associations
> > //
> > *******************************************************************
> >
> > //
> > ==================================================================
> > // Xen_DiskSettingDataRecodedSetting //
> > ==================================================================
> > [Association,
> > Provider ("cmpi:Xen_DiskSettingDataRecodedSetting"),
> > Description (
> > "A class derived from CIM_RecordedSettings to represent "
> > "the association of a current and/or recorded Xen_Disk
> > setting of "
> > "a virtualized disk device in a Xen domain.
> >
> > class Xen_DiskSettingDataRecodedSetting : CIM_RecordedSetting {
> > [Override("CurrentSetting")]
> > Xen_DiskSettingData REF CurrentSetting;
> >
> > [Override("RecordedSetting")]
> > Xen_DiskSettingData REF RecordedSetting; };
> >
>
> I think the description should be something like "A class derived from
> CIM_RecordedSetting which reflects the relationship between the
> recorded and current settings data for a virtualized disk device in a
> Xen domain." This class provides the association between recorded and
> current settings data objects.
>
> > I believe the accompanying C file would be similar to the
> > Xen_HostedDisk.c file.
> >
> > This same pattern could be applied to the other Xen_*RecordedSetting
> > files.
> >
> > Jim mentioned something on the call about the shim having to be
> > tweaked so it exposes the RecordedSetting stuff. Can you point me
> > to where that is?
> >
>
> xm.c contains the private function get_defined_domain() which returns
> an xm_config structure populated with settings found in the domain
> conf file. It could be used (perhaps with some refactoring of the
> code) as a source for recorded settings.
>
> > What are your thoughts here? What else needs to be done?
> >
>
> Your approach seems fine. However, keep in mind that we have not yet
> implemented the actual instantiation of 'recorded'
> CIM_ResourceAllocationSettingData instances. At this time we are only
> producing the 'current' instances. So I think the first step would be
> to produce the recorded settings, followed by implementing your
> suggested associations to tie the two together.
>
> Jim
>
>
> _______________________________________________
> Xen-cim mailing list
> Xen-cim@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-cim
--
Daniel Hiltgen (dhiltgen@xxxxxxxxxx) 650-384-4156 Virtual
Infrastructure Management CIM SDK
_______________________________________________
Xen-cim mailing list
Xen-cim@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-cim
|
Home