1 / 14

Package Management of VO Records

Package Management of VO Records. Concept: Take XML from Ops Portal, Convert to RPM, Combine with YAIM Logic, Manage Updates with RPM or YUM. Recap. Recap: Ops Portal exports XML – what good it that? Not obvious how to convert to YAIM.

andrew
Download Presentation

Package Management of VO Records

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. Package Management ofVO Records Concept: Take XML from Ops Portal, Convert to RPM, Combine with YAIM Logic, Manage Updates with RPM or YUM

  2. Recap • Recap: • Ops Portal exports XML – what good it that? • Not obvious how to convert to YAIM. • Peter G. wrote “Approved Vos” wiki to contain YAIM records. • This records only need to be transcribed once. • Nonetheless, it went stale. • Answer: Automate doc update (i.e. VomsSnooper). • More problems: Recent Backup VOMS changes took weeks. • Answer: Make it easier – but how? Talk Title Goes Here

  3. Recap • Plenty of ways to do it: • Download VOID card, transcribe yourself manually  • Scrape the records you want from the Approved VOs documents, load into YAIM yourself  • Go directly from the Tarball, supplied on Approved VOs document  • Download site copy of VomsSnooper  • Chris W. suggests: Maybe with RPMs? (?) Talk Title Goes Here

  4. Recap • Amelia Earhart: “The most effective way to do it is to do it.” • But she disappeared (assumed dead). Talk Title Goes Here

  5. Investigation • Results of “doing it”: • 5 line script that can break up the Jumbo VOID cards XML from the ops portal into individual XML for any approved VO. • Put the individual XML into specific RPM for that VO, and rig it up so that the XML gets copied out when the RPM is installed. • New mini-vomssnooper (specific) in Perl called update-voconfig.pl. It uses standard Perl components that “always” get installed (I can't use Java/VomsSnooper because Java may not be installed or have poor version, different components etc.) Talk Title Goes Here

  6. Logic • Logic in update-voconfig.pl to perform config_vomsdir and config_vomses. • Put update-voconfig.pl into the RPM as well. • Use a hook (epilog, trigger, %post, whatever …) into the RPM so the final act is to call update-voconfig.pl. • But RPM calls local-update-voconfig.sh instead, should it be present. So, to customise, place local-update-voconfig.sh that contains any logic you like. Talk Title Goes Here

  7. Details Script has 280 lines of perl • Two classes: • VoidCardHandler – holds a VOID card (just the bits we need), and an interface for a SAX parser. • VomsServer – holds data of one Voms Server. A VoidCardHandler has several of these. • Pass the handler to the SAX parser, feed in the XML, load the data. Then call routines to: • sub checkVo ($); • sub configVomsdir ($) { • sub configVomses ($) { • sub printYaimRecords ($) { • Or anything else you want. Talk Title Goes Here

  8. Bad news • Caveats: Bad news first: The VOMS_SERVER variable is also used by config_mkgridmap. This is (unfortunately) a complex, unstructured monster shell script that does much fixing and poking about in an unfathomable manner. It might take a week to reverse. Talk Title Goes Here

  9. Good news • Good news: Despite the horror story that lies inside config_mkgridmap, the shell script works OK. And, when using central authentication with ARGUS, config_mkgridmap only needs to be run on the ARGUS server and DPM. This bit can be managed by hand. • When (if) DPM moves to central authentication with ARGUS, 50% of the problem vanishes automatically (nice!) • In the fullness of time, further standardisation may make it possible to either (a) replace “gridmap” and its children with a pucker database solution or (b) if “gridmap” and its children persist, then reverse config_mkgridmap into something comprehensible. Talk Title Goes Here

  10. Outcome • Upshot: Here's a draft procedure to update a “typical” site using this prototype RPM scheme: • Update the site-info.def on all servers with newest VO records. This is not necessarily needed in all usecases, but it should be kept up to date as a point of fact. BTW: A feature in update-voconfig.pl prints out the records, so you don't need to scrape the Approved VOs wiki page. • Do update: • WN: Install RPMs. • CREAM: Install RPMs. • ARGUS: Install RPMs (& run config_mkgridmap if new admin voms_servers). • DPM: Install RPMs (& run config_mkgridmap if new admin voms_servers). • Restart services as appropriate (e.g. restart tomcat, ARGUS daemons or DPM daemons). Talk Title Goes Here

  11. Discussion • Problem: is this less work? • At present, you just roll out a new site-info.def and run YAIM everywhere. • Now you can be selective, and avoid running YAIM everywhere. • But you still need to maintain site-info.def (in case you need to run config_mkgridmap). • On the other hand, you can implement your own local-update-config.sh. • If you do so, you can just install RPM and relax. • I dunno – let’s have a think. Talk Title Goes Here

  12. Other ideas Here a way to operate it: • Give it a local-update-config.sh that does nothing • Ask Puppet to do all the config. • Just install RPM; puppet does the rest. Here’s another way to operate it: • Put in a local-update-config.sh in that spits the VOMS records out into the Site-info.def/vo.d dir in YAIM format, • Run YAIM. Talk Title Goes Here

  13. Pros, Cons, Ideas, Infrastructure etc. • Various ideas have come up about control of the material. • For example, we could test the rollout first. • We could put version numbers on the RPMS. • We could sign the RPMS to make them safer. • We could add the management to the Ops Portal or keep it outside and maintain it ourselves. • This could be done in conjunction with the Approved VOs or instead of the Approved VOs document. • Because we have versioned the RPMS, we could manage the adoption with great certainty. • There would be no need to screen scrape the Approved Vos • We could alert sites when rollouts occur. • . • . Talk Title Goes Here

  14. Finally • Assuming (for a moment) that it is less work and assuming no bugs (a big assumption?), then the site is now "Ship Shape and Bristol Fashion" wrt. voms records. • I won't go much further with this until I get some feedback. But I'm going to try this process at L'pool to get things straight, and monitor it (I’ll take my own medicine before giving it to anyone else!) • This may (TBD) represent a viable way to configure a site wrt. VO records. • Cheers, Steve Feedback please? Talk Title Goes Here

More Related