Re: [Openstack] [Heat] Locked Outputs

[Steve Baker]

On 11/08/2013 06:07 AM, Andrew Plunk wrote:
> The problem I am trying to solve here is not to secure an output, but to 
> provide the ability to only display an output to an end user one time.
>
>> So it seems that the problem you are seeking to solve is limiting access
>> to sensitive outputs. The solution mentioned above certainly narrows
>> the attack surface, but it suffers from a DOS race condition where a
>> bad actor can lock you out of your own resource.
> Also, if an attacker is able to authenticate as your account, you have much 
> bigger problems than them locking you out of an output.
A non-malicious race condition would be launching your stack through
Horizon. Just clicking around will very quickly use up your one stack-show.

I would suggest either encryption like Clint suggested, or an extra
attribute to stack-show so that sensitive outputs are only returned when
explicitly asked for.

> Thanks.
> -Andrew
> 
> From: Clint Byrum [cl...@fewbar.com]
> Sent: Wednesday, November 06, 2013 8:36 PM
> To: openstack
> Subject: Re: [Openstack] [Heat] Locked Outputs
>
> Excerpts from Andrew Plunk's message of 2013-11-07 06:48:33 +0800:
>> Hello All,
>>
>> Imagine for a minute that you are displaying outputs from heat, but some of 
>> those outputs could have sensitive data (think passwords or private keys). 
>> It would be beneficial to allow outputs to be accessed once, and then go 
>> into a locked state. This could result in the following:
>>
> This is an interesting concept. I'd like to start with a problem
> statement though, as it is not clear what this is meant to solve.
>
>> 1). After an output is accessed for the first time, the output will become 
>> locked, and subsequent calls to the engine to return that output will return 
>> nothing.
>> example:
>>> show stack
>> "outputs": {
>>   "password": "password"
>>  }
>>
>>> show stack
>> "outputs": {
>> }
>>
>>
>> 2). Another option is after an output is accessed for the first time, the 
>> output will become locked, and subsequent calls to the engine will return 
>> the output with a flag saying that this output has been locked, allowing 
>> whatever is consuming that output to take the necessary action.
>> example:
>>
>>> show stack
>> "outputs": {
>>   "password": {
>> "value": "password",
>> "locked": false
>>   }
>> }
>>
>>> show stack
>> "outputs": {
>>   "password": {
>> "value": "password",
>> "locked": true
>>   }
>> }
>>
>>
>> The outputs section of the template for either case would could look like:
>> outputs:
>>   password:
>> value: { get_attr: [ some_resource, some_value ] }
>> description: The password
>> view_once: True
>>
> So it seems that the problem you are seeking to solve is limiting access
> to sensitive outputs. The solution mentioned above certainly narrows
> the attack surface, but it suffers from a DOS race condition where a
> bad actor can lock you out of your own resource.
>
> I have a different idea for that, which is to encrypt the output using
> public key cryptography.
>
> heat stack-create -f mytemplate.yaml -P PasswordRecipientKey="$(gpg
> --armor --print-key m...@foo.com)"
>
> And then have an output type of "Encrypted"
>
> Outputs:
>   Password:
> Type: Encrypted
> Keys:
>   - {Ref: PasswordRecipientKey}
>
> Now you can simply decrypt this with your local gpg key. heatclient
> could even automatically do this for you making it transparent as long
> as you have a gpg key agent running.
>
> ___
> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> Post to : openstack@lists.openstack.org
> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> ___
> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> Post to : openstack@lists.openstack.org
> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack


___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [Openstack] [Heat] Error - Template not in valid format

[Steve Baker]

On 11/01/2013 09:35 PM, Therese Persson wrote:
> Thank you for your answer Angus.
>
> I tried to remove the parameters from the file as you suggested and tried to 
> create a stack with horizon, but I seem to have an authorization problem.
...
> In my heat.conf file:
>
> [DEFAULT]
> connection = mysql://heat:heat@10.10.10.51/heat
>
> (Everything else is commented out.)
>
> In my /etc/heat/api-paste.conf file:
...
> # Auth middleware that validates token against keystone
> [filter:authtoken]
> paste.filter_factory = heat.common.auth_token:filter_factory
> auth_host = 10.10.10.51
> auth_port = 35357
> auth_protocol = http
> admin_tenant_name = service
> admin_user = heat
> admin_password = heat
This section is missing auth_uri, as per this doc fix:
https://review.openstack.org/#/c/55020/

