I think I'm getting closer here. Whenever a VM requests metadata, the
quantum-metadata-agent tries to authenticate to keystone.
correct credentials for my config are
admin_tenant_name = service
admin_user = quantum
admin_password = grizzly
*BUT*
in the keystone log, I can see this
2013-04-28 1
Hi,
1. yes.
2. yes. Moreover, I have to kill it manually and delete the pid file and
then restart l3-agent, cause otherwise it stays alive. No error in its
log file.
3. yes. Here are the corresponding keys for this shared secret:
# on the controller node
root@leonard:~# cat /etc/nova/nova.con
On 04/27/2013 12:44 PM, Michaël Van de Borne wrote:
Anybody has an idea about why the nova metadata server rejects the VM
requests?
Hi,
Just a few questions:-
1. Can you please check /etc/quantum/metadata_agent.ini to see that you
have the correct quantum keystone credential configured?
2. Ca
Anybody has an idea about why the nova metadata server rejects the VM
requests?
Le 26/04/2013 15:58, Michaël Van de Borne a écrit :
Hi there,
I've installed Grizzly on 3 servers:
compute (howard)
controller (leonard)
network (rajesh)).
Namespaces are ON
Overlapping IPs are ON
When booting,
4 matches
Mail list logo
