Re: [openstack-dev] [heat] Rico Lin for heat-core

[Manickam, Kanagaraj]

+1.

From: Sergey Kraynev [mailto:skray...@mirantis.com]
Sent: Monday, December 07, 2015 6:09 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [heat] Rico Lin for heat-core

Hi all.

I'd like to nominate Rico Lin for heat-core. He did awesome job with providing 
useful and valuable reviews. Also his contribution is really high [1] .

[1] http://stackalytics.com/report/contribution/heat-group/60

Heat core-team, please vote with:
 +1 - if you agree
  -1 - if you disagree

--
Regards,
Sergey.
__
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] [heat][infra] heat-templates dsvm gate

[Manickam, Kanagaraj]

From: Pavlo Shchelokovskyy [mailto:pshchelokovs...@mirantis.com]
Sent: Thursday, December 03, 2015 1:20 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [heat][infra] heat-templates dsvm gate

Hi all,

I would like to discuss how to fix and improve $subject, which targets to 
validate the templates present in the repo. Current state is the following:

the gate does merely validate the "parseability" of YAML/JSON templates and 
very basic check on template structure. Any other real checks as would be 
actually performed in real deployment are not executed because:
- only Heat and Keystone are installed on this gate;
- for resources for any other service service-based resource exposure kicks in 
early, producing "Service {name} does not have required endpoint in service 
catalog for the resource type {resource}" errors,


[Manickam, Kanagaraj]  ‘Service not available’ error could be handled once the 
ignore_erros options for validate template blueprint [3] is completed. Below 
command line option would help for it

heat template-validate –ignore-errors 990002 –f  

This helps to ignore the given errors and continue the validation of templates.



- which are ignored by the script running the validation (to not block the 
gate, bug 1492942)


[Manickam, Kanagaraj]  once blueprint [3] is implemented, this tool could be 
updated as mentioned above, which gives more validation control over existing 
logic.


Thus for example the check that properties of the resources are confirming to 
the schema of a particular resource is not performed, and we might be having 
faulty templates (e.g. with typos) in the repo. I hoped to fix this with 
mapping all resources to OS::Heat::None, but it turned out this would not be 
really helpful, as the None-resource has any property and attribute.

[Manickam, Kanagaraj] For unsupported resource types (not part of 
global-requirments.txt), we are currently masking with None resource.  for 
other resource types which does not have keystone endpoint in the gate, I think 
we ignore it in the tool. [4]

So I propose that heat-templates repo can configure its environment itself by 
using the "post_test_hook" facilities provided and supported by gate setup. We 
need that to better control the environment the tests are being run in. In 
particular, I'd like to add some fake service endpoints to Keystone, so 
service-based exposure is out of the validation way.

Thereby I ask Heat and Infra team to take a look at these two patches:
- [0] in heat-templates and
- [1] in project-config (depends on [0]).

Though these are simply moving couple of bash lines from project-config to 
heat-templates, we want to be sure they work so that we do not break the gate. 
Unfortunately I can not prove my further patches [2] are working as it seems 
Depend-On does not work for referencing project-config changes.

[0] https://review.openstack.org/#/c/252515/
[1] https://review.openstack.org/#/c/252523/
[2] 
https://review.openstack.org/#/q/status:open+project:openstack/heat-templates+branch:master+topic:bug/1492942,n,z
[3]  
https://blueprints.launchpad.net/heat/+spec/heat-template-validate-improvements
[4] 
https://github.com/openstack/heat-templates/blob/master/tools/validate-templates#L41

Best regards,
--
Dr. Pavlo Shchelokovskyy
Senior Software Engineer
Mirantis Inc
www.mirantis.com<http://www.mirantis.com>
__
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] [heat] Questions about BP for enable/disable heat-engine

[Manickam, Kanagaraj]

Ethan Lynn,

This blue-print has two parts , one to perform the graceful-shutdown to make 
sure all IN_PROGRESS resources/stacks in the given engine to reach its final 
state..
Other one, expose this feature as disable engine to support the maintenance.
I was planning to re-write the spec to provide the graceful shutdown only and 
remove the api part ( and requested to abandon this spec)
Please review the spec and please let me know, I will restore it and will work 
together to implement it. Thanks.

Regards
Kanagaraj M

-Original Message-
From: Sergey Kraynev [mailto:skray...@mirantis.com] 
Sent: Tuesday, November 10, 2015 5:51 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [heat] Questions about BP for enable/disable 
heat-engine

Ethan,

I can see, that it was assigned on Kanagaraj, but he is now in vacation (afaik).
Also corresponding patch with specification was abandoned by his request, so I 
suggest wait answer here or may be ping him in IRC directly on the next week.

On 8 November 2015 at 17:26, Ethan Lynn  wrote:
> Hi,
>   I notice that there is a BP for enable/disable heat-engine, 
> https://blueprints.launchpad.net/heat/+spec/heat-manage-service-disable-enable
>   This feature is important when maintain heat-engine in HA 
> production, if one controller node needs to be replaced, we can 
> disable heat-engine in this node and then replace this node.
>   I would like to know the reasons why this BP stops working, is there 
> any technical issues to implement it? I don’t quite understand the 
> issues raised by inc0, any one can explain it?
>   I would like to see this feature come into heat, and I would like to 
> pay some effort on it.
>
> Best Regards,
> Ethan Lynn
>
>
>
>
> __
>  OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



--
Regards,
Sergey.

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

Re: [openstack-dev] [Heat] core team nomination

[Manickam, Kanagaraj]

Congrats Rabi and Peter :)

-Original Message-
From: Sergey Kraynev [mailto:skray...@mirantis.com] 
Sent: Wednesday, October 21, 2015 12:57 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Heat] core team nomination

