Re: [vdsm] Future of Vdsm network configuration - Thread mid-summary

[Dan Kenigsberg]

On Tue, Nov 27, 2012 at 03:24:58PM -0500, Alon Bar-Lev wrote:
 
 

  
   Management interface configuration is a separate issue.

But it is an important issue that has to be discussed..

   If we perform changes of this interface when host is in maintenance
   we reduce the complexity of the problem.
  
   For your specific issue, if there are two interfaces, one which is
   up during boot and one which is down during boot, there is no
   problem to bond them after boot without persisting configuration.
  
  how would you know which bond mode to use? which MTU?
 
 I don't understand the question.

I think I do: Alon suggests that on boot, the management interface would
not have bonding at all, and use a single nic. The switch would have to
assume that other nics in the bond are dead, and will use the only one
which is alive to transfer packets.

There is no doubt that we have to persist the vlan tag of the management
interface, and its MTU, in the extremely rare case where the network
would not alow Linux's default of 1500.

Dan.
___
vdsm-devel mailing list
vdsm-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel

Re: [vdsm] Future of Vdsm network configuration - Thread mid-summary

[Itamar Heim]

On 11/28/2012 03:53 AM, Dan Kenigsberg wrote:

On Tue, Nov 27, 2012 at 03:24:58PM -0500, Alon Bar-Lev wrote:







Management interface configuration is a separate issue.


But it is an important issue that has to be discussed..


If we perform changes of this interface when host is in maintenance
we reduce the complexity of the problem.

For your specific issue, if there are two interfaces, one which is
up during boot and one which is down during boot, there is no
problem to bond them after boot without persisting configuration.


how would you know which bond mode to use? which MTU?


I don't understand the question.


I think I do: Alon suggests that on boot, the management interface would
not have bonding at all, and use a single nic. The switch would have to
assume that other nics in the bond are dead, and will use the only one
which is alive to transfer packets.

There is no doubt that we have to persist the vlan tag of the management
interface, and its MTU, in the extremely rare case where the network
would not alow Linux's default of 1500.


i was thinking manager may be using jumbo frames to talk to host, and 
host will have an issue with them since it is set to 1500 instead of 8k.

jumbo frames isn't a rare case.

as for bond, are you sure you can use a nic in a non bonded mode for all 
bond modes?


next, what if we're using openvswitch, and you need some flow 
definitions for the management interface?

___
vdsm-devel mailing list
vdsm-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel

Re: [vdsm] Future of Vdsm network configuration - Thread mid-summary

[Itamar Heim]

On 11/28/2012 05:34 AM, Roni Luxenberg wrote:

- Original Message -

From: Itamar Heim ih...@redhat.com
To: Dan Kenigsberg dan...@redhat.com
Cc: Alon Bar-Lev alo...@redhat.com, VDSM Project Development
vdsm-devel@lists.fedorahosted.org, Yaniv Kaul
yk...@redhat.com
Sent: Wednesday, November 28, 2012 11:01:35 AM
Subject: Re: [vdsm] Future of Vdsm network configuration - Thread
mid-summary

On 11/28/2012 03:53 AM, Dan Kenigsberg wrote:

On Tue, Nov 27, 2012 at 03:24:58PM -0500, Alon Bar-Lev wrote:







Management interface configuration is a separate issue.


But it is an important issue that has to be discussed..


If we perform changes of this interface when host is in
maintenance
we reduce the complexity of the problem.

For your specific issue, if there are two interfaces, one
which
is
up during boot and one which is down during boot, there is no
problem to bond them after boot without persisting
configuration.


how would you know which bond mode to use? which MTU?


I don't understand the question.


I think I do: Alon suggests that on boot, the management
interface
would
not have bonding at all, and use a single nic. The switch would
have to
assume that other nics in the bond are dead, and will use the
only
one
which is alive to transfer packets.

There is no doubt that we have to persist the vlan tag of the
management
interface, and its MTU, in the extremely rare case where the
network
would not alow Linux's default of 1500.


i was thinking manager may be using jumbo frames to talk to host,
and
host will have an issue with them since it is set to 1500 instead
of
8k.
jumbo frames isn't a rare case.

as for bond, are you sure you can use a nic in a non bonded mode
for
all
bond modes?




all bond modes have to cope with a situation where only a single nic is active 
and the rest are down,
so one can boot with a single active nic and only activate the rest and promote 
to the desired bond mode upon getting the full network configuration from the 
manager.


of course they need to handle single active nic, but iirc, the host must 
be configured for a matching bond as the switch.
i.e., you can't configure the switch to be in bond, then boot the host 
with a single active nic in a non bonded config





Changing the master interface mtu for either vlan or bond is required
for management interface and non management interface.

So the logic would probably be set max(mtu(slaves)) regardless it is
management interface or not.

I discussed this with Livnat, if there are applications that access
the master interface directly we may break them, as the destination
may not support non standard mtu.

This is true in current implementation and any future implementation.

It is bad practice to use the master interface directly (mixed
tagged/untagged), better to define in switch that untagged
communication belongs to vlanX, then use this explicit vlanX at
host.


next, what if we're using openvswitch, and you need some flow
definitions for the management interface?


I cannot answer that as I don't know openvswitch very well and don't
know what flow definitions are, however, I do guess that it has
non persistent mode that can effect any interface on its control. If
you like I can research this one.


you mainly need OVS for provisioning VM networks so here too you can completely 
bypass OVS during boot and only configure it in a transactional manner upon 
getting the full network configuration from the manager.

a general question, why would you need to configure VM networks on the host 
(assuming a persistent cached configuration) upon boot if it cannot talk to the 
manager?
after-all, in this case no resources would be scheduled to run on this host 
until connection to the manager is restored and up-to-date network 
configuration is applied.

thanks,
Roni



___
vdsm-devel mailing list
vdsm-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel

Re: [vdsm] Future of Vdsm network configuration - Thread mid-summary

[Alon Bar-Lev]

- Original Message -
 From: Itamar Heim ih...@redhat.com
 To: Roni Luxenberg rluxe...@redhat.com
 Cc: Alon Bar-Lev alo...@redhat.com, VDSM Project Development 
 vdsm-devel@lists.fedorahosted.org
 Sent: Wednesday, November 28, 2012 2:01:45 PM
 Subject: Re: [vdsm] Future of Vdsm network configuration - Thread mid-summary
 
 On 11/28/2012 05:34 AM, Roni Luxenberg wrote:
  - Original Message -
  From: Itamar Heim ih...@redhat.com
  To: Dan Kenigsberg dan...@redhat.com
  Cc: Alon Bar-Lev alo...@redhat.com, VDSM Project
  Development
  vdsm-devel@lists.fedorahosted.org, Yaniv Kaul
  yk...@redhat.com
  Sent: Wednesday, November 28, 2012 11:01:35 AM
  Subject: Re: [vdsm] Future of Vdsm network configuration - Thread
  mid-summary
 
  On 11/28/2012 03:53 AM, Dan Kenigsberg wrote:
  On Tue, Nov 27, 2012 at 03:24:58PM -0500, Alon Bar-Lev wrote:
 
 
 
 
  Management interface configuration is a separate issue.
 
  But it is an important issue that has to be discussed..
 
  If we perform changes of this interface when host is in
  maintenance
  we reduce the complexity of the problem.
 
  For your specific issue, if there are two interfaces, one
  which
  is
  up during boot and one which is down during boot, there is no
  problem to bond them after boot without persisting
  configuration.
 
  how would you know which bond mode to use? which MTU?
 
  I don't understand the question.
 
  I think I do: Alon suggests that on boot, the management
  interface
  would
  not have bonding at all, and use a single nic. The switch would
  have to
  assume that other nics in the bond are dead, and will use the
  only
  one
  which is alive to transfer packets.
 
  There is no doubt that we have to persist the vlan tag of the
  management
  interface, and its MTU, in the extremely rare case where the
  network
  would not alow Linux's default of 1500.
 
  i was thinking manager may be using jumbo frames to talk to host,
  and
  host will have an issue with them since it is set to 1500 instead
  of
  8k.
  jumbo frames isn't a rare case.
 
  as for bond, are you sure you can use a nic in a non bonded mode
  for
  all
  bond modes?
 
 
  all bond modes have to cope with a situation where only a single
  nic is active and the rest are down,
  so one can boot with a single active nic and only activate the rest
  and promote to the desired bond mode upon getting the full network
  configuration from the manager.
 
 of course they need to handle single active nic, but iirc, the host
 must
 be configured for a matching bond as the switch.
 i.e., you can't configure the switch to be in bond, then boot the
 host
 with a single active nic in a non bonded config

as far as I know as long as the 2nd nic is down there is no problem.
it is as if the cord is out.

 
 
  Changing the master interface mtu for either vlan or bond is
  required
  for management interface and non management interface.
 
  So the logic would probably be set max(mtu(slaves)) regardless it
  is
  management interface or not.
 
  I discussed this with Livnat, if there are applications that
  access
  the master interface directly we may break them, as the
  destination
  may not support non standard mtu.
 
  This is true in current implementation and any future
  implementation.
 
  It is bad practice to use the master interface directly (mixed
  tagged/untagged), better to define in switch that untagged
  communication belongs to vlanX, then use this explicit vlanX at
  host.
 
  next, what if we're using openvswitch, and you need some flow
  definitions for the management interface?
 
  I cannot answer that as I don't know openvswitch very well and
  don't
  know what flow definitions are, however, I do guess that it has
  non persistent mode that can effect any interface on its control.
  If
  you like I can research this one.
 
  you mainly need OVS for provisioning VM networks so here too you
  can completely bypass OVS during boot and only configure it in a
  transactional manner upon getting the full network configuration
  from the manager.
 
  a general question, why would you need to configure VM networks on
  the host (assuming a persistent cached configuration) upon boot if
  it cannot talk to the manager?
  after-all, in this case no resources would be scheduled to run on
  this host until connection to the manager is restored and
  up-to-date network configuration is applied.
 
  thanks,
  Roni
 
 
 
___
vdsm-devel mailing list
vdsm-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel

Re: [vdsm] Future of Vdsm network configuration - Thread mid-summary

