Hi Dan, Federico,
I noticed that the current jenkins builds of vdsm have an NVR like vdsm-4.10.3-0.xxxxxx while the current stable version is 4.10.3-10.xxxxx. This means that someone testing nightly builds for oVirt 3.3 will always get the stable version from either ovirt.org or Fedora repos, and not the nightly build.
I would submit a patch to increase the NVR, but I don't know which change is the right one (vdsm-4.10.4 or vdsm-4.11.0 or vdsm-5.0.0).
Mike
On Fri, May 17, 2013 at 01:51:20PM -0400, Mike Burns wrote:
Hi Dan, Federico,
I noticed that the current jenkins builds of vdsm have an NVR like vdsm-4.10.3-0.xxxxxx while the current stable version is 4.10.3-10.xxxxx. This means that someone testing nightly builds for oVirt 3.3 will always get the stable version from either ovirt.org or Fedora repos, and not the nightly build.
I would submit a patch to increase the NVR, but I don't know which change is the right one (vdsm-4.10.4 or vdsm-4.11.0 or vdsm-5.0.0).
oVirt-3.3 would carry at least vdsm-4.11.0, so you could use that NV as a base for nightly builds.
If you can wait, I hope that within a week, we will tag the master branch with v4.11.0. I practically waiting for Vinzenz's little vm.py refactoring for that to happen.
Regards, Dan.
On 05/18/2013 05:27 PM, Dan Kenigsberg wrote:
On Fri, May 17, 2013 at 01:51:20PM -0400, Mike Burns wrote:
Hi Dan, Federico,
I noticed that the current jenkins builds of vdsm have an NVR like vdsm-4.10.3-0.xxxxxx while the current stable version is 4.10.3-10.xxxxx. This means that someone testing nightly builds for oVirt 3.3 will always get the stable version from either ovirt.org or Fedora repos, and not the nightly build.
I would submit a patch to increase the NVR, but I don't know which change is the right one (vdsm-4.10.4 or vdsm-4.11.0 or vdsm-5.0.0).
oVirt-3.3 would carry at least vdsm-4.11.0, so you could use that NV as a base for nightly builds.
If you can wait, I hope that within a week, we will tag the master branch with v4.11.0. I practically waiting for Vinzenz's little vm.py refactoring for that to happen.
Can we maybe just push a patch that bumps the NVR to 4.10.3-999 or something that is the newer than the current stable? Then when you tag 4.11.0, you can update then as well.
The current state is that people could not test the latest vdsm from git unless they manually install the exact version.
Mike
Regards, Dan.
On Sat, May 18, 2013 at 05:31:21PM -0400, Mike Burns wrote:
On 05/18/2013 05:27 PM, Dan Kenigsberg wrote:
On Fri, May 17, 2013 at 01:51:20PM -0400, Mike Burns wrote:
Hi Dan, Federico,
I noticed that the current jenkins builds of vdsm have an NVR like vdsm-4.10.3-0.xxxxxx while the current stable version is 4.10.3-10.xxxxx. This means that someone testing nightly builds for oVirt 3.3 will always get the stable version from either ovirt.org or Fedora repos, and not the nightly build.
I would submit a patch to increase the NVR, but I don't know which change is the right one (vdsm-4.10.4 or vdsm-4.11.0 or vdsm-5.0.0).
oVirt-3.3 would carry at least vdsm-4.11.0, so you could use that NV as a base for nightly builds.
If you can wait, I hope that within a week, we will tag the master branch with v4.11.0. I practically waiting for Vinzenz's little vm.py refactoring for that to happen.
Can we maybe just push a patch that bumps the NVR to 4.10.3-999 or something that is the newer than the current stable? Then when you tag 4.11.0, you can update then as well.
The current state is that people could not test the latest vdsm from git unless they manually install the exact version.
We can easily add a 4.10.4 tag. But wouldn't it be just as easy (and maybe a bit less confusing) to do the -999 trick on the nightly build script?
On 05/18/2013 05:44 PM, Dan Kenigsberg wrote:
On Sat, May 18, 2013 at 05:31:21PM -0400, Mike Burns wrote:
On 05/18/2013 05:27 PM, Dan Kenigsberg wrote:
On Fri, May 17, 2013 at 01:51:20PM -0400, Mike Burns wrote:
Hi Dan, Federico,
I noticed that the current jenkins builds of vdsm have an NVR like vdsm-4.10.3-0.xxxxxx while the current stable version is 4.10.3-10.xxxxx. This means that someone testing nightly builds for oVirt 3.3 will always get the stable version from either ovirt.org or Fedora repos, and not the nightly build.
I would submit a patch to increase the NVR, but I don't know which change is the right one (vdsm-4.10.4 or vdsm-4.11.0 or vdsm-5.0.0).
oVirt-3.3 would carry at least vdsm-4.11.0, so you could use that NV as a base for nightly builds.
If you can wait, I hope that within a week, we will tag the master branch with v4.11.0. I practically waiting for Vinzenz's little vm.py refactoring for that to happen.
Can we maybe just push a patch that bumps the NVR to 4.10.3-999 or something that is the newer than the current stable? Then when you tag 4.11.0, you can update then as well.
The current state is that people could not test the latest vdsm from git unless they manually install the exact version.
We can easily add a 4.10.4 tag. But wouldn't it be just as easy (and maybe a bit less confusing) to do the -999 trick on the nightly build script?
I don't really know.
Eyal, Can you look into this? I don't really know the vdsm build job (or process).
Mike
[adding alon]
----- Original Message -----
From: "Mike Burns" mburns@redhat.com To: "Dan Kenigsberg" danken@redhat.com Cc: "Vinzenz Feenstra" vfeenstr@redhat.com, "Federico Simoncelli" fsimonce@redhat.com, vdsm-devel@lists.fedorahosted.org, "Eyal Edri" eedri@redhat.com Sent: Sunday, May 19, 2013 2:42:57 AM Subject: Re: Nightly builds of vdsm in jenkins need NVR bump
On 05/18/2013 05:44 PM, Dan Kenigsberg wrote:
On Sat, May 18, 2013 at 05:31:21PM -0400, Mike Burns wrote:
On 05/18/2013 05:27 PM, Dan Kenigsberg wrote:
On Fri, May 17, 2013 at 01:51:20PM -0400, Mike Burns wrote:
Hi Dan, Federico,
I noticed that the current jenkins builds of vdsm have an NVR like vdsm-4.10.3-0.xxxxxx while the current stable version is 4.10.3-10.xxxxx. This means that someone testing nightly builds for oVirt 3.3 will always get the stable version from either ovirt.org or Fedora repos, and not the nightly build.
I would submit a patch to increase the NVR, but I don't know which change is the right one (vdsm-4.10.4 or vdsm-4.11.0 or vdsm-5.0.0).
oVirt-3.3 would carry at least vdsm-4.11.0, so you could use that NV as a base for nightly builds.
If you can wait, I hope that within a week, we will tag the master branch with v4.11.0. I practically waiting for Vinzenz's little vm.py refactoring for that to happen.
Can we maybe just push a patch that bumps the NVR to 4.10.3-999 or something that is the newer than the current stable? Then when you tag 4.11.0, you can update then as well.
The current state is that people could not test the latest vdsm from git unless they manually install the exact version.
We can easily add a 4.10.4 tag. But wouldn't it be just as easy (and maybe a bit less confusing) to do the -999 trick on the nightly build script?
i prefer not to "cheat" with versions, these nightly builds are used by jenkins jobs and might need up gradable versions. if we can fix it to have proper versions that represent the current sha and greater than the stable one, that will be ideal.
Do we have the same problem with engine nightlies ?
I don't really know.
Eyal, Can you look into this? I don't really know the vdsm build job (or process).
current process:
from http://jenkins.ovirt.org/view/rpms/job/vdsm_create_rpms/
<snip> export NOSE_EXCLUDE=.* export HOME=${WORKSPACE} test -f Makefile && make -k distclean ./autogen.sh --system --enable-hooks make rpm make dist-gzip </snip>
Mike
----- Original Message -----
From: "Eyal Edri" eedri@redhat.com To: "Mike Burns" mburns@redhat.com, "Alon Bar-Lev" alonbl@redhat.com Cc: "Dan Kenigsberg" danken@redhat.com, "Vinzenz Feenstra" vfeenstr@redhat.com, "Federico Simoncelli" fsimonce@redhat.com, vdsm-devel@lists.fedorahosted.org Sent: Sunday, May 19, 2013 8:54:31 AM Subject: Re: Nightly builds of vdsm in jenkins need NVR bump
[adding alon]
This is well known issue. vdsm version of master is for past version in stead of future version. This due to insisting to use git magic to produce version. We fixed almost all projects, vdsm is still pending. I believe git magic should not be used in source[1]
[1] http://gerrit.ovirt.org/#/c/12448/
----- Original Message -----
From: "Mike Burns" mburns@redhat.com To: "Dan Kenigsberg" danken@redhat.com Cc: "Vinzenz Feenstra" vfeenstr@redhat.com, "Federico Simoncelli" fsimonce@redhat.com, vdsm-devel@lists.fedorahosted.org, "Eyal Edri" eedri@redhat.com Sent: Sunday, May 19, 2013 2:42:57 AM Subject: Re: Nightly builds of vdsm in jenkins need NVR bump
On 05/18/2013 05:44 PM, Dan Kenigsberg wrote:
On Sat, May 18, 2013 at 05:31:21PM -0400, Mike Burns wrote:
On 05/18/2013 05:27 PM, Dan Kenigsberg wrote:
On Fri, May 17, 2013 at 01:51:20PM -0400, Mike Burns wrote:
Hi Dan, Federico,
I noticed that the current jenkins builds of vdsm have an NVR like vdsm-4.10.3-0.xxxxxx while the current stable version is 4.10.3-10.xxxxx. This means that someone testing nightly builds for oVirt 3.3 will always get the stable version from either ovirt.org or Fedora repos, and not the nightly build.
I would submit a patch to increase the NVR, but I don't know which change is the right one (vdsm-4.10.4 or vdsm-4.11.0 or vdsm-5.0.0).
oVirt-3.3 would carry at least vdsm-4.11.0, so you could use that NV as a base for nightly builds.
If you can wait, I hope that within a week, we will tag the master branch with v4.11.0. I practically waiting for Vinzenz's little vm.py refactoring for that to happen.
Can we maybe just push a patch that bumps the NVR to 4.10.3-999 or something that is the newer than the current stable? Then when you tag 4.11.0, you can update then as well.
The current state is that people could not test the latest vdsm from git unless they manually install the exact version.
We can easily add a 4.10.4 tag. But wouldn't it be just as easy (and maybe a bit less confusing) to do the -999 trick on the nightly build script?
i prefer not to "cheat" with versions, these nightly builds are used by jenkins jobs and might need up gradable versions. if we can fix it to have proper versions that represent the current sha and greater than the stable one, that will be ideal.
Do we have the same problem with engine nightlies ?
I don't really know.
Eyal, Can you look into this? I don't really know the vdsm build job (or process).
current process:
from http://jenkins.ovirt.org/view/rpms/job/vdsm_create_rpms/
<snip> export NOSE_EXCLUDE=.* export HOME=${WORKSPACE} test -f Makefile && make -k distclean ./autogen.sh --system --enable-hooks make rpm make dist-gzip </snip>
Mike
On Sun, May 19, 2013 at 06:07:07AM -0400, Alon Bar-Lev wrote:
I believe git magic should not be used in source[1]
I don't see how git describe is unsuitable for this. From the examples section of the manpage[1]:
<<<EOF
With something like git.git current tree, I get:
[torvalds@g5 git]$ git describe parent v1.0.4-14-g2414721
i.e. the current head of my "parent" branch is based on v1.0.4, but since it has a few commits on top of that, describe has added the number of additional commits ("14") and an abbreviated object name for the commit itself ("2414721") at the end.
The number of additional commits is the number of commits which would be displayed by "git log v1.0.4..parent". The hash suffix is "-g" + 7-char abbreviation for the tip commit of parent (which was 2414721b194453f058079d897d13c4e377f92dc6). The "g" prefix stands for "git" and is used to allow describing the version of a software depending on the SCM the software is managed with. This is useful in an environment where people may use different SCMs.
Doing a git describe on a tag-name will just show the tag name:
[torvalds@g5 git]$ git describe v1.0.4 v1.0.4
EOF
Using this I think you can get consistent nightly build versioning. The only downside I see is that you have to put the number of commits + hash in the release so you can't bump when you change the spec file. This isn't a problem since the spec file is included in git so any change will be a commit, thus increasing the release anyway. Since the git hash is included in the version it should make it even easier to exactly know which version is being used.
[1]: https://www.kernel.org/pub/software/scm/git/docs/git-describe.html
vdsm-devel@lists.fedorahosted.org