File transfer priority level configuration requirement clarification

[semaldona]

Checklist (Please check before submitting)

• [x] I reviewed the Contributing Guide.
• [x] I reviewed the CF README.md file to see if the feature is in the major future work.
• [x] I performed a cursory search to see if the feature request is relevant, not redundant, nor in conflict with other tickets.

Is your feature request related to a problem? Please describe. No

Describe the solution you'd like Per requirement CF5030.1, the CF file-transfer priority levels shall be configurable. This functionality is not currently implemented in CF.

Describe alternatives you've considered None

Additional context None

Requester Info Sergio Maldonado NASA/GSFC/Arctic Slope Technical Services

[skliper]

Isn't this requirement just saying that the priority level for a file transfer can configured by the user... vs saying that the priority levels themselves (0-255 or whatever) can be changed to something else (like 0-10)? If it's the former, then it's right here: https://github.com/nasa/CF/blob/d84a3eebf477eec49eef37f6f98d9e1b6fad5013/fsw/src/cf_tbldefs.h#L42 https://github.com/nasa/CF/blob/d84a3eebf477eec49eef37f6f98d9e1b6fad5013/fsw/src/cf_utils.c#L323-L339

[semaldona]

I think it's the latter.

CF5030: Each CF output channel shall have 256 file-transfer priority levels. CF5030.1: The CF file-transfer priority levels shall be configurable CF5030.2: The highest file-transfer priority level shall be zero.

Reading 5030.1 along with the others, it seems as though the required functionality is to limit the range of priorities. Plus, there are other requirements that already call out using the priority in a command argument.

[skliper]

Let's get input from @astrogeco and @jphickey. I don't think there's any need to have a requirement to be able to change the number of priority levels by configuration (this really doesn't seem to add much in terms of useful functionality that I can tell). I do think the priority level for a file transfer shall be configurable. Maybe the requirement just needs to be rewritten?

[skliper]

Note that if you can change the number of priority levels by configuration, then that configuration would fail CF5030. Could be as simple as removing an "s" in CF5030.1: The CF file-transfer priority level shall be configurable.

[skliper]

Although it seems implied by the .1 relationship, might be better to say: CF5030.1: The CF output channel file-transfer priority level shall be configurable.

I'm still guessing on intent here so we should get input from others... but that's how I understand it. It's explicitly requiring the priority as an element in the table for each output channel.

[semaldona]

Agreed on both your interpretation and that a rewrite is in order. However it doesn't seem that "configurable" is the appropriate term either. In the context of most other CF requirements, configuration items and actions typically denote behavior that is table driven. File transfer command arguments, such as class, channel, and priority level seem to capture the run-time behavior.

I would suggest a modification similar to CF5030.1: The CF output channel file-transfer priority level shall be set by a CF command.

While this is somewhat redundant with an existing requirement, CF3000: When CF receives a "Transfer File" command, CF shall play back the file indicated by the command-specified: filename, source path, destination path, keep/delete flag, service class, priority, channel, and peer-entity id, it could be left in for clarity.

[skliper]

Maybe we should chat :) It's in the table per my link above... so doesn't that mean table driven hence, "configurable"?

[skliper]

Basically, for the transfers that aren't commanded (polling or whatever) it uses the priority as specified in the config table doesn't it?

[semaldona]

Yes you are correct, priority is both a table item when polling and a parameter for commanded transfers.

[skliper]

Ok cool, so maybe then: CF5030.1: The CF output channel file-transfer default priority level shall be configurable. and somewhere in the rational state the default priority is used for transfers that are not initiated by command. Commanded transfers override the configured default priority with the priority contained in the command.

[semaldona]

Agreed, this sounds like the optimal solution.