[Roni Luxenberg]

 - Original Message -
  From: Itamar Heim ih...@redhat.com
  To: Roni Luxenberg rluxe...@redhat.com
  Cc: Alon Bar-Lev alo...@redhat.com, VDSM Project Development
  vdsm-devel@lists.fedorahosted.org
  Sent: Wednesday, November 28, 2012 2:01:45 PM
  Subject: Re: [vdsm] Future of Vdsm network configuration - Thread
  mid-summary
  
  On 11/28/2012 05:34 AM, Roni Luxenberg wrote:
   - Original Message -
   From: Itamar Heim ih...@redhat.com
   To: Dan Kenigsberg dan...@redhat.com
   Cc: Alon Bar-Lev alo...@redhat.com, VDSM Project
   Development
   vdsm-devel@lists.fedorahosted.org, Yaniv Kaul
   yk...@redhat.com
   Sent: Wednesday, November 28, 2012 11:01:35 AM
   Subject: Re: [vdsm] Future of Vdsm network configuration -
   Thread
   mid-summary
  
   On 11/28/2012 03:53 AM, Dan Kenigsberg wrote:
   On Tue, Nov 27, 2012 at 03:24:58PM -0500, Alon Bar-Lev wrote:
  
  
  
  
   Management interface configuration is a separate issue.
  
   But it is an important issue that has to be discussed..
  
   If we perform changes of this interface when host is in
   maintenance
   we reduce the complexity of the problem.
  
   For your specific issue, if there are two interfaces, one
   which
   is
   up during boot and one which is down during boot, there is
   no
   problem to bond them after boot without persisting
   configuration.
  
   how would you know which bond mode to use? which MTU?
  
   I don't understand the question.
  
   I think I do: Alon suggests that on boot, the management
   interface
   would
   not have bonding at all, and use a single nic. The switch
   would
   have to
   assume that other nics in the bond are dead, and will use the
   only
   one
   which is alive to transfer packets.
  
   There is no doubt that we have to persist the vlan tag of the
   management
   interface, and its MTU, in the extremely rare case where the
   network
   would not alow Linux's default of 1500.
  
   i was thinking manager may be using jumbo frames to talk to
   host,
   and
   host will have an issue with them since it is set to 1500
   instead
   of
   8k.
   jumbo frames isn't a rare case.
  
   as for bond, are you sure you can use a nic in a non bonded
   mode
   for
   all
   bond modes?
  
  
   all bond modes have to cope with a situation where only a single
   nic is active and the rest are down,
   so one can boot with a single active nic and only activate the
   rest
   and promote to the desired bond mode upon getting the full
   network
   configuration from the manager.
  
  of course they need to handle single active nic, but iirc, the host
  must
  be configured for a matching bond as the switch.
  i.e., you can't configure the switch to be in bond, then boot the
  host
  with a single active nic in a non bonded config
 
 as far as I know as long as the 2nd nic is down there is no problem.
 it is as if the cord is out.
 
regular port grouping or trunking on adjacent switch does not mandate bond 
configuration on the host as long as only a single nic is active. OTAH, 802.3ad 
port grouping might require host configuration as link aggregation control 
packets are exchanged on the wire. If this is the case, you'd need to persist 
your L2 bonding config.

  
  
   Changing the master interface mtu for either vlan or bond is
   required
   for management interface and non management interface.
  
   So the logic would probably be set max(mtu(slaves)) regardless
   it
   is
   management interface or not.
  
   I discussed this with Livnat, if there are applications that
   access
   the master interface directly we may break them, as the
   destination
   may not support non standard mtu.
  
   This is true in current implementation and any future
   implementation.
  
   It is bad practice to use the master interface directly (mixed
   tagged/untagged), better to define in switch that untagged
   communication belongs to vlanX, then use this explicit vlanX at
   host.
  
   next, what if we're using openvswitch, and you need some flow
   definitions for the management interface?
  
   I cannot answer that as I don't know openvswitch very well and
   don't
   know what flow definitions are, however, I do guess that it
   has
   non persistent mode that can effect any interface on its
   control.
   If
   you like I can research this one.
  
   you mainly need OVS for provisioning VM networks so here too you
   can completely bypass OVS during boot and only configure it in a
   transactional manner upon getting the full network configuration
   from the manager.
  
   a general question, why would you need to configure VM networks
   on
   the host (assuming a persistent cached configuration) upon boot
   if
   it cannot talk to the manager?
   after-all, in this case no resources would be scheduled to run on
   this host until connection to the manager is restored and
   up-to-date network configuration is applied.
  
   thanks,
   Roni

Re: [vdsm] Future of Vdsm network configuration - Thread mid-summary

[Livnat Peer]

