RFC: OKD4 Roadmap Draft

[Christian Glombek]

The OKD4 roadmap is currently being drafted here:

https://hackmd.io/Py3RcpuyQE2psYEIBQIzfw

There was an initial discussion on it in yesterday's WG meeting, with some feedback given already.

I have updated the draft and am now calling for comments for a final time, before a formal

Call for Agreement shall follow at the beginning of next week on the OKD WG Google group list.

Please add your comments before Monday. Thank you.

Christian Glombek

Associate Software Engineer

Red Hat GmbH

cglo...@redhat.com

Red Hat GmbH, http://www.de.redhat.com/, Sitz: Grasbrunn, Germany,
Handelsregister: Amtsgericht München, HRB 153243,
Geschäftsführer: Charles Cachera, Michael O'Neill, Tom Savage, Eric Shander

[Dusty Mabe]

On Wednesday, August 14, 2019 at 12:26:54 PM UTC-4, Christian Glombek wrote:

The OKD4 roadmap is currently being drafted here:

https://hackmd.io/Py3RcpuyQE2psYEIBQIzfw

There was an initial discussion on it in yesterday's WG meeting, with some feedback given already.

I have updated the draft and am now calling for comments for a final time, before a formal

Call for Agreement shall follow at the beginning of next week on the OKD WG Google group list.

Please add your comments before Monday. Thank you.

Looks good. I'm sure lots will change as we go! 

[Michael McCune]

On Wed, Aug 14, 2019 at 12:27 PM Christian Glombek <cglo...@redhat.com> wrote:

The OKD4 roadmap is currently being drafted here:

https://hackmd.io/Py3RcpuyQE2psYEIBQIzfw

There was an initial discussion on it in yesterday's WG meeting, with some feedback given already.

I have updated the draft and am now calling for comments for a final time, before a formal

Call for Agreement shall follow at the beginning of next week on the OKD WG Google group list.

Please add your comments before Monday. Thank you.

i'm not sure if i should add this on the document, but is there any consensus (one way or the other) about the notion of bringing forward the all-in-one work that was done in openshift-ansible for version 3?

i am aware of code ready containers, but i would really like to see us provide the option for a single machine install.

peace o/

 

Christian Glombek

Associate Software Engineer

Red Hat GmbH

cglo...@redhat.com

Red Hat GmbH, http://www.de.redhat.com/, Sitz: Grasbrunn, Germany,
Handelsregister: Amtsgericht München, HRB 153243,
Geschäftsführer: Charles Cachera, Michael O'Neill, Tom Savage, Eric Shander

--
You received this message because you are subscribed to the Google Groups "okd-wg" group.
To unsubscribe from this group and stop receiving emails from it, send an email to okd-wg+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/okd-wg/CAABn9-8khhZ4VmHpKXXogo_kH-50QnR6vZgc525FROA41mxboA%40mail.gmail.com.

[Neal Gompa]

On Fri, Aug 16, 2019 at 10:39 AM Michael McCune <elm...@redhat.com> wrote:

On Wed, Aug 14, 2019 at 12:27 PM Christian Glombek <cglo...@redhat.com> wrote:

The OKD4 roadmap is currently being drafted here:

https://hackmd.io/Py3RcpuyQE2psYEIBQIzfw

There was an initial discussion on it in yesterday's WG meeting, with some feedback given already.

I have updated the draft and am now calling for comments for a final time, before a formal

Call for Agreement shall follow at the beginning of next week on the OKD WG Google group list.

Please add your comments before Monday. Thank you.

i'm not sure if i should add this on the document, but is there any consensus (one way or the other) about the notion of bringing forward the all-in-one work that was done in openshift-ansible for version 3?

i am aware of code ready containers, but i would really like to see us provide the option for a single machine install.

I would personally like to see some kind of all-in-one setup support like in OKD v3. I had made my own inventory for doing this for my personal setups: https://pagure.io/openshift-allinone-deployment-configuration

It helps with playing with these things. :)

--

真実はいつも一つ！/ Always, there's only one truth!

[Clayton Coleman]

On Aug 16, 2019, at 10:39 AM, Michael McCune <elm...@redhat.com> wrote:

On Wed, Aug 14, 2019 at 12:27 PM Christian Glombek <cglo...@redhat.com> wrote:

The OKD4 roadmap is currently being drafted here:

https://hackmd.io/Py3RcpuyQE2psYEIBQIzfw

There was an initial discussion on it in yesterday's WG meeting, with some feedback given already.

I have updated the draft and am now calling for comments for a final time, before a formal

Call for Agreement shall follow at the beginning of next week on the OKD WG Google group list.

Please add your comments before Monday. Thank you.

i'm not sure if i should add this on the document, but is there any consensus (one way or the other) about the notion of bringing forward the all-in-one work that was done in openshift-ansible for version 3?

