Bash history can be very useful to re-trace steps performed on the system, but one of the issues is that commands are not logged in real-time but after ending a session. Also history output does not include date and time which is really useful for debugging.
In order to solve this you will need to append 3 lines to your ~/.bashrc file:
Waydroid looked like excellent option to run Android apps on my Lenovo X240 running Linux Mint.
Because Waydroid is reliant on Wayland you need to use either KDE, Gnome or Sway Desktop Environment.
I am running Gnome and Waydroid works perfectly, but I wanted it to run in fullscreen. Unfortunately Waydroid key mapping is conflicting with Gnome F11 key to go fullscreen, so first thing you need to do is to re-map Gnome fullscreen key to something like Shift+F11 which can easily be done with gnome tweaks.
But once you get your Android app to run “fullscreen” you will notice that actual size of the drawn surface is still the one window started with:
Colection of Openstack resources that work together as three-tier application is called a stack. Stack uses openstack resources like instances, networks, volumes and objects, and other elements. The application runs on a stack.
Stack can be set-up via CLI or Horizon GUI which will send API request to various Openstack services (Keystone, Nova, Neutron, Cinder, Swift, Glance …).
Heat is the Openstack orchestration service that sends these API requests automatically. Stack description is taken by heat and interpreted to API requests. Heat accepts AWS Cloudformation templates written in JSON, but heat has it’s own native format called Heat Orchestration Template (HOT) based on YAML.
Create simple stack with heat orchestration template:
Retrieve all parameter functions supported by Openstack version:
openstack orchestration template version list
+--------------------------------------+------+
| version | type |
+--------------------------------------+------+
| AWSTemplateFormatVersion.2010-09-09 | cfn |
| HeatTemplateFormatVersion.2012-12-12 | cfn |
| heat_template_version.2013-05-23 | hot |
| heat_template_version.2014-10-16 | hot |
| heat_template_version.2015-04-30 | hot |
| heat_template_version.2015-10-15 | hot |
| heat_template_version.2016-04-08 | hot |
| heat_template_version.2016-10-14 | hot |
+--------------------------------------+------+
openstack orchestration template function list heat_template_version.2016-10-14
+-----------------+-------------------------------------------------------------------------+
| functions | description |
+-----------------+-------------------------------------------------------------------------+
| list_join | A function for joining one or more lists of strings. |
| if | A function to return corresponding value based on condition evaluation. |
| yaql | A function for executing a yaql expression. |
| digest | A function for performing digest operations. |
| get_attr | A function for resolving resource attributes. |
| repeat | A function for iterating over a list of items. |
| resource_facade | A function for retrieving data in a parent provider template. |
| map_replace | A function for performing substitutions on maps. |
| str_replace | A function for performing string substitutions. |
| get_resource | A function for resolving resource references. |
| map_merge | A function for merging maps. |
| str_split | A function for splitting delimited strings into a list. |
| get_param | A function for resolving parameter references. |
| get_file | A function for including a file inline. |
+-----------------+-------------------------------------------------------------------------+
Parameters can be provided via command line with --parameter imgname=cirros-image keyname=erol-keypair Or combine several parameters under one option: --parameter "imgname=cirros-image; keyname=erol-keypair"
If you have a lot of parameters it is probably better to put them in a file again in YAML format, with single parameters key and parameter key value pairs under that key. For example create myparameters.yaml file with following contents:
In Openstack Ceilometer is the component that gathers data from the cloud and pre-processes it. It distinguishes between samples (CPU time) and events (creation of an instance). Resources, Meters and Samples are fundamental concepts in Ceilometer.
Samples are retrieved at regular intervals and if Ceilometar fails to get the sample it can be estimated by interpolation. Events are retrieved as they happen and cannot be estimated.
Ceilometer sends events to the a storage service, while samples are sent to a service named Gnocchi, which is optimized to handle large amount of time-series data.
Aodh gets measures from Gnocchi, checks whether certain conditions are met and triggers actions. This is the foundation for application auto-scaling.
Other uses for Gnocchi data are monitoring the health of the cloud and billing.
Ceilometer has three ways retrieving samples and events:
Services may voluntarily provide them by sending Ceilometer notification via Openstack’s messaging system. This is preferred way since it is based on internal knowledge that the service has about it’s resources and it is fast without much overhead and stress on the systems.
Ceilometer actively retrieves data via APIs which is a costly method for billing and alarming.
Ceilometer can get data by accessing sub-components of services such as the hypervisor that run the instances.
Second and third method are referred also as methods where Ceilometer “polls” the samples.
While Ceilometer has resources, meters and samples Gnocchi has resources, metrics and measures. Gnocchi resource corresponds to Ceilometer resource. Metric is roughly equivalent to a meter in Ceilometer. Gnocchi does not store every metric value it receives from Ceilomter, but rather it combines values and stores the results at regular intervals according to Archive policy.
Listing gnocchi resources, metrics, measures:
Resources:
gnocchi resource list gnocchi resource show UUID
Metrics:
gnocchi metric list* gnocchi metric show cpu --resource UUID
Measures:
gnocchi measures show cpu --resource UUID --start YYYY-MM-DDTHH:MM:SS+00:00
* Output will be empty for non-admin users.
Listing resources, metrics, measures with openstack client:
Resources:
openstack metric resource list openstack metric resource show UUID
Metrics:
openstack metric metric list* openstack metric metric show cpu --resource UUID
Measures:
openstack metric measures show cpu --resource UUID --start YYYY-MM-DDTHH:MM:SS+00:00
* Output will be empty for non-admin users.
Aggregation:
Server grouping:
openstack server create --property metering.server_group=Mail*
Metrics aggregation:
gnocchi measures aggregation --query server_group=Mail --resource-type=instance --aggregation mean -m cpu_util
* For gnocchi all servers with ‘–property metering.server_group=Mail’ can be considered tagged.
* For gnocchi all servers with ‘–property metering.server_group=Mail’ can be considered tagged. ** There is no option in horizon GUI to view events or statictics, but gnocchi visualisation can be provided by Grafana.
Example generating CPU and disk load and showing gnocchi measures:
Let the instances finish creating and leave them running for a while:
openstack server list
Show cpu usage measures from cpu-user server:
gnocchi measures show cpu.delta --resource-id SERVER_UUID 795 gnocchi measures show cpu_util --resource-id SERVER_UUID
Show disk usage measures from disk-user server:
gnocchi measures show disk.read.requests --resource-id SERVER_UUID gnocchi measures show disk.read.requests.rate --resource-id SERVER_UUID
* Files cpu.sh and disk.sh are your bash scripts to generate CPU load and disk load. ** Don’t forget to stop cpu-server and disk-server after you have finished, since they will continue to generate CPU and disk load.
Alarms:
An alarm has:
Type Condition: depends on type Evaluation window State: OK/Alarm/Insufficient Data Actions for state transitions
Condition example:
mean cpu_util > 60 all resources tagged server_group=Mail
openstack alarm list openstack alarm show ALARM_ID openstack alarm-history show ALARM_ID openstack alarm state get ALARM_ID openstack alarm update ALARM_ID ...
