September 2012

Month: September 2012 (page 2 of 2)

A Quick Performance Boost Tip for Foreman

It doesn’t make sense to continually download the same operating system packages when you can cache them along side your Foreman installation. Assuming you use a debian based OS, in order to do this and have a cached copy of all packages you use within your infrastructure simply install apt-cacher or apt-cacher-ng. Our preference is for apt-cacher-ng but we’ll show you how to install both.

# Installing apt-cacher-ng

[gist id=3720930]

You shouldn’t have to adjust the configuration of apt-cacher-ng for the basic functionality it offers, however if you need to adjust settings in `/etc/apt-cacher-ng/acng.conf`.

# Installing apt-cacher

[gist id=3718168]

Then set the contents of `apt-cacher-conf` to:

[gist id=3718171]

***Note:*** you might want to change the hostname of the ubuntu mirror and interface (eth1 is specific to previous articles on Foreman)

Reports are created every 24 hours, which can be accessed at `http://$FOREMAN:3241/report`. To force the creation run:

[gist id=3718175]

# Configuring Foreman
Once you have setup apt-cacher you can then create a new Foreman “Installation Media Source”. Simply supply a sensible name and importantly set the URL of that installation media source to `http://$FOREMAN:3241/ubuntu`, where $FOREMAN is either the IP or FQDN of your Foreman host.

An Introduction to Software-Defined Networking (SDN)

12. September 2012 / aepp / 3 Comments

Software-Defined Networking (SDN) is an architecture for computer networking. The overall key concept for SDN-based architecture is to define a control plane and a data plane. The control plane is represented as a server or appliance that takes the accountability for the communication between the business applications and the data plane. The data plane is represented by the network infrastructure where we don’t differ anymore between effective hardware and virtualized network devices. Thus, a control plane has to abstract the network for an administrator in both sides, the application and the infrastructure.