Rabi, Peter, my congradulations. You were elected by a unanimous vote :) I will 
add you to heat-core group. Enjoy and stay on this course ! :)

On 21 October 2015 at 09:45, Qiming Teng  wrote:
> +1 to both.
>
> Qiming
>
> On Tue, Oct 20, 2015 at 04:38:12PM +0300, Sergey Kraynev wrote:
>> I'd like to propose new candidates for heat core-team:
>> Rabi Mishra
>> Peter Razumovsky
>>
>> According statistic both candidate made a big effort in Heat as 
>> reviewers and as contributors [1][2].
>> They were involved in Heat community work  during last several 
>> releases and showed good understanding of Heat code.
>> I think, that they are ready to became core-reviewers.
>>
>> Heat-cores, please vote with +/- 1.
>>
>> [1] http://stackalytics.com/report/contribution/heat-group/180
>> [2] http://stackalytics.com/?module=heat-group=person-day
>> --
>> Regards,
>> Sergey.
>>
>> _
>> _ 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



--
Regards,
Sergey.

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

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

Re: [openstack-dev] [Heat] core team nomination

[Manickam, Kanagaraj]

+1 to both Rabi Mishra  & Peter Razumovsky. 

-Kanagaraj M

-Original Message-
From: Sergey Kraynev [mailto:skray...@mirantis.com] 
Sent: Tuesday, October 20, 2015 7:08 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [Heat] core team nomination

I'd like to propose new candidates for heat core-team:
Rabi Mishra
Peter Razumovsky

According statistic both candidate made a big effort in Heat as reviewers and 
as contributors [1][2].
They were involved in Heat community work  during last several releases and 
showed good understanding of Heat code.
I think, that they are ready to became core-reviewers.

Heat-cores, please vote with +/- 1.

[1] http://stackalytics.com/report/contribution/heat-group/180
[2] http://stackalytics.com/?module=heat-group=person-day
--
Regards,
Sergey.

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

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

Re: [openstack-dev] [Heat] conditional resource exposure - second thoughts

[Manickam, Kanagaraj]

Like to share my opinions as below:

Resource-type-list/resource-type-show:
Once the role based resource exposure is enabled, based on the user's 
role, I believe, (s)he would expect to see those deployed resource-types, which 
are authorized. And wanted to know if that resource-type is available currently 
on that cloud. So by default, it will essentially filter out those 
un-authorized resource-types from the users, but it will provide the additional 
information, whether resource-type is currently available or not. (admin has 
access to all resource-types). And resource-type-list could be enhanced further 
with additional filtering flag like :

'---show-authorized': default behavior
'--show-unavailable': list those authorized un-available resource-types
 '--show-available': list those authorized available resource-types
'--show-unauthorized': This may be wrong one, I too believe. But like to get 
others opinion on it. It list all the deployed resource-types, which are 
un-authorized. It  becomes like live resource-type documents from running heat 
service. (other place user may want to know the same details from the public 
resource-type document available in the internet) . But here, operators may 
want to disable to report the un-authorized resource-types to those user, who 
does not have right roles. So we could provide config parameter for the same. 
I'm not sure on it though !

Template-validate:
As it really helps user to validate the template, before starting the 
stack creation, it would be better to validate complete template and report all 
the errors in the template, which includes the unavailability of the service in 
the service catalog, authorization check as well. Currently, template-validate 
exit on the occurrence of first error in the template. (I'm working on it)

Regards
Kanagaraj M


-Original Message-
From: Zane Bitter [mailto:zbit...@redhat.com] 
Sent: Wednesday, July 15, 2015 1:05 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Heat] conditional resource exposure - second 
thoughts

On 14/07/15 14:34, Pavlo Shchelokovskyy wrote:
 Hi Heaters,

 currently we already expose to the user only resources for services 
 deployed in the cloud [1], and soon we will do the same based on 
 whether actual user roles allow creating specific resources [2]. Here 
 I would like to get your opinion on some of my thoughts regarding 
 behavior of resource-type-list, resource-type-show and 
 template-validate with this new features.

 resource-type-list
 We already (or soon will) hide unavailable in the cloud / for the user 
 resources from the listing. But what if we add an API flag e.g. --all 
 to show all registered in the engine resources? That would give any 
 user a glimpse of what their Orchestration service can manage in 
 principle, so they can nag the cloud operator to install additional 
 OpenStack components or give them required roles :)

I worry that this could result in leakage of potentially-sensitive information. 
e.g. once we have this feature implemented, an operator could deploy a plugin 
that is only for the use of one particular user, who has a custom role. I don't 
think it would be expected that other users (without that role) in other 
tenants could find out about that, even if all they can find out is the name of 
the resource type.

I definitely think that admins should have a way of getting a list of _all_ 
resource types (preferably annotated with the roles required to use them). Just 
not ordinary users.

 resource-type-show
 Right now the plan is to disable showing unavailable to the user 
 resources. But may be we should leave this as it is, for the same 
 purpose as above (or again add a --all flag or such)?

This is totally unnecessary IMHO for the reasons Clint mentioned. Again, I 
could imagine an exception for admins though, since I suspect that this API is 
the only way we can annotate resource types with the roles required without 
performing major surgery on resource-type-list.

 template-validate
 Right now Heat is failing validation for templates containing resource 
 types not registered in the engine (e.g. typo). Should we also make 
 this call available services- and roles-sensitive? Or should we leave 
 a way for a user to check validity of any template with any in 
 principle supported resources?

You call template-validate when you're about to launch the template and you 
want to know what parameters and stuff are required. If YOU cannot launch THIS 
template on THIS cloud right NOW it should fail, period.

cheers,
Zane.

 The bottom line is we are good in making Heat service to be as much 
 self-documented via its own API as possible - let's keep doing that 
 and make any Heat deployment to be the Heat primer :)

 Eager to hear your opinions.

 [1]
 http://specs.openstack.org/openstack/heat-specs/specs/liberty/conditio
 nal-resource-exposure-services.html

 [2]
 

