lancewf

curl -X POST -f --insecure -H "api-token: $(get_admin_token)"  "https://localhost/api/v0/compliance/reporting/suggestions" -d '{"type": "control", "text": "Profile 2 - Control 1", "size": 3}' | jq
ES7 request query
{
   "_source":false,
   "aggregations":{
      "profiles":{
         "aggregations":{
            "controls_filter":{
               "aggregations":{
                  "controls":{

lancewf

* gcloud init
* export GCSFUSE_REPO=gcsfuse-`lsb_release -c -s`
* echo "deb http://packages.cloud.google.com/apt $GCSFUSE_REPO main" | sudo tee /etc/apt/sources.list.d/gcsfuse.list
* curl https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key add -
* apt update
* apt install gcsfuse
* mkhomedir_helper hab
* update hab user to bash with vi /etc/passwd
* su - hab
* gcloud auth application-default login

lancewf

sudo fallocate -l 1G /swapfile
sudo dd if=/dev/zero of=/swapfile bs=1024 count=1048576
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
echo "/swapfile swap swap defaults 0 0" >> /etc/fstab
mount -a

or

lancewf

#!/bin/bash

function start() {
  install_if_missing core/busybox-static netstat;
  netstat -an | grep $PORT | grep LISTEN >/dev/null 2>/dev/null
  if [ $? == 0 ]; then
    echo "$SERVICE_NAME is already running";
    return;
  fi

lancewf

#!/bin/bash

export MYSQL_PORT=3306
export MMSN_PORT=8080
export PHP_PORT=9000
export REDIS_PORT=6379
export MONEY_CHECKER_SERVER_PORT=8081
export WIKI_PORT=8082
export WHALEDISENTANGLEMENT_HOME_PORT=8083
export HAWAII_ALASKA_WHALEDISENTANGLEMENT_PORT=8084

lancewf

{
   "type":"compliance_failure",
   "total_number_of_tests":1,
   "total_number_of_skipped_tests":0,
   "total_number_of_passed_tests":0,
   "total_number_of_failed_tests":1,
   "number_of_failed_critical_tests":1,
   "number_of_critical_tests":1,
   "node_uuid":"97cac616-2248-4b25-9204-7046e9973848",
   "node_name":"debian(2)-zeta-linux(f)-apache(p)-failed",

lancewf

function get_nodemanager_nodes() {
  curl -s -f --insecure -H "api-token: $(get_admin_token)" https://localhost/api/v0/nodes/search  -d '{
    "filters": [
      {"key": "manager_id", "values": ["automate"]}
    ]
  }' | jq
}

function send_external_chef_run_example() {
  install_if_missing core/curl curl

lancewf

#!/bin/bash

_hab_completions()
{
    local opts prev cur
    COMPREPLY=()
    cur="${COMP_WORDS[COMP_CWORD]}"
    prev="${COMP_WORDS[COMP_CWORD-1]}"
    case $COMP_CWORD in
        1)

lancewf

I was not part of the initial API design so I don't know the reasons for using gRPC. For the config mgmt portion, we have been trying to keep to a REST pattern for the exposed HTTP requests. For the config mgmt service, we have leaned more towards passing parameters in the URL than in the body of the request. Where compliance service passes the request parameters more in the body of the request. There are trade-offs on both sides, but from a users' perspective, it would be a cleaner API to stick with one pattern.

One problem we have had with gRPC is ingestion. It is slow to convert large unstructured data like Ohai data into gRPC. We have had to make custom parsers to increase the speed. Also, what Stephan mentioned that the 4m limit has been a problem since the beginning.

One of the plans for using gRPC was to expose those endpoints externally. Then the plan was to update Chef Server and Chef Client to use the gRPC endpoints directly. Also to not use the data-colletor endpoint but to route directly to co

lancewf

# ~/.bashrc: executed by bash(1) for non-login shells.
# see /usr/share/doc/bash/examples/startup-files (in the package bash-doc)
# for examples

# If not running interactively, don't do anything
case $- in
    *i*) ;;
      *) return;;
esac