On Tuesday 30 October 2007, Erich Focht wrote: > On Tuesday 30 October 2007 19:39, Geoffroy Vallee wrote: > > I am currently working on a cluster partitioning mechanism which relies > > on the database, please do not erase tables without consulting me first > > or i will be in big troubles! > > > > You are currently breaking all the stuff we did this year! > > If you relied on the deleted tables, it was wrongly done and not along > the idea of opkgc. > If you need to keep a copy of the information in the per > image RPM database in a central database, and need to keep that in sync, > this is a flawed concept. If you need to track package state on nodes, you > will still be able to do it without any change, almost.
And what is the problem with having an asynchronous central database which gives you a global view a system when yum and apt are designed to give you local information only. I agree that you cannot have a synchronous view in large systems but you cannot rely only on yum/apt neither. So i may give up the idea of using ODA as a central database but you will have to find real arguments. Right now you are the only one that really want to remove critical tables from ODA; at least Thomas, DongInn and I do not really agree with your latest modifications. > > I'm wondering how you say I break things. Things are broken since over four > months. I can revert my changes in one step and make a branch in which I > clean up the dirt. It won't help the trunk, as that is and remains broken. Wrong again, on Debian it was far from being so bad. Did you actually give it a try? And my major problem is that you completely modify the OSCAR architecture without even discussing with us (about what we did, what we are doing and what we plan to do)? Why? Your last modifications really bother us (e.g. DongInn's email which says that according to him we should NOT remove central tables such as the package table). > > Regards, > Erich > > > On Tue, 2007-10-30 at 19:35 +0100, Erich Focht wrote: > > > Hi DongInn, > > > > > > please don't fix ODA to some sort of fake compatibility mode. The whole > > > point of doing this exercise was to get rid of a re-invented package > > > management system for opkgs and use the native pkg management. > > > > > > It's now or never! Rather delete code and tables than build > > > compatibility layers which allow code to behave as before. This will > > > show you what is needed and what not. And the bugs/failures will point > > > you exactly to the place where you need to fix things. > > > > > > I edited the schema and am about to check it in. > > > > > > I don't like that we need something called package_id. I think we can > > > get rid of the entire Packages table and use opkg names instead in > > > Node_Packages_Status as well as in the other remaining packages related > > > tables. > > > > > > We could instead populate the Packages table, but that leads into the > > > dead end with multi-arch/distro setups. > > > > > > It's a great chance to clean up, let's do it! > > > > > > Regards, > > > Erich > > > > > > On Tuesday 30 October 2007 18:45, DongInn Kim wrote: > > > > Hi Erich, > > > > > > > > Taking out the Package information from ODA is not trivial and it > > > > will break a lot of database functionalities in OSCAR because many > > > > ODA subroutines use the Packages table and its primary key, > > > > package_id. Eventually in order to take out the Packages information > > > > from ODA, we need to change many parts of the ODA schema. I don't > > > > think it can be done in a very short time period. > > > > > > > > Instead, I would like to keep the ODA stuff as it is for now. Having > > > > the package information in ODA does not hurt OSCAR at all and it > > > > won't affect what we want to implement on Select as long as we do not > > > > forget to use the opkg meta data on Selector. Basically this is what > > > > I am doing and will. > > > > > > > > More importantly, Selector is heavily using the "Node_Package_Status" > > > > table containing the primary key (package_id) of the "Packages" > > > > table. We can not simply make another stuff to replace what the > > > > Node_Package_Status table does now. I still have a strong feeling > > > > that we need to use the "Node_Package_Status" whether we keep the > > > > Package information (which comes from config.xml of all the OSCAR > > > > packages) in ODA or not. > > > > > > > > So for the short time period, I would like to make ODA work as it > > > > does and just we use it for "Node_Package_Status" on Selector. For > > > > the long term, I may want to change the ODA schema to reduce the > > > > fields of the "Packages" table and remove its weak entity group > > > > (Packages_requires, Packages_provides, Packages_conflicts, and so on) > > > > but I still need to keep its strong relation tables (Group_Packages, > > > > Node_Package_Status, Image_Package_Status) as it is. But I still > > > > believe that having the full package information in the "Packages" > > > > table does not hurt OSCAR and it will be just redundant to the opkg > > > > meta data. > > > > > > > > Why don't we just make ODA run as it is and not use it for the > > > > "Packages" table related queries as much as possible? This way, we > > > > will not break the OSCAR source codes terribly. Once we are not using > > > > the ODA "Packages" table any more and we feel that everything is > > > > ready for using only opkg meta data for the package information > > > > instead of oda, then let's decide what we want to do with the > > > > "Packages" table and more stuffs in ODA. > > > > > > > > Regards, > > > > > > > > - DongInn > > > > > > > > Erich Focht wrote: > > > > > Hi, > > > > > > > > > > since the oscar call was interrupted, we should continue on the > > > > > mailing list. > > > > > > > > > > DongInn described in the call how the installation steps go in the > > > > > old OSCAR: 1. prereqs get installed (these are not opkgs, normally) > > > > > 2. ODA is fed with config.xml data > > > > > 3. core opkgs installed > > > > > 4. selector is used to edit the default package set > > > > > 5. ... selected opkgs are configured > > > > > 6. server opkgs are installed on the master > > > > > > > > > > In the new setup we don't have the information from config.xml > > > > > available and the ODA packages info is empty. We are directly > > > > > querying the repositories so we can use selector without ODA, more > > > > > or less. But it is unclear what is the best way to initiate and > > > > > describe steps 1. and 3. in the new setup. > > > > > > > > > > For the start I would propose to leave the prereqs installation as > > > > > it is and expect the prereq packages to be in the repositories. > > > > > > > > > > Step 2 is skipped. > > > > > > > > > > The step 3 can actually be done using the same querying functions > > > > > we use in the selector, i.e. the functions from OpkgDB.pm: build a > > > > > hash with all packages, find out which packages are "core" > > > > > (multiplexed into the group information) and install their > > > > > opkg-*-server rpms. > > > > > > > > > > When we're done with the selector it should create the default > > > > > package set records. > > > > > > > > > > I think this is easilly doable and follows the philosphy of > > > > > removing packaging info from the database. All we need in the > > > > > database is the default package set and the package status. Other > > > > > things can be read on the fly. > > > > > > > > > > Regards, > > > > > Erich > > > > > > ----------------------------------------------------------------------- > > >-- This SF.net email is sponsored by: Splunk Inc. > > > Still grepping through log files to find problems? Stop. > > > Now Search log events and configuration files using AJAX and a browser. > > > Download your FREE copy of Splunk now >> http://get.splunk.com/ > > > _______________________________________________ > > > Oscar-devel mailing list > > > [email protected] > > > https://lists.sourceforge.net/lists/listinfo/oscar-devel -- Geoff ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Oscar-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/oscar-devel
