Add "user-project" option to accept a user-defined project name

[HughNhan]

Synopsis:

Add another flavor of setting run project. Currently crucible-rickshaw is the default project. There is also the "unique-project" option which autogenerates a project name with UUID. This new "user-project" option allows the user to specify a user-defined project name.

Unit test:

1. Default project name crucible-rickshaw works correctly when no unique-project or user-project option.
2. unique-project option works correctly
3. user-project works correctly

[k-rister]

So, I think I have to start by asking why is this needed? I would assume it is because the user defined project name already exists and has been endowed with certain privileges/capabilities/etc. that the user needs. If that is the case, then I think you might want to add an additional piece of logic to skip the namespace deletion to avoid tearing down that user defined project. If this is not the case then I don't really understand why we need this.

Next, I think I would expect a different order of precedence. If the user goes to the trouble of specifing a user-project then it should probably have the highest priority instead of unique-project.

[HughNhan]

So, I think I have to start by asking why is this needed? I would assume it is because the user defined project name already exists and has been endowed with certain privileges/capabilities/etc. that the user needs. If that is the case, then I think you might want to add an additional piece of logic to skip the namespace deletion to avoid tearing down that user defined project. If this is not the case then I don't really understand why we need this.

The new "user-project" option supports multiple users sharing a testbed more conveniently. By having a user-defined namespace each can manually manage their run more conveniently. During debug, I abort/CTK-C a run quite often. I can identify my objects more easily with my namespace.

Next, I think I would expect a different order of precedence. If the user goes to the trouble of specifing a user-project then it should probably have the highest priority instead of unique-project.

The precedence is for code robustness. Perhap due to a typo/mistake the run CLI has both options. In this situation, the new, "user-project" should be overridden because the incumbent "unique-project" has more usage history.

[k-rister]

So, I think I have to start by asking why is this needed? I would assume it is because the user defined project name already exists and has been endowed with certain privileges/capabilities/etc. that the user needs. If that is the case, then I think you might want to add an additional piece of logic to skip the namespace deletion to avoid tearing down that user defined project. If this is not the case then I don't really understand why we need this.

The new "user-project" option supports multiple users sharing a testbed more conveniently. By having a user-defined namespace each can manually manage their run more conveniently. During debug, I abort/CTK-C a run quite often. I can identify my objects more easily with my namespace.

Ok, so deletion isn't an issue.

Next, I think I would expect a different order of precedence. If the user goes to the trouble of specifing a user-project then it should probably have the highest priority instead of unique-project.

The precedence is for code robustness. Perhap due to a typo/mistake the run CLI has both options. In this situation, the new, "user-project" should be overridden because the incumbent "unique-project" has more usage history.

I'm not sure I agree with this. Our CLI leaves a lot to be desired and is one the the reasons why we are switching to JSON so that historical aspect/conflict doesn't really bother me. I'm curious what @atheurer thinks?

[k-rister]

It might make more sense, and avoid the precendence conflict, to change this so that the only parameter is unique-project. If the value is 1 then it would autogenerate a project name as it does today, if it is anything else it could use that value for the project name.

[HughNhan]

It might make more sense, and avoid the precendence conflict, to change this so that the only parameter is unique-project. If the value is 1 then it would autogenerate a project name as it does today, if it is anything else it could use that value for the project name.

I will make that change and resubmit.
Thanks Karl!

[k-rister]

Don't you need to tweak this as well:

    if [ "${unique_project}" == "1" ]; then
        project_name+="--${run_id}-${endpoint_label}"
    fi

[HughNhan]

Don't you need to tweak this as well:

    if [ "${unique_project}" == "1" ]; then
        project_name+="--${run_id}-${endpoint_label}"
    fi

The submit code is currently like this:

if [ "${unique_project}" == "1" ]; then
    project_name+="--${run_id}-${endpoint_label}"
elif [ ! -z "${unique_project}" ]  &&  [ "${unique_project}" != "0" ]; then
    project_name="${unique_project}"
fi

}

[k-rister]

Hmm, so it is. For some reason when I was looking at the changes yesterday I didn't see that part, but I do now...weird.