Mailing List ArchivesAuthenticated access |
![[Computer Systems Lab]](http://www.cs.wisc.edu/pics/csl_logo.gif){kind=logo}
|
Mailing List ArchivesAuthenticated access |
|
| Hi, I had a real time of it trying to get groups to work like I think they should. One clarifying question: there is this sentence in the documentation: In all these examples so far, the hierarchy is merely a notational convenience. Each of the examples could be implemented with a flat structure, although it might be more confusing for the administrator. Surplus is the concept that creates a true hierarchy. This sort of matches the behavior I saw, as the group.subgroup.user seemed to have nothing to do with âgroupâ in the condor_userprio output, group.subgroup seemed to be its own group. Iâd say itâs the other way around, the flat hierarchy is less confusing to the admin when the groups are defined as if they are hierarchical, but theyâre not really. At least for this particular admin. After turning on surplus, it got better, but it was still not how Iâd expect. With this config: GROUP_NAMES = group_atlas, group_atlas.anal, group_atlas.prod, \ group_alice, \ group_dune, \ group_enmr, \ group_lhcb, \ group_gw, \ group_ops GROUP_QUOTA_DYNAMIC_group_alice = 0.08 GROUP_QUOTA_DYNAMIC_group_atlas = 0.41 GROUP_QUOTA_DYNAMIC_group_atlas.prod = 0.79 GROUP_QUOTA_DYNAMIC_group_atlas.anal = 0.20 GROUP_QUOTA_DYNAMIC_group_dune = 0.09 GROUP_QUOTA_DYNAMIC_group_enmr = 0.09 GROUP_QUOTA_DYNAMIC_group_lhcb = 0.20 GROUP_QUOTA_DYNAMIC_group_gw = 0.09 GROUP_QUOTA_DYNAMIC_group_ops = 0.01 GROUP_ACCEPT_SURPLUS = true I get this condor_userprio output: $ condor_userprio -hierarchical -quotas -most Last Priority Update: 11/19 09:29 Group Effective Config Use Subtree Effective Priority Wghted Total Usage Time Since Weighted Submitter Submitter User Name Quota Quota Surplus Quota Priority Factor In Use (wghted-hrs) Last Usage Requested Floor Ceiling ----------------------- --------- --------- ------- --------- ------------ --------- ------ ------------ ---------- ---------- --------- --------- group_lhcb 2958.40 0.20 ByQuota 2958.40 1000.00 0 3.51 0+00:11 0 lhcbpr11@xxxxxxxxx 500.08 1000.00 0 3.51 0+00:11 group_ops 147.92 0.01 ByQuota 147.92 1000.00 0 7.74 0+00:13 0 ops013@xxxxxxxxx 500.00 1000.00 0 5.17 0+00:13 ops007@xxxxxxxxx 501.35 1000.00 1 2.56 0+00:21 group_dune 1331.28 0.09 ByQuota 1331.28 1000.00 11 7498.06 <now> 14 dune090@xxxxxxxxx 180824.04 1000.00 6 7396.01 <now> group_atlas 6064.72 0.41 ByQuota 6064.72 1000.00 218 59.77 <now> 0 atlsm022@xxxxxxxxx 501.80 1000.00 0 3.56 0+00:07 group_gw 1331.28 0.09 ByQuota 1331.28 1000.00 59 2058.82 <now> 59 ligo098@xxxxxxxxx 42919.39 1000.00 59 2040.47 <now> group_enmr 1331.28 0.09 ByQuota 1331.28 1000.00 573 12527.70 <now> 962 enmr043@xxxxxxxxx 270090.67 1000.00 580 12660.26 <now> group_atlas.anal 1212.94 0.20 ByQuota 1212.94 1000.00 683 17552.03 <now> 779 atlpi04@xxxxxxxxx 361534.64 1000.00 767 17555.85 <now> group_alice 1183.36 0.08 ByQuota 1183.36 1000.00 2440 33593.54 <now> 2820 alice039@xxxxxxxxx 500.00 1000.00 0 1.38 0+00:35 alisgm02@xxxxxxxxx 874607.24 1000.00 2744 36861.56 <now> group_atlas.prod 4791.13 0.79 ByQuota 4791.13 1000.00 10266 144213.64 <now> 13610 atlb009@xxxxxxxxx 3368447.15 1000.00 10305 144570.44 <now> <none> 443.76 0.00 yes 14792.00 1000.00 573 78075.87 <now> 4595 atlpi04@xxxxxxxxx 213014.56 1000.00 1 4057.12 <now> enmr043@xxxxxxxxx 245539.72 1000.00 3 945.46 <now> alisgm02@xxxxxxxxx 1570911.20 1000.00 0 30761.14 0+03:21 lhcbpi05@xxxxxxxxx 1769359.15 1000.00 131 2654.35 <now> atlb009@xxxxxxxxx 3843058.59 1000.00 116 29752.33 <now> ----------------------- --------- --------- ------- --------- ------------ --------- ------ ------------ ---------- ---------- --------- --------- Number of users: 16 ByQuota 14713 289271.19 0+23:59 It looks like e.g. group_atlas.prod is its own group, and besides having inherited its idea of quota from group_atlas, it has nothing else to do with that group. Then I looked again at the config, and indeed, I had declared (following the documentation!!) group_atlas.prod as a group in the exact same way as I had defined group_atlas, so there was every reason to expect them both to be top-level groups. Hence I changed the configuration not to define the subgroups in the GROUP_NAMES declaration, but only to define them via the QUOTA declarations: GROUP_NAMES = group_atlas, \ group_alice, \ group_dune, \ group_enmr, \ group_lhcb, \ group_gw, \ group_ops GROUP_QUOTA_DYNAMIC_group_alice = 0.08 GROUP_QUOTA_DYNAMIC_group_atlas = 0.41 GROUP_QUOTA_DYNAMIC_group_atlas.prod = 0.79 GROUP_QUOTA_DYNAMIC_group_atlas.anal = 0.20 GROUP_QUOTA_DYNAMIC_group_dune = 0.09 GROUP_QUOTA_DYNAMIC_group_enmr = 0.09 GROUP_QUOTA_DYNAMIC_group_lhcb = 0.20 GROUP_QUOTA_DYNAMIC_group_gw = 0.09 GROUP_QUOTA_DYNAMIC_group_ops = 0.01 GROUP_ACCEPT_SURPLUS = true Then I see $ condor_userprio -hierarchical -quotas -most Last Priority Update: 11/19 09:34 Group Effective Config Use Subtree Effective Priority Wghted Total Usage Time Since Weighted Submitter Submitter User Name Quota Quota Surplus Quota Priority Factor In Use (wghted-hrs) Last Usage Requested Floor Ceiling --------------------------- --------- --------- ------- --------- ------------ --------- ------ ------------ ---------- ---------- --------- --------- group_lhcb 2958.40 0.20 ByQuota 2958.40 1000.00 0 3.53 0+00:01 0 lhcbpr11@xxxxxxxxx 500.26 1000.00 0 3.53 0+00:01 group_ops 147.92 0.01 ByQuota 147.92 1000.00 0 7.74 0+00:18 0 ops013@xxxxxxxxx 500.00 1000.00 0 5.17 0+00:18 ops007@xxxxxxxxx 501.35 1000.00 1 2.56 0+00:26 group_dune 1331.28 0.09 ByQuota 1331.28 1000.00 39 7499.99 <now> 34 dune090@xxxxxxxxx 180398.90 1000.00 34 7397.49 <now> group_atlas 6064.72 0.41 ByQuota 6064.72 1000.00 245 79.58 <now> 14765 atlsm022@xxxxxxxxx 500.21 1000.00 2 3.57 <now> anal.atlpi04@xxxxxxxxx 362596.38 1000.00 814 17625.10 <now> prod.atlb009@xxxxxxxxx 3386246.17 1000.00 10192 145489.76 <now> group_gw 1331.28 0.09 ByQuota 1331.28 1000.00 60 2064.20 <now> 75 ligo098@xxxxxxxxx 42963.66 1000.00 60 2045.86 <now> group_enmr 1331.28 0.09 ByQuota 1331.28 1000.00 617 12582.50 <now> 942 enmr043@xxxxxxxxx 270990.34 1000.00 624 12715.68 <now> group_atlas.anal 1212.86 0.20 ByQuota 1212.86 1000.00 682 17599.08 0+00:01 886 group_alice 1183.36 0.08 ByQuota 1183.36 1000.00 2432 33812.85 <now> 2821 alice039@xxxxxxxxx 500.00 1000.00 0 1.38 0+00:41 alisgm02@xxxxxxxxx 879456.18 1000.00 2736 37108.15 <now> group_atlas.prod 4790.80 0.79 ByQuota 4790.80 1000.00 10176 144917.66 0+00:01 13838 <none> 443.76 0.00 yes 14792.00 1000.00 572 78127.28 <now> 4595 atlpi04@xxxxxxxxx 212465.88 1000.00 1 4057.21 <now> enmr043@xxxxxxxxx 244912.04 1000.00 3 945.73 <now> alisgm02@xxxxxxxxx 1566845.80 1000.00 0 30761.14 0+03:27 lhcbpi05@xxxxxxxxx 1765119.20 1000.00 130 2666.10 <now> atlb009@xxxxxxxxx 3833413.25 1000.00 116 29762.74 <now> --------------------------- --------- --------- ------- --------- ------------ --------- ------ ------------ ---------- ---------- --------- --------- Number of users: 16 ByQuota 14713 290591.18 0+23:58 Which is more like I expect, with all the ATLAS users being under group_atlas, although now it looks like the subgroup quota sharing isnât doing anything - group_atlas.prod is âlast seen a minute agoâ so is no longer its own group or subgroup, itâs simply some string prepended to the username. How is this supposed to work? JT |