Open Stack

Il 06/02/2015 15:15, Fiorenza Meini ha scritto:
> Il 06/02/2015 15:08, Lars Kellogg-Stedman ha scritto:
>> On Thu, Feb 05, 2015 at 09:10:43AM +0100, Fiorenza Meini wrote:
>>> Thanks for your suggestion, my configuration of tenant_network_types
>>> is gre.
>>> Neutron has different component:
>>> neutron-dhcp-agent
>>> neutron-l3-agent
>>> neutron-metadata-agent
>>> neutron-plugin-openvswitch-agent
>>> neutron-server
>>>
>>> On my second node, I started only neutron-plugin-openvswitch-agent.
>>> Which is the virtual network point of union between two nodes ?
>>
>> I'm not sure I understand your question...
>>
>> Your compute nodes connect to your controller(s) via GRE tunnels,
>> which are set up by the Neutron openvswitch agent.  In a typical
>> configuration, L3 routing happens on the network host, while the
>> compute hosts are stricly L2 environments.
>>
>> The compute hosts only need the openvswitch agent, which in addition
>> to setting up the tunnels is also responsible managing port
>> assignments on the OVS integration bridge, br-int.  All the other
>> logic happens on your controller(s), where all the other neutron
>> agents are running.
>>
>> This is an old post of mine that talks about how things are connected
>> in a GRE (or VXLAN) environment:
>>
>>    http://blog.oddbit.com/2013/11/14/quantum-in-too-much-detail/
>>
>> This post doesn't cover the new hotness that is Neutron DVR or HA
>> routers, but it's still a good starting point.
>>
>
> Thanks,
> I think  L2 layer is working: I can see this on my second node:
>
> 5 DEBUG neutronclient.client [-] RESP:200 {'date': 'Fri, 06 Feb 2015
> 13:28:11 GMT', 'content-length': '731', 'content-type':
> 'application/json; charset=UTF-8', 'x-openstack-request-id':
> 'req-ab82f7a9-b557-44b3-a474-26c8e37003c4'} {"ports": [{"status":
> "ACTIVE", "binding:host_id": "elanor", "allowed_address_pairs": [],
> "extra_dhcp_opts": [], "device_owner": "compute:None",
> "binding:profile": {}, "fixed_ips": [{"subnet_id":
> "42b697f2-2f68-4218-bb86-35337881fdd2", "ip_address": "10.10.0.39"}],
> "id": "27e71fa9-5a48-40fc-b006-5593ec34e837", "security_groups":
> ["26ead0e4-84e1-4593-b612-f6ddc46f937b"], "device_id":
> "23cbaabb-96df-45be-aefa-ec9c8d114cf0", "name": "", "admin_state_up":
> true, "network_id": "489ec53f-56a8-4e5a-bcc3-f27c68de39f3", "tenant_id":
> "9a26a147891a46249567d793a6e7c9b7", "binding:vif_details":
> {"port_filter": true, "ovs_hybrid_plug": true}, "binding:vnic_type":
> "normal", "binding:vif_type": "ovs", "mac_address": "fa:16:3e:5a:99:14"}]}
>
>   http_log_resp
> /usr/lib/python2.7/dist-packages/neutronclient/common/utils.py:186
>
> The problem is that the VM hasn't the network interface configured with
> the ip 10.10.0.39, and I see on VM log file that cloud-init cannot
> contact http://169.254.169.254:80 (which I presume is metadata service).
>
> How can I tell to nova-compute on the second node, that metaservice is
> on another host ? I have no more ideas
>
> Regards
> Fiorenza Meini
>

I solved the problem: on the controller I configured nova_metadata_ip to 
the ip of the server, not localhost.
nova_metadata_ip is the ip address called by nova to connect to metaservice.

Regards
Fiorenza

-- 
Spazio Web S.r.l.
V. Dante, 10
13900 Biella
Tel.: +39 015 2431982
Fax.: +39 015 2522600
Numero d'Iscrizione al Registro Imprese presso CCIAA Biella, Cod.Fisc.e 
P.Iva: 02414430021
Iscriz. REA: BI - 188936 Cap. Soc.: €. 30.000 i.v.