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

Add support for applying set of resources via kubectl #1958

Merged
merged 1 commit into from
Nov 4, 2014

Conversation

mfojtik
Copy link
Contributor

@mfojtik mfojtik commented Oct 22, 2014

Discussion: #1905

@mfojtik
Copy link
Contributor Author

mfojtik commented Oct 22, 2014

@smarterclayton fyi

This is a quick and dirty extraction from the origin repo where I removed references to our objects. Not sure if the Label update should be part of this or we can strip it down as well.

@smarterclayton
Copy link
Contributor

Sorry, this was supposed to be on kubectl as a new submit command, not on kubecfg. Kubecfg is going away

@smarterclayton
Copy link
Contributor

Take the label update out - this is about taking a set of files or a config or multiple configs directly as they are. Brian's comments on the other pull made a good case against addingn labels. If necessary we will move that back to templates

@mfojtik
Copy link
Contributor Author

mfojtik commented Oct 22, 2014

@smarterclayton OK, how about ClientMappings ? Without those I will have to guess the resource path from the Kind.

@smarterclayton
Copy link
Contributor

abstract the mechanism to get the mappings for a given Kind into a method, only implement the Kube objects in that method, and then leave a TODO to sort out client extensibility.

@mfojtik
Copy link
Contributor Author

mfojtik commented Oct 22, 2014

@smarterclayton ack, will look into this tomorrow.


// Config contains a set of Kubernetes resources to be applied.
// TODO: Unify with Kubernetes Config
// https://github.com/GoogleCloudPlatform/kubernetes/pull/1007
Copy link
Contributor

Choose a reason for hiding this comment

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

Remove this TODO

@bgrant0607 bgrant0607 self-assigned this Oct 23, 2014
@bgrant0607
Copy link
Member

@smarterclayton Which comments do you mean?

@bgrant0607
Copy link
Member

/cc @ghodss

package v1beta1

import (
kubeapi "github.com/GoogleCloudPlatform/kubernetes/pkg/api/v1beta1"
Copy link
Member

Choose a reason for hiding this comment

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

If we decide to keep this definition, we should spec a v1beta3 version, also.

@bgrant0607
Copy link
Member

Very cool! Thanks much.

@soltysh
Copy link
Contributor

soltysh commented Oct 23, 2014

@mfojtik just a quick question, currently k8s has only single types.go and you're introducing the OpenShift model described in #1744, is it a step towards that cleanup, or you'll merge those into pkg/api/types.go?

@smarterclayton
Copy link
Contributor

As per #1744 we may want to keep them separate and then import them into v1beta1/2/3/internal placeholders. Also, Config is not a server side type yet, even though it is an API type.

----- Original Message -----

@mfojtik just a quick question, currently k8s has only single types.go and
you're introducing the OpenShift model described in #1744, is it a step
towards that cleanup, or you'll merge those into pkg/api/types.go?


Reply to this email directly or view it on GitHub:
#1958 (comment)

@mfojtik
Copy link
Contributor Author

mfojtik commented Oct 24, 2014

@smarterclayton I updated the Config registration (moved it into api/*/types.go) and removed labels, etc. Can you please review those changes?

The kubectl is still pending, I will try to have some PoC this weekend.

{
"id": "frontend",
"kind": "Service",
"apiVersion": "v1beta3",
Copy link
Member

Choose a reason for hiding this comment

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

FYI, these aren't using the v1beta3 schema. It looks like v1beta1.

@mfojtik mfojtik force-pushed the config branch 2 times, most recently from 10e2ed7 to 6095e56 Compare October 27, 2014 13:11
@mfojtik mfojtik changed the title [WIP] Add support for applying set of resources via kubectl Add support for applying set of resources via kubectl Nov 3, 2014
// be valid API type. It requires ObjectTyper to parse the Version and Kind and
// RESTMapper to get the resource URI and REST client that knows how to create
// given type
func ApplyItems(typer runtime.ObjectTyper, mapper meta.RESTMapper, clientFor ClientFunc, items []runtime.Object) errs.ValidationErrorList {
Copy link
Member

Choose a reason for hiding this comment

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

This just does Create. Please rename to CreateItems.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

+1

How about CreateObjects ?

Copy link
Member

Choose a reason for hiding this comment

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

CreateObjects also SGTM, especially if "items" no longer exists in the serialization.

@mfojtik
Copy link
Contributor Author

mfojtik commented Nov 4, 2014

@bgrant0607 @smarterclayton PR rebased and updated. Thanks!

@mfojtik mfojtik force-pushed the config branch 2 times, most recently from bd47135 to 568173f Compare November 4, 2014 13:19
@mfojtik
Copy link
Contributor Author

mfojtik commented Nov 4, 2014

@smarterclayton @bgrant0607 I'm thinking about removing the config_test.json file or moving it into example... Also do we have some docs I should update about the kubectl createall command?

@bgrant0607
Copy link
Member

LGTM. Thanks!

config_test.json is useful, I think, because it illustrates the format expected by createall.

@bgrant0607
Copy link
Member

Regarding docs: we eventually need a new version of cli.md, but right now we don't have any doc for kubectl AFAIK.

bgrant0607 added a commit that referenced this pull request Nov 4, 2014
Add support for applying set of resources via kubectl
@bgrant0607 bgrant0607 merged commit e8dbcaf into kubernetes:master Nov 4, 2014
@mfojtik mfojtik deleted the config branch November 4, 2014 14:49
@smarterclayton
Copy link
Contributor

Some next steps I'd like to see - @bgrant0607 your opinion?

  • Define a generic mechanism for mapping input sources to a stream of runtime.Objects (including unknown types) (call this an Object stream)
    • Includes directories, JSON files with arrays on disk, JSON files that are a standard List type, and JSON object streams (from HTTP / file etc)
    • Integrate this into createall
    • Ensure we have a good generic error reporting pattern
  • Determine whether we can simply move that function into create (just by relaxing our create arguments?) and remove create all
  • Should we also add that to kubectl update
    • Determine whether kubectl update should have create-or-update behavior (make it an option?)
  • Allow listing of items from an Object stream

@bgrant0607
Copy link
Member

@smarterclayton SGTM. In addition to update and get, I'd like to be able to drive delete from an Object stream. Could you copy your last comment over to #1905?

seans3 pushed a commit to seans3/kubernetes that referenced this pull request Apr 10, 2019
tsmetana pushed a commit to tsmetana/kubernetes that referenced this pull request May 20, 2024
[release-4.14] OCPBUGS-14373: Fix flaky HPA e2e tests by not failing on context cancelled (kubernetes#117669)
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

Successfully merging this pull request may close these issues.

5 participants