[openstack-dev] neutron metadata-agent HA
Hi, I've installed Kilo release of OpenStack. An interesting thing, for us, is the new high available Neutron L3 agent, which - as far as I understand - can be set in active/active mode. But I verified what is reported in the HA Guide (http://docs.openstack.org/ha-guide/networking-ha-metadata.html): metadata-agent cannot be configured in high availability active/active mode. Below that sentence, I read: "[TODO: Update this information. Can this service now be made HA in active/active mode or do we need to pull in the instructions to run this service in active/passive mode?]" So my question is: is there any progress on this topic ? is there a way (something like a cronjob script) to make the metadata-agent redundant without involving the clustering software Pacemaker/Corosync ? Thanks, Alvise __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] Which is the correct way to set ha queues in RabbitMQ
Hi,
I read these two documents:
http://docs.openstack.org/high-availability-guide/content/_configure_rabbitmq.html
https://www.rdoproject.org/RabbitMQ
To configure the queues in HA mode, the two docs suggests two slightly
different commands;
The first one says:
rabbitmqctl set_policy ha-all '^(?!amq\.).*' '{"ha-mode": "all"}'
while the second one says:
rabbitmqctl set_policy HA '^(?!amq\.).*' '{"ha-mode": "all"}'
"ha_all" vs. "HA".
which one is correct ?
thanks,
Alvise
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Openstack-operators] Device {UUID}c not defined on plugin
Hi, I forgot to attach some relevant config files: /etc/neutron/plugins/ml2/ml2_conf.ini : [ml2] type_drivers = gre tenant_network_types = gre mechanism_drivers = openvswitch [ml2_type_flat] [ml2_type_vlan] [ml2_type_gre] tunnel_id_ranges = 1:1000 [ml2_type_vxlan] [securitygroup] firewall_driver = neutron.agent.linux.iptables_firewall.OVSHybridIptablesFirewallDriver enable_security_group = True [ovs] local_ip = 192.168.61.106 tunnel_type = gre enable_tunneling = True /etc/neutron/neutron.conf : [DEFAULT] nova_ca_certificates_file = /etc/grid-security/certificates/INFN-CA-2006.pem auth_strategy = keystone rpc_backend = neutron.openstack.common.rpc.impl_kombu rabbit_hosts = 192.168.60.105:5672,192.168.60.106:5672 notify_nova_on_port_status_changes = True notify_nova_on_port_data_changes = True nova_url = https://cloud-areapd.pd.infn.it:8774/v2 nova_admin_username = nova nova_admin_tenant_id = 1b2caeedb3e2497b935723dc6e142ec9 nova_admin_password = X nova_admin_auth_url = https://cloud-areapd.pd.infn.it:35357/v2.0 core_plugin = neutron.plugins.ml2.plugin.Ml2Plugin service_plugins = neutron.services.l3_router.l3_router_plugin.L3RouterPlugin verbose = True debug = False rabbit_ha_queues = True dhcp_agents_per_network = 2 [quotas] [agent] [keystone_authtoken] auth_uri = https://cloud-areapd.pd.infn.it:35357/v2.0 auth_url = https://cloud-areapd.pd.infn.it:35357/v2.0 auth_host = cloud-areapd.pd.infn.it auth_protocol = https auth_port = 35357 admin_tenant_name = services admin_user = neutron admin_password = X cafile = /etc/grid-security/certificates/INFN-CA-2006.pem [database] connection = mysql://neutron_prod:XX@192.168.60.10/neutron_prod [service_providers] service_provider=LOADBALANCER:Haproxy:neutron.services.loadbalancer.drivers.haproxy.plugin_driver.HaproxyOnHostPluginDriver:default service_provider=VPN:openswan:neutron.services.vpn.service_drivers.ipsec.IPsecVPNDriver:default And here http://pastebin.com/P977162t the output of "ovs-vsctl show". Alvise On 16/06/2015 15:30, Alvise Dorigo wrote: Hi after a migration of Havana to IceHouse (using controller and network services/agents on the same physical node, and using OVS/GRE) we started facing some network-related problems (the internal tag of the element shown by ovs-vsctl show was set to 4095, which is wrong AFAIK). At the beginning the problems could be solved by just restarting the openvswitch related agents (and openvswitch itself), or changing the tag by hand; but now the networking definitely stopped working. When we add a new router interface connected to a tenant lan, it is created in "DOWN" state. The in the openvswitch-agent.log we see this errore message: 2015-06-16 15:07:43.275 40708 WARNING neutron.plugins.openvswitch.agent.ovs_neutron_agent [-] Device ba295e45-9a73-48c1-8864-a59edd5855dc not defined on plugin and nothing more. Any suggestion ? thanks, Alvise ___ OpenStack-operators mailing list openstack-operat...@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Device {UUID}c not defined on plugin
Hi, I forgot to attach some relevant config files: /etc/neutron/plugins/ml2/ml2_conf.ini : [ml2] type_drivers = gre tenant_network_types = gre mechanism_drivers = openvswitch [ml2_type_flat] [ml2_type_vlan] [ml2_type_gre] tunnel_id_ranges = 1:1000 [ml2_type_vxlan] [securitygroup] firewall_driver = neutron.agent.linux.iptables_firewall.OVSHybridIptablesFirewallDriver enable_security_group = True [ovs] local_ip = 192.168.61.106 tunnel_type = gre enable_tunneling = True /etc/neutron/neutron.conf : [DEFAULT] nova_ca_certificates_file = /etc/grid-security/certificates/INFN-CA-2006.pem auth_strategy = keystone rpc_backend = neutron.openstack.common.rpc.impl_kombu rabbit_hosts = 192.168.60.105:5672,192.168.60.106:5672 notify_nova_on_port_status_changes = True notify_nova_on_port_data_changes = True nova_url = https://cloud-areapd.pd.infn.it:8774/v2 nova_admin_username = nova nova_admin_tenant_id = 1b2caeedb3e2497b935723dc6e142ec9 nova_admin_password = X nova_admin_auth_url = https://cloud-areapd.pd.infn.it:35357/v2.0 core_plugin = neutron.plugins.ml2.plugin.Ml2Plugin service_plugins = neutron.services.l3_router.l3_router_plugin.L3RouterPlugin verbose = True debug = False rabbit_ha_queues = True dhcp_agents_per_network = 2 [quotas] [agent] [keystone_authtoken] auth_uri = https://cloud-areapd.pd.infn.it:35357/v2.0 auth_url = https://cloud-areapd.pd.infn.it:35357/v2.0 auth_host = cloud-areapd.pd.infn.it auth_protocol = https auth_port = 35357 admin_tenant_name = services admin_user = neutron admin_password = X cafile = /etc/grid-security/certificates/INFN-CA-2006.pem [database] connection = mysql://neutron_prod:XX@192.168.60.10/neutron_prod [service_providers] service_provider=LOADBALANCER:Haproxy:neutron.services.loadbalancer.drivers.haproxy.plugin_driver.HaproxyOnHostPluginDriver:default service_provider=VPN:openswan:neutron.services.vpn.service_drivers.ipsec.IPsecVPNDriver:default And here http://pastebin.com/P977162t the output of "ovs-vsctl show". Alvise On 16/06/2015 15:30, Alvise Dorigo wrote: Hi after a migration of Havana to IceHouse (using controller and network services/agents on the same physical node, and using OVS/GRE) we started facing some network-related problems (the internal tag of the element shown by ovs-vsctl show was set to 4095, which is wrong AFAIK). At the beginning the problems could be solved by just restarting the openvswitch related agents (and openvswitch itself), or changing the tag by hand; but now the networking definitely stopped working. When we add a new router interface connected to a tenant lan, it is created in "DOWN" state. The in the openvswitch-agent.log we see this errore message: 2015-06-16 15:07:43.275 40708 WARNING neutron.plugins.openvswitch.agent.ovs_neutron_agent [-] Device ba295e45-9a73-48c1-8864-a59edd5855dc not defined on plugin and nothing more. Any suggestion ? thanks, Alvise __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] Device {UUID}c not defined on plugin
Hi after a migration of Havana to IceHouse (using controller and network services/agents on the same physical node, and using OVS/GRE) we started facing some network-related problems (the internal tag of the element shown by ovs-vsctl show was set to 4095, which is wrong AFAIK). At the beginning the problems could be solved by just restarting the openvswitch related agents (and openvswitch itself), or changing the tag by hand; but now the networking definitely stopped working. When we add a new router interface connected to a tenant lan, it is created in "DOWN" state. The in the openvswitch-agent.log we see this errore message: 2015-06-16 15:07:43.275 40708 WARNING neutron.plugins.openvswitch.agent.ovs_neutron_agent [-] Device ba295e45-9a73-48c1-8864-a59edd5855dc not defined on plugin and nothing more. Any suggestion ? thanks, Alvise __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] Custom Kernel Parameters passed to VM
Hello,
I'd like to know if this is supposed to work:
https://wiki.openstack.org/wiki/LibvirtCustomKernelArgs
I've tried it, passing a custom root partition ("root=/dev/vda2"), but cat-ing
the file /proc/cmdline in the instantiated virtual machine (Debian 7.1, and SL
6.4) I still see "root=/dev/vda".
There's a bug or something ? there's a workaround to get the custom kernel args
correctly passed to the vmlinuz AKI image ?
thanks,
Alvise___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] dnsmasq doesn't send DHCPACK
Dear list, I'm facing a problem related with network bring up inside a virtual instance Scientific Linux 5. My Openstack installation has been made with packstack (with options --allinone --os-swift-install=n --os-quantum-install=n --os-cinder-install=n), using the latest Grizzly, on a Scientific Linux 6.4 host machine: [root@lxadorigo log]# rpm -qa|egrep 'openstack|qemu|virt|dnsmasq' qemu-img-0.12.1.2-2.355.el6_4.6.x86_64 openstack-packstack-2013.1.1-0.24.dev660.el6.noarch dnsmasq-utils-2.48-13.el6.x86_64 libvirt-client-0.10.2-18.el6_4.9.x86_64 libvirt-python-0.10.2-18.el6_4.9.x86_64 openstack-nova-scheduler-2013.1.3-1.el6.noarch openstack-glance-2013.1.2-2.el6.noarch openstack-nova-common-2013.1.3-1.el6.noarch openstack-nova-network-2013.1.3-1.el6.noarch gpxe-roms-qemu-0.9.7-6.9.el6.noarch libvirt-0.10.2-18.el6_4.9.x86_64 openstack-nova-compute-2013.1.3-1.el6.noarch openstack-utils-2013.1-8.el6.noarch python-django-openstack-auth-1.0.7-1.el6.noarch openstack-nova-api-2013.1.3-1.el6.noarch qemu-kvm-0.12.1.2-2.355.el6_4.6.x86_64 openstack-nova-conductor-2013.1.3-1.el6.noarch openstack-nova-cert-2013.1.3-1.el6.noarch kernel-2.6.32-358.114.1.openstack.el6.gre.2.x86_64 virt-what-1.11-1.2.el6.x86_64 openstack-nova-novncproxy-2013.1.3-1.el6.noarch openstack-dashboard-2013.1.1-1.el6.noarch kernel-firmware-2.6.32-358.114.1.openstack.el6.gre.2.noarch openstack-keystone-2013.1.3-1.el6.noarch openstack-nova-console-2013.1.3-1.el6.noarch dnsmasq-2.48-13.el6.x86_64 [root@lxadorigo log]# uname -r 2.6.32-358.114.1.openstack.el6.gre.2.x86_64 When I upload a Scientific Linux 6 AMI image (linked to a proper kernel and initramfs) and then I start it, I do not have any problem with it; the instance starts and this is the response the dhcp client gets from the dnsmasq: Aug 14 13:48:43 lxadorigo dnsmasq[3321]: read /etc/hosts - 2 addresses Aug 14 13:48:43 lxadorigo dnsmasq[3321]: read /var/lib/nova/networks/nova-br100.conf Aug 14 13:48:45 lxadorigo kernel: kvm: 24134: cpu0 disabled perfctr wrmsr: 0xc1 data 0xabcd Aug 14 13:48:51 lxadorigo kernel: device vnet0 entered promiscuous mode Aug 14 13:48:51 lxadorigo kernel: br100: port 1(vnet0) entering forwarding state Aug 14 13:48:51 lxadorigo qemu-kvm: Could not find keytab file: /etc/qemu/krb5.tab: No such file or directory Aug 14 13:48:54 lxadorigo ntpd[2283]: Listening on interface #15 vnet0, fe80::fc16:3eff:fe16:fbbc#123 Enabled Aug 14 13:48:56 lxadorigo kernel: kvm: 24392: cpu0 unhandled wrmsr: 0x391 data 200f Aug 14 13:49:04 lxadorigo dnsmasq-dhcp[3321]: DHCPDISCOVER(br100) fa:16:3e:16:fb:bc Aug 14 13:49:04 lxadorigo dnsmasq-dhcp[3321]: DHCPOFFER(br100) 192.168.32.4 fa:16:3e:16:fb:bc Aug 14 13:49:04 lxadorigo dnsmasq-dhcp[3321]: DHCPREQUEST(br100) 192.168.32.4 fa:16:3e:16:fb:bc Aug 14 13:49:04 lxadorigo dnsmasq-dhcp[3321]: DHCPACK(br100) 192.168.32.4 fa:16:3e:16:fb:bc sl64-5gb If I upload a Scientific Linux 5, when its dhclient asks the dnsmasq for negotiation this is the dnsmasq's answer: Aug 14 14:08:53 lxadorigo dnsmasq[25019]: read /etc/hosts - 2 addresses Aug 14 14:08:53 lxadorigo dnsmasq[25019]: read /var/lib/nova/networks/nova-br100.conf Aug 14 14:08:55 lxadorigo kernel: kvm: 26374: cpu0 disabled perfctr wrmsr: 0xc1 data 0xabcd Aug 14 14:09:00 lxadorigo kernel: device vnet0 entered promiscuous mode Aug 14 14:09:00 lxadorigo kernel: br100: port 1(vnet0) entering forwarding state Aug 14 14:09:00 lxadorigo qemu-kvm: Could not find keytab file: /etc/qemu/krb5.tab: No such file or directory Aug 14 14:09:03 lxadorigo ntpd[2283]: Listening on interface #18 vnet0, fe80::fc16:3eff:fea4:1cb8#123 Enabled Aug 14 14:09:12 lxadorigo dnsmasq-dhcp[25019]: DHCPDISCOVER(br100) fa:16:3e:a4:1c:b8 Aug 14 14:09:12 lxadorigo dnsmasq-dhcp[25019]: DHCPOFFER(br100) 192.168.32.2 fa:16:3e:a4:1c:b8 Aug 14 14:09:20 lxadorigo dnsmasq-dhcp[25019]: DHCPDISCOVER(br100) fa:16:3e:a4:1c:b8 Aug 14 14:09:20 lxadorigo dnsmasq-dhcp[25019]: DHCPOFFER(br100) 192.168.32.2 fa:16:3e:a4:1c:b8 Aug 14 14:09:28 lxadorigo dnsmasq-dhcp[25019]: DHCPDISCOVER(br100) fa:16:3e:a4:1c:b8 Aug 14 14:09:28 lxadorigo dnsmasq-dhcp[25019]: DHCPOFFER(br100) 192.168.32.2 fa:16:3e:a4:1c:b8 Aug 14 14:09:35 lxadorigo dnsmasq-dhcp[25019]: DHCPDISCOVER(br100) fa:16:3e:a4:1c:b8 Aug 14 14:09:35 lxadorigo dnsmasq-dhcp[25019]: DHCPOFFER(br100) 192.168.32.2 fa:16:3e:a4:1c:b8 Aug 14 14:09:42 lxadorigo dnsmasq-dhcp[25019]: DHCPDISCOVER(br100) fa:16:3e:a4:1c:b8 Aug 14 14:09:42 lxadorigo dnsmasq-dhcp[25019]: DHCPOFFER(br100) 192.168.32.2 fa:16:3e:a4:1c:b8 Aug 14 14:09:56 lxadorigo dnsmasq-dhcp[25019]: DHCPDISCOVER(br100) fa:16:3e:a4:1c:b8 Aug 14 14:09:56 lxadorigo dnsmasq-dhcp[25019]: DHCPOFFER(br100) 192.168.32.2 fa:16:3e:a4:1c:b8 Aug 14 14:10:07 lxadorigo dnsmasq-dhcp[25019]: DHCPDISCOVER(br100) fa:16:3e:a4:1c:b8 Aug 14 14:10:07 lxadorigo dnsmasq-dhcp[25019]: DHCPOFFER(br100) 192.168.32.2 fa:16:3e:a4:1c:b8 without any DHCPOFFERS message. Now, I'm not a network and/or dnsmasq expert
