1 / 21

GEC17: Uniform Experimenter Experience

GEC17: Uniform Experimenter Experience. Sunday July 21, 2013 0830-1000 Josh Smift , Marshall Brinn GPO. Outline. Motivation: Why a Uniform Experimenter Experience? Recent Progress and Status Looking Ahead. Motivation. This topic is intentionally called “Uniform Experimenter Experience”

yetta
Download Presentation

GEC17: Uniform Experimenter Experience

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. GEC17: Uniform Experimenter Experience Sunday July 21, 2013 0830-1000 Josh Smift, Marshall Brinn GPO

  2. Outline • Motivation: Why a Uniform Experimenter Experience? • Recent Progress and Status • Looking Ahead

  3. Motivation • This topic is intentionally called “Uniform Experimenter Experience” • It doesn’t mean to imply that all aggregates are the same or all services are or should be the same • But it invites us to focus on the experimenter as the ultimate consumer of GENI tools, services and capabilities • It is the experimenter’s experience of these services that we want to be uniform

  4. Motivation [2] • At the last GEC, we suggested a general rule for approaching the natural differences among GENI services: • How we do this ‘advertising’ and ‘hiding’ will determine how uniform (and ultimately experimenter-friendly) we will be. • If a feature is something that is of value to experimenters, advertise it • If not, hide it

  5. Advertising Differences • Ideally, capabilities should be advertised in advertisement RSpecs and then presented to experimenters by tools. • However, many capabilities cannot be easily rendered in advertisements or by tools (e.g. containers vs. VM’s) • Differences are often “advertised” in WIKIs which is not an approach that can be automated or that will scale If not advertised, value-added differences are likely to be unavailable or invisible to experimenters from most tools. This leaves us vulnerable to providing a ‘least common denominator’ capability rather than a diversity of valuable features.

  6. Hiding Differences • We have discussed several approaches towards masking differences between different aggregates and associated resources including • Increasing common RSpec dialects • Tools that speak/translate between dialects • Common post-boot configuration mechanisms • Common images • Limiting the capabilities that can be requested from tools to those that are common to all

  7. Recent Progress and Status

  8. Recent progress and status • Progress on various fronts since GEC 16 • Three in particular to talk about here: • Images: • A more uniform initial environment on nodes • Applicable to custom images or stock ones • Post-boot scripts: • Good for customization in general • Also good for smoothing over differences • GENI meta-information: • As input to post-boot scripts • Also possibly useful for experiment configuration • A generally increasing focus on tools

  9. Images: Overview • Nice to have the same image on all your nodes • Four (at least!) kinds of nodes in the racks: • Raw (“bare metal”) nodes (EG and IG) • Xen VMs (IG) • KVM VMs (EG) • OpenVZ containers (IG) • Slices will often contain two or more of those • Most PG raw images work on Xen too • Containers: least expensive, but least flexible

  10. Images: Approaches • Identical • One set of instructions to build an image • That image then works everywhere • Sounds nice, may not be feasible • Conversion • Build an image of one type • Follow instructions to convert it to other types • Utah folks have this mostly working for KVM → Xen • Common source • One set of instructions to build a “GENI image” • Additional instructions turn it into other types • Perhaps appealing if conversion has issues

  11. Post-boot scripts: Overview • Even multi-rack images may need customization: • OS: Fedora, Ubuntu, etc • AM: ExoGENI/ORCA, InstaGENI/PG/Emulab, etc • Differences in how particular images were created • Post-boot scripts can help: • Bridge gaps between AMs (expected to narrow) • Smooth over OS differences when necessary • Do other setup stuff that you need • Run when the node boots • At least once, when the sliver is created • Also every time it reboots, unless you tell it not to

  12. Post-boot scripts: Dingbot • Dingbot is one example, to bridge current gaps: • Lets you put the same thing in all your rspecs • Handles OS- and AM-specific differences • Extensible to handle other differences • Takes a config file for user-specific stuff • Thus: • (http://groups.geni.net/geni/wiki/Dingbot) <services> <install url="http://www.gpolab.bbn.com/~jbs/dingbot.tar.gz" install_path="/tmp" /> <install url="http://www.gpolab.bbn.com/~jbs/dingbot-jbs.tar.gz" install_path="/tmp" /> <execute shell="/bin/bash" command="sudo /tmp/dingbot/dingbot /tmp/dingbot/dingbot-jbs.jsoncarlin"/> </services>

  13. Post-boot scripts: Dingbotdetails • General: • Checks if it's already run • Logs what it does (separate output and errors) • Sets the hostname (rspec passes a command-line argument) • OS-specific: • Installs packages (a list from the config file) • Configures sudo • AM-specific: • Creates accounts with SSH keys (a list from the config file) • Sets preferred shell on existing accounts • Easy to add more things

  14. Post-boot scripts: Related work • Provisioning tools: • Scripts to manage multiple slices at multiple AMs • Templates for generating AM-specific rspecs • Orchestration tools: • Zoing: Runs experiments repeatedly out of cron • Configuration management tools like Puppet or Salt • Graphical I&M-integrated projects: • GENI Desktop + GEMINI • LabWiki + GIMI

  15. Meta-information: Overview • Nodes should have access to GENI meta-info • Slice URN, sliver URN, manifest rspec, etc • Definitely useful for post-boot scripts • Potentially also for experiments at run time • Sometimes this info is dynamic • Sliver may change after creation (UpdateSliver) • Some info not available until creation is complete • So, just stuffing things in files isn't ideal • Nodes generally can't query the AM directly • You may not want your private key on your nodes • You may not have Omni (esp. if you don't otherwise use it )

  16. Meta-information: Details • Proposed new 'geni-info' command on dev list: • Prints output, creates files, or both • Has the same inputs and outputs on all AMs • Source(s) of the data might be AM-specific • Things to figure out (here? coding sprint?): • What info it should return: • Manifest rspec for sure – lots of good stuff there • Some things missing, e.g. users and/or keys • What format for output (JSON? INI? XML?) • Where it should put files (/geni?) • After that: Write up a detailed spec (GPO)

  17. Looking Ahead

  18. Looking Ahead • Here are some areas we should consider that would help developers provide a uniform experimenter experience while allowing them to access value-added differentiators • RSpec Factoring. We should revisit the effort to factor RSpecs into base and extensions so that base document are universally accepted and understood, while extensions allow for capturing resource/aggregate-specific capabilities • Rspec Services. Solicitation 4 tool builders would benefit from tools/services to help build and parse RSpecs that encapsulate the differences between IG/EG dialects.

  19. Looking Ahead [2] • We should consider how resource allocation and configuration could be better unified • Common images • Perhaps a limited set of OS and OS versions? • Common boot scripts • Common run-time environment • Resource-internal services for self-configuration, discovery Consider, e.g., GIMI and GEMINI not as a completely separate product built on top of a topology but part of a single process of building the configured topology the experimenter wants.

  20. Looking Ahead [3] • Uniform Clearinghouse API (under development) should allow for the same tools to speak to different CH’s • Different credentials, different roles/identities, different policies • Standardize how aggregates interact with multiple CH’s, federations • Complete the work of the AM API development • All get to V3 (providing transactional boundaries) • Ratify and move to V4 (implement ‘update’ capability)

  21. Discussion

More Related