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

Create a repository for examples: kubeflow/examples #174

Closed
jlewi opened this issue Jan 30, 2018 · 11 comments
Closed

Create a repository for examples: kubeflow/examples #174

jlewi opened this issue Jan 30, 2018 · 11 comments

Comments

@jlewi
Copy link
Contributor

jlewi commented Jan 30, 2018

I think we should create a repository where we can start hosting E2E examples.

Right now we have a couple E2E examples in various states of development

/cc @puneith @cwbeitel

@puneith
Copy link
Contributor

puneith commented Jan 30, 2018

@jlewi Why do you think we need a separate repo and not Kubeflow be that place?

@cwbeitel
Copy link
Contributor

I have some additional examples in progress to add.

Would love to have them under e2e test. But for some examples you may want to do progressive testing to speed things up / cache previous runs. Such as with Bazel. That could be a mod to the way kubeflow runs tests or could be a reason to have a separate repo.

@jlewi
Copy link
Contributor Author

jlewi commented Jan 30, 2018

@puneith Because examples will be in various states of development and should probably be separate from the core code.

For the most part, this repo corresponds to our ksonnet registry.

@jlewi
Copy link
Contributor Author

jlewi commented Feb 1, 2018

Another reason for moving examples into their own repository is that it will probably be a different group of folks working on the examples then the folks working on our core ksonnet components.

@puneith
Copy link
Contributor

puneith commented Feb 1, 2018

I agree with that model.

@gaocegege
Copy link
Member

Vote for separate repo 👍

@elsonrodriguez
Copy link
Contributor

I could go either way, but my doc fixes have included ksonnet changes. Managing two separate repos for things that are tied together may be painful.

@jlewi
Copy link
Contributor Author

jlewi commented Feb 1, 2018

@elsonrodriguez I think the fact that writing examples requires modifying our core ksonnet components is an indication of other problems

  • immaturity/limitations of the ksonnet templates
    • e.g. I think in some of your changes you had to add parameters to the TF serving component to allow more flexibility
  • version compatibility issues because we haven't started creating tagged releases yet
    • By March we should have a 0.1 branch for ksonnet registry and our examples should be written against that.

@jlewi
Copy link
Contributor Author

jlewi commented Feb 1, 2018

Lets give a separate repo a shot and then adapt as need be.

I think the main priority now is getting more examples that illustrate Kubeflow so velocity is the primary motivation. With a separate repo we can easily start giving a different set of folks write access and moving the ball forward.

@elsonrodriguez If you want to take the lead on an inception example I'm happy to make you an approver.

@jlewi
Copy link
Contributor Author

jlewi commented Feb 1, 2018

Created the repo:
https://github.com/kubeflow/examples

Created a team examples-approvers and gave it write access to the repo.
I seeded the team with some devrel folks from Google and Microsoft(@wbuchwalter) who've contributed to Kubeflow.

@jlewi jlewi closed this as completed Feb 1, 2018
@elsonrodriguez
Copy link
Contributor

@jlewi Sure, I can take the current inception example and rework/port it over.

yanniszark pushed a commit to arrikto/kubeflow that referenced this issue Nov 1, 2019
* Run helm convert on the current sparkoperator from GCP folks (not GCP specific)

* Try and put the spark operator in the kubeflow namespace

* Move the spark operator into base/ and generate a sample test

* is crd not crb

* Attempt to address CR feedback

* use the nameprefix instead of having sparkoperator- everywhere

* Update the spark test to match the changes

* move spark-operator to spark

* move base into spark-operator subdir

* Update spark operator test

* Add the appplication overlay
yanniszark pushed a commit to arrikto/kubeflow that referenced this issue Feb 15, 2021
…eflow#174)

* Related to kubeflow#141 katib releaser
* Related to kubeflow#1574 use prow to build our images

* We are moving to using prow to run our release workflows and treating them
 just like regular workflows.

* We are doing this because we need to get regular signal about whether
  the image builds are succeeding by running on postsubmit.

* We also want to run them on presubmit so that we can verify any changes
  to the workflwo don't break the workflow.

* Rather than define a new workflow to build the images; we can just reuse the
  existing E2E workflow which already builds all the images. We just
  change postsubmit to push to kubeflow-images-public.

* Delete the releaser app; we will just the existing E2E test workflow
  and have that push to gcr.io/kubeflow-images-public on postsubmit.
elenzio9 pushed a commit to arrikto/kubeflow that referenced this issue Oct 31, 2022
* Include me as viewer

* Alphabetical ordering
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants