Open Stack

Sahid Orentino Ferdjaoui <sahid.ferdjaoui at redhat.com> wrote on 02/23/2015 
11:13:12 AM:

> From: Sahid Orentino Ferdjaoui <sahid.ferdjaoui at redhat.com>
> To: "OpenStack Development Mailing List (not for usage questions)" 
> <openstack-dev at lists.openstack.org>
> Date: 02/23/2015 11:17 AM
> Subject: Re: [openstack-dev] [nova] bp serial-ports *partly* 
implemented?
> 
> On Fri, Feb 20, 2015 at 06:03:46PM +0100, Markus Zoeller wrote:
> > It seems to me that the blueprint serial-ports[1] didn't implement
> > everything which was described in its spec. If one of you could have a 

> > look at the following examples and help me to understand if these 
> > observations are right/wrong that would be great.
> > 
> > Example 1:
> > The flavor provides the extra_spec "hw:serial_port_count" and the 
image
> > the property "hw_serial_port_count". This is used to decide how many
> > serial devices (with different ports) should be defined for an 
instance.
> > But the libvirt driver returns always only the *first* defined port 
> > (see method "get_serial_console" [2]). I didn't find anything in the 
> > code which uses the other defined ports.
> 
> The method you are referencing [2] is used to return the first well
> binded and not connected port in the domain.

Is that the intention behind the code ``mode='bind'`` in said method?
In my test I created an instance with 2 ports with the default cirros
image with a flavor which has the hw:serial_port_count=2 property. 
The domain XML has this snippet:
    <serial type="tcp">
      <source host="127.0.0.1" mode="bind" service="10000"/>
    </serial>
    <serial type="tcp">
      <source host="127.0.0.1" mode="bind" service="10001"/>
    </serial>
My expectation was to be able to connect to the same instance via both 
ports at the same time. But the second connection is blocked as long 
as the first connection is established. A debug trace in the code shows 
that both times the first port is returned. IOW I was not able to create
a scenario where the *second* port was returned and that confuses me
a little. Any thoughts about this?

> When defining the domain '{hw_|hw:}serial_port_count' are well take
> into account as you can see:
> 
>    https://github.com/openstack/nova/blob/master/nova/virt/libvirt/
> driver.py#L3702
> 
> (The method looks to have been refactored and include several parts
> not related to serial-console)
>
> > Example 2:
> >     "If a user is already connected, then reject the attempt of a 
second
> >     user to access the console, but have an API to forceably 
disconnect
> >     an existing session. This would be particularly important to cope
> >     with hung sessions where the client network went away before the
> >     console was cleanly closed." [1]
> > I couldn't find the described API. If there is a hung session one 
cannot
> > gracefully recover from that. This could lead to a bad UX in horizons
> > serial console client implementation[3].
> 
> This API is not implemented, I will see what I can do on that
> part. Thanks for this.

Sounds great, thanks for that! Please keep me in the loop when 
reviews or help with coding are needed.

> > [1] nova bp serial-ports;
> > 
> > https://github.com/openstack/nova-specs/blob/master/specs/juno/
> implemented/serial-ports.rst
> > [2] libvirt driver; return only first port; 
> > 
> > https://github.com/openstack/nova/blob/master/nova/virt/libvirt/
> driver.py#L2518
> > [3] horizon bp serial-console; 
> >     https://blueprints.launchpad.net/horizon/+spec/serial-console
> > 
> > 
> > 
__________________________________________________________________________
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: 
OpenStack-dev-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>