Re: [openstack-dev] [all] Zuul Error for commits

[Kekane, Abhishek]

Goutham,

Add ‘recheck’ as a comment. It will retrigger the jenkins jobs.

Thank you,

Abhishek

From: Goutham Pratapa [mailto:pratapagout...@gmail.com]
Sent: Thursday, October 05, 2017 5:14 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [all] Zuul Error for commits

Hi all,

I have made a commit to a Kingbird-project and Zuul jobs ran and a job namely 
openstack-tox-py27


failed with the error TIMED_OUT in 2h 32m 23s which resulted in -1 how can I 
retrigger it is

this a known issue??

Commit for reference: https://review.openstack.org/#/c/487813/

Any help?

Thanks in advance..

Cheers !!!
Goutham Pratapa

__
Disclaimer: This email and any attachments are sent in strictest confidence
for the sole use of the addressee and may contain legally privileged,
confidential, and proprietary data. If you are not the intended recipient,
please advise the sender by replying promptly to this email and then delete
and destroy this email and any attachments without any further use, copying
or forwarding.
__
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] What is the goal of AggregateImagePropertiesIsolation filter?

[Kekane, Abhishek]

Hi all,

As of now in the current master AggregateImagePropertiesIsolation filter 
returns True even if image property is not present in the host aggregate 
metadata.
Example:
(1) Set below required config options in nova.conf under 'filter_scheduler' 
section:
aggregate_image_properties_isolation_namespace is set to 'os'
aggregate_image_properties_isolation_separator is set to '_'
1) add Host Aggregate with custom metadata "os_windows":
++---+---+--++
| Id | Name  | Availability Zone | Hosts| Metadata   |
++---+---+--++
| 1  | win-agg   | - | 'controller'| 'os_type=os_windows'   
|
++---+---+--++
2) Add AggregateImagePropertiesIsolation filter to 'scheduler_default_filters'
scheduler_default_filters = 
RetryFilter,AggregateImagePropertiesIsolation,AvailabilityZoneFilter,RamFilter,DiskFilter,ComputeFilter,...
Scenario A: Image property is present in the host aggregate metadata
(a) Create image with property os_type=os_windows
(b) Boot VM using image created in point 1.
In this case, 'AggregateImagePropertiesIsolation' will return True and instance 
will be successfully created in host present in aggregate 'win-aggregate'.
Scenario B: Image property is not present in the host aggregate metadata
(a) Create image with property os=rhel
(b) Boot VM using image created in point 1.

In this case, AggregateImagePropertiesIsolation shouldn't select any host from 
"win-aggregate" host aggregate group as it doesn't contains 'os_type=os_rhel". 
But as per the current implementation [1], it is checking if image property key 
"os_type" is present or not. Even if it's not there, it is returning True from 
this filter, thus allowing to boot instance on the host from "win-aggregate" 
host aggregate group.

So the question here is, what is the exact goal of 
AggregateImagePropertiesIsolation' scheduler filter: - Is it one of the 
following:-
1. Matching all metadata of host aggregate with image properties.
2. Matching image properties with host aggregate metadata.

If we decide that actual goal of 'AggregateImagePropertiesIsolation' filter is 
as  pointed in #1, then a small correction is required to return False if image 
property is not present from the host aggregate metadata.
Please let me know your opinion about the same.

[1] 
https://github.com/openstack/nova/blob/master/nova/scheduler/filters/aggregate_image_properties_isolation.py#L53

Thank you,

Abhishek Kekane

__
Disclaimer: This email and any attachments are sent in strictest confidence
for the sole use of the addressee and may contain legally privileged,
confidential, and proprietary data. If you are not the intended recipient,
please advise the sender by replying promptly to this email and then delete
and destroy this email and any attachments without any further use, copying
or forwarding.__
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] [glance] priorities for the coming week (09/08-09/14)

[Kekane, Abhishek]

Hi Brian,

Thanks a lot for appreciation.
It was a great opportunity for me to work along with you, jokke and other 
peoples on glance pike cycle. A huge learning platform for me. It is my 
pleasure to be a part of glance core.

Thank you,

Abhishek Kekane



From: Brian Rosmaita 
Sent: Friday, September 8, 2017 6:25:26 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [glance] priorities for the coming week (09/08-09/14)

Hello Glancers,

1. No meeting on Sept 14 due to PTG.

2. The PTG schedule for Glance is available.  There are etherpads
associated with each session.  If you cannot attend the PTG but are
interested in a session, please put questions/comments on the
appropriate etherpad.  We won't be livecasting the sessions, but we
will have IRC open to  #openstack-glance and #openstack-ptg, and we'll
be taking notes on the session etherpad
- https://etherpad.openstack.org/p/glance-queens-ptg

3. We have bugs targeted to Q-1, so you can't go wrong this week by
reviewing any patches associated with them:
- https://launchpad.net/glance/+milestone/queens-1
- also https://review.openstack.org/#/c/493654/ and
https://review.openstack.org/#/c/492651/

4. We'll be triaging and prioritizing bugs on Thursday (22:30-23:30
UTC) and having a bugfix session Friday, Sept 15 (15:00-18:00 UTC).
Feel free to join in!

Have a good week, everyone!

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

__
Disclaimer: This email and any attachments are sent in strictest confidence
for the sole use of the addressee and may contain legally privileged,
confidential, and proprietary data. If you are not the intended recipient,
please advise the sender by replying promptly to this email and then delete
and destroy this email and any attachments without any further use, copying
or forwarding.__
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] [glance] confirming Abhishek Kekane for glance core

[Kekane, Abhishek]

Hi Brian,

Thanks a lot for appreciation.
It was a great opportunity for me to work along with you, jokke and other 
peoples on glance pike cycle. A huge learning platform for me. It is my 
pleasure to be a part of glance core.

Thank you,

Abhishek Kekane



From: Brian Rosmaita 
Sent: Wednesday, September 13, 2017 6:14:40 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [glance] confirming Abhishek Kekane for glance core

Back in June, I asked Abhishek Kekane to serve as glance core during
the Pike cycle [0].  His contributions exceeded all expectations.
Abhishek's careful reviews, bug fixes, patches, and general
contributions to the community were instrumental in Glance completing
the Pike release.  I'm happy to announce that Abhishek has agreed to
continue to serve the OpenStack community as a Glance core
contributor, and this note confirms his status as a "regular" member
of the Glance core group, with all the rights and privileges
pertaining thereto.

(I just want it to be completely clear before our Queens design
discussions begin this morning that there's nothing provisional about
Abhishek's glance core status -- he's a full-fledged glance core.)

Thanks again to Abhishek for his hard work during the Pike cycle, and
I look forward to working with him for many cycles to come.

cheers,
brian


[0] http://lists.openstack.org/pipermail/openstack-dev/2017-June/118503.html

__
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

__
Disclaimer: This email and any attachments are sent in strictest confidence
for the sole use of the addressee and may contain legally privileged,
confidential, and proprietary data. If you are not the intended recipient,
please advise the sender by replying promptly to this email and then delete
and destroy this email and any attachments without any further use, copying
or forwarding.__
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] [glance][rally] Disabling Glance Testing in Rally gates

[Kekane, Abhishek]

Initial finding:
This is something related to uwsgi socket timeout. Default value for 
socket-timeout is 30 in /etc/glance/glance-uwsgi.ini file.

For testing purpose I have tried to create 10 GB image using create command:
$ time glance --debug image-create --name dsl --file gentoo_root.img 
--disk-format iso --container-format bare

real2m48.539s
user0m4.076s
sys 0m10.012s

It has failed with “502 bad gateway” after 3 minutes. Then I have increased 
this timeout to 60 and restarted glance-api service and ran above command again.

$ time glance --debug image-create --name dsl --file gentoo_root.img 
--disk-format iso --container-format bare

After this I was able to create image without any issue.

So another workaround is to set socket-timeout to higher value in 
/etc/glance/glance-uwsgi.ini file.

Thank you,

Abhishek Kekane

From: Kekane, Abhishek [mailto:abhishek.kek...@nttdata.com]
Sent: Thursday, July 13, 2017 2:45 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [glance][rally] Disabling Glance Testing in Rally 
gates

Someone has reported this issue in glance recently.
Please refer, https://bugs.launchpad.net/glance/+bug/1703856

I think it is same kind of failure which Andrey was mentioning.

As mentioned in the bug temporary solution is to enable the v1 api using the v1 
parameter, --location instead of using --file. But this will not be applicable 
to rally scenarios I guess.
I will spend some time to understand the failure cause.

Thank you,

Abhishek


From: Andrey Kurilin [mailto:andr.kuri...@gmail.com]
Sent: Thursday, July 13, 2017 2:25 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [glance][rally] Disabling Glance Testing in Rally 
gates

Hi Flavio,

2017-07-13 11:16 GMT+03:00 Flavio Percoco 
<fla...@redhat.com<mailto:fla...@redhat.com>>:
On 13/07/17 00:56 -0700, Boris Pavlovic wrote:
Hi stackers,


Unfortunately what was discussed in other thread (situation in glance is
critical) happened.
Glance stopped working and Rally team is forced to disable checking of it
in Rally gates.

P.S. Seems like this patch is casing the problems:
https://github.com/openstack-dev/devstack/commit/1fa653635781cd975a1031e212b35b6c38196ba4

Hey Boris,

Has this been brought up to the Glance team? Or is this email meant to do that?

Yes

http://eavesdrop.openstack.org/irclogs/%23openstack-glance/%23openstack-glance.2017-07-11.log.html#t2017-07-11T07:44:13
http://eavesdrop.openstack.org/irclogs/%23openstack-glance/%23openstack-glance.2017-07-11.log.html#t2017-07-11T22:12:47

FWIW, the switch to uwsgi is a community goal and not so much a Glance thing.
Would you mind elaborating on what exactly is failing and how the glance team
can help?
I understand that switching to uwsgi is a community goal, but we didn't have 
any problems with Glance for years until now.

As from IRC logs:
> HTTPBadGateway: 502 Bad Gateway: Bad Gateway: The proxy server received an 
> invalid: response from an upstream server.: Apache/2.4.18 (Ubuntu) Server at 
> 158.69.73.26 Port 80 (HTTP 502)

Trace:

http://paste.openstack.org/show/615234/

Flavio

--
@flaper87
Flavio Percoco

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



--
Best regards,
Andrey Kurilin.

__
Disclaimer: This email and any attachments are sent in strictest confidence
for the sole use of the addressee and may contain legally privileged,
confidential, and proprietary data. If you are not the intended recipient,
please advise the sender by replying promptly to this email and then delete
and destroy this email and any attachments without any further use, copying
or forwarding.

__
Disclaimer: This email and any attachments are sent in strictest confidence
for the sole use of the addressee and may contain legally privileged,
confidential, and proprietary data. If you are not the intended recipient,
please advise the sender by replying promptly to this email and then delete
and destroy this email and any attachments without any further use, copying
or forwarding.
__
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] [glance][rally] Disabling Glance Testing in Rally gates

[Kekane, Abhishek]

Someone has reported this issue in glance recently.
Please refer, https://bugs.launchpad.net/glance/+bug/1703856

I think it is same kind of failure which Andrey was mentioning.

As mentioned in the bug temporary solution is to enable the v1 api using the v1 
parameter, --location instead of using --file. But this will not be applicable 
to rally scenarios I guess.
I will spend some time to understand the failure cause.

Thank you,

Abhishek


From: Andrey Kurilin [mailto:andr.kuri...@gmail.com]
Sent: Thursday, July 13, 2017 2:25 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [glance][rally] Disabling Glance Testing in Rally 
gates

Hi Flavio,

2017-07-13 11:16 GMT+03:00 Flavio Percoco 
>:
On 13/07/17 00:56 -0700, Boris Pavlovic wrote:
Hi stackers,


Unfortunately what was discussed in other thread (situation in glance is
critical) happened.
Glance stopped working and Rally team is forced to disable checking of it
in Rally gates.

P.S. Seems like this patch is casing the problems:
https://github.com/openstack-dev/devstack/commit/1fa653635781cd975a1031e212b35b6c38196ba4

Hey Boris,

Has this been brought up to the Glance team? Or is this email meant to do that?

Yes

http://eavesdrop.openstack.org/irclogs/%23openstack-glance/%23openstack-glance.2017-07-11.log.html#t2017-07-11T07:44:13
http://eavesdrop.openstack.org/irclogs/%23openstack-glance/%23openstack-glance.2017-07-11.log.html#t2017-07-11T22:12:47

FWIW, the switch to uwsgi is a community goal and not so much a Glance thing.
Would you mind elaborating on what exactly is failing and how the glance team
can help?
I understand that switching to uwsgi is a community goal, but we didn't have 
any problems with Glance for years until now.

As from IRC logs:
> HTTPBadGateway: 502 Bad Gateway: Bad Gateway: The proxy server received an 
> invalid: response from an upstream server.: Apache/2.4.18 (Ubuntu) Server at 
> 158.69.73.26 Port 80 (HTTP 502)

Trace:

http://paste.openstack.org/show/615234/

Flavio

--
@flaper87
Flavio Percoco

__
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



--
Best regards,
Andrey Kurilin.

__
Disclaimer: This email and any attachments are sent in strictest confidence
for the sole use of the addressee and may contain legally privileged,
confidential, and proprietary data. If you are not the intended recipient,
please advise the sender by replying promptly to this email and then delete
and destroy this email and any attachments without any further use, copying
or forwarding.
__
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] [masakari][nova] Allow evacuation of instances in resized state

[Kekane, Abhishek]

Hi Saverio,

Thank you for reply.

Currently we are using Ocata release for Openstack.

Please let me know if you get any update.

Thank you,

Abhishek 

-Original Message-
From: Saverio Proto [mailto:ziopr...@gmail.com] 
Sent: Monday, July 10, 2017 12:52 PM
To: Kekane, Abhishek
Cc: OpenStack Development Mailing List (not for usage questions); 
openstack-operat...@lists.openstack.org
Subject: Re: [Openstack-operators] [openstack-dev] [masakari][nova] Allow 
evacuation of instances in resized state

Hello Abhishek,

I am sorry I dont have an answer for your question. I would have to try my self 
everything to give answer because I never experienced this use case you 
describe.

I would suggest also to specify what version of Openstack you are working with. 
Because the behaviour can change a lot in different versions.

Cheers,

Saverio


2017-07-10 9:00 GMT+02:00 Kekane, Abhishek <abhishek.kek...@nttdata.com>:
> Hi Operators,
>
> Could you please let me know your opinion on below scenario? It will help me 
> to proceed my work.
>
> Thank you,
>
> Abhishek
>
> -Original Message-
> From: Kekane, Abhishek [mailto:abhishek.kek...@nttdata.com]
> Sent: Tuesday, July 04, 2017 2:52 PM
> To: OpenStack Development Mailing List (not for usage questions); 
> openstack-operat...@lists.openstack.org
> Subject: Re: [Openstack-operators] [openstack-dev] [masakari][nova] 
> Allow evacuation of instances in resized state
>
> Hi operators,
>
> I want to know how evacuation of resized instances is handled in real 
> environment.
> For example if the vm is in resized state and if the compute host on which 
> the vm is resized goes down, then how will operator evacuate the vm.
>
> One possible way is to reset that vm state to error and then evacuate it to 
> new compute host.
> Please refer below scenario for reference:
>
> Scenario:
> =
>
> Pre-conditions:
> 
> 1. Config option allow_resize_to_same_host is False.
> 2. Instance path is not mounted on shared storage.
> 3. Three compute nodes: "compute node A", "compute node B" and "compute node 
> C"
>
> Steps:
> 
> 1. Boot an instance on "compute node A".
> 2. User tries to resize the newly created instance and nova-scheduler selects 
> "compute node B" as a destination node for resize.
>In this case nova creates a instance directory on destination "compute 
> node B" and mark the instance directory which is present on the source 
> "compute node A" as "*_resize".
>
> Note that the resize operation is yet not confirmed and "compute node B" goes 
> down.
>
> 3. Reset instance state to ERROR as nova allows evacuation only if instance 
> state is 'ACTIVE', 'STOPPED' or 'ERROR'.
> 4. Evacuate the instance to "compute node C" using target_host option.
>As a result, instance files which were on "compute node B" will be cleaned 
> up after compute service on it is up again, but instance files which were on 
> "compute node A" marked as "*_resize" will never be cleaned up. As of now 
> there is no periodic task in nova to perform cleanup of these kinds of 
> scenarios.
>
>
> Questions:
> 1. is this the only possible way of evacuating the resized instances in real 
> world scenario?
> 2. If yes is there any way to cleanup unused (*_resize) instance files from 
> the source compute node other than cleaning up it manually?
> 3. Should we add support of evacuating of resized instances in nova?
>
> Please let me know your opinions about the same.
>
>
> Thank you,
>
> Abhishek Kekane
>
>
>
> -Original Message-
> From: Kekane, Abhishek [mailto:abhishek.kek...@nttdata.com]
> Sent: Thursday, June 29, 2017 5:57 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [masakari][nova] Allow evacuation of 
> instances in resized state
>
> Hi Chris,
>
> IMO we cannot perform auto-confirm as confirming or reverting is user's 
> choice, whereas reverting is not possible as the node where the instance is 
> resized is down.
> As suggested by you allowing this in nova require additional work. It is 
> possible if we take power-state into consideration for evacuation operation, 
> i.e. while evacuation if instance vmstate is resized and power-state is 
> shutoff then we can stop that instance after evacuation.
>
> Thank you,
>
> Abhishek Kekane
>
> -Original Message-
> From: Chris Friesen [mailto:chris.frie...@windriver.com]
> Sent: Wednesday, June 28, 2017 8:54 PM
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [masakari

Re: [openstack-dev] [masakari][nova] Allow evacuation of instances in resized state

[Kekane, Abhishek]

Hi Operators,

Could you please let me know your opinion on below scenario? It will help me to 
proceed my work.

Thank you,

Abhishek

-Original Message-
From: Kekane, Abhishek [mailto:abhishek.kek...@nttdata.com] 
Sent: Tuesday, July 04, 2017 2:52 PM
To: OpenStack Development Mailing List (not for usage questions); 
openstack-operat...@lists.openstack.org
Subject: Re: [Openstack-operators] [openstack-dev] [masakari][nova] Allow 
evacuation of instances in resized state

Hi operators,

I want to know how evacuation of resized instances is handled in real 
environment.
For example if the vm is in resized state and if the compute host on which the 
vm is resized goes down, then how will operator evacuate the vm.

One possible way is to reset that vm state to error and then evacuate it to new 
compute host.
Please refer below scenario for reference:

Scenario:
=

Pre-conditions:

1. Config option allow_resize_to_same_host is False.
2. Instance path is not mounted on shared storage.
3. Three compute nodes: "compute node A", "compute node B" and "compute node C"

Steps:

1. Boot an instance on "compute node A".
2. User tries to resize the newly created instance and nova-scheduler selects 
"compute node B" as a destination node for resize.
   In this case nova creates a instance directory on destination "compute node 
B" and mark the instance directory which is present on the source "compute node 
A" as "*_resize".

Note that the resize operation is yet not confirmed and "compute node B" goes 
down.

3. Reset instance state to ERROR as nova allows evacuation only if instance 
state is 'ACTIVE', 'STOPPED' or 'ERROR'.
4. Evacuate the instance to "compute node C" using target_host option.
   As a result, instance files which were on "compute node B" will be cleaned 
up after compute service on it is up again, but instance files which were on 
"compute node A" marked as "*_resize" will never be cleaned up. As of now there 
is no periodic task in nova to perform cleanup of these kinds of scenarios.


Questions:
1. is this the only possible way of evacuating the resized instances in real 
world scenario?
2. If yes is there any way to cleanup unused (*_resize) instance files from the 
source compute node other than cleaning up it manually?
3. Should we add support of evacuating of resized instances in nova?

Please let me know your opinions about the same.


Thank you,

Abhishek Kekane



-Original Message-
From: Kekane, Abhishek [mailto:abhishek.kek...@nttdata.com]
Sent: Thursday, June 29, 2017 5:57 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [masakari][nova] Allow evacuation of instances in 
resized state

Hi Chris,

IMO we cannot perform auto-confirm as confirming or reverting is user's choice, 
whereas reverting is not possible as the node where the instance is resized is 
down.
As suggested by you allowing this in nova require additional work. It is 
possible if we take power-state into consideration for evacuation operation, 
i.e. while evacuation if instance vmstate is resized and power-state is shutoff 
then we can stop that instance after evacuation.

Thank you,

Abhishek Kekane 

-Original Message-
From: Chris Friesen [mailto:chris.frie...@windriver.com]
Sent: Wednesday, June 28, 2017 8:54 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [masakari][nova] Allow evacuation of instances in 
resized state

On 06/28/2017 05:50 AM, Kekane, Abhishek wrote:

> In masakari, we are setting an instance to an error state if the 
> vmstate is resized before evacuating it to a new host.

Arguably the instance should be set to an error state as soon as you notice 
that the compute node is down.

> Once an instance (which was in
> resized state) is evacuated then it becomes active on the new host. 
> The main problem with this implementation from user’s point of view is 
> the instance goes into active state after evacuation, it should be in 
> stopped state if the prior action on the instance before resizing was 
> stop. In masakari, It’s possible to set the vm state to stopped state 
> after evacuation but for a short period the instance will go into the active 
> state which is unacceptable.

That's a valid point, I think.

> *Proposing changes to Nova:*
>
> In the current nova code, if the instance is in stopped state before 
> evacuation, then it remains in the stopped state after evacuation is 
> complete. On the similar lines, we are proposing nova should allow 
> instance to be evacuated in resized state and after evacuation the 
> instance should remain in stopped state if the prior action on the instance 
> is stopped before resizing.

The current nova code looks at the vm_state to decide wh

Re: [openstack-dev] [masakari][nova] Allow evacuation of instances in resized state

[Kekane, Abhishek]

Hi operators,

I want to know how evacuation of resized instances is handled in real 
environment.
For example if the vm is in resized state and if the compute host on which the 
vm is resized goes down, then how will operator evacuate the vm.

One possible way is to reset that vm state to error and then evacuate it to new 
compute host.
Please refer below scenario for reference:

Scenario:
=

Pre-conditions:

1. Config option allow_resize_to_same_host is False.
2. Instance path is not mounted on shared storage.
3. Three compute nodes: "compute node A", "compute node B" and "compute node C"

Steps:

1. Boot an instance on "compute node A".
2. User tries to resize the newly created instance and nova-scheduler selects 
"compute node B" as a destination node for resize.
   In this case nova creates a instance directory on destination "compute node 
B" and mark the instance directory which is present on the source "compute node 
A" as "*_resize".

Note that the resize operation is yet not confirmed and "compute node B" goes 
down.

3. Reset instance state to ERROR as nova allows evacuation only if instance 
state is 'ACTIVE', 'STOPPED' or 'ERROR'.
4. Evacuate the instance to "compute node C" using target_host option.
   As a result, instance files which were on "compute node B" will be cleaned 
up after compute service on it is up again, but instance files which were on 
"compute node A" marked as "*_resize" will never be cleaned up. As of now there 
is no periodic task in nova to perform cleanup of these kinds of scenarios.


Questions:
1. is this the only possible way of evacuating the resized instances in real 
world scenario?
2. If yes is there any way to cleanup unused (*_resize) instance files from the 
source compute node other than cleaning up it manually?
3. Should we add support of evacuating of resized instances in nova?

Please let me know your opinions about the same.


Thank you,

Abhishek Kekane



-Original Message-
From: Kekane, Abhishek [mailto:abhishek.kek...@nttdata.com] 
Sent: Thursday, June 29, 2017 5:57 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [masakari][nova] Allow evacuation of instances in 
resized state

Hi Chris,

IMO we cannot perform auto-confirm as confirming or reverting is user's choice, 
whereas reverting is not possible as the node where the instance is resized is 
down.
As suggested by you allowing this in nova require additional work. It is 
possible if we take power-state into consideration for evacuation operation, 
i.e. while evacuation if instance vmstate is resized and power-state is shutoff 
then we can stop that instance after evacuation.

Thank you,

Abhishek Kekane 

-Original Message-
From: Chris Friesen [mailto:chris.frie...@windriver.com]
Sent: Wednesday, June 28, 2017 8:54 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [masakari][nova] Allow evacuation of instances in 
resized state

On 06/28/2017 05:50 AM, Kekane, Abhishek wrote:

> In masakari, we are setting an instance to an error state if the 
> vmstate is resized before evacuating it to a new host.

Arguably the instance should be set to an error state as soon as you notice 
that the compute node is down.

> Once an instance (which was in
> resized state) is evacuated then it becomes active on the new host. 
> The main problem with this implementation from user’s point of view is 
> the instance goes into active state after evacuation, it should be in 
> stopped state if the prior action on the instance before resizing was 
> stop. In masakari, It’s possible to set the vm state to stopped state 
> after evacuation but for a short period the instance will go into the active 
> state which is unacceptable.

That's a valid point, I think.

> *Proposing changes to Nova:*
>
> In the current nova code, if the instance is in stopped state before 
> evacuation, then it remains in the stopped state after evacuation is 
> complete. On the similar lines, we are proposing nova should allow 
> instance to be evacuated in resized state and after evacuation the 
> instance should remain in stopped state if the prior action on the instance 
> is stopped before resizing.

The current nova code looks at the vm_state to decide whether or not it's 
allowable to evacuate, and while "stopped" is a valid state to evacuate from 
"resized" is not.  In your scenario it's both "stopped" *and* "resized" 
simultaneously, but there's no way to represent that in the vmstate so I think 
we'd have to check the power state, which would mean extending the
check_instance_state() routine since it doesn't currently handle the power 
state.

The trickier question is how to handle the &q

Re: [openstack-dev] [glance] stepping down from glance core and other related groups

[Kekane, Abhishek]

Hi Nikhil,

I am very thankful for support and guidance you have provided to me and other 
new members. Hoping to work with you again in near future. All the best for 
your future activities.

Cheers,

Abhishek

Sent from OWA on Android

From: Nikhil Komawar 
Sent: Thursday, June 29, 2017 9:39:30 AM
To: OpenStack Development Mailing List
Subject: [openstack-dev] [glance] stepping down from glance core and other 
related groups

I am thankful to the community for such amazing experience over the past few 
years. For the changes required for glance personnel in the active cycle, I 
would like to step down from core as I cannot commit as much time upstream. I 
was hanging out to help in general but even that time commitment will be 
difficult in the coming months. This should effectively mean, me stepping down 
from the release, core-sec, specs core groups too. I am happy to help where 
needed on case by case basis but I do not think +2/-2 rights or me being 
subscribed to glance-core-sec is needed for such.

Good luck to glancers and all those who form (ionic or covalent) bonds with the 
glance community. Cheers.

--
--
Thanks,
Nikhil

__
Disclaimer: This email and any attachments are sent in strictest confidence
for the sole use of the addressee and may contain legally privileged,
confidential, and proprietary data. If you are not the intended recipient,
please advise the sender by replying promptly to this email and then delete
and destroy this email and any attachments without any further use, copying
or forwarding.__
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] [masakari][nova] Allow evacuation of instances in resized state

[Kekane, Abhishek]

Hi Chris,

IMO we cannot perform auto-confirm as confirming or reverting is user's choice, 
whereas reverting is not possible as the node where the instance is resized is 
down.
As suggested by you allowing this in nova require additional work. It is 
possible if we take power-state into consideration for evacuation operation, 
i.e. while evacuation if instance vmstate is resized and power-state is shutoff 
then we can stop that instance after evacuation.

Thank you,

Abhishek Kekane 

-Original Message-
From: Chris Friesen [mailto:chris.frie...@windriver.com] 
Sent: Wednesday, June 28, 2017 8:54 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [masakari][nova] Allow evacuation of instances in 
resized state

On 06/28/2017 05:50 AM, Kekane, Abhishek wrote:

> In masakari, we are setting an instance to an error state if the 
> vmstate is resized before evacuating it to a new host.

Arguably the instance should be set to an error state as soon as you notice 
that the compute node is down.

> Once an instance (which was in
> resized state) is evacuated then it becomes active on the new host. 
> The main problem with this implementation from user’s point of view is 
> the instance goes into active state after evacuation, it should be in 
> stopped state if the prior action on the instance before resizing was 
> stop. In masakari, It’s possible to set the vm state to stopped state 
> after evacuation but for a short period the instance will go into the active 
> state which is unacceptable.

That's a valid point, I think.

> *Proposing changes to Nova:*
>
> In the current nova code, if the instance is in stopped state before 
> evacuation, then it remains in the stopped state after evacuation is 
> complete. On the similar lines, we are proposing nova should allow 
> instance to be evacuated in resized state and after evacuation the 
> instance should remain in stopped state if the prior action on the instance 
> is stopped before resizing.

The current nova code looks at the vm_state to decide whether or not it's 
allowable to evacuate, and while "stopped" is a valid state to evacuate from 
"resized" is not.  In your scenario it's both "stopped" *and* "resized" 
simultaneously, but there's no way to represent that in the vmstate so I think 
we'd have to check the power state, which would mean extending the
check_instance_state() routine since it doesn't currently handle the power 
state.

The trickier question is how to handle the "resized" state...after evacuating 
an instance in the "resized" state should you be able to revert the resize?  If 
so, how would that work in the case where the instance was resized on the same 
host originally and that host is no longer available?  If not, then you'll end 
up with resources permanently reserved on the host the instance was on before 
the resize.  I suppose one option would be to auto-confirm the resize in the 
case of a resize-to-same-host, but that'll be tricky to process with the host 
not available.

Also, it should be noted that when rebuilding/evacuating a "stopped" instance 
the nova code just boots it up as normal and sets the vm_state to "active", 
then realizes that it's supposed to be stopped and sets the task_state to 
"powering_off" and goes down the normal path to stop the instance, eventually 
setting the vm_state to "stopped".  So you're still going to end up with the 
same state transitions as what you have now, though the timing will probably be 
a bit tighter.  If you really want a stopped instance to not actually start up 
on a rebuild/evacuate then that would be additional work.

Chris

__
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

__
Disclaimer: This email and any attachments are sent in strictest confidence
for the sole use of the addressee and may contain legally privileged,
confidential, and proprietary data. If you are not the intended recipient,
please advise the sender by replying promptly to this email and then delete
and destroy this email and any attachments without any further use, copying
or forwarding.
__
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] [masakari][nova] Allow evacuation of instances in resized state

[Kekane, Abhishek]

Hi Devs,

Masakari [1] provides Virtual Machine High Availability (VMHA) service for 
OpenStack clouds by automatically recovering the KVM-based Virtual Machine(VM)s 
from failure events such as VM process down, provisioning process down, and 
nova-compute host failure. It also provides API service to manage and control 
the automated rescue mechanism.

Masakari use cases:
---
1. Allow evacuation of an instance which is in resized state.
2. If instance was in stopped state before resizing then after evacuation it 
should remain in stopped state instead of active state.

Problem from Nova:
--
Nova does not allow evacuation of an instance which is in resized state.

