Deploying Heapster to Kubernetes

I recently blogged about deploying kubernetes in Azure. After doing so, I wanted to keep an eye on usage of the instances and pods.

Kubernetes recommends Heapster as a cluster aggregator to monitor usage of nodes and pods. Very handy if you are deploying in Google Compute (GCE) as it has a pre-build dashboard to hook it to.

Heapster runs on each node, collects statistics of the system and pods which pipes to a storage backend of your choice. A very handy part of Heapster is that export user labels as part of metadata, which I believe can be used to create custom reports on services across nodes.

monitoring-architecture

If you are not using GCE or just don’t want to use their dashboard, you can deploy a combo of InfluxDB and Grafana as a DIY solution. While this seems promising the documentation, as usual, is pretty short on details..

Start by using the “detailed” guide to deploy the add on, which basically consists of:

**wait! don’t run this yet until you finished reading article**

git clone https://github.com/kubernetes/heapster.git cd heapster kubectl create -f deploy/kube-config/influxdb/

These steps exposes Grafana and InfluxDB via the api proxy, you can see them in your deployment by doing:

kubectl cluster-info

This didn’t quite work for me, and while rummaging in the yamls, I found out that this is not really the recommended configuration for live deployments anyway…

So here is what I did:

Remove env variables influxdb-grafana-controller.yaml
Expose service as NodePort or LoadBalancer depends of your preference in grafana-service.yaml. E.g. Under spec section add: type: NodePort
Now run >kubectl create -f deploy/kube-config/influxdb/

You can see the expose port for Grafana by running:
kubectl --namespace=kube-system describe service grafana-service

In this deployment, all the services, rc and pods are added under the kube-system namespace, so remember to add the –namespace flag to your kubectl commands.

Now you should be able to access Grafana on any external ip or dns on the port listed under NodePort. But I was not able to see any data.

Login to Grafana as admin (admin:admin by default), select DataSources>influxdb-datasource and test the connection. The connection is set up as http://monitoring-influxdb:8086, this failed for me.

Since InfluxDB and Grafana are both in the same pod, you can use localhost to access the service. So change the url to http://localhost:8086, save and test the connection again. This worked for me and a minute later I was getting realtime data from nodes and pods.

Proxying Grafana

I run an nginx proxy that terminates https requests for my domain and a created a https://mydomain/monitoring/ end point as part of it.

For some reason, Grafana needs to know the root-url format that is being accessed from to work properly. This is defined in a config file.. while you could change it and rebuild the image, I preferred to override it via an enviroment variable in the influxdb-grafana-controller.yaml kubernetes file. Just add to the Grafana container section:

env: - name: GF_SERVER_ROOT_URL value: "%(protocol)s://%(domain)s:%(http_port)s/monitoring"

You can do this with any of the Grafana config values, which allows you to reuse the official Grafana docker image straight from the main registry.

[Ubuntu QML] Writting a game.. Alpha Version

Since my first steps into QML when the Ubuntu SDK was launched, I have become a bit addicted to it. I decided to try to write a QML declarative game, and I settle on a shooting fighter jet game. Finally had enough content to put out an alpha. Here is the video:

The code for it in on my LP Junk branches, not really ready for review yet 😉 but happy to have help!

You might notice that I am using the keyboard to drive the game in my computer, I have also build a touch joystick that so far works ok in the Nexus 7, but needs some calibration.

PS: if you have some problems with playing the video, try jumping a head 10 secs, it also helps if you play it in HD 🙂

[Ubuntu QML] ToDo Android vs Ubuntu

A few months back, I decided to write a Simple ToDo app for Android, then I hooked it up to a cloud backend, using Juju. That was my first Android application, so I got to experience first hand the latest developer documentation and development environment.

Last month, Canonical launched Ubuntu for Phones, that gave me the idea to re-write the same application on QML using the Ubuntu Components.

Clearly comparing a new SDK-Alpha with a stable platform like Android will seem hardly fair, however, keep reading as you might be surprised of the results.

QML vs Dalvik Java

Lets start with QT/QML vs Dalvik/Java – I found QML really easy to get to grips with and be productive. I had the UI (see picture below) running in no time and I would say much faster than with Android. QML is a very flexible declarative environment that allows you to embedded quick logic into the layout. This is a blessing and a curse.

While with Android, it was very easy to keep a nice MVC separation, I struggled to stop the leaks in QML. So while it is very easy to quickly write a functional application, it does not impose what you would consider as good development practices.

In summary, they are both very powerful development environments.

IDE: Eclipse vs QtCreator

Part of the development experience is the IDE. I must say that I simply love the QTCreator. Possibly not as polish as Eclipse but you don’t need to read a manual to use it. Also, with a quick integration with the HUD, it is just very simple to use.

So what is QTCreator missing? A good emulator. The Android Development Kit (ADK) provides a really good user experience to develop mobile solutions. QMLScene gives you similar functionality but does not simulate a phone environment. However, all the technology is there, and I am sure that will be included in the v1.0 version of the SDK.

Documentation

I can’t fault Android developer documentation, but taking into account its popularity, you wouldn’t expect anything else.

I was very surprise of the quality of information on http://developer.ubuntu.com/ and specially with the component showcase.

The only thing to watch out for is that in Android you can get all the info you need from a single website. With QML you quickly end up pinging between Digia, Nokia and Ubuntu pages.

The Code

