latest master
by Alexander Wels
Hi,
I just rebased and re-ran the engine setup to make sure I have the latest
schema. I am getting the following exception when starting the engine:
Caused by: org.postgresql.util.PSQLException: The column name
ksm_merge_across_nodes was not found in this ResultSet.
at
org.postgresql.jdbc2.AbstractJdbc2ResultSet.findColumn(AbstractJdbc2ResultSet.java:2542)
at
org.postgresql.jdbc2.AbstractJdbc2ResultSet.getBoolean(AbstractJdbc2ResultSet.java:2390)
at
org.jboss.jca.adapters.jdbc.WrappedResultSet.getBoolean(WrappedResultSet.java:615)
at
org.ovirt.engine.core.dao.VdsGroupDAODbFacadeImpl$VdsGroupRowMapper.mapRow(VdsGroupDAODbFacadeImpl.java:319)
[dal.jar:]
at
org.ovirt.engine.core.dao.VdsGroupDAODbFacadeImpl$VdsGroupRowMapper.mapRow(VdsGroupDAODbFacadeImpl.java:267)
[dal.jar:]
at
org.springframework.jdbc.core.RowMapperResultSetExtractor.extractData(RowMapperResultSetExtractor.java:92)
[spring-jdbc.jar:3.1.1.RELEASE]
at
org.springframework.jdbc.core.RowMapperResultSetExtractor.extractData(RowMapperResultSetExtractor.java:1)
[spring-jdbc.jar:3.1.1.RELEASE]
at
org.springframework.jdbc.core.JdbcTemplate$1.doInPreparedStatement(JdbcTemplate.java:649)
[spring-jdbc.jar:3.1.1.RELEASE]
at
org.springframework.jdbc.core.JdbcTemplate.execute(JdbcTemplate.java:587)
[spring-jdbc.jar:3.1.1.RELEASE]
... 68 more
It appears the code is looking for a column that wasn't added to the schema?
ksm_merge_across_nodes
Can someone merge the column into master so I am not stuck? thanks.
9 years, 4 months
Fwd: New architecture in Copr: PPC64LE
by Sandro Bonazzola
FYI
-------- Messaggio Inoltrato --------
Oggetto: New architecture in Copr: PPC64LE
Data: Mon, 15 Jun 2015 15:38:59 +0200
Mittente: Miroslav Suchy <msuchy(a)redhat.com>
Rispondi-a: Development discussions related to Fedora <devel(a)lists.fedoraproject.org>
A: Development discussions related to Fedora <devel(a)lists.fedoraproject.org>
Hi,
I just enabled new architecture in Copr - PowerPC 64 LE (little endian).
There are those chroots available:
* fedora-21-ppc64le
* fedora-22-ppc64le
* fedora-rawhide-ppc64le
This happened as co-operation of Red Hat, Brno University of Technology
and IBM.
I would like to thanks D, Horak and J. Capik from Secondary
Architectures for cooperation and making this happen.
To enable this architecture on existing project, you need to navigate to
your project -> click on Edit tab -> choose PPC64LE chroots -> Save and
then resubmit your SRPMs.
Enjoy and happy hacking
Mirek Suchy
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
9 years, 4 months
Select storage domain when creating VM from template with python-SDK
by Philip Strömbäck
Hi,
I have a question about python-SDK for Ovirt Engine API. When creating a
new VM from a template in Clone/Independent-mode, I'm not unable to select
storage domain for the new disk. It seems like it always get created on the
same disk at the template. I can move the disk after creation but it's a
little bit time consuming.
Example:
vm_params = params.VM ( name = vm_name, cluster = api.clusters.get (
"Cluster-1" ), template = api.templates.get ( "RHEL7" ), storage_domain =
api.storagedomains.get ( "iscsi1" ), disks = params.Disks ( clone = True ) )
try:
api.vms.add ( vm_params )
except Exception, e:
raise SystemExit ( "Could not create VM from template: %s" % ( e ) )
The VM is added correctly but the disk is located on iscsi0 ( the same as
the template ).
Have anybody an idea how to get this sorted out?
Best regards,
Philip
9 years, 4 months
[ANN] oVirt 3.5.3 Final Release is now available
by Sandro Bonazzola
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
The oVirt team is pleased to announce that the oVirt 3.5.3 Final Release is now available as of June 15th 2015.
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 20,
Red Hat Enterprise Linux 6.6, CentOS Linux 6.6 (or similar) and
Red Hat Enterprise Linux 7.1, CentOS Linux 7.1 (or similar).
This release of oVirt includes numerous bug fixes and two CVE fixes.
See the release notes [1] for a list of the new features and bugs fixed.
Please refer to release notes [1] for Installation / Upgrade instructions.
A new oVirt Live ISO is already available[2] and oVirt Node ISO will be soon available as well[3].
Please note that mirrors[4] may need usually one day before being synchronized.
Please refer to the release notes for known issues in this release.
[1] http://www.ovirt.org/OVirt_3.5.3_Release_Notes
[2] http://resources.ovirt.org/pub/ovirt-3.5/iso/ovirt-live/el6-3.5.3/ovirt-l...
[3] http://resources.ovirt.org/pub/ovirt-3.5/iso/ovirt-node/
[4] http://www.ovirt.org/Repository_mirrors#Current_mirrors
- --
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAEBCAAGBQJVfoI3AAoJEHw3u57E4QAOZtcP/167LZUjWapo8ujNgW9JilAW
Cmz9mWoQWzUopaFFhLkpPJV9+ngCIqiny4bgdeStNQCJ3VsbWS6gz1mFgm9M7ZGl
1y6Q5dbUrt+xRtdec+w8BbTb/UEdFPUeQ2Gxa+Z/YCJ4+ovsAX2Sgv2ZVNe6S6zR
WBVy79X1oKwJDsTbXjSotl2FxWbHW/+S3+3qI5YLVkwHDhwn6uoHdaNC0xo47fUj
Kw9G0VjLhQH3UHtna0QX/rw39elLf9/eVsiIiimSo8YbnQ7aqvkZw3tcOVYs/hGe
s+fW+xDnU5IcD90K6JToZYfHc8xsN7KAyfAbJecgS3HVDef1jyjcfxG08cTlG73C
Q+XqAZQXlAPHbjMQe8EYHYRAZcpk0EGVOaR+BXmL4x4p9sGCppTavq6W/9FlxkmK
tLVz5hFC+H6pjU00T/gCQC1+N8aZSfy8kO5nbbLWdFW9/ixvkIB4SCEVDkbB0keb
KphiOJZuxX5U1ZdwK0HvYcA6Z6bevCp9+wZEyi6UdNu/SjJx785USiFjBi/rmXVY
h/W0u0bqkjqu6Fc/IlDA8irNhxjwDiNp7qLWba72mlqKif0UKeqBgXmFk9A34BWi
bJmToIpnWyrZ5vjYyvHY+fwcnvu7EFFQb/OOnuFspoXc8aOkm6GcGZP+pgm9biN2
aPdWpfSKRDeX6nOg5LZN
=5bEX
-----END PGP SIGNATURE-----
9 years, 4 months
Stomp regression in vdsm master
by Adam Litke
Hi Piotr,
Today I refreshed my vdsm master branch and got the 4 commits at the
bottom of this email (among others). My engine started having
connection timeouts to vdsm (100% connectivity failure). Reverting
the commits resolved the problem for me. I don't have logs at the
moment but just wanted to share this info in case anyone else started
experiencing connectivity problems to vdsm.
14897fea06e8f21ae99144ee0294b21e08ea0892 stomp: calling super explicitly
ed12db391f2f147443baf52b5519d51ad5bd3410 stomp: allow single stomp reactor
ac85274145cd82eec804e3585b3cd12a6c13261a stompreactor: fix naming of default destination
c80ab0657d4f0454c3141aadeadcf134e5f16de7 stomp: server side subscriptions
--
Adam Litke
9 years, 4 months
Re: [ovirt-devel] gerrit+ci improvement proposal
by Oved Ourfali
On Jun 7, 2015 10:00 AM, Eyal Edri <eedri(a)redhat.com> wrote:
>
>
>
> ----- Original Message -----
> > From: "Oved Ourfali" <ovedo(a)redhat.com>
> > To: "Eyal Edri" <eedri(a)redhat.com>
> > Cc: infra(a)ovirt.org, devel(a)ovirt.org
> > Sent: Sunday, June 7, 2015 9:55:56 AM
> > Subject: Re: [ovirt-devel] gerrit+ci improvement proposal
> >
> >
> >
> > ----- Original Message -----
> > > From: "Eyal Edri" <eedri(a)redhat.com>
> > > To: "Eli Mesika" <emesika(a)redhat.com>
> > > Cc: "Oved Ourfali" <ovedo(a)redhat.com>, devel(a)ovirt.org, infra(a)ovirt.org
> > > Sent: Sunday, June 7, 2015 9:52:15 AM
> > > Subject: Re: [ovirt-devel] gerrit+ci improvement proposal
> > >
> > >
> > >
> > > ----- Original Message -----
> > > > From: "Eli Mesika" <emesika(a)redhat.com>
> > > > To: "Oved Ourfali" <ovedo(a)redhat.com>
> > > > Cc: "Eyal Edri" <eedri(a)redhat.com>, infra(a)ovirt.org, devel(a)ovirt.org
> > > > Sent: Thursday, June 4, 2015 3:49:05 PM
> > > > Subject: Re: [ovirt-devel] gerrit+ci improvement proposal
> > > >
> > > >
> > > >
> > > > ----- Original Message -----
> > > > > From: "Oved Ourfali" <ovedo(a)redhat.com>
> > > > > To: "Eyal Edri" <eedri(a)redhat.com>
> > > > > Cc: devel(a)ovirt.org, infra(a)ovirt.org
> > > > > Sent: Thursday, June 4, 2015 10:03:02 AM
> > > > > Subject: Re: [ovirt-devel] gerrit+ci improvement proposal
> > > > >
> > > > >
> > > > >
> > > > > ----- Original Message -----
> > > > > > From: "Eyal Edri" <eedri(a)redhat.com>
> > > > > > To: "Sandro Bonazzola" <sbonazzo(a)redhat.com>
> > > > > > Cc: infra(a)ovirt.org, devel(a)ovirt.org
> > > > > > Sent: Thursday, June 4, 2015 9:46:40 AM
> > > > > > Subject: Re: [ovirt-devel] gerrit+ci improvement proposal
> > > > > >
> > > > > >
> > > > > >
> > > > > > ----- Original Message -----
> > > > > > > From: "Sandro Bonazzola" <sbonazzo(a)redhat.com>
> > > > > > > To: "Eyal Edri" <eedri(a)redhat.com>, "Max Kovgan"
> > > > > > > <mkovgan(a)redhat.com>
> > > > > > > Cc: devel(a)ovirt.org, infra(a)ovirt.org
> > > > > > > Sent: Thursday, June 4, 2015 9:11:10 AM
> > > > > > > Subject: Re: [ovirt-devel] gerrit+ci improvement proposal
> > > > > > >
> > > > > > > Il 03/06/2015 21:46, Eyal Edri ha scritto:
> > > > > > > >
> > > > > > > >
> > > > > > > > ----- Original Message -----
> > > > > > > >> From: "Max Kovgan" <mkovgan(a)redhat.com>
> > > > > > > >> To: devel(a)ovirt.org
> > > > > > > >> Cc: infra(a)ovirt.org
> > > > > > > >> Sent: Wednesday, June 3, 2015 8:22:54 PM
> > > > > > > >> Subject: [ovirt-devel] gerrit+ci improvement proposal
> > > > > > > >>
> > > > > > > >> Hi everyone!
> > > > > > > >> We really want to have reliable and snappy CI: to allow short
> > > > > > > >> cycles
> > > > > > > >> and
> > > > > > > >> encourage developers to write tests.
> > > > > > > >>
> > > > > > > >> # Problem
> > > > > > > >>
> > > > > > > >> Many patches are neither ready for review nor for CI upon
> > > > > > > >> submission,
> > > > > > > >> which
> > > > > > > >> is OK.
> > > > > > > >> But running all the jobs on those patches with limited resources
> > > > > > > >> results
> > > > > > > >> in:
> > > > > > > >> overloaded resources, slow response time, unhappy developers.
> > > > > > > >>
> > > > > > > >> # Proposed Solution
> > > > > > > >>
> > > > > > > >> To run less jobs we know we don’t need to, thus making more
> > > > > > > >> resources
> > > > > > > >> for
> > > > > > > >> the
> > > > > > > >> jobs we need to run.
> > > > > > > >> We have been experimenting to make our CI stabler and quicker to
> > > > > > > >> respond
> > > > > > > >> by
> > > > > > > >> using gerrit flags. This has improved in both directions very
> > > > > > > >> well
> > > > > > > >> internally.
> > > > > > > >> Now it seems a good time to let all the oVirt projects to use
> > > > > > > >> this.
> > > > > > > >> This solution indirectly promotes reviews and quick tests - “to
> > > > > > > >> fail
> > > > > > > >> early”,
> > > > > > > >> yet full blown static code analysis and long tests to run “when
> > > > > > > >> ready”.
> > > > > > > >>
> > > > > > > >> # How it works
> > > > > > > >>
> > > > > > > >> 2 new gerrit independent flags are added to gerrit.
> > > > > > > >>
> > > > > > > >> ## CI flag
> > > > > > > >>
> > > > > > > >> Will express patch CI status. Values:
> > > > > > > >> * +1 CI passed
> > > > > > > >> * 0 CI did not run yet
> > > > > > > >> * -1 CI failed
> > > > > > > >> Permissions for setting: project maintainers (for special cases)
> > > > > > > >> should
> > > > > > > >> be
> > > > > > > >> able to set/override (except Jenkins).
> > > > > > > >>
> > > > > > > >> ## Workflow flag
> > > > > > > >>
> > > > > > > >> Will express patch “workflow” state. Values:
> > > > > > > >> * 0 Work In Progress
> > > > > > > >> * +1 Ready For Review
> > > > > > > >> * +2 Ready For Merge
> > > > > > > >> Permissions for setting: Owner can set +1, Project Maintainers
> > > > > > > >> can
> > > > > > > >> set
> > > > > > > >> +2
> > > > > > > >>
> > > > > > > >> ## Review + CI Integration:
> > > > > > > >>
> > > > > > > >> Merging [“Submit” button to appear] will require: Review+1,
> > > > > > > >> CI+1,
> > > > > > > >> Workflow+2
> > > > > > > >> Patch lifecycle now is:
> > > > > > > >> ---------------------------------------------------------------
> > > > > > > >> patch state |owner |reviewer |maintainer |CI tests |pass
> > > > > > > >> ---------------------------------------------------------------
> > > > > > > >> added/updated |- |- |- |quick |CI+1
> > > > > > > >> review |Workflow+1|Review+1 |- |heavy |CI+1
> > > > > > > >> merge ready |- |- |Workflow+2 |gating |CI+1
> > > > > > > >> merge |- |- |merge |merge |CI+1
> > > > > > > >>
> > > > > > > >> Changes from current workflow:
> > > > > > > >> Owner only adds reviewers, now owner needs to set "Workflow+1"
> > > > > > > >> for
> > > > > > > >> the
> > > > > > > >> patch
> > > > > > > >> to be reviewed, and heavily auto-tested.
> > > > > > > >> Maintainer now needs to set "Workflow+2" and wait for "Submit"
> > > > > > > >> button
> > > > > > > >> to
> > > > > > > >> appear after CI has completed running gating tests.
> > > > > > > >>
> > > > > > > >>
> > > > > > > >> Next step will be to automate merge the change after Workflow+2
> > > > > > > >> has
> > > > > > > >> been
> > > > > > > >> set
> > > > > > > >> by the Maintainer and gating tests passed.
> > > > > > > >>
> > > > > > > >>
> > > > > > > >> ## Why now?
> > > > > > > >>
> > > > > > > >> It is elimination of waste. The sooner - the better.
> > > > > > > >> The solution has been used for a while and it works.
> > > > > > > >> Resolving the problem without gerrit involved will lead to
> > > > > > > >> adding
> > > > > > > >> unreliable
> > > > > > > >> code into jobs, and will still be prone to problems:
> > > > > > > >> Just recently, 3d ago we’ve tried detecting what to run from
> > > > > > > >> jenkins
> > > > > > > >> relying only on gerrit comments so that upon Verified+1, we’d
> > > > > > > >> run
> > > > > > > >> the
> > > > > > > >> job.
> > > > > > > >> We could not use “Review+1”, because it makes no sense at all,
> > > > > > > >> so
> > > > > > > >> we
> > > > > > > >> left
> > > > > > > >> the job to set Verified+1.
> > > > > > > >> Meaning - re-trigger itself immediately more than 1 times.
> > > > > > > >>
> > > > > > > >> Jenkins and its visitors very unhappy, and we had to stop
> > > > > > > >> those
> > > > > > > >> jobs,
> > > > > > > >> clean
> > > > > > > >> up the queue, and spam developers.
> > > > > > > >>
> > > > > > > >> ## OK OK OK. Now what?
> > > > > > > >>
> > > > > > > >> Now we want your comments and opinions before pushing this
> > > > > > > >> further:
> > > > > > > >> Please participate in this thread, so we can start trying it
> > > > > > > >> out.
> > > > > > > >> Ask, Suggest better ideas, all this is welcome.
> > > > > > > >>
> > > > > > > >>
> > > > > > > >> Best Regards!
> > > > > > > >>
> > > > > > > >>
> > > > > > > >> N.B.
> > > > > > > >> Of course, this is not written in stone, in case we find a
> > > > > > > >> better
> > > > > > > >> approach
> > > > > > > >> on
> > > > > > > >> solving those issues, we will change to it.
> > > > > > > >> And we will keep improving so don't be afraid that it will be
> > > > > > > >> enforced:
> > > > > > > >> if
> > > > > > > >> this does not work out we will discard it.
> > > > > > > >>
> > > > > > > >> P.S.
> > > > > > > >> Kudos to dcaro, most of the work was done by him, and most of
> > > > > > > >> this
> > > > > > > >> text
> > > > > > > >> too.
> > > > > > > >>
> > > > > > > >
> > > > > > > > +1 from me, releasing CI from running non critical and
> > > > > > > > un-essential
> > > > > > > > jobs
> > > > > > > > will not only reduce load from ci,
> > > > > > > > and shorted response time for developers, it will allow us to add
> > > > > > > > much
> > > > > > > > more
> > > > > > > > powerful tests such as functional & system
> > > > > > > > tests that actually add hosts and run VMs, improving our ability
> > > > > > > > to
> > > > > > > > find
> > > > > > > > regression much more effectively.
> > > > > > > >
> > > > > > > > Another benefit to consider is saving reviewers time. I.e not
> > > > > > > > only
> > > > > > > > jenkins
> > > > > > > > benefits from Worklow+1, but also human reviewers.
> > > > > > > > Instead of looking at a patch that is too early to be reviewed,
> > > > > > > > the
> > > > > > > > author
> > > > > > > > can set the Workflow+1 when the code is ready to review
> > > > > > > > (even if he didn't verified it yet), thus saving time to other
> > > > > > > > reviewers
> > > > > > > > -
> > > > > > > > for example people can add an email rule
> > > > > > > > to alert them only when they are added to patches that have
> > > > > > > > Workflow+1,
> > > > > > > > and
> > > > > > > > not before.
> > > > > > >
> > > > > > > For human reviewers I suggest to keep using drafts until the patch
> > > > > > > is
> > > > > > > finished.
> > > > > >
> > > > > > keep using? how many developers do you know are working with drafts
> > > > > > until
> > > > > > their patch is ready?
> > > > > > i agree if everyone would use drafts load on jenkins was already much
> > > > > > lower,
> > > > > > unfortunately its not the case.
> > > > > >
> > > > >
> > > > > IMO we don't need the "workflow" flag.
> > > > > I'm okay with CI not running on "drafts". And yes... we do use them.
> > > > > We can try and educate people to use them more where needed.
> > > > > Drafts should be widely used in first-phase development, and less on
> > > > > bug-fixes.
> > > > >
> > > > > In addition, I think the patch owners shouldn't add reviewers, unless
> > > > > they
> > > > > need their input in the stage of the development.
> > > > > Once they want input, they should add reviewers.
> > > > >
> > > > > 1. So, if the patch is draft then no CI runs on it.
> > > > > 2. Once it turns into non-draft, you can run "light-CI" on it.
> > > > > 3. Once the patch has at least one +1 from a (human) reviewer, then it
> > > > > should
> > > > > run the "heavy" CI.
> > > > > 4. Once the patch has +1 from heavy CI, and +2 from reviewer
> > > > > (maintainer),
> > > > > then it can be merged.
> > > > >
> > > > > That's the process we have today, with slight change on when to run the
> > > > > CI
> > > > > and what CI to run (no CI on drafts, light CI on non-draft, heavy CI on
> > > > > +1
> > > > > patches).
> > > >
> > > > +1
> > > >
> > > > This is he right approach to go (I am also using drafts and if other
> > > > don't,
> > > > we can change that....)
> > > > Also, regarding the claim that publishing a draft is a one-way process, I
> > > > don't think that this is problematic, you should publish a draft after it
> > > > is
> > > > stable and you addressed all comments and run all tests locally
> > > >
> > >
> > > this might be true, but the problem is:
> > > 1. we can't enforce people to use drafts (technically), so until they do,
> > > we'll still have a resource problem
> >
> >
> > We can educate, and I don't see an issue with that.
> >
> > > 2. until we do, even "light ci" jobs running per patch will overload the
> > > ci
> > > without need, this is why relying on another
> > > flag will help - if adding workflow is a problem, we can use the CR+1
> > > as
> > > first attempt to improve the flow,
> > > and consider in the future to use workflow if it will be needed. (maybe
> > > we can even set it automatically somehow)
> > >
> >
> > Perhaps marking as "verified" can be this flag.
> > If the patch is verified by the author, then you run light CI on it.
> > If it was also CR+1, run the heavy CI.
>
> question is how soon does an author ticks verify on his patch?
> does he wait for code review before? for e.g. - i heard from some developers they wait
> for CI to give them +1 until they even add reviewers, so this might be the chicken and egg problem.
It depends on the patch I guess.
Again, I think drafts are enough, and that we shouldn't add another flag here, so suggesting alternatives for that.
We can "vote" on that flag addition, and other alternatives, and see what people say.
>
> >
> > That way you both don't need a new flag, and you don't waste resources on
> > non-manually-verified bugs.
> >
> > > > >
> > > > >
> > > > >
> > > > > > > Once it's finished and humans reviewed the logic of the patch,
> > > > > > > Workflow+1
> > > > > > > should be triggered allowing automation to check the correctness of
> > > > > > > the
> > > > > > > patch.
> > > > > > > IMHO there's no reason for wasting CI time on patches that will be
> > > > > > > correct
> > > > > > > from an automation point of view but nacked by reviewers.
> > > > > > > Especially
> > > > > > > if
> > > > > > > the
> > > > > > > patches are part of a big patchset.
> > > > > > >
> > > > > > >
> > > > > > > >
> > > > > > > > And one final note, for Workflow+2 -> this is a preparation for a
> > > > > > > > gating
> > > > > > > > system, like Zuul used by openstack, that in the future
> > > > > > > > we might use as automatic merger pending passing a verification
> > > > > > > > step.
> > > > > > > > this
> > > > > > > > will prevent errors that happen sometimes
> > > > > > > > post merge due to conflicts or other issues, and will be another
> > > > > > > > level
> > > > > > > > of
> > > > > > > > validation before final merge.
> > > > > > > > But as max said, its all part of the plan and we'll test it of
> > > > > > > > course
> > > > > > > > before implementing to see its value.
> > > > > > > >
> > > > > > > >
> > > > > > > >>
> > > > > > > >>
> > > > > > > >>
> > > > > > > >> Max Kovgan
> > > > > > > >>
> > > > > > > >> Senior Software Engineer
> > > > > > > >> Red Hat - EMEA ENG Virtualization R&D
> > > > > > > >> Tel.: +972 9769 2060
> > > > > > > >> Email: mkovgan [at] redhat [dot] com
> > > > > > > >> Web: http://www.redhat.com
> > > > > > > >> RHT Global #: 82-72060
> > > > > > > >>
> > > > > > > >> _______________________________________________
> > > > > > > >> Devel mailing list
> > > > > > > >> Devel(a)ovirt.org
> > > > > > > >> http://lists.ovirt.org/mailman/listinfo/devel
> > > > > > > > _______________________________________________
> > > > > > > > Devel mailing list
> > > > > > > > Devel(a)ovirt.org
> > > > > > > > http://lists.ovirt.org/mailman/listinfo/devel
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > Sandro Bonazzola
> > > > > > > Better technology. Faster innovation. Powered by community
> > > > > > > collaboration.
> > > > > > > See how it works at redhat.com
> > > > > > > _______________________________________________
> > > > > > > Infra mailing list
> > > > > > > Infra(a)ovirt.org
> > > > > > > http://lists.ovirt.org/mailman/listinfo/infra
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > _______________________________________________
> > > > > > Devel mailing list
> > > > > > Devel(a)ovirt.org
> > > > > > http://lists.ovirt.org/mailman/listinfo/devel
> > > > > >
> > > > > >
> > > > > >
> > > > > _______________________________________________
> > > > > Infra mailing list
> > > > > Infra(a)ovirt.org
> > > > > http://lists.ovirt.org/mailman/listinfo/infra
> > > > >
> > > > _______________________________________________
> > > > Infra mailing list
> > > > Infra(a)ovirt.org
> > > > http://lists.ovirt.org/mailman/listinfo/infra
> > > >
> > > >
> > > >
> > > _______________________________________________
> > > Infra mailing list
> > > Infra(a)ovirt.org
> > > http://lists.ovirt.org/mailman/listinfo/infra
> > >
> > _______________________________________________
> > Infra mailing list
> > Infra(a)ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/infra
> >
> >
> >
> _______________________________________________
> Devel mailing list
> Devel(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
>
>
9 years, 4 months
Re: [ovirt-devel] [UI] New/Edit host dialog is broken
by Oved Ourfali
On Jun 9, 2015 21:00, Alexander Wels <awels(a)redhat.com> wrote:
>
> On Monday, June 08, 2015 07:38:05 AM Einav Cohen wrote:
> > Thanks, Eli; @Alexander - can you please investigate this?
> >
> > ----
> > Regards,
> > Einav
> >
>
> Yes, found the problem, fixed here [1].
>
Looks good to me. Thanks for the quick fix.
Who can merge that on a short loop?
>
> [1] https://gerrit.ovirt.org/#/c/42104/
>
> > ----- Original Message -----
> >
> > > From: "Eli Mesika" <emesika(a)redhat.com>
> > > To: "engine-devel(a)ovirt.org" <devel(a)ovirt.org>
> > > Cc: "Einav Cohen" <ecohen(a)redhat.com>, "Oved Ourfali"
> > > <oourfali(a)redhat.com>, "Alexander Wels" <awels(a)redhat.com> Sent: Monday,
> > > June 8, 2015 7:17:46 AM
> > > Subject: [UI] New/Edit host dialog is broken
> > >
> > > Hi guys
> > >
> > > I have found that new/edit host dialog is not working as expected
> > >
> > > 1) Create a new DC 'mydc'
> > > 2) Create a new cluster 'myCluster'
> > > 3) Create a new Host on 'myCluster'
> > >
> > > Result: Host is created in Dc 'Default' and cluster 'Default'
> > >
> > > 1) Edit the host you have created
> > > 2) Change the cluster to 'myCluster'
> > > 3) press OK
> > >
> > > Result: Host is still in Dc 'Default' and cluster 'Default'
> > >
> > >
> > > Thanks
> > > Eli Mesika
>
> _______________________________________________
> Devel mailing list
> Devel(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
>
>
9 years, 4 months
3.6.1 target release
by Michal Skrivanek
Hi,
who's maintaing bugzilla's config?
I'd appreciate 3.6.1 target release to be able to push out the small things supposed to land immediately after feature freeze
Thanks,
michal
9 years, 4 months
