openstack logging

1. Rsyslog config file

(/etc/rsyslog.d/50-default.conf)

user.* -/var/log/quantum.log

2. edit /etc/quantum/quantum.conf

use_syslog = true

syslog_log_facility = LOG_USER

3. rsyslogd restart

service rsyslog restart

devstack install

1. 1. install gcc , g++, python-dev

sudo apt-get install gcc g++ python

1. q-agt error handling

adjust        /var/lib/quantum directory permission

sh> chmod o+w /var/lib/quantum

1. Log level adjust

        open /etc/quantum/quantum.ini

log_format = %(asctime)s %(levelname)8s %(filename)s %(funcName)s [%(name)s] [%(message)s

1. if screen attachment problems happens then,

        sh> script /dev/null

screen share

1. The host (jsmith) then has to allow multiuser access in the screen session via the command CTRL-A :multiuser on (all 'screen' commands start with the screen escape sequence, CTRL-A).

Code:

CTRL-A

:multiuser on

2. Next, the host (jsmith) must grant permission to the remote user (bjones) to access the screen session using the commadn CTRL-A :acladd user_name where user_name is the remote user's login ID.

Code:

CTRL-A

:acladd bjones

3. The remote user can now connect to the hosts 'screen' session. The syntax to connect to another user's screen session is screen -x host_username/sessionname.

Code:

screen -x jsmith/screen-test

Attached is a screenshot of 2 computers "sharing" the same terminal session.

groundhog

yahoo has made “automated hadoop upgrade test tool” . name is groundhog.

Check this out

oozie new version.

What is most tedious but difficult thing in using oozie?

Maybe that’s ‘Time zone’ and related things.

but you should know that oozie server only using UTC based time zone though you set your localtime zone. ( that means if you don't use 3.3.0 or later, you always see UTC base clock).

then how could you make your workflow working at your time zone?

the secret is 'tzOffset()' variables.

First, setting workflow application time as UTC then setting dataset timezone as your timezone. Lastly setting 'tzOffset()/60' to your event setting.

file system is getting complexed.

File system, these days ,

try to enhance performance/scale out performance.

Like Ceph, some file system adapt multiple metadata server.

And design backing algorithm to maintain data consistency among the servers. ( not consistency in objects)

Systems is getting larger and complexed. You need multiple server for metadata server(instances) and multiple servers for object data. That means you might have problem with money for a file system. but you still don't want your file system is going to be a bottle-neck of your service

How you can tackle this problem.

You have a lot of choices.

1. find the file system which is suitable for your service. that means you should define your requirement clearly first.

2. make your file system has several namespaces( that means multiple volumes ). each volume is made by one cluster ( several computers ) . then you don't worry about your whole file system goes down. if there's problem the disaster would be limited to certain directory or certain part.

3. use your coordination service. and make tight couple coordinator with you file system. the file system like 'sheepdog' is devised to use opensource coordinator package like corosync and the famous 'zookeeper'

Map Reduce workflow scheduler

Oozie vs azkaban

•	Oozie	azkaban
workflows	Oozie uses an XML file	Azkaban uses a series of Properties files
Expressing workflows	Oozie uses a Direct Acyclic Graph (DAG) (PDL sytle)	Azkaban uses topological sort (similar to Make/Ant)
Supported types of actions	mapreduce (java, streaming, pipes), pig, java, filesystem, ssh, sub-workflow + Hive/Hbase job	java, javaprocess and pig
Alternate Execution Paths	Oozie supports decision nodes allowing the workflow to make decisions	Azkaban fixes execution path at workflow start time
Scheduling	Oozie interval job scheduling is time & input-data-dependent based	Azkaban interval job scheduling is time based
Runtime	Oozie runs as server	Azkaban runs as standalone (one workflows) or server (one user, multi workflows)
Actions Execute	actions run in the Hadoop cluster as the user that submitted the workflow	Azkaban, actions run in the Azkaban server as the user running Azkaban
Workflows Submission, Management & Monitoring (server)	command-line, HTTP REST, Java API, Browser/HTML	Azkaban, browser/HTML only