glideinWMS

Details in #2378 (Proper support for glexec - required by site vs provided by site)

Igor's relevant comments from #2378
--------
For v3 I would propose we make glexec 1st class citizen and have a dedicated tag, e.g.:

<id_switching required="NO|OPTIONAL|YES" [type="glexec" path="blah" require_credentials="none|x509|voms"]/>

(this would also allow us to use something different than glexec, which is currently being discussed in OSG)
PS2: We will need something similar for the v3 frontend.
--------

Parag will check to see if this really needs to go into v3.1 or if it can wait until v3.x. (If it's a change in the XML, it should probably
go into v3.1..)

So here is my proposal with some modifications:

• Relevant config sections

<glidein ... >
  <entries>
    <entry ... auth_method="grid_proxy|voms_proxy|...">
      <sudo_tools>
        <sudo_tool type="glexec|NONE" required="TRUE|OPTIONAL|FALSE" path="OSG|glite|auto|path to tool" auth_method=" auth method"/>
      </sudo_tools>
    </entry>
  </entries>
</glidein>

<frontend ... >
  <security ... >
    <sudo_tools>
      <sudo_tool type="glexec|NONE" use="NEVER|OPTIONAL|ALWAYS"/>
    </sudo_tools>
    <credentials>
      <credential absfname="path to cred" security_class="frontend" trust_domain="OSG" type="grid_proxy"/>
      </credentials>
  </security>
</frontend>

• Factory
  • Currently will only support type = glexec|NONE with new types supported in future as we need.
  • For glexec, path will override the the GLEXEC_BIN attribute and will perform same functionality

• Frontend
  • sudo_tool[@use] is now equivalent to and override GLIDEIN_Glexec_Use

Changes to match making

• Frontend will only select entries that are ok with the sudo_tools configured and if it has the credential_type specified in the sudo_tool[@auth_method]

Changes to classads

• At present number of classads and contents will remain same with the sudo_tool configuration translated to the existing variables GLIDEIN_Glexec_Use & GLIDEIN_REQUIRE_GLEXEC_USE
• This may change in future based on how it works out, but hopefully changes should not affect existing semantics

Comments appreciated

For the frontend, we should move <sudo_tools> to the group level. Otherwise, as an example, you will not be able to configure your frontend to route jobs to Fermilab and to EC2. You would need two different frontends.

Now the master_2905 should have relevant code thats in branch_v2plus. cherry-picked commits from branch_v2plus that were missing in master. Master now support require_glidein_glexec_use as part of restrictions tag.

This will be in master when we merge master_2905 into master.
commit:54d8e9e535dcfd32e48261d0c5bd71e949f4f127

@Parag proposal:
So, the idea is to allow for multiple sudo tools at each and every site, and the FE decides which one to use?

If this is the case, I see two problems:
1) what is the relationship between auth_method in entry and in sudo_tool? Belongs-to? Something else?
2) What happens when you have more than one sudo_tool, and they are all REQUIRED?
3) What if a site requires at least one sudo_tool, but the FE is free to pick the one it wants?
4) What happens if the FE has several credentials, and an entry matches more than one sudo_tool... which one is used? First? RR? Random?

Bottom line, I think the basic idea is sound, but there are several details that need to be thought out.