from:"Takashi Natsume"

Re: [openstack-dev] [nova] nova-manage cell_v2 map_instances uses invalid UUID as marker in the db

2018-05-09 Thread Takashi Natsume

The temporary fix to pass the gate jobs is to mock
the 'warnings.warn' method in the test method.
Then add a TODO note to fix storing non-UUID value
in the 'map_instances' command of the 'CellV2Commands' class.

The fundamental solution is to change the design of
the 'map_instances' command.
In the first place, it is not good to store non-UUID value in the UUID
field.

In some compute REST APIs, it returns the 'marker' parameter
in their pagination.
Then users can specify the 'marker' parameter in the next request.

So it is one way to change the command to stop storing a 'marker' value
in the InstanceMapping (instance_mappings) DB table
and return (print) a 'marker' value and be able to be specifid
the 'marker' value as the command line argument.

On 2018/05/08 18:49, Balázs Gibizer wrote:

Hi,

The oslo UUIDField emits a warning if the string used as a field value
does not pass the validation of the uuid.UUID(str(value)) call [3]. All
the offending places are fixed in nova except the nova-manage cell_v2
map_instances call [1][2]. That call uses markers in the DB that are not
valid UUIDs. If we could fix this last offender then we could merge the
patch [4] that changes the this warning to an exception in the nova
tests to avoid such future rule violations.

However I'm not sure it is easy to fix. Replacing
'INSTANCE_MIGRATION_MARKER' at [1] to '----'
might work but I don't know what to do with instance_uuid.replace(' ',
'-') [2] to make it a valid uuid. Also I think that if there is an
unfinished mapping in the deployment and then the marker is changed in
the code that leads to inconsistencies.

I'm open to any suggestions.

Cheers,
gibi

[1]
https://github.com/openstack/nova/blob/09af976016a83288df22ac6ed1cce1676c2294cc/nova/cmd/manage.py#L1168

[2]
https://github.com/openstack/nova/blob/09af976016a83288df22ac6ed1cce1676c2294cc/nova/cmd/manage.py#L1180

[3]
https://github.com/openstack/oslo.versionedobjects/blob/29e643e4a9866b33965b68fc8dfb8acf30fa/oslo_versionedobjects/fields.py#L359

[4] https://review.openstack.org/#/c/540386

__
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

Regards,
Takashi Natsume
NTT Software Innovation Center
E-mail: natsume.taka...@lab.ntt.co.jp

Re: [openstack-dev] [nova] Adding Takashi Natsume to python-novaclient core

2018-02-18 Thread Takashi Natsume


Thank you, Matt and everyone.

But I would like to become a core reviewer for the nova project as well 
as python-novaclient.

I have contributed more in the nova project than python-novaclient.
I have done total 2,700+ reviews for the nova project in all releases (*1).
(Total 115 reviews only for python-novaclient.)

*1: http://stackalytics.com/?release=all_id=natsume-takashi

On 2018/02/16 2:18, Matt Riedemann wrote:

On 2/9/2018 9:01 AM, Matt Riedemann wrote:

I'd like to add Takashi to the python-novaclient core team.

python-novaclient doesn't get a ton of activity or review, but Takashi 
has been a solid reviewer and contributor to that project for quite 
awhile now:


http://stackalytics.com/report/contribution/python-novaclient/180

He's always fast to get new changes up for microversion support and 
help review others that are there to keep moving changes forward.


So unless there are objections, I'll plan on adding Takashi to the 
python-novaclient-core group next week.


I've added Takashi to python-novaclient-core:

https://review.openstack.org/#/admin/groups/572,members

Thanks everyone.



Regards,
Takashi Natsume
NTT Software Innovation Center
E-mail: natsume.taka...@lab.ntt.co.jp


__
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-dev] [nova] API reference verification for servers APIs (parameter and example)

2018-01-23 Thread Takashi Natsume


Hi, Nova developers.

There was work verifying the Nova compute API Reference
(*1, *2, *3, *4) before.
But the verification has not been completed yet in "Servers" APIs
(creating, updating, deleting a server, listing servers, etc.).

*1: Convert API Reference to RST and host it in the Nova tree (partial)
https://blueprints.launchpad.net/nova/+spec/api-ref-in-rst

*2: Convert API Reference to RST and host it in the Nova tree (Ocata)
https://blueprints.launchpad.net/nova/+spec/api-ref-in-rst-ocata

