(Click to open topic with navigation)
The first thing you need to do is install Moab Accounting Manager. You can do this through the Adaptive Computing website. After Moab Accounting Manager is installed you can look at the createExampleGoldState.pl script to see examples of how to define users, projects, accounts, and charge rates in Moab Accounting Manager. You can also run the script to set up a few test users, accounts, and charge rates in Moab Accounting Manager. If ever you want to clear the sqlite database in Moab Accounting Manager, run ./resetdb as root with the first parameter being the accounting admin user and it will restore the accounting state the same as a fresh install.
The out-of-the-box-solution doesn't use the create or modify NAMI URL. Moab uses the reserve URL to reserve funds and charge for setup costs, the charge URL to reserve funds and charge for reoccurring costs, and the delete URL to unreserve the funds. These three URLs must be defined in moab.cfg in order to charge a workflow. You should set a Reserve Failure Action in moab.cfg (the bottom line in the example) in case the customer doesn't have enough funds to proceed. Therefore a sample moab.cfg might look like this in the NAMI section:
AMCFG[nami] TYPE=NATIVE AMCFG[nami] StartURL=exec:///opt/moab/tools/mam/usage.start.mam.pl
AMCFG[nami] UpdateURL=exec:///opt/moab/tools/mam/usage.update.mam.pl
AMCFG[nami] PauseURL=exec:///opt/moab/tools/mam/usage.pause.mam.pl
AMCFG[nami] EndURL=exec:///opt/moab/tools/mam/usage.end.mam.pl AMCFG[nami] DeleteURL=exec:///opt/moab/tools/mam/usage.delete.mam.pl AMCFG[nami] FLUSHINTERVAL=hour AMCFG[nami] StartFailureAction=HOLD
The nami.cfg file was designed to be similar to the moab.cfg. Each line is parsed as either Predicate[constant] Attribute=value or key value. Each constant in the JobTemplate predicate identifies specific job templates in moab.cfg. In respect to the workflow, nami.cfg needs to know about:
(required) What job template in the workflow is the infinite job that you will charge based on a recurring bill cycle. In order to specify this you must set the Recurring attribute to True. For example:
JobTemplate[newvm] Recurring=True
(required) What job template starts off the workflow where you will reserve funds for the eventual infinite job's first recurring bill as well as any setup costs that might occur. For example:
JobTemplate[newvm] StartJob=newvmprovision
(required) What job templates follow the infinite job. This is important to register these template names with NAMI in case of a job failure; otherwise, NAMI will simply ignore them.
JobTemplate[newvm] TemplateDepend=newvmprovision JobTemplate[newvm] TemplateDepend=vmstoragehookup
(optional) Moab Accounting Manager VBF charge rate associated with provision jobs. These charge rates will be fixed setup costs per provision job that will be summed up and reserved with the first recurring bill at the run time of the start job. They will be charged at run time of the infinite job to ensure that all provision jobs ran successfully. It is important to note that the run time of the infinite job is also when the bill cycle starts. The first recurring bill is not charged with the setup costs at the beginning of the first bill cycle but rather at the end of each bill cycle after the resources are used. The following is an example of configuring multiple set up costs:
JobTemplate[newvmprovision] GoldChargeRateName=VmSetUpCost JobTemplate[vmstoragehookup] GoldChargeRateName=VmStorageHookUpCost
(optional) In case you want to toggle billing on and off for a workflow, you can use the TrackUsage attribute. The attribute only needs to be set on the recurring job for each workflow. Since having billing on is the default behavior, here is an example of turning billing off:
JobTemplate[newvm] TrackUsage=False
moab.cfg
JOBCFG[newvmprovision] GENERICSYSJOB=AType=exec,Action="$TOOLSDIR/newvmprovision.pl $*.SM",EType=start,Timeout=2:00,Flags=objectxmlstdin JOBCFG[newvmprovision] INHERITRES=TRUE JOBCFG[newvmprovision] FLAGS=NORMSTART
JOBCFG[vmstoragehookup] GENERICSYSJOB=AType=exec,Action="$TOOLSDIR/vmstoragehookup.pl $.SM $.SMMAP",EType=start,Timeout=2:00,Flags=objectxmlstdin JOBCFG[vmstoragehookup] INHERITRES=TRUE JOBCFG[vmstoragehookup] FLAGS=NORMSTART JOBCFG[vmstoragehookup] TEMPLATEDEPEND=AFTEROK:newvmprovision
JOBCFG[newvm] FLAGS=VMTRACKING SELECT=true JOBCFG[newvm] TEMPLATEDEPEND=AFTEROK:vmstoragehookup JOBCFG[newvm] FLAGS=NORMSTART JOBCFG[newvm] DESTROYTEMPLATE=destroyvm
JOBCFG[newvm] MIGRATETEMPLATE=migratevm
nami.cfg
JobTemplate[newvm] Recurring=True JobTemplate[newvm] StartJob=newvmprovision JobTemplate[newvm] TrackUsage=True JobTemplate[newvm] TemplateDepend=newvmprovision JobTemplate[newvm] TemplateDepend=vmstoragehookup JobTemplate[newvmprovision] GoldChargeRateName=VmSetUpCost JobTemplate[vmstoragehookup] GoldChargeRateName=VmStorageHookUpCost
Recurring jobs are represented in Moab Accounting Manager as usage records. A usage record helps constrain what account to charge, how much to charge, as well as keep record of additional information about the job. The nami.cfg file defines what the usage record will like for the recurring job. Each constant in the UsageAttribute can be an account constraint, charge rate name, usage record property name, or any combination of the three. Because the constant can be a usage record property (something that gets recorded and shown when you do a glsusage) and a charge rate name, most people make charge rate names match the usage record property. For example, Processors is something that you probably want to both record and charge for, so it is easier if the charge rate name and usage record attribute name are both called Processors and nami.cfg has the line:
UsageAttribute[Processors] MoabXMLAttribute=Processors
The nami.cfg file interprets this to mean that the value in the Processors tag sent from Moab should be the same value passed in the Processors tag in the usage record sent to Moab Accounting Manager. Moab Accounting Manager will then recognize that it is the usage record property name, so it will record it and show it when you do a glsusage command and will also recognize that it is a charge rate so it will charge it accordingly. Other attributes like user and project help constrain which account gets charged. However, there is nothing preventing you from making additional charge rates in Moab Accounting Manager for them as well.
Currently, the NAMI scripts allow anything in the Moab job XML to be sent to Moab Accounting Manager, including gres and user-defined variables. Gres and variables are expressed with either a gres: or var: prepended to the name of what it is representing. For example you might see the following in nami.cfg:
UsageAttribute[Disk] MoabXMLAttribute=GRes:Os UsageAttribute[StorageHost] MoabXMLAttribute=Var:SH
SetupTime - The amount of time (in seconds) beyond the bill cycle time that the reservation for the setup cost and first bill cycle should last before it destroys itself (defaults to 43200). Here is an example of how to define it in nami.cfg:
SetupTime 3213 (Defaults to 43200)
BillCycle - The amount of time of the bill cycle. It helps determine how much funds to reserve for each bill cycle. Possible values are hour, day, week, month (the default is day). If you want to over- or under-reserve funds for the bill cycle, you can also configure the default values for hour (60), day (86400), week (604800), and month (2630000). Be careful to understand that if you use this with RoundChargeDuration, the charge duration will be rounded to the modified bill cycle which is probably not what you wanted to do. Configuring the bill cycle time is intended to increase or decrease the barrier of entry for your job and assumes that the charge duration is not rounded. Here is an example of setting the bill cycle and changing the time duration of Month.
BILLCYCLE Month (Defaults to Day) BILLCYCLE[Month] 2640000 (Defaults to average seconds in a month)
RoundChargeDuration - If set to True, then the charge duration sent from Moab will be rounded up or down to match what was quoted within the default bounds of plus or minus 0 seconds. Otherwise, charge duration will not be rounded. The bound to round the charge duration is configurable with the Bound attribute. Here is an example of rounding the charge duration if it is within plus or minus a half a day:
RoundChargeDuration True (Defaults to False) RoundChargeDuration[config] Bound=43200 (Defaults to 0)
Log - If set to True, the nami.log will also include everything that is written to the gold.log in /opt/mam/log/. An example log configuration is:
LOG[config] path=../log/nami.log (Defaults to ../log/nami.log) LOG[config] loglevel=debug (Possible values are fatal, error, warn, info, debug and it defaults to info) LOG[config] includeGoldLog=false (Defaults to true) LOG[config] permissions=640 (Defaults to 666) LOG[config] maxSize=10000000 (Defaults to 10000000) LOG[config] rolloverLimit=7 (Defaults to 7)