Any update on this? @thockin

@jlowdermilk this should work in kubectl, right? How does it work?

As far as I know the raw API doesn't support multi-create. kubectl supports creating multiple items via a list, but it does so by parsing the list and issuing create requests against the appropriate endpoint for each resource.

So to answer your question @parikhyash, if you want to create multiple items from a single yaml/json file, use kubectl create -f if you want to use the raw API, you'll have to parse the list and issue multiple creates. Supporting list creating within the API itself is an interesting idea, but not likely to be implemented any time soon. cc @bgrant0607.

Why do we have type List in the API?

On Fri, Jun 19, 2015 at 4:28 PM, Jeff Lowdermilk notifications@github.com
wrote:

So to answer your question @parikhyash https://github.com/parikhyash,
if you want to create multiple items from a single yaml/json file, use kubectl
create -f if you want to use the raw API, you'll have to parse the list
and issue multiple creates. Supporting list creating within the API itself
is an interesting idea, but not likely to be implemented any time soon. cc
@bgrant0607 https://github.com/bgrant0607.

—
Reply to this email directly or view it on GitHub
#9633 (comment)
.

@thockin We have list types for 2 reasons:

1. That's what LIST (GET on a resource collection) returns
2. So kubectl can decode/encode a LIST using the same machinery we use to decode/encode API objects

I could imagine a bulk-creation API in the future. I added this to the "v2" API list (#8190).

Thanks for the update @jlowdermilk . I'll continue using the multiple create approach for now.

The bulk-creation feature is particularly useful for bringing up all components of a Storm cluster or even a Redis cluster at once.
Also, will there be any field similar to dependencies in the future? For example, Nimbus would first wait for the Zookeeper replication controller to come up while supervisors wait for both Nimbus and Zookeeper. @bgrant0607 (Marathon does this by having a field called "dependencies" which takes a list of components)

Re. dependencies: Some previous discussion on #1768 and #4245

1. I thought we returned PodList, ServiceList, etc for GET operations?

2. We have pkg/client/clientcmd/api/types.go, why does this need to be in
   the main API file (assuming I am right on (1).

On Fri, Jun 19, 2015 at 5:01 PM, Brian Grant notifications@github.com
wrote:

@thockin https://github.com/thockin We have list types for 2 reasons:

1. That's what LIST (GET on a resource collection) returns
2. So kubectl can decode/encode a LIST using the same machinery we use to
   decode/encode API objects

I could imagine a bulk-creation API in the future. I added this to the
"v2" API list (#8190
#8190).

—
Reply to this email directly or view it on GitHub
#9633 (comment)
.

1. True. The list mentioned at the top of this issue actually has kind ServiceList.
2. List predates clientcmd/api/types.go. List was added in Allow runtime.Object to be encoded as runtime.RawExtension #2786. It doesn't appear in the swagger, only in types.go.

As I understand it the api/*/types.go List type is for use in json/yaml
files to hold a lit of multiple object types. I just don't get why it is
in pkg/api and not pkg/client, if outr API doesn't actually support it.

On Fri, Jun 19, 2015 at 10:40 PM, Brian Grant notifications@github.com
wrote:

1. True. The list mentioned at the top of this issue actually has kind
   ServiceList.
2. List predates clientcmd/api/types.go. List was added in Allow runtime.Object to be encoded as runtime.RawExtension #2786
   Allow runtime.Object to be encoded as runtime.RawExtension #2786. It
   doesn't appear in the swagger, only in types.go.

—
Reply to this email directly or view it on GitHub
#9633 (comment)
.

Don't know, but added to my massive API/client overhaul list in #8190

SGTM

On Fri, Jun 19, 2015 at 10:52 PM, Brian Grant notifications@github.com
wrote:

Don't know, but added to my massive API/client overhaul list in #8190
#8190

—
Reply to this email directly or view it on GitHub
#9633 (comment)
.

We would use the List type if we implemented watch of multiple kinds #1685

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

Prevent issues from auto-closing with an /lifecycle frozen comment.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or @fejta.
/lifecycle stale

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or @fejta.
/lifecycle rotten
/remove-lifecycle stale

/remove-lifecycle rotten
/lifecycle frozen

Our typical answer to an end user need for bulk creation is to recommend that they use a controller (or operator), right?

How to do bulk action using a controller, Creating one CR will trigger multiple CR creations.