Implementation in masakari:
---
In masakari, we are setting an instance to an error state if the vmstate is 
resized before evacuating it to a new host. Once an instance (which was in 
resized state) is evacuated then it becomes active on the new host. The main 
problem with this implementation from user's point of view is the instance goes 
into active state after evacuation, it should be in stopped state if the prior 
action on the instance before resizing was stop. In masakari, It's possible to 
set the vm state to stopped state after evacuation but for a short period the 
instance will go into the active state which is unacceptable.

Proposing changes to Nova:
In the current nova code, if the instance is in stopped state before 
evacuation, then it remains in the stopped state after evacuation is complete. 
On the similar lines, we are proposing nova should allow instance to be 
evacuated in resized state and after evacuation the instance should remain in 
stopped state if the prior action on the instance is stopped before resizing.  
If the vmstate is resized, the old vmstate in instance_systemmetadata will be 
either active/stop. Based on this old vmstate, nova compute can decide whether 
to set the vm state to active or stopped during evacuation.

Please let me know your opinion about allowing evacuation of instances in 
resized state in nova.

[1] https://github.com/openstack/masakari

Thank you,

Abhishek Kekane


__
Disclaimer: This email and any attachments are sent in strictest confidence
for the sole use of the addressee and may contain legally privileged,
confidential, and proprietary data. If you are not the intended recipient,
please advise the sender by replying promptly to this email and then delete
and destroy this email and any attachments without any further use, copying
or forwarding.__
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] [glance] nominating Abhishek Kekane for glance core

[Kekane, Abhishek]

Thank you all for your positive responses.

I will definitely put 100% efforts to justify my selection as core.

Best Regards,

Abhishek Kekane
 


-Original Message-
From: Brian Rosmaita [mailto:rosmaita.foss...@gmail.com] 
Sent: Wednesday, June 21, 2017 4:47 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [glance] nominating Abhishek Kekane for glance core

Having heard only affirmative responses, I've added Abhishek Kekane to the 
Glance core group, with all the rights and privileges pertaining thereto.

Welcome to the Glance core team, Abhishek!

cheers,
brian

On Tue, Jun 20, 2017 at 1:35 PM, Mikhail Fedosin  wrote:
> Wasn't Abhishek a glance core before? What a surprise for me o_O I 
> thought that he was just being modest and did not put -2 on the patches.
>
> Undoubtedly, we need to correct this misunderstanding as quickly as 
> possible and invite Abhishek to the core team.
>
> On Mon, Jun 19, 2017 at 5:40 PM, Erno Kuvaja  wrote:
>>
>> On Fri, Jun 16, 2017 at 3:26 PM, Brian Rosmaita 
>>  wrote:
>> > I'm nominating Abhishek Kekane (abhishekk on IRC) to be a Glance 
>> > core for the Pike cycle.  Abhishek has been around the Glance 
>> > community for a long time and is familiar with the architecture and 
>> > design patterns used in Glance and its related projects.  He's 
>> > contributed code, triaged bugs, provided bugfixes, and done quality 
>> > reviews for Glance.
>> >
>> > Abhishek has been proposed for Glance core before, but some members 
>> > of the community were concerned that he wasn't able to devote 
>> > sufficient time to Glance.  Given the current situation with the 
>> > project, however, it would be an enormous help to have someone as 
>> > knowledgeable about Glance as Abhishek to have +2 powers.  I 
>> > discussed this with Abhishek, he's aware that some in the community 
>> > have that concern, and he's agreed to be a core reviewer for the 
>> > Pike cycle.  The community can revisit his status early in Queens.
>> >
>> > Now that I've written that down, that puts Abhishek in the same 
>> > boat as all core reviewers, i.e., their levels of participation and 
>> > commitment are assessed at the beginning of each cycle and 
>> > adjustments made.
>> >
>> > In any case, I'd like to put Abhishek to work as soon as possible!  
>> > So please reply to this message with comments or concerns before 
>> > 23:59 UTC on Monday 19 June.  I'd like to confirm Abhishek as a 
>> > core on Tuesday 20 June.
>> >
>> > thanks,
>> > brian
>> >
>>
>> +2 from me! This sounds like a great solution for our immediate
>> staffing issues and I'm happy to hear Abhishek would have the cycles 
>> to help us. Lets hope we get to enjoy his knowledge and good quality 
>> reviews on many cycles forward.
>>
>> - Erno
>>
>> >
>> > ___
>> > ___ 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 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

__
Disclaimer: This email and any attachments are sent in strictest confidence
for the sole use of the addressee and may contain legally privileged,
confidential, and proprietary data. If you are not the intended recipient,
please advise the sender by replying promptly to this email and then delete
and destroy this email and any attachments without any further use, copying
or forwarding.
__
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] [glance] nominating Mike Fedosin for glance core

[Kekane, Abhishek]

+1, agree with Nikhil.

Abhishek

From: Nikhil Komawar [mailto:nik.koma...@gmail.com]
Sent: Friday, May 26, 2017 6:04 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [glance] nominating Mike Fedosin for glance core

This is great news. Always +2 for Mike, he's been great (dev, glancer, stacker 
..) all the years.  Let's not wait so long for reinstatement if folks are 
on-board, as having another core will only help.

On Thu, May 25, 2017 at 11:53 AM, Brian Rosmaita 
> wrote:
As you've no doubt read elsewhere on the ML, we've lost several glance
cores recently due to employment changes.  Luckily, Mike Fedosin
informed me at today's Glance weekly meeting that he will have time
for the next few months to devote some time to Glance reviewing.

For those who don't know Mike (mfedosin on IRC), he was a Glance core
for several years.  He provided a lot of notes that were used to write
the Glance architecture documentation that is so helpful to new
contributors, so he's extremely knowledgeable about the design
patterns used in Glance.

Most recently, Mike's been working on the Glare project, which has a
lot in common with Glance.  While Mike says he can't commit much time
to Glance development, he has proposed porting some of the Glare tests
over to Glance, which will certainly help with our code coverage, and
would be a helpful addition to Glance.

(Mike agreed at today's Glance meeting not to propose re-integrating
Glare into the Glance project until the Queens PTG (if at all), so I'm
not worried about that being a distraction during the Pike cycle when
we are so short-handed.)

I'd like to reinstate Mike as a Glance core contributor at the next
Glance weekly meeting.  Please reply to this message with any comments
or concerns before 23:59 UTC on Wednesday 31 May 2017.

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



--
--
Thanks,
Nikhil

__
Disclaimer: This email and any attachments are sent in strictest confidence
for the sole use of the addressee and may contain legally privileged,
confidential, and proprietary data. If you are not the intended recipient,
please advise the sender by replying promptly to this email and then delete
and destroy this email and any attachments without any further use, copying
or forwarding.
__
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] [glance][openstack-ansible] Moving on

[Kekane, Abhishek]

Thank you, Steve for your help.
Hope to see you back. .

All the best ☺

Abhishek


From: Steve Lewis [mailto:steve...@gmail.com]
Sent: Friday, May 19, 2017 9:26 AM
To: OpenStack
Subject: [openstack-dev] [glance][openstack-ansible] Moving on

It is clear to me now that I won't be able to work on OpenStack as a part of my 
next day job, wherever that ends up being. As such, I’ll no longer be able to 
invest the time and energy required to maintain my involvement in the 
community. It's time to resign my role as a core reviewer, effective 
immediately.
Thanks for all the fish.
--
SteveL

__
Disclaimer: This email and any attachments are sent in strictest confidence
for the sole use of the addressee and may contain legally privileged,
confidential, and proprietary data. If you are not the intended recipient,
please advise the sender by replying promptly to this email and then delete
and destroy this email and any attachments without any further use, copying
or forwarding.
__
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][oslo.utils] Bug-1680130 Check validation of UUID length

[Kekane, Abhishek]

Hi All,

As per suggested by Doug, this is what we will implement.

Add new method (format_canonical_uuid()) in oslo_utils.uuidutils module which 
will return valid uuid and then all other projects which are using 
is_uuid_like() method needs to call this method to get valid uuid. This 
approach sounds reasonable to me. 

Please let me know your opinion about this approach.

Thank you,

Abhishek Kekane

-Original Message-
From: Doug Hellmann [mailto:d...@doughellmann.com] 
Sent: Wednesday, April 26, 2017 9:01 PM
To: openstack-dev
Subject: Re: [openstack-dev] [nova][oslo.utils] Bug-1680130 Check validation of 
UUID length

Excerpts from Sean Dague's message of 2017-04-26 10:55:14 -0400:
> On 04/26/2017 10:47 AM, Doug Hellmann wrote:
> > Excerpts from Sean Dague's message of 2017-04-26 09:01:32 -0400:
> >> On 04/26/2017 08:36 AM, Doug Hellmann wrote:
> >>> Excerpts from Kekane, Abhishek's message of 2017-04-26 07:00:22 +:
>  Hi All,
> 
>  As per suggested by @jay_pipes's
>  if val.count('-') not in (0, 4):
>  raise TypeError
> 
>  It is not sufficient solution because "is_uuid_like" returns only True 
>  or False.
>  For example,
> 
>  If user passes uuid like "urn:----" or 
>  "urn:uuid:----" then "is_uuid_like" 
>  method returns True as it is valid uuid format, but when this uuid tries 
>  to insert into database table then it gives DBDataError because the 
>  reason is in database "block_device_mapping" table has "volume_id" field 
>  of 36 characters only so while inserting data to the table through 
>  'BlockDeviceMapping' object it raises DBDataError.
> 
>  Doug's solution of adding another method format_canonical_uuid() which 
>  would format it with the proper number of hyphens and return actual UUID 
>  will break backward compatibility IMO. Because of adding this new method 
>  in oslo_utils then we have to make changes in all projects which are 
>  using this is_uuid_like().
> >>>
> >>> I don't understand why adding a new function breaks backwards 
> >>> compatibility. Can you elaborate on why you think so?
> >>
> >> I'm not sure why it's believed it would break compatibility, 
> >> however
> >> format_canonical_uuid() isn't what Nova needs here.
> >>
> >> Nova actually wants to stop bad UUIDs ever getting past our API 
> >> layer, and just spin back to the user that they handed us corrupt 
> >> data. Because it will matter later if they try to use things in 
> >> comparisons. Papering over bad format isn't what we want or intended.
> >>
> >> I think we will end up needing a "is_uuid" which accepts the 
> >> standard dashed format only.
> >>
> >> -Sean
> >>
> > 
> > Sure, that's definitely another option, and again a new function 
> > would be the way to do it and maintain backwards compatibility.
> > 
> > It sounds like there's a chance there's already bad data in the 
> > database, though? For example a UUID presented without the dashes 
> > would have passed the existing check and been able to be stored in 
> > the field because it's shorter than the max length. What happens to 
> > those records?
> 
> That is a good question, and one where we have to figure out what the 
> cost of updating that data would be. I do wonder in what operations 
> that round trips and becomes a good value later.
> 
> But, at a minimum, we want to prevent new bad data from landing.
> 
> -Sean
> 

Maybe preventing writes with bad data, but allowing queries with the existing 
looser constraint, solves the problem? Presumably users querying against this 
field already have to enter the UUID in exactly the same way it was recorded, 
since it's not being converted to a canonical form? Or maybe this is not a 
field used in queries?

Either way, I agree the bad data should be blocked with more strict checks on 
input.

Doug

__
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

__
Disclaimer: This email and any attachments are sent in strictest confidence
for the sole use of the addressee and may contain legally privileged,
confidential, and proprietary data. If you are not the intended recipient,
please advise the sender by replying promptly to this email and then delete
and destroy this email and any attachments without any further use, copying
or forwarding.
__
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][oslo.utils] Bug-1680130 Check validation of UUID length

[Kekane, Abhishek]

Hi All,

As per suggested by @jay_pipes's
if val.count('-') not in (0, 4):
raise TypeError

It is not sufficient solution because "is_uuid_like" returns only True or False.
For example,

If user passes uuid like "urn:----" or 
"urn:uuid:----" then "is_uuid_like" method 
returns True as it is valid uuid format, but when this uuid tries to insert 
into database table then it gives DBDataError because the reason is in database 
"block_device_mapping" table has "volume_id" field of 36 characters only so 
while inserting data to the table through 'BlockDeviceMapping' object it raises 
DBDataError.

Doug's solution of adding another method format_canonical_uuid() which would 
format it with the proper number of hyphens and return actual UUID will break 
backward compatibility IMO. Because of adding this new method in oslo_utils 
then we have to make changes in all projects which are using this 
is_uuid_like().

Please let me know if you have any suggestions on the same, IMO restricting 
this uuid size at schema level is one solution but not all projects supports 
schema validation.

Thank you,

Abhishek


From: Lance Bragstad [mailto:lbrags...@gmail.com]
Sent: Monday, April 24, 2017 11:50 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [nova][oslo.utils] Bug-1680130 Check validation of 
UUID length

We had to do similar things in keystone in order to validate uuid-ish types 
(just not as fancy) [0] [1]. If we didn't have to worry about being backwards 
compatible with non-uuid formats, it would be awesome to have one 
implementation for checking that.

[0] 
https://github.com/openstack/keystone/blob/6c6589d2b0f308cb788b37b29ebde515304ee41e/keystone/identity/schema.py#L69
[1] 
https://github.com/openstack/keystone/blob/6c6589d2b0f308cb788b37b29ebde515304ee41e/keystone/common/validation/parameter_types.py#L38-L45

On Mon, Apr 24, 2017 at 1:05 PM, Matt Riedemann 
> wrote:
On 4/24/2017 12:58 PM, Sean Dague wrote:

Which uses is_uuid_like to do the validation -
https://github.com/openstack/nova/blob/1106477b78c80743e6443abc30911b24a9ab7b15/nova/api/validation/validators.py#L85-L87

We assumed (as did many others) that is_uuid_like was strict enough for
param validation. It is apparently not.

Either it needs to be fixed to be so, or some other function needs to be
created that is, that people can cut over to.

-Sean

Well kiss my grits. I had always assumed that was built into jsonschema.

--

Thanks,

Matt


__
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


__
Disclaimer: This email and any attachments are sent in strictest confidence
for the sole use of the addressee and may contain legally privileged,
confidential, and proprietary data. If you are not the intended recipient,
please advise the sender by replying promptly to this email and then delete
and destroy this email and any attachments without any further use, copying
or forwarding.
__
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] [glance] Propose Dharini Chandrasekar for Glance core

[Kekane, Abhishek]

Sorry for wrong auto-correction :)

Congratulations Dharini, All the best. .

Abhishek
From: Kekane, Abhishek [mailto:abhishek.kek...@nttdata.com]
Sent: Sunday, January 29, 2017 8:39 PM
To: OpenStack Development Mailing List
Subject: Re: [openstack-dev] [glance] Propose Dharini Chandrasekar for Glance 
core

Congratulations Sharing. .
All the best.

Abhishek

Sent from OWA on Android

From: Brian Rosmaita 
<rosmaita.foss...@gmail.com<mailto:rosmaita.foss...@gmail.com>>
Sent: Thursday, January 26, 2017 8:56:30 PM
To: OpenStack Development Mailing List
Subject: Re: [openstack-dev] [glance] Propose Dharini Chandrasekar for Glance 
core

Having heard only affirmative responses, I've added Dharini Chandrasekar
to the Glance core group, with all the rights and privileges pertaining
thereto.

Welcome to the Glance core team, Dharini!

On 1/24/17 8:36 AM, Brian Rosmaita wrote:
> I'd like to propose Dharini Chandrasekar (dharinic on IRC) for Glance
> core.  She has been an active reviewer and contributor to the Glance
> project during the Newton and Ocata cycles, has contributed to other
> OpenStack projects, and has represented Glance in some interactions with
> other project teams.  Additionally, she recently jumped in and saw
> through to completion a high priority feature for Newton when the
> original developer was unable to continue working on it.  Plus, she's
> willing to argue with me (and the other cores) about points of software
> engineering.  She will be a great addition to the Glance core reviewers
> team.
>
> If you have any concerns, please let me know.  I plan to add Dharini to
> the core list after this week's Glance meeting.
>
> thanks,
> brian
>


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

__
Disclaimer: This email and any attachments are sent in strictest confidence
for the sole use of the addressee and may contain legally privileged,
confidential, and proprietary data. If you are not the intended recipient,
please advise the sender by replying promptly to this email and then delete
and destroy this email and any attachments without any further use, copying
or forwarding.

__
Disclaimer: This email and any attachments are sent in strictest confidence
for the sole use of the addressee and may contain legally privileged,
confidential, and proprietary data. If you are not the intended recipient,
please advise the sender by replying promptly to this email and then delete
and destroy this email and any attachments without any further use, copying
or forwarding.__
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] [glance] Propose Dharini Chandrasekar for Glance core

[Kekane, Abhishek]

Congratulations Sharing. .
All the best.

Abhishek

Sent from OWA on Android

From: Brian Rosmaita 
Sent: Thursday, January 26, 2017 8:56:30 PM
To: OpenStack Development Mailing List
Subject: Re: [openstack-dev] [glance] Propose Dharini Chandrasekar for Glance 
core

Having heard only affirmative responses, I've added Dharini Chandrasekar
to the Glance core group, with all the rights and privileges pertaining
thereto.

Welcome to the Glance core team, Dharini!

On 1/24/17 8:36 AM, Brian Rosmaita wrote:
> I'd like to propose Dharini Chandrasekar (dharinic on IRC) for Glance
> core.  She has been an active reviewer and contributor to the Glance
> project during the Newton and Ocata cycles, has contributed to other
> OpenStack projects, and has represented Glance in some interactions with
> other project teams.  Additionally, she recently jumped in and saw
> through to completion a high priority feature for Newton when the
> original developer was unable to continue working on it.  Plus, she's
> willing to argue with me (and the other cores) about points of software
> engineering.  She will be a great addition to the Glance core reviewers
> team.
>
> If you have any concerns, please let me know.  I plan to add Dharini to
> the core list after this week's Glance meeting.
>
> thanks,
> 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

__
Disclaimer: This email and any attachments are sent in strictest confidence
for the sole use of the addressee and may contain legally privileged,
confidential, and proprietary data. If you are not the intended recipient,
please advise the sender by replying promptly to this email and then delete
and destroy this email and any attachments without any further use, copying
or forwarding.__
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] Sabari Murugesan stepping down from Glance core

[Kekane, Abhishek]

Nice work Sabari, Thank you for your efforts and help you provided. Hope to see 
you back in the list.

All the best,

Abhishek

-Original Message-
From: Brian Rosmaita [mailto:rosmaita.foss...@gmail.com] 
Sent: Tuesday, January 24, 2017 4:32 AM
Cc: Sabari Murugesan; OpenStack Development Mailing List
Subject: [openstack-dev] Sabari Murugesan stepping down from Glance core

Sabari Murugesan has communicated to me that he's no longer able to commit time 
to working on Glance, and he's stepping down from the core reviewers' team.

This message isn't all bad news, however: I'm particularly grateful that Sabari 
has agreed to continue as the VMware driver maintainer for the glance_store [0].

Please join me in thanking Sabari for all his past service to Glance.
As anyone who's worked with him knows, he's a great colleague, and I'm really 
sorry to see him step down.  I hope that he may find time in the future to work 
on Glance again.

thanks,
brian

[0] http://docs.openstack.org/developer/glance_store/drivers/index.html


__
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

__
Disclaimer: This email and any attachments are sent in strictest confidence
for the sole use of the addressee and may contain legally privileged,
confidential, and proprietary data. If you are not the intended recipient,
please advise the sender by replying promptly to this email and then delete
and destroy this email and any attachments without any further use, copying
or forwarding.

__
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] [ python-novaclient][ python-glanceclient][ python-cinderclient][ python-neutronclient] Remove x-openstack-request-id logging code as it is logged twice

[Kekane, Abhishek]

Hi Dims,

Thank you for the update.

As of now patches for updating requirements.txt in individual clients has been 
proposed by bot, out of which patch for python-novaclient is already merged.
Following patches are still in review queue:

Python-glanceclient: https://review.openstack.org/#/c/423678
Python-cinderclient: https://review.openstack.org/#/c/423674
Python-neutronclient: https://review.openstack.org/#/c/422968

I have submitted patches in python-glanceclient [1], python-cinderclient [2] 
and python-neutronclient [3] to address this issue with dependency on above 
patches.

As client library release is targeted in this week, we need to make sure these 
patches get through and are part of the release otherwise we can hit the issue 
of logging request-id mapping twice in the logs if SessionClient is used.

[1] https://review.openstack.org/422591
[2] https://review.openstack.org/#/c/423940 (one +2)
[3] https://review.openstack.org/#/c/423921


Thank you,

Abhishek Kekane


-Original Message-
From: Davanum Srinivas [mailto:dava...@gmail.com] 
Sent: Saturday, January 21, 2017 6:05 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [ python-novaclient][ python-glanceclient][ 
python-cinderclient][ python-neutronclient] Remove x-openstack-request-id 
logging code as it is logged twice

"keystoneauth1 >= 2.17.0" implies python-novaclient with your fix will work for 
any version including 2.17.0 which is not true. you need to either do 
"keystoneauth1 >= 2.18.0" or "keystoneauth1 > 2.17.0" and we prefer the ">=" 
notation i think.

Thanks,
Dims

On Fri, Jan 20, 2017 at 10:53 PM, Kekane, Abhishek 
<abhishek.kek...@nttdata.com> wrote:
> Hi Dims,
>
> Thank you for reply. I will propose a patch soon. Just for curiosity,
> keystoneauth1 >= 2.17.0 will not install 2.18.0?
>
> Abhishek
> 
> From: Davanum Srinivas <dava...@gmail.com>
> Sent: Saturday, January 21, 2017 8:27:56 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [ python-novaclient][ 
> python-glanceclient][ python-cinderclient][ python-neutronclient] 
> Remove x-openstack-request-id logging code as it is logged twice
>
> Abhishek,
>
> 1) requirements.txt for all 4 python-*client you mentioned have 
> "keystoneauth1>=2.17.0",
> 2) i do not see a review request to bump the minimum version in global 
> requirements for keystoneauth1 to "keystoneauth1>=2.18.0"
> (https://review.openstack.org/#/q/project:openstack/requirements+is:op
> en)
>
> Can you please file one?
>
> Thanks,
> Dims
>
>
> On Fri, Jan 20, 2017 at 12:52 AM, Kekane, Abhishek 
> <abhishek.kek...@nttdata.com> wrote:
>> Hi Devs,
>>
>>
>>
>> In the latest keystoneauth1 version 2.18.0, x-openstack-request-id is 
>> logged for every HTTP response. This keystoneauth1 version will be 
>> used for ocata.
>>
>> The same request id is also logged in 'request' method of 
>> SessionClient class for python-novaclient, python-glanceclient, 
>> python-cinderclient and python-neutronclient. Once requirements.txt 
>> is synced with global-requirements and it uses keystoneauth1 version 
>> 2.18.0 and above, x-openstack-request-id will be logged twice for these 
>> clients.
>>
>>
>>
>> I have submitted patches for python-novaclient [1] and 
>> python-glanceclient [2] and created patches for python-cinderclient 
>> and python-neutronclient but same will not be reviewed unless and 
>> until the requirements.txt is synced with global-requirements and it 
>> uses keystoneauth1 version 2.18.0.
>>
>>
>>
>> As final releases for client libraries are scheduled in the next week 
>> (between Jan 23 - Jan 27) we want to address these issues in the 
>> above mentioned clients.
>>
>>
>>
>> Please let us know your opinion about the same.
>>
>>
>>
>> [1] https://review.openstack.org/422602
>>
>> [2] https://review.openstack.org/422591
>>
>>
>> _
>> _
>> Disclaimer: This email and any attachments are sent in strictest 
>> confidence for the sole use of the addressee and may contain legally 
>> privileged, confidential, and proprietary data. If you are not the 
>> intended recipient, please advise the sender by replying promptly to 
>> this email and then delete and destroy this email and any attachments 
>> without any further use, copying or forwarding.
>>
>> __

Re: [openstack-dev] [ python-novaclient][ python-glanceclient][ python-cinderclient][ python-neutronclient] Remove x-openstack-request-id logging code as it is logged twice

[Kekane, Abhishek]

Hi Steve,

Thank you for the update. I have already submitted patches for 
python-novaclient and python-novaclient for reviews and ready with 
python-cinderclient and python-novaclient patches. I will submit them ASAP when 
requirements.txt is synced with updated version of keystoneauth1.

Thank you,

Abhishek

From: Steve Martinelli <s.martine...@gmail.com>
Sent: Saturday, January 21, 2017 10:07:04 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [ python-novaclient][ python-glanceclient][ 
python-cinderclient][ python-neutronclient] Remove x-openstack-request-id 
logging code as it is logged twice



On Fri, Jan 20, 2017 at 10:53 PM, Kekane, Abhishek 
<abhishek.kek...@nttdata.com<mailto:abhishek.kek...@nttdata.com>> wrote:
Hi Dims,

Thank you for reply. I will propose a patch soon. Just for curiosity, 
keystoneauth1 >= 2.17.0 will not install 2.18.0?

It will, but if we make 2.18.0 the minimum then it will for sure install only 
that level.

> In the latest keystoneauth1 version 2.18.0, x-openstack-request-id is logged
> for every HTTP response. This keystoneauth1 version will be used for ocata.
>
> The same request id is also logged in 'request' method of SessionClient
> class for python-novaclient, python-glanceclient, python-cinderclient and
> python-neutronclient. Once requirements.txt is synced with
> global-requirements and it uses keystoneauth1 version 2.18.0 and above,
> x-openstack-request-id will be logged twice for these clients.

So I approved this change (sorry it took so long to review and merge), but I 
didn't realize it was going to impact python-{nova | glance | cinder | 
neutron}client. I think it's slightly unrealistic to ask four teams to remove 
the logging in the last week we release clients (I'm assuming we want to remove 
the functionality and not log things twice).

 - Would folks prefer I revert the keystoneauth change and re-release without 
it, and we can bring it back in Pike?
- Do teams have the bandwidth to remove the request id logging in the next few 
days?

Sorry for the confusion this caused.

__
Disclaimer: This email and any attachments are sent in strictest confidence
for the sole use of the addressee and may contain legally privileged,
confidential, and proprietary data. If you are not the intended recipient,
please advise the sender by replying promptly to this email and then delete
and destroy this email and any attachments without any further use, copying
or forwarding.__
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] [ python-novaclient][ python-glanceclient][ python-cinderclient][ python-neutronclient] Remove x-openstack-request-id logging code as it is logged twice

[Kekane, Abhishek]

Hi Dims,

Thank you for reply. I will propose a patch soon. Just for curiosity, 
keystoneauth1 >= 2.17.0 will not install 2.18.0?

Abhishek

From: Davanum Srinivas <dava...@gmail.com>
Sent: Saturday, January 21, 2017 8:27:56 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [ python-novaclient][ python-glanceclient][ 
python-cinderclient][ python-neutronclient] Remove x-openstack-request-id 
logging code as it is logged twice

Abhishek,

1) requirements.txt for all 4 python-*client you mentioned have
"keystoneauth1>=2.17.0",
2) i do not see a review request to bump the minimum version in global
requirements for keystoneauth1 to "keystoneauth1>=2.18.0"
(https://review.openstack.org/#/q/project:openstack/requirements+is:open)

Can you please file one?

Thanks,
Dims


On Fri, Jan 20, 2017 at 12:52 AM, Kekane, Abhishek
<abhishek.kek...@nttdata.com> wrote:
> Hi Devs,
>
>
>
> In the latest keystoneauth1 version 2.18.0, x-openstack-request-id is logged
> for every HTTP response. This keystoneauth1 version will be used for ocata.
>
> The same request id is also logged in 'request' method of SessionClient
> class for python-novaclient, python-glanceclient, python-cinderclient and
> python-neutronclient. Once requirements.txt is synced with
> global-requirements and it uses keystoneauth1 version 2.18.0 and above,
> x-openstack-request-id will be logged twice for these clients.
>
>
>
> I have submitted patches for python-novaclient [1] and python-glanceclient
> [2] and created patches for python-cinderclient and python-neutronclient but
> same will not be reviewed unless and until the requirements.txt is synced
> with global-requirements and it uses keystoneauth1 version 2.18.0.
>
>
>
> As final releases for client libraries are scheduled in the next week
> (between Jan 23 - Jan 27) we want to address these issues in the above
> mentioned clients.
>
>
>
> Please let us know your opinion about the same.
>
>
>
> [1] https://review.openstack.org/422602
>
> [2] https://review.openstack.org/422591
>
>
> __
> Disclaimer: This email and any attachments are sent in strictest confidence
> for the sole use of the addressee and may contain legally privileged,
> confidential, and proprietary data. If you are not the intended recipient,
> please advise the sender by replying promptly to this email and then delete
> and destroy this email and any attachments without any further use, copying
> or forwarding.
>
> __
> 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
>



--
Davanum Srinivas :: https://twitter.com/dims

__
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

__
Disclaimer: This email and any attachments are sent in strictest confidence
for the sole use of the addressee and may contain legally privileged,
confidential, and proprietary data. If you are not the intended recipient,
please advise the sender by replying promptly to this email and then delete
and destroy this email and any attachments without any further use, copying
or forwarding.__
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] [ python-novaclient][ python-glanceclient][ python-cinderclient][ python-neutronclient] Remove x-openstack-request-id logging code as it is logged twice

[Kekane, Abhishek]

Hi Devs,

In the latest keystoneauth1 version 2.18.0, x-openstack-request-id is logged 
for every HTTP response. This keystoneauth1 version will be used for ocata.
The same request id is also logged in 'request' method of SessionClient class 
for python-novaclient, python-glanceclient, python-cinderclient and 
python-neutronclient. Once requirements.txt is synced with global-requirements 
and it uses keystoneauth1 version 2.18.0 and above, x-openstack-request-id will 
be logged twice for these clients.

I have submitted patches for python-novaclient [1] and python-glanceclient [2] 
and created patches for python-cinderclient and python-neutronclient but same 
will not be reviewed unless and until the requirements.txt is synced with 
global-requirements and it uses keystoneauth1 version 2.18.0.

As final releases for client libraries are scheduled in the next week (between 
Jan 23 - Jan 27) we want to address these issues in the above mentioned clients.

Please let us know your opinion about the same.

[1] https://review.openstack.org/422602
[2] https://review.openstack.org/422591

__
Disclaimer: This email and any attachments are sent in strictest confidence
for the sole use of the addressee and may contain legally privileged,
confidential, and proprietary data. If you are not the intended recipient,
please advise the sender by replying promptly to this email and then delete
and destroy this email and any attachments without any further use, copying
or forwarding.__
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] Spain Visa for Indian contributors

[Kekane, Abhishek]

Business Visa is a recommended category.

Thank you,

Abhishek

From: Hrishikesh Barua [tal...@gmail.com]
Sent: Friday, September 16, 2016 12:55 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] Spain Visa for Indian contributors

Has anybody applied for a Tourist Visa for this event from India? Or is 
Business Visa the recommended category?

On 16 September 2016 at 11:31, M Ranga Swami Reddy 
<swamire...@gmail.com<mailto:swamire...@gmail.com>> wrote:
That's good...

