The idea is simple. Dice is a light weight build service for KIWI images with full control over the build power by the user.

At SUSE we have the buildservice which is the full professional version of a build service for packages, images and also products. As a normal user I can provide input and I get some output but I have no control what happens with my data, when it's being processed and where it's being processed. That's by design and works great, thus not meant negatively. I'm a 100% fan of the buildservice

If people have the need for build power on demand or they need a trust model which does not allow to hand over information to other people they are mostly down at the ground level of the basic tools we provide to them. At that level a customer has to deal with several hurdles and I'd like to close this gap a little bit with this project

From a technical perspective my idea includes to provide a public worker machine as an image in one ore more public clouds. I think I will use Amazon EC2 as a start because that's also the biggest player in the field. Users can then run as many instances as they need and can control how much and when they need build power. For those who need privacy the worker machine will also be build as a vagrant box and is offered for download.

A nice little tool called dice makes use of this workers and can control and fire up the jobs whenever it is needed. The project is live on github for further details.

Looking for hackers with the skills:

ruby rspec ec2 gce kiwi vagrant

This project is part of:

Hack Week 11

Activity

  • about 10 years ago: sax2 liked this project.
  • about 10 years ago: jordimassaguerpla joined this project.
  • about 10 years ago: jordimassaguerpla liked this project.
  • about 10 years ago: sax2 added keyword "kiwi" to this project.
  • about 10 years ago: sax2 added keyword "vagrant" to this project.
  • about 10 years ago: sax2 added keyword "ruby" to this project.
  • about 10 years ago: sax2 added keyword "rspec" to this project.
  • about 10 years ago: sax2 added keyword "ec2" to this project.
  • about 10 years ago: sax2 added keyword "gce" to this project.
  • about 10 years ago: sax2 started this project.
  • about 10 years ago: sax2 originated this project.

  • Comments

    • jordimassaguerpla
      about 10 years ago by jordimassaguerpla | Reply

      I had implemented the "dice ssh" command and reviewed the setup instructions which turned out to be mostly ok and I just added a minor thing.

      https://github.com/schaefi/dice/pull/4 https://github.com/schaefi/dice/pull/5

    • sax2
      about 10 years ago by sax2 | Reply

      I'll continue working on this project since I can make use of it for setting up a test build matrix as well as I plan to offer it as part of the SUSE public cloud offering for those customers who want to quick establish a simple private build service

    • sax2
      about 10 years ago by sax2 | Reply

      we reached a state which would allow to provide the tool for testing to customers and thus also built the dice package here: http://download.opensuse.org/repositories/Virtualization:/Appliances/openSUSE13.1/x8664/dice-0.4.0-23.1.x86_64.rpm

    • sax2
      about 10 years ago by sax2 | Reply

      we also created a quick startup guide here: https://github.com/schaefi/dice#dice

    • sax2
      about 10 years ago by sax2 | Reply

      Thanks to Jordi who really showed some passion in this project and already contributed the dice ssh command :-)

    • sax2
      about 10 years ago by sax2 | Reply

      next steps are tracked on the project issue page in github. The most important issue is to get rid of the kiwi requirement in dice, so that the kiwi builder is only needed on the worker and nowhere else. I'm currently working on this when the time allows it

    • sax2
      almost 10 years ago by sax2 | Reply

      dice made it into Factory :)

    • sax2
      almost 10 years ago by sax2 | Reply

      The latest version can always be found here: http://download.opensuse.org/repositories/Virtualization:/Appliances/

    • sax2
      almost 10 years ago by sax2 | Reply

      For Hackweek 12 I had planned to continue working on docker build boxes to be used with dice

    Similar Projects

    Recipes catalog and calculator in Rails 8 by gfilippetti

    My wife needs a website to catalog and sell the products of her upcoming bakery, and I need to learn and practice modern Rails. So I'm using this Hack Week to build a modern store using the latest Ruby on Rails best practices, ideally up to the deployment.

    TO DO

    • Index page
    • Product page
    • Admin area -- Supplies calculator based on orders -- Orders notification
    • Authentication
    • Payment
    • Deployment

    Day 1

    As my Rails knowledge was pretty outdated and I had 0 experience with Turbo (wich I want to use in the app), I started following a turbo-rails course. I completed 5 of 11 chapters.

    Day 2

    Continued the course until chapter 8 and added live updates & an empty state to the app. I should finish the course on day 3 and start my own project with the knowledge from it.

    Hackweek 24

    For this Hackweek I'll continue this project, focusing on a Catalog/Calculator for my wife's recipes so she can use for her Café.

    Day 1


    Fix RSpec tests in order to replace the ruby-ldap rubygem in OBS by enavarro_suse

    Description

    "LDAP mode is not official supported by OBS!". See: config/options.yml.example#L100-L102

    However, there is an RSpec file which tests LDAP mode in OBS. These tests use the ruby-ldap rubygem, mocking the results returned by a LDAP server.

    The ruby-ldap rubygem seems no longer maintaned, and also prevents from updating to a more recent Ruby version. A good alternative is to replace it with the net-ldap rubygem.

    Before replacing the ruby-ldap rubygem, we should modify the tests so the don't mock the responses of a LDAP server. Instead, we should modify the tests and run them against a real LDAP server.

    Goals

    Goals of this project:

    • Modify the RSpec tests and run them against a real LDAP server
    • Replace the net-ldap rubygem with the ruby-ldap rubygem

    Achieving the above mentioned goals will:

    • Permit upgrading OBS from Ruby 3.1 to Ruby 3.2
    • Make a step towards officially supporting LDAP in OBS.

    Resources


    Fix RSpec tests in order to replace the ruby-ldap rubygem in OBS by enavarro_suse

    Description

    "LDAP mode is not official supported by OBS!". See: config/options.yml.example#L100-L102

    However, there is an RSpec file which tests LDAP mode in OBS. These tests use the ruby-ldap rubygem, mocking the results returned by a LDAP server.

    The ruby-ldap rubygem seems no longer maintaned, and also prevents from updating to a more recent Ruby version. A good alternative is to replace it with the net-ldap rubygem.

    Before replacing the ruby-ldap rubygem, we should modify the tests so the don't mock the responses of a LDAP server. Instead, we should modify the tests and run them against a real LDAP server.

    Goals

    Goals of this project:

    • Modify the RSpec tests and run them against a real LDAP server
    • Replace the net-ldap rubygem with the ruby-ldap rubygem

    Achieving the above mentioned goals will:

    • Permit upgrading OBS from Ruby 3.1 to Ruby 3.2
    • Make a step towards officially supporting LDAP in OBS.

    Resources