Open Stack

On 08/13/2015 12:41 AM, Gilles Dubreuil wrote:
> Hi Matthew,
>
> On 11/08/15 01:14, Rich Megginson wrote:
>> On 08/10/2015 07:46 AM, Matthew Mosesohn wrote:
>>> Sorry to everyone for bringing up this old thread, but it seems we may
>>> need more openstackclient/keystone experts to settle this.
>>>
>>> I'm referring to the comments in https://review.openstack.org/#/c/207873/
>>> Specifically comments from Richard Megginson and Gilles Dubreuil
>>> indicating openstackclient behavior for v3 keystone API.
>>>
>>>
>>> A few items seem to be under dispute:
>>> 1 - Keystone should be able to accept v3 requests at
>>> <http://keystone-server:5000/>http://keystone-server:5000/
>> I don't think so.  Keystone requires the version suffix "/v2.0" or "/v3".
>>
> Yes, if the public endpoint is set without a version then the service
> can deal with either version.
>
> http://paste.openstack.org/raw/412819/
>
> That is not true for the admin endpoint (authentication is already done,
> the admin services deals only with tokens), at least for now, Keystone
> devs are working on it.

I thought it worked like this - the openstack cli will infer from the 
arguments if it should do v2 or v3 auth.  In the above case for v3, 
since you specify the username/password, osc knows it has to use 
password auth (as opposed to token auth), and since all of the required 
v3 arguments are provided (v3 api version, domains for user/project), it 
can use v3 password auth.  It knows it has to use the "/v3/auth/token" 
path to get a token.

Similarly for v2, since it only has username/password, no v3 api or v3 
domain arguments, it knows it has to use v2 password auth.  It knows it 
has to use "/v2.0/token" to get a token.

With the puppet-keystone code, since it uses TOKEN/URL, osc cannot infer 
if it can use v2 or v3, so it requires the "/v2.0" or "/v3" suffix, and 
the api version.

