Re: [vdsm] [Engine-devel] [ATTENTION] vdsm-bootstrap/host deployment (pre-3.2)
* Alon Bar-Lev alo...@redhat.com [2012-11-28 14:47]: - Original Message - From: Dan Kenigsberg dan...@redhat.com To: Alon Bar-Lev alo...@redhat.com Cc: VDSM Project Development vdsm-devel@lists.fedorahosted.org, engine-devel engine-de...@ovirt.org, users us...@ovirt.org Sent: Wednesday, November 28, 2012 10:39:42 PM Subject: Re: [vdsm] [ATTENTION] vdsm-bootstrap/host deployment (pre-3.2) On Wed, Nov 28, 2012 at 02:57:17PM -0500, Alon Bar-Lev wrote: No... we need it as compatibility with older engines... We keep minimum changes there for legacy, until end-of-life. Is there an EoL statement for oVirt-3.1? We can make sure that oVirt-3.2's vdsm installs properly with ovirt-3.1's vdsm-bootstrap, or even require that Engine must be upgraded to ovirt-3.2 before upgrading any of the hosts. Is it too harsh to our vast install base? us...@ovirt.org, please chime in! I tried to find such, but the more I dig I find that we need to support old legacy. Why, exactly? Fedora gives no such guarntees (heck, I'm stuck with an unupgradable F16). Should we be any better than our (currently single) platform? We should start and detach from specific distro procedures. * legacy-removed: change machine width core file # echo /var/lib/vdsm/core /proc/sys/kernel/core_pattern Yeah, qemu-kvm and libvirtd are much more stable than in the old days, but wouldn't we want to keep a means to collect the corpses of dead processes from hypervisors? It has helped us nail down nasty bugs, even in Python. It does not mean it should be at /var/lib/vdsm ... :) I don't get the joke :-(. If you mind the location, we can think of somewhere else to put the core dumps. Would it be hard to reinstate a parallel feature in otopi? I usually do not make any jokes... A global system setting should not go into package specific location. Usually core dumps are off by default, I like this approach as unattended system may fast consume all disk space because of dumps. If a host fills up with dumps so quickly, it's a sign that it should not be used for production, and that someone should look into the cores. (P.S. we have a logrotate rule for them in vdsm) There should be a vdsm-debug-aids (or similar) to perform such changes. Again, I don't think vdsm should (by default) modify any system width parameter such as this. But I will happy to hear more views. If sysadmin manually enables dumps, he may do this at a location of his own choice. Note that we've just swapped hats: you're arguing for letting a local admin log in and mess with system configuration, and I'm for keeping a centralized feature for storing and collecting core dumps. As problems like crashes are investigated per case and reproduction scenario. But again, I may be wrong and we should have VDSM API command to start/stop storing dumps and manage this via its master... I very much like this idea. There was a thread a while back discussing[1] the this very idea; I was looking for a way to enable 'debugging' mode as well as a way to programatically collect debugging info (which could include host stats, guest stats, logs and any core files). Certainly in such a scenario, being able to enable/disable varous features of a debugging mode could include whether to enable core dumps as well as where to save them on the host. 1. http://comments.gmane.org/gmane.comp.emulators.ovirt.vdsm.devel/1387 -- Ryan Harper Software Engineer; Linux Technology Center IBM Corp., Austin, Tx ry...@us.ibm.com ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] [Engine-devel] [ATTENTION] vdsm-bootstrap/host deployment (pre-3.2)
* Alon Bar-Lev alo...@redhat.com [2012-11-28 15:33]: Leaving only vdsm-devel. - Original Message - From: Ryan Harper ry...@us.ibm.com To: Alon Bar-Lev alo...@redhat.com Cc: Dan Kenigsberg dan...@redhat.com, engine-devel engine-de...@ovirt.org, VDSM Project Development vdsm-devel@lists.fedorahosted.org, users us...@ovirt.org Sent: Wednesday, November 28, 2012 11:22:59 PM Subject: Re: [Engine-devel] [vdsm] [ATTENTION] vdsm-bootstrap/host deployment (pre-3.2) snip If sysadmin manually enables dumps, he may do this at a location of his own choice. Note that we've just swapped hats: you're arguing for letting a local admin log in and mess with system configuration, and I'm for keeping a centralized feature for storing and collecting core dumps. As problems like crashes are investigated per case and reproduction scenario. But again, I may be wrong and we should have VDSM API command to start/stop storing dumps and manage this via its master... I very much like this idea. There was a thread a while back discussing[1] the this very idea; I was looking for a way to enable 'debugging' mode as well as a way to programatically collect debugging info (which could include host stats, guest stats, logs and any core files). Certainly in such a scenario, being able to enable/disable varous features of a debugging mode could include whether to enable core dumps as well as where to save them on the host. 1. http://comments.gmane.org/gmane.comp.emulators.ovirt.vdsm.devel/1387 Yes, I read this, however, I am unsure that debug and low level collections should be implemented as in-band interface and not side-band. After many of years handling crappy bug reports that don't include the data needed for debugging, such as log files and other settings, and spending weeks going back and forth with the submitter on collecting what and where and how to collect it, I'm confident that having something that can programtically enable debugging on-demand and providing a way to collect the relative data (logs, cores, etc) would make a dramatic improvement when handing these support issues. I'm also a firm believer in lowering the barriers for consumption. IIUC, a side-band tool is going to require additional configuration/authenitication; and will ultimately need to access the API anyhow to determine various information about the specific VM. With that in mind, why wouldn't we want to look at a first-class debug API mode which can be used remotely and programatically? A better question is, what are the drawbacks to having it in-band? -- Ryan Harper Software Engineer; Linux Technology Center IBM Corp., Austin, Tx ry...@us.ibm.com ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] [Engine-devel] [ATTENTION] vdsm-bootstrap/host deployment (pre-3.2)
- Original Message - From: Ryan Harper ry...@us.ibm.com To: Alon Bar-Lev alo...@redhat.com Cc: Ryan Harper ry...@us.ibm.com, Dan Kenigsberg dan...@redhat.com, VDSM Project Development vdsm-devel@lists.fedorahosted.org Sent: Wednesday, November 28, 2012 11:59:29 PM Subject: Re: [Engine-devel] [vdsm] [ATTENTION] vdsm-bootstrap/host deployment (pre-3.2) * Alon Bar-Lev alo...@redhat.com [2012-11-28 15:33]: Leaving only vdsm-devel. - Original Message - From: Ryan Harper ry...@us.ibm.com To: Alon Bar-Lev alo...@redhat.com Cc: Dan Kenigsberg dan...@redhat.com, engine-devel engine-de...@ovirt.org, VDSM Project Development vdsm-devel@lists.fedorahosted.org, users us...@ovirt.org Sent: Wednesday, November 28, 2012 11:22:59 PM Subject: Re: [Engine-devel] [vdsm] [ATTENTION] vdsm-bootstrap/host deployment (pre-3.2) snip If sysadmin manually enables dumps, he may do this at a location of his own choice. Note that we've just swapped hats: you're arguing for letting a local admin log in and mess with system configuration, and I'm for keeping a centralized feature for storing and collecting core dumps. As problems like crashes are investigated per case and reproduction scenario. But again, I may be wrong and we should have VDSM API command to start/stop storing dumps and manage this via its master... I very much like this idea. There was a thread a while back discussing[1] the this very idea; I was looking for a way to enable 'debugging' mode as well as a way to programatically collect debugging info (which could include host stats, guest stats, logs and any core files). Certainly in such a scenario, being able to enable/disable varous features of a debugging mode could include whether to enable core dumps as well as where to save them on the host. 1. http://comments.gmane.org/gmane.comp.emulators.ovirt.vdsm.devel/1387 Yes, I read this, however, I am unsure that debug and low level collections should be implemented as in-band interface and not side-band. After many of years handling crappy bug reports that don't include the data needed for debugging, such as log files and other settings, and spending weeks going back and forth with the submitter on collecting what and where and how to collect it, I'm confident that having something that can programtically enable debugging on-demand and providing a way to collect the relative data (logs, cores, etc) would make a dramatic improvement when handing these support issues. I'm also a firm believer in lowering the barriers for consumption. IIUC, a side-band tool is going to require additional configuration/authenitication; and will ultimately need to access the API anyhow to determine various information about the specific VM. With that in mind, why wouldn't we want to look at a first-class debug API mode which can be used remotely and programatically? A better question is, what are the drawbacks to having it in-band? You took it too far... :) The problem with *THE* API is that there is a contract for forward/backward stability. From my experience having first class API for production is good as long as it is not being dragged for other purposes. You can always have second class API for debugging. The advantage of this is that the second class API is much more flexible and can serve strange/none standard (not fully compliant entities. It does not mean you don't reuse your code and/or authentication... Having said that... I think that most of this can be done via simple SSH and proper command-line tool at host side, which is very simple to use and implement. But I did not intend to (re)open the discussion about the debug API :) Regrds, Alon ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] [Engine-devel] [ATTENTION] vdsm-bootstrap/host deployment (pre-3.2)
On 11/28/2012 04:59 PM, Ryan Harper wrote: * Alon Bar-Lev alo...@redhat.com [2012-11-28 15:33]: Leaving only vdsm-devel. - Original Message - From: Ryan Harper ry...@us.ibm.com To: Alon Bar-Lev alo...@redhat.com Cc: Dan Kenigsberg dan...@redhat.com, engine-devel engine-de...@ovirt.org, VDSM Project Development vdsm-devel@lists.fedorahosted.org, users us...@ovirt.org Sent: Wednesday, November 28, 2012 11:22:59 PM Subject: Re: [Engine-devel] [vdsm] [ATTENTION] vdsm-bootstrap/host deployment (pre-3.2) snip If sysadmin manually enables dumps, he may do this at a location of his own choice. Note that we've just swapped hats: you're arguing for letting a local admin log in and mess with system configuration, and I'm for keeping a centralized feature for storing and collecting core dumps. As problems like crashes are investigated per case and reproduction scenario. But again, I may be wrong and we should have VDSM API command to start/stop storing dumps and manage this via its master... I very much like this idea. There was a thread a while back discussing[1] the this very idea; I was looking for a way to enable 'debugging' mode as well as a way to programatically collect debugging info (which could include host stats, guest stats, logs and any core files). Certainly in such a scenario, being able to enable/disable varous features of a debugging mode could include whether to enable core dumps as well as where to save them on the host. 1. http://comments.gmane.org/gmane.comp.emulators.ovirt.vdsm.devel/1387 Yes, I read this, however, I am unsure that debug and low level collections should be implemented as in-band interface and not side-band. After many of years handling crappy bug reports that don't include the data needed for debugging, such as log files and other settings, and spending weeks going back and forth with the submitter on collecting what and where and how to collect it, I'm confident that having something that can programtically enable debugging on-demand and providing a way to collect the relative data (logs, cores, etc) would make a dramatic improvement when handing these support issues. I'm also a firm believer in lowering the barriers for consumption. IIUC, a side-band tool is going to require additional configuration/authenitication; and will ultimately need to access the API anyhow to determine various information about the specific VM. With that in mind, why wouldn't we want to look at a first-class debug API mode which can be used remotely and programatically? A better question is, what are the drawbacks to having it in-band? isn't this what the ovirt-log-collector is for? ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
