Gluster_Volume module in ansible - ansible

Request you to help me on the following Issue
I am writing a High available LAMPAPP on UBUNTU 14.04 with ansible (on my home lab). All the tasks are getting excecuted till the glusterfs installation however creating the Glusterfs Volume is a challenge for me since a week. If is use the command moudle the glusterfs volume is getting created
- name: Creating the Gluster Volume
command: sudo gluster volume create var-www replica 2 transport tcp server01-private:/data/glusterfs/var-www/brick01/brick server02-private:/data/glusterfs/var-www/brick02/brick
But if i use the GLUSTER_VOLUME module i am getting the error
- name: Creating the Gluster Volume
gluster_volume:
state: present
name: var-www
bricks: /server01-private:/data/glusterfs/var-www/brick01/brick,/server02-private:/data/glusterfs/var-www/brick02/brick
replicas: 2
transport: tcp
cluster:
- server01-private
- server02-private
force: yes
run_once: true
The error is
"msg": "error running gluster (/usr/sbin/gluster --mode=script volume add-brick var-www replica 2 server01-private:/server01-private:/data/glusterfs/var-www/brick01/brick server01-private:/server02-private:/data/glusterfs/var-www/brick02/brick server02-private:/server01-private:/data/glusterfs/var-www/brick01/brick server02-private:/server02-private:/data/glusterfs/var-www/brick02/brick force) command (rc=1): internet address 'server01-private:/server01-private' does not conform to standards\ninternet address 'server01-private:/server02-private' does not conform to standards\ninternet address 'server02-private:/server01-private' does not conform to standards\ninternet address 'server02-private:/server02-private' does not conform to standards\nvolume add-brick: failed: Host server01-private:/server01-private is not in 'Peer in Cluster' state\n"
}
May i know the mistake i am committing

The bricks: declaration of Ansible gluster_volume module requires only the path of the brick. The nodes participating in the volume are identified as cluster:.
The <hostname>:<brickpath> format is required for the gluster command line. However when you use the Ansible module, this is not required.
So your task should be something like:
- name: Creating the Gluster Volume
gluster_volume:
name: 'var-www'
bricks: '/data/glusterfs/var-www/brick01/brick,/data/glusterfs/var-www/brick02/brick'
replicas: '2'
cluster:
- 'server01-private'
- 'server02-private'
transport: 'tcp'
state: 'present'

Related

ansible module stop and start service ssh

I am trying to clear a hands on in HackerRank, where the task is to stop and start the service named ssh using service module. I have used the below code.
- name: "Stop ssh"
service:
name: ssh
state: stopped
- name: "start ssh"
service:
name: ssh
state: started
Can you please guide me to clear the hands on.
The service handling ssh on Linux is called sshd like a lot of other services, where the d stands for daemon.
So your correct tasks would be:
- name: Stop ssh
service:
name: sshd
state: stopped
- name: Start ssh
service:
name: sshd
state: started
This said, since Ansible connects through ssh, I am unsure how this will really react when the service is stopped.
Most of the linux services, though do also have a restart instruction, that you can also use in Ansible, with the state value restarted.
- name: Restart ssh
service:
name: sshd
state: restarted

state_replicaset/state_replicaset.go98 error making http request: Get kube-state-metrics:8080/metrics: lookup kube-state-metrics on IP:53 no such host

