Commit c46cc016 authored by Robert Ricci's avatar Robert Ricci

Make the "planned" section suitable for CloudLab

parent 1ca3c4d0
......@@ -37,11 +37,12 @@ CloudLab will interoperate with existing testbeds including
hardware at dozens of sites around the world.
@include-section["getting-started.scrbl"]
@;include-section["preview-notes.scrbl"]
@;include-section["users.scrbl"]
@;include-section["repeatable-research.scrbl"]
@include-section["creating-profiles.scrbl"]
@include-section["basic-concepts.scrbl"]
@include-section["advanced-topics.scrbl"]
@;include-section["hardware.scrbl"]
@;include-section["planned.scrbl"]
@include-section["planned.scrbl"]
@include-section["getting-help.scrbl"]
......@@ -85,12 +85,29 @@ Sometimes, you just need one node running a particular
with it. We plan to add a ``quick profile'' feature that will create a one-off
experiment with a single node.
@section[#:tag "planned-virt-switching"]{Simpler Virtual/Physical Profile Switching}
As recommended in the chapter about @seclink["repeatable-research"]{repeatable
research}, moving back and forth between @seclink["virtual-machines"]{virtual}
and @seclink["physical-machines"]{physical} resources is a good way to move
from doing preliminary work to gathering final results for publication. Doing
this currently requires making two profiles. We plan to make changes to the @(tb)
interface to allow users to select, at experiment creation time, whether to use
virtual or physical resources.
@apt-only{
@section[#:tag "planned-virt-switching"]{Simpler Virtual/Physical Profile Switching}
As recommended in the chapter about
@seclink["repeatable-research"]{repeatable research}, moving back and forth
between @seclink["virtual-machines"]{virtual} and
@seclink["physical-machines"]{physical} resources is a good way to move
from doing preliminary work to gathering final results for publication.
Doing this currently requires making two profiles. We plan to make changes
to the @(tb) interface to allow users to select, at experiment creation
time, whether to use virtual or physical resources.
}
@clab-only{
@section[#:tag "bare-metal-switches"]{Bare-metal access to switches}
Today, switches in @(tb) are treated as infrastructure; that is, they
are under @(tb)'s control and, while we provide a high degree of
transparenccy, we do not let users control them directly. We plan to
make at least some switches---in most cases, ToRs, and in others,
spine and/or core---directly accessible to users. This means that
users will have console access to the switches, and will be able to
reconfigure them and/or load diferent versions of firmware on them.
(This will only be offered on switches that are only used by a single
experiment at a time.)
}
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment