[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Command to install / check routers



Full disclosure, Brian Grant made some comments this weekend that make it sound like he still wants a dynamic configuration mechanism, but I see this as a medium or long term thing and not short term.

https://github.com/GoogleCloudPlatform/kubernetes/issues/4673#issuecomment-75359220

----- Original Message -----
> From: "Clayton Coleman" <ccoleman redhat com>
> To: "Luke Meyer" <lmeyer redhat com>
> Cc: "Openshift Dev" <dev lists openshift redhat com>
> Sent: Monday, February 23, 2015 9:55:34 AM
> Subject: Re: Command to install / check routers
> 
> Yes.  The gotcha is of course that secrets and config overlap a bit - for
> simple components we'll just give a kubeconfig, but the image needs to be
> configured to use it.
> 
> I think it's important for end users to know that a registry and a router
> *require* auth to function correctly, so I suspect this will always be a
> part of this flow.  For instance, if you give us credentials that don't have
> sufficient access for the base router use case (ability to see routes,
> services, and endpoints) we should warn you.
> 
> ----- Original Message -----
> > Is the plan to generalize this pattern once we have Secrets? We will
> > probably
> > have all kinds of infrastructure bits that need to be deployed with the
> > right certs/keys/config to be addressed by the master, access the master,
> > and conform to user needs. The next sort of obvious ones would be
> > authentication servers and admission control plugins...
> > 
> > ----- Original Message -----
> > From: "Clayton Coleman" <ccoleman redhat com>
> > To: "Openshift Dev" <dev lists openshift redhat com>
> > Sent: Thursday, February 19, 2015 10:28:20 PM
> > Subject: Command to install / check routers
> > 
> > Now that more of the authentication and authorization pieces are
> > integrated,
> > we wanted to make setting up and configuring bits of the OpenShift
> > infrastructure easier.  The first step is
> > https://github.com/openshift/origin/pull/1043 which adds a new command:
> > 
> >   openshift ex router
> > 
> > (ex is for experimental, i.e. an alpha command).
> > 
> > This is an admin level command that can check for an installed router,
> > install one for you, help you templatize your routers (if you want to tweak
> > them), and load the necessary credentials for the router into the
> > definition.
> > 
> > To check your router, run:
> > 
> >   $ openshift ex router
> > 
> > It will look for a service called "router" in the default (or current)
> > namespace.  If it doesn't find one, it'll tell you:
> > 
> >   $ openshift ex router
> > 
> > If you pass the '--create' flag OpenShift will generate a deployment config
> > and a service for you based on a few flags - see the help for more details.
> > You need to give the router the credentials it will use to authenticate to
> > the master - you can do that by passing --credentials with a path to a
> > .kubeconfig file.  The "openshift-client" kubeconfig has the right level of
> > access.  To see what would be generated pass "-o yaml" (same as you would
> > to
> > osc get):
> > 
> >   $ openshift ex router
> >   --credentials="<certdir>/openshift-client/.kubeconfig" -o yaml
> >   .... yaml describing the router
> > 
> > If you like what you see, replace `-o yaml` with `--create` (or redirect it
> > to a file, edit it, then cat it to `osc create -f -`):
> > 
> >   $ openshift ex router
> >   --credentials="<certdir>/openshift-client/.kubeconfig" --create
> >   router
> >   router
> > 
> > That's a service and a deployment config:
> > 
> >   $ osc describe dc router
> > 
> > The router will spin up and create a pod.  Because it's a deployment
> > config,
> > you can now roll out config changes or scale it up.
> > 
> > You can also create named routers by giving `openshift ex router` an
> > argument:
> > 
> >   $ openshift ex router myrouter-west --replicas=2 ...
> > 
> > The router command is just a simple generator right now - as we have more
> > pieces of the infrastructure in place you should see more sophistication
> > (like assigning your routers to an infrastructure zone, or defining
> > shards).
> > 
> > Up next - the registry.
> > 
> > _______________________________________________
> > dev mailing list
> > dev lists openshift redhat com
> > http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
> > 
> 
> _______________________________________________
> dev mailing list
> dev lists openshift redhat com
> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
> 


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]