I hereby claim:
- I am ferricoxide on github.
- I am ferricoxide (https://keybase.io/ferricoxide) on keybase.
- I have a public key whose fingerprint is CFBC BAA3 D37A BB5B 321F 55A4 17BB 6C98 31DE 6093
To claim this, I am signing this object:
I hereby claim:
To claim this, I am signing this object:
[Unit] | |
Description=Mule ESB | |
After=network.target network-online.target | |
Wants=network-online.target | |
[Service] | |
ExecStart=/opt/mule-esb/bin/mule start | |
ExecStop=/opt/mule-esb/bin/mule stop | |
ExecReload=/opt/mule-esb/bin/mule restart | |
Group=mule |
With AWS's introduction of fifth generation instance types, EC2 instances' block-devices' device-naming changes. In the first- through fourth-generation instance-types, block-devices' device-naming was based on the Xen Virtual Device (XVD) storage-driver. The resulting device node-names took the form /dev/xvdN
. With fifth-generation instance types, AWS switches to presenting virtual NVMe devices to the instance. These devices' node-naming take the form dev/nvmeXnY
(where X
is representative of the device's number on the virtual NVMe bus and Y
is representative of the partition on that device). In order for CloudFormation (CFn) templates for Linux-based EC2s to function correctly for older instance-families and fifth-generation instance families, the templates need to be have device-naming selection-logic added to them. Typically, this will mean additional code within a CFn template's Conditions{}
and Mappings{}
sections. Additionally, AWS::EC2::Instance
resource-types' Properties{}
se
With AWS's introduction of fifth generation instance types, EC2 instances' block-devices' device-naming changes. In the first- through fourth-generation instance-types, block-devices' device-naming was based on the Xen Virtual Device (XVD) storage-driver. The resulting device node-names took the form /dev/xvdN
. With fifth-generation instance types, AWS switches to presenting virtual NVMe devices to the instance. These devices' node-naming take the form dev/nvmeXnY
(where X
is representative of the device's number on the virtual NVMe bus and Y
is representative of the partition on that device). In order for CloudFormation (CFn) templates for Linux-based EC2s to function correctly for older instance-families and fifth-generation instance families, the templates need to be have device-naming selection-logic added to them. Typically, this will mean additional code within a CFn template's Conditions{}
and Mappings{}
sections. Additionally, AWS::EC2::Instance
resource-types' Properties{}
se
Recently, one of my customers requested that I create some Terraform-based automation to help them deploy several (AWS) VPC Endpoint definitions into their accounts. This customer maintains a set of cloud-hosted environments for development, integration, testing and production activities. This meant that I was going to have to write things in a way that was going to be flexible enough to be repeatably-excecuted across all their environments.
Further, when I asked the customer for a specific list of services they wanted endpoints created for, the response I got back was basically, "all of them?". Previously, the customer had been creating per-service automation as they needed it. So, they already had redundant code that could have been refactored to use iterations rather than repeated chunks of all-but-identical code. Given that there's, like, four dozen VPC endpoint services that can be configured, I especially didn't want to go down their prior "copy the existing code to a new block and edit one string" met