-
Notifications
You must be signed in to change notification settings - Fork 70
Nimbus 2.5 notes
Information about CUMULUS.
One of the focuses of Nimbus 2.5 is the introduction of an end to end installation path that allows an administrator to quickly and repeatably bring up a working “cloud configuration” of Nimbus. Starting with nothing but some Xen or KVM installations, this “zero to cloud” guide will result in a working cloud client.
The admin guide will need to be redone and tested, this will take days
A standalone script that replaces “cloud-admin.sh —add-dn”
- a. create cert
- b. add to gridmap
- c. add to groupauthz
- d. set up w/ cumulus
- e. set up query API mappings?
Python, adjusts files locally. The idea of remote admin API for this commandline (and any other admin utility) is on hold. The webapp of the future will probably be limited to running localhost to the Nimbus service.
- installer should —enable-groupauthz
- cumulus object dereference (object —> propagation coordinates) inside service should turn into this mapping but also chain in a groupauthz call to do the time-based authorization logic
- disable respecting of these things in groupauthz: imageNodeHostname, imageBaseDirectory, dirHashMode
- seems installer could generate sane cloud.properties ready to use…
Bugs and Enhancements in Bugzilla: http://bugzilla.mcs.anl.gov/globus/showdependencytree.cgi?id=7013&hide_resolved=0
Enhancements not in Bugzilla yet…
How costly will it be to move all configs into a nimbus etc directory. Something like etc/services, etc/cumulus, etc/web ? Could GL symlink into this? Could it eventually be an /etc/nimbus directory? Could it work in such a way that someone could save “etc”, run the installer anew, replace “etc” and be done, back where they were but with new code etc.?
This should solve the absolute path issues, how costly will it be to finish and integrate?
Possibly the query authz could hook into pynimbusauthz, thus eliminating tedious maintenance of separate mappings for query tokens