First of all, our large collection of tests needs maintenance. We need to keep adapting it to changing requirements and new hardware. We need to fix bugs and make it more robust. We also need to add some level of polish to the user interface. To make sure all our test programs are behaving in an uniform way, use correct wording, can be localized, etc. Those are all important to keep the project healthy. We also have a big challenge ahead of us, with the whole touch world entering the Ubuntu ecosystem. We will have to revisit some decisions, decide which libraries, tools and layers to use to test certain features and make sure we don't leave anything behind. This is very challenging as we really have a lot of existing tests. We also need to make them work the same way regardless of how they are started (classic Ubuntu, touch Ubuntu, remote Ubuntu server).
The core tools got an amazing boost over the past 12 months. Starting from pretty old technology that was very flexible but hard to understand and modify to something that is probably just as flexible but far easier to understand and work with. Still, it's not all roses. The Ubuntu SDK UI needs a lot of work to get right. It has usability issues, it has architecture design issues. We also have a big disconnect between the core technology (python3) used by and Qt+QML C++ codebase, talking over D-Bus with the rest of the stack. That brings friction and is 10x harder to modify than an all-python solution. Ideally we'd like to switch to PyQt but how that fares with the future Touch world is hard to say. I suspect that our remote testing story will help us have a smooth transition that won't compromise our existing effort and equally won't collide with the direction set by the first Ubuntu touch release.
Perhaps not in the spotlight but definitely we need to work on "whitelists" (aka test plans). We need to learn how our users take our stack and remix it to solve their problems. Our test plan technology is ancient and shows its weaknesses. We need a 2.0 test plans that allow us to express the problems we need to solve clearly, unambiguously and efficiently. We need to improve our per-device-instance test support. We need to provide rich meta-data for user interfaces. We need better vocabulary to create true test plans that can react to results in a way unconstrained by the design of the legacy checkbox first written over seven years ago. We also need to execute those changes in a way that has no flag days or burnt bridges. Nobody likes to build on moving sand and we're here to provide a solid foundation for other teams at Canonical and everyone in the free software ecosystem.
Lastly we have the elephant in the room called deployment. Checkbox doesn't by itself handle deploying system images and configuration onto bare metal (we have a very old and support project for doing that) and the metal is changing very rapidly. Severs are quite unlike desktops, laptops (Ethernet-less ultrabooks?) and most importantly tablets and the whole touch-device ecosystem behind them. In the next 12 months we need a very good story and a solid plan on how to execute the transition from what we have now onto something that keeps us going for the next few years, at least. Canonical luckily has such a project already, MAAS. MAAS was envisioned for big iron hardware but if you look at it from our point of view we really want to have uniform API for all hardware. From that big-ass server in a Data Centre somewhere across the globe to that development board on your desk, which will be the next tablet or phone product. We want to do the same set of operations on all of the devices in this spectrum, manage, control, track, re-image. The means and technology to do that differ widely and from experience I can tell you this is a zoo with all the queer animals you can think of but I'm confident we can make it work.
So there you have it. Checkbox over the next 12+ months, as seen through my eyes.
This is the final week of Trusty Tahr Cycle. We are now at the very last phase of this cycle. It is called The Final Freeze and Release Candidate.
The Final Freeze vs The Final Release
You need to understand the difference between The Final Release and The Final Freeze.
Final Freeze – April 10th
Final Release – April 17th
What does all this mean?
It means that Ubuntu GNOME Trusty Tahr Daily Builds are considered to be RC.
What does RC (Release Candidate) mean?
“During the week leading up to the final release, the images produced are all considered release candidates.”
The Final Round of Testing Ubuntu GNOME Trusty Tahr
This is the final round and the last week to test Ubuntu GNOME Trusty Tahr.
As always, your help, support and testing are highly needed and greatly appreciated.
Thank you for choosing, testing and supporting Ubuntu GNOME. Without your great and amazing support, we would have never reached to this point.
So, we have a Datacenter Engineer Position open, and also a Network Engineer Position.
And as pre-requisite, you should be able to travel through Europe without any issues, you should read/write/speak English, next to your native language.
- are comfortable to travel
- are familiar with routers and switches of different vendors
- know that bonding slaves don’t need a safe word
- know that BGP is no medical condition
- know how to crimp CAT 5/6/7
- know the differences between the different types of LWL cable connections
- have fun working with the smartest guys in this business
- want to even learn something new
- love games
- love streaming
- love PlayStation (well, this is not a must)
Still with me?
You will work out of our Berlin Office, which is in the Heart of Berlin.
You will work directly with our Southern California Based Network Engineering Team, with our Datacenter Team and with our SRE Team.
The Berlin team is a team of several nationalities, which combines the awesomeness of Spanish, Italian, French and German Minds. We all love good food and drinks, good jokes, awesome movies, and we all love to work in the hottest datacenter environments ever.
Is this something for you?
If so, you should apply now.
And applying for this job is easy as provision a Cisco Nexus router today.
- You point your browser to our LinkedIn Page and press ‘Apply Now. (Please refer to me, and where you read this post)
- Or you send your CV directly through the usual channels to me (PDF or ASCII with a Profile Picture attached) and I put you on top of the stack.
Hope to see you soon and welcome you as part of our Sony/Gaikai Family in Berlin
I know some people are afraid of LinkedIn so here is the official job description from our HR Department.Job Description:
As a Network Engineer with deployment focus you will be responsible for rollout logistics, network deployment process and execution. You will work closely with remote Network Engineers and Datacenter Operations to turn up, configure, test and deliver Network platforms across POPs and Datacenters.Principle Duties / Responsibilities:
- Responsible for rollout logistics and coordination
- Responsible for network deployment processes
- Responsible for network deployment execution
- Deployment and provisioning of Transport, Routing and Switching platforms
- Comfortable with travel
- Comfortable with optical transport, DWDM
- Comfortable with various network operating systems
- Comfortable with some network testing equipment
- Comfortable with structured cabling
- Comfortable with interface and chassis diagnostics
- Comfortable with basic power estimation and calculation
- BA degree or equivalent experience
- 1-3 years working in a production datacenter environment
- Experience with asset management and reporting
Knowledge of various vendor RMA processes to deal with repairs and returns
Keen understanding of data center operations, maintenance and technical requirements including replacement of components such as hard drives, RAM, CPUs, motherboards and power supplies.
- Understanding of the importance of Change Management in an online production environment
- High energy and an intense desire to positively impact the business
Ability to rack equipment up to 50 lbs unassisted
High aptitude for technology
- Highly refined organizational skills
- Strong interpersonal and communication skills and the ability to work collaboratively
- Ability to manage multiple tasks at one time
Up to 50% travel required with this position.