From Fedora Project Wiki
(Background)
(Deploy questions)
Line 16: Line 16:
 
== Deploy questions ==
 
== Deploy questions ==
  
* OpenShift Origin or OpenShift Container platform?
+
1. OpenShift Origin or OpenShift Container platform?
* Install to vms or bare metal?
+
OpenShift Container Platform was decided upon due to the scale and complexity of the system and the constant churn of the upstream project, using OCP will give us bugfixes and security updates without the rapid lifecycle.
* Atomic host or Normal?
+
 
* RHEL or Fedora?
+
2. Install to vms or bare metal?
* How many: controllers, nodes, routers?
+
Virtual Machines - Having read Red Hat Reference Architectures and speaking with the OpenShift Online Operations Team (openshift.com), virtual machines are perfectly fine.
* Storage? NFS? gluster?
+
 
* Databases: in or outside?
+
3. Atomic host or Normal?
* Setup things with ansible? what level? just the OpenShift? Any/all apps? Changing things like replicants?
+
RHEL Atomic Host
* Keep proxy network haproxy -> openshift apps?  
+
 
 +
4. RHEL or Fedora?
 +
RHEL (mostly as a side effect of the choice for OCP vs Origin, OCP is only officially supported on RHEL)
 +
 
 +
5. How many: controllers, nodes, routers?
 +
3 Masters, 3 Nodes, 3 Infra Nodes (Routers and Registries on Infra Nodes)
 +
 
 +
6. Storage? NFS? gluster?
 +
 
 +
7. Databases: in or outside?
 +
Depends on load and performance needs. Should always default to database inside the OpenShift cluster, move to external if/when necessary.
 +
 
 +
8. Setup things with ansible? what level? just the OpenShift? Any/all apps? Changing things like replicants?
 +
Ansible literally everything, the OpenShift Online Operations Team does this and recommended it.
 +
 
 +
9. Keep proxy network haproxy -> openshift apps?
  
 
== Policy Questions ==  
 
== Policy Questions ==  

Revision as of 14:24, 10 May 2017

OpenShift in Fedora Infrastructure

Background

We want to stand up at least a proof of concept OpenShift instance in Fedora infrastucture. There's a number of reasons for this, inclusing (but not limited to):

  • A chance to stay on the leading edge of tech
  • Ability to deploy things that are expecting to be deployed in OpenShift
  • Allow us to change/improve our deployment workflow -- shorten fix -> delivery time
  • Save resources by moving applications into pods instead of vm's.
  • Help dogfood software our primary sponsor makes and give them feedback.
  • Reduce required sysadmin/ops cycles for application deployment/updating.

Outstanding questions

Deploy questions

1. OpenShift Origin or OpenShift Container platform? OpenShift Container Platform was decided upon due to the scale and complexity of the system and the constant churn of the upstream project, using OCP will give us bugfixes and security updates without the rapid lifecycle.

2. Install to vms or bare metal? Virtual Machines - Having read Red Hat Reference Architectures and speaking with the OpenShift Online Operations Team (openshift.com), virtual machines are perfectly fine.

3. Atomic host or Normal? RHEL Atomic Host

4. RHEL or Fedora? RHEL (mostly as a side effect of the choice for OCP vs Origin, OCP is only officially supported on RHEL)

5. How many: controllers, nodes, routers? 3 Masters, 3 Nodes, 3 Infra Nodes (Routers and Registries on Infra Nodes)

6. Storage? NFS? gluster?

7. Databases: in or outside? Depends on load and performance needs. Should always default to database inside the OpenShift cluster, move to external if/when necessary.

8. Setup things with ansible? what level? just the OpenShift? Any/all apps? Changing things like replicants? Ansible literally everything, the OpenShift Online Operations Team does this and recommended it.

9. Keep proxy network haproxy -> openshift apps?

Policy Questions

  • All rpms?
  • Trigger builds from git? Just some branches?
  • Does prod vs stg vs dev distrinction exist anymore?
  • Do freezes exist anymore?
  • whats the workflow?

git commit upstream -> build -> test -> deploy (slowly) ? git commits upstream on release branch -> build -> test -> deploy (slowly)? new rpm package -> build -> test -> deploy (slowly)?

  • CI? when and where?
  • "alive tests" ?
  • what monitoring do we do on instances/apps?

Initial apps

  • what initial apps would be good to move to it?
    • I'd be interested in looking at blockerbugs or taskotron as candidates to move to openshift (tflink)