Hi all
Long story short: a long time ago I raised a bug [1] and I started to work on
the fix: GuoHui LIu (the reviewer) and myself had long and useful discussion
about the right solution for that but now we are stuck and we need some more
opinions to find a proper one.
And now the long story:
When we have an instance booted from a volume and we don't specify the image
details in the boot command the XML serialization of instance details fails and
the API call (like nova show) returns a 500 error.
The problem is that the image properties is mandatory to serialize but the xml
serializer can't manage properly an empty value.
In particular in the xmlutil we a have the class Selector which selects datum
within a specific object, that class is designed to deal with missing data in
the object but not to deal with an empty object.
At this moment to deal with missing data the logic used in the method is to
catch KeyError or IndexError exceptions:
try:
obj = obj[elem]
except (KeyError, IndexError):
if do_raise:
raise KeyError(elem)
My simple fix was to following the same logic and add a new exception to get
caught TypeError which is raised when the passed object is empty (it is an
empty string).
One of the main complain was that this approach tends to add some business
logic in the xmlutil and also adding a new exception could hide some potential
errors.
I can't disagree but at the same time I say that I am following the same logic
that we already have there.
We are now stuck, because the long-term solution probably is to rethink the XML
serialization process to allow more flexibility but that doesn't seem an easy
task and I really want to get this bug fixed.
What do you think?
Anyone is available to have a look and give us an opinion?
Please @Llu feel free to add your comments or any missing points.
PS: I am not an expert of the nova xmlutil, could be that I am missing some
easy points if so, please let me know.
Thanks
--
Andrea Rosa
[1] https://bugs.launchpad.net/nova/+bug/1223358
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
