Port the current NuNet CLI tool written in bash to golang
How
Why
The CLI was first written as a bash script to save time but since it's being used regularly by everyone nowadays, it's best to implement it in a more efficient, maintainable and cleaner way. The commands should stay the same with the same subcommands, arguments and response format except in cases where the original format was lazy implementation like the nunet info command which basically passes the raw metadata file through jq. In those cases, updating the output format in a more standard manner would be best.
When
No technical dependencies.
Acceptance Criteria
Click to expand
Merge request
Code review
Work Breakdown Structure (WBS)
[show] log (Start: August 21, Estimated End: August 21)
Click to expand
Task
Description
Duration
Status
Start Date
End Date
Comment
A
Create basic structure for command
1.5 Hrs
Done
August 21
August 21
B
Get log entries organized by boot cycles
2 Hrs
Done
August 21
August 21
C
Function to create tarball
1 Hr
Done
August 21
August 21
D
Implement systemd API instead of exec
3 Hrs
Done
August 21
August 22
E
Testing & Debugging
3 Hrs
Done
August 22
August 22
resource-config (Start: August 16, Estimated End: August 17)
Click to expand
Task
Description
Duration
Status
Start Date
End Date
Comment
A
Create basic structure for command
1.5 Hrs
Done
August 16
August 16
B
Handle flags structure and cases
0.5 Hr
Done
August 16
August 16
C
Formatting output
2 Hr
Done
August 16
August 16
[new/create] wallet (Start: August 15, Estimated End: August 16)
Click to expand
Task
Description
Duration
Status
Start Date
End Date
Comment
A
Create basic structure for command
2 Hrs
Done
August 15
August 16
B
Handle flag structure & cases
3 Hrs
Done
August 16
August 16
C
Final touches
2 Hrs
Done
August 16
August 16
[show] capacity (Start: August 11, End: August 15)
Click to expand
Task
Description
Duration
Status
Start Date
End Date
Comment
A
Create basic structure and logic
1.5 Hr
Done
August 11
August 11
B
Encapsulate metadata function from info command for reusability in capacity command
3 Hrs
Done
August 14
August 14
Had to make some little research about pointers since it's necessary for returning a nil struct
C
Create structure for supported flags
1.5 Hr
Done
August 14
August 14
As for now we have the --full, --available, --onboarded flags. Support for other flags regarding GPUs and so on will be added later.
D
Replace function for printing structs by YAML marshaling
5 Hrs
Done
August 14
August 15
I was doing this manually without knowing though. YAML is more easier to read than JSON. I think that a CLI should be simple and clear with its output and even more if has flags to print just the essential data. If someone perhaps wants to work with JSON they can just do the way the bash script is already doing: make the request directly with curl and parse the response with jq. I don't think this approach makes sense when porting it to Go. In this case I'm opting to print info with YAML formatting.
E
Make only necessary requests upon flags passed by the user
1.5 Hr
Done
August 15
August 15
The current implementation makes two requests: /onboarding/metadata and /onboarding/provisioned. That means is not necessary to always make both requests if the info needed is just in one endpoint. (Actually, all info can be obtained by the /metadata endpoint, but right now I'm just doing the way the bash script did, we can change this later).
F
Define default behavior
1 Hr
Done
August 15
August 15
G
Final touches
3 Hrs
Done
August 15
August 15
Improve readability in general and add better help messages
[show] info command (Start: August 8, End: August 8)
Click to expand
Task
Description
Duration
Status
Start Date
End Date
Comment
A
Handle basic command logic
1 Hr
Done
August 8
August 8
B
Handle better response and errors
1.5 Hr
Done
August 8
August 8
Feature idea: have flags for filtering output
onboard command (Start: August 3, End: August 11)
Click to expand
Task
Description
Duration
Status
Start Date
End Date
Comment
A
Set required flags for onboard (-m, -c, -a, -n)
1 Hr
Done
August 3
August 4
B
Create function for setting JSON values
2 Hrs
Done
August 4
August 4
C
Handle basic command logic
3 Hr
Done
August 7
August 7
D
Handle better response and errors
6 Hrs
Done
August 8
August 9
D1
Check if machine is already onboarded
3 Hrs
Done
August 8
August 8
Took some time until I discovered there was already a function to check for onboarding status. I was trying to invent the wheel.
D2
Create small prompt to confirm if user wants to reonboard
2 Hrs
Done
August 8
August 8
D3
Improve help messages
1 Hr
Done
August 9
August 9
E
Fix JSON body request
2 Hrs
Done
August 9
August 9
F
Fix how data is set on JSON using existing structs
3 Hrs
Done
August 9
August 10
Before I decided to work on this I was fixing some bugs and the situation now is: the values on metadata are being updated and we are able to onboard (in theory). However, I think the data is not being unmarshaled to the JSON correctly and that is why the response code is 400. The solution is to use the existing struct "CapacityForNunet" to set the values instead of creating a new one.
G
Testing and debugging
3 Hrs
Done
August 10
August 10
H
Add mockup support for plugin flag
1 Hr
Done
August 11
August 11
[list] peers & [view] self commands (Start: July 25, End: August 3)
Click to expand
Task
Description
Duration
Status
Start Date
End Date
Comment
A
Create and organize peer subcommands (list & self)
1 Hr
Done
July 25
July 26
B
Create execution code for peer subcommands
7 Hrs
Done
July 26
August 3
B1
Handle structure for request response, JSON parsing and errors
2.5 Hrs
Done
July 26
July 26
B2
Create execution code for self subcommand
1 Hr
Done
July 27
July 27
B3
Create listing of bootstrap peers in list subcommand
1.5 Hr
Done
July 27
July 27
B4
Create listing of DHT peers in list subcommand
1.5 Hr
Done
July 27
July 27
B5
Final touches (listing self peer addresses)
0.5 Hr
Done
July 28
July 28
C
Change command call pattern to list peer and view self
1.5 Hr
Done
July 31
July 31
D
Modularize the process of parsing the JSON response and handling errors within the request context