Rocky Milestone 2 RDO Test Days 14-15 June
by Rain Leander
Who’s up for a rematch?
Rocky Milestone 2 is here and we’re ready to rumble! Join RDO [0] on June
14 &
15 for an awesome time of taking down bugs and fighting errors in the most
recent release [1].
We won’t be pulling any punches.
Want to get in on the action? We’re looking for developers, users,
operators, quality engineers, writers, and, yes, YOU. If you’re reading
this, we think you’re a champion and we want your help!
We’ll have packages for the following platforms:
* RHEL 7
* CentOS 7
You’ll want a fresh install with latest updates installed so that there’s no
hard-to-reproduce interactions with other things.
We’ll be collecting feedback, writing up tickets, filing bugs, and answering
questions.
Even if you only have a few hours to spare, we’d love your help taking this
new version for a spin to work out any kinks. Not only will this help
identify
issues early in the development process, but you can be the one of the first
to cut your teeth on the latest versions of your favorite deployment methods
like TripleO, PackStack, and Kolla.
Interested? We’ll be gathering on #rdo (on Freenode IRC) for any associated
questions / discussions, and working through the “Does it work?” tests [2].
Like Rocky said, “The world ain’t all sunshine and rainbows,” but with your
help, we can keep moving forward and make the RDO world better for those
around us. Hope to see you on the 14th & 15th!
[0] https://www.rdoproject.org/
[1] https://www.rdoproject.org/testday/
[2] https://www.rdoproject.org/testday/tests/
--
K Rain Leander
OpenStack Community Liaison
Open Source and Standards Team
https://www.rdoproject.org/
http://community.redhat.com
7 years
Re: [rdo-dev] openstack-newton rpm packages unavailable now
by Alan Pevec
On Wed, Jun 6, 2018 at 1:44 PM, lucker zheng <lucker6666(a)gmail.com> wrote:
> Sorry to trouble, I met a problem when I want to install RDO newton version,
> after installed the rdo-release-newton.rpm, it links to repo
>
> http://mirror.centos.org/centos/7/cloud/x86_64/openstack-newton/
> seems no rpm avaiable there, is this a mistake?
CentOS SIG repos are retired everytime when CentOS minor update is released,
and it's up to SIG to declare which of their releases should be retired.
In this case OpenStack Newton was EOLed upstream already Oct 2017:
https://releases.openstack.org/
Old packages are frozen at
http://vault.centos.org/centos/7.4.1708/cloud/x86_64/openstack-newton/
and are NOT receiving any updates, so please do not use them!
> BTW I didn't find it in
> https://repos.fedorapeople.org/repos/openstack/EOL/
Those are only archives of rdo-release RPMs only anyway and we should
probably get rid of that old hosting location in Fedora.
> and I found the build system successful built newton jobs at
> https://trunk.rdoproject.org/centos7-newton/report.html
Those are available to support Fast Forward Upgrades CI testing from
Newton to Queens, building project which did not push newton-eol tags
yet. Anything else is frozen at Newton EOL point.
Other than for CI, any other usage of those packages is not
recommended, best would be if you could upgrade to the latest RDO
Queens release ASAP.
Cheers,
Alan
7 years
Kathy Cacciatore
by Rich Bowen
I'm sure that many of you already saw this -
https://twitter.com/laurensell/status/1003743674323349504
If you knew Kathy, consider taking a moment to send a note to Tony.
I worked at a number of events with Kathy. She was always kind, and
always very organized, and kept things running smoothly. She'll
definitely be missed.
--Rich
--
Rich Bowen: CentOS Community Manager
rbowen(a)redhat.com
@rbowen // @CentOSProject
1 859 351 9166
7 years
[meeting] RDO meeting (2018-06-06) minutes
by Rain Leander
==============================
#rdo: RDO meeting - 2018-06-06
==============================
Meeting started by mjturek at 15:00:14 UTC. The full logs are available
athttp://eavesdrop.openstack.org/meetings/rdo_meeting___2018_06_06/2018/r...
.
Meeting summary
---------------
* roll call (mjturek, 15:00:51)
* Test Day Prep (mjturek, 15:02:43)
* LINK:
https://review.rdoproject.org/jenkins/job/periodic-tripleo-centos-7-maste...
(amoralej, 15:07:42)
* LINK:
https://review.rdoproject.org/jenkins/job/periodic-tripleo-centos-7-maste...
(mjturek, 15:08:25)
* current blocker is https://bugs.launchpad.net/tripleo/+bug/1775199
(amoralej, 15:09:32)
* ACTION: leanderthal follow up with the DF DFG re: next week's test
cloud environment (leanderthal, 15:24:42)
* ACTION: mjturek chair next week's meeting (leanderthal, 15:27:25)
* open floor (leanderthal, 15:27:37)
* LINK: https://review.rdoproject.org/r/13951/ is our mapping for
zuul-migrate, plus some changes to JJB which is used to generate
https://review.rdoproject.org/r/13964/ (pabelanger, 15:30:47)
* LINK:
https://review.rdoproject.org/r/#/q/status:open+branch:master+topic:zuulv...
(more reviews here) (number80, 15:30:59)
* LINK: https://review.rdoproject.org/r/14042/ is a working example of
a zuulv3 job, see Zuul CI user (pabelanger, 15:31:17)
* LINK: https://review.rdoproject.org/r/13951/ (leanderthal,
15:32:41)
* LINK: https://review.rdoproject.org/r/13964/ (leanderthal,
15:32:53)
* LINK:
https://review.rdoproject.org/r/#/q/status:open+branch:master+topic:zuulv...
(leanderthal, 15:33:05)
* LINK: https://review.rdoproject.org/r/14042/ (leanderthal,
15:33:14)
* LINK: https://softwarefactory-project.io/r/#/c/12458/ (leanderthal,
15:47:35)
Meeting ended at 15:50:46 UTC.
Action items, by person
-----------------------
* leanderthal
* leanderthal follow up with the DF DFG re: next week's test cloud
environment
* mjturek
* mjturek chair next week's meeting
People present (lines said)
---------------------------
* leanderthal (55)
* mjturek (19)
* amoralej (16)
* pabelanger (10)
* openstack (7)
* weshay (2)
* apevec (2)
* jpena (2)
* number80 (2)
Generated by `MeetBot`_ 0.1.4
7 years
Re: [rdo-dev] qemu-kvm vs qemu-kvm-rhev requirement
by Kashyap Chamarthy
On Mon, Jun 04, 2018 at 09:41:07PM +0300, Roman Kagan wrote:
> Not so long ago openstack-nova started to require qemu-kvm-rhev instead
> of qemu-kvm.
>
> This made it impossible to install on Virtuozzo, which used to work well
> before the change.
I think Virtuozzo is based on CentOS.
> I skimmed through the related tickets
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1367696
> https://review.rdoproject.org/r/1900
> https://bugzilla.redhat.com/show_bug.cgi?id=1392820
> https://review.rdoproject.org/r/9858
>
> but failed to understand the motivation behind this change. What are
> those particular features that are only present in qemu-kvm-rhev and
> make the vendor-neutral requirement insufficient? So far we didn't
> notice any issues running recent enough QEMU with Nova, but I guess this
> must have changed.
Dan has already responded. In short, 'qemu-kvm-rhev' is the recommended
RPM for Red Hat OSP.
- - -
FYI, a related change that will get shortly pushed to RDO Nova spec (and
to "Queens" branch too):
https://review.rdoproject.org/r/#/c/13277/ -- Bump the minimum
version of 'qemu-kvm-rhev' & libvirt
> I'm now trying to figure out what is needed to make our QEMU package
> work with Nova; any help will be appreciated.
>
> Thanks,
> Roman.
--
/kashyap
7 years
Re: [rdo-dev] qemu-kvm vs qemu-kvm-rhev requirement
by Roman Kagan
On Tue, Jun 05, 2018 at 11:03:12AM +0100, Daniel P. Berrangé wrote:
> On Tue, Jun 05, 2018 at 12:55:59PM +0300, Roman Kagan wrote:
> > On Tue, Jun 05, 2018 at 10:24:03AM +0100, Daniel P. Berrangé wrote:
> > > On Tue, Jun 05, 2018 at 12:18:59PM +0300, Roman Kagan wrote:
> > > > On Tue, Jun 05, 2018 at 09:09:36AM +0100, Daniel P. Berrangé wrote:
> > > > > On Mon, Jun 04, 2018 at 09:41:07PM +0300, Roman Kagan wrote:
> > > > > > Not so long ago openstack-nova started to require qemu-kvm-rhev instead
> > > > > > of qemu-kvm.
> > > > > >
> > > > > > This made it impossible to install on Virtuozzo, which used to work well
> > > > > > before the change.
> > > > > >
> > > > > > I skimmed through the related tickets
> > > > > >
> > > > > > https://bugzilla.redhat.com/show_bug.cgi?id=1367696
> > > > > > https://review.rdoproject.org/r/1900
> > > > > > https://bugzilla.redhat.com/show_bug.cgi?id=1392820
> > > > > > https://review.rdoproject.org/r/9858
> > > > > >
> > > > > > but failed to understand the motivation behind this change. What are
> > > > > > those particular features that are only present in qemu-kvm-rhev and
> > > > > > make the vendor-neutral requirement insufficient? So far we didn't
> > > > > > notice any issues running recent enough QEMU with Nova, but I guess this
> > > > > > must have changed.
> > > > >
> > > > > The qemu-kvm package in RHEL is a stable version based on QEMU 1.5.3,
> > > > > and with many features disabled.
> > > > >
> > > > > For OSP we want to guarantee that users have the qemu-kvm-rhev package
> > > > > present which is rebased on every RHEL update to most recent upstream
> > > > > version and has a broader featureset installed, and is what is actually
> > > > > getting real world testing.
> > > >
> > > > This is exactly my problem: you're mixing up two separate things, the
> > > > QEMU version (vendor-neutral) and the features that can only be found in
> > > > the vendor-specific package, and I'm struggling to understand which one
> > > > is the deal-breaker.
> > > >
> > > > E.g. if I try to install Nova from
> > > > http://mirror.centos.org/centos/7/cloud/x86_64/openstack-ocata/ on my
> > > > Fedora28 machine, I have no way to satisfy this qemu-kvm-rhev
> > > > dependency, even though qemu-kvm installed is at version 2.11.1.
> > > >
> > > > Is this the intended behavior?
> > >
> > > In this case we don't care, because mixing distros is explicitly
> > > unsupported. ie you can't expect RPMs build for CentOS7 to be able
> > > to successfully dep-solve against RPMs biuld for Fedora 28. If it
> > > ever worked, it is purely by luck not design.
> > >
> > > IIUC, RDO project explicitly dropped support for running on Fedora
> > > and only targets CentOS or RHEL.
> >
> > I see, good to know.
> >
> > > > If it is, and Nova can only be used with this very special QEMU built
> > > > for RHEV, what are the specific features I should be looking out for to
> > > > be able to produce a compatible build? E.g. we (Virtuozzo) ship QEMU
> > > > package based on approximately the same mainline QEMU version as RHEV
> > > > but with different downstream patches and configuration. Is it likely
> > > > not to work with Nova?
> > >
> > > The qemu-kvm-rhev build is not really special - in fact it is probably
> > > more "normal" than the 'qemu-kvm' build because it is a modern QEMU
> > > version and so has relatively few patches backported, compared to the
> > > ancient 1.5.3 which has a load of patches backported.
> > >
> > > So if you have a QEMU build of comparable vintage to qemu-kvm-rhev
> > > that would likely work. You can then solve the deps problem by adding
> > > a virtual "Provides: qemu-kvm-ev = X.Y.Z"
> >
> > Do you mean "qemu-kvm-rhev = X.Y.Z"? We considered this, but the "rhev"
> > part kinda implied vendor affiliation and a claim of compatibility which
> > I wasn't sure we could guarantee. For one, our machine types differ in
> > names and default properties. If this is not a problem we can go down
> > this route indeed.
>
> AFAIK, the RDO project doesn't provide any claim of compatibility
> with Virtuozzo. So I don't think having a virtual "Provides: qemu-kvm-rhev"
> makes the situation worse wrt compatibility claims.
>
> Right now at least, Nova doesn't care about machine type names. In future
> there is possibility that the Nova RPMs in RDO will care about specific
> machine type names provided by qemu-kvm-rhev/qemu-kvm-ev. If that ever
> happened, you would have to modify the nova.conf to override this to
> work with your own QEMU builds.
Understood, thanks a lot. I think short term our best bet is to provide
qemu-kvm-rhev in our QEMU package indeed.
Thanks,
Roman.
7 years
Re: [rdo-dev] qemu-kvm vs qemu-kvm-rhev requirement
by Kashyap Chamarthy
On Tue, Jun 05, 2018 at 10:24:03AM +0100, Daniel P. Berrangé wrote:
> On Tue, Jun 05, 2018 at 12:18:59PM +0300, Roman Kagan wrote:
[...]
> > This is exactly my problem: you're mixing up two separate things, the
> > QEMU version (vendor-neutral) and the features that can only be found in
> > the vendor-specific package, and I'm struggling to understand which one
> > is the deal-breaker.
> >
> > E.g. if I try to install Nova from
> > http://mirror.centos.org/centos/7/cloud/x86_64/openstack-ocata/ on my
> > Fedora28 machine, I have no way to satisfy this qemu-kvm-rhev
> > dependency, even though qemu-kvm installed is at version 2.11.1.
> >
> > Is this the intended behavior?
>
> In this case we don't care, because mixing distros is explicitly
> unsupported. ie you can't expect RPMs build for CentOS7 to be able
> to successfully dep-solve against RPMs biuld for Fedora 28. If it
> ever worked, it is purely by luck not design.
>
> IIUC, RDO project explicitly dropped support for running on Fedora
> and only targets CentOS or RHEL.
Yes, that is my understanding as well. It was largely dropped to
little-to-no testing on Fedora. And most testing done on CentOS and
RHEL.
> > If it is, and Nova can only be used with this very special QEMU built
> > for RHEV, what are the specific features I should be looking out for to
> > be able to produce a compatible build? E.g. we (Virtuozzo) ship QEMU
> > package based on approximately the same mainline QEMU version as RHEV
> > but with different downstream patches and configuration. Is it likely
> > not to work with Nova?
>
> The qemu-kvm-rhev build is not really special - in fact it is probably
> more "normal" than the 'qemu-kvm' build because it is a modern QEMU
> version and so has relatively few patches backported, compared to the
> ancient 1.5.3 which has a load of patches backported.
>
> So if you have a QEMU build of comparable vintage to qemu-kvm-rhev
> that would likely work. You can then solve the deps problem by adding
> a virtual "Provides: qemu-kvm-ev = X.Y.Z"
Yep, because the CentOS package is called: 'qemu-kvm-ev'. Also you
(Roman) might want to refer to the following note in the RDO Git/master
'openstack-nova.spec' (the RPM spec):
# NOTE-1: CentOS package is called 'qemu-kvm-ev', but it has a
# compatiblity "Provides: qemu-kvm-rhev", so it'll do the
# right thing, that's why we're not special-casing CentOS
# here.
So, even if you're using CentOS, and are trying to install
'qemu-kvm-rhev', it should do the Right Thing.
--
/kashyap
7 years
