Launchpad code hosting unavailable 22.00 UTC 2012-08-17
Published by Matthew Revell August 16, 2012 in Notifications
Launchpad’s code hosting will be unavailable, due to planned maintenance, for four hours starting 22.00 UTC on Friday the 17th August.
This will affect pushing to and pulling from branches, merge proposals, build from branch and translations activity involving code branches. It is in addition to the already announced disruption to Personal Package Archives for the same time.
Starts: 22.00 UTC 2012-08-17
Expected back by: 02.00 UTC 2012-08-18
We’re sorry for the disruption to your service.
Disruption to PPA uploading and building
Published by Laura czajkowski August 15, 2012 in Notifications
Launchpad services will be affected by scheduled maintenance from 22:00 UTC Friday 17th August until 02:00 UTC Saturday 18th August.
During this time, you’ll be unable to upload or build PPA packages. However, packages will remain available for download from PPAs just like normal.
Maintenance starts: 22:00UTC Friday 17th August
Expected back: 02:00 UTC Saturday 18th August
Thanks for your patience while we maintain the hardware powering these services.
Launchpad downtime August 16th
Published by Laura czajkowski in Notifications
Launchpad PPA build services will be affected by an emergency maintenance between 07.00UTC and 19.00 UTC on Thursday 16th August.
During this time there will be significantly reduced capacity in the PPA build farm.
Official Ubuntu distribution builders will be largely unaffected by this maintenance.
Interruption starts: 07.00 UTC 16th August 2012
Expected back: 19.00 UTC 16th August 2012
Thanks for your patience while we maintain the hardware powering these services.
New fastdowntime schedule
Published by Robert Collins August 14, 2012 in General
For the last year, Launchpad has been doing schema patches using a process we call ‘FDT’, short for Fast Down Time. We have applied 60 such patches, typically taking between 60 and 90 seconds each time, at 1000UTC, our scheduled daily 5 minute downtime window for DB patching.
Recently, we eliminated Slony from our environment, which has dropped the overhead of schema patches to ~6 seconds, and this gives us <10 second downtimes to apply schema patches. We’re taking advantage of this to add two new downtime windows at 0200 UTC and 1800 UTC. All three windows will be for 10 seconds. Hopefully you will never notice that we’re doing schema patches. But if Launchpad is offline for a few seconds at one of these times, you’ll know why – we’re busy rolling out a schema change to bring a new feature to life.
Project maintainers can see private bugs
Published by Curtis Hovey July 23, 2012 in General
Project maintainers can now see all the private bugs in their project. While Launchpad tried to ensure the proper people could see private bugs in the past, the old subscription mechanism was brittle. Users could unsubscribe themselves and lose access, or retarget a bug to another projects which does not update bug subscriptions. The Purple squad migrated project configurations to project sharing so that all private information was shared with project maintainers. Project sharing ensures that confidential information is disclosed to the proper people.
If you are a project maintainer, you might be surprised to find old private bugs that you have never seen before. This happened to me. Some ancient private bugs were in the “New” listing of bugs, other were buried in search results. You can search for just private bugs to review all private bugs.
Privacy terminology is restored
We reverted the information type terminology changes introduced a few months ago.
- User data ➙ Private
- Embargoed Security ➙ Private Security
- Unembargoed Security ➙ Public Security
While the jargon-laden terms helped the small number of people who work with confidential information, the people who report bugs were confused. The most common reason for unwanted disclosure is that people enter confidential information, and cannot see how to make it private. Sometimes a user may not notice the mistake until a few minutes later. We also revised the descriptions of the information types to help new users quickly select the correct information type.
You can hide your bug and question comments
Published by Curtis Hovey in General
You can now hide your own bug and question comments. If you want to hide a comment made in error, you can use the “Hide comment” action.
You can see it, and even unhide it if you choose. The project’s maintainer or the trusted people delegated to work with private information can still see your comment.
This allows you, or the people the project shares private information with, to hide just the comments that contain personal information. The bug does not need to be made private if the comment can be hidden. Project maintainers can also hide comments because they contain spam or abuse.
Beta test: asynchronous PPA package copies
Published by Colin Watson July 18, 2012 in General
The Ubuntu Foundations team has sponsored work on various improvements to Launchpad’s archive handling lately, mainly to expose various new facilities on the API where we were previously using privileged scripts. This has involved cleaning up a substantial amount of old code along the way, and it has become possible to fix some other old bugs as spin-offs.
One of these old bugs is “Archive:+copy-packages nearly unusable due to timeouts”. The +copy-packages page allows anyone who can upload to a PPA to instead copy packages from another PPA. This saves effort, and in the “Copy existing binaries” mode it can save a substantial amount of build time as well. For example, the LibreOffice packaging team uses this to deliver packages to different sets of users after they have passed various levels of testing.
Unfortunately, the very cases where this is most useful, namely large and complex packages, are also the cases where it is most likely to break. Copying large numbers of binary packages involves large numbers of database queries and can quite easily overrun the timeout for a single request to the Launchpad web application. Doing this for several series at once, a common case which seems reasonable, is proportionally less likely to work. Various attempts have been made to optimise the database interactions here, but ultimately doing lots of complex synchronous work in time for a single web request is doomed to failure.
The solution to all this is to copy packages asynchronously. For some time Launchpad has had the ability to schedule “package copy jobs” which run very shortly after the request (typically within a minute) but not immediately. For example, the Ubuntu team uses these when copying new versions of packages from Debian unstable in cases where there are no Ubuntu-specific modifications, and when releasing proposed updates to stable releases for general use after verification. A similar facility has been present in the code for the +copy-packages page for some time, but not exposed due to various bugs. We believe that these bugs have been fixed now, and so we would like to start copying packages asynchronously when requested via the web UI.
We have exposed this to beta testers first. The effect is that, if you are a beta tester when you ask for packages to be copied, you will be told something like “Requested sync of 2 packages. Please allow some time for these to be processed.” The processing should normally happen within a minute or two, and you will be able to see it in progress on the +packages page for the target archive. If it succeeds, the in-progress notification will be removed and you will be able to see the changes in the target archive. Otherwise, you will see a failure notification along these lines:
If beta-testing goes well, then we will enable this for all users, and remove the old synchronous copying code shortly afterwards; so please do report any problems you see.
If you are relying on package copies in the web UI happening immediately rather than within a few minutes, firstly, please contact us (e.g. #launchpad-dev on freenode IRC, or launchpad-users@lists.launchpad.net) as we would like to understand your requirements in more detail; secondly, you may be able to use the Archive.syncSource API method instead, which also has timeout constraints but is at least guaranteed to remain synchronous. However, we hope that most people will not have such a requirement.
Bug reporting and search knows about privacy
Published by Curtis Hovey July 16, 2012 in General
The Purple squad recently updated bug reporting and searching to understand the new privacy rules. Some of the changes were requirements to support sharing, others were opportunities we took advantage of.
Improvements to bug reporting and forms
The Purple squad updated the bug reporting UI to make it consistent with the bug pages. We choose to develop one consistent and tested UI rather than update the many kinds of widgets used in bug forms.
- Project maintainers, drivers, and bug supervisors can report private bugs.
- Autocomplete works with bug tags
- The status and importance controls show their definitions.
- Undecided is the first importance because it is the default importance.
Improvements to bug searching
Advanced bug search was updated after we discovered that recent changes made it possible fix some long standing issues with a few additional lines of code.
- Anyone can search for Private or Embargoed Security bugs that are shared with them.
- Autocomplete works with bug tags.
Usability and Accessibility fixes
We discovered that the popups that show bug status, importance and information type did not work with keyboards. It was possible to tab out of every other kind of popup by accident. We made deep fixes to the code so that all launchpad popups work with keyboard.
- You can use the tab key to move between the items in popups.
- You cannot accidentally tab out of any popup.
Launchpad does not have private projects…yet.
Published by Curtis Hovey July 13, 2012 in General
Nothing breaks my heart quite like a request to make a project private–make it invisible to everyone except to the people the project trusts. I am utterly crushed when someone who works for Canonical or on Launchpad asks for one. I have been planning this feature for more than two years, and the Purple squad has been working on it for 13 months. I blog about this, I send emails about this, I present reports on this, but the people who most need private projects don’t know what the Purple squad is doing. I think the problem here is that Launchpad squads no longer use Launchpad to plan and execute work. There is no place for any interested party to see what the goals of Disclosure is and gauge how we are progressing.
I present my first draft of a report that states the simple goals of that the Disclosure feature wants to achieve . The report provides some summaries of the work that allows anyone to see what the Purple squad is doing, recently done, and will do next. There is also some analysis that provides insight into the amount of work remaining. This report complements the Purple squad’s kanban board. While kanban is excellent for tracking branches of code and technical tasks, the level of detail is unsuitable for non-Launchpad developers. The kanban board is also only accessible to a small number of people. I want a report that anyone interested in private projects or managing the disclosure of private information can see and understand. Mostly, I want everyone to see that the Purple squad is delivering valuable features and know when we will be done.
I based the report on the intended reporting UI for Launchpad series and milestones. I really miss using series and milestones to plan releases. For every milestone, I wrote our goals in the summary, and targeted bugs to the milestone. Though we abandoned the analytics because of performance concerns, I could reliably judge the contributors’ velocity, and see when I needed to retarget work to another milestone because the remaining effort exceeded the milestone’s work capacity. Though I didn’t provide a burn down chart of the work, I could sort the milestone to see the colour change. I could confidently see and predict 3 months of work.
This report replaces the canvas-based chart I planned for series and milestones with a YUI 3 chart. The listing of bugs are split into categories so that I can focus on scheduling or provide Diogo with a list of bugs that need exploratory testing. Though this report thinks it is talking to Launchpad, it is actually using JSON for the 500+ bugs that I pulled using a trivial Launchpad API script. Since the data is cheap to retrieve, I can load the chart multiple times, each looking a different set of bug tags so that I can see specific themes of work.
The report shows that there is more than 60 days of work to complete the features needed by private projects. The Orange squad will work on private projects while the Purple squad finishes the prerequisites.
Webinar on Ubuntu MAAS: Metal as a Service
Published by Laura czajkowski July 11, 2012 in General
Some of us on the Launchpad team have been working on Ubuntu’s MAAS (Metal as a Service) over the past few months.
MAAS is all about giving your physical servers the flexibility and ease of deployment you’ve come to expect from the cloud. With MAAS your cluster of ten, one thousand or a hundred thousand servers becomes a single, reusable, pool of computing resource that you can pull up and tear down just like VMs in the cloud.
Tomorrow, Matthew from the Launchpad team is hosting a couple of webinars introducing MAAS. They’re both the same content but at different times.
If you’re interested, sign up for the 15,00 UTC talk or the later one at 18.00 UTC.