*3: Convert API Reference to RST and host it in the Nova tree (Pike)
https://blueprints.launchpad.net/nova/+spec/api-ref-in-rst-pike

*4: NovaAPIRef
https://wiki.openstack.org/wiki/NovaAPIRef


I submitted the following patches
to complete parameter and example verification in "Servers" APIs.

api-ref: Parameter verification for servers.inc
https://review.openstack.org/#/c/528201/

api-ref: Example verification for servers.inc
https://review.openstack.org/#/c/529520/

Regards,
Takashi Natsume
NTT Software Innovation Center
E-mail: natsume.taka...@lab.ntt.co.jp


__
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-dev] [nova] openstack-tox-py27 job is not executed when spec files are added or modified in nova-specs

2017-11-15 Thread Takashi Natsume


Hi, Nova developers.

In nova-specs project, there is an 'openstack-tox-py27' job (in Zuul 
check or Zuul gate).
The job checks whether spec files comply with the template or not, line 
length, etc.
But there are cases that the job is not executed even if a spec file is 
added or modified.


For example, in https://review.openstack.org/#/c/508164/, a spec file 
was added.

But the 'openstack-tox-py27' job was not executed.
So the following error occurs after it has been merged.

* nova-specs: py27 fails "Line limited to a maximum of 79 characters."
  https://bugs.launchpad.net/nova/+bug/1732581

When a spec file is added or modified, the 'openstack-tox-py27' job 
should be executed.


Regards,
Takashi Natsume
NTT Software Innovation Center
E-mail: natsume.taka...@lab.ntt.co.jp


__
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] [nova] A way to delete a record in 'host_mappings' table

2017-10-03 Thread Takashi Natsume


On 2017/10/03 23:12, Dan Smith wrote:

But the record in 'host_mappings' table of api database is not deleted
(I tried it with nova master 8ca24bf1ff80f39b14726aca22b5cf52603ea5a0).
The cell cannot be deleted if the records for the cell remains in 
'host_mappings' table.
(An error occurs with a message "There are existing hosts mapped to cell with uuid 
...".)

Are there any ways (CLI, API) to delete the host record in 'host_mappings' 
table?
I couldn't find it.


Hmm, yeah, I bet this is a gap. Can you file a bug for this?


Dan, thank you for your reply.
I have filed the bug.

https://bugs.launchpad.net/nova/+bug/1721179

Regards,
Takashi Natsume
NTT Software Innovation Center
E-mail: natsume.taka...@lab.ntt.co.jp




__
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-dev] [nova] A way to delete a record in 'host_mappings' table

2017-10-03 Thread Takashi Natsume


Hi. Nova developers.

In cell v2 environment, when deleting a host (compute node) by 'nova 
service-delete',
the records are soft deleted in the 'services' table and the 
'compute_nodes' table of the cell database.


But the record in 'host_mappings' table of api database is not deleted
(I tried it with nova master 8ca24bf1ff80f39b14726aca22b5cf52603ea5a0).
The cell cannot be deleted if the records for the cell remains in 
'host_mappings' table.
(An error occurs with a message "There are existing hosts mapped to cell 
with uuid ...".)


Are there any ways (CLI, API) to delete the host record in 
'host_mappings' table?

I couldn't find it.

Regards,
Takashi Natsume
NTT Software Innovation Center
E-mail: natsume.taka...@lab.ntt.co.jp


__
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-dev] [nova] Suggestion about code review guide in microversion API

2017-08-16 Thread Takashi Natsume


Hi Nova Developers.

When the API microversion is bumped,
patches are required not only in nova side but also in python-novaclient  
side.


But, after the nova patches were merged,
the python-novaclient patches were sometimes not submitted for a while.

The patch in python-novaclient is necessary to submit a patch for a  
subsequent microversion.

For example, the patch for microversion 2.55 should be merged
after the patch for microversion 2.54 is merged.
There is a dependency between them.

So I'm proposing an amendment to the code review guide [1].
The code review guide should be changed as follows:

-
A new patch for the microversion API change in python-novaclient side  
should be submitted

*before the microversion change in Nova is merged*.
-

[1] https://review.openstack.org/#/c/494173/

Regards,
Takashi Natsume
NTT Software Innovation Center
E-mail: natsume.taka...@lab.ntt.co.jp


__
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] [nova] The definition of 'Optional' parameter in API reference

2017-07-04 Thread Takashi Natsume

