WilliamLam.com

RSS feed for VMware release notes

by // 9 Comments

Staying up to date with the latest VMware product releases can be a challenge and with something like VMware Cloud on AWS, which is delivered as a service, it can be even more tricky as new updates are constantly being made available. Historically, there has not been a consistent method for how customers can get notified of new releases and this has also come up from our VMware Cloud on AWS customers.

We posed the challenge to our Information Exchange (documentation) team to see how we can help our VMware Cloud on AWS customers and the team came back with an initial implementation of providing a standard RSS feed which you can now find at the upper right hand corner of the VMware Cloud on AWS release notes page. You can subscribe using your favorite RSS reader, I personally use Feedly and when a new release of the SDDC and/or service, you will get notified via your RSS reader. For those that want a different delivery mechanism such as email for example, you can use the free If This, Than That (IFTTT) service which I also personally use and setup an email notification or any other type of notification that IFTTT supports.


Although this initial requirement was driven by the VMware Cloud on AWS product team, we definitely wanted to see this capability delivered across all VMware products and services which is what the team has done as well. When you navigate to a specific product and/or service release notes, you will now see the additional RSS feed that you can subscribe to.

Here are just a few of the popular RSS feeds that I know folks will want to subscribe to. For a complete list of all VMware product/services, please take a look here.

I think this be a great first step in helping our customers easily get notified of new releases, so that can start reviewing the release notes and start planning. I know many of you have also asked for other methods such as programmatic access to release notes updates or even having a specific changelog for things like our APIs. If folks have any feedback in this area, feel free to leave a comment and I will be more than happy to share this with our documentation team.

Configuring Github Actions self-hosted runners on PhotonOS 

by // Leave a Comment

Ever since Github announced Github Actions, which is now generally available for everyone, I have been a huge fan of the service. I even shared a blog post earlier this year on how you can easily incorporate automated application deployment to a vSphere or VMware Cloud on AWS based environment, which can automatically be triggered by native developer workflows directly from Github. This can be a really powerful and enabling capability for your developers, especially when taking advantage of an on-demand solution like VMware Cloud on AWS.
Right before VMworld Barcelona, I saw a tweet from the Github Twitter account announcing another cool feature which is the ability to run your own self-hosted runners. By default, when you use Github Actions, the runners are hosted by Github and when a Docker Container is launched, it is running within their infrastructure. During the beta, I had noticed some inconsistencies on how long it would take my Github Actions to kickoff which is usually within a minute or so but I have seen cases where it has gone up 5 to 10 minutes.

I was told that this was an infrastructure issue, but it did raise an interesting question in my mind on SLAs. As far as I know, nothing is publicly documented and Github also mentioned they did not have an SLA for the service. If you need a more predictable experience, you now have the option of running the "runners" in your own infrastructure which can be on-premises environment or even a public cloud where you have available compute capacity.

I finally got a chance to explore this capability and of course, I had to figure out how to get this working with our very own VMware PhotonOS. With a bit of trial and error, I was able to get everything working. In fact, I was able to run my Github runner directly in my VMware Cloud on AWS environment which can be quite useful for customers with development and CI/CD-based workloads and being able to leverage Github Actions.

[Read more...]

Listing all Events for vCenter Server

by // 4 Comments

I had a conversation with one of our VMware Cloud on AWS field leaders a couple of weeks ago at reInvent on his initial experience with the vCenter Event Broker Appliance (VEBA) Fling. There were lots great feedback but one thing that stood out to me which looks to have been a barrier to getting started was being able to figure out a specific vCenter Event and its respective identifier. Although the list of "default" vCenter Events are documented in the vSphere API, it is definitely not the first place most folks would go to look nor is it very intuitive to browse.

To be honest, this is not a unique ask for VEBA. I have also seen this requests come up from customers who are automating vCenter Alarms, which can also be based off of vCenter Events and the same question has come up on before. One challenge with such a request is that the number and the types of vCenter Events will vary from customer to customer depending on the number of 2nd and 3rd party solutions deployed, not to mention it will also vary from version to version. In addition, as a customer, you can also publish your own custom Events into vCenter Server which makes this difficult to provide a single list that would cover all possible scenarios.

Ultimately, this ask is completely valid and I started to look at the vSphere API to see if there was something that could help. It did not take look before I stumbled onto the EventDescription which is part of the EventManager, which provides a nice registry for all currently registered vCenter Events. Time for some Automation 🙂

[Read more...]