It seems to me that the blueprint serial-ports 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" ). 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."  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.  nova bp serial-ports; https://github.com/openstack/nova-specs/blob/master/specs/juno/implemented/serial-ports.rst  libvirt driver; return only first port; https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L2518  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