i am aware of code ready containers, but i would really like to see us provide the option for a single machine install.

It’s possible for someone to emulate much of the install, bootstrap, and subsequent operations on a single machine (the installer isn’t that much code, the bulk of the work is across the operators).  You’d end up copying a fair bit of the installer, but it may be tractable.  You’d need to really understand the config passed to bootstrap via ignition, how the bootstrap script works, and how you would trick etcd to start on the bootstrap machine.  When the etcd operator lands in 4.3, that last becomes easier (the operator runs and configures a local etcd).

Single master / single node configurations are possible, but they will be hard.  Many of the core design decisions of 4 are there to ensure the cluster can self host, and they also require that machines really be members of the cluster.

A simpler, less complex path might be to (once we have OKD proto working) to create a custom payload that excludes the installer, the MCD, and to use ansible to configure the prereqs on a single machine (etcd in a specific config), then emulate parts of the bootstrap script and run a single instance (which in theory should work today).  You might be able to update it.  Someone exploring this would possibly be able to get openshift running on a non coreos control plane, so worth exploring if someone has the time.

peace o/

 

Christian Glombek

Associate Software Engineer

Red Hat GmbH

cglo...@redhat.com

Red Hat GmbH, http://www.de.redhat.com/, Sitz: Grasbrunn, Germany,
Handelsregister: Amtsgericht München, HRB 153243,
Geschäftsführer: Charles Cachera, Michael O'Neill, Tom Savage, Eric Shander

--
You received this message because you are subscribed to the Google Groups "okd-wg" group.
To unsubscribe from this group and stop receiving emails from it, send an email to okd-wg+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/okd-wg/CAABn9-8khhZ4VmHpKXXogo_kH-50QnR6vZgc525FROA41mxboA%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "okd-wg" group.
To unsubscribe from this group and stop receiving emails from it, send an email to okd-wg+un...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/okd-wg/CADE%2BktTuSSUaZZ-vPYkOLHKiojM9%2B5qgQVtV1pS7z7eTcu7jdw%40mail.gmail.com.

[Michael Gugino]

Pretty much already had all of this working here: https://github.com/openshift/openshift-ansible/pull/10898

For single host cluster, I think path of least resistance would be to modify the bootstrap host to not pivot, make it clear it's 'not for production' and we can take lots of shortcuts for someone just looking for an easy, 1-VM openshift api.

I'm most interested in running OKD 4.x on Fedora rather than CoreOS.  I might try to do something with that this weekend as POC.

To view this discussion on the web visit https://groups.google.com/d/msgid/okd-wg/CAH16ShKTveB9F9jaH24ycGLO2KbnHSHkP5T0cYLquumLUEe_BQ%40mail.gmail.com.

--

Michael Gugino

Senior Software Engineer - OpenShift

mgu...@redhat.com
540-846-0304

[Clayton Coleman]

On Aug 16, 2019, at 11:29 AM, Michael Gugino <mgu...@redhat.com> wrote:

Pretty much already had all of this working here: https://github.com/openshift/openshift-ansible/pull/10898

For single host cluster, I think path of least resistance would be to modify the bootstrap host to not pivot, make it clear it's 'not for production' and we can take lots of shortcuts for someone just looking for an easy, 1-VM openshift api.

Does that assume bootstrap machine is “anything”?

I'm most interested in running OKD 4.x on Fedora rather than CoreOS.  I might try to do something with that this weekend as POC.

Thanks

[Michael Gugino]

I'm not sure what you mean 'bootstrap machine is anything'.

Haven't seriously looked into single-host cluster yet, but from a high level, creating the bootstrap node as normal, but not pivoting the API to the 'real' cluster would seem to do some of what we want, if what we want is 'just give me a working API so I can run containers' and not 'all of openshift stuffed into a single host'.

[Michael McCune]

On Fri, Aug 16, 2019 at 10:49 AM Clayton Coleman <ccol...@redhat.com> wrote:

On Aug 16, 2019, at 10:39 AM, Michael McCune <elm...@redhat.com> wrote:

On Wed, Aug 14, 2019 at 12:27 PM Christian Glombek <cglo...@redhat.com> wrote:

The OKD4 roadmap is currently being drafted here:

https://hackmd.io/Py3RcpuyQE2psYEIBQIzfw

There was an initial discussion on it in yesterday's WG meeting, with some feedback given already.

I have updated the draft and am now calling for comments for a final time, before a formal

Call for Agreement shall follow at the beginning of next week on the OKD WG Google group list.

Please add your comments before Monday. Thank you.

i'm not sure if i should add this on the document, but is there any consensus (one way or the other) about the notion of bringing forward the all-in-one work that was done in openshift-ansible for version 3?

i am aware of code ready containers, but i would really like to see us provide the option for a single machine install.

