Opened 11 years ago

Last modified 9 years ago

#582 new defect

IZ2760: USE_QSUB_GID feature doesn't work on Windows hosts

Reported by: pollinger Owned by:
Priority: low Milestone:
Component: sge Version: 6.2
Severity: Keywords: execution
Cc:

Description

[Imported from gridengine issuezilla http://gridengine.sunsource.net/issues/show_bug.cgi?id=2760]

        Issue #:      2760             Platform:     All      Reporter: pollinger (pollinger)
       Component:     gridengine          OS:        All
     Subcomponent:    execution        Version:      6.2         CC:    None defined
        Status:       NEW              Priority:     P4
      Resolution:                     Issue type:    DEFECT
                                   Target milestone: ---
      Assigned to:    pollinger (pollinger)
      QA Contact:     pollinger
          URL:
       * Summary:     USE_QSUB_GID feature doesn't work on Windows hosts
   Status whiteboard:
      Attachments:

     Issue 2760 blocks:
   Votes for issue 2760:


   Opened: Tue Oct 21 10:58:00 -0700 2008 
------------------------


The USE_QSUB_GID feature doesn't work if a job is submitted from a Unix, Linux
or even a Windows host from a different domain to a Windows execution host.
The qsub_gid is transferred as a number, and the gid-numbers are in any case
different between Unix/Linux and Windows and usually different between different
Windows domains.

Suggested fix: Don't transfer the gid number, transfer the group name instead
and resolve the gid number on the execution host.

   ------- Additional comments from crei Thu Oct 30 02:44:05 -0700 2008 -------
One question we have also the problem that the gid have different names, but
same gid like:

On linux host the gid=10 is named "wheel"
On solaris host the gid=10 is named "staff"

   ------- Additional comments from pollinger Thu Oct 30 03:26:51 -0700 2008 -------
So we could stay with transferring gids and add a gid-to-gid mapping. This
wouldn't change the existing behaviour, i.E. all combinations of Unix and Linux
hosts would work without a map. If there are Windows hosts it would be
neccessary to add one entry per group and domain, which should be doable.
The question is where to put the map.

   ------- Additional comments from reuti Thu Oct 30 03:30:39 -0700 2008 -------
Wouldn't this fall into the region of enabling user mapping again?

   ------- Additional comments from crei Thu Oct 30 03:39:21 -0700 2008 -------
@reuti:
Yes and no ;-)
But adding a gid mapping for windows only is easier to implement. And we already
have some extra windows code ...

   ------- Additional comments from pollinger Thu Oct 30 03:47:23 -0700 2008 -------
@crei:
It would be not useful to add a mapping in the Windows code only. The mapping
should happen always in the same component (be it submit client, master or on
the execution host), so it must be there on Unix/Linux hosts, too.

   ------- Additional comments from crei Thu Oct 30 03:54:53 -0700 2008 -------
@harald (pollinger):

It depends what you want to have. If we implement the gid mapping you can
argument that it is useful (not only for windows).

Then someone (e.g. reuti) can argument why not also add (reactivate) user
mapping again.

The question here is: should we fix the bug or implement (reactivate) a feature?

We can also file an Enhancement request for the global gid(user) mapping and
implement a small gid mapping for fixing this issue.

What do you think?





   ------- Additional comments from pollinger Thu Oct 30 04:35:54 -0700 2008 -------
No, it does not depend. The mapping should always happen in the same component,
not matter what OS it runs on. Anything else would just be crazy.

I don't know if there are any useful remains of the old user mapping, I've never
seen it working, I don't know what it was (or should have been) capable of, so I
can't tell anything about it. But I doubt that we can just easily reactivate it
and I doubt that there will be time to develop a new full featured user mapping,
so we should just fix this bug in a way it can be enhanced to a complete user
mapping later.

   ------- Additional comments from crei Thu Oct 30 05:07:17 -0700 2008 -------
I agree with this

Change History (0)

Note: See TracTickets for help on using tickets.