Olivier Berger: Configuring the start of multiple docker container with Vagrant in a portable manner
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’).
Here’s an interesting reference post about Vagrant + docker and multiple containers, btw.
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'.
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.)Sponsors
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.
- Issues being worked on at the sprint are being catalogued under the D8 Accelerate NJ tag.
- Formerly critical issue #2413029: Change LinkItem schema to also store a description is no longer critical; upon further inspection this is actually not something links currently do, so totally fine to move to a postponed feature for 8.1.x. Yay.
- The critical issue at #2411333: Create standard logic to handle a entity: URI scheme that was blocking other criticals got committed today. It's the first step in those outlined in #39.
- #2364157: Replace most existing _url calls with Url objects, another critical issue, was also committed; this was one that had been on the go since Amsterdam, and bringing the behemoth critical at #2343669: [PP-2] Remove _l() and _url() officially down to just 3 blockers.
- Looks like we arrived at consensus at #2407913: Discuss/define the minimal UX for adding menu links to entities on how to implement the UI for adding menu links (and resolve a UX problem at the same time, yay!) so spun off another critical at #2416987: Fix UI regression in the menu link form to do implementation.
- Also got to RTBC on two other criticals: #1965074: Add cache wrapper to the UrlGenerator and #2341357: Views entity area config is not deployable and missing dependencies, but they need review from other core maintainers who are not me. :D
- Lots of great work on basically all of the issues in the Menu link sprint hit-list.
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.
- Critical issue #2406749: Use a link field for custom menu link made it in, making us 2 for 3 of menu link UIs that need to be updated to use link field. The final one is at #2416955: Convert MenuLinkContent to use a link widget and being actively worked on as I write this!
- The data model of menu links is now finalized with the commit of #2412509: Change LinkItem.uri to type 'uri' rather than 'string' and introduce user-path: scheme. Also added support for the user-path: schema in critical issue #2417333: Add support for user-path: scheme to Url class.
- This in turn unblocks work on the family of criticals around removing old calls to _l() and _url(). Hopefully we'll have good news on that front tomorrow! EDIT I lied. Tonight! :) #2368653: Replace _l in all places (3) besides one.
- So far the sprint has contributed to the killing of 7 D8 upgrade path blockers. Assuming the final 3 menu/router ones make it in (and we don't find new ones creeping about), we'll be down to only 6 issues blocking a D8 upgrade path!
- We're now at 66 criticals, the lowest we've been so far in the 8.0.0 beta cycle. :D
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.
- Critical, D8 upgrade path blocker issue #2416955: Convert MenuLinkContent to use a link widget made it in early this morning, making us officially done with the link conversions! Yeah!
- This unblocked progress on #2417423: Re-process the user-entered-paths for custom menu links when there is a menu rebuild, which is the last D8 upgrade path blocker in the set, and was actively being worked on throughout the day.
- Critical issue #2417793: Allow entity: URIs to be entered in link fields was the second big commit, which added support for the entity: URI scheme.
- As a result, the critical UI issue at #2418017: [PP-1] Implement autocomplete UI for the link widget is now unblocked for your patching pleasure! :) Note that there's also #2416987: Fix UI regression in the menu link form which is attempting to fix a few UX regressions caused by moving to the link field.
- Also committed a few other patches to lay the ground work for some of the remaining criticals. Good luck tomorrow, sprinters!
Occupying a (paid) meeting room at the hotel where most sprinters were staying.
Apparently there was some football game going on too.
- #2417837: Update menu link definitions when aliases change and #2417423: Re-process the user-entered-paths for custom menu links when there is a menu rebuild made it in today, officially marking the end of D8 upgrade path issues related to menu / routing! BOOM! Only 6 of those upgrade path blockers left now, so the end is in sight!
- #2418139: Add a toUriString method to Url class and add a route: scheme also landed, clearing the path for more _l()/_url() removal. Next in line is #2404603: Add proper support for Url objects in FieldPluginBase::renderAsLink(), so we can remove EntityInterface::getSystemPath(). Will the patch fairy visit them in the night? Stay tuned!
- In UI land, #1959806: Provide a generic 'entity_autocomplete' Form API element made its way to RTBC, pending review from entity/field API maintainers. In the meantime, steady progress has been happening at #2418017: [PP-1] Implement autocomplete UI for the link widget. Here's a preview!
(Note that yes, the fieldset looks wonky; that's being cleaned up in #2416987: Fix UI regression in the menu link form.)
Yes, no more need to sit down and patiently explain to your content authors what a path is, which requires explaining what a URL is, which then requires explaining what all those funny slashes are for, which then requires you developing a drinking habit. Nay! Now they can simply type the name of a piece of content on their site and voilà! It is linked.
While there are still some test failures to figure out, the new UI is definitely en route (Eh? Eh? Get it? ;))
- We're now down to 64 critical issues in total! And while the numbers are still coming in, we already know at this point that this sprint has been responsible for either fixing or demoting at least 17 critical issues in total. In 4 days. And a huge blizzard. Amazing!
While most people are headed home tomorrow, there are a few stalwart hangers-on who are staying through to Tuesday.
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.
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.