From didi at redhat.com  Sun Mar  2 09:32:47 2014
From: didi at redhat.com (Yedidyah Bar David)
Date: Sun, 2 Mar 2014 04:32:47 -0500 (EST)
Subject: hosted-engine rebooting in the middle of setup (was: [vdsm] [Users]
	[ANN] oVirt 3.4.0 Release Candidate is now available)
In-Reply-To: <05A42C7A-7A44-405D-849C-BDCF233469AB@zenfire.com>
References: <5310B530.6090504@redhat.com>
	<05A42C7A-7A44-405D-849C-BDCF233469AB@zenfire.com>
Message-ID: <340077152.10472996.1393752767799.JavaMail.zimbra@redhat.com>

----- Original Message -----
> From: "Darrell Budic" <darrell.budic at zenfire.com>
> To: "Sandro Bonazzola" <sbonazzo at redhat.com>
> Cc: announce at ovirt.org, "engine-devel" <engine-devel at ovirt.org>, "arch" <arch at ovirt.org>, Users at ovirt.org, "VDSM
> Project Development" <vdsm-devel at lists.fedorahosted.org>
> Sent: Saturday, March 1, 2014 1:56:23 AM
> Subject: Re: [vdsm] [Users] [ANN] oVirt 3.4.0 Release Candidate is now	available
> 
> Started testing this on two self-hosted clusters, with mixed results. There
> were updates from 3.4.0 beta 3.
> 
> On both, got informed the system was going to reboot in 2 minutes while it
> was still installing yum updates.
> 
> On the faster system, the whole update process finished before the 2 minutes
> were up, the VM restarted, and all appears normal.
> 
> On the other, slower cluster, the 2 minutes hit while the yum updates were
> still being installed, and the system rebooted. It continued rebooting every
> 3 minutes or so, and the engine console web pages are not available because
> the engine doesn?t start. it did this at least 3 times before I went ahead
> and reran engine-setup, which completed successfully. The system stopped
> restarting and the web interface was available again. A quick perusal of
> system logs and engine-setup logs didn?t reveal what requested the reboot.
> 
> That was rather impolite of something to do that without warning :) At least
> it was recoverable. Seems like scheduling the reboot while the yum updates
> were still running seems like a poor idea as well.