Thanks
Swami

On Thu, Sep 15, 2016 at 10:59 PM, Kekane, Abhishek 
<abhishek.kek...@nttdata.com<mailto:abhishek.kek...@nttdata.com>> wrote:
Hi All,

I have got invitation letter in spanish.
Those who requires this letter in spanish, send mail to 
eventv...@openstack.org<mailto:eventv...@openstack.org> mentioning the same.

Thanks to OpenStack foundation.

Cheers,

Abhishek

From: Gorka Eguileor Gimeno [gegui...@redhat.com<mailto:gegui...@redhat.com>]
Sent: Thursday, September 15, 2016 9:35 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] Spain Visa for Indian contributors

Hi,

As a native Spanish speaker I offer my help with the translation if needed.
I assume the OpenStack visa team would be the one required to issue the 
translated invitation letter for it to be valid.

Cheers,
Gorka.

On Thu, Sep 15, 2016 at 2:14 PM, M Ranga Swami Reddy 
<swamire...@gmail.com<mailto:swamire...@gmail.com><mailto:swamire...@gmail.com<mailto:swamire...@gmail.com>>>
 wrote:
Page#2:  http://www.vfsglobal.com/spain/india/pdf/Spain-Checklist.pdf
==
For business visas:
□ Invitation letter from the Spanish company in Spanish language or both in 
English and Spanish.Letters issued only in English will not be accepted. This 
will be an obligatory requirement.
===

On Thu, Sep 15, 2016 at 3:35 PM, M Ranga Swami Reddy 
<swamire...@gmail.com<mailto:swamire...@gmail.com><mailto:swamire...@gmail.com<mailto:swamire...@gmail.com>>>
 wrote:
That's good. Please share the appropriate link/url to openstack visa team.

On Thu, Sep 15, 2016 at 1:14 PM, Kekane, Abhishek 
<abhishek.kek...@nttdata.com<mailto:abhishek.kek...@nttdata.com><mailto:abhishek.kek...@nttdata.com<mailto:abhishek.kek...@nttdata.com>>>
 wrote:
Hi,

Yes it’s request from embassy than for Indian citizens invitation letter should 
be in Spanish as well English language.
I have sent mail to openstack visa team.

Thank you,

Abhishek Kekane

From: M Ranga Swami Reddy 
[mailto:swamire...@gmail.com<mailto:swamire...@gmail.com><mailto:swamire...@gmail.com<mailto:swamire...@gmail.com>>]
Sent: Thursday, September 15, 2016 1:06 PM

To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] Spain Visa for Indian contributors

Hi,
Who asked the invitation letter in Spanish? Is it embassy, please share the 
same info openstack visa team.

JYI - for Tokyo - invitation letter was in Japanese only.

Thanks
Swami

On Thu, Sep 15, 2016 at 11:58 AM, Kekane, Abhishek 
<abhishek.kek...@nttdata.com<mailto:abhishek.kek...@nttdata.com><mailto:abhishek.kek...@nttdata.com<mailto:abhishek.kek...@nttdata.com>>>
 wrote:
Hi Janki,

I will keep you posted about this. Mean time sent mail to 
‘eventv...@openstack.org<mailto:eventv...@openstack.org><mailto:eventv...@openstack.org<mailto:eventv...@openstack.org>>’
 to explain your issue and also give reference of this ML.

Thank you,

Abhishek Kekane

From: Janki Chhatbar 
[mailto:jankih...@gmail.com<mailto:jankih...@gmail.com><mailto:jankih...@gmail.com<mailto:jankih...@gmail.com>>]
Sent: Thursday, September 15, 2016 11:51 AM

To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] Spain Visa for Indian contributors

Hi Abhishek
I am Janki. I am applying for visa from India. I haven't applied yet but a 
friend of mine is facing the same issue of needing an invitation letter in 
Spanish.
May be everyone applying from India can request to have the letter in Spanish 
too.
Let me know how you proceed further. It would help me while applying.
Thanks
Janki

On Thu, Sep 15, 2016 at 11:30 AM, Kekane, Abhishek 
<abhishek.kek...@nttdata.com<mailto:abhishek.kek...@nttdata.com><mailto:abhishek.kek...@nttdata.com<mailto:abhishek.kek...@nttdata.com>>>
 wrote:
Hi John,

I have sent mail to 
'eventv...@openstack.org<mailto:eventv...@openstack.org><mailto:eventv...@openstack.org<mailto:eventv...@openstack.org>>',
 waiting for positive reply.

One reply I got from Kendall is,

We only send the letter in English. No one else applying for a visa has had a 
problem getting their visa with just the English letter so the letter you 
received sho

Re: [openstack-dev] Spain Visa for Indian contributors

[Kekane, Abhishek]

Hi All,

I have got invitation letter in spanish.
Those who requires this letter in spanish, send mail to eventv...@openstack.org 
mentioning the same.

Thanks to OpenStack foundation.

Cheers,

Abhishek

From: Gorka Eguileor Gimeno [gegui...@redhat.com]
Sent: Thursday, September 15, 2016 9:35 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] Spain Visa for Indian contributors

Hi,

As a native Spanish speaker I offer my help with the translation if needed.
I assume the OpenStack visa team would be the one required to issue the 
translated invitation letter for it to be valid.

Cheers,
Gorka.

On Thu, Sep 15, 2016 at 2:14 PM, M Ranga Swami Reddy 
<swamire...@gmail.com<mailto:swamire...@gmail.com>> wrote:
Page#2:  http://www.vfsglobal.com/spain/india/pdf/Spain-Checklist.pdf
==
For business visas:
□ Invitation letter from the Spanish company in Spanish language or both in 
English and Spanish.Letters issued only in English will not be accepted. This 
will be an obligatory requirement.
===

On Thu, Sep 15, 2016 at 3:35 PM, M Ranga Swami Reddy 
<swamire...@gmail.com<mailto:swamire...@gmail.com>> wrote:
That's good. Please share the appropriate link/url to openstack visa team.

On Thu, Sep 15, 2016 at 1:14 PM, Kekane, Abhishek 
<abhishek.kek...@nttdata.com<mailto:abhishek.kek...@nttdata.com>> wrote:
Hi,

Yes it’s request from embassy than for Indian citizens invitation letter should 
be in Spanish as well English language.
I have sent mail to openstack visa team.

Thank you,

Abhishek Kekane

From: M Ranga Swami Reddy 
[mailto:swamire...@gmail.com<mailto:swamire...@gmail.com>]
Sent: Thursday, September 15, 2016 1:06 PM

To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] Spain Visa for Indian contributors

Hi,
Who asked the invitation letter in Spanish? Is it embassy, please share the 
same info openstack visa team.

JYI - for Tokyo - invitation letter was in Japanese only.

Thanks
Swami

On Thu, Sep 15, 2016 at 11:58 AM, Kekane, Abhishek 
<abhishek.kek...@nttdata.com<mailto:abhishek.kek...@nttdata.com>> wrote:
Hi Janki,

I will keep you posted about this. Mean time sent mail to 
‘eventv...@openstack.org<mailto:eventv...@openstack.org>’ to explain your issue 
and also give reference of this ML.

Thank you,

Abhishek Kekane

From: Janki Chhatbar [mailto:jankih...@gmail.com<mailto:jankih...@gmail.com>]
Sent: Thursday, September 15, 2016 11:51 AM

To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] Spain Visa for Indian contributors

Hi Abhishek
I am Janki. I am applying for visa from India. I haven't applied yet but a 
friend of mine is facing the same issue of needing an invitation letter in 
Spanish.
May be everyone applying from India can request to have the letter in Spanish 
too.
Let me know how you proceed further. It would help me while applying.
Thanks
Janki

On Thu, Sep 15, 2016 at 11:30 AM, Kekane, Abhishek 
<abhishek.kek...@nttdata.com<mailto:abhishek.kek...@nttdata.com>> wrote:
Hi John,

I have sent mail to 'eventv...@openstack.org<mailto:eventv...@openstack.org>', 
waiting for positive reply.

One reply I got from Kendall is,

We only send the letter in English. No one else applying for a visa has had a 
problem getting their visa with just the English letter so the letter you 
received should be sufficient.

I will show this reply mail at VFS center and hopefully they will take no 
objection about this.

Thank you for your time,

Abhishek Kekane

-Original Message-
From: John Villalovos 
[mailto:openstack@sodarock.com<mailto:openstack@sodarock.com>]
Sent: Thursday, September 15, 2016 11:17 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] Spain Visa for Indian contributors

On that page they seem to list a contact email:

eventv...@openstack.org<mailto:eventv...@openstack.org>

Hopefully they can help with the issue.

John

On Wed, Sep 14, 2016 at 9:24 PM, Kekane, Abhishek 
<abhishek.kek...@nttdata.com<mailto:abhishek.kek...@nttdata.com>> wrote:
> Hi John,
>
> I have read the information given at
> https://www.openstack.org/summit/barcelona-2016/travel/#visa
> and got the invitation letter but it's in English language. Problem is that 
> Visa centers in India are demanding this invitation letter in English as well 
> as Spanish language.
>
> Thank you,
>
> Abhishek Kekane
>
> -Original Message-
> From: John Villalovos 
> [mailto:openstack@sodarock.com<mailto:openstack@sodarock.com>]
> Sent: Thursday, September 15, 2016 9:45 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] Spain Visa for Indian contributors
>
> There is informatio

Re: [openstack-dev] Spain Visa for Indian contributors

[Kekane, Abhishek]

Hi,

Yes it’s request from embassy than for Indian citizens invitation letter should 
be in Spanish as well English language.
I have sent mail to openstack visa team.

Thank you,

Abhishek Kekane

From: M Ranga Swami Reddy [mailto:swamire...@gmail.com]
Sent: Thursday, September 15, 2016 1:06 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] Spain Visa for Indian contributors

Hi,
Who asked the invitation letter in Spanish? Is it embassy, please share the 
same info openstack visa team.

JYI - for Tokyo - invitation letter was in Japanese only.

Thanks
Swami

On Thu, Sep 15, 2016 at 11:58 AM, Kekane, Abhishek 
<abhishek.kek...@nttdata.com<mailto:abhishek.kek...@nttdata.com>> wrote:
Hi Janki,

I will keep you posted about this. Mean time sent mail to 
‘eventv...@openstack.org<mailto:eventv...@openstack.org>’ to explain your issue 
and also give reference of this ML.

Thank you,

Abhishek Kekane

From: Janki Chhatbar [mailto:jankih...@gmail.com<mailto:jankih...@gmail.com>]
Sent: Thursday, September 15, 2016 11:51 AM

To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] Spain Visa for Indian contributors

Hi Abhishek
I am Janki. I am applying for visa from India. I haven't applied yet but a 
friend of mine is facing the same issue of needing an invitation letter in 
Spanish.
May be everyone applying from India can request to have the letter in Spanish 
too.
Let me know how you proceed further. It would help me while applying.
Thanks
Janki

On Thu, Sep 15, 2016 at 11:30 AM, Kekane, Abhishek 
<abhishek.kek...@nttdata.com<mailto:abhishek.kek...@nttdata.com>> wrote:
Hi John,

I have sent mail to 'eventv...@openstack.org<mailto:eventv...@openstack.org>', 
waiting for positive reply.

One reply I got from Kendall is,

We only send the letter in English. No one else applying for a visa has had a 
problem getting their visa with just the English letter so the letter you 
received should be sufficient.

I will show this reply mail at VFS center and hopefully they will take no 
objection about this.

Thank you for your time,

Abhishek Kekane

-Original Message-
From: John Villalovos 
[mailto:openstack@sodarock.com<mailto:openstack@sodarock.com>]
Sent: Thursday, September 15, 2016 11:17 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] Spain Visa for Indian contributors

On that page they seem to list a contact email:

eventv...@openstack.org<mailto:eventv...@openstack.org>

Hopefully they can help with the issue.

John

On Wed, Sep 14, 2016 at 9:24 PM, Kekane, Abhishek 
<abhishek.kek...@nttdata.com<mailto:abhishek.kek...@nttdata.com>> wrote:
> Hi John,
>
> I have read the information given at
> https://www.openstack.org/summit/barcelona-2016/travel/#visa
> and got the invitation letter but it's in English language. Problem is that 
> Visa centers in India are demanding this invitation letter in English as well 
> as Spanish language.
>
> Thank you,
>
> Abhishek Kekane
>
> -Original Message-
> From: John Villalovos 
> [mailto:openstack@sodarock.com<mailto:openstack@sodarock.com>]
> Sent: Thursday, September 15, 2016 9:45 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] Spain Visa for Indian contributors
>
> There is information on the Visa process at:
> https://www.openstack.org/summit/barcelona-2016/travel/#visa
>
> Not sure if you have already read that information.
>
> They talk about the steps needed to get an invitation letter.
>
> Good luck!
>
>
> On Wed, Sep 14, 2016 at 8:51 PM, Kekane, Abhishek 
> <abhishek.kek...@nttdata.com<mailto:abhishek.kek...@nttdata.com>> wrote:
>> Hi Devs, Stackers,
>>
>>
>>
>> While applying visa from Pune (India), I came to know that Invitation
>> letter is required in Spanish language and its mandatory.
>>
>> Has anyone from India has faced similar kind of issue while applying
>> for visa?
>>
>>
>>
>> If not please let me know from which city you have applied for the Visa.
>>
>>
>>
>>
>>
>> Thank you,
>>
>>
>>
>> Abhishek Kekane
>>
>>
>> _
>> _
>> Disclaimer: This email and any attachments are sent in strictest
>> confidence for the sole use of the addressee and may contain legally
>> privileged, confidential, and proprietary data. If you are not the
>> intended recipient, please advise the sender by replying promptly to
>> this email and then delete and destroy this email and any attachments
>> without any further use, copying or for

Re: [openstack-dev] Spain Visa for Indian contributors

[Kekane, Abhishek]

Hi Janki,

I will keep you posted about this. Mean time sent mail to 
‘eventv...@openstack.org’ to explain your issue and also give reference of this 
ML.

Thank you,

Abhishek Kekane

From: Janki Chhatbar [mailto:jankih...@gmail.com]
Sent: Thursday, September 15, 2016 11:51 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] Spain Visa for Indian contributors

Hi Abhishek
I am Janki. I am applying for visa from India. I haven't applied yet but a 
friend of mine is facing the same issue of needing an invitation letter in 
Spanish.
May be everyone applying from India can request to have the letter in Spanish 
too.
Let me know how you proceed further. It would help me while applying.
Thanks
Janki

On Thu, Sep 15, 2016 at 11:30 AM, Kekane, Abhishek 
<abhishek.kek...@nttdata.com<mailto:abhishek.kek...@nttdata.com>> wrote:
Hi John,

I have sent mail to 'eventv...@openstack.org<mailto:eventv...@openstack.org>', 
waiting for positive reply.

One reply I got from Kendall is,

We only send the letter in English. No one else applying for a visa has had a 
problem getting their visa with just the English letter so the letter you 
received should be sufficient.

I will show this reply mail at VFS center and hopefully they will take no 
objection about this.

Thank you for your time,

Abhishek Kekane

-Original Message-
From: John Villalovos 
[mailto:openstack@sodarock.com<mailto:openstack@sodarock.com>]
Sent: Thursday, September 15, 2016 11:17 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] Spain Visa for Indian contributors

On that page they seem to list a contact email:

eventv...@openstack.org<mailto:eventv...@openstack.org>

Hopefully they can help with the issue.

John

On Wed, Sep 14, 2016 at 9:24 PM, Kekane, Abhishek 
<abhishek.kek...@nttdata.com<mailto:abhishek.kek...@nttdata.com>> wrote:
> Hi John,
>
> I have read the information given at
> https://www.openstack.org/summit/barcelona-2016/travel/#visa
> and got the invitation letter but it's in English language. Problem is that 
> Visa centers in India are demanding this invitation letter in English as well 
> as Spanish language.
>
> Thank you,
>
> Abhishek Kekane
>
> -Original Message-
> From: John Villalovos 
> [mailto:openstack@sodarock.com<mailto:openstack@sodarock.com>]
> Sent: Thursday, September 15, 2016 9:45 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] Spain Visa for Indian contributors
>
> There is information on the Visa process at:
> https://www.openstack.org/summit/barcelona-2016/travel/#visa
>
> Not sure if you have already read that information.
>
> They talk about the steps needed to get an invitation letter.
>
> Good luck!
>
>
> On Wed, Sep 14, 2016 at 8:51 PM, Kekane, Abhishek 
> <abhishek.kek...@nttdata.com<mailto:abhishek.kek...@nttdata.com>> wrote:
>> Hi Devs, Stackers,
>>
>>
>>
>> While applying visa from Pune (India), I came to know that Invitation
>> letter is required in Spanish language and its mandatory.
>>
>> Has anyone from India has faced similar kind of issue while applying
>> for visa?
>>
>>
>>
>> If not please let me know from which city you have applied for the Visa.
>>
>>
>>
>>
>>
>> Thank you,
>>
>>
>>
>> Abhishek Kekane
>>
>>
>> _
>> _
>> Disclaimer: This email and any attachments are sent in strictest
>> confidence for the sole use of the addressee and may contain legally
>> privileged, confidential, and proprietary data. If you are not the
>> intended recipient, please advise the sender by replying promptly to
>> this email and then delete and destroy this email and any attachments
>> without any further use, copying or forwarding.
>>
>> _
>> _  OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<http://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://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> _

Re: [openstack-dev] Spain Visa for Indian contributors

[Kekane, Abhishek]

Hi John,

I have sent mail to 'eventv...@openstack.org', waiting for positive reply.

One reply I got from Kendall is,

We only send the letter in English. No one else applying for a visa has had a 
problem getting their visa with just the English letter so the letter you 
received should be sufficient.

I will show this reply mail at VFS center and hopefully they will take no 
objection about this.

Thank you for your time,

Abhishek Kekane

-Original Message-
From: John Villalovos [mailto:openstack@sodarock.com] 
Sent: Thursday, September 15, 2016 11:17 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] Spain Visa for Indian contributors

On that page they seem to list a contact email:

eventv...@openstack.org

Hopefully they can help with the issue.

John

On Wed, Sep 14, 2016 at 9:24 PM, Kekane, Abhishek <abhishek.kek...@nttdata.com> 
wrote:
> Hi John,
>
> I have read the information given at 
> https://www.openstack.org/summit/barcelona-2016/travel/#visa
> and got the invitation letter but it's in English language. Problem is that 
> Visa centers in India are demanding this invitation letter in English as well 
> as Spanish language.
>
> Thank you,
>
> Abhishek Kekane
>
> -Original Message-
> From: John Villalovos [mailto:openstack@sodarock.com]
> Sent: Thursday, September 15, 2016 9:45 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] Spain Visa for Indian contributors
>
> There is information on the Visa process at:
> https://www.openstack.org/summit/barcelona-2016/travel/#visa
>
> Not sure if you have already read that information.
>
> They talk about the steps needed to get an invitation letter.
>
> Good luck!
>
>
> On Wed, Sep 14, 2016 at 8:51 PM, Kekane, Abhishek 
> <abhishek.kek...@nttdata.com> wrote:
>> Hi Devs, Stackers,
>>
>>
>>
>> While applying visa from Pune (India), I came to know that Invitation 
>> letter is required in Spanish language and its mandatory.
>>
>> Has anyone from India has faced similar kind of issue while applying 
>> for visa?
>>
>>
>>
>> If not please let me know from which city you have applied for the Visa.
>>
>>
>>
>>
>>
>> Thank you,
>>
>>
>>
>> Abhishek Kekane
>>
>>
>> _
>> _
>> Disclaimer: This email and any attachments are sent in strictest 
>> confidence for the sole use of the addressee and may contain legally 
>> privileged, confidential, and proprietary data. If you are not the 
>> intended recipient, please advise the sender by replying promptly to 
>> this email and then delete and destroy this email and any attachments 
>> without any further use, copying or forwarding.
>>
>> _
>> _  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
>
> __
> Disclaimer: This email and any attachments are sent in strictest 
> confidence for the sole use of the addressee and may contain legally 
> privileged, confidential, and proprietary data. If you are not the 
> intended recipient, please advise the sender by replying promptly to 
> this email and then delete and destroy this email and any attachments 
> without any further use, copying or forwarding.
>
> __
>  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

__
Disclaimer: This email and any attachments are sent in strictest confidence
for the sole use of the addressee and may con

Re: [openstack-dev] Spain Visa for Indian contributors

[Kekane, Abhishek]

Hi John,

I have read the information given at 
https://www.openstack.org/summit/barcelona-2016/travel/#visa
and got the invitation letter but it's in English language. Problem is that 
Visa centers in India are demanding this invitation letter in English as well 
as Spanish language.

Thank you,

Abhishek Kekane

-Original Message-
From: John Villalovos [mailto:openstack@sodarock.com] 
Sent: Thursday, September 15, 2016 9:45 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] Spain Visa for Indian contributors

There is information on the Visa process at:
https://www.openstack.org/summit/barcelona-2016/travel/#visa

Not sure if you have already read that information.

They talk about the steps needed to get an invitation letter.

Good luck!


On Wed, Sep 14, 2016 at 8:51 PM, Kekane, Abhishek <abhishek.kek...@nttdata.com> 
wrote:
> Hi Devs, Stackers,
>
>
>
> While applying visa from Pune (India), I came to know that Invitation 
> letter is required in Spanish language and its mandatory.
>
> Has anyone from India has faced similar kind of issue while applying  
> for visa?
>
>
>
> If not please let me know from which city you have applied for the Visa.
>
>
>
>
>
> Thank you,
>
>
>
> Abhishek Kekane
>
>
> __
> Disclaimer: This email and any attachments are sent in strictest 
> confidence for the sole use of the addressee and may contain legally 
> privileged, confidential, and proprietary data. If you are not the 
> intended recipient, please advise the sender by replying promptly to 
> this email and then delete and destroy this email and any attachments 
> without any further use, copying or forwarding.
>
> __
>  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

__
Disclaimer: This email and any attachments are sent in strictest confidence
for the sole use of the addressee and may contain legally privileged,
confidential, and proprietary data. If you are not the intended recipient,
please advise the sender by replying promptly to this email and then delete
and destroy this email and any attachments without any further use, copying
or forwarding.

__
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] Spain Visa for Indian contributors

[Kekane, Abhishek]

Hi Devs, Stackers,

While applying visa from Pune (India), I came to know that Invitation letter is 
required in Spanish language and its mandatory.
Has anyone from India has faced similar kind of issue while applying  for visa?

If not please let me know from which city you have applied for the Visa.


Thank you,

Abhishek Kekane

__
Disclaimer: This email and any attachments are sent in strictest confidence
for the sole use of the addressee and may contain legally privileged,
confidential, and proprietary data. If you are not the intended recipient,
please advise the sender by replying promptly to this email and then delete
and destroy this email and any attachments without any further use, copying
or forwarding.__
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] [glance] [elections] Glance PTL non-candidacy

[Kekane, Abhishek]

Hi Nikhil,

Thank you for your support, guidance and hard work as Glance PTL.
I have enjoyed working with you and glad to know that you will be there to help 
:)

Thank you,

Abhishek

-Original Message-
From: Nikhil Komawar [mailto:nik.koma...@gmail.com] 
Sent: Monday, September 12, 2016 11:39 AM
To: OpenStack Development Mailing List
Subject: [openstack-dev] [glance] [elections] Glance PTL non-candidacy

Hi team,


Just wanted to share my decision for not running for PTL for Glance.
It's been great serving the community in this role however, there are some 
personal and family matters that I need to attend to over the next couple of 
months or so.


I think the Glance team has done great and we've quite a bunch of bright 
developers who are helping push the project forward in the appropriate 
direction. With Glare becoming separate project and Ocata being short cycle, I 
anticipate the priorities being rather obvious to those who have stayed in 
touch. I will be available to do the rightful handoff to the incoming PTL (for 
Ocata) and update with Newton happenings once we're done with a few important 
bugs that are being targeted for RC1.


I intend to stick around in Glance and related projects like Searchlight, 
Glare, etc. However, I am planning to take a more hands on role and see a few 
features through in Ocata.  Given more and more glance-cores time sharing with 
other projects, I think we need some throttle in our review system. So, I'd 
like to help any new developers get their reviews up, that in turn will help 
the Glance community.


Last but not the least, I have thoroughly enjoyed working in this role with all 
my fellow stackers, particularly glancers! So, a BIG thank you for having 
worked with me in making Glance better over the last couple of years.


-- 

Cheers,
Nikhil


__
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

__
Disclaimer: This email and any attachments are sent in strictest confidence
for the sole use of the addressee and may contain legally privileged,
confidential, and proprietary data. If you are not the intended recipient,
please advise the sender by replying promptly to this email and then delete
and destroy this email and any attachments without any further use, copying
or forwarding.

__
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] Reconciling flavors and block device mappings

[Kekane, Abhishek]

From: John Griffith [mailto:john.griffi...@gmail.com]
Sent: Friday, August 26, 2016 10:21 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Nova] Reconciling flavors and block device 
mappings



On Fri, Aug 26, 2016 at 10:20 AM, Ed Leafe 
> wrote:
On Aug 25, 2016, at 3:19 PM, Andrew Laski 
> wrote:

> One other thing to note is that while a flavor constrains how much local
> disk is used it does not constrain volume size at all. So a user can
> specify an ephemeral/swap disk <= to what the flavor provides but can
> have an arbitrary sized root disk if it's a remote volume.

> This kind of goes to the heart of the argument against flavors being the sole 
> source of truth for a request. As cloud evolves, we keep packing more and 
> more stuff into a concept that was originally meant to only divide up 
> resources that came bundled together (CPU, RAM, and local disk). This hasn’t 
> been a good solution for years, and the sooner we start accepting that a 
> request can be much more complex than a flavor can adequately express, the 
> better.

> If we have decided that remote volumes are a good thing (I don’t think 
> there’s any argument there), then we should treat that part of the request as 
> being as fundamental as a flavor. We need to make the scheduler smarter so 
> that it doesn’t rely on > flavor as being the only source of truth.
​> +1

We have done extensive testing with patch [1] and ensured that it’s not 
breaking anything. IMO this patch should be the best solution till now and 
there should not be any issues in accepting the same. Please review the patch 
and provide your opinions so that we can take appropriate actions to get this 
resolved.

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

Thank you,

Abhishek Kekane
​


The first step to improving Nova is admitting we have a problem. :)


-- Ed Leafe






__
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


__
Disclaimer: This email and any attachments are sent in strictest confidence
for the sole use of the addressee and may contain legally privileged,
confidential, and proprietary data. If you are not the intended recipient,
please advise the sender by replying promptly to this email and then delete
and destroy this email and any attachments without any further use, copying
or forwarding.
__
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 evaluation of host disk usage by volume-backed instances

[Kekane, Abhishek]

Hi Nova developers,

This is about the patch: https://review.openstack.org/#/c/200870/19

We would like to fix this issue in Newton and back port it to Mitaka.

Reason:
Ubuntu 16.04 LTS supports Mitaka release. If we wait for this fix until Ocata 
release (~April 2017), then Ubuntu team might need some more time to release 
Ocata in 16.04 (~Oct 2017). I think it will be too late to fix such an 
important and critical issue. Now on the other hand, if we fix this issue in 
Newton and back port it to Mitaka, the chances of getting this fix in Ubuntu 
16.04 increases and it would be available to the Ubuntu users anytime between 
Oct and Dec of this year.

We admit that this patch is a hack but considering its severity, it's important 
to get it fixed as early as possible. Moreover, this code has been reviewed by 
many eyes so far and I don't see its breaking current functionality. After this 
issue is fixed in the Ocata release during resource-providers implementation, 
we can delete these changes.

This issue is discussed in Thu Aug 11 14:00:18 2016 UTC Nova meeting [1] and 
community came to conclusion that:

We need to fix this issue in Newton but

1. Not willing to modify instance root_gb that is stored in instances db table.
2. Suggested to fix this issue in RT but that won't solve the scheduler 
DiskFilter issue completely.


We have following approach in mind:

1. Scheduler DiskFilter should ignore root_gb from RequestSpec if instance is 
booted from volume.

IMO boot server doesn't accept both image_id and volume_id to launch a new 
server. That means, if the instance is booted from volume, image_ref will 
always be None in the instances db table. i.e. instance.image_ref should be 
None. So, in the RequestSpec class, we should add an attribute 
"is_volume_backed' and set it to True when image is None. The Diskfilter has 
access to spec_obj, so simply check if is_volume_backed is True, if yes, ignore 
root_gb else count root_gb and take further action. This will solve the 
scheduler DiskFilter issue.

2. Resource tracker should also ignore root_gb while updating compute disk 
metrics.
Again in "_get_usage_dict" method of resource_tracker.py, check if image is 
None, if yes, simply set root_gb to 0. This way each compute node will report 
disk metrics to the scheduler correctly.

So the entire logic is based on image_ref of instance, it should be None if 
instance is booted from volume.

I am working on a POC with this approach and will test all possible scenarios 
(boot, resize, reboot, compute service stop/start, shelved-unshelved etc).

Please let me know your opinion about the same or you have any other solution 
in mind.

[1] 
http://eavesdrop.openstack.org/meetings/nova/2016/nova.2016-08-11-14.00.log.html

Thank you,

Abhishek Kekane

__
Disclaimer: This email and any attachments are sent in strictest confidence
for the sole use of the addressee and may contain legally privileged,
confidential, and proprietary data. If you are not the intended recipient,
please advise the sender by replying promptly to this email and then delete
and destroy this email and any attachments without any further use, copying
or forwarding.__
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] [all][log] Ideas to log request-ids in cross-projects

[Kekane, Abhishek]

-Original Message-
From: Doug Hellmann [mailto:d...@doughellmann.com] 
Sent: Wednesday, March 16, 2016 8:35 PM
To: openstack-operators
Subject: Re: [Openstack-operators] [openstack-dev] [all][log] Ideas to log 
request-ids in cross-projects

Excerpts from Kekane, Abhishek's message of 2016-03-16 05:56:25 +:

> Hi Doug,
> 
> Is there a need to submit a cross-project specs for this or should I create 
> individual blueprints in individual python-client for this.
> Please let me know.
> 
> Thank you,
> 
> Abhishek Kekane

>> You already have a spec for this work. If the details are wrong or 
>> incomplete, it can be updated. Otherwise, you should be able to just submit 
>> the patches necessary to complete the spec already defined.

Hi Doug,

As per suggestion, I have registered a blueprint [1] to target this work. I 
will submit patches against this blueprint.
[1] https://blueprints.launchpad.net/python-cinderclient/+spec/log-request-id

>> Doug

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

__
Disclaimer: This email and any attachments are sent in strictest confidence
for the sole use of the addressee and may contain legally privileged,
confidential, and proprietary data. If you are not the intended recipient,
please advise the sender by replying promptly to this email and then delete
and destroy this email and any attachments without any further use, copying
or forwarding.

__
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] [Glance] Block subtractive schema changes

[Kekane, Abhishek]

