1
0
mirror of https://github.com/docker/docs.git synced 2026-11-05 00:14:17 +03:00
Commit Graph

6 Commits

Author SHA1 Message Date
Mary Anthony
983f51fb98 Updating with fixes from web release
Updating with comments
Clarifying installation instructions
Entering second round of Dan's comments

Signed-off-by: Mary Anthony <mary@docker.com>
2016-11-05 21:47:00 -07:00
Mary Anthony
79802a098e Updating with metadata for website
Closes #371: Added metadata for web build
Updating with Dan's comments

Signed-off-by: Mary Anthony <mary@docker.com>
2016-11-05 21:46:54 -07:00
Mary Anthony
5169311224 Updating with Hugo metadata
Signed-off-by: Mary Anthony <mary@docker.com>
2016-11-05 21:46:46 -07:00
Mary Anthony
b868e6b85e Updating install; Initial docs rearrangement
Creating specs directory; may be moved later
Adding fix for Issue #348
Adding in updates for networking
Updating with Dan's comments: removing old -beta
Updating networking after talking to Madhu
Updated install with HA as optional
Moved HA spec into specs
Did "customer-facing" HA page
Renamed server > controller in docs
Entering comments from reviewers

Signed-off-by: Mary Anthony <mary@docker.com>
2016-11-05 21:46:41 -07:00
Daniel Hiltgen
4a02cc19c8 Product/image rename
This revamps the product and image names.  After merging this change,
the bootstrapper image will be known as "dockerorca/ucp" since it is the
primary image customers interact with.  The controller will be known as
"dockerorca/ucp-controller" and the corresponding container names are
"ucp" and "ucp-controller".  Once we get closer to GA, we'll move the
images under the "docker" org, so the product name will flow nicely from
that "docker/ucp" for the bootstrapping tool, and "docker/ucp-controller"
for the server image.
2016-11-05 21:45:57 -07:00
Daniel Hiltgen
30acf5bba6 Revamp support dump to be synchronous
It turns out that our support dump logic is *really* fast and compact.
Even on a large node (hundreds of containers and thousands of images)
it runs in ~10 seconds and weighs in at a few hundred K.  Since we're
running all the dumps in parallel, there's really no need for the added
complexity of saving them to a DB.

This change revamps and simplifies the support dump API.  Now you simply
POST to the API endpoint, and it will stream the full zip file containing
all the nodes payloads within.  If a node is unreachable, times out,
or has some other catastrophic problem, the contents for that node will
be an error message instead of the normal tar.gz bundle.

I've tested this with a swarm of multiple nodes, confirmed the dumps
match up to the hosts, and the system handles offline nodes, reporting
an error message within the bundle.  (it does take a long time in the
failure cases due to a bug in swarm that's slated to be fixed in 1.9,
but curl doesn't give up so this still works fine.)
2016-11-05 21:45:15 -07:00