I have not digested all your ideas today, but here's my one requirement: I
want a simple, small-N set of commands that can set up a replciation
controller, pods, and service. It needs to be dead simple for simple use
cases and for building tests around.

On Thu, Oct 9, 2014 at 2:40 PM, bgrant0607 notifications@github.com wrote:

The run operation is not being implemented in the new kubectl command, as
discussed in #1325
#1325. This is an
alternative approach.

Configuration generation was discussed in #1007
#1007. kubecfg
run could be replaced by this approach, plus perhaps helpers in kubectl
(e.g., something that converts arbitrary command-line args to flat json
fields).

Parameters to kubecfg's run operation could be expressed as JSON:

{
"simpleServiceName": "frontend",
"image": "brendanburns/php-redis",
"replicas": 3,
"ports": [{"containerPort": 80, "servicePort": 8000}]
}

This spec could be expanded by a program, which would generate the
corresponding pod template, replication controller, and service objects.
This translation would occur as part of a more general configuration
generation process (#1694
#1694).

/cc @ghodss https://github.com/ghodss

Reply to this email directly or view it on GitHub
#1695.

Well, even without run, 2 commands is sufficient. That could easily be scripted or wrapped with a library, if it's even worth it.

I am fine with 2 commands. what I don't want is

• write a json file
• run a command
• write another file
• run another command
• write a third damned json file
• run a command

On Thu, Oct 9, 2014 at 10:16 PM, bgrant0607 notifications@github.com
wrote:

Well, even without run, 2 commands is sufficient. That could easily be
scripted or wrapped with a library, if it's even worth it.

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

With the above proposal, a human would have to write at most 1 file, and not any file if we provided a way to generate the json. The number of commands required would depend on the amount of tooling/scripting we provided.

That said, a library of test utility/helper functions would be useful, and something like Run could go in such a library. It could also be implemented as a contrib script.

Run is not a primitive.

ACK that run is not a primitive, but we should make useful tools that cover
common use cases simply.

On Thu, Oct 9, 2014 at 11:14 PM, bgrant0607 notifications@github.com
wrote:

With the above proposal, a human would have to write at most 1 file, and
not any file if we provided a way to generate the json. The number of
commands required would depend on the amount of tooling/scripting we
provided.

That said, a library of test utility/helper functions would be useful, and
something like Run could go in such a library. It could also be implemented
as a contrib script.

Run is not a primitive.

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

For further inspiration, a comparison with Fig: https://gist.github.com/proppy/8e714bf41b6b0978ab0e#fig2kube

/cc @proppy @smarterclayton

I'm happy for kubectl to be able to invoke this directly (ideally as some kind of plugin, at least eventually), though it should also be possible to just dump the generated configs, as discussed in #1905.

I like the idea of pluggable transformation steps at some point - an example I was talking about today with someone was taking a pod generated by Podex and then transforming that into an openshift deployment config and image repository (find the docker repository the pod names, import it into openshift, then turn the pod template / replication controller into a deployment config and point to the image repository). Encouraging multiple step transformation / generation via plugins or other community ecosystem tools seems extremely positive, but it does potentially lead to more support issues.

@smarterclayton Let's discuss pluggability/composability in #1905.

Initial concrete proposal (feel free to bikeshed on the name, though I'm assuming we rename service to something more appropriate):

type UServiceSpec struct {
    ServiceSpec `json:",inline"`
    Count int `json:"count"`
    PodSpec `json:",inline"`
}

If/when we add additional fields to replicationController, as discussed in #3058, they should be bundled into a struct that can be inlined here (except selector, which would collide with the selector from ServiceSpec, though maybe the service reorg discussed in #2585 will also make that easy to avoid).

With aggressive defaulting, propagation of common metadata, and support for json on the command line as suggested in #3233, this could enable fairly simple configurations while including much of the power of the API in a maintainable way.

For example:

kubectl create uservice --app=guestbook count:3 containers:'[{image:brendanburns/redis-slave}]'

The command-line arguments could be mapped to the generator schema in a generic way.

Yes, the containers list is a little ugly, but having dealt with a system where I had to learn different syntaxes and schemas and default behaviors for multiple configuration DSLs and CLIs, as well as the API, I'd much prefer to just learn essentially one schema for object details.

We could also add an optional image field to the above to further simplify the trivial case of one container with no other parameters, while preserving the ability to use the full PodSpec if desired.

I could also imagine an all-in-one API synthetic "macro" control resource that would perform this expansion, rather than doing it on the client side, but we may not want to bite that off yet.

After deploying the microservice, if a user wanted to add another replicationController, such as for a canary, it should be straightforward, with the newly proposed kubectl commands, to add labels to the existing pods and replication controller, and then create the new one under the same service. They'd then use the label-selector-based multi-object kubectl commands to manage the whole constellation of objects.

With some reflection, I think the following could be made to work, without adding an image field:

kubectl create uservice --app=guestbook count:3 image:brendanburns/redis-slave

I'd be ok if the initial implementation weren't fully generic, but I don't want to start with CLI syntax that isn't extensible to the full realization.

Initial version of run-container is in. There are various improvements we could make (e.g., integrating podex, multi-container pods), but let's capture those in other issues and in cli-roadmap.md.