Expected vs actual behavior

• make build should create pctl exe in bin directory

Steps to reproduce the bug

Makefile is missing

Briefly describe the feature

Currently whenever there's a new release of pctl, the user needs to manually download and update the pctl binary in their system. Since it doesn't automatically install while installing Paralus, the user may miss out on updating pctl.

We could have a command like pctl upgrade --latest which basically downloads the latest binary for the current system and installs it.

We could also have a background check for latest version when the user types pctl. If there's a newer version, it can display a sentence like 'you're using an outdated version of pctl, please upgrade to the latest binary'

What problem does this feature solve? Please link any relevant documentation or Issues

Makes the pctl upgrade process easier and faster.

Briefly describe the feature

In order to run the pctl tool, we need to download a configuration file from dashboard. It blocks the Paralus users who wants to only use paralus from pctl. We should remove the dashboard dependency to use pctl.

What problem does this feature solve? Please link any relevant documentation or Issues

pctl can be used independently without dashboard.

(optional) What is your current workaround?

Get the pctl configuration from back-end without dashboard.

Tasks:

• Add a design document about how to implement this

• change the repo name
• changes to go.mod
• changes to all files with Rafay
• changes to command - pctl / paractl
• CI / CD needs to be changed
• readme's, contributing docs, issue, features templates
• governance related docs - to be checked

Expected vs actual behavior

Expected: Location should be optional for cluster creation.
Actual: Cluster creation is failing because of location.

Steps to reproduce the bug

$ pctl create cluster imported sample-imported-cluster --config ./[email protected]
Error: resource sanjose-us of type location not found

Are you using the latest version of the project?

Yes

What is your environment setup? Please tell us your cloud provider, operating system, and include the output of kubectl version --output=yaml and helm version. Any other information that you have, eg. logs and custom values, is highly appreciated!

./pctl version
VERSION: 0.1.0
BUILD: 0.1.0
BUILD-TIME: 1656329967
ARCH: linux/amd64

(optional) If you have ideas on why the bug happens or how it can be solved, please provide it here

• I've described the bug, included steps to reproduce it, and included my environment setup with all customizations.
• I'm using the latest version of the project.

Expected vs actual behavior

Any PCTL call fails due to having that X-API-KEYID header twice, which went calling paralus API leads to a concatenated API Key and a failure:

https://github.com/paralus/cli/blob/b87e7047311b8e13b7e06c1500ed1e515adfb5fe/pkg/authprofile/key_profile.go#L72C17-L72C28

Steps to reproduce the bug

1. Generate the config json
2. Use it as a config input parameter into a PCTL call
3. Call will fail as unable to find key, since the key will be in the format API_KEY, APIKEY

• I've described the bug, included steps to reproduce it, and included my environment setup with all customizations.
• I'm using the latest version of the project.

• changes for namespaced scope role creation
• update role association to users
• update role association to groups
• verify kubectl download and commands execution for namespaced roles

Briefly describe the feature

Before, when Paralus returned an error like "sql: no rows return", it got returned through the CLI. Now, you get a generic error like: could not complete operation create on resource clustertest of type cluster. The real error should be returned

What problem does this feature solve? Please link any relevant documentation or Issues

This prevents a user from knowing why a request failed, which impacts my provider management

(optional) What is your current workaround?

The current workaround is to check the API call directly through postman or debugging inside the library.

Describe the issue you're facing

The repo name cli is generic name and doesn't clarify what exactly it is. Instead of cli we should rename it to pctl (Go binary name is pctl anyway).

Expected vs actual behavior

• digitally signing the pctl CLI for macOS, currently it shows an error saying it is not trust worthy.

Steps to reproduce the bug

1. Download pctl and true to execute any command like pctl get clusters after configuring it.

Are you using the latest version of the project?

You can check your version by running helm ls|grep '^<deployment-name>' or using pctl, pctl version, and provide the output.

• Yes

What is your environment setup? Please tell us your cloud provider, operating system, and include the output of kubectl version --output=yaml and helm version. Any other information that you have, eg. logs and custom values, is highly appreciated!

• Applicable to all

• I've described the bug, included steps to reproduce it, and included my environment setup with all customizations.

• I'm using the latest version of the project.

Checkout this Action job for failing tests.
It is expected to fix all test to run both GitHub workflows without error.

