We have been performing some tests and it seems that on the Lannion2 node only raw images start. We cannot start any image of any GE including Kurento, Orion and Cosmos. Hence, it seems that your problem is not related to Kurento but to some kind of problem on the Lannion2 node that needs to be reviewed by their administrators.

By the way. Once you have Lannion2 node working correctly, at the time of this writting latest version of Kurento is 5.1.1. Hence, until a newer image appears, you should be using this one: stream-oriented-GE-4.2.3-5.1.1

The problem is not related to Kurento but to Lannion2 node malfunction. From Kurento we cannot do anything else.

I am currently looking at this problem.
I will update it as soon as I got a solution.

BR,
Erwan

Hi,

I looked deeper at that problem and here are my notes :

When launching some images, instance try to spawn but quickly fails into an “Error” state.

• It behaves like this with images added by the federation, all those problematic images are owned by the “00000000000000000000000000000001” tenant.
  o It works fine with images we added ourselves.
  o When I look into keystone there is no such “00000000000000000000000000000001”
  o Looking into debug it appears that glance swiftclient complains about a 401 Unauthorized
  o Looking deeper, I am really upset because I found the following line each time I try to launch an instance with one of those federation images :
   glance-api.log:2015-05-27T12:46:39.104031+00:00 info: 2015-05-27 12:46:39.100 4630 INFO urllib3.connectionpool [-] Starting new HTTP connection (1): 130.206.82.10
   I also took some traces with tcpdump, it confirms that auth request goes to 130.206.82.10 (The old KP/idm)

So I don’t understand this behavior, I search for any occurrence of this IP in glance (and other related ones) config file and there is nothing. Furthermore we added the new KP/Idm IP and fqdn in our /etc/hosts, so it can’t be a translation to IP.

I found no trace of the “00000000000000000000000000000001” tenant in the current keystone, so I also tried to change the owner of the image with one of my tenant but same behavior.

BR,
Erwan

I finally had improvements with this problem :

I tried to instantiate the problematic images on Berlin2, it worked.

• So I have downloaded the image from this Berlin2 Region.
• I uploaded it in Lannion2 region
  o Tried to instantiate on Lannion2 : it worked
• Then I added properties one by one, trying to instantiate the instance between each properties : it worked each time.
• Now I have the same image as the non-working one, the only difference is the tenant. I used our Lannion management tenant (to my mind the original tenant used no more exist, it belongs to the old KP/Idm and not to the new one, and this may be part of the problem)

This leads me to following conclusion :

• Technically, Lannion2 node is NOT guilty. Or as much guilty as image providers...
• Problem seems to come from the fact that those images were provided by Telefonica before the KP/idm migration, with an ambiguous tenant ID, and this might be the cause.
  o Still remaining that question : why did the Instance/image try to authenticate with old KP ? I checked glance db and image_locations table contains traces of the old KP IP, but it seems not the be the cause, as working images also have it.
• I created a new Jira ticket assigned to LAB, asking them to re-upload at least one image to test its behavior when uploaded after the KP upgrade.

If really needed now, you can use the image I re-created from the Berlin one, it is called "stream-oriented-GE-image-R4.2.3-5.1.1-FROMBERLIN2" / ID : "61895895-e826-4a5a-9e22-93ec2920ccd4"

BR,
Erwan