redhat-developer / app-services-cli Goto Github PK

The current experience for the command was to be able to execute rhams login but the current command requires users to specify URL.

What we are missing is a config file to easily manage lint rules in the project.

golangci-lint is used but this can be extended by adding a config file. See their docs

We need to move operator to the separate repository - repository is created already.

Edit and improve documentation for CLI by providing documentation that provides number of steps that user can use to achieve some specific needs

Examples:

1. Logging and creating a cluster
2. Interacting with cluster - credentials and topics

Current guide:
https://github.com/bf2fc6cc711aee1a0c2a/cli/blob/main/website/docs/commands.md

Cluster that is currently pending should have special handling to not request topics etc.

We should at least display a message saying that the current user has no kafka clusters.

To reproduce -

change the results in https://github.com/bf2fc6cc711aee1a0c2a/cli/blob/dd3692b9d2e993fefd90db1afcc097e45f6ce306/mas-mock/src/handlers.js#L57 to return an empty list.

Start the mock-server

cd mas-mock
yarn 
yarn start

build the cli and then ./rhmas kafka list.

see attached image

The first command corresponds to what we have when there is something returned from the list.

The second command returns blank since the list is empty (this is a bug).
/cc @craicoverflow @wtrocki

The Managed Services API client (generated) is in /client. This issue is to investigate the best place to put it.

Preferably it should live close to https://github.com/bf2fc6cc711aee1a0c2a/cli/blob/d1cb530f06595f35b34ef9532869c755c4a05b04/pkg/api/rhmas/client.go

The location of this client should also be suitable to place other API clients in the future.

• Mock Credentials/SASL PLain in docker
• Consider changes to edit? Do we need edit?

Create documentation on how to interact with the stagging environment.
See if we can connect Quarkus (What will need to be involved) and use some of the https://github.com/bf2fc6cc711aee1a0c2a/quickstarts temporary repository we use for the investigation.

We need to have guide on website/repo and adapt it as the CLI evolves - NO DOCS!

Current readme and documentation structure is in the bad shape we need to split contributing based commands to contributing.md and focus on the CLI usage in readme (reuse/share some of the instructions from the docs etc.

rhoas is the new cli name

Logging erros is currently broken (see Login cmd for example that has that commented out)
https://github.com/bf2fc6cc711aee1a0c2a/cli/pull/33/files

We need to create POC for the connection to the Kafka CLI.
Investigate how to get cert from created Kafka.

Duplicate of #48

rhmas login should be disabled for the moment. We will work on ADR to enable that flow.
Token should be required.

Let's move the subcommand files to /pkg to keep everything in the same place.

Developers should not need to specify use after creation.

There is a chance users will used this CLI on a Windows computer. We should ensure this builds on Windows by adding the appropriate steps to CI.

Investigate how connect command should look like.

See: redhat-developer/app-services-operator#2

When the user performs the bind command, the CLI contacts the MK Control Plane (Service API) and obtains a list of Kafka instances and metadata for them. It then asks the user which Kafka instance they want to bind to the OSD. When the user selects a Kafka instance, the CLI then creates the ManagedKafka custom resource and creates a secret. Finally on success the CLI returns info on how to create a service binding.

We need to find an approach for us to provide secret creation (with user logging in)

It should be made very simple for people to download and install the release binaries to their path.

We can wrap this process in a Bash script for each operating system.

rhmas login might not make sense right now until decision is made.

It should be straightforward for users to install the CLI. A simple script can be added and referenced in the README to allow users to install the binary with a single command.

Adding mock for possible api that will return credentials.

Spec:
https://gist.github.com/wtrocki/0721da3e8f4db92b0d24d403582c560b

What

Set up a local Keycloak instance which can be deployed with Docker Compose. This is to mock SSO authentication which is not ready yet.

Requirements

1. The CLI needs to have a client registered in order to be able to authenticate.
2. docker-compose.yml Keycloak configuration.

TL;DR - single file produced (.kafka.env or something like it)
Contains environment variables that can be referenced:

URL
USERNAME
PASSWORD

Justification

We embeed credentials in properties at the moment.
that is good for local development.. but terrible for any deployment as one do not want to have credentials embedded in container etc. (classical 12 factor app thing tells that this is very bad)
I think we can change our credentials command to produce more than single file
It will always produce an environment file (that can be later easily translated into Operator/CR secret with the same variables)
Then separate quarkus properties files that reference it

We are beginning to see a need to share code across different commands (see #50). There needs be an architecture in place to decouple business logic from the commands through a common API in /pkg.

There should be environment variables for certain configs which are hard-coded currently:

-Realm
-etc

New api is: /api/managed-services-api/v1/kafkas/{id}/serviceaccount

The current approach is a short term solution but we should (semi) automate this process.

Creating as separate issue as we need to pick time for this.

We need to:

• Move all commands from cmd folder
• Have testing file for each command/rule etc.
• Rename packages that doesn't reflect the folder name.
• Use folders to reflect packages /kafka/create

All points are based on the discussion but not settled stone.

https://github.com/bf2fc6cc711aee1a0c2a/cli/blob/78ed20ab1ec6314272a8555fbb8a3b703ce81f25/cmd/kafka/massdk.go#L38 uses token without checking if it has expired or not. It would be useful to check this before usage.

When I want to run rhoas on MacOS in console/terminal, I get this warning:

I can allow rhoas in "System Preferences -> Security & Privacy" to run, but I would like to avoid this step and run rhoas instantly after download. It can look unsafe this way.

Steps to reproduce:

0. Have a machine with MacOS
1. Download tar.gz with rhoas
2. Untar archive
3. Run ./rhoas
4. You should get warning mentioned above

• Use is not validating value passed by user - wrong cluster can be set
• Use might fetch all clusters and allow to specify name.
• No validation for commands that rely on the cluster.
• status should print text instead of json

Our current help is not targeting exactly the current context of the docs.

FYI @PaulRMellor

I believe we should take a lot of inspiration from the GitHub CLI in its architecture:

https://github.com/cli/cli/

Status codes should be handled and an appropriate message should be displayed in the console.

Example:

rhmas kafka list

This command outputs Error retrieving Kafka clusters: undefined response type when the response code is a 401.

A more helpful message would be something like You are not authorized to make this request. Please login using "rhmas login" or something along those lines.

Generally we are handling two cases right now: 200 == success and everything else is a generic error.

We should be able to release CLI by creating a release tag.
Example: https://github.com/chirino/graphql-gw/blob/master/.github/workflows/release.yml

Questions

1. What kind of automation we want to use?
2. Do we need to test with REAL API?
3. Testing with mock

• Currently CLI has mock that can test all the commands on the CI/CD process.

4. Do we need some external closed CI/CD process or happy with github actions (possibly github actions doing all the job very well)

How to start

• Check all moving parts of the CLI
• Identify commands and what API they use.
• See what areas require improvements
• Engage with developers/Create issues/PR's with suggestions

Standarize fomat of the operating system return codes.

We can:

return error from CLI and make cobra to handle this.
Return error explicitly <- Probably not desired or should be at least wrapped in one place.

You can press tab tab and get results from list as ids to select.

rhmas kafka use

> 1iSY6RQ3JKI8Q0OTmjQFd3ocFRg

3iSY6RQ3JKI8Q0OTmjQFd3ocFRg
4iSY6RQ3JKI8Q0OTmjQFd3ocFRg

When requesting format like jsom/yml we should not print anything else than json - that will allow to pipe things to file etc.

The config abstraction is mixed with some unrelated elements that should be removed.