OK, so I tried setting `openstack_use_bastion: True`. Servers were
provisioned OK. Public IP addresses were only applied to the infra and
dns nodes (not master).
But the inventory/hosts file that gets auto-generated by this process
still contains the "public" hostnames that can't be reached, even if put
into DNS. Also, I expected to see a bastion node, but none was created.
I find the docs for this a bit baffling. Is there anyone on this list
who was involved with creating this who can help get this straight?
On 04/01/18 23:13, Joel Pearson wrote:
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 <http://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 <[email protected]
<mailto:[email protected]>> 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 <[email protected]
<mailto:[email protected]>> 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
[email protected]
<mailto:[email protected]>
http://lists.openshift.redhat.com/openshiftmm/listinfo/users
_______________________________________________
users mailing list
[email protected]
<mailto:[email protected]>
http://lists.openshift.redhat.com/openshiftmm/listinfo/users
_______________________________________________
users mailing list
[email protected]
http://lists.openshift.redhat.com/openshiftmm/listinfo/users
