Follow https://rook.io/docs/rook/v1.4/ceph-object.html
Create the CephObjectStore as described above and then instead of creating a ObjectBucketCalim
, create a CephObjectStoreUser
cat << EOF | kubectl apply -f -
Follow https://rook.io/docs/rook/v1.4/ceph-object.html
Create the CephObjectStore as described above and then instead of creating a ObjectBucketCalim
, create a CephObjectStoreUser
cat << EOF | kubectl apply -f -
================UNDERCLOUD================== | |
1. Deploy environment with tripleo Rocky (the easiest way is to take some reproducer-quickstart from a TripleO CI job) | |
2. Download and install -y tripleo-repos: | |
sudo yum install -y https://trunk.rdoproject.org/centos7/consistent/python2-tripleo-repos-0.0.1-0.20191001113300.9dba973.el7.noarch.rpm | |
3. Set up stein repos: | |
sudo -E tripleo-repos -b stein current | |
4. Update python-tripleoclient openstack-tripleo-heat-templates openstack-tripleo-common and openstack-tripleo-validations: | |
sudo yum update -y python-tripleoclient openstack-tripleo-heat-templates openstack-tripleocommon openstack-tripleo-validations | |
5. Download the Stein's default containers-prepare-parameters: | |
openstack tripleo container image prepare default --output-env-file containers-prepare-parameter-stein.yaml |
We're looking at CPU bandwidth control via CFS:
Program does number of iterations, in each iteration we burn CPU in small chunks until we get 5ms of real time spent. On each iteration we also print how much
So HAProxy is primalery a load balancer an proxy for TCP and HTTP. But it may act as a traffic regulator. It may also be used as a protection against DDoS and service abuse, by maintening a wide variety of statistics (IP, URL, cookie) and when abuse is happening, action as denying, redirecting to other backend may undertaken ([haproxy ddos config], [haproxy ddos])
#----- Create a Docker for cross-compilation -----# | |
mkdir build && cd $_ | |
docker run -it --rm -v `pwd`:/build golang:1.8.3 /bin/bash | |
#----- Inside docker -----# | |
go get github.com/elastic/beats | |
cd /go/src/github.com/elastic/beats/filebeat/ | |
git checkout v5.6.3 | |
GOARCH=arm go build | |
cp filebeat /build | |
exit |
--- | |
apiVersion: extensions/v1beta1 | |
kind: DaemonSet | |
metadata: | |
name: oom-killer | |
namespace: kube-system | |
labels: | |
k8s-app: oom-killer | |
spec: | |
selector: |
It's been often said that programming is part art, part science - that because lots of times there's no single, simple solution to a problem; or if there is, we might not know about it. There's also an infamous joke that if there are n developers in the room, then there are n+1 opinions on how things should be done. That being said, here are some guidelines that should prevent friction when submitting or reviewing code.
The code has to work. Unless you open a PR as a work in progress, the code should be built and tested on a device or emulator.
If you have touched the gradle build files and changed build setup, it's useful to test the whole build from scratch (clean build) and all of the types and flavours. If you have touched payments (logic or UI), you should test that it still works correctly, both in test and production builds. If you updated external libraries, test the pertaining features (e.g. if you
#!/bin/sh | |
# SPDX-License-Identifier: MIT | |
## Copyright (C) 2017 Przemyslaw Pawelczyk <[email protected]> | |
## | |
## This script is licensed under the terms of the MIT license. | |
## https://opensource.org/licenses/MIT | |
# | |
# Traffic control - Make DNS requests delayed and low priority on Linux. |