[openstack-dev] [nova][heat] sqlalchemy-migrate tool to alembic

[Manickam, Kanagaraj]

Hi Nova team,

This mail is regarding an help required on the migration from
sqlalchemy migration tool  to alembic tool.


Heat is currently using sqlalchemy-migration tool and In liberty release,

we are investigating on how to bring the alembic into heat. We found that

nova has already tried the same (https://review.openstack.org/#/c/15196/ )

almost 2 years back and in Kilo release, nova is still using sqlalchemy

migration tool. 
(https://github.com/openstack/nova/tree/master/nova/db/sqlalchemy/migrate_repo/versions)



So we are assuming that, in nova, you might have faced blockers to bring in 
alembic.

And we would like to seek your  recommendation/suggestions based

on your experience on this.  This will help us to take proper direction

on using alembic in heat. Could you kindly share it.



Thanks in advance !

Regards,
Kanagaraj M
__
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] release note items ??

[Manickam, Kanagaraj]

Hi,

Is there any process we follow to create the release notes (ex: 
https://wiki.openstack.org/wiki/ReleaseNotes/Juno) for each release of 
OpenStack, by collection details across different projects in OpenStack.?

Regards
Kanagaraj M
__
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] [heat] Unknown resource OS::Heat::ScaledResource

[Manickam, Kanagaraj]

Hi,

I observed in one of the patch mentioned below, OS::Heat::ScaledResource is 
reported as unknown, could anyone help here to resolve the issue. Thanks.

http://logs.openstack.org/76/157376/8/check/check-heat-dsvm-functional-mysql/c9a1be3/logs/screen-h-eng.txt.gz
 reports OS::Heat::ScaledResource as unknown

Regards
Kanagaraj M


__
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] Module_six_moves_urllib_parse error

[Manickam, Kanagaraj]

Hi,

I see the below error in my devstack and is raised from the package 'six'

AttributeError: 'Module_six_moves_urllib_parse' object has no attribute 
'SplitResult'

Currently my devstack setup is having six 1.9.0 version. Could anyone help here 
to fix the issue? Thanks.

Regards
Kanagaraj M
__
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] Module_six_moves_urllib_parse error

[Manickam, Kanagaraj]

Thanks Michal. It helped me to get rid of the issue.

From: Dulko, Michal [mailto:michal.du...@intel.com]
Sent: Wednesday, February 25, 2015 4:49 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] Module_six_moves_urllib_parse error

Normally “apt-get remove python-six” helps.

From: Jordan Pittier [mailto:jordan.pitt...@scality.com]
Sent: Wednesday, February 25, 2015 12:08 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] Module_six_moves_urllib_parse error

Hi
You probably have an old python-six version installed system-wide.

Jordan

On Wed, Feb 25, 2015 at 11:56 AM, Manickam, Kanagaraj 
kanagaraj.manic...@hp.commailto:kanagaraj.manic...@hp.com wrote:
Hi,

I see the below error in my devstack and is raised from the package ‘six’

AttributeError: 'Module_six_moves_urllib_parse' object has no attribute 
'SplitResult'

Currently my devstack setup is having six 1.9.0 version. Could anyone help here 
to fix the issue? Thanks.

Regards
Kanagaraj M

__
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

__
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] Zuul failure

[Manickam, Kanagaraj]

Hi,

Following error is being reported by zuul and any one facing this issue ?

zuul is failing with No valid host was found. There are not enough hosts 
available  for https://review.openstack.org/#/c/153999/.
I tried twice to build this patch and same error is reported. I think this 
error is something to do with zuul test environment.

How to overcome this issue? Any help is appreciated . Thanks.

Regards
Kanagaraj M

__
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] Priority resizing instance on same host

[Manickam, Kanagaraj]

Hi,

There is a patch on resize https://review.openstack.org/#/c/117116/
To address the resize,  there are some suggestions and please refer the review 
comments on this patch.

Regards
Kanagaraj M

From: Jesse Pretorius [mailto:jesse.pretor...@gmail.com]
Sent: Thursday, February 12, 2015 1:25 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [nova] Priority resizing instance on same host

On Thursday, February 12, 2015, Rui Chen 
chenrui.m...@gmail.commailto:chenrui.m...@gmail.com wrote:
Currently, resizing instance cause migrating from the host that the 
instance run on to other host, but maybe the current host is suitable for new 
flavor. Migrating will lead to copy image between hosts if no shared storage, 
it waste time.
I think that priority resizing instance on the current host may be better 
if the host is suitable.
The logic like this:

if CONF.allow_resize_to_same_host:
filte current host
if suitable:
   resize on current host
else:
   select a host
   resize on the host

I don't know whether there have been some discussion about this question. 
Please let me know what do you think. If the idea is no problem, maybe I can 
register a blueprint to implement it.

But the nova.conf flag for that already exists?

What I would suggest, however, is that some logic is put in to determine 
whether the disk size remains the same while the cpu/ram size is changing - if 
so, then resize the instance on the host without the disk snapshot and copy.


--
Jesse Pretorius
mobile: +44 7586 906045
email: jesse.pretor...@gmail.commailto:jesse.pretor...@gmail.com
skype: jesse.pretorius

__
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] openstack/requirements failure

[Manickam, Kanagaraj]

Hi

In horizon I am trying to increase the python-heatclient=0.3.0 as part of the 
review https://review.openstack.org/#/c/154952/ and its failed with following 
error:


Requirement python-heatclient=0.3.0 does not match openstack/requirements 
value python-heatclient=0.2.9
More details at 
https://jenkins03.openstack.org/job/gate-horizon-requirements/110/console

