upbound / up Goto Github PK
View Code? Open in Web Editor NEWThe @upbound CLI
License: Apache License 2.0
The @upbound CLI
License: Apache License 2.0
accounts.ListControlPlanes
is now supported by https://github.com/upbound/up-sdk-go, and it would be extremely useful to have a up cloud controlplanes list
command, especially when cleaning up self-hosted control planes.
In some scenarios, kube-cluster uid is not known or easily accessible by the user but available to agent running on the cluster.
Deployments through marketplaces are a good example here. For example, while deploying through Rancher marketplace, all deployment flow can be completed through UI without connecting cluster from a local terminal (with up installed).
It should be possible to create a self-hosted control plane and obtain a control plane token without cluster connectivity or providing kube-uid to the cli.
Or to unify the experience, we can always leave setting kube-uid to the agent (with the first connection attempt) and up cloud controlplane attach $NAME
command never sets kube-uid.
After a Helm installation, the following is printed:
NAME: uxp
LAST DEPLOYED: Mon May 10 19:29:06 2021
NAMESPACE: upbound-system
STATUS: deployed
REVISION: 1
TEST SUITE: None
NOTES:
By proceeding, you are accepting to comply with terms and conditions in https://licenses.upbound.io/upbound-software-license.html
โจ Thank you for installing Universal Crossplane!
๐ You can now connect your cluster to Upbound Cloud!
Example command:
$ up cloud controlplane attach <control plane name> | \
up uxp connect --token-secret-name upbound-control-plane-token --namespace upbound-system -
It tells you which namespaces it's installed into and the next steps. I think it'd be great to have something similar to be printed so that users knows the next step and it's a confirmation that the installation went through without errors (right now, it just exits)
This issue is timeboxed to 48 hours. Lazy consensus (i.e. maintain status quo) will be used at 8 AM PST 4/30/21 if universal consensus is not reached prior.
Currently, "user' profiles are stored in ~/.up/config.json
in the following format:
{
"cloud": {
"default": "ada",
"profiles": {
"a-uuid-for-ada-token": {
"type": "token",
"session": "cool-session-token"
},
"ada": {
"type": "user",
"session": "cool-session-token"
},
"a-uuid-for-hasheddan-user": {
"type": "token",
"session": "cool-session-token"
},
"[email protected]": {
"type": "user",
"session": "cool-session-token",
"org": "dan" // optional
}
}
}
}
As can bee seen in this example (and by reading the ratified design for initial commands), there are two types of cloud profiles that can be stored:
When a user executes an up cloud
command that requires supplying a user + org, the following order of precedence takes place:
--user
and --organization
are supplied as flags their values will be used (i.e. the profile that matches --user
will use the designated session
token to establish identify).--user
is specified, but not --organization
, the matching profile will be selected and if it has an org
field then that will be used. If it does not have an org
field then we try to use the specified user
as org
, which obviously will fail in the case that the user identifier is email or token UUID.--user
is not specified, but --organization
is, the profile specified as default
will be used with the supplied organization.Essentially, this boils down to "supplying a flag will always win". @turkenh pointed out some valid concerns with this structure in #14 (comment) revolving around the fact that we have "profiles", similar to how GCP and AWS credentials are stored, but we only allow one profile per user identifier (although you can kind of work around this by creating both a username and email profile for the same user). Hasan (justafiably) points out there that allowing for named profiles is more flexible as a user could theoretically have an endless number of custom profiles with differing configuration setups. However, I am somewhat opposed to this approach as our auth model does not currently mirror cloud providers in its complexity, and I personally don't actually love their model of profiles either (not that what I like or do not like should be the direction we go, but it is another UX data point.
The current design of our configuration schema feels simple and intuitive to me because if you specify a --user
you will always be logged in as that user (or token), whereas passing something like --profile <arbitrary profile name>
feels more opaque to me. We have dedicated commands to switch the default user and the default org for a user profile. This structure also simplifies our login
command as we don't require that a user provide a profile name or anything other than user+password or token. However, I feel almost certain that our auth model is not in its final form, so I would anticipate this schema evolving over time. The nice thing about these config files is that updating them is relatively non-destructive -- if this schema changes in the future, the worst thing a user would have to do is delete their ~/.up/config.json
and up cloud login
again after updating the CLI.
All of that being said, I think there are two cases in which we should modify this structure prior to the first release of up
:
In view both of these cases as unlikely, so I would advocate for preserving the current structure for the time-being. However, since this is a fairly important design choice, I want to offer a short period of discussion before finalizing for just the initial release. Thank you to @turkenh for always having an eye on UX and providing thorough reviews with very constructive feedback :)
The up
binaries need to be made available for download. Possible options include attaching them to the GitHub release, pushing them to a bucket, or other.
Appropriate documentation should exist for up
in the following locations:
README.md
/docs
(consider generating, though might do manual for now)/docs
The CLI should be available from all major package managers, an initial list could be:
Currently up uxp upgrade
will fail to upgrade from an installed Crossplane version unless an explicit version is specified and it is compatible (i.e. up uxp upgrade v1.2.1-up.3
). If no version is specified up
should find the latest compatible version and use it.
In order to create a coherent experience for up
users, we should document all of the commands we aim to support in the initial release, as well as any commands we know we may want to support in the future. Thinking about the long-term experience will inform the design decisions we make initially.
Homebrew is the most popular package manager for macOS and it'd be really easy to get up and running with up
if it's distributed in that channel. Details are in https://docs.brew.sh/Formula-Cookbook
This issue tracks creating the formulae, not automating the release pipeline to push every new version.
@hasheddan I know you have a linux, so I can take a stab at this if you'd like to.
We need CI setup on this repo.
Users should be able to pass a --view-only
flag to specify if a self-hosted control plane is view only.
Hi
I attempted to connect upbound cloud with up CLI.
But I faced following error.
How can I set account information?
NAME=mycrossplane
up cloud controlplane attach $NAME | up uxp connect -
up: error: no account was specified and a default could not be found
my up config is below.
โฏ cat ~/.up/config.json | jq .
{
"cloud": {
"default": "default",
"profiles": {
"default": {
"id": "[email protected]",
"type": "user",
"session": "MASKED"
}
}
}
}
I found both cloudCtx.Account and profile.Account are empty like below.
Thank you.
The first command that will need to be supported by up
is login
, which will allow users to login to Upbound Cloud and store their credentials. By default, this command should be interactive, prompting users for username and password. Providing flags for --username
and --password
should also be supported, as well as overriding with environment variables. By default, credentials will be stored in ~/.up/credentials.json
.
$ UP_USER=negz
$ cat password | up cloud login --password=-
up: error: unable to login: either username or token must be provided
I would expect to not need to pass --username
, since it should be read from $UP_USER.
Currently, if KUBECONFIG
env. variable points to a list of kubeconfig files delimited by :
, up
fails with the following error:
Usage: up cloud login
Login to Upbound Cloud.
Flags:
-h, --help Show context-sensitive help.
-v, --version Print version and exit.
--endpoint=https://api.upbound.io Endpoint used for Upbound API ($UP_ENDPOINT).
--profile=STRING Profile used to execute command ($UP_PROFILE).
-a, --account=STRING Account used to execute command ($UP_ACCOUNT).
-u, --username=STRING Username used to execute command ($UP_USER).
-p, --password=STRING Password for specified user. '-' to read from stdin ($UP_PASSWORD).
-t, --token=STRING Token used to execute command. '-' to read from stdin ($UP_TOKEN).
up: error: --kubeconfig: stat file1:file2: no such file or directory (from envar KUBECONFIG="file1:file2")
Under the same environment, kubectl
works as expected. I have tested this with up cloud login
as shown above.
We currently use the latest stable version of nfpm
in CI. We should instead pin to a specific version and update when appropriate. It appears the install script doesn't currently allow selecting a version for install, but we can download directly from the GitHub release if needed.
The control plane token secret does not have to be named the default value, so we allow users to override it with a --token-secret-name
flag.
Some tools, such as the rust compiler, support an error index, with each error corresponding to a code that can be looked up for more information. This allows for users to supplement information returned about an error with additional documentation. We should consider what it would look like to have a similar pattern in up
and how we can ensure consistency in errors and documentation.
Currently it is a manual process add cluster credentials of an Upbound-hosted cluster to a user's kubeconfig file.
Support the ability to populate a kubeconfig file from an Upbound Cloud hosted control plane, something like;
up cloud controlplane get kubeconfig
Running up uxp install v1.2.1-up.3
/ up uxp upgrade v1.2.1-up.3
fails because helm strips off the v
when storing the chart in the cache:
up: error: stat /home/dan/.cache/up/charts/universal-crossplane-v1.2.1-up.3.tgz: no such file or directory
Because UXP uses a leading v
in its versioning scheme and it is valid semver, we should support specifying the version to install with a leading v
.
We currently set the first profile the user logs in with as the default in ~/.up/config.json
. We should make it easy to change the default profile as desired.
Session tokens and default configured values as specified in #4 will be stored in ~/.up/config.json
. A schema will need to be introduced to read and write data to this file.
This repo should have PR and issue templates to make it easier for folks to report bugs and make contributions.
Currently if a self-hosted control plane already exists we don't have a way to connect to it. It would be nice if up cloud ctp attach
would produce a token if a control plane already exists, but that is problematic right now because:
Create
call for control planes in the Upbound API does not return a helpful error for identifying the control plane by ID in the case that a control plane already exists with the specified KubeClusterID
.We do have a up cloud ctp list
command now, which makes it easy to get a control plane ID. One simple fix would be to add something like --existing=<uuid>
to up cloud ctp attach
in the case where we want to use a self-hosted control plane that already exists.
That being said, self hosted control planes are lightweight and easy to create and delete, so users can always just up cloud xp delete <id>
and run up cloud attach
again.
Currently the default helm chart values cannot be generically overridden when installing / upgrading UXP with up
. This greatly reduces the capabilities of the installer, but it does allow for decoupling of the installer egnine, which means that we could switch out the engine in the future without the user having to know (or let them choose which engine to use). However, since we plan on using helm for the near to distant future, it doesn't make sense to restrict this functionality, and we could potentially accept "helm-style" parameterization in the future, even for a different engine. Therefore, it would be great to allow for pointing to a values.yaml
file via a --helm-values
flag on up uxp install
and up uxp upgrade
.
Every PR and merge to main should run a set of integration tests against a live k8s cluster and an Upbound Cloud account.
As an SRE, I will want to create a new controlplane with up controlplane create
and then monitor for the readiness of the controlplane from a scripted tool.
Inclue a Ready column with the output of up controlplane list
:
NAME ID SELF-HOSTED STATUS
kubeconfigtest a5a3f5cb-df6f-4c25-8529-08301531587f false Ready
hasan-test 44c83a5b-ce4b-4c07-8d37-1fc08440e7ac true Ready
demo-control-plane 5949c08a-0b65-492e-a22c-7387b0877510 false Creating
Michael Test 747379cf-0adc-47b1-8058-fba81e915f31 false Deleting
Currently, the Helm installer used for installing UXP only supports a traditional chart repository. Helm now experimentally supports pushing charts to OCI registries.
The installer should expanded to support pulling charts from OCI registries.
Epic #
Users should be able to run up uxp upgrade
with Crossplane installed and upgrade to compatible uxp
version. Could also consider a dedicated up uxp migrate
command, but the functionality would be similar.
Currently it seems like if you run up uxp uninstall
on a cluster where UXP is not installed exits with a non-zero code with the following message:
โฏ up uxp uninstall
up: error: uninstall: Release not loaded: universal-crossplane: release: not found
How about displaying this warning message but exiting with a zero-code to make this command idempotent?
For operators the up
command should provide information about the cluster's installed crossplane.
For example:
$ up uxp info
Universal Crossplane version 1.2.1 running.up.1
$ up uxp status
Healthy (exit code 0)
$ up uxp status
The Upbound RBAC controller is unhealthy (exit code -1)
The Upbound CLI is Upbound's official CLI for all our products including UXP, Upbound Cloud, and Upbound Registry. Today users authenticate the CLI with Upbound using the up cloud login
command. This makes it seem like users are logging into Upbound Cloud when in reality those credentials might be used to interact with a variety of Upbound products.
Users could instead up login
to authenticate.
This repo should contain a document describing how to contribute to up
and what the current process is for design and implementation of features.
Users currently have to either download the Crossplane CLI or know how to build a Crossplane package using Docker (or other OCI image tooling) in addition to up
to accomplish the full life-cycle of building, pushing, and installing packages alongside UXP and other Upbound services.
Users should be able to build and push Crossplane packages (Provider
/Configuration
) to the Upbound registry without needing any tooling outside of up
. The initial supported commands should include:
up xpkg build
up xpkg push
Future commands may include:
up xpkg init
up xpkg pull
Epic https://github.com/upbound/roadmap/issues/34
/points 5
Currently if you run up uxp install
on a cluster that already has UXP, it comes back with an error and an error code. Is this the right behavior?
Looking at the docs and CLI options, I'm not sure to determine if UXP is already running on a cluster using up
, which may force some users to install and check error codes if they are writing deployment scripts.
$ up uxp install
up: error: chart already installed with version 1.2.1-up.1
$ echo $?
1
For initial implementation, required commands include:
up cloud controlplane create
up cloud controlplane attach
up cloud controlplane delete
Self-hosted control planes use tokens to establish communication with Upbound Cloud. Currently, users are able to create a token for a self-hosted control plane when running up cloud xp attach <name>
, which both creates the control plane on Upbound Cloud and returns the token to connect. However, there is currently not an interface in the UI to manage control plane tokens. It would be great to give users the ability to manage them in up
with commands such as:
up cloud xp token list <control-plane-id>
: list all tokens for a control plane
up cloud xp token delete <token-id>
: delete a specified control plane token
up cloud xp token create <control-plane id>
: create a new token for the specified control plane
Error messages are a bit sparse and can be difficult to understand. They don't have to be perfect for first release, but we should ensure that they do as much as they can to help users get unstuck without needing to go to documentation.
Would also be a good idea to write up a design doc on error message philosophy for up
.
All downloads of up
should be checked against a checksum. Checksums can be automatically published on github for releases, but we should consider publishing them alongside binaries on https://cli.upbound.io
so that are present on dev builds as well.
up
should support auto-completion for common shells, such as bash
, zsh
, fish
, etc.
up uxp install
should wrap the helm install command for the UXP chart.
Our CLI needs to be open sourced under Apache 2.0, similar to how upbound/universal-crossplane
is today. Additionally, we need to have a usage license for this project like UXP does.
AC's
https://github.com/upbound/up/blob/main/LICENSE
When up
can access an installed UXP instance, its version information should be returned in up --version
.
While up
is a native M1 Mac executable available in homebew, developers on M1 macs may wish to run UXP against a local Kind or Minikube cluster for testing. UXP already supports arm64 images so any arm64-compatible version of Kubernetes should run if Docker version > 3.3.1 is installed.
Ensure that you are running a version of Docker that supports Apple Silicon: https://docs.docker.com/docker-for-mac/apple-silicon/
M1 Mac support (via arm64 node images) in Kind is currently a WIP.
There is a workaround to build your own images: kubernetes-sigs/kind#166 (comment)
Until issue #2176 is closed, a custom image can be used as in the example below:
brew install kind
kind create cluster --image rossgeorgiev/kind-node-arm64:v1.21
up uxp install
Minikube currently supports M1 Macs out of the box:
brew install minikube
minikube start
up uxp install
Users should be able to run commands with verbose logging by passing a top-level flag. This can be accomplished by passing a logger down through the command tree.
Currently we force users to either be upgrading from a helm release named crossplane
or universal-crossplane
. Though it is not a frequent occurrence, users are not required to actually helm install Crossplane or UXP with those names. This means that as up
currently functions, users could not interact with installs that use alternate names. A simple solution for this case would be to support a --name
flag for all UXP commands. However, this makes our installer abstraction somewhat leaky in that a release is a helm concept. In practice, any other installer we build may also need to support "names" for installs as well, and would likely want to support upgrading a helm installed Crossplane, so it may not pose much of an issue. In the worst case, the name flag would be ignored by other installer backends. If the --name
flag had a UXP_NAME
env var counterpart, dealing with alternatively named installs may not be too cumbersome, but there has also been some discussion around storing UXP install information in ~/.up/config.json
.
$ up cloud login
Username: muvaf
Password:
$
I log in with up cloud login
with correct credentials successfully, but in order to know that it's successful I need to check the return code. It'd be great to print where the credentials are stored and which profile is used after a successful login.
UXP does not enforce a single name for the control plane token, but it must match the one from the helm install. Users should be able to supply a --token-secret-name
flag to up uxp connect
to do override the default.
Currently when users login with up cloud login
we store a session token in ~/.up/config.json
that will be valid for 30 days (unless user revokes sessions in the UI). We should also make it easy to revoke these individual session tokens using the CLI in the event they are compromised. up cloud logout
will take no arguments and will use the default profile to log out unless overridden by --profile
. This will invalidate the current stored session token.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.