As of now even though we have version info available, looks like we are not providing an option for the user to fetch it. This would be useful when debugging/filing an issue.

Expected vs actual behavior

If while running the command line call to create a project you give it a bad name like "/this/is/mine", it will actually allow the project to be created

Steps to reproduce the bug

1. Run commandline to create a project
2. Give it a bad project name
3. Check the paralus UI

Are you using the latest version of the project?

You can check your version by running helm ls|grep '^<deployment-name>' or using pctl, pctl version, and provide the output.

VERSION: 0.1.0
BUILD: 0.1.0
BUILD-TIME: 1656329967
ARCH: darwin/amd64

What is your environment setup? Please tell us your cloud provider, operating system, and include the output of kubectl version --output=yaml and helm version. Any other information that you have, eg. logs and custom values, is highly appreciated!

kubectl

clientVersion:
  buildDate: "2022-08-23T17:44:59Z"
  compiler: gc
  gitCommit: a866cbe2e5bbaa01cfd5e969aa3e033f3282a8a2
  gitTreeState: clean
  gitVersion: v1.25.0
  goVersion: go1.19
  major: "1"
  minor: "25"
  platform: darwin/amd64
kustomizeVersion: v4.5.7
serverVersion:
  buildDate: "2022-11-29T18:41:42Z"
  compiler: gc
  gitCommit: 52e500d139bdef42fbc4540c357f0565c7867a81
  gitTreeState: clean
  gitVersion: v1.22.16-eks-ffeb93d
  goVersion: go1.16.15
  major: "1"
  minor: 22+
  platform: linux/amd64

helm

version.BuildInfo{Version:"v3.10.3", GitCommit:"835b7334cfe2e5e27870ab3ed4135f136eecc704", GitTreeState:"clean", GoVersion:"go1.19.4"}

(optional) If you have ideas on why the bug happens or how it can be solved, please provide it here

CLI should have a guard against names with slashes.

• I've described the bug, included steps to reproduce it, and included my environment setup with all customizations.
• I'm using the latest version of the project.

Expected vs actual behavior

Actual:

$ ./pctl create role test-role --scope project --permissions project.read,cluster.read,partner.read,organization.read --config ./[email protected] 
Error: invalid permissions, error: invalid permission partner.read  
$ ./pctl create role test-role --scope project --permissions project.read,cluster.read,organization.read --config ./[email protected] 
Error: invalid permissions, error: invalid permission organization.read

Should be able to create role with "partner.read" permission.
We are able to create "project" scoped role with "partner.read" permission from the Paralus console.

Steps to reproduce the bug

Run above steps.

Are you using the latest version of the project?

You can check your version by running helm ls|grep '^<deployment-name>' or using pctl, pctl version, and provide the output.

What is your environment setup? Please tell us your cloud provider, operating system, and include the output of kubectl version --output=yaml and helm version. Any other information that you have, eg. logs and custom values, is highly appreciated!

VERSION: 0.1.0
BUILD: 0.1.0
BUILD-TIME: 1656329967
ARCH: linux/amd64

(optional) If you have ideas on why the bug happens or how it can be solved, please provide it here

• I've described the bug, included steps to reproduce it, and included my environment setup with all customizations.
• I'm using the latest version of the project.

Expected vs actual behavior

Expected:
{type: "ClusterApprove", lastUpdated: {seconds: 1665989454, nanos: 819601552}, reason: "pending"}

Actual:
{type: 1, status: 0, lastUpdated: {seconds: 1665989454, nanos: 819601552}, reason: pending}

Steps to reproduce the bug

1. execute pctl get cluster <cluster_name> -oyaml

Are you using the latest version of the project?

You can check your version by running helm ls|grep '^<deployment-name>' or using pctl, pctl version, and provide the output.

• Yes

What is your environment setup? Please tell us your cloud provider, operating system, and include the output of kubectl version --output=yaml and helm version. Any other information that you have, eg. logs and custom values, is highly appreciated!

• v0.1.6

• I've described the bug, included steps to reproduce it, and included my environment setup with all customizations.
• I'm using the latest version of the project.

Briefly describe the feature

• add this CLI tool in Homebrew package manager which is widely used by Mac users. Adding to their repo will give more visibility to the wide userbase. brew.sh

What problem does this feature solve? Please link any relevant documentation or Issues

• having tool in package manager like brew will make installation process easy

(optional) What is your current workaround?

• NONE