EverythingShouldBeVirtual part of Methodical Cloud

We’ve Moved: Welcome to Methodical Cloud

2025-04-28T00:00:00-04:00

After many years of ideas, exploration, and community through Everything Should Be Virtual, it’s time for the next chapter.

We’re proud to announce that our work continues at Methodical Cloud — a new content-driven platform dedicated to clarity in automation, workflow design, and building scalable systems.

While the name has changed, the mission remains: bringing clarity and purpose to complex infrastructure and automation challenges.

You can now find all future blog posts, podcasts, and educational resources at:

👉 Visit Methodical Cloud

Thank you for being part of the journey. We’re just getting started!

Searching for the Source(s) of Truth in Automation

2024-07-01T10:00:00-04:00

Walk into almost any enterprise and you will find the same thing. Three teams, three tools, no shared view. The networking team has stood up Nautobot or NetBox. The systems team has picked something else entirely. The application team does not care about either one as long as their service runs somewhere. Nobody federated anything. Everybody calls their tool the Source of Truth.

I have seen this play out at scale. The pattern does not change. This is not a failure of execution. This is the actual state of the industry. The Single Source of Truth, the one tool that holds everything for the whole enterprise, is a fantasy. It does not exist, and chasing it is how teams burn quarters with nothing to show.

The interesting work starts when you stop chasing it and accept the distributed reality instead.

The networking team picks well and builds a silo

Networking teams almost always land on Nautobot or NetBox. That is the right call. They are good at networking, those tools are built for networking, and the data inside them is detailed and reliable. Devices, configurations, topology, IPAM. It is solid.

The problem is not the tool. The problem is that the tool becomes an island. The networking SoT was never designed to integrate with the systems or application view, and the team that built it had no reason to make it. They solved their problem correctly and created a silo in the process. That is not a contradiction. It is just what happens when each team optimizes for itself.

The systems team builds on top and stops short

Systems teams sit on top of what networking provides. Servers, virtual machines, storage, the things networking does not track. Broader scope, in theory. In practice they fall short of integrating fully with either the network layer below or the application layer above, so they end up standing up yet another SoT that talks to nobody.

The application team does not care

Application teams want their service available and performing. That is it. The underlying infrastructure, the network configs, the inventory that the other two teams obsess over, none of it registers as their problem. And honestly, from where they sit, that is a reasonable position. It just means there is no third party with any incentive to tie the first two together.

CMDBs, ServiceNow, and the discovery problem

This is usually where someone says the CMDB solves it. A central repository for every asset and relationship, kept current by discovery. ServiceNow gets pointed to most often, and on paper it is a reasonable fit for the role.

In practice, the discovery process is where it falls apart. I have walked into more than one environment where ServiceNow discovery was misconfigured, partially deployed, or quietly broken, and the data inside was wrong in ways nobody had caught. A CMDB that is feeding stale or incomplete data is worse than no CMDB, because people trust it. The tool is not the issue. The discovery feeding it almost always is.

Source control gets handed the same role, and Git is great for configuration and infrastructure as code: version history, review, audit. But it tracks intended state over time, not current state right now. At scale, with enough repos and branches and contributors, drift between what is committed and what is actually running becomes its own problem. Source control is a fine SoT for some things. It is not the SoT for everything.

Stop trying to make one tool do it all

The answer is not a better single tool. The answer is accepting multiple Sources of Truth and federating them on purpose. Let the networking team keep Nautobot or NetBox. Let the systems team keep theirs. Then build the integration between them deliberately, API-first, so each team uses its best-fit tool and shares data where sharing actually matters.

That is the part most organizations skip. They either keep fighting for one tool to rule everything, or they let the silos sit there unconnected and call it good. The work that pays off is in the middle: deliberate federation across tools that were never meant to talk, with each one honest about exactly what it covers and what it does not.

It will be interesting to see how Opsmill Infrahub handles this. It is built around the idea of managing multiple sources of truth rather than pretending one can hold everything, which is the right framing. I have not had the time to dig into it properly yet, but it looks promising. It is the first thing in a while pointed at the actual problem.

What I Learned Watching Teams Automate Without a Center of Gravity

2024-06-29T13:00:00-04:00

It has been a little over three years since I last wrote anything here, and the biggest change in that time is not a tool or a platform. It is what I do day to day. I used to build the automation myself. Now I lead the engineers who build it.

I will be honest. I miss the hands-on work.

What I have gained is a wider view. When you build one team’s automation, you see one team’s problems. When you lead across a dozen engagements, you start to see the same failure mode over and over.

Teams automate without a center of gravity for their standards. One group picks up Ansible and writes roles their way. Another group across the org picks up Ansible and writes roles a completely different way. A third bolts on Terraform with its own conventions. Six months later there are fifteen different ways to do the same thing, no shared modules, no agreed naming, and nobody who owns the platform. The automation that was supposed to reduce toil has become its own source of toil. The thing meant to fix the entropy is now generating it.

This is the part I keep coming back to with clients, and it is why I push the Automation Center of Excellence harder than anything else I recommend. I know “Center of Excellence” sounds like a slide somebody made to justify a reorg. A CoE is the answer to a real problem I have watched play out at scale, across large-scale SRE engagements and enterprise client work. It is the place where the standards live. Someone owns the shared modules. Someone decides how things get named. Someone says no when a team wants to reinvent a wheel that already rolls fine. It is not bureaucracy. It is the difference between automation as an asset and automation as fifteen competing dialects nobody can maintain.

Most of the work itself is hybrid cloud. On-prem and cloud together, Ansible and Terraform together, and a client who needs the same outcome on both sides without two separate teams maintaining two separate truths. That is where the standards question gets sharp, because a hybrid environment punishes inconsistency faster than a single platform ever will.

If you are automating right now and you cannot point to who owns your standards, fix that before anything else. Not the next tool. Not the next platform. The center of gravity. Everything else falls apart without it, and I have watched it fall apart enough times to stop treating it as optional.

NFD24 - DriveNets

2021-03-02T09:00:00-05:00

Recently I had the privilege to attend NFD 24 in which DriveNets presented. I had never heard of them until this event. Which I am shaming myself for because they are doing some amazing things around transforming the network market.

One of the primary things that caught my attention was around what they are doing by disaggregating network functions. This is something that I have experienced in some capacity or another over the past few years. And when I understood what they were doing, I was immediately interested.

They have two products in which I will touch on in this post. One being DNOS and the other is DNOR.

DNOS - DriveNets Network Operating System

DNOS is a fully featured networking stack that runs on servers and white boxes. DNOS leverages many cloud and virtualization technologies to make this a fully distributed OS running as Docker containers in your network. DNOS separates the data plane on a cluster of white boxes and the control plane on any environment supporting containers. Therefore, disaggregating the data and control plane for massive scale.

DNOR - DriveNets Network Orchestrator

DNOR is an orchestrator in which automates the deployment, scaling and management of the DriveNets Cloud solution. Therefore accelerating the deployment of cloud-native networks.

Because of these automated operations provided by DNOR, life-cycle management of things such as: Zero-touch provisioning, modular software orchestration, and scale-up and scale-down are operationalized. Providing benefits such as: shorter maintenance windows, simplified operations, and improved reliability.

