Re: [ovirt-devel] [vdsm] branch ovirt-4.0.5 created
by Eyal Edri
On Mon, Oct 10, 2016 at 6:24 PM, Francesco Romani <fromani(a)redhat.com>
wrote:
> ----- Original Message -----
> > From: "Dan Kenigsberg" <danken(a)redhat.com>
> > To: "Francesco Romani" <fromani(a)redhat.com>
> > Cc: "Nir Soffer" <nsoffer(a)redhat.com>, devel(a)ovirt.org
> > Sent: Monday, October 10, 2016 5:11:26 PM
> > Subject: Re: [vdsm] branch ovirt-4.0.5 created
> >
> > On Mon, Oct 10, 2016 at 10:30:49AM -0400, Francesco Romani wrote:
> > > Hi everyone,
> > >
> > > this time I choose to create the ovirt-4.0.5 branch.
> > > I already merged some patches for 4.0.6.
> > >
> > > Unfortunately I branched a bit too early (from last tag :))
> > >
> > > So patches
> > > https://gerrit.ovirt.org/#/c/65303/1
> > > https://gerrit.ovirt.org/#/c/65304/1
> > > https://gerrit.ovirt.org/#/c/65305/1
> > >
> > > Should be trivially mergeable - the only thing changed from ovirt-4.0
> > > counterpart
> > > is the change-id. Please have a quick look just to doublecheck.
> >
> > Change-Id should be the same for a master patch and all of its backport.
> > It seems that it was NOT changed, at least for
> > https://gerrit.ovirt.org/#/q/I5cea6ec71c913d74d95317ff7318259d64b40969
> > which is a GOOD thing.
>
> Yes, sorry, indeed it is (and indeed it should not change).
>
> > I think we want to enable CI on the new 4.0.5 branch, right? Otherwise
> > we'd need to fake the CI+1 flag until 4.0.5 is shipped.
>
> We should, but it is not urgently needed - just regular priority.
> For the aforementioned first three patches especially I'm just overly
> cautious.
>
>
Was CI enabled for 4.0.5 branch?
Adding infra as well.
Shlomi, Did we enabled the regex for stable branch already and we don't
need to manually update conf files?
> --
> Francesco Romani
> Red Hat Engineering Virtualization R & D
> Phone: 8261328
> IRC: fromani
> _______________________________________________
> Devel mailing list
> Devel(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
>
>
>
--
Eyal Edri
Associate Manager
RHV DevOps
EMEA ENG Virtualization R&D
Red Hat Israel
phone: +972-9-7692018
irc: eedri (on #tlv #rhev-dev #rhev-integ)
8 years
[JIRA] (OVIRT-763) [Lago][rfe] ability to choose version to be installed
by eyal edri [Administrator] (oVirt JIRA)
[ https://ovirt-jira.atlassian.net/browse/OVIRT-763?page=com.atlassian.jira... ]
eyal edri [Administrator] commented on OVIRT-763:
-------------------------------------------------
You already have an option to specify a custom repo to use instead of the ones defined in the conf files.
[~ngoldin(a)redhat.com] [~gbenhaim(a)redhat.com] do we have this feature documented on Lago docs?
> [Lago][rfe] ability to choose version to be installed
> -----------------------------------------------------
>
> Key: OVIRT-763
> URL: https://ovirt-jira.atlassian.net/browse/OVIRT-763
> Project: oVirt - virtualization made easy
> Issue Type: By-EMAIL
> Reporter: Piotr Kliczewski
> Assignee: infra
>
> I started to test using lago with master repos and my custom engine built.
> It was built on 7.10 one test failed and I noticed that newer engine was
> installed instead of my specific version. It seems that we need an ability
> to define which version of the rpms should be used during the tests.
> Thanks,
> Piotr
--
This message was sent by Atlassian JIRA
(v1000.482.3#100017)
8 years
[JIRA] (OVIRT-761) Re: Do we or can we have Mac OS slaves in Jenkins?
by eyal edri [Administrator] (oVirt JIRA)
[ https://ovirt-jira.atlassian.net/browse/OVIRT-761?page=com.atlassian.jira... ]
eyal edri [Administrator] commented on OVIRT-761:
-------------------------------------------------
I replied on the other ticket, but if indeed we can't run MAC OS tests on existing infra and Travis is the only way, we should at least explore this option.
I don't know if it matters that the GitHub repos are mirrors of gerrit and if that should affect the integration with Travis, but if anyone from VDSM team wants to explore it,
we can give permissions in GitHub to the maintainer to check the possibility.
> Re: Do we or can we have Mac OS slaves in Jenkins?
> --------------------------------------------------
>
> Key: OVIRT-761
> URL: https://ovirt-jira.atlassian.net/browse/OVIRT-761
> Project: oVirt - virtualization made easy
> Issue Type: By-EMAIL
> Reporter: sbonazzo
> Assignee: infra
>
> Opening a ticket.
> On Mon, Oct 10, 2016 at 11:44 AM, Juan Hernández <jhernand(a)redhat.com>
> wrote:
> > Hello,
> >
> > Part of the Ruby SDK uses native code that needs to be compiled during
> > installation of the gem. The Ruby SDK is a requirement of ManageIQ, and
> > many ManageIQ developers/users use Mac OS. In the past I had some issues
> > with this environment, as the C compiler there behaves in an slightly
> > different way than GCC. Those issues were discovered only when the SDK
> > was already released. To avoid that I would like to have Jenkins jobs
> > building/testing the SDK for Mac OS. Is that possible? Do we have Mac OS
> > slaves? If not, can we have them?
> >
> > Regards,
> > Juan Hernandez
> >
> > --
> > 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.
> > _______________________________________________
> > Infra mailing list
> > Infra(a)ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/infra
> >
> --
> Sandro Bonazzola
> Better technology. Faster innovation. Powered by community collaboration.
> See how it works at redhat.com
> <https://www.redhat.com/it/about/events/red-hat-open-source-day-2016>
--
This message was sent by Atlassian JIRA
(v1000.482.3#100017)
8 years
[JIRA] (OVIRT-795) Automate updateing of ovirt glance
by Barak Korren (oVirt JIRA)
Barak Korren created OVIRT-795:
----------------------------------
Summary: Automate updateing of ovirt glance
Key: OVIRT-795
URL: https://ovirt-jira.atlassian.net/browse/OVIRT-795
Project: oVirt - virtualization made easy
Issue Type: New Feature
Components: Repositories Mgmt
Reporter: Barak Korren
Assignee: infra
The ovirt Glance repo is only being update manually at this time.
This causes it to quickly go out of data and look unmaintained.
The image updating process should be automated
--
This message was sent by Atlassian JIRA
(v1000.482.3#100017)
8 years
