PatRock's profile - activity

I wrote a minimal example for a triggered ScalingGroup, but with the alarm_url is something wrong.

   heat_template_version: 2013-05-23

parameters:
  key:
    type: string
    default: demo-key
  flavor:
    type: string
    default: m1.small
  image:
    type: string
    default: cirros-0.3.2-x86_64
  network:
    type: string
    default: int-net1

resources:
  myServerGroup:
    type: OS::Heat::AutoScalingGroup
    properties:
      max_size: 5
      desired_capacity: 1
      min_size: 1
      resource:
        type: OS::Nova::Server
        properties:
          key_name: {get_param: key}
          image: {get_param: image}
          flavor: {get_param: flavor}
          networks: [ {network: {get_param: network}} ]

  scale_UP_policy:
    type: OS::Heat::ScalingPolicy
    properties:
      adjustment_type: change_in_capacity
      auto_scaling_group_id: { get_resource: myServerGroup }
      cooldown: 10
      scaling_adjustment: 1

outputs:
  UPscalingURL:
    value: {get_attr: [scale_UP_policy, alarm_url]}

The output is: http://controller:8000/v1/signal/arn%3Aopenstack%3Aheat%3A%3Aad948ee0c33749508d76b95f33e7e02d%3Astacks%2Ftest%2F9ec989d2-ce9d-4d73-be6c-06ba7702b60a%2Fresources%2Fscale_UP_policy?Timestamp=2014-09-22T09%3A27%3A52Z&SignatureMethod=HmacSHA256&AWSAccessKeyId=ec9371233baf46bd95b3150ff00f79d4&SignatureVersion=2&Signature=p0zVObaO5wMpniREfOrZs4jfFrCH9UIvfcCmHqG35vM%3D (http://controller:8000/v1/signal/arn%...)

I see that there is html-code in it ( %3A = ":" %2F = "/" ), but how can i fix this? And even when i change all the HTML code to the correct symbols the Link doesn't work.

So this morning I finished my Loadbalancing Test Template. Everything went well and the stack was created completely, but unfortunately something does quite not work as expected.

1) I added a floating IP resource for my pool, but the floating IP-Adresses weren't created.

  pool:
    type: OS::Neutron::Pool
    properties:
      protocol: HTTP
      monitors: [{get_resource: monitor}]
      subnet_id: {get_param: subnet}
      lb_method: ROUND_ROBIN
      vip:
        protocol_port: 80
  lb:
    type: OS::Neutron::LoadBalancer
    properties:
      protocol_port: 80
      pool_id: {get_resource: pool}

  lb_floating:
    type: OS::Neutron::FloatingIP
    properties:
      floating_network_id: {get_param: public}
      port_id: {get_attr: [pool, vip, port_id]}

public = the ID of my external Network 10.0.x.x and the subnet = the Subnet ID of my internal Network 196.0.x.x

All my instances were created in the internal Network, but nothing has a external IP.

Do I have to create an extra port-resource for the pool?

Update

Output of resource-show for the floating ip address:

+------------------------+-----------------------------------------...+
| Property               | Value                                   ...|
+------------------------+-----------------------------------------...+
| description            |                                         ...|
| links                  | http://controller:8004/v1/ad948ee0c33749...|
|                        | http://controller:8004/v1/ad948ee0c33749...|
| logical_resource_id    | lb_floating                             ...|
| physical_resource_id   | a3fd80f3-ec10-48fa-9d70-1c9f72bd0dcd    ...|
| required_by            |                                         ...|
| resource_name          | lb_floating                             ...|
| resource_status        | CREATE_COMPLETE                         ...|
| resource_status_reason | state changed                           ...|
| resource_type          | OS::Neutron::FloatingIP                 ...|
+------------------------+-----------------------------------------...+

Output of neutron floatingip-list

+--------------------------------------+-----------------+-------------------+-----------+
| id                                   | fixed_ip_address| floating_ip_address | port_id |
+--------------------------------------+-----------------+-------------------+-----------+
| 0f4640f6-a307-4d81-8302-d244c26812ff |              | 10.0.100.16|                     |
| 19659c84-0362-4a9c-bd22-5790257d4c82 |              | 10.0.100.21|                     |
| 26d19489-2760-42bb-adfc-d906cf6f7eb1 |              | 10.0.100.76|                     |
| 31749b21-6ce6-4f16-ae73-21382d0a5f69 |              | 10.0.100.18|                     |
| 41bb0da2-f58d-4cb2-8852-94c3d42da255 |              | 10.0.100.20|                     |
| 7c802527-7d26-42bd-ad65-b62a83934876 |              | 10.0.100.77|                     |
| a3fd80f3-ec10-48fa-9d70-1c9f72bd0dcd | 192.168.1.85 | 10.0.100.89| 1d287d0c-3e7a-4afa- |
|                                      |              |            | b58a-e80fd61118ed   |
| ac101ef7-447f-4db2-bfd4-23e428dd6b01 |              | 10.0.100.14|                     |
| aed67890-321f-4dab-a31b-1517363c4b20 |              | 10.0.100.22|                     |
| be562ec7-6a60-4a80-8ee5-93fa3efbba48 |              | 10.0.100.19|                     |
| c2754b98-3781-4d88-a504-d841cb212efb |              | 10.0.100.15|                     |
| d6c6a48f-3040-48a7-8bfc-56b2721b6efd |              | 10.0.100.17|                     |
| f040c26e-91b9-451c-97e7-07f8818deba8 |              | 10.0.100.12|                     |
| fd3b847e-76f0-4a8a-bbe0-287d70e3c4fb |              | 10.0.100.13|                     |
+--------------------------------------+--------------+------------+---------------------+