On 2017/07/04 21:12, Alex Xu wrote:

2017-07-04 15:40 GMT+08:00 Ghanshyam Mann <ghanshyamm...@gmail.com>:

On Mon, Jul 3, 2017 at 1:38 PM, Takashi Natsume
<natsume.taka...@lab.ntt.co.jp> wrote:

In Nova API reference, there is inconsistency in
whether to define parameters added in new microversion as 'optional' or

not.

Those should be defined based on how they are defined in respective
microversion. If they are 'optional' in that microversion they should
be mentioned as 'optional' and vice versa. Any parameter added in
microversion is mentioned as 'New in version 2.xy' which shows the non
availability of that parameter in earlier versions. Same case for
removal of parameter also.

But if any microversion change parameter from option param to required
or vice versa then it is tricky but IMO documenting the latest
behavior is right thing but with clear notes.
For example, microversion 2.37, where 'network' in request made as
required from optional. In this cases, api-ref have the latest
behavior of that param which is 'required' and a clear notes about
till when it was optional and from when it is mandatory.

In all cases, doc should reflect the latest behavior of param with
notes(manual or auto generated with min_version & max_version)

Thank you for your replies and the fix in
https://review.openstack.org/#/c/480162/ .

In the case that the parameter is always included in the response after a
certain microversion,
some parameters(e.g. 'type' [1]) are defined as 'required', but some
parameters (e.g. 'project_id', 'user_id'[2])
are defined as 'optional'.

[1] List Keypairs in Keypairs (keypairs)
https://developer.openstack.org/api-ref/compute/?expanded=

list-keypairs-detail#list-keypairs

'keypairs_links' in the response should be the required parameter. Because
it always show up after 2.35.

The 'keypairs_links' is an optional parameter.
When the 'get_links' method of the view builder for keypairs operations
returns an empty list, the 'keypairs_links' does not appear
in the response.

https://github.com/openstack/nova/blob/32e613b9cd499847b7a7dc49d43020523b96c1d1/nova/api/openstack/compute/keypairs.py#L286-L288

Regards,
Takashi Natsume
NTT Software Innovation Center
E-mail: natsume.taka...@lab.ntt.co.jp

[openstack-dev] [nova] The definition of 'Optional' parameter in API reference

2017-07-02 Thread Takashi Natsume


Hi, all.

In Nova API reference, there is inconsistency in
whether to define parameters added in new microversion as 'optional' or not.

In the case that the parameter is always included in the response after  
a certain microversion,
some parameters(e.g. 'type' [1]) are defined as 'required', but some  
parameters (e.g. 'project_id', 'user_id'[2])

are defined as 'optional'.

[1] List Keypairs in Keypairs (keypairs)
 
https://developer.openstack.org/api-ref/compute/?expanded=list-keypairs-detail#list-keypairs


[2] List Server Groups in Server groups (os-server-groups)
 
https://developer.openstack.org/api-ref/compute/?expanded=list-server-groups-detail#list-server-groups



In the case that the parameter is always included in the response after  
a certain microversion,

should it be defined as 'required' instead of 'optional'?

Regards,
Takashi Natsume
NTT Software Innovation Center
E-mail: natsume.taka...@lab.ntt.co.jp


__
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] [nova] Fix an issue with resolving citations in nova-specs

2017-06-06 Thread Takashi Natsume


On 2017/06/05 22:19, Sean Dague wrote:

On 06/05/2017 01:06 AM, Takashi Natsume wrote:

But IMO, it is better to fix citations in specs (*4)
rather than capping the sphinx version.


Thank you for the patch, I just merged *4.


Thank you.

It is no longer necessary to cap the sphinx version in nova-specs.
So I submitted the following patch to uncap the sphinx version.

https://review.openstack.org/#/c/471153/

Regards,
Takashi Natsume
NTT Software Innovation Center
E-mail: natsume.taka...@lab.ntt.co.jp




__
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-dev] [nova] Fix an issue with resolving citations in nova-specs

2017-06-04 Thread Takashi Natsume


Hi, Nova developers.

The version of sphinx has been capped (*1)
in order to fix an issue (*2, *3) with resolving citations in nova-specs.

But IMO, it is better to fix citations in specs (*4)
rather than capping the sphinx version.

-
*1: Cap sphinx<1.6.1
  https://review.openstack.org/#/c/470434/

