[Rdo-list] Attempt to reproduce Getting Started with Multi-Node OpenStack RDO Havana + Gluster Backend + Neutron VLAN by Andrew Lau on F19
6:02 a.m.
Original document
http://www.andrewklau.com/getting-started-with-multi-node-openstack-rdo-h...
contains the sample of answer file. In my situation p37p1 is eth0
p4p1 is eth1 and I've tried to make a substitution in answer-file .
packstack fails with error :
Welcome to Installer setup utility
Packstack changed given value to required value /root/.ssh/id_rsa.pub
Packstack changed given value 192.168.1.137:/CINDER-VOLUMES to required value
'192.168.1.137:/CINDER-VOLUMES'
Installing:
Clean Up... [ DONE ]
Setting up ssh keys... [ DONE ]
Discovering hosts' details... [ DONE ]
Adding pre install manifest entries... [ DONE ]
Installing time synchronization via NTP... [ DONE ]
Adding MySQL manifest entries... [ DONE ]
Adding QPID manifest entries... [ DONE ]
Adding Keystone manifest entries... [ DONE ]
Adding Glance Keystone manifest entries... [ DONE ]
Adding Glance manifest entries... [ DONE ]
Installing dependencies for Cinder... [ DONE ]
Adding Cinder Keystone manifest entries... [ DONE ]
Adding Cinder manifest entries... [ DONE ]
Adding Nova API manifest entries... [ DONE ]
Adding Nova Keystone manifest entries... [ DONE ]
Adding Nova Cert manifest entries... [ DONE ]
Adding Nova Conductor manifest entries... [ DONE ]
Adding Nova Compute manifest entries... [ DONE ]
Adding Nova Scheduler manifest entries... [ DONE ]
Adding Nova VNC Proxy manifest entries... [ DONE ]
Adding Nova Common manifest entries... [ DONE ]
Adding Openstack Network-related Nova manifest entries...[ DONE ]
Adding Neutron API manifest entries... [ DONE ]
Adding Neutron Keystone manifest entries... [ DONE ]
Adding Neutron L3 manifest entries... [ DONE ]
Adding Neutron L2 Agent manifest entries... [ DONE ]
Adding Neutron DHCP Agent manifest entries... [ DONE ]
Adding Neutron LBaaS Agent manifest entries... [ DONE ]
Adding Neutron Metadata Agent manifest entries... [ DONE ]
Adding OpenStack Client manifest entries... [ DONE ]
Adding Horizon manifest entries... [ DONE ]
Adding Heat manifest entries... [ DONE ]
Adding Heat Keystone manifest entries... [ DONE ]
Adding Ceilometer manifest entries... [ DONE ]
Adding Ceilometer Keystone manifest entries... [ DONE ]
Adding post install manifest entries... [ DONE ]
Preparing servers... [ DONE ]
Installing Dependencies... [ DONE ]
Copying Puppet modules and manifests... [ DONE ]
Applying Puppet manifests...
Applying 192.168.1.127_prescript.pp
Applying 192.168.1.137_prescript.pp
192.168.1.127_prescript.pp : [ DONE ]
192.168.1.137_prescript.pp : [ DONE ]
Applying 192.168.1.127_ntpd.pp
Applying 192.168.1.137_ntpd.pp
192.168.1.137_ntpd.pp : [ DONE ]
192.168.1.127_ntpd.pp : [ DONE ]
Applying 192.168.1.137_mysql.pp
Applying 192.168.1.137_qpid.pp
192.168.1.137_mysql.pp : [ DONE ]
192.168.1.137_qpid.pp : [ DONE ]
Applying 192.168.1.137_keystone.pp
Applying 192.168.1.137_glance.pp
Applying 192.168.1.137_cinder.pp
192.168.1.137_keystone.pp : [ DONE ]
192.168.1.137_glance.pp : [ DONE ]
192.168.1.137_cinder.pp : [ DONE ]
Applying 192.168.1.137_api_nova.pp
192.168.1.137_api_nova.pp : [ DONE ]
Applying 192.168.1.137_nova.pp
Applying 192.168.1.127_nova.pp
192.168.1.137_nova.pp : [ DONE ]
192.168.1.127_nova.pp : [ DONE ]
Applying 192.168.1.127_neutron.pp
Applying 192.168.1.137_neutron.pp
[ ERROR ]
ERROR : Error appeared during Puppet run: 192.168.1.127_neutron.pp
Error: Validate method failed for class sleep: implicit argument passing of super from
method defined by define_method() is not supported. Specify all arguments explicitly.
Disabling Fedora native Ethernet names and switch to eth0 & eth1 on F19 gives same
error.
This make an impression that only `packstack --allinone` could work on F19 . I just
cannot configure Neutron on
Compute Node with native fedora's ethernet names. It works fine on CentOS 6.4
I would guess that same question would come up for oVirt 3.3.2 Neutron provider on F19
boxes.
How create a server , how create Neutron plugin for oVirt ?
My question is :-
How would look Andrew's
https://gist.github.com/andrewklau/7622535/raw/7dac55bbecc200cfb4bf040b61...
for Fedora 19 ?
5:03 p.m.
On 12/23/2013 12:02 PM, Boris Derzhavets wrote:
Original document
http://www.andrewklau.com/getting-started-with-multi-node-openstack-rdo-h...
contains the sample of answer file. In my situation p37p1 is eth0 p4p1 is eth1 and
I've tried to make a substitution in answer-file . packstack fails with error :
Applying 192.168.1.137_neutron.pp
[ ERROR ]
ERROR : Error appeared during Puppet run: 192.168.1.127_neutron.pp
Error: Validate method failed for class sleep: implicit argument passing of super from
method defined by define_method() is not supported. Specify all arguments explicitly.
What are the versions of packstack and puppet on your centos and Fedora 19 systems?
They should be the same if going from a pristine setup, but if not it would
be worth trying to match the F19 versions to the working centos one.
If they are in fact the same then it must come down to different
logic in the puppet modules for Fedora and EL systems, which we'd
need to look into.
You might get more indication of the particular error in:
/var/tmp/packstack/...neutron...log
thanks,
Pádraig.
4:28 a.m.
I have attached both logs. Traces are there.
My version on F19 :-
[root@openstack1 ~]# rpm -qa | grep openstack
openstack-ceilometer-common-2013.2.1-1.fc20.noarch
openstack-nova-compute-2013.2.1-2.fc20.noarch
openstack-nova-common-2013.2.1-2.fc20.noarch
openstack-nova-cert-2013.2.1-2.fc20.noarch
openstack-utils-2013.2-2.fc20.noarch
openstack-glance-2013.2.1-1.fc20.noarch
openstack-ceilometer-compute-2013.2.1-1.fc20.noarch
openstack-packstack-2013.2.1-0.25.dev936.fc20.noarch
openstack-nova-conductor-2013.2.1-2.fc20.noarch
openstack-nova-scheduler-2013.2.1-2.fc20.noarch
openstack-keystone-2013.2.1-1.fc20.noarch
openstack-nova-api-2013.2.1-2.fc20.noarch
openstack-nova-console-2013.2.1-2.fc20.noarch
openstack-nova-novncproxy-2013.2.1-2.fc20.noarch
openstack-cinder-2013.2.1-1.fc20.noarch
[root@openstack1 ~]# uname -a
Linux openstack1.localdomain 3.12.5-200.fc19.x86_64 #1 SMP Tue Dec 17 22:21:14 UTC 2013
x86_64 x86_64 x86_64 GNU/Linux
System on CentOS 6.4 doesn't belong to me. I am a bit hesitant to ask system's
admin too much
questions. I am sorry.
Boris.
Date: Mon, 23 Dec 2013 23:03:54 +0000
From: pbrady(a)redhat.com
To: bderzhavets(a)hotmail.com
CC: rdo-list(a)redhat.com
Subject: Re: [Rdo-list] Attempt to reproduce Getting Started with Multi-Node OpenStack
RDO Havana + Gluster Backend + Neutron VLAN by Andrew Lau on F19
On 12/23/2013 12:02 PM, Boris Derzhavets wrote:
> Original document
http://www.andrewklau.com/getting-started-with-multi-node-openstack-rdo-h...
> contains the sample of answer file. In my situation p37p1 is eth0 p4p1 is eth1 and
I've tried to make a substitution in answer-file . packstack fails with error :
> Applying 192.168.1.137_neutron.pp
>
[ ERROR ]
>
> ERROR : Error appeared during Puppet run: 192.168.1.127_neutron.pp
> Error: Validate method failed for class sleep: implicit argument passing of super
from method defined by define_method() is not supported. Specify all arguments
explicitly.
What are the versions of packstack and puppet on your centos and Fedora 19 systems?
They should be the same if going from a pristine setup, but if not it would
be worth trying to match the F19 versions to the working centos one.
If they are in fact the same then it must come down to different
logic in the puppet modules for Fedora and EL systems, which we'd
need to look into.
You might get more indication of the particular error in:
/var/tmp/packstack/...neutron...log
thanks,
Pádraig.
7:53 a.m.
Hey,
Rather than just dropping in my packstack file, try generate the default
answer file for Fedora and just modify the variables.
Merry Christmas!
Cheers
,
Andrew
On Tue, Dec 24, 2013 at 9:28 PM, Boris Derzhavets
<bderzhavets(a)hotmail.com>wrote:
I have attached both logs. Traces are there.
My version on F19 :-
[root@openstack1 ~]# rpm -qa | grep openstack
openstack-ceilometer-common-2013.2.1-1.fc20.noarch
openstack-nova-compute-2013.2.1-2.fc20.noarch
openstack-nova-common-2013.2.1-2.fc20.noarch
openstack-nova-cert-2013.2.1-2.fc20.noarch
openstack-utils-2013.2-2.fc20.noarch
openstack-glance-2013.2.1-1.fc20.noarch
openstack-ceilometer-compute-2013.2.1-1.fc20.noarch
openstack-packstack-2013.2.1-0.25.dev936.fc20.noarch
openstack-nova-conductor-2013.2.1-2.fc20.noarch
openstack-nova-scheduler-2013.2.1-2.fc20.noarch
openstack-keystone-2013.2.1-1.fc20.noarch
openstack-nova-api-2013.2.1-2.fc20.noarch
openstack-nova-console-2013.2.1-2.fc20.noarch
openstack-nova-novncproxy-2013.2.1-2.fc20.noarch
openstack-cinder-2013.2.1-1.fc20.noarch
[root@openstack1 ~]# uname -a
Linux openstack1.localdomain 3.12.5-200.fc19.x86_64 #1 SMP Tue Dec 17
22:21:14 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
System on CentOS 6.4 doesn't belong to me. I am a bit hesitant to ask
system's admin too much
questions. I am sorry.
Boris.
> Date: Mon, 23 Dec 2013 23:03:54 +0000
> From: pbrady(a)redhat.com
> To: bderzhavets(a)hotmail.com
> CC: rdo-list(a)redhat.com
> Subject: Re: [Rdo-list] Attempt to reproduce Getting Started with
Multi-Node OpenStack RDO Havana + Gluster Backend + Neutron VLAN by Andrew
Lau on F19
>
> On 12/23/2013 12:02 PM, Boris Derzhavets wrote:
> > Original document
http://www.andrewklau.com/getting-started-with-multi-node-openstack-rdo-h...
> > contains the sample of answer file. In my situation p37p1 is eth0 p4p1
is eth1 and I've tried to make a substitution in answer-file . packstack
fails with error :
>
> > Applying 192.168.1.137_neutron.pp
> > [ ERROR ]
> >
> > ERROR : Error appeared during Puppet run: 192.168.1.127_neutron.pp
> > Error: Validate method failed for class sleep: implicit argument
passing of super from method defined by define_method() is not supported.
Specify all arguments explicitly.
>
> What are the versions of packstack and puppet on your centos and Fedora
19 systems?
> They should be the same if going from a pristine setup, but if not it
would
> be worth trying to match the F19 versions to the working centos one.
>
> If they are in fact the same then it must come down to different
> logic in the puppet modules for Fedora and EL systems, which we'd
> need to look into.
>
> You might get more indication of the particular error in:
> /var/tmp/packstack/...neutron...log
>
> thanks,
> Pádraig.
_______________________________________________
Rdo-list mailing list
Rdo-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/rdo-list
8:18 a.m.
I did. But no eth0,eth1,eth2. There are em1,p37p1,p4p1 and under
/etc/sysconfig/network-scripts
[root@hv02 network-scripts]# ls -l
total 212
-rw-r--r--. 1 root root 102 Dec 24 15:22 ifcfg-enp2s0
-rw-r--r--. 1 root root 288 Dec 24 14:29 ifcfg-enp5s1
-rw-r--r--. 1 root root 288 Dec 24 14:29 ifcfg-enp5s2
-rw-r--r--. 1 root root 254 May 31 2013 ifcfg-lo
which are different from usual ifcfg-eth(X)
[root@hv02 network-scripts]# cat ifcfg-enp5s1
TYPE=Ethernet
BOOTPROTO=dhcp
DEFROUTE=yes
IPV4_FAILURE_FATAL=no
IPV6INIT=yes
IPV6_AUTOCONF=yes
IPV6_DEFROUTE=yes
IPV6_PEERDNS=yes
IPV6_PEERROUTES=yes
IPV6_FAILURE_FATAL=no
NAME=enp5s1
UUID=68e1cb5d-cafa-47e7-aa2e-1ce6d4632bfa
ONBOOT=no
HWADDR=00:E0:53:13:17:4C
PEERDNS=yes
PEERROUTES=yes
No DEVICE=p(XX)p(Y)
Only MAC address allows to understand what is what ?
Looks like parser gets confused working with ifcfg-enp* files
View also http://kashyapc.wordpress.com/tag/fedora/
Set up a bit different from yours , but with same idea Controller + Compute, is done
manually not via packstack with f20 core ( no Ethernet interfaces renaming just ifcfg-eth0
and etc )
Merry Christmas!
Thanks.
Boris.
P.S. I am currently testing CentOS 6.5. libgfapi should be backported :)
From: andrew(a)andrewklau.com
Date: Thu, 26 Dec 2013 00:53:42 +1100
Subject: Re: [Rdo-list] Attempt to reproduce Getting Started with Multi-Node OpenStack RDO
Havana + Gluster Backend + Neutron VLAN by Andrew Lau on F19
To: bderzhavets(a)hotmail.com
CC: pbrady(a)redhat.com; rdo-list(a)redhat.com
Hey,
Rather than just dropping in my packstack file, try generate the default answer file for
Fedora and just modify the variables.
Merry Christmas!Cheers,
Andrew
On Tue, Dec 24, 2013 at 9:28 PM, Boris Derzhavets <bderzhavets(a)hotmail.com> wrote:
I have attached both logs. Traces are there.
My version on F19 :-
[root@openstack1 ~]# rpm -qa | grep openstack
openstack-ceilometer-common-2013.2.1-1.fc20.noarch
openstack-nova-compute-2013.2.1-2.fc20.noarch
openstack-nova-common-2013.2.1-2.fc20.noarch
openstack-nova-cert-2013.2.1-2.fc20.noarch
openstack-utils-2013.2-2.fc20.noarch
openstack-glance-2013.2.1-1.fc20.noarch
openstack-ceilometer-compute-2013.2.1-1.fc20.noarch
openstack-packstack-2013.2.1-0.25.dev936.fc20.noarch
openstack-nova-conductor-2013.2.1-2.fc20.noarch
openstack-nova-scheduler-2013.2.1-2.fc20.noarch
openstack-keystone-2013.2.1-1.fc20.noarch
openstack-nova-api-2013.2.1-2.fc20.noarch
openstack-nova-console-2013.2.1-2.fc20.noarch
openstack-nova-novncproxy-2013.2.1-2.fc20.noarch
openstack-cinder-2013.2.1-1.fc20.noarch
[root@openstack1 ~]# uname -a
Linux openstack1.localdomain 3.12.5-200.fc19.x86_64 #1 SMP Tue Dec 17 22:21:14 UTC 2013
x86_64 x86_64 x86_64 GNU/Linux
System on CentOS 6.4 doesn't belong to me. I am a bit hesitant to ask system's
admin too much
questions. I am sorry.
Boris.
Date: Mon, 23 Dec 2013 23:03:54 +0000
From: pbrady(a)redhat.com
To: bderzhavets(a)hotmail.com
CC: rdo-list(a)redhat.com
Subject: Re: [Rdo-list] Attempt to reproduce Getting Started with Multi-Node OpenStack
RDO Havana + Gluster Backend + Neutron VLAN by Andrew Lau on F19
On 12/23/2013 12:02 PM, Boris Derzhavets wrote:
> Original document
http://www.andrewklau.com/getting-started-with-multi-node-openstack-rdo-h...
> contains the sample of answer file. In my situation p37p1 is
eth0 p4p1 is eth1 and I've tried to make a substitution in answer-file . packstack
fails with error :
> Applying 192.168.1.137_neutron.pp
>
[ ERROR ]
>
> ERROR : Error appeared during Puppet run: 192.168.1.127_neutron.pp
> Error: Validate method failed for class sleep: implicit argument passing of super
from method defined by define_method() is not supported. Specify all arguments explicitly.
What are the versions of packstack and puppet on your centos and Fedora 19 systems?
They should be the same if going from a pristine setup, but if not it would
be worth trying to match the F19 versions to the working centos one.
If they are in fact the same then it must come down to different
logic in the puppet modules for Fedora and EL systems, which we'd
need to look into.
You might get more indication of the particular error in:
/var/tmp/packstack/...neutron...log
thanks,
Pádraig.
_______________________________________________
Rdo-list mailing list
Rdo-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/rdo-list
3:51 a.m.
[. . .]
View also http://kashyapc.wordpress.com/tag/fedora/
Set up a bit different from yours , but with same idea Controller + Compute, is done
manually not via packstack with f20 core ( no Ethernet interfaces renaming just
ifcfg-eth0 and etc )
Here are more updated configurations:
http://kashyapc.fedorapeople.org/virt/openstack/neutron-configs-GRE-OVS-t...
That's the manual configuration details (not *fully* polished, but should
give you an idea.
http://kashyapc.fedorapeople.org/virt/openstack/Two-node-Havana-setup.txt
And, that's the set-up:
- Controller node: Nova, Keystone, Cinder, Glance, Neutron (using Open
vSwitch plugin and GRE tunneling).
- Compute node: Nova (nova-compute), Neutron (openvswitch-agent)
Hope that helps.
--
/kashyap
1:48 p.m.
New subject: [Rdo-list] Attempt to reproduce Getting Started with Multi-Node OpenStack RDO Havana + Gluster Backend + Neutron VLAN by Andrew Lau on F20 (2)
Trying to reproduce :
http://kashyapc.fedorapeople.org/virt/openstack/Two-node-Havana-setup.txt
I stopped at following point :
$ systemctl start openvswitch.service
$ systemctl enable openvswitch.service
$ systemctl enable neutron-ovs-cleanup.service
$ ovs-vsctl add-br br-int
$ cat <<EOF > /etc/sysconfig/network-scripts/ifcfg-eth1
DEVICE=eth1
BOOTPROTO=static
NM_CONTROLLED=no
ONBOOT=yes
TYPE=Ethernet
EOF
$ cat <<EOF > /etc/sysconfig/network-scripts/ifcfg-br-ex
DEVICE=br-ex
BOOTPROTO=static
ONBOOT=yes
IPADDR=192.169.142.140
NETMASK=255.255.255.0
GATEWAY=192.168.122.1
EOF
$ ovs-vsctl add-br br-ex
$ ovs-vsctl add-port br-ex eth0
$
$ systemctl stop NetworkManager
$ systemctl disable NetworkManager
$ systemctl restart network
$ systemct status network # must be running
here
Action (itself) :-
$ cat <<EOF > /etc/sysconfig/network-scripts/ifcfg-eth1
DEVICE=eth1
BOOTPROTO=static
NM_CONTROLLED=no
ONBOOT=yes
TYPE=Ethernet
EOF
won't create second interface on VM. Something else supposed to be done.
Otherwise, eth1 won't appear in ifconfig report as well as it
won't appear in routing table.
Attempt `ifup eth1` reports error : device is not known to system .
[root@ip-192-169-142-140 ~]# ifconfig
br-eth1: flags=67<UP,BROADCAST,RUNNING> mtu 1500
inet6 fe80::3497:35ff:fed5:e59f prefixlen 64 scopeid 0x20<link>
ether 26:b7:3f:05:ca:42 txqueuelen 0 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 8 bytes 648 (648.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
br-ex: flags=67<UP,BROADCAST,RUNNING> mtu 1500
inet 192.169.142.140 netmask 255.255.255.0 broadcast 192.169.142.255
inet6 fe80::a8bb:c8ff:fe10:ba7b prefixlen 64 scopeid 0x20<link>
ether 46:5a:28:79:5d:4e txqueuelen 0 (Ethernet)
RX packets 9 bytes 730 (730.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 12 bytes 816 (816.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
br-int: flags=67<UP,BROADCAST,RUNNING> mtu 1500
inet6 fe80::c53:4cff:fef3:8a84 prefixlen 64 scopeid 0x20<link>
ether 36:44:69:dc:21:44 txqueuelen 0 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 8 bytes 648 (648.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet6 fe80::5054:ff:fe32:e91e prefixlen 64 scopeid 0x20<link>
ether 52:54:00:32:e9:1e txqueuelen 1000 (Ethernet)
RX packets 45 bytes 2602 (2.5 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 8 bytes 648 (648.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 0 (Local Loopback)
RX packets 18 bytes 940 (940.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 18 bytes 940 (940.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
virbr0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500
inet 192.168.122.1 netmask 255.255.255.0 broadcast 192.168.122.255
ether 3e:cb:01:7a:51:ff txqueuelen 0 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
[root@ip-192-169-142-140 ~]# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
169.254.0.0 0.0.0.0 255.255.0.0 U 1002 0 0 eth0
169.254.0.0 0.0.0.0 255.255.0.0 U 1005 0 0 br-ex
192.168.122.0 0.0.0.0 255.255.255.0 U 0 0 0 virbr0
192.169.142.0 0.0.0.0 255.255.255.0 U 0 0 0 br-ex
[root@ip-192-169-142-140 ~]# ifup eth1
ERROR : [/etc/sysconfig/network-scripts/ifup-eth] Device eth1 does not seem
to be present, delaying initialization.
Boris
Date: Fri, 27 Dec 2013 10:51:08 +0100
From: kchamart(a)redhat.com
To: bderzhavets(a)hotmail.com
CC: andrew(a)andrewklau.com; rdo-list(a)redhat.com
Subject: Re: [Rdo-list] Attempt to reproduce Getting Started with Multi-Node OpenStack
RDO Havana + Gluster Backend + Neutron VLAN by Andrew Lau on F19
[. . .]
>
> View also http://kashyapc.wordpress.com/tag/fedora/
> Set up a bit different from yours , but with same idea Controller + Compute, is
done
> manually not via packstack with f20 core ( no Ethernet interfaces renaming just
ifcfg-eth0 and etc )
Here are more updated configurations:
http://kashyapc.fedorapeople.org/virt/openstack/neutron-configs-GRE-OVS-t...
That's the manual configuration details (not *fully* polished, but should
give you an idea.
http://kashyapc.fedorapeople.org/virt/openstack/Two-node-Havana-setup.txt
And, that's the set-up:
- Controller node: Nova, Keystone, Cinder, Glance, Neutron (using Open
vSwitch plugin and GRE tunneling).
- Compute node: Nova (nova-compute), Neutron (openvswitch-agent)
Hope that helps.
--
/kashyap
9 a.m.
New subject: [Rdo-list] Attempt to reproduce Getting Started with Multi-Node OpenStack RDO Havana + Gluster Backend + Neutron VLAN by Andrew Lau on F20 (2)
On 01/16/2014 08:48 PM, Boris Derzhavets wrote:
Trying to reproduce :
http://kashyapc.fedorapeople.org/virt/openstack/Two-node-Havana-setup.txt
Please note: this guide needs some more editing, it's more handy if one
is at-least moderately aware what's going under the hood and can
diagnose any network/routing problems.
Also I was experimenting w/ Neutron/GRE when I wrote the above - which
doesn't require two interfaces.
--
/kashyap
5:01 a.m.
New subject: [Rdo-list] Attempt to reproduce Kashyap Setup (Controller+Compute) on F20 is almost done
I am pretty close. I can load Cirros instance on Compute and run nslookup inside it.
Everything is fine with IP's and routing. However , i cannot connect via ssh to both
Cirros and Fedora 19 instances. Might it be gre tunnelling issue ? Details :-
On Controller :-
[root@ip-192-169-142-57 ~(keystone_admin)]$ neutron security-group-rule-create --protocol
tcp \
--port-range-min 22 --port-range-max 22 \
--direction ingress --remote-ip-prefix 0.0.0.0/0 default
Multiple security_group
matches found for name 'default', use an ID to be more specific.
[root@ip-192-169-142-57 ~(keystone_admin)]$ neutron security-group-list
+--------------------------------------+---------+-------------+
| id | name | description |
+--------------------------------------+---------+-------------+
| a085748d-92c0-40e0-a4c1-bc86935ec0ee | default | default |
| b6203882-561d-4f7b-9e2e-441c57e83419 | default | default |
| c70b80d3-f060-4002-af22-6603c745a6cf | default | default |
+--------------------------------------+---------+-------------+
[root@ip-192-169-142-57 ~(keystone_admin)]$ neutron security-group-rule-create --protocol
tcp --port-range-min 22 --port-range-max 22 --direction ingress --remote-ip-prefix
0.0.0.0/0 a085748d-92c0-40e0-a4c1-bc86935ec0ee
409-{u'NeutronError': {u'message': u'Security group rule already
exists. Group id is 6d15d6cc-ed13-4c26-89ff-7ff10e6c4656.', u'type':
u'SecurityGroupRuleExists', u'detail': u''}}
[root@ip-192-169-142-57 ~(keystone_admin)]$ neutron security-group-rule-create --protocol
tcp --port-range-min 22 --port-range-max 22 --direction ingress --remote-ip-prefix
0.0.0.0/0 b6203882-561d-4f7b-9e2e-441c57e83419
Created a new security_group_rule:
+-------------------+--------------------------------------+
| Field | Value |
+-------------------+--------------------------------------+
| direction | ingress |
| ethertype | IPv4 |
| id | 97232fb3-6ba1-46a3-a8e3-2f25ba0c70dc |
| port_range_max | 22 |
| port_range_min | 22 |
| protocol | tcp |
| remote_group_id | |
| remote_ip_prefix | 0.0.0.0/0 |
| security_group_id | b6203882-561d-4f7b-9e2e-441c57e83419 |
| tenant_id | 751cda6ede504ccd9562edd233b32b34 |
+-------------------+--------------------------------------+
[root@ip-192-169-142-57 ~(keystone_admin)]$ neutron floatingip-show \
3d40ed62-ad78-4042-8342-9f76c419c8c1
+---------------------+--------------------------------------+
| Field | Value |
+---------------------+--------------------------------------+
| fixed_ip_address | 10.0.0.2 |
| floating_ip_address | 192.169.142.105 |
| floating_network_id | 8e2df372-544d-4921-ad58-e164e5128410 |
| id | 3d40ed62-ad78-4042-8342-9f76c419c8c1 |
| port_id | 41da6b37-dfd8-49a2-8dae-45d9a99ef7d7 |
| router_id | ba157037-747e-4a44-84d5-13d7d30e88ac |
| tenant_id | 751cda6ede504ccd9562edd233b32b34 |
+---------------------+--------------------------------------+
[root@ip-192-169-142-57 ~(keystone_admin)]$ ssh -l fedora -i oskey1.priv 192.169.142.105
Hangs
I double checked iptables on compute node . It's OK
Date: Fri, 17 Jan 2014 16:00:12 +0100
From: kchamart(a)redhat.com
To: bderzhavets(a)hotmail.com
CC: rdo-list(a)redhat.com
Subject: Re: [Rdo-list] Attempt to reproduce Getting Started with Multi-Node OpenStack
RDO Havana + Gluster Backend + Neutron VLAN by Andrew Lau on F20 (2)
On 01/16/2014 08:48 PM, Boris Derzhavets wrote:
> Trying to reproduce :
> http://kashyapc.fedorapeople.org/virt/openstack/Two-node-Havana-setup.txt
Please note: this guide needs some more editing, it's more handy if one
is at-least moderately aware what's going under the hood and can
diagnose any network/routing problems.
Also I was experimenting w/ Neutron/GRE when I wrote the above - which
doesn't require two interfaces.
--
/kashyap
11:25 a.m.
New subject: [Rdo-list] Attempt to reproduce Kashyap Setup (Controller+Compute) on F20 is almost done
[Please don't top-post on technical lists.]
On 01/21/2014 12:01 PM, Boris Derzhavets wrote:
I am pretty close. I can load Cirros instance on Compute and run
nslookup inside it. Everything is fine with IP's and routing. However , i cannot
connect via ssh to both Cirros and Fedora 19 instances. Might it be gre tunnelling issue ?
Details :-
If it's GRE tunnelling issues, ensure you have the GRE related iptables
rules on both Controller and Compute nodes:
-A INPUT -p gre -j ACCEPT
-A OUTPUT -p gre -j ACCEPT
(You said - "double checked iptables", but didn't mention specifics.)
Here's my working Neutron configs w/ F20+Havana set-up (might need some
tiny tweaking if you have latest RDO Ice House packages).
http://kashyapc.fedorapeople.org/virt/openstack/neutron-configs-GRE-OVS-t...
On Controller :-
[root@ip-192-169-142-57 ~(keystone_admin)]$ neutron security-group-rule-create --protocol
tcp \
> --port-range-min 22 --port-range-max 22 \
> --direction ingress --remote-ip-prefix 0.0.0.0/0 default
Multiple security_group matches found for name 'default', use an ID to be more
specific.
[root@ip-192-169-142-57 ~(keystone_admin)]$ neutron security-group-list
+--------------------------------------+---------+-------------+
| id | name | description |
+--------------------------------------+---------+-------------+
| a085748d-92c0-40e0-a4c1-bc86935ec0ee | default | default |
| b6203882-561d-4f7b-9e2e-441c57e83419 | default | default |
| c70b80d3-f060-4002-af22-6603c745a6cf | default | default |
+--------------------------------------+---------+-------------+
[root@ip-192-169-142-57 ~(keystone_admin)]$ neutron security-group-rule-create --protocol
tcp --port-range-min 22 --port-range-max 22 --direction ingress --remote-ip-prefix
0.0.0.0/0 a085748d-92c0-40e0-a4c1-bc86935ec0ee
409-{u'NeutronError': {u'message': u'Security group rule already
exists. Group id is 6d15d6cc-ed13-4c26-89ff-7ff10e6c4656.', u'type':
u'SecurityGroupRuleExists', u'detail': u''}}
[root@ip-192-169-142-57 ~(keystone_admin)]$ neutron security-group-rule-create --protocol
tcp --port-range-min 22 --port-range-max 22 --direction ingress --remote-ip-prefix
0.0.0.0/0 b6203882-561d-4f7b-9e2e-441c57e83419
Created a new security_group_rule:
+-------------------+--------------------------------------+
| Field | Value |
+-------------------+--------------------------------------+
| direction | ingress |
| ethertype | IPv4 |
| id | 97232fb3-6ba1-46a3-a8e3-2f25ba0c70dc |
| port_range_max | 22 |
| port_range_min | 22 |
| protocol | tcp |
| remote_group_id | |
| remote_ip_prefix | 0.0.0.0/0 |
| security_group_id | b6203882-561d-4f7b-9e2e-441c57e83419 |
| tenant_id | 751cda6ede504ccd9562edd233b32b34 |
+-------------------+--------------------------------------+
[root@ip-192-169-142-57 ~(keystone_admin)]$ neutron floatingip-show \
3d40ed62-ad78-4042-8342-9f76c419c8c1
+---------------------+--------------------------------------+
| Field | Value |
+---------------------+--------------------------------------+
| fixed_ip_address | 10.0.0.2 |
| floating_ip_address | 192.169.142.105 |
| floating_network_id | 8e2df372-544d-4921-ad58-e164e5128410 |
| id | 3d40ed62-ad78-4042-8342-9f76c419c8c1 |
| port_id | 41da6b37-dfd8-49a2-8dae-45d9a99ef7d7 |
| router_id | ba157037-747e-4a44-84d5-13d7d30e88ac |
| tenant_id | 751cda6ede504ccd9562edd233b32b34 |
+---------------------+--------------------------------------+
[root@ip-192-169-142-57 ~(keystone_admin)]$ ssh -l fedora -i oskey1.priv 192.169.142.105
Hangs
I double checked iptables on compute node . It's OK
--
/kashyap
8:16 a.m.
New subject: [Rdo-list] Attempt to reproduce Kashyap Setup (Controller+Compute) on F20 is almost done
It's there. I checked one more time. I work with native f20 repos.
Date: Tue, 21 Jan 2014 18:25:13 +0100
From: kchamart(a)redhat.com
To: bderzhavets(a)hotmail.com
CC: rdo-list(a)redhat.com
Subject: Re: Attempt to reproduce Kashyap Setup (Controller+Compute) on F20 is almost
done
[Please don't top-post on technical lists.]
On 01/21/2014 12:01 PM, Boris Derzhavets wrote:
> I am pretty close. I can load Cirros instance on Compute and run nslookup inside it.
Everything is fine with IP's and routing. However , i cannot connect via ssh to both
Cirros and Fedora 19 instances. Might it be gre tunnelling issue ? Details :-
If it's GRE tunnelling issues, ensure you have the GRE related iptables
rules on both Controller and Compute nodes:
-A INPUT -p gre -j ACCEPT
-A OUTPUT -p gre -j ACCEPT
(You said - "double checked iptables", but didn't mention specifics.)
Here's my working Neutron configs w/ F20+Havana set-up (might need some
tiny tweaking if you have latest RDO Ice House packages).
http://kashyapc.fedorapeople.org/virt/openstack/neutron-configs-GRE-OVS-t...
>
> On Controller :-
>
> [root@ip-192-169-142-57 ~(keystone_admin)]$ neutron security-group-rule-create
--protocol tcp \
>> --port-range-min 22 --port-range-max 22 \
>> --direction ingress --remote-ip-prefix 0.0.0.0/0 default
> Multiple security_group matches found for name 'default', use an ID to be
more specific.
>
> [root@ip-192-169-142-57 ~(keystone_admin)]$ neutron security-group-list
>
> +--------------------------------------+---------+-------------+
> | id | name | description |
> +--------------------------------------+---------+-------------+
> | a085748d-92c0-40e0-a4c1-bc86935ec0ee | default | default |
> | b6203882-561d-4f7b-9e2e-441c57e83419 | default | default |
> | c70b80d3-f060-4002-af22-6603c745a6cf | default | default |
> +--------------------------------------+---------+-------------+
>
> [root@ip-192-169-142-57 ~(keystone_admin)]$ neutron security-group-rule-create
--protocol tcp --port-range-min 22 --port-range-max 22 --direction ingress
--remote-ip-prefix 0.0.0.0/0 a085748d-92c0-40e0-a4c1-bc86935ec0ee
> 409-{u'NeutronError': {u'message': u'Security group rule already
exists. Group id is 6d15d6cc-ed13-4c26-89ff-7ff10e6c4656.', u'type':
u'SecurityGroupRuleExists', u'detail': u''}}
>
> [root@ip-192-169-142-57 ~(keystone_admin)]$ neutron security-group-rule-create
--protocol tcp --port-range-min 22 --port-range-max 22 --direction ingress
--remote-ip-prefix 0.0.0.0/0 b6203882-561d-4f7b-9e2e-441c57e83419
> Created a new security_group_rule:
>
> +-------------------+--------------------------------------+
> | Field | Value |
> +-------------------+--------------------------------------+
> | direction | ingress |
> | ethertype | IPv4 |
> | id | 97232fb3-6ba1-46a3-a8e3-2f25ba0c70dc |
> | port_range_max | 22 |
> | port_range_min | 22 |
> | protocol | tcp |
> | remote_group_id | |
> | remote_ip_prefix | 0.0.0.0/0 |
> | security_group_id | b6203882-561d-4f7b-9e2e-441c57e83419 |
> | tenant_id | 751cda6ede504ccd9562edd233b32b34 |
> +-------------------+--------------------------------------+
>
> [root@ip-192-169-142-57 ~(keystone_admin)]$ neutron floatingip-show \
> 3d40ed62-ad78-4042-8342-9f76c419c8c1
>
> +---------------------+--------------------------------------+
> | Field | Value |
> +---------------------+--------------------------------------+
> | fixed_ip_address | 10.0.0.2 |
> | floating_ip_address | 192.169.142.105 |
> | floating_network_id | 8e2df372-544d-4921-ad58-e164e5128410 |
> | id | 3d40ed62-ad78-4042-8342-9f76c419c8c1 |
> | port_id | 41da6b37-dfd8-49a2-8dae-45d9a99ef7d7 |
> | router_id | ba157037-747e-4a44-84d5-13d7d30e88ac |
> | tenant_id | 751cda6ede504ccd9562edd233b32b34 |
> +---------------------+--------------------------------------+
>
>
>
> [root@ip-192-169-142-57 ~(keystone_admin)]$ ssh -l fedora -i oskey1.priv
192.169.142.105
>
> Hangs
>
> I double checked iptables on compute node . It's OK
--
/kashyap
2:29 p.m.
New subject: [Rdo-list] Attempt to reproduce Getting Started with Multi-Node OpenStack RDO Havana + Gluster Backend + Neutron VLAN by Andrew Lau on F20 (3)
I believe instruction is missing "virsh attach-interface" :-
[root@openstack2 ~]# virsh list --all
Id Name State
----------------------------------------------------
- fedora20 shut off
- instance-00000007 shut off
[root@openstack2 ~]# virsh attach-interface --domain fedora20 --type bridge \
--source virbr0 --model virtio --mac 52:54:00:3b:65:6f --config
Interface attached successfully
Then inside VM ( fedora20) :-
[root@ip-192-169-142-140 ~]# ifconfig
br-eth1: flags=67<UP,BROADCAST,RUNNING> mtu 1500
inet6 fe80::c49f:64ff:fe07:d84e prefixlen 64 scopeid 0x20<link>
ether 26:b7:3f:05:ca:42 txqueuelen 0 (Ethernet)
RX packets 9 bytes 730 (730.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 8 bytes 648 (648.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
br-ex: flags=67<UP,BROADCAST,RUNNING> mtu 1500
inet 192.169.142.140 netmask 255.255.255.0 broadcast 192.169.142.255
inet6 fe80::a0dd:efff:fe38:1b1b prefixlen 64 scopeid 0x20<link>
ether 46:5a:28:79:5d:4e txqueuelen 0 (Ethernet)
RX packets 9 bytes 730 (730.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 12 bytes 816 (816.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
br-int: flags=67<UP,BROADCAST,RUNNING> mtu 1500
inet6 fe80::b8de:ccff:fec2:5b09 prefixlen 64 scopeid 0x20<link>
ether 36:44:69:dc:21:44 txqueuelen 0 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 8 bytes 648 (648.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet6 fe80::5054:ff:fe32:e91e prefixlen 64 scopeid 0x20<link>
ether 52:54:00:32:e9:1e txqueuelen 1000 (Ethernet)
RX packets 43 bytes 2498 (2.4 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 10 bytes 760 (760.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
eth1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet6 fe80::5054:ff:fe3b:656f prefixlen 64 scopeid 0x20<link>
ether 52:54:00:3b:65:6f txqueuelen 1000 (Ethernet)
RX packets 43 bytes 2498 (2.4 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 9 bytes 718 (718.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 0 (Local Loopback)
RX packets 22 bytes 1140 (1.1 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 22 bytes 1140 (1.1 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
virbr0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500
inet 192.168.122.1 netmask 255.255.255.0 broadcast 192.168.122.255
ether d6:f9:2a:47:81:6a txqueuelen 0 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
[root@ip-192-169-142-140 ~]# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
169.254.0.0 0.0.0.0 255.255.0.0 U 1002 0 0 eth0
169.254.0.0 0.0.0.0 255.255.0.0 U 1003 0 0 eth1
169.254.0.0 0.0.0.0 255.255.0.0 U 1006 0 0 br-ex
192.168.122.0 0.0.0.0 255.255.255.0 U 0 0 0 virbr0
192.169.142.0 0.0.0.0 255.255.255.0 U 0 0 0 br-ex
Again routings tables don't match.
Boris.
Date: Fri, 27 Dec 2013 10:51:08 +0100
From: kchamart(a)redhat.com
To: bderzhavets(a)hotmail.com
CC: andrew(a)andrewklau.com; rdo-list(a)redhat.com
Subject: Re: [Rdo-list] Attempt to reproduce Getting Started with Multi-Node OpenStack
RDO Havana + Gluster Backend + Neutron VLAN by Andrew Lau on F19
[. . .]
>
> View also http://kashyapc.wordpress.com/tag/fedora/
> Set up a bit different from yours , but with same idea Controller + Compute, is
done
> manually not via packstack with f20 core ( no Ethernet interfaces renaming just
ifcfg-eth0 and etc )
Here are more updated configurations:
http://kashyapc.fedorapeople.org/virt/openstack/neutron-configs-GRE-OVS-t...
That's the manual configuration details (not *fully* polished, but should
give you an idea.
http://kashyapc.fedorapeople.org/virt/openstack/Two-node-Havana-setup.txt
And, that's the set-up:
- Controller node: Nova, Keystone, Cinder, Glance, Neutron (using Open
vSwitch plugin and GRE tunneling).
- Compute node: Nova (nova-compute), Neutron (openvswitch-agent)
Hope that helps.
--
/kashyap
7:06 a.m.
New subject: [Rdo-list] Attempt to reproduce Getting Started with Multi-Node OpenStack RDO Havana + Gluster Backend + Neutron VLAN by Andrew Lau on F19 (2)
It started to work after yesterday `yum -y update` 7 p.m MSK time. In general, I followed
your Instructions on physical boxes F20 . Details here :-
http://bderzhavets.blogspot.com/2014/01/setting-up-two-physical-node-open...
Date: Fri, 27 Dec 2013 10:51:08 +0100
From: kchamart(a)redhat.com
To: bderzhavets(a)hotmail.com
CC: andrew(a)andrewklau.com; rdo-list(a)redhat.com
Subject: Re: [Rdo-list] Attempt to reproduce Getting Started with Multi-Node OpenStack
RDO Havana + Gluster Backend + Neutron VLAN by Andrew Lau on F19
[. . .]
>
> View also http://kashyapc.wordpress.com/tag/fedora/
> Set up a bit different from yours , but with same idea Controller + Compute, is
done
> manually not via packstack with f20 core ( no Ethernet interfaces renaming just
ifcfg-eth0 and etc )
Here are more updated configurations:
http://kashyapc.fedorapeople.org/virt/openstack/neutron-configs-GRE-OVS-t...
That's the manual configuration details (not *fully* polished, but should
give you an idea.
http://kashyapc.fedorapeople.org/virt/openstack/Two-node-Havana-setup.txt
And, that's the set-up:
- Controller node: Nova, Keystone, Cinder, Glance, Neutron (using Open
vSwitch plugin and GRE tunneling).
- Compute node: Nova (nova-compute), Neutron (openvswitch-agent)
Hope that helps.
--
/kashyap
7:11 a.m.
New subject: [Rdo-list] Attempt to reproduce Getting Started with Multi-Node OpenStack RDO Havana + Gluster Backend + Neutron VLAN by Andrew Lau on F19 (2)
On 01/24/2014 06:36 PM, Boris Derzhavets wrote:
It started to work after yesterday `yum -y update` 7 p.m MSK time.
In general, I followed your Instructions on physical boxes F20 . Details here :-
http://bderzhavets.blogspot.com/2014/01/setting-up-two-physical-node-open...
Nice, you got it working. I see that you're using XEN there.
--
/kashyap
1:26 a.m.
New subject: [Rdo-list] Attempt to reproduce Getting Started with Multi-Node OpenStack RDO Havana + Gluster Backend + Neutron VLAN by Andrew Lau on F19 (2)
I've just found http://kashyapc.wordpress.com/tag/fedora/
It's done not via packstack and with eth(X) network interfaces
Thanks.
Boris.
Date: Mon, 23 Dec 2013 23:03:54 +0000
From: pbrady(a)redhat.com
To: bderzhavets(a)hotmail.com
CC: rdo-list(a)redhat.com
Subject: Re: [Rdo-list] Attempt to reproduce Getting Started with Multi-Node OpenStack
RDO Havana + Gluster Backend + Neutron VLAN by Andrew Lau on F19
On 12/23/2013 12:02 PM, Boris Derzhavets wrote:
> Original document
http://www.andrewklau.com/getting-started-with-multi-node-openstack-rdo-h...
> contains the sample of answer file. In my situation p37p1 is eth0 p4p1 is eth1 and
I've tried to make a substitution in answer-file . packstack fails with error :
> Applying 192.168.1.137_neutron.pp
>
[ ERROR ]
>
> ERROR : Error appeared during Puppet run: 192.168.1.127_neutron.pp
> Error: Validate method failed for class sleep: implicit argument passing of super
from method defined by define_method() is not supported. Specify all arguments
explicitly.
What are the versions of packstack and puppet on your centos and Fedora 19 systems?
They should be the same if going from a pristine setup, but if not it would
be worth trying to match the F19 versions to the working centos one.
If they are in fact the same then it must come down to different
logic in the puppet modules for Fedora and EL systems, which we'd
need to look into.
You might get more indication of the particular error in:
/var/tmp/packstack/...neutron...log
thanks,
Pádraig.
8:26 a.m.
New subject: [Rdo-list] Attempt to reproduce Getting Started with Multi-Node OpenStack RDO Havana + Gluster Backend + Neutron VLAN by Andrew Lau on F19 (3)
Date: Mon, 23 Dec 2013 23:03:54 +0000
From: pbrady(a)redhat.com
To: bderzhavets(a)hotmail.com
CC: rdo-list(a)redhat.com
Subject: Re: [Rdo-list] Attempt to reproduce Getting Started with Multi-Node OpenStack
RDO Havana + Gluster Backend + Neutron VLAN by Andrew Lau on F19
On 12/23/2013 12:02 PM, Boris Derzhavets wrote:
> Original document
http://www.andrewklau.com/getting-started-with-multi-node-openstack-rdo-h...
> contains the sample of answer file. In my situation p37p1 is eth0 p4p1 is eth1 and
I've tried to make a substitution in answer-file . packstack fails with error :
> Applying 192.168.1.137_neutron.pp
>
[ ERROR ]
>
> ERROR : Error appeared during Puppet run: 192.168.1.127_neutron.pp
> Error: Validate method failed for class sleep: implicit argument passing of super
from method defined by define_method() is not supported. Specify all arguments
explicitly.
What are the versions of packstack and puppet on your centos and Fedora 19 systems?
They should be the same if going from a pristine setup, but if not it would
be worth trying to match the F19 versions to the working centos one.
If they are in fact the same then it must come down to different
logic in the puppet modules for Fedora and EL systems, which we'd
need to look into.
You might get more indication of the particular error in:
/var/tmp/packstack/...neutron...log
thanks,
Pádraig.
3985
days inactive
4017
days old
15 comments
4 participants
participants (4)
-
Andrew Lau -
Boris Derzhavets -
Kashyap Chamarthy -
Pádraig Brady