Feed aggregator

Olivier Berger: Configuring the start of multiple docker container with Vagrant in a portable manner

Planet Debian - Fri, 06/02/2015 - 12:42

I’ve mentioned earlier the work that our students did on migrating part of the elements of the Database MOOC lab VM to docker.

While docker seems quite cool, let’s face it, participants to the MOOCs aren’t all using Linux where docker can be available directly. Hence the need to use boot2docker, for instance on Windows.

Then we’re back quite close to the architecture of the Vagrang VM, which relies too on a VirtualBox VM to run a Linux machine (boot2docker does exactly that with a minimal Linux which runs docker).

If VirtualBox is to be kept around, then why not stick to Vagrant also, as it offers a docker provider. This docker provider for Vagrant helps configure basic parameters of docker containers in a Vagrantfile, and basically uses the vagrant up command instead of using docker build + docker run. If on Linux, it only triggers docker, and if not, then it’ll start boot2docker (or any other Linux box) in between.

This somehow offers a unified invocation command, which renders a bit more portable the documentation.

Now, there are some tricks when using this docker provider, in particular for debugging what’s happening inside the VM.

One nice feature is that you can debug on Linux what is to be executed on Windows, by explicitely requiring the start of the intermediary boot2docker VM even if it’s not really needed.

By using a custom secondary Vagrantfile for that VM, it is possible to tune some parameters of that VM (like its graphic memory to allow to start it with a GUI allowing to connect — another alternative is to “ssh -p 2222 docker@localhost” once you know that its password is ‘tcuser’).

I’ve committed an example of such a setup in the moocbdvm project’s Git, which duplicates the docker provisioning files that our students had already published in the dedicated GitHub repo.

Here’s an interesting reference post about Vagrant + docker and multiple containers, btw.

Categories: Elsewhere

OpenLucius: A robot in your Drupal social intranet / extranet – why and how?

Planet Drupal - Fri, 06/02/2015 - 10:15

If you work with a team on projects, then there are (obviously) tasks to share. Including tasks to be followed up by your clients.

For example: the delivery of a design in Photoshop/fireworks for their new social intranet.

Now it can happen that somebody does not follow-up on his/her task in time resulting in problems for your planning. Usually this is not on purpose, often they simply 'forgot'.

Categories: Elsewhere

Drupal core announcements: Princeton Critical Sprint Recap

Planet Drupal - Fri, 06/02/2015 - 02:35

At the end of January, 2015, sprinters gathered in Princeton, NJ, USA for a focused D8 Accelerate sprint designed to accelerate work on critical and upgrade-path-blocking issues related to menus, menu links, and link generation.

The sprint was coordinated with the 4th annual DrupalCamp NJ. pwolanin, dawehner, kgoel, xjm, Wim Leers, mpdonadio, YesCT, effulgentsia, and tim.plunkett participated onsite. (In addition to the D8 Accelerate Group, local Drupalists davidhernandez, cilefen, crowdcg, wheatpenny, ijf8090, and HumanSky joined the sprint primarily to work on Drupal 8 Twig and theme issues, and EclipseGC and evolvingweb dropped in too.)

The sprint benefitted from pre-sprint planning meetings and discussion with the sprinters and a broader group of contributors (including webchick and catch, as well as amateescu, larowlan, Gábor Hojtsy, Bojhan, and Crell), and daily support from webchick to track, summarize, and unblock progress with issue posts and commits so the sprinters could move on to the next steps.

Thanks to the pre-sprint planning, sprint focus, and the tremendous experience of the participants and their history of working together on hard issues in the past, this sprint achieved a very high level and breadth of success. Sprinters worked on a total of 17 critical issues (14 of which are now fixed) as well as 27 other related bugs and DX fixes. All the issues opened or worked on during the sprint can bee seen under the tag D8 Accelerate NJ.

Take-away lessons

Identifying key issues in advance made the sprint more productive, as did meeting via video chat and in IRC to discuss possible solutions ahead of time. The pending deadline of the sprint helped push contributors to forge consensus and begin work on the issues before the event even happened. Never underestimate the value of a hard deadline!

As always, having the group in the same room (and timezone) with a whiteboard allowed resolution of discussions that would have taken weeks via issue comments and online meetings. We also were able to scale our progress with occasional pair programming and pair code review - very effective for ramping up skilled sprinters to unfamiliar and difficult problem spaces.

In addition, while the sprint was happening at the same time as DrupalCamp NJ activities (and for 2 days in the same building), the sprinters deliberately avoided the presentations or general Drupal mentoring they might have done in other circumstances. This relative lack of distractions was part of what we learned made the prior Ghent sprint a success and it helped maintain the focus at this sprint as well.

The sprinters stayed in 2 adjoining hotels, which made coordination easy.

Changing the sprint room each day initially seemed like it might be a drawback, but instead seemed to keep things a bit fresher. Note, however, that every room had windows and natural light - especially important the first days as people were dealing with jet lag.

