pulsar-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From si...@apache.org
Subject [incubator-pulsar] branch master updated: Make doc image links work when there is a base path. (#2230)
Date Wed, 25 Jul 2018 21:20:40 GMT
This is an automated email from the ASF dual-hosted git repository.

sijie pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/incubator-pulsar.git

The following commit(s) were added to refs/heads/master by this push:
     new fbc12b5  Make doc image links work when there is a base path. (#2230)
fbc12b5 is described below

commit fbc12b51fc7aff878527f6ff8de3213f8f982124
Author: cckellogg <cckellogg@gmail.com>
AuthorDate: Wed Jul 25 14:20:37 2018 -0700

    Make doc image links work when there is a base path. (#2230)
    ### Motivation
    Make images work in the docs when there is a base path. Example can be seen here.
 site2/docs/administration-geo.md                   |  2 +-
 site2/docs/administration-zk-bk.md                 |  2 +-
 site2/docs/cookbooks-encryption.md                 |  4 +--
 site2/docs/cookbooks-tiered-storage.md             |  2 +-
 site2/docs/deploy-bare-metal.md                    |  2 +-
 site2/docs/deploy-dcos.md                          | 38 +++++++++++-----------
 site2/docs/developing-binary-protocol.md           |  8 ++---
 site2/docs/functions-overview.md                   |  6 ++--
 .../getting-started-concepts-and-architecture.md   | 26 +++++++--------
 site2/docs/io-overview.md                          |  2 +-
 site2/docs/security-encryption.md                  |  4 +--
 11 files changed, 48 insertions(+), 48 deletions(-)

diff --git a/site2/docs/administration-geo.md b/site2/docs/administration-geo.md
index 08c7b3e..c505639 100644
--- a/site2/docs/administration-geo.md
+++ b/site2/docs/administration-geo.md
@@ -10,7 +10,7 @@ sidebar_label: Geo-replication
 The diagram below illustrates the process of geo-replication across Pulsar clusters:
-![Replication Diagram](/docs/assets/geo-replication.png)
+![Replication Diagram](assets/geo-replication.png)
 In this diagram, whenever producers **P1**, **P2**, and **P3** publish messages to the topic
**T1** on clusters **Cluster-A**, **Cluster-B**, and **Cluster-C**, respectively, those messages
are instantly replicated across clusters. Once replicated, consumers **C1** and **C2** can
consume those messages from their respective clusters.
diff --git a/site2/docs/administration-zk-bk.md b/site2/docs/administration-zk-bk.md
index cf0eb3a..79ee037 100644
--- a/site2/docs/administration-zk-bk.md
+++ b/site2/docs/administration-zk-bk.md
@@ -329,6 +329,6 @@ PersistencePolicies policies = admin.namespaces().getPersistence(namespace);
 This diagram illustrates the role of ZooKeeper and BookKeeper in a Pulsar cluster:
-![ZooKeeper and BookKeeper](/docs/assets/pulsar-system-architecture.png)
+![ZooKeeper and BookKeeper](assets/pulsar-system-architecture.png)
 Each Pulsar cluster consists of one or more message brokers. Each broker relies on an ensemble
of bookies.
diff --git a/site2/docs/cookbooks-encryption.md b/site2/docs/cookbooks-encryption.md
index 1bf22c9..e11b131 100644
--- a/site2/docs/cookbooks-encryption.md
+++ b/site2/docs/cookbooks-encryption.md
@@ -19,10 +19,10 @@ A message can be encrypted with more than one key.  Any one of the keys
used for
 Pulsar does not store the encryption key anywhere in the pulsar service. If you lose/delete
the private key, your message is irretrievably lost, and is unrecoverable
 ## Producer
-![alt text](/docs/assets/pulsar-encryption-producer.jpg "Pulsar Encryption Producer")
+![alt text](assets/pulsar-encryption-producer.jpg "Pulsar Encryption Producer")
 ## Consumer
-![alt text](/docs/assets/pulsar-encryption-consumer.jpg "Pulsar Encryption Consumer")
+![alt text](assets/pulsar-encryption-consumer.jpg "Pulsar Encryption Consumer")
 ## Here are the steps to get started:
diff --git a/site2/docs/cookbooks-tiered-storage.md b/site2/docs/cookbooks-tiered-storage.md
index 792592e..003cd14 100644
--- a/site2/docs/cookbooks-tiered-storage.md
+++ b/site2/docs/cookbooks-tiered-storage.md
@@ -14,7 +14,7 @@ Tiered storage should be used when you have a topic for which you want to
keep a
 A topic in Pulsar is backed by a log, known as a managed ledger. This log is composed of
an ordered list of segments. Pulsar only every writes to the final segment of the log. All
previous segments are sealed. The data within the segment is immutable. This is known as a
segment oriented architecture.
-![Tiered storage](/docs/assets/pulsar-tiered-storage.png "Tiered Storage")
+![Tiered storage](assets/pulsar-tiered-storage.png "Tiered Storage")
 {% include figure.html src="/img/pulsar-tiered-storage.png" alt="Tiered Storage" width="80"
diff --git a/site2/docs/deploy-bare-metal.md b/site2/docs/deploy-bare-metal.md
index 6fb1f1d..8b3497f 100644
--- a/site2/docs/deploy-bare-metal.md
+++ b/site2/docs/deploy-bare-metal.md
@@ -26,7 +26,7 @@ Each machine in your cluster will need to have [Java 8](http://www.oracle.com/te
 Here's a diagram showing the basic setup:
 In this diagram, connecting clients need to be able to communicate with the Pulsar cluster
using a single URL, in this case `pulsar-cluster.acme.com`, that abstracts over all of the
message-handling brokers. Pulsar message brokers run on machines alongside BookKeeper bookies;
brokers and bookies, in turn, rely on ZooKeeper.
diff --git a/site2/docs/deploy-dcos.md b/site2/docs/deploy-dcos.md
index 62dfd81..64b3d96 100644
--- a/site2/docs/deploy-dcos.md
+++ b/site2/docs/deploy-dcos.md
@@ -48,69 +48,69 @@ This command will deploy Docker container instances in three groups, which
 After executing the `dcos` command above, click on the **Services** tab in the DC/OS [GUI
interface](https://docs.mesosphere.com/latest/gui/), which you can access at [http://m1.dcos](http://m1.dcos)
in this example. You should see several applications in the process of deploying.
-![DC/OS command executed](/docs/assets/dcos_command_execute.png)
+![DC/OS command executed](assets/dcos_command_execute.png)
-![DC/OS command executed2](/docs/assets/dcos_command_execute2.png)
+![DC/OS command executed2](assets/dcos_command_execute2.png)
 ## The BookKeeper group
 To monitor the status of the BookKeeper cluster deployment, click on the **bookkeeper** group
in the parent **pulsar** group.
-![DC/OS bookkeeper status](/docs/assets/dcos_bookkeeper_status.png)
+![DC/OS bookkeeper status](assets/dcos_bookkeeper_status.png)
 At this point, 3 {% popover bookies %} should be shown as green, which means that they have
been deployed successfully and are now running.
-![DC/OS bookkeeper running](/docs/assets/dcos_bookkeeper_run.png)
+![DC/OS bookkeeper running](assets/dcos_bookkeeper_run.png)
 You can also click into each bookie instance to get more detailed info, such as the bookie
running log.
-![DC/OS bookie log](/docs/assets/dcos_bookie_log.png)
+![DC/OS bookie log](assets/dcos_bookie_log.png)
 To display information about the BookKeeper in ZooKeeper, you can visit [http://m1.dcos/exhibitor](http://m1.dcos/exhibitor).
In this example, there are 3 bookies under the `available` directory.
-![DC/OS bookkeeper in zk](/docs/assets/dcos_bookkeeper_in_zookeeper.png)
+![DC/OS bookkeeper in zk](assets/dcos_bookkeeper_in_zookeeper.png)
 ## The Pulsar broker Group
 Similar to the BookKeeper group above, click into the **brokers** to check the status of
the Pulsar brokers.
-![DC/OS broker status](/docs/assets/dcos_broker_status.png)
+![DC/OS broker status](assets/dcos_broker_status.png)
-![DC/OS broker running](/docs/assets/dcos_broker_run.png)
+![DC/OS broker running](assets/dcos_broker_run.png)
 You can also click into each broker instance to get more detailed info, such as the broker
running log.
-![DC/OS broker log](/docs/assets/dcos_broker_log.png)
+![DC/OS broker log](assets/dcos_broker_log.png)
 Broker cluster information in Zookeeper is also available through the web UI. In this example,
you can see that that the `loadbalance` and `managed-ledgers` directories have been created.
-![DC/OS broker in zk](/docs/assets/dcos_broker_in_zookeeper.png)
+![DC/OS broker in zk](assets/dcos_broker_in_zookeeper.png)
 ## Monitor Group
 The **monitory** group consists of Prometheus and Grafana.
-![DC/OS monitor status](/docs/assets/dcos_monitor_status.png)
+![DC/OS monitor status](assets/dcos_monitor_status.png)
 ### Prometheus
 Click into the instance of `prom` to get the endpoint of Prometheus, which is ``
in this example.
-![DC/OS prom endpoint](/docs/assets/dcos_prom_endpoint.png)
+![DC/OS prom endpoint](assets/dcos_prom_endpoint.png)
 If you click that endpoint, you'll see the Prometheus dashboard. The [](
URL will display all the bookies and brokers.
-![DC/OS prom targets](/docs/assets/dcos_prom_targets.png)
+![DC/OS prom targets](assets/dcos_prom_targets.png)
 ### Grafana
 Click into `grafana` to get the endpoint for Grafana, which is `` in this
-![DC/OS grafana endpoint](/docs/assets/dcos_grafana_endpoint.png)
+![DC/OS grafana endpoint](assets/dcos_grafana_endpoint.png)
 If you click that endpoint, you can access the Grafana dashbaord.
-![DC/OS grafana targets](/docs/assets/dcos_grafana_dashboard.png)
+![DC/OS grafana targets](assets/dcos_grafana_dashboard.png)
 ## Run a simple Pulsar consumer and producer on DC/OS
@@ -151,15 +151,15 @@ $ mvn exec:java -Dexec.mainClass="tutorial.ProducerTutorial"
 You can see the producer producing messages and the consumer consuming messages through the
-![DC/OS pulsar producer](/docs/assets/dcos_producer.png)
+![DC/OS pulsar producer](assets/dcos_producer.png)
-![DC/OS pulsar consumer](/docs/assets/dcos_consumer.png)
+![DC/OS pulsar consumer](assets/dcos_consumer.png)
 ### View Grafana metric output
 While the producer and consumer are running, you can access running metrics information from
-![DC/OS pulsar dashboard](/docs/assets/dcos_metrics.png)
+![DC/OS pulsar dashboard](assets/dcos_metrics.png)
 ## Uninstall Pulsar
@@ -168,7 +168,7 @@ You can shut down and uninstall the `pulsar` application from DC/OS at
any time
 1. Using the DC/OS GUI, you can choose **Delete** at the right end of Pulsar group.
-    ![DC/OS pulsar uninstall](/docs/assets/dcos_uninstall.png)
+    ![DC/OS pulsar uninstall](assets/dcos_uninstall.png)
 2. You can use the following command:
diff --git a/site2/docs/developing-binary-protocol.md b/site2/docs/developing-binary-protocol.md
index dfe3365..1dd6c48 100644
--- a/site2/docs/developing-binary-protocol.md
+++ b/site2/docs/developing-binary-protocol.md
@@ -99,7 +99,7 @@ When compression is enabled, the whole batch will be compressed at once.
 After opening a TCP connection to a broker, typically on port 6650, the client
 is responsible to initiate the session.
-![Connect interaction](/docs/assets/binary-protocol-connect.png)
+![Connect interaction](assets/binary-protocol-connect.png)
 After receiving a `Connected` response from the broker, the client can
 consider the connection ready to use. Alternatively, if the broker doesn't
@@ -164,7 +164,7 @@ authorized to publish on the topic.
 Once the client gets confirmation of the producer creation, it can publish
 messages to the broker, referring to the producer id negotiated before.
-![Producer interaction](/docs/assets/binary-protocol-producer.png)
+![Producer interaction](assets/binary-protocol-producer.png)
 ##### Command Producer
@@ -277,7 +277,7 @@ A consumer is used to attach to a subscription and consume messages from
 After every reconnection, a client needs to subscribe to the topic. If a
 subscription is not already there, a new one will be created.
 #### Flow control
@@ -458,7 +458,7 @@ connect to, or a broker hostname to which retry the lookup.
 The `LookupTopic` command has to be used in a connection that has already
 gone through the `Connect` / `Connected` initial handshake.
-![Topic lookup](/docs/assets/binary-protocol-topic-lookup.png)
+![Topic lookup](assets/binary-protocol-topic-lookup.png)
 message CommandLookupTopic {
diff --git a/site2/docs/functions-overview.md b/site2/docs/functions-overview.md
index e0ea6d6..d7c2b50 100644
--- a/site2/docs/functions-overview.md
+++ b/site2/docs/functions-overview.md
@@ -61,13 +61,13 @@ The core programming model behind Pulsar Functions is very simple:
   * Write logs to a **log topic** (potentially for debugging purposes)
   * Increment a [counter](#counters)
-![Pulsar Functions core programming model](/docs/assets/pulsar-functions-overview.png)
+![Pulsar Functions core programming model](assets/pulsar-functions-overview.png)
 ### Word count example
 If you were to implement the classic word count example using Pulsar Functions, it might
look something like this:
-![Pulsar Functions word count example](/docs/assets/pulsar-functions-word-count.png)
+![Pulsar Functions word count example](assets/pulsar-functions-word-count.png)
 If you were writing the function in [Java](functions-api.md#java) using the [Pulsar Functions
SDK for Java](functions-api.md#java-sdk), you could write the function like this...
@@ -111,7 +111,7 @@ The use cases for Pulsar Functions are essentially endless, but let's
dig into a
 Imagine a function that takes items (strings) as input and publishes them to either a fruits
or vegetables topic, depending on the item. Or, if an item is neither a fruit nor a vegetable,
a warning is logged to a [log topic](#logging). Here's a visual representation:
-![Pulsar Functions routing example](/docs/assets/pulsar-functions-routing-example.png)
+![Pulsar Functions routing example](assets/pulsar-functions-routing-example.png)
 If you were implementing this routing functionality in Python, it might look something like
diff --git a/site2/docs/getting-started-concepts-and-architecture.md b/site2/docs/getting-started-concepts-and-architecture.md
index 3ee3c18..e290753 100644
--- a/site2/docs/getting-started-concepts-and-architecture.md
+++ b/site2/docs/getting-started-concepts-and-architecture.md
@@ -116,7 +116,7 @@ A namespace is a logical nomenclature within a tenant. A tenant can create
 A subscription is a named configuration rule that determines how messages are delivered to
consumers. There are three available subscription modes in Pulsar: [exclusive](#exclusive),
[shared](#shared), and [failover](#failover). These modes are illustrated in the figure below.
-![Subscription modes](/docs/assets/pulsar-subscription-modes.png)
+![Subscription modes](assets/pulsar-subscription-modes.png)
 #### Exclusive
@@ -126,7 +126,7 @@ In the diagram above, only **Consumer-A** is allowed to consume messages.
 > Exclusive mode is the default subscription mode.
-![Exclusive subscriptions](/docs/assets/pulsar-exclusive-subscriptions.png)
+![Exclusive subscriptions](assets/pulsar-exclusive-subscriptions.png)
 #### Shared
@@ -139,7 +139,7 @@ In the diagram above, **Consumer-B-1** and **Consumer-B-2** are able to
 > * Message ordering is not guaranteed.
 > * You cannot use cumulative acknowledgment with shared mode.
-![Shared subscriptions](/docs/assets/pulsar-shared-subscriptions.png)
+![Shared subscriptions](assets/pulsar-shared-subscriptions.png)
 #### Failover
@@ -149,7 +149,7 @@ When the master consumer disconnects, all (non-acked and subsequent) messages
 In the diagram above, Consumer-C-1 is the master consumer while Consumer-C-2 would be the
next in line to receive messages if Consumer-C-2 disconnected.
-![Failover subscriptions](/docs/assets/pulsar-failover-subscriptions.png)
+![Failover subscriptions](assets/pulsar-failover-subscriptions.png)
 ### Multi-topic subscriptions
@@ -196,7 +196,7 @@ Behind the scenes, a partitioned topic is actually implemented as N internal
 The diagram below illustrates this:
 Here, the topic **Topic1** has five partitions (**P0** through **P4**) split across three
brokers. Because there are more partitions than brokers, two brokers handle two partitions
a piece, while the third handles only one (again, Pulsar handles this distribution of partitions
@@ -281,7 +281,7 @@ In a Pulsar cluster:
 The diagram below provides an illustration of a Pulsar cluster:
-![Pulsar architecture diagram](/docs/assets/pulsar-system-architecture.png)
+![Pulsar architecture diagram](assets/pulsar-system-architecture.png)
 At the broader instance level, an instance-wide ZooKeeper cluster called the configuration
store handles coordination tasks involving multiple clusters, for example [geo-replication](#replication).
@@ -347,7 +347,7 @@ persistent://my-property/my-namespace/my-topic
 You can see an illustration of how brokers and bookies interact in the diagram below:
-![Brokers and bookies](/docs/assets/broker-bookie.png)
+![Brokers and bookies](assets/broker-bookie.png)
 ### Ledgers
@@ -395,7 +395,7 @@ Pulsar has two features, however, that enable you to override this default
 The diagram below illustrates both concepts:
-![Message retention and expiry](/docs/assets/retention-expiry.png)
+![Message retention and expiry](assets/retention-expiry.png)
 With message retention, shown at the top, a <span style="color: #89b557;">retention
policy</span> applied to all topics in a namespace dicates that some messages are durably
stored in Pulsar even though they've already been acknowledged. Acknowledged messages that
are not covered by the retention policy are <span style="color: #bb3b3e;">deleted</span>.
Without a retention policy, *all* of the <span style="color: #19967d;">acknowledged
messages</span> would be deleted.
@@ -415,7 +415,7 @@ Message **duplication** occurs when a message is [persisted](#persistent-storage
 The following diagram illustrates what happens when message deduplication is disabled vs.
-![Pulsar message deduplication](/docs/assets/message-deduplication.png)
+![Pulsar message deduplication](assets/message-deduplication.png)
 Message deduplication is disabled in the scenario shown at the top. Here, a producer publishes
message 1 on a topic; the message reaches a Pulsar broker and is [persisted](#persistent-storage)
to BookKeeper. The producer then sends message 1 again (in this case due to some retry logic),
and the message is received by the broker and stored in BookKeeper again, which means that
duplication has occurred.
@@ -535,7 +535,7 @@ You can use your own service discovery system if you'd like. If you use
your own
 The diagram below illustrates Pulsar service discovery:
 In this diagram, the Pulsar cluster is addressable via a single DNS name: `pulsar-cluster.acme.com`.
A [Python client](client-libraries-python.md), for example, could access this Pulsar cluster
like this:
@@ -557,7 +557,7 @@ The **reader interface** for Pulsar enables applications to manually manage
 The reader interface is helpful for use cases like using Pulsar to provide [effectively-once](https://streaml.io/blog/exactly-once/)
processing semantics for a stream processing system. For this use case, it's essential that
the stream processing system be able to "rewind" topics to a specific message and begin reading
there. The reader interface provides Pulsar clients with the low-level abstraction necessary
to "manually position" themselves within a topic.
-![The Pulsar consumer and reader interfaces](/docs/assets/pulsar-reader-consumer-interfaces.png)
+![The Pulsar consumer and reader interfaces](assets/pulsar-reader-consumer-interfaces.png)
 > ### Non-partitioned topics only
 > The reader interface for Pulsar cannot currently be used with [partitioned topics](#partitioned-topics).
@@ -639,7 +639,7 @@ Pulsar's segment oriented architecture allows for topic backlogs to grow
very la
 One way to alleviate this cost is to use Tiered Storage. With tiered storage, older messages
in the backlog can be moved from bookkeeper to a cheaper storage mechanism, while still allowing
clients to access the backlog as if nothing had changed. 
-![Tiered Storage](/docs/assets/pulsar-tiered-storage.png)
+![Tiered Storage](assets/pulsar-tiered-storage.png)
 > Data written to bookkeeper is replicated to 3 physical machines by default. However,
once a segment is sealed in bookkeeper is becomes immutable and can be copied to long term
storage. Long term storage can achieve cost savings by using mechanisms such as [Reed-Solomon
error correction](https://en.wikipedia.org/wiki/Reed%E2%80%93Solomon_error_correction) to
require fewer physical copies of data.
@@ -664,7 +664,7 @@ Pulsar IO connectors come in two types:
 This diagram illustrates the relationship between sources, sinks, and Pulsar:
-![Pulsar IO diagram](/docs/assets/pulsar-io.png "Pulsar IO connectors (sources and sinks)")
+![Pulsar IO diagram](assets/pulsar-io.png "Pulsar IO connectors (sources and sinks)")
 ### Working with connectors
diff --git a/site2/docs/io-overview.md b/site2/docs/io-overview.md
index 781fb0e..56a36f2 100644
--- a/site2/docs/io-overview.md
+++ b/site2/docs/io-overview.md
@@ -18,7 +18,7 @@ Pulsar IO connectors come in two types:
 This diagram illustrates the relationship between sources, sinks, and Pulsar:
-![Pulsar IO diagram](/docs/assets/pulsar-io.png "Pulsar IO connectors (sources and sinks")
+![Pulsar IO diagram](assets/pulsar-io.png "Pulsar IO connectors (sources and sinks")
 ## Working with connectors
diff --git a/site2/docs/security-encryption.md b/site2/docs/security-encryption.md
index b2b3b14..133d85b 100644
--- a/site2/docs/security-encryption.md
+++ b/site2/docs/security-encryption.md
@@ -19,10 +19,10 @@ A message can be encrypted with more than one key.  Any one of the keys
used for
 Pulsar does not store the encryption key anywhere in the pulsar service. If you lose/delete
the private key, your message is irretrievably lost, and is unrecoverable
 ## Producer
-![alt text](/docs/assets/pulsar-encryption-producer.jpg "Pulsar Encryption Producer")
+![alt text](assets/pulsar-encryption-producer.jpg "Pulsar Encryption Producer")
 ## Consumer
-![alt text](/docs/assets/pulsar-encryption-consumer.jpg "Pulsar Encryption Consumer")
+![alt text](assets/pulsar-encryption-consumer.jpg "Pulsar Encryption Consumer")
 ## Here are the steps to get started:

View raw message