[Rdo-list] Neutron with existing network issues.
by NS Murthy
Hi
I am new to RDO openstack. I have installed in one single bare metal server which had 2 NICS connected with different subnets on my company network.
1) Primary NIC subnet: 10.58.100.24 - This is where i have installed openstack and openstack dashboard is listening to logon from this IP.2) Tenant NIC subnet: 10.68.200.5 - this is a secondary IP which i kept for tenant network so that i can logon.3) 1 br-ex interface ip 10.58.100.24
I have used br-ex interface address(which is my primary 1GB NIC IP) configured for tenant however i cannot ping tenant instance ip 10.68.200.25 from my management node but can ping floating IPs(10.58.100.25) and can do SSH to floating ip.
can someone provide a tip or help how to ping tenant IP as well connect to tenant IP without floating IP.
At the end i need the below.1) i need to have tenant network on 10.68.200.0/24, i need to ping this network so that tenant can logon to SSH without floating IP.2) i have requirement to have 2 Network interfaces on a instance ? how do i accomplish this ? becasue every tenant have fense network so i can only get one network when i spin instance from image ?
BR,Murthy
I
9 years, 6 months
[Rdo-list] Juno vs Kilo in Fedora 22
by Alan Pevec
Hi all,
until this point we have been able to maintain 1:1 mapping from Fedora
to OpenStack releases [1]
which has some advantages for package maintainers in RDO, rdopkg info
output is nicely symmetrical and predictable:
$ rdopkg info
RDO releases & repos:
kilo (Fedora 23/rawhide)
fedora-22 built in koji/master from master branch
fedora-21: symlink to fedora-22 repo (don't submit fedora-21 updates)
epel-7 built in cbs/cloud7-el7 from master branch
juno (Fedora 22)
fedora-21 built in koji/f22 from f22 branch
fedora-20: symlink to fedora-21 repo (don't submit fedora-20 updates)
epel-7 built in copr/jruzicka/rdo-juno-epel-7 from f22 branch
icehouse (Fedora 21)
fedora-20 built in koji/f21 from f21 branch
epel-6 built in copr/jruzicka/rdo-icehouse-epel-6 from f21 branch
epel-7 built in copr/jruzicka/rdo-icehosue-epel-7 from f21 branch
But OpenStack releases are coming up quickly, upstream stable/juno
will be already in support phase II by the time Fedora 22 is
released[2]
We have a window of opportunity to push Kilo to Fedora 22 before it
freezes for Beta end of the month[3]
Advantage would be that we'll get fresh OpenStack release in Fedora 22
at the cost of skipping one OpenStack release in Fedora and dropping
RDO Juno for Fedora 21.
I'd like to hear from users if that's acceptable. Assumption here is
that Fedora users are mainly developers who are already following Kilo
development while stable production is on EL platforms.
We would keep RDO Juno for EL7 (and EL6 which is in the works) by
moving current f22 dist-git branches to github/openstack-packages
rpm-juno branches and eventually to CentOS CloudSIG dist-git when
that's ready.
Kilo3 import would be then finished on Fedora master and merged to f22
early next week.
Please provide feedback quickly if this plan is acceptable, we need to
execute it before March 31st.
Cheers,
Alan
[1] https://fedoraproject.org/wiki/OpenStack#OpenStack
[2] https://wiki.openstack.org/wiki/StableBranch#Support_phases
[3] https://fedoraproject.org/wiki/Releases/22/Schedule
9 years, 7 months
[Rdo-list] rdo kilo builds
by whayutin
On Centos-7.0
Currently failing w/
00:35:08.440 ERROR : Error appeared during Puppet run:
172.16.32.6_glance.pp
00:35:08.440 Notice: /Stage[main]/Glance::Registry/Exec[glance-manage
db_sync]/returns: ImportError: No module named semantic_version
[0;36mDebug: Executing 'glance-manage
--config-file=/etc/glance/glance-registry.conf db_sync'[0m
[mNotice: /Stage[main]/Glance::Registry/Exec[glance-manage
db_sync]/returns: /usr/lib/python2.7/site-packages/glance/db/sqlalchemy/artifacts.py:20: DeprecationWarning: The oslo namespace package is deprecated. Please use oslo_config instead.[0m
[mNotice: /Stage[main]/Glance::Registry/Exec[glance-manage
db_sync]/returns: from oslo.config import cfg[0m
[mNotice: /Stage[main]/Glance::Registry/Exec[glance-manage
db_sync]/returns: /usr/lib/python2.7/site-packages/glance/db/sqlalchemy/artifacts.py:21: DeprecationWarning: The oslo namespace package is deprecated. Please use oslo_db instead.[0m
[mNotice: /Stage[main]/Glance::Registry/Exec[glance-manage
db_sync]/returns: from oslo.db import exception as db_exc[0m
[mNotice: /Stage[main]/Glance::Registry/Exec[glance-manage
db_sync]/returns: Traceback (most recent call last):[0m
[mNotice: /Stage[main]/Glance::Registry/Exec[glance-manage
db_sync]/returns: File "/usr/bin/glance-manage", line 6, in
<module>[0m
[mNotice: /Stage[main]/Glance::Registry/Exec[glance-manage
db_sync]/returns: from glance.cmd.manage import main[0m
[mNotice: /Stage[main]/Glance::Registry/Exec[glance-manage
db_sync]/returns: File
"/usr/lib/python2.7/site-packages/glance/cmd/manage.py", line 50, in
<module>[0m
[mNotice: /Stage[main]/Glance::Registry/Exec[glance-manage
db_sync]/returns: from glance.db import migration as
db_migration[0m
[mNotice: /Stage[main]/Glance::Registry/Exec[glance-manage
db_sync]/returns: File
"/usr/lib/python2.7/site-packages/glance/db/migration.py", line 29, in
<module>[0m
[mNotice: /Stage[main]/Glance::Registry/Exec[glance-manage
db_sync]/returns: from glance.db.sqlalchemy import api as db_api[0m
[mNotice: /Stage[main]/Glance::Registry/Exec[glance-manage
db_sync]/returns: File
"/usr/lib/python2.7/site-packages/glance/db/sqlalchemy/api.py", line 43,
in <module>[0m
[mNotice: /Stage[main]/Glance::Registry/Exec[glance-manage
db_sync]/returns: from glance.db.sqlalchemy import artifacts[0m
[mNotice: /Stage[main]/Glance::Registry/Exec[glance-manage
db_sync]/returns: File
"/usr/lib/python2.7/site-packages/glance/db/sqlalchemy/artifacts.py",
line 31, in <module>[0m
[mNotice: /Stage[main]/Glance::Registry/Exec[glance-manage
db_sync]/returns: from glance.common import semver_db[0m
[mNotice: /Stage[main]/Glance::Registry/Exec[glance-manage
db_sync]/returns: File
"/usr/lib/python2.7/site-packages/glance/common/semver_db.py", line 16,
in <module>[0m
[mNotice: /Stage[main]/Glance::Registry/Exec[glance-manage
db_sync]/returns: import semantic_version[0m
[mNotice: /Stage[main]/Glance::Registry/Exec[glance-manage
db_sync]/returns: ImportError: No module named semantic_version[0m
[1;31mError: /Stage[main]/Glance::Registry/Exec[glance-manage db_sync]:
Failed to call refresh: glance-manage
--config-file=/etc/glance/glance-registry.conf db_sync returned 1
instead of one of [0][0m
[1;31mError: /Stage[main]/Glance::Registry/Exec[glance-manage db_sync]:
glance-manage --config-file=/etc/glance/glance-registry.conf db_sync
returned 1 instead of one of [0][0m
9 years, 8 months
[Rdo-list] RDO/OpenStack meetups coming up (March 30, 2015)
by Rich Bowen
The following are the meetups I'm aware of in the coming week where
OpenStack and/or RDO enthusiasts are likely to be present. If you know
of others, please let me know, and/or add them to
http://rdoproject.org/Events
If there's a meetup in your area, please consider attending. If you
attend, please consider taking a few photos, and possibly even writing
up a brief summary of what was covered.
--Rich
* Monday, March 30 in Tel Aviv-Yafo, IL: Deploying Cinder in Production
with Avishay Traeger, Stratoscale -
http://www.meetup.com/OpenStack-Israel/events/220597849/
* Monday, March 30 in Garden City, ID, US: Cloud Database-as-Service
with CEO of Tesora -
http://www.meetup.com/Boise-Cloud-Computing-Meetup/events/220929678/
* Tuesday, March 31 in Amsterdam, NL: Ceph Day Amsterdam -
http://www.meetup.com/Openstack-Amsterdam/events/220888847/
* Tuesday, March 31 in Brisbane, AU: OpenShift Hack Night -
http://www.meetup.com/Brisbane-OpenShift-Group/events/220961631/
* Tuesday, March 31 in Roma, RM, IT: Spring OpenStack meetup: fueled and
containerized -
http://www.meetup.com/OpenStack-User-Group-Italia/events/220588968/
* Tuesday, March 31 in Budapest, HU: OpenStack 2015 mar -
http://www.meetup.com/OpenStack-Hungary-Meetup-Group/events/220145792/
* Wednesday, April 01 in Richardson, TX, US: April OpenStack Meetup -
PLUMgrid networking in OpenStack -
http://www.meetup.com/OpenStack-DFW/events/218264002/
* Wednesday, April 01 in Buenos Aires, AR: OpenStack LATAM hangout #2 -
http://www.meetup.com/openstack-argentina/events/221486465/
* Thursday, April 02 in Seattle, WA, US: OpenStack Seattle Meetup:
Getting the Most out of Cinder -
http://www.meetup.com/OpenStack-Seattle/events/219193094/
* Thursday, April 02 in San Francisco, CA, US: South Bay OpenStack
Meetup, Beginner track - http://www.meetup.com/openstack/events/214328702/
* Thursday, April 02 in Whittier, CA, US: Introduction to Red Hat and
OpenShift (cohost with OC MongoDB UG) -
http://www.meetup.com/Southern-California-Red-Hat-User-Group-RHUG/events/...
* Monday, April 06 in Durham, NC, US: April Meetup: “I Can Haz Moar
Networks?” w/Midokura & Cumulus Networks -
http://www.meetup.com/Triangle-OpenStack-Meetup/events/221188847/
--
Rich Bowen - rbowen(a)redhat.com
OpenStack Community Liaison
http://rdoproject.org/
9 years, 8 months
[Rdo-list] Split openstack-glance into openstack-glance-{aip, registry}
by Flavio Percoco
Hi Folks,
It was brought to my attention that Glance is still being shipped as
a single package, despite it being possible to have the services
within it running in separate servers. That is, Glance could,
architecture wise, be split.
Historically, this was not done because the requirements for
glance-api and glance-registry had always been the same. Both services
were required and the config files never differed.
However, after making glance-registry an optional service and the
introduction of glance-store, it might make sense to have both
packages split now.
The reason is that whenever I'd like to install glance-registry, I do
not need glance-store and other runtime dependencies it pulls in. In
addition, it'd allow us to have a clearer distribution of
configuration files distro-wise. Last but not least, it'd help on
keeping a clear understanding on what's running where.
Code wise, the packages would be the same. The main difference between
them would be the services/commands registered/installed.
Thoughts? Does this sound feasible/good to the folks in this list?
Cheers,
Flavio
--
@flaper87
Flavio Percoco
9 years, 8 months
[Rdo-list] [neutron] dibbler: new Fedora package review needed
by Ihar Hrachyshka
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi all,
Neutron will need a new daemon to support IPv6 prefix delegation
feature that is planned for early Liberty, dibbler (which is all of:
client, relay, and server that support dhcpv6 prefix delegation). I've
sent the package for Fedora review [1].
Upstream is eagerly waiting for the package to reach Fedora repos, so
that we're able to run integration tests in gate. Without the package,
we're left with unit tests only that mock out actual dibbler mechanism.
Please review in case you have corresponding permissions.
[1]: https://bugzilla.redhat.com/show_bug.cgi?id=1206639
Thanks in advance,
/Ihar
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAEBAgAGBQJVFXjIAAoJEC5aWaUY1u57+hEIAKk+Vbkgf/g8CW/yICdWrQPk
lyPax8txg6FfXLTtwLd1vDzhrA3CIL1f+88GJwz6uac7I9GNGuYVbnv/q6ho7KFz
cXiMfzbuoGlxZdmOjEd4Oi1yLEoSXQr5VYMNgrhXmud5bvfp+PLb5Gkj0vjTlrf8
KkOfB9SJlxb1pyNUmdtSDKA+7nOOUpCw9VYEYAiZiqzHfN1vy49E6VMUtbYbXM+u
upRYs8bA+1921kq8ms6bW5hnCxlmvpMI3hvyCO1FyVoQanVnVX/L7D28dJ33Gzns
bXxm+kdPNFgvv1XSrG1l5aHven8GBPaae5Z3TeJvusZwjqBNRSQDJ6tXgYr9Iko=
=Dlpl
-----END PGP SIGNATURE-----
9 years, 8 months