As an aside, these values should not be set at all in api-paste.ini, but
instead they should be set in heat.conf, section [keystone_authtoken]
>
>
> -Original Message-
> From: Angus Salkeld [mailto:asalk...@redhat.com] 
> Sent: den 1 november 2013 00:52
> To: openstack@lists.openstack.org
> Subject: Re: [Openstack] [Heat] Error - Template not in valid format
>
> On 31/10/13 15:17 +, Therese Persson wrote:
>> Hi,
>>
>> I have recently upgraded to Havana and just started trying out Heat. I tried 
>> to launch a stack by using this template file:
>> https://github.com/openstack/heat-templates/blob/master/hot/servers_in_
>> existing_neutron_net.yaml
>>
>> However, I am not familiar with these type of files and I am not sure of 
>> what information I should add to the file to make it valid for Heat.
>> This is what my modified file looks like:
> Hi Therese,
>
> It's just yaml, so I sometimes head over to 
> http://yaml-online-parser.appspot.com/ and dump my template in there and 
> tells you what is wrong.
>
> Basically you are putting your parameter values in the wrong place.
>
> instead of:
> parameters:
>key_name: mykey
>  type: string
>  description: Name of keypair to assign to servers remove the "mykey" so 
> it is back to:
>
> parameters:
>key_name:
>  type: string
>  description: Name of keypair to assign to servers
>
>
> Then start the template like this:
>
> heat stack-create mystack 
> --template-file=/scripts/servers_in_existing_neutron_net.yaml -P 
> "key_name=mykey;image=Ubuntu;flavor=m1.small"
>
> Hope that helps
> -Angus
>
>> heat_template_version: 2013-05-23
>>
>> description: >
>>  HOT template to deploy two servers into an existing neutron tenant 
>> network and
>>  assign floating IP addresses to each server so they are routable from 
>> the
>>  public network.
>>
>> parameters:
>>  key_name: mykey
>>type: string
>>description: Name of keypair to assign to servers
>>  image: Ubuntu
>>type: string
>>description: Name of image to use for servers
>>  flavor: m1.small
>>type: string
>>description: Flavor to use for servers
>>  public_net_id: 55896cd0-040a-4e7b-8a92-cb27f32b4ad9
>>type: string
>>description: >
>>  ID of public network for which floating IP addresses will be 
>> allocated
>>  private_net_id: 3bd4e56f-1e8c-4316-8e59-a358016e9ef8
>>type: string
>>description: ID of private network into which servers get deployed
>>  private_subnet_id: f4bac2ea-b74d-47ef-a8b3-5969d60bfbba
>>type: string
>>description: ID of private sub network into which servers get 
>> deployed
>>
>> resources:
>>  server1:
>>type: OS::Nova::Server
>>properties:
>>  name: Server1
>>  image: { get_param: image }
>>  flavor: { get_param: flavor }
>>  key_name: { get_param: key_name }
>>  networks:
>>- port: { get_resource: server1_port }
>>
>>  server1_port:
>>type: OS::Neutron::Port
>>properties:
>>  network_id: { get_param: private_net_id }
>>  fixed_ips:
>>- subnet_id: { get_param: private_subnet_id }
>>
>>  server1_floating_ip:
>>type: OS::Neutron::FloatingIP
>>properties:
>>  floating_network_id: { get_param: public_net_id }
>>  port_id: { get_resource: server1_port }
>>
>>  server2:
>>type: OS::Nova::Server
>>properties:
>>  name: Server2
>>  image: { get_param: image }
>>  flavor: { get_param: flavor }
>>  key_name: { get_param: key_name }
>>  networks:
>>- port: { get_resource: server2_port }
>>
>>  server2_port:
>>type: OS::Neutron::Port
>>properties:
>>  network_id: { get_param: private_net_id }
>>  fixed_ips:
>>- subnet_id: { get_param: private_subnet_id }
>>
>>  server2_floating_ip:
>>type: OS::Neutron::FloatingIP
>>properties:
>>  floating_network_id: { get_param: public_net_id }
>>  port_id: { get_resource: server2_port }
>>
>> outputs:
>>  server1_private_ip:
>>description: IP address of server1 in private network
>>value: { get_attr: [ server1, first_address ] }
>>  server1_public_ip:
>>description: Floating IP address of server1 in public network
>>value: { get_attr: 

Re: [Openstack] Icehouse-2 development milestone available

[Steve Baker]

On 24/01/14 05:35, Thierry Carrez wrote:
> Hi everyone,
>
> The second milestone of the Icehouse development cycle, "icehouse-2" is
> now available for Keystone, Glance, Nova, Horizon, Neutron, Cinder,
> Ceilometer, Heat, and Trove.
>
> You can see the full list of new features and fixed bugs, as well as
> tarball downloads, at:
>
...
> https://launchpad.net/heat/icehouse/icehouse-2
...

Due to the length of the gate queue, the fix for this Critical heat bug
did not make it into icehouse-2:
https://bugs.launchpad.net/heat/+bug/1271190

To include the fix for this bug in your installed heat, please use this
git commit:
https://git.openstack.org/cgit/openstack/heat/commit/?id=a4cbd9cdb38ae38887323bad5dc434532bacee19

cheers

___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [Openstack] [Heat] ERROR: Unknown resource type OS::Heat::ScalingPolicy

[Steve Baker]

On 07/04/14 16:21, Nguyen Van Hiep wrote:
> Operating system:
>
> Distributor ID:Ubuntu
> Description:Ubuntu 12.04.4 LTS
> Release:12.04
> Codename:precise
>
> Heat version:
>
> heat-api2013.2.2-0ubuntu1~cloud0
> at-api-cfn  2013.2.2-0ubuntu1~cloud0
> heat-api-cloudwatch 2013.2.2-0ubuntu1~cloud0
> heat-common 2013.2.2-0ubuntu1~cloud0
> heat-engine 2013.2.2-0ubuntu1~cloud0
> python-heat 2013.2.2-0ubuntu1~cloud0
> python-heatclient   0.2.4-0ubuntu1~cloud0
>
> Content of template I used: https://gist.github.com/nvhbk16k53/10014468
>
> When I run command to create stack, I got an Error message:
>
> ERROR: Unknown resource Type : OS::Heat::ScalingPolicy
>
> has anyone suffer this error? How to fix it?
> I will highly appriciate for any help that you can provide.
> Thanks.
>
OS::Heat::ScalingPolicy is a new resource which will be in heat 2014.1.
Until your cloud is upgraded you will need to use
AWS::AutoScaling::ScalingPolicy, along with the other AWS autoscaling
resource types.
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [Openstack] HEAT and MySQL 5.6

[Steve Baker]

On 21/05/14 10:45, Clint Byrum wrote:
> Excerpts from Clint Dilks's message of 2014-05-20 14:30:40 -0700:
>> Hi,
>>
>> I seem to be hitting a known issue with HEAT MySQL 5.6 and UTF8
>>
>> ERROR: (OperationalError) (1071, 'Specified key was too long; max key
>> length is 767 bytes') 'CREATE INDEX ix_software_config_tenant ON
>> software_config (tenant)' ()
>>
>> So based off https://bugs.launchpad.net/heat/+bug/1316646 I have made the
>> following modifications to the heat database.
>>
>> mysql> alter table software_config modify column tenant varchar(64) NOT
>> NULL;
>>
>> mysql> CREATE INDEX ix_software_config_tenant ON software_config (tenant);
>>
>> Is reducing the size of the tenant column likely to cause issues later?
> No, in researching the issue, I found that all of these columns should be
> varchar(64). I seem to have lost track of the patches though. We should
> definitely fix this in juno, since MySQL 5.6 is starting to arrive in
> the distros.
>
Here we go https://review.openstack.org/#/c/92421/2

___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [Openstack] HEAT and MySQL 5.6

[Steve Baker]

On 21/05/14 16:28, Clint Dilks wrote:
> Hi
>
>
> Does anyone have any suggestions as to how I get a working heat
> database?
>
>
> As a follow up to this I ending up installing heat on another system
> with the default MySQL Server, mysql-server-5.1.73-3.el6_5.x86_64.
>
> It appears that 5.1 still has issues with the creation of indexes but
> reports it as a warning rather than an error. 
>
> When I looked at the tables generated there were definitely columns
> missing from my original heat database.
>
> Now I am at the point where all heat services start and commands like
> heat stack-list or heat stack-delete work, but creation fails.  The
> yaml file I am using appears valid if I run it through
> http://yaml-online-parser.appspot.com
>
> Currently I am out of ideas as to how to get HEAT working, any
> suggestions welcome.
>
> [root@comet ~]# nova net-list | awk '/ demo-net / { print $2}'
> 8faf95e8-5cc4-4369-9df1-3102928770a4
>
> [root@comet ~]# echo $NET_ID
> 8faf95e8-5cc4-4369-9df1-3102928770a4
>
>
> [root@comet ~]# heat stack-create -f test-stack.yml -P
> "ImageID=cirros-0.3.2-x86_64;NetID=$NET_ID" testStack
>
>
> 2014-05-21 16:05:20.633 33816 ERROR heat.engine.resource [-] CREATE :
> Server "server1" [717a33ef-8100-402c-8a62-a7bbf911391f] Stack
> "testStack" [2d8312d6-98d1-4c61-895a-5d169303bcc1]
> 2014-05-21 16:05:20.633 33816 TRACE heat.engine.resource Traceback
> (most recent call last):
> 2014-05-21 16:05:20.633 33816 TRACE heat.engine.resource   File
> "/usr/lib/python2.6/site-packages/heat/engine/resource.py", line 420,
> in _do_action
> 2014-05-21 16:05:20.633 33816 TRACE heat.engine.resource while not
> check(handle_data):
> 2014-05-21 16:05:20.633 33816 TRACE heat.engine.resource   File
> "/usr/lib/python2.6/site-packages/heat/engine/resources/server.py",
> line 545, in check_create_complete
> 2014-05-21 16:05:20.633 33816 TRACE heat.engine.resource return
> self._check_active(server)
> 2014-05-21 16:05:20.633 33816 TRACE heat.engine.resource   File
> "/usr/lib/python2.6/site-packages/heat/engine/resources/server.py",
> line 561, in _check_active
> 2014-05-21 16:05:20.633 33816 TRACE heat.engine.resource raise exc
> 2014-05-21 16:05:20.633 33816 TRACE heat.engine.resource Error:
> Creation of server Test server failed.
>
> [root@comet ~]# cat test-stack.yml
> heat_template_version: 2013-05-23
>
> description: Test Template
>
> parameters:
>   ImageID:
> type: string
> description: Image use to boot a server
>   NetID:
> type: string
> description: Network ID for the server
>
> resources:
>   server1:
> type: OS::Nova::Server
> properties:
>   name: "Test server"
>   image: { get_param: ImageID }
>   flavor: "m1.tiny"
>   networks:
>   - network: { get_param: NetID }
>
> outputs:
>   server1_private_ip:
> description: IP address of the server in the private network
> value: { get_attr: [ server1, first_address ] }
>
You can find out whether your issue is heat or not by running:
* heat resource-show  server1
  (look at the message in the status_reason)
* nova show 
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [Openstack] heat policy.json

[Steve Baker]

On 15/05/14 01:10, Benedikt Trefzer wrote:
> Hi all
>
> I like to disallow upload of heat templates by mentioning a template URL
>  in Horizon (and the same for the environment). This should be achieved
> with policy.json file since the functionality should also be disabled
> for api access.
> Anyone know where the entries in policy.json for heat are documented
> (what entries are available etc.) ?
> Anyone knows which entry I have to change ?
>
> Thanks and regards
>
> Benedikt
>
> PS: for glance image upload the solution is to add "set_image_location":
> "!", in glance/policy.json.
>
We don't currently have a policy option for disabling loading templates
via URL, but you could raise a launchpad bug to request this.

cheers

___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [Openstack] [Heat] Stack Lifetime, Signaling, and AutoScaling Groups

[Steve Baker]

On 18/06/14 05:47, Joe D'Andrea wrote:
> Hi, Zane! Thanks for all your responses.
>
> Regarding cfn-tools vs cloud-init, I'm starting out with Icehouse and no 
> prior cfn-tools usage to maintain. I will likely look toward cloud-init, 
> though Software Deployments + golden images sounds terrific.
>
If cloud-init config meets your needs then you should consider using it.
However keep in mind that cloud-init is boot-only configuration. This
means that any change to cloud-init config during a stack update will
result in your server resources being replaced with servers containing
the new cloud-init boot configuration.

If this behavior is not what you require then you should consider using
SoftwareConfig/SoftwareDeployment resources instead.

___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [Openstack] Heat-IceHouse, stack creation fails

[Steve Baker]

On 06/08/14 09:25, Parisa Heidari wrote:
> Hi,
> I am trying Heat - IceHouse but I cannot even create a tiny VM as explained in
> the documents
> (http://docs.openstack.org/icehouse/install-guide/install/apt/content/heat-verify.html).
> In Heat-engine log file, I saw that "stack-user-domain" ID is not set in the
> heat.conf file. So I modified heat.conf and added admin ID (the one defined
> when Keystone was installed and configured) and its name and password for
> stack_user_domain, stack_domain_admin, and stack_domain_admin_password,
> respectively. But still stack creation fails and I see in the logs that
> "ClientException: The server has either erred or is incapable of performing 
> the
> requested operation".
>
> What should be set in heat.conf as stack-user-domain and other corresponding
> variables? should I create a new domain for Heat and how?
>
> Many thanks,
> Parisa
>
It looks like you need to run the heat-keystone-setup-domain script and
copy the resulting snippet into heat.conf
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [Openstack] Heat-IceHouse, stack creation fails

[Steve Baker]

On 06/08/14 14:32, Anne Gentle wrote:
>
>
>
> On Tue, Aug 5, 2014 at 9:13 PM, Steve Baker  <mailto:sba...@redhat.com>> wrote:
>
> On 06/08/14 09:25, Parisa Heidari wrote:
>> Hi,
>> I am trying Heat - IceHouse but I cannot even create a tiny VM as 
>> explained in
>> the documents
>> 
>> (http://docs.openstack.org/icehouse/install-guide/install/apt/content/heat-verify.html).
>> In Heat-engine log file, I saw that "stack-user-domain" ID is not set in 
>> the
>> heat.conf file. So I modified heat.conf and added admin ID (the one 
>> defined
>> when Keystone was installed and configured) and its name and password for
>> stack_user_domain, stack_domain_admin, and stack_domain_admin_password,
>> respectively. But still stack creation fails and I see in the logs that
>> "ClientException: The server has either erred or is incapable of 
>> performing the
>> requested operation".
>>
>> What should be set in heat.conf as stack-user-domain and other 
>> corresponding
>> variables? should I create a new domain for Heat and how?
>>
>> Many thanks,
>> Parisa
>>
> It looks like you need to run the heat-keystone-setup-domain
> script and copy the resulting snippet into heat.conf
>
>
>
> Hi Steve, 
> Should that script be part of the install docs? Currently it just
> says to Create the heat_stack_user role.
>
> I can log a doc bug, just want to be clear what it is that's missing. 
>
We do have https://bugs.launchpad.net/heat/+bug/1326483 for the missing
man page.

For the doc bug, the heat installation instructions need to describe
when and how to run heat-keystone-setup-domain[1]
but actually for the icehouse release of heat the script is
create_heat_domain[2]

Having said all that, if the heat domain is not configured there is
fallback code which reverts to the Havana behaviour of requiring the
stack launching user be an admin, and _that_ may be the cause of
Parisa's error above.

[1]
http://git.openstack.org/cgit/openstack/heat/tree/bin/heat-keystone-setup-domain
[2]
http://git.openstack.org/cgit/openstack/heat/tree/tools/create_heat_domain?h=stable/icehouse
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [Openstack] upgrading heat from icehouse to juno

[Steve Baker]

On 20/10/14 16:04, Don Waterloo wrote:
After doing this upgrade (with a good chunk of data in the database 
that was created on icehouse), i'm running into a problem I'm 
wondering if anyone else has seen.


In particular, if i do a 'heat resource-list' on a stack that was 
created with icehouse, i get an error, which is below.


I'm not sure how to approach this, my assumption is there is some data 
in my database which is not formatted correctly, but 'which' data is 
the problem.


I turned on mysql logging, and all the queries function, so it is 
parsing something that comes back which is the problem. The below 
trace makes me thing some column is null or '' in the old, and is 
expected in the new.


Any suggestions as to where to look next?

  File "/usr/lib/python2.7/dist-packages/heat/engine/stack.py", line 
348, in __iter__

return iter(self.resources)
  File "/usr/lib/python2.7/dist-packages/heat/engine/stack.py", line 
159, in resources

self.t.resource_definitions(self).items())
  File "/usr/lib/python2.7/dist-packages/heat/engine/stack.py", line 
158, in 

for (name, data) in
  File "/usr/lib/python2.7/dist-packages/heat/engine/resource.py", 
line 191, in __init__

resource = stack.db_resource_get(name)
  File "/usr/lib/python2.7/dist-packages/heat/engine/stack.py", line 
190, in db_resource_get

self.context, self.id )
  File "/usr/lib/python2.7/dist-packages/heat/db/api.py", line 96, in 
resource_get_all_by_stack

return IMPL.resource_get_all_by_stack(context, stack_id)
  File "/usr/lib/python2.7/dist-packages/heat/db/sqlalchemy/api.py", 
line 263, in resource_get_all_by_stack

options(orm.joinedload("data")).all()
  File "/usr/lib/python2.7/dist-packages/sqlalchemy/orm/query.py", 
line 2300, in all

return list(self)
  File "/usr/lib/python2.7/dist-packages/sqlalchemy/orm/loading.py", 
line 73, in instances

rows = [process[0](row, None) for row in fetch]
  File "/usr/lib/python2.7/dist-packages/sqlalchemy/orm/loading.py", 
line 455, in _instance

populate_state(state, dict_, row, isnew, only_load_props)
  File "/usr/lib/python2.7/dist-packages/sqlalchemy/orm/loading.py", 
line 305, in populate_state

populator(state, dict_, row)
  File 
"/usr/lib/python2.7/dist-packages/sqlalchemy/orm/strategies.py", line 
169, in fetch_col

dict_[key] = row[col]
  File "/usr/lib/python2.7/dist-packages/sqlalchemy/sql/type_api.py", 
line 911, in process

return process_value(impl_processor(value), dialect)
  File "/usr/lib/python2.7/dist-packages/heat/db/sqlalchemy/types.py", 
line 37, in process_result_value

return loads(value)
  File "/usr/lib/python2.7/json/__init__.py", line 338, in loads
return _default_decoder.decode(s)
  File "/usr/lib/python2.7/json/decoder.py", line 366, in decode
obj, end = self.raw_decode(s, idx=_w(s, 0).end())
TypeError: expected string or buffer




The most likely culprit is a Json column which was added in the Juno 
cycle. My guess would be resource.properties_data.


Could you run an update query to set existing null 
resource.properties_data values to '{}'?


I've raised the following bug to track this:
https://bugs.launchpad.net/heat/+bug/1383505

If your update query works could you comment on the bug? The backported 
code fix will either make the Json type tolerate None, or add a new 
migration script.
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [Openstack] [openstack-dev] [Heat] Stack stuck in DELETE_IN_PROGRESS even though all resources are DELETE_COMPLETE

[Steve Baker]

On 22/10/14 11:56, Ken Thomas wrote:

Greetings all,

I'm using Heat from Icehouse and I'm hitting a problem that I'm hoping 
y'all can shed some light on.


I have no problems doing stack-create. I can watch the MySQL commands 
go by and see it happily update the stack table so that it eventually 
shows up as CREATE_COMPLETE. When I delete the stack, everything seems 
to be working fine.  I see the MySQL update that sets the stack to 
DELETE IN PROGRESS as well as the updates that sets my single resource 
to DELETE_COMPLETE... but I never see the final update to the stack 
table to set it to DELETE COMPLETE.


One very odd thing that I found in the MySQL logs (snippet below), is 
a query that includes that stack name but with an extra '*' character 
append to it. My stack is named 'xyzzy8' but notice the 'xzyzzy8*' in 
the constraint. That's not going to return anything and I'm wondering 
if that is what's preventing the final stack DELETE_COMPLTE update 
from happening?


There are no errors in the any of the heat logs.

Any guidance would be greatly appreciated!

Ken

SELECT stack.status_reason AS stack_status_reason, stack.created_at AS 
stack_created_at, stack.deleted_at AS stack_deleted_at, stack.action 
AS stack_action, stack.status AS stack_status, stack.id AS stack_id, 
stack.name AS stack_name, stack.raw_template_id AS 
stack_raw_template_id, stack.username AS stack_username, stack.tenant 
AS stack_tenant, stack.parameters AS stack_parameters, 
stack.user_creds_id AS stack_user_creds_id, stack.owner_id AS 
stack_owner_id, stack.timeout AS stack_timeout, stack.disable_rollback 
AS stack_disable_rollback, stack.stack_user_project_id AS 
stack_stack_user_project_id, stack.updated_at AS stack_updated_at

FROM stack
WHERE stack.deleted_at IS NULL AND (stack.tenant = 
'c6c488223aae4e97bf56dda8cef36b3b' OR stack.stack_user_project_id = 
'c6c488223aae4e97bf56dda8cef36b3b') AND stack.name = *'xyzzy8**' AND 
stack.owner_id = '9a3e56d7-0c10-4c1c-8c54-0e5580cee121'




(This is a usage question, so replying to the openstack list)

Seeing 'xzyzzy8*' is odd. I'm not aware of anything in the code which 
would cause this. It would be more useful for you to scan your 
heat-engine log for any errors occurring during the stack delete.
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [Openstack] [autoscaling][icehouse]

[Steve Baker]

On 04/03/15 00:00, Chinasubbareddy M wrote:

Hi,

Thanks for the blog , but I am  getting the below error while I am launching 
the stack as per the instructions.

StackValidationFailed: Unknown resource Type : OS::Nova::Server::Cirros

Assuming you ran the following, what version of python-heatclient do you 
have installed?

  heat stack-create simple -f simple.yaml -e environment.yaml


___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [Openstack] Heat SoftwareDeployment With Autoscaling

[Steve Baker]

On 21/06/15 15:27, Binan AL Halabi wrote:

Hi all,
I have this part of my Heat template:

# Autoscaling group definition
  auto-scaling-group:
type: OS::Heat::AutoScalingGroup
properties:
  min_size: 1
  max_size: 1
  resource:
type: OS::Nova::Server
properties:
  flavor: { get_param: flavor }
  image: { get_param: image }
  key_name: { get_param: key }
  networks:
- port: { get_resource: server_port }
  user_data_format: SOFTWARE_CONFIG
  software_config_transport: POLL_SERVER_HEAT

  deployment:
type: OS::Heat::SoftwareDeployment
properties:
  config:
get_resource: config
server: { get_attr: [auto-scaling-group, resource] } 
??

  input_values:
foo: fo
bar: ba
  signal_transport : CFN_SIGNAL

The SoftwareDeployment is applied to the servers in the autoscaling 
group. The question:  how i specify the server field in the 
SoftwareDeployment to refrence to the server in autoscaling group ?



The scaling resource in your auto-scaling-group needs to be a template 
resource instead of an OS::Nova::Server. The server and the deployment 
resource should be inside that template resource, ie


  auto-scaling-group:
type: OS::Heat::AutoScalingGroup
properties:
  min_size: 1
  max_size: 1
  resource:
type: server.yaml

server.yaml
===
parameters:
...
resources:
  server:
type: OS::Nova::Server
properties:
  flavor: { get_param: flavor }
  ...

  deployment:
type: OS::Heat::SoftwareDeployment
properties:
server: { get_resource: server }
  ...
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack