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
This is part 18 of the Learning NSX blog series, in which I talk about using layer 3 (L3) routing with VMware NSX but without network address translation (NAT). This post describes a configuration that offers yet another connectivity option for OpenStack cloud administrators and operators.
In part 6, I showed you how to add a gateway appliance to your NSX installation. Part 9 leveraged the gateway appliances to create a L3 gateway service, which—as I explained in part 15—provides the functionality for logical routers in OpenStack. (Logical routing was covered in part 14.) Part 16 expanded the routing configuration to support multiple external networks. This post expands the options again by showing you how to do logical routing without using network address translation (NAT). Of course, it would probably be helpful to read the entire series; links to all posts can be found on the Learning NVP/NSX page.
As I mentioned, so far you’ve seen three different external connectivity options:
Both of the routed Continue reading
This is part 18 of the Learning NSX blog series, in which I talk about using layer 3 (L3) routing with VMware NSX but without network address translation (NAT). This post describes a configuration that offers yet another connectivity option for OpenStack cloud administrators and operators.
In part 6, I showed you how to add a gateway appliance to your NSX installation. Part 9 leveraged the gateway appliances to create a L3 gateway service, which—as I explained in part 15—provides the functionality for logical routers in OpenStack. (Logical routing was covered in part 14.) Part 16 expanded the routing configuration to support multiple external networks. This post expands the options again by showing you how to do logical routing without using network address translation (NAT). Of course, it would probably be helpful to read the entire series; links to all posts can be found on the Learning NVP/NSX page.
As I mentioned, so far you’ve seen three different external connectivity options:
Routing (layer 3 connectivity) to a single external network
Routing (layer 3 connectivity) to multiple external networks using VLANs
Bridging (layer 2 connectivity) between a logical network and a physical broadcast domain
Both of the routed Continue reading
This is part 17 of the Learning NSX blog series. In this post, I’ll show you how to add layer 2 (L2) connectivity to your NSX environment, and how to leverage that L2 connectivity in an NSX-powered OpenStack implementation. This will allow you, as an operator of an NSX-powered OpenStack cloud, to offer L2/bridged connectivity to your tenants as an additional option.
As you might expect, this post does build on content from previous posts in the series. Links to all the posts in the series are available on the Learning NVP/NSX page; in particular, this post will leverage content from part 6. Additionally, I’ll be discussing using NSX in the context of OpenStack, so reviewing part 11 and part 12 might also be helpful.
There are 4 basic steps to adding L2 connectivity to your NSX-powered OpenStack environment:
This is part 17 of the Learning NSX blog series. In this post, I’ll show you how to add layer 2 (L2) connectivity to your NSX environment, and how to leverage that L2 connectivity in an NSX-powered OpenStack implementation. This will allow you, as an operator of an NSX-powered OpenStack cloud, to offer L2/bridged connectivity to your tenants as an additional option.
As you might expect, this post does build on content from previous posts in the series. Links to all the posts in the series are available on the Learning NVP/NSX page; in particular, this post will leverage content from part 6. Additionally, I’ll be discussing using NSX in the context of OpenStack, so reviewing part 11 and part 12 might also be helpful.
There are 4 basic steps to adding L2 connectivity to your NSX-powered OpenStack environment:
Add at least one NSX gateway appliance to your NSX implementation. (Ideally, you would add two NSX gateway appliances for redundancy.)
Create an NSX L2 gateway service.
Configure OpenStack for L2 connectivity by configuring Neutron to use the L2 gateway service you just created.
Add L2 connectivity to a Neutron logical network by attaching to the L2 gateway service.
In this post, I’ll describe a technique I found for simplifying the use of multi-machine Vagrantfiles by extracting configuration data into a separate YAML file. This technique is by no means something that I invented or created, so I can’t take any credit whatsoever; this is an idea I first saw here. I wanted to share it here in the hopes that it might prove useful to a larger audience.
If you aren’t familiar with Vagrant and Vagrantfiles, you might start with my quick introduction to Vagrant.
I found this technique after trying to find a way to simplify the creation of multiple machines using Vagrant. Specifically, I was trying to create multiple instances of CoreOS along with an Ubuntu instance for testing things like etcd, fleet, Docker, etc. The Vagrantfile was getting more and more complex, and making changes (to add another CoreOS node, for example) wasn’t as straightforward as I would have liked.
So what’s the fix? As with other DSLs (domain-specific languages) such as Puppet, the fix was found in separating the data from the code. In Puppet, that means parameterizing the module or class, and I needed to use a similar technique here with Vagrant. So, Continue reading
In this post, I’ll describe a technique I found for simplifying the use of multi-machine Vagrantfiles by extracting configuration data into a separate YAML file. This technique is by no means something that I invented or created, so I can’t take any credit whatsoever; this is an idea I first saw here. I wanted to share it here in the hopes that it might prove useful to a larger audience.
If you aren’t familiar with Vagrant and Vagrantfiles, you might start with my quick introduction to Vagrant.
I found this technique after trying to find a way to simplify the creation of multiple machines using Vagrant. Specifically, I was trying to create multiple instances of CoreOS along with an Ubuntu instance for testing things like etcd, fleet, Docker, etc. The Vagrantfile was getting more and more complex, and making changes (to add another CoreOS node, for example) wasn’t as straightforward as I would have liked.
So what’s the fix? As with other DSLs (domain-specific languages) such as Puppet, the fix was found in separating the data from the code. In Puppet, that means parameterizing the module or class, and I needed to use a similar technique here with Vagrant. So, Continue reading
It’s no secret that I’m something of a photography enthusiast. To me, photography is a relaxing puzzle of how to assemble all the various pieces—setting, lighting, exposure, composition, etc.—to create just the right image. I’m not an expert, but that’s OK; I just do this for fun and to relax. If you’d like to see a small sampling of some of the photos I’ve taken, I publish some of them here on 500px.com.
I know that a fair number of folks in the IT industry are also photo enthusiasts, and so I was curious to hear some feedback from fellow enthusiasts about their photography workflows. In particular, I’m curious to know about how others answer these questions:
It’s no secret that I’m something of a photography enthusiast. To me, photography is a relaxing puzzle of how to assemble all the various pieces—setting, lighting, exposure, composition, etc.—to create just the right image. I’m not an expert, but that’s OK; I just do this for fun and to relax. If you’d like to see a small sampling of some of the photos I’ve taken, I publish some of them here on 500px.com.
I know that a fair number of folks in the IT industry are also photo enthusiasts, and so I was curious to hear some feedback from fellow enthusiasts about their photography workflows. In particular, I’m curious to know about how others answer these questions:
What formats do you use with your photos? (I’ve been shooting in RAW—NEF, specifically, since I’m a Nikon guy—then converting to Adobe DNG for use with Lightroom.)
How do you handle long-term storage of your photos? (Once I have the photos in DNG in Lightroom, then I’ve been archiving the RAW files on my Synology NAS.)
What pictures do you keep—all of them, or only the best ones? (So far, I’ve been keeping all the RAW files, archiving when Continue reading
This is part 16 of the Learning NSX series, in which I will show you how to configure VMware NSX to route to multiple external VLANs. This configuration will allow you to have logical routers that could be uplinked to any of the external VLANs, providing additional flexibility for consumers of NSX logical networks.
Naturally, this post builds on all the previous entries in this series, so I encourage you to visit the Learning NVP/NSX page for links to previous posts. Because I’ll specifically be discussing NSX gateways and routing, there are some posts that are more applicable than others; specifically, I strongly recommend reviewing part 6, part 9, part 14, and part 15. Additionally, I’ll assume you’re using VMware NSX with OpenStack, so reviewing part 11 and part 12 might also be helpful.
Ready? Let’s start with a very quick review.
You may recall from part 6 that the NSX gateway appliance is the piece of VMware NSX that handles traffic into or out of logical networks. As such, the NSX gateway appliance is something of a “three-legged” appliance:
This is part 16 of the Learning NSX series, in which I will show you how to configure VMware NSX to route to multiple external VLANs. This configuration will allow you to have logical routers that could be uplinked to any of the external VLANs, providing additional flexibility for consumers of NSX logical networks.
Naturally, this post builds on all the previous entries in this series, so I encourage you to visit the Learning NVP/NSX page for links to previous posts. Because I’ll specifically be discussing NSX gateways and routing, there are some posts that are more applicable than others; specifically, I strongly recommend reviewing part 6, part 9, part 14, and part 15. Additionally, I’ll assume you’re using VMware NSX with OpenStack, so reviewing part 11 and part 12 might also be helpful.
Ready? Let’s start with a very quick review.
You may recall from part 6 that the NSX gateway appliance is the piece of VMware NSX that handles traffic into or out of logical networks. As such, the NSX gateway appliance is something of a “three-legged” appliance:
One “leg” (network interface) provides management connectivity among the gateway appliance and Continue reading
Welcome to Technology Short Take #45. As usual, I’ve gathered a collection of links to various articles pertaining to data center-related technologies for your enjoyment. Here’s hoping you find something useful!