From fabiand at redhat.com Mon Mar 3 16:34:50 2014 From: fabiand at redhat.com (Fabian Deutsch) Date: Mon, 03 Mar 2014 17:34:50 +0100 Subject: [node-devel] Introduction of ovirt-node-config Message-ID: <1393864490.30425.41.camel@fdeutsch-laptop.local> Hey, node 3.0 moved much of the configuration stuff to the ovirt-node-config module, but until now the whole configuration could only be done through the TUI or during auto-installation. ovirt-node-config is a small tool (or shall become one) which exposes all classes from ovirt.node.config and which can be used to: 1. Introspect the classes and see what they do 2. Run the classes to perform the configuration from the console I see two main use cases for this: 1. Test automation - This eases the testing of the functionalit ywhich does the actual configuration work. Basically we can write tests like: (Pseudo code) $ ovirt-node-config run Network.configure_disable_networking $ assert_no_files_like "/etc/sysconfig/network-scripts/ifcfg-*" or $ ovirt-node-config run SSH.configure_pw_auth true $ assert_file_contains /etc/ssh/sshd_config "PWAuth yes" 2. Reuse Other components can use this tool to perform high-level configuration on Node. The corresponding draft can be found here: http://gerrit.ovirt.org/#/c/24968/ The code is not yet fully functional. Thoughts suggestions and anything else is welcome :) - fabian -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part URL: From fabiand at redhat.com Mon Mar 3 16:40:34 2014 From: fabiand at redhat.com (Fabian Deutsch) Date: Mon, 03 Mar 2014 17:40:34 +0100 Subject: [node-devel] Introduction of ovirt-node-features Message-ID: <1393864834.30425.47.camel@fdeutsch-laptop.local> Hey, another introduction. Recently I merged a series of patches to let components export informations about themselves. When we moved to a simple core and extension through plugins model an outsider can't make hard assumptions about the functionality a Node provides anymore. Thus we needed a mechanism to expose the features a Node has. The current (early and simple) mechanism allows TUI plugins to expose properties. ovirt-node-features is the tool which dumps the registered features: E.g. a run on the current master reveals: $ PYTHONPATH=src scripts/ovirt-node-features dumpxml cpe:/o:fedoraproject:fedora:19 The registration currently happens by plugins defining a magic function, which is the called by the tool do discover the exposed features. The idea is to extend this mechanism to provide other ways to expose features. E.g. let plugins drop an xml snippet in some dir. - fabian -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part URL: From leiwang at redhat.com Tue Mar 4 06:18:23 2014 From: leiwang at redhat.com (Lei Wang) Date: Tue, 04 Mar 2014 14:18:23 +0800 Subject: [node-devel] oVirt Node filesystem layout on resources.ovirt.org In-Reply-To: <1393406242.2969.19.camel@fdeutsch-laptop.local> References: <1393402707.2969.13.camel@fdeutsch-laptop.local> <280111502.18113260.1393405400580.JavaMail.zimbra@redhat.com> <1393406242.2969.19.camel@fdeutsch-laptop.local> Message-ID: <5315702F.4060605@redhat.com> The new layout looks nice :-) http://resources.ovirt.org/pub/ovirt-node-base-3.0/rpm/el6/noarch/ Lei Wang On 02/26/2014 05:17 PM, Fabian Deutsch wrote: > Am Mittwoch, den 26.02.2014, 04:03 -0500 schrieb Kiril Nesenko: >> We are moving to a new layout resources.ovirt.org/pub. >> >> Please let us know where do you want to put your files. > For that case I'd suggest: > pub > + ovirt-node-base-3.0 > + iso > + rpm > + src > + ovirt-node-base-stable (symlink to ovirt-node-base-3.0) > > - fabian > >> - Kiril >> >> ----- Original Message ----- >>> From: "Fabian Deutsch" >>> To: infra at ovirt.org >>> Cc: "node-devel" >>> Sent: Wednesday, February 26, 2014 10:18:27 AM >>> Subject: oVirt Node filesystem layout on resources.ovirt.org >>> >>> Hey, >>> >>> currently it is not easy to find oVirt Node (Base Image) releases on >>> resources.o.o - I'd like to suggest a layout simplification to remove >>> some clutter, improve the findability of isos and ease the maintenance. >>> >>> Currently the (Node related) layout is: >>> >>> releases >>> + base >>> + node-base >>> + 3.0.0 >>> + iso >>> + rpm >>> + alpha >>> + beta >>> + nightly (symlink?) >>> + stable (symlink to 3.0.0?) >>> >>> could we please change the tree to be more like: >>> >>> releases >>> + node-base >>> + 3.0 >>> + iso >>> + rpm >>> + stable (symlink to 3.0) >>> >>> Some notes on the removed paths: >>> base - Was unused >>> alpha - To reduce overhead I'd use jenkins builds for alpha >>> beta - To reduce overhead I'd use jenkins builds for beta >>> beta - To reduce overhead I'd use jenkins builds for nightlies >>> >>> Some more notes: >>> 3.0 - Just this one dir for all updates >>> >>> This boils down to Node just offering stable images on resources.o.o. >>> Everything else can be pulled from jenkins (once we get everything into >>> shape again). >>> >>> This suggestion is just for the "base image". Once the base images are >>> in place, jenkins can pick up the base images and generate "layered" >>> images which include vdsm (to be used with Engine). >>> The layered images can then be kept in the same place where the >>> remaining oVirt (Engine, vdsm, ...) packages are kept (for 3.3.3 >>> in /releases/3.3.3/...). >>> >>> Does that make sense? >>> >>> - fabian >>> >>> _______________________________________________ >>> Infra mailing list >>> Infra at ovirt.org >>> http://lists.ovirt.org/mailman/listinfo/infra >>> > > > _______________________________________________ > node-devel mailing list > node-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/node-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From hadong at redhat.com Tue Mar 4 08:29:04 2014 From: hadong at redhat.com (Haiyang Dong) Date: Tue, 4 Mar 2014 03:29:04 -0500 (EST) Subject: [node-devel] Introduction of ovirt-node-config In-Reply-To: <1393864490.30425.41.camel@fdeutsch-laptop.local> References: <1393864490.30425.41.camel@fdeutsch-laptop.local> Message-ID: <364027053.7000161.1393921744626.JavaMail.zimbra@redhat.com> Hey Fabian, i found the patch http://gerrit.ovirt.org/#/c/24968/ didn't work well. for example: ovirt-node-config run [[. [ [] ...]]]] didn't real work. eg: ./ovirt-node-config r KDump.configure_local > Configuring kdump ----------------- Checking pre-conditions ... (1/2) Backing up config files (2/2) Removing kdump backup All changes were applied successfully. it will configure kdump with disable type, not configure with local type. so i push a patch http://gerrit.ovirt.org/#/c/25300/ depends on parent's patch http://gerrit.ovirt.org/#/c/24968 to fix this issue. ----- Original Message ----- From: "Fabian Deutsch" To: "node-devel" Sent: Tuesday, March 4, 2014 12:34:50 AM Subject: [node-devel] Introduction of ovirt-node-config Hey, node 3.0 moved much of the configuration stuff to the ovirt-node-config module, but until now the whole configuration could only be done through the TUI or during auto-installation. ovirt-node-config is a small tool (or shall become one) which exposes all classes from ovirt.node.config and which can be used to: 1. Introspect the classes and see what they do 2. Run the classes to perform the configuration from the console I see two main use cases for this: 1. Test automation - This eases the testing of the functionalit ywhich does the actual configuration work. Basically we can write tests like: (Pseudo code) $ ovirt-node-config run Network.configure_disable_networking $ assert_no_files_like "/etc/sysconfig/network-scripts/ifcfg-*" or $ ovirt-node-config run SSH.configure_pw_auth true $ assert_file_contains /etc/ssh/sshd_config "PWAuth yes" 2. Reuse Other components can use this tool to perform high-level configuration on Node. The corresponding draft can be found here: http://gerrit.ovirt.org/#/c/24968/ The code is not yet fully functional. Thoughts suggestions and anything else is welcome :) - fabian _______________________________________________ node-devel mailing list node-devel at ovirt.org http://lists.ovirt.org/mailman/listinfo/node-devel From fabiand at redhat.com Wed Mar 5 09:31:01 2014 From: fabiand at redhat.com (Fabian Deutsch) Date: Wed, 05 Mar 2014 10:31:01 +0100 Subject: [node-devel] Docker in the land of Node (plugin and build-system) Message-ID: <1394011861.27444.5.camel@fdeutsch-laptop.local> Hey, Docker is somewhat a hype these days. And docker can also be found in the Node land. In two ways actually. First: Ryan added some Dockerfiles which you can use to build ovirt-node-iso within a Docker container. That is great. Because it separates the host OS from the to-be-build-OS. Ref: http://gerrit.ovirt.org/#/c/24679/ Second: I just added a (draft) plugin which adds Docker to an existing Node ISO and runs it in "host mode", that means Docker will be bound to a public port (4243 in out case) and users can use it from remote using: $ docker -H $NODEADDR:4243 info This has the benefit of having the solid nature of Node as a base and the flexibility of Docker on top. Ref: http://gerrit.ovirt.org/#/c/25370/ Both ways need testing, and the latter can not be easily tested yet, as systemd (aka Fedora image) is required. - fabian -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part URL: From mburns at redhat.com Thu Mar 6 03:03:58 2014 From: mburns at redhat.com (Mike Burns) Date: Wed, 05 Mar 2014 22:03:58 -0500 Subject: [node-devel] Docker in the land of Node (plugin and build-system) In-Reply-To: <1394011861.27444.5.camel@fdeutsch-laptop.local> References: <1394011861.27444.5.camel@fdeutsch-laptop.local> Message-ID: <5317E59E.10208@redhat.com> On 03/05/2014 04:31 AM, Fabian Deutsch wrote: > Hey, > > Docker is somewhat a hype these days. > > And docker can also be found in the Node land. In two ways actually. > > First: > Ryan added some Dockerfiles which you can use to build ovirt-node-iso > within a Docker container. That is great. Because it separates the host > OS from the to-be-build-OS. > Ref: http://gerrit.ovirt.org/#/c/24679/ Very nice. So does this removes livecd-tools from the build process? or does it run livecd-tools through Docker? > > Second: > I just added a (draft) plugin which adds Docker to an existing Node ISO > and runs it in "host mode", that means Docker will be bound to a public > port (4243 in out case) and users can use it from remote using: > > $ docker -H $NODEADDR:4243 info > > This has the benefit of having the solid nature of Node as a base and > the flexibility of Docker on top. > Ref: http://gerrit.ovirt.org/#/c/25370/ IIUC, this would allow containers to run locally on ovirt-node. Is there any management interface for this? Is this a roadmap item for engine to consume? Or is it to make Node an option for another container-based virtualization management tool? > > > Both ways need testing, and the latter can not be easily tested yet, as > systemd (aka Fedora image) is required. > > - fabian > From fabiand at redhat.com Thu Mar 6 09:56:02 2014 From: fabiand at redhat.com (Fabian Deutsch) Date: Thu, 06 Mar 2014 10:56:02 +0100 Subject: [node-devel] Docker in the land of Node (plugin and build-system) In-Reply-To: <5317E59E.10208@redhat.com> References: <1394011861.27444.5.camel@fdeutsch-laptop.local> <5317E59E.10208@redhat.com> Message-ID: <1394099762.3560.11.camel@fdeutsch-laptop.local> Am Mittwoch, den 05.03.2014, 22:03 -0500 schrieb Mike Burns: > On 03/05/2014 04:31 AM, Fabian Deutsch wrote: > > Hey, > > > > Docker is somewhat a hype these days. > > > > And docker can also be found in the Node land. In two ways actually. > > > > First: > > Ryan added some Dockerfiles which you can use to build ovirt-node-iso > > within a Docker container. That is great. Because it separates the host > > OS from the to-be-build-OS. > > Ref: http://gerrit.ovirt.org/#/c/24679/ > > Very nice. So does this removes livecd-tools from the build process? > or does it run livecd-tools through Docker? No, livecd-tools are still used, they are run within Docker. > > Second: > > I just added a (draft) plugin which adds Docker to an existing Node ISO > > and runs it in "host mode", that means Docker will be bound to a public > > port (4243 in out case) and users can use it from remote using: > > > > $ docker -H $NODEADDR:4243 info > > > > This has the benefit of having the solid nature of Node as a base and > > the flexibility of Docker on top. > > Ref: http://gerrit.ovirt.org/#/c/25370/ > > IIUC, this would allow containers to run locally on ovirt-node. Is > there any management interface for this? This should as it uses default Docker features (HTTP Rest API). It should be possible to use it with e.g. shipyard (http://shipyard-project.com/). It also seems that OpenStack is using the HTTP Rest API of Docker (https://wiki.openstack.org/wiki/Docker). Tho I must say that I have not tested both yet. > Is this a roadmap item for > engine to consume? Or is it to make Node an option for another > container-based virtualization management tool? No, Engine is not targeting Docker afaik. And yes, it was more about to show that Node can also host other container based virtualization solutions. This was just a small excursion while I played with docker, because I am still looking for a lightweight hypervisor which is easy to use in a home lab. So something like a libvirt-standalone or (now) docker plugin, or maybe it's lxc ... - fabian > > > > > > Both ways need testing, and the latter can not be easily tested yet, as > > systemd (aka Fedora image) is required. > > > > > > - fabian > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part URL: From fabiand at redhat.com Fri Mar 14 16:06:56 2014 From: fabiand at redhat.com (Fabian Deutsch) Date: Fri, 14 Mar 2014 17:06:56 +0100 Subject: [node-devel] [ANN] oVirt Node ISO for oVirt 3.4 RC 2 Message-ID: <1394813216.5037.7.camel@fdeutsch-laptop.local> Hey, let me announce a respun oVirt Node for oVirt 3.4 RC 2. After some time this is finally available from where it belongs: http://resources.ovirt.org/releases/3.4.0_pre/iso/ovirt-node-iso-3.0.4-1.0.201401291204.vdsm34rc2.el6.iso There are also older releases of oVirt Node, in case that the latest version has unknown regressions. http://resources.ovirt.org/releases/3.4.0_pre/iso/ Please let us known about issues you run into. You can also let us know when Node "Just Works (TM)". Greetings fabian -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part URL: From fabiand at redhat.com Tue Mar 18 15:53:58 2014 From: fabiand at redhat.com (Fabian Deutsch) Date: Tue, 18 Mar 2014 16:53:58 +0100 Subject: [node-devel] oVirt Node Weekly Meeting Minutes -- 2014-03-18 Message-ID: <1395158038.6802.16.camel@fdeutsch-laptop.local> Minutes: http://ovirt.org/meetings/ovirt/2014/ovirt.2014-03-18-15.13.html Minutes (text): http://ovirt.org/meetings/ovirt/2014/ovirt.2014-03-18-15.13.txt Log: http://ovirt.org/meetings/ovirt/2014/ovirt.2014-03-18-15.13.log.html ================================= #ovirt: oVirt Node Weekly Meeting ================================= Meeting started by fabiand at 15:13:29 UTC. The full logs are available at http://ovirt.org/meetings/ovirt/2014/ovirt.2014-03-18-15.13.log.html . Meeting summary --------------- * Agenda (fabiand, 15:13:40) * Release planning (fabiand, 15:13:55) * Fedora 20 status (fabiand, 15:14:05) * Jenkins (fabiand, 15:14:07) * Other items (fabiand, 15:14:12) * Release planning (fabiand, 15:14:28) * Slowly prepare 2.0.5 with stabilizing patches (fabiand, 15:15:18) * Re-Add Fedora based Node's with 3.0.5 .. (fabiand, 15:15:52) * Fedora 20 status (fabiand, 15:17:36) * LINK: http://plain.resources.ovirt.org/releases/3.4.0-rc2/rpm/Fedora/20/x86_64/ (fabiand, 15:28:56) * Jenkins (fabiand, 15:39:01) * ACTION: fabiand to ask infra to at least enable selinux in permissive mode .. (fabiand, 15:44:05) * Other items (fabiand, 15:44:16) * glsuerfs will work with some iptables updates and might get even a plugin (fabiand, 15:45:40) * glusterfs basics have been tested by rbarry (fabiand, 15:46:09) * jboggs started to work on hosted engine support (fabiand, 15:48:28) Meeting ended at 15:52:21 UTC. Action Items ------------ * fabiand to ask infra to at least enable selinux in permissive mode .. Action Items, by person ----------------------- * fabiand * fabiand to ask infra to at least enable selinux in permissive mode .. * **UNASSIGNED** * (none) People Present (lines said) --------------------------- * fabiand (86) * rbarry (21) * jboggs (11) * ovirtbot (3) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part URL: From fdeutsch at redhat.com Mon Mar 24 16:09:48 2014 From: fdeutsch at redhat.com (Fabian Deutsch) Date: Mon, 24 Mar 2014 17:09:48 +0100 Subject: [node-devel] Storage Stuff, Installation Module and Anaconda Message-ID: <1395677388.3873.11.camel@fdeutsch-laptop.local> Hey, this has been discussed a couple of times over the last months (already! ): To use some parts of anaconda (python-blivet) in our storage and installer code-base. While investigating this a bit further on last Friday I started to wonder if we can't even use more parts of anaconda, basically ending in a thought where I wondered how much it would take to make anaconda capable of doing the Node installation. The biggest issue with anaconda right now is that the "modus operandi" is around files. Our method on the other hand is around installing images. If we can teach anaconda to install images then I could imagine the following workflow: 1. Our installer create a ks 2. anaconda does the installation based on ks So I would not actually expose anacondas UI. But - We could possibly also leverage other parts of anaconda, e.g. basic network configuration stuff, and maybe even more. I have not yet investigate how much more dependencies we'd be pulling in. It's not that I want to go down this way right now. It just came to my selection of possibilities. Greetings so far - fabian From jmoskovc at redhat.com Mon Mar 24 19:05:01 2014 From: jmoskovc at redhat.com (Jiri Moskovcak) Date: Mon, 24 Mar 2014 20:05:01 +0100 Subject: [node-devel] Storage Stuff, Installation Module and Anaconda In-Reply-To: <1395677388.3873.11.camel@fdeutsch-laptop.local> References: <1395677388.3873.11.camel@fdeutsch-laptop.local> Message-ID: <533081DD.5030602@redhat.com> On 03/24/2014 05:09 PM, Fabian Deutsch wrote: > Hey, > > this has been discussed a couple of times over the last months (already! > ): To use some parts of anaconda (python-blivet) in our storage and > installer code-base. > > While investigating this a bit further on last Friday I started to > wonder if we can't even use more parts of anaconda, basically ending in > a thought where I wondered how much it would take to make anaconda > capable of doing the Node installation. > > > The biggest issue with anaconda right now is that the "modus operandi" > is around files. Our method on the other hand is around installing > images. > > If we can teach anaconda to install images then I could imagine the > following workflow: > > 1. Our installer create a ks > 2. anaconda does the installation based on ks > > So I would not actually expose anacondas UI. > But - We could possibly also leverage other parts of anaconda, e.g. > basic network configuration stuff, and maybe even more. > > I have not yet investigate how much more dependencies we'd be pulling > in. > > It's not that I want to go down this way right now. It just came to my > selection of possibilities. > > Greetings so far > - fabian > Hi Fabian, it's quite an interesting idea and it actually might be easier than you think. You should be able to create an rpm package from the image and just create anaconda install disc with that rpm on it and let anaconda do it's job without having to change it's backend to understand images. --Jirka > _______________________________________________ > node-devel mailing list > node-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/node-devel > From jmoskovc at redhat.com Mon Mar 24 19:20:14 2014 From: jmoskovc at redhat.com (Jiri Moskovcak) Date: Mon, 24 Mar 2014 20:20:14 +0100 Subject: [node-devel] Storage Stuff, Installation Module and Anaconda In-Reply-To: <533081DD.5030602@redhat.com> References: <1395677388.3873.11.camel@fdeutsch-laptop.local> <533081DD.5030602@redhat.com> Message-ID: <5330856E.8050004@redhat.com> On 03/24/2014 08:05 PM, Jiri Moskovcak wrote: > On 03/24/2014 05:09 PM, Fabian Deutsch wrote: >> Hey, >> >> this has been discussed a couple of times over the last months (already! >> ): To use some parts of anaconda (python-blivet) in our storage and >> installer code-base. >> >> While investigating this a bit further on last Friday I started to >> wonder if we can't even use more parts of anaconda, basically ending in >> a thought where I wondered how much it would take to make anaconda >> capable of doing the Node installation. >> >> >> The biggest issue with anaconda right now is that the "modus operandi" >> is around files. Our method on the other hand is around installing >> images. >> >> If we can teach anaconda to install images then I could imagine the >> following workflow: >> >> 1. Our installer create a ks >> 2. anaconda does the installation based on ks >> >> So I would not actually expose anacondas UI. >> But - We could possibly also leverage other parts of anaconda, e.g. >> basic network configuration stuff, and maybe even more. >> >> I have not yet investigate how much more dependencies we'd be pulling >> in. >> >> It's not that I want to go down this way right now. It just came to my >> selection of possibilities. >> >> Greetings so far >> - fabian >> > > Hi Fabian, > it's quite an interesting idea and it actually might be easier than you > think. You should be able to create an rpm package from the image and > just create anaconda install disc with that rpm on it and let anaconda > do it's job without having to change it's backend to understand images. > > --Jirka - and actually when you're installing from livecd you're installing an image, so the logic is already there.. --Jirka > >> _______________________________________________ >> node-devel mailing list >> node-devel at ovirt.org >> http://lists.ovirt.org/mailman/listinfo/node-devel >> > > _______________________________________________ > node-devel mailing list > node-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/node-devel From fdeutsch at redhat.com Mon Mar 24 20:34:52 2014 From: fdeutsch at redhat.com (Fabian Deutsch) Date: Mon, 24 Mar 2014 21:34:52 +0100 Subject: [node-devel] Storage Stuff, Installation Module and Anaconda In-Reply-To: <5330856E.8050004@redhat.com> References: <1395677388.3873.11.camel@fdeutsch-laptop.local> <533081DD.5030602@redhat.com> <5330856E.8050004@redhat.com> Message-ID: <1395693292.7820.15.camel@fdeutsch-laptop.local> Am Montag, den 24.03.2014, 20:20 +0100 schrieb Jiri Moskovcak: > On 03/24/2014 08:05 PM, Jiri Moskovcak wrote: > > On 03/24/2014 05:09 PM, Fabian Deutsch wrote: > >> Hey, > >> > >> this has been discussed a couple of times over the last months (already! > >> ): To use some parts of anaconda (python-blivet) in our storage and > >> installer code-base. > >> > >> While investigating this a bit further on last Friday I started to > >> wonder if we can't even use more parts of anaconda, basically ending in > >> a thought where I wondered how much it would take to make anaconda > >> capable of doing the Node installation. > >> > >> > >> The biggest issue with anaconda right now is that the "modus operandi" > >> is around files. Our method on the other hand is around installing > >> images. > >> > >> If we can teach anaconda to install images then I could imagine the > >> following workflow: > >> > >> 1. Our installer create a ks > >> 2. anaconda does the installation based on ks > >> > >> So I would not actually expose anacondas UI. > >> But - We could possibly also leverage other parts of anaconda, e.g. > >> basic network configuration stuff, and maybe even more. > >> > >> I have not yet investigate how much more dependencies we'd be pulling > >> in. > >> > >> It's not that I want to go down this way right now. It just came to my > >> selection of possibilities. > >> > >> Greetings so far > >> - fabian > >> > > > > Hi Fabian, > > it's quite an interesting idea and it actually might be easier than you > > think. You should be able to create an rpm package from the image and > > just create anaconda install disc with that rpm on it and let anaconda > > do it's job without having to change it's backend to understand images. > > > > --Jirka > > - and actually when you're installing from livecd you're installing an > image, so the logic is already there.. Hey Jirka, thanks for your input! As far as I understand the LiveCd Payload it looks like the filesystem tree is copied, and not the image itself. Greetings fabian From fdeutsch at redhat.com Tue Mar 25 06:52:50 2014 From: fdeutsch at redhat.com (Fabian Deutsch) Date: Tue, 25 Mar 2014 07:52:50 +0100 Subject: [node-devel] Storage Stuff, Installation Module and Anaconda In-Reply-To: <533081DD.5030602@redhat.com> References: <1395677388.3873.11.camel@fdeutsch-laptop.local> <533081DD.5030602@redhat.com> Message-ID: <1395730370.3014.1.camel@fdeutsch-laptop.local> Am Montag, den 24.03.2014, 20:05 +0100 schrieb Jiri Moskovcak: > On 03/24/2014 05:09 PM, Fabian Deutsch wrote: > > Hey, > > > > this has been discussed a couple of times over the last months (already! > > ): To use some parts of anaconda (python-blivet) in our storage and > > installer code-base. > > > > While investigating this a bit further on last Friday I started to > > wonder if we can't even use more parts of anaconda, basically ending in > > a thought where I wondered how much it would take to make anaconda > > capable of doing the Node installation. > > > > > > The biggest issue with anaconda right now is that the "modus operandi" > > is around files. Our method on the other hand is around installing > > images. > > > > If we can teach anaconda to install images then I could imagine the > > following workflow: > > > > 1. Our installer create a ks > > 2. anaconda does the installation based on ks > > > > So I would not actually expose anacondas UI. > > But - We could possibly also leverage other parts of anaconda, e.g. > > basic network configuration stuff, and maybe even more. > > > > I have not yet investigate how much more dependencies we'd be pulling > > in. > > > > It's not that I want to go down this way right now. It just came to my > > selection of possibilities. > > > > Greetings so far > > - fabian > > > > Hi Fabian, > it's quite an interesting idea and it actually might be easier than you > think. You should be able to create an rpm package from the image and > just create anaconda install disc with that rpm on it and let anaconda > do it's job without having to change it's backend to understand images. Hey, IIUYC I am not sure that this would solve Node's installation problem. Because Node is an image (ISO) which is copied onto a Logical Volume (LV). A seperate boot partition then points to the LV at boot time. And this part - writing an image to a LV during installation - is what might not be possible right now. But maybe it can be added. Greetings fabian From pengchunhong at gmail.com Wed Mar 26 06:51:05 2014 From: pengchunhong at gmail.com (=?GB2312?B?xe20urrp?=) Date: Wed, 26 Mar 2014 14:51:05 +0800 Subject: [node-devel] how to debug ovrit frontent and backent Message-ID: hello,everybody.when I development with ovirt,I have meet some obstacles because of without the debug environment. So I really want to know how to config it. Thank you for help! -------------- next part -------------- An HTML attachment was scrubbed... URL: From fabiand at redhat.com Wed Mar 26 07:48:26 2014 From: fabiand at redhat.com (Fabian Deutsch) Date: Wed, 26 Mar 2014 08:48:26 +0100 Subject: [node-devel] how to debug ovrit frontent and backent In-Reply-To: References: Message-ID: <1395820106.2852.5.camel@fdeutsch-laptop.local> Am Mittwoch, den 26.03.2014, 14:51 +0800 schrieb ???: > hello,everybody.when I development with ovirt,I have meet some > obstacles because of without the debug environment. So I really want > to know how to config it. Thank you for help! Hi, could you explain a bit more in what areas of oVirt Node you want to develop, this will help to see how you can better debug your stuff. If you are developing something in the TUI you can use the "dry mode". In the ovirt-node directory, just run: PYTHONPATH=src/ scripts/ovirt-node-setup --dry --defaults /tmp/cfg_dummy --debug That way you can experiment with the TUI, without actually installing it. Additionally you can find log files in /var/log/ovirt.log /var/log/ovirt-node.log /var/log/ovirt-node.debug.log (when the setup was started with --debug) Greetings fabian -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part URL: From fabiand at redhat.com Fri Mar 28 11:37:05 2014 From: fabiand at redhat.com (Fabian Deutsch) Date: Fri, 28 Mar 2014 12:37:05 +0100 Subject: [node-devel] Versioning of oVirt Node Message-ID: <1396006625.2943.43.camel@fdeutsch-laptop.local> Hey, currently [0] - or since the split into base image and layered image - the versioning of Node hasn't been really resolved. I'd like to change the versioning of Node with the goal to make it directly obvious what oVirt version a Node is targeting. Before I continue let me clarify that this is primarily about the versioning of the Node ISO. The versioning of the wrapper-rpm can possibly follow the naming of the ISO, as long as we make yum happy. Also this is not about the ovirt-node (pkg) versioning, only about the iso image. Currently the ISO naming is as follows: ovirt-node-iso--...\ vdsm..iso (i.e. ovirt-node-iso-3.0.4-1.0.201401291204.vdsm34.el6.iso) The main pain point of this is IMO the vdsm34 snippet - because it breaks the whol envr and is currently just added after the edit-node pass. I'm proposing the following scheme: ovirt-node-iso--...iso (i.e. ovirt-node-iso-3.4.0-20140328.1.el6.iso) This should make it obvious to the user what ISO to use. Now about the rpm scheme. We can not change this as long as the Engine logic has not been updated to use the proposed metadata file: https://bugzilla.redhat.com/show_bug.cgi?id=1081969 (Node) https://bugzilla.redhat.com/show_bug.cgi?id=1081970 Once these two bugs have been addressed we can also change the rpm naming. In general I'd like to follow the iso naming, thus: ovirt-node-iso--...rpm (i.e. ovirt-node-iso-3.4.0-20140328.1.el6.rpm) A couple of examples: # Newer build, same day $ rpmdev-vercmp 0:3.4.0-20140328.1 0:3.4.0-20140328.2 0:3.4.0-20140328.1 < 0:3.4.0-20140328.2 # Same build $ rpmdev-vercmp 0:3.4.0-20140328.1 0:3.4.0-20140328.1 0:3.4.0-20140328.1 == 0:3.4.0-20140328.1 # Older and newer build, same day $ rpmdev-vercmp 0:3.4.0-20140328.1 0:3.4.0-20140328.0 0:3.4.0-20140328.1 > 0:3.4.0-20140328.0 # Same ver, one year later $ rpmdev-vercmp 0:3.4.0-20140328.1 0:3.4.0-20150328.1 0:3.4.0-20140328.1 < 0:3.4.0-20150328.1 # New ver $ rpmdev-vercmp 0:3.4.0-20140328.1 0:3.5.0-20140328.1 0:3.4.0-20140328.1 < 0:3.5.0-20140328.1 # Older ver, newer build date $ rpmdev-vercmp 0:3.4.0-20140328.1 0:3.3.0-20150328.1 0:3.4.0-20140328.1 > 0:3.3.0-20150328.1 (Would not get installed by yum automatically) In general the names of the iso and rpm should not be relevant for Engine to decide about updates. The metadata file of the rpm will be used for that. Finally, are there objections to of changing the ISO versioning scheme now? Or does someone see problems with it? Greetings fabian --- [0] http://plain.resources.ovirt.org/releases/3.4/iso/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part URL: From fabiand at redhat.com Fri Mar 28 11:39:38 2014 From: fabiand at redhat.com (Fabian Deutsch) Date: Fri, 28 Mar 2014 12:39:38 +0100 Subject: [node-devel] Versioning of oVirt Node In-Reply-To: <1396006625.2943.43.camel@fdeutsch-laptop.local> References: <1396006625.2943.43.camel@fdeutsch-laptop.local> Message-ID: <1396006778.2943.45.camel@fdeutsch-laptop.local> Am Freitag, den 28.03.2014, 12:37 +0100 schrieb Fabian Deutsch: > Before I continue let me clarify that this is primarily about the > versioning of the Node ISO. > The versioning of the wrapper-rpm can possibly follow the naming of > the > ISO, as long as we make yum happy. > Also this is not about the ovirt-node (pkg) versioning, only about the > iso image. I am also suggesting that the base image should continue to use the ovirt-node (pkg) versions, thus: ovirt-node-base-iso--...iso (i.e. ovirt-node-base-iso-3.0.4-20140328.1.el6.iso) The base iso is used to derive the Node-for-Engine iso. Greetings fabian -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part URL: From dfediuck at redhat.com Sun Mar 30 06:24:36 2014 From: dfediuck at redhat.com (Doron Fediuck) Date: Sun, 30 Mar 2014 02:24:36 -0400 (EDT) Subject: [node-devel] Versioning of oVirt Node In-Reply-To: <1396006778.2943.45.camel@fdeutsch-laptop.local> References: <1396006625.2943.43.camel@fdeutsch-laptop.local> <1396006778.2943.45.camel@fdeutsch-laptop.local> Message-ID: <375911745.4130325.1396160676481.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Fabian Deutsch" > To: arch at ovirt.org > Cc: "Douglas Landgraf" , "node-devel" > Sent: Friday, March 28, 2014 2:39:38 PM > Subject: Re: [node-devel] Versioning of oVirt Node > > Am Freitag, den 28.03.2014, 12:37 +0100 schrieb Fabian Deutsch: > > Before I continue let me clarify that this is primarily about the > > versioning of the Node ISO. > > The versioning of the wrapper-rpm can possibly follow the naming of > > the > > ISO, as long as we make yum happy. > > Also this is not about the ovirt-node (pkg) versioning, only about the > > iso image. > > I am also suggesting that the base image should continue to use the > ovirt-node (pkg) versions, thus: > > > ovirt-node-base-iso--...iso > > (i.e. ovirt-node-base-iso-3.0.4-20140328.1.el6.iso) > > The base iso is used to derive the Node-for-Engine iso. > > Greetings > fabian > Sounds reasonable to me. From bazulay at redhat.com Sun Mar 30 08:46:11 2014 From: bazulay at redhat.com (Barak Azulay) Date: Sun, 30 Mar 2014 04:46:11 -0400 (EDT) Subject: [node-devel] Versioning of oVirt Node In-Reply-To: <1396006625.2943.43.camel@fdeutsch-laptop.local> References: <1396006625.2943.43.camel@fdeutsch-laptop.local> Message-ID: <859671594.4143833.1396169171061.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Fabian Deutsch" > To: arch at ovirt.org, "node-devel" > Cc: "Douglas Landgraf" > Sent: Friday, March 28, 2014 2:37:05 PM > Subject: [node-devel] Versioning of oVirt Node > > Hey, > > currently [0] - or since the split into base image and layered image - > the versioning of Node hasn't been really resolved. > > I'd like to change the versioning of Node with the goal to make it > directly obvious what oVirt version a Node is targeting. > > Before I continue let me clarify that this is primarily about the > versioning of the Node ISO. > The versioning of the wrapper-rpm can possibly follow the naming of the > ISO, as long as we make yum happy. > Also this is not about the ovirt-node (pkg) versioning, only about the > iso image. > > Currently the ISO naming is as follows: > > ovirt-node-iso--...\ > vdsm..iso > > (i.e. ovirt-node-iso-3.0.4-1.0.201401291204.vdsm34.el6.iso) > > The main pain point of this is IMO the vdsm34 snippet - because it > breaks the whol envr and is currently just added after the edit-node > pass. > > I'm proposing the following scheme: > > ovirt-node-iso--...iso > > (i.e. ovirt-node-iso-3.4.0-20140328.1.el6.iso) > > This should make it obvious to the user what ISO to use. > > > Now about the rpm scheme. We can not change this as long as the Engine > logic has not been updated to use the proposed metadata file: > https://bugzilla.redhat.com/show_bug.cgi?id=1081969 (Node) > https://bugzilla.redhat.com/show_bug.cgi?id=1081970 > > Once these two bugs have been addressed we can also change the rpm > naming. > In general I'd like to follow the iso naming, thus: > > ovirt-node-iso--...rpm > > (i.e. ovirt-node-iso-3.4.0-20140328.1.el6.rpm) > > A couple of examples: > # Newer build, same day > $ rpmdev-vercmp 0:3.4.0-20140328.1 0:3.4.0-20140328.2 > 0:3.4.0-20140328.1 < 0:3.4.0-20140328.2 > > # Same build > $ rpmdev-vercmp 0:3.4.0-20140328.1 0:3.4.0-20140328.1 > 0:3.4.0-20140328.1 == 0:3.4.0-20140328.1 > > # Older and newer build, same day > $ rpmdev-vercmp 0:3.4.0-20140328.1 0:3.4.0-20140328.0 > 0:3.4.0-20140328.1 > 0:3.4.0-20140328.0 > > # Same ver, one year later > $ rpmdev-vercmp 0:3.4.0-20140328.1 0:3.4.0-20150328.1 > 0:3.4.0-20140328.1 < 0:3.4.0-20150328.1 > > # New ver > $ rpmdev-vercmp 0:3.4.0-20140328.1 0:3.5.0-20140328.1 > 0:3.4.0-20140328.1 < 0:3.5.0-20140328.1 > > # Older ver, newer build date > $ rpmdev-vercmp 0:3.4.0-20140328.1 0:3.3.0-20150328.1 > 0:3.4.0-20140328.1 > 0:3.3.0-20150328.1 > (Would not get installed by yum automatically) > > In general the names of the iso and rpm should not be relevant for > Engine to decide about updates. The metadata file of the rpm will be > used for that. > > Finally, are there objections to of changing the ISO versioning scheme > now? Or does someone see problems with it? I assume that this new schema is handling also the frist upgrade from the old name schema. Barak > > Greetings > fabian > > --- > [0] http://plain.resources.ovirt.org/releases/3.4/iso/ > > _______________________________________________ > node-devel mailing list > node-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/node-devel > From alonbl at redhat.com Sun Mar 30 08:57:09 2014 From: alonbl at redhat.com (Alon Bar-Lev) Date: Sun, 30 Mar 2014 04:57:09 -0400 (EDT) Subject: [node-devel] Versioning of oVirt Node In-Reply-To: <1396006625.2943.43.camel@fdeutsch-laptop.local> References: <1396006625.2943.43.camel@fdeutsch-laptop.local> Message-ID: <1611733432.4095464.1396169829479.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Fabian Deutsch" > To: arch at ovirt.org, "node-devel" > Cc: "Douglas Landgraf" > Sent: Friday, March 28, 2014 2:37:05 PM > Subject: [node-devel] Versioning of oVirt Node > > Hey, > > currently [0] - or since the split into base image and layered image - > the versioning of Node hasn't been really resolved. > > I'd like to change the versioning of Node with the goal to make it > directly obvious what oVirt version a Node is targeting. > > Before I continue let me clarify that this is primarily about the > versioning of the Node ISO. > The versioning of the wrapper-rpm can possibly follow the naming of the > ISO, as long as we make yum happy. > Also this is not about the ovirt-node (pkg) versioning, only about the > iso image. > > Currently the ISO naming is as follows: > > ovirt-node-iso--...\ > vdsm..iso > > (i.e. ovirt-node-iso-3.0.4-1.0.201401291204.vdsm34.el6.iso) > > The main pain point of this is IMO the vdsm34 snippet - because it > breaks the whol envr and is currently just added after the edit-node > pass. > > I'm proposing the following scheme: > > ovirt-node-iso--...iso > > (i.e. ovirt-node-iso-3.4.0-20140328.1.el6.iso) > > This should make it obvious to the user what ISO to use. > > > Now about the rpm scheme. We can not change this as long as the Engine > logic has not been updated to use the proposed metadata file: > https://bugzilla.redhat.com/show_bug.cgi?id=1081969 (Node) > https://bugzilla.redhat.com/show_bug.cgi?id=1081970 > > Once these two bugs have been addressed we can also change the rpm > naming. > In general I'd like to follow the iso naming, thus: > > ovirt-node-iso--...rpm I think that we should have upstream version for ovirt node as any other upstream version we have. I also do not like dates embed within release as it will make our lives difficult when we have proper bug tracking system in place. I am unsure what 'iso' means... I think it should be removed or converted to subpackage. Should we also consider parallel versions of different distributions(?) (fc19, fc20). Pre-release: ovirt-node-iso-3.4.0-0.$(sequence).$(branch).$(date).dist.rpm Released: ovirt-node-iso-3.4.z-1.dist.rpm Please note that the downstream component is eliminated in upstream, what important in upstream is the source tarball.... ovirt-ndoe-iso-3.4.z.tar.gz Regards, Alon From bazulay at redhat.com Sun Mar 30 09:51:05 2014 From: bazulay at redhat.com (Barak Azulay) Date: Sun, 30 Mar 2014 05:51:05 -0400 (EDT) Subject: [node-devel] Versioning of oVirt Node In-Reply-To: <1611733432.4095464.1396169829479.JavaMail.zimbra@redhat.com> References: <1396006625.2943.43.camel@fdeutsch-laptop.local> <1611733432.4095464.1396169829479.JavaMail.zimbra@redhat.com> Message-ID: <1741846884.4148258.1396173065062.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Alon Bar-Lev" > To: "Fabian Deutsch" > Cc: arch at ovirt.org, "Douglas Landgraf" , "node-devel" > Sent: Sunday, March 30, 2014 11:57:09 AM > Subject: Re: [node-devel] Versioning of oVirt Node > > > > ----- Original Message ----- > > From: "Fabian Deutsch" > > To: arch at ovirt.org, "node-devel" > > Cc: "Douglas Landgraf" > > Sent: Friday, March 28, 2014 2:37:05 PM > > Subject: [node-devel] Versioning of oVirt Node > > > > Hey, > > > > currently [0] - or since the split into base image and layered image - > > the versioning of Node hasn't been really resolved. > > > > I'd like to change the versioning of Node with the goal to make it > > directly obvious what oVirt version a Node is targeting. > > > > Before I continue let me clarify that this is primarily about the > > versioning of the Node ISO. > > The versioning of the wrapper-rpm can possibly follow the naming of the > > ISO, as long as we make yum happy. > > Also this is not about the ovirt-node (pkg) versioning, only about the > > iso image. > > > > Currently the ISO naming is as follows: > > > > ovirt-node-iso--...\ > > vdsm..iso > > > > (i.e. ovirt-node-iso-3.0.4-1.0.201401291204.vdsm34.el6.iso) > > > > The main pain point of this is IMO the vdsm34 snippet - because it > > breaks the whol envr and is currently just added after the edit-node > > pass. > > > > I'm proposing the following scheme: > > > > ovirt-node-iso--...iso > > > > (i.e. ovirt-node-iso-3.4.0-20140328.1.el6.iso) > > > > This should make it obvious to the user what ISO to use. > > > > > > Now about the rpm scheme. We can not change this as long as the Engine > > logic has not been updated to use the proposed metadata file: > > https://bugzilla.redhat.com/show_bug.cgi?id=1081969 (Node) > > https://bugzilla.redhat.com/show_bug.cgi?id=1081970 > > > > Once these two bugs have been addressed we can also change the rpm > > naming. > > In general I'd like to follow the iso naming, thus: > > > > ovirt-node-iso--...rpm > > > I think that we should have upstream version for ovirt node as any other > upstream version we have. > > I also do not like dates embed within release as it will make our lives > difficult when we have proper bug tracking system in place. > > I am unsure what 'iso' means... I think it should be removed or converted to > subpackage. > > Should we also consider parallel versions of different distributions(?) > (fc19, fc20). Doesn't this miss the entire node purpose ? a user should not care what platform was used to build the node. > > Pre-release: > ovirt-node-iso-3.4.0-0.$(sequence).$(branch).$(date).dist.rpm > > Released: > ovirt-node-iso-3.4.z-1.dist.rpm > > Please note that the downstream component is eliminated in upstream, what > important in upstream is the source tarball.... > > ovirt-ndoe-iso-3.4.z.tar.gz > > Regards, > Alon > _______________________________________________ > Arch mailing list > Arch at ovirt.org > http://lists.ovirt.org/mailman/listinfo/arch > > > From alonbl at redhat.com Sun Mar 30 09:53:32 2014 From: alonbl at redhat.com (Alon Bar-Lev) Date: Sun, 30 Mar 2014 05:53:32 -0400 (EDT) Subject: [node-devel] Versioning of oVirt Node In-Reply-To: <1741846884.4148258.1396173065062.JavaMail.zimbra@redhat.com> References: <1396006625.2943.43.camel@fdeutsch-laptop.local> <1611733432.4095464.1396169829479.JavaMail.zimbra@redhat.com> <1741846884.4148258.1396173065062.JavaMail.zimbra@redhat.com> Message-ID: <1148507703.4096754.1396173212861.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Barak Azulay" > To: "Alon Bar-Lev" > Cc: "Fabian Deutsch" , arch at ovirt.org, "Douglas Landgraf" , "node-devel" > > Sent: Sunday, March 30, 2014 12:51:05 PM > Subject: Re: [node-devel] Versioning of oVirt Node > > > > ----- Original Message ----- > > From: "Alon Bar-Lev" > > To: "Fabian Deutsch" > > Cc: arch at ovirt.org, "Douglas Landgraf" , "node-devel" > > > > Sent: Sunday, March 30, 2014 11:57:09 AM > > Subject: Re: [node-devel] Versioning of oVirt Node > > > > > > > > ----- Original Message ----- > > > From: "Fabian Deutsch" > > > To: arch at ovirt.org, "node-devel" > > > Cc: "Douglas Landgraf" > > > Sent: Friday, March 28, 2014 2:37:05 PM > > > Subject: [node-devel] Versioning of oVirt Node > > > > > > Hey, > > > > > > currently [0] - or since the split into base image and layered image - > > > the versioning of Node hasn't been really resolved. > > > > > > I'd like to change the versioning of Node with the goal to make it > > > directly obvious what oVirt version a Node is targeting. > > > > > > Before I continue let me clarify that this is primarily about the > > > versioning of the Node ISO. > > > The versioning of the wrapper-rpm can possibly follow the naming of the > > > ISO, as long as we make yum happy. > > > Also this is not about the ovirt-node (pkg) versioning, only about the > > > iso image. > > > > > > Currently the ISO naming is as follows: > > > > > > ovirt-node-iso--...\ > > > vdsm..iso > > > > > > (i.e. ovirt-node-iso-3.0.4-1.0.201401291204.vdsm34.el6.iso) > > > > > > The main pain point of this is IMO the vdsm34 snippet - because it > > > breaks the whol envr and is currently just added after the edit-node > > > pass. > > > > > > I'm proposing the following scheme: > > > > > > ovirt-node-iso--...iso > > > > > > (i.e. ovirt-node-iso-3.4.0-20140328.1.el6.iso) > > > > > > This should make it obvious to the user what ISO to use. > > > > > > > > > Now about the rpm scheme. We can not change this as long as the Engine > > > logic has not been updated to use the proposed metadata file: > > > https://bugzilla.redhat.com/show_bug.cgi?id=1081969 (Node) > > > https://bugzilla.redhat.com/show_bug.cgi?id=1081970 > > > > > > Once these two bugs have been addressed we can also change the rpm > > > naming. > > > In general I'd like to follow the iso naming, thus: > > > > > > ovirt-node-iso--...rpm > > > > > > I think that we should have upstream version for ovirt node as any other > > upstream version we have. > > > > I also do not like dates embed within release as it will make our lives > > difficult when we have proper bug tracking system in place. > > > > I am unsure what 'iso' means... I think it should be removed or converted > > to > > subpackage. > > > > Should we also consider parallel versions of different distributions(?) > > (fc19, fc20). > > Doesn't this miss the entire node purpose ? a user should not care what > platform was used to build the node. If we keep in parallel different distributions per single version of ovirt, we should somehow mark it in the binary output. For example we have experimental fedora-21 image based on ovirt-node-iso-3.4.2, while release is based on fedora-19. > > > > > > > Pre-release: > > ovirt-node-iso-3.4.0-0.$(sequence).$(branch).$(date).dist.rpm > > > > Released: > > ovirt-node-iso-3.4.z-1.dist.rpm > > > > Please note that the downstream component is eliminated in upstream, what > > important in upstream is the source tarball.... > > > > ovirt-ndoe-iso-3.4.z.tar.gz > > > > Regards, > > Alon > > _______________________________________________ > > Arch mailing list > > Arch at ovirt.org > > http://lists.ovirt.org/mailman/listinfo/arch > > > > > > > From bazulay at redhat.com Sun Mar 30 12:45:56 2014 From: bazulay at redhat.com (Barak Azulay) Date: Sun, 30 Mar 2014 08:45:56 -0400 (EDT) Subject: [node-devel] Versioning of oVirt Node In-Reply-To: <1148507703.4096754.1396173212861.JavaMail.zimbra@redhat.com> References: <1396006625.2943.43.camel@fdeutsch-laptop.local> <1611733432.4095464.1396169829479.JavaMail.zimbra@redhat.com> <1741846884.4148258.1396173065062.JavaMail.zimbra@redhat.com> <1148507703.4096754.1396173212861.JavaMail.zimbra@redhat.com> Message-ID: <2029737926.4163582.1396183556835.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Alon Bar-Lev" > To: "Barak Azulay" > Cc: "Fabian Deutsch" , arch at ovirt.org, "Douglas Landgraf" , "node-devel" > > Sent: Sunday, March 30, 2014 12:53:32 PM > Subject: Re: [node-devel] Versioning of oVirt Node > > > > ----- Original Message ----- > > From: "Barak Azulay" > > To: "Alon Bar-Lev" > > Cc: "Fabian Deutsch" , arch at ovirt.org, "Douglas > > Landgraf" , "node-devel" > > > > Sent: Sunday, March 30, 2014 12:51:05 PM > > Subject: Re: [node-devel] Versioning of oVirt Node > > > > > > > > ----- Original Message ----- > > > From: "Alon Bar-Lev" > > > To: "Fabian Deutsch" > > > Cc: arch at ovirt.org, "Douglas Landgraf" , > > > "node-devel" > > > > > > Sent: Sunday, March 30, 2014 11:57:09 AM > > > Subject: Re: [node-devel] Versioning of oVirt Node > > > > > > > > > > > > ----- Original Message ----- > > > > From: "Fabian Deutsch" > > > > To: arch at ovirt.org, "node-devel" > > > > Cc: "Douglas Landgraf" > > > > Sent: Friday, March 28, 2014 2:37:05 PM > > > > Subject: [node-devel] Versioning of oVirt Node > > > > > > > > Hey, > > > > > > > > currently [0] - or since the split into base image and layered image - > > > > the versioning of Node hasn't been really resolved. > > > > > > > > I'd like to change the versioning of Node with the goal to make it > > > > directly obvious what oVirt version a Node is targeting. > > > > > > > > Before I continue let me clarify that this is primarily about the > > > > versioning of the Node ISO. > > > > The versioning of the wrapper-rpm can possibly follow the naming of the > > > > ISO, as long as we make yum happy. > > > > Also this is not about the ovirt-node (pkg) versioning, only about the > > > > iso image. > > > > > > > > Currently the ISO naming is as follows: > > > > > > > > ovirt-node-iso--...\ > > > > vdsm..iso > > > > > > > > (i.e. ovirt-node-iso-3.0.4-1.0.201401291204.vdsm34.el6.iso) > > > > > > > > The main pain point of this is IMO the vdsm34 snippet - because it > > > > breaks the whol envr and is currently just added after the edit-node > > > > pass. > > > > > > > > I'm proposing the following scheme: > > > > > > > > ovirt-node-iso--...iso > > > > > > > > (i.e. ovirt-node-iso-3.4.0-20140328.1.el6.iso) > > > > > > > > This should make it obvious to the user what ISO to use. > > > > > > > > > > > > Now about the rpm scheme. We can not change this as long as the Engine > > > > logic has not been updated to use the proposed metadata file: > > > > https://bugzilla.redhat.com/show_bug.cgi?id=1081969 (Node) > > > > https://bugzilla.redhat.com/show_bug.cgi?id=1081970 > > > > > > > > Once these two bugs have been addressed we can also change the rpm > > > > naming. > > > > In general I'd like to follow the iso naming, thus: > > > > > > > > ovirt-node-iso--...rpm > > > > > > > > > I think that we should have upstream version for ovirt node as any other > > > upstream version we have. > > > > > > I also do not like dates embed within release as it will make our lives > > > difficult when we have proper bug tracking system in place. > > > > > > I am unsure what 'iso' means... I think it should be removed or converted > > > to > > > subpackage. > > > > > > Should we also consider parallel versions of different distributions(?) > > > (fc19, fc20). > > > > Doesn't this miss the entire node purpose ? a user should not care what > > platform was used to build the node. > > If we keep in parallel different distributions per single version of ovirt, > we should somehow mark it in the binary output. > > For example we have experimental fedora-21 image based on > ovirt-node-iso-3.4.2, while release is based on fedora-19. The purpose of ovirt-node is to be distribution agnostic (see esx server). If we have experimental image than it should be marked as such - not that it is based on f-21. The developers should know exactly what distro/version it was built from, I don't think that users care. Barak > > > > > > > > > > > > > Pre-release: > > > ovirt-node-iso-3.4.0-0.$(sequence).$(branch).$(date).dist.rpm > > > > > > Released: > > > ovirt-node-iso-3.4.z-1.dist.rpm > > > > > > Please note that the downstream component is eliminated in upstream, what > > > important in upstream is the source tarball.... > > > > > > ovirt-ndoe-iso-3.4.z.tar.gz > > > > > > Regards, > > > Alon > > > _______________________________________________ > > > Arch mailing list > > > Arch at ovirt.org > > > http://lists.ovirt.org/mailman/listinfo/arch > > > > > > > > > > > > From alonbl at redhat.com Sun Mar 30 12:49:13 2014 From: alonbl at redhat.com (Alon Bar-Lev) Date: Sun, 30 Mar 2014 08:49:13 -0400 (EDT) Subject: [node-devel] Versioning of oVirt Node In-Reply-To: <2029737926.4163582.1396183556835.JavaMail.zimbra@redhat.com> References: <1396006625.2943.43.camel@fdeutsch-laptop.local> <1611733432.4095464.1396169829479.JavaMail.zimbra@redhat.com> <1741846884.4148258.1396173065062.JavaMail.zimbra@redhat.com> <1148507703.4096754.1396173212861.JavaMail.zimbra@redhat.com> <2029737926.4163582.1396183556835.JavaMail.zimbra@redhat.com> Message-ID: <1251786515.4102123.1396183753291.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Barak Azulay" > To: "Alon Bar-Lev" > Cc: "Fabian Deutsch" , arch at ovirt.org, "Douglas Landgraf" , "node-devel" > > Sent: Sunday, March 30, 2014 3:45:56 PM > Subject: Re: [node-devel] Versioning of oVirt Node > > > > ----- Original Message ----- > > From: "Alon Bar-Lev" > > To: "Barak Azulay" > > Cc: "Fabian Deutsch" , arch at ovirt.org, "Douglas > > Landgraf" , "node-devel" > > > > Sent: Sunday, March 30, 2014 12:53:32 PM > > Subject: Re: [node-devel] Versioning of oVirt Node > > > > > > > > ----- Original Message ----- > > > From: "Barak Azulay" > > > To: "Alon Bar-Lev" > > > Cc: "Fabian Deutsch" , arch at ovirt.org, "Douglas > > > Landgraf" , "node-devel" > > > > > > Sent: Sunday, March 30, 2014 12:51:05 PM > > > Subject: Re: [node-devel] Versioning of oVirt Node > > > > > > > > > > > > ----- Original Message ----- > > > > From: "Alon Bar-Lev" > > > > To: "Fabian Deutsch" > > > > Cc: arch at ovirt.org, "Douglas Landgraf" , > > > > "node-devel" > > > > > > > > Sent: Sunday, March 30, 2014 11:57:09 AM > > > > Subject: Re: [node-devel] Versioning of oVirt Node > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > From: "Fabian Deutsch" > > > > > To: arch at ovirt.org, "node-devel" > > > > > Cc: "Douglas Landgraf" > > > > > Sent: Friday, March 28, 2014 2:37:05 PM > > > > > Subject: [node-devel] Versioning of oVirt Node > > > > > > > > > > Hey, > > > > > > > > > > currently [0] - or since the split into base image and layered image > > > > > - > > > > > the versioning of Node hasn't been really resolved. > > > > > > > > > > I'd like to change the versioning of Node with the goal to make it > > > > > directly obvious what oVirt version a Node is targeting. > > > > > > > > > > Before I continue let me clarify that this is primarily about the > > > > > versioning of the Node ISO. > > > > > The versioning of the wrapper-rpm can possibly follow the naming of > > > > > the > > > > > ISO, as long as we make yum happy. > > > > > Also this is not about the ovirt-node (pkg) versioning, only about > > > > > the > > > > > iso image. > > > > > > > > > > Currently the ISO naming is as follows: > > > > > > > > > > ovirt-node-iso--...\ > > > > > vdsm..iso > > > > > > > > > > (i.e. ovirt-node-iso-3.0.4-1.0.201401291204.vdsm34.el6.iso) > > > > > > > > > > The main pain point of this is IMO the vdsm34 snippet - because it > > > > > breaks the whol envr and is currently just added after the edit-node > > > > > pass. > > > > > > > > > > I'm proposing the following scheme: > > > > > > > > > > ovirt-node-iso--...iso > > > > > > > > > > (i.e. ovirt-node-iso-3.4.0-20140328.1.el6.iso) > > > > > > > > > > This should make it obvious to the user what ISO to use. > > > > > > > > > > > > > > > Now about the rpm scheme. We can not change this as long as the > > > > > Engine > > > > > logic has not been updated to use the proposed metadata file: > > > > > https://bugzilla.redhat.com/show_bug.cgi?id=1081969 (Node) > > > > > https://bugzilla.redhat.com/show_bug.cgi?id=1081970 > > > > > > > > > > Once these two bugs have been addressed we can also change the rpm > > > > > naming. > > > > > In general I'd like to follow the iso naming, thus: > > > > > > > > > > ovirt-node-iso--...rpm > > > > > > > > > > > > I think that we should have upstream version for ovirt node as any > > > > other > > > > upstream version we have. > > > > > > > > I also do not like dates embed within release as it will make our lives > > > > difficult when we have proper bug tracking system in place. > > > > > > > > I am unsure what 'iso' means... I think it should be removed or > > > > converted > > > > to > > > > subpackage. > > > > > > > > Should we also consider parallel versions of different distributions(?) > > > > (fc19, fc20). > > > > > > Doesn't this miss the entire node purpose ? a user should not care what > > > platform was used to build the node. > > > > If we keep in parallel different distributions per single version of ovirt, > > we should somehow mark it in the binary output. > > > > For example we have experimental fedora-21 image based on > > ovirt-node-iso-3.4.2, while release is based on fedora-19. > > The purpose of ovirt-node is to be distribution agnostic (see esx server). > If we have experimental image than it should be marked as such - not that it > is based on f-21. > The developers should know exactly what distro/version it was built from, I > don't think that users care. I am unsure users will not care if we can offer options for multiple images that works with the same ovirt milestone. But this is not that important at this point. > > Barak > > > > > > > > > > > > > > > > > > > > > > Pre-release: > > > > ovirt-node-iso-3.4.0-0.$(sequence).$(branch).$(date).dist.rpm > > > > > > > > Released: > > > > ovirt-node-iso-3.4.z-1.dist.rpm > > > > > > > > Please note that the downstream component is eliminated in upstream, > > > > what > > > > important in upstream is the source tarball.... > > > > > > > > ovirt-ndoe-iso-3.4.z.tar.gz > > > > > > > > Regards, > > > > Alon > > > > _______________________________________________ > > > > Arch mailing list > > > > Arch at ovirt.org > > > > http://lists.ovirt.org/mailman/listinfo/arch > > > > > > > > > > > > > > > > > > From fabiand at redhat.com Mon Mar 31 06:39:55 2014 From: fabiand at redhat.com (Fabian Deutsch) Date: Mon, 31 Mar 2014 08:39:55 +0200 Subject: [node-devel] Versioning of oVirt Node In-Reply-To: <859671594.4143833.1396169171061.JavaMail.zimbra@redhat.com> References: <1396006625.2943.43.camel@fdeutsch-laptop.local> <859671594.4143833.1396169171061.JavaMail.zimbra@redhat.com> Message-ID: <1396247995.3043.4.camel@fdeutsch-laptop.local> Am Sonntag, den 30.03.2014, 04:46 -0400 schrieb Barak Azulay: > I assume that this new schema is handling also the frist upgrade from > the old name schema. Hey Barak, could you explain what the first upgrade to the old schema name was for you? - fabian -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part URL: From dfediuck at redhat.com Mon Mar 31 06:55:53 2014 From: dfediuck at redhat.com (Doron Fediuck) Date: Mon, 31 Mar 2014 02:55:53 -0400 (EDT) Subject: [node-devel] Versioning of oVirt Node In-Reply-To: <1251786515.4102123.1396183753291.JavaMail.zimbra@redhat.com> References: <1396006625.2943.43.camel@fdeutsch-laptop.local> <1611733432.4095464.1396169829479.JavaMail.zimbra@redhat.com> <1741846884.4148258.1396173065062.JavaMail.zimbra@redhat.com> <1148507703.4096754.1396173212861.JavaMail.zimbra@redhat.com> <2029737926.4163582.1396183556835.JavaMail.zimbra@redhat.com> <1251786515.4102123.1396183753291.JavaMail.zimbra@redhat.com> Message-ID: <1498154547.4321522.1396248953024.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Alon Bar-Lev" > To: "Barak Azulay" > Cc: arch at ovirt.org, "Douglas Landgraf" , "node-devel" > Sent: Sunday, March 30, 2014 3:49:13 PM > Subject: Re: [node-devel] Versioning of oVirt Node > > > > ----- Original Message ----- > > From: "Barak Azulay" > > To: "Alon Bar-Lev" > > Cc: "Fabian Deutsch" , arch at ovirt.org, "Douglas > > Landgraf" , "node-devel" > > > > Sent: Sunday, March 30, 2014 3:45:56 PM > > Subject: Re: [node-devel] Versioning of oVirt Node > > > > > > > > ----- Original Message ----- > > > From: "Alon Bar-Lev" > > > To: "Barak Azulay" > > > Cc: "Fabian Deutsch" , arch at ovirt.org, "Douglas > > > Landgraf" , "node-devel" > > > > > > Sent: Sunday, March 30, 2014 12:53:32 PM > > > Subject: Re: [node-devel] Versioning of oVirt Node > > > > > > > > > > > > ----- Original Message ----- > > > > From: "Barak Azulay" > > > > To: "Alon Bar-Lev" > > > > Cc: "Fabian Deutsch" , arch at ovirt.org, "Douglas > > > > Landgraf" , "node-devel" > > > > > > > > Sent: Sunday, March 30, 2014 12:51:05 PM > > > > Subject: Re: [node-devel] Versioning of oVirt Node > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > From: "Alon Bar-Lev" > > > > > To: "Fabian Deutsch" > > > > > Cc: arch at ovirt.org, "Douglas Landgraf" , > > > > > "node-devel" > > > > > > > > > > Sent: Sunday, March 30, 2014 11:57:09 AM > > > > > Subject: Re: [node-devel] Versioning of oVirt Node > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > From: "Fabian Deutsch" > > > > > > To: arch at ovirt.org, "node-devel" > > > > > > Cc: "Douglas Landgraf" > > > > > > Sent: Friday, March 28, 2014 2:37:05 PM > > > > > > Subject: [node-devel] Versioning of oVirt Node > > > > > > > > > > > > Hey, > > > > > > > > > > > > currently [0] - or since the split into base image and layered > > > > > > image > > > > > > - > > > > > > the versioning of Node hasn't been really resolved. > > > > > > > > > > > > I'd like to change the versioning of Node with the goal to make it > > > > > > directly obvious what oVirt version a Node is targeting. > > > > > > > > > > > > Before I continue let me clarify that this is primarily about the > > > > > > versioning of the Node ISO. > > > > > > The versioning of the wrapper-rpm can possibly follow the naming of > > > > > > the > > > > > > ISO, as long as we make yum happy. > > > > > > Also this is not about the ovirt-node (pkg) versioning, only about > > > > > > the > > > > > > iso image. > > > > > > > > > > > > Currently the ISO naming is as follows: > > > > > > > > > > > > ovirt-node-iso--...\ > > > > > > vdsm..iso > > > > > > > > > > > > (i.e. ovirt-node-iso-3.0.4-1.0.201401291204.vdsm34.el6.iso) > > > > > > > > > > > > The main pain point of this is IMO the vdsm34 snippet - because it > > > > > > breaks the whol envr and is currently just added after the > > > > > > edit-node > > > > > > pass. > > > > > > > > > > > > I'm proposing the following scheme: > > > > > > > > > > > > ovirt-node-iso--...iso > > > > > > > > > > > > (i.e. ovirt-node-iso-3.4.0-20140328.1.el6.iso) > > > > > > > > > > > > This should make it obvious to the user what ISO to use. > > > > > > > > > > > > > > > > > > Now about the rpm scheme. We can not change this as long as the > > > > > > Engine > > > > > > logic has not been updated to use the proposed metadata file: > > > > > > https://bugzilla.redhat.com/show_bug.cgi?id=1081969 (Node) > > > > > > https://bugzilla.redhat.com/show_bug.cgi?id=1081970 > > > > > > > > > > > > Once these two bugs have been addressed we can also change the rpm > > > > > > naming. > > > > > > In general I'd like to follow the iso naming, thus: > > > > > > > > > > > > ovirt-node-iso--...rpm > > > > > > > > > > > > > > > I think that we should have upstream version for ovirt node as any > > > > > other > > > > > upstream version we have. > > > > > > > > > > I also do not like dates embed within release as it will make our > > > > > lives > > > > > difficult when we have proper bug tracking system in place. > > > > > > > > > > I am unsure what 'iso' means... I think it should be removed or > > > > > converted > > > > > to > > > > > subpackage. > > > > > > > > > > Should we also consider parallel versions of different > > > > > distributions(?) > > > > > (fc19, fc20). > > > > > > > > Doesn't this miss the entire node purpose ? a user should not care what > > > > platform was used to build the node. > > > > > > If we keep in parallel different distributions per single version of > > > ovirt, > > > we should somehow mark it in the binary output. > > > > > > For example we have experimental fedora-21 image based on > > > ovirt-node-iso-3.4.2, while release is based on fedora-19. > > > > The purpose of ovirt-node is to be distribution agnostic (see esx server). > > If we have experimental image than it should be marked as such - not that > > it > > is based on f-21. > > The developers should know exactly what distro/version it was built from, I > > don't think that users care. > > I am unsure users will not care if we can offer options for multiple images > that works with the same ovirt milestone. > But this is not that important at this point. > +1. I had a long conversation with a user who insists on Debian based hosts. I tried to explain him he should consider it as black box / appliance but he wouldn't want to hear about it. > > > > Barak > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Pre-release: > > > > > ovirt-node-iso-3.4.0-0.$(sequence).$(branch).$(date).dist.rpm > > > > > > > > > > Released: > > > > > ovirt-node-iso-3.4.z-1.dist.rpm > > > > > > > > > > Please note that the downstream component is eliminated in upstream, > > > > > what > > > > > important in upstream is the source tarball.... > > > > > > > > > > ovirt-ndoe-iso-3.4.z.tar.gz > > > > > > > > > > Regards, > > > > > Alon > > > > > _______________________________________________ > > > > > Arch mailing list > > > > > Arch at ovirt.org > > > > > http://lists.ovirt.org/mailman/listinfo/arch > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > Arch mailing list > Arch at ovirt.org > http://lists.ovirt.org/mailman/listinfo/arch > From fabiand at redhat.com Mon Mar 31 07:45:15 2014 From: fabiand at redhat.com (Fabian Deutsch) Date: Mon, 31 Mar 2014 09:45:15 +0200 Subject: [node-devel] Versioning of oVirt Node In-Reply-To: <1611733432.4095464.1396169829479.JavaMail.zimbra@redhat.com> References: <1396006625.2943.43.camel@fdeutsch-laptop.local> <1611733432.4095464.1396169829479.JavaMail.zimbra@redhat.com> Message-ID: <1396251915.3043.24.camel@fdeutsch-laptop.local> Am Sonntag, den 30.03.2014, 04:57 -0400 schrieb Alon Bar-Lev: > > ----- Original Message ----- > > From: "Fabian Deutsch" > > To: arch at ovirt.org, "node-devel" > > Cc: "Douglas Landgraf" > > Sent: Friday, March 28, 2014 2:37:05 PM > > Subject: [node-devel] Versioning of oVirt Node > > > > Hey, > > > > currently [0] - or since the split into base image and layered image - > > the versioning of Node hasn't been really resolved. > > > > I'd like to change the versioning of Node with the goal to make it > > directly obvious what oVirt version a Node is targeting. > > > > Before I continue let me clarify that this is primarily about the > > versioning of the Node ISO. > > The versioning of the wrapper-rpm can possibly follow the naming of the > > ISO, as long as we make yum happy. > > Also this is not about the ovirt-node (pkg) versioning, only about the > > iso image. > > > > Currently the ISO naming is as follows: > > > > ovirt-node-iso--...\ > > vdsm..iso > > > > (i.e. ovirt-node-iso-3.0.4-1.0.201401291204.vdsm34.el6.iso) > > > > The main pain point of this is IMO the vdsm34 snippet - because it > > breaks the whol envr and is currently just added after the edit-node > > pass. > > > > I'm proposing the following scheme: > > > > ovirt-node-iso--...iso > > > > (i.e. ovirt-node-iso-3.4.0-20140328.1.el6.iso) > > > > This should make it obvious to the user what ISO to use. > > > > > > Now about the rpm scheme. We can not change this as long as the Engine > > logic has not been updated to use the proposed metadata file: > > https://bugzilla.redhat.com/show_bug.cgi?id=1081969 (Node) > > https://bugzilla.redhat.com/show_bug.cgi?id=1081970 > > > > Once these two bugs have been addressed we can also change the rpm > > naming. > > In general I'd like to follow the iso naming, thus: > > > > ovirt-node-iso--...rpm > > > I think that we should have upstream version for ovirt node as any other upstream version we have. Yeah, after sleeping a bit about this, I also believe that we can be more "conservative" when it comes to the rpm naming. That means I could imagine going with the plain NVR ? > I also do not like dates embed within release as it will make our lives difficult when we have proper bug tracking system in place. ? including without the build date, and only a propper (increasing) release verison. > I am unsure what 'iso' means... I think it should be removed or converted to subpackage. The iso means that this package carries the ISO which can be deploayed by Engine. ovirt-node - Package with the recipe/kickstart and actual codebase ovirt-node-iso - Wrapper for the ISO containing ovirt-node I do not favor of making ovirt-node-iso a subpackage of ovirt-node. Because ovirt-node is actually contained in ovirt-node-iso. > Should we also consider parallel versions of different distributions(?) (fc19, fc20). In general I favor of having only one stable Node per distribution. Thus one for Fedora, and one for CentOS. Besides that, we could investigate how yum is handling different dist tags on packages in the same repo. I.e.: node-3.0-0.fc19.rpm node-3.0-0.el6.rpm In the same repo. If the el6 variant is installed on the Engine side, does yum automatically update to the 3.1 el6 variant when it comes out? Or does yum ignore the different dist-tags? > Pre-release: > ovirt-node-iso-3.4.0-0.$(sequence).$(branch).$(date).dist.rpm Could you please give an example for this. And - as noted above - I could live with dropping the date for the wrapper-rpms - tho it is still handy to have them. > Released: > ovirt-node-iso-3.4.z-1.dist.rpm would you replase z in that string above? > Please note that the downstream component is eliminated in upstream, Could you please exaplain this a bit more. > what important in upstream is the source tarball.... > ovirt-ndoe-iso-3.4.z.tar.gz Thanks for that lengthy input! - fabian -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part URL: From fabiand at redhat.com Mon Mar 31 07:46:01 2014 From: fabiand at redhat.com (Fabian Deutsch) Date: Mon, 31 Mar 2014 09:46:01 +0200 Subject: [node-devel] Versioning of oVirt Node In-Reply-To: <1741846884.4148258.1396173065062.JavaMail.zimbra@redhat.com> References: <1396006625.2943.43.camel@fdeutsch-laptop.local> <1611733432.4095464.1396169829479.JavaMail.zimbra@redhat.com> <1741846884.4148258.1396173065062.JavaMail.zimbra@redhat.com> Message-ID: <1396251961.3043.25.camel@fdeutsch-laptop.local> Am Sonntag, den 30.03.2014, 05:51 -0400 schrieb Barak Azulay: > > Should we also consider parallel versions of different > distributions(?) > > (fc19, fc20). > > Doesn't this miss the entire node purpose ? a user should not care > what platform was used to build the node. As said elsewhere. For some users the base-os is important to know. - fabian -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part URL: From fabiand at redhat.com Mon Mar 31 07:48:13 2014 From: fabiand at redhat.com (Fabian Deutsch) Date: Mon, 31 Mar 2014 09:48:13 +0200 Subject: [node-devel] Versioning of oVirt Node In-Reply-To: <2029737926.4163582.1396183556835.JavaMail.zimbra@redhat.com> References: <1396006625.2943.43.camel@fdeutsch-laptop.local> <1611733432.4095464.1396169829479.JavaMail.zimbra@redhat.com> <1741846884.4148258.1396173065062.JavaMail.zimbra@redhat.com> <1148507703.4096754.1396173212861.JavaMail.zimbra@redhat.com> <2029737926.4163582.1396183556835.JavaMail.zimbra@redhat.com> Message-ID: <1396252093.3043.27.camel@fdeutsch-laptop.local> Am Sonntag, den 30.03.2014, 08:45 -0400 schrieb Barak Azulay: > > ----- Original Message ----- > > From: "Alon Bar-Lev" > > To: "Barak Azulay" > > Cc: "Fabian Deutsch" , arch at ovirt.org, "Douglas Landgraf" , "node-devel" > > > > Sent: Sunday, March 30, 2014 12:53:32 PM > > Subject: Re: [node-devel] Versioning of oVirt Node > > > > > > > > ----- Original Message ----- > > > From: "Barak Azulay" > > > To: "Alon Bar-Lev" > > > Cc: "Fabian Deutsch" , arch at ovirt.org, "Douglas > > > Landgraf" , "node-devel" > > > > > > Sent: Sunday, March 30, 2014 12:51:05 PM > > > Subject: Re: [node-devel] Versioning of oVirt Node > > > > > > > > > > > > ----- Original Message ----- > > > > From: "Alon Bar-Lev" > > > > To: "Fabian Deutsch" > > > > Cc: arch at ovirt.org, "Douglas Landgraf" , > > > > "node-devel" > > > > > > > > Sent: Sunday, March 30, 2014 11:57:09 AM > > > > Subject: Re: [node-devel] Versioning of oVirt Node > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > From: "Fabian Deutsch" > > > > > To: arch at ovirt.org, "node-devel" > > > > > Cc: "Douglas Landgraf" > > > > > Sent: Friday, March 28, 2014 2:37:05 PM > > > > > Subject: [node-devel] Versioning of oVirt Node > > > > > > > > > > Hey, > > > > > > > > > > currently [0] - or since the split into base image and layered image - > > > > > the versioning of Node hasn't been really resolved. > > > > > > > > > > I'd like to change the versioning of Node with the goal to make it > > > > > directly obvious what oVirt version a Node is targeting. > > > > > > > > > > Before I continue let me clarify that this is primarily about the > > > > > versioning of the Node ISO. > > > > > The versioning of the wrapper-rpm can possibly follow the naming of the > > > > > ISO, as long as we make yum happy. > > > > > Also this is not about the ovirt-node (pkg) versioning, only about the > > > > > iso image. > > > > > > > > > > Currently the ISO naming is as follows: > > > > > > > > > > ovirt-node-iso--...\ > > > > > vdsm..iso > > > > > > > > > > (i.e. ovirt-node-iso-3.0.4-1.0.201401291204.vdsm34.el6.iso) > > > > > > > > > > The main pain point of this is IMO the vdsm34 snippet - because it > > > > > breaks the whol envr and is currently just added after the edit-node > > > > > pass. > > > > > > > > > > I'm proposing the following scheme: > > > > > > > > > > ovirt-node-iso--...iso > > > > > > > > > > (i.e. ovirt-node-iso-3.4.0-20140328.1.el6.iso) > > > > > > > > > > This should make it obvious to the user what ISO to use. > > > > > > > > > > > > > > > Now about the rpm scheme. We can not change this as long as the Engine > > > > > logic has not been updated to use the proposed metadata file: > > > > > https://bugzilla.redhat.com/show_bug.cgi?id=1081969 (Node) > > > > > https://bugzilla.redhat.com/show_bug.cgi?id=1081970 > > > > > > > > > > Once these two bugs have been addressed we can also change the rpm > > > > > naming. > > > > > In general I'd like to follow the iso naming, thus: > > > > > > > > > > ovirt-node-iso--...rpm > > > > > > > > > > > > I think that we should have upstream version for ovirt node as any other > > > > upstream version we have. > > > > > > > > I also do not like dates embed within release as it will make our lives > > > > difficult when we have proper bug tracking system in place. > > > > > > > > I am unsure what 'iso' means... I think it should be removed or converted > > > > to > > > > subpackage. > > > > > > > > Should we also consider parallel versions of different distributions(?) > > > > (fc19, fc20). > > > > > > Doesn't this miss the entire node purpose ? a user should not care what > > > platform was used to build the node. > > > > If we keep in parallel different distributions per single version of ovirt, > > we should somehow mark it in the binary output. > > > > For example we have experimental fedora-21 image based on > > ovirt-node-iso-3.4.2, while release is based on fedora-19. > > The purpose of ovirt-node is to be distribution agnostic (see esx server). > If we have experimental image than it should be marked as such - not that it is based on f-21. > The developers should know exactly what distro/version it was built from, I don't think that users care. Technically the wrapper-rpm is noarch. Because the contained iso is independent of the host-architecture. Besides that I'd reflect the OS in the rpm name. And as my last comment - the classification if an ISO/rpm is stable or not is done by placing the rpm in the correct (stable or beta) repo. - fabian > Barak > > > > > > > > > > > > > > > > > > > > > > Pre-release: > > > > ovirt-node-iso-3.4.0-0.$(sequence).$(branch).$(date).dist.rpm > > > > > > > > Released: > > > > ovirt-node-iso-3.4.z-1.dist.rpm > > > > > > > > Please note that the downstream component is eliminated in upstream, what > > > > important in upstream is the source tarball.... > > > > > > > > ovirt-ndoe-iso-3.4.z.tar.gz > > > > > > > > Regards, > > > > Alon > > > > _______________________________________________ > > > > Arch mailing list > > > > Arch at ovirt.org > > > > http://lists.ovirt.org/mailman/listinfo/arch > > > > > > > > > > > > > > > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part URL: From alonbl at redhat.com Mon Mar 31 08:52:39 2014 From: alonbl at redhat.com (Alon Bar-Lev) Date: Mon, 31 Mar 2014 04:52:39 -0400 (EDT) Subject: [node-devel] Versioning of oVirt Node In-Reply-To: <1396251915.3043.24.camel@fdeutsch-laptop.local> References: <1396006625.2943.43.camel@fdeutsch-laptop.local> <1611733432.4095464.1396169829479.JavaMail.zimbra@redhat.com> <1396251915.3043.24.camel@fdeutsch-laptop.local> Message-ID: <890404270.4200435.1396255959839.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Fabian Deutsch" > To: "Alon Bar-Lev" > Cc: arch at ovirt.org, "node-devel" , "Douglas Landgraf" > Sent: Monday, March 31, 2014 10:45:15 AM > Subject: Re: [node-devel] Versioning of oVirt Node > > Am Sonntag, den 30.03.2014, 04:57 -0400 schrieb Alon Bar-Lev: > > > > ----- Original Message ----- > > > From: "Fabian Deutsch" > > > To: arch at ovirt.org, "node-devel" > > > Cc: "Douglas Landgraf" > > > Sent: Friday, March 28, 2014 2:37:05 PM > > > Subject: [node-devel] Versioning of oVirt Node > > > > > > Hey, > > > > > > currently [0] - or since the split into base image and layered image - > > > the versioning of Node hasn't been really resolved. > > > > > > I'd like to change the versioning of Node with the goal to make it > > > directly obvious what oVirt version a Node is targeting. > > > > > > Before I continue let me clarify that this is primarily about the > > > versioning of the Node ISO. > > > The versioning of the wrapper-rpm can possibly follow the naming of the > > > ISO, as long as we make yum happy. > > > Also this is not about the ovirt-node (pkg) versioning, only about the > > > iso image. > > > > > > Currently the ISO naming is as follows: > > > > > > ovirt-node-iso--...\ > > > vdsm..iso > > > > > > (i.e. ovirt-node-iso-3.0.4-1.0.201401291204.vdsm34.el6.iso) > > > > > > The main pain point of this is IMO the vdsm34 snippet - because it > > > breaks the whol envr and is currently just added after the edit-node > > > pass. > > > > > > I'm proposing the following scheme: > > > > > > ovirt-node-iso--...iso > > > > > > (i.e. ovirt-node-iso-3.4.0-20140328.1.el6.iso) > > > > > > This should make it obvious to the user what ISO to use. > > > > > > > > > Now about the rpm scheme. We can not change this as long as the Engine > > > logic has not been updated to use the proposed metadata file: > > > https://bugzilla.redhat.com/show_bug.cgi?id=1081969 (Node) > > > https://bugzilla.redhat.com/show_bug.cgi?id=1081970 > > > > > > Once these two bugs have been addressed we can also change the rpm > > > naming. > > > In general I'd like to follow the iso naming, thus: > > > > > > ovirt-node-iso--...rpm > > > > > > I think that we should have upstream version for ovirt node as any other > > upstream version we have. > > Yeah, after sleeping a bit about this, I also believe that we can be > more "conservative" when it comes to the rpm naming. > > That means I could imagine going with the plain NVR ? > > > I also do not like dates embed within release as it will make our lives > > difficult when we have proper bug tracking system in place. > > ? including without the build date, and only a propper (increasing) > release verison. > > > I am unsure what 'iso' means... I think it should be removed or converted > > to subpackage. > > The iso means that this package carries the ISO which can be deploayed > by Engine. > > ovirt-node - Package with the recipe/kickstart and actual codebase > ovirt-node-iso - Wrapper for the ISO containing ovirt-node > > I do not favor of making ovirt-node-iso a subpackage of ovirt-node. > Because ovirt-node is actually contained in ovirt-node-iso. ok, although the fact that it carries iso is not significant... as the binary (built) representation of node is iso... but not that important :) > > > Should we also consider parallel versions of different distributions(?) > > (fc19, fc20). > > In general I favor of having only one stable Node per distribution. Thus > one for Fedora, and one for CentOS. > > Besides that, we could investigate how yum is handling different dist > tags on packages in the same repo. > I.e.: > node-3.0-0.fc19.rpm > node-3.0-0.el6.rpm > In the same repo. no... it should be: node-fc19-3.0-0.fc19.rpm node-centos-3.0-0.fc19.rpm node-fc19-3.0-0.el6.rpm node-centos-3.0-0.el6.rpm As there is no reason why I would not like centos hosts for my fedora engine :) And there is no reason why we should not allow keeping these available side-by-side. > If the el6 variant is installed on the Engine side, does yum > automatically update to the 3.1 el6 variant when it comes out? Or does > yum ignore the different dist-tags? > > > Pre-release: > > ovirt-node-iso-3.4.0-0.$(sequence).$(branch).$(date).dist.rpm > > Could you please give an example for this. You can see lots of examples at other projects[1] [1] http://resources.ovirt.org/pub/ovirt-snapshot/rpm/fc19/noarch/ > And - as noted above - I could live with dropping the date for the > wrapper-rpms - tho it is still handy to have them. Why is it handy, what is it serve? > > > Released: > > ovirt-node-iso-3.4.z-1.dist.rpm > > would you replase z in that string above? Each stable release/fix release you issue z is incremented async of any other package. > > > Please note that the downstream component is eliminated in upstream, > > Could you please exaplain this a bit more. You wrote: > > > ovirt-node-iso--...iso This means that you have no upstream version for your own use... ovirt-target-version is of ovirt, but what is the version of the node? I hope I answered your question. > > > what important in upstream is the source tarball.... > > ovirt-ndoe-iso-3.4.z.tar.gz > > Thanks for that lengthy input! > > - fabian > From bazulay at redhat.com Mon Mar 31 09:08:48 2014 From: bazulay at redhat.com (Barak Azulay) Date: Mon, 31 Mar 2014 05:08:48 -0400 (EDT) Subject: [node-devel] Versioning of oVirt Node In-Reply-To: <1396247995.3043.4.camel@fdeutsch-laptop.local> References: <1396006625.2943.43.camel@fdeutsch-laptop.local> <859671594.4143833.1396169171061.JavaMail.zimbra@redhat.com> <1396247995.3043.4.camel@fdeutsch-laptop.local> Message-ID: <80562838.4387376.1396256928698.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Fabian Deutsch" > To: "Barak Azulay" > Cc: arch at ovirt.org, "node-devel" , "Douglas Landgraf" > Sent: Monday, March 31, 2014 9:39:55 AM > Subject: Re: [node-devel] Versioning of oVirt Node > > Am Sonntag, den 30.03.2014, 04:46 -0400 schrieb Barak Azulay: > > I assume that this new schema is handling also the frist upgrade from > > the old name schema. > > Hey Barak, > > could you explain what the first upgrade to the old schema name was for > you? There are 2 scenarios that needs to be considered: 1 older engine with new rhevh (with new name schema) * customer with rhev 3.4 tries to upgrade a 3.4 cluster level rhevh to the latest rhevh (with new name schema ... 3.4 cluster level) 2 newer engine supporting older clustrers: * assume you have 3.4 engine out with several ISOs located in the same dir, Than there is an upgrade to 3.5 where the name schema changes (and in the same dir you have old name schema and new name schema), Than you want to upgrade a 3.4 cluster level rhevh to the latest rhevh (with new name schema ... 3.4 cluster level) In both cases the UI should suggest the best fit for upgrade, While for #2 we can add some logic to the engine to handle both cases (ugly and problematic), For #1 above there is very little we can do. > > - fabian > From bazulay at redhat.com Mon Mar 31 09:16:38 2014 From: bazulay at redhat.com (Barak Azulay) Date: Mon, 31 Mar 2014 05:16:38 -0400 (EDT) Subject: [node-devel] Versioning of oVirt Node In-Reply-To: <1396251961.3043.25.camel@fdeutsch-laptop.local> References: <1396006625.2943.43.camel@fdeutsch-laptop.local> <1611733432.4095464.1396169829479.JavaMail.zimbra@redhat.com> <1741846884.4148258.1396173065062.JavaMail.zimbra@redhat.com> <1396251961.3043.25.camel@fdeutsch-laptop.local> Message-ID: <1679355597.4392392.1396257398561.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Fabian Deutsch" > To: "Barak Azulay" > Cc: arch at ovirt.org, "Douglas Landgraf" , "node-devel" > Sent: Monday, March 31, 2014 10:46:01 AM > Subject: Re: [node-devel] Versioning of oVirt Node > > Am Sonntag, den 30.03.2014, 05:51 -0400 schrieb Barak Azulay: > > > Should we also consider parallel versions of different > > distributions(?) > > > (fc19, fc20). > > > > Doesn't this miss the entire node purpose ? a user should not care > > what platform was used to build the node. > > As said elsewhere. For some users the base-os is important to know. Any idea why ? The only thing I can think off is that we are probably doing something wrong. > > - fabian > > _______________________________________________ > Arch mailing list > Arch at ovirt.org > http://lists.ovirt.org/mailman/listinfo/arch > From bazulay at redhat.com Mon Mar 31 09:20:59 2014 From: bazulay at redhat.com (Barak Azulay) Date: Mon, 31 Mar 2014 05:20:59 -0400 (EDT) Subject: [node-devel] Versioning of oVirt Node In-Reply-To: <890404270.4200435.1396255959839.JavaMail.zimbra@redhat.com> References: <1396006625.2943.43.camel@fdeutsch-laptop.local> <1611733432.4095464.1396169829479.JavaMail.zimbra@redhat.com> <1396251915.3043.24.camel@fdeutsch-laptop.local> <890404270.4200435.1396255959839.JavaMail.zimbra@redhat.com> Message-ID: <251541336.4394812.1396257659607.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Alon Bar-Lev" > To: "Fabian Deutsch" > Cc: arch at ovirt.org, "Douglas Landgraf" , "node-devel" > Sent: Monday, March 31, 2014 11:52:39 AM > Subject: Re: [node-devel] Versioning of oVirt Node > > > > ----- Original Message ----- > > From: "Fabian Deutsch" > > To: "Alon Bar-Lev" > > Cc: arch at ovirt.org, "node-devel" , "Douglas Landgraf" > > > > Sent: Monday, March 31, 2014 10:45:15 AM > > Subject: Re: [node-devel] Versioning of oVirt Node > > > > Am Sonntag, den 30.03.2014, 04:57 -0400 schrieb Alon Bar-Lev: > > > > > > ----- Original Message ----- > > > > From: "Fabian Deutsch" > > > > To: arch at ovirt.org, "node-devel" > > > > Cc: "Douglas Landgraf" > > > > Sent: Friday, March 28, 2014 2:37:05 PM > > > > Subject: [node-devel] Versioning of oVirt Node > > > > > > > > Hey, > > > > > > > > currently [0] - or since the split into base image and layered image - > > > > the versioning of Node hasn't been really resolved. > > > > > > > > I'd like to change the versioning of Node with the goal to make it > > > > directly obvious what oVirt version a Node is targeting. > > > > > > > > Before I continue let me clarify that this is primarily about the > > > > versioning of the Node ISO. > > > > The versioning of the wrapper-rpm can possibly follow the naming of the > > > > ISO, as long as we make yum happy. > > > > Also this is not about the ovirt-node (pkg) versioning, only about the > > > > iso image. > > > > > > > > Currently the ISO naming is as follows: > > > > > > > > ovirt-node-iso--...\ > > > > vdsm..iso > > > > > > > > (i.e. ovirt-node-iso-3.0.4-1.0.201401291204.vdsm34.el6.iso) > > > > > > > > The main pain point of this is IMO the vdsm34 snippet - because it > > > > breaks the whol envr and is currently just added after the edit-node > > > > pass. > > > > > > > > I'm proposing the following scheme: > > > > > > > > ovirt-node-iso--...iso > > > > > > > > (i.e. ovirt-node-iso-3.4.0-20140328.1.el6.iso) > > > > > > > > This should make it obvious to the user what ISO to use. > > > > > > > > > > > > Now about the rpm scheme. We can not change this as long as the Engine > > > > logic has not been updated to use the proposed metadata file: > > > > https://bugzilla.redhat.com/show_bug.cgi?id=1081969 (Node) > > > > https://bugzilla.redhat.com/show_bug.cgi?id=1081970 > > > > > > > > Once these two bugs have been addressed we can also change the rpm > > > > naming. > > > > In general I'd like to follow the iso naming, thus: > > > > > > > > ovirt-node-iso--...rpm > > > > > > > > > I think that we should have upstream version for ovirt node as any other > > > upstream version we have. > > > > Yeah, after sleeping a bit about this, I also believe that we can be > > more "conservative" when it comes to the rpm naming. > > > > That means I could imagine going with the plain NVR ? > > > > > I also do not like dates embed within release as it will make our lives > > > difficult when we have proper bug tracking system in place. > > > > ? including without the build date, and only a propper (increasing) > > release verison. > > > > > I am unsure what 'iso' means... I think it should be removed or converted > > > to subpackage. > > > > The iso means that this package carries the ISO which can be deploayed > > by Engine. > > > > ovirt-node - Package with the recipe/kickstart and actual codebase > > ovirt-node-iso - Wrapper for the ISO containing ovirt-node > > > > I do not favor of making ovirt-node-iso a subpackage of ovirt-node. > > Because ovirt-node is actually contained in ovirt-node-iso. > > ok, although the fact that it carries iso is not significant... as the binary > (built) representation of node is iso... > but not that important :) > > > > > > Should we also consider parallel versions of different distributions(?) > > > (fc19, fc20). > > > > In general I favor of having only one stable Node per distribution. Thus > > one for Fedora, and one for CentOS. > > > > Besides that, we could investigate how yum is handling different dist > > tags on packages in the same repo. > > I.e.: > > node-3.0-0.fc19.rpm > > node-3.0-0.el6.rpm > > In the same repo. > > no... it should be: > > node-fc19-3.0-0.fc19.rpm > node-centos-3.0-0.fc19.rpm > node-fc19-3.0-0.el6.rpm > node-centos-3.0-0.el6.rpm > > As there is no reason why I would not like centos hosts for my fedora engine > :) > > And there is no reason why we should not allow keeping these available > side-by-side. The logic of selection the most appropriate upgrade suggest different. Guys again if users need to know what distro ovirt-node is constructed from than it misses the entire point of the node > > > > If the el6 variant is installed on the Engine side, does yum > > automatically update to the 3.1 el6 variant when it comes out? Or does > > yum ignore the different dist-tags? > > > > > Pre-release: > > > ovirt-node-iso-3.4.0-0.$(sequence).$(branch).$(date).dist.rpm > > > > Could you please give an example for this. > > You can see lots of examples at other projects[1] > > [1] http://resources.ovirt.org/pub/ovirt-snapshot/rpm/fc19/noarch/ > > > And - as noted above - I could live with dropping the date for the > > wrapper-rpms - tho it is still handy to have them. > > Why is it handy, what is it serve? > > > > > > Released: > > > ovirt-node-iso-3.4.z-1.dist.rpm > > > > would you replase z in that string above? > > Each stable release/fix release you issue z is incremented async of any other > package. > > > > > > Please note that the downstream component is eliminated in upstream, > > > > Could you please exaplain this a bit more. > > You wrote: > > > > > ovirt-node-iso--...iso > > This means that you have no upstream version for your own use... > ovirt-target-version is of ovirt, but what is the version of the node? > > I hope I answered your question. > > > > > > what important in upstream is the source tarball.... > > > ovirt-ndoe-iso-3.4.z.tar.gz > > > > Thanks for that lengthy input! > > > > - fabian > > > _______________________________________________ > Arch mailing list > Arch at ovirt.org > http://lists.ovirt.org/mailman/listinfo/arch > > > From alonbl at redhat.com Mon Mar 31 09:29:23 2014 From: alonbl at redhat.com (Alon Bar-Lev) Date: Mon, 31 Mar 2014 05:29:23 -0400 (EDT) Subject: [node-devel] Versioning of oVirt Node In-Reply-To: <251541336.4394812.1396257659607.JavaMail.zimbra@redhat.com> References: <1396006625.2943.43.camel@fdeutsch-laptop.local> <1611733432.4095464.1396169829479.JavaMail.zimbra@redhat.com> <1396251915.3043.24.camel@fdeutsch-laptop.local> <890404270.4200435.1396255959839.JavaMail.zimbra@redhat.com> <251541336.4394812.1396257659607.JavaMail.zimbra@redhat.com> Message-ID: <1089187843.4206459.1396258163862.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Barak Azulay" > To: "Alon Bar-Lev" > Cc: "Fabian Deutsch" , arch at ovirt.org, "Douglas Landgraf" , "node-devel" > > Sent: Monday, March 31, 2014 12:20:59 PM > Subject: Re: [node-devel] Versioning of oVirt Node > > > As there is no reason why I would not like centos hosts for my fedora > > engine > > :) > > > > And there is no reason why we should not allow keeping these available > > side-by-side. > > The logic of selection the most appropriate upgrade suggest different. This should be solved by provides statement. > Guys again if users need to know what distro ovirt-node is constructed from > than it misses the entire point of the node If you base your implementation on specific distribution, then I do mind which, as I want to modify, build and use customized versions, and has no knowledge how to do that in red hat based os. As long as fedora instability and methods or centos/rhel old component enforcements are used, why not allowing debian users to feel comfortable as well, allowing them to pull this into their direction? Maybe at the end stable debian is the right way to go? Had you created your tiny distribution based on busybox, libvirt, vdsm etc... cross compile all from sources, then you would have been right, as it is our own distribution that fully controlled by the ovirt community. Alon From fabiand at redhat.com Mon Mar 31 09:41:43 2014 From: fabiand at redhat.com (Fabian Deutsch) Date: Mon, 31 Mar 2014 11:41:43 +0200 Subject: [node-devel] Versioning of oVirt Node In-Reply-To: <1679355597.4392392.1396257398561.JavaMail.zimbra@redhat.com> References: <1396006625.2943.43.camel@fdeutsch-laptop.local> <1611733432.4095464.1396169829479.JavaMail.zimbra@redhat.com> <1741846884.4148258.1396173065062.JavaMail.zimbra@redhat.com> <1396251961.3043.25.camel@fdeutsch-laptop.local> <1679355597.4392392.1396257398561.JavaMail.zimbra@redhat.com> Message-ID: <1396258903.3043.29.camel@fdeutsch-laptop.local> Am Montag, den 31.03.2014, 05:16 -0400 schrieb Barak Azulay: > > ----- Original Message ----- > > From: "Fabian Deutsch" > > To: "Barak Azulay" > > Cc: arch at ovirt.org, "Douglas Landgraf" , "node-devel" > > Sent: Monday, March 31, 2014 10:46:01 AM > > Subject: Re: [node-devel] Versioning of oVirt Node > > > > Am Sonntag, den 30.03.2014, 05:51 -0400 schrieb Barak Azulay: > > > > Should we also consider parallel versions of different > > > distributions(?) > > > > (fc19, fc20). > > > > > > Doesn't this miss the entire node purpose ? a user should not care > > > what platform was used to build the node. > > > > As said elsewhere. For some users the base-os is important to know. > > Any idea why ? > > The only thing I can think off is that we are probably doing something wrong. Some people just want to use CentOS, others favor Fedora. I believe partially it's just a personal preference. OTOH it is surely the case that el6 is slower moving then Fedora, and thus it is more stable. I'd also say that this is true for the el6 based Node. We keep the Fedora based Node around - or bring it back - to have a platform to develop on. - fabian > > > > - fabian > > > > _______________________________________________ > > Arch mailing list > > Arch at ovirt.org > > http://lists.ovirt.org/mailman/listinfo/arch > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part URL: From bazulay at redhat.com Mon Mar 31 10:19:52 2014 From: bazulay at redhat.com (Barak Azulay) Date: Mon, 31 Mar 2014 06:19:52 -0400 (EDT) Subject: [node-devel] Versioning of oVirt Node In-Reply-To: <1089187843.4206459.1396258163862.JavaMail.zimbra@redhat.com> References: <1396006625.2943.43.camel@fdeutsch-laptop.local> <1611733432.4095464.1396169829479.JavaMail.zimbra@redhat.com> <1396251915.3043.24.camel@fdeutsch-laptop.local> <890404270.4200435.1396255959839.JavaMail.zimbra@redhat.com> <251541336.4394812.1396257659607.JavaMail.zimbra@redhat.com> <1089187843.4206459.1396258163862.JavaMail.zimbra@redhat.com> Message-ID: <149691885.4421293.1396261192577.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Alon Bar-Lev" > To: "Barak Azulay" > Cc: "Fabian Deutsch" , arch at ovirt.org, "Douglas Landgraf" , "node-devel" > > Sent: Monday, March 31, 2014 12:29:23 PM > Subject: Re: [node-devel] Versioning of oVirt Node > > > > ----- Original Message ----- > > From: "Barak Azulay" > > To: "Alon Bar-Lev" > > Cc: "Fabian Deutsch" , arch at ovirt.org, "Douglas > > Landgraf" , "node-devel" > > > > Sent: Monday, March 31, 2014 12:20:59 PM > > Subject: Re: [node-devel] Versioning of oVirt Node > > > > > > As there is no reason why I would not like centos hosts for my fedora > > > engine > > > :) > > > > > > And there is no reason why we should not allow keeping these available > > > side-by-side. > > > > The logic of selection the most appropriate upgrade suggest different. > > This should be solved by provides statement. > > > Guys again if users need to know what distro ovirt-node is constructed from > > than it misses the entire point of the node > > If you base your implementation on specific distribution, then I do mind > which, as I want to modify, build and use customized versions, and has no > knowledge how to do that in red hat based os. > > As long as fedora instability and methods or centos/rhel old component > enforcements are used, why not allowing debian users to feel comfortable as > well, allowing them to pull this into their direction? Maybe at the end > stable debian is the right way to go? > > Had you created your tiny distribution based on busybox, libvirt, vdsm etc... > cross compile all from sources, then you would have been right, as it is our > own distribution that fully controlled by the ovirt community. If a user need to customize the hypervisor he can use a regular OS of his choice configured and tailored to his needs (Fedora ..., CentOS ...Debian, Gentoo ...) This is a valid use case and effort for the community. While having a black box hypervisor, should be the exact fit to just run VMs in oVirt environment. Why to handle specific OS configuration in a much more complex and less intuitive environment to manage ? Guys I really think this entirely misses the black-box approach. I don't mind moving to our own tiny distro as long as it's a single image to release and maintain The effort of maintaining multiple ovirt-nodes based on distro and distro-version and ovirt-version creates an unmanageable test matrix that all the community might loose from > > Alon > From fabiand at redhat.com Mon Mar 31 10:55:22 2014 From: fabiand at redhat.com (Fabian Deutsch) Date: Mon, 31 Mar 2014 12:55:22 +0200 Subject: [node-devel] Versioning of oVirt Node In-Reply-To: <251541336.4394812.1396257659607.JavaMail.zimbra@redhat.com> References: <1396006625.2943.43.camel@fdeutsch-laptop.local> <1611733432.4095464.1396169829479.JavaMail.zimbra@redhat.com> <1396251915.3043.24.camel@fdeutsch-laptop.local> <890404270.4200435.1396255959839.JavaMail.zimbra@redhat.com> <251541336.4394812.1396257659607.JavaMail.zimbra@redhat.com> Message-ID: <1396263322.3043.44.camel@fdeutsch-laptop.local> Am Montag, den 31.03.2014, 05:20 -0400 schrieb Barak Azulay: > > > > > > > > > Should we also consider parallel versions of different > distributions(?) > > > > (fc19, fc20). > > > > > > In general I favor of having only one stable Node per > distribution. Thus > > > one for Fedora, and one for CentOS. > > > > > > Besides that, we could investigate how yum is handling different > dist > > > tags on packages in the same repo. > > > I.e.: > > > node-3.0-0.fc19.rpm > > > node-3.0-0.el6.rpm > > > In the same repo. > > > > no... it should be: > > > > node-fc19-3.0-0.fc19.rpm > > node-centos-3.0-0.fc19.rpm > > node-fc19-3.0-0.el6.rpm > > node-centos-3.0-0.el6.rpm > > > > As there is no reason why I would not like centos hosts for my > fedora engine > > :) > > > > And there is no reason why we should not allow keeping these > available > > side-by-side. > > The logic of selection the most appropriate upgrade suggest different. > > Guys again if users need to know what distro ovirt-node is constructed > from than it misses the entire point of the node Basically the users don't need to know what platform is used for the Node. The original idea was to deliver CenTOS nodes from the centos repo, and Fedora nodes from the Fedora repo. If this makes sense is discussed on another branch of this thread. But we should give them the opportunity to use the Node they want, if they care about the platform. Technically it also makes a difference if you develop a plugin for CentOS or Fedora. - fabian -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part URL: From fabiand at redhat.com Mon Mar 31 11:21:57 2014 From: fabiand at redhat.com (Fabian Deutsch) Date: Mon, 31 Mar 2014 13:21:57 +0200 Subject: [node-devel] Versioning of oVirt Node In-Reply-To: <149691885.4421293.1396261192577.JavaMail.zimbra@redhat.com> References: <1396006625.2943.43.camel@fdeutsch-laptop.local> <1611733432.4095464.1396169829479.JavaMail.zimbra@redhat.com> <1396251915.3043.24.camel@fdeutsch-laptop.local> <890404270.4200435.1396255959839.JavaMail.zimbra@redhat.com> <251541336.4394812.1396257659607.JavaMail.zimbra@redhat.com> <1089187843.4206459.1396258163862.JavaMail.zimbra@redhat.com> <149691885.4421293.1396261192577.JavaMail.zimbra@redhat.com> Message-ID: <1396264917.3043.56.camel@fdeutsch-laptop.local> Am Montag, den 31.03.2014, 06:19 -0400 schrieb Barak Azulay: > > Had you created your tiny distribution based on busybox, libvirt, > vdsm etc... > > cross compile all from sources, then you would have been right, as > it is our > > own distribution that fully controlled by the ovirt community. > > If a user need to customize the hypervisor he can use a regular OS of > his choice configured and tailored to his needs (Fedora ..., > CentOS ...Debian, Gentoo ...) > This is a valid use case and effort for the community. > > While having a black box hypervisor, should be the exact fit to just > run VMs in oVirt environment. > Why to handle specific OS configuration in a much more complex and > less intuitive environment to manage ? > > Guys I really think this entirely misses the black-box approach. > > I don't mind moving to our own tiny distro as long as it's a single > image to release and maintain Well, Node _is_ actually a tiny distro, just based on some package based on some existing one. > The effort of maintaining multiple ovirt-nodes based on distro and > distro-version and ovirt-version creates an unmanageable test matrix > that all the community might loose from I partially agree here. From my POV the Fedora based Node is very useful for us to develop Node, sooner or later the changes we've got in Fedora will land in CentOS, thus devleoping on Fedora is a preparation for being able to deliver a (stable) CentOS based Node. So IMO we should continue to develop on Fedora, but we might want to consider to keep to only deliver the CentOS based Node. The Fedora based build could be seen as nightlies. - fabian -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part URL: From alonbl at redhat.com Mon Mar 31 11:57:56 2014 From: alonbl at redhat.com (Alon Bar-Lev) Date: Mon, 31 Mar 2014 07:57:56 -0400 (EDT) Subject: [node-devel] Versioning of oVirt Node In-Reply-To: <1396264917.3043.56.camel@fdeutsch-laptop.local> References: <1396006625.2943.43.camel@fdeutsch-laptop.local> <1611733432.4095464.1396169829479.JavaMail.zimbra@redhat.com> <1396251915.3043.24.camel@fdeutsch-laptop.local> <890404270.4200435.1396255959839.JavaMail.zimbra@redhat.com> <251541336.4394812.1396257659607.JavaMail.zimbra@redhat.com> <1089187843.4206459.1396258163862.JavaMail.zimbra@redhat.com> <149691885.4421293.1396261192577.JavaMail.zimbra@redhat.com> <1396264917.3043.56.camel@fdeutsch-laptop.local> Message-ID: <213497143.4251932.1396267076154.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Fabian Deutsch" > To: "Barak Azulay" > Cc: "Alon Bar-Lev" , arch at ovirt.org, "Douglas Landgraf" , "node-devel" > > Sent: Monday, March 31, 2014 2:21:57 PM > Subject: Re: [node-devel] Versioning of oVirt Node > > Am Montag, den 31.03.2014, 06:19 -0400 schrieb Barak Azulay: > > > Had you created your tiny distribution based on busybox, libvirt, > > vdsm etc... > > > cross compile all from sources, then you would have been right, as > > it is our > > > own distribution that fully controlled by the ovirt community. > > > > If a user need to customize the hypervisor he can use a regular OS of > > his choice configured and tailored to his needs (Fedora ..., > > CentOS ...Debian, Gentoo ...) > > This is a valid use case and effort for the community. > > > > While having a black box hypervisor, should be the exact fit to just > > run VMs in oVirt environment. > > Why to handle specific OS configuration in a much more complex and > > less intuitive environment to manage ? > > > > Guys I really think this entirely misses the black-box approach. > > > > I don't mind moving to our own tiny distro as long as it's a single > > image to release and maintain > > Well, Node _is_ actually a tiny distro, just based on some package based > on some existing one. I do not think that it is tiny distro... but let's not get into this argument :) > > > The effort of maintaining multiple ovirt-nodes based on distro and > > distro-version and ovirt-version creates an unmanageable test matrix > > that all the community might loose from > > I partially agree here. > From my POV the Fedora based Node is very useful for us to develop Node, > sooner or later the changes we've got in Fedora will land in CentOS, > thus devleoping on Fedora is a preparation for being able to deliver a > (stable) CentOS based Node. > > So IMO we should continue to develop on Fedora, but we might want to > consider to keep to only deliver the CentOS based Node. > The Fedora based build could be seen as nightlies. If we consider single base distribution (aka blackbox which is not black at all...), and you agree that centos is a fit, I do not see any reason to invest resources in fedora. > > - fabian > From fabiand at redhat.com Mon Mar 31 12:34:19 2014 From: fabiand at redhat.com (Fabian Deutsch) Date: Mon, 31 Mar 2014 14:34:19 +0200 Subject: [node-devel] Versioning of oVirt Node In-Reply-To: <213497143.4251932.1396267076154.JavaMail.zimbra@redhat.com> References: <1396006625.2943.43.camel@fdeutsch-laptop.local> <1611733432.4095464.1396169829479.JavaMail.zimbra@redhat.com> <1396251915.3043.24.camel@fdeutsch-laptop.local> <890404270.4200435.1396255959839.JavaMail.zimbra@redhat.com> <251541336.4394812.1396257659607.JavaMail.zimbra@redhat.com> <1089187843.4206459.1396258163862.JavaMail.zimbra@redhat.com> <149691885.4421293.1396261192577.JavaMail.zimbra@redhat.com> <1396264917.3043.56.camel@fdeutsch-laptop.local> <213497143.4251932.1396267076154.JavaMail.zimbra@redhat.com> Message-ID: <1396269259.14764.0.camel@fdeutsch-laptop.local> Am Montag, den 31.03.2014, 07:57 -0400 schrieb Alon Bar-Lev: > > > > > > I don't mind moving to our own tiny distro as long as it's a > single > > > image to release and maintain > > > > Well, Node _is_ actually a tiny distro, just based on some package > based > > on some existing one. > > I do not think that it is tiny distro... but let's not get into this > argument :) Hehe ;) > > > > > The effort of maintaining multiple ovirt-nodes based on distro and > > > distro-version and ovirt-version creates an unmanageable test > matrix > > > that all the community might loose from > > > > I partially agree here. > > From my POV the Fedora based Node is very useful for us to develop > Node, > > sooner or later the changes we've got in Fedora will land in CentOS, > > thus devleoping on Fedora is a preparation for being able to deliver > a > > (stable) CentOS based Node. > > > > So IMO we should continue to develop on Fedora, but we might want to > > consider to keep to only deliver the CentOS based Node. > > The Fedora based build could be seen as nightlies. > > If we consider single base distribution (aka blackbox which is not > black at all...), and you agree that centos is a fit, I do not see any > reason to invest resources in fedora. In the light of man power it makes sense to only support one Node - (as in delivering releases and providing support) which we currently do. From the development point of view, we should continue to develop features on Fedora. - fabian -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part URL: From alonbl at redhat.com Mon Mar 31 12:44:53 2014 From: alonbl at redhat.com (Alon Bar-Lev) Date: Mon, 31 Mar 2014 08:44:53 -0400 (EDT) Subject: [node-devel] Versioning of oVirt Node In-Reply-To: <1396269259.14764.0.camel@fdeutsch-laptop.local> References: <1396006625.2943.43.camel@fdeutsch-laptop.local> <890404270.4200435.1396255959839.JavaMail.zimbra@redhat.com> <251541336.4394812.1396257659607.JavaMail.zimbra@redhat.com> <1089187843.4206459.1396258163862.JavaMail.zimbra@redhat.com> <149691885.4421293.1396261192577.JavaMail.zimbra@redhat.com> <1396264917.3043.56.camel@fdeutsch-laptop.local> <213497143.4251932.1396267076154.JavaMail.zimbra@redhat.com> <1396269259.14764.0.camel@fdeutsch-laptop.local> Message-ID: <450507856.4263471.1396269893182.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Fabian Deutsch" > To: "Alon Bar-Lev" > Cc: "Barak Azulay" , arch at ovirt.org, "Douglas Landgraf" , "node-devel" > > Sent: Monday, March 31, 2014 3:34:19 PM > Subject: Re: [node-devel] Versioning of oVirt Node > > > Am Montag, den 31.03.2014, 07:57 -0400 schrieb Alon Bar-Lev: > > > > > > > > I don't mind moving to our own tiny distro as long as it's a > > single > > > > image to release and maintain > > > > > > Well, Node _is_ actually a tiny distro, just based on some package > > based > > > on some existing one. > > > > I do not think that it is tiny distro... but let's not get into this > > argument :) > > Hehe ;) > > > > > > > > The effort of maintaining multiple ovirt-nodes based on distro and > > > > distro-version and ovirt-version creates an unmanageable test > > matrix > > > > that all the community might loose from > > > > > > I partially agree here. > > > From my POV the Fedora based Node is very useful for us to develop > > Node, > > > sooner or later the changes we've got in Fedora will land in CentOS, > > > thus devleoping on Fedora is a preparation for being able to deliver > > a > > > (stable) CentOS based Node. > > > > > > So IMO we should continue to develop on Fedora, but we might want to > > > consider to keep to only deliver the CentOS based Node. > > > The Fedora based build could be seen as nightlies. > > > > If we consider single base distribution (aka blackbox which is not > > black at all...), and you agree that centos is a fit, I do not see any > > reason to invest resources in fedora. > > In the light of man power it makes sense to only support one Node - > (as in delivering releases and providing support) which we currently do. > > From the development point of view, we should continue to develop features on > Fedora. Why? if we release only centos, why do we need features for fedora? > > - fabian > From fabiand at redhat.com Mon Mar 31 12:49:25 2014 From: fabiand at redhat.com (Fabian Deutsch) Date: Mon, 31 Mar 2014 14:49:25 +0200 Subject: [node-devel] Versioning of oVirt Node In-Reply-To: <450507856.4263471.1396269893182.JavaMail.zimbra@redhat.com> References: <1396006625.2943.43.camel@fdeutsch-laptop.local> <890404270.4200435.1396255959839.JavaMail.zimbra@redhat.com> <251541336.4394812.1396257659607.JavaMail.zimbra@redhat.com> <1089187843.4206459.1396258163862.JavaMail.zimbra@redhat.com> <149691885.4421293.1396261192577.JavaMail.zimbra@redhat.com> <1396264917.3043.56.camel@fdeutsch-laptop.local> <213497143.4251932.1396267076154.JavaMail.zimbra@redhat.com> <1396269259.14764.0.camel@fdeutsch-laptop.local> <450507856.4263471.1396269893182.JavaMail.zimbra@redhat.com> Message-ID: <1396270165.18303.1.camel@fdeutsch-laptop.local> Am Montag, den 31.03.2014, 08:44 -0400 schrieb Alon Bar-Lev: > > ----- Original Message ----- > > From: "Fabian Deutsch" > > To: "Alon Bar-Lev" > > Cc: "Barak Azulay" , arch at ovirt.org, "Douglas Landgraf" , "node-devel" > > > > Sent: Monday, March 31, 2014 3:34:19 PM > > Subject: Re: [node-devel] Versioning of oVirt Node > > > > > > Am Montag, den 31.03.2014, 07:57 -0400 schrieb Alon Bar-Lev: > > > > > > > > > > I don't mind moving to our own tiny distro as long as it's a > > > single > > > > > image to release and maintain > > > > > > > > Well, Node _is_ actually a tiny distro, just based on some package > > > based > > > > on some existing one. > > > > > > I do not think that it is tiny distro... but let's not get into this > > > argument :) > > > > Hehe ;) > > > > > > > > > > > The effort of maintaining multiple ovirt-nodes based on distro and > > > > > distro-version and ovirt-version creates an unmanageable test > > > matrix > > > > > that all the community might loose from > > > > > > > > I partially agree here. > > > > From my POV the Fedora based Node is very useful for us to develop > > > Node, > > > > sooner or later the changes we've got in Fedora will land in CentOS, > > > > thus devleoping on Fedora is a preparation for being able to deliver > > > a > > > > (stable) CentOS based Node. > > > > > > > > So IMO we should continue to develop on Fedora, but we might want to > > > > consider to keep to only deliver the CentOS based Node. > > > > The Fedora based build could be seen as nightlies. > > > > > > If we consider single base distribution (aka blackbox which is not > > > black at all...), and you agree that centos is a fit, I do not see any > > > reason to invest resources in fedora. > > > > In the light of man power it makes sense to only support one Node - > > (as in delivering releases and providing support) which we currently do. > > > > From the development point of view, we should continue to develop features on > > Fedora. > > Why? if we release only centos, why do we need features for fedora? Mainly to prepare for major CentOS releases. Take CentOS 7 for example. We know that it is derived from Fedora 19 or so, thus adding Fedora 19 support, will also help us with CentOS 7. - fabian -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part URL: From alonbl at redhat.com Mon Mar 31 12:51:30 2014 From: alonbl at redhat.com (Alon Bar-Lev) Date: Mon, 31 Mar 2014 08:51:30 -0400 (EDT) Subject: [node-devel] Versioning of oVirt Node In-Reply-To: <1396270165.18303.1.camel@fdeutsch-laptop.local> References: <1396006625.2943.43.camel@fdeutsch-laptop.local> <1089187843.4206459.1396258163862.JavaMail.zimbra@redhat.com> <149691885.4421293.1396261192577.JavaMail.zimbra@redhat.com> <1396264917.3043.56.camel@fdeutsch-laptop.local> <213497143.4251932.1396267076154.JavaMail.zimbra@redhat.com> <1396269259.14764.0.camel@fdeutsch-laptop.local> <450507856.4263471.1396269893182.JavaMail.zimbra@redhat.com> <1396270165.18303.1.camel@fdeutsch-laptop.local> Message-ID: <122041605.4264915.1396270290850.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Fabian Deutsch" > To: "Alon Bar-Lev" > Cc: "Barak Azulay" , arch at ovirt.org, "Douglas Landgraf" , "node-devel" > > Sent: Monday, March 31, 2014 3:49:25 PM > Subject: Re: [node-devel] Versioning of oVirt Node > > Am Montag, den 31.03.2014, 08:44 -0400 schrieb Alon Bar-Lev: > > > > ----- Original Message ----- > > > From: "Fabian Deutsch" > > > To: "Alon Bar-Lev" > > > Cc: "Barak Azulay" , arch at ovirt.org, "Douglas > > > Landgraf" , "node-devel" > > > > > > Sent: Monday, March 31, 2014 3:34:19 PM > > > Subject: Re: [node-devel] Versioning of oVirt Node > > > > > > > > > Am Montag, den 31.03.2014, 07:57 -0400 schrieb Alon Bar-Lev: > > > > > > > > > > > > I don't mind moving to our own tiny distro as long as it's a > > > > single > > > > > > image to release and maintain > > > > > > > > > > Well, Node _is_ actually a tiny distro, just based on some package > > > > based > > > > > on some existing one. > > > > > > > > I do not think that it is tiny distro... but let's not get into this > > > > argument :) > > > > > > Hehe ;) > > > > > > > > > > > > > > The effort of maintaining multiple ovirt-nodes based on distro and > > > > > > distro-version and ovirt-version creates an unmanageable test > > > > matrix > > > > > > that all the community might loose from > > > > > > > > > > I partially agree here. > > > > > From my POV the Fedora based Node is very useful for us to develop > > > > Node, > > > > > sooner or later the changes we've got in Fedora will land in CentOS, > > > > > thus devleoping on Fedora is a preparation for being able to deliver > > > > a > > > > > (stable) CentOS based Node. > > > > > > > > > > So IMO we should continue to develop on Fedora, but we might want to > > > > > consider to keep to only deliver the CentOS based Node. > > > > > The Fedora based build could be seen as nightlies. > > > > > > > > If we consider single base distribution (aka blackbox which is not > > > > black at all...), and you agree that centos is a fit, I do not see any > > > > reason to invest resources in fedora. > > > > > > In the light of man power it makes sense to only support one Node - > > > (as in delivering releases and providing support) which we currently do. > > > > > > From the development point of view, we should continue to develop > > > features on > > > Fedora. > > > > Why? if we release only centos, why do we need features for fedora? > > Mainly to prepare for major CentOS releases. Take CentOS 7 for example. > > We know that it is derived from Fedora 19 or so, thus adding Fedora 19 > support, will also help us with CentOS 7. > And I thought it is black box :) The effort to support for centos 7 should start when centos 7 is out, till we stabilize keep using our "mini distribution" that is the previous, as per what barak/you claim should not be important to users. > - fabian >