[libvirt] [PATCH] ESX: append CURL headers to fix serviceContent entities
Append curl headers with "SOAPAction" header to populate serviceContent object entities which are otherwise missing. --- src/esx/esx_vi.c | 2 ++ src/esx/esx_vi_generator.input | 3 +++ 2 files changed, 5 insertions(+) diff --git a/src/esx/esx_vi.c b/src/esx/esx_vi.c index 99c1eb1..a379183 100644 --- a/src/esx/esx_vi.c +++ b/src/esx/esx_vi.c @@ -322,6 +322,8 @@ esxVI_CURL_Connect(esxVI_CURL *curl, esxUtil_ParsedUri *parsedUri) * approx. 2 sec per POST operation. */ curl->headers = curl_slist_append(curl->headers, "Expect:"); + curl->headers = curl_slist_append(curl->headers, + _("SOAPAction: \"urn:vim25\"")); if (curl->headers == NULL) { virReportError(VIR_ERR_INTERNAL_ERROR, "%s", diff --git a/src/esx/esx_vi_generator.input b/src/esx/esx_vi_generator.input index 22c114e..236dcb3 100644 --- a/src/esx/esx_vi_generator.input +++ b/src/esx/esx_vi_generator.input @@ -1008,6 +1008,8 @@ object ServiceContent ManagedObjectReference clusterProfileManager o ManagedObjectReference complianceManager o ManagedObjectReference localizationManager o + ManagedObjectReference storageResourceManager o + ManagedObjectReference guestOperationsManager o end @@ -1073,6 +1075,7 @@ object UserSession DateTime lastActiveTime r String locale r String messageLocale r + Boolean extensionSession o end -- 1.7.9.5
Please hold off reviews on this post. I've been testing and analyzing some other piece of code (the one that do not need connection headers to include urn:vim25 namespace), but I observed that this namespace include causes lot of other issues such as:1. It breaks existing APIs due to ordering issues of Object variables during serialization.2. Introduces/exposes lot of other fields that were not present earlier causing "warning" messages during deserialization (this one is benign, but first one is FATAL).BUT, if this namespace is not included it not only prevents populating of ServiceContent object but also hides some API methods such as: ParseDescriptor, ImportVApp and CreateImportSpec etc. I'm thinking of limiting the impact and update the headers only inside the routines where its needed and revert back the headers on exit (given it is necessary evil). Please suggest if there is a better idea. Thanks !Ata
From: ata.husain@hotmail.com To: libvir-list@redhat.com CC: ata.husain@hotmail.com Subject: [PATCH] ESX: append CURL headers to fix serviceContent entities Date: Tue, 25 Dec 2012 16:44:23 -0800
Append curl headers with "SOAPAction" header to populate serviceContent object entities which are otherwise missing. --- src/esx/esx_vi.c | 2 ++ src/esx/esx_vi_generator.input | 3 +++ 2 files changed, 5 insertions(+)
diff --git a/src/esx/esx_vi.c b/src/esx/esx_vi.c index 99c1eb1..a379183 100644 --- a/src/esx/esx_vi.c +++ b/src/esx/esx_vi.c @@ -322,6 +322,8 @@ esxVI_CURL_Connect(esxVI_CURL *curl, esxUtil_ParsedUri *parsedUri) * approx. 2 sec per POST operation. */ curl->headers = curl_slist_append(curl->headers, "Expect:"); + curl->headers = curl_slist_append(curl->headers, + _("SOAPAction: \"urn:vim25\""));
if (curl->headers == NULL) { virReportError(VIR_ERR_INTERNAL_ERROR, "%s", diff --git a/src/esx/esx_vi_generator.input b/src/esx/esx_vi_generator.input index 22c114e..236dcb3 100644 --- a/src/esx/esx_vi_generator.input +++ b/src/esx/esx_vi_generator.input @@ -1008,6 +1008,8 @@ object ServiceContent ManagedObjectReference clusterProfileManager o ManagedObjectReference complianceManager o ManagedObjectReference localizationManager o + ManagedObjectReference storageResourceManager o + ManagedObjectReference guestOperationsManager o end
@@ -1073,6 +1075,7 @@ object UserSession DateTime lastActiveTime r String locale r String messageLocale r + Boolean extensionSession o end
-- 1.7.9.5
2012/12/31 Ata Bohra <ata.husain@hotmail.com>:
Please hold off reviews on this post. I've been testing and analyzing some other piece of code (the one that do not need connection headers to include urn:vim25 namespace), but I observed that this namespace include causes lot of other issues such as: 1. It breaks existing APIs due to ordering issues of Object variables during serialization.
Yes, the ESX server is picky about the ordering here. That's a problem.
2. Introduces/exposes lot of other fields that were not present earlier causing "warning" messages during deserialization (this one is benign, but first one is FATAL).
The warnings about unexpected fields are leftovers from the early development stage of the ESX driver. They can be removed if the get in the way.
BUT, if this namespace is not included it not only prevents populating of ServiceContent object but also hides some API methods such as: ParseDescriptor, ImportVApp and CreateImportSpec etc. I'm thinking of limiting the impact and update the headers only inside the routines where its needed and revert back the headers on exit (given it is necessary evil). Please suggest if there is a better idea.
Currently the ESX driver uses only functions and objects from the vSphere API 2.5 (at least it should). This allows it to deal with older ESX server versions down to 3.5. What you're trying to do now is using functions added in a newer vSphere API, don't you? I assume that all the fields and functions you're talking about, that require the SOAPAction header, were added in vSphere API 4.0 or later. Is it documented somewhere that you need to pass the SOAPAction header to the server in order to access vSphere API > 2.5 features? But the real problem could be the serialization order. If this is really different between vSphere API 2.5 and 4.x than we need to decide this at runtime and also extend the generator to know bot orderings. This can become very ugly.
Thanks ! Ata
From: ata.husain@hotmail.com To: libvir-list@redhat.com CC: ata.husain@hotmail.com Subject: [PATCH] ESX: append CURL headers to fix serviceContent entities Date: Tue, 25 Dec 2012 16:44:23 -0800
Append curl headers with "SOAPAction" header to populate serviceContent object entities which are otherwise missing. --- src/esx/esx_vi.c | 2 ++ src/esx/esx_vi_generator.input | 3 +++ 2 files changed, 5 insertions(+)
diff --git a/src/esx/esx_vi.c b/src/esx/esx_vi.c index 99c1eb1..a379183 100644 --- a/src/esx/esx_vi.c +++ b/src/esx/esx_vi.c @@ -322,6 +322,8 @@ esxVI_CURL_Connect(esxVI_CURL *curl, esxUtil_ParsedUri *parsedUri) * approx. 2 sec per POST operation. */ curl->headers = curl_slist_append(curl->headers, "Expect:"); + curl->headers = curl_slist_append(curl->headers, + _("SOAPAction: \"urn:vim25\""));
if (curl->headers == NULL) { virReportError(VIR_ERR_INTERNAL_ERROR, "%s", diff --git a/src/esx/esx_vi_generator.input b/src/esx/esx_vi_generator.input index 22c114e..236dcb3 100644 --- a/src/esx/esx_vi_generator.input +++ b/src/esx/esx_vi_generator.input @@ -1008,6 +1008,8 @@ object ServiceContent ManagedObjectReference clusterProfileManager o ManagedObjectReference complianceManager o ManagedObjectReference localizationManager o + ManagedObjectReference storageResourceManager o + ManagedObjectReference guestOperationsManager o end
@@ -1073,6 +1075,7 @@ object UserSession DateTime lastActiveTime r String locale r String messageLocale r + Boolean extensionSession o end
-- 1.7.9.5
-- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
-- Matthias Bolte http://photron.blogspot.com
Currently the ESX driver uses only functions and objects from the vSphere API 2.5 (at least it should). This allows it to deal with older ESX server versions down to 3.5. What you're trying to do now is using functions added in a newer vSphere API, don't you? I assume that all the fields and functions you're talking about, that require the SOAPAction header, were added in vSphere API 4.0 or later.
Is it documented somewhere that you need to pass the SOAPAction header to the server in order to access vSphere API > 2.5 features?
But the real problem could be the serialization order. If this is really different between vSphere API 2.5 and 4.x than we need to decide this at runtime and also extend the generator to know bot orderings. This can become very ugly. After going back n forth on options, I found that limiting header modification to one-two functions may not hurt that bad. This is what I am doing at the moment: inside the desired function:1. instantiate the a new header (curl_slist *header) and populate it with desired fields.2. Replace priv->primary->curl->header with new header (preserving the old one)3. As part of cleanup revert back old header item to priv->primary->curl. This way I was able to limit the impact of API version change to a routine, else it was getting real messy to make it certain that nothing existing will break elsewhere. Thanks!Ata
Thanks ! Ata
From: ata.husain@hotmail.com To: libvir-list@redhat.com CC: ata.husain@hotmail.com Subject: [PATCH] ESX: append CURL headers to fix serviceContent entities Date: Tue, 25 Dec 2012 16:44:23 -0800
Append curl headers with "SOAPAction" header to populate serviceContent object entities which are otherwise missing. --- src/esx/esx_vi.c | 2 ++ src/esx/esx_vi_generator.input | 3 +++ 2 files changed, 5 insertions(+)
diff --git a/src/esx/esx_vi.c b/src/esx/esx_vi.c index 99c1eb1..a379183 100644 --- a/src/esx/esx_vi.c +++ b/src/esx/esx_vi.c @@ -322,6 +322,8 @@ esxVI_CURL_Connect(esxVI_CURL *curl, esxUtil_ParsedUri *parsedUri) * approx. 2 sec per POST operation. */ curl->headers = curl_slist_append(curl->headers, "Expect:"); + curl->headers = curl_slist_append(curl->headers, + _("SOAPAction: \"urn:vim25\""));
if (curl->headers == NULL) { virReportError(VIR_ERR_INTERNAL_ERROR, "%s", diff --git a/src/esx/esx_vi_generator.input b/src/esx/esx_vi_generator.input index 22c114e..236dcb3 100644 --- a/src/esx/esx_vi_generator.input +++ b/src/esx/esx_vi_generator.input @@ -1008,6 +1008,8 @@ object ServiceContent ManagedObjectReference clusterProfileManager o ManagedObjectReference complianceManager o ManagedObjectReference localizationManager o + ManagedObjectReference storageResourceManager o + ManagedObjectReference guestOperationsManager o end
@@ -1073,6 +1075,7 @@ object UserSession DateTime lastActiveTime r String locale r String messageLocale r + Boolean extensionSession o end
-- 1.7.9.5
-- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
-- Matthias Bolte http://photron.blogspot.com
participants (3)
-
Ata Bohra -
Ata E Husain Bohra
-
Matthias Bolte