search

oar-team / kameleon-recipes

The default kameleon recipes
http://kameleon.imag.fr
Other
5 stars 11 forks source link

Merge kameleon-bootstrap-recipes ? #13

Closed npf closed 7 years ago

npf commented 8 years ago

@SalemHarrache : we are trying to build a debian9, but no bootstrap exists yet of that version.

We could build and host one, but yet we do not understand why we have to rely on such a bootstrap.. Is it a part of what is actually shipped in the builded env ? If yes, that would mean we do not control every steps of the build in our recipes ? We would prefere having a raw debootstrap here..

Could you explain ?

SalemHarrache commented 8 years ago

The short answer is : stability.

We encountered some issues to have recipes stable both in time and in the various environments (virtual machine, user OS, tools version).They were mainly due to the bootstrap step. It is the most instable step because, except Debian and possibly archlinux, no distribution can bootstrap appropriately in a trivial way.

So I switch between installing debootstrap, kickstart, pressed.cfg, iso, netinstall...

For all these reasons, we decided to split the initial repository into two different repots:

That's the best solution I've found to have some stability in Kameleon recipes, since maintenance was demanding and I didn't have a lot of time to devote to it.

npf commented 8 years ago

So I do you see it from a user's perspective ?

One would like to control every steps from the beginning. -> should the user clone the kameleon-bootstrap-recipes, and do some changes here eventually ? How could it benefit from change here in its recipes ? (it kameleon-bootstrap-recipes thought to be placed in the hands of the end users ?) -> would it be possible to let the use choose whether he wants to use debootstrap or a rootfs generated from kameleon-bootstrap-recipes ?

npf commented 8 years ago

Please note that the actual/current use case is a user that wants Debian testing (Debian 9, stretch). No rootfs is provided for now. What would you propose for him ?

mickours commented 8 years ago

The user is @Shurakai by the way :)

SalemHarrache commented 8 years ago

Hi,

I think we can merge both repositories so that the task is both accessible to beginners and advanced users.

However, bootstrap recipes will only be supported by qemu, as it is the only one which covers all bootstrap methods that we developped (kickstart, debootstrap, iso, etc.)

For now, the kameleon-recipes repository looks like this:

.
├── chroot/
├── docker/
├── grid5000/
├── qemu/
├── vagrant/
└── virtualbox/

If I merge both repositories, we will have something like that:

.
├── qemu-bootstrap/
├── chroot/
├── docker/
├── grid5000/
├── qemu/
├── vagrant/
└── virtualbox/

For example, if I want to add a new recipe debian9, I will first add the bootstrap recipe in the qemu-bootstrap directory, then a standard recipe in the chroot|docker|virtualbox|qemu|xxx directories.

Thanks to the inheritance, this task is relatively trivial.

What do you guys think about it?

npf commented 8 years ago

What about having (qemu only) bootstraps in the qemu directory ? Could bootstrap recipes be prefixed bootstrap-* for instance, ditto for steps ?

SalemHarrache commented 8 years ago

why not, It sounds good :)

npf commented 8 years ago

:+1:

mickours commented 8 years ago

Ok for me :)

npf commented 8 years ago

Then, I propose:

I'll give a try to that soon unless anyone is quicker.

mickours commented 8 years ago

Done in the refactor branch (to test)

mickours commented 7 years ago

From scratch recipes tested for build (only the build process is tested not if the exported OS are working)

Working:

Not working (grouped by error type):

npf commented 7 years ago

Merge of the 2 repositories and refactoring is now pushed in the master branch.