Re: [openstack-dev] [Heat] Use block_device_mapping_v2 for swap?

[TIANTIAN]

At 2015-08-28 21:48:11, "marios"  wrote:
>I am working with the OS::Nova::Server resource and looking at the tests
>[1], it should be possible to just define 'swap_size' and get a swap
>space created on the instance:
>
>  NovaCompute:
>type: OS::Nova::Server
>properties:
>  image:
>{get_param: Image}
>  ...
>  block_device_mapping_v2:
>- swap_size: 1
>
>When trying this the first thing I hit is a validation code nit that is
>already fixed @ [2] (I have slightly older heat) and I applied that fix.
>However, when I try and deploy with a Flavor that has a 2MB swap for
>example, and with the above template, I still end up with a 2MB swap.
>
>Am I right in my assumption that the above template is the equivalent of
>specifying --swap on the nova boot cli (i.e. should this work?)? I am
>working with the Ironic nova driver btw and when deploying using the
>nova cli using --swap works; has anyone used/tested this property
>recently? I'm not yet sure if this is worth filing a bug for yet.

>
--According to the codes of heat and novaclient, the above template is the 
equivalent of
   specifying --swap on the nova boot cli:
https://github.com/openstack/python-novaclient/blob/master/novaclient/v2/shell.py#L142-L146
https://github.com/openstack/heat/blob/master/heat/engine/resources/openstack/nova/server.py#L822-L831


But don't know much about nova, and not sure how does nova behave if specified 
different swap size on Flavor


and Bdm.


>thanks very much for reading! marios > >[1] 
>>https://github.com/openstack/heat/blob/a1819ff0696635c516d0eb1c59fa4f70cae27d65/heat/tests/nova/test_server.py#L2446
> >[2] 
>>https://review.openstack.org/#/q/I2c538161d88a51022b91b584f16c1439848e7ada,n,z
> > >__ 
>>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] OS::Neutron::Port fails to set security group by name, no way to retrieve group ID from Neutron::SecurityGroup

[TIANTIAN]

1) OS::Neutron::Port does not seem to recognize security groups by name

-- 
https://github.com/openstack/heat/blob/stable/kilo/heat/engine/resources/openstack/neutron/port.py#L303

https://github.com/openstack/heat/blob/stable/kilo/heat/engine/clients/os/neutron.py#L111
we can recognize group name 
2) OS::Neutron::SecurityGroup has no attributes so it can not return a security 
group ID  
-- 
https://github.com/openstack/heat/blob/stable/kilo/heat/engine/resources/openstack/neutron/neutron.py#L133
we can get the resource id (security group id) by function 
'get_resource'
So what do you want? And what's the problems?


At 2015-08-07 11:10:37, jason witkowski jwit...@gmail.com wrote:

Hey All,


I am having issues on the Kilo branch creating an auto-scaling template that 
builds a security group and then adds instances to it.  I have tried every 
various method I could think of with no success.  My issues are as such:


1) OS::Neutron::Port does not seem to recognize security groups by name  

2) OS::Neutron::SecurityGroup has no attributes so it can not return a security 
group ID


These issues combined find me struggling to automate the building of a security 
group and instances in one heat stack.  I have read and looked at every example 
online and they all seem to use either the name of the security group or the 
get_resource function to return the security group object itself.  Neither of 
these work for me.


Here are my heat template files:


autoscaling.yaml - http://paste.openstack.org/show/412143/

redirector.yaml - http://paste.openstack.org/show/412144/

env.yaml - http://paste.openstack.org/show/412145/



Heat Client: 0.4.1

Heat-Manage: 2015.1.1


Any help would be greatly appreciated.


Best Regards,


Jason
__
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] [ceilometer] Aodh has been imported, next steps

[TIANTIAN]

I'd agree with Angus.


在 2015-07-16 12:05:25，Angus Salkeld asalk...@mirantis.com 写道：

