Re: [Engine-devel] Jenkins job for ovirt-iso-uploader and ovirt-image-uploader
+1, Sandro is indeed already ovirt-engine-tools maintainer and is more than capable of creating jobs for testing them. Eyal. - Original Message - > From: "Sandro Bonazzola" > To: "infra" , "engine-devel" > Cc: "Eyal Edri" > Sent: Tuesday, September 24, 2013 9:30:11 AM > Subject: Re: Jenkins job for ovirt-iso-uploader and ovirt-image-uploader > > Hi oVirt community, > following the previous discussion with infra team, I need to get power user > rights for jenkins > in order to create a jenkins job for basic sanity testing of > ovirt-iso-uploader and ovirt-image-uploader. > That said, I formally request a power user for jenkins (for those tools I'm > already the maintainer) > in order to create new jobs for them as well and ask the community for acks. > Thanks, > > Sandro Bonazzola > > > > Il 11/09/2013 09:56, Eyal Edri ha scritto: > > Hi Sandro, > > > > I assume we can create a new vm on rackspace to act as NFS server for the > > job, > > or even convert one of the existing jenkins slave vms to be one. > > > > any other thoughts from the infra team? > > > > Also, you will need to get a power user for jenkins (for tools) in order to > > create new jobs > > for them as well. > > The process for that is sending email to this list & engine-devel to > > request it formally and > > get acks from the community. > > > > Eyal. > > > > > > - Original Message - > >> From: "Sandro Bonazzola" > >> To: "infra" > >> Sent: Wednesday, September 11, 2013 9:31:36 AM > >> Subject: Jenkins job for ovirt-iso-uploader and ovirt-image-uploader > >> > >> Hi, > >> I would like to introduce a jenkins job for basic sanity testing of > >> ovirt-iso-uploader and ovirt-image-uploader. > >> For covering NFS upload it will be needed an NFS share where to upload the > >> images, writable by an user having UID and GID of 36. > >> For covering SSH uploads it would be needed also SSH access with a user > >> having UID and GID of 36. > >> For covering upload using the domain id it would be needed a running > >> ovirt-engine instance. > >> > >> The space needed for the images may be little: sample ovf provided by > >> ovirt-image-uploader is ~2kb and for the iso image any non empty file > >> should > >> be > >> enough. The uploaded images will be deleted by the job after running. > >> > >> Is it possible for infra to provide the needed services? > >> Thanks, > >> -- > >> Sandro Bonazzola > >> Better technology. Faster innovation. Powered by community collaboration. > >> See how it works at redhat.com > >> ___ > >> Infra mailing list > >> in...@ovirt.org > >> http://lists.ovirt.org/mailman/listinfo/infra > >> > > > -- > Sandro Bonazzola > Better technology. Faster innovation. Powered by community collaboration. > See how it works at redhat.com > ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] [vdsm] stale gerrit patches
- Original Message - > From: "Ayal Baron" > To: "Alon Bar-Lev" > Cc: "Itamar Heim" , "engine-devel" > , vdsm-de...@lists.fedorahosted.org > Sent: Tuesday, September 24, 2013 9:20:55 AM > Subject: Re: [vdsm] stale gerrit patches > > > > - Original Message - > > > > > > - Original Message - > > > From: "Ayal Baron" > > > To: "Alon Bar-Lev" > > > Cc: "Itamar Heim" , "engine-devel" > > > , vdsm-de...@lists.fedorahosted.org > > > Sent: Tuesday, September 24, 2013 12:21:23 AM > > > Subject: Re: [vdsm] stale gerrit patches > > > > > > > > > > > > - Original Message - > > > > > > > > > > > > - Original Message - > > > > > From: "Itamar Heim" > > > > > To: "Alon Bar-Lev" > > > > > Cc: "David Caro" , "engine-devel" > > > > > , vdsm-de...@lists.fedorahosted.org > > > > > Sent: Monday, September 23, 2013 1:54:39 PM > > > > > Subject: Re: [vdsm] stale gerrit patches > > > > > > > > > > On 09/23/2013 01:52 PM, Alon Bar-Lev wrote: > > > > > > > > > > > > > > > > > > - Original Message - > > > > > >> From: "Itamar Heim" > > > > > >> To: "Alon Bar-Lev" > > > > > >> Cc: "David Caro" , "engine-devel" > > > > > >> , vdsm-de...@lists.fedorahosted.org > > > > > >> Sent: Monday, September 23, 2013 1:50:35 PM > > > > > >> Subject: Re: [vdsm] stale gerrit patches > > > > > >> > > > > > >> On 09/23/2013 01:49 PM, Alon Bar-Lev wrote: > > > > > >>> > > > > > >>> > > > > > >>> - Original Message - > > > > > From: "Itamar Heim" > > > > > To: "David Caro" > > > > > Cc: "engine-devel" , > > > > > vdsm-de...@lists.fedorahosted.org > > > > > Sent: Monday, September 23, 2013 1:47:47 PM > > > > > Subject: Re: [vdsm] stale gerrit patches > > > > > > > > > > On 09/23/2013 01:46 PM, David Caro wrote: > > > > > > On Mon 23 Sep 2013 12:36:58 PM CEST, Itamar Heim wrote: > > > > > >> we have some very old gerrit patches. > > > > > >> I'm for abandoning patches which were not touched over 60 days > > > > > >> (to > > > > > >> begin with, I think the number should actually be lower). > > > > > >> they can always be re-opened by any interested party post > > > > > >> their > > > > > >> closure. > > > > > >> > > > > > >> i.e., looking at gerrit, the patch list should actually get > > > > > >> attention, > > > > > >> and not be a few worth looking at, with a "lot of old patches" > > > > > >> > > > > > >> thoughts? > > > > > >> > > > > > >> Thanks, > > > > > >> Itamar > > > > > >> ___ > > > > > >> vdsm-devel mailing list > > > > > >> vdsm-de...@lists.fedorahosted.org > > > > > >> https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel > > > > > > > > > > > > It might helpful to have a cron-like script that checks the age > > > > > > of > > > > > > the > > > > > > posts and first notifies the sender, the reviewers and the > > > > > > maintainer, > > > > > > and if the patch is not updated in a certain period just > > > > > > abandons > > > > > > it. > > > > > > > > > > > > > > > > yep - warn after X days via email to just owner (or all > > > > > subscribed > > > > > to > > > > > the patch), and close if no activity for X+14 days or something > > > > > like > > > > > that. > > > > > >>> > > > > > >>> This will be annoying. > > > > > >>> > > > > > >>> And there are patches that pending with good reason. > > > > > >> > > > > > >> pending for 60 days with zero activity on them (no comment, no > > > > > >> rebase, > > > > > >> nothing)? > > > > > > > > > > > > http://gerrit.ovirt.org/#/q/status:open+project:ovirt-engine+branch:master+topic:independent_deployments,n,z > > > > > > > > > > so how does it help us to have these patches, some without any > > > > > comment > > > > > from any reviewer. > > > > > lets get them reviewed and decide one way or the other, rather than > > > > > let > > > > > them get old and stay forever > > > > > > > > Again... maintainer can close these if he likes. > > > > Owner can close these if he likes. > > > > > > right, but why? > > > a patch without activity being abandoned might actually spur someone into > > > motion (rebasing and resubmitting, prodding maintainers etc). > > > I'm +1 for automatically abandoning old patches. > > > > > > > I do not understand why maintainer should not have human interaction with > > its > > contributers. > > I do not understand the relation between the subject and the things you're > saying. > Right now these patches are stale and are rotting, abandoning them could > actually spur those interactions into motion. You prefer machines to interact with contributers to kick them in motion. I believe that human interaction and discussion between maintainer and contributer is the way to go. It is much more polite and cooperative for maintainer that is not aware of anyt
Re: [Engine-devel] Jenkins job for ovirt-iso-uploader and ovirt-image-uploader
Hi oVirt community, following the previous discussion with infra team, I need to get power user rights for jenkins in order to create a jenkins job for basic sanity testing of ovirt-iso-uploader and ovirt-image-uploader. That said, I formally request a power user for jenkins (for those tools I'm already the maintainer) in order to create new jobs for them as well and ask the community for acks. Thanks, Sandro Bonazzola Il 11/09/2013 09:56, Eyal Edri ha scritto: > Hi Sandro, > > I assume we can create a new vm on rackspace to act as NFS server for the job, > or even convert one of the existing jenkins slave vms to be one. > > any other thoughts from the infra team? > > Also, you will need to get a power user for jenkins (for tools) in order to > create new jobs > for them as well. > The process for that is sending email to this list & engine-devel to request > it formally and > get acks from the community. > > Eyal. > > > - Original Message - >> From: "Sandro Bonazzola" >> To: "infra" >> Sent: Wednesday, September 11, 2013 9:31:36 AM >> Subject: Jenkins job for ovirt-iso-uploader and ovirt-image-uploader >> >> Hi, >> I would like to introduce a jenkins job for basic sanity testing of >> ovirt-iso-uploader and ovirt-image-uploader. >> For covering NFS upload it will be needed an NFS share where to upload the >> images, writable by an user having UID and GID of 36. >> For covering SSH uploads it would be needed also SSH access with a user >> having UID and GID of 36. >> For covering upload using the domain id it would be needed a running >> ovirt-engine instance. >> >> The space needed for the images may be little: sample ovf provided by >> ovirt-image-uploader is ~2kb and for the iso image any non empty file should >> be >> enough. The uploaded images will be deleted by the job after running. >> >> Is it possible for infra to provide the needed services? >> Thanks, >> -- >> Sandro Bonazzola >> Better technology. Faster innovation. Powered by community collaboration. >> See how it works at redhat.com >> ___ >> Infra mailing list >> in...@ovirt.org >> http://lists.ovirt.org/mailman/listinfo/infra >> -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] [vdsm] stale gerrit patches
- Original Message - > > > - Original Message - > > From: "Ayal Baron" > > To: "Alon Bar-Lev" > > Cc: "Itamar Heim" , "engine-devel" > > , vdsm-de...@lists.fedorahosted.org > > Sent: Tuesday, September 24, 2013 12:21:23 AM > > Subject: Re: [vdsm] stale gerrit patches > > > > > > > > - Original Message - > > > > > > > > > - Original Message - > > > > From: "Itamar Heim" > > > > To: "Alon Bar-Lev" > > > > Cc: "David Caro" , "engine-devel" > > > > , vdsm-de...@lists.fedorahosted.org > > > > Sent: Monday, September 23, 2013 1:54:39 PM > > > > Subject: Re: [vdsm] stale gerrit patches > > > > > > > > On 09/23/2013 01:52 PM, Alon Bar-Lev wrote: > > > > > > > > > > > > > > > - Original Message - > > > > >> From: "Itamar Heim" > > > > >> To: "Alon Bar-Lev" > > > > >> Cc: "David Caro" , "engine-devel" > > > > >> , vdsm-de...@lists.fedorahosted.org > > > > >> Sent: Monday, September 23, 2013 1:50:35 PM > > > > >> Subject: Re: [vdsm] stale gerrit patches > > > > >> > > > > >> On 09/23/2013 01:49 PM, Alon Bar-Lev wrote: > > > > >>> > > > > >>> > > > > >>> - Original Message - > > > > From: "Itamar Heim" > > > > To: "David Caro" > > > > Cc: "engine-devel" , > > > > vdsm-de...@lists.fedorahosted.org > > > > Sent: Monday, September 23, 2013 1:47:47 PM > > > > Subject: Re: [vdsm] stale gerrit patches > > > > > > > > On 09/23/2013 01:46 PM, David Caro wrote: > > > > > On Mon 23 Sep 2013 12:36:58 PM CEST, Itamar Heim wrote: > > > > >> we have some very old gerrit patches. > > > > >> I'm for abandoning patches which were not touched over 60 days > > > > >> (to > > > > >> begin with, I think the number should actually be lower). > > > > >> they can always be re-opened by any interested party post their > > > > >> closure. > > > > >> > > > > >> i.e., looking at gerrit, the patch list should actually get > > > > >> attention, > > > > >> and not be a few worth looking at, with a "lot of old patches" > > > > >> > > > > >> thoughts? > > > > >> > > > > >> Thanks, > > > > >> Itamar > > > > >> ___ > > > > >> vdsm-devel mailing list > > > > >> vdsm-de...@lists.fedorahosted.org > > > > >> https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel > > > > > > > > > > It might helpful to have a cron-like script that checks the age > > > > > of > > > > > the > > > > > posts and first notifies the sender, the reviewers and the > > > > > maintainer, > > > > > and if the patch is not updated in a certain period just abandons > > > > > it. > > > > > > > > > > > > > yep - warn after X days via email to just owner (or all subscribed > > > > to > > > > the patch), and close if no activity for X+14 days or something > > > > like > > > > that. > > > > >>> > > > > >>> This will be annoying. > > > > >>> > > > > >>> And there are patches that pending with good reason. > > > > >> > > > > >> pending for 60 days with zero activity on them (no comment, no > > > > >> rebase, > > > > >> nothing)? > > > > > > > > > > http://gerrit.ovirt.org/#/q/status:open+project:ovirt-engine+branch:master+topic:independent_deployments,n,z > > > > > > > > so how does it help us to have these patches, some without any comment > > > > from any reviewer. > > > > lets get them reviewed and decide one way or the other, rather than let > > > > them get old and stay forever > > > > > > Again... maintainer can close these if he likes. > > > Owner can close these if he likes. > > > > right, but why? > > a patch without activity being abandoned might actually spur someone into > > motion (rebasing and resubmitting, prodding maintainers etc). > > I'm +1 for automatically abandoning old patches. > > > > I do not understand why maintainer should not have human interaction with its > contributers. I do not understand the relation between the subject and the things you're saying. Right now these patches are stale and are rotting, abandoning them could actually spur those interactions into motion. > > > > > > > The problem is that maintainers avoid closing. > > > And that there are people who submitted patches without CC anyone and > > > gone. > > > > > > So a simple logic can be applied after we add metadata into tree: > > > > > > 1. If no maintainer is CCed on change, close that change within short > > > cycle > > > (can be even a week). > > > 2. Maintainer to close patches that have no interest in. > > > > > > > > > > > > > > > > >> > > > > >>> > > > > >>> Maintainers can close patches that are no interest nor progress. > > > > >>> > > > > >>> Alon > > > > >>> > > > > >> > > > > >> > > > > > > > > > > > ___ > > > vdsm-devel mailing list > > > vdsm-de...@lists.fedorahosted.org > > > https://lists.fedorahosted.org/mailman/listinfo/v
Re: [Engine-devel] [vdsm] stale gerrit patches
- Original Message - > From: "Ayal Baron" > To: "Alon Bar-Lev" > Cc: "Itamar Heim" , "engine-devel" > , vdsm-de...@lists.fedorahosted.org > Sent: Tuesday, September 24, 2013 12:21:23 AM > Subject: Re: [vdsm] stale gerrit patches > > > > - Original Message - > > > > > > - Original Message - > > > From: "Itamar Heim" > > > To: "Alon Bar-Lev" > > > Cc: "David Caro" , "engine-devel" > > > , vdsm-de...@lists.fedorahosted.org > > > Sent: Monday, September 23, 2013 1:54:39 PM > > > Subject: Re: [vdsm] stale gerrit patches > > > > > > On 09/23/2013 01:52 PM, Alon Bar-Lev wrote: > > > > > > > > > > > > - Original Message - > > > >> From: "Itamar Heim" > > > >> To: "Alon Bar-Lev" > > > >> Cc: "David Caro" , "engine-devel" > > > >> , vdsm-de...@lists.fedorahosted.org > > > >> Sent: Monday, September 23, 2013 1:50:35 PM > > > >> Subject: Re: [vdsm] stale gerrit patches > > > >> > > > >> On 09/23/2013 01:49 PM, Alon Bar-Lev wrote: > > > >>> > > > >>> > > > >>> - Original Message - > > > From: "Itamar Heim" > > > To: "David Caro" > > > Cc: "engine-devel" , > > > vdsm-de...@lists.fedorahosted.org > > > Sent: Monday, September 23, 2013 1:47:47 PM > > > Subject: Re: [vdsm] stale gerrit patches > > > > > > On 09/23/2013 01:46 PM, David Caro wrote: > > > > On Mon 23 Sep 2013 12:36:58 PM CEST, Itamar Heim wrote: > > > >> we have some very old gerrit patches. > > > >> I'm for abandoning patches which were not touched over 60 days (to > > > >> begin with, I think the number should actually be lower). > > > >> they can always be re-opened by any interested party post their > > > >> closure. > > > >> > > > >> i.e., looking at gerrit, the patch list should actually get > > > >> attention, > > > >> and not be a few worth looking at, with a "lot of old patches" > > > >> > > > >> thoughts? > > > >> > > > >> Thanks, > > > >> Itamar > > > >> ___ > > > >> vdsm-devel mailing list > > > >> vdsm-de...@lists.fedorahosted.org > > > >> https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel > > > > > > > > It might helpful to have a cron-like script that checks the age of > > > > the > > > > posts and first notifies the sender, the reviewers and the > > > > maintainer, > > > > and if the patch is not updated in a certain period just abandons > > > > it. > > > > > > > > > > yep - warn after X days via email to just owner (or all subscribed > > > to > > > the patch), and close if no activity for X+14 days or something like > > > that. > > > >>> > > > >>> This will be annoying. > > > >>> > > > >>> And there are patches that pending with good reason. > > > >> > > > >> pending for 60 days with zero activity on them (no comment, no rebase, > > > >> nothing)? > > > > > > > > http://gerrit.ovirt.org/#/q/status:open+project:ovirt-engine+branch:master+topic:independent_deployments,n,z > > > > > > so how does it help us to have these patches, some without any comment > > > from any reviewer. > > > lets get them reviewed and decide one way or the other, rather than let > > > them get old and stay forever > > > > Again... maintainer can close these if he likes. > > Owner can close these if he likes. > > right, but why? > a patch without activity being abandoned might actually spur someone into > motion (rebasing and resubmitting, prodding maintainers etc). > I'm +1 for automatically abandoning old patches. > I do not understand why maintainer should not have human interaction with its contributers. > > > > The problem is that maintainers avoid closing. > > And that there are people who submitted patches without CC anyone and gone. > > > > So a simple logic can be applied after we add metadata into tree: > > > > 1. If no maintainer is CCed on change, close that change within short cycle > > (can be even a week). > > 2. Maintainer to close patches that have no interest in. > > > > > > > > > > > > >> > > > >>> > > > >>> Maintainers can close patches that are no interest nor progress. > > > >>> > > > >>> Alon > > > >>> > > > >> > > > >> > > > > > > > > ___ > > vdsm-devel mailing list > > vdsm-de...@lists.fedorahosted.org > > https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel > > > ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Issues with VirtIO-SCSI
- Original Message - > Hi Daniel, > > I asked this question because I have implemented a filter to show only > compatible disk interfaces (in change #17964). The main purpose of this > patch is to hide the IDE interface type when creating disks for PPC64 VMs > (since IDE is not supported on this architecture). If it was decided that > the VirtIO-SCSI interface type should be hidden from the user in case it was > disabled, I would have to modify that patch a little bit. That is not the case. Point is to allow users to add a scsi controller to a VM that does not have any scsi disks. This is needed in case the user would later on like to hotplug scsi disks. Without this, hotplug would fail since there is no scsi controller in the VM. When the VM is down, you can always attach a scsi disk and if there is no scsi controller then engine will automatically add one. > > Another issue is that in change #18622 the support for a PPC64-specific > controller, the SPAPR VSCSI controller, was introduced. But the code was > created based on the assumption that the VirtIO-SCSI controller was always > present, and this isn't the case anymore. And another patch that I will work > on really soon will add support to create disks that are connected to this > interface. > > So, I would like some feedback before changing these patches. Is a validation > on the backend enough to block the user from using an inexistent controller? > Should the frontend be changed as well? What would be a good approach to > handle multiple SCSI controllers in a VM (were the presence of one of them > is optional)? If you have a need for a VM with more than 256 LUNs then I'd say that the easiest behaviour to understand would be to hide the existence of the controllers from the user altogether and just add support to automatically hotplug controllers on the fly when existing controllers are reaching their limit. > > Thanks, > Vitor > > > > >-Original Message- > >From: Daniel Erez [mailto:de...@redhat.com] > >Sent: segunda-feira, 23 de setembro de 2013 17:06 > >To: Vitor de Lima > >Cc: engine-devel@ovirt.org > >Subject: Re: [Engine-devel] Issues with VirtIO-SCSI > > > >Hi Vitor, > > > >The new VirtIO-SCSI enabled checkbox is an indication whether to attach a > >VirtIO-SCSI controller when running the VM. > >It should be enabled automatically on cluster >= 3.3. > > > >When disabled, I think it's preferable not to add a new controller > >automatically > >when running the VM as it requires creating/attaching a new VmDevice - > >which we refrain of on VmInfoBuilder flows (and since it might be confusing > >to > >the user...). > > > >As an alternative, I've planned to add a warning in the dialog or create a > >canDo > >message to prevent running the VM at all. > >I'm not sure we should hide the option from disk interfaces list as it's > >already > >being filtered using VirtIoScsiEnabled ConfigurationValue (and using OsInfo > >soon...). > > > >Let me know what you think and thanks a lot for the input! > > > >Daniel > > > >- Original Message - > >> From: "Vitor de Lima" > >> To: engine-devel@ovirt.org > >> Sent: Monday, September 23, 2013 10:42:39 PM > >> Subject: [Engine-devel] Issues with VirtIO-SCSI > >> > >> Hi everyone, > >> > >> I have found some issues with this patch: > >> > >> http://gerrit.ovirt.org/#/c/18638/ > >> > >> It allows the user to disable the VirtIO-SCSI disk interface during > >> the VM creation. The problem is that the user still can add, attach > >> and hotplug disks with the VirtIO-SCSI interface type, but when the > >> user does so, libvirt automatically creates a LSI Logic SCSI > >> controller and connects the new disk to it. > >> > >> How can this problem be solved? Should the VirtIO-SCSI interface type > >> be hidden from the user in case it wasn't enabled, or should the > >> engine enable the VirtIO-SCSI controller, hotplug it, then hotplug the > >> disk into it transparently? > >> > >> Thanks, > >> Vitor de Lima > >> > >> ___ > >> Engine-devel mailing list > >> Engine-devel@ovirt.org > >> http://lists.ovirt.org/mailman/listinfo/engine-devel > >> > ___ > Engine-devel mailing list > Engine-devel@ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Issues with VirtIO-SCSI
Hi Daniel, I asked this question because I have implemented a filter to show only compatible disk interfaces (in change #17964). The main purpose of this patch is to hide the IDE interface type when creating disks for PPC64 VMs (since IDE is not supported on this architecture). If it was decided that the VirtIO-SCSI interface type should be hidden from the user in case it was disabled, I would have to modify that patch a little bit. Another issue is that in change #18622 the support for a PPC64-specific controller, the SPAPR VSCSI controller, was introduced. But the code was created based on the assumption that the VirtIO-SCSI controller was always present, and this isn't the case anymore. And another patch that I will work on really soon will add support to create disks that are connected to this interface. So, I would like some feedback before changing these patches. Is a validation on the backend enough to block the user from using an inexistent controller? Should the frontend be changed as well? What would be a good approach to handle multiple SCSI controllers in a VM (were the presence of one of them is optional)? Thanks, Vitor >-Original Message- >From: Daniel Erez [mailto:de...@redhat.com] >Sent: segunda-feira, 23 de setembro de 2013 17:06 >To: Vitor de Lima >Cc: engine-devel@ovirt.org >Subject: Re: [Engine-devel] Issues with VirtIO-SCSI > >Hi Vitor, > >The new VirtIO-SCSI enabled checkbox is an indication whether to attach a >VirtIO-SCSI controller when running the VM. >It should be enabled automatically on cluster >= 3.3. > >When disabled, I think it's preferable not to add a new controller >automatically >when running the VM as it requires creating/attaching a new VmDevice - >which we refrain of on VmInfoBuilder flows (and since it might be confusing to >the user...). > >As an alternative, I've planned to add a warning in the dialog or create a >canDo >message to prevent running the VM at all. >I'm not sure we should hide the option from disk interfaces list as it's >already >being filtered using VirtIoScsiEnabled ConfigurationValue (and using OsInfo >soon...). > >Let me know what you think and thanks a lot for the input! > >Daniel > >- Original Message - >> From: "Vitor de Lima" >> To: engine-devel@ovirt.org >> Sent: Monday, September 23, 2013 10:42:39 PM >> Subject: [Engine-devel] Issues with VirtIO-SCSI >> >> Hi everyone, >> >> I have found some issues with this patch: >> >> http://gerrit.ovirt.org/#/c/18638/ >> >> It allows the user to disable the VirtIO-SCSI disk interface during >> the VM creation. The problem is that the user still can add, attach >> and hotplug disks with the VirtIO-SCSI interface type, but when the >> user does so, libvirt automatically creates a LSI Logic SCSI >> controller and connects the new disk to it. >> >> How can this problem be solved? Should the VirtIO-SCSI interface type >> be hidden from the user in case it wasn't enabled, or should the >> engine enable the VirtIO-SCSI controller, hotplug it, then hotplug the >> disk into it transparently? >> >> Thanks, >> Vitor de Lima >> >> ___ >> Engine-devel mailing list >> Engine-devel@ovirt.org >> http://lists.ovirt.org/mailman/listinfo/engine-devel >> ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] [vdsm] stale gerrit patches
- Original Message - > > > - Original Message - > > From: "Itamar Heim" > > To: "Alon Bar-Lev" > > Cc: "David Caro" , "engine-devel" > > , vdsm-de...@lists.fedorahosted.org > > Sent: Monday, September 23, 2013 1:54:39 PM > > Subject: Re: [vdsm] stale gerrit patches > > > > On 09/23/2013 01:52 PM, Alon Bar-Lev wrote: > > > > > > > > > - Original Message - > > >> From: "Itamar Heim" > > >> To: "Alon Bar-Lev" > > >> Cc: "David Caro" , "engine-devel" > > >> , vdsm-de...@lists.fedorahosted.org > > >> Sent: Monday, September 23, 2013 1:50:35 PM > > >> Subject: Re: [vdsm] stale gerrit patches > > >> > > >> On 09/23/2013 01:49 PM, Alon Bar-Lev wrote: > > >>> > > >>> > > >>> - Original Message - > > From: "Itamar Heim" > > To: "David Caro" > > Cc: "engine-devel" , > > vdsm-de...@lists.fedorahosted.org > > Sent: Monday, September 23, 2013 1:47:47 PM > > Subject: Re: [vdsm] stale gerrit patches > > > > On 09/23/2013 01:46 PM, David Caro wrote: > > > On Mon 23 Sep 2013 12:36:58 PM CEST, Itamar Heim wrote: > > >> we have some very old gerrit patches. > > >> I'm for abandoning patches which were not touched over 60 days (to > > >> begin with, I think the number should actually be lower). > > >> they can always be re-opened by any interested party post their > > >> closure. > > >> > > >> i.e., looking at gerrit, the patch list should actually get > > >> attention, > > >> and not be a few worth looking at, with a "lot of old patches" > > >> > > >> thoughts? > > >> > > >> Thanks, > > >> Itamar > > >> ___ > > >> vdsm-devel mailing list > > >> vdsm-de...@lists.fedorahosted.org > > >> https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel > > > > > > It might helpful to have a cron-like script that checks the age of > > > the > > > posts and first notifies the sender, the reviewers and the > > > maintainer, > > > and if the patch is not updated in a certain period just abandons it. > > > > > > > yep - warn after X days via email to just owner (or all subscribed to > > the patch), and close if no activity for X+14 days or something like > > that. > > >>> > > >>> This will be annoying. > > >>> > > >>> And there are patches that pending with good reason. > > >> > > >> pending for 60 days with zero activity on them (no comment, no rebase, > > >> nothing)? > > > > > > http://gerrit.ovirt.org/#/q/status:open+project:ovirt-engine+branch:master+topic:independent_deployments,n,z > > > > so how does it help us to have these patches, some without any comment > > from any reviewer. > > lets get them reviewed and decide one way or the other, rather than let > > them get old and stay forever > > Again... maintainer can close these if he likes. > Owner can close these if he likes. right, but why? a patch without activity being abandoned might actually spur someone into motion (rebasing and resubmitting, prodding maintainers etc). I'm +1 for automatically abandoning old patches. > > The problem is that maintainers avoid closing. > And that there are people who submitted patches without CC anyone and gone. > > So a simple logic can be applied after we add metadata into tree: > > 1. If no maintainer is CCed on change, close that change within short cycle > (can be even a week). > 2. Maintainer to close patches that have no interest in. > > > > > > > > >> > > >>> > > >>> Maintainers can close patches that are no interest nor progress. > > >>> > > >>> Alon > > >>> > > >> > > >> > > > > > ___ > vdsm-devel mailing list > vdsm-de...@lists.fedorahosted.org > https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel > ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Issues with VirtIO-SCSI
Hi Vitor, The new VirtIO-SCSI enabled checkbox is an indication whether to attach a VirtIO-SCSI controller when running the VM. It should be enabled automatically on cluster >= 3.3. When disabled, I think it's preferable not to add a new controller automatically when running the VM as it requires creating/attaching a new VmDevice - which we refrain of on VmInfoBuilder flows (and since it might be confusing to the user...). As an alternative, I've planned to add a warning in the dialog or create a canDo message to prevent running the VM at all. I'm not sure we should hide the option from disk interfaces list as it's already being filtered using VirtIoScsiEnabled ConfigurationValue (and using OsInfo soon...). Let me know what you think and thanks a lot for the input! Daniel - Original Message - > From: "Vitor de Lima" > To: engine-devel@ovirt.org > Sent: Monday, September 23, 2013 10:42:39 PM > Subject: [Engine-devel] Issues with VirtIO-SCSI > > Hi everyone, > > I have found some issues with this patch: > > http://gerrit.ovirt.org/#/c/18638/ > > It allows the user to disable the VirtIO-SCSI disk interface during the VM > creation. The problem is that the user still can add, attach and hotplug > disks with the VirtIO-SCSI interface type, but when the user does so, > libvirt automatically creates a LSI Logic SCSI controller and connects the > new disk to it. > > How can this problem be solved? Should the VirtIO-SCSI interface type be > hidden from the user in case it wasn't enabled, or should the engine enable > the VirtIO-SCSI controller, hotplug it, then hotplug the disk into it > transparently? > > Thanks, > Vitor de Lima > > ___ > Engine-devel mailing list > Engine-devel@ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
[Engine-devel] Issues with VirtIO-SCSI
Hi everyone, I have found some issues with this patch: http://gerrit.ovirt.org/#/c/18638/ It allows the user to disable the VirtIO-SCSI disk interface during the VM creation. The problem is that the user still can add, attach and hotplug disks with the VirtIO-SCSI interface type, but when the user does so, libvirt automatically creates a LSI Logic SCSI controller and connects the new disk to it. How can this problem be solved? Should the VirtIO-SCSI interface type be hidden from the user in case it wasn't enabled, or should the engine enable the VirtIO-SCSI controller, hotplug it, then hotplug the disk into it transparently? Thanks, Vitor de Lima ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
[Engine-devel] Jenkins upgrade on Thursday at 20:00 UTC
As in the subject, on Thursday at 20:00 UTC I'll update jenkins to the latest LTS release. The downtime is expected to be minimal. ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] disk quota broken in latest master
BZ1011175 (https://bugzilla.redhat.com/show_bug.cgi?id=1011175) Opened - DHC On Mon, Sep 23, 2013 at 3:44 AM, Gilad Chaplik wrote: > http://gerrit.ovirt.org/#/c/19432/ [merged] should fix it. > > Thanks, > Gilad. > > - Original Message - > > From: "Gilad Chaplik" > > To: "Dead Horse" > > Cc: "engine-devel" > > Sent: Sunday, September 22, 2013 9:15:44 AM > > Subject: Re: [Engine-devel] disk quota broken in latest master > > > > Hi, > > > > looks like the quota drop-down isn't getting refreshed according to > selected > > storage domain. > > can you please open a bug? > > > > Thanks, > > Gilad. > > > > - Original Message - > > > From: "Dead Horse" > > > To: "engine-devel" > > > Sent: Friday, September 20, 2013 9:44:20 PM > > > Subject: Re: [Engine-devel] disk quota broken in latest master > > > > > > In further testing I note that assign quota under the disks tab of the > > > associated vm in the admin portal does work. > > > - DHC > > > > > > > > > On Fri, Sep 20, 2013 at 2:24 PM, Dead Horse < > deadhorseconsult...@gmail.com > > > > > > > wrote: > > > > > > > > > > > > > > > really attach the logs > > > > > > I also notice that disks tab is no longer showing a disk inventory as > well. > > > > > > - DHC > > > > > > > > > On Fri, Sep 20, 2013 at 2:15 PM, Dead Horse < > deadhorseconsult...@gmail.com > > > > > > > wrote: > > > > > > > > > > > > When attempting to add a disk from either the admin or power user > portals > > > the > > > according disk quota associated with the requested storage domain > cannot be > > > assigned to the disk. The disk quota pull-down only will only display > > > whatever quota is first in the list alphabetically. > > > - DHC > > > > > > engine and vdsm logs attached. > > > > > > 2013-09-20 13:56:36,810 INFO [org.ovirt.engine.core.bll. > > > LoginUserCommand] (ajp--127.0.0.1-8702-4) Running command: > LoginUserCommand > > > internal: false. > > > 2013-09-20 13:56:36,833 INFO > > > [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] > > > (ajp--127.0.0.1-8702-4) Correlation ID: null, Call Stack: null, Custom > > > Event > > > ID: -1, Message: User admin@internal logged in. > > > 2013-09-20 13:56:45,775 ERROR > > > [org.ovirt.engine.core.utils.servlet.ServletUtils] > (ajp--127.0.0.1-8702-6) > > > Can't read file > "/usr/share/doc/ovirt-engine/manual/DocumentationPath.csv" > > > for request "/docs/DocumentationPath.csv", will send a 404 error > response. > > > 2013-09-20 13:57:00,456 INFO > [org.ovirt.engine.core.bll.quota.QuotaManager] > > > (DefaultQuartzScheduler_Worker-72) Quota Cache updated. (26 msec) > > > 2013-09-20 13:57:01,810 INFO [org.ovirt.engine.core.bll.AddDiskCommand] > > > (ajp--127.0.0.1-8702-10) Lock Acquired to object EngineLock > > > [exclusiveLocks= > > > key: ca3cecf1-090e-469a-aaad-e26ce47f89d8 value: VM_DISK_BOOT > > > , sharedLocks= key: ca3cecf1-090e-469a-aaad-e26ce47f89d8 value: VM > > > ] > > > 2013-09-20 13:57:01,863 ERROR > > > [org.ovirt.engine.core.bll.quota.QuotaManager] > > > (ajp--127.0.0.1-8702-10) Quota storage parameters from command: > > > org.ovirt.engine.core.bll.AddDiskCommand. Storage domain does not match > > > quota > > > 2013-09-20 13:57:01,901 INFO > > > [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] > > > (ajp--127.0.0.1-8702-10) Correlation ID: 5790e811, Job ID: > > > 7abd0b95-4cd4-4cb5-864c-d51c4446a42d, Call Stack: null, Custom Event > ID: > > > -1, > > > Message: Missing Quota for Disk, proceeding since in Permissive (Audit) > > > mode. > > > 2013-09-20 13:57:01,937 INFO [org.ovirt.engine.core.bll.AddDiskCommand] > > > (ajp--127.0.0.1-8702-10) Running command: AddDiskCommand internal: > false. > > > Entities affected : ID: ca3cecf1-090e-469a-aaad-e26ce47f89d8 Type: VM, > ID: > > > 26be0640-01a3-415d-82c9-0a92f2f84c3f Type: Storage > > > 2013-09-20 13:57:02,325 INFO > > > [org.ovirt.engine.core.bll.AddImageFromScratchCommand] > > > (ajp--127.0.0.1-8702-10) Running command: AddImageFromScratchCommand > > > internal: true. Entities affected : ID: > > > 26be0640-01a3-415d-82c9-0a92f2f84c3f > > > Type: Storage > > > 2013-09-20 13:57:02,446 INFO > > > [org.ovirt.engine.core.bll.AddImageFromScratchCommand] > > > (ajp--127.0.0.1-8702-10) Lock freed to object EngineLock > [exclusiveLocks= > > > key: ca3cecf1-090e-469a-aaad-e26ce47f89d8 value: VM_DISK_BOOT > > > , sharedLocks= key: ca3cecf1-090e-469a-aaad-e26ce47f89d8 value: VM > > > ] > > > 2013-09-20 13:57:02,451 INFO > > > [org.ovirt.engine.core.vdsbroker.irsbroker.CreateImageVDSCommand] > > > (ajp--127.0.0.1-8702-10) START, CreateImageVDSCommand( storagePoolId = > > > 5849b030-626e-47cb-ad90-3ce782d831b3, ignoreFailoverLimit = false, > > > storageDomainId = 26be0640-01a3-415d-82c9-0a92f2f84c3f, imageGroupId = > > > bf6458bc-627a-4399-822d-f72751edf303, imageSizeInBytes = 1073741824, > > > volumeFormat = RAW, newImageId = 165089b7-4737-4900-9a7f-d2d888ec3514, > > > newImageDescription = ), log id: 1ef8212d > > > 2013-09-20
Re: [Engine-devel] Suggesting new packaging and setup maintainer
+1. Agree and fully support the nomination for sandro as maintainer for ovirt-engine. Eyal. - Original Message - > From: "Ofer Schreiber" > To: "board" , "engine-devel" > Sent: Monday, September 23, 2013 1:49:36 PM > Subject: [Engine-devel] Suggesting new packaging and setup maintainer > > Nominating Sandro Bonazzola as packaging and setup maintainer > -- > > During his recent year of participation in ovirt-engine development, > Sandro demonstrated a genuine care for the product health, great coding > abilities, > and great responsibility to the setup and packaging components. > > Sandro's contribution the the project is undoubtable, he's responsible for > over 70 patches in ovirt-engine, > and he's the maintainer of log-collector, iso-uploader and image-uploader > packages. > > I suggest that Sandro will obtain +2 and merge rights in the ovirt-engine > gerrit project, > in the understanding that those rights should be used only in packaging and > setup parts of the code. > > -- > Ofer Schreiber. > ___ > Engine-devel mailing list > Engine-devel@ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] External events and flood rate
Thanks for looking into this Michael. Only allowing one external event every 30 seconds seems like kind of a high initial setting. However, I've put in a workaround on our side that will retry sending the event after 30 seconds and queue the rest if an error is received while logging. -Chris > -Original Message- > From: Michael Pasternak [mailto:mpast...@redhat.com] > Sent: Monday, September 23, 2013 6:36 AM > To: Eli Mesika > Cc: Morrissey, Christopher; engine-devel@ovirt.org > Subject: Re: [Engine-devel] External events and flood rate > > Eli, > > any reason for hardcoding this [1]? i'd move it to vdc_config. > > [1] Math.max(auditLogable.getEventFloodInSec(), 30) // Min duration for > External Events is 30 sec > > On 09/19/2013 12:50 AM, Morrissey, Christopher wrote: > > Hi All, > > > > > > > > I've been working on submitting external events to oVirt through the > > REST API. It seems to be working in general, although it appears that, > > no matter what value I put for the flood rate in the event, only 1 or > > so events are allowed every 30 seconds. If I send another event during this > time, I get an operation failed exception. Should the flood rate have any > impact on this? Is there any way to allow my code to get an event through > when needed or should I have a thread that shoots them off every 30 > seconds if several occur too quickly together? > > > > > > > > -Chris > > > > > > > > *Chris Morrissey* > > > > Software Engineer > > > > NetApp Inc. > > > > 919.476.4428 > > > > > > > > > > > > ___ > > Engine-devel mailing list > > Engine-devel@ovirt.org > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > -- > > Michael Pasternak > RedHat, ENG-Virtualization R&D ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Suggesting new packaging and setup maintainer
Absolutely agree. Sandro has done a great work on the project, and personally helped me solve a lot of issues in the development of installation utilities and packaging. I think he'll be a responsible maintainer. -- Best regards, Alex Lourie Software Developer in Integration Red Hat - Original Message - > From: "Ofer Schreiber" > To: "board" , "engine-devel" > Sent: Monday, September 23, 2013 12:49:36 PM > Subject: [Engine-devel] Suggesting new packaging and setup maintainer > > Nominating Sandro Bonazzola as packaging and setup maintainer > -- > > During his recent year of participation in ovirt-engine development, > Sandro demonstrated a genuine care for the product health, great coding > abilities, > and great responsibility to the setup and packaging components. > > Sandro's contribution the the project is undoubtable, he's responsible for > over 70 patches in ovirt-engine, > and he's the maintainer of log-collector, iso-uploader and image-uploader > packages. > > I suggest that Sandro will obtain +2 and merge rights in the ovirt-engine > gerrit project, > in the understanding that those rights should be used only in packaging and > setup parts of the code. > > -- > Ofer Schreiber. > ___ > Engine-devel mailing list > Engine-devel@ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] [vdsm] stale gerrit patches
- Original Message - > From: "Itamar Heim" > To: "Alon Bar-Lev" > Cc: "David Caro" , "engine-devel" > , vdsm-de...@lists.fedorahosted.org > Sent: Monday, September 23, 2013 1:54:39 PM > Subject: Re: [vdsm] stale gerrit patches > > On 09/23/2013 01:52 PM, Alon Bar-Lev wrote: > > > > > > - Original Message - > >> From: "Itamar Heim" > >> To: "Alon Bar-Lev" > >> Cc: "David Caro" , "engine-devel" > >> , vdsm-de...@lists.fedorahosted.org > >> Sent: Monday, September 23, 2013 1:50:35 PM > >> Subject: Re: [vdsm] stale gerrit patches > >> > >> On 09/23/2013 01:49 PM, Alon Bar-Lev wrote: > >>> > >>> > >>> - Original Message - > From: "Itamar Heim" > To: "David Caro" > Cc: "engine-devel" , > vdsm-de...@lists.fedorahosted.org > Sent: Monday, September 23, 2013 1:47:47 PM > Subject: Re: [vdsm] stale gerrit patches > > On 09/23/2013 01:46 PM, David Caro wrote: > > On Mon 23 Sep 2013 12:36:58 PM CEST, Itamar Heim wrote: > >> we have some very old gerrit patches. > >> I'm for abandoning patches which were not touched over 60 days (to > >> begin with, I think the number should actually be lower). > >> they can always be re-opened by any interested party post their > >> closure. > >> > >> i.e., looking at gerrit, the patch list should actually get attention, > >> and not be a few worth looking at, with a "lot of old patches" > >> > >> thoughts? > >> > >> Thanks, > >> Itamar > >> ___ > >> vdsm-devel mailing list > >> vdsm-de...@lists.fedorahosted.org > >> https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel > > > > It might helpful to have a cron-like script that checks the age of the > > posts and first notifies the sender, the reviewers and the maintainer, > > and if the patch is not updated in a certain period just abandons it. > > > > yep - warn after X days via email to just owner (or all subscribed to > the patch), and close if no activity for X+14 days or something like > that. > >>> > >>> This will be annoying. > >>> > >>> And there are patches that pending with good reason. > >> > >> pending for 60 days with zero activity on them (no comment, no rebase, > >> nothing)? > > > > http://gerrit.ovirt.org/#/q/status:open+project:ovirt-engine+branch:master+topic:independent_deployments,n,z > > so how does it help us to have these patches, some without any comment > from any reviewer. > lets get them reviewed and decide one way or the other, rather than let > them get old and stay forever Again... maintainer can close these if he likes. Owner can close these if he likes. The problem is that maintainers avoid closing. And that there are people who submitted patches without CC anyone and gone. So a simple logic can be applied after we add metadata into tree: 1. If no maintainer is CCed on change, close that change within short cycle (can be even a week). 2. Maintainer to close patches that have no interest in. > > > > >> > >>> > >>> Maintainers can close patches that are no interest nor progress. > >>> > >>> Alon > >>> > >> > >> > > ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] [vdsm] stale gerrit patches
On 09/23/2013 01:52 PM, Alon Bar-Lev wrote: - Original Message - From: "Itamar Heim" To: "Alon Bar-Lev" Cc: "David Caro" , "engine-devel" , vdsm-de...@lists.fedorahosted.org Sent: Monday, September 23, 2013 1:50:35 PM Subject: Re: [vdsm] stale gerrit patches On 09/23/2013 01:49 PM, Alon Bar-Lev wrote: - Original Message - From: "Itamar Heim" To: "David Caro" Cc: "engine-devel" , vdsm-de...@lists.fedorahosted.org Sent: Monday, September 23, 2013 1:47:47 PM Subject: Re: [vdsm] stale gerrit patches On 09/23/2013 01:46 PM, David Caro wrote: On Mon 23 Sep 2013 12:36:58 PM CEST, Itamar Heim wrote: we have some very old gerrit patches. I'm for abandoning patches which were not touched over 60 days (to begin with, I think the number should actually be lower). they can always be re-opened by any interested party post their closure. i.e., looking at gerrit, the patch list should actually get attention, and not be a few worth looking at, with a "lot of old patches" thoughts? Thanks, Itamar ___ vdsm-devel mailing list vdsm-de...@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel It might helpful to have a cron-like script that checks the age of the posts and first notifies the sender, the reviewers and the maintainer, and if the patch is not updated in a certain period just abandons it. yep - warn after X days via email to just owner (or all subscribed to the patch), and close if no activity for X+14 days or something like that. This will be annoying. And there are patches that pending with good reason. pending for 60 days with zero activity on them (no comment, no rebase, nothing)? http://gerrit.ovirt.org/#/q/status:open+project:ovirt-engine+branch:master+topic:independent_deployments,n,z so how does it help us to have these patches, some without any comment from any reviewer. lets get them reviewed and decide one way or the other, rather than let them get old and stay forever Maintainers can close patches that are no interest nor progress. Alon ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] [vdsm] stale gerrit patches
- Original Message - > From: "Alon Bar-Lev" > To: "Itamar Heim" > Cc: "David Caro" , "engine-devel" > , vdsm-de...@lists.fedorahosted.org > Sent: Monday, September 23, 2013 1:52:56 PM > Subject: Re: [vdsm] stale gerrit patches > > > > - Original Message - > > From: "Itamar Heim" > > To: "Alon Bar-Lev" > > Cc: "David Caro" , "engine-devel" > > , vdsm-de...@lists.fedorahosted.org > > Sent: Monday, September 23, 2013 1:50:35 PM > > Subject: Re: [vdsm] stale gerrit patches > > > > On 09/23/2013 01:49 PM, Alon Bar-Lev wrote: > > > > > > > > > - Original Message - > > >> From: "Itamar Heim" > > >> To: "David Caro" > > >> Cc: "engine-devel" , > > >> vdsm-de...@lists.fedorahosted.org > > >> Sent: Monday, September 23, 2013 1:47:47 PM > > >> Subject: Re: [vdsm] stale gerrit patches > > >> > > >> On 09/23/2013 01:46 PM, David Caro wrote: > > >>> On Mon 23 Sep 2013 12:36:58 PM CEST, Itamar Heim wrote: > > we have some very old gerrit patches. > > I'm for abandoning patches which were not touched over 60 days (to > > begin with, I think the number should actually be lower). > > they can always be re-opened by any interested party post their > > closure. > > > > i.e., looking at gerrit, the patch list should actually get attention, > > and not be a few worth looking at, with a "lot of old patches" > > > > thoughts? > > > > Thanks, > > Itamar > > ___ > > vdsm-devel mailing list > > vdsm-de...@lists.fedorahosted.org > > https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel > > >>> > > >>> It might helpful to have a cron-like script that checks the age of the > > >>> posts and first notifies the sender, the reviewers and the maintainer, > > >>> and if the patch is not updated in a certain period just abandons it. > > >>> > > >> > > >> yep - warn after X days via email to just owner (or all subscribed to > > >> the patch), and close if no activity for X+14 days or something like > > >> that. > > > > > > This will be annoying. > > > > > > And there are patches that pending with good reason. > > > > pending for 60 days with zero activity on them (no comment, no rebase, > > nothing)? > > http://gerrit.ovirt.org/#/q/status:open+project:ovirt-engine+branch:master+topic:independent_deployments,n,z http://gerrit.ovirt.org/#/q/status:open+project:ovirt-engine+branch:master+topic:ldap_independence,n,z > > > > > > > > > Maintainers can close patches that are no interest nor progress. > > > > > > Alon > > > > > > > > ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] [vdsm] stale gerrit patches
- Original Message - > From: "Itamar Heim" > To: "Alon Bar-Lev" > Cc: "David Caro" , "engine-devel" > , vdsm-de...@lists.fedorahosted.org > Sent: Monday, September 23, 2013 1:50:35 PM > Subject: Re: [vdsm] stale gerrit patches > > On 09/23/2013 01:49 PM, Alon Bar-Lev wrote: > > > > > > - Original Message - > >> From: "Itamar Heim" > >> To: "David Caro" > >> Cc: "engine-devel" , > >> vdsm-de...@lists.fedorahosted.org > >> Sent: Monday, September 23, 2013 1:47:47 PM > >> Subject: Re: [vdsm] stale gerrit patches > >> > >> On 09/23/2013 01:46 PM, David Caro wrote: > >>> On Mon 23 Sep 2013 12:36:58 PM CEST, Itamar Heim wrote: > we have some very old gerrit patches. > I'm for abandoning patches which were not touched over 60 days (to > begin with, I think the number should actually be lower). > they can always be re-opened by any interested party post their closure. > > i.e., looking at gerrit, the patch list should actually get attention, > and not be a few worth looking at, with a "lot of old patches" > > thoughts? > > Thanks, > Itamar > ___ > vdsm-devel mailing list > vdsm-de...@lists.fedorahosted.org > https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel > >>> > >>> It might helpful to have a cron-like script that checks the age of the > >>> posts and first notifies the sender, the reviewers and the maintainer, > >>> and if the patch is not updated in a certain period just abandons it. > >>> > >> > >> yep - warn after X days via email to just owner (or all subscribed to > >> the patch), and close if no activity for X+14 days or something like that. > > > > This will be annoying. > > > > And there are patches that pending with good reason. > > pending for 60 days with zero activity on them (no comment, no rebase, > nothing)? http://gerrit.ovirt.org/#/q/status:open+project:ovirt-engine+branch:master+topic:independent_deployments,n,z > > > > > Maintainers can close patches that are no interest nor progress. > > > > Alon > > > > ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] [vdsm] stale gerrit patches
On 09/23/2013 01:49 PM, Alon Bar-Lev wrote: - Original Message - From: "Itamar Heim" To: "David Caro" Cc: "engine-devel" , vdsm-de...@lists.fedorahosted.org Sent: Monday, September 23, 2013 1:47:47 PM Subject: Re: [vdsm] stale gerrit patches On 09/23/2013 01:46 PM, David Caro wrote: On Mon 23 Sep 2013 12:36:58 PM CEST, Itamar Heim wrote: we have some very old gerrit patches. I'm for abandoning patches which were not touched over 60 days (to begin with, I think the number should actually be lower). they can always be re-opened by any interested party post their closure. i.e., looking at gerrit, the patch list should actually get attention, and not be a few worth looking at, with a "lot of old patches" thoughts? Thanks, Itamar ___ vdsm-devel mailing list vdsm-de...@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel It might helpful to have a cron-like script that checks the age of the posts and first notifies the sender, the reviewers and the maintainer, and if the patch is not updated in a certain period just abandons it. yep - warn after X days via email to just owner (or all subscribed to the patch), and close if no activity for X+14 days or something like that. This will be annoying. And there are patches that pending with good reason. pending for 60 days with zero activity on them (no comment, no rebase, nothing)? Maintainers can close patches that are no interest nor progress. Alon ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
[Engine-devel] Suggesting new packaging and setup maintainer
Nominating Sandro Bonazzola as packaging and setup maintainer -- During his recent year of participation in ovirt-engine development, Sandro demonstrated a genuine care for the product health, great coding abilities, and great responsibility to the setup and packaging components. Sandro's contribution the the project is undoubtable, he's responsible for over 70 patches in ovirt-engine, and he's the maintainer of log-collector, iso-uploader and image-uploader packages. I suggest that Sandro will obtain +2 and merge rights in the ovirt-engine gerrit project, in the understanding that those rights should be used only in packaging and setup parts of the code. -- Ofer Schreiber. ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] [vdsm] stale gerrit patches
- Original Message - > From: "Itamar Heim" > To: "David Caro" > Cc: "engine-devel" , vdsm-de...@lists.fedorahosted.org > Sent: Monday, September 23, 2013 1:47:47 PM > Subject: Re: [vdsm] stale gerrit patches > > On 09/23/2013 01:46 PM, David Caro wrote: > > On Mon 23 Sep 2013 12:36:58 PM CEST, Itamar Heim wrote: > >> we have some very old gerrit patches. > >> I'm for abandoning patches which were not touched over 60 days (to > >> begin with, I think the number should actually be lower). > >> they can always be re-opened by any interested party post their closure. > >> > >> i.e., looking at gerrit, the patch list should actually get attention, > >> and not be a few worth looking at, with a "lot of old patches" > >> > >> thoughts? > >> > >> Thanks, > >> Itamar > >> ___ > >> vdsm-devel mailing list > >> vdsm-de...@lists.fedorahosted.org > >> https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel > > > > It might helpful to have a cron-like script that checks the age of the > > posts and first notifies the sender, the reviewers and the maintainer, > > and if the patch is not updated in a certain period just abandons it. > > > > yep - warn after X days via email to just owner (or all subscribed to > the patch), and close if no activity for X+14 days or something like that. This will be annoying. And there are patches that pending with good reason. Maintainers can close patches that are no interest nor progress. Alon ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] [vdsm] stale gerrit patches
On 09/23/2013 01:46 PM, David Caro wrote: On Mon 23 Sep 2013 12:36:58 PM CEST, Itamar Heim wrote: we have some very old gerrit patches. I'm for abandoning patches which were not touched over 60 days (to begin with, I think the number should actually be lower). they can always be re-opened by any interested party post their closure. i.e., looking at gerrit, the patch list should actually get attention, and not be a few worth looking at, with a "lot of old patches" thoughts? Thanks, Itamar ___ vdsm-devel mailing list vdsm-de...@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel It might helpful to have a cron-like script that checks the age of the posts and first notifies the sender, the reviewers and the maintainer, and if the patch is not updated in a certain period just abandons it. yep - warn after X days via email to just owner (or all subscribed to the patch), and close if no activity for X+14 days or something like that. ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] [vdsm] stale gerrit patches
On Mon 23 Sep 2013 12:36:58 PM CEST, Itamar Heim wrote: > we have some very old gerrit patches. > I'm for abandoning patches which were not touched over 60 days (to > begin with, I think the number should actually be lower). > they can always be re-opened by any interested party post their closure. > > i.e., looking at gerrit, the patch list should actually get attention, > and not be a few worth looking at, with a "lot of old patches" > > thoughts? > > Thanks, >Itamar > ___ > vdsm-devel mailing list > vdsm-de...@lists.fedorahosted.org > https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel It might helpful to have a cron-like script that checks the age of the posts and first notifies the sender, the reviewers and the maintainer, and if the patch is not updated in a certain period just abandons it. -- David Caro Red Hat Czech s.r.o. Continuous Integration Engineer - EMEA ENG Virtualization R&D Tel.: +420 532 294 605 Email: dc...@redhat.com Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic RHT Global #: 82-62605 ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
[Engine-devel] stale gerrit patches
we have some very old gerrit patches. I'm for abandoning patches which were not touched over 60 days (to begin with, I think the number should actually be lower). they can always be re-opened by any interested party post their closure. i.e., looking at gerrit, the patch list should actually get attention, and not be a few worth looking at, with a "lot of old patches" thoughts? Thanks, Itamar ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] External events and flood rate
Eli, any reason for hardcoding this [1]? i'd move it to vdc_config. [1] Math.max(auditLogable.getEventFloodInSec(), 30) // Min duration for External Events is 30 sec On 09/19/2013 12:50 AM, Morrissey, Christopher wrote: > Hi All, > > > > I’ve been working on submitting external events to oVirt through the REST > API. It seems to be working in general, although it appears that, no matter > what value I put for > the flood rate in the event, only 1 or so events are allowed every 30 > seconds. If I send another event during this time, I get an operation failed > exception. Should the > flood rate have any impact on this? Is there any way to allow my code to get > an event through when needed or should I have a thread that shoots them off > every 30 seconds if > several occur too quickly together? > > > > -Chris > > > > *Chris Morrissey* > > Software Engineer > > NetApp Inc. > > 919.476.4428 > > > > > > ___ > Engine-devel mailing list > Engine-devel@ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > -- Michael Pasternak RedHat, ENG-Virtualization R&D ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
[Engine-devel] 3.3.1/stable branch
to recap on previous discussions in ovirt meetings and emails: - 3.3.1 will be rebased off master branch for ovirt-engine/vdsm - for vdsm, danken will send more details, but general plan is to issue a release next week then create a stable branch for it - for engine, a stable ovirt-engine-3.3 branch was created today. all backports for patches to stabilize 3.3 should go to this branch. - will give this branch a few weeks to stabilize before releasing updates from it. - critical updates for 3.3.0 should be backported to both ovirt- engine-3.3 and ovirt-engine-3.3.0 branches. Thanks, Itamar ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] disk quota broken in latest master
http://gerrit.ovirt.org/#/c/19432/ [merged] should fix it. Thanks, Gilad. - Original Message - > From: "Gilad Chaplik" > To: "Dead Horse" > Cc: "engine-devel" > Sent: Sunday, September 22, 2013 9:15:44 AM > Subject: Re: [Engine-devel] disk quota broken in latest master > > Hi, > > looks like the quota drop-down isn't getting refreshed according to selected > storage domain. > can you please open a bug? > > Thanks, > Gilad. > > - Original Message - > > From: "Dead Horse" > > To: "engine-devel" > > Sent: Friday, September 20, 2013 9:44:20 PM > > Subject: Re: [Engine-devel] disk quota broken in latest master > > > > In further testing I note that assign quota under the disks tab of the > > associated vm in the admin portal does work. > > - DHC > > > > > > On Fri, Sep 20, 2013 at 2:24 PM, Dead Horse < deadhorseconsult...@gmail.com > > > > > wrote: > > > > > > > > > > really attach the logs > > > > I also notice that disks tab is no longer showing a disk inventory as well. > > > > - DHC > > > > > > On Fri, Sep 20, 2013 at 2:15 PM, Dead Horse < deadhorseconsult...@gmail.com > > > > > wrote: > > > > > > > > When attempting to add a disk from either the admin or power user portals > > the > > according disk quota associated with the requested storage domain cannot be > > assigned to the disk. The disk quota pull-down only will only display > > whatever quota is first in the list alphabetically. > > - DHC > > > > engine and vdsm logs attached. > > > > 2013-09-20 13:56:36,810 INFO [org.ovirt.engine.core.bll. > > LoginUserCommand] (ajp--127.0.0.1-8702-4) Running command: LoginUserCommand > > internal: false. > > 2013-09-20 13:56:36,833 INFO > > [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] > > (ajp--127.0.0.1-8702-4) Correlation ID: null, Call Stack: null, Custom > > Event > > ID: -1, Message: User admin@internal logged in. > > 2013-09-20 13:56:45,775 ERROR > > [org.ovirt.engine.core.utils.servlet.ServletUtils] (ajp--127.0.0.1-8702-6) > > Can't read file "/usr/share/doc/ovirt-engine/manual/DocumentationPath.csv" > > for request "/docs/DocumentationPath.csv", will send a 404 error response. > > 2013-09-20 13:57:00,456 INFO [org.ovirt.engine.core.bll.quota.QuotaManager] > > (DefaultQuartzScheduler_Worker-72) Quota Cache updated. (26 msec) > > 2013-09-20 13:57:01,810 INFO [org.ovirt.engine.core.bll.AddDiskCommand] > > (ajp--127.0.0.1-8702-10) Lock Acquired to object EngineLock > > [exclusiveLocks= > > key: ca3cecf1-090e-469a-aaad-e26ce47f89d8 value: VM_DISK_BOOT > > , sharedLocks= key: ca3cecf1-090e-469a-aaad-e26ce47f89d8 value: VM > > ] > > 2013-09-20 13:57:01,863 ERROR > > [org.ovirt.engine.core.bll.quota.QuotaManager] > > (ajp--127.0.0.1-8702-10) Quota storage parameters from command: > > org.ovirt.engine.core.bll.AddDiskCommand. Storage domain does not match > > quota > > 2013-09-20 13:57:01,901 INFO > > [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] > > (ajp--127.0.0.1-8702-10) Correlation ID: 5790e811, Job ID: > > 7abd0b95-4cd4-4cb5-864c-d51c4446a42d, Call Stack: null, Custom Event ID: > > -1, > > Message: Missing Quota for Disk, proceeding since in Permissive (Audit) > > mode. > > 2013-09-20 13:57:01,937 INFO [org.ovirt.engine.core.bll.AddDiskCommand] > > (ajp--127.0.0.1-8702-10) Running command: AddDiskCommand internal: false. > > Entities affected : ID: ca3cecf1-090e-469a-aaad-e26ce47f89d8 Type: VM, ID: > > 26be0640-01a3-415d-82c9-0a92f2f84c3f Type: Storage > > 2013-09-20 13:57:02,325 INFO > > [org.ovirt.engine.core.bll.AddImageFromScratchCommand] > > (ajp--127.0.0.1-8702-10) Running command: AddImageFromScratchCommand > > internal: true. Entities affected : ID: > > 26be0640-01a3-415d-82c9-0a92f2f84c3f > > Type: Storage > > 2013-09-20 13:57:02,446 INFO > > [org.ovirt.engine.core.bll.AddImageFromScratchCommand] > > (ajp--127.0.0.1-8702-10) Lock freed to object EngineLock [exclusiveLocks= > > key: ca3cecf1-090e-469a-aaad-e26ce47f89d8 value: VM_DISK_BOOT > > , sharedLocks= key: ca3cecf1-090e-469a-aaad-e26ce47f89d8 value: VM > > ] > > 2013-09-20 13:57:02,451 INFO > > [org.ovirt.engine.core.vdsbroker.irsbroker.CreateImageVDSCommand] > > (ajp--127.0.0.1-8702-10) START, CreateImageVDSCommand( storagePoolId = > > 5849b030-626e-47cb-ad90-3ce782d831b3, ignoreFailoverLimit = false, > > storageDomainId = 26be0640-01a3-415d-82c9-0a92f2f84c3f, imageGroupId = > > bf6458bc-627a-4399-822d-f72751edf303, imageSizeInBytes = 1073741824, > > volumeFormat = RAW, newImageId = 165089b7-4737-4900-9a7f-d2d888ec3514, > > newImageDescription = ), log id: 1ef8212d > > 2013-09-20 13:57:02,454 INFO > > [org.ovirt.engine.core.vdsbroker.irsbroker.CreateImageVDSCommand] > > (ajp--127.0.0.1-8702-10) -- executeIrsBrokerCommand: calling 'createVolume' > > with two new parameters: description and UUID > > 2013-09-20 13:57:02,456 INFO > > [org.ovirt.engine.core.vdsbroker.irsbroker.CreateImageVDSCommand] > > (ajp--127.0.0.1-8702-10) -- createVolume parameters:
