Hi, To be a little bit more precise and try to fit what you say, the thing i would like to see is the following:
1/ install prereqs (equivalent of your "third-party" software i guess); we already have a mechanism for that. 2/ repositories configuration: both local and online, it depends on the configuration. 3/ installation of core packages (and not before the configuration of the repos since needed packages may be provided via those repos). Optional: if using the current GUI, install GUI prereqs (typically perlQT), no need to install those if users only use the CLI. 4/ sanity check >From there, if everything is fine, just move on and "enable" cluster deployment/management. About your remark "OSCAR core software installation. Installation paths must be editable", I tend to agree with you but we are very far from being able to do so. I tried to initiate a discussion on the subject several times but only had few comments. I do not think this is a good idea to start to work on that if the whole group does not agree this is the way to go. So i think we need first to discuss about that and be sure everybody agree on a timetable for such modifications. Finally, few inline remarks about your comments: >Step 1 is only done once. It must be switched off when installing from > packages. Installation, FMHO, must not be done automatically, only a > summary of missing software given to the user. I have to admit that the current prereqs mechanism works just fine. I also understand your point and maybe we can write a tool that translates the list of prereqs into dependencies for "top-level OSCAR binary packages" but i think we can focus on that later. For a first step, if we can have an automatic management of the prereqs like it is currently done today, i will be pretty happy with that. :-) My first goal is to clarify the code path and be sure the CLI can be used out-of-the-box. > Step 2 may install OSCAR sofware in standard paths: /usr or /usr/local > and not /opt, or at least this must be setup by the user. This is > important for packaging. Again, the group has to decide what exactly we want to do, and how to do it. > Step 3 can be done once the UI is launched, because user can be asked > for which repositories he wants and where to install it. Definitively not because some prereqs are currently shipped via OSCAR and we do not have yet a "fully-binary-packages" solution. I guess you assume there that you use only online repositories. I do not think this is correct (at least not in a near future). We still need to support local repositories and allow a transparent configuration of those local repositories without facing the chicken/egg issue. In other term, at least with the current architecture, the repositories have to initialized early, at least for the installation of OSCAR components such as Packman and so on. > Step 4 is the only step run at every launch of OSCAR UI. I agree with that. > > IMO, use of autotools should ease a lot of things. Everybody knows > configure script with its numerous options for installation paths. > Then Makefile have standard targets: 'make install' to install and > 'make dist' to get tarball. Maybe it is not the best tool but its use > is well-known by everyone. I see that as a possible second step, not as a first step: autotools can be used to install OSCAR components in different locations (your remark about the installation of core stuff), but i only want as a first step to have a common code path for both the GUI and the CLI, without to have to touch all the different OSCAR components (let's stabilize trunk first). At the same time, long term, i tend to agree with you, i think this is the way to go. > > I'd like to help on this task but I'm already plenty of other work :-( > Does what i describe at the top of this email make sense for a first step? I think the points you make about autoconf/Makefile is more about the OSCAR integration into Linux distributions and not directly the bootstrap mechanism. Even if of course, they are related, i think they can be concidered as two different issues. BTW, i would like to speak about that tomorrow during the OSCAR call in order to start developments ASAP on that topic (this is slowing me down to stable trunk and also work on the new GUI). Thanks for your valuable remarks. On Mon, 2007-12-17 at 22:24 +0100, Jean Parpaillon wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, > > Geoffroy VALLEE a écrit : > > Hi all, > > > > Working on the new GUI, which is based on the CLI, i realized that > > the code for bootstrapping (i.e., OSCAR initialization) is not very > > clean and is actually pretty incomplete for the CLI. > > > > For instance, systemimager-client and systeminstaller-oscar are > > installed during wizard-prep execution which is called by > > oscar_wizard. It means that if you try to execute the CLI directly, > > you will most certainly face issues because of not-installed > > packages (there is also somehow kind of weird because we try to > > refer to systemimager-client in oscar_wizard before to actually > > install it). > > > > Therefore i would like to "clean up" the bootstrap and at the end > > have something that can be used with the current CLI, the current > > GUI and the new GUI. Note that if i can do that, i will also > > include the configuration tool i was working on. For that my idea > > is to do the following: install_cluster->bootstrap->system sanity > > check and then call oscar_wizard or main_cli. Of course i plan to > > reuse the prereq mechanism and as many stuff we already have. > > > > Any suggestions/remarks? I will start to work on that in few days > > so if you have any remarks, please speak-up ASAP. > > I don't know deeply the current bootstrap mechanism, so I may say > stupid things, but here is some remarks about what I imagine it should be. > > There might be a clear separation between the several parts of > bootstrapping: > 1 - third part software checking and, eventually, installation. > 2 - OSCAR core software installation. Installation paths must be > editable. > 3 - repositories configuration: > 3.1 - local repositories installation (optional) > 3.2 - yum/apt configuration > 4 - sanity check: ODA integrity, DHCP config checkup, etc. > > > Step 1 is only done once. It must be switched off when installing from > packages. Installation, FMHO, must not be done automatically, only a > summary of missing software given to the user. > Step 2 may install OSCAR sofware in standard paths: /usr or /usr/local > and not /opt, or at least this must be setup by the user. This is > important for packaging. > Step 3 can be done once the UI is launched, because user can be asked > for which repositories he wants and where to install it. > Step 4 is the only step run at every launch of OSCAR UI. > > IMO, use of autotools should ease a lot of things. Everybody knows > configure script with its numerous options for installation paths. > Then Makefile have standard targets: 'make install' to install and > 'make dist' to get tarball. Maybe it is not the best tool but its use > is well-known by everyone. > > I'd like to help on this task but I'm already plenty of other work :-( > > Regards, > Jean > > > > > Regards, > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.6 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iD8DBQFHZukJ8P+pSEjr0u4RAjgwAJ44cWR9A1T9m3K2b8mNSqKHxemioACfSwIG > maKnf7S9QOTNnlrHppFe30Q= > =IjUX > -----END PGP SIGNATURE----- > > > ------------------------------------------------------------------------- > SF.Net email is sponsored by: > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services > for just about anything Open Source. > http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace > _______________________________________________ > Oscar-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/oscar-devel ------------------------------------------------------------------------- SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace _______________________________________________ Oscar-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/oscar-devel
