8:05 p.m.
Dear Boris and John,
Firstly thank you very much for your suggestion. Every comment from
you make me gain my knowledge on libvirt-cim. But I think I should
explain what the goal we want to reach.
The reason I got this mission is most of bugs reported recently is
users lost some of tags during resource operation. Even more serious is
the lost tag had nothing to do with the device they updated. For
example, if one attribute in <disk> device changed, the "model"
attribute in the <cpu> lost after updated! Isn't it a serious bug? What
should we do after a bug reported? One patch generated. And another bug,
another patch...But our users may fall into reporting bugs like this,
again and again.
After thought about the whole process carefully I think we may lost
my original intention. That is just adding some struture to keep some
unsupported tags without missing during updating even OTHER devices.
Hence, with regard to the device updating issue we ever focused on, an
option could be offered to the code may use it instead of user. Such as
<lun> and <disk> Boris mentioned. That situation is impossible occur now
because we haven't added this type into libvirt-cim so it belongs to
UNKNOWN_TYPE now. That option or some other hack code could be added
into this patch (maybe made in the future).
So my design is just designed a set of basic operations and use them
intead of changed the old pattern. All xml reading and generating logic
just like before.
As we discuss more the design becomes more complex. So I think I
should describe my new version design now,
1. Boris's data structure is so good that it looks very tiny and
suitable. That's a good choice to keep data structure and unsupported
tags now.
2. Basic operations based on macros is a good choice.
3. We shouldn't extend the function of data structure but just mark
it with status UNMANAGED, MANAGED and DELETED (UPDATED is not necessary
because all data just could be updated in the virt_device members now).
3. As to resource updating, we just could change the variables in the
libvirt-cim API so some resource updating issue would not occur.
4. I am glad to be responsible for all works about it.
At last, I sincerely hope get any suggestion from you to solve that
issue (my customers and boss almost take me to shreds because that),
even an absolutely new one :-)
Thanks,
Xu Wang
于 2013/12/2 16:28, Boris Fiuczynski 写道:
John and Xu,
in the last view days I have done some thinking about the idea from Xu
to work with the unknown tags and properties.
Starting off by looking at how one would get into the situation of
losing additional tags and properties I ended up with actually only
one feasible explanation: A libvirt-cim user wants to use a libvirt
feature not implemented in libvirt-cim.
With that in mind I revisited the new proposed pattern again:
Before I was thinking that the errors caused by new (unknown) tags and
properties are just kind of the reversal of losing the new (unknown)
tags and properties.
I now come to another conclusion: Now I think that the errors are far
worse than I thought, because as long as libvirt-cim is reducing
everything to the known management scope the libvirt-cim user has it
in his control to create and manage a new error free and working
libvirt domain.
With the new proposed pattern that is no longer true since if errors
are caused by new (unknown) tags and properties that are outside of
the known management scope of libvirt-cim the users have NO LONGER the
capability to fix these problems from within libvirt-cim!
What would be the result? I would guess that bugs would be opened
against libvirt-cim reporting that it creates erroneous libvirt domain
definitions.
I would really not like to see libvirt-cim fixes in support for
unsupported libvirt features which are caused by the new pattern of
how unknown tag and properties are maintained.
If currently bugs are opened that libvirt-cim is following the pattern
of reducing a domain definition to its known management scope the
answer is very easy: The used libvirt feature that is removed from the
domain definition is not supported by libvirt-cim and libvirt-cim only
maintains what it is supporting in the domain definition.
The question should actually be how the missing libvirt feature can be
implemented in libvirt-cim. This unsurprisingly correlates exactly
with the second paragraph above ("A libvirt-cim user wants to...").
In summary: I no longer agree to the idea of replacing the old pattern
with the new proposed pattern of how to handle unknown tags and
properties.
Sorry that it took me a while to realize that. I hope that my above
explanations can be followed of why I changed my mind.
On 11/26/2013 01:31 PM, Xu Wang wrote:
>
> 于 2013/11/23 0:18, Boris Fiuczynski 写道:
>> On 11/21/2013 04:15 AM, Xu Wang wrote:
>>>
>>> 于 2013/11/21 5:10, John Ferlan 写道:
>>>> On 11/20/2013 08:27 AM, Boris Fiuczynski wrote:
>>>>> John and Xu,
>>>>>
>>>>> On 11/19/2013 10:49 PM, John Ferlan wrote:
>>>>>> On 11/18/2013 09:59 AM, Boris Fiuczynski wrote:
>>>>>>> John and Xu Wang,
>>>>>>> here are a few general observations from side:
>>>>>> First off - I tend to find myself agreeing with Boris here. I
>>>>>> think the
>>>>>> concept is important and necessary; however, I'm not
convinced the
>>>>>> implementation goes far enough.
>>>>>>
>>>>>>> 1) I agree that it makes sense to preserve the unknown xml
>>>>>>> "entities"
>>>>>>> even so it can create complex scenarios and even new kinds
of
>>>>>>> errors if
>>>>>>> unknown entities depend on known entities which get modified
>>>>>>> making
>>>>>>> them
>>>>>>> unusable for the unknown entities. This error would probably
be
>>>>>>> the
>>>>>>> reversal of what is currently the problem when unknown
entities
>>>>>>> simply
>>>>>>> disappear.
>>>>>> Is there a more concrete example of "new kinds of errors if
unknown
>>>>>> entities depend on known entities which get modified making them
>>>>>> unusable for the unknown entities" that can be given? Just
for
>>>>>> clarity.
>>>>>> I've read that line a few times and I'm still not sure
:-)
>>>>> OK, let's take a look at device type disk.
>>>>> Since 1.0.2 the property sgio was added. Let's assume this is
the
>>>>> unknown entity. sgio is only valid for property device
"lun".
>>>>> If one now changes the property device to "disk" than the
unknown
>>>>> entity
>>>>> sgio would cause an error when specified.
>>>>>
>>>> Ah - I see. Not only do you have to manage the properties you
>>>> have to
>>>> know how to use them as well and all their rules. I forgot about
>>>> that. I
>>>> came from HP/HPVM and yes, this brings back all sorts of memories...
>>>>
>>>> Seems like in this case, when/if the property was changed from
>>>> "lun" to
>>>> "disk" - code would have to search that 'others' list
for the "sgio"
>>>> property and know how to handle adjusting it. That'll get tricky...
>> You cannot search in others for something you do not know about...
>> unless you can code magic! :-)
> If needed that's possible. We just coding just like...xpath. Before that
> we should make sure if it's necessary.