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
begin:vcard fn:Jean Parpaillon n:Parpaillon;Jean org:Kerlabs;Support - Development adr:;;Campus Universitaire de Beaulieu;Rennes Cedex;;35042;France email;internet:[EMAIL PROTECTED] title:Engineer tel;work:+33 2 99 84 25 99 url:http://kerlabs.com/ version:2.1 end:vcard
signature.asc
Description: OpenPGP digital 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
