Attendees

Cameras On for the first time!

Agenda & Notes

ASWF CI Goals for Year 1

6 projects:
- Seems goal is achievable, 2 official, one coming soon (EXR),
- Environment configuration?
CI with VFX Reference Platform dependencies
- Commercial components
  - Build
  - Test
Stretch goals:
- Downloadable and installable artefacts (with signing?)
- Windows, Mac support
- Possibly GPU support

Notes from LA Forum

Bring people together, get feedback on how everyone feels the ASWF is coming along. Several instant polls were run, overall the response was “ahead of expectations” / “along expectations”.
Strong interest in package management & environment configuration
Strong interest in Windows & Mac builds. Some early steps were taken with the LF CI infrastructure, but we haven’t had projects or individuals testing out the Windows support yet. How do we bring in expertise from projects or individuals to make this happen faster. Offers from Blur and Epic Games to help with expertise. Also as a Foundation could bring in outside consulting / engineering resources, or draw on specific commitments made by the foundation.
NVIDIA finalizing membership in ASWF, should help with support and expertise on GPUs.
Intel offered to help with security issues, specifically in context of OpenVDB. Both Intel and Autodesk have concept of project “security champions” who interface with company wide security experts.
Gordon (Autodesk): need cross platform support on OpenColorIO, OCIO steering committee could try to establish their immediate priorities for cross platform support to help prioritize CI group efforts. Larry agrees. Patrick has started document and sent to OCIO TSC meeting to provided ordered set of needs for OCIO.
Notes should be in TAC repo as tac/meetings/2019-02-07.md

Project CI requirements

All
- CII badge static analysis
- Dependency management
OpenVDB
- CMake builds and assistance
  - Intel has started to provide support
  - Hoping for ASWF “best practice” or templates (CMakeTools project)
- Transition from Travis-CI to ASWF / LF CI infrastructure. Thanh: project hasn’t switched to Jenkins yet, will provide further points in CI toolchain discussion.
- Houdini for plugin build & test. Thanh: we had the OK from legal to provide the Houdini package needed to build.
- GPU for OpenGL tests?
OpenColorIO
- Patrick: at the beginning of process of figuring out what’s needed to transition to ASWF CI infrastructure.
- Nuke plugin build. Discussion between The Foundry and Linux Foundation, usage of Foundry APIs / NDK, Nuke distribution for build and test. Doug Walker: this was brought up at SIGGRAPH BOF, Foundry was thinking of separating out their plugins, OCIO TSC feels it’s not high priority issue for now.
- GPU?
- Windows, Mac?

VFX Reference Platform Dependencies and Package Management

Posted survey of package management systems for C++ to mailing list
Aloys: 2 main contenders to move forward with, Rez and Conan, could even work together.
We had chat with Allan Johns (Rez author): designed for deployment and package management, but not meant to run a cloud server, download packages… Could extend Rez to do that, or combine something like Conan to do package / artifact management.
There are some package management systems based on CMake, could allow for light weight integration with the CMake infrastructure most of our projects will use.
So we should discuss whether we extend Rez or integrate Conan, non trivial projects, would need dedicated resources.
Jeff: really interested in exploration of building in containers.
Aloys: Docker would be integral part of the solution, should be best place to build the software. We need to figure out the overall architecture / layering.
Jeff: they want to figure out how to deliver their artist facing software as containers. So want to build containers on top of Rez managed packages.
Daniel: Rez as an environment management system vs build time tool. Agrees that we need to figure out the actual approach we will take and how it will be architected.
Trevor: would Rez become an ASWF project? That was a point of discussion when Allan joined a previous call.
Aloys: we should identify some specific prototypes to try before we go ahead and architecting a definitive solution. Gordon agrees.

CI Toolchain

Thanh: some projects are investigating alternatives to Jenkins for CI, in particular CircleCI
Supports Linux and Mac, but not Windows
AppVeyor does Windows builds
We haven’t really started using Jenkins yet, so this might be a time to look at other options.
Larry: curious as to what is the motivation / perceived shortcomings of Jenkins? Is CircleCI a self hosted service? Why not Travis-CI?
Thanh: LF has offered Jenkins for a long time, starting to feel like an “old” tool.
CircleCI has somewhat better integration with GitHub
Plan (for other foundations) would be to use the hosted service.
Does our Jenkins infrastructrure use the “Declarative Pipeline”? No, LF infrastructure uses Jenkins Job Builder.
If we use hosted services, does it make it difficult to use third party commercial apps, as well as GPU?
There is option for self hosted: https://circleci.com/enterprise/
There is a free tier for open source projects. Paid tier is billed by minute, so don’t have to host full time VMs.
Gordon: goals of the foundation is to build the platform we need, should we move to latest & greatest vs leveraging existing Jenkins expertise within organization members. Should we have a straw poll?
Larry: has used Travis and AppVeyor, apparently Travis is in beta for Windows support. Other than the Linux vs Windows differences, conceptual differences between Travis / AppVeyor were minimal.
Thanh: there is a self hosted / enterprise option. Standard Jenkins CI from LF has been very well tested with Linux, but not with Windows / Mac, we have a proof of concept for Windows builds, hasn’t been used in anger yet. Also our Jenkins doesn’t have Mac support yet.
Gordon: we should build a prototype for OCIO which has clear cross platform needs.
Daniel: through ASWF members we have had offers of free or subsidized cloud platform, the more we move away from Jenkins / OpenStack model to a “SaaS” model, the less likely we can leverage those offers (from instance Google GCP). If we are looking to move away from OpenStack / Jenkins, we need to determine what we are trying to optimize for. Agrees we should do lightweight prototyping for OCIO. Also the more we formalize our dependency management, the less complexity we need from the CI system. We should have as little configuration within the CI system as possible, should be handled in our projects.
Daniel: do we foresee issues using something like CircleCI with commercial components (managing secrets, licenses). Robert (SideFX): doesn’t see different issues from LF Jenkins infrastructure. Gordon: does CircleCI work happen on “their” servers, that could affect licensing issues? Current infrastructure runs on a cloud provider (VEXXhost). Gordon: there may be a difference between running a public cloud infrastructure provider that you are paying for, as opposed to some other corporate entity (who may be using a cloud provider themselves). Could trigger some subtle license issues. Gordon: if we are going to make a decision to move away, we need to know better what is motivating the change. Jeff: one factor is bringing in the ability to bring in the infrastructure to inside the company, a for pay solution might be more complicated.
Daniel: taking the “mood of the room”: we aren’t sold on the tradeoff of going to a SaaS model via our own infrastructure, and what we would be gaining vs giving up. Is it worth the investment of time from the LF releng team. Gordon: agrees. From the in person meeting, one of the reasons we picked the LF, we wanted to leverage the infrastructure, and we assumed there would be cross platform support. Travis doesn’t offer GPU instances, CircleCI does.
Daniel: asking Thanh to provide a short summary to present at TAC meeting next week. We should understand the impact on the environment configuration side of things.
Aloys: AL is already using Jenkins, you can run it everywhere (public cloud, on premise), seems a more open system. There’s a difference between “raw” Jenkins and Jenkins deployed by LF, they build VMs and run it on OpenStack cloud provider. At AL they have Jenkins jobs running on Windows / Mac.

Next Steps

Follow up meeting: 13 March 2019