mirror of
https://github.com/clearlinux/clear-linux-documentation.git
synced 2026-06-29 09:16:08 +00:00
Merge branch 'master' of github.com:clearlinux/clear-linux-documentation into rtd-theme
This commit is contained in:
Kevin Putnam
@@ -3,11 +3,11 @@
|
||||
Data Analytics Reference Stack
|
||||
##############################
|
||||
|
||||
This guide shows you how to use the Data Analytics Reference Stack
|
||||
(DARS), and to optionally build your own images with the baseline Dockerfiles
|
||||
provided in the `DARS repository`_. Our assumption is that |CL-ATTR| is the
|
||||
host. However, any system that supports Docker\* containers can be used to
|
||||
follow these steps.
|
||||
This guide explains how to use the :abbr:`DARS (Data Analytics Reference Stack)`,
|
||||
and to optionally build your own DARS container image.
|
||||
|
||||
Any system that supports Docker\* containers can be used with DARS. This steps
|
||||
in this guide use |CL-ATTR| as the host system.
|
||||
|
||||
.. contents::
|
||||
:local:
|
||||
@@ -16,96 +16,118 @@ follow these steps.
|
||||
The Data Analytics Reference Stack release
|
||||
******************************************
|
||||
|
||||
The Data Analytics Reference Stack (DARS) provides developers and enterprises a straightforward, highly optimized software stack for storing and processing large amounts of data. More detail is available on the `DARS architecture and performance benchmarks`_.
|
||||
The Data Analytics Reference Stack (DARS) provides developers and enterprises a straightforward, highly optimized software stack for storing and processing large
|
||||
amounts of data. More detail is available on the
|
||||
`DARS architecture and performance benchmarks`_.
|
||||
|
||||
The Data Analytics Reference Stack provides two pre-built Docker images, available on `Docker Hub`_:
|
||||
The Data Analytics Reference Stack provides two pre-built Docker images,
|
||||
available on `Docker Hub`_:
|
||||
|
||||
* A |CL|-derived `DARS with OpenBlas`_ stack optimized for `OpenBLAS`_
|
||||
* A |CL|-derived `DARS with MKL`_ stack optimized for `MKL`_
|
||||
* A |CL|-derived `DARS with Intel® MKL`_ stack optimized for `MKL`_
|
||||
|
||||
We recommend you view the latest component versions for each image in the
|
||||
:file:`README` found in the `DARS repository`_. Because |CL| is a rolling
|
||||
distribution, the package version numbers in the |CL|-based containers may
|
||||
not be the latest released by |CL|.
|
||||
:file:`README` found in the `Data Analytics Reference Stack`_ GitHub\*
|
||||
repository. Because |CL| is a rolling distribution, the package version numbers
|
||||
in the |CL|-based containers may not be the latest released by |CL|.
|
||||
|
||||
.. note::
|
||||
|
||||
The Data Analytics Reference Stack is a collective work, and each piece
|
||||
of software within the work has its own license. Please see the `terms
|
||||
of use`_ for more details about licensing and usage of the Data Analytics
|
||||
Reference Stack.
|
||||
of software within the work has its own license. Please see the
|
||||
`DARS Terms of Use`_ for more details about licensing and usage of the Data
|
||||
Analytics Reference Stack.
|
||||
|
||||
Using the Docker Images
|
||||
Using the Docker images
|
||||
***********************
|
||||
|
||||
To immediately start using the latest stable DARS images, pull directly
|
||||
from `Docker Hub`_. For this guide we'll use the `Dars with MKL`_ version of the stack.
|
||||
#. To immediately start using the latest stable DARS images, pull an image
|
||||
directly from `Docker Hub`_. This example uses the
|
||||
`DARS with Intel® MKL`_ Docker image.
|
||||
|
||||
Once you have downloaded the image, you can run it with
|
||||
#. Once you have downloaded the image, you can run it with
|
||||
|
||||
.. code-block:: bash
|
||||
.. code-block:: bash
|
||||
|
||||
docker run -it --ulimit nofile=1000000:1000000 --name mkl <name of image>
|
||||
docker run -it --ulimit nofile=1000000:1000000 --name mkl <name of image>
|
||||
|
||||
This will launch the image and drop you into a bash shell inside the
|
||||
container. You will see output similar to the following:
|
||||
This will launch the image and drop you into a bash shell inside the
|
||||
container. You will see output similar to the following:
|
||||
|
||||
.. code-block:: console
|
||||
.. code-block:: console
|
||||
|
||||
root@fd5155b89857 /root # spark-shell
|
||||
spark-shell
|
||||
Config directory: /usr/share/defaults/spark/
|
||||
Welcome to
|
||||
____ __
|
||||
/ __/__ ___ _____/ /__
|
||||
_\ \/ _ \/ _ `/ __/ '_/
|
||||
/___/ .__/\_,_/_/ /_/\_\ version 2.4.0
|
||||
/_/
|
||||
root@fd5155b89857 /root # spark-shell
|
||||
spark-shell
|
||||
Config directory: /usr/share/defaults/spark/
|
||||
Welcome to
|
||||
____ __
|
||||
/ __/__ ___ _____/ /__
|
||||
_\ \/ _ \/ _ `/ __/ '_/
|
||||
/___/ .__/\_,_/_/ /_/\_\ version 2.4.0
|
||||
/_/
|
||||
|
||||
Using Scala version 2.12.7 (OpenJDK 64-Bit Server VM, Java 1.8.0-internal)
|
||||
Type in expressions to have them evaluated.
|
||||
Type :help for more information.
|
||||
Using Scala version 2.12.7 (OpenJDK 64-Bit Server VM, Java 1.8.0-internal)
|
||||
Type in expressions to have them evaluated.
|
||||
Type :help for more information.
|
||||
|
||||
scala>
|
||||
scala>
|
||||
|
||||
The :command:`--ulimit nofile` parameter is currently required in order to
|
||||
increase the number of open files opened at certain point by the spark
|
||||
engine.
|
||||
The :command:`--ulimit nofile` parameter is currently required in order to
|
||||
increase the number of open files opened at certain point by the spark
|
||||
engine.
|
||||
|
||||
Building DARS Images
|
||||
Building DARS images
|
||||
********************
|
||||
|
||||
If you choose to build your own DARS container images, you can customize
|
||||
them as needed. Use the provided Dockerfile as a baseline. To construct
|
||||
images with |CL|, start with a |CL| development platform that
|
||||
them as needed. Use the provided Dockerfile as a baseline.
|
||||
|
||||
To construct images with |CL|, start with a |CL| development platform that
|
||||
has the :command:`containers-basic-dev` bundle installed. Learn more about
|
||||
bundles and installing them by using :ref:`swupd-guide`.
|
||||
|
||||
First, clone the `DARS repository`_ from GitHub.
|
||||
#. Clone the `Data Analytics Reference Stack`_ GitHub\* repository.
|
||||
|
||||
.. code-block:: bash
|
||||
.. code-block:: bash
|
||||
|
||||
git clone https://github.com/clearlinux/dockerfiles/tree/master/stacks/dars -b master
|
||||
git clone https://github.com/clearlinux/dockerfiles/tree/master/stacks/dars -b master
|
||||
|
||||
Then, inside the DARS directory, run :command:`make` to build OpenBLAS and
|
||||
MKL images, and run :command:`make baseline` to build the baseline CentOS
|
||||
image. Depending on the system, it may take a while to finish building.
|
||||
Once completed, check the resulting images with :command:`Docker`
|
||||
#. Inside the DARS directory, run :command:`make` to build OpenBLAS and MKL images.
|
||||
|
||||
.. code-block:: bash
|
||||
.. code-block:: bash
|
||||
|
||||
docker images | grep dars
|
||||
make
|
||||
|
||||
You can use any of the resulting images to launch fully functional
|
||||
containers. If you need to customize the containers, you can edit the
|
||||
provided :file:`Dockerfile`.
|
||||
Run :command:`make baseline` to build the baseline CentOS image. Depending on
|
||||
the system, it may take a while to finish building.
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
make baseline
|
||||
|
||||
#. Once completed, check the resulting images with :command:`Docker`
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
docker images | grep dars
|
||||
|
||||
#. You can use any of the resulting images to launch fully functional containers.
|
||||
If you need to customize the containers, you can edit the provided :file:`Dockerfile`.
|
||||
|
||||
.. _Data Analytics Reference Stack: https://github.com/clearlinux/dockerfiles/tree/master/stacks/dars
|
||||
|
||||
.. _DARS repository: https://github.com/clearlinux/dockerfiles/tree/master/stacks/dars
|
||||
.. _Docker Hub: https://hub.docker.com/
|
||||
|
||||
.. _OpenBLAS: http://www.openblas.net/
|
||||
|
||||
.. _MKL: https://software.intel.com/en-us/mkl
|
||||
|
||||
.. _CentOS: https://www.centos.org/
|
||||
|
||||
.. _DARS with OpenBLAS: https://hub.docker.com/r/clearlinux/stacks-dars-openblas/
|
||||
.. _DARS with MKL: https://hub.docker.com/r/clearlinux/stacks-dars-mkl/
|
||||
|
||||
.. _DARS with Intel® MKL: https://hub.docker.com/r/clearlinux/stacks-dars-mkl/
|
||||
|
||||
.. _DARS architecture and performance benchmarks: https://clearlinux.org/stacks/data-analytics-stack-v1
|
||||
.. _terms of use: https://clearlinux.org/stacks/data-analytics/terms-of-use
|
||||
|
||||
.. _DARS Terms of Use: https://clearlinux.org/stacks/data-analytics/terms-of-use
|
||||
|
||||
@@ -44,19 +44,19 @@ The Deep Learning Reference Stack is available in the following versions:
|
||||
Stack features
|
||||
==============
|
||||
|
||||
* Deep Learning Reference Stack `V3.0 release announcement`_.
|
||||
* `DLRS V3.0`_ release announcement.
|
||||
* Deep Learning Reference Stack v2.0 including current
|
||||
`PyTorch benchmark results`_.
|
||||
`PyTorch benchmark`_.
|
||||
* Deep Learning Reference Stack v1.0 including current
|
||||
`TensorFlow benchmark results`_.
|
||||
* `Release notes on Github\*`_ for the latest release of Deep Learning Reference
|
||||
Stack.
|
||||
`TensorFlow benchmark`_ results.
|
||||
* `DLRS Release notes`_ on Github\* for the latest release of Deep Learning
|
||||
Reference Stack.
|
||||
|
||||
.. note::
|
||||
|
||||
The Deep Learning Reference Stack is a collective work, and each piece of software within the work has its own license. Please see the `terms of use`_ for more details about licensing and usage of the Deep Learning Reference Stack.
|
||||
|
||||
|
||||
The Deep Learning Reference Stack is a collective work, and each piece of
|
||||
software within the work has its own license. Please see the `DLRS Terms of Use`_
|
||||
for more details about licensing and usage of the Deep Learning Reference Stack.
|
||||
|
||||
Prerequisites
|
||||
=============
|
||||
@@ -104,19 +104,22 @@ We validated these steps against the following software package versions:
|
||||
|
||||
.. note::
|
||||
|
||||
The Deep Learning Reference Stack was developed to provide the best user experience when executed on a |CL| host. However, as the stack runs in a container environment, you should be able to complete the following sections of this guide on other Linux* distributions, provided they comply with the Docker*, Kubernetes* and Go* package versions listed above. Look for your distribution documentation on how to update packages and manage Docker services.
|
||||
The Deep Learning Reference Stack was developed to provide the best user
|
||||
experience when executed on a |CL| host. However, as the stack runs in a
|
||||
container environment, you should be able to complete the following sections of this guide on other Linux* distributions, provided they comply with the Docker*, Kubernetes* and Go* package versions listed above. Look for your distribution documentation on how to update packages and manage Docker services.
|
||||
|
||||
TensorFlow single and multi-node benchmarks
|
||||
*******************************************
|
||||
|
||||
This section describes running the `TensorFlow benchmarks`_ in single node.
|
||||
This section describes running the `TensorFlow Benchmarks`_ in single node.
|
||||
For multi-node testing, replicate these steps for each node. These steps
|
||||
provide a template to run other benchmarks, provided that they can invoke
|
||||
TensorFlow.
|
||||
|
||||
.. note::
|
||||
|
||||
Performance test results for the Deep Learning Reference Stack and for this guide were obtained using `runc` as the runtime.
|
||||
Performance test results for the Deep Learning Reference Stack and for this
|
||||
guide were obtained using `runc` as the runtime.
|
||||
|
||||
#. Download either the `Eigen`_ or the `Intel MKL-DNN`_ Docker image
|
||||
from `Docker Hub`_.
|
||||
@@ -198,28 +201,30 @@ The benchmark workload runs in a Kubernetes cluster. The guide uses
|
||||
|
||||
.. warning::
|
||||
|
||||
If you choose the Intel® MKL-DNN or Intel® MKL-DNN-VNNI image, your platform must support the Intel® AVX-512 instruction set. Otherwise, an *illegal instruction* error may appear, and you won’t be able to complete this guide.
|
||||
If you choose the Intel® MKL-DNN or Intel® MKL-DNN-VNNI image, your platform
|
||||
must support the Intel® AVX-512 instruction set. Otherwise, an
|
||||
*illegal instruction* error may appear, and you won’t be able to complete this guide.
|
||||
|
||||
|
||||
Kubernetes setup
|
||||
================
|
||||
|
||||
Follow the instructions in the :ref:`kubernetes` tutorial to get set up on
|
||||
|CL|. The Kubernetes community also has
|
||||
`instructions for creating a cluster`_.
|
||||
|CL|. The Kubernetes community also has instructions for creating a cluster,
|
||||
described in `Creating a single control-plane cluster with kubeadm`_.
|
||||
|
||||
Kubernetes networking
|
||||
=====================
|
||||
|
||||
We used `flannel`_ as the network provider for these tests. If you
|
||||
prefer a different network layer, refer to the Kubernetes
|
||||
`networking documentation`_ for setup.
|
||||
prefer a different network layer, refer to the Kubernetes network documentation
|
||||
described in `Creating a single control-plane cluster with kubeadm`_ for setup.
|
||||
|
||||
Kubectl
|
||||
=======
|
||||
|
||||
You can use kubectl to run commands against your Kubernetes cluster. Refer to
|
||||
the `kubectl overview`_ for details on syntax and operations. Once you have a
|
||||
the `Overview of kubectl`_ for details on syntax and operations. Once you have a
|
||||
working cluster on Kubernetes, use the following YAML script to start a pod with
|
||||
a simple shell script, and keep the pod open.
|
||||
|
||||
@@ -297,7 +302,7 @@ Kubeflow
|
||||
========
|
||||
|
||||
Once you have Kubernetes running on your nodes, set up `Kubeflow`_ by
|
||||
following these instructions from the `quick start guide`_.
|
||||
following these instructions from the `Getting Started with Kubeflow`_ guide.
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
@@ -329,7 +334,7 @@ This creates the CustomResourceDefinition (CRD) endpoint to launch a TFJob.
|
||||
Run a TFJob
|
||||
===========
|
||||
|
||||
#. Select this link for the `ksonnet registries for deploying TFJobs`_.
|
||||
#. Get the ksonnet registries for deploying TFJobs from `dlrs-tfjob`_.
|
||||
|
||||
#. Install the TFJob components as follows:
|
||||
|
||||
@@ -367,8 +372,8 @@ Results of running this guide
|
||||
You must parse the logs of the Kubernetes pod to retrieve performance
|
||||
data. The pods will still exist post-completion and will be in
|
||||
‘Completed’ state. You can get the logs from any of the pods to inspect the
|
||||
benchmark results. More information about `Kubernetes logging`_ is available
|
||||
from the Kubernetes community.
|
||||
benchmark results. More information about Kubernetes logging is available
|
||||
in the Kubernetes `Logging Architecture`_ documentation.
|
||||
|
||||
Use Jupyter Notebook
|
||||
********************
|
||||
@@ -455,7 +460,9 @@ deep learning frameworks. Refer to `Jupyter Notebook`_ for details.
|
||||
Uninstallation
|
||||
**************
|
||||
|
||||
To uninstall the Deep Learning Reference Stack, you can choose to stop the container so that it is not using system resources, or you can stop the container and delete it to free storage space.
|
||||
To uninstall the Deep Learning Reference Stack, you can choose to stop the
|
||||
container so that it is not using system resources, or you can stop the
|
||||
container and delete it to free storage space.
|
||||
|
||||
To stop the container, execute the following from your host system:
|
||||
|
||||
@@ -472,7 +479,8 @@ To stop the container, execute the following from your host system:
|
||||
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
|
||||
e131dc71d339 clearlinux/stacks-dlrs-oss "/bin/sh -c 'bash'" 23 seconds ago Up 21 seconds oss
|
||||
|
||||
#. You can then use the ID or container name to stop the container. This example uses the name "oss":
|
||||
#. You can then use the ID or container name to stop the container. This example
|
||||
uses the name "oss":
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
@@ -528,8 +536,8 @@ To stop the container, execute the following from your host system:
|
||||
Related topics
|
||||
**************
|
||||
|
||||
* Deep Learning Reference Stack `V3.0 release announcement`_
|
||||
* `TensorFlow benchmarks`_
|
||||
* `DLRS V3.0`_ release announcement
|
||||
* `TensorFlow Benchmarks`_
|
||||
* `PyTorch benchmarks`_
|
||||
* `Kubeflow`_
|
||||
* :ref:`kubernetes` tutorial
|
||||
@@ -541,17 +549,15 @@ Related topics
|
||||
|
||||
.. _Docker Hub: https://hub.docker.com/
|
||||
|
||||
.. _TensorFlow benchmarks: https://www.tensorflow.org/guide/performance/benchmarks
|
||||
.. _TensorFlow Benchmarks: https://www.tensorflow.org/guide/performance/benchmarks
|
||||
|
||||
.. _PyTorch benchmarks: https://github.com/pytorch/pytorch/blob/master/caffe2/python/convnet_benchmarks.py
|
||||
|
||||
.. _instructions for creating a cluster: https://kubernetes.io/docs/setup/independent/create-cluster-kubeadm/
|
||||
.. _Creating a single control-plane cluster with kubeadm: https://kubernetes.io/docs/setup/independent/create-cluster-kubeadm/
|
||||
|
||||
.. _flannel: https://github.com/coreos/flannel
|
||||
|
||||
.. _networking documentation: https://kubernetes.io/docs/setup/independent/create-cluster-kubeadm/#pod-network
|
||||
|
||||
.. _quick start guide: https://www.kubeflow.org/docs/started/getting-started/
|
||||
.. _Getting Started with Kubeflow: https://www.kubeflow.org/docs/started/getting-started/
|
||||
|
||||
.. _Eigen: https://hub.docker.com/r/clearlinux/stacks-dlrs-oss/
|
||||
|
||||
@@ -563,24 +569,24 @@ Related topics
|
||||
|
||||
.. _Intel MKL-DNN-VNNI: https://hub.docker.com/r/clearlinux/stacks-dlrs-mkl-vnni
|
||||
|
||||
.. _V3.0 release announcement: https://clearlinux.org/stacks/deep-learning-reference-stack-v3
|
||||
.. _DLRS V3.0: https://clearlinux.org/stacks/deep-learning-reference-stack-v3
|
||||
|
||||
.. _ksonnet registries for deploying TFJobs: https://github.com/clearlinux/dockerfiles/tree/master/stacks/dlrs/kubeflow/dlrs-tfjob
|
||||
.. _dlrs-tfjob: https://github.com/clearlinux/dockerfiles/tree/master/stacks/dlrs/kubeflow/dlrs-tfjob
|
||||
|
||||
.. _Kubernetes logging: https://kubernetes.io/docs/concepts/cluster-administration/logging/
|
||||
.. _Logging Architecture: https://kubernetes.io/docs/concepts/cluster-administration/logging/
|
||||
|
||||
.. _TensorFlow benchmark results: https://clearlinux.org/stacks/deep-learning-reference-stack
|
||||
.. _TensorFlow benchmark: https://clearlinux.org/stacks/deep-learning-reference-stack
|
||||
|
||||
.. _PyTorch benchmark results: https://clearlinux.org/stacks/deep-learning-reference-stack-pytorch
|
||||
.. _PyTorch benchmark: https://clearlinux.org/stacks/deep-learning-reference-stack-pytorch
|
||||
|
||||
.. _Jupyter Notebook: https://jupyter.org/
|
||||
|
||||
.. _kubectl overview: https://kubernetes.io/docs/reference/kubectl/overview/
|
||||
.. _Overview of kubectl: https://kubernetes.io/docs/reference/kubectl/overview/
|
||||
|
||||
.. _launcher.py: https://github.com/clearlinux/dockerfiles/tree/master/stacks/dlrs/kubeflow
|
||||
|
||||
.. _terms of use: https://clearlinux.org/stacks/deep-learning/terms-of-use
|
||||
.. _DLRS Terms of Use: https://clearlinux.org/stacks/deep-learning/terms-of-use
|
||||
|
||||
.. _Release notes on Github\*: https://github.com/clearlinux/dockerfiles/blob/master/stacks/dlrs/releasenote.md
|
||||
.. _DLRS Release notes: https://github.com/clearlinux/dockerfiles/blob/master/stacks/dlrs/releasenote.md
|
||||
|
||||
.. _Intel® quantization tools: https://github.com/IntelAI/tools/blob/master/tensorflow_quantization/README.md#quantization-tools
|
||||
|
||||
@@ -3,6 +3,22 @@
|
||||
Enable AWS Greengrass\* and OpenVINO™ toolkit
|
||||
#############################################
|
||||
|
||||
This guide explains how to enable AWS Greengrass\* and OpenVINO™ toolkit.
|
||||
Specifically, the guide demonstrates how to:
|
||||
|
||||
* Set up the Intel® edge device with |CL-ATTR|
|
||||
* Install the OpenVINO™ toolkit and Amazon Web Services\* (AWS\*)
|
||||
Greengrass\* software stacks
|
||||
* Use AWS Greengrass\* and AWS Lambda\* to deploy the FaaS samples from
|
||||
the cloud
|
||||
|
||||
.. contents::
|
||||
:local:
|
||||
:depth: 1
|
||||
|
||||
Overview
|
||||
********
|
||||
|
||||
Hardware accelerated Function-as-a-Service (FaaS) enables cloud developers to
|
||||
deploy inference functionalities [1] on Intel® IoT edge devices with
|
||||
accelerators (CPU, Integrated GPU, Intel® FPGA, and Intel® Movidius™
|
||||
@@ -12,19 +28,6 @@ using a containerized environment. Hardware-accelerated FaaS provides the
|
||||
best-in-class performance by accessing optimized deep learning libraries on
|
||||
Intel® IoT edge devices with accelerators.
|
||||
|
||||
This guide demonstrates how to:
|
||||
|
||||
* Set up the Intel® edge device with |CL-ATTR|
|
||||
* Install the OpenVINO™ toolkit and Amazon Web Services\* (AWS\*)
|
||||
Greengrass\* software stacks
|
||||
* Use AWS Greengrass\* and AWS Lambda\* to deploy the FaaS samples from
|
||||
the cloud
|
||||
|
||||
Refer to the following topics:
|
||||
|
||||
.. contents:: :local:
|
||||
:depth: 1
|
||||
|
||||
Supported platforms
|
||||
*******************
|
||||
|
||||
@@ -75,8 +78,8 @@ see Greengrass user below).
|
||||
useradd <userid>
|
||||
passwd <userid>
|
||||
|
||||
#. Next, enable the :command:`sudo` command for your new ``<userid>``. Add
|
||||
``<userid>`` to the *wheel* group:
|
||||
#. Next, enable the :command:`sudo` command for your new <userid>. Add
|
||||
<userid> to the `wheel` group:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
@@ -120,20 +123,22 @@ There are two types of provided models that can be used in conjunction with
|
||||
AWS Greengrass for this guide: classification or object detection.
|
||||
|
||||
To complete this guide using an image classification model,
|
||||
download the BVLC AlexNet model files `bvlc_alexnet.caffemodel`_ and `deploy.prototxt`_
|
||||
to the default model_location at :file:`/usr/share/openvino/models`.
|
||||
Any custom pre-trained classification models can be used with the
|
||||
classification sample.
|
||||
download the BVLC AlexNet model files `bvlc_alexnet.caffemodel`_ and
|
||||
`deploy.prototxt`_ to the default model_location at
|
||||
:file:`/usr/share/openvino/models`. Any custom pre-trained classification models
|
||||
can be used with the classification sample.
|
||||
|
||||
For object detection, the sample models optimized for Intel® edge platforms
|
||||
are included with the computer-vision-basic bundle installation at :file:`/usr/share/openvino/models`.
|
||||
These models are provided as an example; however, you may also use a custom SSD model
|
||||
with the Greengrass object detection sample.
|
||||
are included with the computer-vision-basic bundle installation at
|
||||
:file:`/usr/share/openvino/models`. These models are provided as an example;
|
||||
you may also use a custom SSD model with the Greengrass object detection sample.
|
||||
|
||||
Run model optimizer
|
||||
-------------------
|
||||
|
||||
Follow these instructions for `converting deep learning models to Intermediate Representation using Model Optimizer`_. To optimize either of the sample models described above, run one of the following commands.
|
||||
Follow the instructions in the `Model Optimizer Developer Guide`_ for converting
|
||||
deep learning models to Intermediate Representation using Model Optimizer. To
|
||||
optimize either of the sample models described above, run one of the following commands.
|
||||
|
||||
For classification using BVLC AlexNet model:
|
||||
|
||||
@@ -155,11 +160,11 @@ For object detection using SqueezeNetSSD-5Class model:
|
||||
|
||||
In these examples:
|
||||
|
||||
* ``<model_location>`` is :file:`/usr/share/openvino/models`.
|
||||
* `<model_location>` is :file:`/usr/share/openvino/models`.
|
||||
|
||||
* ``<data_type>`` is FP32 or FP16, depending on target device.
|
||||
* `<data_type>` is FP32 or FP16, depending on target device.
|
||||
|
||||
* ``<output_dir>`` is the directory where the Intermediate Representation
|
||||
* `<output_dir>` is the directory where the Intermediate Representation
|
||||
(IR) is stored. IR contains .xml format corresponding to the network
|
||||
structure and .bin format corresponding to weights. This .xml file should be
|
||||
passed to :command:`<PARAM_MODEL_XML>`.
|
||||
@@ -168,7 +173,7 @@ In these examples:
|
||||
batch size 10 by default. In order to use any other batch size, the
|
||||
entire input shape must be provided as an argument to the model
|
||||
optimizer. For example, to use batch size 1, you must provide:
|
||||
``--input_shape [1,3,227,227]``
|
||||
`--input_shape [1,3,227,227]`
|
||||
|
||||
|
||||
Configure AWS Greengrass group
|
||||
@@ -178,7 +183,7 @@ For each Intel® edge platform, you must create a new AWS Greengrass group
|
||||
and install AWS Greengrass core software to establish the connection between
|
||||
cloud and edge.
|
||||
|
||||
#. To create an AWS Greengrass group, follow the instructions in
|
||||
#. To create an AWS Greengrass group, follow the instructions in
|
||||
`Configure AWS IoT Greengrass on AWS IoT`_.
|
||||
|
||||
#. To install and configure AWS Greengrass core on edge platform, follow
|
||||
@@ -189,7 +194,7 @@ cloud and edge.
|
||||
.. note::
|
||||
|
||||
You do not need to run the :file:`cgroupfs-mount.sh` script in step #6
|
||||
of Module 1 of the `AWS Greengrass developer guide`_ because this is
|
||||
of Module 1 of the `AWS Greengrass Developer Guide`_ because this is
|
||||
enabled already in |CL|.
|
||||
|
||||
#. Be sure to download both the security resources and the AWS Greengrass
|
||||
@@ -203,7 +208,8 @@ cloud and edge.
|
||||
Create and package Lambda function
|
||||
**********************************
|
||||
|
||||
#. Complete steps 1-4 of the AWS Greengrass guide at `Create and Package a Lambda Function`_.
|
||||
#. Complete steps 1-4 of the AWS Greengrass guide at
|
||||
`Create and Package a Lambda Function`_.
|
||||
|
||||
.. note::
|
||||
|
||||
@@ -211,15 +217,15 @@ Create and package Lambda function
|
||||
environment on the edge device.
|
||||
|
||||
|
||||
#. In step 5, replace :file:`greengrassHelloWorld.py` with the classification or object detection
|
||||
Greengrass sample from `Edge-Analytics-Faas`_:
|
||||
#. In step 5, replace :file:`greengrassHelloWorld.py` with the classification or
|
||||
object detection Greengrass sample from `Edge-Analytics-Faas`_:
|
||||
|
||||
* Classification: `greengrass_classification_sample.py`_
|
||||
|
||||
* Object Detection: `greengrass_object_detection_sample_ssd.py`_
|
||||
|
||||
#. Zip the selected Greengrass sample with the extracted Greengrass SDK folders from the previous
|
||||
step into :file:`greengrass_sample_python_lambda.zip`.
|
||||
#. Zip the selected Greengrass sample with the extracted Greengrass SDK folders
|
||||
from the previous step into :file:`greengrass_sample_python_lambda.zip`.
|
||||
|
||||
The zip should contain:
|
||||
|
||||
@@ -234,8 +240,8 @@ Create and package Lambda function
|
||||
zip -r greengrass_lambda.zip greengrasssdk
|
||||
greengrass_object_detection_sample_ssd.py
|
||||
|
||||
#. Return to the AWS documentation section called `Create and Package a Lambda Function`_
|
||||
and complete the procedure.
|
||||
#. Return to the AWS documentation section called
|
||||
`Create and Package a Lambda Function`_ and complete the procedure.
|
||||
|
||||
.. note::
|
||||
|
||||
@@ -253,8 +259,8 @@ Configure Lambda function
|
||||
After creating the Greengrass group and the Lambda function, start
|
||||
configuring the Lambda function for AWS Greengrass.
|
||||
|
||||
#. Follow steps 1-8 in `Configure the Lambda Function for AWS IoT Greengrass`_ in the AWS
|
||||
documentation.
|
||||
#. Follow steps 1-8 in `Configure the Lambda Function for AWS IoT Greengrass`_
|
||||
in the AWS documentation.
|
||||
|
||||
#. In addition to the details mentioned in step 8, change the Memory limit
|
||||
to 2048 MB to accommodate large input video streams.
|
||||
@@ -298,7 +304,8 @@ configuring the Lambda function for AWS Greengrass.
|
||||
Add local resources
|
||||
===================
|
||||
|
||||
Refer to the AWS documentation for details about `local resources and access privileges`_.
|
||||
Refer to the AWS documentation `Access Local Resources with Lambda Functions and Connectors`_
|
||||
for details about local resources and access privileges.
|
||||
|
||||
The following table describes the local resources needed for the CPU:
|
||||
|
||||
@@ -330,9 +337,8 @@ The following table describes the local resources needed for the CPU:
|
||||
Deploy Lambda function
|
||||
**********************
|
||||
|
||||
Refer to the AWS documentation for instructions on how to
|
||||
`deploy the lambda function to AWS Greengrass core device`_. Select
|
||||
*Deployments* on the group page and follow the instructions.
|
||||
Refer to the AWS documentation `Deploy Cloud Configurations to an AWS IoT Greengrass Core Device`_ for instructions on how to deploy the lambda function to AWS
|
||||
Greengrass core device. Select *Deployments* on the group page and follow the instructions.
|
||||
|
||||
Output consumption
|
||||
==================
|
||||
@@ -341,7 +347,7 @@ There are four options available for output consumption. These options are
|
||||
used to report, stream, upload, or store inference output at an interval
|
||||
defined by the variable :command:`reporting_interval` in the AWS Greengrass samples.
|
||||
|
||||
a. IoT cloud output:
|
||||
#. IoT cloud output:
|
||||
|
||||
This option is enabled by default in the AWS Greengrass samples using the
|
||||
:command:`enable_iot_cloud_output` variable. You can use it to verify the lambda
|
||||
@@ -353,9 +359,11 @@ a. IoT cloud output:
|
||||
results such as bounding box coordinates of objects, class label, and
|
||||
class confidence are published.
|
||||
|
||||
Follow the instructions here to `view the output on IoT cloud`_.
|
||||
Refer to the AWS documentation
|
||||
`Verify the Lambda Function Is Running on the Device`_ for instructions on
|
||||
how to view the output on IoT cloud.
|
||||
|
||||
b. Kinesis streaming:
|
||||
#. Kinesis streaming:
|
||||
|
||||
This option enables inference output to be streamed from the edge device
|
||||
to cloud using Kinesis [3] streams when :command:`enable_kinesis_output` is set
|
||||
@@ -364,7 +372,7 @@ b. Kinesis streaming:
|
||||
Kinesis stream name, Kinesis shard, and AWS region in the AWS Greengrass
|
||||
samples.
|
||||
|
||||
c. Cloud storage using AWS S3 bucket:
|
||||
#. Cloud storage using AWS S3 bucket:
|
||||
|
||||
When the :command:`enable_s3_jpeg_output` variable is set to True, it enables
|
||||
uploading and storing processed frames (in jpeg format) in an AWS S3
|
||||
@@ -372,7 +380,7 @@ c. Cloud storage using AWS S3 bucket:
|
||||
Greengrass samples to store the JPEG images. The images are named using the
|
||||
timestamp and uploaded to S3.
|
||||
|
||||
d. Local storage:
|
||||
#. Local storage:
|
||||
|
||||
When the :command:`enable_s3_jpeg_output` variable is set to True, it enables
|
||||
storing processed frames (in jpeg format) on the edge device. The images
|
||||
@@ -382,9 +390,9 @@ d. Local storage:
|
||||
References
|
||||
**********
|
||||
|
||||
1. AWS Greengrass: https://aws.amazon.com/greengrass/
|
||||
2. AWS Lambda: https://aws.amazon.com/lambda/
|
||||
3. AWS Kinesis: https://aws.amazon.com/kinesis/
|
||||
#. AWS Greengrass: https://aws.amazon.com/greengrass/
|
||||
#. AWS Lambda: https://aws.amazon.com/lambda/
|
||||
#. AWS Kinesis: https://aws.amazon.com/kinesis/
|
||||
|
||||
.. _Edge-Analytics-FaaS: https://github.com/intel/Edge-Analytics-FaaS/tree/v1.0/AWS%20Greengrass
|
||||
|
||||
@@ -396,7 +404,7 @@ References
|
||||
|
||||
.. _greengrass_object_detection_sample_ssd.py: https://github.com/intel/Edge-Analytics-FaaS/blob/v1.0/AWS%20Greengrass/greengrass_object_detection_sample_ssd.py
|
||||
|
||||
.. _converting deep learning models to Intermediate Representation using Model Optimizer: https://software.intel.com/en-us/articles/OpenVINO-ModelOptimizer
|
||||
.. _Model Optimizer Developer Guide: https://software.intel.com/en-us/articles/OpenVINO-ModelOptimizer
|
||||
|
||||
.. _AWS Greengrass Developer Guide: https://docs.aws.amazon.com/greengrass/latest/developerguide/what-is-gg.html
|
||||
|
||||
@@ -406,14 +414,10 @@ References
|
||||
|
||||
.. _Configure the Lambda Function for AWS IoT Greengrass: https://docs.aws.amazon.com/greengrass/latest/developerguide/config-lambda.html
|
||||
|
||||
.. _local resources and access privileges: https://docs.aws.amazon.com/greengrass/latest/developerguide/access-local-resources.html
|
||||
.. _Access Local Resources with Lambda Functions and Connectors: https://docs.aws.amazon.com/greengrass/latest/developerguide/access-local-resources.html
|
||||
|
||||
.. _deploy the lambda function to AWS Greengrass core device: https://docs.aws.amazon.com/greengrass/latest/developerguide/configs-core.html
|
||||
.. _Deploy Cloud Configurations to an AWS IoT Greengrass Core Device: https://docs.aws.amazon.com/greengrass/latest/developerguide/configs-core.html
|
||||
|
||||
.. _Edge-optmized models repository: https://github.com/intel/Edge-optimized-models
|
||||
|
||||
.. _view the output on IoT cloud: https://docs.aws.amazon.com/greengrass/latest/developerguide/lambda-check.html
|
||||
|
||||
.. _this link to add local resources and access privileges: https://docs.aws.amazon.com/greengrass/latest/developerguide/access-local-resources.html
|
||||
.. _Verify the Lambda Function Is Running on the Device: https://docs.aws.amazon.com/greengrass/latest/developerguide/lambda-check.html
|
||||
|
||||
.. _Create and Package a Lambda Function: https://docs.aws.amazon.com/greengrass/latest/developerguide/create-lambda.html
|
||||
|
||||
+97
-81
@@ -3,10 +3,10 @@
|
||||
mixer
|
||||
#####
|
||||
|
||||
**mixer** is the tool used by the |CL-ATTR| team to generate official update content
|
||||
and releases. The update content generated by mixer is then consumed by swupd on
|
||||
a downstream client. The same mixer tool is available as part of |CL| to create
|
||||
your own customized update content and releases.
|
||||
**mixer** is the tool used by the |CL-ATTR| team to generate official update
|
||||
content and releases. The update content generated by mixer is then consumed
|
||||
by swupd on a downstream client. The same mixer tool is available as part of
|
||||
|CL| to create your own customized update content and releases.
|
||||
|
||||
.. contents::
|
||||
:local:
|
||||
@@ -21,19 +21,12 @@ mixer uses the following sources as inputs to generate update content:
|
||||
* Locally-defined bundles with their corresponding local RPM packages
|
||||
* Locally-defined bundles with upstream RPM packages
|
||||
|
||||
Using the mixer tool, you select which set of content from these sources will be
|
||||
part of your update. You can select content from each of these sources to make a
|
||||
unique combination of functionality for your custom update content, known as a
|
||||
**mix**.
|
||||
Using the mixer tool, you select which set of content from these sources
|
||||
will be part of your update. You can select content from each of these sources to make a unique combination of functionality for your custom update content, known as a **mix**.
|
||||
|
||||
The update content that mixer generates consists of various pieces of OS
|
||||
content, update metadata, as well as a complete image. The OS content includes
|
||||
all files in an update, as well as zero- and delta-packs for improved update
|
||||
performance. The update metadata, stored as manifests, describes all of the bundle
|
||||
information for the update. Update content produced by mixer is then published
|
||||
to a web server and consumed by clients via swupd. Refer to
|
||||
:ref:`swupd <swupd-guide>` for additional information regarding updates and
|
||||
update content.
|
||||
content, update metadata, as well as a complete image. The OS content
|
||||
includes all files in an update, as well as zero- and delta-packs for improved update performance. The update metadata, stored as manifests, describes all of the bundle information for the update. Update content produced by mixer is then published to a web server and consumed by clients via swupd. Refer to :ref:`swupd <swupd-guide>` for additional information regarding updates and update content.
|
||||
|
||||
How it works
|
||||
************
|
||||
@@ -67,7 +60,7 @@ Prerequisites
|
||||
If you use a proxy server, you must set your proxy environment variables and
|
||||
create a proxy configuration file for the Docker daemon and container.
|
||||
|
||||
Consult your IT department for the correct values if you are behind a
|
||||
Consult your IT department for the correct values if you are behind a
|
||||
corporate proxy.
|
||||
|
||||
Refer to `Configure Docker proxy info`_ for instruction.
|
||||
@@ -232,8 +225,6 @@ mixer for a new mix.
|
||||
CONTENTURL="http://192.168.25.52"
|
||||
VERSIONURL="http://192.168.25.52"
|
||||
|
||||
|
||||
|
||||
Example 2: Create a simple mix
|
||||
==============================
|
||||
|
||||
@@ -253,6 +244,27 @@ set to get a smaller kernel image, which will also be faster to load.
|
||||
mixer bundle remove kernel-native
|
||||
mixer bundle add kernel-kvm
|
||||
|
||||
#. In this case, we will add the `editors` bundle from upstream, but we will
|
||||
remove the `joe` editor.
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
mixer bundle add editors
|
||||
mixer bundle edit editors
|
||||
|
||||
#. Use an editor and manually remove `joe` from the bundle definition.
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$EDITOR ./local-bundles/editors
|
||||
|
||||
#. List the bundles in the mix again to confirm removal.
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
mixer bundle list --tree
|
||||
|
||||
|
||||
#. Build bundles:
|
||||
|
||||
.. code-block:: bash
|
||||
@@ -343,8 +355,8 @@ Example 3: Deploy updates to target
|
||||
===================================
|
||||
|
||||
The image created in Example 2 is directly bootable in QEMU. In this example,
|
||||
we'll boot the image from Example 2 to verify it, and update the image from mix
|
||||
version 10 (from which the image was built), to mix version 20.
|
||||
we'll boot the image from Example 2 to verify it, and update the image from
|
||||
mix version 10 (from which the image was built), to mix version 20.
|
||||
|
||||
#. Set up the QEMU environment.
|
||||
|
||||
@@ -381,13 +393,17 @@ version 10 (from which the image was built), to mix version 20.
|
||||
swupd bundle-list
|
||||
swupd bundle-list -a
|
||||
|
||||
.. note::
|
||||
|
||||
You cannot see the curl bundle that you added in Example 2 because
|
||||
your mix is still on version 10.
|
||||
#. Now we will add the `editors` bundle that we modified.
|
||||
|
||||
Check for updates. You should see that version 20 is available. Use swupd to
|
||||
update your mix:
|
||||
.. code-block:: bash
|
||||
|
||||
swupd bundle add editors
|
||||
|
||||
#. Try to start the `joe` editor. It should not appear because we removed it
|
||||
from the original `editors` bundle.
|
||||
|
||||
#. Next we will update from version 10 to 20 to capture the newly
|
||||
available bundles. Use :command:`swupd` to update your mix:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
@@ -395,7 +411,7 @@ version 10 (from which the image was built), to mix version 20.
|
||||
swupd update
|
||||
swupd bundle-list -a
|
||||
|
||||
Now your mix should be at version 20 and curl is now available. Try using
|
||||
#. Now your mix should be at version 20 and curl is now available. Try using
|
||||
curl. This will fail because curl is not yet installed:
|
||||
|
||||
.. code-block:: console
|
||||
@@ -416,6 +432,7 @@ version 10 (from which the image was built), to mix version 20.
|
||||
|
||||
poweroff
|
||||
|
||||
|
||||
.. Example: Create a mix with custom RPM
|
||||
.. -------------------------------------
|
||||
.. TODO future example to show copy into local-rpms...
|
||||
@@ -538,30 +555,34 @@ Format version
|
||||
|
||||
Compatible versions of an OS are tracked with an OS *compatibility epoch*.
|
||||
Versions of an OS within an epoch are fully compatible and can update to any
|
||||
other version within that epoch. The compatibility epoch is set as the `Format`
|
||||
variable in the :file:`mixer.state` file. Variables in the :file:`mixer.state`
|
||||
are used by mixer between executions and should not be manually changed.
|
||||
other version within that epoch. The compatibility epoch is set as the
|
||||
`Format` variable in the :file:`mixer.state` file. Variables in the
|
||||
:file:`mixer.state` are used by mixer between executions and should not be
|
||||
manually changed.
|
||||
|
||||
If `Format` increments to a new epoch (a "format bump"), the OS has changed in
|
||||
such a way that updating from build M in format X to build N in format Y will
|
||||
not work. Generally, this scenario occurs when the software updater or the software
|
||||
has a change such that it is no longer compatible with the previous update
|
||||
scheme, or when a package is removed from the update stream and the update
|
||||
must ensure the files associated with that package are removed from the system.
|
||||
A format bump is like modifying the foundation of a house to create a new
|
||||
level. If `Format` increments to a new epoch (a "format bump"), the OS has
|
||||
changed in such a way that updating from build A in format X to build B in
|
||||
format Y will not work.
|
||||
|
||||
A format bump is required when:
|
||||
|
||||
* The software updater, :command:`swupd`, or the software is no longer
|
||||
compatible with the previous update scheme
|
||||
|
||||
* A package is removed from the update stream and the update must ensure the
|
||||
files associated with that package are removed from the system
|
||||
|
||||
Using a format increment, we make sure pre- and co-requisite changes flow out
|
||||
with proper ordering. The updated client will only update to the latest
|
||||
release in its respective format version, unless overridden by command line
|
||||
flags. In this way, we can guarantee that all clients update to the final version
|
||||
in their given format.
|
||||
flags. In this way, we can guarantee that all clients update to the final
|
||||
version in their given format.
|
||||
|
||||
The given format *must* contain all the changes needed to understand the content
|
||||
built in the next format. Only after reaching the final release in the old
|
||||
format can a client continue to update to releases in the new format.
|
||||
The given format *must* contain all the changes needed to understand the content built in the next format. Only after reaching the final release in the old format can a client continue to update to releases in the new format.
|
||||
|
||||
The format version is incremented only when a compatibility breakage is
|
||||
introduced. Normal updates, such as updating a software package, do not require a
|
||||
format increment.
|
||||
introduced. Normal updates, such as updating a software package, do not require a format increment.
|
||||
|
||||
.. rst-class:: content-collapse
|
||||
|
||||
@@ -569,44 +590,41 @@ Bundles
|
||||
=======
|
||||
|
||||
mixer stores information about the bundles included in a mix in a flat file
|
||||
called :file:`mixbundles`, which is located in the path set by the VERSIONS_PATH
|
||||
variable in :file:`builder.conf`. :file:`mixbundles` is automatically created
|
||||
when the mix is initiated. mixer will refresh the file each time you change the
|
||||
bundles in the mix.
|
||||
called :file:`mixbundles`, which is located in the path set by the VERSIONS_PATH variable in :file:`builder.conf`. :file:`mixbundles` is automatically created when the mix is initiated. mixer will refresh the file each time you change the bundles in the mix.
|
||||
|
||||
Bundles can include other bundles. Nested bundles can themselves include other
|
||||
bundles. If you see an unexpected bundle in your mix, it is likely a nested
|
||||
bundle in one of the bundles you explicitly added.
|
||||
Bundles can include other bundles. Nested bundles can themselves include
|
||||
other bundles. If you see an unexpected bundle in your mix, it is likely a
|
||||
nested bundle in one of the bundles you explicitly added.
|
||||
|
||||
A bundle will fill into one of two categories: upstream or local. Upstream
|
||||
bundles are those provided by |CL|. Local bundles are either modified upstream
|
||||
bundles or new local bundles.
|
||||
bundles are those provided by |CL|. Local bundles are either modified upstream bundles or new local bundles.
|
||||
|
||||
Upstream bundles
|
||||
----------------
|
||||
|
||||
mixer automatically downloads and caches upstream bundle definition files. These
|
||||
definition files are stored in the upstream-bundles directory in the workspace.
|
||||
Do not modify the files in this directory. This directory is simply a mirror for
|
||||
mixer to use. mixer will automatically delete the contents of this directory
|
||||
before repopulating it on-the-fly if a new version must be downloaded.
|
||||
mixer automatically downloads and caches upstream bundle definition files.
|
||||
These definition files are stored in the upstream-bundles directory in the
|
||||
workspace. Do not modify the files in this directory. This directory is
|
||||
simply a mirror for mixer to use. mixer will automatically delete the
|
||||
contents of this directory before repopulating it on-the-fly if a new
|
||||
version must be downloaded.
|
||||
|
||||
The mixer tool automatically caches the bundles for the |CL| version configured
|
||||
in the :file:`upstreamversion` file. mixer also cleans up old versions once they
|
||||
are no longer needed.
|
||||
The mixer tool automatically caches the bundles for the |CL| version
|
||||
configured in the :file:`upstreamversion` file. mixer also cleans up old
|
||||
versions once they are no longer needed.
|
||||
|
||||
Local bundles
|
||||
-------------
|
||||
|
||||
Local bundles are bundles that you create, or are edited versions of upstream
|
||||
bundles. Local bundle definition files are stored in the local-bundles directory
|
||||
in the workspace. The LOCAL_BUNDLE_DIR variable sets the path of this directory
|
||||
in the :file:`builder.conf` file.
|
||||
bundles. Local bundle definition files are stored in the local-bundles
|
||||
directory in the workspace. The LOCAL_BUNDLE_DIR variable sets the path of this directory in the :file:`builder.conf` file.
|
||||
|
||||
*mixer always checks for local bundles first and the upstream bundles second.*
|
||||
So bundles in the local-bundles directory will always take precedence over any
|
||||
upstream bundles that have the same name. This precedence enables you to copy
|
||||
upstream bundles locally, and edit into a local variation.
|
||||
*mixer always checks for local bundles first and the upstream bundles
|
||||
second.* So bundles in the local-bundles directory will always take
|
||||
precedence over any upstream bundles that have the same name. This
|
||||
precedence enables you to copy upstream bundles locally, and edit into a
|
||||
local variation.
|
||||
|
||||
Bundle configuration
|
||||
--------------------
|
||||
@@ -622,13 +640,11 @@ file in your favorite editor, making the desired edits, and saving your changes.
|
||||
.. note::
|
||||
|
||||
Removing bundles from a mix: By default, removing a bundle will only
|
||||
remove the bundle from the mix. The local bundle definition file will still
|
||||
remain. To completely remove a bundle, including its local bundle definition
|
||||
file, use the :command:`--local` flag.
|
||||
remove the bundle from the mix. The local bundle definition file will
|
||||
still remain. To completely remove a bundle, including its local bundle definition file, use the :command:`--local` flag.
|
||||
|
||||
If you remove the bundle definition file for a local, edited version of an
|
||||
upstream bundle in a mix, the mix reverts to reference the original upstream
|
||||
version of the bundle.
|
||||
upstream bundle in a mix, the mix reverts to reference the original upstream version of the bundle.
|
||||
|
||||
.. rst-class:: content-collapse
|
||||
|
||||
@@ -656,8 +672,8 @@ Pull Docker container manually (optional)
|
||||
-----------------------------------------
|
||||
|
||||
By default, mixer automatically pulls a Docker container for mixing if one
|
||||
does not already exist. If you need to troubleshoot the mixer container, it may
|
||||
be useful to manually pull a mixer Docker container.
|
||||
does not already exist. If you need to troubleshoot the mixer container, it
|
||||
may be useful to manually pull a mixer Docker container.
|
||||
|
||||
Versions of the mixer Docker container are available under the tags for the
|
||||
`clearlinux/mixer repo <https://hub.docker.com/r/clearlinux/mixer/tags/>`_
|
||||
@@ -695,7 +711,7 @@ If needed, use these steps to configure the Docker proxy information.
|
||||
.. code-block:: bash
|
||||
|
||||
sudo mkdir -p /etc/systemd/system/docker.service.d
|
||||
|
||||
|
||||
#. Create :file:`/etc/systemd/system/docker.service.d/http-proxy.conf` and
|
||||
add the following using your own proxy values:
|
||||
|
||||
@@ -711,7 +727,7 @@ If needed, use these steps to configure the Docker proxy information.
|
||||
|
||||
sudo systemctl daemon-reload
|
||||
|
||||
Configure the Docker container proxies, to pass proxy settings to
|
||||
Configure the Docker container proxies, to pass proxy settings to
|
||||
containers:
|
||||
|
||||
#. Create a directory for your container config:
|
||||
@@ -764,8 +780,8 @@ a firewall.
|
||||
Set up a nginx web server for mixer
|
||||
===================================
|
||||
|
||||
A web server is needed to host your update content. In this example, we use the
|
||||
nginx web server, which comes with |CL|.
|
||||
A web server is needed to host your update content. In this example, we use
|
||||
the nginx web server, which comes with |CL|.
|
||||
|
||||
Set up a nginx web server for mixer with the following steps:
|
||||
|
||||
@@ -781,9 +797,9 @@ Set up a nginx web server for mixer with the following steps:
|
||||
|
||||
sudo mkdir -p /var/www
|
||||
|
||||
#. Create a symbolic link between your workspace updates and the updates on the
|
||||
local nginx web server. In this example, `$HOME/mixer` is the workspace for
|
||||
the mix.
|
||||
#. Create a symbolic link between your workspace updates and the updates on
|
||||
the local nginx web server. In this example, `$HOME/mixer` is the
|
||||
workspace for the mix.
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
|
||||
Reference in New Issue
Block a user