The mice hotel owners happen to be in the hall when Bruce started jumping and growling. They rush into a nearby mouse hole in the wall, above which they stuck an Employees Only sign. When the mice come out, two have ties. The third one seems upset it seems as though one of the other two may have stolen his tie. They walk over to Bruce grinning, but the area fills with black smoke before he could complain.
Bruce and the mice run into the kitchen to see what's going on. They approach, and a fox with an apron on runs out, shortly after which a group of turtles follows, chasing the fox with silverware. They go into the kitchen and see a pot boiling over on the stove.
"Looks like turtle soup gone wrong." The booming voice says. "It was a disaster, and Bruce started to lose his cool..."
Before Bruce could start growling, one of his kids walks over. This particular young goose is wearing a bellhop uniform. Bruce looks around and notices that all his kids are in bellhop uniforms. The miniature goose bellhop takes Bruce's hand, and they walk over to the employee's only mouse hole. Bruce's other children are talking to the mice and pointing at Bruce. It looks like the mice understand Bruces' concerns. Then you hear
"...The geese stepped in to smooth things over, and the mice sort of understood." One of the mice goes into the hole and comes out with a large box that he hands to Bruce. Inside is a bear-sized bellhop uniform. In the next moment, you see Bruce and his kids standing in front of the North Woods Hotel posing for a group picture of them in their bellhop uniforms. The mouse owners agreed to take the photo, obviously at the Geese's request. The booming voice returned.
"Just when things couldn't get any worse, they did."
You see the group look into the distance as a tour bus pulls up. The bus stops, and a crowd of elephants, all with cameras, get off. The elephants start stomping everything, franticly taking snapshots, not realizing they were causing lots of property damage.
| . . . . . | ||
| . . . . . | . . . . . | |
| Bruce Screams! |