The code is on my launchpad repos. The actual source functionality is not finished as I am still trying to figure out how to add menu options to access Done items. Anyway, the whole thing is pretty compact compare to the Dalvik code. The actual logic is almost identical in both. A ListView that is populate from an List model. All the data is persisted in SQLite db.

Conclusion

Both environments have been equally painless to work with, the difference is that the Ubuntu environment has *just* been released as an Alpha. I think this is the start of a very vibrant App development ecosystem.

Chrome OS Gets A New “Retro” Look

I had a CR-48 Chromebook for a while, which has recently fallen in disuse. While I have never being totally convinced about Chrome OS being a polished, well designed, interface that simplifies the “always connected” user journey that Google was envisioning, I liked the concept.

Now I am reading in ArsTechnica that Chrome OS is getting a brand new look, that is … basically.. well, not new. While I am sure there are many technical advantages of a fully hardware accelerated windows managers, my issue is with the [lack of] concept.

Continue reading “Chrome OS Gets A New “Retro” Look” →

Problems with Dell Vostro 3300 and External Monitors in Ubuntu

Having installed Ubuntu 10.4 on my Vostro 3300, I hooked it up on my home made docking station… a belkin usb hub with wireless keyboard and mouse and a 20″ external monitor.

Everything seem to work ok – until I noticed that the monitor image was on a continuous flickering/wavy pattern. Searching on the web for similar problems, I found that the same issue had been found by several Vostro 3300 uses. I should note at this point that my laptop has an intel graphics card. Continue reading “Problems with Dell Vostro 3300 and External Monitors in Ubuntu” →

The value of the first contribution

Since we started the BugSquad, we had many people come and go from the mailing list, some of them show to the IRC sessions… however most of the ones that do contribute at least once (raising or fixing bugs) always seem to stick around.

It is my experience that making an extra effort to support someone’s first contribution is key to them becoming a regular member of the community. So, what are my “lessons learned” from the BugSquad so far:

Getting started guides – It is crucial to have detailed step-by-step guides for newbies, if you are trying to attract people from outside that might not have an in-depth knowledge of the project. For example, we realised that we didn’t have a simple guide on how to raise a bug. We had tones of detailed information on obscure Bugzilla functionality but nothing on the basics!
Make it simple (effort) – the more time that is needed to be spend downloading , installing and configuring stuff the less likely people are to participate. For example, we split the kits down to smaller download files, and reduce by half the amount of MBs needed to set up a running emulator. Continue reading “The value of the first contribution” →

Symbian^2 Success Story: 24 Contributions and Counting

If you have been following the Symbian world, the latest hot news is the announcement of the first Symbian^3 phone by Nokia (the N8).

However, between Symbian^1 and Symbian^3 there is missing number – so what is it going on with Symbian^2? While Symbian^2 is not a revolutionary step in platform functionality, it is in terms of Open Source working practices.

Despite the fact that Symbian^2 remains SFL, and hence its source still open only to members, there are currently 24 contributions from non-Package Owner companies that have been accepted into the MCL, and another 50 still going through the review process.

So why is this important? Firstly, because it clearly signals the willingness of Symbian members to make source contributions and to improve the overall quality of the platform.

Secondly, because Symbian^2 is a foundation release and most of these quality improvements are still relevant for Symbian^3.

Kudos goes to DOCOMO as the main contributor and to all the package owners that are providing feedback and managing these contributions. To all of you: Thanks and Keep up the good work!

Improving Code Contributions

If you have been dowloanding code from the mercurial repos, you would have notice some spooky coincidences… most package MCLs update all at the same time!

Well you can relax, our repos are not posses. This is the result of Nokia’s package owners delivering contributions to our repos in a centralised manner.As you can imagine delivering updates to over 30 million lines of code every other week is a rather complexed operation.

We have been Working with Nokia to improve the contribution channel to make it reliable (we now consistently recieve contributions every 2 weeks). We are now moving towards the next big step, an automated package-base publishing system. You can now see the first live pilot on the access security package repo. Continue reading “Improving Code Contributions” →

Update on the Bug Squad

One month on..

It is a month(ish) already since we started the Bug Squad (call to join the team through the Symbian Developer Forums). I am pretty pleased with the participation so far and also with how much the Symbian team is learning from this programme.

I think the participation numbers tell an insightful story: The forum entry received 1,087 reads and we twittered our mailing list link to +1K followers. This resulted in 45 people subscribed to the mailing list (including about 5 symbian staff) . Since then , 7 squad members have scored points for contributing to the bug squad efforts. Continue reading “Update on the Bug Squad” →

Contributions: 130+ fixes and counting!

Trolling through Bugtracker this week , I was surprise to find out how many fixes are currently in the contributions pipeline.

I have been looking at tracking the large amount of defect fixes DoCoMo has contributed to S^2 (30+). Chris Dudding , the Package Owner for Persistent Data Services has been blogging about it.

I knew part of the pipeline, but I was pleasently surprise to see that the community elsewhere has been keeping busy. A large part of the S^3 proposed enhancements comes from the Freedom Fighters project, that is focusing on compiling the Symbian platform using open source tools (namely GCCE). Peter Fordham is doing a great job in this initiative with more than 30 fixes under his belt.

From the BUG SQUAD part, we have already had our first patch integrated to the MCL, and anouther one in the pipeline.

Now the challenge for us is to improve the turn around time on feedback and integration of proposed contributions – (as the Zohan would say) So lets go!