1 / 12

pSPT Topics

January 31 2010, perfSONAR-PS Developers Meeting Jason Zurawski, Internet2 Aaron Brown, Internet2. pSPT Topics. Outline. 3.1 Topics Remaining Releases Critical fixes vs Development Debian 4 is EOL’ed on Feb 15 th Kernel Bingo LTS Kernel vs Vendor Kernels USATLAS/SLAC Request

candy
Download Presentation

pSPT Topics

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. January 31 2010, perfSONAR-PS Developers Meeting Jason Zurawski, Internet2 Aaron Brown, Internet2 pSPT Topics

  2. Outline • 3.1 Topics • Remaining Releases • Critical fixes vs Development • Debian 4 is EOL’ed on Feb 15th • Kernel Bingo • LTS Kernel vs Vendor Kernels • USATLAS/SLAC Request • Support Plan • 3.2 Transition • Late 2010 Target • Features

  3. 3.1 Topics • Remaining Releases • 3.1.2 pushed back to Feb 17th • Beta’s available Feb 10th • Waiting on owamp/powstream bug • Targeting 3.1.3 For Late April (MM time) • Targeting 3.1.4 For July (JTs time), if needed • 3.1.4+ as needed (depends on support and 3.2 transition) • Critical vulnerabilities will send one out sooner. • Turnaround could be fast if all we want to do is fix the bug

  4. 3.1 Topics • Critical fixes vs Development • Proposing a freeze on all non-critical bugs for the pSPT effective after 3.1.2 release • Bug list should be reviewed (Jason will propose ups/downs for current prios) • If we set this expectation now, it will make the 3.2 pill easier to swallow • Should be public about our intentions

  5. 3.1 Topics • Debian 4 is EOL’ed on Feb 15th • Two proposals • Convert to Debian 5 • If we do this, it’s the only thing for a target release • Lots of testing needed • No time estimate available (could be easy, or hard) • Stall • If a critical bug comes out, we need to hope a backport is available • If not, backport ourselves (could be problematic) • Would be a rough 1 – 1.5 years if we continue to support 3.1

  6. Kernel Bingo • Long term support kernel • We went with 2.6.27 lineage due to decision to make this the new LTS kernel (change from 2.6.18) • Kernel is subject to the same regressive fixes elsewhere for CVEs • Does not feature a lot of bleeding edge development • Vendor Kernels • Usually based on something newer (2.6.32) • Update frequently – if we were to adopt would be building constantly • Vendor kernels have their own patches, makes applying web100 harder • MCNC has been doing this for a while…

  7. Kernel Bingo • USATLAS/SLAC Request • All machines in the house are RH lineage, thus are all on the same kernel series • When there is an update, vendor will update quickly • Can patch all machines in 2-4 weeks • Current pSPT breaks this, different lineage and different rules • Solutions: • If we are going to use a non-standard kernel (where standard is RH), we need to be very clear why and state our support structure • We can convert to a RH kernel, upkeep this instead • Would dovetail with 3.2 plans • Would be labor intensive vs current setup

  8. Kernel Bingo • Solutions in order of pain: • Follow sec lists. When we see a CVE, process and alert the communities (perf node list, VOs). Suggest instant steps to comply in the event of a problem, announce when releases will be available to fix. • Automatically update the 2.6.27 kernel when a fix becomes available (even if there is not a CVE that applies to us). Follow same announcement steps as in 1. • Migrate to a vanilla 2.6.32 (or whatever the vendors are using). Apply the same tactic as in 1 (or 2) regarding upgrades • Use stock vendor kernels and apply web100. Would need to monitor what they are using (will be easier when we are in 3.2) and will need to follow same announcement steps as in 1. • Convert all tools that use web100 (ndt/npad) to not use web100. This eliminates some of the problem, but we would still need to follow what the vendors are doing regarding kernels.

  9. Kernel Bingo • Support needs to be defined • We are a small group – building kernels will become a large job. • Can as for VO help • Can automate the process (as much as possible) • Making our intentions known will matter • See related talk about support too • Should work with USATLAS/SLAC since their use case is probably the most extreme – if we beat this we should be good everywhere.

  10. 3.2 Transition • Target is Late Summer 2010 • Should release after pSPS 3.2 • Basic timeline: • Full release of pSPS and associated testing • Define new development process • Everything is an RPM – will need to either use a new SVN or structure the current appropriately • Need to move away from the current monolith build machine, every developer should be able to build using the LiveCD scripts • Beta testing needs to be extensive, we have volunteers • At least a month of solid trials • VOs will be hesitant, Jason will be working with them closely to identify Pilot sites. • Expect high churn in beta phase - probably several rounds.

  11. 3.2 Transition • Slated Features (at a glance): • New Wizard interfaces • May need some Python slinging for the RH menu tie-ins • Re-inventing the wheel on the backend magic • Will not be able to re-use a lot of things • LVM worries? • Upgrade Path? – e.g. is there one? • All RPMs all the time • Install to disk option • New measurement/monitoring services • Circuit/status stuff? • Including other tools (nuttcp support for psb?) • Others?

  12. pSPT Topics January 31 2010, perfSONAR-PS Developers Meeting Jason Zurawski, Internet2 Aaron Brown, Internet2 For more information, visit http://code.google.com/p/perfsonar-ps/wiki/20100131Meet

More Related