lvh's profile - activity

2014-05-29 07:32:57 -0500 received badge  Famous Question (source)
2014-05-05 03:56:52 -0500 received badge  Notable Question (source)
2014-05-04 10:14:10 -0500 received badge  Popular Question (source)
2014-05-02 07:29:17 -0500 asked a question devstack: how to bridge VMs directly to external network using quantum

I'm looking to attach all my instances to a bridge that is connected to my public/external network interface so they can receive their ipv4 address from an external dhcp-server. I previously used nova-network's flatmanager to accomplish this, which worked just fine.

I recently switched to quantum because I'm looking to use the lb-aas (load balancing) features. I've tried both the OVS and linuxbridge plugins, but the network layout is way more than I actually need (multiple bridges, tap interfaces, vlans, etc...).

My question is: which neutron network settings do I use to simply plug in all my instances in a bridge that already exists, so that I can still use the lbaas-services?

2014-04-22 15:39:54 -0500 received badge  Famous Question (source)
2014-03-31 04:10:03 -0500 received badge  Famous Question (source)
2014-03-31 00:16:49 -0500 received badge  Notable Question (source)
2014-03-19 04:12:30 -0500 received badge  Popular Question (source)
2014-03-17 05:20:19 -0500 answered a question ceilometer api put alarm does not trigger heat autoscaling

Thanks for your reply.

2014-03-14 10:35:01 -0500 asked a question ceilometer api put alarm does not trigger heat autoscaling

I am using a devstack setup (stable/havana) with heat and ceilometer enabled. I defined a simple threshold alarm in a heat template which works fine: threshold is calculated based on the samples, and if necessary autoscaling is performed accordingly.

Now, I would also like to be able to trigger the alarm&autoscaling by using the ceilometer API, but:

After a call to change the alarm state ( PUT /v2/alarms/(alarm_id)/state ), the alarm state is set to 'alarm' in mongodb. The ceilometer-alarm-evaluator does not, however, register this change to trigger the alarm policy in heat. Any idea why not? Instead, as soon as the next evaluation cycle hits, the state is set back to 'insufficient data'.

2014-03-07 09:06:53 -0500 received badge  Notable Question (source)
2014-03-04 08:04:49 -0500 commented question heat autoscaling aws authentication failure

I haven't (properly )solved the problem yet, but i confirmed the autoscaling didn't work because of the authentication failure: setting "insecure = true" in /etc/heat/heat.conf in the [keystone_authtoken] section solves the problem and enables the extra instance to be launched

2014-03-03 07:59:08 -0500 received badge  Popular Question (source)
2014-02-27 17:01:57 -0500 received badge  Student (source)
2014-02-26 08:13:41 -0500 received badge  Editor (source)
2014-02-26 08:09:10 -0500 asked a question heat autoscaling aws authentication failure

I installed devstack, (single node, stable/havana, heat and ceilometer included) and was hoping to test the autoscaling feature. I am using a custom meter ("testcounter") in ceilometer. The meter seems to be working fine, I post samples to trigger the alarm using the REST API.

When I launch the stack, one instance is booted. But when the alarm is triggered, no additional instance is booting.. Any advice is most appreciated.

This is the h-api-cfn output, which seems to indicate that heat receives the ceilometer alarm, but that there is an authentication failure that might be preventing the extra instance to be launched:

2014-02-26 13:41:47.776 DEBUG heat.api.middleware.version_negotiation [-] Processing request: POST /v1/signal/arn:openstack:heat::574192af441e4e0487b0ad60a9fda946:stacks/test/f04974cc-3d64-4fc1-ab0c-04518a595477/resources/WebServerScaleDownPolicy Accept: */* from (pid=21822) process_request /opt/stack/heat/heat/api/middleware/version_negotiation.py:53
2014-02-26 13:41:47.776 DEBUG heat.api.middleware.version_negotiation [-] Matched versioned URI. Version: 1.0 from (pid=21822) process_request /opt/stack/heat/heat/api/middleware/version_negotiation.py:68
2014-02-26 13:41:47.777 INFO heat.api.aws.ec2token [-] Checking AWS credentials..
2014-02-26 13:41:47.777 INFO heat.api.aws.ec2token [-] AWS credentials found, checking against keystone.
2014-02-26 13:41:47.778 INFO heat.api.aws.ec2token [-] Authenticating with http://<ip_controller>:5000/v2.0/ec2tokens
2014-02-26 13:41:47.791 INFO requests.packages.urllib3.connectionpool [-] Starting new HTTP connection (1): <proxy>
2014-02-26 13:41:47.803 DEBUG requests.packages.urllib3.connectionpool [-] "POST http://<ip_controller>:5000/v2.0/ec2tokens HTTP/1.1" 500 183 from (pid=21822) _make_request /usr/local/lib/python2.7/dist-packages/requests/packages/urllib3/connectionpool.py:344
2014-02-26 13:41:47.804 INFO heat.api.aws.ec2token [-] AWS authentication failure.
2014-02-26 13:41:47.805 DEBUG root [-] XML response : <ErrorResponse><Error><Message>User is not authorized to perform action</Message><Code>AccessDenied</Code><Type>Sender</Type></Error></ErrorResponse> from (pid=21822) to_xml /opt/stack/heat/heat/common/wsgi.py:604

This is the keystone log:

2014-02-26 13:41:47.609 INFO access [-] 157.193.215.17 - - [26/Feb/2014:12:41:47 +0000] "POST http://<ip_controller>:5000/v2.0/tokens HTTP/1
.0" 200 9697
2014-02-26 13:41:47.797 DEBUG routes.middleware [-] Matched POST /ec2tokens from (pid=11474) __call__ /usr/lib/python2.7/dist-packages
/routes/middleware.py:100
2014-02-26 13:41:47.797 DEBUG routes.middleware [-] Route path: '/ec2tokens', defaults: {'action': u'authenticate', 'controller': <keystone.contrib.ec2.controllers.Ec2Controller object at 0x4518f50>} from (pid=11474) __call__ /usr/lib/python2.7/dist-packages/routes/middleware.py:102
2014-02-26 13:41:47.797 DEBUG routes.middleware [-] Match dict: {'action': u'authenticate', 'controller': <keystone.contrib.ec2.controllers.Ec2Controller object at 0x4518f50>} from (pid=11474) __call__ /usr/lib/python2.7/dist-packages/routes/middleware.py:103
2014-02-26 13:41:47.801 ERROR keystone.common.wsgi [-] 'unicode' object has no attribute 'get'
2014-02-26 13:41:47.801 TRACE keystone.common.wsgi Traceback (most recent call last):
2014-02-26 13:41:47.801 TRACE keystone.common.wsgi   File "/opt/stack/keystone/keystone/common/wsgi ...
(more)
2014-01-29 07:51:35 -0500 received badge  Enthusiast