On 11/16/2016 02:35 PM, Nicolas Hicher wrote: > Hello, > > > On 11/16/2016 07:52 AM, Tristan Cacqueray wrote: >> Hello folks, >> >> here is a break down of the shell scripts in SF code base: >> >> A) Image building >> * Build cache >> * Build image >> * Logic to know when to build cache or image >> >> B) Functional test runner >> * Call image building >> * Deploy image >> * Do action such as turn off/turn on, run backup, ... >> >> C) Configuration script (sfconfig.sh) >> * Generate secrets >> * Generate playbook/inventory >> * Call configuration playbook >> >> D) Generated script by sfconfig (/root/*.sh) >> * Create user >> * Set acls >> >> E) Random scripts such as build doc, publish and fetch image >> >> >> It seems like each of above point could be replaced by a better tool: >> >> A) Use DIB > > I agree with that point, but what about the upgrade process with only an > image build with DIB instead edeploy ? Not sure will be able to use the > same upgrade path.
Well edeploy is very similar to DIB as it builds a system disk image. Then it is also a shell script that takes care of copying a new image in place on a running system. Thus the upgrade process will be the same if we install the rsync server and the edeploy script on the resulting DIB image. The only bits that needs to be improved is that we are currently building a .qcow image (for boot) as well as a .tar.gz image (for upgrade). We could either: * build both using DIB * make the upgrade be able to work with .qcow image, see that proposal for a draft POC: https://softwarefactory-project.io/r/#/c/3795/1/upgrade/upgrade_2x/tasks/fetchupstream.yml If we choose the later, then it may be easier to work with .raw image format all the way too. >> B and E) Rewrite in Ansible playbooks (which is more zuulV3 friendly) > > +1 >> C) A python based script that would subprocess ansible commands > > Why do not use only ansible ? What is the benefit to use a python script ? > That's something to consider too, but that process is mostly a setup for ansible usage. It seems more trivial to do the following steps in python: * Generate secrets and write them in sfcreds.yaml * Generate and execute playbooks based on arch content Though sfconfig.sh task such as root user git config could be done in the sf-install-server role. > Nico >> D) Those are remaining legacy stuff from the puppet era that could >> easily be integrated into SF roles. >> >> Well if you thing that's worthy, then let's create stories and address >> above point! >> >> Yours, >> -Tristan >> >> >> >> _______________________________________________ >> Softwarefactory-dev mailing list >> [email protected] >> https://www.redhat.com/mailman/listinfo/softwarefactory-dev > >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Softwarefactory-dev mailing list [email protected] https://www.redhat.com/mailman/listinfo/softwarefactory-dev
