Getting Stoned with "Project Onyx"
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

Getting Stoned with "Project Onyx"

on

  • 3,081 views

Introducing "Project Onyx" which is a code generator for use with vSphere Client. Just launch Onyx, connect to it with your vSphere Client, then any action you take is converted into real, functional ...

Introducing "Project Onyx" which is a code generator for use with vSphere Client. Just launch Onyx, connect to it with your vSphere Client, then any action you take is converted into real, functional code.

For more info visit http://vmware.com/go/onyx

Statistics

Views

Total Views
3,081
Views on SlideShare
3,073
Embed Views
8

Actions

Likes
1
Downloads
30
Comments
0

1 Embed 8

http://www.slideshare.net 8

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • I want to begin by saying something you might find a bit surprising. That is that none of you knows how to use the vSphere API. You may think you do, but can anyone in this room be truly confident that you’re doing things the right way?After all the documentation is sparse, there is no training, very few published best practices. And there is only one book in the entire world that even covers the use of VMware’s APIs.There are very few materials you can depend on. There’s practically nothing out there that shows you the right way to do things when you program against ESX or vCenter.So how can you be confident that you’re doing the right things? How can you be confident that you aren’t shipping hidden bugs that are just waiting to upset your customers and create an expensive crisis for you to deal with?
  • Let me illustrate what I mean about expensive. We all know that it’s cheaper to fix bugs when you’re building code than when you’re shipping code, but just how much cheaper is it? So this guy Barry Boehm, he’s about as big a name as you can find in software development, he’s the guy who created the spiral model of software development, he also pioneered a lot of work in the field of Software Economics in the 1980s, well he estimates that a bug is two to five times as expensive to fix when testing and more than 15 times as expensive to fix in the field versus when you are writing your code.So what? What is means is you have a huge incentive to do everything you can to reduce the number of bugs and improve the quality of your code. And code quality doesn’t mean the code is neat and readable, or that it compiles without warnings. Code quality means your code creates an experience your user expects, that it does just what your user wants it to do.
  • So let me tell you a little bit more about what you’re up against when you code against vSphere.First, the API has over 450 functions. You might say vSphere is a big product, big feature set, 450 sounds like a pretty small number and yeah it is. But there’s a dark side to this number. The main reason it’s so small is because behind many of these functions are hiding tens or even hundreds of use cases.Consider for example a little function called ReconfigVM. This is a little function that takes just a single argument. Just 1. On the other hand if you make any modification whatsoever to your VM, this is the function that gets used. Now that could be add a hard disk, changing the memory, assigning resource reservations, everything, all squeezed into one little function.If fact, if you count up all the properties in this one little function accepts, there are more than 300 of them that cover everything there is to do about configuring VMs.There are other examples. Virtual switches. Storage. Host profiles. The list goes on.The vSphere API is difficult to deal with.Difficult because most of the API is built with one specific client in mind, namely the developers of the vSphere Client. If fact if you look really closely it becomes obvious that many of them are purpose built for specific UI screens in the vSphere Client.Very complex, and very difficult for someone who doesn’t have a VMware badge in their pocket to deal with. How are you going to deal with this complexity? What can you do to be more confident in the software you’re writing?
  • No doubt all of you have seen several diagrams like this before.The point is that your code uses exactly the same API as VMware’s code.What if there was a way to write your application to behave exactly the same way as vSphere Client?What if there was a tool that would show you exactly what the vSphere Client is doing and how it does it.If you had such a tool you could … Learn from the experts at VMware.You could Borrow the best practices that VMware has put in place around using its API.And by using a tool like this you gain confidence that you’re doing things the right way, confidence that your code is as good as it can be and isn’t hiding expensive bugs that you’ll have to fix later.
  • Well guess what, there is just such a tool, from VMware, and it’s called Project Onyx.Onyx is quite simply a proxy that sits between your vSphere Client and ESX and converts all the calls your client makes into real, functional, executable code. Code, mind you, that does exactly what the vSphere Client does.With Onyx you can develop your software Faster, with Fewer Bugs, but most of all you Follow the best practices established by vSphere Client.
  • Let’s take a look at how Onyx operates. We have here a user, his laptop and a server that could be either ESX or vCenter.First: You launch Onyx on your laptop. Onyx runs as a service on port 1545.Second: Launch your vSphere Client and connect to http localhost 1545.When you do that, Onyx will then act as a proxy, and will connect out to your ESX or vCenter. Everything is secure, encrypted, and you don’t need to make any server-side changes whatsoever.The last step is to turn on Onyx’s script generation. When you do that, everything you click on, everything you do in the UI is turned into real, functional, executable code.
  • So what does this all mean?With Onyx, you as a developer, deliver fewer problems to QA, and ultimately fewer problems to your customers, because you are following the de-facto standards created within VMware on the proper use of the API.Consistent with the de-facto usage standards created by the vSphere Client.That means you will be using the same code paths that are tested and known to work by VMware QA.That means your customers will see fewer bugs and you’ll spend less time and effortWhat would you rather ship? Code that seems to work in your lab? Or code that has been tested and vetted across years of releases by VMware?
  • Briefly, how this simplifies the development process.Let’s say we want to change a VM’s MAC address.We have choice. We can dig through the vSphere API documentation, which is a very error prone process. Something that sounds as simple as changing a MAC address proves to be very difficult if you look at it, and chances are you’re going to have to try a few different approaches before you stumble upon the right one.With Onyx you use a tool that is familiar to you, and all the code needed to make the change is simply presented to you, and best of all it works exactly like the vSphere Client does. So whenever you have a vSphere programming problem you can’t figure out, Onyx is the solution.
  • This works no matter how difficult your use case is.Even the mechanics behind difficult things like distributed switches or host profiles are immediately obvious when you use Onyx.
  • Now Onyx is not perfect, you have to look at the code it generates with a developer’s eye. The code has to be refactored before it’s ready for use.For one thing Onyx shows you what it sees very literally and that means that things like object IDs are hard-coded.In a moment I’m going to introduce 4 rules that establish a systematic process for converting Onyx code into your language of choice, then we’ll see some examples of these rules in action.
  • Let’s get into a hands-on demo. I’m going to hook Onyx up to an ESX instance I have running on my laptop, generate code for various things and then show the steps to take that code and convert it into VI Java code.If you’re a Java user and you haven’t used VI Java you should really take a look, it’s easy to use, the performance is good, and it also provides more object-orientation than the vSphere API itself provides through the use of first-class Java objects for things like CD-ROM drives and the like. If you’re a Java developer and looking at integrating with VMware, this is well worth checking out.
  • I mentioned 4 rules, here they are.Read the rules.These will make a lot more sense as we go through the demo, so don’t worry if these don’t make sense to you just yet.
  • Demo Scenarios:0. Change a VM’s memory.1. Add a second hard disk.2. Change a network adapter’s network3. Enable VMotion4. Reconfigure console allocations
  • Poll questions for audience:???