On Tue, Jun 30, 2015 at 6:09 PM, Julien Danjou jul...@danjou.info wrote:
On Mon, Jun 29 2015, Ildikó Váncsa wrote:

 I think removing options from the API requires version bump. So if we plan to
 do this, that should be introduced in v3 as opposed to v2, which should remain
 the same and maintained for two cycles (assuming that we still have this 
 policy
 in OpenStack). It this is achievable by removing the old code and relying on
 the new repo that would be the best, if not then we need to figure out how to
 freeze the old code.

This is not an API change as we're not modifying anything in the API.
It's just the endpoint *potentially* split in two. But you can also
merge them as they are 2 separate entities (/v2/alarms and /v2/*).
So there's no need for a v3 here.



Hi Julien,


I just saw this, and I am concerned this is going to kill Heat's gate (and 
user's templates).


Will this be hidden within the client so that as long as we have aodh enabled 
in our gate's devstack
this will just work?


-Angus
 

As the consensus goes toward removal, I'll work on a patch for that.

--
Julien Danjou
/* Free Software hacker
   http://julien.danjou.info */

__
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] PTL Candidacy

[TIANTIAN]

+1
I am very happy to work with you:)
At 2015-04-07 10:50:23, Steve Baker sba...@redhat.com wrote:
I'd like to announce my candidacy for the Heat PTL in Liberty.

As I was the PTL during Icehouse, this will be Heat's first rerun PTL 
under our convention for rotating leaders. Even if elected I would hope 
that we continue to find Heat PTL new-blood for future cycles.

Towards the end of the Kilo cycle we started to get some momentum on 
landing the changes required for the Convergence effort. The aim will be 
to get much of the first-phase features landing early in Liberty, and 
spend the rest of the cycle focusing on convergence features which 
provide the most user benefit.

There are important maintenance tasks in the Liberty cycle which will 
need continued effort, including functional/integration testing, content 
for the template-writer's guide, and general usability improvements.

It seems that our merge throughput would be higher if our existing 
review attention were more coordinated. Nova has had some success with 
priorities, and Swift works well with a PTL curated etherpad of 
suggested reviews. I'd like to discuss the options with other heat 
cores, and am currently suggesting something like the Swift approach.

As the Big Tent process continues to mature I'd like to ensure that Heat 
is well positioned to qualify for the appropriate tags as they are 
defined. Also it would be worth looking into whether there should be 
heat-related tags available for projects with sufficiently mature 
resource implementations.

I'll be continuing Heat's tradition of the leadership emerging from a 
shared consensus, leaving the PTL as a point of coordination within the 
project, and a point of communication to the greater ecosystem.

I look forward to the opportunity to do this!

Steve

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

[openstack-dev] Glance tests failed

[Tiantian Gao]

Hi stackers,

I found a error after run glance tests. One of them is:

==
ERROR: 
glance.tests.unit.test_store_image.TestStoreAddToBackend.test_bad_metadata_not_dict
--
_StringException: Traceback (most recent call last):
  File 
/home/jenkins/workspace/rebase-glance-master/glance/tests/unit/test_store_image.py,
line 788, in test_bad_metadata_not_dict
store.__str__().AndReturn(('hello'))
AttributeError: 'str' object has no attribute 'AndReturn'

==

The code around the traceback is:



def _bad_metadata(self, in_metadata):

store = self.mox.CreateMockAnything()
store.add(self.image_id, mox.IgnoreArg(), self.size).AndReturn(
(self.location, self.size, self.checksum, in_metadata))
store.__str__().AndReturn(('hello'))   AttributeError here.

self.mox.ReplayAll()

..
self.mox.VerifyAll()


I try these codes in python shell, and raised the same exception.

I inspect the source code of mox, find that  __str__() was defined as a
normal method. when we call store.__str__(), it will return a str object.
Of cause str doesn't have 'AndReturn' attribute.

That make me crazy, and what really confuse me is that jenkins is happy
with it.
Did I ignore somethings? Thanks in advance.

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