-Original Message-
From: Flavio Percoco [mailto:fla...@redhat.com] 
Sent: 24 March 2016 17:21
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Glance] Block subtractive schema changes

On 24/03/16 05:42 +, Kekane, Abhishek wrote:
>Hi Glance Team,
>
> 
>
>I have registered a blueprint [1] for blocking subtractive schema changes.
>
>Cinder and Nova are already supporting blocking of subtractive schema 
>operations. Would like to add similar support here.
>
> 
>
>Please let me know your opinion on the same.
>
> 
>
>[1] 
>https://blueprints.launchpad.net/glance/+spec/block-subtractive-operati
>ons
>


Hey Abhishek,

Thanks for submitting this! Could you please submit a spec here[0]. That way we 
can go through the details and approve accordingly. At first glance, I think it 
makes sense.

Hi Flavio,

I will create a spec and submit it ASAP.

Thank You,

Abhishek Kekane

Flavio

[0] http://git.openstack.org/cgit/openstack/glance-specs/
>
> 
>
>Thank you,
>
> 
>
>Abhishek Kekane
>
>
>__
>Disclaimer: This email and any attachments are sent in strictest 
>confidence for the sole use of the addressee and may contain legally 
>privileged, confidential, and proprietary data. If you are not the 
>intended recipient, please advise the sender by replying promptly to 
>this email and then delete and destroy this email and any attachments 
>without any further use, copying or forwarding.

>___
>___ 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


--
@flaper87
Flavio Percoco

__
Disclaimer: This email and any attachments are sent in strictest confidence
for the sole use of the addressee and may contain legally privileged,
confidential, and proprietary data. If you are not the intended recipient,
please advise the sender by replying promptly to this email and then delete
and destroy this email and any attachments without any further use, copying
or forwarding.
__
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] [Glance] Block subtractive schema changes

[Kekane, Abhishek]

Hi Glance Team,

I have registered a blueprint [1] for blocking subtractive schema changes.
Cinder and Nova are already supporting blocking of subtractive schema 
operations. Would like to add similar support here.

Please let me know your opinion on the same.

[1] https://blueprints.launchpad.net/glance/+spec/block-subtractive-operations


Thank you,

Abhishek Kekane

__
Disclaimer: This email and any attachments are sent in strictest confidence
for the sole use of the addressee and may contain legally privileged,
confidential, and proprietary data. If you are not the intended recipient,
please advise the sender by replying promptly to this email and then delete
and destroy this email and any attachments without any further use, copying
or forwarding.__
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][log] Ideas to log request-ids in cross-projects

[Kekane, Abhishek]

Excerpts from Kekane, Abhishek's message of 2016-03-01 06:17:15 +:

> Hi Devs,

>

> Considering return request-id to caller specs [1] is implemented in

> python-*client, I would like to begin discussion on how these request-ids

> will be logged in cross-projects. In logging work-group meeting (11-Nov-2015)

> [2] there was a discussion about how to log request-id in the log messages.

> In same meeting it wass decided to write oslo.log specs but as of now no 
> specs has been submitted.

>

> I would like to share our approach to log request-ids and seek suggestions

> for the same. We are planning to use request_utils module [3] which was

> earlier part of oslo-incubator but removed as no one was using it.

>

> A typical use case is: Tempest asking Nova to perform some action and Nova

> calling Glance internally, then the linkages might look like this:

>

> RequestID mapping in nova for nova and glance:

> -

>

> INFO nova.utils [req-f0fb885b-18a2-4510-9e85-b9066b410ee4 admin admin] 
> Request ID Link: request.link 'req-f0fb885b-18a2-4510-9e85-b9066b410ee4' -> 
> Target='glance' TargetId=req-a1ac739c-c816-4f82-ad82-9a9b1a603f43



When is that message emitted? After glance returns a value? What logs

the message?



>

> RequestID mapping in tempest for tempest and nova:

> -

>

> INFO tempest.tests [req-a0df655b-18a2-4510-9e85-b9435dh8ye4 admin admin] 
> Request ID Link: request.link 'req-a0df655b-18a2-4510-9e85-b9435dh8ye4' -> 
> Target='nova' TargetId=req-f0fb885b-18a2-4510-9e85-b9066b410ee4

>

> As there is a reference of nova's request-id in tempest and glance's

> request-id in nova, operator can easily trace the cause of failure.

>

> Using request_utils module we can also mention the 'stage' parameter to

> divide the entire api cycle with stages, e.g. create server can be

> staged as start, get-image can be staged as download-image and active instance

> can be staged as end of the operation.



> I think this is conflating the request stages and "linking" in a way

> that isn't going to always apply.

>

> It really seems like what we want it to just log the request id(s)

> returned from each call made using a client. The format you proposed

> includes all of that data, it's just a bit more verbose than I think we

> really need.

>

> Given that we want to log the information regardless of whether

> there was an error, we need to put the logging inside the client

> libraries themselves where we can always log before raising an

> exception. As a bonus, this significantly reduces the number of

> places we need to make code changes to log the request id chain.

> The clients don't know the request id for the current context, but

> that's OK because oslo.context does and apps using oslo.log will

> get that for free (that's the repeated value in your example above).

>

> So, we could, from the client, do something like:

>

>   LOG.info('call to %(my_service_name)s.%(my_endpoint_name)s used request id 
> %(response_request_id)s',

>extras={'my_service_name': 'nova', 'my_endpoint_name':

> 'create_server', 'response_request_id': request_id})

>

> That would produce something like:

>

>   INFO tempest.tests [req-a0df655b-18a2-4510-9e85-b9435dh8ye4 admin admin] 
> call to nova.create_server used request id 
> req-f0fb885b-18a2-4510-9e85-b9066b410ee4

>

> and in the JSON formatter output, you would have separate fields for

> request_id (the current request) and response_request_id (the value just

> returned to the client by the service).

>

> I don't know if we want to use INFO or DEBUG level, so I've used INFO to

> be consistent with your example.

>



Hi Doug,



With your solution only minimal changes are required to log request-ids in 
client libraries.



I have tried to implement your solution in python-cinderclient and found that 
'endpoint_name' (callee function) is not accessible.

We can use inspect module for this purpose but I am not sure whether it is 
advisable or not.

Another thing is as of now oslo.log is not used in any core client so we need 
to make this change first to use oslo.log in individual python-clients.



If we log request method and url instead of endpoint_name in the log then IMO 
it will be more helpful for the operator.



For example something like this:



LOG.debug(_('%(method)s call to %(my_service_name)s for %(my_url)s '

'used request id %(response_request_id)s') %

   {'method': resp.request.method,

'my_service_name': 'cinder',

'my_url': resp.url,

'response_request_id': request_ids})



Which would produce something like:



DEBUG cinderclient.client [req-22f6b4ed-d746-4af6-b183-073df681d14b demo demo] 
GET call to cinder for 
http://172.31.21.78:8776/v2/9ffea7c24c9d440d9690850da90c8bfb/volumes/f5d1aefa-5632-4c42-89ef-c115df659875
 used request id 

Re: [openstack-dev] [glance] Glance Mitaka: Passing the torch

[Kekane, Abhishek]

Thanks for all your leadership, Flavio! Really appreciated all help from you!


Abhishek


-Original Message-
From: Flavio Percoco [mailto:fla...@redhat.com] 
Sent: 09 March 2016 19:45
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [glance] Glance Mitaka: Passing the torch


Greetings,

I'm not going to run for Glance's PTL position for the Newton timeframe.

There are many motivations behind this choice. Some of them I'm willing to 
discuss in private if people are interested but I'll go as far as saying there 
are personal and professional reasons for me to not run again.

As I've always done in my past cycles as PTL, I'd like to take some time to 
summarize what's happened in the past cycle not only for the new PTL to know 
what's coming up but for the community to know how things went.

Before I even start, I'd like to thank everyone in the Glance community. I 
truly believe this was a great cycle for the project and the community has 
gotten stronger. None of this would have been possible without the help of all 
of you and for that, I'm deeply in debt with you all. It does not just take an 
employer to get someone to contribute to a project. Being paid, for those who 
are, to do Open Source is not enough. It takes passion, motivation and a lot of 
patience to analyze a technology, think out of the box and look for ways it can 
be improved either by fixing bugs or by implementing new features. The amount 
of time and dedication this process requires is probably worth way more than 
what we get back from it.

Now, with all that being said, here's Glance Mitaka for all of you:

Completed Features
==

I think I've mentioned this already but I'm proud of it so I'll say it again.
The prioritization and scheduling of Glance Mitaka went so well that we managed 
to release M-3 without any feature freeze exception (FFE) request. This doesn't 
mean all the features were implemented. In fact, at least 4 were pushed back to 
Newton. However, the team communicated, reviewed, sprinted and coded in such a 
way that we were able to re-organize the schedule to avoid wasting time on 
things we new weren't going to make it. This required transparency and hard 
decisions but that's part of the job, right?

* [0] CIM Namespace Metadata
* [1] Support download from and upload to Cinder volumes
* [2] Glance db purge utility
* [3] Deprecate Glance v3 API
* [4] Implement trusts for Glance
* [5] Migrate the HTTP Store to Use Requests
* [6] Glance Image Signing and Verification
* [7] Supporting OVF Single Disk Image Upload
* [8] Prevention of Unauthorized errors during upload/download in Swift driver
* [9] Add filters using an ‘in’ operator

[0] 
http://specs.openstack.org/openstack/glance-specs/specs/mitaka/implemented/cim-namespace-metadata-definitions.html
[1] 
http://specs.openstack.org/openstack/glance-specs/specs/mitaka/implemented/cinder-store-upload-download.html
[2] 
http://specs.openstack.org/openstack/glance-specs/specs/mitaka/implemented/database-purge.html
[3] 
http://specs.openstack.org/openstack/glance-specs/specs/mitaka/implemented/deprecate-v3-api.html
[4] 
http://specs.openstack.org/openstack/glance-specs/specs/mitaka/implemented/glance-trusts.html
[5] 
http://specs.openstack.org/openstack/glance-specs/specs/mitaka/implemented/http-store-on-requests.html
[6] 
http://specs.openstack.org/openstack/glance-specs/specs/mitaka/implemented/image-signing-and-verification-support.html
[7] 
http://specs.openstack.org/openstack/glance-specs/specs/mitaka/implemented/ovf-lite.html
[8] 
http://specs.openstack.org/openstack/glance-specs/specs/mitaka/implemented/prevention-of-401-in-swift-driver.html
[9] 
http://specs.openstack.org/openstack/glance-specs/specs/mitaka/implemented/v2-add-filters-with-in-operator.html

If the above doesn't sound impressive to you, let me fill you in with some 
extra info about Glance's community.

Community
=

Glance's community currently has 12 core members, 3 of which joined during 
Mitaka and 2 of those 3 members joined at the end of the cycle. That means the 
team ran on 9 reviewers for most of the cycle except that out of those 9, 1 
left the team and joined later in the cycle and 3 folks weren't super active 
this cycle. That left the team with 5 constant reviewers throughout the cycle.

Now, the above is *NOT* to say that the success of the cycle is thanks to those
5 constant reviewers. On the contrary, it's to say that we've managed to build 
a community capable of working together with other non-core reviewers. This was 
a key thing for this cycle.

I don't think it's a secret to anyone that, at the beginning of the cycle, the 
community was fragile and somewhat split. There were different opinions on what 
Glance should (or shouldn't) look like, what new features Glance should (or
shouldn't) have and where the project should be headed in the next 6 months.

The team sat down, the team talked and the team agreed on what the project 
should 

Re: [openstack-dev] [all][log] Ideas to log request-ids in cross-projects

[Kekane, Abhishek]

Hi,

Added openstack-operators in cc so that they can share there views as well.

Abhishek


From: Bogdan Dobrelya [bdobre...@mirantis.com]
Sent: Tuesday, March 01, 2016 3:55 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [all][log] Ideas to log request-ids in 
cross-projects

On 01.03.2016 07:17, Kekane, Abhishek wrote:
> Hi Devs,
>
> Considering return request-id to caller specs [1] is implemented in
> python-*client, I would like to begin discussion on how these request-ids
> will be logged in cross-projects. In logging work-group meeting
> (11-Nov-2015)
> [2] there was a discussion about how to log request-id in the log messages.
> In same meeting it wass decided to write oslo.log specs but as of now no
> specs has been submitted.
>
> I would like to share our approach to log request-ids and seek suggestions
> for the same. We are planning to use request_utils module [3] which was
> earlier part of oslo-incubator but removed as no one was using it.
>
> A typical use case is: Tempest asking Nova to perform some action and Nova
> calling Glance internally, then the linkages might look like this:
>
> RequestID mapping in nova for nova and glance:
> -
>
> INFO nova.utils [req-f0fb885b-18a2-4510-9e85-b9066b410ee4 admin admin]
> Request ID Link: request.link 'req-f0fb885b-18a2-4510-9e85-b9066b410ee4'
> -> Target='glance' TargetId=req-a1ac739c-c816-4f82-ad82-9a9b1a603f43
>
> RequestID mapping in tempest for tempest and nova:
> -
>
> INFO tempest.tests [req-a0df655b-18a2-4510-9e85-b9435dh8ye4 admin admin]
> Request ID Link: request.link 'req-a0df655b-18a2-4510-9e85-b9435dh8ye4'
> -> Target='nova' TargetId=req-f0fb885b-18a2-4510-9e85-b9066b410ee4
>
> As there is a reference of nova's request-id in tempest and glance's
> request-id in nova, operator can easily trace the cause of failure.
>
> Using request_utils module we can also mention the 'stage' parameter to
> divide the entire api cycle with stages, e.g. create server can be
> staged as start, get-image can be staged as download-image and active
> instance
> can be staged as end of the operation.
>
> Advantages:
> ---
>
> With stages provided for API, it's easy for the operator to find out the
> failure stage from entire API cycle.
>
> An example with 'stage' is,
> Tempest asking Nova to perform some action and Nova calling Glance
> internally,
> then the linkages might look like this:
>
> INFO tempest.tests [req-a0df655b-18a2-4510-9e85-b9435dh8ye4 admin admin]
> Request ID Link: request.link.start
> 'req-a0df655b-18a2-4510-9e85-b9435dh8ye4'
>
> INFO nova.utils [req-f0fb885b-18a2-4510-9e85-b9066b410ee4 admin admin]
> Request ID Link: request.link.image_download
> 'req-f0fb885b-18a2-4510-9e85-b9066b410ee4' -> Target='glance'
> TargetId=req-a1ac739c-c816-4f82-ad82-9a9b1a603f43
>
> INFO tempest.tests [req-b0df857fb-18a2-4510-9e85-b9435dh8ye4 admin
> admin] Request ID Link: request.link.end
> 'req-b0df857fb-18a2-4510-9e85-b9435dh8ye4'
>
> Concern:
> 
>
> As request_utils module is removed from oslo-incubator and this module is
> also getting deprecated, I have following options to add it back to
> OpenStack.
>
> Option 1: Add request_utils module in oslo.log (as it is related to logging
> request_ids)
> Option 2: Add request_utils module in oslo.utils
> Option 3: Add link_request_ids method in utils.py of individual projects.
> (this will cause code duplication)
>
> Please let me know your thoughts about the same.

I believe the former option should work good as well. By the way, any
plans to track requests down to the root wrappers' shell commands? There
is also interesting R related to the topic directly [0], see "4.
Logging and coordination". Would be nice to reach those people and ask
for code snippets or cooperation as well...

[0] https://kabru.eecs.umich.edu/papers/publications/2013/socc2013_ju.pdf

>
> [1]
> http://specs.openstack.org/openstack/openstack-specs/specs/return-request-id.html
> [2]
> http://eavesdrop.openstack.org/meetings/log_wg/2015/log_wg.2015-11-11-20.02.log.html
> [3]
> http://docs.openstack.org/developer/oslo-incubator/api/openstack.common.request_utils.html
>
> Thank You,
>
> Abhishek Kekane
>
> __
> Disclaimer: This email and any attachments are sent in strictest confidence
> for the sole use of the addressee and may contain legally privileged,
> confidential, and proprietary data. If you are not the intended recipient,
> please advise the sender by replying promptl

[openstack-dev] [all][log] Ideas to log request-ids in cross-projects

[Kekane, Abhishek]

Hi Devs,

Considering return request-id to caller specs [1] is implemented in
python-*client, I would like to begin discussion on how these request-ids
will be logged in cross-projects. In logging work-group meeting (11-Nov-2015)
[2] there was a discussion about how to log request-id in the log messages.
In same meeting it wass decided to write oslo.log specs but as of now no specs 
has been submitted.

I would like to share our approach to log request-ids and seek suggestions
for the same. We are planning to use request_utils module [3] which was
earlier part of oslo-incubator but removed as no one was using it.

A typical use case is: Tempest asking Nova to perform some action and Nova
calling Glance internally, then the linkages might look like this:

RequestID mapping in nova for nova and glance:
-

INFO nova.utils [req-f0fb885b-18a2-4510-9e85-b9066b410ee4 admin admin] Request 
ID Link: request.link 'req-f0fb885b-18a2-4510-9e85-b9066b410ee4' -> 
Target='glance' TargetId=req-a1ac739c-c816-4f82-ad82-9a9b1a603f43

RequestID mapping in tempest for tempest and nova:
-

INFO tempest.tests [req-a0df655b-18a2-4510-9e85-b9435dh8ye4 admin admin] 
Request ID Link: request.link 'req-a0df655b-18a2-4510-9e85-b9435dh8ye4' -> 
Target='nova' TargetId=req-f0fb885b-18a2-4510-9e85-b9066b410ee4

As there is a reference of nova's request-id in tempest and glance's
request-id in nova, operator can easily trace the cause of failure.

Using request_utils module we can also mention the 'stage' parameter to
divide the entire api cycle with stages, e.g. create server can be
staged as start, get-image can be staged as download-image and active instance
can be staged as end of the operation.

Advantages:
---

With stages provided for API, it's easy for the operator to find out the 
failure stage from entire API cycle.

An example with 'stage' is,
Tempest asking Nova to perform some action and Nova calling Glance internally,
then the linkages might look like this:

INFO tempest.tests [req-a0df655b-18a2-4510-9e85-b9435dh8ye4 admin admin] 
Request ID Link: request.link.start 'req-a0df655b-18a2-4510-9e85-b9435dh8ye4'

INFO nova.utils [req-f0fb885b-18a2-4510-9e85-b9066b410ee4 admin admin] Request 
ID Link: request.link.image_download 'req-f0fb885b-18a2-4510-9e85-b9066b410ee4' 
-> Target='glance' TargetId=req-a1ac739c-c816-4f82-ad82-9a9b1a603f43

INFO tempest.tests [req-b0df857fb-18a2-4510-9e85-b9435dh8ye4 admin admin] 
Request ID Link: request.link.end 'req-b0df857fb-18a2-4510-9e85-b9435dh8ye4'

Concern:


As request_utils module is removed from oslo-incubator and this module is
also getting deprecated, I have following options to add it back to OpenStack.

Option 1: Add request_utils module in oslo.log (as it is related to logging
request_ids)
Option 2: Add request_utils module in oslo.utils
Option 3: Add link_request_ids method in utils.py of individual projects.
(this will cause code duplication)

Please let me know your thoughts about the same.

[1] 
http://specs.openstack.org/openstack/openstack-specs/specs/return-request-id.html
[2] 
http://eavesdrop.openstack.org/meetings/log_wg/2015/log_wg.2015-11-11-20.02.log.html
[3] 
http://docs.openstack.org/developer/oslo-incubator/api/openstack.common.request_utils.html

Thank You,

Abhishek Kekane

__
Disclaimer: This email and any attachments are sent in strictest confidence
for the sole use of the addressee and may contain legally privileged,
confidential, and proprietary data. If you are not the intended recipient,
please advise the sender by replying promptly to this email and then delete
and destroy this email and any attachments without any further use, copying
or forwarding.__
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][clients] Enable hacking in python-*clients

[Kekane, Abhishek]

> Hi Abishek,

> In my understanding, hacking check is enabled for most (or all) of
> python-*client.
> For example, flake8 is run for each neutronclient review [1].
> test-requirements installs hacking, so I believe hacking check is enabled.
> openstackclient and novaclient do the same [2] [3].
> Am I missing something?

Hi Akhiro Motoki,

Individual OpenStack projects has separate hacking module (e.g. 
nova/hacking/checks.py) which contains additional rules other than standard 
PEP8 errors/warnings.
In similar mode can we do same in python-*clients?

Abhishek

> [1] 
> http://git.openstack.org/cgit/openstack/python-neutronclient/tree/tox.ini#n26
> [2] 
> http://git.openstack.org/cgit/openstack/python-openstackclient/tree/tox.ini#n15
> [3] http://git.openstack.org/cgit/openstack/python-novaclient/tree/tox.ini#n24

From: Kekane, Abhishek [mailto:abhishek.kek...@nttdata.com]
Sent: 19 January 2016 10:49
To: OpenStack Development Mailing List (openstack-dev@lists.openstack.org)
Subject: [openstack-dev] [all][clients] Enable hacking in python-*clients

Hi Devs,

As of now all OpenStack projects has hacking checks which take cares about 
OpenStack guidelines issues are caught while running PEP8 checks using tox.
There are no such checks in any of the python-*client.

IMO its worth to enable hacking checks in python-*clients as well which will 
caught some guidelines issues in local environment only,

Please let me know your opinion on the same.

Thanks & Regards,

Abhishek Kekane

__
Disclaimer: This email and any attachments are sent in strictest confidence
for the sole use of the addressee and may contain legally privileged,
confidential, and proprietary data. If you are not the intended recipient,
please advise the sender by replying promptly to this email and then delete
and destroy this email and any attachments without any further use, copying
or forwarding.

__
Disclaimer: This email and any attachments are sent in strictest confidence
for the sole use of the addressee and may contain legally privileged,
confidential, and proprietary data. If you are not the intended recipient,
please advise the sender by replying promptly to this email and then delete
and destroy this email and any attachments without any further use, copying
or forwarding.__
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][clients] Enable hacking in python-*clients

[Kekane, Abhishek]

-Original Message-
From: Andreas Jaeger [mailto:a...@suse.com] 
Sent: 19 January 2016 15:19
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [all][clients] Enable hacking in python-*clients

On 2016-01-19 10:44, Abhishek Kekane wrote:
>> Hi Abishek,
>
>> In my understanding, hacking check is enabled for most (or all) of
>
>> python-*client.
>
>> For example, flake8 is run for each neutronclient review [1].
>
>> test-requirements installs hacking, so I believe hacking check is enabled.
>
>> openstackclient and novaclient do the same [2] [3].
>
>> Am I missing something?
>
> Hi Akhiro Motoki,
>
> Individual OpenStack projects has separate hacking module (e.g.
> nova/hacking/checks.py) which contains additional rules other than 
> standard PEP8 errors/warnings.
>
> In similar mode can we do same in python-*clients?

Let's share one common set of rules and not have each repo additional ones. So, 
if those are useful, propose them for the hacking repo.

To answer your questions: Sure, it can be done but why?

Because we can encounter this issues in local environments only, also we can 
add custom checks like
1. use six.string_types instead of basestring 
2. use dict.items or six.iteritems(dict) instead of dict.items
3. checks on assertions etc.

Abhishek

Andreas
--
  Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
   SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton,
HRB 21284 (AG Nürnberg)
 GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126


__
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

__
Disclaimer: This email and any attachments are sent in strictest confidence
for the sole use of the addressee and may contain legally privileged,
confidential, and proprietary data. If you are not the intended recipient,
please advise the sender by replying promptly to this email and then delete
and destroy this email and any attachments without any further use, copying
or forwarding.

__
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] [all][clients] Enable hacking in python-*clients

[Kekane, Abhishek]

Hi Devs,

As of now all OpenStack projects has hacking checks which take cares about 
OpenStack guidelines issues are caught while running PEP8 checks using tox.
There are no such checks in any of the python-*client.

IMO its worth to enable hacking checks in python-*clients as well which will 
caught some guidelines issues in local environment only,

Please let me know your opinion on the same.

Thanks & Regards,

Abhishek Kekane

__
Disclaimer: This email and any attachments are sent in strictest confidence
for the sole use of the addressee and may contain legally privileged,
confidential, and proprietary data. If you are not the intended recipient,
please advise the sender by replying promptly to this email and then delete
and destroy this email and any attachments without any further use, copying
or forwarding.__
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] [all] cross project communication: Return request-id to caller

[Kekane, Abhishek]

Hi Devs,

I have submitted a cross-project specs [1] for returning request-id to the 
caller which was approved. For implementation we have submitted patches in 
python-cinderclient [2] as per design in cross-project specs. However we have 
found one issue while implementing this design in python-glanceclient and 
submitted a lite-spec [3] to address this issue.

As per the comments [4] on lite-specs, glance core are suggesting new approach 
to use hooks and pass empty list to each of the api, so that when the hook is 
executed it will append the request-id to the list.

POC code for approach suggested by glance:
--
# change in python-glanceclient/v2/images.py to delete api

import functools

def append_request_id(req_id_lst, response, *args, **kwargs):
req_id = response.headers.get('x-openstack-request-id')
if req_id:
req_id_lst.append(req_id)

def setup_request_id_hook(req_id_lst):
if req_id_lst is not None:
return dict(response=functools.partial(append_request_id, req_id_lst))

def delete(self, image_id, request_ids=None):
hook = setup_request_id_hook(request_ids)
url = '/v2/images/%s' % image_id
self.http_client.delete(url, hooks=hook)

# modify the do_image_delete function (glanceclient/v2/shell.py) to look as 
follows:

request_ids = []
gc.images.delete(args_id, request_ids=request_ids)
print request_ids

$ glance image-delete 11887d68-7faf-4821-9a42-3ec63451067c
['req-a0892f56-2626-4069-8787-f8bf56e0c1cc']

We have tested this approach and it is working as per expectation, only thing 
is that we need to make changes in every method to add hook and request_id list.
>From third-party tools, user need to pass this request-ids list as mentioned 
>in above poc in order to get the request-id back.

My point here is, should we follow this new approach in all python-clients to 
maintain the consistency across openstack?

Please provide your feedback for the same.

[1] 
http://specs.openstack.org/openstack/openstack-specs/specs/return-request-id.html
[2] https://review.openstack.org/#/c/257170/  (base patch, followed by 
dependent patches)
[3] https://bugs.launchpad.net/glance/+bug/1525259
[4] https://bugs.launchpad.net/glance/+bug/1525259/comments/1 and 
https://bugs.launchpad.net/glance/+bug/1525259/comments/5


Thank you,

Abhishek Kekane

__
Disclaimer: This email and any attachments are sent in strictest confidence
for the sole use of the addressee and may contain legally privileged,
confidential, and proprietary data. If you are not the intended recipient,
please advise the sender by replying promptly to this email and then delete
and destroy this email and any attachments without any further use, copying
or forwarding.__
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] [python-glanceclient] Return request-id to caller

[Kekane, Abhishek]

-Original Message-
From: Kekane, Abhishek [mailto:abhishek.kek...@nttdata.com] 
Sent: 10 December 2015 12:56
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [python-glanceclient] Return request-id to caller



-Original Message-
From: stuart.mcla...@hp.com [mailto:stuart.mcla...@hp.com]
Sent: 09 December 2015 23:54
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [python-glanceclient] Return request-id to caller

