planned.scrbl 6.82 KB
Newer Older
1 2 3 4 5 6
#lang scribble/manual

@(require "defs.rkt")

@title[#:tag "planned" #:version apt-version]{Planned Features}

This chapter describes features that are planned for @(tb) or under development:
please @seclink["getting-help"]{contact us} if you have any feedback or
Robert Ricci's avatar
Robert Ricci committed

Robert Ricci's avatar
Robert Ricci committed
@section[#:tag "planned-versioned-profiles"]{Versioned Profiles}

13 14 15 16 17 18
We plan to add the @italic{versioning} to profiles to capture the evolution
of a profile over time. When @seclink["updating-profiles"]{updating profiles},
the result will be a new version that does not (entirely) replace the profile
being updated.

There will be two types of versions: @italic{working} versions that should be
Robert Ricci's avatar
Robert Ricci committed
considered ephemeral, and @italic{published} versions that are intended to be
20 21 22
long-term stable. For example, a user may generate many working versions as
they refine their software, fix bugs, etc. Then, when the profile is in a state
where it is appropriate to share with others, it can be published.  Users will
Robert Ricci's avatar
Robert Ricci committed
be able to link to a specific version---example, to unambiguously identify which
24 25
version was used for a paper.

One limitation on this feature will be the fact that @(tb) has limited storage
27 28 29
space; we will have to apply a quota system that limits the amount of storage
that a project can use to store multiple versions of the same profile.

Robert Ricci's avatar
Robert Ricci committed
@section[#:tag "planned-persistent-storage"]{Persistent Storage}

For the time being, the contents of all disks in @(tb) are considered ephemeral:
33 34 35 36 37
the contents are lost whenever an experiment terminates. The only way to save
data is to copy it off or to @seclink["creating-profiles"]{create a profile}
using the disk.

We plan to change this by adding persistent storage that is hosted on storage
servers within @(tb). Users will be able to use the @(tb) web interface to create
39 40 41
and manage their persistent storage, and profiles will be able to reference
where these stores should be mounted in the experiment. When sharing profiles,
it will be possible to indicate that the persistent store may only be mounted
Robert Ricci's avatar
Robert Ricci committed
read-only---a common use case will be to put a dataset in a persistent store,
and allow other @(tb) users read-only access to the dataset.
44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61

There will be two types of persistent storage: @italic{block stores} which
are mounted using iSCSI, and which generally can only be mounted on one host
at a time, and @italic{file stores} which are mounted over NFS, and can be
mounted read/write by many nodes at the same time.

This feature will be based on Emulab's
@hyperlink[""]{block storage system}.
Underlying this system is ZFS, which supports snapshots. We intend to expose
this snapshot functionality to users, and to allow profiles to mount specific
snapshots (eg. the version of a dataset used for a particular paper.)

It should be noted that performance of persistent stores will not be guaranteed
or isolated from other users, since it will be implemented using shared storage
servers that others may be accessing at the same time. Therefore, for
experiments whose @seclink["repeatable-research"]{repeatability} depends on 
I/O performance, all data should be copied to local disk before use.

62 63 64 65 66 67 68 69 70 71 72
@section[#:tag "geni-users"]{Account Integration for GENI Users}

We are in the process of enabling accounts from the
@hyperlink[""]{GENI} facility and its federates to work
directly with @(tb). When this integration is complete, all users with accounts
at GENI identity providers (such as the
@hyperlink[""]{GENI Portal}) will be able to use those
accounts on @(tb) without the need to create a new account. This feature will
make use of the @hyperlink[""]{GENI trusted
signer} for authentication and authorization.

Robert Ricci's avatar
Robert Ricci committed
@section[#:tag "planned-easier-profiles"]{Easier From-Scratch Profile Creation}

Currently, there are two ways to create profiles in @(tb): 
@seclink["creating-from-existing"]{cloning an existing profile} or creating one
Robert Ricci's avatar
Robert Ricci committed
77 78
from scratch by @seclink["creating-from-scratch"]{writing an RSpec by hand}.
We plan to add two more: a GUI for RSpec creation, and bindings to a programming
language for generation of RSpecs.
Robert Ricci's avatar
Robert Ricci committed
80 81

The GUI will be based on Jacks, an embeddable RSpec editor currently in
development for the GENI project. Jacks is already used in @(tb) to display
83 84 85 86 87 88 89 90
topologies in the profile selection dialog and on the experiment page. 

The programming language bindings will allow users to write programs in an
existing, popular language (likely Python) to create RSpecs. This will allow
users to use loops, conditionals, and other programming language constructs to
create large, complicated RSpecs. We are evaluating
@hyperlink[""]{@code{geni-lib}} for
this purpose.

Robert Ricci's avatar
Robert Ricci committed
@section[#:tag "planned-quick-profiles"]{``Quick'' Profiles}

94 95 96 97
Sometimes, you just need one node running a particular
@seclink["disk-images"]{disk image}, without making a complicated profile to go
with it. We plan to add a ``quick profile'' feature that will create a one-off
experiment with a single node.

99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124
    @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.

    @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.)
125 126 127 128 129 130 131 132 133 134 135 136

    @section[#:tag "openflow"]{OpenFlow support}

    All switches in @(tb) will be OpenFlow-capable. In the case of
    exclusive-access @seclink["bare-metal-switches"]{bare metal switches},
    users will get direct and complte OpenFlow access to the switches.  In the
    case of shared switches, we are investigating the use of
    @hyperlink[""]{FlowSpace Firewall}
    from the @hyperlink[""]{GRNOC} and
    @hyperlink[""]{Internet2} for virtualization.