Could anyone help me to resolve this issue? Thanks.

Regards
Kanagaraj M
__
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][horizon] Inter-project issue : redundant hyperviosr_hostname

[Manickam, Kanagaraj]

Hi,

Nova provides following REST API to get the details of instances provisioned in 
the given hypervisor.
REST API: /v2/​{tenant_id}​/os-hypervisors/​{hypervisor_hostname}​/servers
Ref: http://developer.openstack.org/api-ref-compute-v2-ext.html

This API is consumed in horizon to report hypervisor’s instances details under 
Admin-Hypervisors panel.
According to the above API, nova never should allow same ‘hypervisor_hostname’ 
for more than
one hypervisors, as ‘hypervisor_hostname’  used as identifier, but it allows. 
Due to this reason,
horizon reports invalid data.

So, this should be fixed on horizon, with the intention that, horizon should 
consume the API
provided by nova as it’s and reports correct information.  To address it, bug 
has been filed in horizon
at https://bugs.launchpad.net/horizon/+bug/1402572 (using work-around, it’s 
being fixed)

This could be fixed at the nova side as well by using ‘hypervisor.id’ as 
identifier instead of ‘hypervisor_hostname’
and use it in horizon and python-novaclient as well.

Now this issue  becomes inter-project related. And I’m looking for help to take 
it forward
to get fixed in kilo release. Could someone please help here?

Thanks
Kanagaraj M
__
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/requirements failure

[Manickam, Kanagaraj]

Thanks Ben Nemec. 
I have proposed the changes https://review.openstack.org/154989.

-Original Message-
From: Ben Nemec [mailto:openst...@nemebean.com] 
Sent: Wednesday, February 11, 2015 11:25 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] openstack/requirements failure

On 02/11/2015 11:33 AM, Manickam, Kanagaraj wrote:
 Hi
 
 In horizon I am trying to increase the python-heatclient=0.3.0 as part of 
 the review https://review.openstack.org/#/c/154952/ and its failed with 
 following error:
 
 
 Requirement python-heatclient=0.3.0 does not match openstack/requirements 
 value python-heatclient=0.2.9
 More details at 
 https://jenkins03.openstack.org/job/gate-horizon-requirements/110/console
 
 Could anyone help me to resolve this issue? Thanks.

Requirements changes have to be proposed to global requirements first.
There's a full explanation here:
http://git.openstack.org/cgit/openstack/requirements/tree/README.rst


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

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

Re: [openstack-dev] [horizon] system information panel, update with heat-engine status

[Manickam, Kanagaraj]

Hi,

I am waiting for the approval for K-3 as on the heat side, this functionality 
already implemented. Could some please approve
https://blueprints.launchpad.net/horizon/+spec/heat-engine-status-report

Thanks.

Regards
Kanagaraj M

From: Manickam, Kanagaraj
Sent: Thursday, February 05, 2015 11:13 PM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev][horizon] system information panel, update with 
heat-engine status

Hello Horizon Cores,

In K-2, Heat is enabled with new REST API to report the running heat-engine 
status, This is in-line with how nova reports nova-compute running status.
To report this feature in horizon under 'System information panel', a new 
blueprint is created at 
https://blueprints.launchpad.net/horizon/+spec/heat-engine-status-report

Can one of you kindly approve it to target in K release, so that admin can view 
the currently running Heat-engine's status from horizon.

Thanks.

Regards
Kanagaraj M
__
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] [horizon] system information panel, update with heat-engine status

[Manickam, Kanagaraj]

Hello Horizon Cores,

In K-2, Heat is enabled with new REST API to report the running heat-engine 
status, This is in-line with how nova reports nova-compute running status.
To report this feature in horizon under 'System information panel', a new 
blueprint is created at 
https://blueprints.launchpad.net/horizon/+spec/heat-engine-status-report

Can one of you kindly approve it to target in K release, so that admin can view 
the currently running Heat-engine's status from horizon.

Thanks.

Regards
Kanagaraj M
__
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] Get keystone auth token via Horizon URL

[Manickam, Kanagaraj]

From Horizon, you won’t be able to do keystone way of authentication.

From: Ed Lima [mailto:e...@stackerz.com]
Sent: Wednesday, October 15, 2014 8:30 AM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] Get keystone auth token via Horizon URL


I'm on the very early stages of developing an app for android to manage 
openstack services and would like to get the user credentials/tokens on 
keystone to get data and execute commands via the horizon URL. I'm using 
IceHouse on Ubuntu 14.04.

In my particular use case I have keystone running on my internal server 
http://localhost:5000/v3/auth/tokens; which would allow me to use my app fine 
with JSON to get information from other services and execute commands however 
I'd have to be on the same network as my server for it to work.

On the other hand I have my horizon URL published externally on the internet at 
the address https://openstack.domain.com/horizon; which is available from 
anywhere and gives me access to my OpenStack services fine via browser on a 
desktop. I'd like to do the same on android, would it be possible? Is there a 
way for my app to send JSON requests to horizon at 
https://openstack.domain.com/horizon and get the authentication tokens from 
keystone indirectly?

I should mention I'm not a very experienced developer and any help would be 
amazing! Thanks
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [nova-specs] WARNING: document isn't included in any toctree

[Manickam, Kanagaraj]

Hi,

I tried to add a spec under specs/kilo folder and got the following exception:

ERROR: InvocationError: 
'/home/jenkins/workspace/gate-nova-specs-docs/.tox/venv/bin/python setup.py 
build_sphinx'

http://logs.openstack.org/66/126866/1/check/gate-nova-specs-docs/c00edfe/console.html


Can anyone please help here to fix it.

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

Re: [openstack-dev] [nova-specs] WARNING: document isn't included in any toctree

[Manickam, Kanagaraj]

