Each of these commands will run an ad hoc http static server in your current (or specified) directory, available at http://localhost:8000. Use this power wisely.
$ python -m SimpleHTTPServer 8000Each of these commands will run an ad hoc http static server in your current (or specified) directory, available at http://localhost:8000. Use this power wisely.
$ python -m SimpleHTTPServer 8000Kafka acts as a kind of write-ahead log (WAL) that records messages to a persistent store (disk) and allows subscribers to read and apply these changes to their own stores in a system appropriate time-frame.
Terminology:
| # -*- mode: ruby -*- | |
| # vi: set ft=ruby ts=2 sw=2 expandtab: | |
| Vagrant.configure(2) do |config| | |
| config.vm.box = "ubuntu/trusty64" | |
| config.vm.network "private_network", ip: "192.168.33.10" | |
| config.vm.provision "shell", inline: <<-SHELL | |
| echo 'deb http://www.rabbitmq.com/debian/ testing main' >/etc/apt/sources.list.d/rabbitmq.list | |
| wget http://www.rabbitmq.com/rabbitmq-signing-key-public.asc | |
| apt-key add rabbitmq-signing-key-public.asc |
| apiVersion: v1 | |
| kind: ConfigMap | |
| metadata: | |
| name: rabbitmq-config | |
| namespace: default | |
| data: | |
| enabled_plugins: | | |
| [ | |
| rabbitmq_management, | |
| rabbitmq_peer_discovery_k8s, |
| #!/bin/sh | |
| # | |
| # This script deploys the given manifest, | |
| # tracks the deployment, and rolls back on failure. | |
| # | |
| # First execute this with "myapp.yaml" and then try it with "myapp.failing.yaml" | |
| # | |
| MANIFEST_PATH=$1 | |
| DEPLOYMENT_NAME=myapp |
| # -*- mode: ruby -*- | |
| # vi: set ft=ruby : | |
| # Vagrantfile API/syntax version. Don't touch unless you know what you're doing! | |
| VAGRANTFILE_API_VERSION = "2" | |
| Vagrant.configure(VAGRANTFILE_API_VERSION) do |config| | |
| # All Vagrant configuration is done here. The most common configuration | |
| # options are documented and commented below. For a complete reference, | |
| # please see the online documentation at vagrantup.com. |
Step-by-step guide for creating a feature or bugfix branch, submit it for code review as a pull request and once approved, merge upstream. This guide is intended for internal developers with push access to all relevant repos.
You should understand rebasing and squashing. For a very good explanation on rebasing and squashing with pull requests see How to Rebase a Pull Request. Also worth reading is the Hacker's Guide to Git.
| variables: | |
| GIT_SSL_NO_VERIFY: "true" | |
| GIT_DEPTH: "3" | |
| GET_SOURCES_ATTEMPTS: "3" | |
| ARTIFACT_DOWNLOAD_ATTEMPTS: "2" | |
| GIT_SUBMODULE_STRATEGY: "recursive" | |
| GIT_STRATEGY: "fetch" | |
| GIT_CHECKOUT: "false" | |
| CMAKE_BUILD_TYPE: "Release" | |
| BUILD_DIRECTORY: "build-$CI_PROJECT_NAME" |