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