Unfortunately this doesn't seem to solve the problem :/ I changed the interval in the /etc/ceilometer/pipeline.yaml and restartet all ceilometer-services but it's still up to 10 minutes till the alarm triggers. I updated the question with the alarm-history

I have reset my vm-controller out of a snapshot, but i haven't changed any passwords manually. How can i controll that the passwords are still correct? commands like nova keypair-list are working.

My OpenStack worked completely fine for several days, but suddenly I can't create instance completely. I'm watching 3 logs (nova-api.log, keystone.log & neutron.log) at the time i create the instance and nothing appears. I got no clue what's wrong and just the error message from the instance console at the boot.

http://postimg.org/image/wx8wy0hu5/

Something that I noticed is that the token ttl is wrong. when I get a token via keystone token-get it's already expired 1 hour ago. I changed the expire time to 86400 seconds (24hours) so now the token expires in 22hours! so keystone uses a wrong time, but thats not reason for this error isn't it?

After 24min in the keystone.log

WARNING keystone.openstack.common.versionutils [-] Deprecated: keystone.middleware.core.XmlBodyMiddleware is deprecated as of Icehouse in favor of support for "application/json" only and may be removed in K.

New line in nova.log when I start another instance.

 WARNING keystoneclient.middleware.auth_token [-] Authorization failed for token

After one day off i got some messages in the logs when i try to create a instance via nova boot

nova-api.log

WARNING keystoneclient.middleware.auth_token [-] Authorization failed for token

keystone.log

WARNING keystone.common.wsgi [-] Authorization failed. The request you have made requires authentication. from 10.0.9.10

neutron.log

WARNING keystoneclient.middleware.auth_token [-] Authorization failed for token

10.0.9.10 is my controller. So i see that i can't get authenticate, I just don't know why. Could there be something wrong with my openstack.rc file?

think i found something in nova-scheduler.log

WARNING nova.scheduler.host_manager [req-02dd9235-49e0-47d3-96e5-d53f31982d1c a9ed4eb9161244bdb9306f589f301e08 ad948ee0c33749508d76b95f33e7e02d] Host has more disk space than database expected (4gb > -33gb)

my dashboard says under hypervisions that 40GB from 14GB is used. All 40 are on the compute2 node. How can this be possible when the node only has 7GB of storage? Is something wrong with the database?

I have a complete loadbalanced ScalingGroup, but the time it takes to create or delete a new instance takes 10 minutes.

   Policy:
     type: OS::Heat::ScalingPolicy
     properties:
       adjustment_type: change_in_capacity
       auto_scaling_group_id: {get_resource: myServer_Group}
       cooldown: 30
       scaling_adjustment: 1

   Alarm:
     type: OS::Ceilometer::Alarm
     properties:
       meter_name: cpu_util
       statistic: avg
       period: 30
       evaluation_periods: 1
      threshold: 50
    alarm_actions:
     - {get_attr: [Policy, alarm_url]}
    comparison_operator: gt

So I set the Policy Cooldown to 30seconds and the period of the alarm also to 30seconds. I keep my Instance at 90% CPU so that the alarm should trigger within the first (or second) Period. Why does it stil take 10 minutes to trigger?

I hope that someone can explain me this events and thanks to everyone who help me with my Questions.

 ceilometer alarm-history -a 5507767f-1b31-461d-a6c1-9a855ebbdbb0

 +------------------+----------------------------+--------------------------------------------+
 | Type             | Timestamp                  | Detail                                     |
 +------------------+----------------------------+--------------------------------------------+
 | creation         | 2014-10-02T12:53:02.986000 | name: Scal-cpu_alarm_HIGH-zjhgpr3ct2qy     |
 |                  |                            | type: threshold                            |
 |                  |                            | rule: cpu_util > 50.0 during 1 x 60s       |
 | state transition | 2014-10-02T13:03:35.944000 | state: alarm                               |
 | state transition | 2014-10-02T13:05:35.942000 | state: insufficient data                   |
 | state transition | 2014-10-02T13:13:36.008000 | state: alarm                               |
 | state transition | 2014-10-02T13:15:36.004000 | state: insufficient data                   |
 +------------------+----------------------------+--------------------------------------------+

Unfortunately this doesn't seem to solve the problem :/ I changed the interval in the /etc/ceilometer/pipeline.yaml and restartet all ceilometer-services but it's still up to 10 minutes till the alarm triggers. I updated the question with the alarm-history

Thank you for the answer and the additional information.

so i wrote a Heat Template with a simple alarm that triggers my upscaling Policy when the CPU is above 75% for 60s. It works fine, but i never thought about what CPU the alarm monitors. Is it the CPU of the Instance thats upscaled? (I don't think so because i haven't define a instance in the alarm) or is it the CPU of all Resources in the Stack? so when my Main Server is fully occupied but the other Resources are fine there will be no new instance?

  CPU_Alarm_HIGH:
    type: OS::Ceilometer::Alarm
    properties:
      meter_name: cpu_util
      statistic: avg
      period: 60
      evaluation_periods: 1
      threshold: 75
      alarm_actions:
        - {get_attr: [Scale_UP_Policy, alarm_url]}
      comparison_operator: gt