Hi Dims,

Thanks. I will move to approved folder.

Regards
Kanagaraj M

-Original Message-
From: Davanum Srinivas [mailto:dava...@gmail.com] 
Sent: Wednesday, October 08, 2014 5:07 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [nova-specs] WARNING: document isn't included in 
any toctree

Kanagaraj,

Drop it in specs/kilo/approved/ should work fine.

-- dims

On Wed, Oct 8, 2014 at 7:01 AM, Manickam, Kanagaraj kanagaraj.manic...@hp.com 
wrote:
 Hi,



 I tried to add a spec under specs/kilo folder and got the following
 exception:



 ERROR: InvocationError:
 '/home/jenkins/workspace/gate-nova-specs-docs/.tox/venv/bin/python 
 setup.py build_sphinx'



 http://logs.openstack.org/66/126866/1/check/gate-nova-specs-docs/c00ed
 fe/console.html





 Can anyone please help here to fix it.



 Regards

 Kanagaraj M


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




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

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

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

[openstack-dev] pycharm license?

[Manickam, Kanagaraj]

Hi,

Does anyone has pycharm license for openstack project development? Thanks.

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

Re: [openstack-dev] how to deploy juno devstack without multiple backend

[Manickam, Kanagaraj]

HP MSA is supported by cinder and use the following guidelines:
http://docs.openstack.org/trunk/config-reference/content/hp-msa-driver.html

you could install devstack and follow the above wiki or update the above 
defined HP MSA param as suggested by devstack at 
http://devstack.org/configuration.html

[[post-config|$NOVA_CONF]]
HERE ADD THE HP MSA CONFIG DETAILS.


From: Nikesh Kumar Mahalka [mailto:nikeshmaha...@vedams.com]
Sent: Tuesday, September 16, 2014 11:50 AM
To: openst...@lists.openstack.org; openstack-dev@lists.openstack.org
Subject: [openstack-dev] how to deploy juno devstack without multiple backend

 Hi,
I want to delploy a juno devstack without multiple backends.
I want only one backend different from lvm,say HP MSA.
Can any one tell me what to modify in local.conf  of devstack for this?
By default,it is enabling multiple lvm backends.
Also,if i want multiple backends different from lvm backends ,what to modify in 
local.conf?
i have gone through Devstack documentation,but it is not straightforward like 
openstack documentation.








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

[openstack-dev] [openstack][nova] Resize: allow_resize_to_same_host=True fails

[Manickam, Kanagaraj]

This mail is regarding the flag allow_resize_to_same_host=True in nova.conf.

Currently Nova allows to resize the instance across different host by default 
and it provides the flag allow_resize_to_same_host to set  to True, when 
resize is required to be tested in single host  environment.
But this flag could be useful in multi host environment, where cloud admin 
wants the resize to happen on the same host.  To support this scenario, I have 
submitted a patch https://review.openstack.org/#/c/117116/.

As part of this patch, reviewers suggested to use new variable called 
'force_resize_to_same_host' instead. So Would like to get more reviews on this 
one.

Could you please provide your +1/-1 on following choices:


1.Use the same flag 'allow_resize_to_same_host=True' with the above patch.

2.Use the new flag called 'force_resize_to_same_host' with 'True'

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

Re: [openstack-dev] [nova] Resize:allow_resize_to_same_host=True fails

[Manickam, Kanagaraj]

Updated the subject

From: Manickam, Kanagaraj
Sent: Wednesday, September 03, 2014 5:30 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [openstack][nova] Resize: 
allow_resize_to_same_host=True fails

This mail is regarding the flag allow_resize_to_same_host=True in nova.conf.

Currently Nova allows to resize the instance across different host by default 
and it provides the flag allow_resize_to_same_host to set  to True, when 
resize is required to be tested in single host  environment.
But this flag could be useful in multi host environment, where cloud admin 
wants the resize to happen on the same host.  To support this scenario, I have 
submitted a patch https://review.openstack.org/#/c/117116/.

As part of this patch, reviewers suggested to use new variable called 
'force_resize_to_same_host' instead. So Would like to get more reviews on this 
one.

Could you please provide your +1/-1 on following choices:


1.Use the same flag 'allow_resize_to_same_host=True' with the above patch.

2.Use the new flag called 'force_resize_to_same_host' with 'True'

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

Re: [openstack-dev] [nova] Bug: resize on same node with allow_resize_to_same_host=True

[Manickam, Kanagaraj]

Hi Jay,

I have summited a patch https://review.openstack.org/#/c/117116/ with same fix. 
But there are different opinions provided  this patch. 
Could you validate and provide your inputs on this patch. Thanks.

Regards
Kanagaraj M

-Original Message-
From: Jay Pipes [mailto:jaypi...@gmail.com] 
Sent: Thursday, August 14, 2014 9:39 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [nova] Bug: resize on same node with 
allow_resize_to_same_host=True

On 08/13/2014 11:50 PM, Manickam, Kanagaraj wrote:
 Hi,

 Nova provides a flag 'allow_resize_to_same_host' to resize the given 
 instance on the same hypervisor where it is currently residing. When 
 this flag is set to True, the nova.compute.api: resize() method does 
 not set the scheduler hint with 'force_nodes', where as its set the 
 'ignored_hosts' properly when this flag is set to False.

 So I have filed following defect to fix the logic when this flag is 
 set to True.

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

 I felt this defect is import to fix, when cloud admin wants the resize 
 to be happen on the same hypervisor (compute node). So could you 
 please let me know whether I can fix this for Juno-3? Thanks.

Hi Kanagaraj,

AFAICT, there is no bug here.

 if not CONF.allow_resize_to_same_host:
 filter_properties['ignore_hosts'].append(instance['host'])
 else:
 filter_properties['force_nodes'] = [instance['node']]

