Today, I’m pleased to announce that the PowerShell and Python libraries have been released. They are currently under the MIT OpenSource license. These libraries are available for customers to download and utilize for their own scripting purposes. Of course, the source code is available for anyone to download and modify for their own purposes. Each library provides methods for customers or partners to submit feedback, issues and other discussions.
So enough babbling, onto the sources!
PowerShell
The PowreShell library is hosted on CodePlex (http://hponeview.codeplex.com). Anyone with a valid Microsoft Account and/or a CodePlex account can subscribe to the site and monitor the project. Downloading releases or source code does NOT require authentication. With each update of the library, a new installer will be provided for easy use. Downloading the source code and samples can either be performed with your browser, or by using a GIT client. A pretty awesome Windows GIT client is available here: http://windows.github.com/
This CodePlex site also provides an issues tracker, for reported issues or feature requests.
Python
We are now officially live on the external GitHub site. The repository is here: https://github.com/HewlettPackard/python-hpOneView
The public mailing list is here, please sign up so we can move development discussions to this external list: https://groups.google.com/forum/#!forum/hp-oneview-python
As both projects are hosted on GIT-compliant sites, the following is common for either:
There is a tremendous amount of documentation on the web about git.
One of the best references is the git book which I strongly suggest you read if you are not familiar with git: http://git-scm.com/book
One of the key things that we as commuters need to agree on is the repository layout and overall workflow. Since this is an extremely small project we can use a very standard simple workflow where the "master" branch will always be the "top of tree" trunk and we will simply tag each of our release and only branch a release if we need to do a bug fix on a specific release.
Unlike other version control solutions branching in git is almost free, so that becomes the cornerstone of a standard workflow. Let me give an example:
I checkout the repo:
git clone [repo]
Let's say that I want to work on implementing the Logical Interconnect Groups features. I can create a topic branch just to contain that work (this is a short cut of a couple different commands to create then switch to a new branch"
git checkout -b "LIG_Work"
I can hack away on my feature and do as many commits as I feel like.
When I'm happy with my solution and am getting ready to commit it back to the trunk (aka master) branch. I can simply switch back and then merge my LIG_Work branch into the master:
git checkout master
git merge LIG_Work
Let's say that I was half way through my LIG_Work but it isn't finished but we decided that ID Pools is a higher priority. I can simply switch back to the master branch (which is our top of tree
trunk) and create a new branch to work on the ID Pool feature:
git checkout master
git checkout -b "ID_Pools"
Now I have multiple branches each with different content. If you run a git branch command you can see a list of your branches and which one you are currently on:
$ git branch
* ID_Pool
LIG_Work
master
After you finish the work on the ID_Pool branch you can simply switch back to the master and merge in your working branch onto the trunk.
These temporary working branches are generally called topic branches.
The idea is that you can develop in a clean branch without affecting anything else then after your merge your branch you simply delete it.
This is a very simplified example of a simple work flow but hopefully it is enough to point you in the right direction. Let me know if you have any questions by asking questions here in the HP OneView Communities forum.
I am an HPE employee
