Re: Modifying existing advanced installation
On Tue, Sep 20, 2016 at 4:07 AM, Lionel Orellanawrote: > Hello > > I want to configure LDAP authentication on my existing cluster. > > Instead of manually modifying the master config file, can I add the new > settings to my Ansible inventory and rerun the config playbook? > Yes, you can update your inventory and re-run Ansible. > Does it know to only apply the new configuration? > It will re-run the entire config playbook. There are some steps that will not be applied automatically (certificate creation, router, registry, logging, metrics), and there are some tasks that may report "changed" when they have not actually modified anything. We are working on improving the roles for better suitability for ongoing configuration management. > Generally speaking, is this the best way to make changes to an existing > cluster? > It is the way that I would recommend, yes. > > Thanks > > Lionel. > > ___ > users mailing list > users@lists.openshift.redhat.com > http://lists.openshift.redhat.com/openshiftmm/listinfo/users > > -- Jason DeTiberus ___ users mailing list users@lists.openshift.redhat.com http://lists.openshift.redhat.com/openshiftmm/listinfo/users
Re: scenarios of entire app in a cluster unavailable
Thank you for info. It it’s useful -- Srinivas Kotaru On 9/20/16, 5:37 AM, "Brenton Leanhardt"wrote: On Mon, Sep 19, 2016 at 6:40 PM, Srinivas Naga Kotaru (skotaru) wrote: > Trying to understand on which scenarios all the instances of an application > running from cluster unavailable? > > > > OS upgrade failure?? > > Openshift upgrade bugs/failures/downtime? The best way to mitigate risks from the first two are to upgrade independent sets of Nodes in batches to prevent downtime in the event of unforeseen problems. This should be rare if there is sufficient monitoring in the environment. In the Origin 1.4, OCP 3.4 timeframe it will be much easier to upgrade batches of Nodes. It's possible today but it takes a little more involvement with the ansible inventory. In large environments with strict maintenance windows it's common to only update a set of Nodes during each window. > > Router failures ?? This is likely the most common source of user-facing downtime. > > Keepalive containers failed?? Unless this event triggered a failover to a pod that was actually in outage I don't think the Keepalive pod failing would cause a user-facing outage. The platform would spawn another. > > Floating IP shared by keepalive container had issues?? If somehow the floating IP was in use by another interface on the network I'm certain bad things would happen. > > VXLAN bug or upgrade caused entire cluster network failure? Catastrophic network failures could indeed cause a major outage. > > Human config error ( what those???) Always. Best avoided by using a tool like Ansible and testing changes in other environments before production. > > > > Is above list accurate? Can we think off any other possible scanarios where > whole application will be down in cluster duet to platform issues? > I would mention downtime caused by load. Anecdotally, this is probably the second most common cause of downtime. It often relates to the human error and lack of monitoring. The more dense the platform operators wish to keep the environment the more rigor is needed for monitoring. This could simply be an error of the pod owner as well. eg, the JVM inside the pod might be online however the application running in the JVM might be throwing out of memory errors due to incorrect assignment of limits. > > > -- > > Srinivas Kotaru > > > ___ > users mailing list > users@lists.openshift.redhat.com > http://lists.openshift.redhat.com/openshiftmm/listinfo/users > ___ users mailing list users@lists.openshift.redhat.com http://lists.openshift.redhat.com/openshiftmm/listinfo/users
Re: Repository of the OpenShift Templates & Catalog of the Origin Docker Images
This information is very valuable. Thx. Next step will be to aggregate what we have for xPaas, iPaas, DevOps ... On Thu, Sep 22, 2016 at 5:13 PM, Clayton Colemanwrote: > There is a plan to but the repo has not been fully sorted out. > > You can see what it might look like here: https://github.com/ > luciddreamz/library > > On Sep 22, 2016, at 10:55 AM, Charles Moulliard > wrote: > > Hi, > > Are the informations/versions about the Origin OpenShift Templates > published on a Web site like Fabric8 did it -> http://fabric8.io/ > manifests/openshift.html ? > > Is there also a catalog of the Origin Docker images available : Catalog of > the Origin Docker Images ? > > Regards, > > Charles > > ___ > users mailing list > users@lists.openshift.redhat.com > http://lists.openshift.redhat.com/openshiftmm/listinfo/users > > ___ users mailing list users@lists.openshift.redhat.com http://lists.openshift.redhat.com/openshiftmm/listinfo/users
Re: Repository of the OpenShift Templates & Catalog of the Origin Docker Images
There is a plan to but the repo has not been fully sorted out. You can see what it might look like here: https://github.com/luciddreamz/library On Sep 22, 2016, at 10:55 AM, Charles Moulliardwrote: Hi, Are the informations/versions about the Origin OpenShift Templates published on a Web site like Fabric8 did it -> http://fabric8.io/manifests/openshift.html ? Is there also a catalog of the Origin Docker images available : Catalog of the Origin Docker Images ? Regards, Charles ___ users mailing list users@lists.openshift.redhat.com http://lists.openshift.redhat.com/openshiftmm/listinfo/users ___ users mailing list users@lists.openshift.redhat.com http://lists.openshift.redhat.com/openshiftmm/listinfo/users
Repository of the OpenShift Templates & Catalog of the Origin Docker Images
Hi, Are the informations/versions about the Origin OpenShift Templates published on a Web site like Fabric8 did it -> http://fabric8.io/manifests/openshift.html ? Is there also a catalog of the Origin Docker images available : Catalog of the Origin Docker Images ? Regards, Charles ___ users mailing list users@lists.openshift.redhat.com http://lists.openshift.redhat.com/openshiftmm/listinfo/users