Remote repository setting:
- Do we have the hardware?
-> We have two machines at IU
-> We need to buy new harddrives: currently it is a SCSI drive; at least
100GB and if possible multiple harddrives for the creation of a RAID FS.
It seems that a SATA port is also available, but can we put SATA
harddrives into the box?
Current hardware configuration:
-> machine1: harddrive: about 200GB; CPU: ??; Mem: ??
-> machine2: harddrive: 20GB (too small); CPU: Xeon 2.6; Mem: 8GB
-> configuration: machine1 -> repos (later we could migrate Drupal/Trac/SVN
on this machine)
machine2 -> automated testing (later work)
-> can ORNL guys have access to machine1 to setup the repositories?
- Two scripts are in SVN:
-> update-apt.sh
-> update-yum.sh
-> Q: do these scripts needs to be executed into a chroot environment?
No: - package upload to a directory incoming/dist/arch (opkg-upload)
- scripts picks the packages in that dir and create a repo based
on that
It only allows one to download binary packages
- What Linux distribution do we use on the repository server
-> if we use Debian, we can support both RPM and Deb
-> if we use RPM based system, we can support directly only RPM
-> Q: do we need to always chroot to a specific distro for the management of
binary packages (checking dependencies, packages validity and so on)?
Yes
If so, how do we manage the chroot environments?
Project organization
- Modular architecture
-> Merge of 5.1 into trunk: step-by-step approach; for each step, we do a
new release
* database
* be able to use the binary packages generated by OPKGC by trunk (some
specific efforts have been done for 5.1)
* we need to make an audit for the other points
-> the GUI should not be in core but an independent component. Separate the
GUI from the CLI (Ticket #416, #462)
-> needs repositories (do not put everything into SVN). The idea is to
remove binary packages from the SVN and only deal with spec files. Debian
watch file -> grab the tarball from the upstream project (Ticket #463). Other
question: do we keep all the OPKGs with the core? What is core?
-> place for a tool that abstracts details: open opportunities (non image
based deployment tools)
- Chairman: election (Thomas will deal with that)
- Project rules: we should modify the rules to ease the integration of new
independent developers
PackageUnIn
- Design is there
- Implementation is too depend to underlying mechanisms (for instance the
database schema). We need a simple API for the ODA side.
- Discussion after OSCAR 5.2
OPKGC
- If the "-dist" option is not specified, we should detect the local distro id
and use that (Ticket #464)
- Post-install issue: some scripts break the installation
Do we have an example?
Trac
- Blog: HowTo create a new blog page and put it on the main page
- Missing features: cluster registration -> it is PHP/Drupal only code, it does
not work on Trac (which is Python based)
- PDF generation w/ Trac: unicode support is broken and images are not included
- File/directory browsing (not in SVN but on the server -- accessible by apache)
Is there a module for that? We are looking for a result similar to SourceForge
- Can we now delete an attached file with Trac?
Discussions
- Management: binary package update w/ a tracking mechanism
-> We delay the implementation of such a solution because we do not even
know what are the users needs
-> Some basic needed mechanisms are already identified
o Packman needs to have a notion of binary package versioning
o Need to implement a tracking system
o Need a way to do kernel updates, dealing with the reboot issue
-> First step: status management
o What is the current state of the compute nodes (software/hardware)?
o What is the current state of the image (software) if you do image
based management?
o Node status -- hardware: node up/down; offline/online
-- software: managemnt action -> success/fail
Idea: implement a basic mechanism that can tell if a command fails:
Ex: node1 success node_is_online.sh Tells the node is alive
node1 fail install_opkgs (bla, v2) Tells that the install
of the opkg bla v2
failed
At the end, such a tool is just a wrapper around standard OSCAR
scripts that just deal with the result (logging/report).
- NFS: make NFS configurable; be able to plug OSCAR cluster to NFS servers that
are outside. Should be ease to implement with a configuration file:
- if the configuration file exists: plug to an existing NFS server
- if the configuration file does not exist, "normal" behavior
Ticket #465
- LDAP: use the headnode as proxy
- OPKGs classification
-> (prereqs: needed components to bootstrap OSCAR)
-> core: a small number of packages that provide the core functionality of
OSCAR
-> included: optional maintained OPKGs shipped with OSCAR
Prereqs: packman, AppConfig, Perl-db, Perl-xmlsimple, mysql/postgresql
Note: the choice between mysql/prosgresql should be done in the
OSCAR configuration file (/etc/oscar/oscar.conf)
Prereqs-GUI: perl-Qt, perl-Tk
Note: How can we make OSCAR smart enough to not bootstrap GUI
specific prereqs when not necessary?
GUI Prereqs: perl-Qt, perl-Tk
Core: c3, sc3, sis, switcher/modules, base, apitest, oda, rapt, selinux,
sync-files, yume
Note: - apitest should be moved to included if not used by the core
libraries
- Why base is a core package? This is actually a prereqs!
Base: netbootmgr
Note: - netbootmgr should be moved in core: the GUI provides a button to
activate netbootmgr so netbootmgr is mandatory. Solution: use the
the config file to activate/deactivate netbootmgr and make the GUI
smart (if netbootmgr disabled, freeze the GUI button)
- the base class should _not_ exist
Included: jobmonarch, disable-services, lam, loghost, maui, mpich, mtaconfig,
networking, ntpconfig, openmpi, opium, pfilter, pvm, sge, torque
Note: - Do we need a specific class for config only OPKG?
- Can pfilter be removed?
Third-party: linux-ha, documentation
Note: - This class should _not_ exist
- Linux-ha should be moved into included
- documentation should be removed
- Naming policy issue? Ex: pvm from FC8 versus pvm from OSCAR
=> pvm-oscar
- Collaboration
-> an effort has been initiated at IU for the integration of OSCAR and Perceus
o wait for the creation of a page under openclustergroup.org that describe
the project
o should be able to have a clean API to abstract the underlying imaging
mechanism
Roadmap
* 5.2 -> database backport from the 5.1 branch
* 5.3 -> fix error handling in packman/rapt/yume (write unit tests for
validation) - Ticket #460
Note: bug #460 was only about a mechanism for Packman in order to catch errors,
this was been fixed for 5.2. RAPT and Yume just need to display error messages,
PackMan will detect them.
-> man pages for all the OSCAR scripts
-> SLURM OPKG
-> separation GUI/CLI: fix Configurator in CLI mode (Ticket #459); separation of
the Perl modules for the CLI and the GUI (Ticket #416, #462); GUI should
not be shipped by default with the CLI; definition of what is the OSCAR core
-> NFS configuration (see details in the discussion section) - Ticket #465
* 5.4 -> Small Management Tool (SMT) implementation (see details in the
discussion section)
-> official support of oscar-config/oscar scripts (include oscar-config
--bootstrap into install_cluster)
-> include V2M/Xen (experimental)
-> (implementation of scripts for automated testing -- unit tests)
Note: release "validation" w/ a fully workable GUI on rhel/centos 5 x86/x86_64
and debian 4 x86/x86_64
A TODO list for OSCAR 5.2 is available here.
Powered by Trac 0.11
By Edgewall Software.
© Copyright 2000-2008 http://openclustergroup.org/
All rights reserved.