Merge pull request #2979 from vespa-engine/bratseth/no-vespa-deploy

Remove references to vespa-deploy

en/application-packages.html

@@ -77,7 +77,7 @@ <h3 id="convergence">Convergence</h3>
 <h3 id="file-distribution">File distribution</h3>
 <p>
   The application package can have components and other large files.
-  At <em>vespa-deploy prepare</em>, these files are distributed to the nodes:
+  At <em>vespa prepare</em>, these files are distributed to the nodes:
 </p>
 <ul>
   <li>Components (i.e bundles)</li>
@@ -242,22 +242,4 @@ <h2 id="further-reads">Further reads</h2>
         vespa-remove-index</a> to wipe content nodes</li>
     </ol>
   </li>
-  <li>
-    <p>
-      See <a href="/en/operations-selfhosted/vespa-cmdline-tools.html#vespa-deploy">vespa-deploy</a> for an alternative debug tool
-      for local deployments - use it to:
-    </p>
-    <ol>
-      <li><em>prepare:</em> Upload, validate and distribute to nodes</li>
-      <li>
-        <em>activate:</em> Activate on all nodes -
-        this reloads the application <a href="components/bundles.html">bundles</a>, while serving.
-        It waits for prepare to complete before running activation.
-      </li>
-    </ol>
-    <p>Find more details in the <a href="reference/application-packages-reference.html#deploy">reference</a>.</p>
-    {% include important.html content='The <em>prepare</em> step does not validate
-    <span style="text-decoration: underline">all</span> changes.
-    E.g., the container itself is not started with the bundles and bundle configuration at <em>prepare</em>-time.' %}
-  </li>
 </ul>

en/config-introduction.html

@@ -96,14 +96,14 @@ <h2 id="configuration-assembly">Configuration assembly</h2>
   including which nodes belong in the system,
   which services they should run and the configuration of these services and their components.
   When the application deployer wants to change the application,
-  <a href="application-packages.html#deploy">vespa-deploy prepare</a> is issued to a config server,
+  <a href="application-packages.html#deploy">vespa prepare</a> is issued to a config server,
   with the application package as argument.
 </p>
 <p>
   At this point the system model is assembled and validated
   and any feedback is issued to the deployer.
   If the deployer decides to make the new configuration active,
-  a <a href="application-packages.html#deploy">vespa-deploy activate</a> is then issued,
+  a <a href="application-packages.html#deploy">vespa activate</a> is then issued,
   causing the config server cluster to switch to the new system model
   and respond with new configs on any active subscriptions
   where the new system model caused the config to change.

en/contributing/configapi-dev-java.html

@@ -153,7 +153,7 @@ <h2 id="unit-testing">Unit testing config</h2>
 Use this to set up config fixtures for unit tests.
 The <code>ConfigSubscriber</code> has a <code>reload()</code> method
 which is used in tests to force the subscriptions into a new
-generation. It emulates a <code>vespa-deploy activate</code> operation after
+generation. It emulates a <code>vespa activate</code> operation after
 you have updated the <code>ConfigSet</code>.
 </p><p>
 A full example can be found in

en/contributing/configapi-dev.html

@@ -176,16 +176,13 @@ <h2 id="setting-up">Setting Up a Running System</h2>
 <p>
 To get a running system, first install the cloudconfig package,
 start the config server, then deploy the application:
-<pre>
-$ vespa-deploy upload /path/to/app/folder
-</pre>
 Prepare the application:
 <pre>
-$ vespa-deploy prepare /path/to/app/folder
+$ vespa prepare /path/to/app/folder
 </pre>
 Activate the application:
 <pre>
-$ vespa-deploy activate /path/to/app/folder
+$ vespa activate /path/to/app/folder
 </pre>
 <p>
 Then, start vespa. This will start the application and pass it its config id
@@ -278,7 +275,7 @@ <h3 id="guidelines-dependent-static">Dependent Static Configs</h3>
 to the same <strong>generation</strong>.
 </p>
   {% include note.html content="A generation is a monotonically increasing number which is increased
-  each time an application is deployed with <code>vespa-deploy</code>.
+  each time an application is deployed with <code>vespa deploy</code>.
   Certain applications may require that all configs are of the same generation to ensure consistency,
   especially container-like applications.
   All configs subscribed to by a ConfigSubscriber are guaranteed to be of the same generation."%}

en/document-processing.html

@@ -414,10 +414,10 @@ <h2 id="reconfiguring-document-processing">(Re)configuring Document Processing</
 </pre>
 <p>
   Changing chain ids, components in a chain, component configuration and schema mapping all takes effect after
-  <a href="application-packages.html#deploy">vespa-deploy activate</a> -
+  <a href="application-packages.html#deploy">vespa activate</a> -
   no restart required.
   Changing a <em>cluster name</em> (i.e. the container id)
-  requires a restart of docproc services after <em>vespa-deploy activate</em>.
+  requires a restart of docproc services after <em>vespa activate</em>.
 </p><p>
   Note when adding or modifying a processing chain in a running cluster;
   if at the same time deploying a <em>new</em> document processor

en/jdisc/container-components.html

@@ -227,7 +227,7 @@ <h3 id="deploying-the-application-package">Deploying the Application Package</h3
   Set up a Vespa instance using the <a href="../vespa-quick-start.html">quick start</a>.
   Once the component and the config are added to the application package,
   it can be <a href="../application-packages.html#deploy">deployed</a>
-  by running <code>vespa-deploy</code>.
+  by running <code>vespa deploy</code>.
   These steps will copy any changed bundles to the nodes in the cluster which needs them
   and switch queries over to running the new component versions.
 </p><p>
@@ -363,7 +363,7 @@ <h2 id="troubleshooting">Troubleshooting</h2>
 <h3 id="container-start">Container start</h3>
 <p>
   If there is some error in the application package,
-  it will usually be detected during the <code>vespa-deploy prepare</code> step and cause an error message.
+  it will usually be detected during the <code>vespa prepare</code> step and cause an error message.
   However, some classes of errors are only detected once the application is deployed.
   When redeploying an application, it is therefore recommended watching the vespa log by running:
 </p>
@@ -376,7 +376,7 @@ <h3 id="container-start">Container start</h3>
 </pre>
 <p>
   If this message does not appear after a reasonable amount of time
-  after completion of <code>vespa-deploy activate</code>,
+  after completion of <code>vespa activate</code>,
   one will see some errors or warnings instead, that will help debug the application.
 </p>
 

en/operations-selfhosted/admin-procedures.html

@@ -241,9 +241,9 @@ <h2 id="monitor-distance-to-ideal-state">Monitor distance to ideal state</h2>
 
 <h2 id="cluster-configuration">Cluster configuration</h2>
 <ul>
-  <li>Running <code>vespa-deploy prepare</code> will not change served
-    configurations until <code>vespa-deploy activate</code> is run.
-    <code>vespa-deploy prepare</code> will warn about all config changes that require restart.
+  <li>Running <code>vespa prepare</code> will not change served
+    configuration until <code>vespa activate</code> is run.
+    <code>vespa prepare</code> will warn about all config changes that require restart.
   </li><li>
     Refer to <a href="../schemas.html">schemas</a> for how to add/change/remove these.
   </li><li>
@@ -330,7 +330,7 @@ <h2 id="add-or-remove-services-on-a-node">Add or remove services on a node</h2>
 <p>
   It is possible to run multiple Vespa services on the same host.
   If changing the services on a given host,
-  stop Vespa on the given host before running <code>vespa-deploy activate</code>.
+  stop Vespa on the given host before running <code>vespa activate</code>.
   This is because the services are dynamically allocated port numbers,
   depending on what is running on the host.
   Consider if some of the services changed are used by services on other hosts.
@@ -339,7 +339,7 @@ <h2 id="add-or-remove-services-on-a-node">Add or remove services on a node</h2>
 <ol>
   <li>Edit <em>services.xml</em> and <em>hosts.xml</em></li>
   <li>Stop Vespa on the nodes that have changes</li>
-  <li>Run <code>vespa-deploy prepare</code> and <code>vespa-deploy activate</code></li>
+  <li>Run <code>vespa prepare</code> and <code>vespa activate</code></li>
   <li>Start Vespa on the nodes that have changes</li>
 </ol>
 

en/operations-selfhosted/config-proxy.html

@@ -66,7 +66,7 @@
 The tool displays heap usage for the proxy, displays the configs cached and flushes the cache.
 View the pending requests it has against the server(s).
 A pending request is the same as a subscription of server data,
-the requests are held open until the data changes on the server, through a <em>vespa-deploy activate</em>.
+the requests are held open until the data changes on the server, through a <em>vespa activate</em>.
 </p>
 
 

en/operations-selfhosted/configuration-server.html

@@ -248,7 +248,7 @@ <h2 id="scaling-up">Scaling up</h2>
     first. Config server will log which servers are configured when starting up to vespa log.
   </li><li>
     Update <em>services.xml</em> and <em>hosts.xml</em> with the new set of config servers,
-    then <em>vespa-deploy prepare</em> and <em>vespa-deploy activate</em>.
+    then <em>vespa prepare</em> and <em>vespa activate</em>.
   </li>
   <li>
     Restart other nodes one by one to start using the new config servers.
@@ -299,10 +299,10 @@ <h2 id="zookeeper">ZooKeeper</h2>
   similar to a file system.
 </p>
 <p>
-  At <a href="/en/application-packages.html#deploy">vespa-deploy prepare</a>, the application's files,
+  At <a href="/en/application-packages.html#deploy">vespa prepare</a>, the application's files,
   along with global configurations, are stored in ZooKeeper.
   The application data is stored under <em>/config/v2/tenants/default/sessions/[sessionid]/userapp</em>.
-  At <a href="/en/application-packages.html#deploy">vespa-deploy activate</a>,
+  At <a href="/en/application-packages.html#deploy">vespa activate</a>,
   the newest application is activated <em>live</em>
   by writing the session id into <em>/config/v2/tenants/default/applications/default:default:default</em>.
   It is at that point the other nodes get configured.
@@ -344,8 +344,8 @@ <h3 id="zookeeper-recovery">ZooKeeper recovery</h3>
   <li><a href="/en/operations-selfhosted/vespa-cmdline-tools.html#vespa-stop-configserver">vespa-stop-configserver</a></li>
   <li><a href="/en/operations-selfhosted/vespa-cmdline-tools.html#vespa-configserver-remove-state">vespa-configserver-remove-state</a></li>
   <li><a href="/en/operations-selfhosted/vespa-cmdline-tools.html#vespa-start-configserver">vespa-start-configserver</a></li>
-  <li><a href="/en/operations-selfhosted/vespa-cmdline-tools.html#vespa-deploy">vespa-deploy</a> prepare &lt;application path&gt;</li>
-  <li><a href="/en/operations-selfhosted/vespa-cmdline-tools.html#vespa-deploy">vespa-deploy</a> activate</li>
+  <li><a href="/en/vespa-cli.html#deployment">vespa</a> prepare &lt;application path&gt;</li>
+  <li><a href="/en/vespa-cli.html#deployment">vespa</a> activate</li>
 </ol>
 <p>
   This procedure completely cleans out ZooKeeper's internal data snapshots and deploys from scratch.
@@ -462,7 +462,7 @@ <h2 id="troubleshooting">Troubleshooting</h2>
             http://localhost:19071/application/v2/tenant/default/application/default</a>
           displays active config generation and should be the same on all servers,
           and the same as in response from running
-          <a href="/en/operations-selfhosted/vespa-cmdline-tools.html#vespa-config-status">vespa-deploy</a>
+          <a href="/en/vespa-cli.html#deployment">vespa deploy</a>
         </p>
       </td>
     </tr><tr>
@@ -476,7 +476,7 @@ <h2 id="troubleshooting">Troubleshooting</h2>
         </p>
         <p>
           Deploying applications will take longer,
-          as <a href="/en/operations-selfhosted/vespa-cmdline-tools.html#vespa-deploy">vespa-deploy</a>
+          as <a href="/en/vespa-cli.html#deployment">vespa deploy</a>
           will not be able to complete a deployment on all servers when one of them is down.
           If this is troublesome, lower the <a href="#zookeeper-barrier-timeout">barrier timeout</a> -
           (default value is 120 seconds).

en/operations-selfhosted/live-upgrade.html

@@ -51,7 +51,7 @@
       or use <a href="/en/operations-selfhosted/configuration-server.html#troubleshooting">health checks</a>.
     </li><li>
       Redeploy and activate the application:
-      <pre>$ <a href="/en/operations-selfhosted/vespa-cmdline-tools.html#vespa-deploy">vespa-deploy</a> prepare &lt;app&gt; &amp;&amp; vespa-deploy activate</pre>
+      <pre>$ <a href="/en/vespa-cli.html#deployment">vespa</a> prepare &lt;app&gt; &amp;&amp; vespa activate</pre>
     </li><li>
       The other nodes in the system will not receive config until they are upgraded to the new version
       (there will be warnings in vespa log containing "Request callback failed: UNKNOWN_VESPA_VERSION"

en/operations-selfhosted/mtls.md

@@ -276,15 +276,6 @@ in the Subject / Subject Alternative Names extensions.
 [Disable hostname validation](/en/reference/mtls.html#top-level-elements) if this is not the case.
 
 
-### Application deployment fails with `SEC_ERROR_BAD_KEY`
-
-This is usually caused by running `vespa-deploy` from an OS that has an old version of `curl` (such as on CentOS 7).
-Older versions of the NSS cryptographic library used by `curl` do not support elliptic curve (EC) keys.
-
-To resolve this, either run `vespa-deploy` from an environment with a sufficiently new version of `curl` or
-use RSA keys instead of EC keys.
-
-
 ## Appendix A: setting up with a self-signed Certificate Authority
 
 Our goal is to create cryptographic keys and certificates that can be used by Vespa for secure mTLS

en/operations-selfhosted/vespa-cmdline-tools.html

@@ -250,8 +250,10 @@ <h2 id="vespa-config-status">vespa-config-status</h2>
 
 <h2 id="vespa-deploy">vespa-deploy</h2>
 <p>
-<em>vespa-deploy</em> deploys an application package,
-using the <a href="/en/reference/deploy-rest-api-v2.html">deploy API</a>.
+<em>vespa-deploy</em> is a standalone tool to deploy an application package.
+Prefer the <a href="/en/vespa-cli.html#deployment">Vespa CLI</a> instead.
+Under the hood deployment uses the the <a href="/en/reference/deploy-rest-api-v2.html">deploy REST API</a>,
+which you can also use directly.
 Refer to the <a href="/en/reference/application-packages-reference.html#deploy">deploy reference</a> for details.
 </p><p>
 Synopsis: <code>vespa-deploy [-h] [-v] [-n] [-f] [-t timeout] [-c hostname] [-p port] prepare|activate|upload|fetch|help [args]</code>

en/performance/container-tuning.html

@@ -143,8 +143,8 @@ <h3 id="config-server-and-config-proxy">Config Server and Config Proxy</h3>
   Consequently, one must use configuration variables
   to set the JVM parameters for the config server and config proxy.
   They also need to be restarted (<em>services</em> in the config proxy's case) after a change,
-  but one does <em>not</em> need to <em>vespa-deploy prepare</em>
-  or <em>vespa-deploy activate</em> first. Example:
+  but one does <em>not</em> need to <em>vespa prepare</em>
+  or <em>vespa activate</em> first. Example:
 </p>
 <pre>
 VESPA_CONFIGSERVER_JVMARGS      -Xlog:gc

en/performance/profiling.html

@@ -160,7 +160,7 @@ <h3 id="install-yourkit-profiler-on-the-container">Install YourKit profiler on t
     Disabling the freezedetector stops the container from shutting down during profiling.</li>
   <li>Re-deploy the application:
 <pre>
-$ vespa-deploy prepare appdir &amp;&amp; vespa-deploy activate
+$ vespa deploy appdir
 </pre></li>
   <li>restart Vespa on the node that runs the Container</li>
 </ul>

en/query-rewriting.html

@@ -182,7 +182,7 @@ <h2 id="configuration">Configuration</h2>
 To deactivate the default rules,
 add <a href="reference/query-api-reference.html#rules.off">rules.off</a> to the query.
 </p><p>
-The rules can safely be updated at any time by running <code>vespa-deploy prepare</code> again.
+The rules can safely be updated at any time by running <code>vespa prepare</code> again.
 If there are errors in the rule bases, they will not be updated,
 and the errors will be reported on the command line.
 </p><p>

en/reference/application-packages-reference.html

@@ -9,7 +9,7 @@
 This is the <a href="../application-packages.html">application package</a> reference.
 An application package is the deployment unit in Vespa.
 To deploy an application, create an application package
-and <a href="/en/operations-selfhosted/vespa-cmdline-tools.html#vespa-deploy">vespa-deploy</a> or
+and <a href="/en/vespa-cli.html#deployment">vespa deploy</a> or
 use the <a href="deploy-rest-api-v2.html">deploy API</a>.
 The application package is a directory of files and subdirectories:
 </p>
@@ -187,8 +187,7 @@ <h2 id="deploy">Deploy</h2>
 $ zip -r ../app.zip .
 </pre>
 <p>
-  Use whatever name for the zip file - then refer to the file instead of the path in deploy commands -
-  <a href="/en/operations-selfhosted/vespa-cmdline-tools.html#vespa-deploy">example</a>.
+  Use any name for the zip file - then refer to the file instead of the path in <a href="/en/vespa-cli.html#deployment">deploy</a> commands.
 </p>
 {% include important.html  content='Using <code>tar</code> / <code>gzip</code> is not supported.
 <a href="https://github.com/vespa-engine/vespa/issues/17837">Details</a>.'%}

en/reference/deploy-rest-api-v2.html

@@ -54,8 +54,7 @@
 </tbody>
 </table>
 <p>
-  Use <a href="../vespa-cli.html">Vespa CLI</a> to deploy from the command line,
-  or use the <a href="/en/operations-selfhosted/vespa-cmdline-tools.html#vespa-deploy">vespa-deploy</a> tool.
+  Use <a href="../vespa-cli.html">Vespa CLI</a> to deploy from the command line.
 </p>
 {% include note.html content='Use <a href="../application-packages.html#convergence">convergence</a>
 to confirm configuration activation on all nodes.' %}