Re: [openstack-dev] [vitrage] Gate issues

[Weyl, Alexey (Nokia - IL/Kfar Sava)]

Hi,

The gate problem was solved.

The problem wasn’t with the setuptools, but with a change that was pushed to 
the project-config (a change that was also pushed to other projects 
configurations as well).

Due to that problem the vitrage was enabled twice.

BR,
Alexey Weyl

From: Yujun Zhang (ZTE) [mailto:zhangyujun+...@gmail.com]
Sent: Thursday, June 01, 2017 6:15 PM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] [vitrage] Gate issues

We have encountered similar issue also in OPNFV.

It seems to be a problem of setuptools 36.0.0 and it is now removed from pypi. 
Hope it resolves the vitrage gate tests as well.

See discussion in https://github.com/pypa/setuptools/issues/1042


On Thu, Jun 1, 2017 at 11:08 PM Afek, Ifat (Nokia - IL/Kfar Sava) 
mailto:ifat.a...@nokia.com>> wrote:
Hi,

Note that we are currently having problems with the Vitrage gate tests, related 
to python-setuptools. Other projects experience similar problems. We hope to 
fix it by the beginning of next week.

Best Regards,
Ifat.


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Yujun Zhang
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tc][ptls][all] Potential Queens Goal: Migrate Off Paste

[Ihar Hrachyshka]

On Fri, Jun 2, 2017 at 1:21 PM, Matt Riedemann  wrote:
> I don't think the maintenance issue is the prime motivator, it's the fact
> paste is in /etc which makes it a config file and therefore an impediment to
> smooth upgrades. The more we can move into code, like default policy and
> privsep, the better.

I am not sure this problem is of general interest to all code
consumers. For one, the fact that we even consider the file a
configuration file (and put it under /etc) is just a glitch that could
be easily fixed by 1) stopping considering it a config file; and 2)
moving it out of /etc/. Actually, both 1) and 2) are already done in
RDO/RH-OSP for quite some time, and I think nothing blocks others to
do the same, or upstream to adopt this stance. If that's the only
issue with the current approach, then I can't see how this is of broad
community interest to tackle it and not something more user
visible/impactful.

As for the library being not maintained, this can be solved
organizationally, without impacting consuming projects.

Ihar

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][keystone][product] api keys/application specific passwords

[Colleen Murphy]

On Wed, May 17, 2017 at 12:21 AM, Monty Taylor  wrote:

> On 05/16/2017 02:44 PM, Sean Dague wrote:
>
>> On 05/16/2017 03:40 PM, Monty Taylor wrote:
>>
>>> On 05/16/2017 10:20 AM, Doug Hellmann wrote:
>>>
 Excerpts from Chris Dent's message of 2017-05-16 15:16:08 +0100:

> On Tue, 16 May 2017, Monty Taylor wrote:
>
> FWIW - I'm un-crazy about the term API Key - but I'm gonna just roll
>> with
>> that until someone has a better idea. I'm uncrazy about it for two
>> reasons:
>>
>> a) the word "key" implies things to people that may or may not be
>> true here.
>> If we do stick with it - we need some REALLY crisp language about
>> what it is
>> and what it isn't.
>>
>> b) Rackspace Public Cloud (and back in the day HP Public Cloud) have
>> a thing
>> called by this name. While what's written in the spec is quite
>> similar in
>> usage to that construct, I'm wary of re-using the name without the
>> semantics
>> actually being fully the same for risk of user confusion. "This uses
>> api-key... which one?" Sean's email uses "APPKey" instead of
>> "APIKey" - which
>> may be a better term. Maybe just "ApplicationAuthorization"?
>>
>
> "api key" is a fairly common and generic term for "this magical
> thingie I can create to delegate my authority to some automation".
> It's also sometimes called "token", perhaps that's better (that's
> what GitHub uses, for example)? In either case the "api" bit is
> pretty important because it is the thing used to talk to the API.
>
> I really hope we can avoid creating yet more special language for
> OpenStack. We've got an API. We want to send keys or tokens. Let's
> just call them that.
>
>
 +1

>>>
>>> Fair. That's an excellent argument for "api key" - because I certainly
>>> don't think we want to overload 'token'.
>>>
>>
>> As someone who accidentally named "API Microversions", I fully cede
>> naming territory to others here.
>>
>
> I named "jeepyb" on _purpose_.
>
> For those playing at home, that's a phoneticization of "GPB" which is an
> otherwise never-used acronym for "Gerrit Project Builder".
>
> /me hides
>
> It seems like there is general agreement on the review that "api key" is a
bad name. Thoughts on renaming it "application key" / "app key" (what Ron
proposed in an earlier version of this spec)?

Colleen
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev