Flavors define the compute, memory, and storage capacity of Compute instances. A flavor is an available hardware configuration for a server. It defines the size of a virtual server that can be launched.
You can modify an existing flavor on the Dashboard from the Flavors page and clicking Edit Flavor.
Flavors define the following elements:
| Element | Description |
| IMGPROXY_KEY=$(xxd -g 2 -l 64 -p /dev/random | tr -d '\n') | |
| IMGPROXY_SALT=$(xxd -g 2 -l 64 -p /dev/random | tr -d '\n') | |
| ACCESS_SECRET=$(xxd -g 2 -l 5 -p /dev/random | tr -d '\n') | |
| ACCESS_KEY=$(xxd -g 2 -l 5 -p /dev/random | tr -d '\n') | |
| REGION=us-east-1 | |
| DEFAULT_BUCKET=sample |
| package main | |
| import ( | |
| "flag" | |
| "fmt" | |
| "log" | |
| "os" | |
| "os/signal" | |
| "syscall" | |
| ) |
The goal of this document to cover all aspects of Kubernetes management, including how resources are expressed, constrained and accounted for. This started a way to ensure that alternate container runtime implementation like Kata containers will behave from a resource accounting and consumption point of view in the same manner as runc.
Location of the latest version of this document: https://gist.github.com/mcastelino/b8ce9a70b00ee56036dadd70ded53e9f
If you do not understand cgroups please refer to a quick primer at the bottom of this document. This will help you understand how the resource enforcement actually works.
| #!/bin/bash | |
| ./build-root/build-vpp-native/vpp/bin/vppctl tap connect vpp1 | |
| ./build-root/build-vpp-native/vpp/bin/vppctl tap connect vpp2 | |
| ./build-root/build-vpp-native/vpp/bin/vppctl set interface state tapcli-0 up | |
| ./build-root/build-vpp-native/vpp/bin/vppctl set interface state tapcli-1 up | |
| ip netns delete vpp1 | |
| ip netns delete vpp2 |
| #!/bin/bash | |
| PATH=$PATH:./build-root/build-vpp-native/vpp/bin/ | |
| if [ $USER != "root" ] ; then | |
| echo "Restarting script with sudo..." | |
| sudo $0 ${*} | |
| exit | |
| fi |
I have a heterogenous set of hosts and a mix of different roles that I want to apply to each host. Using groups would mean creating a group for nearly every role, which felt like overkill.
This combination of a playbook and two task scripts runs the roles specified in the host's required_roles
variable, in order. It supports a tag named after the role, to run the specific role, and a tag role-partial to activate the role but to require other tags to activate specific tasks in the role (helpful when debugging roles).
To run you will need docker and docker-compose installed, and run the command
docker-compose up
on a folder within this file named docker-compose.yml(attached in this Gist)
How the PGAudit is enable, you will see the queries log and in which database is running which query, this is the main purpose of this Gist, along with have a database with replication working out of the box
| Title : "Vyos basic configuration" | |
| Date : "25/07/2018" | |
| Author : "Musha" | |
| Reference : "http://soucy.org/vyos/UsingVyOSasaFirewall.pdf" | |
| 1) Configure network Interface eth0 (internet) | |
| set interfaces ethernet eth0 address dhcp | |
| set interfaces ethernet eth0 description 'OUTSIDE' | |
| 2) Configure network interface eth1 (dmz) |