When I shared the story behind migrating the blog to Jekyll and GitHub, I mentioned that one of the reasons for the migration was to embrace Git as a part of my regular workflow. I’d been recommending to folks that they learn and use Git, and now I needed to “walk the walk” as well as “talk the talk.” This post describes another step in my effort to “walk the walk.”
As the title of the post implies, this step involves the well-known tool Vagrant. (If you are unclear what Vagrant is or what it does, please read my quick introduction to Vagrant.) In the same presentation where I was recommending to folks to learn tools like Git, I was also recommending that they learn (and use, where applicable) tools like Vagrant. Once again, though, I was talking a good game but not backing it up with my actions. So, I’ve resolved to expand my use of Vagrant, sharing with all of my readers and followers along the way. And, because I believe that VMware Fusion is the most robust virtualization solution for Mac OS X, I’ll be using Vagrant with VMware Fusion.
So what will Continue reading
Nigel Poulton recently posted an article titled “ESXi vs. Hyper-V - Could Docker Support Be Significant,” in which he contemplates whether Microsoft’s announcement of Docker support on Windows will be a factor in the hypervisor battle between ESXi and Hyper-V. His post got me thinking—which is a good thing, I’d say—and I wanted to share my thoughts on the topic here.
Naturally, it’s worth pointing out that I work for VMware, although I do work in a business unit that makes a multi-hypervisor product (NSX).
Nigel makes a few key points in his article:
To be completely fair, the article fully admits that all this is assumption and is just thinking out loud (his statement, not a play on the title of this post). As I said, I think it’s a good thing to Continue reading
A number of readers have asked—via e-mail, of course, given the subject of this post—why comments aren’t available yet on the new site. I’d like to take a quick moment to explain the current situation.
First and foremost, it’s not because I don’t want feedback from readers. I would love to continue to have the outstanding feedback from readers that I’ve had over the last 9 years of this site. It’s also not because it’s too much trouble (too much comment spam, too much time to moderate, etc.). It’s not because enabling comments is too difficult, either.
If not these reasons, then why? With a static site generator like Jekyll, I’m left with very few options for handling comments. The most common way is to use a service like Disqus, but there are a number of privacy and security concerns around Disqus (see here for just one example). As a result, I’m hesitant to put my readers in the situation where the privacy of their information is outside my hands. At least with WordPress, readers’ personal information was under my control alone. Not so with a service like Disqus (or any of the hosted alternative solutions).
I’ve tried Continue reading
Now that I’ve provided you with an introduction to Git and a brief overview of using Git with GitHub, it’s time to build on that knowledge by taking a closer look at one workflow often used when collaborating with Git. The “fork and branch” workflow is a common way of collaborating on open source projects using Git and GitHub. In this post, I’m going to walk through this workflow (as I understand it—I’m constantly learning), with a focus toward helping those that are new to this sort of thing.
If you’re new to Git and/or GitHub and haven’t yet read the earlier posts on Git and using Git with GitHub, I strongly recommend you read those first.
Basically, the “fork and branch” workflow looks something like this:
Here’s a bit more Continue reading
Building on my earlier non-programmer’s introduction to Git, I wanted to talk a little bit about using Git with GitHub, a very popular service for hosting Git repositories. This post, in conjunction with the earlier introductory post on Git, will serve as the basis for a future post that talks about how to use Git and GitHub to collaborate with others on an open source project hosted on GitHub.
If you aren’t familiar with Git and haven’t yet read the earlier introductory post, I strongly recommend reading that post first.
Recall that Git is a distributed version control system (DVCS), and is designed to operate in such a way that full copies of repositories exist on multiple systems. This means you (as a single user) might have multiple copies of a repository across multiple systems. So how does one keep these repositories in sync? Generally, this would be handled via the use of a “server-side” repository to which the various repository clones are linked via a Git remote. This server-side repository might be hosted on an internal server or on a public server, and you may be connecting to it using the Git protocol, SSH, or HTTP(S). You Continue reading
In this post, I’m going to discuss some projects that I’ve set out for myself in the upcoming year. I’ve done this in years past, and the feedback that I’ve gotten from readers is that they found these posts to be quite helpful.
I first started posting annual project lists in January 2012, when I posted a list of some projects for 2012. In January 2013, I graded myself on my progress (spoiler alert: I didn’t do very well), followed by a new 2013 project list in early February. The series of posts ends in January 2014 when I assessed my 2013 performance.
Here’s what I’m seeing for myself with regard to 2015 projects:
Complete a new book. Having successfully transitioned the “Mastering VMware vSphere” series to Nick Marshall (who did an astounding job with the 5.5 release of the book), it’s time for me to get back into the book writing saddle. One of my projects for this coming year will be to complete a new book before the end of the year. This is a pretty significant effort, and it will absorb a large portion of my time and attention (as those who have written books can Continue reading
Git is a distributed version control system that is widely used by a number of open source projects. In this post, I’m going to provide a quick non-programmer’s introduction to Git, and encourage readers to spend some time getting familiar with Git. I think it is a time investment that will pay off down the road.
First, I’m going to provide some definitions/brief explanations in order to establish a foundation upon which you can build your Git knowledge. A version control system (sometimes just referred to as a VCS) is a system that tracks changes to files (or groups of files) over time.
The group of files that a VCS tracks is called a repository. The basic idea behind a VCS is that you could use it to “roll back” to an earlier version of any file (or group of files) in the repository in the event that the current version isn’t working or isn’t optimal. Almost all version control systems, including Git, support multiple repositories, and typically each repository would represent a particular project, component, or function. (I say “almost all version control systems” because there may be some VCS out there of which I am not aware that Continue reading
I just saw the news that Citrix has acquired Sanbolic, a storage virtualization company that I’ve written about before. (TechCrunch also has a quick write-up as well.) Early this year, Sanbolic announced their storage virtualization product, completing a pivot from offering a Windows-only solution (file system and volume manager) to a multi-platform solution that encompasses multiple storage tiers, multiple operating systems, and multiple hypervisors.
It will be interesting to see how this acquisition affects the virtualization industry. With the exception of a few major players running open source Xen, Citrix has thus far been unsuccessful (to my knowledge, correct me if I’m wrong) in making any significant inroads with XenServer (either commercial or open source). KVM seems to be the open source hypervisor of choice while VMware’s vSphere continues to dominate (for now) the commercial market—leaving XenServer with leftovers. The same can be said for CloudStack, which—with a few exceptions—is losing to OpenStack on the open source side and VMware’s offerings on the commercial side.
So the big question becomes, “Will the Sanbolic acquisition change things?” Will the addition of a storage virtualization solution that supports multiple operating systems and multiple hypervisors give Citrix an edge that Continue reading
In my post about the story behind the migration, I mentioned that I made extensive use of regular expressions (“regexes”) to help reformat portions of the Markdown documents that are used by Jekyll to build this site. In this post, I wanted to briefly share one of the regexes I used (and am still using) to convert URLs to Jekyll references.
First, let me clarify what I mean by Jekyll references. Jekyll offers a tag (not to be confused with content tags, more like a function) named post_url that will automatically build the correct URL when passed the filename of a content source. For example, if my _posts directory had a Markdown file named 2015-01-02-my-first-blog-post-of-2015.md, then I could use the filename (2015-01-02-my-first-blog-post-of-2015) inside a post_url tag, and Jekyll would automatically convert that to the appropriate permalink (URL) for that blog post. If the permalink ever changed for whatever reason, whenever the site is regenerated Jekyll would convert that tag to the new permalink. This helps you ensure that every time you update your site (which, when used on GitHub Pages like I’m doing, means every time you push commits to GitHub using git push origin Continue reading
Welcome to Technology Short Take #47! This is the first Technology Short Take for 2015 and the first to be published on the new blog platform. I have quite a bit of information to share this time around, so buckle up and let’s get started!
A number of people have asked me why I migrated from WordPress—which powered my blog for 9 years—to Jekyll and GitHub Pages. Now that the migration is finally complete, I can share with you the story behind the migration: why I migrated, the process I followed, and some of the tools I used.
“Why?” is a question I heard quite a bit as I was sharing updates on the progress of the blog migration over the Christmas/New Year holiday. It’s quite simple, really: I needed to walk the walk.
Allow me to explain. For the last couple of years, I’ve occasionally been giving presentations at VMUG meetings and other events on how to stay relevant in the fast-changing world of IT. The most recent instance was a whirlwind tour of Dallas, Chicago, and Phoenix in September of this last year, where I presented this deck, titled “Closing the Cloud Skills Gap.”
In that presentation, one of the recommendations I made to the audience was to become more familiar with the software development process. That includes tools like Git (and, by extension, GitHub), Vagrant (a quick introduction is available here), and others. I Continue reading
The blog migration is finally complete! It’s taken quite a while, but I’ve finally managed to migrate the over 1,600 posts from my original WordPress installation over to Jekyll hosted on GitHub Pages. I’ll have another post later that goes into more detail on the process that I followed (and why) as well as some of the tools that I used in the migration.
As of right now, there are 2 outstanding issues:
While all the content is here, what’s not here is the comments (yet). I’m still working through some issues with Disqus, but I hope to have the issues resolved soon.
Also, depending on when you read this, my original domain (“blog.scottlowe.org”) may or may not be working with the new content.
I appreciate your patience as I work through these issues.
I’d also appreciate it if you could let me know if you find anything that’s not working, such as links to other blog posts, code listings, images, etc. Because this entire site is a GitHub repo, if you’re so inclined you’re welcome to clone the repo, fix the problems, and submit a pull request. If you don’t feel like doing that, just drop me Continue reading
You might have noticed that blog content has been a bit sparse over the last few weeks. The reason I haven’t generated any new content is because all my spare time is taken up with preparing to migrate this site to a new hosting platform.
Sometime over the holiday season, I’ll be migrating this site from a hosted WordPress installation to Jekyll running on GitHub Pages. Given that I have 9 years of content (over 1,600 blog posts), this is a pretty fair amount of work.
Most of the “structural” work on the new site is already complete; you can get a preview of the site by visiting http://lowescott.github.io. There’s no content there yet (other than some boilerplate content), but you’ll be able to get a feel for how the new layout will look and work. As you can see, I’ll be using the Lanyon theme, which provides a nice clean layout and a good mobile as well as desktop experience.
There’s still some additional “structural” work to be done, such as adding support for comments (which will be handled via Disqus), but I hope to have that done in the next few days.
Once the Continue reading
You might have noticed that blog content has been a bit sparse over the last few weeks. The reason I haven’t generated any new content is because all my spare time is taken up with preparing to migrate this site to a new hosting platform.
Sometime over the holiday season, I’ll be migrating this site from a hosted WordPress installation to Jekyll running on GitHub Pages. Given that I have 9 years of content (over 1,600 blog posts), this is a pretty fair amount of work.
Most of the “structural” work on the new site is already complete; you can get a preview of the site by visiting http://lowescott.github.io. There’s no content there yet (other than some boilerplate content), but you’ll be able to get a feel for how the new layout will look and work. As you can see, I’ll be using the Lanyon theme, which provides a nice clean layout and a good mobile as well as desktop experience.
There’s still some additional “structural” work to be done, such as adding support for comments (which will be handled via Disqus), but I hope to have that done in the next few days.
Once the Continue reading
I’ve written quite a bit about Open vSwitch (OVS), but I realized recently that despite all the articles I’ve written I still haven’t talked about how to remove a configuration setting to OVS. I’m fixing that now with this article.
As part of my ongoing mission to give back to the open source community, I recently started making contributions and improvements to the OVS web site; specifically, I’ve been reformatting the configuration cookbooks to make them more readable (and to clean up the HTML source). Along the way, I’ve been adding small bits of content here and there. Most recently, I just updated the QoS rate-limiting entry, and I wanted to add information on how to remove the QoS settings.
Normally, you can remove an OVS configuration setting using the ovs-vsctl remove command. For example, if you set a VLAN tag on an port with this command:
ovs-vsctl set port vnet0 tag=100
Then you could remove that VLAN tag with this command:
ovs-vsctl remove port vnet0 tag 100
Note the slight syntactical difference in the two commands; the remove command expects four parameters.
It turns out, however, that this command won’t work for all configuration parameters. In some Continue reading
I’ve written quite a bit about Open vSwitch (OVS), but I realized recently that despite all the articles I’ve written I still haven’t talked about how to remove a configuration setting to OVS. I’m fixing that now with this article.
As part of my ongoing mission to give back to the open source community, I recently started making contributions and improvements to the OVS web site; specifically, I’ve been reformatting the configuration cookbooks to make them more readable (and to clean up the HTML source). Along the way, I’ve been adding small bits of content here and there. Most recently, I just updated the QoS rate-limiting entry, and I wanted to add information on how to remove the QoS settings.
Normally, you can remove an OVS configuration setting using the ovs-vsctl remove command. For example, if you set a VLAN tag on an port with this command:
ovs-vsctl set port vnet0 tag=100
Then you could remove that VLAN tag with this command:
ovs-vsctl remove port vnet0 tag 100
Note the slight syntactical difference in the two commands; the remove command expects four parameters.
It turns out, however, that this command won’t work for all configuration parameters. In some Continue reading
Welcome to Technology Short Take #46. That’s right, it’s time for yet another collection of links and articles from around the Internet on various data center-related technologies, products, projects, and efforts. As always, there is no rhyme or reason to my collection; this is just a glimpse into what I’ve seen over the past few weeks. I hope you are able to glean something useful.
Welcome to Technology Short Take #46. That’s right, it’s time for yet another collection of links and articles from around the Internet on various data center-related technologies, products, projects, and efforts. As always, there is no rhyme or reason to my collection; this is just a glimpse into what I’ve seen over the past few weeks. I hope you are able to glean something useful.
For non-programmers, making a meaningful contribution to an open source project can be difficult; this is as true for OpenStack as for other open source projects. Documentation is a way to contribute, but in the case of OpenStack there is a non-trivial setup required in order to be able to contribute to the OpenStack documentation. In this post, I’m going to share how to set up the tools to contribute to OpenStack documentation in the hopes that it will help others get past the “barrier to entry” that currently exists.
I’ve long wanted to be more involved in supporting the OpenStack community, beyond my unofficial support via advocacy and blogging about OpenStack. I felt that documentation might be a way to achieve that goal. After all, I’ve written books and have been blogging for 9 years, so I should be able to add some value via documentation contributions. However, the toolchain that the OpenStack documentation uses requires a certain level of familiarity with development-focused tools, and the “how to” guides were less than ideal because of assumptions made regarding the knowledge level of new contributors. For these reasons, I felt that sharing how I (a non-programmer) set up the tools Continue reading
For non-programmers, making a meaningful contribution to an open source project can be difficult; this is as true for OpenStack as for other open source projects. Documentation is a way to contribute, but in the case of OpenStack there is a non-trivial setup required in order to be able to contribute to the OpenStack documentation. In this post, I’m going to share how to set up the tools to contribute to OpenStack documentation in the hopes that it will help others get past the “barrier to entry” that currently exists.
I’ve long wanted to be more involved in supporting the OpenStack community, beyond my unofficial support via advocacy and blogging about OpenStack. I felt that documentation might be a way to achieve that goal. After all, I’ve written books and have been blogging for 9 years, so I should be able to add some value via documentation contributions. However, the toolchain that the OpenStack documentation uses requires a certain level of familiarity with development-focused tools, and the “how to” guides were less than ideal because of assumptions made regarding the knowledge level of new contributors. For these reasons, I felt that sharing how I (a non-programmer) set up the tools Continue reading