Hi, So thinking about your comments, i updated the bootstrap description:
Stage 1 of the bootstrap: able the installation of packages via OSCAR mechanisms. 1/ low-level configuration (e.g., setup OSCAR_HOME, installation of Packman, RAPT and YUME in dumb mode) and repositories configuration (both local and online, it depends on the configuration). Stage 2: installation of OSCAR components/packages to enable cluster installation/management: 2/ install prereqs. 3/ installation of core packages, server side (and not before the configuration of the repos since needed packages may be provided via those repos). 3.1 (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. Thinking about that, maybe we will have to perform the sanity check before to install OSCAR core packages on the server side. We will have to double check that point. I also think the issue of the integration in the distros (remarks on the usage of autotools and so on) may be a good discussion subject for the January meeting (which will happen in February). BTW, do you think you will be able to attend the meeting? Regards, On Tue, 2007-12-18 at 16:48 +0100, Jean Parpaillon wrote: > Hi, > > Le 17.12.2007 23:11, Geoffroy Vallee a écrit : > > 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. > > > > Sure, we are not ready for that, AFAIK. Just let's think about it > everytime we're rewritting/modifying a piece of installation code. > > > > 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. > > Current way is not far from what I think. It is just that it must easy > to switch it off, for packagers. > > > > >> 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. > > > > Again, this can be done smoothly, if everyone is aware of this issue > when coding. Here are little simple "tips" to do it: > 1 - forbid path hard-coding in code > 2 - forbid path hard-coding in Makefiles > > >> 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. > > > > I understand. But whatever it is step 2 or 3, it must be a separate step . > > >> 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. > > > > As I said autotools is not the best software ever. But it is well-known. > And this is an important thing for users ;-) > But it's sure also that it is a long term solution because it requires a > lot of changes. If we already have clear and separate steps for the > bootstrap process, I think it will be far easier to incorporate > autotools in the future. > > > >> 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. > > > > > > Sure, it make sense. We have to find a solution to this bootstrapping issue. > > > > > > > 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. > > > > > > > Regards, > Jean > > > > > On Mon, 2007-12-17 at 22:24 +0100, Jean Parpaillon wrote: > > 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, > >> > >> > ------------------------------------------------------------------------- > 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 > > ------------------------------------------------------------------------- > 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
