Add support for the Sms APIs

[hartsock]

Reference: http://ruby-doc.org/gems/docs/r/rbvmomi-1.8.1/RbVmomi/SMS.html

[grzn]

I have a question. It seems that the pyVmomi package inside ESXi servers (located at /lib/python2.6/site-packages) already includes support for SMS and EsxCLI (there are promising files like SmsObjects.py and ReflectType.py).

Why not just add those files to this repository?

[hartsock]

Basically there's an open source fork and a proprietary fork of the project. We are still negotiating how we are going to proceed between the two. My hope is to avoid duplication of effort, for example @wiggin15 is pressing ahead with SMS support ... which you have pointed out exists already. So, we may be left with pursuing unofficial support for SMS and SSO. If we do go that route, we will run the risk of creating two incompatible libraries. I suggested the development of pyvmomi-tools to hold any unoffical bindings.

NOTE: Support for the OpenSource version of pyVmomi is considered unoffiical in any legal sense, since it will not be part of any official support package you can purchase... so my designation of official and unofficial is really about to degree. There's the gold supported pyvmomi included inside the vCenter release, this silver supported library and then the bronze support in pyvmomi-tools ... at least that's what I'd like to see.

CAVEAT: This is all my own observation of the situation and VMware itself has not committed to a course of action on these topics yet.

EDIT: and it should be noted I am working harder than I would if I didn't care about compatibility between the two versions. There will be periods of cross porting between the open and closed versions. This period of cross porting means I have to be much more conservative in modifying the library than I would have to be if I were to simply discard the possibility of cross-porting between the versions of the code.

[grzn]

I asked why not to publicly share all the managed objects and data types. This information exists in the documentation, implemented in the public Java SDK, and apparently exists in the internal pyvmomi repository,and you already have the marshalling infrastructure in the public pyvmomi. You just need to add the missing managed objects and data types.

From what I understand -- the marshalling component (pyvmomi/pyVmomi) should come directly from VMware and if it contains everything, then the community doesn't need to touch this part of the package, and you could just merge the changes from the internal repositories after every vSphere release.

The other part in the package is the component that handles the HTTP connections (pyvmomi/pyVim), and it makes sense the internal and public versions will have different implementations because of the varying use-cases (SSO, SSL client-side certificated, proxies, concurrency and coroutines, etc...). It may very will be that vCenter has one implementation for this part, ESXi has another since it benefits from other things that exists within the hypervisor, and the public pyvmomi will have a different implementation that is more generic and fits a wider range of use-cases.

That's what I think should be in pyvmomi, and on top of these blocks, the community can build facades and wrappers, and put them in a community-owned repository like pyvmomi-tools. This is the place for cached property collectors with builders for common traversals, sophisticated task managers, command-line tools for managing vSphere, etc...

[hartsock]

I've actually forwarded this thread to business decision makers inside VMware.

First, I don't know why we can't open source all the API. I've asked for some clarification of what I can and can't get into here.

Secondly, I personally don't like the scan-and-load strategy employed in this version of pyVmomi as it points out the large number of API we can't use here. I am researching a way to reverse this relationship between the plugins and the pyVmomi library. I actually like @wiggin15 's refactor on that principle since it moves in the right direction. I'm just not clear if his change will break one of those 34 other modules @wiggin15 can't see the code to and can't test... (albeit his change is unlikely to break anything we need to have some mechanism in place to address such changes in the event a desirable but breaking change does come along).

[sparrc]

@hartsock, Any updates on this? I'd love to get access to the APIs that grzn is talking about, it's a bit clunky to have to decompile .pyc files within our workflow.

As grzn also mentioned, all of these APIs are publicly documented and available within the Java SDK. It's not clear to me why the business decision at VMware would be to restrict the python development tools more than Java.

[hartsock]

@cameronsparr I'm assigned to a new project right now and I'm on a critical path so I've not had much time the last few months to donate to pyVmomi. I am expecting @parthgala to start making contributions in these directions as he's coming up to speed on the project.

[tianhao64]

Sms api type is uploaded. Feel free to give it a try and report any issues. Thank you!

[wiggin15]

Hi @tianhao64, thank you very much for the inclusion of the SMS API in pyvmomi. To use the SMS API using sms.ServiceInstance, the user must instantiate the class with a SoapStubAdapter. It is mandatory that this adapter send an additional SOAP header named vcSessionCookie for authentication. It is currently trivial to pass this SOAP header and not possible to do that without affecting all stub adapters in the thread: the code that adds SOAP headers is in https://github.com/vmware/pyvmomi/blob/master/pyVmomi/SoapAdapter.py#L874, and from here we can see that the user must change _threadLocalContext['reqCtx']. This is not good because it requires changing an internal global variable and also affects the thread context, which means that the regular clients are affected to. Please see the discussion and commit in https://github.com/vmware/pyvmomi/pull/165.

[tianhao64]

Hi @wiggin15 , I will forward your message and proposed changes to my team and try to get back to you probably next week.

[wiggin15]

@tianhao64 is there an update?