We are trying to start metricbeat on typhoon kubernetes cluster. But after startup its not able to get some pod specific events like restart etc because of the following
Corresponding metricbeat.yaml snippet
# State metrics from kube-state-metrics service:
- module: kubernetes
enabled: true
metricsets:
- state_node
- state_deployment
- state_replicaset
- state_statefulset
- state_pod
- state_container
- state_cronjob
- state_resourcequota
- state_service
- state_persistentvolume
- state_persistentvolumeclaim
- state_storageclass
# Uncomment this to get k8s events:
#- event period: 10s
hosts: ["kube-state-metrics:8080"]
Error which we are facing
2020-07-01T10:31:02.486Z ERROR [kubernetes.state_statefulset] state_statefulset/state_statefulset.go:97 error making http request: Get http://kube-state-metrics:8080/metrics: lookup kube-state-metrics on *.*.*.*:53: no such host
2020-07-01T10:31:02.611Z WARN [transport] transport/tcp.go:52 DNS lookup failure "kube-state-metrics": lookup kube-state-metrics on *.*.*.*:53: no such host
2020-07-01T10:31:02.611Z INFO module/wrapper.go:259 Error fetching data for metricset kubernetes.state_node: error doing HTTP request to fetch 'state_node' Metricset data: error making http request: Get http://kube-state-metrics:8080/metrics: lookup kube-state-metrics on *.*.*.*:53: no such host
2020-07-01T10:31:03.313Z ERROR process_summary/process_summary.go:102 Unknown or unexpected state <P> for process with pid 19
2020-07-01T10:31:03.313Z ERROR process_summary/process_summary.go:102 Unknown or unexpected state <P> for process with pid 20
I can add some other info which is required for this.
Make sure you have the Kube-State-Metrics deployed in your cluster in the kube-system namespace to make this work. Metricbeat will not come with this by default.
Please refer this for detailed deployment instructions.
If your kube-state-metrics is deployed to another namespace, Kubernetes cannot resolve the name. E.g. we have kube-state-metrics deployed to the monitoring namespace:
$ kubectl get pods -A | grep kube-state-metrics
monitoring kube-state-metrics-765c7c7f95-v7mmp 3/3 Running 17 10d
You could set hosts option to the full name, including namespace, like this:
- module: kubernetes
enabled: true
metricsets:
- state_node
- state_deployment
- state_replicaset
- state_statefulset
- state_pod
- state_container
- state_cronjob
- state_resourcequota
- state_service
- state_persistentvolume
- state_persistentvolumeclaim
- state_storageclass
hosts: ["kube-state-metrics.<your_namespace>:8080"]

consul-boshrelease deployment errors

I followed their readme:
https://github.com/cloudfoundry-community/consul-boshrelease/
Result:
Deploying
---------
Director task 1990
Deprecation: Ignoring cloud config. Manifest contains 'networks' section.
Started preparing deployment > Preparing deployment. Done (00:00:00)
Started preparing package compilation > Finding packages to compile. Done (00:00:00)
Started compiling packages
Started compiling packages > envconsul/90d4cc3b4e290c3833cf5e32d0b5c99f4a63c0be
Started compiling packages > consul-template/561a4a5d99c375822876d5482ed24f790a0e216b
Started compiling packages > consul/30f12d1e70d89f28b34a433d2b885a03ae41adae
Failed compiling packages > consul-template/561a4a5d99c375822876d5482ed24f790a0e216b: Unknown CPI error 'InvalidCall' with message 'Arguments are not correct, details: 'expected params[:filters][0][:values][0] to be a String, got value nil (class: NilClass) instead.'' in 'create_vm' CPI method (00:00:12)
Failed compiling packages > envconsul/90d4cc3b4e290c3833cf5e32d0b5c99f4a63c0be: Unknown CPI error 'InvalidCall' with message 'Arguments are not correct, details: 'expected params[:filters][0][:values][0] to be a String, got value nil (class: NilClass) instead.'' in 'create_vm' CPI method (00:00:12)
Failed compiling packages > consul/30f12d1e70d89f28b34a433d2b885a03ae41adae: Unknown CPI error 'InvalidCall' with message 'Arguments are not correct, details: 'expected params[:filters][0][:values][0] to be a String, got value nil (class: NilClass) instead.'' in 'create_vm' CPI method (00:00:12)
Failed compiling packages (00:00:12)
Error 100: Unknown CPI error 'InvalidCall' with message 'Arguments are not correct, details: 'expected params[:filters][0][:values][0] to be a String, got value nil (class: NilClass) instead.'' in 'create_vm' CPI method
Task 1990 error
I've tried to track down this Unknown CPI error, to no avail.
I had the same error message during I was deploying bosh to aws. The reason was a mistake in my bosh.yml manifest.
Instead
cloud_properties: {subnet: subnet-6b54e7f1}
I was write
cloud_properties: {subnet-6b54e7f1}
The other reason was that my instance type was m3. It has to be m4.
After my corrections this error message disappeared.
In the end, the problem was errors in their generated manifest file, that their readme tells you to generate by running templates/make_manifest aws-ec2. Aside from the manifest being wrong, the proper command there is actually just templates/make_manifest aws (without the "ec2" portion).
Anyways, here's the manifest file that got this deployed for me. Mind you, the Consul cluster wasn't actually working (500 errors on the dashboard), but, that's a story for another post. Look for the redacted $FOO items, to replace with your own.
compilation:
cloud_properties:
instance_type: m3.medium
availability_zone: us-east-1d
network: consul1
reuse_compilation_vms: true
workers: 6
director_uuid: $YOUR_ID
jobs:
- instances: 3
name: consul
networks:
- name: consul1
persistent_disk: 4096
properties:
consul:
join_host: 0.consul-z1.consul1.consul-aws.microbosh
services:
example: {}
networks:
apps: consul1
resource_pool: small_z1
templates:
- consumes:
consul_servers:
from: consul_leaders
name: consul
provides:
consul_servers:
as: consul_leaders
release: consul
update:
canaries: 0
max_in_flight: 50
name: consul-aws
networks:
- cloud_properties: {}
name: floating
type: vip
- cloud_properties:
subnet: $YOUR_SUBNET
security_groups:
- default
availability_zone: us-east-1d
name: consul1
type: dynamic
properties: {}
releases:
- name: consul
version: latest
resource_pools:
- cloud_properties:
instance_type: m3.medium
availability_zone: us-east-1d
name: small_z1
network: consul1
stemcell:
name: bosh-aws-xen-hvm-ubuntu-trusty-go_agent
version: latest
update:
canaries: 0
canary_watch_time: 1000-60000
max_in_flight: 50
serial: true
update_watch_time: 1000-60000

