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.

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].


[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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to