Open Stack

On Tue, Feb 24, 2015 at 04:19:39PM +0100, Markus Zoeller wrote:
> 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?

So we probably have a bug here, can you at least refer it in launchpad
? We need to see if the problem comes from the code in Nova or a bad
interpretation of the behavior of libvirt or a bug in libvirt.

Please on the report can you also paste the XML when you have a well
connected session on the first port?

> > 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
> > 
> 
> 
> __________________________________________________________________________
> 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