Re: [openstack-dev] [glance] newton rc-2 deadline

[Timothy Symanczyk]

https://bugs.launchpad.net/glance/+bug/1620833

Would be my suggestion for a conservative / quick-hit / high impact bug to
consider for inclusion. Especially since this cycle is when the
documentation for using db.simple was added, it seems like it¹d be nice if
this were also fixed.


Tim



On 9/23/16, 1:05 PM, "Brian Rosmaita"  wrote:

>We're going to need to cut rc-2 for Glance to accommodate some new
>translations, so there is an opportunity to include some conservative
>bugfixes.  Any such must be merged before 16:00 UTC on Wed 28 Sept, so I
>am setting a deadline of 12:00 UTC on Tue 27 Sept for approval.  If you
>have a bugfix that is a worthy candidate, please reply to this email with
>the appropriate info.
>
>cheers,
>brian
>
>
>__
>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

__
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] [Keystone]: Help needed with RBAC policies

[Timothy Symanczyk]

Hi Kam,

The first thing I'd do is ensure that you're editing the correct "in use" 
policy file ( /etc/keystone/policy.json , if it's a default devstack install ). 
Secondly, a good test would be to change the actual policy to "!" (deny all). 
If that still allows anyone but the service token to do the operation, 
something beyond your specific edits is wrong.

The service token bypasses RBAC, but the admin accounts should not. Beyond 
editing the correct "in use" policy file, there should not be additional 
changes necessary to enable them.

Tim

From: "Nasim, Kam" mailto:kam.na...@windriver.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Tuesday, July 19, 2016 at 11:56 AM
To: 
"openstack-dev@lists.openstack.org" 
mailto:openstack-dev@lists.openstack.org>>
Subject: [openstack-dev] [Keystone]: Help needed with RBAC policies

Hi  folks,

I have been trying to modify the default RBAC policies in keystone/policy.json 
however my policy changes don't seem to be enforced.

As a quick test, I modified the identity:list_users policy to:

"identity:list_users": "role:kam",

There is no role called "kam" defined in my deployment so I would have expected 
this operation to fail.

However:

$ openstack --debug user list

+--++
| ID   | Name   |
+--++
| 3c1bd8c0f6324dcc938900d8eb801aa5 | admin  |
| 4b76763e375946998445b65b11c8db73 | ceilometer |
| 15c8e1e463cc4370ad369eaf8504b727 | cinder |
| 951068b3372f47ac827ade8f67cc19b4 | glance |
| 2b62ced877244e74ba90b546225740d0 | heat   |
| 438a24497bc8448d9ac63bf05a005796 | kam|
| 0b7af941da9b4896959f9258c6b498a0 | kam2   |
| d1c4f7a244f74892b612b9b2ded6d602 | neutron|
| 5c3ea23eb8e14070bc562951bb266073 | sysinv |
+--++

$ cat myrc
unset OS_SERVICE_TOKEN
export OS_AUTH_URL=http://192.168.204.2:5000/v2.0
export OS_ENDPOINT_TYPE=publicURL
export CINDER_ENDPOINT_TYPE=publicURL

export OS_USERNAME=admin
export OS_PASSWORD=admin
export PS1='[\u@\h \W(keystone_admin)]\$ '

export OS_TENANT_NAME=admin
export OS_REGION_NAME=RegionOne


After getting the auth token, the client uses the adminURL endpoint to get the 
user list:
curl -g -i -X GET http://192.168.204.2:35357/v2.0/users -H "User-Agent: 
python-keystoneclient" -H "Accept: application/json" -H "X-Auth-Token: 
{SHA1}75002edfff1eb6751b3425d9d247ac3212e750f9"


Is there something I am missing here? Some specific configuration to enable 
RBAC? Do admin URL ops bypass RBAC


Thanks,
Kam

__
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] [devstack] - suggested development workflow without ./rejoin-stack.sh ?

[Timothy Symanczyk]

Thanks for asking this, I would also like to know what the “real” answer is.

But what I’ve found myself doing recently, since it was unwise to 100% count on 
rejoin-stack.sh, was to “do” everything via scripts and take periodic backups 
of same. You’re still only one power outage away from losing your state, but 
ideally a clean install and running the same scripts again could mostly 
recover. With that said most of what I’d been working on has a noop result if 
the same command is repeated multiple times (like “openstack role create”), so 
slowly appending to the script and just rerunning it in its entirety was a 
completely fine workflow. If you’re doing stuff where that’s not the case, this 
will not be a good solution.

Tim

From: Kevin Benton mailto:ke...@benton.pub>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Monday, May 2, 2016 at 3:10 PM
To: 
"openstack-dev@lists.openstack.org" 
mailto:openstack-dev@lists.openstack.org>>
Subject: [openstack-dev] [devstack] - suggested development workflow without 
./rejoin-stack.sh ?

This patch removed the ./rejoin-stack.sh script: 
https://review.openstack.org/#/c/291453/

I relied on this heavily in my development VM which sees lots of restarts 
because of various things (VM becomes unresponsive in load testing, my laptop 
has a kernel panic, etc). Normally this was not a big deal because I could 
./rejoin-stack.sh and pick up where I left off (all db objects, virtual 
interfaces, instance images, etc all intact).

Now am I correct in understanding that when this happens there is no way to 
restart the services in a simple manner without blowing away everything and 
starting over? Unless I'm missing some way to run ./stack.sh without losing 
previous state, this seems like a major regression (went from mostly working 
./rejoin-stack.sh to nothing).

What is the recommended way to use devstack without being a power outage away 
from losing hours of work?

Thanks,
Kevin Benton
__
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] [Openstack-operators] [keystone] RBAC usage at production

[Timothy Symanczyk]

We are running keystone kilo in production, and I¹m actively implementing
RBAC right now. I¹m certain that, at least with the version of keystone
we¹re running, a restart is NOT required when the policy file is modified.

Tim




On 12/9/15, 9:18 AM, "Edgar Magana"  wrote:

>We use RBAC in production but basically modify networking operations and
>some compute ones. In our case we don¹t need to restart the services if
>we modify the policy.json file. I am surprise that keystone is not
>following the same process.
>
>Edgar
>
>
>
>
>On 12/9/15, 9:06 AM, "Kris G. Lindgren"  wrote:
>
>>In other projects the policy.json file is read each time of api request.
>> So changes to the file take place immediately.  I was 90% sure keystone
>>was the same way?
>>
>>___
>>Kris Lindgren
>>Senior Linux Systems Engineer
>>GoDaddy
>>
>>
>>
>>
>>
>>
>>
>>On 12/9/15, 1:39 AM, "Oguz Yarimtepe"  wrote:
>>
>>>Hi,
>>>
>>>I am wondering whether there are people using RBAC at production. The
>>>policy.json file has a structure that requires restart of the service
>>>each time you edit the file. Is there and on the fly solution or tips
>>>about it?
>>>
>>>
>>>
>>>___
>>>OpenStack-operators mailing list
>>>openstack-operat...@lists.openstack.org
>>>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>___
>>OpenStack-operators mailing list
>>openstack-operat...@lists.openstack.org
>>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>__
>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


__
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