Add a router command to install / check routers

[smarterclayton]

@deads2k @derekwaynecarr - the first commit here cleans up the experimental
commands to share a lot more logic with cli, and unifies the factories. Please
review your respective commands (if you have good test coverage, you shouldn't
worry... :))

@pweil- see the second commit for steps to generate the router on the fly.

[smarterclayton]

@sosiouxme may also be something you're interested in - regarding the "diagnostic" check discussion, this would be an administrative command that could have checks for the current routers and provide higher level setup. There would be an equivalent command for the registry or other shared components that are slightly more involved than templates.

[smarterclayton]

[test]

[openshift-bot]

continuous-integration/openshift-jenkins/test SUCCESS (https://ci.openshift.redhat.com/jenkins/job/test_pull_requests_openshift3/1121/)

[pweil-]

Excellent. I have an f5 branch that introduces a second type of router that will be a good test case for the command.

[sosiouxme]

When you say "type" you probably mean "image name" right? Or at least partial image name...

Would like it to be clear that this is not just something from a list of tokens somewhere but actually feeds directly into which image is deployed in the container.

[pweil-]

@sosiouxme Here is my interpretation of the type arg: the router type and image are related but not the same thing. In the plugin architecture we have a router infrastructure command (openshift-router) that is expected to be in the router image as the entry point. The openshift-router command is what creates the plugin to communicate with the underlying implementation. It currently supports only one type, the template router. When more types are supported we will pass the type to openshift-router so it knows what config is required and which plugin to create.

So for example, you could create a router with -type template -image apache. The command would start a pod with the specified image, specify the openshift-router command with the required type/config, the command would start the plugin.

It's all done manually today in the docker images but these can be passed as commands in the generated pod template:

ENTRYPOINT ["/usr/bin/openshift-router", "--template=/var/lib/haproxy/conf/haproxy-config.template", "--reload=/var/lib/haproxy/reload-haproxy"]

[smarterclayton]

Actually - type is the name of the image. So if we have two ootb images, "origin-haproxy-router" and "origin-f5-integration", you can say --type=f5-integration and it will use "origin-f5-integration"

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

•           bulk := configcmd.Bulk{
  

•               Factory: f.Factory,
  

•               Command: cmd,
  

•               After:   configcmd.NewPrintNameOrErrorAfter(out, os.Stderr),
  

•           }
  

•           if errs := bulk.Create(list, namespace); len(errs) != 0 {
  

•               os.Exit(1)
  

•           }
  

•           return
  

•       }
  

•       glog.Infof("Router %q service exists", name)
  

•   },
  

• }

• cmd.Flags().StringVar(&cfg.Type, "type", "haproxy-router", "The type of
  router to use - if you specify --images this flag may be ignored.")

@sosiouxme Here is my interpretation of the type arg: the router type and
image are related but not the same thing. In the plugin architecture we
have a router infrastructure command (openshift-router) that is expected
to be in the router image as the entry point. The openshift-router
command is what creates the plugin to communicate with the underlying
implementation. It currently supports only one type, the template router.
When more types are supported we will pass the type to openshift-router
so it knows what config is required and which plugin to create.

So for example, you could create a router with -type template -image apache. The command would start a pod with the specified image, specify
the openshift-router command with the required type/config, the command
would start the plugin.

It's all done manually today in the docker images but these can be passed as
commands in the generated pod template:

ENTRYPOINT ["/usr/bin/openshift-router", "--template=/var/lib/haproxy/conf/haproxy-config.template", "--reload=/var/lib/haproxy/reload-haproxy"]

---

Reply to this email directly or view it on GitHub:
https://github.com/openshift/origin/pull/1043/files#r24933624

[sosiouxme]

Nice description :)

I'm sure users would also like to specify which host(s) the router(s) end up on. We can do that now, right?

This would make --replicas kind of redundant because you obviously want one per host.

[smarterclayton]

We can assign pods to hosts... but it's not a good idea. I think this would be a zone thing ("infrastructure zone") rather than a named host. You don't get the benefit of being able to ballistically decommission an infra node otherwise.

[smarterclayton]

This is now ready for final review in "alpha" state for beta2 - it's capable of generating a router config with credentials and checking whether one is already installed. Updated test-cmd and test-end-to-end.

[smarterclayton]

[test]

[smarterclayton]

[merge]

[openshift-bot]

continuous-integration/openshift-jenkins/merge SUCCESS (https://ci.openshift.redhat.com/jenkins/job/merge_pull_requests_openshift3/988/) (Image: devenv-fedora_852)

[openshift-bot]

Evaluated for origin up to fbfd171