The third Swiss Python Summit took place in Rapperswil, Switzerland, today. Conveniently located about an hour drive from the Service Prototyping Lab at Zurich University of Applied Sciences, the event reserved a spot on our conferences shortlist this year. In this post, we will briefly summarise major impressions from the well-organised summit.
PyParis is a community-organised conference on all topics around the Python programming language. The expected target group are primarily practitioners and researchers in the greater capital region of France, but also international engineers and language advocates. At Zurich University of Applied Sciences, Python is taught as automation and statistics application language to more than 200 business engineering, aviation and traffic engineering undergraduates per year. It is furthermore used a lot in research, including several prototypes resulting from the Service Prototyping Lab. Therefore, it was consequential for us to attend the conference and to contribute an in-depth tutorial on one of our research topics, Function-as-a-Service, to its attendees.
The Service Prototyping Lab at Zurich University of Applied Sciences is committed to advancing the state of technology for bringing applications to the cloud, for the benefit of the society of large in general and of the local industry in particular. This obliges us to closely monitor industrial trends along with academic advances. A hot topic currently found in both is the higher-PaaS-level service class of FaaS, or Function-as-a-Service, which coincides with the marketing term Serverless Computing. We have already contributed analytical work on finding the limits and possibilities of today’s FaaS systems (preprint), and engineering work on translating legacy monolithic code into fine-grained functions (preprint). It was only a matter of time until the limits in both commercially operated FaaS services and open-source FaaS prototypes became too severe for our work. Hence, after a careful analysis of what is available, we decided to come up with an alternative FaaS host process design. The design led to an architecture, and the architecture eventually to an implementation called Snafu. This post presents Snafu and positions it as Swiss Army Knife for situations in which functions should be prototyped, tested or hosted.
Rapid service prototyping, cloud application prototyping and API prototyping are closely related techniques which share a common goal: To get a first working prototype designed, implemented and placed online quickly, with small effort and with little headache over tooling concerns. The approaches in this area are still emerging and thus often ad-hoc or even immature. Several prototyping frameworks do nevertheless show a potential to become part of serious engineering workflows. In this post, the Ramses framework will be presented and evaluated regarding this goal.
ICCLab is announcing an integration of the Openstack OVA onboarding tool into OpenStack’s Horizon dashboard. To deploy the OVA file to Openstack all images are extracted from the file and uploaded to the Openstack cluster, all necessary file format transformations are automatically performed, glance images get created and the tool creates a heat stack out of them. As we mentioned a couple of weeks ago, uploading your local VMs into OpenStack was never easier.
If you ever thought of uploading your local VMs to OpenStack, perhaps you have come across OpenStack’s support for importing single virtual disk images. However, this cannot be used to deploy complicated VM setups, including network configurations and multiple VMs connected to each other.
We at ICCLab have therefore decided to develop a tool that will allow anyone to upload their VM setups from their local environments directly to OpenStack. We call it OpenStack VM onboarding tool and it’s available as open source.
VM onboarding tool features:
- Easy to run – the tool comprises of simple frontend, backend and Openstack client libraries to access Openstack APIs. All these components can be easily run with one command.
- Easy to Import – to import an OVA file the user needs to provide only the basic Openstack credentials (username, password, tenant, region, keystone URL) and an OVA file.
- Full infrastructure import – the tool imports virtual machines, external networks, internal network connections and security groups.
You can check out a quick demo of VM onboarding functionality, workflow and interface. Continue reading
Today the ICCLab introduces a new way on how to interact with your notes.
What is powdernote?
Powdernote is a note-taking, cloud-based application for the terminal.
Because we never leave the terminal, not even to read our notes or create new ones.
This tool is for busy engineers, developers, power users, devops, …
Our target is to have an un-cluttered, distraction-free application to solve the simple task of taking notes and having them available everywhere (storage is on the cloud)!
- Create, edit, delete, print, tag notes
- Search content
- Browse versions of notes
- Export/import to/from powdernote files
As mentioned in the first post about SmartDataCenter, it features various APIs. In this post we will have a look at them. Further I would like to present sdcadmin & sdc-heat, two small Python projects I have been working on. The former is a Python client library for SDCs admin APIs. The latter is an OpenStack Heat plugin that allows provisioning of SmartMachines and KVM VMs on SDC.
In our previous blog post we showed a web application to monitor and understand energy consumption in an Openstack cluster; the main goal of this tool is to understand how energy consumption relates to activity on the cloud resources. In general, this can be quite complex as there are many resources to take in account and Ceilometer doesn’t report all the information required at this time. In this blog post we describe one task we needed to perform in this work: we needed to retrieve from Ceilometer the set of VMs running on a given physical server together with their CPU utilization over some period of time. We can envisage other contexts in which it might be useful to do this, so we present the solution here. (Note that it is of course possible to obtain the set of VMs that are currently running on a given physical host using Nova, but this does not offer the historical perspective).
We are using ceilometer to collect data energy from our servers. As noted previously we were having some performance issues and we needed to investigate further. In this blog post we will cover our approach to performing profiling on ceilometer API to determine where the problems arose.
Of course, the first step was to take a look at the log files (in
/var/log/ceilometer-all.log); as there was nothing unusual in there, we decided to perform profiling of the code.