CASA Build and Test Group Meeting
Thursday, 26th March, 2015, 15:00; Room ER245.
Thursday, 26th March, 2015, 13:00; Room (N/A)
Friday, 28th March, 2014, 05:00).
- System: Polycom HDX 7000
- Video Name: CV-ER245
- VideoIP: 188.8.131.52
- VideoHub Name: CV-ER245-hub
- VideoHubIP: 184.108.40.206##6523
- AudioHub: 434-817-6285
- Phoneconf Info
- ConferencePhone: 434-295-7123
- ConferenceHub (30 line): 434-295-1363
Mark, Darrell, Ville, Andy, Akeem
Post-meeting edits and additions in blue text.
- Status of current CASA packages
- Release - 4.3.1 out for OS X (10.8) and RHEL 5 and 6
- 4.4 test/stable packages routinely being produced for RHEL5 and 6
- Pre-release branch creation currently blocked by ASAP-related build issues for OS X (10.10). Any other roadblocks currently anticipated (e.g. 3rd party packages, etc.)? Pyfits issue - probably fixed, would be good to test (Darrell had to put in a bugfix for numpy to successfully compile on RHEL5)
- Masaya to act as interim (occasional) contact for B&T group for the handling of (e.g.) NAOJ CASA site deployment issues, etc.
- CASA SD User Testing oversight to transfer from Bunyo Hatsukade to Erik Muller as of April 1st
- Build and Test Review Status
- Casacore unification - Being worked on now. For reference, Jim's proposed plan was as follows:
- 0.5. Attempt to build against the GC casacore and identify problems. Done.
- 0.75. Iteratively fix bugs and attempt to build again. This was Shinnosuke's B&T primary assignment. Done.
- 1. Merge our Casacore into GC casacore. This will require us to flush all casacore mods in and then let Ger do the final merge (finally). Done.
- 2. Build CASA against GC casacore (platforms?) Done for Linux.
- 3. Test CASA/GC casacore against our various regression tests, etc. Done for Linux - can pass.
- 4. Create a Jenkins job that will handle B&T of codebase using GC casacore. See also below agenda item on Jenkins
- 5. Keep a cached, read-only copy of GC casacore locally(?) to prevent a glitch at googlecode/github from allowing us to build. Also we should maintain periodic a backup copies.
- 5.5. Survive the migration from GC to GitHub... (A parenthetical thumbs-up for BitBucket from Darrell here).
- 6. Go live and live happily ever after.
- B&T news/items from EA.
- B&T news/items from Charlottesville.
- Ville's nightly regression test reporting summary table now works! URL to be circulated. Akeem's testing using Pybot, so could be relatively easily integrated as well, but that doing this right now would be a little premature, as there was still work to be done by the test group first (e.g. for MPI work, Sandra and Justo want more than one machine to be used). There may be a need to add additional new "sub-cells" to Ville's table, in order to support multi-stage testing. Note: Updates to the logging should not be happening when the cron job that updates the table is running. Robot Framework produces pretty good reports.
- Use (or not) of Jenkins in regression test reporting? Villee generally endorsed the way that the casa-cbts server had been configured by Scott: it seems to follow the recommended conventions for Jenkins usage. He had also experimented with a Jenkins/Robot/Gradle plug-in mock-up. The plug-in seems to work OK, but it is unclear how to set up the master/slave configuration options in such a way that it makes sense for us right now: the logging data ends up in a fairly obscure location, etc. A Jenkins set-up for multiple types of clients would require quite a lot more work to set up and maintain. A Docker container approach might help?
- Review short-term task priority lists
- Ville: Ville had been working on the Jenkins/Robot/Gradle plug-in mock-up, would like to spend a bit more time looking at the casa-cbts server set-up, and on nightly test reporting improvements. Other pending work included starting assessing developer tools, and packaging (and testing) automation for OS X. We are already close to having one set of scripts that will handle RHEL and OS X. It was decided during the meeting that Ville's high priority items for the short term should be:
- OS X build machine set-up and automation; Ville asked about the availability of OS X machines that could be used for running the nightly regression test suites. Some of the Macs he is aware of at the AOC are currently in use by developers.
- Look into the building of the tasks/tools documentation. The plan will be to muddle through as best we can for the 4.4 release, and seriously review the documentation requirements (and hence their production) post-4.4.
- Documentation (task/tools) - longer-term plans? Mark to push for an internal review of this, post-4.4. To be informed by Ville's experience of working with it for 4.4 (see above). Ville should ping Mark and/or Darrell as needed for additional information regarding the current task/tools build process (such as it is...).
- Overall group goals for the 4.5 development period? (Not specifically discussed due to time constraints).
- Early results on performance on the cbt test VMs versus a dedicated machine (e.g. icarus has 4 processors - each Intel(R) Core(TM) i5-4670 CPU @ 3.40GHz, 8 G mem, cbt-el6-1 has 4 processors - QEMU Virtual CPU version (cpu64-rhel6), 16 G mem) Akeem's initial like-for-like performance tests are difficult to interpret right now, as they run a little differently each time. He did report that the VM-based tests take about 50% more time to run than the "bare-metal" tests.
- Reporting out on the "Accepted" pool test results Darrell can help the testing group a little with this, if needed.
- Publicizing the process of submitting newly developed tests to be added to the framework. The testing group will be the gatekeepers. The plan for this is that Andy will draft a wiki page to describe the test submission process for the developers. This page will be reviewed by those present at the meeting, and will not be circulated until one or more tests have actually gone through the whole process (as a "test particle"). Akeem already has a particular test in mind. Sandra's MPI test may also be a suitable example for this.
- Old Action Items
- Andy: Discuss Jenkins test for check-ins on OS X with Alexis: same (or different?) smoke tests for OS X as for Linux? Related: machines in Socorro for this? (See above). (It was noted during the meeting that this AI is not a pressing issue at this point). Andy had started to have some discussion with Alexis about this. Smoke tests will be run on the new Test Group Macs. They still need to discuss test coverage for OS X and Linux. Ongoing? Ongoing, with the understanding that this is a lower priority item than Alexis' other work, and that his remaining contract period is limited.
- * Action Item on Mark from NAOJ: Raise the issue of software license conformance with Jeff and Joe, just to make sure we're doing the right thing. Issue previously raised; no reply so far. Can we just close this one? Generally, this is not historically an issue for the project. Closed.
- Next meeting: 7th April, 2015.
- Any Other Business
- Andy noted that he still needs to provide a recommendation for an NRAo-wide C++ testing framework. He will focus his initial search on Open Source options. This will probably need to be a post-4.4 activity now.
- Darrell had switched off a number of the old auto-mailing cron jobs, and no-one had complained so far.
- Mark reported on a recent discussion regarding the observatory's reliance on cron jobs running on an old machine that made use of a copy of AIPS++ based on Kumar's desktop machine. These cron jobs are Glish-based, and are responsible for retrieving updates to geodetic data that are vital to ALMA's ongoing operation. The intention duing the 4.5 development cycle is to replace these scripts with something newer (and on more-suitable hardware!). Dirk Petry had expressed interest in working on this problem, if time allows. The matter has been raised with CASA management for prioritization. A Juergen-maintained wiki page related to this topic is also being updated.
New Action Items Arising