Hi Tim, Yes, I only discovered what the basion setting did by looking at the heat template, as I was going to try and remove the need for the bastion by myself.
I found this line in the heat template: https://github.com/openshift/openshift-ansible-contrib/blob/master/roles/openstack-stack/templates/heat_stack.yaml.j2#L75 I don't know what provider_network does. But you might want to grep around the repo chasing down those settings to see if it suits your purposes. It seems a bit undocumented. In regards to creating private floating ip's, this is what we did for our on-premise openstack, because we wanted to have floating ip's that allowed other computers outside the openstack network to be able connect to individual servers. I don't know what sort of privileges you need to run this command, so it might not work for you. openstack network create --external --provider-physical-network flat --provider-network-type flat public openstack subnet create --network public --allocation-pool start=10.2.100.1,end=10.2.100.254 --dns-nameserver 10.2.0.1 --gateway 10.2.0.1 --subnet-range 10.2.0.0/16 public Instead of public, you could call it something else. So the end result of that command was that when openshift ansible asked for a floating ip, we'd get an IP address in the range of 10.2.100.1-254. Hope it helps. Thanks, Joel On Fri, Jan 5, 2018 at 8:18 AM Tim Dudgeon <tdudgeon...@gmail.com> wrote: > Joel, > Thanks for that. > I had seen this but didn't really understand what it meant. > Having read through it again I still don't! > I'll give it a try tomorrow and see what happens. > > As for the warning about scaling up/down then yes, that is a big concern. > That's the whole point of getting automation in place. > So if anyone can shed any light on this then please do so! > > Could you explain more about 'an alternative is to create a floating ip > range that uses private non-routable ip addressees'? > > > On 04/01/18 20:17, Joel Pearson wrote: > > I had exactly the same concern and I discovered that inside the heat > template there is a bastion mode, which once enabled it doesn’t use > floating ip’s any more. > > Have a look at > https://github.com/openshift/openshift-ansible-contrib/blob/master/playbooks/provisioning/openstack/advanced-configuration.md > > I think you want openstack_use_bastion: True but I am yet to test it out > so I’d recommend checking the heat template to see if it does what I think > it does. > > At the bottom of that advanced page it mentions that in bastion mode scale > up doesn’t work for some reason, so I don’t know if that matters for you. > > Otherwise an alternative is to create a floating ip range that uses > private non-routable ip addressees. That’s what we’re using in our > on-premise OpenStack. But only because we hadn’t discovered the bastion > mode at the time. > > Hope that helps. > On Fri, 5 Jan 2018 at 4:10 am, Tim Dudgeon <tdudgeon...@gmail.com> wrote: > >> I hope this is the right place to ask questions about the >> openshift/openshift-ansible-contrib GitHub repo, and specifically the >> playbooks for installing OpenShift on OpenStack: >> >> https://github.com/openshift/openshift-ansible-contrib/tree/master/playbooks/provisioning/openstack >> If not then please redirect me. >> >> By following the instructions in that link I successfully ran a basic >> deployment that involved provisioning the OpenStack servers and the >> deploying OpenShift using the byo config.yaml playbook. But in doing so >> it's immediately obvious that this approach is not really viable as >> public IP addresses are assigned to every node. It should only be >> necessary to have public IP addresses for the master and the >> infrastructure node hosting the router. >> >> My expectation is that the best way to handle this would be to: >> >> 1. provision the basic openstack networking environment plus a bastion >> node from outside the openstack environment >> 2. from that bastion node provision the nodes that will form the >> OpenShift cluster and deploy OpenShift to those. >> >> Are there any examples along those lines? >> >> >> _______________________________________________ >> 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 >
_______________________________________________ users mailing list users@lists.openshift.redhat.com http://lists.openshift.redhat.com/openshiftmm/listinfo/users
