If you find yourself needing to enable Swift on DevStack and you already have DevStack deployed and running and do not want to redo the whole thing I can relate. I found myself in this exact spot tonight. By default DevStack does not enable Swift, but its really trivial to enable it. The tricky part may be once its enabled how do you make it work without just redoing the whole thing?>
Getting Swift enabled is pretty simple. First open your local.conf file in your /home/stack/devstack directory using your favorite editor. Next add the following lines to it: enable_service s-proxy s-object s-container s-account
And save the file. If you havent built your DevStack yet now you can simply proceed with ./stack.sh If you have already built your DevStack and its up and running simply proceed with ./unstack.sh and when that completes then proceed with the ./stack.sh During the install it will prompt you for a hash/passphrase and I just used the same password I used for the initial DevStack install. Once this process finishes you should have Swift added to your DevStack. Happy Stacking!
Today I am proud to announce that I have released yavijava-6.0.01 This was a huge task for me to complete. While doing it I realized if I wanted to get these done in a timely manor going forward I would need some automated tool to help get the work done. I spent a couple of days and built a tool called yavijava_generator. It is a tool written in Groovy that will parse the HTML docs provided by VMWare and generate the new classes and update old ones with new properties speeding up the process to deliver new versions by 100’s of times. This release today includes some bug fixes as well. A security flaw was pointed out to on the vijava forums about vijava changing the global security context when you passed the ignoreInvalidSSL flag. I have addressed that in this release. I have also included a massive amount of logging. If you want to see ALL the SOAP payloads being sent to the server, and the payloads the server is sending you all you have to do is enable trace level logging on com.vmware Please be aware this WILL INCLUDE PASSWORDS in plain text in your log files. I have also made a lot of progress in testing coverage. Please upgrade to this version and et me know if you run into any problems.
Do you currently use vijava? Have you noticed how the forums are kind of dead (meaning lots of questions, but no one from the project answering those questions), and there have not been any more community releases since 2013 or so ending with 5.5 beta? I noticed these things, and so I did something about it. I forked the project and started maintaing it. I have done a lot of work on the project. I have added logging using log4j. I have added the ability to RESET VCENTER ALARMS FROM RED TO GREEN. I have fixed several bugs including a bug where every single exception was being wrapped in a RemoteException causing you to have to check the exception.getCause() to find the underlying exception instead of being able to catch normal vCenter exceptions. I have refactored the code allowing you the user to provide your own HTTP clients should you need to, and even added a great deal of tests to the code (this is an ongoing work in process). I also converted the project to use gradle. This makes building the project a snap.. But wait theres more!! I fixed a bug in the InventoryNavigator which made the 5.5 release not work properly with vSphere 6.0.. speaking of 6.0 I have been hard at work adding support for vSphere 6.0 and Im happy to announce the beta release is done and available right now! With the help of people from the community work is being done RIGHT NOW to add SPBM support to yavijava as well!! One of the best parts about all of this is that I have maintained compatibility with vijava so switching to yavijava is painless for you the user!
So.. How do you switch? Switching is simple. If you have a project using maven you can simply update your pom, or gradle, or what ever to point at the yavijava repo. As of this blog post the current stable release is 5.5.11. If you are just grabbing the jar file to include in your project some other way thats fine too. Please be aware that I did introduce new dependencies, so if you are manually downloading jar files (you should consider stopping that and moving to gradle its super easy to do) be sure to check the build file for the latest requirements.
If you do run into any issues please report those issues on the GitHub issue tracker. When you submit an issue please consider reading over this basic guide I created. If you do not have a bug but just have a question, you are welcome and encouraged to open an issue and ask your question there, or join the web chat and ask there, just be sure if you cant wait around for an answer to open a GitHub issue.
I really look forward to growing the community and bringing it new life. Please help me spread the word about yavijava, and welcome to the community!
I’ve been hard at work adding support for vSphere 6.0 to yavijava, the vijava fork. Im happy to announce that I am done and ready for a beta release. I am not going to push this to public maven right now. For those of you who want to test this release out please download the release from GitHub. Next follow these simple instructions to build a jar.
Unzip the 6.0.01b1.zip file
Enter the yavijava-6.0.01b1 folder
On Linux or Mac use ./gradlew build
On Windows use gradlew.bat build
A jar file will be built for you and it will be located in the build/libs directory.
If you run into any issues please please please report them to me so I can get them fixed. Simply go to https://github.com/yavijava/yavijava/issues and open a new issue.
As many of you may or may not know there were some significant changes with regards to SSL in python 2.7.9 which introduce a default verify ssl cert where in the past it was ignored. This creates one hell of a problem when using pyVmomi because 99% of us use the default self signed certs created during the install process of our vCenters or ESXi systems. This problem has been reported afewtimes now. I answered the question on the mailing list of how to work around the problem, but figured I would add it here as well because there is so much confusion over how to work around the problem until we are able to get upstream pyVmomi patched up.
To work around this issue:
_create_unverified_https_context = ssl._create_unverified_context
# Legacy Python that doesn't verify HTTPS certificates by default
# Handle target environment that doesn't support HTTPS verification
ssl._create_default_https_context = _create_unverified_https_context
Add this to your scripts or tools that need to connect. This will make your scripts continue to work like they did on 2.7.8 and older where the default was to ignore the cert and not check it. I hope to see a fix added to upstream pyVmomi soon.
If you didn’t already know I created a fork of vijava called yavijava. It is quickly becoming a pretty popular alternative to using vijava due to the features I have implemented like fixing the InventoryNavigator in the current production release found in public maven central. That fix makes 5.5.10 and newer releases have a functional InventoryNavigator on vSphere 6.0. Ive also added other features like logging using log4j, and the ability to reset Alarms from red to green. Ive also been hard at work adding full support for vSphere 6. With all of these things going on I also decided the project was getting so popular it was time to move it to its own GitHub Org.
A lot of these things have caused a great deal of confusion for end users of the library. Questions like:
Which version of yavijava should I be using?
Im using vSphere 6. Shouldnt I be using the vsphere_6 branch of yavijava?!?
Where do I report issues Im having with yavijava?
Is there a place for chat support?
I plan to address these questions in this post. Ill start by answering the first question of Which version of yavijava should I use? The answer to that depends. Ill start by asking you a very important question:
Are you looking for the latest stable and supported version for use in production code?
If your answer to that question is YES! then you need to be using the latest version available in public maven.
Now for question number 2 Im using vSphere 6. Shouldnt I be using the vsphere_6 branch of yavijava?!? Let me ask you another question to help answer that for you:
Are you comfortable testing an ALPHA version of a library that is in no way ready for production use?
Are you a developer who is looking to help get vSphere 6 fully supported by submitting code to yavijava that implements new properties, DataObjects, or ManagedObjects so the new features added to vSphere 6 will work in yavijava?
Are you a tester who is wanting to help get vSphere 6 fully supported in yavijava by submitting detailed bug reports about things in vsphere_6 branch that have been implemented but are not working?
Unless you answered YES! to some or all of those questions DO NOT USE vsphere_6 BRANCH! Support for vSphere 6 in the vsphere_6 branch is NOT DONE. There is a lot of work left to do and pretty basic stuff will fail until the work is done.
Now for the next question: Where do I report issues Im having with yavijava? This one is pretty easy.
If you are using vijava 5.x stable or beta release and you are ready to move on to vSphere 6 then find your InventoryNavigator is giving you problems and your code isnt working as expected anymore give yavijava a try. I fixed an issue with the InventoryNavigator class that is part of 5.5.10-DEVELOPMENT and newer releases of YAVIJAVA. Since 6.0 went GA today I will be pushing 5.5.10 to public maven this weekend.
Im currently working on adding all the new ManagedObjects and DataObjects that are part of 6.0 to YAVIJAVA and should have an official 6.0 release in a couple of weeks. If you want to help out with those efforts or just follow the development feel free to tune into this branch on GitHub where I am pushing all of the vSphere 6 code before it gets merged into the primary release branch.
Are you testing new versions of vSphere with VIJAVA and finding problems with the InventoryNavigator? Missing properties, and missing inventory are common complaints when using VIJAVA and new versions of vSphere. Never fear though! YAVIJAVA is here to save the day!!
The InventoryNavigator is not a default part of the VI SOAP API and was added by the creator of VIJAVA. In that class he uses the PropertyCollectorUtil to create complex TraversalSpecs that can be used to traverse an inventory very quickly. VIJAVA has been around for a very long time and supports many versions of vSphere. To do that there are a couple of helper methods in the PropertyCollectorUtil that can be used to make traversal specs. One of them is meant for use on older vSphere systems (pre 4.0), and one of them is meant for use on version 4 and newer vSphere systems. In the InventoryNavigator there was a check being done against the string that contained the API version to try to decide which version of the TraversalSpec creator should be used. The problem with new versions of vSphere and any version of VIJAVA (as of March 8th 2015) is that VIJAVA has a conditional where it was looking specifically for version 4 or 5 in the version string to load the newer TraversalSpec method. I reworked that logic in the YAVIJAVA code base for now so if it finds any version >=4 it will load the newer TraversalSpec else it loads the old one. Give it a try on those newer vSphere versions and report any issues you may have in the GitHub issues. This rework was added to 5.5.10-DEVELOPMENT I plan to release 5.5.10 to public maven in April. To use the development version just check out the code from github and use gradle to build the jar with the following commands:
git clone https://github.com/yavijava/yavijava && cd yavijava && gradle build
This will build the jars for you. Take a look in build/libs/ for all the jar files.
I began working on a fork of VIJAVA several months ago. I have reached a point where I feel it is ready for its first mainstream release. I have now pushed it to central maven. I have been using this in production now for a few months, and I am no longer giving it the beta mark and I am calling it production ready for vSphere 5.5 The versioning I am using is . so the current production release is 5.5.07 where 5.5 is the vSphere version and 07 is the release number. Please use and report any bugs to the Github issue tracker. YAVIJAVA is basically a drop in replacement for VIJAVA with the exception that new dependencies have been added, but this will NOT require a code change to use. One of the biggest benefits this release gains you from using VIJAVA is logging. Logging has been missing from VIJAVA and at times can really make troubleshooting issues nearly impossible. Now there is TONS of logging. Just configure your log4j for com.vmware Another benefit is the ability to use your own custom http clients. I have provided 1 using the Apache Http Commons library as an example, but the original http client is the default.
Do you need to set some kind of Key, Value info up on a VirtualMachine in vCenter that you can access from the API? I thought with 5.5 and the addition of this that there was going to be some kind of actual Matadata fields added to the vSphere API, but it seems that still hasnt happened, as this is incomplete and missing any way to actually use it. The good news is that since 4.0 there has been a way to add key value pairs to the vm.config.extraConfig. The key has to be a String, and the Value can be an object. I have used this to store all kinds of stuff from Strings to JSON and XML payloads and even base64 encoded files. I wrote a sample for the pyVmomi-community-samples project that uses the vm.config.extraConfig to store some key value pairs. You can get it here until it gets accepted by the project and merged into master.