Another benefit of DNOR is complete visibility of your network. This means that such things as: cluster views, availability, and performance within hardware and software is visible. In turn, this assists in troubleshooting issues faster and ensuring that network performance and availability are proactively monitored.

Target Audience

From what I gathered at this point, it appears that service providers are the target audience for DriveNets. With that being said, AT&T became the first in the industry to implement DriveNets disaggregated core routing platform. This is obviously a huge win for DriveNets, and they definitely did a great job highlighting this during their presentation. Huge props to the DriveNets team on this for sure.

Conclusion

Although I have only highlighted two of DriveNets products here, I plan on digging more into their products more in depth as time permits. As I mentioned at the start of this post, I’ve been exposed to a few implementations over the past several years where DriveNets would have been a game changer. So, I’ll definitely be keeping an eye on what they are doing over time.

DISCLAIMER: I have been invited to Network Field Day Exclusive by Gestalt IT who paid for travel, hotel, meals and transportation. I did not receive any compensation to attend NFD and I am under no obligation whatsoever to write any content related to NFD. The contents of these blog posts represent my personal opinions about the products and solutions presented during NFD.

Ubuntu 20.04 - cloud-init Gotchas

2020-08-25T22:41:00-04:00

Recently while working on my latest Packer Templates I ran into an issue with Ubuntu 20.04. The issue was related to cloud-init not being able to grow the root partition nor change the hostname. I was testing this on Proxmox using Terraform.

NOTE: terraform-provider-proxmox

Obviously these are two very important capabilities when provisioning cloud instances. So, why was this not working? Well I started Googling and of course nothing was coming up that would give me a clue. So, I started digging into logs, etc. And sure enough, I found in the log that these two capabilities were not working because of the file /etc/cloud/cloud.cfg.d/99-installer.cfg.

An example of the contents of /etc/cloud/cloud.cfg.d/99-installer.cfg:

datasource:
  None:
    metadata: {instance-id: 872e2bc0-9805-4623-bdda-5e8bcca540dc}
    userdata_raw: "#cloud-config\ngrowpart: {mode: 'off'}\nlocale: en_US.UTF-8\npreserve_hostname:\
      \ true\nresize_rootfs: false\nusers:\n- gecos: packer\n  groups: [adm, cdrom,\
      \ dip, plugdev, lxd, sudo]\n  lock_passwd: false\n  name: packer\n  passwd:\
      \ $6$AA.Jw829.bXpJ4w$bf2mI99OoUo2F4/rSfnAD9vNg2vjOiJaynMSeOgZcE3PB/OMCRgYuon74mIyzgUiXBEA8/VluqEQuZBGcQq5B.\n\
      \  shell: /bin/bash\n"
datasource_list: [None]

