Open Stack

Dani

You are always welcome - I am adding fuel documentation team into the
thread.

On Fri, Jul 10, 2015 at 5:45 PM, Daniel Comnea <comnea.dani at gmail.com>
wrote:

> Okay Vladimir, thanks for confirmation!
>
> So then you happy to stick my sketch proposal (of course needs re-wording)
> into documentation?
>
> Dani
>
> On Fri, Jul 10, 2015 at 11:31 AM, Vladimir Kuklin <vkuklin at mirantis.com>
> wrote:
>
>> Daniel
>>
>> Yes, if you want to do some administrative stuff you need to have access
>> to management network to be able to work with internal and admin endpoints.
>>
>> On Fri, Jul 10, 2015 at 9:58 AM, Daniel Comnea <comnea.dani at gmail.com>
>> wrote:
>>
>>> I know about the flow but what i'm questioning is:
>>>
>>> admin endpoint is mapped to br-mgmt subnet (you do have the HAproxy as
>>> below defined in 6.1. In 6.0 and before you had no HAproxy)
>>>
>>> listen keystone-2
>>>   bind 192.168.20.3:35357
>>>   option  httpchk
>>>   option  httplog
>>>   option  httpclose
>>>   server node-17 192.168.20.20:35357   check inter 10s fastinter 2s
>>> downinter 3s rise 3 fall 3
>>>   server node-18 192.168.20.21:35357   check inter 10s fastinter 2s
>>> downinter 3s rise 3 fall 3
>>>   server node-23 192.168.20.26:35357   check inter 10s fastinter 2s
>>> downinter 3s rise 3 fall 3
>>>
>>> public endpoint is mapped to br-ex
>>>
>>> So with this behavior you are saying the bt-mgmt subnet (which i thought
>>> is only for controller <> compute traffic, isolated network) should be
>>> routable in the same way br-ex is?
>>>
>>> Dani
>>>
>>>
>>> On Thu, Jul 9, 2015 at 11:30 PM, Stanislaw Bogatkin <
>>> sbogatkin at mirantis.com> wrote:
>>>
>>>> Hi Daniel,
>>>>
>>>> answer is no - actually there is no strong dependency between public
>>>> and internal/admin endpoints. In your case keystone client ask keystone on
>>>> address 10.52.71.39 (which, I think, was provided by system
>>>> variable OS_AUTH_URL), auth on it and then keystone give endpoints list to
>>>> client. Client selected admin endpoint from this list (192.168.20.3
>>>> address) and tried to get information you asked. It's a normal behavior.
>>>>
>>>> So, in Fuel by default we have 3 different endpoints for keystone -
>>>> public on public VIP, port 5000; internal on management VIP, port 5000,
>>>> admin on management VIP, port 35357.
>>>>
>>>> On Thu, Jul 9, 2015 at 4:59 PM, Daniel Comnea <comnea.dani at gmail.com>
>>>> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> I'm running Fuel 6.1 and i've seen an interesting behavior which i
>>>>> think match bug [1]
>>>>>
>>>>> Basically the adminUrl & publicUrl part of keystone endpoint are
>>>>> different
>>>>>
>>>>> And the result of that is that you can't run keystone cli - i.e
>>>>> create/list tenants etc
>>>>>
>>>>> keystone --debug tenant-list
>>>>> /usr/local/lib/python2.7/site-packages/keystoneclient/shell.py:65:
>>>>> DeprecationWarning: The keystone CLI is deprecated in favor of python-
>>>>> openstackclient. For a Python library, continue using python-keys
>>>>> toneclient.
>>>>>   'python-keystoneclient.', DeprecationWarning)
>>>>> DEBUG:keystoneclient.auth.identity.v2:Making authentication request
>>>>> to http://10.20.71.39:5000/v2.0/tokens
>>>>> INFO:requests.packages.urllib3.connectionpool:Starting new HTTP
>>>>> connection (1): 10.52.71.39
>>>>> DEBUG:requests.packages.urllib3.connectionpool:"POST /v2.0/tokens
>>>>> HTTP/1.1" 200 3709
>>>>> DEBUG:keystoneclient.session:REQ: curl -g -i -X GET
>>>>> http://192.168.20.3:35357/v2.0/tenants -H "User-Agent: python-
>>>>> keystoneclient" -H "Accept: application/json" -H "X-Auth-Token:
>>>>> {SHA1}cc918b89c2dca563edda43e01964b1f1979c552b"
>>>>>
>>>>> shouldn't adminURL = publicURL = br-ex for keystone?
>>>>>
>>>>>
>>>>> Dani
>>>>>
>>>>>
>>>>> [1] https://bugs.launchpad.net/fuel/+bug/1441855
>>>>>
>>>>>
>>>>> __________________________________________________________________________
>>>>> OpenStack Development Mailing List (not for usage questions)
>>>>> Unsubscribe:
>>>>> OpenStack-dev-request at 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-request at 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-request at lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>
>>
>> --
>> Yours Faithfully,
>> Vladimir Kuklin,
>> Fuel Library Tech Lead,
>> Mirantis, Inc.
>> +7 (495) 640-49-04
>> +7 (926) 702-39-68
>> Skype kuklinvv
>> 35bk3, Vorontsovskaya Str.
>> Moscow, Russia,
>> www.mirantis.com <http://www.mirantis.ru/>
>> www.mirantis.ru
>> vkuklin at mirantis.com
>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> OpenStack-dev-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Yours Faithfully,
Vladimir Kuklin,
Fuel Library Tech Lead,
Mirantis, Inc.
+7 (495) 640-49-04
+7 (926) 702-39-68
Skype kuklinvv
35bk3, Vorontsovskaya Str.
Moscow, Russia,
www.mirantis.com <http://www.mirantis.ru/>
www.mirantis.ru
vkuklin at mirantis.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150710/77652ee3/attachment.html>