Given that OS X is the primary platform for a huge segment of astronomy, we really need to think seriously about getting CI for OS X. I don’t know how we’d want to do this — a Mac Mini on someone’s shelf, co-located somewhere, and/or inside VMWare — but it would be nice to stand something up quickly to help prevent us from publishing tagged releases that don’t work on OS X (see DM-3655).
I agree completely. Although I don’t think it would have found the problems in that ticket because it seems that they are both caused by extra libraries on the system (FFTW or PLplot) and CI systems are usually set up to be minimalist.
That still has to be running on an actual Mac somewhere.
We have an actual Mac at NCSA and have talked about buying more, but the problem (I believe) has been getting root access. Perhaps virtualizing might help with that.
That’s true. But I suspect that OS X systems are often more ‘lived-in’ than their Linux counterparts. Ideally we’d want to test against a matrix of OS X VMs with real-world setups (e.g., using their own anaconda, or using a homebrew Python and using homebrewed dependencies, etc, and having realistic sets of other astronomy software installed.
I may be asking for too much… ¯\_(ツ)_/¯
NCSA is planning to setup 3 Mac nodes dedicated to CI use. Our plan is to always have the 3 most recent major OS X releases (which would currently be OS X 10.8.x, 10.9.x, & 10.10x) available for CI.
But I also like the idea developers voluntarily offering up real life nodes for CI testing as well.
Would it also be worthwhile to have a dedicated CI system for public betas of upcoming OS X releases when they exist? I expect a significant fraction of our Mac user- (and developer-) base will want to upgrade to new versions soon after release.
See also DM-3200.
(But of course that runs the risk of us chasing Apple’s bugs, which will be resolved prior to release, rather than our own…)
I’m not that enthusiastic about running public betas. Not only am I OK with being (a little) behind the curve for both OS X and Linux, but I worry about the administrator time necessary to install and update the beta OS. I’d say that betas are not a priority for now, and just getting official release support will be a big improvement.
I’d be happy with current and previous. Given OS updates are free and given that Apple don’t support the old releases I don’t see a need for us to try to do that.
NCSA now has a Mac Pro setup with VMware vSphere that is capable of running a few (~4-8) Mac VMs.
I’m curious who we want to use these Mac VMs and how they would expect to use them. I’d like to keep things as simple as possible to begin with and avoid significant numbers of users or difficult requirements.
- Should they primarily be available as CI nodes and accessible to the SQRE team?
- Are there other DM teams that need access to similar Mac VMs?
- Would remote users be needing to connect via Screen Sharing or ssh?
- Is there a ‘requirement’ to have a fresh install every time CI runs?
- Or a requirement for some users to self provision Mac VMs?
1 Like
I’m guessing Stack CI and SUI/T would be the prime users. I don’t think we want/need everyday developer access to self-provisioned Mac VMs at this time – most have laptops or desktops for that anyway.
Details of provisioning requirements will have to come from others.
Of course there is the Web side of the SUI/T where we need to be sure that we are testing on a variety of platforms and browsers, but of particular interest here is the ability of users to bring up their own Firefly servers in conjunction with their personal development/analysis environment. So the ability to CI the Firefly server side on OS X (including Tomcat, etc.) is of importance.
I (and @danielsf + @ljones) would benefit from access to a Mac VM to be able to generate conda binary packages for OS X.
Shouldn’t that be an output of CI?
Having everything automated would be awesome, of course, but I’d be happy just with access to an OS X machine!