Re: [openstack-dev] [nova] bp serial-ports *partly* implemented?

2015-02-25 Thread Sahid Orentino Ferdjaoui
On Tue, Feb 24, 2015 at 04:19:39PM +0100, Markus Zoeller wrote:
 Sahid Orentino Ferdjaoui sahid.ferdja...@redhat.com wrote on 02/23/2015 
 11:13:12 AM:
 
  From: Sahid Orentino Ferdjaoui sahid.ferdja...@redhat.com
  To: OpenStack Development Mailing List (not for usage questions) 
  openstack-dev@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=1/
 /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-requ...@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-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin

Re: [openstack-dev] [nova] bp serial-ports *partly* implemented?

2015-02-25 Thread Markus Zoeller
Sahid Orentino Ferdjaoui sahid.ferdja...@redhat.com wrote on 02/25/2015 
12:58:30 PM:
 [...]
 
 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?
 
 [...]

I opened bug 1425640: https://bugs.launchpad.net/nova/+bug/1425640


__
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


Re: [openstack-dev] [nova] bp serial-ports *partly* implemented?

2015-02-24 Thread Markus Zoeller
Sahid Orentino Ferdjaoui sahid.ferdja...@redhat.com wrote on 02/23/2015 
11:13:12 AM:

 From: Sahid Orentino Ferdjaoui sahid.ferdja...@redhat.com
 To: OpenStack Development Mailing List (not for usage questions) 
 openstack-dev@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=1/
/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-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [nova] bp serial-ports *partly* implemented?

2015-02-24 Thread Markus Zoeller
Tony Breeds t...@bakeyournoodle.com wrote on 02/21/2015 08:35:32 AM:

 From: Tony Breeds t...@bakeyournoodle.com
 To: OpenStack Development Mailing List (not for usage questions) 
 openstack-dev@lists.openstack.org
 Date: 02/21/2015 08:41 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.
 
 Nope I think you're pretty much correct.  The implementation doesn't
 match the details in the spec.

Thanks Tony for your feedback. I'm still new to nova and it's sometimes
hard for me to grasp the intention of the code.

 Yours Tony.
 
__
 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


__
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


Re: [openstack-dev] [nova] bp serial-ports *partly* implemented?

2015-02-23 Thread Sahid Orentino Ferdjaoui
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.

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.

 [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

__
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


Re: [openstack-dev] [nova] bp serial-ports *partly* implemented?

2015-02-20 Thread Tony Breeds
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.

Nope I think you're pretty much correct.  The implementation doesn't
match the details in the spec.

Yours Tony.


pgp4G3jk2z21t.pgp
Description: PGP signature
__
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