When allow_resize_to_same_host is True, then filter_properties['force_node'] 
will be set to a list with only one node (the compute node that the instance is 
currently on), and therefore the resize will happen on the original host.

Best,
-jay


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

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

[openstack-dev] [nova] Bug: resize on same node with allow_resize_to_same_host=True

[Manickam, Kanagaraj]

Hi,

Nova provides a flag 'allow_resize_to_same_host' to resize the given instance 
on the same hypervisor where it is currently residing. When this flag is set to 
True, the nova.compute.api: resize() method does not set the scheduler hint 
with 'force_nodes', where as its set the 'ignored_hosts' properly when this 
flag is set to False.

So I have filed following defect to fix the logic when this flag is set to True.
https://bugs.launchpad.net/nova/+bug/1356309

I felt this defect is import to fix, when cloud admin wants the resize to be 
happen on the same hypervisor (compute node). So could you please let me know 
whether I can fix this for Juno-3? Thanks.

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

Re: [openstack-dev] [Nova] Nominating Jay Pipes for nova-core

[Manickam, Kanagaraj]

+1

From: Christopher Yeoh [cbky...@gmail.com]
Sent: Thursday, July 31, 2014 3:13 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Nova] Nominating Jay Pipes for nova-core

On Wed, 30 Jul 2014 14:02:38 -0700
Michael Still mi...@stillhq.com wrote:

 Greetings,

 I would like to nominate Jay Pipes for the nova-core team.

 Jay has been involved with nova for a long time now.  He's previously
 been a nova core, as well as a glance core (and PTL). He's been around
 so long that there are probably other types of core status I have
 missed.

 Please respond with +1s or any concerns.



+1

 References:

   https://review.openstack.org/#/q/owner:%22jay+pipes%22+status:open,n,z

   https://review.openstack.org/#/q/reviewer:%22jay+pipes%22,n,z

   http://stackalytics.com/?module=nova-groupuser_id=jaypipes

 As a reminder, we use the voting process outlined at
 https://wiki.openstack.org/wiki/Nova/CoreTeam to add members to our
 core team.

 Thanks,
 Michael



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

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

[openstack-dev] Live update of openstack

[Manickam, Kanagaraj]

Hi,

This mail is generic to all openstack service and explained the problem with 
respect to heat here.

I have come across the situation where, updates are involved in the heat db 
model and corresponding code changes in the heat-engine component. Now assume 
that in a given deployment, there are two heat-engines and customer wants to 
update as follows:

1.   Run db sync and update the first heat-engine and restart the 
heat-engine

2.   Don't touch the second heat-engine.

In this scenario, first heat-engine will work properly as its updated with new 
db change done by the db sync. But second heat-engine is not updated and it 
will fail. To address this problem, would like to know if any other service 
came across the same scenario and a solution is already provided? Thanks.

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

[openstack-dev] [heat]Heat Db Model updates

[Manickam, Kanagaraj]

I have gone thru the Heat Database and found the drawbacks in the existing 
model as listed below.  Could you review and add anything missing here. Thanks.

Heat Database model is having following drawbacks:
1.   Duplicate information
2.   Incomplete naming of columns
3.   Inconsistency in the identifiers (id) and deleted_at columns across 
the tables
4.   resource table is specific to nova and make it generic
5.   Pre-defined constants are not using enum.

And the section provided below describes these problem on  table vice.

Stack
Duplicate info
Tenant  stack_user_project_id
Credentials_id  username , owner_id.
Tenant is also part of user_creds and Stack always has credentials_id,  so what 
is the need of having tenant info in stack table and in stack table only the 
credentials_id is sufficient.

Status  action should be enum of predefined status

User_creads
correct the spelling in Truststore_id

Resource
Status  action should be enum of predefined status
Rsrc_metadata - make full name resource_metadata
Why only nova_instance column how about for other services like cinder, glance 
resource, could be renamed to be generic enough??

Watch_rule
Last_evaluated - append _at
State should be an enum

Event
Why uuid and id both used?
Resource_action is being used in both event and resource table, so it should be 
moved to common table
Resource_status should be any enum



Regards
Kanagaraj M

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

Re: [openstack-dev] [heat]Heat Db Model updates

[Manickam, Kanagaraj]

Hi Zane,

Please find inline answer.

Regards
Kanagaraj M

-Original Message-
From: Zane Bitter [mailto:zbit...@redhat.com] 
Sent: Thursday, July 17, 2014 10:01 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [heat]Heat Db Model updates

On 16/07/14 23:48, Manickam, Kanagaraj wrote:
 I have gone thru the Heat Database and found the drawbacks in the 
 existing model as listed below.  Could you review and add anything 
 missing here. Thanks.

 Heat Database model is having following drawbacks:

 1.Duplicate information

 2.Incomplete naming of columns

 3.Inconsistency in the identifiers (id) and deleted_at columns across 
 the tables

 4.resource table is specific to nova and make it generic

 5.Pre-defined constants are not using enum.

 And the section provided below describes these problem on  table vice.

 *Stack*

 Duplicate info

 Tenant  stack_user_project_id

These are different things; stack_user_project_id is the project/tenant in 
which Heat creates users (in a different domain); tenant is the 
project/tenant in which the stack itself was created.


KanagarajM  


 Credentials_id  username , owner_id.

 Tenant is also part of user_creds and Stack always has credentials_id, 
 so what is the need of having tenant info in stack table and in stack 
 table only the credentials_id is sufficient.

tenant is in the Stack table because we routinely query by tenant and we don't 
want to have to do a join.

There may be a legitimate reason for the UserCreds table to exist separately 
from the Stack table but I don't know what it is, so merging the two is an 
option. 

