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.

On Mon, Aug 19, 2019 at 3:11 AM Clayton Coleman <ccole...@redhat.com> wrote:
>
> > On Aug 16, 2019, at 10:25 PM, Michael McCune <elm...@redhat.com> wrote:
> >
> >> 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 <ccole...@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.
>
> 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/
>
> --
> 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+unsubscr...@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
Senior Software Engineer - OpenShift
mgug...@redhat.com
540-846-0304

_______________________________________________
dev mailing list
dev@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/dev

Reply via email to