Open Stack

Without straying too far off-topic, the v1/v2 issues with cinder cause
major headaches for the installation guide primarily because we can't get a
consistent answer from the developers regarding the appropriate service
entities and API endpoints. Furthermore, the gates often contain defunct
configuration. For Kilo, I spent probably too much time finding a magic
combination that worked for the conventional cinder client, OpenStack
client, and nova. I found one... two service entities, cinder/volume and
cinderv2/volumev2 with API endpoints that all contain /v2. As with every
release, I attempted to determine the recommendations for Liberty which
seem to involve removing the cinder/volume service entity and endpoints
that contain /v1. The recommendations work for what the installation guide
needs to accomplish. However, they break the OpenStack client. Frankly, the
only real solution to these perpetual problems involves cinder (including
services that use it) and clients supporting one cinder/volume service
entity and endpoints without a specific version in them. The magic
combination seems to work in Liberty, so I can update the cinder content to
use it again.

On Tue, Oct 13, 2015 at 8:12 AM, Anne Gentle <annegentle at justwriteclick.com>
wrote:

>
>
> On Tue, Oct 13, 2015 at 9:05 AM, Matt Kassawara <mkassawara at gmail.com>
> wrote:
>
>> Keystone/Apache:
>>
>> Does the package also include the /usr/bin/keystone-wsgi-admin and
>> /usr/bin/keystone-wsgi-public files?
>>
>> Keystone:
>>
>> I haven't found any problems with v3.
>>
>> Cinder:
>>
>> The v1 API does not exist in Liberty. I spoke with cinder developers
>> including the former PTL who told me to remove the service and endpoints
>> for v1. So far, so good in testing.
>>
>
> This thread and discussions at the TC meetings indicate otherwise, latest
> from Oct 5th is that we need a cross-project session in Tokyo to talk about
> the right way forward for all considerations.
>
>
> http://lists.openstack.org/pipermail/openstack-dev/2015-September/075828.html
>
> Without deep client support we need to have the install guide default to
> cinder API v1 while also documenting how to install v2 with the caveat that
> the client support may be lacking for v2.
>
> Anne
>
>
>>
>> On Tue, Oct 13, 2015 at 7:55 AM, Thomas Goirand <zigo at debian.org> wrote:
>>
>>> On 10/13/2015 03:02 PM, Matt Kassawara wrote:
>>> > As I wrote in a comment on the patch, why not simply install and
>>> > configure Apache separately like we do for all the other distributions
>>> > that don't package it with keystone?
>>>
>>> I have added a wsgi-keystone.conf file in the Keystone package, and now,
>>> the only thing you have to do in Debian to get Keystone to use Apache,
>>> is:
>>>
>>> - disable the .service file (with: systemctl disable keystone)
>>> - enable the wsgi-keystone.conf (a2ensite wsgi-keystone.conf and
>>> restarting apache)
>>>
>>> > Also, keystone isn't my only concern. I haven't seen any effort to test
>>> > Debian
>>>
>>> I'm hereby saying that I'll be working on this over the following weeks.
>>> Please give me a chance, as I am finished with Liberty packaging. This
>>> also helps me to improve the quality of Debian packages significantly by
>>> discussing things with the doc people.
>>>
>>> > with other significant changes for Liberty such as a completely
>>> > different architecture with Linux bridge instead of OVS
>>>
>>> Would you care to point me at the relevant changes? Can't we still use
>>> OVS? I'm sorry, I may have missed a train here...
>>>
>>> > use of only the keystone v3 API
>>>
>>> As much as I could see, the v3 API has many problems, I'm not sure if it
>>> is early enough to use it. If you think it is, then I'll try *more* to
>>> use it and set that up as default in the Debian package.
>>>
>>> > and removal of the cinder v1 API.
>>>
>>> This is completely wrong. For what I could test using Tempest, if you
>>> remove the v1 endpoint, Cinder simply fails in many ways. I would
>>> strongly advise not to remove the v1 endpoint from the install-guide. If
>>> you did already, then it should be reverted.
>>>
>>> Matt, let's be constructive and not destructive this time, ok?
>>>
>>> Cheers,
>>>
>>> Thomas Goirand (zigo)
>>>
>>>
>>
>> _______________________________________________
>> OpenStack-docs mailing list
>> OpenStack-docs at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs
>>
>>
>
>
> --
> Anne Gentle
> Rackspace
> Principal Engineer
> www.justwriteclick.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-docs/attachments/20151013/ded34f4d/attachment.html>