Provide (remote) access to overcloud services

Bug #1564946 reported by Adam Young
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
tripleo-quickstart
Won't Fix
Wishlist
Unassigned

Bug Description

Our current quickstart deployments leave the overcloud largely inaccessible. We need an easy path from "deploy using quickstart" to "accessing overcloud services" that doesn't involve manually sshing into the undercloud.

Revision history for this message
Adam Young (ayoung) wrote :

@halcyondude suggested in #55:

    Do something similar to: redhat-openstack/khaleesi@0f5197f - This adds aliases to ssh.config.ansible to create/nuke SSH tunnels that map local ports --> :80 on the undercloud. Add one for overcloud (if deployed). This would make it simple for a new user (or anyone) to access the dashboard via a local port.

My take
The overcloud should be exposed to people other than the original developer. The ssh tunnel approach makes that hard to collaborate. Suggest that we add an inactive interface for the external network on the controller that can be activated after the deploy is completed.

Revision history for this message
Adam Young (ayoung) wrote :

From the stack account on baremetal I can run:

cat external.xml
  <interface type='bridge'>
      <source bridge='brext'/>
      <target dev='tap0'/>
      <model type='virtio'/>
    </interface>

virsh attach-device control_0 external.xml

On the VM I now see:

11: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
    link/ether 52:54:00:63:70:56 brd ff:ff:ff:ff:ff:ff

running

sudo ifup eth1

 reports a failure, but afterwards the interface seems to be up

John Trowbridge (trown)
Changed in tripleo-quickstart:
importance: Undecided → Wishlist
status: New → Triaged
Revision history for this message
Adam Young (ayoung) wrote :

Note that I can access them from my laptop using:

sshuttle -e "ssh -F $HOME/.quickstart/ssh.config.ansible" -r undercloud -v 10.149.2.0/24

But that does not let other people work against the deployment. Undercloud controller should be on a public network, if not by default, than by a configurable option.

Revision history for this message
John Trowbridge (trown) wrote :

We have the sshuttle and proxy methods documented[1], but do not intend on implementing any feature for this at this time.

If there is interest in implementing this, I am not opposed, but it is not a priority for the tripleo-quickstart team at this time.

[1] https://github.com/openstack/tripleo-quickstart/blob/master/doc/source/accessing-overcloud.rst

Changed in tripleo-quickstart:
status: Triaged → Won't Fix
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.