Kanagaraj M user_creds are being consumed by stack only and I feel that for 
one user say 'admin1' there will be one row in user_Creds table and who can 
have more than one stacks owned. I assumed this could be the reason. 
But to validate,  I created two stacks with same user and for each stack, a 
seprate row is created. So as you suggested, I also feel that stack and 
user_creds could be merged if there is no other fact. And it will remove the 
redundancy too.

 Status  action should be enum of predefined status

+1. I assume it is still easy to add more actions later?

 *User_creads*

 correct the spelling in Truststore_id

trustor_user_id is correct.

Kanagaraj M sure.

 *Resource*

 Status  action should be enum of predefined status

+1

 Rsrc_metadata - make full name resource_metadata

-0. I don't see any benefit here.

KanagarajM  It is to just make consistency in naming format 

 Why only nova_instance column how about for other services like 
 cinder, glance resource, could be renamed to be generic enough??

+1 this should have been called physical_resource_id.

 *Watch_rule*

 Last_evaluated - append _at

I really don't see the point.

KanagarajM  It is to just make consistency in naming format when we say 
created_at, updated_at and so last_evaluated_at. 

 State should be an enum

+1

 *Event*

 Why uuid and id both used?

I believe it's because you should always use an integer as the primary key. I'm 
not sure if it makes a difference even though we _never_ do a lookup by the 
(integer) id.

Kanagaraj M In openstack, most of the services migrated from using INT to UUID 
for the primary key.  And more than that, it would be nice to make consistency. 
The reason is, when the user access the resource over REST API, if we use UUID 
for the all the entities used in the heat project, it will make user/developer 
experience easier.

 Resource_action is being used in both event and resource table, so it 
 should be moved to common table

I'm not sure what this means. Do you mean a common base class?

KanagarajM  Yes, its an implementation specific and have a common python base 
class.


 Resource_status should be any enum

+1

cheers,
Zane.

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

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

Re: [openstack-dev] [Cinder] Integrated with iSCSI target Question

[Manickam, Kanagaraj]

I think, It should be on the cinder node which is usually deployed on the 
controller node

From: Johnson Cheng [mailto:johnson.ch...@qsantechnology.com]
Sent: Thursday, July 17, 2014 10:38 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [Cinder] Integrated with iSCSI target Question

Dear All,

I have three nodes, a controller node and two compute nodes(volume node).
The default value for iscsi_helper in cinder.conf is tgtadm, I will change to 
ietadm to integrate with iSCSI target.
Unfortunately I am not sure that iscsitarget should be installed at controller 
node or compute node?
Have any reference?


Regards,
Johnson

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

[openstack-dev] [nova] tempest failure on image creation time out

[Manickam, Kanagaraj]

While building the patch in Jenkins, following exception reported in tempest.



2014-06-25 
19:09:19.009http://logs.openstack.org/82/92782/17/check/check-tempest-dsvm-full/8aa24c6/console.html#_2014-06-25_19_09_19_009
 |

2014-06-25 
19:09:19.010http://logs.openstack.org/82/92782/17/check/check-tempest-dsvm-full/8aa24c6/console.html#_2014-06-25_19_09_19_010
 | setUpClass 
(tempest.api.compute.images.test_list_image_filters.ListImageFiltersTestXML)

2014-06-25 
19:09:19.010http://logs.openstack.org/82/92782/17/check/check-tempest-dsvm-full/8aa24c6/console.html#_2014-06-25_19_09_19_010
 | 
---

2014-06-25 
19:09:19.010http://logs.openstack.org/82/92782/17/check/check-tempest-dsvm-full/8aa24c6/console.html#_2014-06-25_19_09_19_010
 |

2014-06-25 
19:09:19.010http://logs.openstack.org/82/92782/17/check/check-tempest-dsvm-full/8aa24c6/console.html#_2014-06-25_19_09_19_010
 | Captured traceback:

2014-06-25 
19:09:19.010http://logs.openstack.org/82/92782/17/check/check-tempest-dsvm-full/8aa24c6/console.html#_2014-06-25_19_09_19_010
 | ~~~

2014-06-25 
19:09:19.010http://logs.openstack.org/82/92782/17/check/check-tempest-dsvm-full/8aa24c6/console.html#_2014-06-25_19_09_19_010
 | Traceback (most recent call last):

2014-06-25 
19:09:19.010http://logs.openstack.org/82/92782/17/check/check-tempest-dsvm-full/8aa24c6/console.html#_2014-06-25_19_09_19_010
 |   File tempest/api/compute/images/test_list_image_filters.py, line 52, 
in setUpClass

2014-06-25 
19:09:19.010http://logs.openstack.org/82/92782/17/check/check-tempest-dsvm-full/8aa24c6/console.html#_2014-06-25_19_09_19_010
 | cls.server2['id'], wait_until='ACTIVE')

2014-06-25 
19:09:19.010http://logs.openstack.org/82/92782/17/check/check-tempest-dsvm-full/8aa24c6/console.html#_2014-06-25_19_09_19_010
 |   File tempest/api/compute/base.py, line 326, in 
create_image_from_server

2014-06-25 
19:09:19.010http://logs.openstack.org/82/92782/17/check/check-tempest-dsvm-full/8aa24c6/console.html#_2014-06-25_19_09_19_010
 | kwargs['wait_until'])

2014-06-25 
19:09:19.010http://logs.openstack.org/82/92782/17/check/check-tempest-dsvm-full/8aa24c6/console.html#_2014-06-25_19_09_19_010
 |   File tempest/services/compute/xml/images_client.py, line 140, in 
wait_for_image_status

2014-06-25 
19:09:19.011http://logs.openstack.org/82/92782/17/check/check-tempest-dsvm-full/8aa24c6/console.html#_2014-06-25_19_09_19_011
 | waiters.wait_for_image_status(self, image_id, status)

