Great news in Chameleon-land!

 

Because you’re probably sick of turkey by now, we have something else to whet your appetite.

 

OpenFlow experiments can now utilize multiple networks. We have deployed a new capability which allows users to associate multiple Chameleon OpenFlow networks to a single OpenFlow controller and switch abstraction. The centralized controller can be programed to selectively maintain network isolation or to forward traffic between networks based on the requirements of the experiment. This functionality works with both localized isolated networks as well as externally (i.e. ExoGENI) stitchable network circuits. It enables advanced switching and routing experiments including wide-area multipath routing. To find out more read our documentation.

 

BYOC (Bring Your Own Controller) is now easier to do than ever. A common difficulty with using the OpenFlow BYOC capabilities has been the ability to know which OpenFlow switch port is connected to which node. A recent Chameleon update standardized the mapping of port identifiers to the nodes at UC. We have now deployed this update at TACC as well and have created a similar standard mapping. The port mappings for both sites can be found in the SDN networking documentation.

 

Temperature metrics for (all!) low power nodes are now available. In addition to the power metrics announced in June, Chameleon now collects temperature metrics for all low power nodes (Intel Atom, Low Power Xeon, and ARM64 Nodes) via the `temperature_cpu` metric. Take a look at our docs to see an example of how to use this new metric, and if you need a refresher or have not used this feature before, we have a blog post covering the original feature.

 

KVM cloud traces for past 4 years available for analysis. Making cloud traces available is critical to supporting research as it enables researchers to validate their research by testing how it would perform on real life data. We updated the existing Chameleon OpenStack KVM cloud traces on Science Clouds to include data for the past 4 years. As part of this, we now also provide the software tool that we used to extract the data and a Jupyter Notebook example illustrating how one can share traces from similar OpenStack clouds easily. For more information about cloud traces, please visit our cloud traces page on Science Clouds and contact us if you would like to either use our data or contribute your own.

 

(Even) better Chameleon Jupyter Notebooks. Last month we announced the introduction of a shared Swift-backed drive to the JupyterLab application, which allows you to share Notebooks with collaborators within your project. This month we improved the reliability of that, especially concerning larger Notebook files, and also added an ability to switch the active project for those of you who are affiliated with multiple projects on Chameleon--see here for instructions. If you’re new to Jupyter, or just want to know more about how to share your research with collaborators using the Notebook as a convenient medium, we have prepared some docs for you.

 

Usability improvements. Some users noticed that when they were signed in to the wrong testbed region, clicking a link to launch an appliance from the appliance catalog would give you an uninformative 404 error. Those links got a talking to and won’t do that anymore. We also added a way to filter appliances for only those officially supported by Chameleon staff, so you can choose to only use images we actively keep an eye on for misbehavior.

Last but not least: we have extended the deadline for the Call for Presentations and Demonstrations for our User Meeting until this Wednesday! We look forward to seeing what you all have come up with!