> Excerpts from Flavio Percoco's message of 2015-12-09 09:09:10 -0430:
>> On 09/12/15 11:33 +0000, Kekane, Abhishek wrote:
>>> Hi Devs,
>>>
>>>
>>>
>>> We are adding support for returning ?x-openstack-request-id?  to the 
>>> caller as per the design proposed in cross-project specs:
>>>
>>> http://specs.openstack.org/openstack/openstack-specs/specs/
>>> return-request-id.html
>>>
>>>
>>>
>>> Problem Description:
>>>
>>> Cannot add a new property of list type to the warlock.model object.
>>>
>>>
>>>
>>> How is a model object created:
>>>
>>> Let?s take an example of glanceclient.api.v2.images.get() call [1]:
>>>
>>>
>>>
>>> Here after getting the response we call model() method. This model() 
>>> does the job of creating a warlock.model object(essentially a dict) 
>>> based on the schema given as argument (image schema retrieved from 
>>> glance in this case). Inside
>>> model() the raw() method simply return the image schema as JSON 
>>> object. The advantage of this warlock.model object over a simple 
>>> dict is that it validates any changes to object based on the rules 
>>> specified in the reference schema.
>>> The keys of this  model object are available as object properties to 
>>> the caller.
>>>
>>>
>>>
>>> Underlying reason:
>>>
>>> The schema for different sub APIs is returned a bit differently. For 
>>> images, metadef APIs glance.schema.Schema.raw() is used which 
>>> returns a schema containing ?additionalProperties?: {?type?: 
>>> ?string?}. Whereas for members and tasks APIs 
>>> glance.schema.Schema.minimal() is used to return schema object which does 
>>> not contain ?additionalProperties?.
>>>
>>>
>>>
>>> So we can add extra properties of any type to the model object 
>>> returned from members or tasks API but for images and metadef APIs 
>>> we can only add properties which can be of type string. Also for the 
>>> latter case we depend on the glance configuration to allow additional 
>>> properties.
>>>
>>>
>>>
>>> As per our analysis we have come up with two approaches for 
>>> resolving this
>>> issue:
>>>
>>>
>>>
>>> Approach #1:  Inject request_ids property in the warlock model 
>>> object in glance client
>>>
>>> Here we do the following:
>>>
>>> 1. Inject the ?request_ids? as additional property into the model 
>>> object (returned from model())
>>>
>>> 2. Return the model object which now contains request_ids property
>>>
>>>
>>>
>>> Limitations:
>>>
>>> 1. Because the glance schemas for images and metadef only allows 
>>> additional properties of type string, so even though natural type of 
>>> request_ids should be list we have to make it as a comma separated 
>>> ?string? of request ids as a compromise.
>>>
>>> 2. Lot of extra code is needed to wrap objects returned from the 
>>> client API so that the caller can get request ids. For example we 
>>> need to write wrapper classes for dict, list, str, tuple, generator.
>>>
>>> 3. Not a good design as we are adding a property which should 
>>> actually be a base property but added as additional property as a 
>>> compromise.
>>>
>>> 4. There is a dependency on glance whether to allow 
>>> custom/additional properties or not. [2]
>>>
>>>
>>>
>>> Approach #2:  Add ?request_ids? property to all schema definitions 
>>> in glance
>>>
>>>
>>>
>>> Here we add  ?request_ids? property as follows to the various APIs (schema):
>>>
>>>
>>>
>>> ?request_ids?: {
>>>
>>>  "type": "array",
>>>
>>>  "items": {
>>>
>>>"type": &qu

[openstack-dev] [python-glanceclient] Return request-id to caller

[Kekane, Abhishek]

Hi Devs,

We are adding support for returning 'x-openstack-request-id'  to the caller as 
per the design proposed in cross-project specs:
http://specs.openstack.org/openstack/openstack-specs/specs/return-request-id.html

Problem Description:
Cannot add a new property of list type to the warlock.model object.

How is a model object created:
Let's take an example of glanceclient.api.v2.images.get() call [1]:

Here after getting the response we call model() method. This model() does the 
job of creating a warlock.model object(essentially a dict) based on the schema 
given as argument (image schema retrieved from glance in this case). Inside 
model() the raw() method simply return the image schema as JSON object. The 
advantage of this warlock.model object over a simple dict is that it validates 
any changes to object based on the rules specified in the reference schema.  
The keys of this  model object are available as object properties to the caller.

Underlying reason:
The schema for different sub APIs is returned a bit differently. For images, 
metadef APIs glance.schema.Schema.raw() is used which returns a schema 
containing "additionalProperties": {"type": "string"}. Whereas for members and 
tasks APIs glance.schema.Schema.minimal() is used to return schema object which 
does not contain "additionalProperties".

So we can add extra properties of any type to the model object returned from 
members or tasks API but for images and metadef APIs we can only add properties 
which can be of type string. Also for the latter case we depend on the glance 
configuration to allow additional properties.

As per our analysis we have come up with two approaches for resolving this 
issue:

Approach #1:  Inject request_ids property in the warlock model object in glance 
client
Here we do the following:
1. Inject the 'request_ids' as additional property into the model 
object(returned from model())
2. Return the model object which now contains request_ids property

Limitations:
1. Because the glance schemas for images and metadef only allows additional 
properties of type string, so even though natural type of request_ids should be 
list we have to make it as a comma separated 'string' of request ids as a 
compromise.
2. Lot of extra code is needed to wrap objects returned from the client API so 
that the caller can get request ids. For example we need to write wrapper 
classes for dict, list, str, tuple, generator.
3. Not a good design as we are adding a property which should actually be a 
base property but added as additional property as a compromise.
4. There is a dependency on glance whether to allow custom/additional 
properties or not. [2]

Approach #2:  Add 'request_ids' property to all schema definitions in glance

Here we add  'request_ids' property as follows to the various APIs (schema):

"request_ids": {
  "type": "array",
  "items": {
"type": "string"
  }
}

Doing this will make changes in glance client very simple as compared to 
approach#1.
This also looks a better design as it will be consistent.
We simply need to modify the request_ids property in  various API calls for 
example glanceclient.v2.images.get().

Please let us know which approach is better or any suggestions for the same.

[1] 
https://github.com/openstack/python-glanceclient/blob/master/glanceclient/v2/images.py#L179
[2] https://github.com/openstack/glance/blob/master/glance/api/v2/images.py#L944

__
Disclaimer: This email and any attachments are sent in strictest confidence
for the sole use of the addressee and may contain legally privileged,
confidential, and proprietary data. If you are not the intended recipient,
please advise the sender by replying promptly to this email and then delete
and destroy this email and any attachments without any further use, copying
or forwarding.__
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] [python-glanceclient] Return request-id to caller

[Kekane, Abhishek]

-Original Message-
From: Doug Hellmann [mailto:d...@doughellmann.com] 
Sent: 09 December 2015 19:28
To: openstack-dev
Subject: Re: [openstack-dev] [python-glanceclient] Return request-id to caller

Excerpts from Flavio Percoco's message of 2015-12-09 09:09:10 -0430:
> On 09/12/15 11:33 +0000, Kekane, Abhishek wrote:
> >Hi Devs,
> >
> > 
> >
> >We are adding support for returning ‘x-openstack-request-id’  to the 
> >caller as per the design proposed in cross-project specs:
> >
> >http://specs.openstack.org/openstack/openstack-specs/specs/
> >return-request-id.html
> >
> > 
> >
> >Problem Description:
> >
> >Cannot add a new property of list type to the warlock.model object.
> >
> > 
> >
> >How is a model object created:
> >
> >Let’s take an example of glanceclient.api.v2.images.get() call [1]:
> >
> > 
> >
> >Here after getting the response we call model() method. This model() 
> >does the job of creating a warlock.model object(essentially a dict) 
> >based on the schema given as argument (image schema retrieved from 
> >glance in this case). Inside
> >model() the raw() method simply return the image schema as JSON 
> >object. The advantage of this warlock.model object over a simple dict 
> >is that it validates any changes to object based on the rules specified in 
> >the reference schema.
> >The keys of this  model object are available as object properties to 
> >the caller.
> >
> > 
> >
> >Underlying reason:
> >
> >The schema for different sub APIs is returned a bit differently. For 
> >images, metadef APIs glance.schema.Schema.raw() is used which returns 
> >a schema containing “additionalProperties”: {“type”: “string”}. 
> >Whereas for members and tasks APIs glance.schema.Schema.minimal() is 
> >used to return schema object which does not contain “additionalProperties”.
> >
> > 
> >
> >So we can add extra properties of any type to the model object 
> >returned from members or tasks API but for images and metadef APIs we 
> >can only add properties which can be of type string. Also for the 
> >latter case we depend on the glance configuration to allow additional 
> >properties.
> >
> > 
> >
> >As per our analysis we have come up with two approaches for resolving 
> >this
> >issue:
> >
> > 
> >
> >Approach #1:  Inject request_ids property in the warlock model object 
> >in glance client
> >
> >Here we do the following:
> >
> >1. Inject the ‘request_ids’ as additional property into the model 
> >object (returned from model())
> >
> >2. Return the model object which now contains request_ids property
> >
> > 
> >
> >Limitations:
> >
> >1. Because the glance schemas for images and metadef only allows 
> >additional properties of type string, so even though natural type of 
> >request_ids should be list we have to make it as a comma separated 
> >‘string’ of request ids as a compromise.
> >
> >2. Lot of extra code is needed to wrap objects returned from the 
> >client API so that the caller can get request ids. For example we 
> >need to write wrapper classes for dict, list, str, tuple, generator.
> >
> >3. Not a good design as we are adding a property which should 
> >actually be a base property but added as additional property as a compromise.
> >
> >4. There is a dependency on glance whether to allow custom/additional 
> >properties or not. [2]
> >
> > 
> >
> >Approach #2:  Add ‘request_ids’ property to all schema definitions in 
> >glance
> >
> > 
> >
> >Here we add  ‘request_ids’ property as follows to the various APIs (schema):
> >
> > 
> >
> >“request_ids”: {
> >
> >  "type": "array",
> >
> >  "items": {
> >
> >"type": "string"
> >
> >  }
> >
> >}
> >
> > 
> >
> >Doing this will make changes in glance client very simple as compared 
> >to approach#1.
> >
> >This also looks a better design as it will be consistent.
> >
> >We simply need to modify the request_ids property in  various API 
> >calls for example glanceclient.v2.images.get().
> >
> 
> Hey Abhishek,
> 
> thanks for working on this.
> 
> To be honest, I'm a bit confused on why the request_id needs to be an 
> attribute of the image. Isn't it passed as a header? Does it have to 
> be an attribute so we can "print" i

Re: [openstack-dev] [python-glanceclient] Return request-id to caller

[Kekane, Abhishek]

-Original Message-
From: stuart.mcla...@hp.com [mailto:stuart.mcla...@hp.com] 
Sent: 09 December 2015 23:54
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [python-glanceclient] Return request-id to caller

> Excerpts from Flavio Percoco's message of 2015-12-09 09:09:10 -0430:
>> On 09/12/15 11:33 +0000, Kekane, Abhishek wrote:
>>> Hi Devs,
>>>
>>>
>>>
>>> We are adding support for returning ?x-openstack-request-id?  to the caller 
>>> as
>>> per the design proposed in cross-project specs:
>>>
>>> http://specs.openstack.org/openstack/openstack-specs/specs/
>>> return-request-id.html
>>>
>>>
>>>
>>> Problem Description:
>>>
>>> Cannot add a new property of list type to the warlock.model object.
>>>
>>>
>>>
>>> How is a model object created:
>>>
>>> Let?s take an example of glanceclient.api.v2.images.get() call [1]:
>>>
>>>
>>>
>>> Here after getting the response we call model() method. This model() does 
>>> the
>>> job of creating a warlock.model object(essentially a dict) based on the 
>>> schema
>>> given as argument (image schema retrieved from glance in this case). Inside
>>> model() the raw() method simply return the image schema as JSON object. The
>>> advantage of this warlock.model object over a simple dict is that it 
>>> validates
>>> any changes to object based on the rules specified in the reference schema.
>>> The keys of this  model object are available as object properties to the
>>> caller.
>>>
>>>
>>>
>>> Underlying reason:
>>>
>>> The schema for different sub APIs is returned a bit differently. For images,
>>> metadef APIs glance.schema.Schema.raw() is used which returns a schema
>>> containing ?additionalProperties?: {?type?: ?string?}. Whereas for members 
>>> and
>>> tasks APIs glance.schema.Schema.minimal() is used to return schema object 
>>> which
>>> does not contain ?additionalProperties?.
>>>
>>>
>>>
>>> So we can add extra properties of any type to the model object returned from
>>> members or tasks API but for images and metadef APIs we can only add 
>>> properties
>>> which can be of type string. Also for the latter case we depend on the 
>>> glance
>>> configuration to allow additional properties.
>>>
>>>
>>>
>>> As per our analysis we have come up with two approaches for resolving this
>>> issue:
>>>
>>>
>>>
>>> Approach #1:  Inject request_ids property in the warlock model object in 
>>> glance
>>> client
>>>
>>> Here we do the following:
>>>
>>> 1. Inject the ?request_ids? as additional property into the model object
>>> (returned from model())
>>>
>>> 2. Return the model object which now contains request_ids property
>>>
>>>
>>>
>>> Limitations:
>>>
>>> 1. Because the glance schemas for images and metadef only allows additional
>>> properties of type string, so even though natural type of request_ids 
>>> should be
>>> list we have to make it as a comma separated ?string? of request ids as a
>>> compromise.
>>>
>>> 2. Lot of extra code is needed to wrap objects returned from the client API 
>>> so
>>> that the caller can get request ids. For example we need to write wrapper
>>> classes for dict, list, str, tuple, generator.
>>>
>>> 3. Not a good design as we are adding a property which should actually be a
>>> base property but added as additional property as a compromise.
>>>
>>> 4. There is a dependency on glance whether to allow custom/additional
>>> properties or not. [2]
>>>
>>>
>>>
>>> Approach #2:  Add ?request_ids? property to all schema definitions in glance
>>>
>>>
>>>
>>> Here we add  ?request_ids? property as follows to the various APIs (schema):
>>>
>>>
>>>
>>> ?request_ids?: {
>>>
>>>  "type": "array",
>>>
>>>  "items": {
>>>
>>>"type": "string"
>>>
>>>  }
>>>
>>> }
>>>
>>>
>>>
>>> Doing this will make changes in glance client very simple as compared to
>>> approach#1.
>>&g

Re: [openstack-dev] [nova][glance][cinder][neutron]How to make use of x-openstack-request-id

[Kekane, Abhishek]

Hi Tan,



Most of the OpenStack RESTful API returns `X-Openstack-Request-Id` in the API 
response header but this request id is not available to the caller from the 
python client.

When you use --debug option from command from the command prompt using client, 
you can see `X-Openstack-Request-Id` on the console but it is not logged 
anywhere.



Currently a cross-project specs [1] is submitted and approved for returning 
X-Openstack-Request-Id to the caller and the implementation for the same is in 
progress.

Please go through the specs for detail information which will help you to 
understand more about request-ids and current work about the same.



Please feel free to revert back anytime for your doubts.



[1] 
https://github.com/openstack/openstack-specs/blob/master/specs/return-request-id.rst



Thanks,



Abhishek Kekane









Hi guys

I recently play around with 'x-openstack-request-id' header but have a 
dump question about how it works. At beginning, I thought an action across 
different services should use a same request-id but it looks like this is not 
the true.



First I read the spec: 
https://blueprints.launchpad.net/nova/+spec/cross-service-request-id which said 
"This ID and the request ID of the other service will be logged at service 
boundaries". and I see cinder/neutron/glance will attach its context's 
request-id as the value of "x-openstack-request-id" header to its response 
while nova use X-Compute-Request-Id. This is easy to understand. So It looks 
like each service should generate its own request-id and attach to its 
response, that's all.



But then I see glance read 'X-Openstack-Request-ID' to generate the request-id 
while cinder/neutron/nova read 'openstack.request_id' when using with keystone. 
It is try to reuse the request-id from keystone.



This totally confused me. It would be great if you can correct me or point me 
some reference. Thanks a lot



Best Regards,



Tan


__
Disclaimer: This email and any attachments are sent in strictest confidence
for the sole use of the addressee and may contain legally privileged,
confidential, and proprietary data. If you are not the intended recipient,
please advise the sender by replying promptly to this email and then delete
and destroy this email and any attachments without any further use, copying
or forwarding.__
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] [oslo] Graduate cliutils.py into oslo.utils

[Kekane, Abhishek]

-Original Message-
From: Davanum Srinivas [mailto:dava...@gmail.com] 
Sent: 20 November 2015 16:59
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [oslo] Graduate cliutils.py into oslo.utils

Abhishek,

Go for it!

Thank you Dims, I am on it!!

Abhishek

On Fri, Nov 20, 2015 at 2:32 AM, Kekane, Abhishek <abhishek.kek...@nttdata.com> 
wrote:
> -Original Message-
> From: Doug Hellmann [mailto:d...@doughellmann.com]
> Sent: 16 November 2015 21:46
> To: openstack-dev
> Subject: Re: [openstack-dev] [oslo] Graduate cliutils.py into 
> oslo.utils
>
> Excerpts from Kekane, Abhishek's message of 2015-11-16 07:33:48 +:
>> Hi,
>>
>> As apiclient is now removed from oslo-incubator, to proceed with 
>> request-id spec [1] I have two options in mind,
>>
>>
>> 1.   Use keystoneauth1 + cliff in all python-clients (add request-id 
>> support in cliff library)
>
> cliff is being used outside of OpenStack, and is not at all related to REST 
> API access, so I don't think that's the right place.
>
>>
>> 2.   apiclient code is available in all python-*clients, modify this 
>> code in individual clients and add support to return request-id.
>
> Yes, I think that makes sense.
>
> Hi Devs,
>
> As per mentioned by Dough I will start pushing patches for 
> python-cinderclient, python-glanceclient and python-novaclient from next week 
> which includes changes for returning request-id to caller.
> Please let me know if you have any suggestions on the same.
>
>>
>> Please let me know your opinion on the same.
>>
>> [1] https://review.openstack.org/#/c/156508/
>>
>> Thanks & Regards,
>>
>> Abhishek Kekane
>>
>> > On Nov 11, 2015, at 3:54 AM, Andrey Kurilin > > mirantis.com<http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>>
>> >  wrote:
>>
>> >
>>
>> >
>>
>> >
>>
>> > On Tue, Nov 10, 2015 at 4:25 PM, Sean Dague > > dague.net<http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
>> >  <mailto:sean at 
>> > dague.net<http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>>>
>> >  wrote:
>>
>> > On 11/10/2015 08:24 AM, Andrey Kurilin wrote:
>>
>> > >>It was also proposed to reuse openstackclient or the openstack SDK.
>>
>> > >
>>
>> > > Openstack SDK was proposed a long time ago(it looks like it was 
>> > > several
>>
>> > > cycles ago) as "alternative" for cliutils and apiclient, but I 
>> > > don't
>>
>> > > know any client which use it yet. Maybe openstacksdk cores should 
>> > > try to
>>
>> > > port any client as an example of how their project should be used.
>>
>> >
>>
>> > The SDK is targeted for end user applications, not service clients.
>> > I do
>>
>> > get there was lots of confusion over this, but SDK is not the 
>> > answer
>>
>> > here for service clients.
>>
>> >
>>
>> > Ok, thanks for explanation, but there is another question in my head: If 
>> > openstacksdk is not for python-*clients, why apiclient(which is actually 
>> > used by python-*clients) was marked as deprecated due to openstacksdk?
>>
>>
>>
>> The Oslo team wanted to deprecate the API client code because it wasn't 
>> being maintained. We thought at the time we did so that the SDK would 
>> replace the clients, but discussions since that time have changed direction.
>>
>> >
>>
>> > The service clients are *always* going to have to exist in some form.
>>
>> > Either as libraries that services produce, or by services deciding 
>> > they
>>
>> > don't want to consume the libraries of other clients and just put a
>>
>> > targeted bit of rest code in their own tree to talk to other services.
>>
>> >
>>
>> > -Sean
>>
>> >
>>
>> > --
>>
>> > Sean Dague
>>
>> > http://dague.net <http://dague.net/>
>>
>> >
>>
>> > ___
>> > _
>> > __
>>
>> > OpenStack Development Mailing List (not for usage questions)
>>
>> > Unsubscribe: OpenStack-dev-request at 
>> > lists.openstack.org<http://lists.openstack.org/cgi-bin/mailman/list
>> > i nfo/opens

Re: [openstack-dev] [oslo] Graduate cliutils.py into oslo.utils

[Kekane, Abhishek]

-Original Message-
From: Doug Hellmann [mailto:d...@doughellmann.com] 
Sent: 16 November 2015 21:46
To: openstack-dev
Subject: Re: [openstack-dev] [oslo] Graduate cliutils.py into oslo.utils

Excerpts from Kekane, Abhishek's message of 2015-11-16 07:33:48 +:
> Hi,
> 
> As apiclient is now removed from oslo-incubator, to proceed with 
> request-id spec [1] I have two options in mind,
> 
> 
> 1.   Use keystoneauth1 + cliff in all python-clients (add request-id 
> support in cliff library)

cliff is being used outside of OpenStack, and is not at all related to REST API 
access, so I don't think that's the right place.

> 
> 2.   apiclient code is available in all python-*clients, modify this code 
> in individual clients and add support to return request-id.

Yes, I think that makes sense.

Hi Devs,

As per mentioned by Dough I will start pushing patches for python-cinderclient, 
python-glanceclient and python-novaclient from next week which includes changes 
for returning request-id to caller.
Please let me know if you have any suggestions on the same.

> 
> Please let me know your opinion on the same.
> 
> [1] https://review.openstack.org/#/c/156508/
> 
> Thanks & Regards,
> 
> Abhishek Kekane
> 
> > On Nov 11, 2015, at 3:54 AM, Andrey Kurilin  > mirantis.com>
> >  wrote:
> 
> >
> 
> >
> 
> >
> 
> > On Tue, Nov 10, 2015 at 4:25 PM, Sean Dague  > dague.net
> >   > dague.net>>
> >  wrote:
> 
> > On 11/10/2015 08:24 AM, Andrey Kurilin wrote:
> 
> > >>It was also proposed to reuse openstackclient or the openstack SDK.
> 
> > >
> 
> > > Openstack SDK was proposed a long time ago(it looks like it was 
> > > several
> 
> > > cycles ago) as "alternative" for cliutils and apiclient, but I 
> > > don't
> 
> > > know any client which use it yet. Maybe openstacksdk cores should 
> > > try to
> 
> > > port any client as an example of how their project should be used.
> 
> >
> 
> > The SDK is targeted for end user applications, not service clients. 
> > I do
> 
> > get there was lots of confusion over this, but SDK is not the answer
> 
> > here for service clients.
> 
> >
> 
> > Ok, thanks for explanation, but there is another question in my head: If 
> > openstacksdk is not for python-*clients, why apiclient(which is actually 
> > used by python-*clients) was marked as deprecated due to openstacksdk?
> 
> 
> 
> The Oslo team wanted to deprecate the API client code because it wasn't being 
> maintained. We thought at the time we did so that the SDK would replace the 
> clients, but discussions since that time have changed direction.
> 
> >
> 
> > The service clients are *always* going to have to exist in some form.
> 
> > Either as libraries that services produce, or by services deciding 
> > they
> 
> > don't want to consume the libraries of other clients and just put a
> 
> > targeted bit of rest code in their own tree to talk to other services.
> 
> >
> 
> > -Sean
> 
> >
> 
> > --
> 
> > Sean Dague
> 
> > http://dague.net 
> 
> >
> 
> > 
> > __
> 
> > OpenStack Development Mailing List (not for usage questions)
> 
> > Unsubscribe: OpenStack-dev-request at 
> > lists.openstack.org > nfo/openstack-dev>?subject:unsubscribe 
> >  > be>
> 
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
> > 
> 
> >
> 
> >
> 
> >
> 
> > --
> 
> > Best regards,
> 
> > Andrey Kurilin.
> 
> > 
> > __
> 
> > OpenStack Development Mailing List (not for usage questions)
> 
> > Unsubscribe: OpenStack-dev-request at 
> > lists.openstack.org > nfo/openstack-dev>  > lists.openstack.org > nfo/openstack-dev>>?subject:unsubscribe
> 
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
> > 
> 
> -- next part --
> 
> An HTML attachment was scrubbed...
> 
> URL: 
>  11/d457a660/attachment.html>
> 

__
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

Thank You,

Abhishek Kekane

[openstack-dev] [cross-project] Return request-id to caller - Step 1

[Kekane, Abhishek]

Hi Devs,

As per mentioned in cross-project specs [1] 'Proposed Change' section, I would 
like to proceed with adding 'request-id' attribute to base exception class.

request-id is most needed when api returns anything >= 400 error code. As of 
now python-cinderclient, python-keystoneclient and python-novaclient already 
has a mechanism to return request-id in exception.

So we will make similar changes in remaining clients to return request-id in 
exception and log the same in the response.

Please let me know your suggestions on the same.

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


Thanks & Regards,

Abhishek Kekane

__
Disclaimer: This email and any attachments are sent in strictest confidence
for the sole use of the addressee and may contain legally privileged,
confidential, and proprietary data. If you are not the intended recipient,
please advise the sender by replying promptly to this email and then delete
and destroy this email and any attachments without any further use, copying
or forwarding.__
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] [oslo] Graduate cliutils.py into oslo.utils

[Kekane, Abhishek]

Hi,

As apiclient is now removed from oslo-incubator, to proceed with request-id 
spec [1] I have two options in mind,


1.   Use keystoneauth1 + cliff in all python-clients (add request-id 
support in cliff library)

2.   apiclient code is available in all python-*clients, modify this code 
in individual clients and add support to return request-id.

Please let me know your opinion on the same.

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

Thanks & Regards,

Abhishek Kekane






> On Nov 11, 2015, at 3:54 AM, Andrey Kurilin  mirantis.com>
>  wrote:

>

>

>

> On Tue, Nov 10, 2015 at 4:25 PM, Sean Dague  dague.net 
>  dague.net>>
>  wrote:

> On 11/10/2015 08:24 AM, Andrey Kurilin wrote:

> >>It was also proposed to reuse openstackclient or the openstack SDK.

> >

> > Openstack SDK was proposed a long time ago(it looks like it was several

> > cycles ago) as "alternative" for cliutils and apiclient, but I don't

> > know any client which use it yet. Maybe openstacksdk cores should try to

> > port any client as an example of how their project should be used.

>

> The SDK is targeted for end user applications, not service clients. I do

> get there was lots of confusion over this, but SDK is not the answer

> here for service clients.

>

> Ok, thanks for explanation, but there is another question in my head: If 
> openstacksdk is not for python-*clients, why apiclient(which is actually used 
> by python-*clients) was marked as deprecated due to openstacksdk?



The Oslo team wanted to deprecate the API client code because it wasn't being 
maintained. We thought at the time we did so that the SDK would replace the 
clients, but discussions since that time have changed direction.



>

> The service clients are *always* going to have to exist in some form.

> Either as libraries that services produce, or by services deciding they

> don't want to consume the libraries of other clients and just put a

> targeted bit of rest code in their own tree to talk to other services.

>

> -Sean

>

> --

> Sean Dague

> http://dague.net 

>

> __

> OpenStack Development Mailing List (not for usage questions)

> Unsubscribe: OpenStack-dev-request at 
> lists.openstack.org?subject:unsubscribe
>  

> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
> 

>

>

>

> --

> Best regards,

> Andrey Kurilin.

> __

> OpenStack Development Mailing List (not for usage questions)

> Unsubscribe: OpenStack-dev-request at 
> lists.openstack.org
>   lists.openstack.org>?subject:unsubscribe

> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
> 

-- next part --

An HTML attachment was scrubbed...

URL: 



__
Disclaimer: This email and any attachments are sent in strictest confidence
for the sole use of the addressee and may contain legally privileged,
confidential, and proprietary data. If you are not the intended recipient,
please advise the sender by replying promptly to this email and then delete
and destroy this email and any attachments without any further use, copying
or forwarding.__
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] [oslo] Graduate apiclient library

[Kekane, Abhishek]

Hi Devs,

In the Mitaka design summit session [1], it was decided to create a new
library apiclient with completely new code (Metadata classes) and copy
only code from oslo-incubator/openstack/common/apiclient that is needed by
all python clients libraries.

We have done extensive analysis to figure out the differences of usages of
different oslo-incubator/openstack/common/apiclient modules used in the
respective Openstack python client libraries and added all our
observations in the google spreadsheet [2].

Please read the spreadsheet before reading the below information.

All modules from oslo-incubator/openstack/common/apiclient are taken into
consideration.

auth.py
===
Few python client libraries are using auth.py from oslo-incubator for
loading auth plugins and authentication and others have its own code
auth_plugin.py which does the same job in conjunction with keystoneclient
library.

