Page tree
Skip to end of metadata
Go to start of metadata

Project Name:

  • Proposed name for the project: SNAPS-OO
  • Proposed name for the repository: snaps

Latest information:

SNAPS-OO Home

Project description:

Developing OpenStack management applications can be quite cumbersome.  The sheer complexity of OpenStack systems combined with the incessant evolution of the landscape contribute to the difficulties.  Users may run test applications concurrently, with unknown starting states, in shared OpenStack environments and then clean up after themselves following errors.  Identifying the underlying component / API call that caused the issue from the test client logs is problematic.  The aim of this project is to overlay object oriented concepts on top of existing OpenStack python libraries to provide an easy to scale development library, enabling developers to manipulate VMs, networks, storage, images and other OpenStack components as objects.

Unit tests based on the SNAPS libraries have successfully run against Apex and Fuel.  JOID support is expected shortly.  The current source can be found at: https://gerrit.opnfv.org/gerrit/#/admin/projects/snaps or obtained with, "git clone https://gerrit.opnfv.org/gerrit/snaps"

Scope:

The OpenStack Python APIs are very useful but can be rather cumbersome to use. As they have been written for procedural use, managing newly minted objects (networks, routers, images, instances, etc.) becomes more daunting the larger the virtual environment becomes. As certain OpenStack objects contain others, the creator classes encapsulate not only the first-class object (network, router, keypair, image, user, project, VM instance, security group), but also any other underlying OpenStack objects (i.e. ports, subnets) that are not shared across objects, and all of the individual API calls required during creation.

SNAPS-OO currently contains over 200 (and growing) automated unit, component and integration tests that use the PyTest framework and exercise many of the create, get, and delete functions found within the Keystone, Glance, Neutron, and Nova clients. Several of these tests transcend simple API calls by spawning an entire virtual environment whose VMs are provisioned with Ansible Playbooks. In a CI environment, these tests can be executed against any OpenStack infrastructure; a subset can be executed against the mock OpenStack server Mimic.

The true power of this library lies in not requiring shell/environment variables to obtain OpenStack credentials. This fact alone makes it possible for one to create a Python application that is able to deploy and control objects across multiple clouds that may be hidden behind proxies. By taking an object-oriented paradigm in the library, there are benefits in the ease of cleaning up the virtual environment once it is no longer required. This aspect improves on the Functest housekeeping method where the framework maintains a manifest of known objects and removes anything that did not previously exist, making it impossible to leverage the cloud under test. Each of these two main features allow for parallel processing and opens the door for Functest and other OPNFV testing projects to mature more quickly. Some of the most notable SNAPS-OO features are:

  • Object-Oriented for easier usage and object management (especially valuable for cleanup and the alteration of deployed OpenStack components/objects)
  • Able to maintain connections across multiple users and clouds in the same runtime
  • HTTP and SSH proxy support for controlling and provisioning clouds hidden behind proxy servers.
  • Supported OpenStack objects:
    • Flavors
    • Images (http and files)
    • Projects/Tenants
    • Users
    • Networks
      • Subnets
    • Routers
      • Ports
    • Security Groups
    • Keypairs
    • VM Instances
      • Floating IPs
      • Ports
      • SSH Client retrieval
      • Security Group updates
      • Status checking
  • Future support of OPNFV scenarios and related projects:
    • Congress
    • Doctor
    • Multi-site
    • Many more based on needs identified by the community.
  • SNAPS Application:
    • Virtual environment configuration via YAML
    • Ansible Playbook support with dynamic variable substitution (i.e. IP addresses, port names, OS credentials, VM attributes, constants) 
  • SNAPS tests:
    • Wide range of OpenStack API calls
    • Dynamic creation of User/Project objects to be leveraged for the integration tests
    • Self cleanup
    • Floating IP and Ansible provisioning (note: Important as floating IPs can be problematic)
    • Multiple NIC configuration

As SNAPS-OO is a library designed to be used by any Python 2.7.x application, it has been designed for extensibility. As the code patterns used within the library are generally mature, the addition of the following features should not be overly difficult to new developers. Below is a list of potential new features and enhancements:

  • Block Storage
  • Domain CRUD
  • Tacker support (potentially)
  • DSL for complex scenarios (long-term vision)
  • Improve exception handling
  • Runtime updates to OpenStack objects (security groups on instances already implemented)

Documentation:

SNAPS Usage

Dependencies:

This library was designed to be very lightweight and does not require any upstream projects other than the following standard Python libraries:

  • python-novaclient
  • python-neutronclient
  • python-keystoneclient
  • python-glanceclient
  • ansible
  • wrapt
  • scp
  • cryptography

Committers and Contributors:

 

Planned deliverables:

Source code, test suites, markdown documentation, and examples.

Proposed Release Schedule:

  • When is the first release planned? OPNFV Danube
  • Will this align with the current release cadence? Yes

Key Project Facts

Project Name: SNAPS-OO
Repo name: snaps
Lifecycle State: Proposal
Primary Contact: Steven Pisarski (s.pisarski@cablelabs.com)
Project Lead: Steven Pisarski (s.pisarski@cablelabs.com)
Jira Project Name: SNAPS-OO 
Jira Project Prefix: [SNAPS ] 
mailing list tag [SNAPS] 
Committers: 
s.pisarski@cablelabs.com

r.levensalor@cablelabs.com

m.makati@cablelabs.com
*Link to TSC approval: TSC#February7,2017 
Link to approval of additional submitters: 

  • No labels