Re: [Engine-devel] Question about the attribute lunType (LUNs)
Hi Gustavo, - Original Message - From: Gustavo Frederico Temple Pedrosa gustavo.pedr...@eldorado.org.br To: engine-devel@ovirt.org Cc: Leonardo Bianconi leonardo.bianc...@eldorado.org.br Sent: Monday, July 29, 2013 9:06:53 PM Subject: [Engine-devel] Question about the attribute lunType (LUNs) Hello everyone, The QEMU/KVM on IBM POWER does not support iSCSI yet. This requires the implementation of methods that evaluate if a Disk is a iSCSI LUN or not, in order to avoid its use in this specific architecture. Looks like this can be determined by the attribute lunType (which is of the type StorageType, an Enum) of the class LUNs. But when I retrieve the object, the attribute lunType has the value UNKNOWN, even if I've setted it with another value. In the class LunDAODbFacadeImpl there is not a call to the entity.setLunType method. Does anyone know how to retrieve the attribute lunType? Is the UNKNOW value a bug? IIRC the lun type isn't saved in the DB - so that DAO will never set it. This attribute is currently being generated by checking if the LUN is FC or ISCSI based on it's connections (FC - currently means no connections while ISCSI means has connections). Therefore you won't see it being set when querying it from the DB. let me know if you have any further related questions. Liron. Thanks, Leonardo Bianconi/Vitor de Lima/Gustavo Pedrosa ___ 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] [Users] [Feedback required][host-deploy] Fedora-19 misses tar at minimal setup
Hi all, - Original Message - From: alo...@redhat.com, a...@redhat.com, Alon Bar-Lev redhat@redhat.com Sent: Monday, July 29, 2013 10:15:33 AM Subject: [Engine-devel] [Users] [Feedback required][host-deploy] Fedora-19 misses tar at minimal setup [snip] for some reason fedora-18/19 got tar out of base system, so we are forced to find some solution, although manual configuration is required anyway (repository, networking etc...). there was attempt to use python tar module, however this module has a bug when last block is empty, so it is not suitable for usage. cpio is alternative for fedora, however it is rightfully missing from other distributions as it is much less used. as we do not support hosts using different distributions, we are ok now. in future, we can use python self extract script, work already performed at: I1e5ddab9ae87979da7d7296c4f3c7ef08e21e903 at the price of complexity. Change-Id: I1386e7d688a9ec7e28519fb407478fd17cbab4ca Signed-off-by: Alon Bar-Lev alonbl at redhat.com [1] http://gerrit.ovirt.org/#/c/17396/ FWIW: I personally find it least ugly to choose neither cpio nor pyar, and require installing tar. Besides Ohad's case in the bug, do we know about real problems? Is there a specific requirement to be able to run a node on a minimal installation of $distro? Some other real complications this might cause? Anyway, if we do have to choose, I'd go with pyar and not cpio. cpio is used by rpm and initramfs, but other than that it's not very common (? IMHO), and if we go with it we might face ourselves in the same situation at some later point in time - that cpio will not be included in a minimal installation of $distro. Best regards, -- Didi ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] [Users] [Feedback required][host-deploy] Fedora-19 misses tar at minimal setup
On 07/30/2013 04:07 PM, Yedidyah Bar David wrote: Hi all, - Original Message - From: alo...@redhat.com, a...@redhat.com, Alon Bar-Lev redhat@redhat.com Sent: Monday, July 29, 2013 10:15:33 AM Subject: [Engine-devel] [Users] [Feedback required][host-deploy] Fedora-19 misses tar at minimal setup [snip] for some reason fedora-18/19 got tar out of base system, so we are forced to find some solution, although manual configuration is required anyway (repository, networking etc...). there was attempt to use python tar module, however this module has a bug when last block is empty, so it is not suitable for usage. cpio is alternative for fedora, however it is rightfully missing from other distributions as it is much less used. as we do not support hosts using different distributions, we are ok now. in future, we can use python self extract script, work already performed at: I1e5ddab9ae87979da7d7296c4f3c7ef08e21e903 at the price of complexity. Change-Id: I1386e7d688a9ec7e28519fb407478fd17cbab4ca Signed-off-by: Alon Bar-Lev alonbl at redhat.com [1] http://gerrit.ovirt.org/#/c/17396/ FWIW: I personally find it least ugly to choose neither cpio nor pyar, and require installing tar. I personally always install fedora/rhel at minimal install level when using it for oVirt, so i can appreciate the pain in failing on this. (i.e., my success criteria for testing things is i don't need to change anything to use it out of the box with minimal install). Besides Ohad's case in the bug, do we know about real problems? we fixed missing deps in the past around issues with minimal install. this is a chicken and an egg one, still i think it should be fixed. Is there a specific requirement to be able to run a node on a minimal installation of $distro? Some other real complications this might cause? I'd say yes... Anyway, if we do have to choose, I'd go with pyar and not cpio. cpio is used by rpm and initramfs, but other than that it's not very common (? IMHO), and if we go with it we might face ourselves in the same situation at some later point in time - that cpio will not be included in a minimal installation of $distro. Best regards, did we solve the issue with pyar? (i don't have a preference between the two, i just want/expect things to work out of the box without RTFM) ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] [Users] [Feedback required][host-deploy] Fedora-19 misses tar at minimal setup
Hello All, Starting the discussion again... I would like to receive feedback regarding how we should cope with a state presented to use by Fedora. Fedora-19 minimal setup does not install tar utility which is required to deploy files during the host-deploy process (Hosts-Add Host). I guess because of 2.8M in size (including translations) -- a standard commonly used utility was removed. There are three alternatives : 1. Instruct users who are using minimal installations to manually install tar utility just like they configure repository, dns, etc.. Benefit: simplicity. Benefit: use standard tools. Benefit: lower payload to transmit. Drawback: require tar at destination machine. 2. Do not use tar but self extracting python script, a patch is ready[1]. Benefit: ability to deploy environment in which tar is missing. Drawback: non standard tool at destination machine. Drawback: complexity within our code. 3. Do not use tar but cpio, a patch is ready[2]. Benefit: simplicity. Benefit: use standard tools. Benefit: lower payload to transmit. Benefit: ability to use Fedora-19 minimal. Drawback: cpio is even less common than tar, even if it exists in Fedora-19 it can be removed without anyone notice. Drawback: most other distributions will not have cpio in their minimal installation. [[[ There was 4rd alternative, using python tar module to deploy tar. However, there is a bug in that module when processing last block if empty. This is edge condition but happened to at least one of the users and I could reproduce it. ]]] What option do you prefer? Regards, Alon Bar-Lev [1] http://gerrit.ovirt.org/#/c/17295/ [2] http://gerrit.ovirt.org/#/c/17396/ ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] [Users] [Feedback required][host-deploy] Fedora-19 misses tar at minimal setup
On Jul 30, 2013, at 15:12 , Alon Bar-Lev alo...@redhat.com wrote: Hello All, Starting the discussion again... I would like to receive feedback regarding how we should cope with a state presented to use by Fedora. Fedora-19 minimal setup does not install tar utility which is required to deploy files during the host-deploy process (Hosts-Add Host). I guess because of 2.8M in size (including translations) -- a standard commonly used utility was removed. How about filing bug on that? This is such a basic utility I can't imagine anyone removing it. There are three alternatives : 1. Instruct users who are using minimal installations to manually install tar utility just like they configure repository, dns, etc.. Benefit: simplicity. Benefit: use standard tools. Benefit: lower payload to transmit. Drawback: require tar at destination machine. 2. Do not use tar but self extracting python script, a patch is ready[1]. Benefit: ability to deploy environment in which tar is missing. Drawback: non standard tool at destination machine. Drawback: complexity within our code. 3. Do not use tar but cpio, a patch is ready[2]. Benefit: simplicity. Benefit: use standard tools. Benefit: lower payload to transmit. Benefit: ability to use Fedora-19 minimal. Drawback: cpio is even less common than tar, even if it exists in Fedora-19 it can be removed without anyone notice. Drawback: most other distributions will not have cpio in their minimal installation. [[[ There was 4rd alternative, using python tar module to deploy tar. However, there is a bug in that module when processing last block if empty. This is edge condition but happened to at least one of the users and I could reproduce it. ]]] What option do you prefer? Regards, Alon Bar-Lev [1] http://gerrit.ovirt.org/#/c/17295/ [2] http://gerrit.ovirt.org/#/c/17396/ ___ 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] [Users] [Feedback required][host-deploy] Fedora-19 misses tar at minimal setup
I would advocate for option 2. - Original Message - From: Michal Skrivanek michal.skriva...@redhat.com To: Alon Bar-Lev alo...@redhat.com Cc: Juan Hernandez jhern...@redhat.com, engine-devel engine-devel@ovirt.org, arch a...@ovirt.org, users us...@ovirt.org Sent: Tuesday, July 30, 2013 3:25:24 PM Subject: Re: [Engine-devel] [Users] [Feedback required][host-deploy] Fedora-19misses tar at minimal setup On Jul 30, 2013, at 15:12 , Alon Bar-Lev alo...@redhat.com wrote: Hello All, Starting the discussion again... I would like to receive feedback regarding how we should cope with a state presented to use by Fedora. Fedora-19 minimal setup does not install tar utility which is required to deploy files during the host-deploy process (Hosts-Add Host). I guess because of 2.8M in size (including translations) -- a standard commonly used utility was removed. How about filing bug on that? This is such a basic utility I can't imagine anyone removing it. There are three alternatives : 1. Instruct users who are using minimal installations to manually install tar utility just like they configure repository, dns, etc.. Benefit: simplicity. Benefit: use standard tools. Benefit: lower payload to transmit. Drawback: require tar at destination machine. 2. Do not use tar but self extracting python script, a patch is ready[1]. Benefit: ability to deploy environment in which tar is missing. Drawback: non standard tool at destination machine. Drawback: complexity within our code. 3. Do not use tar but cpio, a patch is ready[2]. Benefit: simplicity. Benefit: use standard tools. Benefit: lower payload to transmit. Benefit: ability to use Fedora-19 minimal. Drawback: cpio is even less common than tar, even if it exists in Fedora-19 it can be removed without anyone notice. Drawback: most other distributions will not have cpio in their minimal installation. [[[ There was 4rd alternative, using python tar module to deploy tar. However, there is a bug in that module when processing last block if empty. This is edge condition but happened to at least one of the users and I could reproduce it. ]]] What option do you prefer? Regards, Alon Bar-Lev [1] http://gerrit.ovirt.org/#/c/17295/ [2] http://gerrit.ovirt.org/#/c/17396/ ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Arch mailing list a...@ovirt.org http://lists.ovirt.org/mailman/listinfo/arch ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Question about the attribute lunType (LUNs)
-Original Message- From: Itamar Heim [mailto:ih...@redhat.com] Sent: terça-feira, 30 de julho de 2013 07:12 To: Gustavo Frederico Temple Pedrosa Cc: engine-devel@ovirt.org; Leonardo Bianconi Subject: Re: [Engine-devel] Question about the attribute lunType (LUNs) On 07/29/2013 09:06 PM, Gustavo Frederico Temple Pedrosa wrote: Hello everyone, The QEMU/KVM on IBM POWER does not support iSCSI yet. This requires the implementation of methods that evaluate if a Disk is a iSCSI LUN or not, in order to avoid its use in this specific architecture. Looks like this can be determined by the attribute lunType (which is of the type StorageType, an Enum) of the class LUNs. But when I retrieve the object, the attribute lunType has the value UNKNOWN, even if I've setted it with another value. In the class LunDAODbFacadeImpl there is not a call to the entity.setLunType method. Does anyone know how to retrieve the attribute lunType? Is the UNKNOW value a bug? Thanks, Leonardo Bianconi/Vitor de Lima/Gustavo Pedrosa ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel Gustavo - what are you trying to achieve exactly? not allowing iscsi storage domains for ppc, or direct lun type disks (or something else)? Thanks, Itamar Hello Itamar, The QEMU/KVM on IBM POWER does not support direct LUN disks (i.e. -drive file=iscsi://ip_address/target/1), so this kind of device cannot be available on the frontend. Thanks, Leonardo Bianconi/Vitor de Lima/Gustavo Pedrosa ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Question about the attribute lunType (LUNs)
On 07/30/2013 05:13 PM, Gustavo Frederico Temple Pedrosa wrote: -Original Message- From: Itamar Heim [mailto:ih...@redhat.com] Sent: terça-feira, 30 de julho de 2013 07:12 To: Gustavo Frederico Temple Pedrosa Cc: engine-devel@ovirt.org; Leonardo Bianconi Subject: Re: [Engine-devel] Question about the attribute lunType (LUNs) On 07/29/2013 09:06 PM, Gustavo Frederico Temple Pedrosa wrote: Hello everyone, The QEMU/KVM on IBM POWER does not support iSCSI yet. This requires the implementation of methods that evaluate if a Disk is a iSCSI LUN or not, in order to avoid its use in this specific architecture. Looks like this can be determined by the attribute lunType (which is of the type StorageType, an Enum) of the class LUNs. But when I retrieve the object, the attribute lunType has the value UNKNOWN, even if I've setted it with another value. In the class LunDAODbFacadeImpl there is not a call to the entity.setLunType method. Does anyone know how to retrieve the attribute lunType? Is the UNKNOW value a bug? Thanks, Leonardo Bianconi/Vitor de Lima/Gustavo Pedrosa ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel Gustavo - what are you trying to achieve exactly? not allowing iscsi storage domains for ppc, or direct lun type disks (or something else)? Thanks, Itamar Hello Itamar, The QEMU/KVM on IBM POWER does not support direct LUN disks (i.e. -drive file=iscsi://ip_address/target/1), so this kind of device cannot be available on the frontend. Thanks, Leonardo Bianconi/Vitor de Lima/Gustavo Pedrosa i could be wrong, but i'm pretty sure direct lun disks in ovirt are done by the host doing the iscsi connection, and mounting the disk as a regular block device to the guest? ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] [ATN] oVirt 3.3 release, moving to RC [3.3 branching, blockers review]
- Original Message - From: Moran Goldboim mgold...@redhat.com To: engine-devel engine-devel@ovirt.org, vdsm-de...@ovirt.org, us...@ovirt.org Sent: Tuesday, July 30, 2013 6:05:46 PM Subject: [Engine-devel] [ATN] oVirt 3.3 release, moving to RC [3.3 branching, blockers review] We would like to go a head on oVirt 3.3 release process and issue an RC for tomorrow meeting: Maintainers/ Package owners == -branch your git repo (master) with 3.3 branch (making master ready for 3.4) -for tomorrow meeting, overview [1] , see if you have any changes to it -if you don't have any blockers under your component, please branch 3.3 with RC1 branch | -master | -engine_3.3 | -RC1 | -engine_3.2 Please use proper notation... ovirt-engine-3.3.0 branch for 3.3.0 release cycle ovirt-engine-3.3.0_rc1 - for rc1 tag or branch ... Users with your experience from test day and with nightlies, if you feel there are additional candidates to block this version for please add it to the tracker bug [1]. Suggested Schedule Wed Jul 31st - review of blockers for the version and component readiness Mon Aug 5th - RC1 release Wed Aug 7th - Release readiness review (in case of blockers an RC2 will be issued) Thanks. [1] Bug 918494 - Tracker: oVirt 3.3 release ___ 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] [Users] [Feedback required][host-deploy] Fedora-19 misses tar at minimal setup
Il 30/07/2013 15:12, Alon Bar-Lev ha scritto: Hello All, Starting the discussion again... I would like to receive feedback regarding how we should cope with a state presented to use by Fedora. Fedora-19 minimal setup does not install tar utility which is required to deploy files during the host-deploy process (Hosts-Add Host). I guess because of 2.8M in size (including translations) -- a standard commonly used utility was removed. There are three alternatives : 1. Instruct users who are using minimal installations to manually install tar utility just like they configure repository, dns, etc.. Benefit: simplicity. Benefit: use standard tools. Benefit: lower payload to transmit. Drawback: require tar at destination machine. 2. Do not use tar but self extracting python script, a patch is ready[1]. Benefit: ability to deploy environment in which tar is missing. Drawback: non standard tool at destination machine. Drawback: complexity within our code. 3. Do not use tar but cpio, a patch is ready[2]. Benefit: simplicity. Benefit: use standard tools. Benefit: lower payload to transmit. Benefit: ability to use Fedora-19 minimal. Drawback: cpio is even less common than tar, even if it exists in Fedora-19 it can be removed without anyone notice. Drawback: most other distributions will not have cpio in their minimal installation. [[[ There was 4rd alternative, using python tar module to deploy tar. However, there is a bug in that module when processing last block if empty. This is edge condition but happened to at least one of the users and I could reproduce it. ]]] What option do you prefer? Well, honestly, the solution I like more than the others is having the python tar bug fixed and be free to use the python tar lib. I would like to exclude cpio: it's on rpm based distro but not commonly available on others. I would like to exclude the RTFM solution, having it working out of the box. So my second choice is using a self extracting script. If you think pyar is a non standard tool, do you have considered the use of shar? Or do you think it's also a non standard tool? Regards, Alon Bar-Lev [1] http://gerrit.ovirt.org/#/c/17295/ [2] http://gerrit.ovirt.org/#/c/17396/ ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel -- 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] [Users] [Feedback required][host-deploy] Fedora-19 misses tar at minimal setup
- Original Message - From: Sandro Bonazzola sbona...@redhat.com To: Alon Bar-Lev alo...@redhat.com Cc: users us...@ovirt.org, arch a...@ovirt.org, engine-devel engine-devel@ovirt.org, Juan Hernandez jhern...@redhat.com Sent: Tuesday, July 30, 2013 6:11:38 PM Subject: Re: [Engine-devel] [Users] [Feedback required][host-deploy] Fedora-19 misses tar at minimal setup Il 30/07/2013 15:12, Alon Bar-Lev ha scritto: Hello All, Starting the discussion again... I would like to receive feedback regarding how we should cope with a state presented to use by Fedora. Fedora-19 minimal setup does not install tar utility which is required to deploy files during the host-deploy process (Hosts-Add Host). I guess because of 2.8M in size (including translations) -- a standard commonly used utility was removed. There are three alternatives : 1. Instruct users who are using minimal installations to manually install tar utility just like they configure repository, dns, etc.. Benefit: simplicity. Benefit: use standard tools. Benefit: lower payload to transmit. Drawback: require tar at destination machine. 2. Do not use tar but self extracting python script, a patch is ready[1]. Benefit: ability to deploy environment in which tar is missing. Drawback: non standard tool at destination machine. Drawback: complexity within our code. 3. Do not use tar but cpio, a patch is ready[2]. Benefit: simplicity. Benefit: use standard tools. Benefit: lower payload to transmit. Benefit: ability to use Fedora-19 minimal. Drawback: cpio is even less common than tar, even if it exists in Fedora-19 it can be removed without anyone notice. Drawback: most other distributions will not have cpio in their minimal installation. [[[ There was 4rd alternative, using python tar module to deploy tar. However, there is a bug in that module when processing last block if empty. This is edge condition but happened to at least one of the users and I could reproduce it. ]]] What option do you prefer? Well, honestly, the solution I like more than the others is having the python tar bug fixed and be free to use the python tar lib. I would like to exclude cpio: it's on rpm based distro but not commonly available on others. I would like to exclude the RTFM solution, having it working out of the box. So my second choice is using a self extracting script. If you think pyar is a non standard tool, do you have considered the use of shar? Or do you think it's also a non standard tool? shar needs dependencies on remote: - md5sum - uudecode Regards, Alon Bar-Lev [1] http://gerrit.ovirt.org/#/c/17295/ [2] http://gerrit.ovirt.org/#/c/17396/ ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel -- 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] [Users] [ATN] oVirt 3.3 release, moving to RC [3.3 branching, blockers review]
On Tue, Jul 30, 2013 at 06:05:46PM +0300, Moran Goldboim wrote: We would like to go a head on oVirt 3.3 release process and issue an RC for tomorrow meeting: Maintainers/ Package owners == -branch your git repo (master) with 3.3 branch (making master ready for 3.4) -for tomorrow meeting, overview [1], see if you have any changes to it -if you don't have any blockers under your component, please branch 3.3 with RC1 branch | -master | -engine_3.3 | -RC1 | -engine_3.2 ... Users with your experience from test day and with nightlies, if you feel there are additional candidates to block this version for please add it to the tracker bug [1]. Suggested Schedule Wed Jul 31st - review of blockers for the version and component readiness Mon Aug 5th - RC1 release Wed Aug 7th - Release readiness review (in case of blockers an RC2 will be issued) Thanks. [1]*Bug 918494* https://bugzilla.redhat.com/show_bug.cgi?id=918494 -Tracker: oVirt 3.3 release I've just tagged vdsm-4.12.0 and branched ovirt-3.3 branch for the vdsm repository starting at git has 620343d6317c849fc985a5083cebb68c995f7c15. Expect a deluge of non-ovirt-3.3 merges to the master branch soon. Future ovirt-3.3 fixes would have to be backported and cherry-picked. Dan. ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] [Users] [Feedback required][host-deploy] Fedora-19 misses tar at minimal setup
On 07/30/2013 03:07 PM, Yedidyah Bar David wrote: Hi all, - Original Message - From: alo...@redhat.com, a...@redhat.com, Alon Bar-Lev redhat@redhat.com Sent: Monday, July 29, 2013 10:15:33 AM Subject: [Engine-devel] [Users] [Feedback required][host-deploy] Fedora-19 misses tar at minimal setup [snip] for some reason fedora-18/19 got tar out of base system, so we are forced to find some solution, although manual configuration is required anyway (repository, networking etc...). there was attempt to use python tar module, however this module has a bug when last block is empty, so it is not suitable for usage. cpio is alternative for fedora, however it is rightfully missing from other distributions as it is much less used. as we do not support hosts using different distributions, we are ok now. in future, we can use python self extract script, work already performed at: I1e5ddab9ae87979da7d7296c4f3c7ef08e21e903 at the price of complexity. Change-Id: I1386e7d688a9ec7e28519fb407478fd17cbab4ca Signed-off-by: Alon Bar-Lev alonbl at redhat.com [1] http://gerrit.ovirt.org/#/c/17396/ FWIW: I personally find it least ugly to choose neither cpio nor pyar, and require installing tar. Besides Ohad's case in the bug, do we know about real problems? Is there a specific requirement to be able to run a node on a minimal installation of $distro? Some other real complications this might cause? Anyway, if we do have to choose, I'd go with pyar and not cpio. cpio is used by rpm and initramfs, but other than that it's not very common (? IMHO), and if we go with it we might face ourselves in the same situation at some later point in time - that cpio will not be included in a minimal installation of $distro. Best regards, As far as I know most distributions use initramfs to boot, and that requires the cpio command to build it, so all machines running Fedora, RHEL, CentOS, Debian, Ubuntu and Gentoo (if using genkernel) should have cpio installed even for minimal installations. -- Dirección Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta 3ºD, 28016 Madrid, Spain Inscrita en el Reg. Mercantil de Madrid – C.I.F. B82657941 - Red Hat S.L. ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] [Users] [Feedback required][host-deploy] Fedora-19 misses tar at minimal setup
- Original Message - From: Juan Hernandez jhern...@redhat.com To: Yedidyah Bar David d...@redhat.com Cc: engine-devel@ovirt.org Sent: Tuesday, July 30, 2013 9:25:13 PM Subject: Re: [Engine-devel] [Users] [Feedback required][host-deploy] Fedora-19 misses tar at minimal setup On 07/30/2013 03:07 PM, Yedidyah Bar David wrote: Hi all, - Original Message - From: alo...@redhat.com, a...@redhat.com, Alon Bar-Lev redhat@redhat.com Sent: Monday, July 29, 2013 10:15:33 AM Subject: [Engine-devel] [Users] [Feedback required][host-deploy] Fedora-19 misses tar at minimal setup [snip] for some reason fedora-18/19 got tar out of base system, so we are forced to find some solution, although manual configuration is required anyway (repository, networking etc...). there was attempt to use python tar module, however this module has a bug when last block is empty, so it is not suitable for usage. cpio is alternative for fedora, however it is rightfully missing from other distributions as it is much less used. as we do not support hosts using different distributions, we are ok now. in future, we can use python self extract script, work already performed at: I1e5ddab9ae87979da7d7296c4f3c7ef08e21e903 at the price of complexity. Change-Id: I1386e7d688a9ec7e28519fb407478fd17cbab4ca Signed-off-by: Alon Bar-Lev alonbl at redhat.com [1] http://gerrit.ovirt.org/#/c/17396/ FWIW: I personally find it least ugly to choose neither cpio nor pyar, and require installing tar. Besides Ohad's case in the bug, do we know about real problems? Is there a specific requirement to be able to run a node on a minimal installation of $distro? Some other real complications this might cause? Anyway, if we do have to choose, I'd go with pyar and not cpio. cpio is used by rpm and initramfs, but other than that it's not very common (? IMHO), and if we go with it we might face ourselves in the same situation at some later point in time - that cpio will not be included in a minimal installation of $distro. Best regards, As far as I know most distributions use initramfs to boot, and that requires the cpio command to build it, so all machines running Fedora, RHEL, CentOS, Debian, Ubuntu and Gentoo (if using genkernel) should have cpio installed even for minimal installations. Hi, Binary based distributions do not build initramfs on the fly, right? Require cpio to build initramfs is like require gcc to build kernel, no? RHEL, CentOS does have tar at minimal as far as I know... Gentoo does not have genkernel/cpio in stage3 (minimal). All but Fedora have tar at minimal. Regards, Alon ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] [Users] [Feedback required][host-deploy] Fedora-19 misses tar at minimal setup
On 07/30/2013 08:29 PM, Alon Bar-Lev wrote: - Original Message - From: Juan Hernandez jhern...@redhat.com To: Yedidyah Bar David d...@redhat.com Cc: engine-devel@ovirt.org Sent: Tuesday, July 30, 2013 9:25:13 PM Subject: Re: [Engine-devel] [Users] [Feedback required][host-deploy] Fedora-19 misses tar at minimal setup On 07/30/2013 03:07 PM, Yedidyah Bar David wrote: Hi all, - Original Message - From: alo...@redhat.com, a...@redhat.com, Alon Bar-Lev redhat@redhat.com Sent: Monday, July 29, 2013 10:15:33 AM Subject: [Engine-devel] [Users] [Feedback required][host-deploy] Fedora-19 misses tar at minimal setup [snip] for some reason fedora-18/19 got tar out of base system, so we are forced to find some solution, although manual configuration is required anyway (repository, networking etc...). there was attempt to use python tar module, however this module has a bug when last block is empty, so it is not suitable for usage. cpio is alternative for fedora, however it is rightfully missing from other distributions as it is much less used. as we do not support hosts using different distributions, we are ok now. in future, we can use python self extract script, work already performed at: I1e5ddab9ae87979da7d7296c4f3c7ef08e21e903 at the price of complexity. Change-Id: I1386e7d688a9ec7e28519fb407478fd17cbab4ca Signed-off-by: Alon Bar-Lev alonbl at redhat.com [1] http://gerrit.ovirt.org/#/c/17396/ FWIW: I personally find it least ugly to choose neither cpio nor pyar, and require installing tar. Besides Ohad's case in the bug, do we know about real problems? Is there a specific requirement to be able to run a node on a minimal installation of $distro? Some other real complications this might cause? Anyway, if we do have to choose, I'd go with pyar and not cpio. cpio is used by rpm and initramfs, but other than that it's not very common (? IMHO), and if we go with it we might face ourselves in the same situation at some later point in time - that cpio will not be included in a minimal installation of $distro. Best regards, As far as I know most distributions use initramfs to boot, and that requires the cpio command to build it, so all machines running Fedora, RHEL, CentOS, Debian, Ubuntu and Gentoo (if using genkernel) should have cpio installed even for minimal installations. Hi, Binary based distributions do not build initramfs on the fly, right? Require cpio to build initramfs is like require gcc to build kernel, no? Fedora, RHEL, CentOS, Debian and Ubuntu (for example) do build initramfs on the fly when the kernel is installed/updated, and that uses the cpio command. So any updatable installation has it. RHEL, CentOS does have tar at minimal as far as I know... Gentoo does not have genkernel/cpio in stage3 (minimal). It doesn't have any kernel either, so you need to build it (according to the installations instructions) which would need to build the initramfs as well, and that (if using genkernel, at least) requires cpio. All but Fedora have tar at minimal. Regards, Alon -- Dirección Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta 3ºD, 28016 Madrid, Spain Inscrita en el Reg. Mercantil de Madrid – C.I.F. B82657941 - Red Hat S.L. ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] [Users] [ATN] oVirt 3.3 release, moving to RC [3.3 branching, blockers review]
On 07/30/2013 09:56 PM, Itamar Heim wrote: On 07/30/2013 06:05 PM, Moran Goldboim wrote: We would like to go a head on oVirt 3.3 release process and issue an RC how can we do this before folks review all the bugs with target release of 3.3 and either suggest them as blockers or move them from 3.3? there are currently 59 NEW, 7 ASSIGNED and 22 POST with target release of 3.3? http://alturl.com/aq23x that the aim of this mail, maintainers should review their realm for blockers (unscrubbed bugs as well), and this release should get into stabilization mode. by tomorrow we should have a better view on what are the blockers for the version, we are already going to delay this release, and i would like to get a clear view by tomorrow, as mentioned later in the mail - RC should go out without any known blockers. for tomorrow meeting: Maintainers/ Package owners == -branch your git repo (master) with 3.3 branch (making master ready for 3.4) -for tomorrow meeting, overview [1], see if you have any changes to it -if you don't have any blockers under your component, please branch 3.3 with RC1 branch | -master | -engine_3.3 | -RC1 | -engine_3.2 ... Users with your experience from test day and with nightlies, if you feel there are additional candidates to block this version for please add it to the tracker bug [1]. Suggested Schedule Wed Jul 31st - review of blockers for the version and component readiness Mon Aug 5th - RC1 release Wed Aug 7th - Release readiness review (in case of blockers an RC2 will be issued) Thanks. [1]*Bug 918494* https://bugzilla.redhat.com/show_bug.cgi?id=918494 -Tracker: oVirt 3.3 release ___ Users mailing list us...@ovirt.org http://lists.ovirt.org/mailman/listinfo/users ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] [Users] [ATN] oVirt 3.3 release, moving to RC [3.3 branching, blockers review]
On 07/30/2013 06:05 PM, Moran Goldboim wrote: We would like to go a head on oVirt 3.3 release process and issue an RC how can we do this before folks review all the bugs with target release of 3.3 and either suggest them as blockers or move them from 3.3? there are currently 59 NEW, 7 ASSIGNED and 22 POST with target release of 3.3? http://alturl.com/aq23x for tomorrow meeting: Maintainers/ Package owners == -branch your git repo (master) with 3.3 branch (making master ready for 3.4) -for tomorrow meeting, overview [1], see if you have any changes to it -if you don't have any blockers under your component, please branch 3.3 with RC1 branch | -master | -engine_3.3 | -RC1 | -engine_3.2 ... Users with your experience from test day and with nightlies, if you feel there are additional candidates to block this version for please add it to the tracker bug [1]. Suggested Schedule Wed Jul 31st - review of blockers for the version and component readiness Mon Aug 5th - RC1 release Wed Aug 7th - Release readiness review (in case of blockers an RC2 will be issued) Thanks. [1]*Bug 918494* https://bugzilla.redhat.com/show_bug.cgi?id=918494 -Tracker: oVirt 3.3 release ___ Users mailing list us...@ovirt.org http://lists.ovirt.org/mailman/listinfo/users ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Question about the attribute lunType (LUNs)
-Original Message- From: Itamar Heim [mailto:ih...@redhat.com] Sent: terça-feira, 30 de julho de 2013 11:15 To: Gustavo Frederico Temple Pedrosa Cc: engine-devel@ovirt.org; Leonardo Bianconi; Vitor de Lima; Federico Simoncelli Subject: Re: [Engine-devel] Question about the attribute lunType (LUNs) On 07/30/2013 05:13 PM, Gustavo Frederico Temple Pedrosa wrote: -Original Message- From: Itamar Heim [mailto:ih...@redhat.com] Sent: terça-feira, 30 de julho de 2013 07:12 To: Gustavo Frederico Temple Pedrosa Cc: engine-devel@ovirt.org; Leonardo Bianconi Subject: Re: [Engine-devel] Question about the attribute lunType (LUNs) On 07/29/2013 09:06 PM, Gustavo Frederico Temple Pedrosa wrote: Hello everyone, The QEMU/KVM on IBM POWER does not support iSCSI yet. This requires the implementation of methods that evaluate if a Disk is a iSCSI LUN or not, in order to avoid its use in this specific architecture. Looks like this can be determined by the attribute lunType (which is of the type StorageType, an Enum) of the class LUNs. But when I retrieve the object, the attribute lunType has the value UNKNOWN, even if I've setted it with another value. In the class LunDAODbFacadeImpl there is not a call to the entity.setLunType method. Does anyone know how to retrieve the attribute lunType? Is the UNKNOW value a bug? Thanks, Leonardo Bianconi/Vitor de Lima/Gustavo Pedrosa ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel Gustavo - what are you trying to achieve exactly? not allowing iscsi storage domains for ppc, or direct lun type disks (or something else)? Thanks, Itamar Hello Itamar, The QEMU/KVM on IBM POWER does not support direct LUN disks (i.e. - drive file=iscsi://ip_address/target/1), so this kind of device cannot be available on the frontend. Thanks, Leonardo Bianconi/Vitor de Lima/Gustavo Pedrosa i could be wrong, but i'm pretty sure direct lun disks in ovirt are done by the host doing the iscsi connection, and mounting the disk as a regular block device to the guest? Yes, you are correct. We tested and the VDSM does not pass LUNs directly to QEMU. ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] [Users] [Feedback required][host-deploy] Fedora-19 misses tar at minimal setup
On 07/30/2013 09:25 AM, Michal Skrivanek wrote: On Jul 30, 2013, at 15:12 , Alon Bar-Lev alo...@redhat.com wrote: Hello All, Starting the discussion again... I would like to receive feedback regarding how we should cope with a state presented to use by Fedora. Fedora-19 minimal setup does not install tar utility which is required to deploy files during the host-deploy process (Hosts-Add Host). I guess because of 2.8M in size (including translations) -- a standard commonly used utility was removed. How about filing bug on that? This is such a basic utility I can't imagine anyone removing it. +1 I do agree with Michael. I have opened a thread in fedora devel mailing list anyway. There are three alternatives : 1. Instruct users who are using minimal installations to manually install tar utility just like they configure repository, dns, etc.. Benefit: simplicity. Benefit: use standard tools. Benefit: lower payload to transmit. Drawback: require tar at destination machine. 2. Do not use tar but self extracting python script, a patch is ready[1]. Benefit: ability to deploy environment in which tar is missing. Drawback: non standard tool at destination machine. Drawback: complexity within our code. 3. Do not use tar but cpio, a patch is ready[2]. Benefit: simplicity. Benefit: use standard tools. Benefit: lower payload to transmit. Benefit: ability to use Fedora-19 minimal. Drawback: cpio is even less common than tar, even if it exists in Fedora-19 it can be removed without anyone notice. Drawback: most other distributions will not have cpio in their minimal installation. [[[ There was 4rd alternative, using python tar module to deploy tar. However, there is a bug in that module when processing last block if empty. This is edge condition but happened to at least one of the users and I could reproduce it. ]]] What option do you prefer? Regards, Alon Bar-Lev [1] http://gerrit.ovirt.org/#/c/17295/ [2] http://gerrit.ovirt.org/#/c/17396/ ___ 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 -- Cheers Douglas ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] [Users] [Feedback required][host-deploy] Fedora-19 misses tar at minimal setup
On Tue, Jul 30, 2013 at 10:09:47AM -0400, Antoni Segura Puimedon wrote: I would advocate for option 2. - Original Message - From: Michal Skrivanek michal.skriva...@redhat.com To: Alon Bar-Lev alo...@redhat.com Cc: Juan Hernandez jhern...@redhat.com, engine-devel engine-devel@ovirt.org, arch a...@ovirt.org, users us...@ovirt.org Sent: Tuesday, July 30, 2013 3:25:24 PM Subject: Re: [Engine-devel] [Users] [Feedback required][host-deploy] Fedora-19 misses tar at minimal setup On Jul 30, 2013, at 15:12 , Alon Bar-Lev alo...@redhat.com wrote: Hello All, Starting the discussion again... I would like to receive feedback regarding how we should cope with a state presented to use by Fedora. Fedora-19 minimal setup does not install tar utility which is required to deploy files during the host-deploy process (Hosts-Add Host). I guess because of 2.8M in size (including translations) -- a standard commonly used utility was removed. How about filing bug on that? This is such a basic utility I can't imagine anyone removing it. There are three alternatives : 1. Instruct users who are using minimal installations to manually install tar utility just like they configure repository, dns, etc.. Benefit: simplicity. Benefit: use standard tools. Benefit: lower payload to transmit. Drawback: require tar at destination machine. 2. Do not use tar but self extracting python script, a patch is ready[1]. Benefit: ability to deploy environment in which tar is missing. Drawback: non standard tool at destination machine. Drawback: complexity within our code. How about option 2.1: convince Fedora to reintroduce tar? It is ironic that Gnome is shipped by default, but not such a staple utility. Where in Fedora did this decision take place? Can it be undone? Is it commonplace these days among other distros to boycot tar? Dan. ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] [Users] [ATN] oVirt 3.3 release, moving to RC [3.3 branching, blockers review]
On Tue, Jul 30, 2013 at 06:05:46PM +0300, Moran Goldboim wrote: We would like to go a head on oVirt 3.3 release process and issue an RC for tomorrow meeting: Maintainers/ Package owners == -branch your git repo (master) with 3.3 branch (making master ready for 3.4) -for tomorrow meeting, overview [1], see if you have any changes to it -if you don't have any blockers under your component, please branch 3.3 with RC1 branch | -master | -engine_3.3 | -RC1 | -engine_3.2 ... Users with your experience from test day and with nightlies, if you feel there are additional candidates to block this version for please add it to the tracker bug [1]. Suggested Schedule Wed Jul 31st - review of blockers for the version and component readiness Mon Aug 5th - RC1 release Wed Aug 7th - Release readiness review (in case of blockers an RC2 will be issued) Thanks. [1]*Bug 918494* https://bugzilla.redhat.com/show_bug.cgi?id=918494 -Tracker: oVirt 3.3 release I've just tagged vdsm-4.12.0 and branched ovirt-3.3 branch for the vdsm repository starting at git has 620343d6317c849fc985a5083cebb68c995f7c15. Expect a deluge of non-ovirt-3.3 merges to the master branch soon. Future ovirt-3.3 fixes would have to be backported and cherry-picked. Dan. ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