Differences between oslo.incubator/openstack/common/apiclient/auth.py and
python-*client/*client/auth_plugin.py :

a) Methods names are same but implementation is different
(discover_auth_systems, load_auth_system_opts, load_plugin etc)

b) auth_plugin.py module is present in nova and cinder client (nova and
cinder has almost same auth_plugin module)

c) BaseAuthPlugin of auth_plugin.py and auth.py have same methods defined
except
 i. BaseAuthPlugin class of auth.py module do not have 'get_auth_url'
method
 ii. 'authenticate' function takes different arguments

Possible resolutions:-
1) Remove auth_plugin.py from respective python client libraries and add
all required common functionality in auth.py. Add auth.py module into the
new apiclient library.
2) Remove auth.py completely and add auth_plugins.py module in the
respective python client libraries. No need to add auth.py into the new
apiclient library.
3) Check if keystoneauth library has all needed functionality present in
auth.py and auth_plugin.py. If present, don¹t include auth.py in the new
client library and eliminate auth_plugin.py from python client libraries
and instead use keystoneauth wherever needed.

base.py
===
Uses classes ResourceClass and CrudManager and method getid() from
openstack/common/apiclient/base.py in various python client libraries.
There is also getid() method implemented in some of the python client
libraries. getid() method should be deleted from respective python client
libraries and should be used from base.py and this module should be added
to the new apiclient library as it is.


client.py
===

Only few of the python client libraries are using get_class() static
method of class BaseClient from
oslo.incubator/openstack/common/apiclient/client.py module.
This method is implemented in few of the python client libraries. we can
simply ignore client.py and not include in the new apiclient library. We
should add get_class method missing in the required python client
libraries.


exceptions.py
===

Please refer to the exception classes present in the respective python
client libraries in the google spreadsheet ³exception_details².
All common exceptions from respective python client libraries should be
moved to the exception.py module and this module should be part of the new
apiclient library.


fake_client.py
===

Retain this module as it is for unit testing purpose.


utils.py
===

find_resource method from utils.py is used only by manila-client, all
other clients has it¹s own version.

Possible resolutions:
1. Move utils.py to the new apiclient library and delete find_resource
method from all python client libraries and make them use it from the
apiclient library
2. Simply not include utils.py to the new apiclient library and implement
find_resource method in the manila client.
We prefer to implement option #1.


Please have a look at it and let us know your suggestions on the same.
Currently we are having Diwali Vacation in India and once we are back from the 
vacation, based on your inputs I will update the oslo-specs [3] and upload it 
for community review.

[1]: https://mitakadesignsummit.sched.org/event/a98e66b41bf5a8bec8db81dd15f77671
[2]: 
https://docs.google.com/spreadsheets/d/1ZpnEl5QoZz6kv4_ElvqIZULQ4UrVFkxmIuUo_zsyVnE
[3]: https://review.openstack.org/#/c/235200/

Thank you in advance.

Abhishek Kekane

__
Disclaimer: This email and any attachments are sent in strictest confidence
for the sole use of the addressee and may contain legally privileged,
confidential, and proprietary data. If you are not the intended recipient,
please advise the sender by replying promptly to this email and then delete
and destroy this email and any attachments without any further use, copying
or forwarding.__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 

[openstack-dev] [nova] Shared storage space count for Nova

[Kekane, Abhishek]

Hi Devs,

Nova shared storage has issue [1] for counting free space, total space and disk 
available least which affects hypervisor stats and scheduler.
I have created a etherpad [2] which contains detail problem description and 
possible solution with possible challenges for this design.

Later I came to know there is ML [3] initiated by Jay Pipes which has a 
solution of creating resource pools for disk, CPU, memory, Numa modes etc.

IMO this is a good way and good to be addressed in Mitaka release. I am eager 
to work on this and will provide any kind of help in implementation, review etc.

Please give us your opinion about the same.

[1] https://bugs.launchpad.net/nova/+bug/1252321
[2] https://etherpad.openstack.org/p/shared-storage-space-count
[3] http://lists.openstack.org/pipermail/openstack-dev/2015-July/070564.html


Thank you,

Abhishek Kekane

__
Disclaimer: This email and any attachments are sent in strictest confidence
for the sole use of the addressee and may contain legally privileged,
confidential, and proprietary data. If you are not the intended recipient,
please advise the sender by replying promptly to this email and then delete
and destroy this email and any attachments without any further use, copying
or forwarding.__
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] Shared storage space count for Nova

[Kekane, Abhishek]

Hi Jay,

Thank you for the update.

Abhishek Kekane

-Original Message-
From: Jay Pipes [mailto:jaypi...@gmail.com] 
Sent: 30 September 2015 15:48
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [nova] Shared storage space count for Nova

On 09/30/2015 03:04 AM, Kekane, Abhishek wrote:
> Hi Devs,
>
> Nova shared storage has issue [1] for counting free space, total space 
> and disk available least which affects hypervisor stats and scheduler.
>
> I have created a etherpad [2] which contains detail problem 
> description and possible solution with possible challenges for this design.
>
> Later I came to know there is ML [3] initiated by Jay Pipes which has 
> a solution of creating resource pools for disk, CPU, memory, Numa modes etc.
>
> IMO this is a good way and good to be addressed in Mitaka release. I 
> am eager to work on this and will provide any kind of help in 
> implementation, review etc.
>
> Please give us your opinion about the same.

Hi! I actually have created a work in progress blueprint for the above proposed 
solution here:

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

I will have it completed by end of week.

Best,
-jay

> [1] https://bugs.launchpad.net/nova/+bug/1252321
>
> [2] https://etherpad.openstack.org/p/shared-storage-space-count
>
> [3] 
> http://lists.openstack.org/pipermail/openstack-dev/2015-July/070564.ht
> ml

__
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

__
Disclaimer: This email and any attachments are sent in strictest confidence
for the sole use of the addressee and may contain legally privileged,
confidential, and proprietary data. If you are not the intended recipient,
please advise the sender by replying promptly to this email and then delete
and destroy this email and any attachments without any further use, copying
or forwarding.

__
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] [cinder] snapshot and cloning for NFS backend

[Kekane, Abhishek]

Hi Sean,

Author of specs is Eric Harney, If he is ok with it then I will submit the 
patch for moving specs to Mitaka.

Thank you,

Abhishek Kekane

-Original Message-
From: Kekane, Abhishek [mailto:abhishek.kek...@nttdata.com] 
Sent: 29 September 2015 17:47
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [cinder] snapshot and cloning for NFS backend

Hi Sean,

Sure I will submit a patch to add this spec in Mitaka.

Thank you,

Abhishek Kekane

-Original Message-
From: Sean McGinnis [mailto:sean.mcgin...@gmx.com]
Sent: 29 September 2015 17:38
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [cinder] snapshot and cloning for NFS backend

On Tue, Sep 29, 2015 at 06:26:06AM +, Kekane, Abhishek wrote:
> Hi Devs,
> 
> The cinder-specs [1] for snapshot and cloning NFS backend submitted by Eric 
> was approved in Kilo but due to nova issue [2] it is not implemented in Kilo 
> and Liberty.
> I am discussing about this nova bug with nova team for finding possible 
> solutions and Nikola has given some pointers about fixing the same in 
> launchpad bug.
> 
> This feature is very useful for NFS backend and if the work should be 
> continued then is there a need to resubmit this specs for approval in Mitaka?

Thanks for looking at this Abhishek. I would like to see this work continued 
and completed in Mitaka if at all possible.

Would you mind submitting a patch to add the spec to Mitaka? I will make sure 
we get that through and targeted for this release.

Thanks!

Sean

> 
> Please let me know your opinion on the same.
> 
> [1] https://review.openstack.org/#/c/133074/
> [2] https://bugs.launchpad.net/nova/+bug/1416132
> 
> 
> Thanks & Regards,
> 
> Abhishek Kekane

__
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

__
Disclaimer: This email and any attachments are sent in strictest confidence for 
the sole use of the addressee and may contain legally privileged, confidential, 
and proprietary data. If you are not the intended recipient, please advise the 
sender by replying promptly to this email and then delete and destroy this 
email and any attachments without any further use, copying or forwarding.

__
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

__
Disclaimer: This email and any attachments are sent in strictest confidence
for the sole use of the addressee and may contain legally privileged,
confidential, and proprietary data. If you are not the intended recipient,
please advise the sender by replying promptly to this email and then delete
and destroy this email and any attachments without any further use, copying
or forwarding.

__
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] [cinder] snapshot and cloning for NFS backend

[Kekane, Abhishek]

Hi Devs,

The cinder-specs [1] for snapshot and cloning NFS backend submitted by Eric was 
approved in Kilo but due to nova issue [2] it is not implemented in Kilo and 
Liberty.
I am discussing about this nova bug with nova team for finding possible 
solutions and Nikola has given some pointers about fixing the same in launchpad 
bug.

This feature is very useful for NFS backend and if the work should be continued 
then is there a need to resubmit this specs for approval in Mitaka?

Please let me know your opinion on the same.

[1] https://review.openstack.org/#/c/133074/
[2] https://bugs.launchpad.net/nova/+bug/1416132


Thanks & Regards,

Abhishek Kekane

__
Disclaimer: This email and any attachments are sent in strictest confidence
for the sole use of the addressee and may contain legally privileged,
confidential, and proprietary data. If you are not the intended recipient,
please advise the sender by replying promptly to this email and then delete
and destroy this email and any attachments without any further use, copying
or forwarding.__
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] [cinder] snapshot and cloning for NFS backend

[Kekane, Abhishek]

Hi Sean,

Sure I will submit a patch to add this spec in Mitaka.

Thank you,

Abhishek Kekane

-Original Message-
From: Sean McGinnis [mailto:sean.mcgin...@gmx.com] 
Sent: 29 September 2015 17:38
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [cinder] snapshot and cloning for NFS backend

On Tue, Sep 29, 2015 at 06:26:06AM +, Kekane, Abhishek wrote:
> Hi Devs,
> 
> The cinder-specs [1] for snapshot and cloning NFS backend submitted by Eric 
> was approved in Kilo but due to nova issue [2] it is not implemented in Kilo 
> and Liberty.
> I am discussing about this nova bug with nova team for finding possible 
> solutions and Nikola has given some pointers about fixing the same in 
> launchpad bug.
> 
> This feature is very useful for NFS backend and if the work should be 
> continued then is there a need to resubmit this specs for approval in Mitaka?

Thanks for looking at this Abhishek. I would like to see this work continued 
and completed in Mitaka if at all possible.

Would you mind submitting a patch to add the spec to Mitaka? I will make sure 
we get that through and targeted for this release.

Thanks!

Sean

> 
> Please let me know your opinion on the same.
> 
> [1] https://review.openstack.org/#/c/133074/
> [2] https://bugs.launchpad.net/nova/+bug/1416132
> 
> 
> Thanks & Regards,
> 
> Abhishek Kekane

__
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

__
Disclaimer: This email and any attachments are sent in strictest confidence
for the sole use of the addressee and may contain legally privileged,
confidential, and proprietary data. If you are not the intended recipient,
please advise the sender by replying promptly to this email and then delete
and destroy this email and any attachments without any further use, copying
or forwarding.

__
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] [murano] Fix order of arguments in assertEqual

[Kekane, Abhishek]

Hi,

There is a bug for this, you can add murano projects to this bug.

https://bugs.launchpad.net/heat/+bug/1259292

Thanks,

Abhishek Kekane

-Original Message-
From: Bulat Gaifullin [mailto:bgaiful...@mirantis.com] 
Sent: 24 September 2015 13:29
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [murano] Fix order of arguments in assertEqual

+1

> On 24 Sep 2015, at 10:45, Tetiana Lashchova  wrote:
> 
> Hi folks!
> 
> Some tests in murano code use incorrect order of arguments in assertEqual.
> The correct order expected by the testtools is
> 
> def assertEqual(self, expected, observed, message=''):
> """Assert that 'expected' is equal to 'observed'.
> 
> :param expected: The expected value.
> :param observed: The observed value.
> :param message: An optional message to include in the error.
> """
> 
> Error message has the following format:
> 
> raise mismatch_error
> testtools.matchers._impl.MismatchError: !=:
> reference = 
> actual= 
> 
> Use of arguments in incorrect order could make debug output very confusing.
> Let's fix it to make debugging easier.
> 
> Best regards,
> Tetiana Lashchova
> __
>  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

__
Disclaimer: This email and any attachments are sent in strictest confidence
for the sole use of the addressee and may contain legally privileged,
confidential, and proprietary data. If you are not the intended recipient,
please advise the sender by replying promptly to this email and then delete
and destroy this email and any attachments without any further use, copying
or forwarding.

__
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] [oslo] incubator move to private modules

[Kekane, Abhishek]

Hi All,

I am working on "Returning request-id to caller".
Please refer, https://review.openstack.org/#/c/156508

To implement this specs in cross-projects it is also required to move 
oslo-incubator to private modules.

IMO moving oslo-incubator/openstack as a private module 
oslo-incubator/_openstack will require lot of changes (import statements) in 
all projects which are using it which will be time consuming.
I also want to know if anyone is proposing blueprint/specs for the same.

Thank you,

Abhishek Kekane

From: Davanum Srinivas [mailto:dava...@gmail.com]
Sent: 26 August 2015 15:57
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [oslo] incubator move to private modules

yep ttx. this will be for Mitaka.

-- Dims

On Wed, Aug 26, 2015 at 6:18 AM, Thierry Carrez 
> wrote:
Flavio Percoco wrote:
> On 25/08/15 06:01 -0400, Davanum Srinivas wrote:
>> Morgan,
>>
>> Bit more radical :) I am inclined to just yank all code from
>> oslo-incubator and
>> let the projects modify/move what they have left into their own
>> package/module
>> structure (and change the contracts however they see fit).
>
> Glad this conversation is happening, I've started to think about this
> as well. I think we're at a point were we could just let projects move
> from were they are.
>
> However, I'd like this to be a bit more organized. For instance, if we
> dismiss oslo-incubator and let projects move forward on their own,
> it'd be better to have all the `openstack/common/` packages renamed so
> that it'll create less confusion to newcomers. At the very least, as
> Morgan mentioned, these packages could be prefixed with an `_` and
> become 'private' and 'owned' by the project.
>
> We still need a 'deprecation' process for the code in the
> oslo-incubator repository and we would still have to accept fixes for
> previous releases.

The Death of the Incubator. Sounds like a great thing to discuss at the
Design Summit. I don't think we would kill it before start of Mitaka
anyway ?

--
Thierry Carrez (ttx)


__
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



--
Davanum Srinivas :: https://twitter.com/dims

__
Disclaimer: This email and any attachments are sent in strictest confidence
for the sole use of the addressee and may contain legally privileged,
confidential, and proprietary data. If you are not the intended recipient,
please advise the sender by replying promptly to this email and then delete
and destroy this email and any attachments without any further use, copying
or forwarding.
__
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] New PyCharm License

[Kekane, Abhishek]

Hi Andrew,

My launchpad id is abhishek-kekane

Thank you,

Abhishek

From: Andrew Melton [andrew.mel...@rackspace.com]
Sent: Monday, September 21, 2015 10:54 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] New PyCharm License

Hi devs,


I've got the new license for the next year. As always, please reply to this 
email with your launchpad-id if you would like a license.


Also, if there are other JetBrains products you use to contribute to OpenStack, 
please let me know and I will request licenses.

​

--Andrew


__
Disclaimer: This email and any attachments are sent in strictest confidence
for the sole use of the addressee and may contain legally privileged,
confidential, and proprietary data. If you are not the intended recipient,
please advise the sender by replying promptly to this email and then delete
and destroy this email and any attachments without any further use, copying
or forwarding.
__
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] Pycharm License for OpenStack developers

[Kekane, Abhishek]

Thank you Michal,

Abhishek

-Original Message-
From: Dulko, Michal [mailto:michal.du...@intel.com] 
Sent: 16 September 2015 15:23
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] Pycharm License for OpenStack developers

> From: Kekane, Abhishek [mailto:abhishek.kek...@nttdata.com]
> Sent: Wednesday, September 16, 2015 11:20 AM Hi Devs,
> 
> 
> 
> I am using Pycharm for development and current license is about to expire.
> 
> Please let me know if anyone has a new license key for the same.
> 
> 
> 
> Thank you in advance.
> 
> 
> 
> Abhishek


I've applied for the license for OpenStack a moment ago. I'll send an update to 
the ML once I get a response from JetBrains.

__
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

__
Disclaimer: This email and any attachments are sent in strictest confidence
for the sole use of the addressee and may contain legally privileged,
confidential, and proprietary data. If you are not the intended recipient,
please advise the sender by replying promptly to this email and then delete
and destroy this email and any attachments without any further use, copying
or forwarding.

__
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] [cinder][nova] snapshot and cloning for NFS backend

[Kekane, Abhishek]

Hi Nikola,

Thank you for update.

Abhishek Kekane

-Original Message-
From: Nikola Đipanov [mailto:ndipa...@redhat.com] 
Sent: 27 August 2015 01:10
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [cinder][nova] snapshot and cloning for NFS backend

On 07/28/2015 09:00 AM, Kekane, Abhishek wrote:
 Hi Devs,
 
  
 
 There is an NFS backend driver for cinder, which supports only limited 
 volume handling features. Specifically, snapshot and cloning
 features are missing.
 
  
 
 Eric Harney has proposed a feature of NFS driver snapshot [1][2][3], 
 which was approved on Dec 2014 but not implemented yet.
 
  
 
 [1] blueprint 
 https://blueprints.launchpad.net/cinder/+spec/nfs-snapshots
 
 [2] cinder-specs https://review.openstack.org/#/c/133074/  - merged 
 for Kilo but moved to Liberty
 
 [3] implementation https://review.openstack.org/#/c/147186/  - WIP
 
  
 
 As of now [4] nova patch is a blocker for this feature.
 
 I have tested this feature by applying [4] nova patch and it is 
 working as per expectation.
 
  
 
 [4] https://review.openstack.org/#/c/149037/
 

so [4] is actually related to the following bug (it is linked on the
review):

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

The proposed patch is, as was discussed in some details on the patch - not the 
right approach for several reasons.

I have added a comment on the bug [1] outlining what I think is the right 
solution here, however - it is far from a trivial change.

Let me know if the comment on the bug makes sense and if I need to add more 
information.

I will try to devote some time to fixing this, as I believe this is causing us 
a lot more problems in the gate on an ongoing basis (see [2] for example), but 
the discussion in the bug should be enough to get anyone else who may want to 
pick it up on the right path to making progress!

Best,
N.

[1] https://bugs.launchpad.net/nova/+bug/1416132/comments/8
[2] https://bugs.launchpad.net/nova/+bug/1445021


__
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

__
Disclaimer: This email and any attachments are sent in strictest confidence
for the sole use of the addressee and may contain legally privileged,
confidential, and proprietary data. If you are not the intended recipient,
please advise the sender by replying promptly to this email and then delete
and destroy this email and any attachments without any further use, copying
or forwarding.

__
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] Mitaka nova-specs is open?

[Kekane, Abhishek]

Hi Nova Devs,

I have submitted a nova-specs for liberty but as it is not approved I have 
moved it under liberty/backlog.

Now mitaka specs directory is added in nova-specs.
Should it be ok to move nova-specs from specs/liberty/backlog/approved to 
specs/mitaka/approved directory?

Please let me know your opinion on the same.


Thanks  Best Regards,

Abhishek Kekane

__
Disclaimer: This email and any attachments are sent in strictest confidence
for the sole use of the addressee and may contain legally privileged,
confidential, and proprietary data. If you are not the intended recipient,
please advise the sender by replying promptly to this email and then delete
and destroy this email and any attachments without any further use, copying
or forwarding.__
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] cross project communication: Return request-id to caller

[Kekane, Abhishek]

Hi Devs,

I have modified the cross-project specs for request-id based on this analysis 
and submitted same for review.
Please refer, 
https://review.openstack.org/#/c/156508/17/specs/return-request-id.rst and give 
your valuable feedback on the same.

Thank you in advance.

Abhishek Kekane

-Original Message-
From: Gorka Eguileor [mailto:gegui...@redhat.com] 
Sent: 29 July 2015 15:07
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [all] cross project communication: Return 
request-id to caller

On Tue, Jul 28, 2015 at 09:48:25AM -0400, Doug Hellmann wrote:
 Excerpts from Gorka Eguileor's message of 2015-07-28 10:37:42 +0200:
  On Fri, Jul 24, 2015 at 10:08:45AM -0400, Doug Hellmann wrote:
   Excerpts from Kekane, Abhishek's message of 2015-07-24 06:33:00 +:
Hi Devs,

X-Openstack-Request-Id. We have analysed python-cinderclient, 
python-glanceclient, python-novaclient, python-keystoneclient and 
python-neutronclient to check the return types.

There are 9 ways return values are returned from python clients:
1. List
2. Dict
3. Resource class object
4. None
5. Tuple
6. Exception
7. Boolean (True/False, for keystoneclient) 8. Generator (for 
list api's in glanceclient) 9. String (for novaclient)

Out of 9 we have solution for all return types except generator.
In case of glance-client list api's are returning generator which is 
immutable. So it is not possible to return request-id in this case, 
which is a blocker for adopting the solution.

I have added detail analysis for above return types in etherpad [2] as 
solution #3.

If you have any suggestion in case of generation type then please let 
me know.
   
   It should be possible to create a new class to wrap the existing 
   generator and implement the iterator protocol [3].
   
   [3] 
   https://docs.python.org/2/reference/expressions.html#generator-ite
   rator-methods
   
   Doug
   
  
  Unless I'm missing something I think we wouldn't even need to create 
  a new class that implements the iterator protocol, we can just 
  return a generator that generates from the other one.
  
  For example, for each of the requests, if we get the generator in 
  variable *result* that returns dictionaries and we want to add 
  *headers* to each dictionary:
  
  return (DictWithHeaders(resource, headers) for resource in result)
  
  Wouldn't that work?
 
 That would work, but it wouldn't be consistent with the way I read [2] 
 as describing how the other methods are being updated.
 
 For example, a method that now returns a list() will return a 
 ListWithHeaders(), and only that returned object will have the 
 headers, not its contents. A caller could do:

You are right, it wouldn't be consistent with other methods, and that's not 
good. So the new iterator class wrapper seems to be the way to go.


Gorka.

 
   response = client.some_method_returning_a_list()
   print reponse.headers
 
 but could not do
 
   print response[0].headers
 
 and get the same values.
 
 Creating a GeneratorWithHeaders class mirrors that behavior for 
 methods that return generators instead of lists.
 
 Doug
 
[2] https://etherpad.openstack.org/p/request-id
 
 __
  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

__
Disclaimer: This email and any attachments are sent in strictest confidence
for the sole use of the addressee and may contain legally privileged,
confidential, and proprietary data. If you are not the intended recipient,
please advise the sender by replying promptly to this email and then delete
and destroy this email and any attachments without any further use, copying
or forwarding.

__
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] [cinder][nova] snapshot and cloning for NFS backend

[Kekane, Abhishek]

Hi Devs,

There is an NFS backend driver for cinder, which supports only limited volume 
handling features. Specifically, snapshot and cloning features are missing.

Eric Harney has proposed a feature of NFS driver snapshot [1][2][3], which 
was approved on Dec 2014 but not implemented yet.

[1] blueprint https://blueprints.launchpad.net/cinder/+spec/nfs-snapshots
[2] cinder-specs https://review.openstack.org/#/c/133074/  - merged for Kilo 
but moved to Liberty
[3] implementation https://review.openstack.org/#/c/147186/  - WIP

As of now [4] nova patch is a blocker for this feature.
I have tested this feature by applying [4] nova patch and it is working as per 
expectation.

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

IMO this is a very useful feature and I want to know communities 
opinion/direction about getting it merged during liberty time-frame.

Thanks  Regards,

Abhishek Kekane

__
Disclaimer: This email and any attachments are sent in strictest confidence
for the sole use of the addressee and may contain legally privileged,
confidential, and proprietary data. If you are not the intended recipient,
please advise the sender by replying promptly to this email and then delete
and destroy this email and any attachments without any further use, copying
or forwarding.__
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] [cinder][nova] snapshot and cloning for NFS backend

[Kekane, Abhishek]

Hi Jordan,

The patch [4] is abandoned by the owner because as of now as it’s not an 
appropriate way to fix this issue and it need to be fixed using some other way.
Nova members please let us know your suggestions about the same.

Thank you,

Abhishek Kekane

From: Jordan Pittier [mailto:jordan.pitt...@scality.com]
Sent: 28 July 2015 14:24
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [cinder][nova] snapshot and cloning for NFS backend

Hi

The patch [4] has been abandoned but it's not clear why. I too think that 
having a full fledged NFS driver would be great !

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

Jordan

On Tue, Jul 28, 2015 at 10:00 AM, Kekane, Abhishek 
abhishek.kek...@nttdata.commailto:abhishek.kek...@nttdata.com wrote:
Hi Devs,

There is an NFS backend driver for cinder, which supports only limited volume 
handling features. Specifically, snapshot and cloning features are missing.

Eric Harney has proposed a feature of NFS driver snapshot [1][2][3], which 
was approved on Dec 2014 but not implemented yet.

[1] blueprint https://blueprints.launchpad.net/cinder/+spec/nfs-snapshots
[2] cinder-specs https://review.openstack.org/#/c/133074/  - merged for Kilo 
but moved to Liberty
[3] implementation https://review.openstack.org/#/c/147186/  - WIP

As of now [4] nova patch is a blocker for this feature.
I have tested this feature by applying [4] nova patch and it is working as per 
expectation.

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

IMO this is a very useful feature and I want to know communities 
opinion/direction about getting it merged during liberty time-frame.

Thanks  Regards,

Abhishek Kekane

__
Disclaimer: This email and any attachments are sent in strictest confidence
for the sole use of the addressee and may contain legally privileged,
confidential, and proprietary data. If you are not the intended recipient,
please advise the sender by replying promptly to this email and then delete
and destroy this email and any attachments without any further use, copying
or forwarding.

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


__
Disclaimer: This email and any attachments are sent in strictest confidence
for the sole use of the addressee and may contain legally privileged,
confidential, and proprietary data. If you are not the intended recipient,
please advise the sender by replying promptly to this email and then delete
and destroy this email and any attachments without any further use, copying
or forwarding.
__
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] [all] cross project communication: Return request-id to caller

[Kekane, Abhishek]

Hi Devs,

X-Openstack-Request-Id. We have analysed python-cinderclient, 
python-glanceclient, python-novaclient, python-keystoneclient and 
python-neutronclient to check the return types.

There are 9 ways return values are returned from python clients:
1. List
2. Dict
3. Resource class object
4. None
5. Tuple
6. Exception
7. Boolean (True/False, for keystoneclient)
8. Generator (for list api's in glanceclient)
9. String (for novaclient)

Out of 9 we have solution for all return types except generator.
In case of glance-client list api's are returning generator which is immutable. 
So it is not possible to return request-id in this case, which is a blocker for 
adopting the solution.

I have added detail analysis for above return types in etherpad [2] as solution 
#3.

If you have any suggestion in case of generation type then please let me know.


[1] 
http://eavesdrop.openstack.org/meetings/crossproject/2015/crossproject.2015-07-07-21.01.log.html
[2] https://etherpad.openstack.org/p/request-id


Thanks  Best Regards,

Abhishek Kekane

__
Disclaimer: This email and any attachments are sent in strictest confidence
for the sole use of the addressee and may contain legally privileged,
confidential, and proprietary data. If you are not the intended recipient,
please advise the sender by replying promptly to this email and then delete
and destroy this email and any attachments without any further use, copying
or forwarding.__
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] Recall: [Nova] [Liberty] Approval dates for non-priority specs

[Kekane, Abhishek]

Kekane, Abhishek would like to recall the message, [Nova] [Liberty] Approval 
dates for non-priority specs .

__
Disclaimer: This email and any attachments are sent in strictest confidence
for the sole use of the addressee and may contain legally privileged,
confidential, and proprietary data. If you are not the intended recipient,
please advise the sender by replying promptly to this email and then delete
and destroy this email and any attachments without any further use, copying
or forwarding.

__
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] [Liberty] Approval dates for non-priority specs

[Kekane, Abhishek]

Hi Nova Devs,

I have submitted a nova spec [1] for improving unshelve api performance.

It's not listed under the liberty priorities, in spec also I have set project 
priority as None and in Launchpad blueprint [2] also milestone target is None.
As per nova liberty schedule, June 23-25, 2015 were the dates for nova spec 
freeze for L and July 28-30, 2015 liberty-2 is non-priority feature freeze.

I have raised review requests in couple of nova meetings as well as on IRC 
whenever I got a chance for discussion but failed to get any constructive 
feedback.

I would like to know what will the last date of approving non-priority specs 
for Liberty.
If it is already passed, can I raise a Spec freeze exception for the same.


Thank you in advance.

Abhishek Kekane


__
Disclaimer: This email and any attachments are sent in strictest confidence
for the sole use of the addressee and may contain legally privileged,
confidential, and proprietary data. If you are not the intended recipient,
please advise the sender by replying promptly to this email and then delete
and destroy this email and any attachments without any further use, copying
or forwarding.__
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] Approval dates for non-priority specs

[Kekane, Abhishek]

Hi Nova Devs,

I have submitted a nova spec [1] for improving unshelve api performance.

It's not listed under the liberty priorities, in spec also I have set project 
priority as None and in Launchpad blueprint [2] also milestone target is None.
As per nova liberty schedule, June 23-25, 2015 were the dates for nova spec 
freeze for L and July 28-30, 2015 liberty-2 is non-priority feature freeze.

I have raised review requests in couple of nova meetings as well as on IRC 
whenever I got a chance for discussion but failed to get any constructive 
feedback.

I would like to know what will the last date of approving non-priority specs 
for Liberty.
If it is already passed, can I raise a Spec freeze exception for the same.


Thank you in advance.

Abhishek Kekane

[1] https://review.openstack.org/#/c/135387/
[2] https://blueprints.launchpad.net/nova/+spec/improve-unshelve-performance


__
Disclaimer: This email and any attachments are sent in strictest confidence
for the sole use of the addressee and may contain legally privileged,
confidential, and proprietary data. If you are not the intended recipient,
please advise the sender by replying promptly to this email and then delete
and destroy this email and any attachments without any further use, copying
or forwarding.__
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] Recall: [Nova] [Liberty] Approval dates for non-priority specs

[Kekane, Abhishek]

Kekane, Abhishek would like to recall the message, [Nova] [Liberty] Approval 
dates for non-priority specs .

__
Disclaimer: This email and any attachments are sent in strictest confidence
for the sole use of the addressee and may contain legally privileged,
confidential, and proprietary data. If you are not the intended recipient,
please advise the sender by replying promptly to this email and then delete
and destroy this email and any attachments without any further use, copying
or forwarding.

__
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] cross project communication: Return request-id to caller

[Kekane, Abhishek]

Hi Devs,

So for I have got following responses on the proposed solutions:

Solution 1: Return tuple containing headers and body from - 3 +1
Solution 2: Use thread local storage to store 'x-openstack-request-id' returned 
from headers - 0 +1
Solution 3: Unique request-id across OpenStack Services - 1 +1

Requesting community people, cross-project members and PTL's to go through this 
mailing thread [1] and give your suggestions/opinions about the solutions 
proposed so that It will be easy to finalize the solution.

[1] http://lists.openstack.org/pipermail/openstack-dev/2015-May/064842.html

Thanks  Regards,

Abhishek Kekane

-Original Message-
From: Nikhil Komawar [mailto:nik.koma...@gmail.com] 
Sent: 28 May 2015 12:34
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [all] cross project communication: Return 
request-id to caller

Did you get to talk with anyone in the LogWG ( 
https://wiki.openstack.org/wiki/LogWorkingGroup )? In wonder what kind of 
recommendations, standards we can come up with while adopting a cross project 
solution. If our logs follow certain prefix and or suffix style across 
projects, that would help a long way.

Personally: +1 on Solution 1

On 5/28/15 2:14 AM, Kekane, Abhishek wrote:

 Hi Devs,

  

 Thank you for your opinions/thoughts.

 However I would like to suggest that please give +1 against the 
 solution which you will like to propose so that at the end it will be 
 helpful for us to consolidate the voting against each solution and 
 make some decision.

  

 Thanks in advance.

  

 Abhishek Kekane

  

  

 *From:*Joe Gordon [mailto:joe.gord...@gmail.com]
 *Sent:* 28 May 2015 00:31
 *To:* OpenStack Development Mailing List (not for usage questions)
 *Subject:* Re: [openstack-dev] [all] cross project communication:
 Return request-id to caller

  

  

  

 On Wed, May 27, 2015 at 12:06 AM, Kekane, Abhishek 
 abhishek.kek...@nttdata.com mailto:abhishek.kek...@nttdata.com wrote:

 Hi Devs,

  

 Each OpenStack service sends a request ID header with HTTP responses.
 This request ID can be useful for tracking down problems in the logs.
 However, when operation crosses service boundaries, this tracking can 
 become difficult, as each service has its own request ID. Request ID 
 is not returned to the caller, so it is not easy to track the request.
 This becomes especially problematic when requests are coming in 
 parallel. For example, glance will call cinder for creating image, but 
 that cinder instance may be handling several other requests at the 
 same time. By using same request ID in the log, user can easily find 
 the cinder request ID that is same as glance request ID in the g-api 
 log. It will help operators/developers to analyse logs effectively.

  

 Thank you for writing this up.

  

  

 To address this issue we have come up with following solutions:

  

 Solution 1: Return tuple containing headers and body from
 respective clients (also favoured by Joe Gordon)

 Reference:
 
 https://review.openstack.org/#/c/156508/6/specs/log-request-id-mapping
 s.rst

  

 Pros:

 1. Maintains backward compatibility

 2. Effective debugging/analysing of the problem as both calling
 service request-id and called service request-id are logged in
 same log message

 3. Build a full call graph

 4. End user will able to know the request-id of the request and
 can approach service provider to know the cause of failure of
 particular request.

  

 Cons:

 1. The changes need to be done first in cross-projects before
 making changes in clients

 2. Applications which are using python-*clients needs to do
 required changes (check return type of  response)

  

 Additional cons:

  

 3. Cannot simply search all logs (ala logstash) using the request-id 
 returned to the user without any post processing of the logs.

  

  

  

 Solution 2:  Use thread local storage to store
 'x-openstack-request-id' returned from headers (suggested by Doug
 Hellmann)

 Reference:
 
 https://review.openstack.org/#/c/156508/9/specs/log-request-id-mapping
 s.rst

  

 Add new method 'get_openstack_request_id' to return this
 request-id to the caller.

  

 Pros:

 1. Doesn't break compatibility

 2. Minimal changes are required in client

 3. Build a full call graph

  

 Cons:

 1. Malicious user can send long request-id to fill up the
 disk-space, resulting in potential DoS

 2. Changes need to be done in all python-*clients

 3. Last request id should be flushed out in a subsequent call
 otherwise it will return wrong request id to the caller

  

  

 Solution 3: Unique request-id across OpenStack Services (suggested
 by Jamie Lennox)

 Reference:
 
 https://review.openstack.org/#/c/156508/10/specs/log-request-id-mappin
 gs.rst

  

 Get 'x-openstack

Re: [openstack-dev] [all] cross project communication: Return request-id to caller

[Kekane, Abhishek]

Hi Nikhil,

Thanks for the opinion, actually I was in different time-zone and was not aware 
about this LogWG. I will certainly approach them in next meeting.

Thank you,

Abhishek Kekane

-Original Message-
From: Nikhil Komawar [mailto:nik.koma...@gmail.com] 
Sent: 28 May 2015 12:34
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [all] cross project communication: Return 
request-id to caller

Did you get to talk with anyone in the LogWG ( 
https://wiki.openstack.org/wiki/LogWorkingGroup )? In wonder what kind of 
recommendations, standards we can come up with while adopting a cross project 
solution. If our logs follow certain prefix and or suffix style across 
projects, that would help a long way.

Personally: +1 on Solution 1

On 5/28/15 2:14 AM, Kekane, Abhishek wrote:

 Hi Devs,

  

 Thank you for your opinions/thoughts.

 However I would like to suggest that please give +1 against the 
 solution which you will like to propose so that at the end it will be 
 helpful for us to consolidate the voting against each solution and 
 make some decision.

  

 Thanks in advance.

  

 Abhishek Kekane

  

  

 *From:*Joe Gordon [mailto:joe.gord...@gmail.com]
 *Sent:* 28 May 2015 00:31
 *To:* OpenStack Development Mailing List (not for usage questions)
 *Subject:* Re: [openstack-dev] [all] cross project communication:
 Return request-id to caller

  

  

  

 On Wed, May 27, 2015 at 12:06 AM, Kekane, Abhishek 
 abhishek.kek...@nttdata.com mailto:abhishek.kek...@nttdata.com wrote:

 Hi Devs,

  

 Each OpenStack service sends a request ID header with HTTP responses.
 This request ID can be useful for tracking down problems in the logs.
 However, when operation crosses service boundaries, this tracking can 
 become difficult, as each service has its own request ID. Request ID 
 is not returned to the caller, so it is not easy to track the request.
 This becomes especially problematic when requests are coming in 
 parallel. For example, glance will call cinder for creating image, but 
 that cinder instance may be handling several other requests at the 
 same time. By using same request ID in the log, user can easily find 
 the cinder request ID that is same as glance request ID in the g-api 
 log. It will help operators/developers to analyse logs effectively.

  

 Thank you for writing this up.

  

  

 To address this issue we have come up with following solutions:

  

 Solution 1: Return tuple containing headers and body from
 respective clients (also favoured by Joe Gordon)

 Reference:
 
 https://review.openstack.org/#/c/156508/6/specs/log-request-id-mapping
 s.rst

  

 Pros:

 1. Maintains backward compatibility

 2. Effective debugging/analysing of the problem as both calling
 service request-id and called service request-id are logged in
 same log message

 3. Build a full call graph

 4. End user will able to know the request-id of the request and
 can approach service provider to know the cause of failure of
 particular request.

  

 Cons:

 1. The changes need to be done first in cross-projects before
 making changes in clients

 2. Applications which are using python-*clients needs to do
 required changes (check return type of  response)

  

 Additional cons:

  

 3. Cannot simply search all logs (ala logstash) using the request-id 
 returned to the user without any post processing of the logs.

  

  

  

 Solution 2:  Use thread local storage to store
 'x-openstack-request-id' returned from headers (suggested by Doug
 Hellmann)

 Reference:
 
 https://review.openstack.org/#/c/156508/9/specs/log-request-id-mapping
 s.rst

  

 Add new method 'get_openstack_request_id' to return this
 request-id to the caller.

  

 Pros:

 1. Doesn't break compatibility

 2. Minimal changes are required in client

 3. Build a full call graph

  

 Cons:

 1. Malicious user can send long request-id to fill up the
 disk-space, resulting in potential DoS

 2. Changes need to be done in all python-*clients

 3. Last request id should be flushed out in a subsequent call
 otherwise it will return wrong request id to the caller

  

  

 Solution 3: Unique request-id across OpenStack Services (suggested
 by Jamie Lennox)

 Reference:
 
 https://review.openstack.org/#/c/156508/10/specs/log-request-id-mappin
 gs.rst

  

 Get 'x-openstack-request-id' from auth plugin and add it to the
 request headers. If 'x-openstack-request-id' key is present in the
 request header, then it will use the same one further or else it
 will generate a new one.

  

 Dependencies:

 https://review.openstack.org/#/c/164582/ - Include request-id in
 auth plugin and add it to request headers

 https://review.openstack.org/#/c/166063/ - Add session-object for
 glance

Re: [openstack-dev] [all] cross project communication: Return request-id to caller

[Kekane, Abhishek]

Hi Devs,

Thank you for your opinions/thoughts.
However I would like to suggest that please give +1 against the solution which 
you will like to propose so that at the end it will be helpful for us to 
consolidate the voting against each solution and make some decision.

Thanks in advance.

Abhishek Kekane


From: Joe Gordon [mailto:joe.gord...@gmail.com]
Sent: 28 May 2015 00:31
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [all] cross project communication: Return 
request-id to caller



On Wed, May 27, 2015 at 12:06 AM, Kekane, Abhishek 
abhishek.kek...@nttdata.commailto:abhishek.kek...@nttdata.com wrote:
Hi Devs,

Each OpenStack service sends a request ID header with HTTP responses. This 
request ID can be useful for tracking down problems in the logs. However, when 
operation crosses service boundaries, this tracking can become difficult, as 
each service has its own request ID. Request ID is not returned to the caller, 
so it is not easy to track the request. This becomes especially problematic 
when requests are coming in parallel. For example, glance will call cinder for 
creating image, but that cinder instance may be handling several other requests 
at the same time. By using same request ID in the log, user can easily find the 
cinder request ID that is same as glance request ID in the g-api log. It will 
help operators/developers to analyse logs effectively.

Thank you for writing this up.


To address this issue we have come up with following solutions:

Solution 1: Return tuple containing headers and body from respective clients 
(also favoured by Joe Gordon)
Reference: 
https://review.openstack.org/#/c/156508/6/specs/log-request-id-mappings.rst

Pros:
1. Maintains backward compatibility
2. Effective debugging/analysing of the problem as both calling service 
request-id and called service request-id are logged in same log message
3. Build a full call graph
4. End user will able to know the request-id of the request and can approach 
service provider to know the cause of failure of particular request.

Cons:
1. The changes need to be done first in cross-projects before making changes in 
clients
2. Applications which are using python-*clients needs to do required changes 
(check return type of  response)

Additional cons:

3. Cannot simply search all logs (ala logstash) using the request-id returned 
to the user without any post processing of the logs.



Solution 2:  Use thread local storage to store 'x-openstack-request-id' 
returned from headers (suggested by Doug Hellmann)
Reference: 
https://review.openstack.org/#/c/156508/9/specs/log-request-id-mappings.rst

Add new method ‘get_openstack_request_id’ to return this request-id to the 
caller.

Pros:
1. Doesn’t break compatibility
2. Minimal changes are required in client
3. Build a full call graph

Cons:
1. Malicious user can send long request-id to fill up the disk-space, resulting 
in potential DoS
2. Changes need to be done in all python-*clients
3. Last request id should be flushed out in a subsequent call otherwise it will 
return wrong request id to the caller


Solution 3: Unique request-id across OpenStack Services (suggested by Jamie 
Lennox)
Reference: 
https://review.openstack.org/#/c/156508/10/specs/log-request-id-mappings.rst

Get 'x-openstack-request-id' from auth plugin and add it to the request 
headers. If 'x-openstack-request-id' key is present in the request header, then 
it will use the same one further or else it will generate a new one.

Dependencies:
https://review.openstack.org/#/c/164582/ - Include request-id in auth plugin 
and add it to request headers
https://review.openstack.org/#/c/166063/ - Add session-object for glance client
Add 'UserAuthPlugin' and '_ContextAuthPlugin' same as nova in cinder and neutron


Pros:
1. Using same request id for the request crossing multiple service boundaries 
will help operators/developers identify the problem quickly
2. Required changes only in keystonemiddleware and oslo_middleware libraries. 
No changes are required in the python client bindings or OpenStack core services

Cons:
1. As 'x-openstack-request-id' in the request header will be visible to the 
user, it is possible to send same request id for multiple requests which in 
turn could create more problems in case of troubleshooting cause of the failure 
as request_id middleware will not check for its uniqueness in the scope of the 
running OpenStack service.
2. Having the same request ID for all services for a single user API call means 
you cannot generate a full call graph. For example if a single user's nova API 
call produces 2 calls to glance you want to be able to differentiate the two 
different calls.


During the Liberty design summit, I had a chance of discussing these designs 
with some of the core members like Doug, Joe Gordon, Jamie Lennox etc. But not 
able to came to any conclusion on the final design and know the communities 
direction by which way

[openstack-dev] [all] cross project communication: Return request-id to caller

[Kekane, Abhishek]

Hi Devs,

Each OpenStack service sends a request ID header with HTTP responses. This 
request ID can be useful for tracking down problems in the logs. However, when 
operation crosses service boundaries, this tracking can become difficult, as 
each service has its own request ID. Request ID is not returned to the caller, 
so it is not easy to track the request. This becomes especially problematic 
when requests are coming in parallel. For example, glance will call cinder for 
creating image, but that cinder instance may be handling several other requests 
at the same time. By using same request ID in the log, user can easily find the 
cinder request ID that is same as glance request ID in the g-api log. It will 
help operators/developers to analyse logs effectively.

To address this issue we have come up with following solutions:

Solution 1: Return tuple containing headers and body from respective clients 
(also favoured by Joe Gordon)
Reference: 
https://review.openstack.org/#/c/156508/6/specs/log-request-id-mappings.rst

Pros:
1. Maintains backward compatibility
2. Effective debugging/analysing of the problem as both calling service 
request-id and called service request-id are logged in same log message
3. Build a full call graph
4. End user will able to know the request-id of the request and can approach 
service provider to know the cause of failure of particular request.

Cons:
1. The changes need to be done first in cross-projects before making changes in 
clients
2. Applications which are using python-*clients needs to do required changes 
(check return type of  response)


Solution 2:  Use thread local storage to store 'x-openstack-request-id' 
returned from headers (suggested by Doug Hellmann)
Reference: 
https://review.openstack.org/#/c/156508/9/specs/log-request-id-mappings.rst

Add new method 'get_openstack_request_id' to return this request-id to the 
caller.

Pros:
1. Doesn't break compatibility
2. Minimal changes are required in client
3. Build a full call graph

Cons:
1. Malicious user can send long request-id to fill up the disk-space, resulting 
in potential DoS
2. Changes need to be done in all python-*clients
3. Last request id should be flushed out in a subsequent call otherwise it will 
return wrong request id to the caller


Solution 3: Unique request-id across OpenStack Services (suggested by Jamie 
Lennox)
Reference: 
https://review.openstack.org/#/c/156508/10/specs/log-request-id-mappings.rst

Get 'x-openstack-request-id' from auth plugin and add it to the request 
headers. If 'x-openstack-request-id' key is present in the request header, then 
it will use the same one further or else it will generate a new one.

Dependencies:
https://review.openstack.org/#/c/164582/ - Include request-id in auth plugin 
and add it to request headers
https://review.openstack.org/#/c/166063/ - Add session-object for glance client
Add 'UserAuthPlugin' and '_ContextAuthPlugin' same as nova in cinder and neutron


Pros:
1. Using same request id for the request crossing multiple service boundaries 
will help operators/developers identify the problem quickly
2. Required changes only in keystonemiddleware and oslo_middleware libraries. 
No changes are required in the python client bindings or OpenStack core services

Cons:
1. As 'x-openstack-request-id' in the request header will be visible to the 
user, it is possible to send same request id for multiple requests which in 
turn could create more problems in case of troubleshooting cause of the failure 
as request_id middleware will not check for its uniqueness in the scope of the 
running OpenStack service.
2. Having the same request ID for all services for a single user API call means 
you cannot generate a full call graph. For example if a single user's nova API 
call produces 2 calls to glance you want to be able to differentiate the two 
different calls.


During the Liberty design summit, I had a chance of discussing these designs 
with some of the core members like Doug, Joe Gordon, Jamie Lennox etc. But not 
able to came to any conclusion on the final design and know the communities 
direction by which way they want to use this request-id effectively.

However IMO, solution 1 sounds more useful as the debugger can able to build 
the full call graph which can be helpful for analysing gate failures 
effectively as well as end user will be able to know his request-id and can 
track his request.

I request all community members to go through these solutions and let us know 
which is the appropriate way to improve the logs by logging request-id.


Thanks  Regards,

Abhishek Kekane

__
Disclaimer: This email and any attachments are sent in strictest confidence
for the sole use of the addressee and may contain legally privileged,
confidential, and proprietary data. If you are not the intended recipient,
please advise the sender by replying promptly to this email and then delete
and 

[openstack-dev] [oslo] Add request_utils module in oslo-incubator

[Kekane, Abhishek]

Hi Devs,

Earlier request_utils module was removed from oslo-incubator [1] as it was not 
used.
Now we want to use this module for logging request-id  across 
openstack-services [2].

I have submitted a patch [3] to add request_utils module back to oslo-incubator.
If anyone has suggestions please let me know.


[1] https://review.openstack.org/#/c/150370/
[2] https://review.openstack.org/#/c/156508/
[3] https://review.openstack.org/#/c/170074/



Thanks  Regards,

Abhishek Kekane

__
Disclaimer: This email and any attachments are sent in strictest confidence
for the sole use of the addressee and may contain legally privileged,
confidential, and proprietary data. If you are not the intended recipient,
please advise the sender by replying promptly to this email and then delete
and destroy this email and any attachments without any further use, copying
or forwarding.__
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]: Doubts regarding Cells V2 deployment

[Kekane, Abhishek]

Hi Devs,

I have couple of questions regarding cells V2.

Once cells V2 is implemented then there will be no concept on non-cell 
deployment which means there will be one cell at least (by default).
1. How the deployment with multiple availability zones done with cells V2?
2. How the availability zones and cells will be mapped? Is there any specific 
plan to target this?

Please let me know your opinions on the same.

Thanks  Regards,

Abhishek Kekane

__
Disclaimer: This email and any attachments are sent in strictest confidence
for the sole use of the addressee and may contain legally privileged,
confidential, and proprietary data. If you are not the intended recipient,
please advise the sender by replying promptly to this email and then delete
and destroy this email and any attachments without any further use, copying
or forwarding.__
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] Unshelve Instance Performance Optimization Questions

[Kekane, Abhishek]

Hi John,

Thanks for your opinion.

Fundamentally we cannot assume infinite storage space.

To enhance the shelve/unshelve performance, I have proposed nova-specs [1], in 
which there are two challenges.

A. This design is libvirt specific, currently I am using KVM hypervisor but I 
am open to make changes to other hypervisors.
  I don't have the know-how about other hypervisors (how to configuration 
etc.)  any help about same from community is appreciated.

B. HostAggregateGroupFilter [2] (Rescheduling instance)- Filter to schedule 
instance on different node if shared storage is full or resources are not 
available.
 Please let me know your opinion about this HostAggregateGroupFilter.

I request community members to go through the nova-specs [1] and patches 
submitted [3] for the same and let us give your feedback on the same.

[1] https://review.openstack.org/135387
[2] https://review.openstack.org/150330
[3] https://review.openstack.org/150315, https://review.openstack.org/150337, 
https://review.openstack.org/150344

Thank You,

Abhishek Kekane

-Original Message-
From: John Garbutt [mailto:j...@johngarbutt.com] 
Sent: 12 March 2015 17:41
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [nova] Unshelve Instance Performance Optimization 
Questions

Hi,

On 11 March 2015 at 06:35, Kekane, Abhishek abhishek.kek...@nttdata.com wrote:
 In case of start/stop API’s cpu/memory are not released/reassigned. We 
 can modify these API’s to release the cpu and memory while stopping 
 the instance and reassign the same while starting the instance. In 
 this case also rescheduling logic need  to be modified to reschedule 
 the instance on different host, if required resources are not 
 available while starting the instance. This is similar to what I have 
 implemented in [2] Improving the performance of unshelve API.

I am against start releasing the resources, as you can't guarantee start will 
work quickly. Similar to suspend I suppose.

The idea of shelve/unshelve is to avoid that problem, by ensuring you can 
resume the VM anywhere, should someone else use the resources you have freed 
up. But the idea was to optimize for a quick unshelve, where possible. The 
feature is not really complete, we need a scheduling weighter to deal with 
avoiding that capacity till you need it, etc. When you have shared storage, it 
maybes sense to add the option of skipping the snapshot (boot from volume 
clearly doesn't need a snapshot), if you are happy to assume there will always 
be space on some host that can see that shared storage.

 Please let me know your opinion, whether we can modify start/stop 
 API’s as an alternative to shelve/unshelve API’s.

I would rather we enhance shelve/unshelve, rather than fundamentally change the 
semantics of start/stop.

Thanks,
John


 From: Kekane, Abhishek [mailto:abhishek.kek...@nttdata.com]
 Sent: 24 February 2015 12:47

 To: OpenStack Development Mailing List (not for usage questions)
 Subject: Re: [openstack-dev] [nova] Unshelve Instance Performance 
 Optimization Questions



 Hi Duncan,



 Thank you for the inputs.



 @Community-Members

 I want to know if there are any other alternatives to improve the 
 performance of unshelve api ((booted from image only).

 Please give me your opinion on the same.



 Thank You,



 Abhishek Kekane







 From: Duncan Thomas [mailto:duncan.tho...@gmail.com]
 Sent: 16 February 2015 16:46
 To: OpenStack Development Mailing List (not for usage questions)
 Subject: Re: [openstack-dev] [nova] Unshelve Instance Performance 
 Optimization Questions



 There has been some talk in cinder meetings about making 
 cinder-glance interactions more efficient. They are already 
 optimised in some deployments, e.g. ceph glance and ceph cinder, and 
 some backends cache glance images so that many volumes created from the same 
 image becomes very efficient.
 (search the meeting logs or channel logs for 'public snapshot' to get 
 some entry points into the discussions)

 I'd like to see more work done on this, and perhaps re-examine a 
 cinder backend to glance. This would give some of what you're 
 suggesting (particularly fast, low traffic un-shelve), and there is 
 more that can be done to improve that performance, particularly if we 
 can find a better performing generic CoW technology than QCOW2.

 As suggested in the review, in the short term you might be better 
 experimenting with moving to boot-from-volume instances if you have a 
 suitable cinder deployed, since that gives you some of the performance 
 improvements already.



 On 16 February 2015 at 12:10, Kekane, Abhishek 
 abhishek.kek...@nttdata.com
 wrote:

 Hi Devs,



 Problem Statement: Performance and storage efficiency of 
 shelving/unshelving instance booted from image is far worse than instance 
 booted from volume.



 When you unshelve hundreds of instances at the same time, instance 
 spawning time varies and it mainly

Re: [openstack-dev] [nova] Unshelve Instance Performance Optimization Questions

[Kekane, Abhishek]

Hi John,

Thanks for your opinion.

Fundamentally we cannot assume infinite storage space.

To enhance the shelve/unshelve performance, I have proposed nova-specs [1], in 
which there are two challenges.

A. This design is libvirt specific, currently I am using KVM hypervisor but I 
am open to make changes to other hypervisors.
  I don't have the know-how about other hypervisors (how to configuration 
etc.)  any help about same from community is appreciated.

B. HostAggregateGroupFilter [2] - Filter to schedule host on different node if 
shared storage is full or resources are not available.
 Please let me know your opinion about this HostAggregateGroupFilter.

I request community members to go through the nova-specs [1] and patches 
submitted [3] for the same and let us give your feedback on the same.

[1] https://review.openstack.org/135387
[2] https://review.openstack.org/150330
[3] https://review.openstack.org/150315, https://review.openstack.org/150337, 
https://review.openstack.org/150344

Thank You,

Abhishek Kekane

-Original Message-
From: John Garbutt [mailto:j...@johngarbutt.com] 
Sent: 12 March 2015 17:41
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [nova] Unshelve Instance Performance Optimization 
Questions

Hi,

On 11 March 2015 at 06:35, Kekane, Abhishek abhishek.kek...@nttdata.com wrote:
 In case of start/stop API’s cpu/memory are not released/reassigned. We 
 can modify these API’s to release the cpu and memory while stopping 
 the instance and reassign the same while starting the instance. In 
 this case also rescheduling logic need  to be modified to reschedule 
 the instance on different host, if required resources are not 
 available while starting the instance. This is similar to what I have 
 implemented in [2] Improving the performance of unshelve API.

I am against start releasing the resources, as you can't guarantee start will 
work quickly. Similar to suspend I suppose.

The idea of shelve/unshelve is to avoid that problem, by ensuring you can 
resume the VM anywhere, should someone else use the resources you have freed 
up. But the idea was to optimize for a quick unshelve, where possible. The 
feature is not really complete, we need a scheduling weighter to deal with 
avoiding that capacity till you need it, etc. When you have shared storage, it 
maybes sense to add the option of skipping the snapshot (boot from volume 
clearly doesn't need a snapshot), if you are happy to assume there will always 
be space on some host that can see that shared storage.

 Please let me know your opinion, whether we can modify start/stop 
 API’s as an alternative to shelve/unshelve API’s.

I would rather we enhance shelve/unshelve, rather than fundamentally change the 
semantics of start/stop.

Thanks,
John


 From: Kekane, Abhishek [mailto:abhishek.kek...@nttdata.com]
 Sent: 24 February 2015 12:47

 To: OpenStack Development Mailing List (not for usage questions)
 Subject: Re: [openstack-dev] [nova] Unshelve Instance Performance 
 Optimization Questions



 Hi Duncan,



 Thank you for the inputs.



 @Community-Members

 I want to know if there are any other alternatives to improve the 
 performance of unshelve api ((booted from image only).

 Please give me your opinion on the same.



 Thank You,



 Abhishek Kekane







 From: Duncan Thomas [mailto:duncan.tho...@gmail.com]
 Sent: 16 February 2015 16:46
 To: OpenStack Development Mailing List (not for usage questions)
 Subject: Re: [openstack-dev] [nova] Unshelve Instance Performance 
 Optimization Questions



 There has been some talk in cinder meetings about making 
 cinder-glance interactions more efficient. They are already 
 optimised in some deployments, e.g. ceph glance and ceph cinder, and 
 some backends cache glance images so that many volumes created from the same 
 image becomes very efficient.
 (search the meeting logs or channel logs for 'public snapshot' to get 
 some entry points into the discussions)

 I'd like to see more work done on this, and perhaps re-examine a 
 cinder backend to glance. This would give some of what you're 
 suggesting (particularly fast, low traffic un-shelve), and there is 
 more that can be done to improve that performance, particularly if we 
 can find a better performing generic CoW technology than QCOW2.

 As suggested in the review, in the short term you might be better 
 experimenting with moving to boot-from-volume instances if you have a 
 suitable cinder deployed, since that gives you some of the performance 
 improvements already.



 On 16 February 2015 at 12:10, Kekane, Abhishek 
 abhishek.kek...@nttdata.com
 wrote:

 Hi Devs,



 Problem Statement: Performance and storage efficiency of 
 shelving/unshelving instance booted from image is far worse than instance 
 booted from volume.



 When you unshelve hundreds of instances at the same time, instance 
 spawning time varies and it mainly depends on the size

Re: [openstack-dev] [nova] Unshelve Instance Performance Optimization Questions

[Kekane, Abhishek]

Hi Devs,

As another alternative we can use start/stop API’s instead of shelve/unshelve 
the instance.
Following is the details of start/stop and shelve/unshelve on the basis of 
cpu/memory/disk released and fast respawning.

API’S: start/stop
cpu/memory released: No
Disk released: No
Fast respawning: Yes

API’S: shelve/unshelve
cpu/memory released: Yes
Disk released: Yes (Not released if shelved_offload_time = -1)
Fast respawning: No (if instance is booted from image)


In order to make unshelve fast enough, we need to preserve instance root disk 
in compute node,
which I have proposed in spec [1] of shelve-partial-offload.

In case of start/stop API’s cpu/memory are not released/reassigned. We can 
modify these API’s to release
the cpu and memory while stopping the instance and reassign the same while 
starting the instance. In this case
also rescheduling logic need  to be modified to reschedule the instance on 
different host, if required resources
are not available while starting the instance. This is similar to what I have 
implemented in [2] Improving the
performance of unshelve API.

[1] https://review.openstack.org/#/c/135387/
[2] https://review.openstack.org/#/c/150344/

Please let me know your opinion, whether we can modify start/stop API’s as an 
alternative to shelve/unshelve API’s.

Thank You,

Abhishek Kekane


From: Kekane, Abhishek [mailto:abhishek.kek...@nttdata.com]
Sent: 24 February 2015 12:47
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [nova] Unshelve Instance Performance Optimization 
Questions

Hi Duncan,

Thank you for the inputs.

@Community-Members
I want to know if there are any other alternatives to improve the performance 
of unshelve api ((booted from image only).
Please give me your opinion on the same.

Thank You,

Abhishek Kekane



From: Duncan Thomas [mailto:duncan.tho...@gmail.com]
Sent: 16 February 2015 16:46
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [nova] Unshelve Instance Performance Optimization 
Questions

There has been some talk in cinder meetings about making cinder-glance 
interactions more efficient. They are already optimised in some deployments, 
e.g. ceph glance and ceph cinder, and some backends cache glance images so that 
many volumes created from the same image becomes very efficient. (search the 
meeting logs or channel logs for 'public snapshot' to get some entry points 
into the discussions)

I'd like to see more work done on this, and perhaps re-examine a cinder backend 
to glance. This would give some of what you're suggesting (particularly fast, 
low traffic un-shelve), and there is more that can be done to improve that 
performance, particularly if we can find a better performing generic CoW 
technology than QCOW2.
As suggested in the review, in the short term you might be better experimenting 
with moving to boot-from-volume instances if you have a suitable cinder 
deployed, since that gives you some of the performance improvements already.

On 16 February 2015 at 12:10, Kekane, Abhishek 
abhishek.kek...@nttdata.commailto:abhishek.kek...@nttdata.com wrote:
Hi Devs,

Problem Statement: Performance and storage efficiency of shelving/unshelving 
instance booted from image is far worse than instance booted from volume.

When you unshelve hundreds of instances at the same time, instance spawning 
time varies and it mainly depends on the size of the instance snapshot and
the network speed between glance and nova servers.

If you have configured file store (shared storage) as a backend in Glance for 
storing images/snapshots, then it's possible to improve the performance of
unshelve instance dramatically by configuring nova.image.download.FileTransfer 
in nova. In this case, it simply copies the instance snapshot as if it is
stored on the local filesystem of the compute node. But then again in this 
case, it is observed the network traffic between shared storage servers and
nova increases enormously resulting in slow spawning of the instances.

I would like to gather some thoughts about how we can improve the performance 
of unshelve api (booted from image only) in terms of downloading large
size instance snapshots from glance.

I have proposed a nova-specs [1] to address this performance issue. Please take 
a look at it.

During the last nova mid-cycle summit, Michael 
Stillhttps://review.openstack.org/#/q/owner:mikal%2540stillhq.com+status:open,n,z
 has suggested alternative solutions to tackle this issue.

Storage solutions like ceph (Software based) and NetApp (Hardare based) support 
exposing images from glance to nova-compute and cinder-volume with
copy in write feature. This way there will be no need to download the instance 
snapshot and unshelve api will be pretty faster than getting it
from glance.

Do you think the above performance issue should be handled in the OpenStack 
software as described in nova-specs [1] or storage solutions like

Re: [openstack-dev] [nova] Unshelve Instance Performance Optimization Questions

[Kekane, Abhishek]

Hi Devs,

As another alternative we can use start/stop API’s instead of shelve/unshelve 
the instance.

API’s

cpu/memory released

Disk released

Fast respawning

Notes

start/stop

No

No

Yes



shelve/unshelve

Yes

Yes (Not released if shelved_offload_time = -1)

No

Instance does not respawn faster in case of instance is booted from image


In order to make unshelve fast enough, we need to preserve instance root disk 
in compute node,
which I have proposed in spec [1] of shelve-partial-offload.

In case of start/stop API’s cpu/memory are not released/reassigned. We can 
modify these API’s to release
the cpu and memory while stopping the instance and reassign the same while 
starting the instance. In this case
also rescheduling logic need  to be modified to reschedule the instance on 
different host, if required resources
are not available while starting the instance. This is similar to what I have 
implemented in [2] Improving the
performance of unshelve API.

[1] https://review.openstack.org/#/c/135387/
[2] https://review.openstack.org/#/c/150344/

Please let me know your opinion, whether we can modify start/stop API’s as an 
alternative to shelve/unshelve API’s.

Thank You,

Abhishek Kekane

From: Kekane, Abhishek [mailto:abhishek.kek...@nttdata.com]
Sent: 24 February 2015 12:47
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [nova] Unshelve Instance Performance Optimization 
Questions

Hi Duncan,

Thank you for the inputs.

@Community-Members
I want to know if there are any other alternatives to improve the performance 
of unshelve api ((booted from image only).
Please give me your opinion on the same.

Thank You,

Abhishek Kekane



From: Duncan Thomas [mailto:duncan.tho...@gmail.com]
Sent: 16 February 2015 16:46
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [nova] Unshelve Instance Performance Optimization 
Questions

There has been some talk in cinder meetings about making cinder-glance 
interactions more efficient. They are already optimised in some deployments, 
e.g. ceph glance and ceph cinder, and some backends cache glance images so that 
many volumes created from the same image becomes very efficient. (search the 
meeting logs or channel logs for 'public snapshot' to get some entry points 
into the discussions)

I'd like to see more work done on this, and perhaps re-examine a cinder backend 
to glance. This would give some of what you're suggesting (particularly fast, 
low traffic un-shelve), and there is more that can be done to improve that 
performance, particularly if we can find a better performing generic CoW 
technology than QCOW2.
As suggested in the review, in the short term you might be better experimenting 
with moving to boot-from-volume instances if you have a suitable cinder 
deployed, since that gives you some of the performance improvements already.

On 16 February 2015 at 12:10, Kekane, Abhishek 
abhishek.kek...@nttdata.commailto:abhishek.kek...@nttdata.com wrote:
Hi Devs,

Problem Statement: Performance and storage efficiency of shelving/unshelving 
instance booted from image is far worse than instance booted from volume.

When you unshelve hundreds of instances at the same time, instance spawning 
time varies and it mainly depends on the size of the instance snapshot and
the network speed between glance and nova servers.

If you have configured file store (shared storage) as a backend in Glance for 
storing images/snapshots, then it's possible to improve the performance of
unshelve instance dramatically by configuring nova.image.download.FileTransfer 
in nova. In this case, it simply copies the instance snapshot as if it is
stored on the local filesystem of the compute node. But then again in this 
case, it is observed the network traffic between shared storage servers and
nova increases enormously resulting in slow spawning of the instances.

I would like to gather some thoughts about how we can improve the performance 
of unshelve api (booted from image only) in terms of downloading large
size instance snapshots from glance.

I have proposed a nova-specs [1] to address this performance issue. Please take 
a look at it.

During the last nova mid-cycle summit, Michael 
Stillhttps://review.openstack.org/#/q/owner:mikal%2540stillhq.com+status:open,n,z
 has suggested alternative solutions to tackle this issue.

Storage solutions like ceph (Software based) and NetApp (Hardare based) support 
exposing images from glance to nova-compute and cinder-volume with
copy in write feature. This way there will be no need to download the instance 
snapshot and unshelve api will be pretty faster than getting it
from glance.

Do you think the above performance issue should be handled in the OpenStack 
software as described in nova-specs [1] or storage solutions like
ceph/NetApp should be used in production environment? Apart from ceph/NetApp 
solutions, are there any other options available

Re: [openstack-dev] [cinder] Resuming of workflows/tasks

[Kekane, Abhishek]

Hi Michal,

 1. Need of distributed lock to avoid same task being resumed by two instances 
 of a service. Do we need tooz to do that or is there any other solution?

Tooz library is already being used in ceilometer to manage group membership. 
(https://github.com/openstack/ceilometer/blob/master/ceilometer/coordination.py 
)
Tooz also supports MySQL driver for distributed locking, so we can use this as 
we are storing taskflow details in MySQL database.

Thank You,

Abhishek Kekane


-Original Message-
From: Dulko, Michal [mailto:michal.du...@intel.com] 
Sent: 24 February 2015 18:12
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [cinder] Resuming of workflows/tasks

Hi all,

I was working on spec[1] and prototype[2] to make Cinder to be able to resume 
workflows in case of server or service failure. Problem of requests lost and 
resources left in unresolved states in case of failure was signaled at the 
Paris Summit[3].

What I was able to prototype was to resume running tasks locally after service 
restart using persistence API provided by TaskFlow. However core team agreed 
that we should aim at resuming workflows globally even by other service 
instances (which I think is a good decision).

There are few major problems blocking this approach:

1. Need of distributed lock to avoid same task being resumed by two instances 
of a service. Do we need tooz to do that or is there any other solution?
2. Are we going to step out from using TaskFlow? Such idea came up at the 
mid-cycle meetup, what's the status of it? Without TaskFlow's persistence 
implementing task resumptions would be a lot more difficult.
3. In case of cinder-api service we're unable to monitor it's state using 
servicegroup API. Do we have alternatives here to make decision if particular 
workflow being processed by cinder-api is abandoned?

As this topic is deferred to Liberty release I want to start discussion here to 
be continued at the summit.

[1] https://review.openstack.org/#/c/147879/
[2] https://review.openstack.org/#/c/152200/
[3] https://etherpad.openstack.org/p/kilo-crossproject-ha-integration

__
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

__
Disclaimer: This email and any attachments are sent in strictest confidence
for the sole use of the addressee and may contain legally privileged,
confidential, and proprietary data. If you are not the intended recipient,
please advise the sender by replying promptly to this email and then delete
and destroy this email and any attachments without any further use, copying
or forwarding.

__
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] Unshelve Instance Performance Optimization Questions

[Kekane, Abhishek]

Hi Devs,

Problem Statement: Performance and storage efficiency of shelving/unshelving 
instance booted from image is far worse than instance booted from volume.

When you unshelve hundreds of instances at the same time, instance spawning 
time varies and it mainly depends on the size of the instance snapshot and
the network speed between glance and nova servers.

If you have configured file store (shared storage) as a backend in Glance for 
storing images/snapshots, then it's possible to improve the performance of
unshelve instance dramatically by configuring nova.image.download.FileTransfer 
in nova. In this case, it simply copies the instance snapshot as if it is
stored on the local filesystem of the compute node. But then again in this 
case, it is observed the network traffic between shared storage servers and
nova increases enormously resulting in slow spawning of the instances.

I would like to gather some thoughts about how we can improve the performance 
of unshelve api (booted from image only) in terms of downloading large
size instance snapshots from glance.

I have proposed a nova-specs [1] to address this performance issue. Please take 
a look at it.

During the last nova mid-cycle summit, Michael 
Stillhttps://review.openstack.org/#/q/owner:mikal%2540stillhq.com+status:open,n,z
 has suggested alternative solutions to tackle this issue.

Storage solutions like ceph (Software based) and NetApp (Hardare based) support 
exposing images from glance to nova-compute and cinder-volume with
copy in write feature. This way there will be no need to download the instance 
snapshot and unshelve api will be pretty faster than getting it
from glance.

Do you think the above performance issue should be handled in the OpenStack 
software as described in nova-specs [1] or storage solutions like
ceph/NetApp should be used in production environment? Apart from ceph/NetApp 
solutions, are there any other options available in the market.

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

Thank You,

Abhishek Kekane

__
Disclaimer: This email and any attachments are sent in strictest confidence
for the sole use of the addressee and may contain legally privileged,
confidential, and proprietary data. If you are not the intended recipient,
please advise the sender by replying promptly to this email and then delete
and destroy this email and any attachments without any further use, copying
or forwarding.__
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] [python-cinderclient] Return request ID to caller

[Kekane, Abhishek]

Hi Devs,

This change is not backward compatible and to do not break OpenStack services 
which are using cinder-client,
we need to first make provision in these consumer services to handle 
cinder-client return type change.
To make this cinder-client change backward compatible we need to do changes in 
consumers of cinder-client like patch : https://review.openstack.org/#/c/152820/

Also for backward compatibility can we make changes suggested by Gary W. Smith 
on cinder-spec : https://review.openstack.org/#/c/132161/6/.
As per his suggestion we need to add one new optional kwarg 'return_req_id' in 
cinder-client api methods, when it is 'True' cinder-client will returns the 
tuple, but when False (the default) it returns the current value (i.e.- only 
response body).

For example cinder-client 'get' method will look like -

def _get(self, url, response_key=None, return_req_id=False):
resp, body = self.api.client.get(url)
if response_key:
body = self.resource_class(self, body[response_key], loaded=True)
else:
body = self.resource_class(self, body, loaded=True)

if return_req_id:
# return tuple containing headers and body
return (resp.headers, body)

return body


If we want headers from cinder-client then we need to pass kwarg 
'return_req_id' as True from caller.
For example from nova we need to call cinder-client get method as -

resp_header, volume = cinderclient(context).volumes.get(volume_id, 
return_req_id=True)


With this optional kwarg 'return_req_id' approach we do not need to make 
changes in services which are using cinder-client.
It will be backward compatible change.

Could you please give your suggestion on this approach.

Thanks,

Abhishek


From: Joe Gordon [mailto:joe.gord...@gmail.com]
Sent: 05 February 2015 22:50
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [python-cinderclient] Return request ID to caller



On Wed, Feb 4, 2015 at 11:23 PM, Malawade, Abhijeet 
abhijeet.malaw...@nttdata.commailto:abhijeet.malaw...@nttdata.com wrote:
Hi,

I have submitted patch for cinder-client [1] to 'Return tuple containing header 
and body from client' instead of just response.
Also cinder spec for the same is under review [2].

This change will break OpenStack services which are using cinder-client. To do 
not break services which are using cinder-client,
we need to first make changes in those projects to check return type of 
cinder-client. We are working on doing cinder-client return
type check changes in OpenStack services like nova, glance_store, heat, trove, 
manila etc.
We have already submitted patch for same against nova : 
https://review.openstack.org/#/c/152820/

[1] https://review.openstack.org/#/c/152075/
[2] https://review.openstack.org/#/c/132161/

This sounds like a backwards incompatible change to the python client, that 
will break downstream consumers of python-cinderclient. This change should be 
done in a way that allows us to deprecate the old usage without breaking it 
right away.


I want to seek early feedback from the community members on the above patches, 
so please give your thoughts on the same.

Thanks,
Abhijeet Malawade

__
Disclaimer: This email and any attachments are sent in strictest confidence
for the sole use of the addressee and may contain legally privileged,
confidential, and proprietary data. If you are not the intended recipient,
please advise the sender by replying promptly to this email and then delete
and destroy this email and any attachments without any further use, copying
or forwarding.

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


__
Disclaimer: This email and any attachments are sent in strictest confidence
for the sole use of the addressee and may contain legally privileged,
confidential, and proprietary data. If you are not the intended recipient,
please advise the sender by replying promptly to this email and then delete
and destroy this email and any attachments without any further use, copying
or forwarding.
__
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] Adding new features to Kilo and future releases - DB upgrades

[Kekane, Abhishek]

Hi devs,

With online schema changes/No downtime DB upgrades things would be much lot 
easier for OpenStack deployments.
Big kudos to Johannes who initiated this feature. But as a service provider, 
I'm curious to understand what is the development process of adding new 
features to Kilo and future releases once the online schema changes is in.


1.   Will the committer be responsible of adding new procedures of 
upgrading db with minimal or zero downtime? or the online schema changes 
framework itself will detect whatever db changes are required on its own and 
the decision to apply db changes online or offline will be left solely with the 
service provider?


2.   Is it possible to predict how much time it would take to upgrade db 
(expand/migrate/contract phases) for adding a new column, constraint.
For example, adding a new column with NULL constraint would 
take less time than adding a default value.


Please let us know your valuable opinions for the same.

Thank you,

Abhishek Kekane

__
Disclaimer: This email and any attachments are sent in strictest confidence
for the sole use of the addressee and may contain legally privileged,
confidential, and proprietary data. If you are not the intended recipient,
please advise the sender by replying promptly to this email and then delete
and destroy this email and any attachments without any further use, copying
or forwarding.__
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] request spec freeze exception for Improving performance of unshelve-api

[Kekane, Abhishek]

Hi Devs,

Please consider my spec for spec freeze exception.

I am ready with the code and also submitted the patches for review on community 
gerrit.

Nova-specs: https://review.openstack.org/#/c/135387/

Nova: https://review.openstack.org/#/c/147078/

Tempest: https://review.openstack.org/#/c/147079/

Please review the specs and let me know your valuable suggestions.


Thank you,

Abhishek Kekane
From: Kekane, Abhishek [mailto:abhishek.kek...@nttdata.com]
Sent: 08 January 2015 19:57
To: OpenStack Development Mailing List (openstack-dev@lists.openstack.org)
Subject: [openstack-dev] [nova] request spec freeze exception for Improving 
performance of unshelve-api

Hi Devs,

I have submitted a nova-spec [1] for improving the performance of unshelve-api.

The aim of this feature is to improve the performance of unshelve instance by 
eliminating downloading/copying snapshot time.
All instance files will be retained in the instance store backed by shared or 
non-shared storage on the compute node when an instance is shelved.

Please review this spec, and consider this spec for request spec freeze 
exception.

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

Thank You,

Abhishek Kekane

__
Disclaimer: This email and any attachments are sent in strictest confidence
for the sole use of the addressee and may contain legally privileged,
confidential, and proprietary data. If you are not the intended recipient,
please advise the sender by replying promptly to this email and then delete
and destroy this email and any attachments without any further use, copying
or forwarding.

__
Disclaimer: This email and any attachments are sent in strictest confidence
for the sole use of the addressee and may contain legally privileged,
confidential, and proprietary data. If you are not the intended recipient,
please advise the sender by replying promptly to this email and then delete
and destroy this email and any attachments without any further use, copying
or forwarding.__
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] shelved_offload_time configuration

[Kekane, Abhishek]

Hi Joe,

Thanks for update.

I am working on nova-specs to improve the performance of unshelve api 
https://review.openstack.org/135387
In this spec, I am proposing not to take snapshot if shelved_offload_time is 
set to -2.

As of now the logic of creating the image is on the controller node, where I 
cannot take the decision whether to take snapshot or not as this 
shelved_offload_time is not exposed to controller node.

Please review the specs and let me know your suggestions on the same.

Thank You,

Abhishek Kekane

From: Joe Gordon [mailto:joe.gord...@gmail.com]
Sent: 07 January 2015 22:43
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Nova] shelved_offload_time configuration



On Mon, Dec 22, 2014 at 10:36 PM, Kekane, Abhishek 
abhishek.kek...@nttdata.commailto:abhishek.kek...@nttdata.com wrote:
Hi All,

AFAIK, for shelve api the parameter shelved_offload_time need to be configured 
on compute node.
Can we configure this parameter on controller node as well.

Not 100% sure what you are asking but hopefully this will clarify things: 
nova.conf files are read locally, so setting the value on a controller node 
doesn't affect any compute nodes.


Please suggest.

Thank You,

Abhishek Kekane

__
Disclaimer: This email and any attachments are sent in strictest confidence
for the sole use of the addressee and may contain legally privileged,
confidential, and proprietary data. If you are not the intended recipient,
please advise the sender by replying promptly to this email and then delete
and destroy this email and any attachments without any further use, copying
or forwarding.

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


__
Disclaimer: This email and any attachments are sent in strictest confidence
for the sole use of the addressee and may contain legally privileged,
confidential, and proprietary data. If you are not the intended recipient,
please advise the sender by replying promptly to this email and then delete
and destroy this email and any attachments without any further use, copying
or forwarding.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [nova] request spec freeze exception for Improving performance of unshelve-api

[Kekane, Abhishek]

Hi Devs,

I have submitted a nova-spec [1] for improving the performance of unshelve-api.

The aim of this feature is to improve the performance of unshelve instance by 
eliminating downloading/copying snapshot time.
All instance files will be retained in the instance store backed by shared or 
non-shared storage on the compute node when an instance is shelved.

Please review this spec, and consider this spec for request spec freeze 
exception.

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

Thank You,

Abhishek Kekane

__
Disclaimer: This email and any attachments are sent in strictest confidence
for the sole use of the addressee and may contain legally privileged,
confidential, and proprietary data. If you are not the intended recipient,
please advise the sender by replying promptly to this email and then delete
and destroy this email and any attachments without any further use, copying
or forwarding.___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Nova] shelved_offload_time configuration

[Kekane, Abhishek]

Hi All,

AFAIK, for shelve api the parameter shelved_offload_time need to be configured 
on compute node.
Can we configure this parameter on controller node as well.

Please suggest.

Thank You,

Abhishek Kekane

__
Disclaimer: This email and any attachments are sent in strictest confidence
for the sole use of the addressee and may contain legally privileged,
confidential, and proprietary data. If you are not the intended recipient,
please advise the sender by replying promptly to this email and then delete
and destroy this email and any attachments without any further use, copying
or forwarding.___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Glance][stable] Review request

[Kekane, Abhishek]

Hi All,
Greetings!!!

Can anyone please review this patch [1].
It requires one more +2 to get merged in stable/juno.

We want to use stable/juno in production environment and this patch will fix 
the blocker bug [1] for restrict download image feature.
Please do the needful.

[1] https://review.openstack.org/#/c/133858/
[2] https://bugs.launchpad.net/glance/+bug/1387973


Thank You in advance.

Abhishek Kekane

__
Disclaimer: This email and any attachments are sent in strictest confidence
for the sole use of the addressee and may contain legally privileged,
confidential, and proprietary data. If you are not the intended recipient,
please advise the sender by replying promptly to this email and then delete
and destroy this email and any attachments without any further use, copying
or forwarding.___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [glance][feature freeze exception] Proposal for using Launcher/ProcessLauncher for launching services

[Kekane, Abhishek]

Hi All,

Please give your support me for applying the  freeze exception for using 
oslo-incubator service framework in glance, based on the following blueprint:

https://blueprints.launchpad.net/glance/+spec/use-common-service-framework

I have ensured that after making these changes everything is working smoothly.

I have done the functional testing for following three scenarios:

1.   Enabled SSL and checked requests are processed by the Api service 
before and after SIGHUP signal

2.   Disabled SSL and  checked requests are processed by the Api service 
before and after SIGHUP signal

3.   I have also ensured reloading of the parameters like 
ilesystem_store_datadir, filesystem_store_datadirs are  working effectively 
after sending the SIGHUP signal.

To test 1st and 2nd I have created a python script which will send multiple 
requests to glance at a time and added a chron job to send a SIGHUP signal to 
the parent process.
I have tested above script for 1 hour and confirmed every request has been 
processed successfully.

Please consider this feature to be a part of Juno release.



Thanks  Regards,

Abhishek Kekane


From: Kekane, Abhishek [mailto:abhishek.kek...@nttdata.com]
Sent: 02 September 2014 19:11
To: OpenStack Development Mailing List (openstack-dev@lists.openstack.org)
Subject: [openstack-dev] [glance][feature freeze exception] Proposal for using 
Launcher/ProcessLauncher for launching services

Hi All,

I'd like to ask for a feature freeze exception for using oslo-incubator service 
framework in glance, based on the following blueprint:

https://blueprints.launchpad.net/glance/+spec/use-common-service-framework


The code to implement this feature is under review at present.

1. Sync oslo-incubator service module in glance: 
https://review.openstack.org/#/c/117135/2
2. Use Launcher/ProcessLauncher in glance: 
https://review.openstack.org/#/c/117988/


If we have this feature in glance then we can able to use features like reload 
glance configuration file without restart, graceful shutdown etc.
Also it will use common code like other OpenStack projects nova, keystone, 
cinder does.


We are ready to address all the concerns of the community if they have any.


Thanks  Regards,

Abhishek Kekane

__
Disclaimer:This email and any attachments are sent in strictest confidence for 
the sole use of the addressee and may contain legally privileged, confidential, 
and proprietary data. If you are not the intended recipient, please advise the 
sender by replying promptly to this email and then delete and destroy this 
email and any attachments without any further use, copying or forwarding

__
Disclaimer:This email and any attachments are sent in strictest confidence for 
the sole use of the addressee and may contain legally privileged, confidential, 
and proprietary data.  If you are not the intended recipient, please advise the 
sender by replying promptly to this email and then delete and destroy this 
email and any attachments without any further use, copying or forwarding___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [glance][feature freeze exception] Proposal for using Launcher/ProcessLauncher for launching services

[Kekane, Abhishek]

Hi  Erno,


I agree that we must document what all config parameters will be reloaded after 
SIGHUP signal is processed, that's the reason why we have added DocImpact tag 
to patch https://review.openstack.org/#/c/117988/. We will test what parameters 
are reloaded and report them to the Doc team.


Our use case:


We want to use SIGHUP signal to reload filesystem store related config 
parameters namely filesystem_store_datadir and filesystem_store_datadirs 
which are very crucial in the production environment especially for people 
using NFS. In case, the filesystem is approaching at full capacity, 
administrator can add more storage and configured it via the above parameters 
which will be taken into effect upon sending SIGHUP signal. Secondly, most of 
the OpenStack services uses service framework and it does handle reloading of 
configuration files via SIGHUP signal which glance cannot without this patch.


Thanks  Regards,


Abhishek Kekane


From: Kekane, Abhishek
Sent: Wednesday, September 03, 2014 9:39 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: RE: [openstack-dev] [glance][feature freeze exception] Proposal for 
using Launcher/ProcessLauncher for launching services

Hi All,

Please give your support me for applying the  freeze exception for using 
oslo-incubator service framework in glance, based on the following blueprint:

https://blueprints.launchpad.net/glance/+spec/use-common-service-framework

I have ensured that after making these changes everything is working smoothly.

I have done the functional testing for following three scenarios:

1.   Enabled SSL and checked requests are processed by the Api service 
before and after SIGHUP signal

2.   Disabled SSL and  checked requests are processed by the Api service 
before and after SIGHUP signal

3.   I have also ensured reloading of the parameters like 
ilesystem_store_datadir, filesystem_store_datadirs are  working effectively 
after sending the SIGHUP signal.

To test 1st and 2nd I have created a python script which will send multiple 
requests to glance at a time and added a chron job to send a SIGHUP signal to 
the parent process.
I have tested above script for 1 hour and confirmed every request has been 
processed successfully.

Please consider this feature to be a part of Juno release.



Thanks  Regards,

Abhishek Kekane


From: Kekane, Abhishek [mailto:abhishek.kek...@nttdata.com]
Sent: 02 September 2014 19:11
To: OpenStack Development Mailing List (openstack-dev@lists.openstack.org)
Subject: [openstack-dev] [glance][feature freeze exception] Proposal for using 
Launcher/ProcessLauncher for launching services

Hi All,

I'd like to ask for a feature freeze exception for using oslo-incubator service 
framework in glance, based on the following blueprint:

https://blueprints.launchpad.net/glance/+spec/use-common-service-framework


The code to implement this feature is under review at present.

1. Sync oslo-incubator service module in glance: 
https://review.openstack.org/#/c/117135/2
2. Use Launcher/ProcessLauncher in glance: 
https://review.openstack.org/#/c/117988/


If we have this feature in glance then we can able to use features like reload 
glance configuration file without restart, graceful shutdown etc.
Also it will use common code like other OpenStack projects nova, keystone, 
cinder does.


We are ready to address all the concerns of the community if they have any.


Thanks  Regards,

Abhishek Kekane

__
Disclaimer:This email and any attachments are sent in strictest confidence for 
the sole use of the addressee and may contain legally privileged, confidential, 
and proprietary data. If you are not the intended recipient, please advise the 
sender by replying promptly to this email and then delete and destroy this 
email and any attachments without any further use, copying or forwarding

__
Disclaimer:This email and any attachments are sent in strictest confidence for 
the sole use of the addressee and may contain legally privileged, confidential, 
and proprietary data.  If you are not the intended recipient, please advise the 
sender by replying promptly to this email and then delete and destroy this 
email and any attachments without any further use, copying or forwarding___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [glance] Use Launcher/ProcessLauncher in glance

[Kekane, Abhishek]

Hi All,

In current scenario we are not closing the original server socket, we are 
closing the duplicate socket.
Server socket will hold the connection until its time out from client side.

IMO, this behaviour is good in end-user's point of view, as user will not get 
error immediately.
It will wait until the requests time out and before this request time out 
completes, if SIGHUP signal is complete and service restarts completely then 
this request will get processed immediately.

This is what we feel good for the end-user, but we will like to hear the 
opinion of the community.

Thank You,

Abhishek Kekane

-Original Message-
From: stuart.mcla...@hp.com [mailto:stuart.mcla...@hp.com] 
Sent: 01 September 2014 21:25
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [glance] Use Launcher/ProcessLauncher in glance


I've been looking at the most recent patch for this 
(https://review.openstack.org/#/c/117988/).

I'm wondering what behaviour do folks feel is best in the following scenario?

1) an image download starts (download1)

2) send SIGHUP to glance-api

3) start another download (download2)

4) download1 completes

5) ?

I think there's a few potential options:

5a) The request for 'download2' is never accepted (in which case the service is 
'offline' on the node until all in-flight requests are completed).

5b) The request for 'download2' is killed when 'download1' completes and the 
service restarts (not much point in new SIGHUP behaviour)

5c) The request for 'download2' is accepted and completes using the existing 
process, but in this case the service potentially never restarts if new 
requests keep coming in

5d) A 'swift reload' type operation is done where the old processes are left 
alone to complete (download1 and download2 complete) but new parent (and child) 
processes are spun up to handle new requests ('download3'). The disadvantage 
here is some extra process accounting and potentially stray old code running on 
your system

(See http://docs.openstack.org/developer/swift/admin_guide.html#swift-orphans)

-Stuart


On Mon, Jul 28, 2014 at 8:12 AM, Tailor, Rajesh rajesh.tai...@nttdata.com
wrote:

 Hi All,

 I have submitted the patch Made provision for glance service to use 
 Launcher to the community gerrit.
 Pl refer: https://review.openstack.org/#/c/110012/

 I have also set the workflow to 'work in progress'. I will start 
 working on writing unit tests for the proposed changes, after positive 
 feedback for the same.

 Could you please give your comments on this.

 Could you also please suggest me whether to file a launchpad bug or a 
 blueprint,  to propose these changes in the glance project ?


Submitting to github.com/openstack/glance-specs would be best. Thanks.



 Thanks,
 Rajesh Tailor

 -Original Message-
 From: Tailor, Rajesh [mailto:rajesh.tai...@nttdata.com]
 Sent: Wednesday, July 23, 2014 12:13 PM
 To: OpenStack Development Mailing List (not for usage questions)
 Subject: Re: [openstack-dev] [glance] Use Launcher/ProcessLauncher in 
 glance

 Hi Jay,
 Thank you for your response.
 I will soon submit patch for the same.

 Thanks,
 Rajesh Tailor

 -Original Message-
 From: Jay Pipes [mailto:jaypi...@gmail.com]
 Sent: Tuesday, July 22, 2014 8:07 AM
 To: openstack-dev@lists.openstack.org
 Subject: Re: [openstack-dev] [glance] Use Launcher/ProcessLauncher in 
 glance

 On 07/17/2014 03:07 AM, Tailor, Rajesh wrote:
  Hi all,
 
  Why glance is not using Launcher/ProcessLauncher (oslo-incubator) 
  for its wsgi service like it is used in other openstack projects i.e.
  nova, cinder, keystone etc.

 Glance uses the same WSGI service launch code as the other OpenStack 
 project from which that code was copied: Swift.

  As of now when SIGHUP signal is sent to glance-api parent process, 
  it calls the callback handler and then throws OSError.
 
  The OSError is thrown because os.wait system call was interrupted 
  due to SIGHUP callback handler.
 
  As a result of this parent process closes the server socket.
 
  All the child processes also gets terminated without completing 
  existing api requests because the server socket is already closed 
  and the service doesn't restart.
 
  Ideally when SIGHUP signal is received by the glance-api process, it 
  should process all the pending requests and then restart the 
  glance-api service.
 
  If (oslo-incubator) Launcher/ProcessLauncher is used in glance then 
  it will handle service restart on 'SIGHUP' signal properly.
 
  Can anyone please let me know what will be the positive/negative 
  impact of using Launcher/ProcessLauncher (oslo-incubator) in glance?

 Sounds like you've identified at least one good reason to move to 
 oslo-incubator's Launcher/ProcessLauncher. Feel free to propose 
 patches which introduce that change to Glance. :)

  Thank You,
 
  Rajesh Tailor
  
  __ Disclaimer:This email and any attachments are 

[openstack-dev] [glance][feature freeze exception] Proposal for using Launcher/ProcessLauncher for launching services

[Kekane, Abhishek]

Hi All,

I'd like to ask for a feature freeze exception for using oslo-incubator service 
framework in glance, based on the following blueprint:

https://blueprints.launchpad.net/glance/+spec/use-common-service-framework


The code to implement this feature is under review at present.

1. Sync oslo-incubator service module in glance: 
https://review.openstack.org/#/c/117135/2
2. Use Launcher/ProcessLauncher in glance: 
https://review.openstack.org/#/c/117988/


If we have this feature in glance then we can able to use features like reload 
glance configuration file without restart, graceful shutdown etc.
Also it will use common code like other OpenStack projects nova, keystone, 
cinder does.


We are ready to address all the concerns of the community if they have any.


Thanks  Regards,

Abhishek Kekane

__
Disclaimer:This email and any attachments are sent in strictest confidence for 
the sole use of the addressee and may contain legally privileged, confidential, 
and proprietary data.  If you are not the intended recipient, please advise the 
sender by replying promptly to this email and then delete and destroy this 
email and any attachments without any further use, copying or forwarding___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Glance]: V2 api support for download_image policy?

[Kekane, Abhishek]

Hi All,

Can anyone let me know whether is download_image policy applicable only for V1 
api and not for V2 api?

Thanks  Regards,

Abhishek

__
Disclaimer:This email and any attachments are sent in strictest confidence for 
the sole use of the addressee and may contain legally privileged, confidential, 
and proprietary data.  If you are not the intended recipient, please advise the 
sender by replying promptly to this email and then delete and destroy this 
email and any attachments without any further use, copying or forwarding___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Cinder] Confusion about the respective use cases for volume's admin_metadata, metadata and glance_image_metadata

[Kekane, Abhishek]

Hi All,

For this purpose we have added a blueprint in cinder for Juno release.
https://blueprints.launchpad.net/cinder/+spec/restrict-uploading-volume-to-image

Here on the basis of property protection feature of glance we are restricting 
unintended user from creating image from volume.

To differentiate between core and custom properties we are adding new parameter 
in cinder.conf which will store core properties of the image.
glance_core_properties = 'container_format', 'disk_format',  'min_disk',  
'min_ram', 'name', 'size'

Please share your thoughts on the same.

Thanks,

Abhishek



-Original Message-
From: Day, Phil [mailto:philip@hp.com] 
Sent: Thursday, May 22, 2014 1:19 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Cinder] Confusion about the respective use cases 
for volume's admin_metadata, metadata and glance_image_metadata

 -Original Message-
 From: Tripp, Travis S
 Sent: 07 May 2014 18:06
 To: OpenStack Development Mailing List (not for usage questions)
 Subject: Re: [openstack-dev] [Cinder] Confusion about the respective 
 use cases for volume's admin_metadata, metadata and 
 glance_image_metadata
 
  We're suffering from a total overload of the term 'metadata' here, 
  and there are
  3 totally separate things that are somehow becoming mangled
 
 Thanks for the summary. The term metadata definitely gets overloaded.
 I've been experimenting with the metadata to see what happens with 
 all of it.
 
OK I won't even try to bring Nova's three types of metadata into the discussion 
then.

 Glance image properties == ALL properties are copied to 
 volume_image_metadata in Cinder

Let's just limit this thread to this one, since that's the one that is partly 
mutable in Glance and becomes immutable in Cinder

 
 Regarding the property protections in Glance, it looks to use RBAC.  
 It seems to me that if a volume is being uploaded to glance with 
 protected properties and the user doing the copying doesn't have the 
 right roles to create those properties that Glance should reject the upload 
 request.
 
 Based on the etherpads, the primary motivation for property 
 protections was for an image marketplace, which doesn't seem like 
 there would be the same need for volumes.
No it is still needed.   Consider the case where there is a licensed image in 
Glance.   That license key, which will be passed through to the billing system 
has to be immutable and has to be availabe to Nova for any instance that is 
running a copy of that image.  Create a snapshot in Glance, the key needs to be 
there.  Create a bootable volume in Cinder, the key needs to be there, etc, 
etc.So both Nova and Cinder have to copy the Glance Image properties 
whenever they create a copy of an image.

The full set of paths where the image properties need to be copied are:

- When Cinder creates a bootable volume from an Image on Glance
- When Cinder creates a snapshot or copy of a bootable volume
- When Nova creates a snapshot in Glance from a running instance (So Nova has 
to have a copy of the properties of the image the instance was booted from - 
the image in Glance can be deleted while the instance is running)

The issue is that the set of Glance Image Properties that are copied need are a 
combination of muatable and immutable values - but that distinction is lost 
when they are copied into Cinder.  I'm not even sure if you can query Glance to 
find out if a property is mutable or not.

So to make Cinder and Glance consistent I think we would need:

1) A way to find out from Glance is a property is mutable or not
2) A way in Cinder to mark a property as mutable or immutable

I don't think Nova needs to know the difference, since it only ever creates 
snapshots in Glance - and Glance already knows what can and can't be changed.

Phil

 
  -Original Message-
  From: Duncan Thomas [mailto:duncan.tho...@gmail.com]
  Sent: Wednesday, May 07, 2014 7:57 AM
  To: OpenStack Development Mailing List (not for usage questions)
  Subject: Re: [openstack-dev] [Cinder] Confusion about the respective 
  use cases for volume's admin_metadata, metadata and 
  glance_image_metadata
 
  On 7 May 2014 09:36, Trump.Zhang zhangleiqi...@gmail.com wrote:
   @Tripp, Thanks for your reply and info.
  
   I am also thinking if it is proper to add support for updating the 
   volume's glance_image_metadta to reflect the newest status of
 volume.
  
   However, there may be alternative ways to achieve it:
   1. Using the volume's metatadata
   2. Using the volume's admin_metadata
  
   So I am wondering which is the most proper method.
 
 
  We're suffering from a total overload of the term 'metadata' here, 
  and there are
  3 totally separate things that are somehow becoming mangled:
 
  1. Volume metadata - this is for the tenant's own use. Cinder and 
  nova don't assign meaning to it, other than treating it as stuff the 
  tenant can set. It is entirely 

[openstack-dev] [Cinder]Persistance layer for cinder create_volume api + taskflow

[Kekane, Abhishek]

Hello Everyone,



Currently NTT Data team is working on adding persistence layer for 
create_volume api using taskflow.



I have added new section Cinder create_volume api + taskflow persistance  in 
etherpad https://etherpad.openstack.org/p/taskflow-cinder to with the issues 
while resuming the taskflows,

which we wanted to bring to the notice of the community in order to seek 
suggestions for fixing some of these issues.



Please have a look and let me know your suggestions on the same.



Thanks  Regards,



Abhishek Kekane

NTT DATA






__
Disclaimer:This email and any attachments are sent in strictest confidence for 
the sole use of the addressee and may contain legally privileged, confidential, 
and proprietary data.  If you are not the intended recipient, please advise the 
sender by replying promptly to this email and then delete and destroy this 
email and any attachments without any further use, copying or forwarding___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev