TryStack is a great way to take OpenStack for a spin without having to commit to a full deployment.

This free service lets you test what the cloud can do for you, offering networking, storage and compute instances, without having to go all in with your own hardware.

It’s a labor of love spearheaded by three Red Hat OpenStack experts Will Foster, Kambiz Aghaiepour and Dan Radez.

TryStack’s set-up must bear the load of anyone who wants to use it, but instead of an equally boundless budget and paid staff, it was originally powered by donated equipment and volunteers from Cisco, Dell, Equinix, NetApp, Rackspace and Red Hat who pulled together for this OpenStack Foundation project.

The sandbox has been offline for a few months for some major upgrades. Superuser talked to Foster and Aghaiepour, both systems engineers at Red Hat’s cloud operations team, about what’s new under the hood and common mistakes people make when doing a trial run with OpenStack.

What are the major changes with this revamp?

Aghaiepour: Red Hat, Dell, NetApp, and the OpenStack Foundation are continually working together on improvements of the TryStack platform. The newest revamp has gotten a hardware refresh expanding the overall capacity of the platform. The biggest improvement is in the overall compute capacity, as we have gone from three compute nodes to nine, each with 8core (16vCPU) systems and 96G of ram.

We’re also excited to have NetApp join us in the revamp effort by providing the backend network-attached storage (NAS) platform now being used for Cinder and Swift storage. Ben Swartzlander from NetApp is also working on Manila integration. We’re looking forward to making the technology available on TryStack in the coming months; you can see what Ben is working on via GitHub here: https://github.com/bswartz?tab=repositories

We’ve also moved the www.trystack.org web content under the OpenStack Infrastructure group’s continuous integration (CI) purview and gating/review mechanisms just like any OpenStack component.

What are some of the cool things that people have been testing with it lately?

Foster: Some of the more common uses are on-demand services like CI (Jenkins, Gerrit, Travis etc). or where people want to quickly spin up an entire operating system and stack and run verification tests, recording the results and tearing everything down automatically.

We see this often with various operating system patches where instantiating a certain patch-level of an OS for QA testing or bug reproduction is needed without having to do it by hand or wait for installation (or an IT team).

With cloud-init and custom cloud images you can run just about anything. Anything from Vagrant (to develop OpenStack code) to a common web application or blog. It’s also been a good proving ground for new users interested in moving towards Cloud technology without having to deal with the overhead of an extensive proof-of-concept or incurred costs just to try.

What’s a common misconception about apps and OpenStack?

Foster: I see a lot of people using OpenStack like they would a normal hypervisor, but OpenStack isn’t just another virtualization technology. There are some great self-service features OpenStack provides innately but for applications to truly take full advantage of them they need to be architected in a fault-tolerant way, taking advantage of benefits derived by automatically adding or removing backend infrastructure (compute/storage/network). OpenStack is good at quickly spinning up (or down) a sundry of useful software-based infrastructure resources but sometimes its not the best fit for a long-running legacy application or database.

A good example for OpenStack usage might be a CI system which quickly spins up an operating system to run automated tests and tears itself down, or a scalable web application that can scale across instances as demand increases or decreases. An easy way to look at it is if you’re not taking advantage of the rich API-driven virtualization OpenStack offers your application might not be utilizing its full potential.

What’s the biggest mistake people make when testing their apps?

Foster: OpenStack provides a lot of power and autonomy but with that level of control also comes the need to understand how OpenStack treats network isolation, instances and associated resources like object storage and automation capabilities. The most common mistakes might arise when a developer is still designing and testing applications like they would on traditional legacy IT infrastructure. For example, much of the testing regimen can be easily automated by use of Heat templates or automating instantiation and tests via Rally.

Because OpenStack is a loose collection of related programs, taking full advantage of the software-defined networking capabilities of Neutron and the “multi-tenant by default” design is a huge boon to testing and development. In a more traditional IT setting you’d need dedicated equipment or network switch isolation to avoid parallel testing without impacting others.

Anything new planned for the Tokyo Summit?

Aghaiepour: We’re focusing on adding more advanced monitoring checks and continuing to publish those on Github for others to use, like detection of low floating-ip pool allocation and usage visualization via Graphite and Ceilometer. We are also focused on getting other primary authentication methods in place like openstackid which uses OAuth2 now that API access is functioning again under Kilo.

Ben Swartzlander is also using Trystack.org for development and hopes to add the official Netapp Manila and Cinder driver after the Liberty release feature freeze.

To get in touch with the TryStack team, reach out on #trystack on irc.freenode.net

Cover Photo // CC BY NC