Figure 1: SDN architecture (source: https://www.opennetworking.org/images/stories/downloads/white-papers/wp-sdn-newnorm.pdf)

Currently there exists one SDN specification and related implementations for the communication between the data plane and the business applications which is called OpenFlow. OpenFlow does neither specify how the control plane is technically implemented nor how the network infrastructure is build, it is responsible for the communication of them. The standardizing of the elements in SDN were made by the Open Network Foundation (ONF) which is a non-profit industry consortium, working in close collaboration with OpenFlow. This circumstance lead to the general opinion that OpenFlow is the equivalent to SDN and that there is no limitation in what technology can be used in a SDN-based infrastructure.
As the architecture for SDN describes, the control plane is a single, abstracted entry point for network administrators what has the following advantages:

Centralized control of different network infrastructure vendors
Reduced complexity of newly added business applications and/or network devices
More network reliability and security
More granular network control of the incoming and outgoing network traffic
A higher and less complex rate of automation

All these points cover the problems that big datacentre’s currently have from the perspective of the network infrastructure. But what about the really small networks, for example a home-network. Does it make sense to separate the control and the data plane from each other if you have only one router/modem with 2 computers connected to it? The Answer is: Think big. Why do we have to manage the router/modem in the home-network by ourselves? In future times, this may be a task for the Internet Service Provider who is doing this today in some way anyways. The benefit for the ISP and the end-user is clear, less support tickets means happier end-users and a smaller support effort for the ISP itself.

We at the ICCLab have realised that we are having in our OpenStack Cluster problems that can be solved easily with a SDN architecture for our internal network infrastructure. If you are interested in some of the experiences we have made with SDN, we will publish soon an article how we setup our test-environment

[1] Software-Defined Networking: The New Norm for Networks

[2] OpenFlow White Paper

Workshop with Snabb.co / Luke Gorrie on the future of Software Defined Networking

12. September 2012 / TMB / 0 Comments

Luke Gorrie, founder of http://www.snabb.co/, pioneer, and serial make-it-happener (call it entrepreneur) in the network technology domain, came over to visit the ICCLab to discuss future research and engineering domains of Software Defined Networking (SDN).

About Luke. ” I’ve helped to build the internet for nearly 15 years through my work at Bluetail, Synapse, Teclo, and for Nortel and Ericsson. This is a really interesting and rewarding field to work in. I recommend giving it a try if you get the chance. I’ve worked with really interesting people and with really interesting software. I’ve been able to hang out with clever people like Joe Armstrong, the OLPC engineering team, and VPRI. And to work with the really fantastic hacker communities around Erlang, Common Lisp, Smalltalk, and Openfirmware. I hope this has given me an interesting mix of ideas to shake into a unique and delicious cocktail”.

It’s always brilliant to meet technology enthusiasts like Luke, with a focused approach on real-world problems and innovations to go after them. We at the ICCLab appreciate and value that. Cause lot’s of great ideas were discussed naturally during our get-together and many common aspects and understandings identified. Truly inspiring.

We are looking forward to following-up!

For more on Luke
I’m on Github, Twitter, LinkedIn, and Couchsurfing. I’ve been an off-and-on blogger for many years. I’m currently writing at blog.lukego.com

ICCLab to talk about OpenStack at the Puzzle ITC Tech Talk 2012

10. September 2012 / TMB / 0 Comments

Update: The final program is now online!

http://www.puzzle.ch/blog/articles/2012/10/09/puzzle-tech-talk-2012

Puzzle Tech Talk 2012

Von André Kunz, publiziert am 09. Oktober 2012
Tags: Event, Java, RHEV, Tech Talk, UX, Workshop

Puzzle ITC lädt Sie zum Tech Talk 2012 ein. Am 25.10.2012 erwartet Sie ein themenreicher Anlass mit Workshops, Vorträgen und einem Apéro zum Ausklang.

Wir freuen uns, Sie zum Puzzle Tech Talk 2012 einzuladen. Der Anlass findet am 25. Oktober 2012 im Hotel Ambassador in Bern statt.

Die Vorträge sind thematisch in einen Business- und einen Technologie-Track gegliedert. Zuvor bieten wir Ihnen in drei Workshops einen vertieften Einblick in das Angebot von Puzzle. Abgerundet wird der Abend mit interessanten Gesprächen an unserem Apéro Riche.

The ICCLab is proud to be invited to the Puzzle ITC Tech Talk 2012.

Puzzle ITC is one of the leading Open Source Software (OSS) based Software and System Engineering power houses in Switzerland.

The company fully embraces OSS innovations and recognizes the importance of Cloud Computing for the future, just as we do at the ICCLab.

More about the Puzzle ITC Tech Talk 2012 can be found on Puzzle’s tech blog.

Installing Foreman 1.0.1

7. September 2012 / Andy Edmonds / 3 Comments

Just recently the Foreman project released the latest version, 1.0.1. If you are following our [previous guide to install 0.4.2](http://www.cloudcomp.ch/2012/06/automating-the-icclab-part-one/) then you should also follow this.

# Installing & Configuring Foreman
You should setup your virtual machine exactly as we did in the previous guide, install puppet and checkout the foreman-installer modules from github. There is a small number of issues with the installer but we’ll easily walk you through them!

To check things out quickly, you can [download a VM (OVA) that has Foreman 1.0.1](http://www.cloudcomp.ch/wp-content/uploads/2012/09/Foreman1.01.ova) preconfigured. The username/password is `root` and `root`. This also includes puppet modules to deploy OpenStack compute and controller nodes.

> Side note: the puppetlabs repository has changed. Make sure to:
> `wget http://apt.puppetlabs.com/puppetlabs-release-stable.deb`

Ensure that the foreman-proxy is part of the bind group. If not add the user:

[gist id=3667157]

Configure your `foreman_proxy/manifests/params.pp as` before, ensuring to enable DHCP and DNS and for each of those setting the correct network settings (subnet etc)

Configure you `foreman/manifest/params.pp` as before. For us we disabled SSL. Very important here is that you set the `foreman_url` parameter to include the port number on which foreman listens (port 3000).

[gist id=3667152]

If it is not set then the scripts that tie puppet and foreman together will not work. This is a [known and reported issue](http://theforeman.org/issues/1855), which will be resolved.

Currently there is a bug in `foreman_proxy/manifests/proxydhcp.pp`. For now you need to manually set the DNS `nameserver` and TFTP `nextserver` parameters. This [bug has been reported](https://groups.google.com/d/topic/foreman-users/t1m8JeWVd7U/discussion) and will be resolved soon.

Finally you need to apply [this patch](https://github.com/theforeman/smart-proxy/commit/a402c71290f2d8205e60b876f2a40dfa9fefacda). Puppet in its most recent version changed the value of the return code from operations related to `puppetca`. This causes blocking issues with provisioning and deleting hosts with foreman. You can use this sed command if it suits you:

[gist id=3667151]

Once applied you should restart the foreman-proxy service

[gist id=3667147]

Note, if you start the foreman service and it halts with a stacktrace then you will have to reinitialise the database. This is a one-time operation.

[gist id=3667139]

Once these step have been complete, you can then configure Foreman itself (setting smart proxy, host groups etc).

When configuring these various aspects you should update the ‘Ubuntu default’ disk partition table configuration. Use the following to ensure a complete automatic install:

[gist id=3667133]

One of the issues that we’re dealing with currently is that rather than the puppetmaster’s hostname being placed in the relevant configuration files (e.g. `puppet.conf`), an IP address is inserted. This will not work as it will fail with SSL issues. The current work around is to create a ‘snippet’ in the Provisioning Templates section. With this snippet created then set the content of the config files in Provisioning Templates to (using `puppet.conf` as an examples):

[gist id=3667127]

Pietro Brossi

5. September 2012 / TMB / 1 Comment

Since 2000 Pietro Brossi is teaching courses as a lecturer at Zurich University of Applied Sciences in the study program Computer Science. His focus area is “enterprise computing”. Courses include: ICT infrastructure management, communication networks, network security & operation, computer systems and intranet services. He is also lecturing in various other study programs, seminars and courses at ZHAW. He participates in different projects of the Institute for Applied Information Technology (InIT) at the School of Engineering in Winterthur, Switzerland.

He has a diploma as a lic. phil II from the University of Zurich. Prior to joining ZHAW, he has started his career in the world of computer science as a system analyst at Wang Computers, where he was also involved in product marketing and pre-sales support. After this, he spent 12 years in different roles/positions in the ICT-Department of a large Swiss bank, where he acted as team-leader for the Information-Center Europe and was involved as ICT architect and strategist in the Private Banking division.

Since 2000 he is working as lecturer at ZHAW, where he also acted as Program Director of the study program “Enterprise Computing from 2000-2008.

Future Internet Research Group

5. September 2012 / TMB / 0 Comments

The Future Internet is an all-encompassing concept that embraces all our research in the area of computing. It is a highly vague term and the interpretation continues to be subject of debate, in particular amongst the different Internet stakeholders, but there is no doubt about the need for a Future Internet as such.

Genesis of the concept of an Future Internet is linked to the early works on an alternative communication architecture conducted in the US in the early years of this century. Meanwhile the term emerged as a global theme with a much more comprehensive interpretation, in particular in Europe where it is driven by a massive financial investment by the public and private sector, first and foremost by the Future Internet Public-Private Partnership.

The ICCLab deeply involved and committed to in Future Internet Research. If you share the same spirit then come and join us at the Future Internet Research Group.

Related Publications

T. M. Bohnert, “Global Future Internet Research (slides)”, Keynote ICIN 2010, Berlin, Germany, Oct 2010
T. M. Bohnert, “Vision and Status towards the Future Internet Technology Foundation” (slides)“, Net!Works General Assembly 2011, Munich, Germany, Nov 2011
T. M. Bohnert, “The FI-PPP after One Year: Lessons Learned, Challenges and Opportunities Ahead” (slides)“, 3rd European Future Internet Summit, Helsinki, June 2012

Open- or Not-So-OpenStack? – Comments on the OpenStack Foundation

5. September 2012 / TMB / 5 Comments

Contributions to Open Source Software (OSS) projects are an excellent means to foster broad uptake of innovations and has therefore become indispensable for research and development in computer science.

With the Internet allowing ubiquitous collaboration (e.g. between OSS software developers, OSS community managers, OSS document editors, etc) of all sorts, across all backgrounds, and locations spread over the entire globe, some OSS projects are so successful that they reach sizes (and budgets) that are comparable to full-blown companies.

Contributing to OSS is also an unparalleled frank (and in times brutal) means for receiving feedback by an expert community. OSS communities are commonly governed by technical meritocracy, a term inherently subjective and thus reliable warrant of controversy. Contributions are in turn relentlessly scrutinized, the latter not seldom amplified by the fact that the motivation for OSS contribution is reward by community appreciation (instead of financial compensation), a principle that renders OSS environments highly competitive, in particular for highly popular projects like Linux, Apache, OpenStack and the likes.

We, at the ICCLab, consider it paramount to deliver our ideas and innovations as running code to a few carefully selected and relevant OSS projects to get receive feedback that validates our ideas and to ensure that our ideas and innovations gain support and uptake by the community. This is an inherent element of our impact-centric research methodology.

The power of OSS is exemplified by the OpenStack project. It emerged out of a merger between NASA and Rackspace, who both developed their own IaaS framework but decided to cooperate for the sake of creating a serious competitor to existing incumbents, like Amazon and VMWare. This initial motivation of the founders continues to materialize and the project enjoys comprehensive community support backed up by significant financial and organizational backing by some of the most influential industry incumbents.

OpenStack meanwhile became (supposedly) the largest OSS project since Linux and reached a size significantly larger than Linux. Such growth pushes organizational structures of any OSS project to the limits. If also imposes a hefty burden onto founding members, for OpenStack in particular onto Rackspace who managed the project from an administrative perspective.

A common way out of this is to transform the organisation into an foundation, like for instance the Apache Foundation or the Linux Foundation, and this was applied to OpenStack too. With the beginning of September 2012 the OpenStack Foundation is in charge of the OpenStack project. The advantages are evident; professional structures, comprehensive governance, and financial management. All this fosters trust as it leads OpenStack out of a loosly coupled community project into a trustworthy company-style enterprise.

But such industry-grade and -oriented advantages come at a price. While native (pure) OSS projects share powers based on meritocracy, derived from technical expertise and commitment to the project, foundations are characterized by a significant financial dimension, and the OpenStack Foundation does not make an exception. The difficult part of this is the balanace between professional structures, the financial backing required, and the value (influence) provided to those that are willing to invest cash on one hand, and on the other to preserve the drive and nature of the OSS movement, that is technical liberty and community recognition.

The OpenStack compromise to this issue is documented in the OpenStack Foundation Bylaws. This document lays out the general framework (not to say powers) and thus puts any person and institution committed to OpenStack – just like the ICCLab – in an unequivocal context. The question therefore is: What are the implications of the OpenStack Foundation?

Our initial analysis goes here ICCLab : The OpenStack Project and Foundation

Feedback much welcome!

Service Engineering (ICCLab & SPLab)

A Blog of the ZHAW Zurich University of Applied Sciences