Offsite Hosting Notes

Coopr Proposal from Bill Hart

The following discussion concerns the question of whether to integrate the Coopr software into COIN-OR. The proposal would host Coopr at off-site, which raises issues that have not been resolved with the integration of LEMON.

I heard two things at INFORMS that suggest that we reconsider whether to add Coopr (and specifically Pyomo) into COIN-OR:

• The LEMON package suggests a strategy for managing Coopr outside of COIN-OR, which would address my previous concerns about relying on COIN-OR infrastructure for SNL business needs. (You may recall that those concerns led me to withdraw the submission of Coopr last year.)

• Several people pointed out the clear need for modeling tools in COIN-OR, which is a gap that Pyomo fills.

Given this, I’d like to discuss whether it makes sense to integrate Coopr into COIN-OR while retaining management of the software at Sandia. I've discussed the integration of Coopr in COIN-OR with Sandia management, and there is a preference for this loosely-coupled model since this allows Sandia to control the Coopr software to meet our business needs. (For example, to address sysadmin issues like Trac upgrades.)

Despite the integration of LEMON, it seems that the requirements for integration a project like Coopr are not well defined. Here's my proposal for doing this:

1. Host the main subversion and Trac packages at Sandia (see https://software.sandia.gov/trac/coopr)

2. Automatically mirror the subversion repository to COIN-OR

3. Have a simple COIN-OR Trac page that (a) references the main Coopr page and (b) supports downloads for a Coopr installer script. [Since Coopr is Python, we expect most users to either (1) install from the PyPI repository directly (using the easy_install command), or (2) use an installer script that I've developed to build a virtual Python installation that contains Coopr and related packages.]

4. We could use the coin-or mailing list for the Coopr project. [FWIW, I think that the mailing support in COIN-OR is inadequate; for example, I've found the the google code forums to be much easier to search and navigate. However, Sandia supports an equivalently bad solution for email lists.]

5. I do not see a convenient way to synchronize tickets between the Trac repositories. I would suggest that we simply lock the ticket mechanism within COIN-OR or redirect ticket submissions to the Sandia Trac site.

There is one downside to hosting Coopr at Sandia: foreign national collaborators need to process some paperwork before we can give them access to the machine that hosts the code. In the short term, this isn't an issue since (a) we allow anonymous ticket submissions and (b) we don't have any foreign software developers. My management has agreed that if this process becomes a burden then that would be a reason to migrate off of Sandia's computers.

However, to mitigate this risk, we have (a) developed Coopr in a very modular manner and (b) we've setup a google code project: Coopr Forum (see http://code.google.com/p/coopr-forum/). Our goal is to make it easy for external developers to create extensions to the Coopr code base and then make them available to the OR community. Developing in Python encourages this type of community development (which has been quite successful for the Trac project). One possibility that we should also consider is the migration of Coopr Forum to COIN-OR. Perhaps the Coopr Trac site in COIN-OR provides this community of extensions???

Comments

Ted

This looks very workable to me and I think addresses most of the concerns that came up during the LEMON discussion. We need to work on a generic policy for how we handle off-site hosting generally.