perators. Generally they'll want to publish it there first then
> you follow-up with your blog post a few days later.
>
> On Mon, Nov 7, 2016 at 8:17 AM, Lance Bragstad
> wrote:
>
>> That's a good idea. Is there a page detailing the process for
>> contributing to th
Looping this into the operator's list, too!
On Wed, Jan 18, 2017 at 2:13 PM, Lance Bragstad wrote:
> Thanks to Morgan in today's policy meeting [0], we were able to shed some
> light on the reasons for keystone having two policy files. The main reason
> a second policy file
Hi Sam,
I've been trying to wrangle folks into discussions to see how we can
improve policy as a whole across OpenStack [0] [1]. So far, we've had some
involvement from a couple operators, but more feedback would be even better.
My goal is to try and generate a bunch of discussion prior to the PT
nd
> everything would be in code.’ Without this file, how can we define
> policies? Can user configure policies?
>
> Ruan
>
>
>
> *From:* Lance Bragstad [mailto:lbrags...@gmail.com]
> *Sent:* mercredi 18 janvier 2017 23:16
> *To:* OpenStack Development Mailing List (no
During the PTG, Morgan mentioned that there was the possibility of keystone
removing the v2.0 API [0]. This thread is a follow up from that discussion
to make sure we loop in the right people and do everything by the books.
The result of the session [1] listed the following work items:
- Figure ou
Sending out a heads up that the initial spec [0] merged.
[0] https://review.openstack.org/#/c/440815/
On Thu, Mar 30, 2017 at 1:44 PM, Tim Bell wrote:
>
> For those that are interested in nested quotas, there is proposal on how
> to address this forming in openstack-dev (and any comments on the
Hey operators,
I wanted to send out a friendly reminder that keystone's policy has been
moved into code [0]. Sample policy files can be generated using oslopolicy
tooling [1], and duplicate policies can be removed from policy files,
making maintenance a little easier.
We're still working through
Hi Vladimir,
I can try and help with some of the keystone troubleshooting, but we might
need some more information.
On Fri, May 5, 2017 at 9:00 AM, Vladimir Prokofev wrote:
> Writing things down always helps.
> So I dug a little further, and seems that keystone is the weakest link.
> It appears
Hey all,
To date we have two proposed solutions for tackling the admin-ness issue we
have across the services. One builds on the existing scope concepts by
scoping to an admin project [0]. The other introduces global role
assignments [1] as a way to denote elevated privileges.
I'd like to get som
er scope in their deployments.
Thanks for reading!
[0]
https://github.com/openstack/keystone/blob/3d033df1c0fdc6cc9d2b02a702efca286371f2bd/etc/keystone.conf.sample#L2334-L2342
On Wed, May 24, 2017 at 10:35 AM, Lance Bragstad
wrote:
> Hey all,
>
> To date we have two proposed solutio
willing to make. This might be a
loaded question and it will vary across deployments, but how long would you
expect that migration to take for you're specific deployment(s)?
-m
>
>
>
>
> On Thu, 2017-05-25 at 10:42 +1200, Adrian Turjak wrote:
>
>
>
> On 25/05/17 07:4
;
>> Belmiro
>>
>> On Fri, May 26, 2017 at 2:52 AM, joehuang wrote:
>>
>>> I think a option 2 is better.
>>>
>>> Best Regards
>>> Chaoyi Huang (joehuang)
>>> --
>>> *From:* Lance Bragstad [lbrags...@gmail.com]
>
64763/
On Tue, Jun 6, 2017 at 10:01 AM, Lance Bragstad wrote:
> I replied to John, but directly. I'm sending the responses I sent to him
> but with the intended audience on the thread. Sorry for not catching that
> earlier.
>
>
> On Fri, May 26, 2017 at 2:44 AM, John Garbutt
On Tue, Jun 6, 2017 at 3:06 PM, Marc Heckmann
wrote:
> Hi,
>
> On Tue, 2017-06-06 at 10:09 -0500, Lance Bragstad wrote:
>
> Also, with all the people involved with this thread, I'm curious what the
> best way is to get consensus. If I've tallied the responses prope
ce development opens.
Thanks for all the feedback and patience.
[0] https://review.openstack.org/#/c/464763/
On Tue, Jun 6, 2017 at 4:39 PM, Marc Heckmann
wrote:
> On Tue, 2017-06-06 at 17:01 -0400, Erik McCormick wrote:
> > On Tue, Jun 6, 2017 at 4:44 PM, Lance Bragstad
> > wro
Hi all,
Keystone has deprecated the domain configuration upload capability
provided through `keystone-manage`. We discussed it's removal in today's
meeting [0] and wanted to send a quick note to the operator list. The
ability to upload a domain config into keystone was done as a stop-gap
until the
Hi all,
Keystone has a script to perform some bootstrapping operations [0]. It's
not really tested and its purpose has been superseded by using the
`keystone-manage bootstrap` command. Based on codesearch, only
openstack/rpm-packaging references the script [1].
Is anyone opposed to the removal
stone#L331
On 07/05/2017 04:28 PM, Colleen Murphy wrote:
> On Wed, Jul 5, 2017 at 9:36 PM, Lance Bragstad <mailto:lbrags...@gmail.com>> wrote:
>
> Hi all,
>
> Keystone has a script to perform some bootstrapping operations
> [0]. It's
> no
During RC, Morgan's made quite a bit of progress on a bug found by the
gate [0]. Part of the solution led to another patch that removes the
ability to configure anything but sql for keystone's resource backend
(`keystone.conf [resource] driver`). The reasoning behind this is that
there were FK cons
Hey all,
Now that we're finishing up the last few bits of v2.0 removal, I'd like
to send out a reminder that *Queens* will not include the *v2.0 keystone
APIs* except the ec2-api. Authentication and validation of v2.0 tokens
has been removed (in addition to the public and admin APIs) after a
lengt
at 15:00 UTC. The meeting will be recorded. Previous
context and information is in this thread.
Thanks!
On 10/25/2017 01:29 PM, Lance Bragstad wrote:
> I've recapped the notes from today's session and I'll post a follow up
> with the recording as soon as it's available.
On 10/26/2017 08:10 AM, Andy Wojnarek wrote:
>
> Hi,
>
>
>
> Is it possible to have both v2.0 and v3 endpoints for Keystone? I’m
> trying to integrate a backup software into Swift, and it requires
> Keystone 2.0. I added the new endpoints fine, but I’m getting
> authentication/authorization err
Hi all,
I'm following up a thread we started earlier this year with proposals
for fixing RBAC [0]. Just wanted to give a quick update that the
specification has merged [1] and the implementation is underway [2]. I
will have a few more patches up shortly to handle the token scoping bits.
Adding th
Hey all,
We had a couple sessions over the last month or two analyzing RBAC in
other systems. The notes from the sessions can be found in etherpad [0].
The discussions and outcomes are useful for thinking about how we want
things to work in the near future, specifically highlighting the
importance
Hey all,
We've had a topic come up a few times about making it so IDs can be
specified in the API request when creating a project [0]. This has come
up over several releases, including the Queens release and in today's
keystone meeting [1]. The proposal is meant to solve spanning keystone
in large
Hey all,
This note is a continuation of a thread we started last year on
analyzing other policy systems [0]. Now that we're back from the
holidays and having policy meetings on Wednesdays [1], it'd be good to
pick up the conversation again. We had a few good sessions a couple
months ago going thro
On 02/08/2018 03:36 PM, Adrian Turjak wrote:
> Hello fellow Public Cloud operators!
>
> I'm quite sorry I haven't been able to attend the last few public cloud
> meetings, have been deep in various bits of work, and been very asleep when
> the meetings normally were.
>
> That said, I have some
On 05/10/2018 08:52 AM, Matt Riedemann wrote:
> On 5/9/2018 8:11 PM, Jean-Philippe Méthot wrote:
>> I currently operate a multi-region cloud split between 2 geographic
>> locations. I have updated it to Pike not too long ago, but I've been
>> running into a peculiar issue. Ever since the Pike rel
Here is the link to the session in case you'd like to add it to your
schedule [0].
[0]
https://www.openstack.org/summit/vancouver-2018/summit-schedule/events/21759/openstack-is-mature-time-to-get-serious-on-maintainers
On 05/17/2018 07:55 PM, Rochelle Grober wrote:
>
> Folks,
>
>
>
> TL;DR
>
>
The topic of having consistent policy names has popped up a few times this
week. Ultimately, if we are to move forward with this, we'll need a
convention. To help with that a little bit I started an etherpad [0] that
includes links to policy references, basic conventions *within* that
service, and
load-balancer
>
> Michael
> On Wed, Sep 12, 2018 at 12:52 PM Tim Bell wrote:
> >
> > So +1
> >
> >
> >
> > Tim
> >
> >
> >
> > From: Lance Bragstad
> > Reply-To: "OpenStack Development Mailing List (not f
n purposes.
>
> I am guilty of borrowing this from existing code examples[0].
>
> [0]
> http://specs.openstack.org/openstack/nova-specs/specs/newton/implemented/policy-in-code.html
>
> Michael
> On Fri, Sep 14, 2018 at 8:46 AM Lance Bragstad
> wrote:
> >
> >
&
ainberg
wrote:
> I am generally opposed to needlessly prefixing things with "os".
>
> I would advocate to drop it.
>
>
> On Fri, Sep 14, 2018, 20:17 Lance Bragstad wrote:
>
>> Ok - yeah, I'm not sure what the history behind that is either...
>>
>> I&#x
patch, and delete in the naming convention?
[0] https://service-types.openstack.org/service-types.json
[1]
https://gist.github.com/lbragstad/5000b46f27342589701371c88262c35b#file-policy-names-yaml
On Sun, Sep 16, 2018 at 9:47 PM Lance Bragstad wrote:
> If we consider dropping "os",
Adding the operator list back in.
On Fri, Sep 28, 2018 at 8:48 AM Lance Bragstad wrote:
> Bumping this thread again and proposing two conventions based on the
> discussion here. I propose we decide on one of the two following
> conventions:
>
> *::*
>
> or
>
ority
- resources are always singular
Thanks to all for sticking through this tedious discussion. I appreciate it.
>
> /R
>
> Harry
> >
> > On Fri, Sep 28, 2018 at 6:49 AM Lance Bragstad
> wrote:
> >>
> >> Bumping this thread again and proposing tw
n Fri, Sep 28, 2018 at 3:33 PM Sean McGinnis wrote:
> On Fri, Sep 28, 2018 at 01:54:01PM -0500, Lance Bragstad wrote:
> > On Fri, Sep 28, 2018 at 1:03 PM Harry Rybacki
> wrote:
> >
> > > On Fri, Sep 28, 2018 at 1:57 PM Morgan Fainberg
> > > wrote:
> > &g
On Mon, Oct 1, 2018 at 8:13 AM Ghanshyam Mann
wrote:
> On Sat, 29 Sep 2018 03:54:01 +0900 Lance Bragstad <
> lbrags...@gmail.com> wrote
> >
> > On Fri, Sep 28, 2018 at 1:03 PM Harry Rybacki
> wrote:
> > On Fri, Sep 28, 2018 at 1:5
https://review.openstack.org/#/c/606214/
On Mon, Oct 8, 2018 at 8:49 AM Lance Bragstad wrote:
>
> On Mon, Oct 1, 2018 at 8:13 AM Ghanshyam Mann
> wrote:
>
>> On Sat, 29 Sep 2018 03:54:01 +0900 Lance Bragstad <
>> lbrags...@gmail.com> wrote
>> >
>>
n Sat, Oct 13, 2018 at 6:07 AM Ghanshyam Mann
wrote:
> On Sat, 13 Oct 2018 01:45:17 +0900 Lance Bragstad <
> lbrags...@gmail.com> wrote
> > Sending a follow up here quick.
> > The reviewers actively participating in [0] are nearing a conclusion.
> Ultimatel
On Wed, Oct 24, 2018 at 2:49 PM Jay Pipes wrote:
> On 10/24/2018 02:57 PM, Matt Riedemann wrote:
> > On 10/24/2018 10:10 AM, Jay Pipes wrote:
> >> I'd like to propose deprecating this API and getting rid of this
> >> functionality since it conflicts with the new Keystone /limits
> >> endpoint, is
Hello ops folks,
During our session on global admin [0] [1], we heard several operators were
making changes to policy that worked towards a common goal. Unfortunately,
our session ended before we could gather all deployer changes.
As a follow-up, we'd like to give all the operators who are making
Hey all,
I wanted to send out a follow up on this. Yesterday in the keystone meeting
we voted on Mitaka specs that we would like to commit to. The
online-migration spec was accepted as something we would definitely like to
see [0]. On the other hand, the development team doesn't really have enough
When trusts were implemented, they were designed to work as an extension
under the version 3 API. The implementation didn't prevent the use of a
trust to authenticate against version 2.0, which was never officially
documented in the v2.0 API docs.
The keystone team is curious if there is anyone cr
I totally agree with communicating this the best we can. I'm adding the
operator list to this thread to increase visibility.
If there are any other methods folks think of for getting the word out,
outside of what we've already done (release notes, email threads, etc.),
please let me know. I'd be h
penStack sore might be good. superuser? there are
> folks reading this who can help
>
> Sent from HUAWEI AnyOffice
> *From:*Lance Bragstad
> *To:*OpenStack Development Mailing List (not for usage questions),
> openstack-operators@lists.openstack.org,
> *Date:*2016-11-03 08:11
Hi Christian,
There were changes proposed recently that documented this behavior [1] [2],
but they haven't been merged yet.
You're using v2.0, correct?
The v2.0 API enforces policy/context at the controller layer [3], which
calls assert_admin. By the looks of it, assert_admin is hardcoded to che
47 matches
Mail list logo
