4 ms·

If Rackspace, given their major support for various opensource projects, were to provide POWER9 runners for, say, Gitlab CI, this could be a major help in porti

by cm3 10y ago

If Rackspace, given their major support for various opensource projects, were to provide POWER9 runners for, say, Gitlab CI, this could be a major help in porting software. Or, they could, like IBM provide SSH access to interested projects. But the CI part is important to ensure there's no regression, and given the scarce availability of POWER9 (or even POWER8) hardware to the general public, let alone opensource developers, Gitlab CI integration sounds like the more practical service.

jacques_chester 10y ago
IBM sponsor a fleet of POWER-based systems at the OSU Open Source Lab[1]. Edit: You already said this ("Or, they could, like IBM provide SSH access to interested projects."), and if you'll excuse me, I'm going to go hide in shame. In my day job we've interacted with an IBM team who are porting our entire buildpacks pipeline[2][3] (which uses Concourse) to run on ppc64le. We fall under the Cloud Foundry heading the list of projects. The eventual goal is that we will be able to run x86 workers (on a regular commercial cloud) and some POWER workers at OSU-OSL or SoftLayer, and build both kinds of binaries from the same pipeline. I believe the eventual eventual goal is that all Cloud Foundry pipelines and products will be fully available across both x86 and ppc64le, including first-class integration with any pipeline producing binaries. Given that buildpacks represents the bulk of the binary volume, it makes sense to ensure our entire pipeline works on ppc64le. Disclosure: I work for Pivotal, not IBM, and I'm not able to commit either to anything. [1] http://osuosl.org/services/powerdev http://osuosl.org/services/powerdev [2] https://buildpacks.ci.cf-app.com/ https://buildpacks.ci.cf-app.com/ [3] https://github.com/cloudfoundry/buildpacks-ci https://github.com/cloudfoundry/buildpacks-ci
- cm3 10y ago
  What would be the course of action for an opensource project to set up a CI worker there (ideally per-commit on X branches, not periodic) such that it could be integrated in a pre-merge check? I'm not bound to Gitlab CI runners, but it's the first thing that came to mind given the popularity of github and gitlab.
  - jacques_chester 10y ago
    I honestly have no idea. I imagine access is mediated by OSU, not IBM. The contact page (http://osuosl.org/contact http://osuosl.org/contact) seems like the place to start. One of the tricky parts about running PRs is that you're running arbitrary code, for which the main threat is the exfiltration of secrets. You need to lock down the workers fairly tightly to avoid unintended consequences. I'd be interested in reading more about how Travis, CircleCI, Gitlab et al do it -- some light googling didn't turn up any specifics. Edit: looks like CircleCI call this out explicitly and state their defences -- https://circleci.com/docs/fork-pr-builds/#security-implications-of-running-builds-for-pull-requests-from-forks https://circleci.com/docs/fork-pr-builds/#security-implicati...
    - cm3 10y ago
      That CircleCI post seems to talk about different issues than I see when I think safety of random CI jobs. It's a non-trivial problem to solve, especially with caching of artifacts involved. You'd probably want to run a sandbox inside a vm and secure the vm itself first, while having only ephemeral storage attached. Barring a container escape via just read/write/execve allowed inside the sandbox, which could probably also used to escape the surrounding vm, there isn't much you can do if you support running random stuff in a CI job. Actually, maybe CI needs to be limited to tools that can run on something like ZeroVM. Limiting persistent state and spinning up machines (vm or bare metal) for each job, while having no permanently active job runners, sounds like another defense to consider. That said, I very much doubt any of the CI services goes to such great lengths, given the limitations involved.
      - jacques_chester 10y ago
        > Limiting persistent state and spinning up machines (vm or bare metal) for each job, while having no permanently active job runners, sounds like another defense to consider. I can imagine how I'd do this with Concourse, but it'd be confusingly meta in approach -- a pipeline which builds a new pipeline with a new worker for each PR. I still think the exfiltration threat is the worst. Any secret injected into the environment of any tested codebase is vulnerable -- especially if your logs are public.

by cm3 10y ago

jacques_chester 10y ago

IBM sponsor a fleet of POWER-based systems at the OSU Open Source Lab[1]. Edit: You already said this ("Or, they could, like IBM provide SSH access to interested projects."), and if you'll excuse me, I'm going to go hide in shame. In my day job we've interacted with an IBM team who are porting our entire buildpacks pipeline[2][3] (which uses Concourse) to run on ppc64le. We fall under the Cloud Foundry heading the list of projects. The eventual goal is that we will be able to run x86 workers (on a regular commercial cloud) and some POWER workers at OSU-OSL or SoftLayer, and build both kinds of binaries from the same pipeline. I believe the eventual eventual goal is that all Cloud Foundry pipelines and products will be fully available across both x86 and ppc64le, including first-class integration with any pipeline producing binaries. Given that buildpacks represents the bulk of the binary volume, it makes sense to ensure our entire pipeline works on ppc64le. Disclosure: I work for Pivotal, not IBM, and I'm not able to commit either to anything. [1] http://osuosl.org/services/powerdev http://osuosl.org/services/powerdev [2] https://buildpacks.ci.cf-app.com/ https://buildpacks.ci.cf-app.com/ [3] https://github.com/cloudfoundry/buildpacks-ci https://github.com/cloudfoundry/buildpacks-ci

cm3 10y ago
What would be the course of action for an opensource project to set up a CI worker there (ideally per-commit on X branches, not periodic) such that it could be integrated in a pre-merge check? I'm not bound to Gitlab CI runners, but it's the first thing that came to mind given the popularity of github and gitlab.
- jacques_chester 10y ago
  I honestly have no idea. I imagine access is mediated by OSU, not IBM. The contact page (http://osuosl.org/contact http://osuosl.org/contact) seems like the place to start. One of the tricky parts about running PRs is that you're running arbitrary code, for which the main threat is the exfiltration of secrets. You need to lock down the workers fairly tightly to avoid unintended consequences. I'd be interested in reading more about how Travis, CircleCI, Gitlab et al do it -- some light googling didn't turn up any specifics. Edit: looks like CircleCI call this out explicitly and state their defences -- https://circleci.com/docs/fork-pr-builds/#security-implications-of-running-builds-for-pull-requests-from-forks https://circleci.com/docs/fork-pr-builds/#security-implicati...
  - cm3 10y ago
    That CircleCI post seems to talk about different issues than I see when I think safety of random CI jobs. It's a non-trivial problem to solve, especially with caching of artifacts involved. You'd probably want to run a sandbox inside a vm and secure the vm itself first, while having only ephemeral storage attached. Barring a container escape via just read/write/execve allowed inside the sandbox, which could probably also used to escape the surrounding vm, there isn't much you can do if you support running random stuff in a CI job. Actually, maybe CI needs to be limited to tools that can run on something like ZeroVM. Limiting persistent state and spinning up machines (vm or bare metal) for each job, while having no permanently active job runners, sounds like another defense to consider. That said, I very much doubt any of the CI services goes to such great lengths, given the limitations involved.
    - jacques_chester 10y ago
      > Limiting persistent state and spinning up machines (vm or bare metal) for each job, while having no permanently active job runners, sounds like another defense to consider. I can imagine how I'd do this with Concourse, but it'd be confusingly meta in approach -- a pipeline which builds a new pipeline with a new worker for each PR. I still think the exfiltration threat is the worst. Any secret injected into the environment of any tested codebase is vulnerable -- especially if your logs are public.