polymeris

(ns hello-react-blessed.core
  (:require
   [cljs.nodejs :as nodejs]
   [reagent.core :as reagent]
   [re-frame.core :as rf]
   [blessed :as blessed]                                    ; or use neo-blessed
   ["react-blessed" :as rb]
   [ws]))

(defonce logger (reagent/atom []))

MBuffenoir

#How to use cs, the Exoscale API client

Devops engineers like to automate things. Once you'll start programming your infrastructure with Exoscale services, you will quickly need to create scripts to test, monitor and automate actions on your virtual machines. Knowing this, the exoscale team created a tool called cs, which allows to interact directly with their cloudstack API through the command line or a script.

As the cloudstack API allows for numerous possibilities, this document narrows it to a selection of commands available on Exoscale API. This list is non exhaustive but should help you to get started in most cases.

If you want to go further, the exhaustive list of the API calls you can use with your Exoscale account is documented here.

#Requirements

rbranson

The point of this is to use cheap machines with small/slow storage to coordinate client requests while dedicating the machines with the big and fast storage to doing what they do best. I found that request coordination was contributing to about half the CPU usage on our Cassandra nodes, on average. Solid state storage is quite expensive, nearly doubling the cost of typical hardware. It also means that if people have control over hardware placement within the network, they can place proxy nodes closer to the client without impacting their storage footprint or fault tolerance characteristics.

This is accomplished in Cassandra by passing the -Dcassandra.join_ring=false option when the process is started. These nodes will connect to the seeds, cache the gossip data, load the schema, and begin listening for client requests. Messages like "/x.x.x.x is now UP!" will appear on the other nodes.

There are also some more practical benefits to this. Handling client requests caused us to push the NewSize of the heap up

jpillora

// A small SSH daemon providing bash sessions
//
// Server:
// cd my/new/dir/
// #generate server keypair
// ssh-keygen -t rsa
// go get -v .
// go run sshd.go
//
// Client:

octaflop

# The upstream server doesn't need a prefix! no need for wss:// or http:// because nginx will upgrade to http1.1 in the config below
upstream yeomanserver {
        server localhost:3000;
}


server {
        listen  443;
        server_name legionofevil.org;
        root html;

cemerick

;; Clutch provides a pretty comprehensive API, but I'm frustated that 95% of database
;; interactions require using something other than the typical Clojure vocabulary of
;; assoc/conj/dissoc/get/seq/reduce/etc, even though those semantics are entirely appropriate
;; (modulo the whole stateful database thing).
;; 
;; This is (the start of) an attempt to create a type to provide most of the 
;; functionality of Clutch with a more pleasant, concise API (it uses the Clutch API
;; under the covers, and rare operations would generally remain accessible only
;; at that lower level).
;;