bridge_version
optional
The Strimzi HTTP Bridge for Apache Kafka provides a REST API for integrating HTTP based client applications with a Kafka cluster. You can use the API to create and manage consumers and send and receive records over HTTP rather than the native Kafka protocol.
Version : 0.1.0
Contact Email<EMAIL_ADDRESS>License : Apache 2.0
License URL : http://www.apache.org/licenses/LICENSE-2.0.html
Terms of service : http://swagger.io/terms/
Host : bridge.swagger.io
BasePath : /
Schemes : HTTP
Consumers : Consumer operations to create consumers in your Kafka cluster and perform common actions, such as subscribing to topics, retrieving processed records, and committing offsets.
Producer : Producer operations to send records to a specified topic or topic partition.
Seek : Seek operations that enable a consumer to begin receiving messages from a given offset position.
Topics : Topic operations to send messages to a specified topic or topic partition, optionally including message keys in requests. You can also retrieve topics and topic metadata.
application/json
application/json
Description : Find out more about the Strimzi HTTP Bridge
URL : https://strimzi.io/documentation/
Type : < string, < integer (int32) > array > map
| Name | Description | Schema |
|---|---|---|
auto.offset.reset |
Resets the offset position for the consumer.
If set to |
string |
consumer.request.timeout.ms |
Sets the maximum amount of time, in milliseconds, for the consumer to wait for messages for a request. If the timeout period is reached without a response, an error is returned. |
integer |
enable.auto.commit |
If set to |
boolean |
fetch.min.bytes |
Sets the minimum ammount of data, in bytes, for the consumer to receive. The broker waits until the data to send exceeds this amount. |
integer |
format |
The allowable message format for the consumer, which can be |
string |
name |
The unique name for the consumer instance. The name is unique within the scope of the consumer group. The name is used in URLs. |
string |
| Name | Schema |
|---|---|
headers |
|
key |
string |
offset |
integer (int64) |
partition |
integer (int32) |
topic |
string |
value |
string |
Type : < ConsumerRecord > array
| Name | Description | Schema |
|---|---|---|
base_uri |
Base URI used to construct URIs for subsequent requests against this consumer instance. |
string |
instance_id |
Unique ID for the consumer instance in the group. |
string |
| Name | Schema |
|---|---|
error_code |
integer (int32) |
message |
string |
| Name | Description | Schema |
|---|---|---|
key |
string |
|
value |
The header value in binary format, base64-encoded |
string (byte) |
Type : < KafkaHeader > array
| Name | Schema |
|---|---|
offset |
integer (int64) |
partition |
integer (int32) |
topic |
string |
| Name | Schema |
|---|---|
offsets |
< OffsetCommitSeek > array |
| Name | Schema |
|---|---|
offset |
integer (int64) |
partition |
integer (int32) |
| Name | Schema |
|---|---|
offsets |
< OffsetRecordSent > array |
| Name | Schema |
|---|---|
beginning_offset |
integer (int64) |
end_offset |
integer (int64) |
| Name | Schema |
|---|---|
partition |
integer (int32) |
topic |
string |
| Name | Schema |
|---|---|
leader |
integer (int32) |
partition |
integer (int32) |
replicas |
< Replica > array |
| Name | Schema |
|---|---|
partitions |
< Partition > array |
| Name | Schema |
|---|---|
headers |
|
partition |
integer (int32) |
| Name | Schema |
|---|---|
records |
< ProducerRecord > array |
Type : object
| Name | Schema |
|---|---|
records |
< ProducerRecordToPartition > array |
| Name | Schema |
|---|---|
broker |
integer (int32) |
in_sync |
boolean |
leader |
boolean |
| Name | Schema |
|---|---|
partitions |
< AssignedTopicPartitions > array |
topics |
| Name | Description | Schema |
|---|---|---|
configs |
Per-topic configuration overrides |
< string, string > map |
name |
Name of the topic |
string |
partitions |
< PartitionMetadata > array |
| Name | Description | Schema |
|---|---|---|
topic_pattern |
A regex topic pattern for matching multiple topics |
string |
topics |
< string > array |
Retrieves information about the Kafka Bridge instance, in JSON format.
| HTTP Code | Description | Schema |
|---|---|---|
200 |
Information about Kafka Bridge instance. |
application/json
{
"bridge_version" : "0.16.0"
}
Creates a consumer instance in the given consumer group. You can optionally specify a consumer name and supported configuration options. It returns a base URI which must be used to construct URLs for subsequent requests against this consumer instance.
| Type | Name | Description | Schema |
|---|---|---|---|
Path |
groupid |
ID of the consumer group in which to create the consumer. |
string |
Body |
body |
Name and configuration of the consumer. The name is unique within the scope of the consumer group. If a name is not specified, a randomly generated name is assigned. All parameters are optional. The supported configuration options are shown in the following example. |
| HTTP Code | Description | Schema |
|---|---|---|
200 |
Consumer created successfully. |
|
409 |
A consumer instance with the specified name already exists in the Kafka Bridge. |
|
422 |
One or more consumer configuration options have invalid values. |
application/vnd.kafka.v2+json
application/vnd.kafka.v2+json
Consumers
{
"name" : "consumer1",
"format" : "binary",
"auto.offset.reset" : "earliest",
"enable.auto.commit" : false,
"fetch.min.bytes" : 512,
"consumer.request.timeout.ms" : 30000
}
{
"application/vnd.kafka.v2+json" : {
"instance_id" : "consumer1",
"base_uri" : "http://localhost:8080/consumers/my-group/instances/consumer1"
}
}
{
"application/vnd.kafka.v2+json" : {
"error_code" : 409,
"message" : "A consumer instance with the specified name already exists in the Kafka Bridge."
}
}
{
"application/vnd.kafka.v2+json" : {
"error_code" : 422,
"message" : "One or more consumer configuration options have invalid values."
}
}
Deletes a specified consumer instance. The request for this operation MUST use the base URL (including the host and port) returned in the response from the POST
request to /consumers/{groupid}
that was used to create this consumer.
| Type | Name | Description | Schema |
|---|---|---|---|
Path |
groupid |
ID of the consumer group to which the consumer belongs. |
string |
Path |
name |
Name of the consumer to delete. |
string |
| HTTP Code | Description | Schema |
|---|---|---|
204 |
Consumer removed successfully. |
No Content |
404 |
The specified consumer instance was not found. |
application/vnd.kafka.v2+json
application/vnd.kafka.v2+json
Consumers
{
"application/vnd.kafka.v2+json" : {
"error_code" : 404,
"message" : "The specified consumer instance was not found."
}
}
Assigns one or more topic partitions to a consumer.
| Type | Name | Description | Schema |
|---|---|---|---|
Path |
groupid |
ID of the consumer group to which the consumer belongs. |
string |
Path |
name |
Name of the consumer to assign topic partitions to. |
string |
Body |
body |
List of topic partitions to assign to the consumer. |
| HTTP Code | Description | Schema |
|---|---|---|
204 |
Partitions assigned successfully. |
No Content |
404 |
The specified consumer instance was not found. |
|
409 |
Subscriptions to topics, partitions, and patterns are mutually exclusive. |
application/vnd.kafka.v2+json
application/vnd.kafka.v2+json
Consumers
{
"partitions" : [ {
"topic" : "topic",
"partition" : 0
}, {
"topic" : "topic",
"partition" : 1
} ]
}
{
"application/vnd.kafka.v2+json" : {
"error_code" : 404,
"message" : "The specified consumer instance was not found."
}
}
{
"application/vnd.kafka.v2+json" : {
"error_code" : 409,
"message" : "Subscriptions to topics, partitions, and patterns are mutually exclusive."
}
}
Commits a list of consumer offsets. To commit offsets for all records fetched by the consumer, leave the request body empty.
| Type | Name | Description | Schema |
|---|---|---|---|
Path |
groupid |
ID of the consumer group to which the consumer belongs. |
string |
Path |
name |
Name of the consumer. |
string |
Body |
body |
List of consumer offsets to commit to the consumer offsets commit log. You can specify one or more topic partitions to commit offsets for. |
| HTTP Code | Description | Schema |
|---|---|---|
204 |
Commit made successfully. |
No Content |
404 |
The specified consumer instance was not found. |
application/vnd.kafka.v2+json
application/vnd.kafka.v2+json
Consumers
{
"offsets" : [ {
"topic" : "topic",
"partition" : 0,
"offset" : 15
}, {
"topic" : "topic",
"partition" : 1,
"offset" : 42
} ]
}
{
"application/vnd.kafka.v2+json" : {
"error_code" : 404,
"message" : "The specified consumer instance was not found."
}
}
Configures a subscribed consumer to fetch offsets from a particular offset the next time it fetches a set of records from a given topic partition. This overrides the default fetch behavior for consumers. You can specify one or more topic partitions.
| Type | Name | Description | Schema |
|---|---|---|---|
Path |
groupid |
ID of the consumer group to which the consumer belongs. |
string |
Path |
name |
Name of the subscribed consumer. |
string |
Body |
body |
List of partition offsets from which the subscribed consumer will next fetch records. |
| HTTP Code | Description | Schema |
|---|---|---|
204 |
Seek performed successfully. |
No Content |
404 |
The specified consumer instance was not found, or the specified consumer instance did not have one of the specified partitions assigned. |
application/vnd.kafka.v2+json
application/vnd.kafka.v2+json
Consumers
Seek
{
"offsets" : [ {
"topic" : "topic",
"partition" : 0,
"offset" : 15
}, {
"topic" : "topic",
"partition" : 1,
"offset" : 42
} ]
}
{
"application/vnd.kafka.v2+json" : {
"error_code" : 404,
"message" : "The specified consumer instance was not found."
}
}
Configures a subscribed consumer to seek (and subsequently read from) the first offset in one or more given topic partitions.
| Type | Name | Description | Schema |
|---|---|---|---|
Path |
groupid |
ID of the consumer group to which the subscribed consumer belongs. |
string |
Path |
name |
Name of the subscribed consumer. |
string |
Body |
body |
List of topic partitions to which the consumer is subscribed. The consumer will seek the first offset in the specified partitions. |
| HTTP Code | Description | Schema |
|---|---|---|
204 |
Seek to the beginning performed successfully. |
No Content |
404 |
The specified consumer instance was not found, or the specified consumer instance did not have one of the specified partitions assigned. |
application/vnd.kafka.v2+json
application/vnd.kafka.v2+json
Consumers
Seek
{
"partitions" : [ {
"topic" : "topic",
"partition" : 0
}, {
"topic" : "topic",
"partition" : 1
} ]
}
{
"application/vnd.kafka.v2+json" : {
"error_code" : 404,
"message" : "The specified consumer instance was not found."
}
}
Configures a subscribed consumer to seek (and subsequently read from) the offset at the end of one or more of the given topic partitions.
| Type | Name | Description | Schema |
|---|---|---|---|
Path |
groupid |
ID of the consumer group to which the subscribed consumer belongs. |
string |
Path |
name |
Name of the subscribed consumer. |
string |
Body |
body |
List of topic partitions to which the consumer is subscribed. The consumer will seek the last offset in the specified partitions. |
| HTTP Code | Description | Schema |
|---|---|---|
204 |
Seek to the end performed successfully. |
No Content |
404 |
The specified consumer instance was not found, or the specified consumer instance did not have one of the specified partitions assigned. |
application/vnd.kafka.v2+json
application/vnd.kafka.v2+json
Consumers
Seek
{
"partitions" : [ {
"topic" : "topic",
"partition" : 0
}, {
"topic" : "topic",
"partition" : 1
} ]
}
{
"application/vnd.kafka.v2+json" : {
"error_code" : 404,
"message" : "The specified consumer instance was not found."
}
}
Retrieves records for a subscribed consumer, including message values, topics, and partitions. The request for this operation MUST use the base URL (including the host and port) returned in the response from the POST
request to /consumers/{groupid}
that was used to create this consumer.
| Type | Name | Description | Schema |
|---|---|---|---|
Path |
groupid |
ID of the consumer group to which the subscribed consumer belongs. |
string |
Path |
name |
Name of the subscribed consumer to retrieve records from. |
string |
Query |
max_bytes |
The maximum size, in bytes, of unencoded keys and values that can be included in the response. Otherwise, an error response with code 422 is returned. |
integer |
Query |
timeout |
The maximum amount of time, in milliseconds, that the HTTP Bridge spends retrieving records before timing out the request. |
integer |
| HTTP Code | Description | Schema |
|---|---|---|
200 |
Poll request executed successfully. |
|
404 |
The specified consumer instance was not found. |
|
406 |
The |
|
422 |
Response exceeds the maximum number of bytes the consumer can receive |
application/vnd.kafka.json.v2+json
application/vnd.kafka.binary.v2+json
application/vnd.kafka.v2+json
Consumers
{
"application/vnd.kafka.json.v2+json" : [ {
"topic" : "topic",
"key" : "key1",
"value" : {
"foo" : "bar"
},
"partition" : 0,
"offset" : 2
}, {
"topic" : "topic",
"key" : "key2",
"value" : [ "foo2", "bar2" ],
"partition" : 1,
"offset" : 3
} ],
"application/vnd.kafka.binary.v2+json" : "[\n {\n \"topic\": \"test\",\n \"key\": \"a2V5\",\n \"value\": \"Y29uZmx1ZW50\",\n \"partition\": 1,\n \"offset\": 100,\n },\n {\n \"topic\": \"test\",\n \"key\": \"a2V5\",\n \"value\": \"a2Fma2E=\",\n \"partition\": 2,\n \"offset\": 101,\n }\n]"
}
{
"application/vnd.kafka.v2+json" : {
"error_code" : 404,
"message" : "The specified consumer instance was not found."
}
}
{
"application/vnd.kafka.v2+json" : {
"error_code" : 406,
"message" : "The `format` used in the consumer creation request does not match the embedded format in the Accept header of this request."
}
}
{
"application/vnd.kafka.v2+json" : {
"error_code" : 422,
"message" : "Response exceeds the maximum number of bytes the consumer can receive"
}
}
Subscribes a consumer to one or more topics. You can describe the topics to which the consumer will subscribe in a list (of Topics
type) or as a topic_pattern
field. Each call replaces the subscriptions for the subscriber.
| Type | Name | Description | Schema |
|---|---|---|---|
Path |
groupid |
ID of the consumer group to which the subscribed consumer belongs. |
string |
Path |
name |
Name of the consumer to unsubscribe from topics. |
string |
Body |
body |
List of topics to which the consumer will subscribe. |
| HTTP Code | Description | Schema |
|---|---|---|
204 |
Consumer subscribed successfully. |
No Content |
404 |
The specified consumer instance was not found. |
|
409 |
Subscriptions to topics, partitions, and patterns are mutually exclusive. |
|
422 |
A list (of |
application/vnd.kafka.v2+json
application/vnd.kafka.v2+json
Consumers
{
"topics" : [ "topic1", "topic2" ]
}
{
"application/vnd.kafka.v2+json" : {
"error_code" : 404,
"message" : "The specified consumer instance was not found."
}
}
{
"application/vnd.kafka.v2+json" : {
"error_code" : 409,
"message" : "Subscriptions to topics, partitions, and patterns are mutually exclusive."
}
}
{
"application/vnd.kafka.v2+json" : {
"error_code" : 422,
"message" : "A list (of Topics type) or a topic_pattern must be specified."
}
}
Retrieves a list of the topics to which the consumer is subscribed.
| Type | Name | Description | Schema |
|---|---|---|---|
Path |
groupid |
ID of the consumer group to which the subscribed consumer belongs. |
string |
Path |
name |
Name of the consumer to unsubscribe from topics. |
string |
| HTTP Code | Description | Schema |
|---|---|---|
200 |
List of subscribed topics and partitions. |
|
404 |
The specified consumer instance was not found. |
application/vnd.kafka.v2+json
Consumers
{
"topics" : [ "my-topic1", "my-topic2" ],
"partitions" : [ {
"my-topic1" : [ 1, 2, 3 ]
}, {
"my-topic2" : [ 1 ]
} ]
}
{
"application/vnd.kafka.v2+json" : {
"error_code" : 404,
"message" : "The specified consumer instance was not found."
}
}
Unsubscribes a consumer from all topics.
| Type | Name | Description | Schema |
|---|---|---|---|
Path |
groupid |
ID of the consumer group to which the subscribed consumer belongs. |
string |
Path |
name |
Name of the consumer to unsubscribe from topics. |
string |
| HTTP Code | Description | Schema |
|---|---|---|
204 |
Consumer unsubscribed successfully. |
No Content |
404 |
The specified consumer instance was not found. |
Consumers
{
"error_code" : 404,
"message" : "The specified consumer instance was not found."
}
Check if the bridge is running. This does not necessarily imply that it is ready to accept requests.
| HTTP Code | Description | Schema |
|---|---|---|
200 |
The bridge is healthy |
No Content |
Retrieves the OpenAPI v2 specification in JSON format.
| HTTP Code | Description | Schema |
|---|---|---|
200 |
OpenAPI v2 specification in JSON format retrieved successfully. |
string |
application/json
Check if the bridge is ready and can accept requests.
| HTTP Code | Description | Schema |
|---|---|---|
200 |
The bridge is ready |
No Content |
Retrieves a list of all topics.
| HTTP Code | Description | Schema |
|---|---|---|
200 |
List of topics. |
< string > array |
application/vnd.kafka.v2+json
Topics
{
"application/vnd.kafka.v2+json" : [ "topic1", "topic2" ]
}
Sends one or more records to a given topic, optionally specifying a partition, key, or both.
| Type | Name | Description | Schema |
|---|---|---|---|
Path |
topicname |
Name of the topic to send records to or retrieve metadata from. |
string |
Body |
body |
| HTTP Code | Description | Schema |
|---|---|---|
200 |
Records sent successfully. |
|
404 |
The specified topic was not found. |
|
422 |
The record list is not valid. |
application/vnd.kafka.json.v2+json
application/vnd.kafka.binary.v2+json
application/vnd.kafka.v2+json
Producer
Topics
{
"records" : [ {
"key" : "key1",
"value" : "value1"
}, {
"value" : "value2",
"partition" : 1
}, {
"value" : "value3"
} ]
}
{
"application/vnd.kafka.v2+json" : {
"offsets" : [ {
"partition" : 2,
"offset" : 0
}, {
"partition" : 1,
"offset" : 1
}, {
"partition" : 2,
"offset" : 2
} ]
}
}
{
"application/vnd.kafka.v2+json" : {
"error_code" : 404,
"message" : "The specified topic was not found."
}
}
{
"application/vnd.kafka.v2+json" : {
"error_code" : 422,
"message" : "The record list contains invalid records."
}
}
Retrieves the metadata about a given topic.
| Type | Name | Description | Schema |
|---|---|---|---|
Path |
topicname |
Name of the topic to send records to or retrieve metadata from. |
string |
| HTTP Code | Description | Schema |
|---|---|---|
200 |
Topic metadata |
application/vnd.kafka.v2+json
Topics
{
"application/vnd.kafka.v2+json" : {
"name" : "topic",
"offset" : 2,
"configs" : {
"cleanup.policy" : "compact"
},
"partitions" : [ {
"partition" : 1,
"leader" : 1,
"replicas" : [ {
"broker" : 1,
"leader" : true,
"in_sync" : true
}, {
"broker" : 2,
"leader" : false,
"in_sync" : true
} ]
}, {
"partition" : 2,
"leader" : 2,
"replicas" : [ {
"broker" : 1,
"leader" : false,
"in_sync" : true
}, {
"broker" : 2,
"leader" : true,
"in_sync" : true
} ]
} ]
}
}
Retrieves a list of partitions for the topic.
| Type | Name | Description | Schema |
|---|---|---|---|
Path |
topicname |
Name of the topic to send records to or retrieve metadata from. |
string |
| HTTP Code | Description | Schema |
|---|---|---|
200 |
List of partitions |
< PartitionMetadata > array |
404 |
The specified topic was not found. |
application/vnd.kafka.v2+json
Topics
{
"application/vnd.kafka.v2+json" : [ {
"partition" : 1,
"leader" : 1,
"replicas" : [ {
"broker" : 1,
"leader" : true,
"in_sync" : true
}, {
"broker" : 2,
"leader" : false,
"in_sync" : true
} ]
}, {
"partition" : 2,
"leader" : 2,
"replicas" : [ {
"broker" : 1,
"leader" : false,
"in_sync" : true
}, {
"broker" : 2,
"leader" : true,
"in_sync" : true
} ]
} ]
}
{
"application/vnd.kafka.v2+json" : {
"error_code" : 404,
"message" : "The specified topic was not found."
}
}
Sends one or more records to a given topic partition, optionally specifying a key.
| Type | Name | Description | Schema |
|---|---|---|---|
Path |
partitionid |
ID of the partition to send records to or retrieve metadata from. |
integer |
Path |
topicname |
Name of the topic to send records to or retrieve metadata from. |
string |
Body |
body |
List of records to send to a given topic partition, including a value (required) and a key (optional). |
| HTTP Code | Description | Schema |
|---|---|---|
200 |
Records sent successfully. |
|
404 |
The specified topic partition was not found. |
|
422 |
The record is not valid. |
application/vnd.kafka.json.v2+json
application/vnd.kafka.binary.v2+json
application/vnd.kafka.v2+json
Producer
Topics
{
"records" : [ {
"key" : "key1",
"value" : "value1"
}, {
"value" : "value2"
} ]
}
{
"application/vnd.kafka.v2+json" : {
"offsets" : [ {
"partition" : 2,
"offset" : 0
}, {
"partition" : 1,
"offset" : 1
}, {
"partition" : 2,
"offset" : 2
} ]
}
}
{
"application/vnd.kafka.v2+json" : {
"error_code" : 404,
"message" : "The specified topic partition was not found."
}
}
{
"application/vnd.kafka.v2+json" : {
"error_code" : 422,
"message" : "The record is not valid."
}
}
Retrieves partition metadata for the topic partition.
| Type | Name | Description | Schema |
|---|---|---|---|
Path |
partitionid |
ID of the partition to send records to or retrieve metadata from. |
integer |
Path |
topicname |
Name of the topic to send records to or retrieve metadata from. |
string |
| HTTP Code | Description | Schema |
|---|---|---|
200 |
Partition metadata |
|
404 |
The specified topic partition was not found. |
application/vnd.kafka.v2+json
Topics
{
"application/vnd.kafka.v2+json" : {
"partition" : 1,
"leader" : 1,
"replicas" : [ {
"broker" : 1,
"leader" : true,
"in_sync" : true
}, {
"broker" : 2,
"leader" : false,
"in_sync" : true
} ]
}
}
{
"application/vnd.kafka.v2+json" : {
"error_code" : 404,
"message" : "The specified topic partition was not found."
}
}
Retrieves a summary of the offsets for the topic partition.
| Type | Name | Description | Schema |
|---|---|---|---|
Path |
partitionid |
ID of the partition. |
integer |
Path |
topicname |
Name of the topic containing the partition. |
string |
| HTTP Code | Description | Schema |
|---|---|---|
200 |
A summary of the offsets for the topic partition. |
|
404 |
The specified topic partition was not found. |
application/vnd.kafka.v2+json
Topics
{
"application/vnd.kafka.v2+json" : {
"beginning_offset" : 10,
"end_offset" : 50
}
}
{
"application/vnd.kafka.v2+json" : {
"error_code" : 404,
"message" : "The specified topic partition was not found."
}
}
Revised on 2021-12-12 16:00:59 +0100


Each and every restaurant meal produces half a pound of food waste. All that adds up to 11.4 million tons—and $25 billion—of food waste each year just from U.S. restaurants, says a recent report by the nonprofit ReFED. So what do restaurants do with leftover food?
We give the leftover food to people in need of it, to homeless shelters, orphanages, senior homes etc.
Volunteers
These superheroes are ordinary people with hearts for giving and helping others. They dedicate their time and effort to local causes they're passionate about, positively impacting the lives of others in their communities.
An opportunity to serve the community, it's a voluntary work, flexible timings. Nothing to lose, volunteering your time will have a big impact and will be rewarding in ways you never expected.
Donors/Business
You see the importance of making small changes close to home to make your community a better place to live.
Your help feeds thousands of people and reduce wastage of food and resources. An opportunity to serve the
community and to distribute the leftover food.


---
layout: post
title: ''
date: '2010-11-11T12:40:54-08:00'
tags:
tumblr_url: http://alexhwilliams.tumblr.com/post/1545590278/four-square-heroes-of-the-game-no-location
---
Four Square - Heroes of the Game
No location based monkeying around here.
This is the real Four Square - gridiron on the playground.


Creates a new Pool instance.
Inserts a new host to the pool.
Makes a request and discards any response body it receives. An error is returned on a non-2xx status code.
Returns a list of currently active hosts.
Returns a list of hosts that are currently disabled due to network errors.
Returns true if there's any host available to by queried.
Makes a request and calls back with the response, parsed as JSON. An error is returned on a non-2xx status code or on a parsing exception.
Ping sends out a request to all available Kapacitor servers, reporting on their response time and version number.
Makes a request and calls back with the IncomingMessage stream, if possible. An error is returned on a non-2xx status code.
Makes a request and resolves with the plain text response, if possible. An error is raised on a non-2xx status code.
Generated using TypeDoc
The Pool maintains a list available Kapacitor hosts and dispatches requests to them. If there are errors connecting to hosts, it will disable that host for a period of time.


Investopedia: Green Technology
Green Technology is an umbrella term that describes the use of technology and science to create products and services that are environmentally friendly. Green-tech is related to cleantech, which specifically refers to products or services that improve operational performance while also reducing costs, energy consumption, waste, or negative effects on the environment. The goal of green tech is to protect the environment, repair damage done to the environment in the past, conserve natural resources, and preserve the Earth's natural resources. Green-tech has also become a burgeoning industry that's attracting enormous amounts of investment capital. The use of green tech can be a stated goal of a business segment or a company. While green tech has become increasingly popular in the modern age, elements of these business practices have been in use since the Industrial Revolution. Still, green technology as a recognized business sector did not really develop until the 1990s. To read the full version


ABBAS ALI & SONS UNIFORMS AND TEXTILES
Sales
Sales Order
Packing List
Commercial Invoice
Reciept Voucher
Purchase
Purchase Order
Good Recieving Note / Invoice
Vendor Payment
Production
Reports
Sales Report
Purchase Report
Production Report
Accounts Report
Master Data
Master View
Packing List
Search
Refresh
New
Save as draft
Print
Cancel Sales Order
Delete
Delivery Order/Packing List
Customers
Select Customer
L.P.O Ref
Select Lpo
Invoice#
Date
Organization Name:
Address:
Contact:
Person
Item
Size
Available Qty
Qty to deliver
Ctn/bale no
pcs per ctn/bale
Add in List
Update Packing List
Generate Packing List


Koi apps have no gas fees and anyone can participate.
The Koi protocol is open source and the Network is governed by KOI token holders.
Keep the rights (and rewards) for the content you create and post.


Docker
Edit (pull request)The puccini orchestrator plugin allows you to deploy applications on Docker.
Tosca mapped / location exposed types
The Docker location exposes some types to help you configure a deployment and map the native Tosca types. Theses nodes are exposed as on demand resources
on the location management view.
Compute
The tosca type tosca.nodes.Compute
is mapped to the Docker nodes:
org.alien4cloud.puccini.docker.nodes.Container
for a docker container
Explanation to the properties:
image_id
: The image id for running the containertag
: The tag for the docker imageinteractive
:exposed_ports
: Put the exposed port of the docker containerport_mappings
: Mapping the exposed port of the docker container to the port of the host.from
: Put the exposed port of the docker containerto
: Put the mapped port of the host
pull_image
: If selected, it will pull the docker image from docker hub, else local image will be used.puccini_concurrent_restriction
: The number of the task can be executed concurrently on the compute instance.
Network
The tosca type tosca.nodes.Network
can be mapped as org.alien4cloud.puccini.docker.nodes.Network
:
Explanation to the properties:
network_name
: The name of the networkcidr
: The ip range of the network
Volumes
TODO
Deletable volumes
TODO


1 write to _helpCommand
System.Management.Automation (1)
engine\debugger\debugger.cs (1)
5086
_commandTable[HelpCommand] = _commandTable[HelpShortcut] =
_helpCommand
= new DebuggerCommand(HelpCommand, null, repeatOnEnter: false, executedByDebugger: true);
1 reference to _helpCommand
System.Management.Automation (1)
engine\debugger\debugger.cs (1)
5196
if (debuggerCommand ==
_helpCommand
)


1.it is the process of contaminating the environment.
1. avoid burning rubbish in open to prevent respiratory problems.
recycling used materials eg plastics to make complex materials eg drums.
avoid disposing chemicals in rivers to prevent death of water animals.


Validation Results
ChemWizard
v<IP_ADDRESS>
Manifest validation:
Passed
For additional information, review the
Office Store Validation Policy
.
Sat, 04 Nov 2017 20:14:07 GMT
Request Correlation ID: 647e2d0d-504e-4836-bbe5-4399e1efb817


PAYMENT SYSTEM #{{ payment.serial_no }}
Home > Payment System > Payment System #{{ payment.serial_no }}
Serial no :
#{{ payment.serial_no }}
-
Reference no :
Payment type :
{{ payment.payment_type | capitalize }}
Payment Method :
{{ payment.payment_method | capitalize }}
For :
{{ payment.sender.username | capitalize }}
Total Amount :
{{ payment.total_amount | currency:undefined:'1.2-2' }}
Status :
{{ payment.status | capitalize }}
PAYMENT SYSTEM
Home > Payment System


Example Xaal Animation in JSXaal
The following shows an example of the JSXaal Xaal animation viewer. If you are not seeing anything, you either have an unsuitable browser or something is broken. It should work at least in Firefox 3+ and Safari 3+. It definitely won't work in IE. If it is broken in a supported browser, let me know.


" please ensure that the vim modeline option is not disabled vim:textwidth=72 ------------------------------------------------------------------------------- Zones on shared storage (v1.3) ---------- A. INTRODUCTION The most commonly requested zones feature is support for the NFS server within a zone (4964859). The next two most requested zones features are support for hosting zones on shared storage, specifically NFS and iSCSI. These last two requests are being tracked via the following bugs: 6688400 Want zonepath on iscsi targets 4963321 RFE: hosting root filesystems for Zones on NFS servers This document proposed a plan to address the latter two issues. These proposed changes will also start to bring the zones storage administration closer in line with the experience provided by other virtualization technologies (VTs, examples of which are xVM, LDOMs, and VirtualBox). ---------- B. BACKGROUND Currently, it is possible to combine existing supported technologies (FC, iSCSI, NFS, lofi, zfs, etc) to host zones on shared storage, and there are a few blog entries out there describing how to create such configurations[00]. While these configurations are usable and technically supportable, they require extensive configuration of multiple different technologies, making them complex, potentially fragile (since they are not regularly tested), and out of reach for most customers. Creating these configurations today also causes problems with the use of other existing zones features, the most obvious of which is zone migration. These configurations complicate zone migration because all of the additional global zone configuration that was required to host the zone on shared storage must be tracked and then migrated along with the zone data itself. VM Migration is critical component of all existing VTs and anything that can be done to improve zone migration support would be a great benefit to zones administrators. All the other virtualization technologies currently available in Solaris support the hosting of Virtual Machines (VMs) on shared storage. They all do this in the same fashion, which involves taking a "storage object"[01] which is accessible from the "global zone"[02], and making it visible within the VM as a local disk. In this document we're refer to this process as "encapsulation", since the "disk" which a VM thinks it's accessing is actually contained (ie encapsulated) within some storage object in the global zone. This encapsulation has advantages and disadvantages. Encapsulation makes it easier to manage the storage associated with VMs. These storage objects may be accessible from multiple hosts simultaneously. They can be backed up, restored, moved around, and copied as individual files instead of filesystems. One disadvantage of the encapsulation used by these other VTs is that currently on Solaris, there is no way to open up these encapsulated disks and access their contents from the global zone. Currently, the only way to access these encapsulated disks is to import them into a running VM. Another interesting development with these encapsulated disks used by other VTs is the proliferation of storage object formats. These custom storage objects formats allows for features which are transparent to the VM using the disks and independent of any features offered by the underlying global zone. While specific feature sets may vary, common features that may be supported are things like compression, sparseness, dedup, snapshotting, and rollback. Management of all these storage object features is usually done from the global zone. Examples of some of these different formats are: VDI - VirtualBox Virtual HDD VHD - Microsoft Virtual Hard Disk VMDK - VMWare Virtual Machine Disk These formats are also commonly used for moving and sharing VM images, and it's not uncommon for users to take VMs encapsulated in one format and convert them into another. ---------- C. PROPOSAL / DESCRIPTION The essence of this proposal is to enhance zonecfg(1m) to allow for the specification of shared storage objects which can be used to encapsulate zone filesystems, including the zones root filesystem. Once shared storage objects are specified in zonecfg(1m) the management of this shared storage will be handled automatically by the zones framework. This will allow administrators to host zones on shared storage with no additional system configuration being required outside of zonecfg(1m). It will also provide zones with a consistent global zone storage usage and administration experience compared with other VTs. All the existing zoneadm(1m) operations that administrators can do today should continue to work seamlessly with this new support for shared storage objects. The proposal is broken down into the following subsections: C.0 Out of scope C.1 Zones enhancements C.2 Storage object uid/gid handling C.3 Taskq enhancements C.4 Zfs enhancements C.5 Lofi and lofiadm(1m) enhancements C.6 Performance considerations C.7 Phased delivery C.8 Future work ---------- C.0 Out of scope Before discussing the details of the changes being proposed, here are the things this proposal will not address: - Hosting zones natively on NFS. We will not be considering enhancements which would allow zone roots to live natively (ie, unencapsulated) on NFS. Supporting this functionality is not prevented by anything proposed herein, but initially we are not pursuing this option because: - Encapsulation allows us to host zones on a myriad of storage in addition to NFS. - Encapsulation brings the zones storage feature set closer in line with other VTs. - Encapsulation will likely be easier to implement than unencapsulated hosting of a zone root filesystems on NFS. - Advanced shared storage configuration. Initially there will be no support for advanced shared storage configuration options. If advanced configuration options need to be used, they will need to be setup in the global zone outside the zones framework. That said, nothing in this proposal should prevent us from adding support for more complex configurations in the future, should they become popular. Some examples of what would be considered advanced shared storage configuration options are (and this is by no means a complete list): - iSCSI target discovery management - iSCSI target parameter configuration (CHAP, etc) - custom vdisk creation options - encapsulated zpools spanning multiple storage objects - custom zpool/zfs creation options ---------- C.1 Zones enhancements This is a list of proposed enhancements to specific zones subsystems. It is broken down into the following categories: C.1.i Zonecfg(1m) C.1.ii Storage object uri (so-uri) format C.1.iii Zoneadm(1m) install C.1.iv Zoneadm(1m) attach C.1.v Zoneadm(1m) boot C.1.vi Zoneadm(1m) detach C.1.vii Zoneadm(1m) uninstall C.1.viii Zoneadm(1m) clone C.1.ix Zoneadm(1m) move C.1.x Zonecfg(1m) misc changes ---------- C.1.i Zonecfg(1m) The zonecfg(1m) command will be enhanced with the following two new resources and associated properties: rootzpool resource src resource property install-size resource property zpool-preserve resource property dataset resource property user resource property zpool resource src resource property install-size resource property zpool-preserve resource property name resource property user resource property The new resource and properties will be defined as follows: "rootzpool" - Status: Optional. - Description: Identifies a shared storage object (and it's associated parameters) which will be used to contain the root zfs filesystem for a zone. Only one "rootzpool" may be defined per zone. "zpool" - Status: Optional. - Description: Identifies a shared storage object (and it's associated parameters) which will be made available to the zone as a delegated zfs dataset. Multiple "zpool" resources may be defined per zone. "src" - Status: Required. - Format: Storage object uri (so-uri). (See definition below.) - Description: Identifies the storage object associated with this resource. "install-size" - Status: Optional. - Format: Integer. Defaults to bytes, but can be flagged as gigabytes, kilobytes, or megabytes, with a g, k, or m suffix, respectively. - Description: If the specified storage object doesn't exist at zone install time it will be created with this specific size. This property has no effect for storage objects which already exist and have a pre-defined size. "zpool-preserve" - Status: Optional. - Format: Boolean. Defaults to false. - Description: When doing an install, if this property if this property is set to true and a zpool already exists on the specified storage object it will be used. When doing a destroy, if this property is set to true, the root zpool will not be destroyed. "dataset" - Status: Optional - Format: zfs filesystem name component (can't contain a '/') - Description: Name of a dataset within the root zpool to delegate to the zone. "name" - Status: Required - Format: zfs filesystem name component (can't contain a '/') - Description: Used as part of the name for a zpool which will be delegated to the zone. "user" - Status: Optional - Format: User name string - Description: User name to use when accessing a path:// or nfs:// based storage object. Zonecfg(1m) "verify" will verify the syntax of any "rootzpool" resource group (and its properties), but it will NOT verify the accessibility of any storage specified by by a so-uri. (This is because accessing the storage specified by an so-uri could require configuration changes to other subsystems.) These new resources should provide zone administrators with lots of flexibility when it comes to deploying zones on shared storage. Some of the likely zone deployment models that are envisioned and enabled by this proposal are: - A zone with an encapsulated "rootzpool" zpool. In this scenario the OS will be stored in the "rootzpool", and all non-OS software and data will also be stored in datasets which are descendent from the zone root dataset. This means that system operations which snapshot and clone the OS will also snapshot and clone non-OS software and data. - A zone with an encapsulated "rootzpool" zpool and a "dataset" defined within the "rootzpool". In this scenario, the OS will be stored in in the "rootzpool", and all non-OS software and data will be stored within "dataset", which is also contained within the "rootzpool", but is not a direct descendent of any zone root dataset. This means that system operations which snapshot and clone the OS will not affect non-OS software and data. - A zone with an encapsulated "rootzpool" and one or more encapsulated "zpool"s. In this scenario, the OS will be stored in in the "rootzpool", and all non-OS software and data will be stored within other "zpool"s. This means that system operations which snapshot and clone the OS will not affect non-OS software and data. More information about these new resources and how they will be managed by the zones framework is available below. ---------- C.1.ii Storage object uri (so-uri) format The storage object uri (so-uri) syntax[03] will conform to the standard uri format defined in RFC 3986 [04]. The nfs URI scheme is defined in RFC 2224 [05]. The so-uri syntax can be summarised as follows: File and vdisk storage objects: path:///<file-absolute> nfs://<host>[:port]/<file-absolute> Device storage objects: path:///dev/<file-absolute> fc:///wwn[@<lun>] iscsi:///alias=<alias>[@<lun>] iscsi:///target=<target>[@<lun>] iscsi://host[:port]/[tpgt=<tpgt>/]target=<target>[@<lun>] File storage objects point to plain files on a local, nfs, or cifs filesystems. These files are used to contain zpools which store zone datasets. These are the simplest types of storage objects. Once created, they have a fixed size, can't be grown, and don't support advanced features like snapshotting, etc. Some example file so-uris are: path:///export/xvm/vm1.disk - a local file path:///net/heaped.sfbay/export/xvm/1.disk - a nfs file accessible via autofs nfs://heaped.sfbay/export/xvm/1.disk - same file specified directly via a nfs so-uri Vdisk storage objects are similar to file storage objects in that they can live on local, nfs, or cifs filesystems, but they each have their own special data format and varying feature sets, with support for things like snapshotting, etc.. Some common vdisk formats are: VDI, VMDK and VHD. Some example vdisk so-uris are: path:///export/xvm/vm1.vmdk - a local vdisk image directory path:///net/heaped.sfbay/export/xvm/1.vmdk - a nfs vdisk image directory accessible via autofs nfs://heaped.sfbay/export/xvm/1.vmdk - same vdisk image directory specified directly via a nfs so-uri Device storage objects specify block storage devices in a host independent fashion. Some /dev device names may already be named in a host independent fashion. In this case the admin can simply specify the /dev device path for this device as the so-uri. When configuring FC or iscsi storage on different hosts, the storage configuration normally lives outside of zonecfg, and the configured storage may have varying /dev/dsk/cXtXdX* names. In these cases, the so-uri syntax provides a way to specify storage in a host independent fashion, and during zone management operations, the zones framework can map this storage to a host specific device path. Some example device so-uris are: path:///dev/vx/dsk/zone1/rootvol - a Veritas volume that is accessible from multiple hosts using the same name fc:///20000014c347492a@0 - lun 0 of a fc disk with the specified wwn iscsi:///alias=oracle zone root@0 - lun 0 of an iscsi disk with the specified alias. iscsi:///target=iqn.1986-03.com.sun:02:38abfd16-78c5-c58e-e629-ea77a33c6740 - lun 0 of an iscsi disk with the specified target id. ---------- C.1.iii Zoneadm(1m) install When a zone is installed via the zoneadm(1m) "install" subcommand, the zones subsystem will first verify that any required so-uris exist and are accessible. If an so-uri points to a plain file (or a file on an nfs server), and the file object does not exist, the object will be created with the install-size that was specified via zonecfg(1m). If the so-uri does not exist and an install-size was not specified via zonecfg(1m) an error will be generated and the install will fail. If the so-uri points to a vdisk, the vdisk must have been previously created using vdiskadm(1m). If an so-uri points to an explicit nfs server, the zones framework will need to mount the nfs filesystem containing storage object. The nfs server share containing the specified object will be mounted at: /var/zones/nfsmount/<host>/<nfs-share-name> If an so-uri points to a fibre channel lun, the zones subsystem will verify that the specified wwn corresponds to a global zone accessible fibre channel disk device. If an so-uri points to an iSCSI target or alias, the zones subsystem will verify that the iSCSI device is accessible on the local system. If an so-uri points to a static iSCSI target and that target is not already accessible on the local host, then the zones subsystem will enable static discovery for the local iSCSI initiator and attempt to apply the specified static iSCSI configuration. If the iSCSI target device is not accessible then the install will fail. Once a zones install has verified that any required so-uri exists and is accessible, the zones subsystem will need to initialise the so-uri. In the case of a path or nfs path, this will involve creating a zpool within the specified file. In the case of a vdisk, fibre channel lun, or iSCSI lun, this will involve creating a EFI/GPT partition on the device which uses the entire disk, then a zpool will be created within this partition. For data protection purposes, if a storage object contains any pre-existing partitions, zpools, or ufs filesystems, the install will fail with an appropriate error message. To continue the installation and overwrite any pre-existing data, the user will be able to specify a new '-f' option to zoneadm(1m) install. (This option mimics the '-f' option used by zpool(1m) create.) If zpool-preserve is set to true, then before initialising any target storage objects, the zones subsystem will attempt to import a pre-existing zpool from those objects. This will allow users to pre-create a zpool with custom creation time options, for use with zones. To successfully import a pre-created zpool for a zone install, that zpool must not be attached. (Ie, any pre-created zpool must be exported from the system where it was created before a zone can be installed on it.) Once the zpool is imported the install process will check for the existence of a /ROOT filesystem within the zpool. If this filesystem exists the install will fail with an appropriate error message. To continue the installation the user will need to specify the '-f' option to zoneadm(1m) install, which will cause the zones framework to delete the pre-existing /ROOT filesystem within the zpool. (This is done because during install the zones root filesystem will be created under /ROOT. See [07] of more details.) The newly created or imported root zpool will be named after the zone to which it is associated, with the assigned name being "<zonename>_rpool". This zpool will then be mounted on the zones zonepath and then the install process will continue normally[07]. XXX: use altroot at zpool creation or just manually mount zpool? If the user has specified a "zpool" resource, then the zones framework will configure, initialize, and/or import it in a similar manner to a zpool specified by the "rootzpool" resource. The key differences are that the name of the newly created or imported zpool will be "<zonename>_<name>". The specified zpool will also have the zfs "zoned" property set to "on", hence it will not be mounted anywhere in the global zone. XXX: do we need "zpool import -O file-system-property=" to set the zoned property upon import. Once a zone configured with a so-uri is in the installed state, the zones framework needs a mechanism to mark that storage as in use to prevent it from being accessed by multiple hosts simultaneously. The most likely situation where this could happen is via a zoneadm(1m) attach on a remote host. The easiest way to achieve this is to keep the zpools associated with the storage imported at all times, and leverage the existing zpool support for detecting and preventing multi-host access. So whenever a global zone boots and the zones smf service runs, it will attempt to configure and import any shared storage objects associated with installed zones. It will then continue to behave as it does today and boot any installed zones that have the autoboot property set. If any shared storage objects fail to configure or import, then: - the zones associated with the failed storage will be transitioned to the "configured" state. - an error message will be emitted to the zones smf log file. - after booting any remaining installed zones that have autoboot set to true, the zones smf service will enter the "maintenance" state, there by prompting the administrator to look at the zones smf log file. After fixing any problems with shared storage accessibility, the admin should be able to simply re-attach the zone to the system. Currently the zones smf service is dependent upon multi-user-server, so all networking services required for access to shared storage should be properly configured well before we try to import any shared storage associated with zones. On system shutdown, the zones system will NOT export zpools contained within storage object used by the zone. Zpools contained within storage objects assigned to installed zones will only be exported during zone detach. More details about the behaviour of zone detach is provided below. ---------- C.1.iv Zoneadm(1m) attach The zoneadm(1m) attach operation moves a zone from the configured to the installed state. This operation will behave similarly to to a zoneadm(1m) install wrt so-uri management. One key difference between attach and install is that during an attach, any missing storage objects will not be automatically created and instead the attach will fail. Once all the storage objects associated with an attaching zone are configured and accessible, the attach operation will attempt to import and mount the zpools contained within those storage objects. If zfs detects that any zpools are in use by another host the attach will fail. A new '-f' option will be added to zoneadm(1m) which will allow the user to force import and mount any zpools which appear to still be in use. (once again, this option mimics the '-f' option used by zpool(1m) import.) Currently, when a zone is attached to a system a software inventory check is done to verify that the contents of the zone are in sync with the global zone. If they are then the zone is successfully attached. If the contents are older than what is present in the global zone, then the attach fails unless the user specifies the "-u" update option. If the contents of the zone are newer than what is in the global zone then the attach will fail. Encapsulated zones within zpools changes the behaviour of attach slightly because if the zone was created on a host with newer global zone bits, it's possible that the zpool/zfs filesystem versions associated with that zpool may be newer than what the host supports. If this is the case we will be unable to import the zone to check it's software contents. In practice this is not a problem because we know that if the zpool/zfs versions used by an encapsulated zone are later than that supported by the global zone, the software contents of that zone are also guaranteed to be later than what we have in our global zone, so the attach would fail regardless. In the case of older zpool/zfs encapsulated zpool versions, these can be imported without a problem and the version numbers will remain unchanged by the attach operation. ---------- C.1.v Zoneadm(1m) boot The "dataset" property within a "rootzpool" is designed to provide a convenient mechanism for zones to store data within the root zpool, but outside of the /ROOT filesystem (which is subject to snapshotting and cloning during boot environment management operations). To keep things simple, the dataset property can only specify a single path component. (ie, it can not contain any '/' characters.) If the user has specified the "dataset" property for a "rootzpool" resource, then when the zone is booted the framework will check for the presence of a zfs filesystem named /dataset/<dataset> within the root zpool. If no such filesystem exists it will be created. If this zfs filesystem is created by the zones framework, it will have the zfs mountpoint property set to none. This filesystem will then be be delegated to the zone as if a zonecfg(1m) "dataset" resource with a name property value set to "<zonename>_rpool/dataset/<dataset>" existed. For example, if an admin wanted to configure a zone contained within a single storage object, but still have a separate dataset where they can manage snapshots and clones of their data independently of their root filesystem and software, then they could create a configuration as follows: ---8<--- zonecfg -z ibis ... add rootzpool set src=iscsi:///alias=ibis zone@0 set dataset=oracle_data end ---8<--- once this zone was booted, the zone would have access to the following zfs dataset: ibis_rpool/dataset/oracle_data, and it could mount, snapshot, and clone this dataset. All independently of any zone ROOT dataset snapshots and clones created by system management tools, image-updates, etc. If a zone has any "zpool" resources specified, when the zone is booted those zpools will be delegated to the zone. ---------- C.1.vi Zoneadm(1m) detach The zoneadm(1m) detach operation will be enhanced so that when detaching a zone from a system, any zpools residing in storage objects associated with the detaching zone will be exported. This will allow the administrator to attach the zone on another host without having to specify the force flag ('-f') to zoneadm(1m) attach. Also, if any static iSCSI storage objects are associated with the zone, the iSCSI initiator configuration for those targets will be removed. (Although iSCSI initiator static discovery will remain enabled.) ---------- C.1.vii Zoneadm(1m) uninstall If a user initiates a zoneadm(1m) uninstall operation, then for each zpool specified via a "rootzpool" or "zpool" resource, if the "zpool-preserve" property is set to false, the zpool contained within the specified storage object will be destroyed. If the "zpool-preserve" property is set to true, then for a "rootzpool" resource only the /ROOT filesystem (and any of it's descendents) within the root zpool will be destroyed, and then all the zones zpools will be exported. After destroying or exporting the zpool, any associated storage object will be unconfigured as described in the zoneadm(1m) detach section above. ---------- C.1.viii Zoneadm(1m) clone Normally when cloning a zone which lives on a zfs filesystem the zones framework will take a zfs(1m) snapshot of the source zone and then do a zfs(1m) clone operation to create a filesystem for the new zone which is being instantiated. This works well when all the zones on a given system live on local storage in a single zfs filesystem, but this model doesn't work well for zones with encapsulated roots. First, with encapsulated roots each zone has it's own zpool, and zfs(1m) does not support cloning across zpools. Second, zfs(1m) snapshotting/cloning within the source zpool and then mounting the resultant filesystem onto the target zones zoneroot would introduce dependencies between zones, complicating things like zone migration. Hence, for cloning operations, if the source zone has an encapsulated root, zoneadm(1m) will not use zfs(1m) snapshot/clone. Currently zoneadm(1m) will fall back to the use of find+cpio to clone zones if it is unable to use zfs(1m) snapshot/clone. We could just fall back to this default behaviour for encapsulated root zones, but find+cpio are not error free and can have problem with large files. So we propose to update zoneadm(1m) clone to detect when both the source and target zones are using separate zfs filesystems, and in that case attempt to use zfs send/recv before falling back to find+cpio. Today, the zoneadm(1m) clone operations ignores any additional storage (specified via the "fs", "device", or "dataset" resources) that may be associated with the zone. Similarly, the clone operation will ignore additional storage associated with any "zpool" resources. Since zoneadm(1m) clone will be enhanced to support cloning between encapsulated root zones and un-encapsulated root zones, zoneadm(1m) clone will be documented as the recommended migration mechanism for users who which to migrate existing zones from one format to another. ---------- C.1.ix Zoneadm(1m) move Since an installed zone with a "rootzpool" resource will have zfs datasets mounted on it's zonepath, the zoneadm(1m) move subcommand will have to handle unmounting and remounting the "rootzpool" in the process of doing the move operation. ---------- C.1.x Zonecfg(1m) misc changes Currently renaming of a zone is done via zonecfg(1m) by setting the zonename property to the new desired zone name. This operation can be done while the zone is in the "configured" or "installed" state. This presents a problem for installed zones which have a "rootzpool" or "zpool" resource, since these zones zones have associated zpools and the names of these zpools are dependent upon the zone's name. Hence, zonecfg(1m) will need to be modified to prevent the renaming of installed installed zones which have a "rootzpool" or "zpool" resource. zonecfg(1m). To rename these zones, the administrator will need to detach the zone via zoneadm(1m), rename it via zonecfg(1m), and subsequently re-attach the zone via zoneadm(1m). Another non-obvious impact upon zonecfg(1m) operation is that since "rootzpool" or "zpool" resource are only configured during zone install and attach, it will not be possible to add, remove, or modify "rootzpool" or "zpool" resource for an installed zone. Once again, to change these resources the admin will need to detach and re-attach the zone. ---------- C.2 Storage object uid/gid handling One issue faced by all VTs that support shared storage is dealing with file access permissions of storage objects accessible via NFS. This issue doesn't affect device based shared storage, or local files and vdisks, since these types of storage are always accessible, regardless of the uid of the access process (as long as the accessing process has the necessary privileges). But when accessing files and vdisk via NFS, the accessing process can not use privileges to circumvent restrictive file access permissions. This issue is also complicated by the fact that by default most NFS server will map all accesses by remote root user to a different uid, usually "nobody". (a process known as "root squashing".) We propose multiple mechanisms for avoiding problems caused by root squashing. If the optional storage object "user" parameter has been specified, then the zones framework will assume the uid of the specified user when attempting to create or access the storage object via nfs. The "user" parameter overrides all the other uid handling mechanism described below. If a file or vdisk storage object exists on an nfs server, the framework will temporarily switch its uid and gid to match the owner and group of the file/vdisk and ensure that the object is readable and writable by it's owner (updating the permissions if necessary) If a file storage object doesn't exist on an nfs server, the framework will temporarily switch it's uid and gid to match the owner and group of the last path element in the storage object that does exist. It will then ensure that the last path component is writable by it's owner (updating the permissions if necessary) and create the subsequent path elements (with permissions 0600 for files and 0700 for directories). Finally, if a storage object doesn't exist and the framework attempts to create that object (as described above), only to discover that the subsequently created objects uid doesn't match the current uid, then the framework will destroy the object and generate an error indicating that root-squashing has been detected. The user can resolve this error multiple ways: by disabling root-squashing, by specifying a "user" parameter, or by changing the ownership of the directory which will contain the storage objects. ---------- C.3 Taskq enhancements The integration of Duckhorn[08] greatly simplifies the management of cpu resources assigned to zone. This management is partially implemented through the use of dynamic resource pools, where zones and their associated cpu resources can both be bound to a pool. Internally, zfs has worker threads associated with each zpool. These are kernel taskq threads which can run on any cpu which has not been explicitly allocated to a cpu set/partition/pool. So today, for any zones living on zfs filesystems, and running in a dedicated cpu pool, any zfs disk processing associated with that zone is not done by the cpus bound to that zones pool. Essentially all the zones zfs processing is done for "free" by the global zone. With the introduction of zpools encapsulated within storage objects, which are themselves associated with specific zones, it would be desirable to have the zpool worker threads bound to the cpus currently allocated to the zone. Currently, zfs uses taskq threads for each zpool, so one way of doing this would be to introduce a mechanism that allows for the binding of taskqs to pools. Hence we propose the following new interfaces: zfs_poolbind(char *, poolid_t); taskq_poolbind(taskq_t, poolid_t); When a zone, which is bound to a pool, is booted, the zones framework will call zfs_poolbind() for each zpool associated with an encapsulated storage object bound to the zone being booted. Zfs will in turn use the new taskq pool binding interfaces to bind all it's taskqs to the specified pools. This mapping is transient and zfs will not record or persist this binding in any way. The taskq implementation will be enhanced to allow for binding worker threads to a specific pool. If taskqs threads are created for a taskq which is bound to a specific pool, those new thread will also inherit the same pool bindings. The taskq to pool binding will remain in effect until the taskq is explicitly rebound or the pool to which it is bound is destroyed. ---------- C.4 Zfs enhancements In addition to the zfs_poolbind() interface proposed above. The zpool(1m) "import" command will need to be enhanced. Currently the zpool(1m) import by default scans all storage devices on the system looking for pools to import. The caller can also use the '-d' option to specify a directory within which the zpool(1m) command will scan for zpools that may be imported. This scanning involves sampling many objects. When dealing with zpools encapsulated in storage objects, this scanning is unnecessary since we already know the path to the objects which contains the zpool. Hence, the '-d' option will be enhanced to allow for the specification of a file or device. The user will also be able to specify this option multiple times, in case the zpool spans multiple objects. ---------- C.5 Lofi and lofiadm(1m) enhancements Currently, there is no way for a global zone to access the contents of a vdisk. Vdisk support was first introduced in VirtualBox. xVM then adopted the VirtualBox code for vdisk support. With both technologies, the only way to access the contents of a vdisk is to export it to a VM. To allow zones to use vdisk devices we propose to leverage the code introduced by by xVM by incorporating it into lofi. This will allow any solaris system to access the contents of vdisk devices. The interface changes to lofi to allow for this are fairly straightforward. A new '-l' option will be added to the lofiadm(1m) "-a" device creation mode. The '-l' option will indicate to lofi that the new device should have a label associated with it. Normally lofi device are named /dev/lofi/<I> and /dev/rlofi/<I>, where <I> is the lofi device number. When a disk device has a label associated with it, it exports many device nodes with different names. Therefore lofi will need to be enhanced to support these new device names, which multiple nodes per device. These new names will be: /dev/lofi/dsk<I>/p<j> - block device partitions /dev/lofi/dsk<I>/s<j> - block device slices /dev/rlofi/dsk<I>/p<j> - char device partitions /dev/rlofi/dsk<I>/s<j> - char device slices Lofi will also be enhanced to support accessing vdisks in addition to normal files. Accessing a vdisk via lofi will be no different from accessing a disk encapsulated within a file as described above with the -l option. The lofi '-a' option will be enhanced to allow for the automatic detection of vdisk targets on the lofi command line. Since all vdisks represent actual disks they all contain a partition/label data, hence when if a vdisk is detected on the command line, the '-l' flag is automatically implied. The vdisk formats that will be supported by lofi are whatever vdisk formats happen to be supported by xVM at the time of integration. Since the implementation between lofi and xVM will be shared, as new vdisk format support is added to xVM, it should be immediately supportable via lofi as well. In many cases, vdisk formats may provide their own management features such as snapshotting, compression, encryption, etc. As such, the lofi vdisk support exists purely to access the contents of vdisks. Hence, vdisk based lofi devices will not support other lofi options such as encryption ('-c') and compression ('-C' / '-U'). The current xVM implementation for accessing vdisks involves two drivers and a userland utility. A "frontend" driver runs inside a VM and it exports normal solaris disk interface. It takes IO requests to these disks and transmits them, via a ring buffer, to the "backend" driver running in the global zone. The backend driver then maps these ring requests into a dedicated vdisk process (there is one such process for every vdisk), and this process translates these ring requests into access to a vdisk of the requested format. Given all this existing xVM functionality, the most straightforward way to support vdisk from within lofi would be to leverage the xVM implementation. This will involve re-factoring the existing xVM code, thereby allowing lofi to utilise the "frontend" code which translates strategy io requests into ring buffer requests, and also the "backend" code which exports the ring buffer to userland. The unchanged xVM userland vdisk utility can then be used to map ring buffer requests to the actual vdisk storage. Currently this utility is only available on x86, but since lofi is a cross-platform utility, this proposal will require the delivery of this utility on both sparc and x86. This utility is currently delivered in an xVM private directory, /usr/lib/xen/bin/vdisk. Given that lofi is a more general and cross platform utility as compared to xVM, and also given that that we don't expect users to access the vdisk management utilities directly, we propose to move the vdisk application to /usr/lib/lofi/bin/vdisk. For RAS purposes, we will need to ensure that this vdisk utility is always running. Hence we will introduce a new lofi smf service svc:/system/lofi:default, which will start a new /usr/lib/lofi/lofid daemon, which will manage the starting, stopping, monitoring, and possible re-start of the vdisk utility. Re-starts of vdisk utility should be transparent (aside from a short performance hiccup) to any zones accessing those vdisks. By default this service will be disabled. If a lofi vdisk device is created, this service will be temporarily enabled. When the last vdisk based lofi device is destroyed, this service will disable itself. XXX: what to do about disk geometry assignment? sigh. Here's some examples of how this lofi functionality could be used (outside of the zone framework). If an admin wanted to access a disk embedded within a plain file then they could run the following command: lofiadm -a -l /export/xvm/vm1.disk If an admin wanted to access a vdisk (which always implicitly has a disk embedded within it) they could run the following command: lofiadm -a /export/xvm/vm1.vmdk In both the examples above, if there were no previously configured lofi devices on the system, the following new lofi devices would be created: /dev/lofi/dsk0/p# - for # == 0 - 4 /dev/lofi/dsk0/s# - for # == 0 - 15 /dev/rlofi/dsk0/p# - for # == 0 - 4 /dev/rlofi/dsk0/s# - for # == 0 - 15 By default, format(1m) will not list these devices in it's output. But users will be able to treat these devices like regular disks and pass their names to utilities like fdisk(1m), format(1m), prtvtoc(1m), fmthard(1m), zpool(1m), etc. ---------- C.6 Performance considerations As previously mentioned, this proposal primarily simplifies the process of configuring zones on shared storage. In most cases these proposed configurations can be created today, but no one has actually verified that these configurations perform acceptably. Hence, in conjunction with providing functionality to simplify the setup of these configs, we also need to be quantifying their performance to make sure that none of the configurations suffer from gross performance problems. The most straightforward configurations, with the least possibilities for poor performance, are ones using local devices, fibre channel luns, and iSCSI luns. These configuration should perform identically to the configurations where the global zone uses these objects to host zfs filesystems without zones. Additionally, the performance of these configurations will mostly be dependent upon the hardware associated with the storage devices. Hence the performance of these configuration is for the most part uninteresting and performance analysis of these configuration can by skipped. Looking at the performance of storage objects which are local files or nfs files is more interesting. In these cases the zpool that hosts the zone will be accessing it's storage via the zpool vdev_file vdev_ops_t interface. Currently, this interface doesn't receive as much use and performance testing as some of the other zpool vdev_ops_t interfaces. Hence it will worthwhile to measure the performance of a zpool backed by a file within another zfs filesystem. Likewise we will want to measure the performance of a zpool backed by a file on an NFS filesystem. Finally, we should compare these two performance points to a zone which is not encapsulated within a zpool, but is instead installed directly on a local zfs filesystem. (These comparisons are not really that interesting when dealing with block device based storage objects.) We will also want to determine if there are any specific NFS mount options that should be used which could affect performance, for example, should "forcedirectio" be enabled? Currently, while it is very common to deploy large numbers of zfs filesystems, systems with large numbers of zpools are not very common. The solution proposed in this project will likely result in an increase of zpools on systems hosting zones. Hence, we should evaluate the impact of an increasing number of zpools on performance scalability. This could be done by comparing the io performance drop-off of an increasing number of zones hosted multiple zfs filesystems in a single zpool vs zones hosted in separate zpools. Finally, it will be important to do performance measurements for vdisk configurations. These configurations are similar to the local file or nfs configurations, but they will be utilising the vdev_disk backend and they will have an additional layer of indirection through lofi. XXX: impact of multiple zpools on arc and l2 arc? talk to mark maybee. ---------- C.7 Phased delivery Customers have been asking for a simple mechanisms to allow hosting of zones on NFS since the introduction of zones. Hence we'd like to get this functionality into the hands of customers as quickly as possible. Also, the approach taken by this proposal to supporting zones on shared storage is different from what was originally anticipated, hence we'd like to get practical experience with this approach at customer sites asap to determine if there are situations where this approach may not meet their requires. To accelerate the delivery of the previously proposed features, we plan to deliver them in three phases: I - Basic Zone encapsulation support This will involve the introduction of the new "rootzpool" and "zpool" resources and support the "file" and "nfs" type storage objects. It will require implementation of all the proposed zone, zfs, and taskq changes. This phase will not require any lofi changes. II - Zone encapsulation on fc and iSCSI storage. This will provide enhanced so-uri support for fibre channel and iSCSI type storage objects. III - Zone encapsulation on vdisk storage. This will involve implementation of the proposed lofi enhancements and enhancement support for vdisk type storage objects. ---------- C.8 Future work In addition to the proposed work above, there are future enhancements that could be made which would extend the functionality proposed above. These are included here because the features proposed above have been designed with this extensibility in mind. One simple enhancement would be the addition a new "rootzpool/zpool" resource property called "zpool-auto-upgrade". If set to true, whenever a zpool is imported by the zones framework (at install, attach, or boot) the zpool and zfs filesystems would be upgraded to the latest version supported by the global zone. Aside from helping to ensure that zones are using the latest and greatest zpool/zfs features, this feature would help ensure that all the encapsulated zones on a system are running on the same zpool/zfs versions. This is important because zfs send and receive are not guaranteed to be compatible across zpool/zfs versions. So by ensure that all zones are running the latest zpool/zfs versions, we increase the chances of being able to use zfs send/recv for zone cloning. Another possible enhancement to the "rootzpool/zpool" resources would be to allow the specification of multiple so-uris to support more complex root zpool configurations. With the introduction of vdisk support, we will have the ability to access VMs created by other VTs. Using this functionality it would be straightforward to enhance the existing zoneadm(1m) attach p2v functionality to be able to do v2v, where the source system image for installing a zone could be a vdisk created by another VT. Finally, a new "storage" zonecfg(1m) resource could be added to allow for the addition of arbitrary storage objects to zones. This "storage" resource would have the similar properties as a "zpool" resource, along with a few additional properties: storage resource src resource property install-size resource property name resource property locking-required resource property The zones framework would ensure that the specified storage objects were accessible from the global zone, and then it would grant the zone access to the raw disk devices. But global zone disk device names can be different on different host, so if global zone device names were used within the non-global zone, this would negatively impact zone migration since the software within the zone would have to be updated to deal with potentially new device names. To avoid this problems and facilitate zone migration, the disk devices would be mapped into the non-global zone with different names which would be global zone independent. Regardless of the global zone disk device name, from within the non-global zone, the devices would be named: /dev/storage/<name>/p<j> /dev/storage/<name>/s<j> By basing the names of the device as seen from within the zone on the "name" specified in the zonecfg(1m) (instead of the raw device names from the global zone), we can guarantee that these device names will not change when migrating the zones between hosts. One difficulty with allowing the specification of storage objects which don't by default contain a zpools is that we can no longer use zfs to ensure that multiple entities are not accessing these objects at the same time. Hence other mechanisms will need to be used. In the case of fibre channel and iSCSI, we should be able to use SCSI reservations. In the case of file paths we should be able to use standard file locking. In the case of vdisks, some vdisks support meta-data which can be utilised to prevent concurrent access, and if a vdisk format does not allow for this then we will need to fall back to file locking. If for some reason we are unable to do in use detection for a specific storage object, then we could alert the user and refuse to use that storage object unless the user set the optional "locking-required" property to false. ---------- D. INTERFACES Zonecfg(1m): rootzpool committed, resource src committed, resource property install-size committed, resource property zpool-preserve committed, resource property dataset committed, resource property zpool resource src resource property install-size resource property zpool-preserve resource property name resource property Zoneadm(1m): install -f committed, optional flag attach -f committed, optional flag Zones misc: /var/zones/nfsmount/<host>/<nfs-share-name> project private, nfs mount point Taskq pool binding: taskq_poolbind(taskq_t, poolid_t) consolidation private Zfs pool binding: zfs_poolbind(char *, poolid_t) consolidation private Lofiadm(1m): -a -l committed, optional flag -a -v <vdisk-format> committed, optional flag Lofi misc: svc:/system/lofi:default project private /lib/lofi/lofid project private /lib/lofi/vdisk consolidation private /w contract for xVM ---------- E. ABBREVIATIONS VDI - VirtualBox Virtual HDD VHD - Microsoft Virtual Hard Disk VM - Virtual Machine VMDK - VMWare Virtual Machine Disk VT - Virtualization Technology ---------- F. FOOTNOTES / REFERENCES -- 00 - Blogs and emails describing custom configurations used to host zones on shared storage: June 2005 Containers on NFS? http://blogs.sun.com/jph/entry/containers_on_nfs February 2008 The quick & dirty guide to zones on iSCSI LUNs http://opensolaris.org/jive/thread.jspa?messageID=226951 April 2008 ZoiT: Solaris Zones on iSCSI Targets (aka NAC: Network-Attached Containers) http://blogs.sun.com/JeffV/entry/zoit_solaris_zones_on_iscsi -- 01 - For the purposes of this document, the term storage object refers to any device or file which can be used to store data. These "objects" can take the form of files on a local filesystem, files on a remote filesystem accessible via NFS, CIFS, etc, local disk devices, FC disk devices, iSCSI target devices, -- 02 - Each VT has a different name for the zones concept of the "global zone". With LDOMs we have the "control domain", with xVM we have "dom0", with VirtualBox we have the "host domain". For the purposes of this document the "global zone" refers to the OS entity which allocates resources to and has control over the state of VMs. For simplicity, this document will always just refer to the "global zone" in place of all these other terms. -- 03 - Complete so-uri ABNF syntax definition: so-uri = path-uri / nfs-uri / vpath-uri / vnfs-uri / fc-uri / iscsi-uri path-uri = "path://" file-absolute file-absolute = "/" *( segment "/" ) segment-nz ; Since file-absolute is always the last component ; in a uri reserved characters do not need to be ; percent encoding. To simplify path management ; we will also not permit '/./' or '/../' segments. nfs-uri = "nfs://" hostport "/" file-absolute ; Defined in RFC 2224 [05] hostport = host [ ":" port ] vpath-uri = "vpath://" file-absolute vnfs-uri = "vnfs://" host [ ":" port ] "/" file-absolute ; same syntax as nfs-uri fc-uri = "fc:/// wwn [ "@" lun ] wwn = 1000 12HEXDIG / 2 15HEXDIG / 50 14HEXDIG / 60 14HEXDIG ; see http://en.wikipedia.org/wiki/World_Wide_Name iscsi-uri = "iscsi:///" iscsi-alias / "iscsi:///" iscsi-target / "iscsi://" iscsi-static iscsi-alias = "alias=" iscsi-alias-name [ "@" lun ] iscsi-alias-name = 1*255pchar ; Defined in RFC 3720 [06] ; any "@" chars must be percent encoded iscsi-target = "target=" iscsi-target-iqn [ "@" lun ] / "target=" iscsi-target-eui [ "@" lun ] iscsi-target-iqn = "iqn." iqn-date "." reg-name [ ":" 1*pchar ] ; Defined in RFC 3720 [06] ; any "@" chars must be percent encoded iqn-date = 4DIGIT "-" "0" %x31-39 ; "XXXX-01" - "XXXX-09" / 4DIGIT "-" "1" %x30-32 ; "XXXX-10" - "XXXX-12" iscsi-target-eui = XXX ; Defined in RFC 3720 [06] ; any "@" chars must be percent encoded iscsi-static = hostport "/" [ "tpgt=" iscsi-tpgt "/" ] iscsi-target iscsi-tpgt = DIGIT ; 0-9 / %x31-39 1*3DIGIT ; 10-9999 / %x31-35 4DIGIT ; 10000-59999 / "6" %x30-34 3DIGIT ; 60000-64999 / "65" %x30-34 2DIGIT ; 65000-65499 / "655" %x30-32 1DIGIT ; 65500-65529 / "6553" %x30-35 ; 65530-65535 lun = DIGIT ; 0-9 / %x31-39 1*3DIGIT ; 10-9999 / "1" %x30-35 3DIGIT ; 10000-15999 / "16" %x30-32 2DIGIT ; 16000-16299 / "163" %x30-37 1DIGIT ; 16300-16379 / "1638" %x30-33 ; 16380-16383 DIGIT = Defined in RFC 3986 [04] HEXDIG = Defined in RFC 3986 [04] segment-nz = Defined in RFC 3986 [04] segment = Defined in RFC 3986 [04] host = Defined in RFC 3986 [04] port = Defined in RFC 3986 [04] -- 04 - RFC 3986: Uniform Resource Identifier (URI): Generic Syntax http://www.ietf.org/rfc/rfc3986.txt http://www.websitedev.de/temp/rfc3986-check.html.gz -- 05 - RFC 2224 NFS URL Scheme http://www.ietf.org/rfc/rfc2224.txt -- 06 - RFC 3720: Internet Small Computer Systems Interface (iSCSI) -- 07 - Zones/SNAP Design - 8/25/2008 http://www.opensolaris.org/jive/thread.jspa?messageID=272726񂥖 -- 08 - PSARC/2006/496 Improved Zones/RM Integration http://arc.opensolaris.org/caselog/PSARC/2006/496 -------------------------------------------------------------------------------


| DOSE: |
500 mg |
insufflated |
Cocaine |
(daily) |
I found myself in front of the DHR, explaining me that one of my 'workmates' had accused me of using cocaine the previous night. Being a Poker player, I volunteered to pass a test, but it was 'not necessary'. I got fired anyway, just like in the movies, with the security guard behind me to collect my stuff. Nevertheless, I had to justify the 'incident' to more people than just the DHR, so the test was 'socially' inevitable.
Last use: Sunday night. (snorted about 0.5-0.7g), with drinks.
Before: Consistently during the previous 2 weeks 1/2, about 0.5/day.
I read everything I could find about testing and how to 'clean up'. I ate double meals 2 days on a row, ran as much as possible to increase the metabolism (I read that could increase it by 1000%!). I went to the sauna to burn toxins and tested myself on 'watering' to see if that could eventually help but I desisted on that path thinking about the 'counter-test' to check a sample for dilution.
Test day: Wednesday (about 63hrs after last use.) My 'sample' was collected at a regular doctor's office, not in a lab, where it was way easier to 'cut' or cheat on the test. On the morning, I did drink a bit more liquid than usual, but just enough to go a couple of times an clean up the 'sample' a little bit.. Then in place (following something I read), I filled it normally, then before I finish, while washing my hands, in a quick move I filled about 1/4 of the cup with temperate water.. (yes! it was just a regular bathroom! they let the door open, waiting outside without looking inside). The test was looking for the 7 standard drugs traces (including the coke metabolite.)
Four days later: Negative, Sample normal (not diluted)
Considering the 'consistent' period of use and the borderline detection time, I wasn't sure it was going to work, but it did.
Experience Reports are the writings and opinions of the individual authors who submit them.
Some of the activities described are dangerous and/or illegal and none are recommended by Erowid.


Simple Route Rules
This section demonstrates how to use various traffic management capabilities of Istio.
We will show you how to route requests dynamically to multiple versions of a microservice.
Deploy recommendation:v2
kubectl apply -f manifests/kubernetes/recommendation-v2.yml
Wait for those pods to show "2/2", the istio-proxy/envoy sidecar is part of that pod
NAME READY STATUS RESTARTS AGE
customer-3600192384-fpljb 2/2 Running 0 17m
preference-243057078-8c5hz 2/2 Running 0 15m
recommendation-v1-60483540-9snd9 2/2 Running 0 12m
recommendation-v2-2815683430-vpx4p 2/2 Running 0 15s
and test the customer endpoint:
curl $customer
you would likely see "customer => preference => recommendation v1 from '99634814-d2z2t': 3"
, where '99634814-d2z2t' is the pod running v1
and the 3
is basically the number of times you hit the endpoint.
Run again the command:
curl $customer
you would likely see "customer => preference => recommendation v2 from '2819441432-5v22s': 1"
as by default you get round-robin load-balancing when there is more than one Pod behind a Service
Send several requests to see their responses:
while true; do curl $customer; sleep .5; done
The default Kubernetes behavior is to round-robin load-balance across all available pods behind a single Service. Add another replica of recommendation-v2 Deployment.
kubectl scale --replicas=2 deployment/recommendation-v2
Now, you will see two requests into the v2 and one for v1.
customer => preference => recommendation v1 from '2819441432-qsp25': 29
customer => preference => recommendation v2 from '99634814-sf4cl': 37
customer => preference => recommendation v2 from '99634814-xq3c5': 38
Scale back to a single replica of the recommendation-v2 Deployment
kubectl scale --replicas=1 deployment/recommendation-v2
Changing Istio Routings
Before you can use Istio to control version routing, you need to define the available versions, called subsets, in DestinationRule.
kind: DestinationRule
metadata:
name: recommendation
spec:
host: recommendation
subsets:
- name: version-v1
labels:
version: v1
- name: version-v2
labels:
version: v2
Run the following command to create default destination rules to send traffic to versions v1
and v2
of recommandation service.
kubectl apply -f manifests/istio/routing-simple/recommendation-destination-rule-v1-v2.yml
Wait a few seconds for the destination rules to propagate.
You can display the created destination rule with the following command:
kubectl get destinationrules recommendation -o yaml
To display all destination rules :
kubectl get destinationrules -o yaml
Route all the traffic to recommendation:v2
To route to one version only, you apply virtual services that set the default version for the microservices. In this case, the virtual services will route all traffic to v2 of recommendation microservice.
kind: VirtualService
metadata:
name: recommendation
spec:
hosts:
- recommendation
http:
- route:
- destination:
host: recommendation
subset: version-v2
weight: 100
kubectl apply -f manifests/istio/routing-simple/recommendation-virtual-service-v2.yml
curl $customer
you should only see v2 being returned
Route all the traffic to recommendation:v1
kubectl apply -f manifests/istio/routing-simple/recommendation-virtual-service-v1.yml
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: recommendation
spec:
hosts:
- recommendation
http:
- route:
- destination:
host: recommendation
subset: version-v1
Route the traffic to both versions of recommendation: v1 and v2
By simply removing the virtual service
kubectl delete virtualservice recommendation
and you should see the default behavior of load-balancing between v1 and v2
curl $customer
Canary deployment: Split traffic between v1 and v2
Canary Deployment scenario: push v2 into the cluster but slowly send end-user traffic to it, if you continue to see success, continue shifting more traffic over time
kubectl get pods -l app=recommendation
NAME READY STATUS RESTARTS AGE
recommendation-v1-3719512284-7mlzw 2/2 Running 6 2h
recommendation-v2-2815683430-vn77w 2/2 Running 0 1h
Create the virtualservice
that will send 90% of requests to v1 and 10% to v2
kubectl apply -f manifests/istio/routing-simple/recommendation-virtual-service-v1_and_v2.yml
kind: VirtualService
metadata:
name: recommendation
spec:
hosts:
- recommendation
http:
- route:
- destination:
host: recommendation
subset: version-v1
weight: 90
- destination:
host: recommendation
subset: version-v2
weight: 10
and send in several requests:
while true; do curl $customer; sleep .5; done
In another terminal, change the mixture to be 75/25
kubectl apply -f manifests/istio/routing-simple/recommendation-virtual-service-v1_and_v2_75_25.yml


This page explains how to interpret the graphs that are generated by doxygen.
Consider the following example:
This will result in the following graph:
The boxes in the above graph have the following meaning:
- A filled gray box represents the struct or class for which the graph is generated.
- A box with a black border denotes a documented struct or class.
- A box with a grey border denotes an undocumented struct or class.
- A box with a red border denotes a documented struct or class forwhich not all inheritance/containment relations are shown. A graph is truncated if it does not fit within the specified boundaries.
The arrows have the following meaning:
- A dark blue arrow is used to visualize a public inheritance relation between two classes.
- A dark green arrow is used for protected inheritance.
- A dark red arrow is used for private inheritance.
- A purple dashed arrow is used if a class is contained or used by another class. The arrow is labeled with the variable(s) through which the pointed class or struct is accessible.
- A yellow dashed arrow denotes a relation between a template instance and the template class it was instantiated from. The arrow is labeled with the template parameters of the instance.


My Development Environment
Editor Preference - Visual Studio Code
- Free
- Open Source
- Runs Everywhere
FTP Client - Really?
- Yes - I insist!
- FileZilla - Just get it
- No editing files using the dashboard editor
define('DISALLOW_FILE_EDIT',true);
Add to
wp-config.php
above the
/* That's all, stop editing! Happy blogging. */
line.


StateInUSA
public enum StateInUSA : String, CaseIterable, Decodable
Constituent political entity in the United States
-
Alabama
Declaration
Swift
case alabama = "AL"
-
Alaska
Declaration
Swift
case alaska = "AK"
-
Arizona
Declaration
Swift
case arizona = "AZ"
-
Arkansas
Declaration
Swift
case arkansas = "AR"
-
California
Declaration
Swift
case california = "CA"
-
Colorado
Declaration
Swift
case colorado = "CO"
-
Connecticut
Declaration
Swift
case connecticut = "CT"
-
Delaware
Declaration
Swift
case delaware = "DE"
-
Florida
Declaration
Swift
case florida = "FL"
-
Georgia
Declaration
Swift
case georgia = "GA"
-
Hawaii
Declaration
Swift
case hawaii = "HI"
-
Idaho
Declaration
Swift
case idaho = "ID"
-
Illinois
Declaration
Swift
case illinois = "IL"
-
Indiana
Declaration
Swift
case indiana = "IN"
-
Iowa
Declaration
Swift
case iowa = "IA"
-
Kansas
Declaration
Swift
case kansas = "KS"
-
Kentucky
Declaration
Swift
case kentucky = "KY"
-
Louisiana
Declaration
Swift
case louisiana = "LA"
-
Maine
Declaration
Swift
case maine = "ME"
-
Maryland
Declaration
Swift
case maryland = "MD"
-
Massachusetts
Declaration
Swift
case massachusetts = "MA"
-
Michigan
Declaration
Swift
case michigan = "MI"
-
Minnesota
Declaration
Swift
case minnesota = "MN"
-
Mississippi
Declaration
Swift
case mississippi = "MS"
-
Missouri
Declaration
Swift
case missouri = "MO"
-
Montana
Declaration
Swift
case montana = "MT"
-
Nebraska
Declaration
Swift
case nebraska = "NE"
-
Nevada
Declaration
Swift
case nevada = "NV"
-
New Hampshire
Declaration
Swift
case newHampshire = "NH"
-
New Jersey
Declaration
Swift
case newJersey = "NJ"
-
New Mexcio
Declaration
Swift
case newMexico = "NM"
-
New York
Declaration
Swift
case newYork = "NY"
-
North Carolina
Declaration
Swift
case northCarolina = "NC"
-
North Dakota
Declaration
Swift
case northDakota = "ND"
-
Ohio
Declaration
Swift
case ohio = "OH"
-
Oklahoma
Declaration
Swift
case oklahoma = "OK"
-
Oregon
Declaration
Swift
case oregon = "OR"
-
/ Pennsylvania
Declaration
Swift
case pennsylvania = "PA"
-
Rhode Island
Declaration
Swift
case rhodeIsland = "RI"
-
South Carolina
Declaration
Swift
case southCarolina = "SC"
-
/ South Dakota
Declaration
Swift
case southDakota = "SD"
-
Tennessee
Declaration
Swift
case tennessee = "TN"
-
Texas
Declaration
Swift
case texax = "TX"
-
Utah
Declaration
Swift
case utah = "UT"
-
Vermont
Declaration
Swift
case vermont = "VT"
-
Virginia
Declaration
Swift
case virgina = "VA"
-
Washington
Declaration
Swift
case washington = "WA"
-
West Virginia
Declaration
Swift
case westVirginia = "WV"
-
Wisconsin
Declaration
Swift
case wisconsin = "WI"
-
Wyoming
Declaration
Swift
case wyoming = "WY"
-
Returns name of the state, e.g. “California” for .california
Declaration
Swift
public var name: String { get }
-
Returns 2 character state code, e.g. “CA” for .california
Declaration
Swift
public var postalAbbreviation: String { get }


Hello world!
This "little" project of mine required much more time and effort than what I had first anticipated.
The whole Luv token idea was at first a fun little exercise to learn more about smart contracts and to (hopefully) make some money.
The thing is that to complete this I ended up learning HTML, CSS, SASS, Javascript, Solidity (and the OpenZeppelin library) as well as using the Embark and Foundation frameworks!..
That was quite a lot to learn!
And yes I had to learn all this because I'm no programmer. I'm just a guy who finished high school last year.
(I'm going to study Mathematics by the way)
In order to go through all those hardships and finish this big project on my own, my goals had to change.
This is no longer just a fun little project. This is my art.
This is my vivid red mark in a mundane and devoid of true love world.
Love is the most important and powerful emotion. (The one that always defeats the bad witch)
You may even say that love is the strongest force in the whole universe.
Considering that, it is a shame that love has been reduced to stuff.
It truly is devastating that love is being related with money; and in general material possessions..
Following that logic, actually turning love into a token and selling it would be the worst.
However, the idea is an ideal irony which is so much needed to wake up people.
Love can't be bought.
Then again... it can.
People forgot how to truly love and instead express their love with money.
That is flawed since love is not a thing; love is an emotion, it's a bond.
The confusion of money with true love leads to multiple fatal errors.
First and foremost, due to that, many are led to believe that love is non-existent...
Moreover, those who are still "believers" are in constant agony since nobody can guarantee that you will keep your love.
Love is not secure nor can you know exactly how much you are loved.
Last but not least, it is an undoubtable fact that
most times people give more for the amount of love that they receive in exchange...
Luv is a fungible token built in the Ethereum blockchain under the ERC20 standard.
The only purpose of Luv is to serve as the token of love; to make transactions of love fair.
By naming it Luv we differentiate it from true love, afterall "Luv is the kind of love you can buy, sell or trade"...
That sets Luv apart from the "pure" emotion and adds some benefits since it's a token in the Ethereum blockchain.
Luv is secured in the immutable blockchain. Nobody can steal your Luv!
It also removes uncertainty of the amount of Luv you possess since it's countable with a precision of 18 decimal digits.
Therefore, by trading Luv utilizing the smart contracts' technology you are guaranteed to receive the amount of Luv you have agreed upon and keep it.
The crowdsale begins at August 20, 2019 12:00 AM GMT.
It ends at January 1st, 2020 12:00 AM GMT.
Luv's initial total supply is 0 LUV. Every time you purchase
Luv with your ethereum
Luv is created, sent to your wallet and the total supply increases.
At first the rate is 1 million LUV/ETH meaning that you get 1 million LUV for 1 ETH.
The rate decreases by 10 for every million Luv purchased, meaning that when the total supply is 1 million LUV
the rate is 999990 LUV/ETH.
Therefore, Luv's price increases as the total supply increases.
There is no hard cap ,however, at 100 Billion LUV the rate will be 0 LUV/ETH so that could be considered the "hard cap" even though there is no limit on the amount of Luv you can buy in one transaction.
As a result theoritically more than 100 Billion LUV could be minted in total despite the fact that it's practically impossible to buy such a great amount of Luv -at once- to go beyond the 100 Billion LUV "hard cap" (or to buy enough Luv at all, once the rate is really low).
All ethereum collected will be the fuel of my life to help me achieve my goals.
One of them is to develop this project even more; to update the UI and add new functionality to the site, that is if Luv is a success...
With your help Luv could be something big, something great.
Also, if I receive a lot of ethereum then I will be able to sustain myself while studying in the university and
fund my next projects; which will be much greater.
Basically it's just me.
January 2019
Development beginning
March 2019
Finished contracts
July 2019
Completed the UI - site
July End 2019
Dapp/Site goes live
August 20th 2019
Launch of crowdsale
January 2020
End of crowdsale