Duplicate upgrade scripts issue
by Eli Mesika
Hi guys
I have talked with Eyal about the $Subject and he asked me to write and
send this email
As you probably know, we have from time to time an issue with duplicate
upgrade scripts that are merged by mistake, each such issue forces us to
publish a fixing patch that renames the duplicated file.
I was discussed this issue today with Marin P on out weekly meeting
We would like to write some kind of a hook that will check on each patch
set if it has DB upgrade files and rename them (if necessary) such that it
will have the correct numbering according to the last existing upgrade
patch on the related branch.
The hook should be done upon 'git push' request so it will also prevent CI
tests to fail on this issue
I will be happy to get your ideas/comments on that
Thanks
Eli Mesika
8 years, 5 months
Enhancing std-ci for deployment (std-cd)
by Barak Korren
Hi all,
I'm contemplating the best way to enable including deployment logic in
standard-CI scripts.
Case to the point - embedding the deployment logic of our infra-puppet
repo. One thing to note about this, is that deployment in this
scenario can happen either post-merge (Like it does today) or
pre-merge (Create a per-patch puppet env to enable easy testing)
I can think of a few ways to go about this:
1. Copy the full generated puppet configuration into
'exported-artifacts' and add logic to the YAML to copy it to the
foreman server.
The main shortcoming of this is that we will have to maintain quite a
bit of custom logic in the YAML. This beats the purpose of embedding
the logic in the source repo in the 1st place.
2. Mount the '/etc/puppet' directory into the chrrot
This will require having the foreman be a Jenkins slave and some
custom YAML to ensure the jobs run on it (not a big deal IMO)
The shortcoming is that running tests locally with mock_runner would
be cumbersome (It will touch your local /etc/puppet directory and
probably fail). Another issue is that we will have to find a way to
figure out Gerrit patch information from inside mock. Possibly we
could use the commit message or git hash for that.
3. Invent some kind of a new deploy_*.sh script
This makes it possible to run the checking code locally without the
deployment code. The YAML changes for this could be quite generic and
shared with other projects. We could possibly also invent a
'deploy_*.target' to specify where to run the deploy script (E.g. a
Jenkins label).
We could even consider not running the script inside mock, though I
think mock's benefits outweigh the limits it imposes on accessing the
outside system (which can be mostly bypassed anyway with bind mounts).
So,
WDYT?
--
Barak Korren
bkorren(a)redhat.com
RHEV-CI Team
8 years, 5 months
[Vdsm] infra support for the new stable branch ovirt-4.0
by Francesco Romani
Hi Infra,
(Dan, please ACK/NACK the following)
I'm not sure this is already been worked on, or if it was already configured automatically,
sending just in case to be sure.
Me and Yaniv (CC'd) agreed to continue our maintainer duties and take care of the ovirt-4.0
Vdsm stable branch which was recently created.
I'd like to ask if we have the gerrit permissions and CI jobs ready for the new
branch.
DISCLAIMER: I haven't yet tried to submit (yet alone merge) a patch to the ovirt-4.0
branch, we are still preparing the first backports :)
Thanks,
--
Francesco Romani
RedHat Engineering Virtualization R & D
Phone: 8261328
IRC: fromani
8 years, 5 months
Old Jenkins findbugs error ignored
by Tal Nisan
Check out this patch:
https://gerrit.ovirt.org/#/c/58652/
Old Jenkins failed on Findbugs (seems like an env problem, not a findbugs
analysis failure for that matter).
Patch was marked as failed CI yet as soon as the new Jenkins finished its
run it overwritten the failed CI of the old Jenkins and marked as CI passed
8 years, 5 months
Adding a new flag to a specific gerrit project?
by Juan Hernández
Hello,
As part of the effort to improve the documentation of the REST API the
documentation team will help us review the patches for the
specification. I was wondering if it is possible to add a new flag, like
the CR, CI, and V that we currently have. Would be nice to have a
"Documentation" flag (or similar) so that the documentation team can +1
that flag. Is this possible? Can this flag be added to the
ovirt-engine-api-model project? Can we define a group of users that have
permissions to set this flag?
Thanks in advance,
Juan Hernández
--
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.
8 years, 5 months
[JIRA] (OVIRT-545) Re: Please remove ovirt-node-ng-image* from several repositories
by eyal edri [Administrator] (oVirt JIRA)
[ https://ovirt-jira.atlassian.net/browse/OVIRT-545?page=com.atlassian.jira... ]
eyal edri [Administrator] updated OVIRT-545:
--------------------------------------------
Resolution: Fixed
Status: Done (was: Blocked)
> Re: Please remove ovirt-node-ng-image* from several repositories
> ----------------------------------------------------------------
>
> Key: OVIRT-545
> URL: https://ovirt-jira.atlassian.net/browse/OVIRT-545
> Project: oVirt - virtualization made easy
> Issue Type: By-EMAIL
> Reporter: eyal edri [Administrator]
>
> Creating a ticket for it.
> I think all node members have access to the resources server also if
> needed. (rbarry has).
> On Fri, May 13, 2016 at 1:44 PM, Fabian Deutsch <fdeutsch(a)redhat.com> wrote:
> > Hey,
> >
> > could someone please remove all builds of these two packages:
> >
> > ovirt-node-ng-image
> > ovirt-node-ng-image-update
> >
> > from the
> > ovirt-3.6*
> > ovirt-4.0*
> > master*
> >
> > repositories?
> >
> > This is needed, because the versioning was changed.
> >
> > Thanks
> > fabian
> >
> > --
> > Fabian Deutsch <fdeutsch(a)redhat.com>
> > RHEV Hypervisor
> > Red Hat
> > _______________________________________________
> > Infra mailing list
> > Infra(a)ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/infra
> >
> >
> >
> --
> Eyal Edri
> Associate Manager
> RHEV DevOps
> EMEA ENG Virtualization R&D
> Red Hat Israel
> phone: +972-9-7692018
> irc: eedri (on #tlv #rhev-dev #rhev-integ)
--
This message was sent by Atlassian JIRA
(v1000.25.1#100000)
8 years, 5 months