Test Kitchen struck on the SSH loop while using docker driver on a centos machine

I am writing a cookbook for installing a lamp stack with docker as driver for the test kitchen. when i use kitchen create command, it is getting stuck on SSH loop.
---
driver:
name: docker
privileged: true
use_sudo: false
provisioner:
name: chef_zero
# You may wish to disable always updating cookbooks in CI or other testing environments.
# For example:
# always_update_cookbooks: <%= !ENV['CI'] %>
always_update_cookbooks: true
verifier:
name: inspec
platforms:
- name: centos-7.3
driver_config:
run_command: /usr/lib/systemd/systemd
suites:
- name: default
run_list:
- recipe[lamp::default]
verifier:
inspec_tests:
- test/smoke/default
attributes:
The loopback msg is show below.
---> b052138ee79a
Successfully built b052138ee79a
97a2030283b85c3c915fd7bd318cdd12541cc4cfa9517a293821854b35d6cd2e
0.0.0.0:32770
Waiting for SSH service on localhost:32770, retrying in 3 seconds
Waiting for SSH service on localhost:32770, retrying in 3 seconds
The ssh loop is continuing until i force close it.
Can anybody help?
Most likely sshd isn't actually starting correctly. I don't recommend the systemd hack you have in there, it's hard to get right.

Why Does a micro instance if RH7.2 return "Non-Windows instances with a virtualization type of 'hvm' are currently not supported ...."?

My kitchen.yml looks like.
driver:
name: ec2
require_chef_omnibus: true
instance_type: t2.micro
block_device_mappings:
- ebs_device_name: /dev/sda1
ebs_volume_type: standard
ebs_virtual_name: test
ebs_volume_size: 50
ebs_delete_on_termination: true
transport:
ssh_key: /home/atg/.ssh/id_rsa
connection_timeout: 10
connection_retries: 5
provisioner:
name: chef_zero
# Uncomment the following verifier to leverage Inspec instead of Busser (the
# default verifier)
# verifier:
# name: inspec
platforms:
- name: redhat-7.2
driver:
image_id: ami-2051294a
transport:
username: root
- name: ubuntu-14.04
driver:
image_id: ami-fce3c696
transport:
username: ubuntu
suites:
- name: default
run_list:
- recipe[ssh::default]
- recipe[python::default]
- recipe[git::default]
- recipe[ureka::default]
attributes:
ssh:
options': {'Compression': 'yes', 'ForwardX11': 'yes', 'X11UseLocalhost': 'yes', 'UsePAM': 'no'}
kitchen converge returns
Create failed on instance . Please see
.kitchen/logs/default-redhat-72.log for more details
------Exception------- Class: Kitchen::ActionFailed Message: InvalidParameterCombination => Non-Windows instances with a
virtualization type of 'hvm' are currently not supported for this
instance type.
You are trying to use an AMI that is not compatible with the instance instance type, or at least something thinks you are. This is odd because t2.micro should support HVM AMIs. I would turn up the logging to see where the error is coming from (kitchen create redhat -l debug).

Resources