You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@lucene.apache.org by is...@apache.org on 2019/11/17 22:14:09 UTC
[lucene-solr] branch jira/solr-13661-refguide updated: SOLR-13662:
Fix precommit due to asciidoc errors
This is an automated email from the ASF dual-hosted git repository.
ishan pushed a commit to branch jira/solr-13661-refguide
in repository https://gitbox.apache.org/repos/asf/lucene-solr.git
The following commit(s) were added to refs/heads/jira/solr-13661-refguide by this push:
new 78d0420 SOLR-13662: Fix precommit due to asciidoc errors
78d0420 is described below
commit 78d042031e32b38e263c96315de7574c9ebcad20
Author: Ishan Chattopadhyaya <is...@apache.org>
AuthorDate: Mon Nov 18 03:43:58 2019 +0530
SOLR-13662: Fix precommit due to asciidoc errors
---
.../src/package-manager-internals.adoc | 39 ++++++----------------
solr/solr-ref-guide/src/package-manager.adoc | 6 ++--
.../src/the-well-configured-solr-instance.adoc | 2 +-
3 files changed, 15 insertions(+), 32 deletions(-)
diff --git a/solr/solr-ref-guide/src/package-manager-internals.adoc b/solr/solr-ref-guide/src/package-manager-internals.adoc
index 6d89ca9..470d076 100644
--- a/solr/solr-ref-guide/src/package-manager-internals.adoc
+++ b/solr/solr-ref-guide/src/package-manager-internals.adoc
@@ -1,21 +1,4 @@
= Package Manager Internals
-// Licensed to the Apache Software Foundation (ASF) under one
-// or more contributor license agreements. See the NOTICE file
-// distributed with this work for additional information
-// regarding copyright ownership. The ASF licenses this file
-// to you under the Apache License, Version 2.0 (the
-// "License"); you may not use this file except in compliance
-// with the License. You may obtain a copy of the License at
-//
-// http://www.apache.org/licenses/LICENSE-2.0
-//
-// Unless required by applicable law or agreed to in writing,
-// software distributed under the License is distributed on an
-// "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
-// KIND, either express or implied. See the License for the
-// specific language governing permissions and limitations
-// under the License.
-
The package manager (CLI) internally uses various Solr APIs to install, deploy and update packages. This document contains an overview of those APIs.
== Design Objectives
@@ -26,8 +9,7 @@ The package manager (CLI) internally uses various Solr APIs to install, deploy a
** Artifacts (jars containing custom plugins) that users have already deployed (and are using in production) should be compatible, without needing to recompile or re-package, for greater adoption.
** Should support single jar packages as well as multiple jar packages.
** Use familiar / standard naming
-** Use industry standard concepts and terminology around package manager, similar to those like apt, dnf, homebrew etc.
-
+** Use industry standard concepts and terminology around package manager, similar to those like apt, dnf, homebrew etc.s
== Classloaders
@@ -35,7 +17,6 @@ At the heart of the system, we have classloader isolation. To achieve this, the
The root classloader which has all the jars from Solr classpath. This requires Solr node restart to change anything.
A set of named classloaders that inherit from the root classloader. The life cycles of the named classloaders are tied to the package configuration in ZK. As soon as the configuration is modified, the corresponding classloaders are reloaded and components are asked to reload.
-
== Package loading security
Packages are disabled by default. Start all your nodes with the system property `-Denable.packages=true` to use this feature.
@@ -46,7 +27,7 @@ Packages are disabled by default. Start all your nodes with the system property
$ bin/solr -c -Denable.packages=true
----
-==== Upload your keys
+=== Upload your keys
Package binaries must be signed with your private keys and ensure your public keys are published in Zookeeper
*Example*
@@ -157,20 +138,20 @@ The package configurations live in a file called /packages.json in Zookeeper. At
----
-=== API end points
+== API end points
* `GET /api/cluster/package` Get the list of packages
* `POST /api/cluster/package` edit packages
** `add` command: add a version of a package
** `delete` command : delete a version of a package
-==== How to upgrade?
+=== How to upgrade?
Use the add command to add a version that is bigger than the current version
-==== How to downgrade ?
+=== How to downgrade ?
Use the delete command to delete a version that is the highest and the next highest version will be chosen
-==== Using multiple versions in parallel in each collection
+=== Using multiple versions in parallel in each collection
We use the `params.json` in the collection config to store a version of a package it uses. by default it is the $LATEST.
[source, json]
----
@@ -183,14 +164,14 @@ We use the `params.json` in the collection config to store a version of a packag
* for `mypkg` use the version `0.1` irrespective of whether there is a newer version is available or not
* for `pkg2` use the latest. This is optional. The default is ‘$LATEST’
-==== The workflow
+=== The workflow
* A new version of a package is added
* The package loader loads the classes and notifies every plugin holder of the availability of the new version
* It checks if it is supposed to use a specific version, Ignore the update
* If not, reload the plugin
-==== Using them in Plugins
+=== Using them in Plugins
Any class name can be prefixed with the packagename e.g : `mypkg:fully.qualified.ClassName` and Solr would use the latest version of the package to load the classes from. The plugins loaded from packages cannot depend on core level classes.
*Plugin declaration in `solrconfig.xml`*
@@ -201,7 +182,7 @@ Any class name can be prefixed with the packagename e.g : `mypkg:fully.qualified
</requestHandler>
----
-==== Full working example
+=== Full working example
1) create a package
@@ -358,7 +339,7 @@ $ curl http://localhost:8983/solr/gettingstarted/test?omitHeader=true
----
Note that the `Version` value is `"2"` . So the plugin is updated
-==== How to avoid automatic upgrade (while only using internal APIs)?
+=== How to avoid automatic upgrade (while only using internal APIs)?
The default version used in any collection is always the latest. However, setting a per-collection property in the `params.json` ensures that the versions are always fixed irrespective of the new versions added
diff --git a/solr/solr-ref-guide/src/package-manager.adoc b/solr/solr-ref-guide/src/package-manager.adoc
index 5e111e4..edf88a3 100644
--- a/solr/solr-ref-guide/src/package-manager.adoc
+++ b/solr/solr-ref-guide/src/package-manager.adoc
@@ -1,4 +1,6 @@
= Package Management
+:page-children: package-manager-internals
+
// Licensed to the Apache Software Foundation (ASF) under one
// or more contributor license agreements. See the NOTICE file
// distributed with this work for additional information
@@ -32,7 +34,7 @@ The package manager in Solr consists of the following internal components:
* Isolated classloaders
* Package Store
-In this guide, we will focus on the Package Manager CLI, which essentially uses the other APIs and components internally. For details on the other components (and hence details of inner workings of the package manager), please refer to <<package-manager-internals.adoc,Package Manager internals>>.
+In this guide, we will focus on the Package Manager CLI, which essentially uses the other APIs and components internally. For details on the other components (and hence details of inner workings of the package manager), please refer to <<package-manager-internals.adoc#package-manager-internals,Package Manager internals>>.
== Interacting with the package manager
@@ -152,6 +154,6 @@ $ bin/solr package deploy mypackage:2.0.0 --update -collections mycollection
You can run the `list-deployed` command to verify that this collection is using the newly added version.
== Security
-Except the `add-repo` step, all other steps can be executed using a HTTP endpoint in Solr (see <<package-manager-internals.adoc,Package Manager internals>>). This step registers the public key of the trusted repository, and hence can only be executed using the package manager (CLI) having direct write access to Zookeeper. Hence, as you can imagine, it is important to protect Zookeeper from unauthorized write access.
+Except the `add-repo` step, all other steps can be executed using a HTTP endpoint in Solr (see <<package-manager-internals.adoc#package-manager-internals,Package Manager internals>>). This step registers the public key of the trusted repository, and hence can only be executed using the package manager (CLI) having direct write access to Zookeeper. Hence, as you can imagine, it is important to protect Zookeeper from unauthorized write access.
Also, keep in mind, that it is possible to install any package from a trusted and an already added repository. Hence, if you want to use some packages in production, then it is better to setup your own repository and add that to Solr, instead of adding a generic third-party repository that is beyond your administrative control.
\ No newline at end of file
diff --git a/solr/solr-ref-guide/src/the-well-configured-solr-instance.adoc b/solr/solr-ref-guide/src/the-well-configured-solr-instance.adoc
index 5e3e6c0..85531e0 100644
--- a/solr/solr-ref-guide/src/the-well-configured-solr-instance.adoc
+++ b/solr/solr-ref-guide/src/the-well-configured-solr-instance.adoc
@@ -31,7 +31,7 @@ This section covers the following topics:
<<solr-plugins.adoc#solr-plugins,Solr Plugins>>: Introduces Solr plugins with pointers to more information.
-<<package-manager.adoc, Packages and Package Management>>: Installing, deploying and updating packages (containing plugins) into a Solr cluster
+<<package-manager.adoc#glossary-of-terms, Packages and Package Management>>: Installing, deploying and updating packages (containing plugins) into a Solr cluster
<<jvm-settings.adoc#jvm-settings,JVM Settings>>: Gives some guidance on best practices for working with Java Virtual Machines.