It's off-season for New Jersey in January, so the low flight costs that allowed us to fund many more people to come and also accommodated people who made travel plans as late as a week prior to the event. This allowed us to recruit more participants even with a very short time frame to plan. (When the sprint was first given the D8 Accelerate Grant at the end of December, we had only 3 confirmed attendees and just a rough idea of the issues and goals to be addressed.)


The sprint was sponsored by a Drupal Association grant and by Princeton University Web Development Services providing space and logistical support.

In addition, Black Mesh sponsored all travel costs for YesCT, Forum One provided time off for kgoel, Night Kitchen Interactive provided time off for mpdonadio, and Acquia provided several employees' time (pwolanin, effulgentsia, xjm, tim.plunkett, and Wim Leers).

Daily sprint updates from webchick

These daily issue summaries were originally provided by webchick on [meta] Finalize the menu links system.

January 27

A very hyped snow storm leads to the cancelation of all 3 flights coming from Europe - but the snow fell further North and East, so all 3 participants were able to reschedule for the next day.

January 28

Most participants arrived in Princeton and settled in.

January 29

Day one of the sprint! Occupying the lounge at the NE corner of 701 Carnegie, part of the facilities of Princeton University.

Dinner plans were inspired by the DrupalCamp NJ theme for 2015 - a New Jersey diner! Just reading the menu was an exotic treat for the Europeans.

January 30

Occupying a multi-purpose room at the SE Corner of 701 Carnegie.

At the same time, about 70 people participated in 4 Drupal training courses in other rooms on the ground floor.

Thanks to the prompting of Tim Plunkett, dinner was real New Jersey pizza at Nino's Pizza Star in Princeton (a local favorite among the Central NJ Drupal meetup regulars). EclipseGC even treated the group to a Nutella pizza for dessert!

January 31

Occupying room 111 at the Friend Engineering Center, on the campus of Princeton University. In the neighboring rooms the sessions and BoFs were happening for the 4th annual DrupalCamp NJ. The sprinters were counted among the 257 registered attendees.

February 1

Occupying a (paid) meeting room at the hotel where most sprinters were staying.

Apparently there was some football game going on too.

While most people are headed home tomorrow, there are a few stalwart hangers-on who are staying through to Tuesday.

February 2

People worked together at the hotel or remotely. A Farewell lunch in Princeton was followed by a brief look at the Princeton University campus as a scenic amount of snow fell again.

Categories: Elsewhere

Holger Levsen: 20150205-lts-january-2015

Planet Debian - Thu, 05/02/2015 - 20:39
My LTS January

It was very nice to hear many appreciations for our work on Squeeze LTS during the last weekend at FOSDEM. People really seem to like and use LTS a lot - and start to rely on it. I was approached more than once about Wheezy LTS already...

(Most of my FOSDEM time I spent with reproducible builds however, though this shall be the topic of another report, coming hopefully soon.)

So, about LTS. First I'd like to describe some current practices clearly:

  • the Squeeze LTS team might fix your package without telling the maintainers in advance nor directly: dak will send a mail as usual, but that might be the only notification you'll get. (Plus the DLA send out to the debian-lts-announce mailing list.)
  • when we fix a package we will likely not push these changes into whatever VCS is used for packaging. So when you start working on an update (which is great), please check whether there has been an update before. (We don't do this because we are mean, but because we normally don't have commit access to your VCS...
  • we totally appreciate help from maintainers and everybody else too. We just don't expect it, so we don't go and ask each time there is a DLA to be made. Please do support us & please do talk to us!

I hope this clarifies things. And as usual, things are open for discussion and best practices will change over time.

In January 2014 I spent 12h on Debian LTS work and managed to get four DLAs released, plus I've marked some CVEs as not affecting squeeze. The DLAs I released were:

  • DLA 139-1 for eglibc fixing CVE-2015-0235 also known as the "Ghost" vulnerability. The update itself was simple, testing needed some more attention but then there were also many many user requests asking about the update, and some were providing fixes too. And then many people were happy, though one person seriously complained at FOSDEM that the squeeze update was released full six hours after the wheezy update. I think I didn't really reply to that complaint, though obviously this person was right
  • DLA 140-1 for rpm was quite straightforward to do, thanks to RedHat unsurprisingly providing patches for many rpm releases. There was just a lots of unfuzzying to do...
  • DLA 141-1 for libksba had an easy to pick git commit in upstreams repo too, except that I had to disable the testsuite, but given the patch is 100% trivial I decided that was a safe thing to do.
  • DLA 142-1 for privoxy was a bit more annoying, despite clearly available patches from the maintainers upload to sid: first, I had to convert them from quilt to dpatch format, then I found that 2 ouf 6 CVEs were not affecting the squeeze version as the code ain't present and then I spent almost an hour in total to find+fix 10 whitespace difference in 3 patches. At least there was one patch which needed some more serious changes

Thanks to everyone who is supporting Squeeze LTS in whatever form! We like to hear from you, we love your contributions, but it's also totally ok to silently enjoy a good old quality distribution

Finally, something for the future: checking for previous DLAs is currently best done via said mailing list archive, as DLAs are not yet integrated into the website due to a dependency loop of blocking bugs... see #761945 for a starting point.

Categories: Elsewhere


Subscribe to jfhovinne aggregator