On 26/11/12 16:59, Adam Litke wrote:
 On Mon, Nov 26, 2012 at 02:57:19PM +0200, Livnat Peer wrote:
 On 26/11/12 03:15, Shu Ming wrote:
 Livnat,

 Thanks for your summary.  I got comments below.

 2012-11-25 18:53, Livnat Peer:
 Hi All,
 We have been discussing $subject for a while and I'd like to summarized
 what we agreed and disagreed on thus far.

 The way I see it there are two related discussions:


 1. Getting VDSM networking stack to be distribution agnostic.
 - We are all in agreement that VDSM API should be generic enough to
 incorporate multiple implementation. (discussed on this thread: Alon's
 suggestion, Mark's patch for adding support for netcf etc.)

 - We would like to maintain at least one implementation as the
 working/up-to-date implementation for our users, this implementation
 should be distribution agnostic (as we all acknowledge this is an
 important goal for VDSM).
 I also think that with the agreement of this community we can choose to
 change our focus, from time to time, from one implementation to another
 as we see fit (today it can be OVS+netcf and in a few months we'll use
 the quantum based implementation if we agree it is better)

 2. The second discussion is about persisting the network configuration
 on the host vs. dynamically retrieving it from a centralized location
 like the engine. Danken raised a concern that even if going with the
 dynamic approach the host should persist the management network
 configuration.

 About dynamical retrieving from a centralized location,  when will the
 retrieving start? Just in the very early stage of host booting before
 network functions?  Or after the host startup and in the normal running
 state of the host?  Before retrieving the configuration,  how does the
 host network connecting to the engine? I think we need a basic well
 known network between hosts and the engine first.  Then after the
 retrieving, hosts should reconfigure the network for later management.
 However, the timing to retrieve and reconfigure are challenging.


 We did not discuss the dynamic approach in details on the list so far
 and I think this is a good opportunity to start this discussion...

 From what was discussed previously I can say that the need for a well
 known network was raised by danken, it was referred to as the management
 network, this network would be used for pulling the full host network
 configuration from the centralized location, at this point the engine.

 About the timing for retrieving the configuration, there are several
 approaches. One of them was described by Alon, and I think he'll join
 this discussion and maybe put it in his own words, but the idea was to
 'keep' the network synchronized at all times. When the host have
 communication channel to the engine and the engine detects there is a
 mismatch in the host configuration, the engine initiates 'apply network
 configuration' action on the host.

 Using this approach we'll have a single path of code to maintain and
 that would reduce code complexity and bugs - That's quoting Alon Bar Lev
 (Alon I hope I did not twisted your words/idea).

 On the other hand the above approach makes local tweaks on the host
 (done manually by the administrator) much harder.
 
 I worry a lot about the above if we take the dynamic approach.  It seems we'd
 need to introduce before/after 'apply network configuration' hooks where the
 admin could add custom config commands that aren't yet modeled by engine.
 

yes, and I'm not sure the administrators would like the fact that we are
'forcing' them to write everything in a script and getting familiar with
VDSM hooking mechanism (which in some cases require the use of custom
properties on the engine level) instead of running a simple command line.

 Any other approaches ?
 
 Static configuration has the advantage of allowing a host to bring itself back
 online independent of the engine.  This is also useful for anyone who may want
 to deploy a vdsm node in standalone mode.
 
 I think it would be possible to easily support a quasi-static configuration 
 mode
 simply by extending the design of the dynamic approach slightly.  In dynamic
 mode, the network configuration is passed down as a well-defined data 
 structure.
 When a particular configuration has been committed, vdsm could write a copy of
 that configuration data structure to /var/run/vdsm/network-config.json.  
 During
 a subsequent boot, if the engine cannot be contacted after activating the
 management network, the cached configuration can be applied using the same 
 code
 as for dynamic mode.  We'd have to flesh out the circumstances under which 
 this
 would happen. 

I like this approach a lot but we need to consider that network
configuration is an accumulated state, for example -

1. The engine sends a setup-network command with the full host network
configuration
2. The user configures new network on the host, the engine sends a new
setup-network request to VDSM which includes only the 

Re: [vdsm] Future of Vdsm network configuration - Thread mid-summary

[Alon Bar-Lev]

- Original Message -
 From: Livnat Peer lp...@redhat.com
 To: Adam Litke a...@us.ibm.com
 Cc: Alon Bar-Lev abar...@redhat.com, VDSM Project Development 
 vdsm-devel@lists.fedorahosted.org
 Sent: Tuesday, November 27, 2012 10:42:00 AM
 Subject: Re: [vdsm] Future of Vdsm network configuration - Thread mid-summary
 
 On 26/11/12 16:59, Adam Litke wrote:
  On Mon, Nov 26, 2012 at 02:57:19PM +0200, Livnat Peer wrote:
  On 26/11/12 03:15, Shu Ming wrote:
  Livnat,
 
  Thanks for your summary.  I got comments below.
 
  2012-11-25 18:53, Livnat Peer:
  Hi All,
  We have been discussing $subject for a while and I'd like to
  summarized
  what we agreed and disagreed on thus far.
 
  The way I see it there are two related discussions:
 
 
  1. Getting VDSM networking stack to be distribution agnostic.
  - We are all in agreement that VDSM API should be generic enough
  to
  incorporate multiple implementation. (discussed on this thread:
  Alon's
  suggestion, Mark's patch for adding support for netcf etc.)
 
  - We would like to maintain at least one implementation as the
  working/up-to-date implementation for our users, this
  implementation
  should be distribution agnostic (as we all acknowledge this is
  an
  important goal for VDSM).
  I also think that with the agreement of this community we can
  choose to
  change our focus, from time to time, from one implementation to
  another
  as we see fit (today it can be OVS+netcf and in a few months
  we'll use
  the quantum based implementation if we agree it is better)
 
  2. The second discussion is about persisting the network
  configuration
  on the host vs. dynamically retrieving it from a centralized
  location
  like the engine. Danken raised a concern that even if going with
  the
  dynamic approach the host should persist the management network
  configuration.
 
  About dynamical retrieving from a centralized location,  when
  will the
  retrieving start? Just in the very early stage of host booting
  before
  network functions?  Or after the host startup and in the normal
  running
  state of the host?  Before retrieving the configuration,  how
  does the
  host network connecting to the engine? I think we need a basic
  well
  known network between hosts and the engine first.  Then after the
  retrieving, hosts should reconfigure the network for later
  management.
  However, the timing to retrieve and reconfigure are challenging.
 
 
  We did not discuss the dynamic approach in details on the list so
  far
  and I think this is a good opportunity to start this discussion...
 
  From what was discussed previously I can say that the need for a
  well
  known network was raised by danken, it was referred to as the
  management
  network, this network would be used for pulling the full host
  network
  configuration from the centralized location, at this point the
  engine.
 
  About the timing for retrieving the configuration, there are
  several
  approaches. One of them was described by Alon, and I think he'll
  join
  this discussion and maybe put it in his own words, but the idea
  was to
  'keep' the network synchronized at all times. When the host have
  communication channel to the engine and the engine detects there
  is a
  mismatch in the host configuration, the engine initiates 'apply
  network
  configuration' action on the host.
 
  Using this approach we'll have a single path of code to maintain
  and
  that would reduce code complexity and bugs - That's quoting Alon
  Bar Lev
  (Alon I hope I did not twisted your words/idea).
 
  On the other hand the above approach makes local tweaks on the
  host
  (done manually by the administrator) much harder.
  
  I worry a lot about the above if we take the dynamic approach.  It
  seems we'd
  need to introduce before/after 'apply network configuration' hooks
  where the
  admin could add custom config commands that aren't yet modeled by
  engine.
  
 
 yes, and I'm not sure the administrators would like the fact that we
 are
 'forcing' them to write everything in a script and getting familiar
 with
 VDSM hooking mechanism (which in some cases require the use of custom
 properties on the engine level) instead of running a simple command
 line.

In which case will we force? Please be more specific.
If we can pass most of the iproute2, brctl, bond parameters via key/value pairs 
via the API, what in your view that is common or even seldom should be used?
This hook mechanism is only as fallback, provided to calm people down.

 
  Any other approaches ?
  
  Static configuration has the advantage of allowing a host to bring
  itself back
  online independent of the engine.  This is also useful for anyone
  who may want
  to deploy a vdsm node in standalone mode.
  
  I think it would be possible to easily support a quasi-static
  configuration mode
  simply by extending the design of the dynamic approach slightly.
   In dynamic
  mode, the network configuration is passed down as a well

Re: [vdsm] Future of Vdsm network configuration - Thread mid-summary

[Livnat Peer]

On 27/11/12 10:53, Alon Bar-Lev wrote:
 
 
 - Original Message -
 From: Livnat Peer lp...@redhat.com
 To: Adam Litke a...@us.ibm.com
 Cc: Alon Bar-Lev abar...@redhat.com, VDSM Project Development 
 vdsm-devel@lists.fedorahosted.org
 Sent: Tuesday, November 27, 2012 10:42:00 AM
 Subject: Re: [vdsm] Future of Vdsm network configuration - Thread mid-summary

 On 26/11/12 16:59, Adam Litke wrote:
 On Mon, Nov 26, 2012 at 02:57:19PM +0200, Livnat Peer wrote:
 On 26/11/12 03:15, Shu Ming wrote:
 Livnat,

 Thanks for your summary.  I got comments below.

 2012-11-25 18:53, Livnat Peer:
 Hi All,
 We have been discussing $subject for a while and I'd like to
 summarized
 what we agreed and disagreed on thus far.

 The way I see it there are two related discussions:


 1. Getting VDSM networking stack to be distribution agnostic.
 - We are all in agreement that VDSM API should be generic enough
 to
 incorporate multiple implementation. (discussed on this thread:
 Alon's
 suggestion, Mark's patch for adding support for netcf etc.)

 - We would like to maintain at least one implementation as the
 working/up-to-date implementation for our users, this
 implementation
 should be distribution agnostic (as we all acknowledge this is
 an
 important goal for VDSM).
 I also think that with the agreement of this community we can
 choose to
 change our focus, from time to time, from one implementation to
 another
 as we see fit (today it can be OVS+netcf and in a few months
 we'll use
 the quantum based implementation if we agree it is better)

 2. The second discussion is about persisting the network
 configuration
 on the host vs. dynamically retrieving it from a centralized
 location
 like the engine. Danken raised a concern that even if going with
 the
 dynamic approach the host should persist the management network
 configuration.

 About dynamical retrieving from a centralized location,  when
 will the
 retrieving start? Just in the very early stage of host booting
 before
 network functions?  Or after the host startup and in the normal
 running
 state of the host?  Before retrieving the configuration,  how
 does the
 host network connecting to the engine? I think we need a basic
 well
 known network between hosts and the engine first.  Then after the
 retrieving, hosts should reconfigure the network for later
 management.
 However, the timing to retrieve and reconfigure are challenging.


 We did not discuss the dynamic approach in details on the list so
 far
 and I think this is a good opportunity to start this discussion...

 From what was discussed previously I can say that the need for a
 well
 known network was raised by danken, it was referred to as the
 management
 network, this network would be used for pulling the full host
 network
 configuration from the centralized location, at this point the
 engine.

 About the timing for retrieving the configuration, there are
 several
 approaches. One of them was described by Alon, and I think he'll
 join
 this discussion and maybe put it in his own words, but the idea
 was to
 'keep' the network synchronized at all times. When the host have
 communication channel to the engine and the engine detects there
 is a
 mismatch in the host configuration, the engine initiates 'apply
 network
 configuration' action on the host.

 Using this approach we'll have a single path of code to maintain
 and
 that would reduce code complexity and bugs - That's quoting Alon
 Bar Lev
 (Alon I hope I did not twisted your words/idea).

 On the other hand the above approach makes local tweaks on the
 host
 (done manually by the administrator) much harder.

 I worry a lot about the above if we take the dynamic approach.  It
 seems we'd
 need to introduce before/after 'apply network configuration' hooks
 where the
 admin could add custom config commands that aren't yet modeled by
 engine.


 yes, and I'm not sure the administrators would like the fact that we
 are
 'forcing' them to write everything in a script and getting familiar
 with
 VDSM hooking mechanism (which in some cases require the use of custom
 properties on the engine level) instead of running a simple command
 line.
 
 In which case will we force? Please be more specific.
 If we can pass most of the iproute2, brctl, bond parameters via key/value 
 pairs via the API, what in your view that is common or even seldom should be 
 used?
 This hook mechanism is only as fallback, provided to calm people down.
 

I understand, I'm saying it can irritate the administrators that needs
to use it, it does not help that we are calmed down ;)

Just to make it clear I'm not against the stateless approach, I'm trying
to understand it better and make sure we are all aware of the drawbacks
this approach has. Complicating local tweaks to the admin is one of them.

I'll reply on your original mail with the questions I have on your proposal.


 Any other approaches ?

 Static configuration has the advantage of allowing a host to bring
 itself

Re: [vdsm] Future of Vdsm network configuration - Thread mid-summary

[Alon Bar-Lev]

- Original Message -
 From: Livnat Peer lp...@redhat.com
 To: Alon Bar-Lev alo...@redhat.com
 Cc: VDSM Project Development vdsm-devel@lists.fedorahosted.org, Shu 
 Ming shum...@linux.vnet.ibm.com, Saggi
 Mizrahi smizr...@redhat.com, Dan Kenigsberg dan...@redhat.com
 Sent: Tuesday, November 27, 2012 12:18:31 PM
 Subject: Re: [vdsm] Future of Vdsm network configuration - Thread mid-summary
 
 On 26/11/12 22:18, Alon Bar-Lev wrote:
  
  
  - Original Message -
  From: Livnat Peer lp...@redhat.com
  To: Shu Ming shum...@linux.vnet.ibm.com
  Cc: Alon Bar-Lev abar...@redhat.com, VDSM Project
  Development vdsm-devel@lists.fedorahosted.org
  Sent: Monday, November 26, 2012 2:57:19 PM
  Subject: Re: [vdsm] Future of Vdsm network configuration - Thread
  mid-summary
 
  On 26/11/12 03:15, Shu Ming wrote:
  Livnat,
 
  Thanks for your summary.  I got comments below.
 
  2012-11-25 18:53, Livnat Peer:
  Hi All,
  We have been discussing $subject for a while and I'd like to
  summarized
  what we agreed and disagreed on thus far.
 
  The way I see it there are two related discussions:
 
 
  1. Getting VDSM networking stack to be distribution agnostic.
  - We are all in agreement that VDSM API should be generic enough
  to
  incorporate multiple implementation. (discussed on this thread:
  Alon's
  suggestion, Mark's patch for adding support for netcf etc.)
 
  - We would like to maintain at least one implementation as the
  working/up-to-date implementation for our users, this
  implementation
  should be distribution agnostic (as we all acknowledge this is
  an
  important goal for VDSM).
  I also think that with the agreement of this community we can
  choose to
  change our focus, from time to time, from one implementation to
  another
  as we see fit (today it can be OVS+netcf and in a few months
  we'll
  use
  the quantum based implementation if we agree it is better)
 
  2. The second discussion is about persisting the network
  configuration
  on the host vs. dynamically retrieving it from a centralized
  location
  like the engine. Danken raised a concern that even if going with
  the
  dynamic approach the host should persist the management network
  configuration.
 
  About dynamical retrieving from a centralized location,  when
  will
  the
  retrieving start? Just in the very early stage of host booting
  before
  network functions?  Or after the host startup and in the normal
  running
  state of the host?  Before retrieving the configuration,  how
  does
  the
  host network connecting to the engine? I think we need a basic
  well
  known network between hosts and the engine first.  Then after the
  retrieving, hosts should reconfigure the network for later
  management.
  However, the timing to retrieve and reconfigure are challenging.
 
 
  We did not discuss the dynamic approach in details on the list so
  far
  and I think this is a good opportunity to start this discussion...
 
  From what was discussed previously I can say that the need for a
  well
  known network was raised by danken, it was referred to as the
  management
  network, this network would be used for pulling the full host
  network
  configuration from the centralized location, at this point the
  engine.
 
  About the timing for retrieving the configuration, there are
  several
  approaches. One of them was described by Alon, and I think he'll
  join
  this discussion and maybe put it in his own words, but the idea
  was
  to
  'keep' the network synchronized at all times. When the host have
  communication channel to the engine and the engine detects there
  is a
  mismatch in the host configuration, the engine initiates 'apply
  network
  configuration' action on the host.
 
  Using this approach we'll have a single path of code to maintain
  and
  that would reduce code complexity and bugs - That's quoting Alon
  Bar
  Lev
  (Alon I hope I did not twisted your words/idea).
 
  On the other hand the above approach makes local tweaks on the
  host
  (done manually by the administrator) much harder.
 
  Any other approaches ?
 
  I'd like to add a more general question to the discussion what are
  the
  advantages of taking the dynamic approach?
  So far I collected two reasons:
 
  -It is a 'cleaner' design, removes complexity on VDSM code, easier
  to
  maintain going forward, and less bug prone (I agree with that one,
  as
  long as we keep the retrieving configuration mechanism/algorithm
  simple).
 
  -It adheres to the idea of having a stateless hypervisor - some
  more
  input on this point would be appreciated
 
  Any other advantages?
 
  discussing the benefits of having the persisted
 
  Livnat
 
  
  Sorry for the delay. Some more expansion.
  
  ASSUMPTION
  
  After boot a host running vdsm is able to receive communication
  from engine.
  This means that host has legitimate layer 2 configuration and layer
  3 configuration for the interface used to communicate to engine.
  
  MISSION
  
  Reduce

Re: [vdsm] Future of Vdsm network configuration - Thread mid-summary

[Dan Kenigsberg]

On Tue, Nov 27, 2012 at 05:38:25AM -0500, Alon Bar-Lev wrote:
 
snip

   
   ASSUMPTION
   
   After boot a host running vdsm is able to receive communication
   from engine.
   This means that host has legitimate layer 2 configuration and layer
   3 configuration for the interface used to communicate to engine.
   
   MISSION
   
   Reduce complexity of implementation, so that only one algorithm is
   used in order to reach to operative state as far as networking is
   concerned.
   
   (Storage is extremely similar I can s/network/storage/ and still be
   relevant).
   
  
  For reaching the mission above we can also use the approach suggested
  by
  Adam. start from a clean configuration and execute setup network to
  set
  the host networking configuration. In Adam's proposal VDSM itself is
  issuing the setupNetwork and in your approach the engine does.
 
 Right. we can do this 100+ ways, question is which implementation will be the 
 simplest.

My problem with Adam's idea is http://xkcd.com/927/ : it amounts to an
(n+1)th way of persisting network configuration on disk.
We may have to take that way, but as with VM definitions and storage
connections, I would like to keep it in a smaller service on top of
vdsm.

 
  
  
   DESIGN FOCAL POINT
   
   Host running vdsm is a complete slave of its master, will it be
   ovirt-engine or other engine.
   
   Having a complete slave ease implementation:
   
1. Master always apply the setting as-is.
2. No need to consider slave state.
3. No need to implement AI to reach from unknown state X to known
state Y + delta.
4. After reboot (or fence) host is always in known state.
   
   ALGORITHM

   A. Given communication to vdsm,

I think we should not brush this permise aside. Current Vdsm API lets
Engine tweak the means of communication for next boot.
We had customers that wanted to add a bond, or change the vlan, or fix
the IP address of the management interface. They could have used Engine
for this, and declare the new configuration as safe (setSafeNetConfig).
In many cases, the latter step has to be done out of band. But there are
cases where this can be done completely remotely.

It seems that you suggest to take this crucial configuration completely
out-of-band.

   construct required vlan, bonding,
   bridge setup on machine.
   
   B. Reboot/Fence - host is reset, apply A.
   
   C. Network configuration is changed at engine:
 (1) Drop all resources that are not used by active VMs.
  
  I'm not sure what you mean by the above, drop all resources *not*
  used
  by VMs?
 
 Let's say we have running VM using bridge bridge1.
 We cannot modify this bridge1 as long as VM is operative.
 So we drop all network configuration except of bridge1 to allow VM to survive 
 the upgrade.
 
 I was tempted to write something else but I did not want to alarm people
 But... when network configuration is changed on a host with running VMs, 
 first move the VMs to a different host, then recycle configuration (simplest: 
 reboot).

We've been doing that until v3.1...

 
 (2) Apply A.
   
   D. Host in maintenance - network configuration can be changed, will
   be applied when host go into active, apply C (no resources are
   used by VMs, all resources are dropped).
   
   E. Critical network is down (Host not operative) - network
   configuration is not changed.
   
   F. Host unreachable (None responsive) - network configuration
   cannot be changed.
   
  
  What happens if we have a host that is added to the engine (or used
  to
  be non-operational and now returns to up) and reports a network
  configuration different than what is configured in the engine?
 
 This is a sign of totally malicious node!
 A trigger to fencing, active rebooting.
 Can you please describe a valid sequence in which it can happen?

I'm not sure this example flies all, but how about a sysadmin that wants
to replace our bonding definition with teaming.
___
vdsm-devel mailing list
vdsm-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel

Re: [vdsm] Future of Vdsm network configuration - Thread mid-summary

[Dan Kenigsberg]

On Tue, Nov 27, 2012 at 11:56:54AM +0200, Livnat Peer wrote:
 On 27/11/12 10:53, Alon Bar-Lev wrote:
  
  
  - Original Message -
  From: Livnat Peer lp...@redhat.com
  To: Adam Litke a...@us.ibm.com
  Cc: Alon Bar-Lev abar...@redhat.com, VDSM Project Development 
  vdsm-devel@lists.fedorahosted.org
  Sent: Tuesday, November 27, 2012 10:42:00 AM
  Subject: Re: [vdsm] Future of Vdsm network configuration - Thread 
  mid-summary
 
  On 26/11/12 16:59, Adam Litke wrote:
  On Mon, Nov 26, 2012 at 02:57:19PM +0200, Livnat Peer wrote:
  On 26/11/12 03:15, Shu Ming wrote:
  Livnat,
 
  Thanks for your summary.  I got comments below.
 
  2012-11-25 18:53, Livnat Peer:
  Hi All,
  We have been discussing $subject for a while and I'd like to
  summarized
  what we agreed and disagreed on thus far.
 
  The way I see it there are two related discussions:
 
 
  1. Getting VDSM networking stack to be distribution agnostic.
  - We are all in agreement that VDSM API should be generic enough
  to
  incorporate multiple implementation. (discussed on this thread:
  Alon's
  suggestion, Mark's patch for adding support for netcf etc.)
 
  - We would like to maintain at least one implementation as the
  working/up-to-date implementation for our users, this
  implementation
  should be distribution agnostic (as we all acknowledge this is
  an
  important goal for VDSM).
  I also think that with the agreement of this community we can
  choose to
  change our focus, from time to time, from one implementation to
  another
  as we see fit (today it can be OVS+netcf and in a few months
  we'll use
  the quantum based implementation if we agree it is better)
 
  2. The second discussion is about persisting the network
  configuration
  on the host vs. dynamically retrieving it from a centralized
  location
  like the engine. Danken raised a concern that even if going with
  the
  dynamic approach the host should persist the management network
  configuration.
 
  About dynamical retrieving from a centralized location,  when
  will the
  retrieving start? Just in the very early stage of host booting
  before
  network functions?  Or after the host startup and in the normal
  running
  state of the host?  Before retrieving the configuration,  how
  does the
  host network connecting to the engine? I think we need a basic
  well
  known network between hosts and the engine first.  Then after the
  retrieving, hosts should reconfigure the network for later
  management.
  However, the timing to retrieve and reconfigure are challenging.
 
 
  We did not discuss the dynamic approach in details on the list so
  far
  and I think this is a good opportunity to start this discussion...
 
  From what was discussed previously I can say that the need for a
  well
  known network was raised by danken, it was referred to as the
  management
  network, this network would be used for pulling the full host
  network
  configuration from the centralized location, at this point the
  engine.
 
  About the timing for retrieving the configuration, there are
  several
  approaches. One of them was described by Alon, and I think he'll
  join
  this discussion and maybe put it in his own words, but the idea
  was to
  'keep' the network synchronized at all times. When the host have
  communication channel to the engine and the engine detects there
  is a
  mismatch in the host configuration, the engine initiates 'apply
  network
  configuration' action on the host.
 
  Using this approach we'll have a single path of code to maintain
  and
  that would reduce code complexity and bugs - That's quoting Alon
  Bar Lev
  (Alon I hope I did not twisted your words/idea).
 
  On the other hand the above approach makes local tweaks on the
  host
  (done manually by the administrator) much harder.
 
  I worry a lot about the above if we take the dynamic approach.  It
  seems we'd
  need to introduce before/after 'apply network configuration' hooks
  where the
  admin could add custom config commands that aren't yet modeled by
  engine.
 
 
  yes, and I'm not sure the administrators would like the fact that we
  are
  'forcing' them to write everything in a script and getting familiar
  with
  VDSM hooking mechanism (which in some cases require the use of custom
  properties on the engine level) instead of running a simple command
  line.
  
  In which case will we force? Please be more specific.
  If we can pass most of the iproute2, brctl, bond parameters via key/value 
  pairs via the API, what in your view that is common or even seldom should 
  be used?
  This hook mechanism is only as fallback, provided to calm people down.
  
 
 I understand, I'm saying it can irritate the administrators that needs
 to use it, it does not help that we are calmed down ;)
 
 Just to make it clear I'm not against the stateless approach, I'm trying
 to understand it better and make sure we are all aware of the drawbacks
 this approach has. Complicating local tweaks

Re: [vdsm] Future of Vdsm network configuration - Thread mid-summary

[Alon Bar-Lev]

- Original Message -
 From: Dan Kenigsberg dan...@redhat.com
 To: Livnat Peer lp...@redhat.com
 Cc: Alon Bar-Lev alo...@redhat.com, VDSM Project Development 
 vdsm-devel@lists.fedorahosted.org
 Sent: Tuesday, November 27, 2012 4:22:19 PM
 Subject: Re: [vdsm] Future of Vdsm network configuration - Thread mid-summary
 

snip

  
   
   Livnat, I don't see any argument of persistence vs non
   persistence as the above is common to any approach taken.
   
   Only this manual configuration argument keeps poping, which as
   I wrote is irrelevant in large scale and we do want to go into
   large scale.
 
 Well, we call it manual configuration, but it applies just as well
 to
 puppet-based configuration.
 
 Dan.
 

There can by only one (manager to each host).

Alon.
___
vdsm-devel mailing list
vdsm-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel

Re: [vdsm] Future of Vdsm network configuration - Thread mid-summary

[Adam Litke]

On Tue, Nov 27, 2012 at 10:42:00AM +0200, Livnat Peer wrote:
 On 26/11/12 16:59, Adam Litke wrote:
  On Mon, Nov 26, 2012 at 02:57:19PM +0200, Livnat Peer wrote:
  On 26/11/12 03:15, Shu Ming wrote:
  Livnat,
 
  Thanks for your summary.  I got comments below.
 
  2012-11-25 18:53, Livnat Peer:
  Hi All,
  We have been discussing $subject for a while and I'd like to summarized
  what we agreed and disagreed on thus far.
 
  The way I see it there are two related discussions:
 
 
  1. Getting VDSM networking stack to be distribution agnostic.
  - We are all in agreement that VDSM API should be generic enough to
  incorporate multiple implementation. (discussed on this thread: Alon's
  suggestion, Mark's patch for adding support for netcf etc.)
 
  - We would like to maintain at least one implementation as the
  working/up-to-date implementation for our users, this implementation
  should be distribution agnostic (as we all acknowledge this is an
  important goal for VDSM).
  I also think that with the agreement of this community we can choose to
  change our focus, from time to time, from one implementation to another
  as we see fit (today it can be OVS+netcf and in a few months we'll use
  the quantum based implementation if we agree it is better)
 
  2. The second discussion is about persisting the network configuration
  on the host vs. dynamically retrieving it from a centralized location
  like the engine. Danken raised a concern that even if going with the
  dynamic approach the host should persist the management network
  configuration.
 
  About dynamical retrieving from a centralized location,  when will the
  retrieving start? Just in the very early stage of host booting before
  network functions?  Or after the host startup and in the normal running
  state of the host?  Before retrieving the configuration,  how does the
  host network connecting to the engine? I think we need a basic well
  known network between hosts and the engine first.  Then after the
  retrieving, hosts should reconfigure the network for later management.
  However, the timing to retrieve and reconfigure are challenging.
 
 
  We did not discuss the dynamic approach in details on the list so far
  and I think this is a good opportunity to start this discussion...
 
  From what was discussed previously I can say that the need for a well
  known network was raised by danken, it was referred to as the management
  network, this network would be used for pulling the full host network
  configuration from the centralized location, at this point the engine.
 
  About the timing for retrieving the configuration, there are several
  approaches. One of them was described by Alon, and I think he'll join
  this discussion and maybe put it in his own words, but the idea was to
  'keep' the network synchronized at all times. When the host have
  communication channel to the engine and the engine detects there is a
  mismatch in the host configuration, the engine initiates 'apply network
  configuration' action on the host.
 
  Using this approach we'll have a single path of code to maintain and
  that would reduce code complexity and bugs - That's quoting Alon Bar Lev
  (Alon I hope I did not twisted your words/idea).
 
  On the other hand the above approach makes local tweaks on the host
  (done manually by the administrator) much harder.
  
  I worry a lot about the above if we take the dynamic approach.  It seems 
  we'd
  need to introduce before/after 'apply network configuration' hooks where the
  admin could add custom config commands that aren't yet modeled by engine.
  
 
 yes, and I'm not sure the administrators would like the fact that we are
 'forcing' them to write everything in a script and getting familiar with
 VDSM hooking mechanism (which in some cases require the use of custom
 properties on the engine level) instead of running a simple command line.
 
  Any other approaches ?
  
  Static configuration has the advantage of allowing a host to bring itself 
  back
  online independent of the engine.  This is also useful for anyone who may 
  want
  to deploy a vdsm node in standalone mode.
  
  I think it would be possible to easily support a quasi-static configuration 
  mode
  simply by extending the design of the dynamic approach slightly.  In dynamic
  mode, the network configuration is passed down as a well-defined data 
  structure.
  When a particular configuration has been committed, vdsm could write a copy 
  of
  that configuration data structure to /var/run/vdsm/network-config.json.  
  During
  a subsequent boot, if the engine cannot be contacted after activating the
  management network, the cached configuration can be applied using the same 
  code
  as for dynamic mode.  We'd have to flesh out the circumstances under which 
  this
  would happen. 
 
 I like this approach a lot but we need to consider that network
 configuration is an accumulated state, for example -
 
 1. The engine sends a 

Re: [vdsm] Future of Vdsm network configuration - Thread mid-summary

[Adam Litke]

On Mon, Nov 26, 2012 at 06:13:01PM -0500, Alon Bar-Lev wrote:
 Hello,
 
 - Original Message -
  From: Adam Litke a...@us.ibm.com To: Alon Bar-Lev alo...@redhat.com
  Cc: Livnat Peer lp...@redhat.com, VDSM Project Development
  vdsm-devel@lists.fedorahosted.org Sent: Tuesday, November 27, 2012
  12:51:36 AM Subject: Re: [vdsm] Future of Vdsm network configuration -
  Thread mid-summary
  
  Nice writeup!  I like where this is going but see my comments inline below.
  
  On Mon, Nov 26, 2012 at 03:18:22PM -0500, Alon Bar-Lev wrote:
   
   
   - Original Message -
From: Livnat Peer lp...@redhat.com To: Shu Ming
shum...@linux.vnet.ibm.com Cc: Alon Bar-Lev abar...@redhat.com,
VDSM Project Development vdsm-devel@lists.fedorahosted.org Sent:
Monday, November 26, 2012 2:57:19 PM Subject: Re: [vdsm] Future of Vdsm
network configuration - Thread mid-summary

On 26/11/12 03:15, Shu Ming wrote:
 Livnat,
 
 Thanks for your summary.  I got comments below.
 
 2012-11-25 18:53, Livnat Peer:
 Hi All, We have been discussing $subject for a while and I'd like to
 summarized what we agreed and disagreed on thus far.

 The way I see it there are two related discussions:


 1. Getting VDSM networking stack to be distribution agnostic.  - We
 are all in agreement that VDSM API should be generic enough to
 incorporate multiple implementation. (discussed on this thread:
 Alon's suggestion, Mark's patch for adding support for netcf etc.)

 - We would like to maintain at least one implementation as the
 working/up-to-date implementation for our users, this implementation
 should be distribution agnostic (as we all acknowledge this is an
 important goal for VDSM).  I also think that with the agreement of
 this community we can choose to change our focus, from time to time,
 from one implementation to another as we see fit (today it can be
 OVS+netcf and in a few months we'll use the quantum based
 implementation if we agree it is better)

 2. The second discussion is about persisting the network
 configuration on the host vs. dynamically retrieving it from a
 centralized location like the engine. Danken raised a concern that
 even if going with the dynamic approach the host should persist the
 management network configuration.
 
 About dynamical retrieving from a centralized location,  when will the
 retrieving start? Just in the very early stage of host booting before
 network functions?  Or after the host startup and in the normal
 running state of the host?  Before retrieving the configuration,  how
 does the host network connecting to the engine? I think we need a
 basic well known network between hosts and the engine first.  Then
 after the retrieving, hosts should reconfigure the network for later
 management.  However, the timing to retrieve and reconfigure are
 challenging.
 

We did not discuss the dynamic approach in details on the list so far
and I think this is a good opportunity to start this discussion...

From what was discussed previously I can say that the need for a well
known network was raised by danken, it was referred to as the management
network, this network would be used for pulling the full host network
configuration from the centralized location, at this point the engine.

About the timing for retrieving the configuration, there are several
approaches. One of them was described by Alon, and I think he'll join
this discussion and maybe put it in his own words, but the idea was to
'keep' the network synchronized at all times. When the host have
communication channel to the engine and the engine detects there is a
mismatch in the host configuration, the engine initiates 'apply network
configuration' action on the host.

Using this approach we'll have a single path of code to maintain and
that would reduce code complexity and bugs - That's quoting Alon Bar Lev
(Alon I hope I did not twisted your words/idea).

On the other hand the above approach makes local tweaks on the host
(done manually by the administrator) much harder.

Any other approaches ?

I'd like to add a more general question to the discussion what are the
advantages of taking the dynamic approach?  So far I collected two
reasons:

-It is a 'cleaner' design, removes complexity on VDSM code, easier to
maintain going forward, and less bug prone (I agree with that one, as
long as we keep the retrieving configuration mechanism/algorithm
simple).

-It adheres to the idea of having a stateless hypervisor - some more
input on this point would be appreciated

Any other advantages?

discussing the benefits of having the persisted

Livnat

   
   Sorry for the delay. Some more

Re: [vdsm] Future of Vdsm network configuration - Thread mid-summary

[Itamar Heim]

On 11/26/2012 03:18 PM, Alon Bar-Lev wrote:



- Original Message -

From: Livnat Peer lp...@redhat.com
To: Shu Ming shum...@linux.vnet.ibm.com
Cc: Alon Bar-Lev abar...@redhat.com, VDSM Project Development 
vdsm-devel@lists.fedorahosted.org
Sent: Monday, November 26, 2012 2:57:19 PM
Subject: Re: [vdsm] Future of Vdsm network configuration - Thread mid-summary

On 26/11/12 03:15, Shu Ming wrote:

Livnat,

Thanks for your summary.  I got comments below.

2012-11-25 18:53, Livnat Peer:

Hi All,
We have been discussing $subject for a while and I'd like to
summarized
what we agreed and disagreed on thus far.

The way I see it there are two related discussions:


1. Getting VDSM networking stack to be distribution agnostic.
- We are all in agreement that VDSM API should be generic enough
to
incorporate multiple implementation. (discussed on this thread:
Alon's
suggestion, Mark's patch for adding support for netcf etc.)

- We would like to maintain at least one implementation as the
working/up-to-date implementation for our users, this
implementation
should be distribution agnostic (as we all acknowledge this is an
important goal for VDSM).
I also think that with the agreement of this community we can
choose to
change our focus, from time to time, from one implementation to
another
as we see fit (today it can be OVS+netcf and in a few months we'll
use
the quantum based implementation if we agree it is better)

2. The second discussion is about persisting the network
configuration
on the host vs. dynamically retrieving it from a centralized
location
like the engine. Danken raised a concern that even if going with
the
dynamic approach the host should persist the management network
configuration.


About dynamical retrieving from a centralized location,  when will
the
retrieving start? Just in the very early stage of host booting
before
network functions?  Or after the host startup and in the normal
running
state of the host?  Before retrieving the configuration,  how does
the
host network connecting to the engine? I think we need a basic well
known network between hosts and the engine first.  Then after the
retrieving, hosts should reconfigure the network for later
management.
However, the timing to retrieve and reconfigure are challenging.



We did not discuss the dynamic approach in details on the list so far
and I think this is a good opportunity to start this discussion...

 From what was discussed previously I can say that the need for a well
known network was raised by danken, it was referred to as the
management
network, this network would be used for pulling the full host network
configuration from the centralized location, at this point the
engine.

About the timing for retrieving the configuration, there are several
approaches. One of them was described by Alon, and I think he'll join
this discussion and maybe put it in his own words, but the idea was
to
'keep' the network synchronized at all times. When the host have
communication channel to the engine and the engine detects there is a
mismatch in the host configuration, the engine initiates 'apply
network
configuration' action on the host.

Using this approach we'll have a single path of code to maintain and
that would reduce code complexity and bugs - That's quoting Alon Bar
Lev
(Alon I hope I did not twisted your words/idea).

On the other hand the above approach makes local tweaks on the host
(done manually by the administrator) much harder.

Any other approaches ?

I'd like to add a more general question to the discussion what are
the
advantages of taking the dynamic approach?
So far I collected two reasons:

-It is a 'cleaner' design, removes complexity on VDSM code, easier to
maintain going forward, and less bug prone (I agree with that one, as
long as we keep the retrieving configuration mechanism/algorithm
simple).

-It adheres to the idea of having a stateless hypervisor - some more
input on this point would be appreciated

Any other advantages?

discussing the benefits of having the persisted

Livnat



Sorry for the delay. Some more expansion.

ASSUMPTION

After boot a host running vdsm is able to receive communication from engine.
This means that host has legitimate layer 2 configuration and layer 3 
configuration for the interface used to communicate to engine.

MISSION

Reduce complexity of implementation, so that only one algorithm is used in 
order to reach to operative state as far as networking is concerned.

(Storage is extremely similar I can s/network/storage/ and still be relevant).

DESIGN FOCAL POINT

Host running vdsm is a complete slave of its master, will it be ovirt-engine or 
other engine.

Having a complete slave ease implementation:

  1. Master always apply the setting as-is.
  2. No need to consider slave state.
  3. No need to implement AI to reach from unknown state X to known state Y + 
delta.
  4. After reboot (or fence) host is always in known state.

ALGORITHM

A. Given communication to vdsm, construct

Re: [vdsm] Future of Vdsm network configuration - Thread mid-summary

[Alon Bar-Lev]

- Original Message -
 From: Itamar Heim ih...@redhat.com
 To: Alon Bar-Lev alo...@redhat.com
 Cc: Livnat Peer lp...@redhat.com, VDSM Project Development 
 vdsm-devel@lists.fedorahosted.org
 Sent: Tuesday, November 27, 2012 10:08:34 PM
 Subject: Re: [vdsm] Future of Vdsm network configuration - Thread mid-summary
 
 On 11/26/2012 03:18 PM, Alon Bar-Lev wrote:
 
 
  - Original Message -
  From: Livnat Peer lp...@redhat.com
  To: Shu Ming shum...@linux.vnet.ibm.com
  Cc: Alon Bar-Lev abar...@redhat.com, VDSM Project
  Development vdsm-devel@lists.fedorahosted.org
  Sent: Monday, November 26, 2012 2:57:19 PM
  Subject: Re: [vdsm] Future of Vdsm network configuration - Thread
  mid-summary
 
  On 26/11/12 03:15, Shu Ming wrote:
  Livnat,
 
  Thanks for your summary.  I got comments below.
 
  2012-11-25 18:53, Livnat Peer:
  Hi All,
  We have been discussing $subject for a while and I'd like to
  summarized
  what we agreed and disagreed on thus far.
 
  The way I see it there are two related discussions:
 
 
  1. Getting VDSM networking stack to be distribution agnostic.
  - We are all in agreement that VDSM API should be generic enough
  to
  incorporate multiple implementation. (discussed on this thread:
  Alon's
  suggestion, Mark's patch for adding support for netcf etc.)
 
  - We would like to maintain at least one implementation as the
  working/up-to-date implementation for our users, this
  implementation
  should be distribution agnostic (as we all acknowledge this is
  an
  important goal for VDSM).
  I also think that with the agreement of this community we can
  choose to
  change our focus, from time to time, from one implementation to
  another
  as we see fit (today it can be OVS+netcf and in a few months
  we'll
  use
  the quantum based implementation if we agree it is better)
 
  2. The second discussion is about persisting the network
  configuration
  on the host vs. dynamically retrieving it from a centralized
  location
  like the engine. Danken raised a concern that even if going with
  the
  dynamic approach the host should persist the management network
  configuration.
 
  About dynamical retrieving from a centralized location,  when
  will
  the
  retrieving start? Just in the very early stage of host booting
  before
  network functions?  Or after the host startup and in the normal
  running
  state of the host?  Before retrieving the configuration,  how
  does
  the
  host network connecting to the engine? I think we need a basic
  well
  known network between hosts and the engine first.  Then after the
  retrieving, hosts should reconfigure the network for later
  management.
  However, the timing to retrieve and reconfigure are challenging.
 
 
  We did not discuss the dynamic approach in details on the list so
  far
  and I think this is a good opportunity to start this discussion...
 
   From what was discussed previously I can say that the need for a
   well
  known network was raised by danken, it was referred to as the
  management
  network, this network would be used for pulling the full host
  network
  configuration from the centralized location, at this point the
  engine.
 
  About the timing for retrieving the configuration, there are
  several
  approaches. One of them was described by Alon, and I think he'll
  join
  this discussion and maybe put it in his own words, but the idea
  was
  to
  'keep' the network synchronized at all times. When the host have
  communication channel to the engine and the engine detects there
  is a
  mismatch in the host configuration, the engine initiates 'apply
  network
  configuration' action on the host.
 
  Using this approach we'll have a single path of code to maintain
  and
  that would reduce code complexity and bugs - That's quoting Alon
  Bar
  Lev
  (Alon I hope I did not twisted your words/idea).
 
  On the other hand the above approach makes local tweaks on the
  host
  (done manually by the administrator) much harder.
 
  Any other approaches ?
 
  I'd like to add a more general question to the discussion what are
  the
  advantages of taking the dynamic approach?
  So far I collected two reasons:
 
  -It is a 'cleaner' design, removes complexity on VDSM code, easier
  to
  maintain going forward, and less bug prone (I agree with that one,
  as
  long as we keep the retrieving configuration mechanism/algorithm
  simple).
 
  -It adheres to the idea of having a stateless hypervisor - some
  more
  input on this point would be appreciated
 
  Any other advantages?
 
  discussing the benefits of having the persisted
 
  Livnat
 
 
  Sorry for the delay. Some more expansion.
 
  ASSUMPTION
 
  After boot a host running vdsm is able to receive communication
  from engine.
  This means that host has legitimate layer 2 configuration and layer
  3 configuration for the interface used to communicate to engine.
 
  MISSION
 
  Reduce complexity of implementation, so that only one algorithm is
  used in order

Re: [vdsm] Future of Vdsm network configuration - Thread mid-summary

[Alon Bar-Lev]

- Original Message -
 From: Itamar Heim ih...@redhat.com
 To: Alon Bar-Lev alo...@redhat.com
 Cc: Livnat Peer lp...@redhat.com, VDSM Project Development 
 vdsm-devel@lists.fedorahosted.org
 Sent: Tuesday, November 27, 2012 10:19:51 PM
 Subject: Re: [vdsm] Future of Vdsm network configuration - Thread mid-summary
 
 On 11/27/2012 03:17 PM, Alon Bar-Lev wrote:
 
 
  - Original Message -
  From: Itamar Heim ih...@redhat.com
  To: Alon Bar-Lev alo...@redhat.com
  Cc: Livnat Peer lp...@redhat.com, VDSM Project Development
  vdsm-devel@lists.fedorahosted.org
  Sent: Tuesday, November 27, 2012 10:08:34 PM
  Subject: Re: [vdsm] Future of Vdsm network configuration - Thread
  mid-summary
 
  On 11/26/2012 03:18 PM, Alon Bar-Lev wrote:
 
 
  - Original Message -
  From: Livnat Peer lp...@redhat.com
  To: Shu Ming shum...@linux.vnet.ibm.com
  Cc: Alon Bar-Lev abar...@redhat.com, VDSM Project
  Development vdsm-devel@lists.fedorahosted.org
  Sent: Monday, November 26, 2012 2:57:19 PM
  Subject: Re: [vdsm] Future of Vdsm network configuration -
  Thread
  mid-summary
 
  On 26/11/12 03:15, Shu Ming wrote:
  Livnat,
 
  Thanks for your summary.  I got comments below.
 
  2012-11-25 18:53, Livnat Peer:
  Hi All,
  We have been discussing $subject for a while and I'd like to
  summarized
  what we agreed and disagreed on thus far.
 
  The way I see it there are two related discussions:
 
 
  1. Getting VDSM networking stack to be distribution agnostic.
  - We are all in agreement that VDSM API should be generic
  enough
  to
  incorporate multiple implementation. (discussed on this
  thread:
  Alon's
  suggestion, Mark's patch for adding support for netcf etc.)
 
  - We would like to maintain at least one implementation as the
  working/up-to-date implementation for our users, this
  implementation
  should be distribution agnostic (as we all acknowledge this is
  an
  important goal for VDSM).
  I also think that with the agreement of this community we can
  choose to
  change our focus, from time to time, from one implementation
  to
  another
  as we see fit (today it can be OVS+netcf and in a few months
  we'll
  use
  the quantum based implementation if we agree it is better)
 
  2. The second discussion is about persisting the network
  configuration
  on the host vs. dynamically retrieving it from a centralized
  location
  like the engine. Danken raised a concern that even if going
  with
  the
  dynamic approach the host should persist the management
  network
  configuration.
 
  About dynamical retrieving from a centralized location,  when
  will
  the
  retrieving start? Just in the very early stage of host booting
  before
  network functions?  Or after the host startup and in the normal
  running
  state of the host?  Before retrieving the configuration,  how
  does
  the
  host network connecting to the engine? I think we need a basic
  well
  known network between hosts and the engine first.  Then after
  the
  retrieving, hosts should reconfigure the network for later
  management.
  However, the timing to retrieve and reconfigure are
  challenging.
 
 
  We did not discuss the dynamic approach in details on the list
  so
  far
  and I think this is a good opportunity to start this
  discussion...
 
From what was discussed previously I can say that the need for
a
well
  known network was raised by danken, it was referred to as the
  management
  network, this network would be used for pulling the full host
  network
  configuration from the centralized location, at this point the
  engine.
 
  About the timing for retrieving the configuration, there are
  several
  approaches. One of them was described by Alon, and I think he'll
  join
  this discussion and maybe put it in his own words, but the idea
  was
  to
  'keep' the network synchronized at all times. When the host have
  communication channel to the engine and the engine detects there
  is a
  mismatch in the host configuration, the engine initiates 'apply
  network
  configuration' action on the host.
 
  Using this approach we'll have a single path of code to maintain
  and
  that would reduce code complexity and bugs - That's quoting Alon
  Bar
  Lev
  (Alon I hope I did not twisted your words/idea).
 
  On the other hand the above approach makes local tweaks on the
  host
  (done manually by the administrator) much harder.
 
  Any other approaches ?
 
  I'd like to add a more general question to the discussion what
  are
  the
  advantages of taking the dynamic approach?
  So far I collected two reasons:
 
  -It is a 'cleaner' design, removes complexity on VDSM code,
  easier
  to
  maintain going forward, and less bug prone (I agree with that
  one,
  as
  long as we keep the retrieving configuration mechanism/algorithm
  simple).
 
  -It adheres to the idea of having a stateless hypervisor - some
  more
  input on this point would be appreciated
 
  Any other advantages?
 
  discussing the benefits

Re: [vdsm] Future of Vdsm network configuration - Thread mid-summary

[Livnat Peer]

On 26/11/12 03:15, Shu Ming wrote:
 Livnat,
 
 Thanks for your summary.  I got comments below.
 
 2012-11-25 18:53, Livnat Peer:
 Hi All,
 We have been discussing $subject for a while and I'd like to summarized
 what we agreed and disagreed on thus far.

 The way I see it there are two related discussions:


 1. Getting VDSM networking stack to be distribution agnostic.
 - We are all in agreement that VDSM API should be generic enough to
 incorporate multiple implementation. (discussed on this thread: Alon's
 suggestion, Mark's patch for adding support for netcf etc.)

 - We would like to maintain at least one implementation as the
 working/up-to-date implementation for our users, this implementation
 should be distribution agnostic (as we all acknowledge this is an
 important goal for VDSM).
 I also think that with the agreement of this community we can choose to
 change our focus, from time to time, from one implementation to another
 as we see fit (today it can be OVS+netcf and in a few months we'll use
 the quantum based implementation if we agree it is better)

 2. The second discussion is about persisting the network configuration
 on the host vs. dynamically retrieving it from a centralized location
 like the engine. Danken raised a concern that even if going with the
 dynamic approach the host should persist the management network
 configuration.
 
 About dynamical retrieving from a centralized location,  when will the
 retrieving start? Just in the very early stage of host booting before
 network functions?  Or after the host startup and in the normal running
 state of the host?  Before retrieving the configuration,  how does the
 host network connecting to the engine? I think we need a basic well
 known network between hosts and the engine first.  Then after the
 retrieving, hosts should reconfigure the network for later management.
 However, the timing to retrieve and reconfigure are challenging.
 

We did not discuss the dynamic approach in details on the list so far
and I think this is a good opportunity to start this discussion...

From what was discussed previously I can say that the need for a well
known network was raised by danken, it was referred to as the management
network, this network would be used for pulling the full host network
configuration from the centralized location, at this point the engine.

About the timing for retrieving the configuration, there are several
approaches. One of them was described by Alon, and I think he'll join
this discussion and maybe put it in his own words, but the idea was to
'keep' the network synchronized at all times. When the host have
communication channel to the engine and the engine detects there is a
mismatch in the host configuration, the engine initiates 'apply network
configuration' action on the host.

Using this approach we'll have a single path of code to maintain and
that would reduce code complexity and bugs - That's quoting Alon Bar Lev
(Alon I hope I did not twisted your words/idea).

On the other hand the above approach makes local tweaks on the host
(done manually by the administrator) much harder.

Any other approaches ?

I'd like to add a more general question to the discussion what are the
advantages of taking the dynamic approach?
So far I collected two reasons:

-It is a 'cleaner' design, removes complexity on VDSM code, easier to
maintain going forward, and less bug prone (I agree with that one, as
long as we keep the retrieving configuration mechanism/algorithm simple).

-It adheres to the idea of having a stateless hypervisor - some more
input on this point would be appreciated

Any other advantages?

discussing the benefits of having the persisted

Livnat

___
vdsm-devel mailing list
vdsm-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel

Re: [vdsm] Future of Vdsm network configuration - Thread mid-summary

[Adam Litke]

On Mon, Nov 26, 2012 at 02:57:19PM +0200, Livnat Peer wrote:
 On 26/11/12 03:15, Shu Ming wrote:
  Livnat,
  
  Thanks for your summary.  I got comments below.
  
  2012-11-25 18:53, Livnat Peer:
  Hi All,
  We have been discussing $subject for a while and I'd like to summarized
  what we agreed and disagreed on thus far.
 
  The way I see it there are two related discussions:
 
 
  1. Getting VDSM networking stack to be distribution agnostic.
  - We are all in agreement that VDSM API should be generic enough to
  incorporate multiple implementation. (discussed on this thread: Alon's
  suggestion, Mark's patch for adding support for netcf etc.)
 
  - We would like to maintain at least one implementation as the
  working/up-to-date implementation for our users, this implementation
  should be distribution agnostic (as we all acknowledge this is an
  important goal for VDSM).
  I also think that with the agreement of this community we can choose to
  change our focus, from time to time, from one implementation to another
  as we see fit (today it can be OVS+netcf and in a few months we'll use
  the quantum based implementation if we agree it is better)
 
  2. The second discussion is about persisting the network configuration
  on the host vs. dynamically retrieving it from a centralized location
  like the engine. Danken raised a concern that even if going with the
  dynamic approach the host should persist the management network
  configuration.
  
  About dynamical retrieving from a centralized location,  when will the
  retrieving start? Just in the very early stage of host booting before
  network functions?  Or after the host startup and in the normal running
  state of the host?  Before retrieving the configuration,  how does the
  host network connecting to the engine? I think we need a basic well
  known network between hosts and the engine first.  Then after the
  retrieving, hosts should reconfigure the network for later management.
  However, the timing to retrieve and reconfigure are challenging.
  
 
 We did not discuss the dynamic approach in details on the list so far
 and I think this is a good opportunity to start this discussion...
 
 From what was discussed previously I can say that the need for a well
 known network was raised by danken, it was referred to as the management
 network, this network would be used for pulling the full host network
 configuration from the centralized location, at this point the engine.
 
 About the timing for retrieving the configuration, there are several
 approaches. One of them was described by Alon, and I think he'll join
 this discussion and maybe put it in his own words, but the idea was to
 'keep' the network synchronized at all times. When the host have
 communication channel to the engine and the engine detects there is a
 mismatch in the host configuration, the engine initiates 'apply network
 configuration' action on the host.
 
 Using this approach we'll have a single path of code to maintain and
 that would reduce code complexity and bugs - That's quoting Alon Bar Lev
 (Alon I hope I did not twisted your words/idea).
 
 On the other hand the above approach makes local tweaks on the host
 (done manually by the administrator) much harder.

I worry a lot about the above if we take the dynamic approach.  It seems we'd
need to introduce before/after 'apply network configuration' hooks where the
admin could add custom config commands that aren't yet modeled by engine.

 Any other approaches ?

Static configuration has the advantage of allowing a host to bring itself back
online independent of the engine.  This is also useful for anyone who may want
to deploy a vdsm node in standalone mode.

I think it would be possible to easily support a quasi-static configuration mode
simply by extending the design of the dynamic approach slightly.  In dynamic
mode, the network configuration is passed down as a well-defined data structure.
When a particular configuration has been committed, vdsm could write a copy of
that configuration data structure to /var/run/vdsm/network-config.json.  During
a subsequent boot, if the engine cannot be contacted after activating the
management network, the cached configuration can be applied using the same code
as for dynamic mode.  We'd have to flesh out the circumstances under which this
would happen. 

 
 I'd like to add a more general question to the discussion what are the
 advantages of taking the dynamic approach?
 So far I collected two reasons:
 
 -It is a 'cleaner' design, removes complexity on VDSM code, easier to
 maintain going forward, and less bug prone (I agree with that one, as
 long as we keep the retrieving configuration mechanism/algorithm simple).
 
 -It adheres to the idea of having a stateless hypervisor - some more
 input on this point would be appreciated
 
 Any other advantages?
 
 discussing the benefits of having the persisted

As I mentioned above, the main benefit I see of having some sort of 

Re: [vdsm] Future of Vdsm network configuration - Thread mid-summary

[Alon Bar-Lev]

- Original Message -
 From: Livnat Peer lp...@redhat.com
 To: Shu Ming shum...@linux.vnet.ibm.com
 Cc: Alon Bar-Lev abar...@redhat.com, VDSM Project Development 
 vdsm-devel@lists.fedorahosted.org
 Sent: Monday, November 26, 2012 2:57:19 PM
 Subject: Re: [vdsm] Future of Vdsm network configuration - Thread mid-summary
 
 On 26/11/12 03:15, Shu Ming wrote:
  Livnat,
  
  Thanks for your summary.  I got comments below.
  
  2012-11-25 18:53, Livnat Peer:
  Hi All,
  We have been discussing $subject for a while and I'd like to
  summarized
  what we agreed and disagreed on thus far.
 
  The way I see it there are two related discussions:
 
 
  1. Getting VDSM networking stack to be distribution agnostic.
  - We are all in agreement that VDSM API should be generic enough
  to
  incorporate multiple implementation. (discussed on this thread:
  Alon's
  suggestion, Mark's patch for adding support for netcf etc.)
 
  - We would like to maintain at least one implementation as the
  working/up-to-date implementation for our users, this
  implementation
  should be distribution agnostic (as we all acknowledge this is an
  important goal for VDSM).
  I also think that with the agreement of this community we can
  choose to
  change our focus, from time to time, from one implementation to
  another
  as we see fit (today it can be OVS+netcf and in a few months we'll
  use
  the quantum based implementation if we agree it is better)
 
  2. The second discussion is about persisting the network
  configuration
  on the host vs. dynamically retrieving it from a centralized
  location
  like the engine. Danken raised a concern that even if going with
  the
  dynamic approach the host should persist the management network
  configuration.
  
  About dynamical retrieving from a centralized location,  when will
  the
  retrieving start? Just in the very early stage of host booting
  before
  network functions?  Or after the host startup and in the normal
  running
  state of the host?  Before retrieving the configuration,  how does
  the
  host network connecting to the engine? I think we need a basic well
  known network between hosts and the engine first.  Then after the
  retrieving, hosts should reconfigure the network for later
  management.
  However, the timing to retrieve and reconfigure are challenging.
  
 
 We did not discuss the dynamic approach in details on the list so far
 and I think this is a good opportunity to start this discussion...
 
 From what was discussed previously I can say that the need for a well
 known network was raised by danken, it was referred to as the
 management
 network, this network would be used for pulling the full host network
 configuration from the centralized location, at this point the
 engine.
 
 About the timing for retrieving the configuration, there are several
 approaches. One of them was described by Alon, and I think he'll join
 this discussion and maybe put it in his own words, but the idea was
 to
 'keep' the network synchronized at all times. When the host have
 communication channel to the engine and the engine detects there is a
 mismatch in the host configuration, the engine initiates 'apply
 network
 configuration' action on the host.
 
 Using this approach we'll have a single path of code to maintain and
 that would reduce code complexity and bugs - That's quoting Alon Bar
 Lev
 (Alon I hope I did not twisted your words/idea).
 
 On the other hand the above approach makes local tweaks on the host
 (done manually by the administrator) much harder.
 
 Any other approaches ?
 
 I'd like to add a more general question to the discussion what are
 the
 advantages of taking the dynamic approach?
 So far I collected two reasons:
 
 -It is a 'cleaner' design, removes complexity on VDSM code, easier to
 maintain going forward, and less bug prone (I agree with that one, as
 long as we keep the retrieving configuration mechanism/algorithm
 simple).
 
 -It adheres to the idea of having a stateless hypervisor - some more
 input on this point would be appreciated
 
 Any other advantages?
 
 discussing the benefits of having the persisted
 
 Livnat
 

Sorry for the delay. Some more expansion.

ASSUMPTION

After boot a host running vdsm is able to receive communication from engine.
This means that host has legitimate layer 2 configuration and layer 3 
configuration for the interface used to communicate to engine.

MISSION

Reduce complexity of implementation, so that only one algorithm is used in 
order to reach to operative state as far as networking is concerned.

(Storage is extremely similar I can s/network/storage/ and still be relevant).

DESIGN FOCAL POINT

Host running vdsm is a complete slave of its master, will it be ovirt-engine or 
other engine.

Having a complete slave ease implementation:

 1. Master always apply the setting as-is.
 2. No need to consider slave state.
 3. No need to implement AI to reach from unknown state X to known state Y + 
delta.
 4

Re: [vdsm] Future of Vdsm network configuration - Thread mid-summary

[Adam Litke]

Nice writeup!  I like where this is going but see my comments inline below.

On Mon, Nov 26, 2012 at 03:18:22PM -0500, Alon Bar-Lev wrote:
 
 
 - Original Message -
  From: Livnat Peer lp...@redhat.com
  To: Shu Ming shum...@linux.vnet.ibm.com
  Cc: Alon Bar-Lev abar...@redhat.com, VDSM Project Development 
  vdsm-devel@lists.fedorahosted.org
  Sent: Monday, November 26, 2012 2:57:19 PM
  Subject: Re: [vdsm] Future of Vdsm network configuration - Thread 
  mid-summary
  
  On 26/11/12 03:15, Shu Ming wrote:
   Livnat,
   
   Thanks for your summary.  I got comments below.
   
   2012-11-25 18:53, Livnat Peer:
   Hi All,
   We have been discussing $subject for a while and I'd like to
   summarized
   what we agreed and disagreed on thus far.
  
   The way I see it there are two related discussions:
  
  
   1. Getting VDSM networking stack to be distribution agnostic.
   - We are all in agreement that VDSM API should be generic enough
   to
   incorporate multiple implementation. (discussed on this thread:
   Alon's
   suggestion, Mark's patch for adding support for netcf etc.)
  
   - We would like to maintain at least one implementation as the
   working/up-to-date implementation for our users, this
   implementation
   should be distribution agnostic (as we all acknowledge this is an
   important goal for VDSM).
   I also think that with the agreement of this community we can
   choose to
   change our focus, from time to time, from one implementation to
   another
   as we see fit (today it can be OVS+netcf and in a few months we'll
   use
   the quantum based implementation if we agree it is better)
  
   2. The second discussion is about persisting the network
   configuration
   on the host vs. dynamically retrieving it from a centralized
   location
   like the engine. Danken raised a concern that even if going with
   the
   dynamic approach the host should persist the management network
   configuration.
   
   About dynamical retrieving from a centralized location,  when will
   the
   retrieving start? Just in the very early stage of host booting
   before
   network functions?  Or after the host startup and in the normal
   running
   state of the host?  Before retrieving the configuration,  how does
   the
   host network connecting to the engine? I think we need a basic well
   known network between hosts and the engine first.  Then after the
   retrieving, hosts should reconfigure the network for later
   management.
   However, the timing to retrieve and reconfigure are challenging.
   
  
  We did not discuss the dynamic approach in details on the list so far
  and I think this is a good opportunity to start this discussion...
  
  From what was discussed previously I can say that the need for a well
  known network was raised by danken, it was referred to as the
  management
  network, this network would be used for pulling the full host network
  configuration from the centralized location, at this point the
  engine.
  
  About the timing for retrieving the configuration, there are several
  approaches. One of them was described by Alon, and I think he'll join
  this discussion and maybe put it in his own words, but the idea was
  to
  'keep' the network synchronized at all times. When the host have
  communication channel to the engine and the engine detects there is a
  mismatch in the host configuration, the engine initiates 'apply
  network
  configuration' action on the host.
  
  Using this approach we'll have a single path of code to maintain and
  that would reduce code complexity and bugs - That's quoting Alon Bar
  Lev
  (Alon I hope I did not twisted your words/idea).
  
  On the other hand the above approach makes local tweaks on the host
  (done manually by the administrator) much harder.
  
  Any other approaches ?
  
  I'd like to add a more general question to the discussion what are
  the
  advantages of taking the dynamic approach?
  So far I collected two reasons:
  
  -It is a 'cleaner' design, removes complexity on VDSM code, easier to
  maintain going forward, and less bug prone (I agree with that one, as
  long as we keep the retrieving configuration mechanism/algorithm
  simple).
  
  -It adheres to the idea of having a stateless hypervisor - some more
  input on this point would be appreciated
  
  Any other advantages?
  
  discussing the benefits of having the persisted
  
  Livnat
  
 
 Sorry for the delay. Some more expansion.
 
 ASSUMPTION
 
 After boot a host running vdsm is able to receive communication from engine.
 This means that host has legitimate layer 2 configuration and layer 3
 configuration for the interface used to communicate to engine.
 
 MISSION
 
 Reduce complexity of implementation, so that only one algorithm is used in
 order to reach to operative state as far as networking is concerned.
 
 (Storage is extremely similar I can s/network/storage/ and still be relevant).
 
 DESIGN FOCAL POINT
 
 Host running vdsm is a complete slave

Re: [vdsm] Future of Vdsm network configuration - Thread mid-summary

[Alon Bar-Lev]

Hello,

- Original Message -
 From: Adam Litke a...@us.ibm.com
 To: Alon Bar-Lev alo...@redhat.com
 Cc: Livnat Peer lp...@redhat.com, VDSM Project Development 
 vdsm-devel@lists.fedorahosted.org
 Sent: Tuesday, November 27, 2012 12:51:36 AM
 Subject: Re: [vdsm] Future of Vdsm network configuration - Thread mid-summary
 
 Nice writeup!  I like where this is going but see my comments inline
 below.
 
 On Mon, Nov 26, 2012 at 03:18:22PM -0500, Alon Bar-Lev wrote:
  
  
  - Original Message -
   From: Livnat Peer lp...@redhat.com
   To: Shu Ming shum...@linux.vnet.ibm.com
   Cc: Alon Bar-Lev abar...@redhat.com, VDSM Project
   Development vdsm-devel@lists.fedorahosted.org
   Sent: Monday, November 26, 2012 2:57:19 PM
   Subject: Re: [vdsm] Future of Vdsm network configuration - Thread
   mid-summary
   
   On 26/11/12 03:15, Shu Ming wrote:
Livnat,

Thanks for your summary.  I got comments below.

2012-11-25 18:53, Livnat Peer:
Hi All,
We have been discussing $subject for a while and I'd like to
summarized
what we agreed and disagreed on thus far.
   
The way I see it there are two related discussions:
   
   
1. Getting VDSM networking stack to be distribution agnostic.
- We are all in agreement that VDSM API should be generic
enough
to
incorporate multiple implementation. (discussed on this
thread:
Alon's
suggestion, Mark's patch for adding support for netcf etc.)
   
- We would like to maintain at least one implementation as the
working/up-to-date implementation for our users, this
implementation
should be distribution agnostic (as we all acknowledge this is
an
important goal for VDSM).
I also think that with the agreement of this community we can
choose to
change our focus, from time to time, from one implementation
to
another
as we see fit (today it can be OVS+netcf and in a few months
we'll
use
the quantum based implementation if we agree it is better)
   
2. The second discussion is about persisting the network
configuration
on the host vs. dynamically retrieving it from a centralized
location
like the engine. Danken raised a concern that even if going
with
the
dynamic approach the host should persist the management
network
configuration.

About dynamical retrieving from a centralized location,  when
will
the
retrieving start? Just in the very early stage of host booting
before
network functions?  Or after the host startup and in the normal
running
state of the host?  Before retrieving the configuration,  how
does
the
host network connecting to the engine? I think we need a basic
well
known network between hosts and the engine first.  Then after
the
retrieving, hosts should reconfigure the network for later
management.
However, the timing to retrieve and reconfigure are
challenging.

   
   We did not discuss the dynamic approach in details on the list so
   far
   and I think this is a good opportunity to start this
   discussion...
   
   From what was discussed previously I can say that the need for a
   well
   known network was raised by danken, it was referred to as the
   management
   network, this network would be used for pulling the full host
   network
   configuration from the centralized location, at this point the
   engine.
   
   About the timing for retrieving the configuration, there are
   several
   approaches. One of them was described by Alon, and I think he'll
   join
   this discussion and maybe put it in his own words, but the idea
   was
   to
   'keep' the network synchronized at all times. When the host have
   communication channel to the engine and the engine detects there
   is a
   mismatch in the host configuration, the engine initiates 'apply
   network
   configuration' action on the host.
   
   Using this approach we'll have a single path of code to maintain
   and
   that would reduce code complexity and bugs - That's quoting Alon
   Bar
   Lev
   (Alon I hope I did not twisted your words/idea).
   
   On the other hand the above approach makes local tweaks on the
   host
   (done manually by the administrator) much harder.
   
   Any other approaches ?
   
   I'd like to add a more general question to the discussion what
   are
   the
   advantages of taking the dynamic approach?
   So far I collected two reasons:
   
   -It is a 'cleaner' design, removes complexity on VDSM code,
   easier to
   maintain going forward, and less bug prone (I agree with that
   one, as
   long as we keep the retrieving configuration mechanism/algorithm
   simple).
   
   -It adheres to the idea of having a stateless hypervisor - some
   more
   input on this point would be appreciated
   
   Any other advantages?
   
   discussing the benefits of having the persisted
   
   Livnat
   
  
  Sorry for the delay. Some

Re: [vdsm] Future of Vdsm network configuration - Thread mid-summary

[Shu Ming]

Livnat,

Thanks for your summary.  I got comments below.

2012-11-25 18:53, Livnat Peer:

Hi All,
We have been discussing $subject for a while and I'd like to summarized
what we agreed and disagreed on thus far.

The way I see it there are two related discussions:


1. Getting VDSM networking stack to be distribution agnostic.
- We are all in agreement that VDSM API should be generic enough to
incorporate multiple implementation. (discussed on this thread: Alon's
suggestion, Mark's patch for adding support for netcf etc.)

- We would like to maintain at least one implementation as the
working/up-to-date implementation for our users, this implementation
should be distribution agnostic (as we all acknowledge this is an
important goal for VDSM).
I also think that with the agreement of this community we can choose to
change our focus, from time to time, from one implementation to another
as we see fit (today it can be OVS+netcf and in a few months we'll use
the quantum based implementation if we agree it is better)

2. The second discussion is about persisting the network configuration
on the host vs. dynamically retrieving it from a centralized location
like the engine. Danken raised a concern that even if going with the
dynamic approach the host should persist the management network
configuration.


About dynamical retrieving from a centralized location,  when will the 
retrieving start? Just in the very early stage of host booting before 
network functions?  Or after the host startup and in the normal running 
state of the host?  Before retrieving the configuration,  how does the 
host network connecting to the engine? I think we need a basic well 
known network between hosts and the engine first.  Then after the 
retrieving, hosts should reconfigure the network for later management. 
However, the timing to retrieve and reconfigure are challenging.





Obviously the second discussion influences the API modeling. Since I
think it would be challenging to add support for generic API and change
the current implementation to match the dynamic configuration approach
simultaneously I suggest we'll focus our efforts on one change at a time.

I suggest to have a discussion on the pro's and con's of dynamic
configuration and after we get to a consensus around that we can start
modeling the generic API.

thoughts? comments?

Livnat
___
vdsm-devel mailing list
vdsm-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel



--
---
舒明 Shu Ming
Open Virtualization Engineerning; CSTL, IBM Corp.
Tel: 86-10-82451626  Tieline: 9051626 E-mail: shum...@cn.ibm.com or 
shum...@linux.vnet.ibm.com
Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District, 
Beijing 100193, PRC


___
vdsm-devel mailing list
vdsm-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel