9:10 a.m.
I received the following feedback from a user. Not sure if Daniel is on
this list to answer followup questions, but I'll encourage him to join.
--Rich
-------- Original Message --------
Date: Tue, 25 Feb 2014 12:39:01 +0800
From: Daniel Veillard <veillard(a)redhat.com>
BTW I installed RDO from scratch on a CentOS 6.5 box 2 weeks ago,
The Good:
1/ the instruction worked, no tweaking, packstack did work
even with the horrible connection I'm having at the moment
2/ the setup instructions are clear and simple
http://openstack.redhat.com/Quickstart
however it should be made clear that the host where the
installation is done should have a fully qualified DNS name
as that's one of the small issue I hit, and people doing testing
are likely to do it on machines without that set up
3/ I got the console working just fine
The Less Good:
Creating a CentOS test instance should be no more than an
additional 2 steps, it wasn't
http://openstack.redhat.com/Running_an_instance
Step 1 if CONTROL_NODE is not the IP (previous document referenced
an iP) then one need to pass a FQDN, in my case
http://test/dashboard fails with
"Openstack dashboard Something went wrong an unexpected error
has occured ..."
http://test.veillard.com/dashboard works
http://http://192.168.0.12/dashboard works
So either make sure the FQDN is part of the requirement in step 0
or like for the quickstart use $YOURIP that will also be coherent
=> I wonder how many get stuck at that step thinking their
installation is broken
Step 2 and 3 just fine
Step 4:
that's another issue, the default is a Fedora image, and that
worked fine but for CentOS i had to
- click the image resource link
- then follow CentOS 6.5 images
one end up at
http://repos.fedorapeople.org/repos/openstack/guest-images/
a CentOs image, one month old, hosted on Fedora, with no checksum
no README, etc ...
I do think that
http://openstack.redhat.com/Image_resources
need to be updated to point to a real web page, on the CentOS project
with a current image and followup instruction dedicated to people
who were following the RDO instructions
In comparison the http://cloud-images.ubuntu.com/ link for
"Ubuntu cloud images" at least has some pointers, we can do way
better and streamline for an RDO setup
Step 5:
Launch the instance instruction failed for me, just providing a
name was not sufficient, the error was
"At least one network must be specified."
it got me to the Networking tab and i had to pick the private
network from the available networks only selection, then launch
worked
Step 6:
it looks like it worked and got a 172.24.4.127 IP, but the instance
still says "IP address 10.0.0.3" , and trying in step 7 to ssh
to 172.24.4.127 failed, both from the remote workstation and
when logged as root
Then messed up creating a local pool of IPs as suggested at
http://openstack.redhat.com/Floating_IP_range
but tuned to the local IP address, registering the network was fine
but it never seems used when trying to associate a floating IP to
the instance.
=> IMHO we need to fix quite a few things so that instructions work
out of the box up to running and ssh'ing to a CentOS instance.
Rich, are you able to sort and fix those points at least up to
networking setup ?
KB, do we have a page with QCow2 ready CentOS image on the centos site
that we could link to, and provide RDO tuned instructions ?
Daniel
10:48 a.m.
New subject: [Rdo-list] Feedback on RDO install
... and my reply to Daniel (reposted here):
Daniel Veillard wrote:
<snip>
The Less Good:
Creating a CentOS test instance should be no more than an
additional 2 steps, it wasn't
http://openstack.redhat.com/Running_an_instance
<snip>
Step 5:
Launch the instance instruction failed for me, just providing a
name was not sufficient, the error was
"At least one network must be specified."
it got me to the Networking tab and i had to pick the private
network from the available networks only selection, then launch
worked
With the move to Neutron, a certain number of things which should be
done automatically are not done:
1) Set up an internal network & subnet for guests (I believe this is
automatically done by Packstack now)
2) Create a default router and attach the internal subnet to it
3) (not sure if this can be done automatically, or whether it needs to
be a post-install config step) Attach the external network as the
gateway for the router, and create some floating IP addresses outside
any DHCP range on the public network to associate with newly created
instances
Step 6:
it looks like it worked and got a 172.24.4.127 IP, but the instance
still says "IP address 10.0.0.3" , and trying in step 7 to ssh
to 172.24.4.127 failed, both from the remote workstation and
when logged as root
Then messed up creating a local pool of IPs as suggested at
http://openstack.redhat.com/Floating_IP_range
but tuned to the local IP address, registering the network was fine
but it never seems used when trying to associate a floating IP to
the instance.
I think this is network namespace related: routing from an int to ext
network isn't automatically done, you either need to create an L3 router
and connect the networks to it, and/or ensure that your local IP address
is routing directly to the instance via the router.
Cheers,
Dave.
--
Dave Neary - Community Action and Impact
Open Source and Standards, Red Hat - http://community.redhat.com
Ph: +33 9 50 71 55 62 / Cell: +33 6 77 01 92 13
11:04 a.m.
New subject: [Rdo-list] Feedback on RDO install
On Tue, Feb 25, 2014 at 05:48:15PM +0100, Dave Neary wrote:
1) Set up an internal network & subnet for guests (I believe this
is
automatically done by Packstack now)
This is done for --allinone installs, but not otherwise.
2) Create a default router and attach the internal subnet to it
And also this.
3) (not sure if this can be done automatically, or whether it needs
to
be a post-install config step) Attach the external network as the
gateway for the router, and create some floating IP addresses outside
any DHCP range on the public network to associate with newly created
instances
And this isn't done either. Generally, the Quickstart instructions
end before there is functional external connectivity, and the existing
documentation for setting that up is a little sketchy.
I was hoping to tackle some of this in the next week.
--
Lars Kellogg-Stedman <lars(a)redhat.com> | larsks @ irc
Cloud Engineering / OpenStack | " " @ twitter
9:25 p.m.
New subject: [Rdo-list] Feedback on RDO install
On Tue, Feb 25, 2014 at 12:04:44PM -0500, Lars Kellogg-Stedman wrote:
On Tue, Feb 25, 2014 at 05:48:15PM +0100, Dave Neary wrote:
> 1) Set up an internal network & subnet for guests (I believe this is
> automatically done by Packstack now)
This is done for --allinone installs, but not otherwise.
> 2) Create a default router and attach the internal subnet to it
And also this.
yes, i got the private 10.0.0.0 network setup, a public one and a
bridge between the two.
> 3) (not sure if this can be done automatically, or whether it
needs to
> be a post-install config step) Attach the external network as the
> gateway for the router, and create some floating IP addresses outside
> any DHCP range on the public network to associate with newly created
> instances
And this isn't done either. Generally, the Quickstart instructions
end before there is functional external connectivity, and the existing
documentation for setting that up is a little sketchy.
I was hoping to tackle some of this in the next week.
At that point i tried various things to have the 'public' network
allocate IPs in the range of my local LAN, I tried for example
[root@test ~(keystone_admin)]# nova floating-ip-bulk-delete 10.3.4.0/22
[root@test ~(keystone_admin)]# nova floating-ip-bulk-create 192.168.0.56/29
[root@test ~(keystone_admin)]# nova-manage floating list
2014-02-25 12:22:55.983 13516 DEBUG nova.openstack.common.lockutils
[req-854a5ff1-baf3-43b3-b381-d23966d7ea04 None None] Got semaphore
"dbapi_backend" lock
/usr/lib/python2.6/site-packages/nova/openstack/common/lockutils.py:166
2014-02-25 12:22:56.006 13516 DEBUG nova.openstack.common.lockutils
[req-854a5ff1-baf3-43b3-b381-d23966d7ea04 None None] Got semaphore /
lock "__get_backend" inner
/usr/lib/python2.6/site-packages/nova/openstack/common/lockutils.py:245
None 192.168.0.57 None nova eth0
None 192.168.0.58 None nova eth0
None 192.168.0.59 None nova eth0
None 192.168.0.60 None nova eth0
None 192.168.0.61 None nova eth0
None 192.168.0.62 None nova eth0
[root@test ~(keystone_admin)]#
then i disasociated the floating IP of my guest which were allocated
as 172.24.4.127 and tried to reallocate a floating IP but that didn't
work it still picked 172.24.4.x
Then I tried to create another public network matching my range
and create a router from the private network, the operations worked
at the interface level but I still cound not associate my instance
interface to it.
So right now I can create guests, I can't ssh to them, and I have
no root password to log from the console (which works), it's a bit
frustrating.
Someone who understands the basic operations needed to have the
default created public network allocate IPs in the range of the user
network should document those operations, it should be added to
the RDO setup page, because as is even if the setup worked it's not
really functional :)
And I'm just fine playing the guinea pig !
thanks,
Daniel
--
Daniel Veillard | Open Source and Standards, Red Hat
veillard(a)redhat.com | libxml Gnome XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | virtualization library http://libvirt.org/
2:11 a.m.
New subject: [Rdo-list] Feedback on RDO install
On Wed, Feb 26, 2014 at 11:25:34AM +0800, Daniel Veillard wrote:
On Tue, Feb 25, 2014 at 12:04:44PM -0500, Lars Kellogg-Stedman
wrote:
> On Tue, Feb 25, 2014 at 05:48:15PM +0100, Dave Neary wrote:
[. . .]
At that point i tried various things to have the 'public'
network
allocate IPs in the range of my local LAN, I tried for example
[root@test ~(keystone_admin)]# nova floating-ip-bulk-delete 10.3.4.0/22
[root@test ~(keystone_admin)]# nova floating-ip-bulk-create 192.168.0.56/29
[root@test ~(keystone_admin)]# nova-manage floating list
2014-02-25 12:22:55.983 13516 DEBUG nova.openstack.common.lockutils
[req-854a5ff1-baf3-43b3-b381-d23966d7ea04 None None] Got semaphore
"dbapi_backend" lock
/usr/lib/python2.6/site-packages/nova/openstack/common/lockutils.py:166
2014-02-25 12:22:56.006 13516 DEBUG nova.openstack.common.lockutils
[req-854a5ff1-baf3-43b3-b381-d23966d7ea04 None None] Got semaphore /
lock "__get_backend" inner
/usr/lib/python2.6/site-packages/nova/openstack/common/lockutils.py:245
None 192.168.0.57 None nova eth0
None 192.168.0.58 None nova eth0
None 192.168.0.59 None nova eth0
None 192.168.0.60 None nova eth0
None 192.168.0.61 None nova eth0
None 192.168.0.62 None nova eth0
[root@test ~(keystone_admin)]#
then i disasociated the floating IP of my guest which were allocated
as 172.24.4.127 and tried to reallocate a floating IP but that didn't
work it still picked 172.24.4.x
Then I tried to create another public network matching my range
and create a router from the private network, the operations worked
at the interface level but I still cound not associate my instance
interface to it.
So right now I can create guests, I can't ssh to them, and I have
no root password to log from the console (which works), it's a bit
frustrating.
You may want to check if you have SSH (and ICMP) security group
rules are correctly added[1].
Someone who understands the basic operations needed to have the
default created public network allocate IPs in the range of the user
network should document those operations, it should be added to
the RDO setup page, because as is even if the setup worked it's not
really functional :)
Thanks for taking time to try this. I see that you're using Nova
network.
FWIW, in my testing, I use Neutron networking (in a manually configured
2-node setup -- this helps for my nature of work involving a lot of
debugging). I'd like to outline the flow here, in case if you/someone
would like to try Neutron at some point:
Concept of tenant (now renamed to 'project') network: User-A can have
his/her own IP-namespace, private subnets while a User-B can _also_ have
his/her own isoloated set of IP namespace, subnets, iptables namespace.
Networks, subnets, routers creation
-----------------------------------
Once Neutron configured, and its services are running, then the below
applies:
1. Create a Keystone tenant called 'demoten1'.
2. Then, a Keystone user called 'tuser1' and associates it to the
'demoten1'.
3. Creates a Keystone RC file for the user (tuser1) and sources it.
4. Creates a new private network called 'priv-net1'.
5. Creates a new private subnet called 'priv-subnet1' on 'priv-net1'.
6. Creates a router called 'trouter1'.
7. Associates the router (trouter1 in this case) to an existing
external network (the script assumes it’s called as ext) by setting
it as its gateway.
8. Associates the private network interface (priv-net1) to the router
(trouter1).
9. Adds Neutron security group rules for this test tenant (demoten1)
for ICMP and SSH.
There's a blog-post here[2] with all the commands noted for the above
steps. Also, my iptables rules are here[3], at the end of the page.
[1] http://docs.openstack.org/user-guide/content/configure_security_groups_ru...
[2] http://kashyapc.com/2013/12/13/script-to-create-neutron-tenant-networks/
[3]
http://kashyapc.fedorapeople.org/virt/openstack/neutron-configs-GRE-OVS-t...
--
/kashyap
3928
days inactive
3929
days old
4 comments
5 participants
participants (5)
-
Daniel Veillard -
Dave Neary -
Kashyap Chamarthy -
Lars Kellogg-Stedman -
Rich Bowen