Link Search Menu Expand Document

ASWF CI Working Group

Meeting: 9 January 2019

Attendees

Wayne Arnold (Autodesk)

Aloys Baillet (Animal Logic)

Jeff Bradley (DWA)

Mark Elendt (SideFX)

Larry Gritz (Sony)

Thanh Ha (LF)

Daniel Heckenberg (AL, TAC Chair)

Patrick Hodoul (Autodesk)

John Mertic (LF)

Jean-François Panisset (VES Tech Committee)

Trevor Thomson (Blue Sky)

Robert Vinluan (SideFX)

Agenda & Notes

ASWF TAC Goals for Year 1

  • 6 projects:

    • Environment configuration?

    • Rez?

    • Docker?

  • Stretch goals:

    • Downloadable and installable artefacts

    • Windows, Mac support

Packer config to build VFX Reference Platform (Aloys)

  • Packer, Docker, OpenStack

  • Conan.io

    • Aloys’ branch : use Docker to build TBB, Boost, IlmBase

    • Probably not a scalable solution for supporting multiple packages that can be distributed

    • AL has been using Rez for many years with a lot of success, but move to VFX Reference Platform 2018 showed that moving to new compiler toolchain is difficult in Rez

    • Conan has more flexible way of working with multiple compiler toolchains, OS platforms.

    • Conan uses a hash to capture the environment you used (tools, build options…) so you can identify a binary based on its hash

    • Conan has good documentation, was able to make use of it mostly from docs and sample code with minimal Stack Overflow googling

    • Haven’t created a PR yet, since for now it’s more an experiment for discussion purposes

    • Found working recipes for TBB, Boost, OpenEXR, what was found online wasn’t always up to our requirements.

    • Aloys feels that whereas Rez remains essential to deploying software in studios, Conan may be workable solution to building software, and eventually it may be possible to make the two interoperate.

    • Thanh asked “why do we want to create a separate OpenEXR job / artifact when we already have a separate job in the CI infrastructure”: Aloys sees that maintaining the OpenEXR project itself may be a somewhat separate goal from maintaining a VFX Reference Platform compliant OpenEXR build / distribution. We should clarify those goals and how we should create Jenkins jobs to fill these goals. Thanh suggests we reuse the same OpenEXR job templates from the official OpenEXR project with a different “stream” for VFX Reference Platform. Many LF projects use “streams” to build certain branches / LTS release, so OpenEXR project could have streams based on major versions, and there could be a “stream” for VFX Reference Platform builds / versions. This allows work on job templates from the main project to be reused. Aloys started trying to use that mechanism by using “vfx2018” as the stream name for the 2018 VFX Reference Platform.

    • Aloys used Docker containers to build under CentOS 7 (with Ubuntu as the Docker host).

    • Daniel: what are the impacts of introducing a new technology like Conan in a build environment (learning curve for instance, impact on the facility). Rez / Conan can be quite “opinionated”. Experience at Animal Logic is that Rez can be difficult to implement in a CI environment. Conan may be cleaner for that purpose.

    • CMake-based project suggest may introduce fewer dependencies, but scalability with large number of packages becomes an issue.

    • Trevor: how does this interact with needing multiple versions of the Reference Platform support multiple Maya versions? Aloys: Conan can do this in a non-opinionated way, you can declare your dependencies up front, it will generate a CMake file with the paths you need, you can invoke that in your own CMake file. Conan doesn’t handle deployment to the end user (that would probably be done by Rez). Conan can be contained to just the build environment, doesn’t need to impact deployment to the studio.

    • For a vendor, if they use Conan, the resulting binaries would be packaged in a directory, which can then be zip’ed / packaged in the installer as part of the application. Studios will need a more complex distribution mechanism for their internal uses.

    • Jeff Bradley: DWA is pretty strict about what code can be pulled into the facility, where would Conan pull code from? Aloys: you can install your own Conan server (open source), so no dependency on Internet. Can configure your remote repos to be internal or external. Conan server is integrated in Artifactory (same developers).

    • Daniel: asking Larry how this would interact with changes to CMake scripts for instance. From the point of view of a downstream consumer, it seems that Conan would solve problems in better way than Rez and solve a number of real problems, but adds a layer of complexity and learning curve. Larry: not a lot of Conan experience, and believes not many studios do. Feels that not only is the task to get the CI up and running, but to provide a way for studios to effectively consume and manage versions of ASWF software. But we shouldn’t be afraid of the Rez solution since there are long term benefits to going with that.

    • Aloys, Larry: CMake project is still very useful, and mostly orthogonal project.

    • Daniel asking Thanh for comments about some of the PRs so far: he doesn’t see any issues with the PR so fars in the context of the LF infrastructure. But if we introduce new tools it needs to be determined who is responsible for managing those looks, and in particular whether the LF team.

    • Nexus3 does have a Conan plugin, so that could provide an integration point (it isn’t enabled in the current LF infrastructure, open source plugin, not officially supported by the SonaType). Opening a helpdesk ticket is the way to get this work started.

    • Larry: are the needs of our projects so different than other LF foundations / projects, and is there existing infrastructure that could be leveraged. Thanh: his experience is OpenDaylight which is Java, so very different tools / requirements. There are C/C++ LF projects such as FD.IO, EdgeX (mostly Go, but come C/C++, so would be a good idea to talk to folks on those projects to see if there’s anything we can reuse). Some of these projects are using Docker for their deployments, so they are building end-user containers rather than delivering libraries.

    • Daniel: our environment heavily relies on heavily nested C/C++ plugins hierarchies, with commercial libraries / host applications, which somewhat differentiates the VFX environment. John says he’s been working in the issue of how to integrate licenses of commercials apps / libraries in an open source environment.

    • Aloys: Conan seems to want to be the de facto package manager for C/C++ projects, the way npm for Javascript, Pip for Python, and Maven for Java.

