Skip to content
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

Merged
merged 9 commits into from
Feb 20, 2019
Merged

[KEP 0003] Initial Draft for 0003-kep-cli.md #118

merged 9 commits into from
Feb 20, 2019

Conversation

fabianbaier
Copy link
Member

This KEP is for the KUDO CLI.

Copy link
Member

@gerred gerred left a 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 Show resolved Hide resolved
keps/draft-0003-kep-cli.md Outdated Show resolved Hide resolved

As a user I want to be able to list current installed frameworks in my namespace.

#### Getting the status of a running framework
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You mean Instance?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1

Copy link
Member Author

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.

Copy link
Member

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 Show resolved Hide resolved
keps/draft-0003-kep-cli.md Outdated Show resolved Hide resolved

#### Executing into a particular framework

As a user I want to be able to execute into my framework environment.
Copy link
Member

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?

Copy link
Member Author

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.

Copy link
Member

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 Show resolved Hide resolved

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
Copy link
Member

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

Copy link
Member Author

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


As a user I want to be able to get a shell to a specific framework.

#### Read all combined logs of a framework
Copy link
Member

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.

Copy link
Member Author

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 ?


### User Stories

#### Installing a framework
Copy link
Contributor

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.


As a user I want to be able to list current installed frameworks in my namespace.

#### Getting the status of a running framework
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1

keps/draft-0003-kep-cli.md Outdated Show resolved Hide resolved
Copy link
Contributor

@joerg84 joerg84 left a 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

@runyontr runyontr merged commit 0c6b23c into master Feb 20, 2019
fabianbaier added a commit that referenced this pull request Mar 8, 2019
* 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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
component/cli kubectl kudo a.k.a. kudoctl help wanted kind/kep Kudo Enhancement needs review
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants