[Rdo-list] RDO-Mitaka milestone3- error during installation
by Eran Kuris
HI all .
I am trying to install with packstack the latest RDO-Mitaka-milestone3 on RHEL7 OS.
I am using those repo:
ll /etc/yum.repos.d/
total 40
-rw-r--r--. 1 root root 169 Mar 20 09:23 delorean-deps.repo
-rw-r--r--. 1 root root 218 Mar 20 09:23 delorean.repo
-rw-r--r--. 1 root root 957 Mar 20 10:14 epel.repo
-rw-r--r--. 1 root root 1056 Nov 25 2014 epel-testing.repo
-rw-r--r--. 1 root root 212 Mar 20 10:14 rdo-release.repo
-rw-r--r--. 1 root root 160 Oct 21 20:47 rdo-testing.repo
-rw-r--r--. 1 root root 358 Mar 20 09:05 redhat.repo
-rw-r--r--. 1 root root 315 Mar 20 09:38 rhel7-extras.repo
-rw-r--r--. 1 root root 165 Mar 20 09:07 rhel-optional.repo
-rw-r--r--. 1 root root 153 Mar 20 09:07 rhel-server.repo
And getting this error
Applying 10.35.160.39_api_nova.pp
10.35.160.39_api_nova.pp: [ ERROR ]
Applying Puppet manifests [ ERROR ]
ERROR : Error appeared during Puppet run: 10.35.160.39_api_nova.pp
Error: Execution of '/usr/bin/yum -d 0 -e 0 -y install python-nova' returned 1: Error: Package: 1:python-nova-13.0.0.0b4-0.20160304162843.c5a45a2.el7.centos.noarch (delorean)
You will find full trace in log /var/tmp/packstack/20160320-100719-1Sqzbk/manifests/10.35.160.39_api_nova.pp.log
Please check log file /var/tmp/packstack/20160320-100719-1Sqzbk/openstack-setup.log for more information
Additional information:
* Time synchronization installation was skipped. Please note that unsynchronized time on server instances might be problem for some OpenStack components.
* Warning: NetworkManager is active on 10.35.160.39. OpenStack networking currently does not work on systems that have the Network Manager service enabled.
* File /root/keystonerc_admin has been created on OpenStack client host 10.35.160.39. To use the command line tools you need to source the file.
* To access the OpenStack Dashboard browse to http://10.35.160.39/dashboard .
Please, find your login credentials stored in the keystonerc_admin in your home directory.
* To use Nagios, browse to http://10.35.160.39/nagios username: nagiosadmin, password: c1f907019abe4c89
1mError: Execution of '/usr/bin/yum -d 0 -e 0 -y install python-nova' returned 1: Error: Package: 1:python-nova-13.0.0.0b4-0.20160304162843.c5a45a2.el7.centos.noarch (delorean)
Requires: python-cheetah
You could try using --skip-broken to work around the problem
You could try running: rpm -Va --nofiles --nodigest^[[0m
^[[1;31mError: /Stage[main]/Nova/Package[python-nova]/ensure: change from absent to present failed: Execution of '/usr/bin/yum -d 0 -e 0 -y install python-nova' returned 1: Error: Package: 1:python-nova-13.0.0.0b4-0.20160304162843.c5a45a2.el7.centos.noarch (delorean)
Requires: python-cheetah
Any advise ?
Best Regards ,
Eran Kuris
8 years, 8 months
[Rdo-list] Openstack Liberty with DVR and VLAN overlay
by Charles Short
Hi,
I have a simple single nic bare metal set up much like this -
https://answers.launchpad.net/neutron/+question/228376
Tenant networks are VLANs, and the external network a VLAN provider network.
This enables me to have one bridge which allows the VLAN overlays to
pass between nodes/physical switches, and importantly allows external
access via floating ip through the external provider network VLAN.
This was all working fine, but I wanted to install DVR. I saw that DVR
functionality had relatively recently been added for VLAN overlays (Kilo
and beyond)
https://blueprints.launchpad.net/neutron/+spec/neutron-ovs-dvr-vlan
So I enabled DVR, noting that for VLAN overlays l2population is not
required.
I created two instances, two tenant networks one with a normal router
(non DVR) and one with a DVR router.
I first tested SNAT on both. Worked fine (I could ping externally from
the instances)
I then applied a FIP to the non DVR routed instance. I could ping the
instance from the external network, so all working fine.
I then applied a FIP to the DVR routed instance. This is where the
problems began. I could not ping externally from the instance, and I
could not ping the instance from the external network.
I looked at the traffic flow schematic outlined here for North/South FIP
(allowing for the fact I am not using tunneling) -
http://docs.openstack.org/liberty/networking-guide/scenario_dvr_ovs.html
I noticed that the fg interface from the FIP namespace in my compute
node was NOT attached to br-int as in the guide, but was attached to my
VLAN bridge. This seemed odd.
I thought that maybe this would have an effect on the tagging, so tried
manually adding the tag for the external provider network VLAN to the fg
port on the VLAN bridge
ovs-vsctl set port fg-15df2853-c2 tag=1041
Suddenly it all started working. I could now ping externally from the
DVR routed instance, and I could ping the instance from the external
network.
Please can someone explain why I am seeing this behavior?
Thanks
Charles
--
Charles Short
Cloud Engineer
Virtualization and Cloud Team
European Bioinformatics Institute (EMBL-EBI)
Tel: +44 (0)1223 494205
8 years, 8 months
[Rdo-list] [tripleo-quickstart] Patches and more patches
by Lars Kellogg-Stedman
Hello fellow tripleo-quickstarters;
There are a pile of my patches in the queue right now, so I wanted to
present a summary to help sort them out.
266425 larsks use nthhost filter to derive floating ip values
https://review.gerrithub.io/266425
266527 larsks derive network settings in undercloud.conf
https://review.gerrithub.io/266527
266815 larsks pingtest must respect floating ip range
https://review.gerrithub.io/266815
These three patches make it easier to specify an address range for
the undercloud and for the floating ip networks created during
overcloud validation. They also (266815) make sure that our
validation scripts respect the address range we configure.
266446 larsks teach quickstart.sh about --no-clone
https://review.gerrithub.io/266446
This is primarily a developer optimization that makes it easier to
test quickstart.sh against a local working copy (which removes the
requirement of first posting changes to gerrit so they can be
obtained using the '-g' flag to quickstart.sh).
266269 larsks support targeting localhost
https://review.gerrithub.io/266269
This ensures that both "quickstart.sh some.remote.host" and
"quickstart.sh localhost" will work. Note that at the moment
changes between this patch and the previous one (266446) are
conflated; I'm going to try sort these out this evening.
266680 larsks add overcloud hosts to /etc/hosts
https://review.gerrithub.io/266680
266748 larsks generate ssh config on undercloud
https://review.gerrithub.io/266748
These are convenience patches. The first adds the names of
overcloud hosts to /etc/hosts on the undercloud, and the second adds
an ssh configuration on the undercloud that means you don't need to
specify 'heat-admin@' when logging in to overcloud hosts. So once
logged into the undercloud, you can...
ssh overcloud-controller-0
...and it Just Works.
266574 larsks ensure local_working_dir exists
https://review.gerrithub.io/266574
266633 larsks grant libvirt access to non-root user
https://review.gerrithub.io/266633
266635 larsks ensure XDG_RUNTIME_DIR is set
https://review.gerrithub.io/266635
These are small maintenance packages. The last makes sure that
`virsh` will operate correctly when accessing the unprivileged user
account via `su -` in addition to direct ssh access.
--
Lars Kellogg-Stedman <lars(a)redhat.com> | larsks @ {freenode,twitter,github}
Cloud Engineering / OpenStack | http://blog.oddbit.com/
8 years, 8 months
[Rdo-list] What should be RDO Definition of Done?
by Haïkel
Hello,
In an effort to improve RDO release process, we came accross the idea
of having a defined definition of done.
What are the criteria to decide if a release of RDO is DONE?
* RDO installs w/ packstack
* RDO installs w/ RDO Manager
* Documentation is up to date
etc ....
I added the topic to the RDO meeting agenda, but I'd like to enlarge
the discussion outside the pool of people coming
to the meetings and even technical contributors.
Regards,
H.
8 years, 8 months
[Rdo-list] rdo liberty neutron 7.0.2
by Jeff Weber
Is there any timeline on neutron packages for rdo liberty being bumped to
7.0.2?
I need the capability to convert HA router to non-HA and it looks like it
was backported to liberty and introduced in this patch.
8 years, 8 months
Re: [Rdo-list] Packstack tagging
by Martin Mágr
CC'ing rdo-list
On 03/18/2016 04:23 PM, Martin Mágr wrote:
> Greetings guys,
>
> I think that it's time to finally start tagging packstack upstream
> releases as David now needs that. This task has been in TODO list for
> several releases already and was always thrown away from radar with
> low priority.
>
> I'd like us to agree on a tagging workflow. David suggested first
> tag "<dmsimard> I wanted to tag 8.0.0b1", so IIUC to follow OpenStack
> upstream milestones (eg. Mitaka beta1 -> 8.0.0b1 ?). Has anybody
> something against that scheme?
>
> What should be the first tag in stable/liberty?
>
> Regards,
> Martin
>
>
>
>
8 years, 8 months
Re: [Rdo-list] Packstack tagging
by David Moreau Simard
For context, when working on release notes for Packstack with Reno I
noticed that it relied on git tags for providing version-based release
notes [1].
> Notes are immutable in that for a given git hash/tag the release notes will be the same. Tagging a commit will change the version description but that is all.
Since Packstack doesn't have any tags right now, Reno builds the
following notes:
---
=============
Release Notes
=============
0.0.0
=====
Release notes for Packstack are now managed through Reno.
---
Reno allows release notes to be fit between two tags appropriately,
i.e, like the Nova ones [2].
Tagging is also relied on by PBR when generating version numbers and
I'd like to see Packstack transition it's setup to PBR eventually [3].
Packstack is known as 8.0.0 for Mitaka already, so let's just start
with that IMO.
We can start at rc1 instead of b1 at this point I guess - the
stable/mitaka branch is already cut.
The proposed scheme also fits puppet module release tags [4].
I don't know if a tag for Liberty is necessary, we can probably start
for Mitaka.
[1]: http://docs.openstack.org/developer/reno/design.html
[2]: http://docs.openstack.org/releasenotes/nova/unreleased.html
[3]: https://bugs.launchpad.net/packstack/+bug/1559150
[4]: https://github.com/openstack/puppet-nova/releases
David Moreau Simard
Senior Software Engineer | Openstack RDO
dmsimard = [irc, github, twitter]
On Fri, Mar 18, 2016 at 11:23 AM, Martin Mágr <mmagr(a)redhat.com> wrote:
> Greetings guys,
>
> I think that it's time to finally start tagging packstack upstream
> releases as David now needs that. This task has been in TODO list for
> several releases already and was always thrown away from radar with low
> priority.
>
> I'd like us to agree on a tagging workflow. David suggested first tag
> "<dmsimard> I wanted to tag 8.0.0b1", so IIUC to follow OpenStack upstream
> milestones (eg. Mitaka beta1 -> 8.0.0b1 ?). Has anybody something against
> that scheme?
>
> What should be the first tag in stable/liberty?
>
> Regards,
> Martin
>
>
>
>
8 years, 8 months
