Find out whom to contact about Datahub or PARASOL (formerly DSMLP), what to include in a ticket,
and how to ask for a change you cannot make yourself, such as more disk space
or a larger GPU class. If you are a student in a course, start with your
instructor or TA.
Support Tiers
Students in a course contact their instructor or TA first. Course staff are the
first tier of support for course matters: an assignment, a package the course
needs, an environment that does not contain what the syllabus specifies, or a
missing roster entry. Course staff hold the course's own support ticket with ITS
and can see the course and its roster.
Platform problems go directly to ITS, whoever reports them. Platform problems
include an inability to sign in at all, a service that is down, and behavior
that differs from the documentation.
Researchers and lab members have no instructor tier and use the contacts in
Support Contacts directly.
| Question |
Contact |
| A course a student is enrolled in |
The instructor or TA, first |
| Datahub or PARASOL itself: access, images, launching, quotas, GPUs |
parasol@ucsd.edu |
| Research work, or Universal Scale Storage |
rcd-support@ucsd.edu |
| An outage, or anything to be tracked as a ticket |
The ITS Service Desk |
| Which platform is appropriate for a research project |
Research IT |
| An in-depth conversation, for an instructor, TA, or Technical Point of Contact (TPOC) |
1:1 Consultation |
Email and the Service Desk
Email to parasol@ucsd.edu and a ticket through the
Service Desk reach the same staff. Email to that address opens a case, and the
Service Desk web form submits to the same queue. Either route may be used. The
web form is better suited to screenshots and long pastes.
Research IT is the first contact for the question of whether a research project
belongs on PARASOL. Research IT can compare a project against the other platforms
the campus runs, including capabilities PARASOL does not have, such as a full
batch scheduler, MPI, and multi-node work, and against the platforms a PI's
group already uses.
See also: Coming from HPC
Contents of a Support Ticket
A ticket that ITS can act on without further questions contains the following
items.
| Item |
Detail |
| The course or workspace |
By name or ID, for example COGS 108. The disk-quota-service page displays the ID. |
| The system |
datahub.ucsd.edu in a browser, or dsmlp-login at a terminal |
| The environment or container |
The one selected, for example scipy-ml-notebook |
| The exact command |
If there was one, copied rather than described |
| The exact error |
Copied rather than described, with a screenshot |
| The time |
Approximately when it happened, and whether it happens every time |
Command-Line Details
A ticket about a problem at the command line also includes the node and the
pod. The launch output names the node the pod was assigned to, for example
INFO pod assigned to node: its-dsmlp-n04.ucsd.edu, and kubectl get pods
gives the pod ID and its status.
See also: Error Messages
Incidents Affecting More Than One Person
A report of an incident that affects more than one person states its scope in
the first line. ITS prioritizes effort by the number of courses and students
affected and by the overall impact on instruction. A first line such as "none of
my 200 students can start a notebook, and the midterm is Thursday" distinguishes
a broad incident from an individual report such as "my notebook will not start".
Response Targets
Individual User Issues
ITS targets resolution of individual user issues within 1-2 business days. The
target applies to students in a course, researchers, and instructors, and to
the requests in Administrative Requests.
A problem report from an independent study or project user, whose access came
through the Independent Study Request form, may take up to 5 days to answer.
Instructor Incident Tier
For instructors only, an incident affecting multiple courses, many users, or a
critical point in the quarter such as an exam carries a target response time of
30 minutes from first contact to the Service Desk and a target resolution time
of 8 hours. The tier is an instructional commitment. An instructor or TA reaches
it by reporting a broad incident. An individual user does not reach it by
marking a ticket urgent, and a student whose whole class is affected reaches it
by telling the instructor.
Escalation Outside Business Hours
Urgent problems outside business hours may be escalated through the Service
Desk. Escalation may be requested, and the Service Desk determines how it is
routed.
1:1 Consultation
1:1 Consultation appointments connect instructors, TAs, and TPOCs with ITS
technical staff for real-time guidance. See
Support & Technical Consultation.
Administrative Requests
None of the requests in this section has a self-service control. The requester
has no form, slider, or setting in the interface for any of them; each is an
administrative action taken by someone else.
| Request |
Granted by |
Information to include |
| More disk space |
Cluster administrators, by ticket. In a course, the instructor or TA raises it on the course's existing ticket. |
The workspace ID, the current disk-quota-service reading, what is taking the space, and what has already been cleared |
| A resource tier above the default. See Resource Tiers |
Cluster administrators, by ticket to parasol@ucsd.edu |
What the work is, the CPU and memory it needs and why, whether it is one container or several at once, and how long the raise is needed for |
| A GPU class the workspace was not granted |
Cluster administrators. A request from an instructor or PI carries more weight than one from a member. |
The workspace, the class needed, the model or dataset whose memory footprint requires it, and the dates it matters on |
| More Service Units |
Cluster administrators set budgets. A workspace manager may request a change but cannot edit a budget. |
The workspace, what the work is, the date by which it must be done, and what the budget has already been spent on |
| A waived cancellation penalty |
The workspace manager: an instructor or TA for a course, a PI for a lab, at cancellation or afterwards. A manager's waiver clears the member's share; only an administrator clears a group pool's share. |
Which booking, and what happened |
| A longer reservation than the workspace permits |
Cluster administrators, by ticket to parasol@ucsd.edu. They alone set the workspace length cap; a course's cap is usually changed at the instructor's request |
The length needed, why the work cannot be split into shorter windows, and how it checkpoints |
Cancellation Penalty Waivers
A cancellation penalty waiver needs no ticket. The workspace manager grants it
on the Group Reservations page of the reservation app, without ITS
involvement.
See also: The Cancellation Penalty
Booking on a Member's Behalf
A booking a workspace manager makes on a member's behalf is charged to the
member's budget. It is not a way around a spent budget: it can leave the member
over budget, which blocks their own bookings and on-demand leases until the
window renews. When a member has run out of Service Units before a deadline,
request more by ticket.
See also: Service Units & Budgets
Writing an Administrative Request
An administrative request names the workspace, describes the work, states the
deadline and time window, and lists what has already been tried.
Naming the Workspace
Almost every limit in Administrative Requests
belongs to a workspace rather than to an individual. A request that does not
name a workspace cannot be acted on. The disk-quota-service page displays the
workspace ID, and workspace --list on the login node prints every workspace an
account belongs to.
See also: Naming a Workspace on the Command Line
Describing the Work
One sentence describing the work is sufficient. "Fine-tuning a 7B model for a
CSE 251 project" indicates the GPU class, the approximate memory, and the
approximate duration.
Deadline and Time Window
A request bounded in time is easier to approve than an open-ended one. Quotas
are date-aware: cluster administrators can raise a course's share for the span
of a project deadline and let it revert automatically. A request for "32 CPU for
the week of the 9th" is therefore stronger than a request for "32 CPU".
Checks Before Requesting
For a disk quota, state that the Jupyter Trash is empty and that no personal
copy of a shared dataset is held. For a GPU class, state that a smaller class
does not fit. These two checks resolve a large share of requests without a
ticket.
Workspace Managers and Cluster Administrators
The workspace manager is the instructor or TA in a course, and the PI in a
lab. A manager may view the group's reservations, book on a member's behalf,
cancel members' bookings, and waive a cancellation charge, among other actions.
A manager may not edit Service Unit budgets, group limits, or the workspace
length cap, regardless of seniority.
Cluster administrators hold all other administrative controls and are
reached by ticket.
See also: Managing a Group
Other Administrative Requests
The requests in this table also have no self-service path.
Expected Behaviors Reported as Faults
Several of the most frequently reported behaviors are the system working as
designed.
A quota increase, a GPU class, or a longer reservation window is an
administrative request rather than a fault report. These requests have no
self-service path. See Administrative Requests.
Report a problem with this page