DNS on my MacBook Pro has been a mystery to me. But, I can figure it out most of the time after a little bit of digging. This time, I have given up for the moment after spending too much time on this issue. The Problem This started sometime during the day on March 1, 2016. Everything was working before. I’m not aware of any updates to the OS or anything I did.
I’m just returning from the latest OpenStack Neutron mid-cycle in Rochestor, MN. It turned out to be great mid-cycle for me. I wanted to share a new idea that came out of it. The Problem One thing that has been on my mind for a while now is wasted IPv4 address space by Neutron. I guess I was waiting for someone else to bring the solution because I wasn’t personally feeling the pain yet but it is time to solve it once and for all.
An exciting new feature was just merged to Openstack Neutron in the Mitaka release; it’s called address scopes. Address scopes build from subnet pools added in Kilo. While subnet pools give us a mechanism for controlling the allocation of addresses to subnets, address scopes give Neutron a way to know where addresses are viable. They are also the thing within which addresses are not allowed to overlap. If you’re unfamiliar with them, you might want to review subnet pools before you read on.
Back in 2012, a new IP allocation was made called “shared address space.” At first glance, you might think that this allocation is just like the old RFC 1918 allocation. Maybe the IANA decided that we could use a fresh allocation of these things because our address space is feeling a little cramped. That wasn’t it. ISPs and other service providers needed an address space that can be reused in different geographies, doesn’t overlap with any global IP addresses and, just as importantly, won’t overlap with any private IP address usage on customers’ private networks.
Year 2000 I was an intern working on timing tools for the PA-RISC and Itanium processor projects at HP. We were starting a new C++ project. My mentor – who is a great engineer and I still admire in many ways – suggested that we use asserts to check certain invariants on entering and exiting methods. We could even do complex checks that reduced performance because once we finished all of our testing, we could just turn them off and it would all be great.
I got started in OpenStack when I took an unexpected job opportunity at HP to help stand up Neutron in the second release of HP Public Cloud. At the time, it was among the largest scale deployments of Neutron in existence. I suspect it was the largest at the time. One of the perks of the job was access to free virtual machines to use for work and even some personal use.
I’m not paranoid, I just like to think paranoid. I’m actually a pretty trusting person. But, I know the reality that if I let my guard down, someone will take advantage. I’ve had two bikes stolen because I let my guard down, I know this. But seriously, thinking paranoid, or defensively takes some serious thought, learning, and practice. And, I find it fun. With that in mind, I’d like to share how I handle passwords.
I was chatting with my brother last Saturday while we were watching a soccer game. He was frustrated with the lack of discipline in the developers at his new job. After a lengthy conversation, we agreed that much of the problem boiled down to something I feel very strongly about. I think this is a such a fundamental and obvious best practice that I would say if you’re doing it wrong then you should make it your highest priority task to go fix it now.
Since the beginning of Openstack Neutron (then Quantum), its logical model has centered around a networking layer 2 construct named the Network. The semantics of this construct have not always been clear. In fact, there have been some attempts to model layer 3 networks with it. They have resulted in some awkward implementations and don’t clearly communicate to the end user the capabilities of the network. Recent discussions on the mailing list and examining the code base have made it clear to me that the Network is meant to represent an L2 broadcast domain.
A new feature was added to Openstack Neutron in the Kilo release; it’s called subnet pools: a simple feature that has the potential to improve your workflow considerably. It also provides a building block from which other new features will be built in to Neutron. Turns out, I’m not the first to blog about this new feature. Click for mestery’s blog. Why you need them Before Kilo, Neutron had no automation around the addresses used to create a subnet.