*2: nova-specs docs builds fail with sphinx 1.6.1: Citation is not  
referenced.

  https://bugs.launchpad.net/nova/+bug/1693010

*3: nova-specs docs builds fail with sphinx 1.6.2: Citation is not  
referenced.

  https://bugs.launchpad.net/nova/+bug/1695127

*4: Fix citation references (Sphinx 1.6.x compatibility)
https://review.openstack.org/#/c/470252/
-

Regards,
Takashi Natsume
NTT Software Innovation Center
E-mail: natsume.taka...@lab.ntt.co.jp


__
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] [nova] Inconsistency of parameter type in Nova API Reference

2017-01-12 Thread Takashi Natsume


On 2017/01/10 20:35, Sean Dague wrote:

On 01/10/2017 01:39 AM, Takashi Natsume wrote:

Hi Nova developers.

In Nova API Reference(*1),
the following parameters' values are 'null' in HTTP request body samples.
And their parameter types are defined as 'string'.

* 'confirmResize' parameter in "Confirm Resized Server (confirmResize
Action)"
* 'lock' parameter in "Lock Server (lock Action)"
* 'pause' parameter in "Pause Server (pause Action)"
* 'resume' parameter in "Resume Suspended Server (resume Action)"
* 'revertResize' parameter in "Revert Resized Server (revertResize Action)"
* 'os-start' parameter in "Start Server (os-start Action)"
* 'os-stop' parameter in "Stop Server (os-stop Action)"
* 'suspend' parameter in "Suspend Server (suspend Action)"

On the other hand,
the following parameter's value is 'null' in the HTTP request body sample.
But the parameter type is defined as 'none'.

* 'trigger_crash_dump' in "Trigger Crash Dump In Server"

IMO, there is inconsistency of parameter types.
Should they be unified as 'none'?


+1. 'none' seem appropriate here and not confuse this with strings.

-Sean


Thank you for your reply.
I will replace 'string' with 'none' in the parameters.

Regards,
Takashi Natsume
NTT Software Innovation Center
E-mail: natsume.taka...@lab.ntt.co.jp



__
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-dev] [nova] Inconsistency of parameter type in Nova API Reference

2017-01-09 Thread Takashi Natsume


Hi Nova developers.

In Nova API Reference(*1),
the following parameters' values are 'null' in HTTP request body samples.
And their parameter types are defined as 'string'.

* 'confirmResize' parameter in "Confirm Resized Server (confirmResize  
Action)"

* 'lock' parameter in "Lock Server (lock Action)"
* 'pause' parameter in "Pause Server (pause Action)"
* 'resume' parameter in "Resume Suspended Server (resume Action)"
* 'revertResize' parameter in "Revert Resized Server (revertResize Action)"
* 'os-start' parameter in "Start Server (os-start Action)"
* 'os-stop' parameter in "Stop Server (os-stop Action)"
* 'suspend' parameter in "Suspend Server (suspend Action)"

On the other hand,
the following parameter's value is 'null' in the HTTP request body sample.
But the parameter type is defined as 'none'.

* 'trigger_crash_dump' in "Trigger Crash Dump In Server"

IMO, there is inconsistency of parameter types.
Should they be unified as 'none'?

*1: Compute API Reference
http://developer.openstack.org/api-ref/compute/

Regards,
Takashi Natsume
NTT Software Innovation Center
E-mail: natsume.taka...@lab.ntt.co.jp



__
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] [nova] Outlook on Ocata blueprints

2017-01-03 Thread Takashi Natsume


Hi Matt.

The following blueprint has been approved for ocata,
but it is not in "nova-ocata-feature-freeze" etherpad.

* 
https://blueprints.launchpad.net/nova/+spec/cold-migration-with-target-ocata

* https://review.openstack.org/#/c/334725/ (spec)

The blueprint's definition is "Approved", but the series goal is still 
"Proposed for ocata".

It should be "Accepted for ocata".

Would you change it to "Accepted for ocata"?

On 2016/12/29 10:19, Matt Riedemann wrote:

Over the last couple of days I've gone over each blueprint targeted for
Ocata [1] which isn't yet implemented. I've categorized each based on
it's current status or what my outlook is for it getting done in this
release before the feature freeze on January 26th. The results are here:

https://etherpad.openstack.org/p/nova-ocata-feature-freeze

We have 69 blueprints targeted for Ocata of which only 14 are already
implemented (complete). That leaves 55 outstanding blueprints.

