On Tue, Sep 13, 2016 at 12:53:41PM +0100, Derek Higgins wrote: > On 9 September 2016 at 16:38, Paul Belanger <pabelan...@redhat.com> wrote: > > Greetings, > > > > I would like to start the discussions around the removal of the bastion host > > that sits in front of tripleo-test-cloud-rh1. It is my understanding, all > > traffic from tripleo-test-cloud-rh1 flows through this linux box. Obviously > > this is problematic for a public cloud. > > > > I currently do not know the history of the bastion host, I am hoping this > > thread > > will start discussions around it. > > > > However, my personal preference is to remove the bastion from the pipeline > > between internet and tripleo-test-cloud-rh1. My main objection to the host, > > is > > the fact we do packet filtering of traffic flowing between the internet and > > tripleo-test-cloud-rh1. > > Would it be enough to simply remove the traffic filtering? or are > there other problems you are hoping to get rid of? > I'm hoping to remove it so we don't have to worry about managing it. Today, it exists for a reason (which I am still trying to understand). As I understand today, it is used as a jump box to access some resource in tripleo-test-cloud-rh1, assuming the controller and compute nodes. But is that all?
When things are working, there usually isn't problems. However, when problems occur, it is another box that we have to loop into to trace outbound connections. I think the most recent issues with DNS were a result of something throttling connections? > > > > Ideally tripleo-test-cloud-rh1 will simply have an unfiltered network drop > > on > > the public web, this is how we do it today with the infracloud in > > #openstack-infra. > > > > This will avoid the need to gain access to a private server (bastion) and > > need > > to manipulate networking traffic. > > > > I'd like for us to try and establish a time frame to make this happen too. > > I don't know how much work this would be and what problems we would > hit, historically the upstream tripleo team have been hands off when > it comes to this box(and the rack switch), from our point of view we > use it as a jump host to get to the other hosts on which openstack > runs. And all outside traffic goes through it, I suppose the > alternative would be to route the traffic directly to the overcloud > controller. > Yes, I think that would be the ideal setup. Removing any unmanaged linux systems between tripleo-test-cloud-rh1 and the internet is the goal. This give tripleo move control of the network and 1 less thing to depend on. > We should be moving all our cloud usage onto RDO-Cloud some day, we > should probably try and first get a timeline for when we are moving > onto RDO-Cloud, if that is coming up soon perhaps we can just wait at > this situation goes away. > Pushing it off is one option, however I am offering up bandwidth to support this effort. Last I have heard RDO Cloud is still 3-6 months away. > > > > --- > > Paul > > > > __________________________________________________________________________ > > OpenStack Development Mailing List (not for usage questions) > > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev