[Rdo-list] Deploying RDO using Foreman
by Arash Kaffamanesh
Hi,
I posted a question regarding "Deploying RDO using Foreman" to
ask.openstack.org and thanks to Keshyap and Rich which engaged me to
proceed further, I updated the thread here:
https://ask.openstack.org/en/question/12104/deploying-rdo-using-foreman/
The post might be too long, here some more information about the reason
behind my question and some more questions:
I'm trying to learn Foreman for installing OpenStack and use it to deploy
RDO on top of RDO to provide some kind of OpenStack training / webinars and
later to run the whole thing on 6-8 bare metal machines and use it to
deploy OpenShift and write a tutorial about the whole thing and post it on
the RDO site, LinkedIn, etc.
About our BASE RDO environment:
Our RDO based 3 node environment is thanks to the latest update very stable
and very fast now and I've to thank all of you smart guys for doing such a
great work!
Our environment uses VLAN and the Foreman RDO installation shall use GRE
and Qemu (or LXC / Docker) to let us play with the whole thing and write a
tutorial about the whole thing.
So my questions:
Does the Foreman installation on top of a virtualized environment work at
all? (I guess yes)
Could a VLAN based BASE-Install be a problem to succeed with this scenario
(to have GRE on top of VLAN)? (I guess no)
Has someone tried such a scenario before? (I guess yes)
Could I use LXC / Docker instead Qemu?
Thanks in advance for any help / advice!
Arash
10 years, 1 month
[Rdo-list] RDO Icehouse milestone 3 test day, March 25th, 26th
by Rich Bowen
As Kashyap mentioned earlier today, there were some failures in the
build system that have brought us to decide to reschedule the test day
for next week, when we can be assured of more solid packages, and a more
successful, productive test day experience.
As before, the relevant URLs are:
The full test day information is at
http://openstack.redhat.com/RDO_test_day_Icehouse_milestone_3
The test day tool is at
http://testdays.qa.fedoraproject.org/testdays/show_event?event_id=16
where you can see what tests need to be done, and leave your notes.
If you wish to add more tests, or enhance the instructions for an
existing test, both of these are in wikis, and can be edited directly.
The testcases are listed at
https://fedoraproject.org/wiki/Test_Day:2014-03-19_RDOMetadata (Required
a Fedora account, as we're using their test infrastructure for this.)
and the test instructions are linked next to each test case.
If you want to help get the word out about our rescheduling, please RT
the tweet from @RDOCommunity, or tweet:
Come help test the @RDOCommunity #openstack packages. Test day
rescheduled for March 25, 26.
http://openstack.redhat.com/RDO_test_day_Icehouse_milestone_3
Thanks!
--
Rich Bowen - rbowen(a)redhat.com
OpenStack Community Liaison
http://openstack.redhat.com/
10 years, 1 month
[Rdo-list] Reminder: RDO Test Day March 19-20
by Rich Bowen
A reminder: We'll be doing an RDO test day for the Icehouse Milestone 3,
next week, March 19-20.
This time around we're using the Fedora Test Day infrastructure, to make
it easier to report your test results.
Details about the test day are in the RDO wiki at
http://openstack.redhat.com/RDO_test_day_Icehouse_milestone_3
The test cases that you'll want to run are listed at
http://testdays.qa.fedoraproject.org/testdays/show_event?event_id=16 and
that's also the interface where you'll enter your test results as you go.
If you'd like to help augment the list of tests, and the instructions
that go with them, those can be edited at
https://fedoraproject.org/wiki/Test_Day:2014-03-19_RDOMetadata or you
can send updated directly to me.
If you'd like to help get the word out via Twitter, Facebook, Google+ or
whatever, you'll probably want to use the first of those three URLs. You
could, for example, tweet:
Join us to help test the @RDOCommunity packaging of the @OpenStack
Icehouse Milestone 3, March 19 and 20 -
http://openstack.redhat.com/RDO_test_day_Icehouse_milestone_3
(Thanks for helping us get the word out.)
--
Rich Bowen - rbowen(a)rcbowen.com - @rbowen
http://apachecon.com/ - @apachecon
10 years, 1 month
[Rdo-list] Installing RDO w/ Foreman + icehouse and ml2 plugin
by Andrew Lau
Hi all,
So far, I've been successful with the following setup on havana, but
icehouse had issue as below:
1x Controller
2x Compute + Network + Gluster
I forked the astapor repo so I can run the compute + networker in the same
module, along with a few other tweaks. [1]
So far everything is working, I plan on uploading my notes in a few days
but I've run into a few issues which I'm hoping someone could help:
- When using the icehouse repo, the controller hostgroup will install but
httpd will fail with 'no listening sockets available, shutting down, Unable
to open logs'. There were no selinux denies, or anything else in the log
files.
- From a brief look at the manifest and trial and error, it looks like the
ml2 plugin does have some support in the quickstack files. It however fails
at the neutron-db-manage. Manual steps: [2]
Error Output: [3]
I'm aware there's a few new projects going on to bridge the foreman and rdo
integration, I like the current foreman setup because it's very
customizable, but the key flaws are too many options. ie. if I'm using
VLANs, I don't want to see tunnel options etc.
Thanks,
Andrew.
[1] https://github.com/andrewklau/astapor
[2] http://openstack.redhat.com/ML2_plugin
[3] http://www.fpaste.org/85834/94970823/
10 years, 1 month
[Rdo-list] metadata service issue
by Xin Zhao
Hello,
On my newly installed grizzly testbed, which has one controller, one
network host (quantum/ovs) and one compute node, there is an issue with
metadata service:
From the instance, its routing table looks like this:
[root@host-172-16-0-8 ~]# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
172.16.0.0 0.0.0.0 255.255.252.0 U 0 0 0 eth0
169.254.0.0 0.0.0.0 255.255.0.0 U 1002 0 0 eth0
0.0.0.0 172.16.0.1 0.0.0.0 UG 0 0 0 eth0
And metadata service is not reachable, the curl command complains about
"no route to 169.254.169.254".
After deleting the 169.254.0.0/16 entry from the routing table, the
metadata service works.
Why would quantum append the 169.254.0.0 route into the routing table of
the VM instance ? I have enable_isolated_metadata set to False in the
dhcp_agent.ini.
Thanks,
Xin
10 years, 1 month
[Rdo-list] neutron Flatnetwork config with two nics port status is always down
by Yogesh Bhanu
Hi ,
I have a two node setup with two nics:
eth0 -- Intranet - br-ex
eth1 -- Management - br-int
Node1 acts as:
Controller
Network
Storage
Compute
Node2 acts as:
Compute
I have followed the guidelines of using packstack with vlan and modifying
/etc/neutron/plugins/openvswitch/ovs_neutron_plugin.ini to:
[OVS]
tenant_network_type=none
enable_tunneling=False
integration_bridge=br-int
network_vlan_ranges = physnet1
bridge_mappings = physnet1:br-ex
vxlan_udp_port=4789
- restart the neutron-server service
- define a network/subnet
neutron net-create vm-ext --shared --provider:network_type flat
--provider:physical_network physnet1
neutron subnet-create --name vm-ext-intra --gateway 192.168.10.1
--dns-nameserver 192.168.10.0 --allocation-pool
start=192.168.10.231,end=192.168.10.249 vm-ext 192.168.10.0/24
neutron subnet-update vm-ext-intra --enable_dhcp False
- I can start a VM instance but I'm not able to access the VMs from
my Intranet.
- IP gets associated with the VM but the port status is alwaysdown
Question: Is it possible to set the port status Up and if yes How?
neutron port-show 824fc086-841d-48af-906b-ceeb3ea83510
+-----------------------+-----------------------------------------------------------------------------------+
| Field | Value |
+-----------------------+-----------------------------------------------------------------------------------+
| admin_state_up | True |
| allowed_address_pairs | |
| binding:capabilities | {"port_filter":
true} |
| binding:host_id | rhc02 |
| binding:vif_type | ovs |
| device_id | 08ebc2b6-1500-4140-82e2-4acec52e4cac |
| device_owner | compute:None |
| extra_dhcp_opts | |
| fixed_ips | {"subnet_id":
"2f45cc95-05d8-4d8e-bb0a-e21884a9df2a", "ip_address": "192.168.10.231"} |
| id | 824fc086-841d-48af-906b-ceeb3ea83510 |
| mac_address | fa:16:3e:a2:a2:05 |
| name | |
| network_id | 2a981f3a-2df1-4d53-bfcb-4750902400ca |
| security_groups | fa6850a7-cf87-447e-b83d-1f99b9eef94a |
| status | DOWN |
| tenant_id | c620b9e73cd24d52b1a0c4b9803d056f |
+-----------------------+-----------------------------------------------------------------------------------+
Thanks in advance
10 years, 1 month
[Rdo-list] can't access quantum API from network host
by Xin Zhao
Hello,
I am re-installing a multi-host grizzly cluster, using quantum/OVS.
One thing strange is that quantum commands, like "quantum net-list",
fail to run on the network host, returned "403 Forbidden" error message.
But using the same admin credential, the quantum commands work from the
controller node.
It used to work before, with my previous install. Should I be worried
about it ? Any suggestions on where to start to debug this?
Thanks,
Xin
10 years, 1 month