I've broken them down as such:

- Good progress: there are 16 of these which I'm fairly confident can
get merged before the feature freeze given enough focus. 5 of these are
priorities.

- Slow progress / at risk: there are 19 of these which for one reason or
another are at risk of not getting completed before the feature freeze.
Some just haven't had enough (or any) core reviewer attention yet, or
they are wayward changes that look basically abandoned. 2 of these are
related to priorities.

- Not started / blocked: there are 13 of these. Some don't have any code
proposed yet. Several are blocked because of dependencies on library
releases or other projects (some for os-vif or Ironic for example). 2 of
these are priorities.

- On-going refactor / cleanup series: there are 7 of these. I consider
these lower priority as they are multi-release efforts and what doesn't
get done in Ocata can be worked on in Pike.

--

As you'll see in the etherpad, I have notes on each one. If you own one
of these blueprints and there is a note about something that needs to
get done, please make that a priority if you want to see the blueprint
have a chance of landing in Ocata.

Keep in mind that the non-client library release freeze for Ocata is
January 19th, so if you have dependencies on os-* or oslo libraries
those need to get released before the 19th, and then after that there is
only one week until feature freeze. With most people out until the 3rd,
that only leaves 3 weeks to get library changes released and 4 weeks
until feature freeze.

If you know that you aren't going to have the time to work on something
please let me know and we can look for volunteers to pick up the
remaining work or I'll defer the blueprint out of tracking for Ocata so
reviewers can focus on what's planned to get done.

If by January 12th we still have changes which haven't started I'll
probably just automatically defer them.

Please let me know if there are any questions.

[1] https://blueprints.launchpad.net/nova/ocata


Regards,
Takashi Natsume
NTT Software Innovation Center
E-mail: natsume.taka...@lab.ntt.co.jp



__
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-dev] [nova][cinder] Fix nova swap volume (updating an attached volume) function

2016-02-25 Thread Takashi Natsume

Hi Nova and Cinder developers.

As I reported in a bug report [1], nova swap volume
(updating an attached volume) fuction does not work
in the case of non admin users by default. 
(Volumes are stuck.)

Before I was working for fixing another swap volume bug [2][3].
But Ryan fixed it on the Cinder side [4].
As a result, admin users can execute swap volume function,
but it was not fixed in the case of non admin users.
So I reported the bug report [1].

In the patch[5], I tried to change the default cinder's policy
to allow non admin users to execute migrate_volume_completion API.
But it was rejected by the cinder project ('-2' was voted).

In the patch[5], it was suggested to make the swap volume API admin only
on the Nova side.
But IMO, the swap volume function should be allowed to non admin users
because attaching a volume and detaching a volume can be performed
by non admin users.

If migrate_volume_completion is only allowed to admin users
by default on the Cinder side, attaching a new volume and
detaching an old volume should be performed on the Nova side
when swapping volumes.

If you have a good idea, please let me know it.

[1] Cinder volumes are stuck when non admin user executes nova swap volume API
https://bugs.launchpad.net/cinder/+bug/1522705

[2] Cinder volume stuck in swap_volume
https://bugs.launchpad.net/nova/+bug/1471098

[3] Fix cinder volume stuck in swap_volume
https://review.openstack.org/#/c/207385/

[4] Fix swap_volume for case without migration
https://review.openstack.org/#/c/247767/

[5] Enable volume owners to execute migrate_volume_completion
https://review.openstack.org/#/c/253363/

Regards,
Takashi Natsume
NTT Software Innovation Center
E-mail: natsume.taka...@lab.ntt.co.jp





__
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] [nova] Authorization by user_id does not work in V2.1 API

2016-02-07 Thread Takashi Natsume

> This doesn't feel intentional, and is a good catch.
> https://review.openstack.org/#/c/276738/ was pushed this morning to fix it. I 
> think that's fine (and can be backported)
> but needs tests.

Sean,

Thank you for your reply.
I will review the patch.

> It would be good to know if there were other situations that were different 
> here between the old policy enforcement and
> the new one.

If I find another case, I will report it.

Regards,
Takashi Natsume
NTT Software Innovation Center
Tel: +81-422-59-4399
E-mail: natsume.taka...@lab.ntt.co.jp

