Sure, I just opened an issue so I don't forget about it (
https://github.com/jupyterhub/batchspawner/issues/62) so I'm happy to get a
PR implementing it!

On Fri, Mar 16, 2018 at 2:02 PM, Brian Fulton-Howard <[email protected]>
wrote:

> Should I do a pull request?
>
> On Friday, March 16, 2018 at 3:00:09 PM UTC-4, Michael Milligan wrote:
>>
>> Yes, in general that's the correct idiom. You probably need to explicitly
>> import your base class though (i.e. add "import batchspawner.LsfSpawner"
>> before you declare your subclass).
>>
>> That said, both of those req_* options look like good candidates for
>> adding to the base class, especially since req_partition already exists in
>> at least one other batchspawner subclass.
>>
>> On Fri, Mar 16, 2018 at 11:15 AM, Brian Fulton-Howard <[email protected]>
>> wrote:
>>
>>> Thanks!
>>>
>>> I have a potential addition to my config file. I had to subclass the
>>> LsfSpawner class because it appears incomplete and doesn't have all of the
>>> options required for our cluster. Does this look right?
>>>
>>> c.JupyterHub.spawner_class = 'wrapspawner.ProfilesSpawner'
>>> c.Spawner.http_timeout = 120
>>> #-----------------------------------------------------------
>>> -------------------
>>> # BatchSpawnerBase configuration
>>> #   Providing default values that we may omit in the profiles
>>> #-----------------------------------------------------------
>>> -------------------
>>> c.BatchSpawnerBase.req_runtime = '12:00'
>>> #-----------------------------------------------------------
>>> -------------------
>>> # ProfilesSpawner configuration
>>> #-----------------------------------------------------------
>>> -------------------
>>> # List of profiles to offer for selection. Signature is:
>>> #   List(Tuple( Unicode, Unicode, Type(Spawner), Dict ))
>>> # corresponding to profile display name, unique key, Spawner class,
>>> # dictionary of spawner config options.
>>> #
>>> # The first three values will be exposed in the input_template as
>>> {display},
>>> # {key}, and {type}
>>> #
>>>
>>> ## Override LsfSpawner to be compatible with Minerva
>>>
>>> class MinervaSpawner(batchspawner.LsfSpawner):
>>>     batch_script = Unicode('''#!/bin/sh
>>> #BSUB -R "span[hosts=1]"        # Only spawn job on one server
>>> #BSUB -P {account}
>>> #BSUB -q {queue}
>>> #BSUB -m {partition}
>>> #BSUB -R rusage[mem={memory}]
>>> #BSUB -n {nprocs}
>>> #BSUB -J spawner-jupyterhub
>>> #BSUB -o {homedir}/.jupyterhub.lsf.out
>>> #BSUB -e {homedir}/.jupyterhub.lsf.err''')
>>>
>>>     req_partition = Unicode('', \
>>>         help="Partition name to submit job to resource manager"
>>>         ).tag(config=True)
>>>
>>>     req_account = Unicode('', \
>>>         help="Account name to submit job to resource manager"
>>>         ).tag(config=True)
>>>
>>> c.ProfilesSpawner.profiles = [
>>>    ( "Local server", 'local', 'jupyterhub.spawner.SudoSpawner', {'ip':
>>> '0.0.0.0'} ),
>>>    ('Bode - 2 cores, 4 GB, 8 hours', 'bode2c4g12h', 'MinervaSpawner',
>>>     dict(req_nprocs='2', req_queue='premium', req_runtime='8:00',
>>> req_memory='4000',
>>>          req_partition='bode', req_account='acc_LOAD')),
>>>    ('Manda - 8 cores, 128 GB, 4 hours', 'manda128gb', 'MinervaSpawner',
>>>     dict(req_nprocs='8', req_queue='premium', req_runtime='4:00',
>>> req_memory='16000',
>>>          req_partition='bode', req_account='acc_LOAD')),
>>>    ('Bode - 2 cores, 4 GB, 24 hours', 'mesabi2c4gb24h',
>>> 'batchspawner.TorqueSpawner',
>>>     dict(req_nprocs='2', req_queue='premium', req_runtime='24:00',
>>> req_memory='4gb',
>>>          req_partition='bode', req_account='acc_LOAD')),
>>>    ]
>>>
>>>
>>>
>>> On Thursday, March 15, 2018 at 6:47:28 PM UTC-4, Michael Milligan wrote:
>>>>
>>>> Hi Brian -
>>>>
>>>> It is possible, and it sounds like you already mostly have the
>>>> solution! The example config at the end of the batchspawner README should
>>>> be roughly what you want, except that you will use the SudoSpawner instead
>>>> of LocalProcessSpawner. Specifically, you need to install all of the
>>>> spawners you are using alongside Jupyterhub (e.g. pip install wrapspawner,
>>>> batchspawner, and sudospawner into the same virtualenv as jupyterhub) --
>>>> the ProfilesSpawner configuration will tell Jupyterhub which spawner to use
>>>> in response to the user's menu selection.
>>>>
>>>> Sorry about the confusing state of the documentation about how to do
>>>> this. Batchspawner and wrapspawner were originally distributed in the same
>>>> repository, and when we split them apart it sounds like we may not have
>>>> included enough context on one side or the other. We're happy to get
>>>> suggestions about how to improve the docs if you'd like to give us some
>>>> feedback when you get a chance.
>>>>
>>>> Regards,
>>>> Michael
>>>>
>>>> On Thu, Mar 15, 2018 at 4:58 PM, Brian Fulton-Howard <[email protected]
>>>> > wrote:
>>>>
>>>>> As I understand it, I need to use some combination of wrapspawner,
>>>>> localspawner, sudospawner and batchspawner. I want to run jupyterhub as an
>>>>> unprivileged user, but the admins are happy to edit the sudoers file to
>>>>> make it work. What I'd like to do is give users in my lab a choice to 
>>>>> start
>>>>> on the LSF cluster (batchspawner) or locally (localspawner). Wrapspawner
>>>>> would provide the interface to make a selection.
>>>>>
>>>>> Is this possible, and how would I go about doing it? I looked in the
>>>>> documentation for the various spawners and didn't find any detailed
>>>>> information.
>>>>>
>>>>> The cluster supports PAM, so I don't need any special authenticator.
>>>>>
>>>>> --
>>>>> You received this message because you are subscribed to the Google
>>>>> Groups "Project Jupyter" group.
>>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>>> an email to [email protected].
>>>>> To post to this group, send email to [email protected].
>>>>> To view this discussion on the web visit
>>>>> https://groups.google.com/d/msgid/jupyter/a3f21888-0495-4fe0
>>>>> -b598-ca7e226bd61f%40googlegroups.com
>>>>> <https://groups.google.com/d/msgid/jupyter/a3f21888-0495-4fe0-b598-ca7e226bd61f%40googlegroups.com?utm_medium=email&utm_source=footer>
>>>>> .
>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>
>>>>
>>>>
>>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Project Jupyter" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to [email protected].
>>> To post to this group, send email to [email protected].
>>> To view this discussion on the web visit https://groups.google.com/d/ms
>>> gid/jupyter/1f26020c-41cf-4dc4-84d7-41a879c68bea%40googlegroups.com
>>> <https://groups.google.com/d/msgid/jupyter/1f26020c-41cf-4dc4-84d7-41a879c68bea%40googlegroups.com?utm_medium=email&utm_source=footer>
>>> .
>>>
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>> --
> You received this message because you are subscribed to the Google Groups
> "Project Jupyter" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> To post to this group, send email to [email protected].
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/jupyter/49e1e9c4-32a6-4843-8738-3cc3c468305e%40googlegroups.com
> <https://groups.google.com/d/msgid/jupyter/49e1e9c4-32a6-4843-8738-3cc3c468305e%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Project Jupyter" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jupyter/CAPuy8grh4mjKhC7vVMNpcJvQS3H7God2R9XDvDW%3Di1ZwFP03pA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to