I honestly don't get it. Why is casulana so necessary for building these images going forward. What kicked off this thread was me demonstrating that machine images could be built in gitlab on google cloud runners that have nested virt support.
On Wed, Aug 29, 2018, 10:25 AM Luca Filipozzi <[email protected]> wrote: > On Wed, Aug 29, 2018 at 05:07:55PM +0200, Thomas Goirand wrote: > > On 08/12/2018 02:51 AM, Luca Filipozzi wrote: > > > On Sat, Aug 11, 2018 at 03:06:53PM +0200, Bastian Blank wrote: > > >> Right now this layers are: > > >> - gitlab: repository store, job scheduler > > >> - gitlab-runner: job executor > > >> - docker-machine: VM handling with docker and directly supported by > > >> gitlab-runner > > >> - docker: runtime environment within transient VM > > >> - gitlab ci script: just a script > > >> - fai class wrapper > > >> - fai > > > > > > casulana is also used to build the CD images. Currently, the scripts > > > that build the CD images execute a number of 'build jobs' in parallel, > > > effectively monopoloizing the machine. One of the things we > could/should > > > do is turn those 'build jobs' things that can be executed by a > scheduler > > > such as sge or gitlab-runner. Can we inject non-gitlab-originating jobs > > > into gitlab's scheduler? > > > > > > The other thing we could do is set up system-wide semaphor that both > > > cd-build and gitlab-runner use, but i prefer the idea of enqueuing jobs > > > into SGE (or equivalent) > > > > What is SGE? A google non-free version of beanstalk? > > Son of Grid Engine, the open-source fork? of Sun Grid Engine. > > Packaged in Debian as 'gridengine-*' > > A job scheduler / resource manager. More suited for cluster but still > useful for a large machine like casulana. > > -- > Luca Filipozzi > >
