-
Notifications
You must be signed in to change notification settings - Fork 356
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
chore: migrate continue trial form and remove steps [DET-3780 DET-3854] #1050
Conversation
@@ -1,3 +1,6 @@ | |||
/* eslint-disable-next-line @typescript-eslint/no-explicit-any */ | |||
export type RawJson = Record<string, any>; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
question: probably a good reason for this, but just curious of as to using any
instead of unknown
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if it's unknown we can't access any level in the object other than the first level. may if there was a way of defining a recursive Record<string, unknown>; type?
unknown was working fine because clone actually turns it into any. open to suggestions :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see, let's leave it
const TrialDetailsComp: React.FC = () => { | ||
const { trialId: trialIdParam } = useParams<Params>(); | ||
const trialId = parseInt(trialIdParam); | ||
const [ trial, triggerTrialRequest ] = | ||
useRestApi<TrialDetailsParams, TrialDetails>(getTrialDetails, { id: trialId }); | ||
const [ contModalVisible, setContModalVisible ] = useState(false); | ||
const [ contModalConfig, setContModalConfig ] = useState('Loading'); | ||
const [ contFormVisible, setContFormVisible ] = useState<boolean>(false); | ||
const [ contMaxLength, setContMaxLength ] = useState<number>(100); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
question: I asked about whether there is a good default value to set to for max length and the answer was "not really". Can we leave it blank so it forces the user to have to make that decision. @vishnu2kmohan @stoksc what are your thoughts on the default value of 100 for max length / batches?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I don't think there's a great default for how long to continue the trial. 100 batches is probably just fine.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What if the user specified records and epochs instead of batches in the base trial?
The user would expect that the unit from the base trial be carried over?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we want that, then maybe if records, 100 * global_batch_size
, if batches , 100
and if epochs math.ceil((100 * global_batch_size) / records_per_epoch)
. But in the event global_batch_size
, we pick the max
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But I think just not having a default is better, at that point.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we leave it blank
yes, and it'd fall back to what the experiment had set before which is the same behavior as the existing trial page. so I thnk this should be fine. does this sound right?
try { | ||
const expConfig = clone(experiment.configRaw); | ||
expConfig.description = formValues.description; | ||
setTrialLength(expConfig, parseInt(formValues.maxLength)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We may also need to shim min_validation_period
and min_checkpoint_period
in the same way.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@stoksc looks like min_validation_period
and min_checkpoint_period
are the same format as max_length
? Where they can be batches
, epochs
or records
?
Reference:
https://github.com/determined-ai/determined/compare/remove-steps
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yep, they are.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
would these also apply to experiment forking/creation? if so I think we should address it separately where it affects both workflows.
webui/react/src/ErrorHandler.ts
Outdated
@@ -26,6 +26,7 @@ export enum ErrorLevel { | |||
export enum ErrorType { | |||
Server = 'server', // internal apis and server errors. | |||
Auth = 'auth', | |||
Deprecated = 'deprecated', |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
question: looks like we're not using this yet. Is the plan to use this in the near future or this is just a forgotten loose end during PR dev?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hmm I go back and forth on it. some of the errors we run into about experiment config could be due to depracated attributes but we could also use Api type
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see, in that case I think the more info the better. Meaning knowing that it's deprecation error, separate from API error is a good thing.
return Object.entries(maxLength)[0] as [string, number]; | ||
}; | ||
|
||
const setTrialLength = (experimentConfig: RawJson, length: number): void => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
suggestion: how about returning new RawJson
(cloned) instead of mutating the exiting one?
Something like:
const setTrialLength = (experimentConfig: RawJson, length: number): RawJson => {
const newConfig = clone(experimentConfig);
... do stuff to clone
return newConfig;
};
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
in the current usecase (and some future ones) the pattern can provide an already cloned version. I didn't clone here to avoided double cloning. I'm thinking the use can always provide a cloned object if they want to? or if the cloning isn't expensive we can always do it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ah if it's already cloned, you're right, no need to do it again.
nit: wdy think about |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This PR looks good and worked great. Wrote some comments and questions throughout.
7ecbbb1
to
74ddeb9
Compare
hmm it's actually creating a single trial experiment so that could be confusing.. Continue trial? or just continue. but then continue is less strong than creatte |
0b5e121
to
ee237da
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Love the backwards compatibility! Two small nits.
pick 7ff1aa7 pr feedback part 1 pick cf64b18 delegate error view to createexperiment modal pick 9e09845 clean up and make it reset on cancel pick ee237da upgrade config for experiment detail as well pick 20be1bc use Api type for config errors instead of Deprecated pick 93c0a9f7 sort some props and use isNumber utility
20be1bc
to
92ff9db
Compare
Description
Test Plan
old experiment config:
after config upgrade:
Commentary (optional)