Re: [vdsm] Back to future of vdsm network configuration
- 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, Simon Grinberg si...@redhat.com, Andrew Cathrow acath...@redhat.com Sent: Monday, December 3, 2012 10:56:53 PM Subject: Re: [vdsm] Back to future of vdsm network configuration On 12/03/2012 06:54 PM, Dan Kenigsberg wrote: On Mon, Dec 03, 2012 at 04:28:16PM +0200, Itamar Heim wrote: On 12/03/2012 04:25 PM, Dan Kenigsberg wrote: On Mon, Dec 03, 2012 at 04:35:34AM -0500, Alon Bar-Lev wrote: - Original Message - From: Mark Wu wu...@linux.vnet.ibm.com To: VDSM Project Development vdsm-devel@lists.fedorahosted.org Cc: Alon Bar-Lev alo...@redhat.com, Dan Kenigsberg dan...@redhat.com, Simon Grinberg si...@redhat.com, Antoni Segura Puimedon asegu...@redhat.com, Igor Lvovsky ilvov...@redhat.com, Daniel P. Berrange berra...@redhat.com Sent: Monday, December 3, 2012 7:39:49 AM Subject: Re: [vdsm] Back to future of vdsm network configuration On 11/29/2012 04:24 AM, Alon Bar-Lev wrote: - Original Message - From: Dan Kenigsberg dan...@redhat.com To: Alon Bar-Lev alo...@redhat.com Cc: Simon Grinberg si...@redhat.com, VDSM Project Development vdsm-devel@lists.fedorahosted.org Sent: Wednesday, November 28, 2012 10:20:11 PM Subject: Re: [vdsm] MTU setting according to ifcfg files. On Wed, Nov 28, 2012 at 12:49:10PM -0500, Alon Bar-Lev wrote: Itamar though a bomb that we should co-exist on generic host, this is something I do not know to compute. I still waiting for a response of where this requirement came from and if that mandatory. This bomb has been ticking since ever. We have ovirt-node images for pure hypervisor nodes, but we support plain Linux nodes, where local admins are free to `yum upgrade` in the least convenient moment. The latter mode can be the stuff that nightmares are made of, but it also allows the flexibility and bleeding-endgeness we all cherish. There is a different between having generic OS and having generic setup, running your email server, file server and LDAP on a node that running VMs. I have no problem in having generic OS (opposed of ovirt-node) but have full control over that. Alon. Can I say we have got agreement on oVirt should cover two kinds of hypervisors? Stateless slave is good for pure and normal virtualization workload, while generic host can keep the flexibility of customization. In my opinion, it's good for the oVirt community to provide choices for users. They could customize it in production, building and even source code according to their requirements and skills. I also think it will be good to support both modes! It will also good if we can rule the world! :) Now seriously... :) If we want to ever have a working solution we need to focus, dropping wishful requirements in favour of the minimum required that will allow us to reach to stable milestone. Having a good clean interface for vdsm network within the stateless mode, will allow a persistent implementation to exists even if the whole implementation of master and vdsm assume stateless. This kind of implementation will get a new state from master, compare to whatever exists on the host and sync. I, of course, will be against investing resources in such network management plugin approach... but it is doable, and my vote is not something that you cannot safely ignore. I cannot say that I do not fail to parse English sentences with double or triple negations... I'd like to see an API that lets us define a persistent initial management interface, and create volatile network devices during runtime. I'd love to see a define/create distiction, as libvirt has. How about keeping our current setupNetwork API, with a minor change to its sematics - it would not persist anything. A new persistNetwork API would be added, intending to persist the management network after it has been tested. On boot, only the management defitions would show up, and Engine (or a small local sevice on top of vdsm) would push the complete configuration. how does this benefit over loading the last config, and then have engine refresh (always/if needed)? It's clearer for the local admin: if it's on the file system, it would be there after boot; he can do his worst to them, and we'd try to manage. Also, it is easier to recover from utterly-horrible remote commands, which had rendered our host incommunicado: the management interface used to send these commands -- and only it -- would show up after boot. This increases the probability that after fencing, we'd see the host again. i think we mentioned this before, but this will kill any way to have hosts come back
Re: [vdsm] Back to future of vdsm network configuration
On 12/04/2012 07:49 PM, Simon Grinberg 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, Simon Grinberg si...@redhat.com, Andrew Cathrow acath...@redhat.com Sent: Monday, December 3, 2012 10:56:53 PM Subject: Re: [vdsm] Back to future of vdsm network configuration On 12/03/2012 06:54 PM, Dan Kenigsberg wrote: On Mon, Dec 03, 2012 at 04:28:16PM +0200, Itamar Heim wrote: On 12/03/2012 04:25 PM, Dan Kenigsberg wrote: On Mon, Dec 03, 2012 at 04:35:34AM -0500, Alon Bar-Lev wrote: - Original Message - From: Mark Wu wu...@linux.vnet.ibm.com To: VDSM Project Development vdsm-devel@lists.fedorahosted.org Cc: Alon Bar-Lev alo...@redhat.com, Dan Kenigsberg dan...@redhat.com, Simon Grinberg si...@redhat.com, Antoni Segura Puimedon asegu...@redhat.com, Igor Lvovsky ilvov...@redhat.com, Daniel P. Berrange berra...@redhat.com Sent: Monday, December 3, 2012 7:39:49 AM Subject: Re: [vdsm] Back to future of vdsm network configuration On 11/29/2012 04:24 AM, Alon Bar-Lev wrote: - Original Message - From: Dan Kenigsberg dan...@redhat.com To: Alon Bar-Lev alo...@redhat.com Cc: Simon Grinberg si...@redhat.com, VDSM Project Development vdsm-devel@lists.fedorahosted.org Sent: Wednesday, November 28, 2012 10:20:11 PM Subject: Re: [vdsm] MTU setting according to ifcfg files. On Wed, Nov 28, 2012 at 12:49:10PM -0500, Alon Bar-Lev wrote: Itamar though a bomb that we should co-exist on generic host, this is something I do not know to compute. I still waiting for a response of where this requirement came from and if that mandatory. This bomb has been ticking since ever. We have ovirt-node images for pure hypervisor nodes, but we support plain Linux nodes, where local admins are free to `yum upgrade` in the least convenient moment. The latter mode can be the stuff that nightmares are made of, but it also allows the flexibility and bleeding-endgeness we all cherish. There is a different between having generic OS and having generic setup, running your email server, file server and LDAP on a node that running VMs. I have no problem in having generic OS (opposed of ovirt-node) but have full control over that. Alon. Can I say we have got agreement on oVirt should cover two kinds of hypervisors? Stateless slave is good for pure and normal virtualization workload, while generic host can keep the flexibility of customization. In my opinion, it's good for the oVirt community to provide choices for users. They could customize it in production, building and even source code according to their requirements and skills. I also think it will be good to support both modes! It will also good if we can rule the world! :) Now seriously... :) If we want to ever have a working solution we need to focus, dropping wishful requirements in favour of the minimum required that will allow us to reach to stable milestone. Having a good clean interface for vdsm network within the stateless mode, will allow a persistent implementation to exists even if the whole implementation of master and vdsm assume stateless. This kind of implementation will get a new state from master, compare to whatever exists on the host and sync. I, of course, will be against investing resources in such network management plugin approach... but it is doable, and my vote is not something that you cannot safely ignore. I cannot say that I do not fail to parse English sentences with double or triple negations... I'd like to see an API that lets us define a persistent initial management interface, and create volatile network devices during runtime. I'd love to see a define/create distiction, as libvirt has. How about keeping our current setupNetwork API, with a minor change to its sematics - it would not persist anything. A new persistNetwork API would be added, intending to persist the management network after it has been tested. On boot, only the management defitions would show up, and Engine (or a small local sevice on top of vdsm) would push the complete configuration. how does this benefit over loading the last config, and then have engine refresh (always/if needed)? It's clearer for the local admin: if it's on the file system, it would be there after boot; he can do his worst to them, and we'd try to manage. Also, it is easier to recover from utterly-horrible remote commands, which had rendered our host incommunicado: the management interface used to send these commands -- and only it -- would show up after boot. This increases the probability that after fencing, we'd see the host again. i think we mentioned this before, but this will kill any way to have hosts come back to life, also have a policy on connecting to storage, even if engine is still down. (one of these use cases is for the engine itself to be hosted on the hosts as well) For this use case you'll need much
Re: [vdsm] Back to future of vdsm network configuration
On 12/03/2012 04:25 PM, Dan Kenigsberg wrote: On Mon, Dec 03, 2012 at 04:35:34AM -0500, Alon Bar-Lev wrote: - Original Message - From: Mark Wu wu...@linux.vnet.ibm.com To: VDSM Project Development vdsm-devel@lists.fedorahosted.org Cc: Alon Bar-Lev alo...@redhat.com, Dan Kenigsberg dan...@redhat.com, Simon Grinberg si...@redhat.com, Antoni Segura Puimedon asegu...@redhat.com, Igor Lvovsky ilvov...@redhat.com, Daniel P. Berrange berra...@redhat.com Sent: Monday, December 3, 2012 7:39:49 AM Subject: Re: [vdsm] Back to future of vdsm network configuration On 11/29/2012 04:24 AM, Alon Bar-Lev wrote: - Original Message - From: Dan Kenigsberg dan...@redhat.com To: Alon Bar-Lev alo...@redhat.com Cc: Simon Grinberg si...@redhat.com, VDSM Project Development vdsm-devel@lists.fedorahosted.org Sent: Wednesday, November 28, 2012 10:20:11 PM Subject: Re: [vdsm] MTU setting according to ifcfg files. On Wed, Nov 28, 2012 at 12:49:10PM -0500, Alon Bar-Lev wrote: Itamar though a bomb that we should co-exist on generic host, this is something I do not know to compute. I still waiting for a response of where this requirement came from and if that mandatory. This bomb has been ticking since ever. We have ovirt-node images for pure hypervisor nodes, but we support plain Linux nodes, where local admins are free to `yum upgrade` in the least convenient moment. The latter mode can be the stuff that nightmares are made of, but it also allows the flexibility and bleeding-endgeness we all cherish. There is a different between having generic OS and having generic setup, running your email server, file server and LDAP on a node that running VMs. I have no problem in having generic OS (opposed of ovirt-node) but have full control over that. Alon. Can I say we have got agreement on oVirt should cover two kinds of hypervisors? Stateless slave is good for pure and normal virtualization workload, while generic host can keep the flexibility of customization. In my opinion, it's good for the oVirt community to provide choices for users. They could customize it in production, building and even source code according to their requirements and skills. I also think it will be good to support both modes! It will also good if we can rule the world! :) Now seriously... :) If we want to ever have a working solution we need to focus, dropping wishful requirements in favour of the minimum required that will allow us to reach to stable milestone. Having a good clean interface for vdsm network within the stateless mode, will allow a persistent implementation to exists even if the whole implementation of master and vdsm assume stateless. This kind of implementation will get a new state from master, compare to whatever exists on the host and sync. I, of course, will be against investing resources in such network management plugin approach... but it is doable, and my vote is not something that you cannot safely ignore. I cannot say that I do not fail to parse English sentences with double or triple negations... I'd like to see an API that lets us define a persistent initial management interface, and create volatile network devices during runtime. I'd love to see a define/create distiction, as libvirt has. How about keeping our current setupNetwork API, with a minor change to its sematics - it would not persist anything. A new persistNetwork API would be added, intending to persist the management network after it has been tested. On boot, only the management defitions would show up, and Engine (or a small local sevice on top of vdsm) would push the complete configuration. how does this benefit over loading the last config, and then have engine refresh (always/if needed)? setSafeNetConfig, and the rollback-on-boot mess would be scrapped. The only little problem would be to implement setupNetwork without playing with persisted ifcfg* files. Having said that, let's come back to your original claim: while generic host can keep the flexibility of customization. NOBODY, and I repeat my answer to Dan, NOBODY claim we should not support generic host. But the term 'generic' seems to confuse everyone... generic is a a host does not mean administrator can do whatever he likes, it just a host that is installed using standard distribution installation procedure. Using 'generic host' can be done with either stateful or stateless modes. However what and how customization can be done to a resource that is managed by VDSM (eg: storage, network) is a complete different question. There cannot be two managers to the same resource, it is a rule of thumb, any other approach is non-deterministic and may lead to huge resource investment with almost no benefit, as it will never be stable. So moving back to the discussion network configuration, I would like to suggest we could adopt both of the two solutions. dynamic way (as Alon suggested in his previous mail.) -- for oVirt node. It will take a step
Re: [vdsm] Back to future of vdsm network configuration
On Mon, Dec 03, 2012 at 04:28:16PM +0200, Itamar Heim wrote: On 12/03/2012 04:25 PM, Dan Kenigsberg wrote: On Mon, Dec 03, 2012 at 04:35:34AM -0500, Alon Bar-Lev wrote: - Original Message - From: Mark Wu wu...@linux.vnet.ibm.com To: VDSM Project Development vdsm-devel@lists.fedorahosted.org Cc: Alon Bar-Lev alo...@redhat.com, Dan Kenigsberg dan...@redhat.com, Simon Grinberg si...@redhat.com, Antoni Segura Puimedon asegu...@redhat.com, Igor Lvovsky ilvov...@redhat.com, Daniel P. Berrange berra...@redhat.com Sent: Monday, December 3, 2012 7:39:49 AM Subject: Re: [vdsm] Back to future of vdsm network configuration On 11/29/2012 04:24 AM, Alon Bar-Lev wrote: - Original Message - From: Dan Kenigsberg dan...@redhat.com To: Alon Bar-Lev alo...@redhat.com Cc: Simon Grinberg si...@redhat.com, VDSM Project Development vdsm-devel@lists.fedorahosted.org Sent: Wednesday, November 28, 2012 10:20:11 PM Subject: Re: [vdsm] MTU setting according to ifcfg files. On Wed, Nov 28, 2012 at 12:49:10PM -0500, Alon Bar-Lev wrote: Itamar though a bomb that we should co-exist on generic host, this is something I do not know to compute. I still waiting for a response of where this requirement came from and if that mandatory. This bomb has been ticking since ever. We have ovirt-node images for pure hypervisor nodes, but we support plain Linux nodes, where local admins are free to `yum upgrade` in the least convenient moment. The latter mode can be the stuff that nightmares are made of, but it also allows the flexibility and bleeding-endgeness we all cherish. There is a different between having generic OS and having generic setup, running your email server, file server and LDAP on a node that running VMs. I have no problem in having generic OS (opposed of ovirt-node) but have full control over that. Alon. Can I say we have got agreement on oVirt should cover two kinds of hypervisors? Stateless slave is good for pure and normal virtualization workload, while generic host can keep the flexibility of customization. In my opinion, it's good for the oVirt community to provide choices for users. They could customize it in production, building and even source code according to their requirements and skills. I also think it will be good to support both modes! It will also good if we can rule the world! :) Now seriously... :) If we want to ever have a working solution we need to focus, dropping wishful requirements in favour of the minimum required that will allow us to reach to stable milestone. Having a good clean interface for vdsm network within the stateless mode, will allow a persistent implementation to exists even if the whole implementation of master and vdsm assume stateless. This kind of implementation will get a new state from master, compare to whatever exists on the host and sync. I, of course, will be against investing resources in such network management plugin approach... but it is doable, and my vote is not something that you cannot safely ignore. I cannot say that I do not fail to parse English sentences with double or triple negations... I'd like to see an API that lets us define a persistent initial management interface, and create volatile network devices during runtime. I'd love to see a define/create distiction, as libvirt has. How about keeping our current setupNetwork API, with a minor change to its sematics - it would not persist anything. A new persistNetwork API would be added, intending to persist the management network after it has been tested. On boot, only the management defitions would show up, and Engine (or a small local sevice on top of vdsm) would push the complete configuration. how does this benefit over loading the last config, and then have engine refresh (always/if needed)? It's clearer for the local admin: if it's on the file system, it would be there after boot; he can do his worst to them, and we'd try to manage. Also, it is easier to recover from utterly-horrible remote commands, which had rendered our host incommunicado: the management interface used to send these commands -- and only it -- would show up after boot. This increases the probability that after fencing, we'd see the host again. setSafeNetConfig, and the rollback-on-boot mess would be scrapped. The only little problem would be to implement setupNetwork without playing with persisted ifcfg* files. ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] Back to future of vdsm network configuration
On 12/03/2012 06:54 PM, Dan Kenigsberg wrote: On Mon, Dec 03, 2012 at 04:28:16PM +0200, Itamar Heim wrote: On 12/03/2012 04:25 PM, Dan Kenigsberg wrote: On Mon, Dec 03, 2012 at 04:35:34AM -0500, Alon Bar-Lev wrote: - Original Message - From: Mark Wu wu...@linux.vnet.ibm.com To: VDSM Project Development vdsm-devel@lists.fedorahosted.org Cc: Alon Bar-Lev alo...@redhat.com, Dan Kenigsberg dan...@redhat.com, Simon Grinberg si...@redhat.com, Antoni Segura Puimedon asegu...@redhat.com, Igor Lvovsky ilvov...@redhat.com, Daniel P. Berrange berra...@redhat.com Sent: Monday, December 3, 2012 7:39:49 AM Subject: Re: [vdsm] Back to future of vdsm network configuration On 11/29/2012 04:24 AM, Alon Bar-Lev wrote: - Original Message - From: Dan Kenigsberg dan...@redhat.com To: Alon Bar-Lev alo...@redhat.com Cc: Simon Grinberg si...@redhat.com, VDSM Project Development vdsm-devel@lists.fedorahosted.org Sent: Wednesday, November 28, 2012 10:20:11 PM Subject: Re: [vdsm] MTU setting according to ifcfg files. On Wed, Nov 28, 2012 at 12:49:10PM -0500, Alon Bar-Lev wrote: Itamar though a bomb that we should co-exist on generic host, this is something I do not know to compute. I still waiting for a response of where this requirement came from and if that mandatory. This bomb has been ticking since ever. We have ovirt-node images for pure hypervisor nodes, but we support plain Linux nodes, where local admins are free to `yum upgrade` in the least convenient moment. The latter mode can be the stuff that nightmares are made of, but it also allows the flexibility and bleeding-endgeness we all cherish. There is a different between having generic OS and having generic setup, running your email server, file server and LDAP on a node that running VMs. I have no problem in having generic OS (opposed of ovirt-node) but have full control over that. Alon. Can I say we have got agreement on oVirt should cover two kinds of hypervisors? Stateless slave is good for pure and normal virtualization workload, while generic host can keep the flexibility of customization. In my opinion, it's good for the oVirt community to provide choices for users. They could customize it in production, building and even source code according to their requirements and skills. I also think it will be good to support both modes! It will also good if we can rule the world! :) Now seriously... :) If we want to ever have a working solution we need to focus, dropping wishful requirements in favour of the minimum required that will allow us to reach to stable milestone. Having a good clean interface for vdsm network within the stateless mode, will allow a persistent implementation to exists even if the whole implementation of master and vdsm assume stateless. This kind of implementation will get a new state from master, compare to whatever exists on the host and sync. I, of course, will be against investing resources in such network management plugin approach... but it is doable, and my vote is not something that you cannot safely ignore. I cannot say that I do not fail to parse English sentences with double or triple negations... I'd like to see an API that lets us define a persistent initial management interface, and create volatile network devices during runtime. I'd love to see a define/create distiction, as libvirt has. How about keeping our current setupNetwork API, with a minor change to its sematics - it would not persist anything. A new persistNetwork API would be added, intending to persist the management network after it has been tested. On boot, only the management defitions would show up, and Engine (or a small local sevice on top of vdsm) would push the complete configuration. how does this benefit over loading the last config, and then have engine refresh (always/if needed)? It's clearer for the local admin: if it's on the file system, it would be there after boot; he can do his worst to them, and we'd try to manage. Also, it is easier to recover from utterly-horrible remote commands, which had rendered our host incommunicado: the management interface used to send these commands -- and only it -- would show up after boot. This increases the probability that after fencing, we'd see the host again. i think we mentioned this before, but this will kill any way to have hosts come back to life, also have a policy on connecting to storage, even if engine is still down. (one of these use cases is for the engine itself to be hosted on the hosts as well) ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