Can you please post relevant logs?
hosts: /var/log/ovirt-hosted-engine-setup/*, /var/log/ovirt-hosted-engine-ha/*,
/var/log/vdsm/*
engine: /var/log/ovirt-engine/setup/*, /var/log/ovirt-engine/*

You can of course open a bug on bugzilla and attach there logs if you want.

Thanks, and thanks for the report!
-- 
Didi


From iheim at redhat.com  Sun Mar  2 20:55:57 2014
From: iheim at redhat.com (Itamar Heim)
Date: Sun, 02 Mar 2014 22:55:57 +0200
Subject: Discuss about GSoC 2014 Project: oVirt virtual disks advanced
	integration with libvirt
In-Reply-To: <CA+4q1bc-Q2ebLfo0Azy77c+Gaj43ws_YpJhTfL62XVTtGWVVQw@mail.gmail.com>
References: <CA+4q1bc-Q2ebLfo0Azy77c+Gaj43ws_YpJhTfL62XVTtGWVVQw@mail.gmail.com>
Message-ID: <53139ADD.10003@redhat.com>

On 02/28/2014 08:05 PM, Siddharth Jain wrote:
> Can I ask questions about the GSoC 2014 Project: oVirt virtual disks
> advanced integration with libvirt in this mailing list or am I in the
> wrong place?
>
> Regards,
> Siddharth Jain
> Fourth Year Undergraduate,
> BITS-Pilani Goa Campus, India
> Email: sid270592 at gmail.com <mailto:sid270592 at gmail.com>
>
>
> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch
>

right place. what's the question?


From sid270592 at gmail.com  Mon Mar  3 03:28:31 2014
From: sid270592 at gmail.com (Siddharth Jain)
Date: Mon, 3 Mar 2014 08:58:31 +0530
Subject: Fwd: Discuss about GSoC 2014 Project: oVirt virtual disks advanced
	integration with libvirt
In-Reply-To: <CA+4q1beOpLc48AFraTx+6v3U7svyfc7gyAia7jrMqJePsuAPSw@mail.gmail.com>
References: <CA+4q1bc-Q2ebLfo0Azy77c+Gaj43ws_YpJhTfL62XVTtGWVVQw@mail.gmail.com>
	<53139ADD.10003@redhat.com>
	<CA+4q1beOpLc48AFraTx+6v3U7svyfc7gyAia7jrMqJePsuAPSw@mail.gmail.com>
Message-ID: <CA+4q1bfj9RycTumH+tKf9dAGcj1wTBmfSDY4VK=bzEHgRq2UQQ@mail.gmail.com>

Hello,

I am Siddharth Jain, a 4th year undergraduate student at BITS-Pilani, India
and an extremely interested GSoC aspirant. I have gone through the project
list of various organizations but this particular project caught my special
attention - 'oVirt virtual disks advanced integration with libvirt'

I am very interested in working on this project as I am currently working
on a similar project as an intern at Dell Research and Development Center,
Bangalore, India and this could help me contribute better to oVirt. Here,
as part of the project, I have to deal with configuring various Virtual
Disk and Physical Disk capabilities of Dell PowerEdge Servers by
communicating with iDRAC(integrated Dell Remote Access Controller) using
the WSMAN Web Service. My work also involves automating features like
configuring Power Cap, adding hot spare to Virtual Disk, configuring RAID
and SNMP Trap Destinations.
I am using Python and C# to create the APIs for the job.

I have good experience working with Java on an open-source project but not
so much with libvirt/QEMU. Since I am very interested in working on this
project, can you advise me on how to proceed in the right direction and
provide me more details about the task so that I can understand the work
better?


Regards,

Siddharth Jain | +91 9741145051
Email: sid270592 at gmail.com,
Fourth Year Undergraduate,
BE(Hons) Computer Science,
BITS Pilani, India


On Mon, Mar 3, 2014 at 2:25 AM, Itamar Heim <iheim at redhat.com> wrote:

> On 02/28/2014 08:05 PM, Siddharth Jain wrote:
>
>> Can I ask questions about the GSoC 2014 Project: oVirt virtual disks
>> advanced integration with libvirt in this mailing list or am I in the
>> wrong place?
>>
>> Regards,
>> Siddharth Jain
>> Fourth Year Undergraduate,
>> BITS-Pilani Goa Campus, India
>> Email: sid270592 at gmail.com <mailto:sid270592 at gmail.com>
>>
>>
>> _______________________________________________
>> Arch mailing list
>> Arch at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/arch
>>
>>
> right place. what's the question?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/arch/attachments/20140303/bdce992d/attachment.html>

From sbonazzo at redhat.com  Mon Mar  3 14:25:41 2014
From: sbonazzo at redhat.com (Sandro Bonazzola)
Date: Mon, 03 Mar 2014 15:25:41 +0100
Subject: oVirt 3.4.0 branch creation
Message-ID: <531490E5.8060608@redhat.com>

Hi,
we're going to create ovirt-engine-3.4.0 branch tomorrow morning 09:00 UTC.
oVirt 3.4.1 development will continue on ovirt-engine-3.4 branch.
Critical fixes for oVirt 3.4.0 GA will need to be pushed to 3.4.0 branch too starting tomorrow morning 09:00 UTC.
Thanks,

-- 
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com


From liviu.elama at gmail.com  Sun Mar  2 20:35:56 2014
From: liviu.elama at gmail.com (Liviu Elama)
Date: Mon, 3 Mar 2014 09:35:56 +1300
Subject: [Users] hosted-engine rebooting in the middle of setup (was:
	[vdsm] [ANN] oVirt 3.4.0 Release Candidate is now available)
In-Reply-To: <340077152.10472996.1393752767799.JavaMail.zimbra@redhat.com>
References: <5310B530.6090504@redhat.com>
	<05A42C7A-7A44-405D-849C-BDCF233469AB@zenfire.com>
	<340077152.10472996.1393752767799.JavaMail.zimbra@redhat.com>
Message-ID: <CAPshyAtAjC+tdBBObbi5X6bayUSBuxm=fZ5pP1+L6r9QH7qq-Q@mail.gmail.com>

Sounds like your hosts were not in maintenance mode while you were
upgrading the engine which explains the 2 min reboot.

This should be revealed by logs

Regards
Liviu


On Sun, Mar 2, 2014 at 10:32 PM, Yedidyah Bar David <didi at redhat.com> wrote:

> ----- Original Message -----
> > From: "Darrell Budic" <darrell.budic at zenfire.com>
> > To: "Sandro Bonazzola" <sbonazzo at redhat.com>
> > Cc: announce at ovirt.org, "engine-devel" <engine-devel at ovirt.org>, "arch"
> <arch at ovirt.org>, Users at ovirt.org, "VDSM
> > Project Development" <vdsm-devel at lists.fedorahosted.org>
> > Sent: Saturday, March 1, 2014 1:56:23 AM
> > Subject: Re: [vdsm] [Users] [ANN] oVirt 3.4.0 Release Candidate is now
>      available
> >
> > Started testing this on two self-hosted clusters, with mixed results.
> There
> > were updates from 3.4.0 beta 3.
> >
> > On both, got informed the system was going to reboot in 2 minutes while
> it
> > was still installing yum updates.
> >
> > On the faster system, the whole update process finished before the 2
> minutes
> > were up, the VM restarted, and all appears normal.
> >
> > On the other, slower cluster, the 2 minutes hit while the yum updates
> were
> > still being installed, and the system rebooted. It continued rebooting
> every
> > 3 minutes or so, and the engine console web pages are not available
> because
> > the engine doesn't start. it did this at least 3 times before I went
> ahead
> > and reran engine-setup, which completed successfully. The system stopped
> > restarting and the web interface was available again. A quick perusal of
> > system logs and engine-setup logs didn't reveal what requested the
> reboot.
> >
> > That was rather impolite of something to do that without warning :) At
> least
> > it was recoverable. Seems like scheduling the reboot while the yum
> updates
> > were still running seems like a poor idea as well.
>
> Can you please post relevant logs?
> hosts: /var/log/ovirt-hosted-engine-setup/*,
> /var/log/ovirt-hosted-engine-ha/*,
> /var/log/vdsm/*
> engine: /var/log/ovirt-engine/setup/*, /var/log/ovirt-engine/*
>
> You can of course open a bug on bugzilla and attach there logs if you want.
>
> Thanks, and thanks for the report!
> --
> Didi
> _______________________________________________
> Users mailing list
> Users at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/arch/attachments/20140303/e43778aa/attachment.html>

From fsimonce at redhat.com  Mon Mar  3 23:27:39 2014
From: fsimonce at redhat.com (Federico Simoncelli)
Date: Mon, 3 Mar 2014 18:27:39 -0500 (EST)
Subject: Discuss about GSoC 2014 Project: oVirt virtual disks advanced
	integration with libvirt
In-Reply-To: <CA+4q1bfj9RycTumH+tKf9dAGcj1wTBmfSDY4VK=bzEHgRq2UQQ@mail.gmail.com>
References: <CA+4q1bc-Q2ebLfo0Azy77c+Gaj43ws_YpJhTfL62XVTtGWVVQw@mail.gmail.com>
	<53139ADD.10003@redhat.com>
	<CA+4q1beOpLc48AFraTx+6v3U7svyfc7gyAia7jrMqJePsuAPSw@mail.gmail.com>
	<CA+4q1bfj9RycTumH+tKf9dAGcj1wTBmfSDY4VK=bzEHgRq2UQQ@mail.gmail.com>
Message-ID: <1418363267.13348898.1393889259322.JavaMail.zimbra@redhat.com>

----- Original Message -----
> From: "Siddharth Jain" <sid270592 at gmail.com>
> To: fsimonce at redhat.com, arch at ovirt.org
> Sent: Monday, March 3, 2014 4:28:31 AM
> Subject: Fwd: Discuss about GSoC 2014 Project: oVirt virtual disks advanced integration with libvirt
> 
> Hello,
> 
> I am Siddharth Jain, a 4th year undergraduate student at BITS-Pilani, India
> and an extremely interested GSoC aspirant. I have gone through the project
> list of various organizations but this particular project caught my special
> attention - 'oVirt virtual disks advanced integration with libvirt'
> 
> I am very interested in working on this project as I am currently working
> on a similar project as an intern at Dell Research and Development Center,
> Bangalore, India and this could help me contribute better to oVirt. Here,
> as part of the project, I have to deal with configuring various Virtual
> Disk and Physical Disk capabilities of Dell PowerEdge Servers by
> communicating with iDRAC(integrated Dell Remote Access Controller) using
> the WSMAN Web Service. My work also involves automating features like
> configuring Power Cap, adding hot spare to Virtual Disk, configuring RAID
> and SNMP Trap Destinations.
> I am using Python and C# to create the APIs for the job.
> 
> I have good experience working with Java on an open-source project but not
> so much with libvirt/QEMU. Since I am very interested in working on this
> project, can you advise me on how to proceed in the right direction and
> provide me more details about the task so that I can understand the work
> better?

This GSoC Project is actually split in two parts:

- implement the support for the advanced disk capabilities (discard, eio,
  cache) in VDSM (python, libvirt)

- provide a way to configure the advanced disk capabilities in the UI
  per storage, virtual machine and disk (java, jboss + gwt)

The first part (python) should be easier (and faster) to implement.
Basically it would consist in coming up with the API changes (extension
probably) in order to pass the request for these new disk capabilities
when you start a virtual machine (or you hotplug a disk).
This will translate in a simple XML configuration that then it's fed to
libvirt (nothing more than that).

In order to tackle this you'll probably need to:

- install an host with fedora/centos
- use git to access VDSM code in our repository
- build VDSM (rpm build is mostly automated)
- install your own VDSM rpms
- install ovirt-engine/webadmin from the official repositories
- start using oVirt to instantiate VMs
- add the changes to the API used to start the VM

The scope of the second part is actually larger. We'll have to make
changes to the UI in order to let the user configure these capabilities
(e.g. a checkbox to enable discard, etc...) and save them in the
database.
Then when a request of starting a virtual machine is created it should
take in account these configurations to use the API we extended in the
previous point (VDSM).

In order to tackle this you'll probably need to:

- do everything stated in the previous list
- use git to access ovirt-engine code in our repository
- build ovirt-engine (jboss application + gwt)
- add the new capabilities to the UI (gwt)
- use the new capabilities when starting a VM

Let me know if you need more information.
-- 
Federico


From sid270592 at gmail.com  Tue Mar  4 04:00:27 2014
From: sid270592 at gmail.com (Siddharth Jain)
Date: Tue, 4 Mar 2014 09:30:27 +0530
Subject: Discuss about GSoC 2014 Project: oVirt virtual disks advanced
	integration with libvirt
In-Reply-To: <1418363267.13348898.1393889259322.JavaMail.zimbra@redhat.com>
References: <CA+4q1bc-Q2ebLfo0Azy77c+Gaj43ws_YpJhTfL62XVTtGWVVQw@mail.gmail.com>
	<53139ADD.10003@redhat.com>
	<CA+4q1beOpLc48AFraTx+6v3U7svyfc7gyAia7jrMqJePsuAPSw@mail.gmail.com>
	<CA+4q1bfj9RycTumH+tKf9dAGcj1wTBmfSDY4VK=bzEHgRq2UQQ@mail.gmail.com>
	<1418363267.13348898.1393889259322.JavaMail.zimbra@redhat.com>
Message-ID: <CA+4q1bdLdb28K_bhA6Wr16cwFtGX6zxn-k5DsuvZ+WDmmSiN2A@mail.gmail.com>

Thank You Federico for the detailed answer. That certainly clears up many
doubts.

However, I'd like to spend a few days learning more about oVirt,
familiarizing myself with the architecture, going through existing code in
the cloned repository, working with oVirt gerrit and going through the
documentation in detail. That'll help me speed things up later on and help
me start contributing sooner.
I'll let you know if I need more information.

I would really love to work on this project and I am confident I'll be able
to come up with something great. Please provide a few suggestions on coming
up with a strong GSoC proposal as I would like to focus all my energy on
this project starting now.

Regards,
Siddharth Jain
Fourth Year Undergraduate,
BITS-Pilani University, India
Email: sid270592 at gmail.com


On Tue, Mar 4, 2014 at 4:57 AM, Federico Simoncelli <fsimonce at redhat.com>wrote:

> ----- Original Message -----
> > From: "Siddharth Jain" <sid270592 at gmail.com>
> > To: fsimonce at redhat.com, arch at ovirt.org
> > Sent: Monday, March 3, 2014 4:28:31 AM
> > Subject: Fwd: Discuss about GSoC 2014 Project: oVirt virtual disks
> advanced integration with libvirt
> >
> > Hello,
> >
> > I am Siddharth Jain, a 4th year undergraduate student at BITS-Pilani,
> India
> > and an extremely interested GSoC aspirant. I have gone through the
> project
> > list of various organizations but this particular project caught my
> special
> > attention - 'oVirt virtual disks advanced integration with libvirt'
> >
> > I am very interested in working on this project as I am currently working
> > on a similar project as an intern at Dell Research and Development
> Center,
> > Bangalore, India and this could help me contribute better to oVirt. Here,
> > as part of the project, I have to deal with configuring various Virtual
> > Disk and Physical Disk capabilities of Dell PowerEdge Servers by
> > communicating with iDRAC(integrated Dell Remote Access Controller) using
> > the WSMAN Web Service. My work also involves automating features like
> > configuring Power Cap, adding hot spare to Virtual Disk, configuring RAID
> > and SNMP Trap Destinations.
> > I am using Python and C# to create the APIs for the job.
> >
> > I have good experience working with Java on an open-source project but
> not
> > so much with libvirt/QEMU. Since I am very interested in working on this
> > project, can you advise me on how to proceed in the right direction and
> > provide me more details about the task so that I can understand the work
> > better?
>
> This GSoC Project is actually split in two parts:
>
> - implement the support for the advanced disk capabilities (discard, eio,
>   cache) in VDSM (python, libvirt)
>
> - provide a way to configure the advanced disk capabilities in the UI
>   per storage, virtual machine and disk (java, jboss + gwt)
>
> The first part (python) should be easier (and faster) to implement.
> Basically it would consist in coming up with the API changes (extension
> probably) in order to pass the request for these new disk capabilities
> when you start a virtual machine (or you hotplug a disk).
> This will translate in a simple XML configuration that then it's fed to
> libvirt (nothing more than that).
>
> In order to tackle this you'll probably need to:
>
> - install an host with fedora/centos
> - use git to access VDSM code in our repository
> - build VDSM (rpm build is mostly automated)
> - install your own VDSM rpms
> - install ovirt-engine/webadmin from the official repositories
> - start using oVirt to instantiate VMs
> - add the changes to the API used to start the VM
>
> The scope of the second part is actually larger. We'll have to make
> changes to the UI in order to let the user configure these capabilities
> (e.g. a checkbox to enable discard, etc...) and save them in the
> database.
> Then when a request of starting a virtual machine is created it should
> take in account these configurations to use the API we extended in the
> previous point (VDSM).
>
> In order to tackle this you'll probably need to:
>
> - do everything stated in the previous list
> - use git to access ovirt-engine code in our repository
> - build ovirt-engine (jboss application + gwt)
> - add the new capabilities to the UI (gwt)
> - use the new capabilities when starting a VM
>
> Let me know if you need more information.
> --
> Federico
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/arch/attachments/20140304/36aa9dab/attachment.html>

From sbonazzo at redhat.com  Tue Mar  4 09:22:07 2014
From: sbonazzo at redhat.com (Sandro Bonazzola)
Date: Tue, 04 Mar 2014 10:22:07 +0100
Subject: oVrit 3.4.0 branch created
Message-ID: <53159B3F.3090403@redhat.com>

Hi,
as announced yesterday the new branch ovirt-engine-3.4.0 branch has been created from 3.4.
Branch commit was:
* 9ab9f01 - (origin/ovirt-engine-3.4) core: Remove error messages from log when adding host <lzelkha at redhat.com>

Only critical fixes will be accepted on ovirt-engine-3.4.0 branch.
Thanks,

-- 
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com


From sbonazzo at redhat.com  Tue Mar  4 13:02:36 2014
From: sbonazzo at redhat.com (Sandro Bonazzola)
Date: Tue, 04 Mar 2014 14:02:36 +0100
Subject: [ANN] oVirt 3.3.4 release
Message-ID: <5315CEEC.7020401@redhat.com>

The oVirt development team is pleased to announce the general
availability of oVirt 3.3.4 as of March 4th 2014. This release
solidifies oVirt as a leading KVM management application and open
source alternative to VMware vSphere.

oVirt is available now for Fedora 19 and Red Hat Enterprise Linux 6.5
(or similar).

This release of oVirt includes numerous bug fixes.
See the release notes [1] for a list of the new features and bugs fixed.

The existing repository ovirt-stable has been updated for delivering this
release without the need of enabling any other repository.

A new oVirt Node build is also available [2].

[1] http://www.ovirt.org/OVirt_3.3.4_release_notes
[2] http://resources.ovirt.org/releases/3.3.4/iso/ovirt-node-iso-3.0.4-1.0.201401291204.vdsm33.el6.iso

-- 
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com


From sbonazzo at redhat.com  Tue Mar  4 13:42:53 2014
From: sbonazzo at redhat.com (Sandro Bonazzola)
Date: Tue, 04 Mar 2014 14:42:53 +0100
Subject: [QE] oVirt 3.3.5 status
Message-ID: <5315D85D.5060305@redhat.com>

Hi,
  now that 3.3.4 has been released, it's time to look at 3.3.5.
Here is the tentative timeline:

    General availability: 2014-04-09
    RC Build: 2014-04-02

Nightly builds are available enabling the oVirt 3.3 snapshots repositories:

# yum-config-manager --enable ovirt-3.3-snapshot
# yum-config-manager --enable ovirt-3.3-snapshot-static


As you can see there won't be any beta release before RC for 3.3.z and the
same will be for 3.4.z.
Now we've nightly builds also for stable branches so you can test them
whenever you want to. If you're going to test it, please add yourself
as tester on [3]


Note to maintainers:
* For Release candidate builds, we'll send to all maintainers
a reminder the week before the build on Thursday morning (UTC timezone).
Packages that won't be ready before the announced compose time won't be
added to the release candidate.
Please remember to build your packages the day before repository
composition if you want it in.

* Release notes must be filled [1]

* A tracker bug has been created [2] and shows 1 bug blocking the release:
Whiteboard	Bug ID	Summary
virt		1071997	VM is not locked on run once

* Please add bugs to the tracker if you think that 3.3.5 should not be released without them fixed.

[1] http://www.ovirt.org/OVirt_3.3.5_release_notes
[2] http://bugzilla.redhat.com/1071867
[3] http://www.ovirt.org/Testing/oVirt_3.3.5_testing


Thanks,


-- 
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com


From sbonazzo at redhat.com  Tue Mar  4 14:25:30 2014
From: sbonazzo at redhat.com (Sandro Bonazzola)
Date: Tue, 04 Mar 2014 15:25:30 +0100
Subject: [QE] oVirt 3.4.0 status
Message-ID: <5315E25A.2040703@redhat.com>

Hi,
oVirt 3.4.0 RC has been released and is currently on QA.
While we're preparing for this week Test Day on 2014-03-06
a few blockers have been opened.

The bug tracker [1] shows the following bugs blocking the release:

Whiteboard	Bug ID	Status		Summary
infra		1070742	POST		[database] support postgres user length within schema version
infra		1071536	POST		Notifier doesn't send any notifications via email
integration	1067058	POST		[database] old psycopg2 does not accept unicode string as port name
integration	1069193	POST		Release maven artifacts with correct version numbers
integration	1072307	POST		remote database cannot be used
virt		1069201	ASSIGNED	[REST]: Missing domain field on VM\Template object.
virt		1071997	POST		VM is not locked on run once

All remaining bugs have been re-targeted to 3.4.1.

Maintainers / Assignee:
- Please remember to rebuild your packages before 2014-03-11 09:00 UTC if you want them to be included in 3.4.0 GA.
- Please add the bugs to the tracker if you think that 3.4.0 should not be released without them fixed.
- Please provide ETA on blockers bugs and fix them as soon as possible
- Please fill release notes, the page has been created here [2]
- Please update http://www.ovirt.org/OVirt_3.4_TestDay before 2014-02-19

Be prepared for upcoming oVirt 3.4.0 Test Day on 2014-03-06!

Thanks to all people already testing 3.4.0 RC!

[1] https://bugzilla.redhat.com/1024889
[2] http://www.ovirt.org/OVirt_3.4.0_release_notes

-- 
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com


From dfediuck at redhat.com  Fri Mar  7 06:29:37 2014
From: dfediuck at redhat.com (Doron Fediuck)
Date: Fri, 7 Mar 2014 01:29:37 -0500 (EST)
Subject: oVirt 3.4 RC test day results
In-Reply-To: <1913536241.22782038.1394173239070.JavaMail.zimbra@redhat.com>
Message-ID: <974958615.22787882.1394173777327.JavaMail.zimbra@redhat.com>

Hi all,
thanks for joining yesterday's RC test day!
The results are 48 new bugs, and critical ones should
be fixed for GA.

Feel free to send reports on your work yesterday to the users list.

Some additional stats-

Bugs, Top 5:
"bdagan at redhat.com"	2
"didi at redhat.com"	2
"hadong at redhat.com"	2
"lvernia at redhat.com"	2
"rhev-integ at redhat.com"	2
"pbenas at redhat.com"	3
"s.kieske at mittwald.de"	3
"istein at redhat.com"	4
"ydary at redhat.com"	6

Full list by reporter: http://goo.gl/tGzhDr

IRC top 10:

5	boberson
6	Mossel
7	FIBERIT
8	rgolan
9	ydary
14	sahina
21	jvandewege
24	evilissimo
27	fabiand
35	sbonazzo




From chuan.liao at hp.com  Mon Mar 10 09:17:13 2014
From: chuan.liao at hp.com (Liao, Chuan (Jason Liao, HPservers-Core-OE-PSC))
Date: Mon, 10 Mar 2014 09:17:13 +0000
Subject: Supposed to add per CPU usage related infomation into engine core
	and vdsm
Message-ID: <B63C858E777679458338A30A991BB524015C4A99@G2W2441.americas.hpqcorp.net>

Hi All,

In order to support NUMA and guest NUMA feature in ovirt.
We need per NUMA node CPU usage or per CPU usage related information on engine core.

This information will be used for VM who have NUMA aware information and find the best Host to run it on with best performance.

Approach 1:

1.      Sample data in vdsm for each CPU stats. (sys, usr, iowait, idle)

2.      Calculate the each CPU usage information. (%sys, %usr, %iowait, %idle)

3.      Transport the usage data to engine core.

4.      Engine core merge per NUMA node CPU usage. (%sys, %usr, %iowait, %idle)

Approach 2:

1.      Sample data in vdsm for each CPU stats. (sys, usr, iowait, idle)

2.      Calculate the each CPU usage information. (%sys, %usr, %iowait, %idle)

3.      VDSM merge per NUMA node CPU usage. (%sys, %usr, %iowait, %idle)

4.      Transport the usage data to engine core.

Which one do you prefer, and why, or other solution.

Best Regards,
Jason Liao

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/arch/attachments/20140310/50248a26/attachment.html>

From gchaplik at redhat.com  Mon Mar 10 11:36:20 2014
From: gchaplik at redhat.com (Gilad Chaplik)
Date: Mon, 10 Mar 2014 07:36:20 -0400 (EDT)
Subject: Supposed to add per CPU usage related infomation into engine
	core and vdsm
In-Reply-To: <B63C858E777679458338A30A991BB524015C4A99@G2W2441.americas.hpqcorp.net>
References: <B63C858E777679458338A30A991BB524015C4A99@G2W2441.americas.hpqcorp.net>
Message-ID: <888059896.16866790.1394451380205.JavaMail.zimbra@redhat.com>

----- Original Message -----
> From: "Chuan Liao (Jason Liao, HPservers-Core-OE-PSC)" <chuan.liao at hp.com>
> To: "arch" <arch at ovirt.org>, "vdsm-devel" <vdsm-devel at lists.fedorahosted.org>, engine-devel at ovirt.org
> Cc: "Gilad Chaplik" <gchaplik at redhat.com>, dfediuck at redhat.com, msivak at redhat.com
> Sent: Monday, March 10, 2014 11:17:13 AM
> Subject: Supposed to add per CPU usage related infomation into engine core and vdsm
> 
> Hi All,
> 
> In order to support NUMA and guest NUMA feature in ovirt.
> We need per NUMA node CPU usage or per CPU usage related information on
> engine core.
> 
> This information will be used for VM who have NUMA aware information and find
> the best Host to run it on with best performance.
> 
> Approach 1:
> 
> 1.      Sample data in vdsm for each CPU stats. (sys, usr, iowait, idle)
> 
> 2.      Calculate the each CPU usage information. (%sys, %usr, %iowait,
> %idle)
> 
> 3.      Transport the usage data to engine core.
> 
> 4.      Engine core merge per NUMA node CPU usage. (%sys, %usr, %iowait,
> %idle)
> 

+1, since this data can be used for hardware other than NUMA

> Approach 2:
> 
> 1.      Sample data in vdsm for each CPU stats. (sys, usr, iowait, idle)
> 
> 2.      Calculate the each CPU usage information. (%sys, %usr, %iowait,
> %idle)
> 
> 3.      VDSM merge per NUMA node CPU usage. (%sys, %usr, %iowait, %idle)
> 
> 4.      Transport the usage data to engine core.
> 
> Which one do you prefer, and why, or other solution.
> 
> Best Regards,
> Jason Liao
> 
> 


From emesika at redhat.com  Mon Mar 10 11:49:55 2014
From: emesika at redhat.com (Eli Mesika)
Date: Mon, 10 Mar 2014 07:49:55 -0400 (EDT)
Subject: [Engine-devel] Supposed to add per CPU usage related infomation
	into engine core and vdsm
In-Reply-To: <888059896.16866790.1394451380205.JavaMail.zimbra@redhat.com>
References: <B63C858E777679458338A30A991BB524015C4A99@G2W2441.americas.hpqcorp.net>
	<888059896.16866790.1394451380205.JavaMail.zimbra@redhat.com>
Message-ID: <867513868.15558046.1394452195743.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Gilad Chaplik" <gchaplik at redhat.com>
> To: "Chuan Liao (Jason Liao, HPservers-Core-OE-PSC)" <chuan.liao at hp.com>
> Cc: engine-devel at ovirt.org, "arch" <arch at ovirt.org>, "vdsm-devel" <vdsm-devel at lists.fedorahosted.org>
> Sent: Monday, March 10, 2014 1:36:20 PM
> Subject: Re: [Engine-devel] Supposed to add per CPU usage related infomation into engine core and vdsm
> 
> ----- Original Message -----
> > From: "Chuan Liao (Jason Liao, HPservers-Core-OE-PSC)" <chuan.liao at hp.com>
> > To: "arch" <arch at ovirt.org>, "vdsm-devel"
> > <vdsm-devel at lists.fedorahosted.org>, engine-devel at ovirt.org
> > Cc: "Gilad Chaplik" <gchaplik at redhat.com>, dfediuck at redhat.com,
> > msivak at redhat.com
> > Sent: Monday, March 10, 2014 11:17:13 AM
> > Subject: Supposed to add per CPU usage related infomation into engine core
> > and vdsm
> > 
> > Hi All,
> > 
> > In order to support NUMA and guest NUMA feature in ovirt.
> > We need per NUMA node CPU usage or per CPU usage related information on
> > engine core.
> > 
> > This information will be used for VM who have NUMA aware information and
> > find
> > the best Host to run it on with best performance.
> > 
> > Approach 1:
> > 
> > 1.      Sample data in vdsm for each CPU stats. (sys, usr, iowait, idle)
> > 
> > 2.      Calculate the each CPU usage information. (%sys, %usr, %iowait,
> > %idle)
> > 
> > 3.      Transport the usage data to engine core.
> > 
> > 4.      Engine core merge per NUMA node CPU usage. (%sys, %usr, %iowait,
> > %idle)
> > 
> 
> +1, since this data can be used for hardware other than NUMA

+1 , can be relevant to engine reports as well ....

> 
> > Approach 2:
> > 
> > 1.      Sample data in vdsm for each CPU stats. (sys, usr, iowait, idle)
> > 
> > 2.      Calculate the each CPU usage information. (%sys, %usr, %iowait,
> > %idle)
> > 
> > 3.      VDSM merge per NUMA node CPU usage. (%sys, %usr, %iowait, %idle)
> > 
> > 4.      Transport the usage data to engine core.
> > 
> > Which one do you prefer, and why, or other solution.
> > 
> > Best Regards,
> > Jason Liao
> > 
> > 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From sbonazzo at redhat.com  Tue Mar 11 16:17:03 2014
From: sbonazzo at redhat.com (Sandro Bonazzola)
Date: Tue, 11 Mar 2014 17:17:03 +0100
Subject: [ANN] oVirt 3.4.0 Second Release Candidate is now available
Message-ID: <531F36FF.6000600@redhat.com>

The oVirt team is pleased to announce that the 3.4.0 Second Release Candidate is now available for testing.

Release notes and information on the changes for this update are still being worked on and will be available soon on the wiki[1].
Please ensure to follow install instruction from release notes if you're going to test it.
The existing repository ovirt-3.4.0-prerelease has been updated for delivering this release candidate and future refreshes until final release.

An oVirt Node iso will also be available soon.

We decided to postpone Final Release by one week in order to properly test the bugs fixed since last Release Candidate.
Help us make this the best release ever, testing it yourself!

[1] http://www.ovirt.org/OVirt_3.4.0_release_notes

-- 
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com


From bproffit at redhat.com  Tue Mar 11 19:20:51 2014
From: bproffit at redhat.com (Brian Proffitt)
Date: Tue, 11 Mar 2014 15:20:51 -0400 (EDT)
Subject: [Events] Call for Papers Update: March 11, 2014
In-Reply-To: <1780845410.12758568.1394565313856.JavaMail.zimbra@redhat.com>
Message-ID: <1267610602.12759773.1394565651911.JavaMail.zimbra@redhat.com>

The following is a list of industry events that oVirt community members may want to attend and give presentations. If you are interested in speaking, or if you know of other events not on this list, please contact me at bkp at redhat.com.

---

LinuxCon/CloudOpen Japan	
May 20-22
Tokyo, Japan
http://events.linuxfoundation.org/events/linuxcon-japan
Call for papers deadline: 3/14/2014
Call for papers URL: http://events.linuxfoundation.org/events/linuxcon-japan/program/cfp

LISA
Nov. 9-14
Seattle, WA
https://www.usenix.org/conference/lisa14
Call for papers deadline: 4/14/2014
Call for papers URL: https://www.usenix.org/conference/lisa14/call-for-participation

DockerConf
June 6
London, UK
http://dockerconf.com/
Call for papers: Open (deadline not known)
Call for papers URL: http://bit.ly/1fnHtSA

LinuxCon/CloudOpen NA
Aug. 20-22
Chicago, IL
http://events.linuxfoundation.org/events/linuxcon-north-america
Call for papers deadline: 5/2/2014
Call for papers URL: http://events.linuxfoundation.org/events/linuxcon-north-america/program/cfp

LinuxCon/CloudOpen Europe
Oct. 13-15
http://events.linuxfoundation.org/events/cloudopen-europe
Dusseldorf, Germany
Call for papers deadline: 7/11/2014
Call for papers URL: http://events.linuxfoundation.org/events/cloudopen-europe/program/cfp

KVM Forum
Oct. 14-16
Dusseldorf, Germany
http://events.linuxfoundation.org/events/kvm-forum
Call for papers: Not Open

Linux.conf.au
Jan. 12-16, 2015
Auckland, NZ
Call for papers: Not Open

-- 
Brian Proffitt - oVirt Community Manager
Open Source and Standards, Red Hat - http://community.redhat.com
Phone: +1 312 477 4320 / Cell: +1 574 383 9BKP
IRC: bkp @ OFTC


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: [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: <http://lists.ovirt.org/pipermail/arch/attachments/20140314/40e6b583/attachment.sig>

From bproffit at redhat.com  Mon Mar 17 13:46:48 2014
From: bproffit at redhat.com (Brian Proffitt)
Date: Mon, 17 Mar 2014 09:46:48 -0400 (EDT)
Subject: Industry Events: Call for Papers Update, March 17, 2014
In-Reply-To: <1668349122.296386.1395063578479.JavaMail.zimbra@redhat.com>
Message-ID: <501864454.300473.1395064008135.JavaMail.zimbra@redhat.com>

The following is a list of industry events that oVirt community members may want to attend and give presentations. If you are interested in speaking, or if you know of other events not on this list, please contact me at bkp at redhat.com.

---

Open Source Bridge
Jun 24-27
Portland, OR
http://opensourcebridge.org/
Call for papers deadline: 4/4/2014
Call for papers URL: http://opensourcebridge.org/events/2014/proposals

LISA
Nov. 9-14
Seattle, WA
https://www.usenix.org/conference/lisa14
Call for papers deadline: 4/14/2014
Call for papers URL: https://www.usenix.org/conference/lisa14/call-for-participation

DockerConf
June 6
London, UK
http://dockerconf.com/
Call for papers: Open (deadline not known)
Call for papers URL: http://bit.ly/1fnHtSA

LinuxCon/CloudOpen NA
Aug. 20-22
Chicago, IL
http://events.linuxfoundation.org/events/linuxcon-north-america
Call for papers deadline: 5/2/2014
Call for papers URL: http://events.linuxfoundation.org/events/linuxcon-north-america/program/cfp

LinuxCon/CloudOpen Europe
Oct. 13-15
http://events.linuxfoundation.org/events/cloudopen-europe
Dusseldorf, Germany
Call for papers deadline: 7/11/2014
Call for papers URL: http://events.linuxfoundation.org/events/cloudopen-europe/program/cfp

KVM Forum
Oct. 14-16
Dusseldorf, Germany
http://events.linuxfoundation.org/events/kvm-forum
Call for papers: Not Open

Linux.conf.au
Jan. 12-16, 2015
Auckland, NZ
Call for papers: Not Open

-- 
Brian Proffitt - oVirt Community Manager
Open Source and Standards, Red Hat - http://community.redhat.com
Phone: +1 312 477 4320 / Cell: +1 574 383 9BKP
IRC: bkp


From dfediuck at redhat.com  Wed Mar 19 15:52:29 2014
From: dfediuck at redhat.com (Doron Fediuck)
Date: Wed, 19 Mar 2014 11:52:29 -0400 (EDT)
Subject: [ANN] oVirt 3.4.0 GA postponed to Monday, March 24
In-Reply-To: <531F36FF.6000600@redhat.com>
Message-ID: <1251687102.2186519.1395244349609.JavaMail.zimbra@redhat.com>

Hi,
due to 2 blocker bugs we found, the GA is pushed to Monday, March 24.

This should provide sufficient time for us to properly fix and test
oVirt 3.4, in order to make sure we have no critical issues in the
3.4.0 version we're all waiting for.

Thanks for understanding,
Doron


From dcaroest at redhat.com  Fri Mar 21 09:59:34 2014
From: dcaroest at redhat.com (David Caro)
Date: Fri, 21 Mar 2014 10:59:34 +0100
Subject: New git repository for maven-modules-plugin
In-Reply-To: <505798165.4593639.1393333530981.JavaMail.zimbra@redhat.com>
References: <53076750.8050909@redhat.com> <530C92F3.8020102@redhat.com>
	<505798165.4593639.1393333530981.JavaMail.zimbra@redhat.com>
Message-ID: <532C0D86.3080303@redhat.com>

On Tue 25 Feb 2014 02:05:30 PM CET, Alon Bar-Lev wrote:
>
>
> ----- Original Message -----
>> From: "Itamar Heim" <iheim at redhat.com>
>> To: "Juan Hernandez" <jhernand at redhat.com>, "arch" <arch at ovirt.org>, "infra" <infra at ovirt.org>, "David Caro Estevez"
>> <dcaroest at redhat.com>
>> Sent: Tuesday, February 25, 2014 2:56:19 PM
>> Subject: Re: New git repository for maven-modules-plugin
>>
>> On 02/21/2014 04:48 PM, Juan Hernandez wrote:
>>> Hello,
>>>
>>> I would like to request a new git repository named maven-modules-plugin
>>> to manage the source of a little tool that we use for the build process
>>> of the engine.
>>>
>>> Currently the source of this tool is inside the ovirt-engine repository,
>>> but I want to start distributing it via maven central, in order to build
>>> other projects. This is much simpler if the source is in it's own
>>> repository and has its own release cycle.
>>>
>>> What I would like to have in that repository is the same that I
>>> currently have here:
>>>
>>> https://github.com/jhernand/modules-maven-plugin
>>>
>>> Once the code is moved to this new repository, and distributed via Maven
>>> Central, the build process of the engine can be updated accordingly with
>>> the following patch:
>>>
>>> http://gerrit.ovirt.org/24866
>>>
>>> Thanks in advance,
>>> Juan Hernandez
>>>
>>
>> I see no other comment on this.
>> none of the other repo's used to manage our infra/build is a match
>> currently?
>
> If we fork this out, we need it packaged for fedora as well, and other distros as we go.
>
> So it requires own repository.
>
> If it is ovirt specific, I would like to see ovirt within the name... but not critical.
>
> Regards,
> Alon

Is this still required?

--
David Caro

Red Hat S.L.
Continuous Integration Engineer - EMEA ENG Virtualization R&D

Email: dcaro at redhat.com
Web: www.redhat.com
RHT Global #: 82-62605

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.ovirt.org/pipermail/arch/attachments/20140321/56ebbb36/attachment.sig>

From jhernand at redhat.com  Fri Mar 21 10:00:27 2014
From: jhernand at redhat.com (Juan Hernandez)
Date: Fri, 21 Mar 2014 11:00:27 +0100
Subject: New git repository for maven-modules-plugin
In-Reply-To: <532C0D86.3080303@redhat.com>
References: <53076750.8050909@redhat.com> <530C92F3.8020102@redhat.com>
	<505798165.4593639.1393333530981.JavaMail.zimbra@redhat.com>
	<532C0D86.3080303@redhat.com>
Message-ID: <532C0DBB.3080200@redhat.com>

On 03/21/2014 10:59 AM, David Caro wrote:
> On Tue 25 Feb 2014 02:05:30 PM CET, Alon Bar-Lev wrote:
>> 
>> 
>> ----- Original Message -----
>>> From: "Itamar Heim" <iheim at redhat.com> To: "Juan Hernandez"
>>> <jhernand at redhat.com>, "arch" <arch at ovirt.org>, "infra"
>>> <infra at ovirt.org>, "David Caro Estevez" <dcaroest at redhat.com> 
>>> Sent: Tuesday, February 25, 2014 2:56:19 PM Subject: Re: New
>>> git repository for maven-modules-plugin
>>> 
>>> On 02/21/2014 04:48 PM, Juan Hernandez wrote:
>>>> Hello,
>>>> 
>>>> I would like to request a new git repository named
>>>> maven-modules-plugin to manage the source of a little tool
>>>> that we use for the build process of the engine.
>>>> 
>>>> Currently the source of this tool is inside the ovirt-engine
>>>> repository, but I want to start distributing it via maven
>>>> central, in order to build other projects. This is much
>>>> simpler if the source is in it's own repository and has its
>>>> own release cycle.
>>>> 
>>>> What I would like to have in that repository is the same that
>>>> I currently have here:
>>>> 
>>>> https://github.com/jhernand/modules-maven-plugin
>>>> 
>>>> Once the code is moved to this new repository, and
>>>> distributed via Maven Central, the build process of the
>>>> engine can be updated accordingly with the following patch:
>>>> 
>>>> http://gerrit.ovirt.org/24866
>>>> 
>>>> Thanks in advance, Juan Hernandez
>>>> 
>>> 
>>> I see no other comment on this. none of the other repo's used
>>> to manage our infra/build is a match currently?
>> 
>> If we fork this out, we need it packaged for fedora as well, and
>> other distros as we go.
>> 
>> So it requires own repository.
>> 
>> If it is ovirt specific, I would like to see ovirt within the
>> name... but not critical.
>> 
>> Regards, Alon
> 
> Is this still required?
> 

No, it isn't required. Thanks David.

-- 
Direcci?n Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta
3?D, 28016 Madrid, Spain
Inscrita en el Reg. Mercantil de Madrid ? C.I.F. B82657941 - Red Hat S.L.


From dcaroest at redhat.com  Fri Mar 21 11:18:28 2014
From: dcaroest at redhat.com (David Caro)
Date: Fri, 21 Mar 2014 12:18:28 +0100
Subject: Update-tracker hook
Message-ID: <532C2004.3000403@redhat.com>

Hi everyone,

I've enabled the update-tracker hook on all the ovirt gerrit projects, except:

infra*
jenkins*
test*
samples*
gerrit-admin

So you will start seeing the trackers being created on the linked bugs (Bug-Url:
in the commit message).

I've added also the branch information to be shown in the bugzilla external
priority field, in the lack of a better one.

If you see any errors or have any issues please send me an email or ping me
directly.

To update the patches that you have already sent, you can just add a new gerrit
comment with the text:
"""
Rerun-Hooks: all
"""

And it will trigger the hooks again (not the jenkins jobs though).

Enjoy!

-- 
David Caro

Red Hat S.L.
Continuous Integration Engineer - EMEA ENG Virtualization R&D

Email: dcaro at redhat.com
Web: www.redhat.com
RHT Global #: 82-62605

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.ovirt.org/pipermail/arch/attachments/20140321/6a9903ea/attachment.sig>

From chuan.liao at hp.com  Tue Mar 25 07:43:05 2014
From: chuan.liao at hp.com (Liao, Chuan (Jason Liao, HPservers-Core-OE-PSC))
Date: Tue, 25 Mar 2014 07:43:05 +0000
Subject: Help to review the design of NUMA feature for oVirt
Message-ID: <B63C858E777679458338A30A991BB524015ED524@G1W3780.americas.hpqcorp.net>

Hi All,

Please help us to review the design of NUMA feature for oVirt,

Here are two design on wiki page
General Feature Design
http://www.ovirt.org/Features/NUMA_and_Virtual_NUMA

Detailed Design
http://www.ovirt.org/Features/Detailed_NUMA_and_Virtual_NUMA

Please feel free to have any comments, and we will reply as quickly as we could.


And we are in a tight schedule - we want it in to ovirt 3.5 release

Best Regards,
Jason Liao

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/arch/attachments/20140325/85a6a12c/attachment.html>

From mburns at redhat.com  Wed Mar 26 14:16:44 2014
From: mburns at redhat.com (Mike Burns)
Date: Wed, 26 Mar 2014 10:16:44 -0400 (EDT)
Subject: oVirt Weekly Meeting
Message-ID: <398891958.963337.1395843404035.JavaMail.zimbra@redhat.com>

The following meeting has been modified:

Subject: oVirt Weekly Meeting 
Organizer: "Mike Burns" <mburns at redhat.com> 

Location: #ovirt of oftc.net 
Time: 10:00:00 AM - 11:00:00 AM GMT -05:00 US/Canada Eastern [MODIFIED]
 Recurrence : Every 1 week(s) on  End by Mar 25, 2014 Effective Apr 25, 2012

Required: danken at redhat.com; oschreib at redhat.com; ykaul at redhat.com; sgordon at redhat.com; dfediuck at redhat.com; Jon.Benedict at netapp.com; pmyers at redhat.com; simon at redhat.com; imad.sousou at intel.com; aliguori at us.ibm.com; lhawthor at redhat.com ... 
Optional: arch at ovirt.org; board at ovirt.org; menescu at cisco.com 

*~*~*~*~*~*~*~*~*~*

Cancelling this and Doron will setup a new reminder.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/arch/attachments/20140326/3a747a3d/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: meeting.ics
Type: text/calendar
Size: 4033 bytes
Desc: not available
URL: <http://lists.ovirt.org/pipermail/arch/attachments/20140326/3a747a3d/attachment.ics>

From bproffit at redhat.com  Wed Mar 26 18:39:51 2014
From: bproffit at redhat.com (Brian Proffitt)
Date: Wed, 26 Mar 2014 14:39:51 -0400 (EDT)
Subject: Attention: Mailing List Change
In-Reply-To: <1787230321.4093240.1395858027310.JavaMail.zimbra@redhat.com>
Message-ID: <432909486.4099248.1395859191777.JavaMail.zimbra@redhat.com>

All:

One of the long-standing requests in the oVirt community is the merging of the [arch] and [engine-devel] mailing lists. This note is an announcement that on Monday, March 31, this will get done.

What will happen:

1) Subscribers from [arch] and [engine-devel] will be migrated to a new [devel] list.
2) Archives from [arch] (this list) will be left as is, and available for searching on the list.ovirt.org/mailman site.
3) Archived from [engine-devel] will be renamed to [devel]

If you have any comments or concerns, let me know.

Thank you for your patience in this matter,
Brian

-- 
Brian Proffitt - oVirt Community Manager
Open Source and Standards, Red Hat - http://community.redhat.com
Phone: +1 574 383 9BKP
IRC: bkp @ OFTC


From lpeer at redhat.com  Thu Mar 27 08:32:07 2014
From: lpeer at redhat.com (Livnat Peer)
Date: Thu, 27 Mar 2014 10:32:07 +0200
Subject: Attention: Mailing List Change
In-Reply-To: <432909486.4099248.1395859191777.JavaMail.zimbra@redhat.com>
References: <432909486.4099248.1395859191777.JavaMail.zimbra@redhat.com>
Message-ID: <5333E207.3000800@redhat.com>

On 03/26/2014 08:39 PM, Brian Proffitt wrote:
> All:
> 
> One of the long-standing requests in the oVirt community is the merging of the [arch] and [engine-devel] mailing lists. This note is an announcement that on Monday, March 31, this will get done.
> 
> What will happen:
> 
> 1) Subscribers from [arch] and [engine-devel] will be migrated to a new [devel] list.
> 2) Archives from [arch] (this list) will be left as is, and available for searching on the list.ovirt.org/mailman site.
> 3) Archived from [engine-devel] will be renamed to [devel]
> 
> If you have any comments or concerns, let me know.
> 
> Thank you for your patience in this matter,
> Brian
> 

First of all +1 for doing that.

Can we include VDSM as well in a single ovirt-devel list? There is no
reason to track two different lists. which is a concern we've discussed
in the past...


From eedri at redhat.com  Thu Mar 27 08:49:02 2014
From: eedri at redhat.com (Eyal Edri)
Date: Thu, 27 Mar 2014 04:49:02 -0400 (EDT)
Subject: Attention: Mailing List Change
In-Reply-To: <5333E207.3000800@redhat.com>
References: <432909486.4099248.1395859191777.JavaMail.zimbra@redhat.com>
	<5333E207.3000800@redhat.com>
Message-ID: <1101623691.1370597.1395910142465.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Livnat Peer" <lpeer at redhat.com>
> To: "Brian Proffitt" <bproffit at redhat.com>, "arch" <arch at ovirt.org>
> Sent: Thursday, March 27, 2014 10:32:07 AM
> Subject: Re: Attention: Mailing List Change
> 
> On 03/26/2014 08:39 PM, Brian Proffitt wrote:
> > All:
> > 
> > One of the long-standing requests in the oVirt community is the merging of
> > the [arch] and [engine-devel] mailing lists. This note is an announcement
> > that on Monday, March 31, this will get done.
> > 
> > What will happen:
> > 
> > 1) Subscribers from [arch] and [engine-devel] will be migrated to a new
> > [devel] list.
> > 2) Archives from [arch] (this list) will be left as is, and available for
> > searching on the list.ovirt.org/mailman site.
> > 3) Archived from [engine-devel] will be renamed to [devel]
> > 
> > If you have any comments or concerns, let me know.
> > 
> > Thank you for your patience in this matter,
> > Brian
> > 
> 
> First of all +1 for doing that.
> 
> Can we include VDSM as well in a single ovirt-devel list? There is no
> reason to track two different lists. which is a concern we've discussed
> in the past...

+1

> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch
> 


From danken at redhat.com  Thu Mar 27 09:32:35 2014
From: danken at redhat.com (Dan Kenigsberg)
Date: Thu, 27 Mar 2014 09:32:35 +0000
Subject: Attention: Mailing List Change
In-Reply-To: <5333E207.3000800@redhat.com>
References: <432909486.4099248.1395859191777.JavaMail.zimbra@redhat.com>
	<5333E207.3000800@redhat.com>
Message-ID: <20140327093235.GJ27429@redhat.com>

On Thu, Mar 27, 2014 at 10:32:07AM +0200, Livnat Peer wrote:
> On 03/26/2014 08:39 PM, Brian Proffitt wrote:
> > All:
> > 
> > One of the long-standing requests in the oVirt community is the merging of the [arch] and [engine-devel] mailing lists. This note is an announcement that on Monday, March 31, this will get done.
> > 
> > What will happen:
> > 
> > 1) Subscribers from [arch] and [engine-devel] will be migrated to a new [devel] list.
> > 2) Archives from [arch] (this list) will be left as is, and available for searching on the list.ovirt.org/mailman site.
> > 3) Archived from [engine-devel] will be renamed to [devel]
> > 
> > If you have any comments or concerns, let me know.
> > 
> > Thank you for your patience in this matter,
> > Brian
> > 
> 
> First of all +1 for doing that.
> 
> Can we include VDSM as well in a single ovirt-devel list? There is no
> reason to track two different lists. which is a concern we've discussed
> in the past...

I prefer keeping vdsm-devel intact. It's a different programming
language, with its different set of problems, unrelated profiling
issues, and somewhat different target audience.


From lpeer at redhat.com  Thu Mar 27 09:50:55 2014
From: lpeer at redhat.com (Livnat Peer)
Date: Thu, 27 Mar 2014 11:50:55 +0200
Subject: Attention: Mailing List Change
In-Reply-To: <20140327093235.GJ27429@redhat.com>
References: <432909486.4099248.1395859191777.JavaMail.zimbra@redhat.com>
	<5333E207.3000800@redhat.com> <20140327093235.GJ27429@redhat.com>
Message-ID: <5333F47F.2030003@redhat.com>

On 03/27/2014 11:32 AM, Dan Kenigsberg wrote:
> On Thu, Mar 27, 2014 at 10:32:07AM +0200, Livnat Peer wrote:
>> On 03/26/2014 08:39 PM, Brian Proffitt wrote:
>>> All:
>>>
>>> One of the long-standing requests in the oVirt community is the merging of the [arch] and [engine-devel] mailing lists. This note is an announcement that on Monday, March 31, this will get done.
>>>
>>> What will happen:
>>>
>>> 1) Subscribers from [arch] and [engine-devel] will be migrated to a new [devel] list.
>>> 2) Archives from [arch] (this list) will be left as is, and available for searching on the list.ovirt.org/mailman site.
>>> 3) Archived from [engine-devel] will be renamed to [devel]
>>>
>>> If you have any comments or concerns, let me know.
>>>
>>> Thank you for your patience in this matter,
>>> Brian
>>>
>>
>> First of all +1 for doing that.
>>
>> Can we include VDSM as well in a single ovirt-devel list? There is no
>> reason to track two different lists. which is a concern we've discussed
>> in the past...
> 
> I prefer keeping vdsm-devel intact. It's a different programming
> language, with its different set of problems, unrelated profiling
> issues, and somewhat different target audience.
> 

We can use the message subject to differentiate between VDSM specific
correspondence to Engine etc.

Having a unified mailing list would expose VDSM to other people which do
not track VDSM list today and would increase VDSM visibility.

In addition most of the features are cross component and tracking it in
two different lists is not working - at least not for me.

Livnat


From amedeo at oscert.net  Thu Mar 27 10:56:55 2014
From: amedeo at oscert.net (Amedeo Salvati)
Date: Thu, 27 Mar 2014 11:56:55 +0100
Subject: [Users] [Ann] oVirt 3.4 GA Releases
In-Reply-To: <920387293.4456633.1395913941056.JavaMail.zimbra@redhat.com>
References: <920387293.4456633.1395913941056.JavaMail.zimbra@redhat.com>
Message-ID: <N33D2V$372C316984AB9E756677B082475D5F7B@oscert.net>

+1

I'll try soon and migrate our 3.3.x to 3.4!

best regards
a


Da: announce-bounces at ovirt.org
A: "users" users at ovirt.org, announce at ovirt.org
Cc: 
Data: Thu, 27 Mar 2014 05:52:21 -0400 (EDT)
Oggetto: [Users] [Ann] oVirt 3.4 GA Releases


> The oVirt Project is pleased to announce the general availability of its fifth formal release, oVirt 3.4, as of March 27, 2014.
> 
> oVirt is an open source alternative to VMware vSphere, and provides an excellent KVM management interface for multi-node virtualization. oVirt is available now for Fedora 19, Red Hat Enterprise Linux 6.5, and CentOS 6.5 (or similar).
> 
> New features include:
> 
> oVirt 3.4 Release Notes
> 
> * Hosted Engine: oVirt 3.4 features hosted engine, which enables oVirt engine to be run as a virtual machine (VM) on the host it manages. Hosted engine solves the chicken-and-the egg problem for users: the basic challenge of deploying and running an oVirt engine inside a VM. This clustered solution enables users to configure multiple hosts to run the hosted engine, ensuring the engine still runs in the event of any one host failure.
> 
> * Enhanced Gluster Support: Gluster Volume Asynchronous Tasks Management enables users to re-balance volumes and remove bricks in Gluster operations/rebalance and remove bricks in Gluster volumes.
> 
> * Preview: PPC64: Engine Support for PPC64 will add PPC64 architecture awareness to the ovirt-engine code, which currently makes various assumptions based on the x86 architecture. When specifying virtual machine devices, for example, what is suitable for x86 architecture may not be for POWER (or may not be available yet). VDSM Support for PPC64 introduces the capability of managing KVM on IBM POWER processors via oVirt. Administrators will be able to perform management functionalities such as adding or activating KVM, creating clusters of KVM and performing VM lifecycle management on any IBM POWER host. Migration is still a work in progress for KVM on IBM POWER processor.
> 
> * Preview: Hot-plug CPUs: oVirt 3.4 adds a preview of a Hot-plug CPU feature that enables administrators to ensure customer's service-level agreements are being met, the full utilization of spare hardware, and the capability to dynamically to scale vertically, down or up, a system's hardware according to application needs without restarting the virtual machine.
> 
> This release of oVirt also includes numerous bug fixes. See the release notes [1] for a complete list of the new features and bugs fixed.
> 
> The existing repository ovirt-stable has been updated for delivering this release without the need of enabling any other repository.
> 
> A new oVirt Node build is also available [2].
> 
> [1] http://www.ovirt.org/OVirt_3.4_Release_Notes
> [2] http://resources.ovirt.org/releases/3.4/iso/ovirt-node-iso-3.0.4-1.0.201401291204.vdsm34.el6.iso
> 
> -- 
> Brian Proffitt - oVirt Community Manager
> IRC: bkp @ #ovirt OFTC
> _______________________________________________
> Announce mailing list
> Announce at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/announce
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/arch/attachments/20140327/64fef05a/attachment.html>

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: 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-<node-version>-<number>.<number>.<build-date>.\
  vdsm<ovirt-target-version>.<dist>.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-<ovirt-target-version>-<build-date>.<number>.<dist>.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-<ovirt-target-version>-<build-date>.<number>.<dist>.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: <http://lists.ovirt.org/pipermail/arch/attachments/20140328/69717eec/attachment.sig>

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-<ovirt-node-version>-<build-date>.<number>.<dist>.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: <http://lists.ovirt.org/pipermail/arch/attachments/20140328/4befa2e5/attachment.sig>

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" <fabiand at redhat.com>
> To: arch at ovirt.org
> Cc: "Douglas Landgraf" <dlandgra at redhat.com>, "node-devel" <node-devel at ovirt.org>
> 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-<ovirt-node-version>-<build-date>.<number>.<dist>.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" <fabiand at redhat.com>
> To: arch at ovirt.org, "node-devel" <node-devel at ovirt.org>
> Cc: "Douglas Landgraf" <dlandgra at redhat.com>
> 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-<node-version>-<number>.<number>.<build-date>.\
>   vdsm<ovirt-target-version>.<dist>.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-<ovirt-target-version>-<build-date>.<number>.<dist>.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-<ovirt-target-version>-<build-date>.<number>.<dist>.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" <fabiand at redhat.com>
> To: arch at ovirt.org, "node-devel" <node-devel at ovirt.org>
> Cc: "Douglas Landgraf" <dlandgra at redhat.com>
> 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-<node-version>-<number>.<number>.<build-date>.\
>   vdsm<ovirt-target-version>.<dist>.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-<ovirt-target-version>-<build-date>.<number>.<dist>.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-<ovirt-target-version>-<build-date>.<number>.<dist>.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" <alonbl at redhat.com>
> To: "Fabian Deutsch" <fabiand at redhat.com>
> Cc: arch at ovirt.org, "Douglas Landgraf" <dlandgra at redhat.com>, "node-devel" <node-devel at ovirt.org>
> Sent: Sunday, March 30, 2014 11:57:09 AM
> Subject: Re: [node-devel] Versioning of oVirt Node
> 
> 
> 
> ----- Original Message -----
> > From: "Fabian Deutsch" <fabiand at redhat.com>
> > To: arch at ovirt.org, "node-devel" <node-devel at ovirt.org>
> > Cc: "Douglas Landgraf" <dlandgra at redhat.com>
> > 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-<node-version>-<number>.<number>.<build-date>.\
> >   vdsm<ovirt-target-version>.<dist>.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-<ovirt-target-version>-<build-date>.<number>.<dist>.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-<ovirt-target-version>-<build-date>.<number>.<dist>.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" <bazulay at redhat.com>
> To: "Alon Bar-Lev" <alonbl at redhat.com>
> Cc: "Fabian Deutsch" <fabiand at redhat.com>, arch at ovirt.org, "Douglas Landgraf" <dlandgra at redhat.com>, "node-devel"
> <node-devel at ovirt.org>
> Sent: Sunday, March 30, 2014 12:51:05 PM
> Subject: Re: [node-devel] Versioning of oVirt Node
> 
> 
> 
> ----- Original Message -----
> > From: "Alon Bar-Lev" <alonbl at redhat.com>
> > To: "Fabian Deutsch" <fabiand at redhat.com>
> > Cc: arch at ovirt.org, "Douglas Landgraf" <dlandgra at redhat.com>, "node-devel"
> > <node-devel at ovirt.org>
> > Sent: Sunday, March 30, 2014 11:57:09 AM
> > Subject: Re: [node-devel] Versioning of oVirt Node
> > 
> > 
> > 
> > ----- Original Message -----
> > > From: "Fabian Deutsch" <fabiand at redhat.com>
> > > To: arch at ovirt.org, "node-devel" <node-devel at ovirt.org>
> > > Cc: "Douglas Landgraf" <dlandgra at redhat.com>
> > > 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-<node-version>-<number>.<number>.<build-date>.\
> > >   vdsm<ovirt-target-version>.<dist>.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-<ovirt-target-version>-<build-date>.<number>.<dist>.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-<ovirt-target-version>-<build-date>.<number>.<dist>.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" <alonbl at redhat.com>
> To: "Barak Azulay" <bazulay at redhat.com>
> Cc: "Fabian Deutsch" <fabiand at redhat.com>, arch at ovirt.org, "Douglas Landgraf" <dlandgra at redhat.com>, "node-devel"
> <node-devel at ovirt.org>
> Sent: Sunday, March 30, 2014 12:53:32 PM
> Subject: Re: [node-devel] Versioning of oVirt Node
> 
> 
> 
> ----- Original Message -----
> > From: "Barak Azulay" <bazulay at redhat.com>
> > To: "Alon Bar-Lev" <alonbl at redhat.com>
> > Cc: "Fabian Deutsch" <fabiand at redhat.com>, arch at ovirt.org, "Douglas
> > Landgraf" <dlandgra at redhat.com>, "node-devel"
> > <node-devel at ovirt.org>
> > Sent: Sunday, March 30, 2014 12:51:05 PM
> > Subject: Re: [node-devel] Versioning of oVirt Node
> > 
> > 
> > 
> > ----- Original Message -----
> > > From: "Alon Bar-Lev" <alonbl at redhat.com>
> > > To: "Fabian Deutsch" <fabiand at redhat.com>
> > > Cc: arch at ovirt.org, "Douglas Landgraf" <dlandgra at redhat.com>,
> > > "node-devel"
> > > <node-devel at ovirt.org>
> > > Sent: Sunday, March 30, 2014 11:57:09 AM
> > > Subject: Re: [node-devel] Versioning of oVirt Node
> > > 
> > > 
> > > 
> > > ----- Original Message -----
> > > > From: "Fabian Deutsch" <fabiand at redhat.com>
> > > > To: arch at ovirt.org, "node-devel" <node-devel at ovirt.org>
> > > > Cc: "Douglas Landgraf" <dlandgra at redhat.com>
> > > > 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-<node-version>-<number>.<number>.<build-date>.\
> > > >   vdsm<ovirt-target-version>.<dist>.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-<ovirt-target-version>-<build-date>.<number>.<dist>.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-<ovirt-target-version>-<build-date>.<number>.<dist>.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" <bazulay at redhat.com>
> To: "Alon Bar-Lev" <alonbl at redhat.com>
> Cc: "Fabian Deutsch" <fabiand at redhat.com>, arch at ovirt.org, "Douglas Landgraf" <dlandgra at redhat.com>, "node-devel"
> <node-devel at ovirt.org>
> Sent: Sunday, March 30, 2014 3:45:56 PM
> Subject: Re: [node-devel] Versioning of oVirt Node
> 
> 
> 
> ----- Original Message -----
> > From: "Alon Bar-Lev" <alonbl at redhat.com>
> > To: "Barak Azulay" <bazulay at redhat.com>
> > Cc: "Fabian Deutsch" <fabiand at redhat.com>, arch at ovirt.org, "Douglas
> > Landgraf" <dlandgra at redhat.com>, "node-devel"
> > <node-devel at ovirt.org>
> > Sent: Sunday, March 30, 2014 12:53:32 PM
> > Subject: Re: [node-devel] Versioning of oVirt Node
> > 
> > 
> > 
> > ----- Original Message -----
> > > From: "Barak Azulay" <bazulay at redhat.com>
> > > To: "Alon Bar-Lev" <alonbl at redhat.com>
> > > Cc: "Fabian Deutsch" <fabiand at redhat.com>, arch at ovirt.org, "Douglas
> > > Landgraf" <dlandgra at redhat.com>, "node-devel"
> > > <node-devel at ovirt.org>
> > > Sent: Sunday, March 30, 2014 12:51:05 PM
> > > Subject: Re: [node-devel] Versioning of oVirt Node
> > > 
> > > 
> > > 
> > > ----- Original Message -----
> > > > From: "Alon Bar-Lev" <alonbl at redhat.com>
> > > > To: "Fabian Deutsch" <fabiand at redhat.com>
> > > > Cc: arch at ovirt.org, "Douglas Landgraf" <dlandgra at redhat.com>,
> > > > "node-devel"
> > > > <node-devel at ovirt.org>
> > > > Sent: Sunday, March 30, 2014 11:57:09 AM
> > > > Subject: Re: [node-devel] Versioning of oVirt Node
> > > > 
> > > > 
> > > > 
> > > > ----- Original Message -----
> > > > > From: "Fabian Deutsch" <fabiand at redhat.com>
> > > > > To: arch at ovirt.org, "node-devel" <node-devel at ovirt.org>
> > > > > Cc: "Douglas Landgraf" <dlandgra at redhat.com>
> > > > > 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-<node-version>-<number>.<number>.<build-date>.\
> > > > >   vdsm<ovirt-target-version>.<dist>.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-<ovirt-target-version>-<build-date>.<number>.<dist>.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-<ovirt-target-version>-<build-date>.<number>.<dist>.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: <http://lists.ovirt.org/pipermail/arch/attachments/20140331/89fd7de4/attachment.sig>

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" <alonbl at redhat.com>
> To: "Barak Azulay" <bazulay at redhat.com>
> Cc: arch at ovirt.org, "Douglas Landgraf" <dlandgra at redhat.com>, "node-devel" <node-devel at ovirt.org>
> Sent: Sunday, March 30, 2014 3:49:13 PM
> Subject: Re: [node-devel] Versioning of oVirt Node
> 
> 
> 
> ----- Original Message -----
> > From: "Barak Azulay" <bazulay at redhat.com>
> > To: "Alon Bar-Lev" <alonbl at redhat.com>
> > Cc: "Fabian Deutsch" <fabiand at redhat.com>, arch at ovirt.org, "Douglas
> > Landgraf" <dlandgra at redhat.com>, "node-devel"
> > <node-devel at ovirt.org>
> > Sent: Sunday, March 30, 2014 3:45:56 PM
> > Subject: Re: [node-devel] Versioning of oVirt Node
> > 
> > 
> > 
> > ----- Original Message -----
> > > From: "Alon Bar-Lev" <alonbl at redhat.com>
> > > To: "Barak Azulay" <bazulay at redhat.com>
> > > Cc: "Fabian Deutsch" <fabiand at redhat.com>, arch at ovirt.org, "Douglas
> > > Landgraf" <dlandgra at redhat.com>, "node-devel"
> > > <node-devel at ovirt.org>
> > > Sent: Sunday, March 30, 2014 12:53:32 PM
> > > Subject: Re: [node-devel] Versioning of oVirt Node
> > > 
> > > 
> > > 
> > > ----- Original Message -----
> > > > From: "Barak Azulay" <bazulay at redhat.com>
> > > > To: "Alon Bar-Lev" <alonbl at redhat.com>
> > > > Cc: "Fabian Deutsch" <fabiand at redhat.com>, arch at ovirt.org, "Douglas
> > > > Landgraf" <dlandgra at redhat.com>, "node-devel"
> > > > <node-devel at ovirt.org>
> > > > Sent: Sunday, March 30, 2014 12:51:05 PM
> > > > Subject: Re: [node-devel] Versioning of oVirt Node
> > > > 
> > > > 
> > > > 
> > > > ----- Original Message -----
> > > > > From: "Alon Bar-Lev" <alonbl at redhat.com>
> > > > > To: "Fabian Deutsch" <fabiand at redhat.com>
> > > > > Cc: arch at ovirt.org, "Douglas Landgraf" <dlandgra at redhat.com>,
> > > > > "node-devel"
> > > > > <node-devel at ovirt.org>
> > > > > Sent: Sunday, March 30, 2014 11:57:09 AM
> > > > > Subject: Re: [node-devel] Versioning of oVirt Node
> > > > > 
> > > > > 
> > > > > 
> > > > > ----- Original Message -----
> > > > > > From: "Fabian Deutsch" <fabiand at redhat.com>
> > > > > > To: arch at ovirt.org, "node-devel" <node-devel at ovirt.org>
> > > > > > Cc: "Douglas Landgraf" <dlandgra at redhat.com>
> > > > > > 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-<node-version>-<number>.<number>.<build-date>.\
> > > > > >   vdsm<ovirt-target-version>.<dist>.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-<ovirt-target-version>-<build-date>.<number>.<dist>.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-<ovirt-target-version>-<build-date>.<number>.<dist>.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" <fabiand at redhat.com>
> > To: arch at ovirt.org, "node-devel" <node-devel at ovirt.org>
> > Cc: "Douglas Landgraf" <dlandgra at redhat.com>
> > 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-<node-version>-<number>.<number>.<build-date>.\
> >   vdsm<ovirt-target-version>.<dist>.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-<ovirt-target-version>-<build-date>.<number>.<dist>.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-<ovirt-target-version>-<build-date>.<number>.<dist>.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: <http://lists.ovirt.org/pipermail/arch/attachments/20140331/b0aa57ed/attachment.sig>

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: <http://lists.ovirt.org/pipermail/arch/attachments/20140331/062eb740/attachment.sig>

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" <alonbl at redhat.com>
> > To: "Barak Azulay" <bazulay at redhat.com>
> > Cc: "Fabian Deutsch" <fabiand at redhat.com>, arch at ovirt.org, "Douglas Landgraf" <dlandgra at redhat.com>, "node-devel"
> > <node-devel at ovirt.org>
> > Sent: Sunday, March 30, 2014 12:53:32 PM
> > Subject: Re: [node-devel] Versioning of oVirt Node
> > 
> > 
> > 
> > ----- Original Message -----
> > > From: "Barak Azulay" <bazulay at redhat.com>
> > > To: "Alon Bar-Lev" <alonbl at redhat.com>
> > > Cc: "Fabian Deutsch" <fabiand at redhat.com>, arch at ovirt.org, "Douglas
> > > Landgraf" <dlandgra at redhat.com>, "node-devel"
> > > <node-devel at ovirt.org>
> > > Sent: Sunday, March 30, 2014 12:51:05 PM
> > > Subject: Re: [node-devel] Versioning of oVirt Node
> > > 
> > > 
> > > 
> > > ----- Original Message -----
> > > > From: "Alon Bar-Lev" <alonbl at redhat.com>
> > > > To: "Fabian Deutsch" <fabiand at redhat.com>
> > > > Cc: arch at ovirt.org, "Douglas Landgraf" <dlandgra at redhat.com>,
> > > > "node-devel"
> > > > <node-devel at ovirt.org>
> > > > Sent: Sunday, March 30, 2014 11:57:09 AM
> > > > Subject: Re: [node-devel] Versioning of oVirt Node
> > > > 
> > > > 
> > > > 
> > > > ----- Original Message -----
> > > > > From: "Fabian Deutsch" <fabiand at redhat.com>
> > > > > To: arch at ovirt.org, "node-devel" <node-devel at ovirt.org>
> > > > > Cc: "Douglas Landgraf" <dlandgra at redhat.com>
> > > > > 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-<node-version>-<number>.<number>.<build-date>.\
> > > > >   vdsm<ovirt-target-version>.<dist>.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-<ovirt-target-version>-<build-date>.<number>.<dist>.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-<ovirt-target-version>-<build-date>.<number>.<dist>.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: <http://lists.ovirt.org/pipermail/arch/attachments/20140331/7aa61a1d/attachment.sig>

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" <fabiand at redhat.com>
> To: "Alon Bar-Lev" <alonbl at redhat.com>
> Cc: arch at ovirt.org, "node-devel" <node-devel at ovirt.org>, "Douglas Landgraf" <dlandgra at redhat.com>
> 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" <fabiand at redhat.com>
> > > To: arch at ovirt.org, "node-devel" <node-devel at ovirt.org>
> > > Cc: "Douglas Landgraf" <dlandgra at redhat.com>
> > > 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-<node-version>-<number>.<number>.<build-date>.\
> > >   vdsm<ovirt-target-version>.<dist>.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-<ovirt-target-version>-<build-date>.<number>.<dist>.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-<ovirt-target-version>-<build-date>.<number>.<dist>.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-<ovirt-target-version>-<build-date>.<number>.<dist>.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" <fabiand at redhat.com>
> To: "Barak Azulay" <bazulay at redhat.com>
> Cc: arch at ovirt.org, "node-devel" <node-devel at ovirt.org>, "Douglas Landgraf" <dlandgra at redhat.com>
> 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" <fabiand at redhat.com>
> To: "Barak Azulay" <bazulay at redhat.com>
> Cc: arch at ovirt.org, "Douglas Landgraf" <dlandgra at redhat.com>, "node-devel" <node-devel at ovirt.org>
> 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" <alonbl at redhat.com>
> To: "Fabian Deutsch" <fabiand at redhat.com>
> Cc: arch at ovirt.org, "Douglas Landgraf" <dlandgra at redhat.com>, "node-devel" <node-devel at ovirt.org>
> Sent: Monday, March 31, 2014 11:52:39 AM
> Subject: Re: [node-devel] Versioning of oVirt Node
> 
> 
> 
> ----- Original Message -----
> > From: "Fabian Deutsch" <fabiand at redhat.com>
> > To: "Alon Bar-Lev" <alonbl at redhat.com>
> > Cc: arch at ovirt.org, "node-devel" <node-devel at ovirt.org>, "Douglas Landgraf"
> > <dlandgra at redhat.com>
> > 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" <fabiand at redhat.com>
> > > > To: arch at ovirt.org, "node-devel" <node-devel at ovirt.org>
> > > > Cc: "Douglas Landgraf" <dlandgra at redhat.com>
> > > > 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-<node-version>-<number>.<number>.<build-date>.\
> > > >   vdsm<ovirt-target-version>.<dist>.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-<ovirt-target-version>-<build-date>.<number>.<dist>.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-<ovirt-target-version>-<build-date>.<number>.<dist>.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-<ovirt-target-version>-<build-date>.<number>.<dist>.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" <bazulay at redhat.com>
> To: "Alon Bar-Lev" <alonbl at redhat.com>
> Cc: "Fabian Deutsch" <fabiand at redhat.com>, arch at ovirt.org, "Douglas Landgraf" <dlandgra at redhat.com>, "node-devel"
> <node-devel at ovirt.org>
> 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" <fabiand at redhat.com>
> > To: "Barak Azulay" <bazulay at redhat.com>
> > Cc: arch at ovirt.org, "Douglas Landgraf" <dlandgra at redhat.com>, "node-devel" <node-devel at ovirt.org>
> > 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: <http://lists.ovirt.org/pipermail/arch/attachments/20140331/2a33e7a5/attachment.sig>

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" <alonbl at redhat.com>
> To: "Barak Azulay" <bazulay at redhat.com>
> Cc: "Fabian Deutsch" <fabiand at redhat.com>, arch at ovirt.org, "Douglas Landgraf" <dlandgra at redhat.com>, "node-devel"
> <node-devel at ovirt.org>
> Sent: Monday, March 31, 2014 12:29:23 PM
> Subject: Re: [node-devel] Versioning of oVirt Node
> 
> 
> 
> ----- Original Message -----
> > From: "Barak Azulay" <bazulay at redhat.com>
> > To: "Alon Bar-Lev" <alonbl at redhat.com>
> > Cc: "Fabian Deutsch" <fabiand at redhat.com>, arch at ovirt.org, "Douglas
> > Landgraf" <dlandgra at redhat.com>, "node-devel"
> > <node-devel at ovirt.org>
> > 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: <http://lists.ovirt.org/pipermail/arch/attachments/20140331/a8a84057/attachment.sig>

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: <http://lists.ovirt.org/pipermail/arch/attachments/20140331/bbecc2db/attachment.sig>

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" <fabiand at redhat.com>
> To: "Barak Azulay" <bazulay at redhat.com>
> Cc: "Alon Bar-Lev" <alonbl at redhat.com>, arch at ovirt.org, "Douglas Landgraf" <dlandgra at redhat.com>, "node-devel"
> <node-devel at ovirt.org>
> 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: <http://lists.ovirt.org/pipermail/arch/attachments/20140331/5c0755f6/attachment.sig>

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" <fabiand at redhat.com>
> To: "Alon Bar-Lev" <alonbl at redhat.com>
> Cc: "Barak Azulay" <bazulay at redhat.com>, arch at ovirt.org, "Douglas Landgraf" <dlandgra at redhat.com>, "node-devel"
> <node-devel at ovirt.org>
> 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" <fabiand at redhat.com>
> > To: "Alon Bar-Lev" <alonbl at redhat.com>
> > Cc: "Barak Azulay" <bazulay at redhat.com>, arch at ovirt.org, "Douglas Landgraf" <dlandgra at redhat.com>, "node-devel"
> > <node-devel at ovirt.org>
> > 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: <http://lists.ovirt.org/pipermail/arch/attachments/20140331/2d1fc377/attachment.sig>

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" <fabiand at redhat.com>
> To: "Alon Bar-Lev" <alonbl at redhat.com>
> Cc: "Barak Azulay" <bazulay at redhat.com>, arch at ovirt.org, "Douglas Landgraf" <dlandgra at redhat.com>, "node-devel"
> <node-devel at ovirt.org>
> 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" <fabiand at redhat.com>
> > > To: "Alon Bar-Lev" <alonbl at redhat.com>
> > > Cc: "Barak Azulay" <bazulay at redhat.com>, arch at ovirt.org, "Douglas
> > > Landgraf" <dlandgra at redhat.com>, "node-devel"
> > > <node-devel at ovirt.org>
> > > 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
> 


From phresus at gmail.com  Mon Mar 31 14:33:26 2014
From: phresus at gmail.com (Ryan Barry)
Date: Mon, 31 Mar 2014 07:33:26 -0700
Subject: [node-devel] Versioning of oVirt Node
Message-ID: <CAKNutvcD5SJCccVrc3gRrcysOptNaGS9H6psNRBpBxR18c3JjA@mail.gmail.com>

> Message: 3
> Date: Mon, 31 Mar 2014 05:16:38 -0400 (EDT)
> From: Barak Azulay <bazulay at redhat.com>
> To: Fabian Deutsch <fabiand at redhat.com>
> Cc: arch at ovirt.org, Douglas Landgraf <dlandgra at redhat.com>,
node-devel <node-devel at ovirt.org>
> Subject: Re: [node-devel] Versioning of oVirt Node

> Any idea why ?

> The only thing I can think off is that we are probably doing something
wrong.

For my part, because knowing what it's based on allows me to pick based
upon feature sets and known compatibility with addons. I know that a
Fedora-based image will support nested virt if I want to install that VDSM
hook. And CentOS will support Dell's monitoring tools.

Building from scratch with libvirt and busybox, even if hyperbolic, would
make adding plugins, vendor tools, or anything else exceptionally
problematic unless we were to reinvent RPM or an oVirt-specific VIB. Debian
stable presents some of the same problems.

We may be able to get away with an EL7-based build only until it diverges
too far from Fedora, at least, but I can't help but see this as a temporary
solution.
-- 
while (!asleep) { sheep++; }
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/arch/attachments/20140331/681e19cc/attachment.html>

From alonbl at redhat.com  Mon Mar 31 15:04:55 2014
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Mon, 31 Mar 2014 11:04:55 -0400 (EDT)
Subject: [node-devel] Versioning of oVirt Node
In-Reply-To: <CAKNutvcD5SJCccVrc3gRrcysOptNaGS9H6psNRBpBxR18c3JjA@mail.gmail.com>
References: <CAKNutvcD5SJCccVrc3gRrcysOptNaGS9H6psNRBpBxR18c3JjA@mail.gmail.com>
Message-ID: <855473452.33277.1396278295007.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Ryan Barry" <phresus at gmail.com>
> To: arch at ovirt.org
> Sent: Monday, March 31, 2014 5:33:26 PM
> Subject: Re: [node-devel] Versioning of oVirt Node
> 
> > Message: 3
> > Date: Mon, 31 Mar 2014 05:16:38 -0400 (EDT)
> > From: Barak Azulay < bazulay at redhat.com >
> > To: Fabian Deutsch < fabiand at redhat.com >
> > Cc: arch at ovirt.org , Douglas Landgraf < dlandgra at redhat.com >, node-devel <
> > node-devel at ovirt.org >
> > Subject: Re: [node-devel] Versioning of oVirt Node
> 
> > Any idea why ?
> 
> > The only thing I can think off is that we are probably doing something
> > wrong.
> 
> For my part, because knowing what it's based on allows me to pick based upon
> feature sets and known compatibility with addons. I know that a Fedora-based
> image will support nested virt if I want to install that VDSM hook. And
> CentOS will support Dell's monitoring tools.
> 
> Building from scratch with libvirt and busybox, even if hyperbolic, would
> make adding plugins, vendor tools, or anything else exceptionally
> problematic unless we were to reinvent RPM or an oVirt-specific VIB. Debian
> stable presents some of the same problems.

vdsm plugins are not supported on ovirt-node as far as I know.

anyway, I use this example to demonstrate how much it is not black box as people argue.

for the record, there is nothing to be re-invented, rpm is not a tool suitable for creating embedded solution, open embedded or plain cross compile image are valid. rpm or any package management solution is <somewhat> good for dynamic system, which is not the case in ovirt-node, as image is static once released.

> 
> We may be able to get away with an EL7-based build only until it diverges too
> far from Fedora, at least, but I can't help but see this as a temporary
> solution.

there is already rhel 7 beta, and I do not see any reason to start porting before it stabilize and waste resources on fedora, but you have this as a base for development instead of fedora if someone really like.

> --
> while (!asleep) { sheep++; }
> 
> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch
>