> -Original Message-
> From: Sean Dague [mailto:s...@dague.net]
> Sent: Friday, February 05, 2016 11:12 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [nova] Authorization by user_id does not work in 
> V2.1 API
> 
> On 02/05/2016 02:46 AM, Takashi Natsume wrote:
> > Hi Nova developers,
> >
> > I have already submitted a bug report[1], authorization by user_id
> > when deleting a VM instance does not work in Nova V2.1 API although it
> > works in Nova V2.0 API.
> >
> > Has this change been done intentionally?
> >
> > [1] Authorization by user_id does not work in V2.1 API
> > https://bugs.launchpad.net/nova/+bug/1539351
> >
> > Regards,
> > Takashi Natsume
> > NTT Software Innovation Center
> > Tel: +81-422-59-4399
> > E-mail: natsume.taka...@lab.ntt.co.jp
> 
> This doesn't feel intentional, and is a good catch.
> https://review.openstack.org/#/c/276738/ was pushed this morning to fix it. I 
> think that's fine (and can be backported)
> but needs tests.
> 
> It would be good to know if there were other situations that were different 
> here between the old policy enforcement and
> the new one.
> 
>   -Sean
> 
> --
> Sean Dague
> http://dague.net
> 
> __
> 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

[openstack-dev] [nova] Authorization by user_id does not work in V2.1 API

2016-02-04 Thread Takashi Natsume

Hi Nova developers,

I have already submitted a bug report[1],
authorization by user_id when deleting a VM instance does not work in Nova V2.1 
API
although it works in Nova V2.0 API.

Has this change been done intentionally?

[1] Authorization by user_id does not work in V2.1 API
https://bugs.launchpad.net/nova/+bug/1539351

Regards,
Takashi Natsume
NTT Software Innovation Center
Tel: +81-422-59-4399
E-mail: natsume.taka...@lab.ntt.co.jp





__
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-dev] [Keystone] Token invalidation in deleting role assignments

2014-06-25 Thread Takashi Natsume

Hi all,

When deleting role assignments, not only tokens that are related with
deleted role assignments but also other tokens that the(same) user has are
invalidated in stable/icehouse(2014.1.1).

For example,
A) Role assignment between domain and user by OS-INHERIT(*1)
1. Assign a role(For example,'Member') between 'Domain1' and 'user' by
OS-INHERIT
2. Assign the role('Member') between 'Domain2' and 'user' by OS-INHERIT
3. Get a token with specifying 'user' and 'Project1'(in 'Domain1')
4. Get a token with specifying 'user' and 'Project2'(in 'Domain2')
5. Create reources(For example, cinder volumes) in 'Project1' with the token
that was gotten in 3.
it is possible to create them.
6. Create reources in 'Project2' with the token that was gotten in 4.
it is possible to create them.
7. Delete the role assignment between 'Domain1' and 'user' (that was added
in 1.)

(After validated token cache is expired in cinder, etc.)
8. Create reources in 'Project1' with the token that was gotten in 3.
it is not possible to create them. 401 Unauthorized.
9. Create reources in 'Project2' with the token that was gotten in 4.
it is not possible to create them. 401 Unauthorized.

In 9., my expectation is that it is possible to create resources with the
token that was gotten in 4..

*1:
v3/OS-INHERIT/domains/{domain_id}/users/{user_id}/roles/{role_id}/inherited_
to_projects

B) Role assignment between project and user
1. Assign a role(For example,'Member') between 'Project1' and 'user'
2. Assign the role('Member') between 'Project2' and 'user'
3. Get a token with specifying 'user' and 'Project1'
4. Get a token with specifying 'user' and 'Project2'
5. Create reources(For example, cinder volumes) in 'Project1' with the token
that was gotten in 3.
it is possible to create them.
6. Create reources in 'Project2' with the token that was gotten in 4.
it is possible to create them.
7. Delete the role assignment between 'Project1' and 'user' (that was added
in 1.)

(After validated token cache is expired in cinder, etc.)
8. Create reources in 'Project1' with the token that was gotten in 3.
it is not possible to create them. 401 Unauthorized.
9. Create reources in 'Project2' with the token that was gotten in 4.
it is not possible to create them. 401 Unauthorized.

In 9., my expectation is that it is possible to create resources with the
token that was gotten in 4..


Are these bugs?
Or are there any reasons to implement these ways?

Regards,
Takashi Natsume
NTT Software Innovation Center
Tel: +81-422-59-4399
E-mail: natsume.taka...@lab.ntt.co.jp




___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Keystone] Token invalidation in deleting role assignments