Getting Stoned with "Project Onyx" Presentation Transcript

  • 1. Getting Stoned with “Project Onyx”
  • 2. You Don’t Know How To Use The VMware API!
    • How much confidence do you have in the code you ship?
    • 3. How can you be sure you’re not setting an expensive trap for yourself?
    Documentation is sparse.
    No training.
    No developer certifications.
    Few published best practices.
    Limited samples.
    Only one book on the market.
  • 4. That’s Just Like, You Know, Your Opinion, Man.
    Cost of fixing bugs is huge.
    But the worst is when you find bugs in the field.
    What bugs are you shipping that you don’t even know about?
  • 5. The Blunt Truth About vSphere API.
    Quick facts about the vSphere API.
    Over 450 functions.
    Some functions hide dozens of use cases.
    The single argument to ReconfigVM contains 306 nested properties.
    Total of 69 optional properties when reconfiguring switches or portgroups.
    Total of 52 properties when configuring iSCSI targets.
    Not object-oriented, many things lack object representation.
    VM CDROM drives.
    VM network cards.
    Virtual switches.
    Very complex, taking years to master.
  • 6. You use the same API that VMware does!
    Re-Hashing Some Old Details.
    Learn from the experts
    Borrow best practices
    Your Code!
    vSphere Client
    vSphere Web Services
    vCenter
    ESX
    ESX
    ESX
    ESX
    ESX
  • 7. Blaze Through Your Product Development Cycle With Onyx.
    There is a tool just like that! “Project Onyx”!
    What is “Project Onyx”?
    Client-side proxy software.
    Macro record style code generation.
    Convert vSphere Client requests to code.
    From the creators of PowerCLI.
    Generates functional PowerShell code.
    Can be easily converted to other languages such as Java or C#.
    With Onyx your development:
    Faster!
    Fewer Bugs!
    Follows Best Practices!
  • 8. Onyx: Your Stepping Stone To High Performance.
    ESX or vCenter
    • Launch Onyx on your client, runs on port 1545.
    • 9. Start vSphere Client, connect to http://localhost:1545/
    • 10. Onyx connects to your ESX or vCenter via https.
    • 11. Any action after that can be turned into code.
  • Do You Really Want To Roll Your Own Way?
    You have a choice:
    Fly blind and try to figure out the API yourself.
    Hope you get it right and your customers don’t dream of strangling you.
    OR
    Use the same practices and de-facto standards as VMware uses.
    Use the same tested and vetted code paths VMware has used for years.
    Fewer bugs to QA.
    Fewer bugs to your customers.
    Spend more time on what matters.
    Onyx automates this process.
  • 12. Let Onyx Smoke Out The Details For You.
    Let’s say you need to figure out how to set a VM’s MAC address.
    Old way:
    Open the vSphere API documentation.
    Try to find a network card object.
    Discover there is no network card object, so grope around in the VM object.
    Discover the virtual hardware array, poke around looking for network cards.
    (About 5 more steps omitted.)
    With Onyx:
    Launch Onyx and log in.
    Edit the VM’s properties.
    Change the MAC address.
    Look at the code that Onyx generated for you.
    It’s that simple!
  • 13. End Chronic Confusion Syndrome.
    Onyx sees everything and can explain everything.
    Turn anything the vSphere Client can do into code, no matter how complex.
    You don’t waste time digging through API references.
    You don’t waste time figuring out complex property relationships.
  • 14. Don’t Get Burned By These Gotchas.
    Onyx code requires human review and refactoring.
    Object IDs are constant and hard-coded.
    Unnecessary code may be generated.
    Code is not complete and functional, you have to add supporting logic.
  • 15. A Joint Demo With VI Java API.
    What exactly is VI Java?
    A Java binding to the vSphere Web Service API!
    An alternative to the vSphere Web Services SDK!
    True object-oriented model!
    High performance! (http://vijmark.sf.net)
    Open source! (http://vijava.sf.net)
    Provides POJO for many things not objectified by vSphere API!
    (Although Onyx cannot take advantage of that!)
    Demo shows how to convert Onyx code to VI Java code.
    VM.
    Storage.
    Network.
  • 16. The Science.
    4 rules for converting into your language of choice.
    Create objects when Onyx does, use the same name.
    Assemble the overall object at the end.
    Bring your own code for looking up IDs.
    Replace Get-View with class methods or static lookup code.
  • 17. DEMO
    http://vmware.com/go/onyx
  • 18. Get Hooked Up!
    Conclusion:
    vSphere API is hard.
    Onyx makes it less hard.
    4 rules for converting into your language of choice.
    Create objects when Onyx does, use the same name.
    Assemble the overall object at the end.
    Bring your own code for looking up IDs.
    Replace Get-View with class methods or static lookup code.
    Net result:
    Faster Development
    Fewer Bugs.
    Follow Best Practices.
    But wait there’s more!
    Debug your own clients with Onyx!
  • 19. Time Keeps Slipping Into The Future
    Onyx Future Possibilities.
    Java / C#.
    Integration into vSphere Client.
    Code refactoring and function/method generation.
    What do you want to see?
  • 20. Get Hooked Up!
    http://vmware.com/go/onyx
    Download.
    Watch the getting started video.
    Give feedback.
  • 21. Q+A
    http://vmware.com/go/onyx