It’s possible for someone to emulate much of the install, bootstrap, and subsequent operations on a single machine (the installer isn’t that much code, the bulk of the work is across the operators).  You’d end up copying a fair bit of the installer, but it may be tractable.  You’d need to really understand the config passed to bootstrap via ignition, how the bootstrap script works, and how you would trick etcd to start on the bootstrap machine.  When the etcd operator lands in 4.3, that last becomes easier (the operator runs and configures a local etcd).

Single master / single node configurations are possible, but they will be hard.  Many of the core design decisions of 4 are there to ensure the cluster can self host, and they also require that machines really be members of the cluster.

thank you for the detailed answer, i'm not sure i understand all of it yet but it sounds like we might be best served by adding the all-in-one goal into the medium or long term to better coincide with a 4.3+ release.

also, i am curious if these details you are talking about (eg bootstrapping and installation) are available in documentation?

my concern is that currently this information /appears/ to only be available by examining the code of the various installer bits, i think it would be a great service to the community if we could publish more documentation about the installation process.

A simpler, less complex path might be to (once we have OKD proto working) to create a custom payload that excludes the installer, the MCD, and to use ansible to configure the prereqs on a single machine (etcd in a specific config), then emulate parts of the bootstrap script and run a single instance (which in theory should work today).  You might be able to update it.  Someone exploring this would possibly be able to get openshift running on a non coreos control plane, so worth exploring if someone has the time.

this /sounds/ reasonable to me, but again i would like to be able to read more about how this bootstrapping and installation process works so that i could better understand how to test and also how to contribute to the work that is happening.

peace o/

[Michael McCune]

On Fri, Aug 16, 2019 at 2:36 PM Kevin Lapagna <4...@gmx.ch> wrote:

>
> On Fri, Aug 16, 2019 at 4:50 PM Clayton Coleman <ccol...@redhat.com> wrote:
>>
>> Single master / single node configurations are possible, but they will be hard. Many of the core design decisions of 4 are there to ensure the cluster can self host, and they also require that machines really be members of the cluster.
>
>

> How about (as alternative) spinning up multiple virtual machines and simulate "the real thing". Sure, that uses lots of memory, but it will nicely show what 4.x is capable of.

my understanding is that this is essentially similar to the current
installer with a libvirt backend as the deployment, at least that's
how it looks when i try to run an installation on a single physical
node with multiple virtual machines.

peace o/

[Clayton Coleman]

Yes. Although as mike notes it may be possible to get this running
with less effort via his route, which is a good alternative for simple
single machine.

>
> peace o/

[Christian Glombek]

Hi everybody,

we can't go ahead with a vote on the roadmap just yet, as we have to await conclusion of the Charter vote, first.

If you have specific suggestions for the roadmap, please add comments on the draft [1] in the meantime

Mz apologies for the delay.

[1] https://hackmd.io/Py3RcpuyQE2psYEIBQIzfw

Christian Glombek

Associate Software Engineer

Red Hat GmbH

cglo...@redhat.com

Red Hat GmbH, http://www.de.redhat.com/, Sitz: Grasbrunn, Germany,
Handelsregister: Amtsgericht München, HRB 153243,
Geschäftsführer: Charles Cachera, Michael O'Neill, Tom Savage, Eric Shander

--
You received this message because you are subscribed to the Google Groups "okd-wg" group.
To unsubscribe from this group and stop receiving emails from it, send an email to okd-wg+un...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/okd-wg/CAH16ShJS4Fe7xtt8hqgxw2Zcj4Hu9-MaTEXhr8e1gqvS8ti70g%40mail.gmail.com.

[Michael Gugino]

Just to follow up on this. I did work on it the weekend before last
as intended. I hoped to get to do more this past weekend, but time
did not avail itself.

Here's where we are:

There's been some changes to terraform, plugins, etc since I was
working on this for RHEL, and there have been corresponding changes in
4.1 and 4.2 branches. I hacked it together enough to deploy a
bootstrap host and a master, as well as parse the igition files and
start services. Everything looked like it should have worked, but
something is wrong with the certificates on the bootstrap host. The
kubectl client is complaining that the server cert of the api is only
valid for <some name> not localhost. Manually editing the kubeconfig
that is on the bootstrap host results then in 'server cert signed by
unknown authority' despite the fact that a CA is embedded in the
kubeconfig.

I'm unsure if RHCOS is doing something to mutate those files after the
ignition payload. I would suspect not, but I'm just not sure how to
recover from these issues.

After a while, things got pretty hacked up. I'm going to go back to
the direction of hacking the installer to provision fedora+userdata vs
having my own terraform files and see if I can make more progress
there.

> --
> You received this message because you are subscribed to the Google Groups "okd-wg" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to okd-wg+un...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/okd-wg/CAH16ShJS4Fe7xtt8hqgxw2Zcj4Hu9-MaTEXhr8e1gqvS8ti70g%40mail.gmail.com.