From the above example you can see that growpart: {mode: 'off} and preserve_hostname: true are set. This right here was the cause of my issues. So, to resolve this issue. Simply delete the file and you are good to go!

Just sharing this with folks in case you ever run into this as well.

Enjoy!

CFD7 - VMware TKG

2020-05-05T01:00:00-04:00

Recently I had the pleasure to attend #CFD7 in which VMware presented VMware Tanzu Kubernetes Grid. Our friend, Kendrick Coleman did a great job presenting TKG to us. Even squashed a few questions/concerns along the way. Of course, not all of them were squashed but..

NOTE: Current version of Kubernetes supported as of #CFD7 - 1.17.3

What Is TKG

Directly from the VMware TKG docs, TKG can be summed up as:

VMware Tanzu™ Kubernetes Grid™ provides organizations with a consistent, upstream-compatible, regional Kubernetes substrate across software-defined datacenters (SDDC) and public cloud environments, that is ready for end-user workloads and ecosystem integrations. Tanzu Kubernetes Grid builds on trusted upstream and community projects and delivers a Kubernetes platform that is engineered and supported by VMware, so that you do not have to build your Kubernetes environment by yourself.

TKG is the core component of Kubernetes deployments. This component applies to all implementations. TKG uses Kubernetes to deploy Kubernetes. Ummm What? Yep, you heard that! WOW! I can hear the comments of how complex this sounds. However, it does sound like it. But it actually makes sense to ensure a consistent deployment across all implementations. But, it is very complex and not for the faint at heart. The reality is, if they never showed TKG CLI and the underlying constructs, no one would likely question the complexity. But here we are!

TKG extends core Kubernetes by using a Custom Resource Definition(CRD). This CRD defines specific resources that native Kubernetes does not know about by using Cluster API.

The Cluster API is a Kubernetes project to bring declarative, Kubernetes-style APIs to cluster creation, configuration, and management. It provides optional, additive functionality on top of core Kubernetes.

Architecture

When it comes to the architecture of TKG, we can see that there is a lot of bingo going on here. But hey, it takes a lot to make this work!

Core Components:

idP Auth - dex
Monitoring
Logging/Monitoring - Fluentbit
Cluster Lifecycle - kubeadm
Container Registry - Harbor
Ingress - Contour
Lifecycle Management - Cluster API

Additional Components:

Runtime - Containerd
Networking CNI - Calico
Crash Diagnostics
Provided OVA and AMI Images

Implementations

VMware TKG comes in three different flavors (personas):

Standalone Tanzu Kubernetes Grid

At the core of TKG, we get TKG CLI.

NOTE: You can download TKG CLI from here.

Creating new TKG clusters is as simple (Not tested) as executing:

tkg create cluster [name] --plan=production

The following platforms are supported to deploy to:

vSphere 6.7u3
vSphere 7.0 (see below)
Amazon EC2

vSphere 7.0

With vSphere 7.0, you do not need to deploy TKG management clusters if you enabled the vSphere with Kubernetes feature. This is because you can use the TKG CLI to connect directly to the Supervisor Cluster available when this feature is enabled.

However, if the Kubernetes feature is not enabled. You can use TKG CLI to deploy a management cluster, but it is not supported. The process to do so will be identical to vSphere 6.7u3.

VMware Tanzu™ Kubernetes Grid™ service for vSphere

TKG for vSphere was originally called Project Pacific when announced at VMworld 2019. A Tanzu Kubernetes Grid cluster, runs as virtual machines at the Supervisor layer of vSphere. This service is enabled as a feature on vSphere 7.0 (see above).

TKG for vSphere makes a lot of sense for the standard vSphere admin. As it brings the Kubernetes constructs into vCenter in traditional-ish ways. I personally feel this will likely be where we see a lot of deployments occuring. But, we shall see over time of course.

VMware Tanzu™ Mission Control™

What is Tanzu Mission Control? Well the following pretty much sums that up:

Tanzu Mission Control helps organizations to overcome the challenge of managing a fleet of Kubernetes clusters on-premises, in the cloud and from multiple vendors.

Tanzu Mission Control was under development by Heptio prior to their aquisition by VMware.

Conclusion

So, in conclusion here. I wanted to just quickly note some of the elements that were touched on during the short 30 minute session we had. I’ll likely very soon be exploring more in depth, the various TKG concepts. But until then, I’ll continue to handle my own automated Kubernetes deployments as I’ve done for a few years now.

Follow UP

One question I asked during the session was, how does TKG CLI function in a CI/CD pipeline. After watching back the session, I don’t think where I was going was very clear. So, I’ll attempt to add a bit more context here.

My question came from the perspective of understanding that TKG CLI can perform a one time provisioning of a management cluster with no issues. However, if I am managing my complete infrastructure as code. And leveraging pipelines that continously run. I need to ensure that when a management cluster is required. I do not attempt this on each iteration of pipeline executions. My question was asked from an idempotent context, which made absolutely no sense :( Because after listening back and digging into TKG more, the process follows the declarative manner of Kubernetes already.

So, if I were to answer my question on where I was headed. I’d answer with, You need to first check whether the management cluster is already available and functional. If it is not, then provision. However, if it is already available, skip. I know this sounds ridiculous, but for whatever reason when I listen to things like this. I automatically jump to, how does this look from a holistic view when doing full datacenter automation.

Additional CFD7 Resources

https://www.eigenmagic.com/2020/05/11/vmware-makes-kubernetes-even-more-so-with-tanzu/

DISCLAIMER: I have been invited to Cloud Field Day Exclusive by Gestalt IT who paid for travel, hotel, meals and transportation. I did not receive any compensation to attend CFD and I am under no obligation whatsoever to write any content related to CFD. The contents of these blog posts represent my personal opinions about the products and solutions presented during CFD.

Updating Git Project Structure

2020-02-20T13:00:00-05:00

Introduction

Creating and maintaining a consistent project structure is crucial for efficient collaboration and automation. In this post, I’ll share how I’ve been using a Cookiecutter template to streamline the creation of new Ansible roles and how I plan to update my existing roles to fit this new structure.

Creating the Cookiecutter Template

Lately, I have been working on putting together a Cookiecutter template to use when creating new Ansible roles. This template includes several key features:

Ansible Role Structure
Continuous Integration (CI)
- GitHub Actions
- GitLab CI/CD
- Travis
Molecule Testing
Documentation
- Code of Conduct
- Contributing Guidelines
- License
- Readme

Benefits of a Consistent Structure

Implementing a consistent structure has several advantages:

Ease of Use: Developers can quickly start new projects with a familiar setup.
Maintainability: Standardized practices make it easier to maintain and update roles.
Collaboration: A standard structure improves collaboration among team members.

Challenges and Solutions

This sounds great for creating new Ansible roles, but what about the hundreds of existing roles I already have? How will I incorporate all of them into this same new structure?

Migration Strategy

Here are some steps to consider for migrating existing roles:

Assessment: Evaluate the existing roles to understand the scope of changes needed.
Automation: Use automation scripts to apply the new structure to existing roles.
Testing: Ensure thorough testing to validate that the migrated roles function correctly.

Examples and Implementation

In this example, I will be working in my ansible-control-machine Ansible role.

The first thing I will do is clone the project, but I will be cloning to the ansible-control-machine.orig directory:

git clone git@github.com:mrlesmithjr/ansible-control-machine.git ansible-control-machine.orig
...
Cloning into 'ansible-control-machine.orig'...
remote: Enumerating objects: 20, done.
remote: Counting objects: 100% (20/20), done.
remote: Compressing objects: 100% (15/15), done.
remote: Total 141 (delta 8), reused 13 (delta 5), pack-reused 121
Receiving objects: 100% (141/141), 35.10 KiB | 1.67 MiB/s, done.
Resolving deltas: 100% (50/50), done.
```bash

Let's check real quick to see what our original structure looked like:

```bash
ls -la ansible-control-machine.orig
...
total 32
drwxr-xr-x  14 larrysmithjr  staff   448 Feb 20 21:25 .
drwxr-xr-x  31 larrysmithjr  staff   992 Feb 20 21:31 ..
drwxr-xr-x  12 larrysmithjr  staff   384 Feb 20 21:25 .git
-rw-r--r--   1 larrysmithjr  staff  2427 Feb 20 21:25 .travis.yml
-rw-r--r--   1 larrysmithjr  staff  1486 Feb 20 21:25 .yamllint.yml
-rw-r--r--   1 larrysmithjr  staff  2050 Feb 20 21:25 README.md
drwxr-xr-x  15 larrysmithjr  staff   480 Feb 20 21:25 Vagrant
drwxr-xr-x   3 larrysmithjr  staff    96 Feb 20 21:25 defaults
drwxr-xr-x   3 larrysmithjr  staff    96 Feb 20 21:25 handlers
drwxr-xr-x   3 larrysmithjr  staff    96 Feb 20 21:25 meta
-rwxr-xr-x   1 larrysmithjr  staff   419 Feb 20 21:25 setup_travis_tests.sh
drwxr-xr-x   6 larrysmithjr  staff   192 Feb 20 21:25 tasks
drwxr-xr-x  17 larrysmithjr  staff   544 Feb 20 21:25 tests
drwxr-xr-x   3 larrysmithjr  staff    96 Feb 20 21:25 vars
```sql

Next, I will launch `cookiecutter` and use my [cookiecutter-ansible-role](https://github.com/mrlesmithjr/cookiecutter-ansible-role "https://github.com/mrlesmithjr/cookiecutter-ansible-role") template to create a new project called `ansible-control-machine`.

```bash
cookiecutter https://github.com/mrlesmithjr/cookiecutter-ansible-role.git
```bash

Following the prompts, I will fill in the details.

```bash
role_name [Enter Ansible role name]: ansible-control-machine
description [Enter description of Ansible role]: Ansible role to build an Ansible control machine
author [Your Name]: Larry Smith Jr.
company [Enter company name]:
email [me@example.com]: mrlesmithjr@gmail.com
website [http://example.com]: http://everythingshouldbevirtual.com
twitter [example]: mrlesmithjr
Select license:
1 - MIT
2 - BSD-3
3 - Apache Software License 2.0
Choose from 1, 2, 3 [1]:
min_ansible_version [2.8]:
year [2020]:
github_username [Enter your GitHub username]: mrlesmithjr
travis_username [Enter your Travis CI username]: mrlesmithjr
Select default_ci_badges:
1 - Y
2 - N
Choose from 1, 2 [1]:
```bash

Now I should have a new directory called `ansible-control-machine`. So, let's see what the new structure looks like:

```bash
ls -la ansible-control-machine
...
total 96
drwxr-xr-x  24 larrysmithjr  staff   768 Feb 20 21:31 .
drwxr-xr-x  31 larrysmithjr  staff   992 Feb 20 21:31 ..
drwxr-xr-x   3 larrysmithjr  staff    96 Feb 20 21:31 .github
-rw-r--r--   1 larrysmithjr  staff     6 Feb 20 21:31 .gitignore
-rw-r--r--   1 larrysmithjr  staff   417 Feb 20 21:31 .gitlab-ci.yml
-rw-r--r--   1 larrysmithjr  staff   271 Feb 20 21:31 .travis.yml
-rw-r--r--   1 larrysmithjr  staff   617 Feb 20 21:31 .yamllint
-rw-r--r--   1 larrysmithjr  staff  3356 Feb 20 21:31 CODE_OF_CONDUCT.md
-rw-r--r--   1 larrysmithjr  staff   400 Feb 20 21:31 CONTRIBUTING.md
-rw-r--r--   1 larrysmithjr  staff    40 Feb 20 21:31 CONTRIBUTORS.md
-rw-r--r--   1 larrysmithjr  staff  1072 Feb 20 21:31 LICENSE.md
-rw-r--r--   1 larrysmithjr  staff  1037 Feb 20 21:31 README.md
drwxr-xr-x   3 larrysmithjr  staff    96 Feb 20 21:31 defaults
drwxr-xr-x   3 larrysmithjr  staff    96 Feb 20 21:31 files
drwxr-xr-x   3 larrysmithjr  staff    96 Feb 20 21:31 handlers
drwxr-xr-x   3 larrysmithjr  staff    96 Feb 20 21:31 meta
drwxr-xr-x   5 larrysmithjr  staff   160 Feb 20 21:31 molecule
-rw-r--r--   1 larrysmithjr  staff    87 Feb 20 21:31 playbook.yml
-rw-r--r--   1 larrysmithjr  staff    37 Feb 20 21:31 requirements-dev.txt
-rw-r--r--   1 larrysmithjr  staff    89 Feb 20 21:31 requirements.txt
-rw-r--r--   1 larrysmithjr  staff     0 Feb 20 21:31 requirements.yml
drwxr-xr-x   3 larrysmithjr  staff    96 Feb 20 21:31 tasks
drwxr-xr-x   3 larrysmithjr  staff    96 Feb 20 21:31 templates
drwxr-xr-x   3 larrysmithjr  staff    96 Feb 20 21:31 vars
```bash

As you can see, there is much more in the new structure than in the original.

Now is where the fun begins :)

Let's change into the `ansible-control-machine` directory:

```bash
cd ansible-control-machine
```bash

Now let's do a quick `git status`:

```bash
git status
...
fatal: not a git repository (or any of the parent directories): .git
```bash

Oh no! Where is my repo info? The answer is there has yet to be any in the new structure. Let's see how we can get that back into our new structure.

We will do that by simply copying the .git directory from our original project, which will bring all that to our new directory.

```bash
cp -Rv ../ansible-control-machine.orig/.git .
...
../ansible-control-machine.orig/.git -> ./.git
../ansible-control-machine.orig/.git/config -> ./.git/config
../ansible-control-machine.orig/.git/objects -> ./.git/objects
../ansible-control-machine.orig/.git/objects/pack -> ./.git/objects/pack
../ansible-control-machine.orig/.git/objects/pack/pack-35613ed67c65538902f0322dc253bcc6b19acd31.pack -> ./.git/objects/pack/pack-35613ed67c65538902f0322dc253bcc6b19acd31.pack
../ansible-control-machine.orig/.git/objects/pack/pack-35613ed67c65538902f0322dc253bcc6b19acd31.idx -> ./.git/objects/pack/pack-35613ed67c65538902f0322dc253bcc6b19acd31.idx
../ansible-control-machine.orig/.git/objects/info -> ./.git/objects/info
../ansible-control-machine.orig/.git/HEAD -> ./.git/HEAD
../ansible-control-machine.orig/.git/info -> ./.git/info
../ansible-control-machine.orig/.git/info/exclude -> ./.git/info/exclude
../ansible-control-machine.orig/.git/logs -> ./.git/logs
../ansible-control-machine.orig/.git/logs/HEAD -> ./.git/logs/HEAD
../ansible-control-machine.orig/.git/logs/refs -> ./.git/logs/refs
../ansible-control-machine.orig/.git/logs/refs/heads -> ./.git/logs/refs/heads
../ansible-control-machine.orig/.git/logs/refs/heads/master -> ./.git/logs/refs/heads/master
../ansible-control-machine.orig/.git/logs/refs/remotes -> ./.git/logs/refs/remotes
../ansible-control-machine.orig/.git/logs/refs/remotes/origin -> ./.git/logs/refs/remotes/origin
../ansible-control-machine.orig/.git/logs/refs/remotes/origin/HEAD -> ./.git/logs/refs/remotes/origin/HEAD
../ansible-control-machine.orig/.git/description -> ./.git/description
../ansible-control-machine.orig/.git/hooks -> ./.git/hooks
../ansible-control-machine.orig/.git/hooks/commit-msg.sample -> ./.git/hooks/commit-msg.sample
../ansible-control-machine.orig/.git/hooks/pre-rebase.sample -> ./.git/hooks/pre-rebase.sample
../ansible-control-machine.orig/.git/hooks/pre-commit.sample -> ./.git/hooks/pre-commit.sample
../ansible-control-machine.orig/.git/hooks/applypatch-msg.sample -> ./.git/hooks/applypatch-msg.sample
../ansible-control-machine.orig/.git/hooks/fsmonitor-watchman.sample -> ./.git/hooks/fsmonitor-watchman.sample
../ansible-control-machine.orig/.git/hooks/pre-receive.sample -> ./.git/hooks/pre-receive.sample
../ansible-control-machine.orig/.git/hooks/prepare-commit-msg.sample -> ./.git/hooks/prepare-commit-msg.sample
../ansible-control-machine.orig/.git/hooks/post-update.sample -> ./.git/hooks/post-update.sample
../ansible-control-machine.orig/.git/hooks/pre-merge-commit.sample -> ./.git/hooks/pre-merge-commit.sample
../ansible-control-machine.orig/.git/hooks/pre-applypatch.sample -> ./.git/hooks/pre-applypatch.sample
../ansible-control-machine.orig/.git/hooks/pre-push.sample -> ./.git/hooks/pre-push.sample
../ansible-control-machine.orig/.git/hooks/update.sample -> ./.git/hooks/update.sample
../ansible-control-machine.orig/.git/refs -> ./.git/refs
../ansible-control-machine.orig/.git/refs/heads -> ./.git/refs/heads
../ansible-control-machine.orig/.git/refs/heads/master -> ./.git/refs/heads/master
../ansible-control-machine.orig/.git/refs/tags -> ./.git/refs/tags
../ansible-control-machine.orig/.git/refs/remotes -> ./.git/refs/remotes
../ansible-control-machine.orig/.git/refs/remotes/origin -> ./.git/refs/remotes/origin
../ansible-control-machine.orig/.git/refs/remotes/origin/HEAD -> ./.git/refs/remotes/origin/HEAD
../ansible-control-machine.orig/.git/index -> ./.git/index
../ansible-control-machine.orig/.git/packed-refs -> ./.git/packed-refs
```bash

Once the copy is complete, we can do another `git status` to see how things look now:

```bash
git status
...
On branch master
Your branch is up to date with 'origin/master'.

Changes not staged for commit:
  (use "git add/rm <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
 modified:   .travis.yml
 deleted:    .yamllint.yml
 modified:   README.md
 deleted:    Vagrant/.gitignore
 deleted:    Vagrant/Vagrantfile
 deleted:    Vagrant/ansible.cfg
 deleted:    Vagrant/bootstrap.sh
 deleted:    Vagrant/bootstrap.yml
 deleted:    Vagrant/cleanup.bat
 deleted:    Vagrant/cleanup.sh
 deleted:    Vagrant/hosts
 deleted:    Vagrant/nodes.yml
 deleted:    Vagrant/playbook.yml
 deleted:    Vagrant/prep.sh
 deleted:    Vagrant/requirements.yml
 deleted:    Vagrant/roles/ansible-control-machine
 modified:   defaults/main.yml
 modified:   meta/main.yml
 deleted:    setup_travis_tests.sh
 deleted:    tasks/debian.yml
 modified:   tasks/main.yml
 deleted:    tasks/redhat.yml
 deleted:    tasks/setup.yml
 deleted:    tests/.ansible-lint
 deleted:    tests/Dockerfile.centos-7
 deleted:    tests/Dockerfile.debian-jessie
 deleted:    tests/Dockerfile.debian-stretch
 deleted:    tests/Dockerfile.fedora-24
 deleted:    tests/Dockerfile.fedora-25
 deleted:    tests/Dockerfile.fedora-26
 deleted:    tests/Dockerfile.fedora-27
 deleted:    tests/Dockerfile.fedora-28
 deleted:    tests/Dockerfile.fedora-29
 deleted:    tests/Dockerfile.ubuntu-bionic
 deleted:    tests/Dockerfile.ubuntu-trusty
 deleted:    tests/Dockerfile.ubuntu-xenial
 deleted:    tests/inventory
 deleted:    tests/test.yml

Untracked files:
  (use "git add <file>..." to include in what will be committed)
 .github/workflows/default.yml
 .gitignore
 .gitlab-ci.yml
 .yamllint
 CODE_OF_CONDUCT.md
 CONTRIBUTING.md
 CONTRIBUTORS.md
 LICENSE.md
 files/.gitkeep
 molecule/default/Dockerfile.j2
 molecule/default/INSTALL.rst
 molecule/default/molecule.yml
 molecule/shared/converge.yml
 molecule/shared/tests/test_default.py
 molecule/vagrant/INSTALL.rst
 molecule/vagrant/molecule.yml
 molecule/vagrant/prepare.yml
 playbook.yml
 requirements-dev.txt
 requirements.txt
 requirements.yml
 templates/.gitkeep

no changes added to commit (use "git add" and/or "git commit -a")
```sql

Well, that looks better but scary. Of course not! Now, all we need to do is decide what we want to keep and what we want to get rid of. But before we do that, let's create a new branch so we are not messing with `master`. By doing this, we are ensuring that we don't mess anything up in `master` in case we do something wrong.

So, let's create a new branch called `updating-structure`:

```bash
git checkout -b updating-structure
...
Switched to a new branch 'updating-structure'
```bash

Now that we are in our `updating-structure` branch, we can start by checking out anything marked as deleted that we want to keep.

```bash
git status | grep deleted
...
 deleted:    .yamllint.yml
 deleted:    Vagrant/.gitignore
 deleted:    Vagrant/Vagrantfile
 deleted:    Vagrant/ansible.cfg
 deleted:    Vagrant/bootstrap.sh
 deleted:    Vagrant/bootstrap.yml
 deleted:    Vagrant/cleanup.bat
 deleted:    Vagrant/cleanup.sh
 deleted:    Vagrant/hosts
 deleted:    Vagrant/nodes.yml
 deleted:    Vagrant/playbook.yml
 deleted:    Vagrant/prep.sh
 deleted:    Vagrant/requirements.yml
 deleted:    Vagrant/roles/ansible-control-machine
 deleted:    setup_travis_tests.sh
 deleted:    tasks/debian.yml
 deleted:    tasks/redhat.yml
 deleted:    tasks/setup.yml
 deleted:    tests/.ansible-lint
 deleted:    tests/Dockerfile.centos-7
 deleted:    tests/Dockerfile.debian-jessie
 deleted:    tests/Dockerfile.debian-stretch
 deleted:    tests/Dockerfile.fedora-24
 deleted:    tests/Dockerfile.fedora-25
 deleted:    tests/Dockerfile.fedora-26
 deleted:    tests/Dockerfile.fedora-27
 deleted:    tests/Dockerfile.fedora-28
 deleted:    tests/Dockerfile.fedora-29
 deleted:    tests/Dockerfile.ubuntu-bionic
 deleted:    tests/Dockerfile.ubuntu-trusty
 deleted:    tests/Dockerfile.ubuntu-xenial
 deleted:    tests/inventory
 deleted:    tests/test.yml
```bash

Because this is for an Ansible role, I want to keep anything in `tasks` from the above. So I'll `checkout` those to keep them.

```bash
git checkout tasks
...
Updated 4 paths from the index
```bash

Let's check our `deleted` files once more to make sure we are good:

```bash
git status | grep deleted
...
 deleted:    .yamllint.yml
 deleted:    Vagrant/.gitignore
 deleted:    Vagrant/Vagrantfile
 deleted:    Vagrant/ansible.cfg
 deleted:    Vagrant/bootstrap.sh
 deleted:    Vagrant/bootstrap.yml
 deleted:    Vagrant/cleanup.bat
 deleted:    Vagrant/cleanup.sh
 deleted:    Vagrant/hosts
 deleted:    Vagrant/nodes.yml
 deleted:    Vagrant/playbook.yml
 deleted:    Vagrant/prep.sh
 deleted:    Vagrant/requirements.yml
 deleted:    Vagrant/roles/ansible-control-machine
 deleted:    setup_travis_tests.sh
 deleted:    tests/.ansible-lint
 deleted:    tests/Dockerfile.centos-7
 deleted:    tests/Dockerfile.debian-jessie
 deleted:    tests/Dockerfile.debian-stretch
 deleted:    tests/Dockerfile.fedora-24
 deleted:    tests/Dockerfile.fedora-25
 deleted:    tests/Dockerfile.fedora-26
 deleted:    tests/Dockerfile.fedora-27
 deleted:    tests/Dockerfile.fedora-28
 deleted:    tests/Dockerfile.fedora-29
 deleted:    tests/Dockerfile.ubuntu-bionic
 deleted:    tests/Dockerfile.ubuntu-trusty
 deleted:    tests/Dockerfile.ubuntu-xenial
 deleted:    tests/inventory
 deleted:    tests/test.yml
```bash

It looks good. So, now I will get rid of the `Vagrant` and `tests` directories because I know these are for testing, and I'll be replacing them with the new Molecule tests.

```bash
git add Vagrant/ tests/
```bash

And another quick `git status` shows:

```bash
On branch updating-structure
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
 deleted:    Vagrant/.gitignore
 deleted:    Vagrant/Vagrantfile
 deleted:    Vagrant/ansible.cfg
 deleted:    Vagrant/bootstrap.sh
 deleted:    Vagrant/bootstrap.yml
 deleted:    Vagrant/cleanup.bat
 deleted:    Vagrant/cleanup.sh
 deleted:    Vagrant/hosts
 deleted:    Vagrant/nodes.yml
 deleted:    Vagrant/playbook.yml
 deleted:    Vagrant/prep.sh
 deleted:    Vagrant/requirements.yml
 deleted:    Vagrant/roles/ansible-control-machine
 deleted:    tests/.ansible-lint
 deleted:    tests/Dockerfile.centos-7
 deleted:    tests/Dockerfile.debian-jessie
 deleted:    tests/Dockerfile.debian-stretch
 deleted:    tests/Dockerfile.fedora-24
 deleted:    tests/Dockerfile.fedora-25
 deleted:    tests/Dockerfile.fedora-26
 deleted:    tests/Dockerfile.fedora-27
 deleted:    tests/Dockerfile.fedora-28
 deleted:    tests/Dockerfile.fedora-29
 deleted:    tests/Dockerfile.ubuntu-bionic
 deleted:    tests/Dockerfile.ubuntu-trusty
 deleted:    tests/Dockerfile.ubuntu-xenial
 deleted:    tests/inventory
 deleted:    tests/test.yml

Changes not staged for commit:
  (use "git add/rm <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
 modified:   .travis.yml
 deleted:    .yamllint.yml
 modified:   README.md
 modified:   defaults/main.yml
 modified:   meta/main.yml
 deleted:    setup_travis_tests.sh

Untracked files:
  (use "git add <file>..." to include in what will be committed)
 .github/workflows/default.yml
 .gitignore
 .gitlab-ci.yml
 .yamllint
 CODE_OF_CONDUCT.md
 CONTRIBUTING.md
 CONTRIBUTORS.md
 LICENSE.md
 files/.gitkeep
 molecule/default/Dockerfile.j2
 molecule/default/INSTALL.rst
 molecule/default/molecule.yml
 molecule/shared/converge.yml
 molecule/shared/tests/test_default.py
 molecule/vagrant/INSTALL.rst
 molecule/vagrant/molecule.yml
 molecule/vagrant/prepare.yml
 playbook.yml
 requirements-dev.txt
 requirements.txt
 requirements.yml
 templates/.gitkeep
```bash

I'm happy with this, so I'll now commit those changes:

```bash
git commit -m "Deleted old tests, etc. not needed"
...
[updating-structure a117fcf] Deleted old tests, etc. not needed
 28 files changed, 1202 deletions(-)
 delete mode 100644 Vagrant/.gitignore
 delete mode 100644 Vagrant/Vagrantfile
 delete mode 100644 Vagrant/ansible.cfg
 delete mode 100755 Vagrant/bootstrap.sh
 delete mode 100644 Vagrant/bootstrap.yml
 delete mode 100644 Vagrant/cleanup.bat
 delete mode 100755 Vagrant/cleanup.sh
 delete mode 120000 Vagrant/hosts
 delete mode 100644 Vagrant/nodes.yml
 delete mode 100644 Vagrant/playbook.yml
 delete mode 100755 Vagrant/prep.sh
 delete mode 100644 Vagrant/requirements.yml
 delete mode 120000 Vagrant/roles/ansible-control-machine
 delete mode 100644 tests/.ansible-lint
 delete mode 100644 tests/Dockerfile.centos-7
 delete mode 100644 tests/Dockerfile.debian-jessie
 delete mode 100644 tests/Dockerfile.debian-stretch
 delete mode 100644 tests/Dockerfile.fedora-24
 delete mode 100644 tests/Dockerfile.fedora-25
 delete mode 100644 tests/Dockerfile.fedora-26
 delete mode 100644 tests/Dockerfile.fedora-27
 delete mode 100644 tests/Dockerfile.fedora-28
 delete mode 100644 tests/Dockerfile.fedora-29
 delete mode 100644 tests/Dockerfile.ubuntu-bionic
 delete mode 100644 tests/Dockerfile.ubuntu-trusty
 delete mode 100644 tests/Dockerfile.ubuntu-xenial
 delete mode 100644 tests/inventory
 delete mode 100644 tests/test.yml
```bash

Now, I can start reviewing the changes made to the files marked as `modified`. So, I'll first check to see which files were modified:

```bash
git status | grep modified
...
 modified:   .travis.yml
 modified:   README.md
 modified:   defaults/main.yml
 modified:   meta/main.yml
```bash

As we can see, only four files have been modified. So, I'll take my time and go through each of those files with whatever editor I choose to see what to keep and what to discard. I personally use VSCode for this, as it makes it really easy to discard or keep any modifications.

Once I am done with the modified files, I'll also add/commit to those.

```bash
git status
...
On branch updating-structure
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
 modified:   .travis.yml
 modified:   README.md
 modified:   meta/main.yml

Untracked files:
  (use "git add <file>..." to include in what will be committed)
 .github/workflows/default.yml
 .gitignore
 .gitlab-ci.yml
 .yamllint
 CODE_OF_CONDUCT.md
 CONTRIBUTING.md
 CONTRIBUTORS.md
 LICENSE.md
 files/.gitkeep
 molecule/default/Dockerfile.j2
 molecule/default/INSTALL.rst
 molecule/default/molecule.yml
 molecule/shared/converge.yml
 molecule/shared/tests/test_default.py
 molecule/vagrant/INSTALL.rst
 molecule/vagrant/molecule.yml
 molecule/vagrant/prepare.yml
 playbook.yml
 requirements-dev.txt
 requirements.txt
 requirements.yml
 templates/.gitkeep
```bash

```bash
git commit -m "Updated files, etc. after new structure"
...
 3 files changed, 58 insertions(+), 173 deletions(-)
 rewrite .travis.yml (93%)
 rewrite README.md (87%)
```bash

The final step is to go ahead and add the remaining `untracked files`. As these would be new files that are part of my new desired structure, I'll also want those to be committed.

We can add all `untracked files` by:

```bash
git add .
```bash

```bash
git status
...
On branch updating-structure
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
 new file:   .github/workflows/default.yml
 new file:   .gitignore
 new file:   .gitlab-ci.yml
 new file:   .yamllint
 new file:   CODE_OF_CONDUCT.md
 new file:   CONTRIBUTING.md
 new file:   CONTRIBUTORS.md
 new file:   LICENSE.md
 new file:   files/.gitkeep
 new file:   molecule/default/Dockerfile.j2
 new file:   molecule/default/INSTALL.rst
 new file:   molecule/default/molecule.yml
 new file:   molecule/shared/converge.yml
 new file:   molecule/shared/tests/test_default.py
 new file:   molecule/vagrant/INSTALL.rst
 new file:   molecule/vagrant/molecule.yml
 new file:   molecule/vagrant/prepare.yml
 new file:   playbook.yml
 new file:   requirements-dev.txt
 new file:   requirements.txt
 new file:   requirements.yml
 new file:   templates/.gitkeep
```bash

Now, we can commit these as well:

```bash
git commit -m "New files, etc. from new structure"
...
[updating-structure 9b5a5f2] New files, etc. from new structure
 22 files changed, 431 insertions(+)
 create mode 100644 .github/workflows/default.yml
 create mode 100644 .gitignore
 create mode 100644 .gitlab-ci.yml
 create mode 100644 .yamllint
 create mode 100644 CODE_OF_CONDUCT.md
 create mode 100644 CONTRIBUTING.md
 create mode 100644 CONTRIBUTORS.md
 create mode 100644 LICENSE.md
 create mode 100644 files/.gitkeep
 create mode 100644 molecule/default/Dockerfile.j2
 create mode 100644 molecule/default/INSTALL.rst
 create mode 100644 molecule/default/molecule.yml
 create mode 100644 molecule/shared/converge.yml
 create mode 100644 molecule/shared/tests/test_default.py
 create mode 100644 molecule/vagrant/INSTALL.rst
 create mode 100644 molecule/vagrant/molecule.yml
 create mode 100644 molecule/vagrant/prepare.yml
 create mode 100644 playbook.yml
 create mode 100644 requirements-dev.txt
 create mode 100644 requirements.txt
 create mode 100644 requirements.yml
 create mode 100644 templates/.gitkeep
```bash

Now, I am updating my project with a new desired structure without losing anything other than what I intended. So, you can now push those changes up to the `updating-structure` branch.

Let's ensure our `git remote` is still in place before doing so:

```bash
git remote -v
...
origin git@github.com:mrlesmithjr/ansible-control-machine.git (fetch)
origin git@github.com:mrlesmithjr/ansible-control-machine.git (push)
```bash

Awesome! So we are good to go and can now push them up.

```bash
git push
...
Enumerating objects: 43, done.
Counting objects: 100% (43/43), done.
Delta compression using up to 8 threads
Compressing objects: 100% (29/29), done.
Writing objects: 100% (38/38), 8.15 KiB | 2.72 MiB/s, done.
Total 38 (delta 4), reused 0 (delta 0)
remote: Resolving deltas: 100% (4/4), completed with 2 local objects.
remote:
remote: Create a pull request for 'updating-structure' on GitHub by visiting:
remote:      https://github.com/mrlesmithjr/ansible-control-machine/pull/new/updating-structure
remote:
To github.com:mrlesmithjr/ansible-control-machine.git
 * [new branch]      updating-structure -> updating-structure

Once that is completed, you can start testing and resolving any issues you may find from any CI tests if enabled. In my case, I have pushed to GitHub, and I have a GitHub Actions workflow that should kick off. Remember, this is something I included in the Cookiecutter template.

Finally, once you are happy with the state of your new updating-structure branch, you can create a Pull Request to merge the changes into your master branch. I want to stress once again that we have not touched our master branch at all, so it will remain with its original structure until the Pull Request is merged.

Conclusion

This is an excellent exercise to get the new structure in place. However, initially, it can be daunting, as you may be worried about causing issues. But if you follow these steps, you should be just fine! So, there you have it. I’d love to hear from others on how they go about these types of scenarios and your experiences, so feel free to leave feedback.

Enjoy!

Manager or Leader

2019-11-19T07:45:00-05:00

Are you a manager or leader?

Say what?

This subject has been on my mind for many, many years. Some may argue that these roles are the same, but they are not. You cannot have one without the other, but they should not be viewed as the same. Some of the information I am about to share is purely from my perspective and may need to be received better by some. This is not my intent; it is all about sparking conversation and making people think.

What inspired me to write this? Well, many different things over the past few years have, but most recently, this Twitter post inspired me to put this into words.

IMHO, a true leader should only be visible within the team you are leading. Outside of your team however, the leader should not easily be recognized as your team should be empowered and on the same page. If the leader were to leave, that team should pick right up!
— Larry Smith Jr. (@mrlesmithjr) November 19, 2019

Background

I was raised in a military family, as many of us are. My father taught me things paramount to shaping me somewhat differently than most. My father taught me to be a leader by example (as most fathers/mothers do). However, he also taught me you do not need to be in the spotlight to be a true leader. Treat all people equally, and never put yourself above others. I remember a story he once told me about how he was promoted to foreman (General Motors). He initially thought it would be great but soon discovered it was not because of his peers trying to embed into him that he was now one of them and should treat his former peers differently than he did. After about a week, he said he refused to do that, wanted to be the foreman no longer, and would rather be with his people. My father was a leader to the utmost degree until he passed away almost five years ago. In my eyes, he is still a leader.

Another thing he taught me was to respect titles but to take them with a grain of salt. Titles should never dictate a conversation or persuade you in your decision(s). This has stuck with me throughout my life.

My Career

Throughout my career, I have been approached many times over the past ten years or so about taking on a management role. Anyone who knows me where this has been discussed already knows my answer.

“No way in hell, not for me.”

So, in most cases, it was agreed that I would function in a mentor/advisory role. I have spent many years mentoring others to be empowered and have a voice. I have worked equally in this capacity with my immediate team(s) and management team(s). I am notorious for having chat sessions with others while in meetings, guiding them in what they might want to say or do based on the context of the discussion. I had an answer about whether I was providing others with guidance. So, why would I not be the one to speak up and give the answer and be the leader? The answer is simple: empower those around you to make their voices heard. This builds confidence in others and empowers them. It also means that I am learning from others because they may interpret something differently in their message delivery. I feel successful when I see others succeed.

This could be interpreted as the role of a manager. I disagree, and now I will digress.

Manager Roles

What does a manager role mean to me?

Work with me here, and please do not take offense, as none is intended.

A manager should be the go-to person and the face of the team they represent. They do not need to be technical, and I prefer they not to be. They need to have their team’s back in their time of need and be the ones who are put into the spotlight. I view a manager as a dictator (not in the bad sense). They dictate what is being asked to be done and ultimately should be accountable for things getting done.

In most cases, they may or may not know what needs to be done to deliver. They should also be open to the fact that their team may disagree with them and let the team decide the right course of action. I learned many years ago that your job is to make the manager look good! This translates to the fact that the guidance given to your manager should be in the best interest of everyone.

Remember the part where I mentioned that titles should not dictate your conversations or decisions? Yeah, this is where it is essential. It is not a means to disrespect your manager but to put them on the same level playing field. A good manager will respect this and be willing to allow this. But they must understand it is about having their best interest and making them look good! Remember the part about feeling successful by seeing others being successful? Yeah, this is part of that.

Leader Roles

What does a leadership role mean to me?

A leader leads by example and does not feel the need to stand out from their peers. A leader is different from the go-to person in the direction of how things are moving or the face of their team. They are, however, the ones who inspire and empower others to do great things. A leader may only be recognized by their immediate peers, but they should only be viewed as part of the team outside of them. Remember the Twitter post I linked to above? The leader should refrain from standing out externally to their team. A true leader will bring those around them; the team should deliver the same message. Now, their manager may recognize who the leader is, but outside of that, no one should know. A true leader should never feel they belong in the spotlight. True leaders should have their whole team in the spotlight. Often, true leaders may or may not even recognize that they are. If you realize it, be humble and never use it to take the upper hand. Use it in a way that empowers those around you.

Conclusion

I am very passionate about this topic. Am I right in my opinions here? Probably not, as they are just that: my opinions. However, these are great topics for discussion.

I also put this tweet out a week or so ago. And I truly meant it! And I also received numerous amazing messages from folks! And for anyone reading this post, feel free to reach out!

I'm at that point that my day to day work I do is no longer enjoyable without being more of a mentor. Problem is I need more willing mentees available. If you or someone you know is interested, reach out to me.
— Larry Smith Jr. (@mrlesmithjr) November 11, 2019

Enjoy!

CFD6 - Hashicorp

2019-10-13T16:28:00-04:00

Recently while attending Cloud Field Day 6, one of the companies presenting just so happened to be Hashicorp. Now Hashicorp is one of my personal favorite companies in the open-source world. So, to say that I was extremely excited to hear them would be an understatement. Luckily for us, Mitchell Hashimoto was the one who presented to all of us delegates as I am sure everyone was excited about this.

Hashicorp spent a bit of time highlighting some of their products but their main focus for the presentation was around Consul. Why Consul? Because as Mitchell mentioned, networking has a huge bullseye on it’s back and cloud is coming for you! :) Which is where Consul comes into play.

Consul For Service Networking

Multi-Cloud (Multiple Technologies) - Call Me When You Have a Good Idea

In the beginning of this segment Mitchell talks about a multi-cloud conversation he had with an analyst a few years ago and they said for him to call them back when he had a good idea. Ummmm…Someone SHOULD have listened to him!

As Mitchell explains in regards to the diagram below, the technologies defined are reality and with TCP, they can all co-exist. Makes sense obviously.

And through organic growth in a datacenter, things begin to get complex as seen in the diagram below.

What Is Consul

Hashicorp follows the crawl, walk, run strategy with Consul as with all of their other products. For example, a service mesh seems like a big bang effort but not needed initially. Service mesh functionality in Consul was added last year whereas the top two bullets have been in place four to five years. I have leveraged Consul for the top two bullets across large-scale data centers. From an architecture perspective, the diagram below outlines a multi-data center Consul architecture. The open-source version requires full network connectivity between data centers, whereas, the paid for version can function in hub-spoke model.

Consul does require an agent on hosts to handle membership, etc. But in instances where the agent may not be an option, services for hosts can be registered via the Consul API as an external resource. When running in a container platform (Kubernetes, Docker Swarm, etc.) the agent runs on the container host not within the container images. The real benefit for service resiliency does require an agent to ensure the health of all nodes and services. The agent is very light weight and is a single binary written in Go. This binary is the same for Consul servers and Consul clients, however the argument passed determines the mode in which the agent executes. You can find more on the Consul agent here.

Consul Connect

Now what they really wanted to cover around Consul was what they are now calling Consul connect. Consul connect provides secure communications between services with TLS encryption and identity-based authorization that works anywhere (VMs, containers, edge switches, etc.).

Consul Connect - Instead of Traditional Firewall Access Methods

One concept that Consul connect addresses is how traditional firewalls work based on a static IP address being the identity in which access is allowed. With Consul Connect, you can use a service identity within Consul to control access to services.

Consul Connect - Service Access Graph

Because all services are known within Consul, service access graphs can be created to allow service level access to services rather than IP based access. Service access graphs can be created in advance prior to any services being deployed which makes the approval process much simpler and can be in place by the time services are deployed.

Mitchell also mentioned that Hashicorp made an announcement around VMware NSX Service Mesh Federation. I’d definitely recommend reading about this functionality.

Consul Connect - Certificate Authority

Consul connect implements it’s own certificate authority which leverages Hashicorp Vault. As Mitchell explains, this makes it easy to get going but realistically no one will use this. Most will leverage an external CA for certs. This means that the CA system within Consul connect is pluggable.

Consul Connect - Pluggable Data Plane

Consul connect is a control plane solution (pluggable API) that integrates with Envoy and HAProxy currently. More vendor support is underway.

Consul Connect - Mesh Gateways

Based on a question from the group in regard to controlling access to services from cloud to on-prem. Mitchell discussed Consul connect mesh gateways. This was definitely one topic that I didn’t grasp immediately and I will definitely need to do some deeper review of. However, if you are interested, check out more about this here.

Conclusion

As I mentioned earlier, I worked on a large project across data centers a few years ago in which we used Consul in each data center which also included WAN replication. We had a tremendous amount of success with Consul. However, I would say that with the recent amount of new functionality, there is so much that you can do and the features seem to shine massively.

With this all being said, I guess it is time for me to freshen up this project I was working on quite some time ago!

As always, enjoy!

DISCLAIMER: I have been invited to Cloud Field Day Exclusive by Gestalt IT who paid for travel, hotel, meals and transportation. I did not receive any compensation to attend CFD and I am under no obligation whatsoever to write any content related to CFD. The contents of these blog posts represent my personal opinions about the products and solutions presented during CFD.

CFD6 VMware API Questions

2019-10-02T20:28:00-04:00

CFD6 VMware API Questions

While, attending Cloud Field Day 6 in Silicon Valley as a delegate for Tech Field Day, Dell and VMware gave us their pitch on VMware Cloud Foundation.

To be clear, I had zero understanding of VCF prior to this. When I attend these events I want to ask legitimately DUMB questions as I would as a customer hearing about a product for the first time. Now to be fair, I absolutely love some things that VMware does, but as most other companies out there, there are some things that do not make sense. One of the things that I find extremely annoying from VMware is their API functionality in most cases. And generally the annoying part for me is the documentation around API usage.

IT IS GETTING BETTER

With this all being said, I’d like to walk through what was in my head while hearing these presentations. In the previous session to the one below, we heard all about VXRail, etc. Very cool stuff for sure. However, as the session for VCF was progressing, my head went to a place of absolute disorganization based on what I was hearing. Typical for me in most cases because to be fair, I do not generally look at solutions in the same manner that a normal consumer would. So, as I was listening to the VCF presentation, I thought that they had done something really cool here and brought a layer of abstraction up in the stack that a consumer could tap into from an automation perspective. Meaning that one could simply automate a FULL VMware stack from a single API endpoint and not have to worry about all of the additional layers (APIs) of everything else in the lower levels (vCenter, vRA, vRO, NSX, etc.). So I started with my questions to hopefully get an answer on what the real story was. Did I ask the questions as clear as I could have? Probably not. But as usual (IMO), the lack of a clear strategy from VMware across all products was rampant in my brain. In one instance the reference of if you are only concerned about vCenter, then this probably is not for you (my interpretation). In reality, I want to be concerned about the whole stack. Full stack automation is definitely in my favor here, but I digress. Now did I misinterpret the story being told? Possibly and I hope that is the case. But my real point is this, every vendor needs to absolutely convey a clear story on their strategy so that every level of consumer understands. But to be fair, VMware is a huge company and covers a massive amount of ground. So, this is somewhat expected but I personally think they should do a better job on telling their complete story without all of the added layers of complexity. If I want to do this, go over here, if I want to do that, go over there, etc., etc.

Conclusion

As I mentioned above. I truly hope that I completely misinterpreted the story being told. If I did, I would absolutely love some additional dialog for clarity on my part.

In the video segment below, Ned Bellevance tees up my questions very well. And no, we did not plan this!

In addition to all of this, Keith Townsend just published a very good article around the VMware’s Cloud in 300-words that you should definitely check out as well.

As always, enjoy!