2014-06-25 
19:09:19.011http://logs.openstack.org/82/92782/17/check/check-tempest-dsvm-full/8aa24c6/console.html#_2014-06-25_19_09_19_011
 |   File tempest/common/waiters.py, line 143, in wait_for_image_status

2014-06-25 
19:09:19.011http://logs.openstack.org/82/92782/17/check/check-tempest-dsvm-full/8aa24c6/console.html#_2014-06-25_19_09_19_011
 | raise exceptions.TimeoutException(message)

2014-06-25 
19:09:19.011http://logs.openstack.org/82/92782/17/check/check-tempest-dsvm-full/8aa24c6/console.html#_2014-06-25_19_09_19_011
 | TimeoutException: Request timed out

2014-06-25 
19:09:19.011http://logs.openstack.org/82/92782/17/check/check-tempest-dsvm-full/8aa24c6/console.html#_2014-06-25_19_09_19_011
 | Details: (ListImageFiltersTestXML:setUpClass) Image 
49211f6e-8771-4e07-a581-901cda3ad45b failed to reach ACTIVE status within the 
required time (196 s). Current status: SAVING.


Any one facing this issue?

Ref: 
http://logs.openstack.org/82/92782/17/check/check-tempest-dsvm-full/8aa24c6/console.html

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

[openstack-dev] [nova] Jenkins failure ... nova-docs UNSTABLE

[Manickam, Kanagaraj]

Jenkins fails with following error (nova-docs UNSTABLE), could anyone help here 
to fix the issue. Thanks.

[cid:image001.png@01CF8F05.234979A0]


Log is located at 
http://logs.openstack.org/82/92782/14/check/gate-nova-docs/f04242e/console.html


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

[openstack-dev] [keystone]endpoint table is missing reference to region table

[Manickam, Kanagaraj]

Hi,

In keystone, though region table is provided, it is not consumed in the 
endpoint table. I have filed bug 
https://bugs.launchpad.net/keystone/+bug/1332196 to address the same.

Can anyone please provide details on, why this disconnect between endpoint and 
region table.

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

Re: [openstack-dev] [keystone]endpoint table is missing reference to region table

[Manickam, Kanagaraj]

A) Yes, we need to migrate.

B)  I have queries:

a.   Region is consumed only in the end-point object in keystone. So when 
an end point is created, keystone can go ahead and create a region in the 
“region” table if the region does not exist. Otherwise keystone can bind the 
existing region with the endpoint. This will make sure that endpoint is having 
foreign key reference to the region.  I see this as dynamic way of creating the 
region. Could you please validate the understanding and correct it, if required.

b.  In addition, The endpoint API request  response will be provided with 
“region” name as like today. So user does not get affected by this change.

Regards,
Kanagaraj M
From: Dolph Mathews [mailto:dolph.math...@gmail.com]
Sent: Friday, June 20, 2014 8:41 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [keystone]endpoint table is missing reference to 
region table

The region table is relatively new, and no one has stepped up to link the two 
together. A couple considerations:

A) a data migration will need to be performed to sync up the regions in the 
endpoint table with regions in the region table (populate those foreign keys, 
creating corresponding regions where necessary)

B) endpoints are created today without requiring a region to be created; this 
workflow will have to continue for v2 and v3 (regions need to be created 
dynamically)

On Thu, Jun 19, 2014 at 12:38 PM, Manickam, Kanagaraj 
kanagaraj.manic...@hp.commailto:kanagaraj.manic...@hp.com wrote:
Hi,

In keystone, though “region” table is provided, it is not consumed in the 
“endpoint” table. I have filed bug 
https://bugs.launchpad.net/keystone/+bug/1332196 to address the same.

Can anyone please provide details on, why this disconnect between endpoint and 
region table.

Thanks
Kanagaraj M

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

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

[openstack-dev] [nova] Set compute_node:hypervisor_nodename as unique and not null

[Manickam, Kanagaraj]

Hi,

This mail is regarding the required model change in nova. Please fine more 
details below:

As we knew, Nova db has the table compute_nodes for modelling the hypervisors 
and its using the hypervisor_hostname field to represent the hypervisor name.
This value is having significant value in os-hypervisor extension api which is 
using this field to uniquely identify the hypervisor.

Consider the case where a given environment is having more than one hypervisors 
(KVM, EXS, Xen, etc)  with same hostname and os-hypervisor and thereby Horizon 
Hypervisor panel and nova hypervisors-servers command will fail.
There is a defect (https://bugs.launchpad.net/nova/+bug/1329261)  already filed 
on VMware VC driver to address this issue to make sure that, a unique value is 
generated for the VC driver's hypervisor.  But its good to fix at the model 
level as well by  making hypervisor_hostname field as unique always. And a 
bug https://bugs.launchpad.net/nova/+bug/1329299 is filed for the same.

Before fixing this bug, I would like to get the opinion from the community. 
Could you please help here !

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

Re: [openstack-dev] New Pycharm License

[Manickam, Kanagaraj]

Hi Andrew,


Hi Andrew,

Can you please share a license key if I could use it for pycharm pro version.

Regards
Kanagaraj M

From: Andrew Melton [mailto:andrew.mel...@rackspace.com]
Sent: Thursday, September 26, 2013 8:41 AM
To: openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: [openstack-dev] New Pycharm License


Hey Devs,



It's almost been a year since I sent out the first email and I've been getting 
a few emails lately about alerts that the current license is about to expire. 
Well, I've got a hold of our new license, good for another year. This'll give 
you access to the new Pro edition of Pycharm and any updates for a year.



As this list is public, I can't email the license out to everyone, so please 
reply to this email and I'll get you the license.



Also, please note that if your current license expires, Pycharm will continue 
to work. You will just stop receiving updates until you've entered this new 
license.



Thanks,

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