-
Notifications
You must be signed in to change notification settings - Fork 101
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[KEP 0003] Initial Draft for 0003-kep-cli.md #118
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks pretty good. We don't have to put that non-goal in if we don't want to, it's just the only thing I can think of other than spelling.
keps/draft-0003-kep-cli.md
Outdated
|
||
As a user I want to be able to list current installed frameworks in my namespace. | ||
|
||
#### Getting the status of a running framework |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You mean Instance?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, and very good find! I see this important with kep-2
coming along to not confuse Framework
with framework or Component
. I had the fear that once we have dynamic CRDs the definition of Framework wouldn't apply here anymore and we would have to rewrite. Originally it was intended as running framework aka that would be an Instance.
I also think the user story should be getting the status of an Instance, leaving the running
entirely out.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The Components
in that branch are just a playground, those won't be merged in with those names.
keps/draft-0003-kep-cli.md
Outdated
|
||
#### Executing into a particular framework | ||
|
||
As a user I want to be able to execute into my framework environment. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This ones a little tricky. I'm not sure we're going to have a good use-case for this after we get the FrameworkCLI portion working (using Framework cli against an instance). What's an example use-case here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would also replace framework with Instance.
Then this was more thought of as having the option to bring up an Instance specific container similar to a busybox, just equipped with specific tooling for the environment. E.g. for Flink having a special flink-busybox
with the FlinkCLI pre-installed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When would they need this instead of just running the kubectl kudo flink cli <args>
over and over again to interact?
keps/draft-0003-kep-cli.md
Outdated
|
||
As a user I want to be able to use framework specific logic, e.g. in Kafka create a topic or in Flink to upload a new job. | ||
|
||
#### Shell into containers of a framework |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same comment as Executing into a particular Framework
. Not sure the difference between the two
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here the difference would lay in having directly access to the pods/containers itself of an Instance rather than launching next to it a busybox container as proposed in Executing into a particular Framework
keps/draft-0003-kep-cli.md
Outdated
|
||
As a user I want to be able to get a shell to a specific framework. | ||
|
||
#### Read all combined logs of a framework |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just to think about as we implement. We should be able to identify where each log line came from.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How would we identify where each log line came from? We would have more control over events, so instead of logs should we focus more on events (don't have that here at all)? Otherwise maybe a simple wrapper around kubectl logs -l heritage=kudo,app=instance
?
keps/draft-0003-kep-cli.md
Outdated
|
||
### User Stories | ||
|
||
#### Installing a framework |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would use an instance of a framework
as the typical user story would be to get a running (e.g., kafka) cluster.
keps/draft-0003-kep-cli.md
Outdated
|
||
As a user I want to be able to list current installed frameworks in my namespace. | ||
|
||
#### Getting the status of a running framework |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1
* Updated Mailing list link and OWNERS * Kudo Community.
* Update Mailing List in CONTRIBUTING * Fix linebreak. * Fix list formatting
* Provide local build instructions in CONTRIBUTING> * Remove kubebuilder dep. * Add docker build steps.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, looks great. Maybe just wait for @runyontr review as he had some feedback on the earlier versions
* initial draft for 0003-kep-cli.md * Added Kubebuilder as prerequisite. (#116) * Simplified Docker build step in Makefile. (#117) * Updated Mailing list link and OWNERS (#119) * Updated Mailing list link and OWNERS * Kudo Community. * Update Release Process. (#120) * Update Slack link to point to channel. (#123) * Update Mailing List in CONTRIBUTING (#122) * Update Mailing List in CONTRIBUTING * Fix linebreak. * Fix list formatting * Add local build steps to CONTRIBUTING. (#124) * Provide local build instructions in CONTRIBUTING> * Remove kubebuilder dep. * Add docker build steps. * addressed review for 0003-kep-cli.md
This KEP is for the KUDO CLI.