VMware, Inc. responded to issues raised by advanced users concerning version 4.1 of its PowerCLI scripting tool with a statement explaining the changes, as well as its perspective on the nature and scope of their impact.
Starting with version 4.1, the way PowerCLI refers to named objects is incompatible with scripts written in earlier versions, causing some scripts to “break,” and resulting in incompatibilities with popular third-party scripting tools, users reported.
According to Preetham Gopalaswamy, group product manager for VMware, the changes were made to accommodate the many updates to VMware’s vSphere product since PowerCLI was first introduced in 2007.
“At that time, there was one major offering from VMware: [Virtual Infrastructure],” Gopalaswamy said in a statement. “As we have introduced new products like vCloud Director and View -- all of which have an automation story through PowerCLI -- we have had to rethink our namespace to allow for further expansion.”
VMware claims the changes only affect users of Quest Software’s PowerGUI tool. “We want to make sure to clarify here that the compatibility issues being discussed are related to integration with PowerGUI. This means that only users of PowerGUI have the potential to be impacted. The vast majority of PowerCLI users will not experience problems and will not need to rewrite their PowerCLI 4.X scripts,” Gopalaswamy said.
As such, “to date, we have had zero customer support requests or escalations surrounding namespace/backward compatibility,” he added.
As for PowerGUI itself, Gopalaswamy said, “[Quest] has already announced a fix to alleviate any future issues. However, we are also actively engaging with PowerGUI engineering to ensure we have the best possible solution for customers and that we are sharing best practices for our joint customer base.”
The fix mentioned by Gopalaswamy, an aliasing scheme meant to accommodate deprecated object names into version 4.1, should allow users who do use named objects to keep version 4.0 scripts running, according to sources familiar with the 4.1.1 updates.
However, according to a separate VMware blog post from last month, this fix will be temporary. “[VMware plans] to remove the old [object] types in the release following 4.1.1. This means that no new scripts should be written based on the old types and legacy scripts should be updated to remove dependencies on the old types."
Quest looks to coordinate with VMware on PowerGUI updates
Meanwhile, rather than implement the fix in 4.1.1, Quest said it will support both PowerCLI 4.0 and PowerCLI 4.1 in tandem as it updates its code. PowerGUI pulls together multiple scripting tools under one interface using modules it calls Power Packs. Based on 107,000 unique downloads, the VMware Power Pack community for PowerGUI stands at about 30,000 users, estimated Kirk Munro, PowerGUI product manager. Overall, the PowerGUI tool has had more than a million downloads.
The problem with the 4.1.1 fix, said Munro, isn’t that the aliasing system doesn’t work, but that “right now there isn’t a graceful process for PowerGUI users to upgrade.” PowerGUI is automatically updated over the Web after users download it, he said, but the user also has to update PowerCLI independently to get both working together.
“There’s no way for me to send them the PowerCLI update, or coordinate the two, from my side,” Munro said. VMware and Quest have been in communication about how best to make sure users’ PowerGUI applications keep working as they should, he added.
Munro did quibble, however, with VMware’s assessment that the changes in PowerCLI 4.1 will only affect PowerGUI users, calling the comment “surprising.” According to Munro, “the changes to PowerCLI 4.1 affect a large number of scripts out there, in books, on blogs….Other [Microsoft] MVPs and vExperts I’ve spoken with have confirmed that.”
Strengthening ties with the PowerCLI community
At the same time, VMware denied a lack of communication with the PowerCLI users, and is moving to reestablish trust with the community.
“As is standard practice in the industry, we give customers and partners multiple releases to update their scripts/integrations to leverage the new API,” said VMware’s Gopalaswamy. “The fact is that as products evolve, older interfaces are deprecated -- change is unavoidable…this is…standard industry practice in APIs.”
Gopalaswamy said that members of the PowerCLI community have regularly scheduled meetings with VMware product management and engineering teams to discuss new release builds. “Is the process perfect? Of course not. But we are committed to maintaining an open dialogue with our customers and users.” Some insiders dispute the recent regularity of their meetings with VMware, but the company did hold a focus group meeting last Tuesday with PowerCLI power users to clear the air around PowerCLI 4.1.x.
Some PowerCLI users beg to differ with those statements. One virtualization admin at the focus group said he still felt the transition had not been in keeping with the “standard practice” cited by Gopalaswamy. “They say it is standard industry practice to deprecate older stuff, and to an extent, this is true,” this user said. “I would argue, however, that they are not doing it right.”
Take, for example, how Microsoft deals with APIs such as Windows Management Instrumentation (WMI). “I can use the same WMI query today to, for example, find the serial number of a server, as I could for a Windows NT 4.0 SP4 system from October 1998,” the user said.
“While the [focus group] meeting was great, you can hardly call that a regular occurrence,” the user added.
Another PowerCLI expert at the focus group, Luc Dekens, a systems engineer at a European organization, said he agrees with VMware that the scope of the problem had been previously blown out of proportion.
However, Dekens added, “I [also] agree with the fact that the way the last two PowerCLI builds were done was not very user-friendly.” Going forward, Dekens said he would urge VMware to keep the 4.1.1 fix around long enough to give Quest and others the opportunity to update code, and to present changes to “a selected subset of the PowerCLI community for feedback” before they are released.
According to Dekens, such a community has existed for quite some time, meeting in a private online forum with the VMware PowerCLI program manager. When the program manager moved to a new position, however, “the community landed into a vacuum and the private forum lost its usefulness.”
Quest’s Munro also cited the personnel transition as “the period where these accidents happened.” But now, he said, VMware is “back on track with the community, and being open and communicative.”
Beth Pariseau is a senior news writer for SearchServerVirtualization.com. Write to her at email@example.com.