>
>>> 2 - openstackclient should be able to interpret v3 requests and append
>>> "v3/" to OS_AUTH_URL=http://keystone-server.5000/ or rewrite the URL
>>> if it is set as
>>> OS_AUTH_URL=<http://keystone-server.5000/>http://keystone-server.5000/
>> It does, if it can determine from the given authentication arguments if
>> it can do v3 or v2.0.
>>
> It effectively does, again, assuming the path doesn't contain a version
> number (x.x.x.x:5000)
>
>>> 3 - All deployments require /etc/keystone/keystone.conf with a token
>>> (and not simply use openrc for creating additional endpoints, users,
>>> etc beyond keystone itself and an admin user)
>> No.  What I said about this issue was "Most people using
>> puppet-keystone, and realizing Keystone resources on nodes that are not
>> the Keystone node, put a /etc/keystone/keystone.conf on that node with
>> the admin_token in it."
>>
>> That doesn't mean the deployment requires /etc/keystone/keystone.conf.
>> It should be possible to realize Keystone resources on non-Keystone
>> nodes by using ENV or openrc or other means.
>>
> Agreed. Also keystone.conf is used only to bootstrap keystone
> installation and create admin users, etc.
>
>
>>> I believe it should be possible to set v2.0 keystone OS_AUTH_URL in
>>> openrc and puppet-keystone + puppet-openstacklib should be able to
>>> make v3 requests sensibly by manipulating the URL.
>> Yes.  Because for the puppet-keystone resource providers, they are coded
>> to a specific version of the api, and therefore need to be able to
>> set/override the OS_IDENTITY_API_VERSION and the version suffix in the URL.
>>
> No. To support V2 and V3, the OS_AUTH_URL must not contain any version
> in order.
>
> The less we deal with the version number the better!
>
>>> Additionally, creating endpoints/users/roles shouldbe possible via
>>> openrc alone.
>> Yes.
>>
> Yes, the openrc variables are used, if not available then the service
> token from the keystone.conf is used.
>
>>> It's not possible to write single node tests that can demonstrate this
>>> functionality, which is why it probably went undetected for so long.
>> And since this is supported, we need tests for this.
> I'm not sure what's the issue besides the fact keystone_puppet doesn't
> generate a RC file once the admin user has been created. That is left to
> be done by the composition layer. Although we might want to integrate that.
>
> If that issue persists, assuming the AUTH_URL is free for a version
> number and having an openrc in place, we're going to need a bug number
> to track the investigation.
>
>>> If anyone can speak up on these items, it could help influence the
>>> outcome of this patch.
>>>
>>> Thank you for your time.
>>>
>>> Best Regards,
>>> Matthew Mosesohn
>
> Thanks,
> Gilles
>
>>> On Fri, Jul 31, 2015 at 6:32 PM, Rich Megginson <rmeggins at redhat.com
>>> <mailto:rmeggins at redhat.com>> wrote:
>>>
>>>      On 07/31/2015 07:18 AM, Matthew Mosesohn wrote:
>>>
>>>          Jesse, thanks for raising this. Like you, I should just track
>>>          upstream
>>>          and wait for full V3 support.
>>>
>>>          I've taken the quickest approach and written fixes to
>>>          puppet-openstacklib and puppet-keystone:
>>>          https://review.openstack.org/#/c/207873/
>>>          https://review.openstack.org/#/c/207890/
>>>
>>>          and again to Fuel-Library:
>>>          https://review.openstack.org/#/c/207548/1
>>>
>>>          I greatly appreciate the quick support from the community to
>>>          find an
>>>          appropriate solution. Looks like I'm just using a weird edge case
>>>          where we're creating users on a separate node from where
>>>          keystone is
>>>          installed and it never got thoroughly tested, but I'm happy to fix
>>>          bugs where I can.
>>>
>>>
>>>      Most puppet deployments either realize all keystone resources on
>>>      the keystone node, or drop an /etc/keystone/keystone.conf with
>>>      admin token onto non-keystone nodes where additional keystone
>>>      resources need to be realized.
>>>
>>>
>>>
>>>          -Matthew
>>>
>>>          On Fri, Jul 31, 2015 at 3:54 PM, Jesse Pretorius
>>>          <jesse.pretorius at gmail.com <mailto:jesse.pretorius at gmail.com>>
>>>          wrote:
>>>
>>>              With regards to converting all services to use Keystone v3
>>>              endpoints, note
>>>              the following:
>>>
>>>              1) swift-dispersion currently does not support consuming
>>>              Keystone v3
>>>              endpoints [1]. There is a patch merged to master [2] to
>>>              fix that, but a
>>>              backport to kilo is yet to be done.
>>>              2) Each type (internal, admin, public) of endpoint created
>>>              with the Keystone
>>>              v3 API has its own unique id, unlike with the v2 API where
>>>              they're all
>>>              created with a single ID. This results in the keystone
>>>              client being unable
>>>              to read the catalog created via the v3 API when querying
>>>              via the v2 API. The
>>>              solution is to use the openstack client and to use the v3
>>>              API but this
>>>              obviously needs to be noted for upgrade impact and operators.
>>>              3) When glance is setup to use swift as a back-end,
>>>              glance_store is unable
>>>              to authenticate to swift when the endpoint it uses is a v3
>>>              endpoint. There
>>>              is a review to master in progress [3] to fix this which is
>>>              unlikely to make
>>>              it into kilo.
>>>
>>>              We (the openstack-ansible/os-ansible-deployment project)
>>>              are tracking these
>>>              issues and doing tests to figure out all the bits. These
>>>              are the bugs we've
>>>              hit so far. Also note that there is a WIP patch to gate
>>>              purely on Keystone
>>>              v3 API's which is planned to become voting (hopefully) by
>>>              the end of this
>>>              cycle.
>>>
>>>              [1] https://bugs.launchpad.net/swift/+bug/1468374
>>>              [2] https://review.openstack.org/195131
>>>              [3] https://review.openstack.org/193422
>>>
>>>              __________________________________________________________________________
>>>              OpenStack Development Mailing List (not for usage questions)
>>>              Unsubscribe:
>>>              OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>>              <http://OpenStack-dev-request@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://OpenStack-dev-request@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://OpenStack-dev-request@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
>>
> __________________________________________________________________________
> 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