GitHub, if you’re not familiar with it is a code hoster that boasts around 5 million users and close to 10 million individual repositories.  Through the magic of its “pull request” feature it has vastly increased participation in open source projects and accelerated innovation.  Listen to Mark and learn more.

Some of the ground Mark covers:

• How did GitHub rise to prominence and eclipse SourceForge as the developer repository of choice
• Success Metrics
• GitHubs architecture
• What are GitHubs challenges as it moves forward
• How the “pull request,” the killer app of GitHub, work

Extra-credit reading:

• What Exactly Is GitHub Anyway? – TechCrunch

Pau for now…

That date has now passed and Peter Owens, who is the project manager for the Profile Tool effort, has collated the feedback and mapped it against our vision for the tool and our minimum requirements.

(When not managing the profile tool effort Peter, as Director of Software Engineering in Dell Services, leads a development team responsible for the delivery of Managed-Private Clouds to global customers and expanding Dell’s OpenStack /DevOps development capability. Peter is based Dell’s Cloud Centre of Excellence in Dublin Ireland.)

Here is Peter’s  summary:

What we’ve learned

It is clear that you believe we are on the right track with the Profile Tool and that our plan to leveraging Docker will allow users to set up environments with minimum impact on system resources.

Where the feedback became very interesting was in the following areas:

1) project lifecycle

We need to define user stories for the following scenarios:

• where the tool is re-run or a project has already been setup by a user
• the project definition is changed
• adding and removing packages
• handling changes to languages or frameworks pulled into a project

2) User specific configurations

• to avoid conflicts, profiles should not be keyed solely on username

3) Specifying language versions

• we need to specify language versions within potentially multi-project environments
• users should be able to specify the language version from within a project

It was generally felt that separating out usernames, packages and config definitions was the correct approach. There were also some useful comparisons with other tools such as Boxen which enables you to centralize your configs for an entire organization. This means a “template” can be created for new hires or groups of developers.

 A Big Thanks and Next Steps

We are very grateful to those who took the time to contribute, share this initiative with their respective communities and provide feedback. Based on the feedback we’ve received we have started working on user story requirements which we hope to have done by the end of the year.  After that we will start coding in January.

As you’d expect we will be using a GitHub central repository where all the code can stay in sync. Code changes will be committed to this and other developers will pull them (sync them to their local repository). To start with we will be providing read-only access to the central repository, so the community will be able to keep track of our progress!  Once we get a little further along we will open up the repository for others to jump in.

Stay tuned and thanks again!

Extra-credit reading

• Dell aims for cloudy orbit with Sputnik Ubuntu developer project – The Register

Pau for now…

As you may remember, besides the needed drivers and basic utilities/tools there are two “extra-bits” that are part of the overall project Sputnik solution: the Profile tool and the Cloud launcher.  I will use a future post to give an update on the Cloud Launcher but today I want to focus on the Profile tool.

Project Sputnik Profile tool

With regards to the Profile tool we are doing a bit of reset on this effort and going forward will be doing the development out in the open and asking the community to dive in.

What is the Profile tool

In short, the profile tool provides access to a library of community created profiles on github, such as Ruby and Android, to quickly set up your development environments and tool chains.

As alpha cosmonaut Charles Lowell (aka cowboyd),  who originally teed up the idea, put it

What I’d like to see is not only a gold-standard configuration, but also a meta-system to manage your developer configuration… The devops revolution is about configuration as code. How cool would it be if my laptop configuration were code that I could store in a source repo somewhere?

Here’s how it would basically work, when a developer creates a profile based on a development framework e.g rails, this profile template is published to central catalog.  On another machine, the same developer—or another developer if the authoring developer makes his template shareable—grabs the template and runs it. The profile tool then reads the template, brings in any necessary dependencies (packages, package archives, SCM repositories, keys, dotfiles, etc) and places them in a sandbox within the user’s home directory.

Making it so, with a little help for our friends

Our original idea was to build out the profile tool in two phases: Phase I – “System Configuration” and Phase II – “User Configuration.”  We started down the path of building out Phase I but have realized two things 1) we cant look at the two phases separately and 2) we need to be developing this out in the open and incorporating direct feedback.

Given this we are opening up development at the Sputnik page on github and are looking for people like you to steer the course we eventually take.  At this stage nothing is set in stone and the profile tool is experimental beta work with several different prototypes.   If this is something that appeals to you please dive in and help shape the future of project Sputnik!

Extra-credit reading

• Project Sputnik Readme file on github
• Project Sputnik page on github
• Sputnik update: Profile tool and touchpad

If you would like to get involved, check out this 1 min video from Rob Hirschfeld talking about how:

Look for the code on the Crowbar GitHub repo by the last week of November.

Extra-credit reading:

• Dell | Cloudera Solution: Reference Architecture Guide
• Dell | Cloudera Solution: Deployment Guide

Pau for now…