Documentation / Getting Started

CII Badge Automation Support

  • clang-tidy vs SonarQube, and other tools

  • specific badge requirements

    • Candidate tools: cppcheck, clang-tidy, coverity (free scans for open source projects with time limit)

    • “All medium and high severity exploitable vulnerabilities discovered with static code analysis MUST be fixed in a timely way after they are confirmed. (N/A allowed.)”

None of these tools provide explicit mapping between their reports with CVSS severity levels.

  • Example C++ project with CII badge: https://github.com/nlohmann/json

  • OpenVDB, OpenEXR projects are working on these issues to achieve this certification.

  • Jeff: not specifically involved in OpenVDB project, but DWA is evaluating checking for its internal code. Flawfinder is fast, describes which vulnerability it finds.

  • Larry: working its way through requirements for OpenColorIO, some requirements are not relevant, some are things that were already done. Static analysis is the “big mystery”, unclear how relevant some of the vulnerabilities are, especially in the context of a segregated studio network. But OpenColorIO is incorporated into a lot of third party applications and could become an “attack surface”, so need to do fuzz testing for input formats (LUTs for instance).

  • John: is the main concern the selection of the tool or how to interpret the results of these tools. Larry: interpretation of reports is fairly straightforward, but the hard part is figuring out which of those reports is relevant, so getting hundreds of reports would result in a large amount of work trying to fix issues which may not be relevant. John: sounds like it may make sense to specify the tooling for static analysis, and is configured at the right “warning level” for the requirements of ASWF projects. Larry: what developers want is something like “here’s the 30 clang-tidy (say) tests that need to be fixed to get the CII badge”. Jeff: hard part is figuring out what level to of severity needs to be set, and rules for fixing issues at different severity levels.

  • Thanh: currently infrastructure only provides Sonar and NexusIQ, have to use provided templates, currently no Sonar template for C/C++ projects. John: looks like there’s a significant amount of work on the LF engineering side. Thanh: doesn’t believe there’s a lot of existing C/C++ static analysis expertise at LF right now, so ASWF may be leading the way here.

  • Daniel pinged the CII mailing list about these issues, hasn’t heard back yet.

  • Daniel: Issue of C/C++ commercial vs open source/community Sonar plugins. The community supported plugin may work best in our environment.

  • John: LF doesn’t see a lot of C/C++ projects in its foundation projects, mostly Java and Python, but hopefully can provide some expertise. Largest C project is the Linux kernel, but they just publish a tarball, they don’t publish binaries. Companies like RedHat do a lot of the work of static analysis.

Next Steps

  • Follow up meeting: 23 January 2019