Re: [openstack-dev] Identify Openstack commands and manipulate them
Thanks for the help. Openstack commands mean some administrative commands as listed here: https://docs.openstack.org/developer/python-openstackclient/command-objects/server.html I want to identify incoming openstack server commands on controller machine and manipulate their execution. On Mon, Jul 3, 2017 at 1:05 AM, Maciej Kucia wrote: > What is "OpenStack command"? You mean Rest API, RPC? What services? > > Maybe the following will be of help. > http://vmartinezdelacruz.com/in-a-nutshell-how-openstack-works/ > > Regards, > Maciej > > 2017-07-02 15:16 GMT+02:00 david jhon : > >> Hello folks, >> >> I've been digging into openstack code for quite some time, I'm wondering >> how to identify some specific openstack commands possibly coming from >> hosted tenants or projects. >> >> Where should I look into the code if I want to suspend or block their >> execution. OR >> What is the starting point or any useful resource which can help me >> further. >> >> Any suggestion/link/help might be great. >> >> Thanks. >> >> >> __ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib >> e >> 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 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] Identify Openstack commands and manipulate them
Hello folks, I've been digging into openstack code for quite some time, I'm wondering how to identify some specific openstack commands possibly coming from hosted tenants or projects. Where should I look into the code if I want to suspend or block their execution. OR What is the starting point or any useful resource which can help me further. Any suggestion/link/help might be great. Thanks. __ 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] SRIOV-error
Hi Irena,
Thanks a lot for your help, it has helped me a lot to fix bugs and get
issues to be resolved.
Thanks again!
On Tue, Dec 16, 2014 at 4:40 PM, Irena Berezovsky
wrote:
>
> Hi David,
>
> As I mentioned before, you do not need to run sriov agent in your setup,
> just set agent_required=False in your neutron-server configuration. I think
> that initially this may be easier to make things work this way.
>
> I also cannot understand why you have two neutron config files that
> contain same sections with different settings.
>
>
>
> You can find me on #openstack-neuron IRC channel, I can try to help.
>
>
>
> BR,
>
> Irena
>
>
>
>
>
> *From:* david jhon [mailto:djhon9...@gmail.com]
> *Sent:* Tuesday, December 16, 2014 9:44 AM
> *To:* Irena Berezovsky
> *Cc:* OpenStack Development Mailing List (not for usage questions);
> Murali B
> *Subject:* Re: [openstack-dev] SRIOV-error
>
>
>
> Hi Irena and Murali,
>
> Thanks a lot for your reply!
>
> Here is the output from pci_devices table of nova db:
>
> select * from pci_devices;
>
> +-+++-++-+--++---+--+--+-+---+---+---++
> | created_at | updated_at | deleted_at | deleted | id |
> compute_node_id | address | product_id | vendor_id | dev_type |
> dev_id | label | status|
> extra_info| instance_uuid | request_id |
>
> +-+++-++-+--++---+--+--+-+---+---+---++
> | 2014-12-15 12:10:52 | NULL | NULL | 0 | 1
> | 1 | :03:10.0 | 10ed | 8086 | type-VF |
> pci__03_10_0 | label_8086_10ed | available | {"phys_function":
> ":03:00.0"} | NULL | NULL |
> | 2014-12-15 12:10:52 | NULL | NULL | 0 | 2
> | 1 | :03:10.2 | 10ed | 8086 | type-VF |
> pci__03_10_2 | label_8086_10ed | available | {"phys_function":
> ":03:00.0"} | NULL | NULL |
> | 2014-12-15 12:10:52 | NULL | NULL | 0 | 3
> | 1 | :03:10.4 | 10ed | 8086 | type-VF |
> pci__03_10_4 | label_8086_10ed | available | {"phys_function":
> ":03:00.0"} | NULL | NULL |
> | 2014-12-15 12:10:52 | NULL | NULL | 0 | 4
> | 1 | :03:10.6 | 10ed | 8086 | type-VF |
> pci__03_10_6 | label_8086_10ed | available | {"phys_function":
> ":03:00.0"} | NULL | NULL |
> | 2014-12-15 12:10:53 | NULL | NULL | 0 | 5
> | 1 | :03:10.1 | 10ed | 8086 | type-VF |
> pci__03_10_1 | label_8086_10ed | available | {"phys_function":
> ":03:00.1"} | NULL | NULL |
> | 2014-12-15 12:10:53 | NULL | NULL | 0 | 6
> | 1 | :03:10.3 | 10ed | 8086 | type-VF |
> pci__03_10_3 | label_8086_10ed | available | {"phys_function":
> ":03:00.1"} | NULL | NULL |
> | 2014-12-15 12:10:53 | NULL | NULL | 0 | 7
> | 1 | :03:10.5 | 10ed | 8086 | type-VF |
> pci__03_10_5 | label_8086_10ed | available | {"phys_function":
> ":03:00.1"} | NULL | NULL |
> | 2014-12-15 12:10:53 | NULL | NULL | 0 | 8
> | 1 | :03:10.7 | 10ed | 8086 | type-VF |
> pci__03_10_7 | label_8086_10ed | available | {"phys_function":
> ":03:00.1"} | NULL | NULL |
>
> +-+++-++-+--++---+--+--+-+---+---+---++
>
> output from select hypervisor_hostname,pci_stats from compute_nodes; is:
>
> +-+---+
> | hypervisor_hostname |
> pci_stats
> |
>
> +-+---+
> | blade08 | [{"count": 8, "vendor_id": "8086",
>
Re: [openstack-dev] SRIOV-error
agent's node-specific list of
virtual
# functions that should not be used for virtual networking.
# vfs_to_exclude is a semicolon-separated list of virtual
# functions to exclude from network_device. The network_device in the
# mapping should appear in the physical_device_mappings list.
# exclude_devices =
# Example: exclude_devices = eth1::07:00.2; :07:00.3
pci_passthrough_whitelist from /etc/nova/nova.conf:
pci_passthrough_whitelist =
{"address":"*:03:10.*","physical_network":"ext-net"}
/etc/neutron/plugins/ml2/ml2_conf.ini:
[ml2]
# (ListOpt) List of network type driver entrypoints to be loaded from
# the neutron.ml2.type_drivers namespace.
#
#type_drivers = local,flat,vlan,gre,vxlan
#Example: type_drivers = flat,vlan,gre,vxlan
#type_drivers = flat,gre, vlan
type_drivers = flat,vlan
# (ListOpt) Ordered list of network_types to allocate as tenant
# networks. The default value 'local' is useful for single-box testing
# but provides no connectivity between hosts.
#
# tenant_network_types = local
# Example: tenant_network_types = vlan,gre,vxlan
#tenant_network_types = gre, vlan
tenant_network_types = vlan
# (ListOpt) Ordered list of networking mechanism driver entrypoints
# to be loaded from the neutron.ml2.mechanism_drivers namespace.
mechanism_drivers = openvswitch, sriovnicswitch
# Example: mechanism_drivers = openvswitch,mlnx
# Example: mechanism_drivers = arista
# Example: mechanism_drivers = cisco,logger
# Example: mechanism_drivers = openvswitch,brocade
# Example: mechanism_drivers = linuxbridge,brocade
# (ListOpt) Ordered list of extension driver entrypoints
# to be loaded from the neutron.ml2.extension_drivers namespace.
# extension_drivers =
# Example: extension_drivers = anewextensiondriver
[ml2_type_flat]
# (ListOpt) List of physical_network names with which flat networks
# can be created. Use * to allow flat networks with arbitrary
# physical_network names.
#
flat_networks = ext-net
# Example:flat_networks = physnet1,physnet2
# Example:flat_networks = *
[ml2_type_vlan]
# (ListOpt) List of [::] tuples
# specifying physical_network names usable for VLAN provider and
# tenant networks, as well as ranges of VLAN tags on each
# physical_network available for allocation as tenant networks.
network_vlan_ranges = ext-net:2:100
# Example: network_vlan_ranges = physnet1:1000:2999,physnet2
[ml2_type_gre]
# (ListOpt) Comma-separated list of : tuples enumerating
ranges of GRE tunnel IDs that are available for tenant network allocation
#tunnel_id_ranges = 1:1000
[ml2_type_vxlan]
# (ListOpt) Comma-separated list of : tuples enumerating
# ranges of VXLAN VNI IDs that are available for tenant network allocation.
#
# vni_ranges =
# (StrOpt) Multicast group for the VXLAN interface. When configured, will
# enable sending all broadcast traffic to this multicast group. When left
# unconfigured, will disable multicast VXLAN mode.
#
# vxlan_group =
# Example: vxlan_group = 239.1.1.1
[securitygroup]
# Controls if neutron security group is enabled or not.
# It should be false when you use nova security group.
enable_security_group = True
# Use ipset to speed-up the iptables security groups. Enabling ipset support
# requires that ipset is installed on L2 agent node.
enable_ipset = True
firewall_driver =
neutron.agent.linux.iptables_firewall.OVSHybridIptablesFirewallDriver
[ovs]
local_ip = controller
enable_tunneling = True
bridge_mappings = external:br-ex
[agent]
tunnel_types = vlan
[ml2_sriov]
agent_required = True
Please tell me what is wrong in there plus what exactly "physnet1" should
be? Thanks again for all your help and suggestion
Regards,
On Tue, Dec 16, 2014 at 10:42 AM, Irena Berezovsky
wrote:
>
> Hi David,
>
> You error is not related to agent.
>
> I would suggest to check:
>
> 1.nova.conf at your compute node for pci whitelist configuration
>
> 2. Neutron server configuration for correct physical_network label
> matching the label in pci whitelist
>
> 3. Nova DB tables containing PCI devices entries:
>
> "#echo 'use nova;select hypervisor_hostname,pci_stats from compute_nodes;'
> | mysql -u root"
>
> You should not run SR-IOV agent in you setup. SR-IOV agent is an
> optional and currently does not add value if you use Intel NIC.
>
>
>
>
>
> Regards,
>
> Irena
>
> *From:* david jhon [mailto:djhon9...@gmail.com]
> *Sent:* Tuesday, December 16, 2014 5:54 AM
> *To:* Murali B
> *Cc:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* Re: [openstack-dev] SRIOV-error
>
>
>
> Just to be more clear, command $lspci | grep -i Ethernet gives following
> output:
>
> 01:00.0 Ethernet controller: Intel Corporati
Re: [openstack-dev] SRIOV-error
Just to be more clear, command $lspci | grep -i Ethernet gives following output: 01:00.0 Ethernet controller: Intel Corporation 82599 10 Gigabit Dual Port Backplane Connection (rev 01) 01:00.1 Ethernet controller: Intel Corporation 82599 10 Gigabit Dual Port Backplane Connection (rev 01) 03:00.0 Ethernet controller: Intel Corporation 82599 10 Gigabit Dual Port Backplane Connection (rev 01) 03:00.1 Ethernet controller: Intel Corporation 82599 10 Gigabit Dual Port Backplane Connection (rev 01) 03:10.0 Ethernet controller: Intel Corporation 82599 Ethernet Controller Virtual Function (rev 01) 03:10.1 Ethernet controller: Intel Corporation 82599 Ethernet Controller Virtual Function (rev 01) 03:10.2 Ethernet controller: Intel Corporation 82599 Ethernet Controller Virtual Function (rev 01) 03:10.3 Ethernet controller: Intel Corporation 82599 Ethernet Controller Virtual Function (rev 01) 03:10.4 Ethernet controller: Intel Corporation 82599 Ethernet Controller Virtual Function (rev 01) 03:10.5 Ethernet controller: Intel Corporation 82599 Ethernet Controller Virtual Function (rev 01) 03:10.6 Ethernet controller: Intel Corporation 82599 Ethernet Controller Virtual Function (rev 01) 03:10.7 Ethernet controller: Intel Corporation 82599 Ethernet Controller Virtual Function (rev 01) 04:00.0 Ethernet controller: Intel Corporation 82599 10 Gigabit Dual Port Backplane Connection (rev 01) 04:00.1 Ethernet controller: Intel Corporation 82599 10 Gigabit Dual Port Backplane Connection (rev 01) 04:10.0 Ethernet controller: Intel Corporation 82599 Ethernet Controller Virtual Function (rev 01) 04:10.1 Ethernet controller: Intel Corporation 82599 Ethernet Controller Virtual Function (rev 01) 04:10.2 Ethernet controller: Intel Corporation 82599 Ethernet Controller Virtual Function (rev 01) 04:10.3 Ethernet controller: Intel Corporation 82599 Ethernet Controller Virtual Function (rev 01) 04:10.4 Ethernet controller: Intel Corporation 82599 Ethernet Controller Virtual Function (rev 01) 04:10.5 Ethernet controller: Intel Corporation 82599 Ethernet Controller Virtual Function (rev 01) 04:10.6 Ethernet controller: Intel Corporation 82599 Ethernet Controller Virtual Function (rev 01) 04:10.7 Ethernet controller: Intel Corporation 82599 Ethernet Controller Virtual Function (rev 01) How can I make SR-IOV agent run and fix this bug? On Tue, Dec 16, 2014 at 8:36 AM, david jhon wrote: > > Hi Murali, > > Thanks for your response, I did the same, it has resolved errors > apparently but 1) neutron agent-list shows no agent for sriov, 2) neutron > port is created successfully but creating vm is erred in scheduling as > follows: > > result from neutron agent-list: > > +--++-+---++---+ > | id | agent_type | host| > alive | admin_state_up | binary| > > +--++-+---++---+ > | 2acc7044-e552-4601-b00b-00ba591b453f | Open vSwitch agent | blade08 | > xxx | True | neutron-openvswitch-agent | > | 595d07c6-120e-42ea-a950-6c77a6455f10 | Metadata agent | blade08 | > :-) | True | neutron-metadata-agent| > | a1f253a8-e02e-4498-8609-4e265285534b | DHCP agent | blade08 | > :-) | True | neutron-dhcp-agent| > | d46b29d8-4b5f-4838-bf25-b7925cb3e3a7 | L3 agent | blade08 | > :-) | True | neutron-l3-agent | > > +--++-+---++---+ > > 2014-12-15 19:30:44.546 40249 ERROR oslo.messaging.rpc.dispatcher > [req-c7741cff-a7d8-422f-b605-6a1d976aeb09 ] Exception during message > handling: PCI $ > 2014-12-15 19:30:44.546 40249 TRACE oslo.messaging.rpc.dispatcher > Traceback (most recent call last): > 2014-12-15 19:30:44.546 40249 TRACE oslo.messaging.rpc.dispatcher File > "/usr/lib/python2.7/dist-packages/oslo/messaging/rpc/dispatcher.py", line > 13$ > 2014-12-15 19:30:44.546 40249 TRACE oslo.messaging.rpc.dispatcher > incoming.message)) > 2014-12-15 19:30:44.546 40249 TRACE oslo.messaging.rpc.dispatcher File > "/usr/lib/python2.7/dist-packages/oslo/messaging/rpc/dispatcher.py", line > 17$ > 2014-12-15 19:30:44.546 40249 TRACE oslo.messaging.rpc.dispatcher > return self._do_dispatch(endpoint, method, ctxt, args) > 2014-12-15 19:30:44.546 40249 TRACE oslo.messaging.rpc.dispatcher File > "/usr/lib/python2.7/dist-packages/oslo/messaging/rpc/dispatcher.py", line > 12$ > 2014-12-15 19:30:44.546 40249 TRACE oslo.messaging.rpc.dispatcher > result = getattr(endpoint, method)(ctxt, **new_args) > 2014-12-15 19:30:44.5
Re: [openstack-dev] SRIOV-error
Hi Murali,
Thanks for your response, I did the same, it has resolved errors apparently
but 1) neutron agent-list shows no agent for sriov, 2) neutron port is
created successfully but creating vm is erred in scheduling as follows:
result from neutron agent-list:
+--++-+---++---+
| id | agent_type | host|
alive | admin_state_up | binary|
+--++-+---++---+
| 2acc7044-e552-4601-b00b-00ba591b453f | Open vSwitch agent | blade08 |
xxx | True | neutron-openvswitch-agent |
| 595d07c6-120e-42ea-a950-6c77a6455f10 | Metadata agent | blade08 |
:-) | True | neutron-metadata-agent|
| a1f253a8-e02e-4498-8609-4e265285534b | DHCP agent | blade08 |
:-) | True | neutron-dhcp-agent|
| d46b29d8-4b5f-4838-bf25-b7925cb3e3a7 | L3 agent | blade08 |
:-) | True | neutron-l3-agent |
+--++-+---++---+
2014-12-15 19:30:44.546 40249 ERROR oslo.messaging.rpc.dispatcher
[req-c7741cff-a7d8-422f-b605-6a1d976aeb09 ] Exception during message
handling: PCI $
2014-12-15 19:30:44.546 40249 TRACE oslo.messaging.rpc.dispatcher Traceback
(most recent call last):
2014-12-15 19:30:44.546 40249 TRACE oslo.messaging.rpc.dispatcher File
"/usr/lib/python2.7/dist-packages/oslo/messaging/rpc/dispatcher.py", line
13$
2014-12-15 19:30:44.546 40249 TRACE oslo.messaging.rpc.dispatcher
incoming.message))
2014-12-15 19:30:44.546 40249 TRACE oslo.messaging.rpc.dispatcher File
"/usr/lib/python2.7/dist-packages/oslo/messaging/rpc/dispatcher.py", line
17$
2014-12-15 19:30:44.546 40249 TRACE oslo.messaging.rpc.dispatcher
return self._do_dispatch(endpoint, method, ctxt, args)
2014-12-15 19:30:44.546 40249 TRACE oslo.messaging.rpc.dispatcher File
"/usr/lib/python2.7/dist-packages/oslo/messaging/rpc/dispatcher.py", line
12$
2014-12-15 19:30:44.546 40249 TRACE oslo.messaging.rpc.dispatcher
result = getattr(endpoint, method)(ctxt, **new_args)
2014-12-15 19:30:44.546 40249 TRACE oslo.messaging.rpc.dispatcher File
"/usr/lib/python2.7/dist-packages/oslo/messaging/rpc/server.py", line 139,
i$
2014-12-15 19:30:44.546 40249 TRACE oslo.messaging.rpc.dispatcher
return func(*args, **kwargs)
2014-12-15 19:30:44.546 40249 TRACE oslo.messaging.rpc.dispatcher File
"/usr/lib/python2.7/dist-packages/nova/scheduler/manager.py", line 175, in
s$
2014-12-15 19:30:44.546 40249 TRACE oslo.messaging.rpc.dispatcher
filter_properties)
2014-12-15 19:30:44.546 40249 TRACE oslo.messaging.rpc.dispatcher File
"/usr/lib/python2.7/dist-packages/nova/scheduler/filter_scheduler.py", line
$
2014-12-15 19:30:44.546 40249 TRACE oslo.messaging.rpc.dispatcher
filter_properties)
2014-12-15 19:30:44.546 40249 TRACE oslo.messaging.rpc.dispatcher File
"/usr/lib/python2.7/dist-packages/nova/scheduler/filter_scheduler.py", line
$
2014-12-15 19:30:44.546 40249 TRACE oslo.messaging.rpc.dispatcher
chosen_host.obj.consume_from_instance(instance_properties)
2014-12-15 19:30:44.546 40249 TRACE oslo.messaging.rpc.dispatcher File
"/usr/lib/python2.7/dist-packages/nova/scheduler/host_manager.py", line
246,$
2014-12-15 19:30:44.546 40249 TRACE oslo.messaging.rpc.dispatcher
self.pci_stats.apply_requests(pci_requests.requests)
2014-12-15 19:30:44.546 40249 TRACE oslo.messaging.rpc.dispatcher File
"/usr/lib/python2.7/dist-packages/nova/pci/pci_stats.py", line 209, in
apply$
2014-12-15 19:30:44.546 40249 TRACE oslo.messaging.rpc.dispatcher raise
exception.PciDeviceRequestFailed(requests=requests)
2014-12-15 19:30:44.546 40249 TRACE oslo.messaging.rpc.dispatcher
PciDeviceRequestFailed: PCI device request ({'requests':
[InstancePCIRequest(alias_$
2014-12-15 19:30:44.546 40249 TRACE oslo.messaging.rpc.dispatcher.
Moreover, no /var/log/sriov-agent.log file exists. Please help me to fix
this issue. Thanks everyone!
On Mon, Dec 15, 2014 at 5:18 PM, Murali B wrote:
>
> Hi David,
>
> Please add as per the Irena suggestion
>
> FYI: refer the below configuration
>
> http://pastebin.com/DGmW7ZEg
>
>
> Thanks
> -Murali
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] SRIOV failures error-
Hi, I am doing the same i.e., configuring SR-IOV with Openstack juno, I
have manually done this but now I am doing it for openstack. Can you please
list down steps you used for configuring SR-IOV. I am currently following
this link but getting many errors:
https://wiki.openstack.org/wiki/SR-IOV-Passthrough-For-Networking
Please share some tutorial you found for this configuration. I'll be real
grateful for your help. Thanking you in anticipation
Looking forward seeing your response
Thanks and Regards,
On Tue, Dec 2, 2014 at 12:18 PM, Itzik Brown wrote:
>
> Hi,
> Seems like you don't have available devices for allocation.
>
> What's the output of:
> #echo 'use nova;select hypervisor_hostname,pci_stats from compute_nodes;'
> | mysql -u root
>
> Itzik
>
>
> On 12/02/2014 08:21 AM, Murali B wrote:
>
> Hi
>
> we are trying to bring-up the SRIOV on set-up.
>
> facing the below error when we tried create the vm.
>
>
> * Still during creating instance ERROR appears . PciDeviceRequestFailed:
> PCI device request ({'requests':
> [InstancePCIRequest(alias_name=None,count=1,is_new=False,request_id=58584ee1-8a41-4979-9905-4d18a3df3425,spec=[{physical_network='physnet1'}])],
> 'code': 500}equests)s failed*
>
> followed the steps from the
> https://wiki.openstack.org/wiki/SR-IOV-Passthrough-For-Networking
>
> Please help us to get rid this error. let us know if any configuration
> is required at hardware in order to work properly.
>
> Thanks
> -Murali
>
>
> ___
> OpenStack-dev mailing
> listOpenStack-dev@lists.openstack.orghttp://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 mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Ceilometer][Heat]Defining a webhook URL for alarm-actions
Hi, Thank you Steven, I followed templates given there in examples, created one for me(see attached), but I am getting following error in /var/log/heat/heat-api.log file: 2014-10-30 10:07:44.749 30476 TRACE root 2014-10-30 10:07:44.749 30476 TRACE root File "/usr/lib/python2.7/dist-packages/heat/openstack/common/rpc/dispatcher.py", line 172, in dispatch 2014-10-30 10:07:44.749 30476 TRACE root result = getattr(proxyobj, method)(ctxt, **kwargs) 2014-10-30 10:07:44.749 30476 TRACE root 2014-10-30 10:07:44.749 30476 TRACE root File "/usr/lib/python2.7/dist-packages/heat/engine/service.py", line 60, in wrapped 2014-10-30 10:07:44.749 30476 TRACE root return func(self, ctx, *args, **kwargs) 2014-10-30 10:07:44.749 30476 TRACE root 2014-10-30 10:07:44.749 30476 TRACE root File "/usr/lib/python2.7/dist-packages/heat/engine/service.py", line 368, in validate_template 2014-10-30 10:07:44.749 30476 TRACE root ResourceClass = resource.get_class(res['Type']) 2014-10-30 10:07:44.749 30476 TRACE root 2014-10-30 10:07:44.749 30476 TRACE root File "/usr/lib/python2.7/dist-packages/heat/engine/resource.py", line 45, in get_class 2014-10-30 10:07:44.749 30476 TRACE root return resources.global_env().get_class(resource_type, resource_name) 2014-10-30 10:07:44.749 30476 TRACE root 2014-10-30 10:07:44.749 30476 TRACE root File "/usr/lib/python2.7/dist-packages/heat/engine/environment.py", line 326, in get_class 2014-10-30 10:07:44.749 30476 TRACE root return self.registry.get_class(resource_type, resource_name) 2014-10-30 10:07:44.749 30476 TRACE root 2014-10-30 10:07:44.749 30476 TRACE root File "/usr/lib/python2.7/dist-packages/heat/engine/environment.py", line 257, in get_class 2014-10-30 10:07:44.749 30476 TRACE root raise exception.StackValidationFailed(message=msg) 2014-10-30 10:07:44.749 30476 TRACE root 2014-10-30 10:07:44.749 30476 TRACE root StackValidationFailed: Unknown resource Type : OS::Heat::AutoScalingGroup 2014-10-30 10:07:44.749 30476 TRACE root Why is it not supporting OS::Heat::AutoScalingGroup resource_type, Should I move to Icehouse or Junos to get it fixed? Or there is some other reason? Thanks in advance for any hint or suggestions. David On Wed, Oct 29, 2014 at 3:56 PM, Steven Hardy wrote: > On Wed, Oct 29, 2014 at 03:19:49PM +0500, david jhon wrote: > >Hi, > > > >I am using all-in-one Havana on Ubuntu 12.04 LTS, working on > Ceilometer > >and Heat. I want to launch an instance based on a threshold defined in > >alarm. My question is where and how am I supposed to define the > webhook > >URL for --alarm-actions argument. I am creating threshold alarm with > the > >following command: > > > >ceilometer -k alarm-threshold-create --name tester_cpu_high > --description > >'instance_too_high' --meter-name cpu_util --threshold 20.0 > >--comparison-operator ge --statistic avg --period 30 > --evaluation-periods > >1 --query resource_id=bd4ec331-dfc5-4a75-b928-6d0988dfc369 > > Hi, you may want to use the general mailing list for future usage questions > like this, as it's not really related to development: > > https://wiki.openstack.org/wiki/Mailing_Lists#General_List > > The answer to your question is you must create the alarm inside your heat > template, and reference a resource which provides a pre-signed URL, such as > a ScalingPolicy resource. > > Here's an example template: > > > https://github.com/openstack/heat-templates/blob/master/hot/autoscaling.yaml#L121 > > If you really want to create the alarm via the ceilometer CLI for testing, > you'll need to expose the URL of the ScalingPolicy via a stack output, like > this: > > > https://github.com/openstack/heat-templates/blob/master/hot/asg_of_servers.yaml#L78 > > And get the output URL via "heat stack-show " > > Steve > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > scaleup.yaml Description: application/yaml ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Ceilometer][Heat]Defining a webhook URL for alarm-actions
Hi, I am using all-in-one Havana on Ubuntu 12.04 LTS, working on Ceilometer and Heat. I want to launch an instance based on a threshold defined in alarm. My question is where and how am I supposed to define the webhook URL for --alarm-actions argument. I am creating threshold alarm with the following command: ceilometer -k alarm-threshold-create --name tester_cpu_high --description 'instance_too_high' --meter-name cpu_util --threshold 20.0 --comparison-operator ge --statistic avg --period 30 --evaluation-periods 1 --query resource_id=bd4ec331-dfc5-4a75-b928-6d0988dfc369 -- Regards, David ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Ceilometer] Ceilometer-Alarm-Not Working
dation and will not set the X-Service- # Catalog header. (boolean value) #include_service_catalog=true # Used to control the use and type of token binding. Can be # set to: "disabled" to not check token binding. "permissive" # (default) to validate binding information if the bind type # is of a form known to the server and ignore it if not. # "strict" like "permissive" but if the bind type is unknown # the token will be rejected. "required" any form of token # binding is needed to be allowed. Finally the name of a # binding method that must be present in tokens. (string # value) #enforce_token_bind=permissive [collector] # # Options defined in ceilometer.collector.service # # address to bind the UDP socket todisabled if set to an empty # string (string value) #udp_address=0.0.0.0 # port to bind the UDP socket to (integer value) #udp_port=4952 # Acknowledge message when event persistence fails (boolean # value) #ack_on_event_error=true # Save event details (boolean value) #store_events=false # dispatcher to process metering data (multi valued) #dispatcher=database [matchmaker_ring] # # Options defined in ceilometer.openstack.common.rpc.matchmaker_ring # # Matchmaker ring file (JSON) (string value) #ringfile=/etc/oslo/matchmaker_ring.json [matchmaker_redis] # # Options defined in ceilometer.openstack.common.rpc.matchmaker_redis # # Host to locate redis (string value) #host=127.0.0.1 # Use this port to connect to redis host. (integer value) #port=6379 # Password for Redis server. (optional) (string value) #password= On Mon, Oct 20, 2014 at 5:23 PM, Chris Dent wrote: > On Mon, 20 Oct 2014, david jhon wrote: > > 2014-10-20 16:33:07.854 30437 TRACE ceilometer.alarm.service >> CommunicationError: Error communicating with http://193.168.4.121:8777 >> [Errno 111]$ >> 2014-10-20 16:33:07.854 30437 TRACE ceilometer.alarm.service >> >> How do I fix it? >> > > It looks like it may be that either your ceilometer-api service is > not running or is not bound to the correct network interface. > > Since you've got a ceilometer-api.log is may be that the service is > unreachable because of some configuration setting (firewall, alarm > and api service on different networks, that sort of thing). > > -- > Chris Dent tw:@anticdent freenode:cdent > https://tank.peermore.com/tanks/cdent > > ___ > 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] [Ceilometer] Ceilometer-Alarm-Not Working
Hi,
Just opened /var/log/ceilometer/ceilometer-alarm-evaluator.log file and
found following errors:
2014-10-20 16:32:15.263 23166 TRACE ceilometer.alarm.service
2014-10-20 16:33:07.854 30437 ERROR ceilometer.alarm.service [-] alarm
evaluation cycle failed
2014-10-20 16:33:07.854 30437 TRACE ceilometer.alarm.service Traceback
(most recent call last):
2014-10-20 16:33:07.854 30437 TRACE ceilometer.alarm.service File
"/usr/lib/python2.7/dist-packages/ceilometer/alarm/service.py", line 96, in$
2014-10-20 16:33:07.854 30437 TRACE ceilometer.alarm.service alarms =
self._assigned_alarms()
2014-10-20 16:33:07.854 30437 TRACE ceilometer.alarm.service File
"/usr/lib/python2.7/dist-packages/ceilometer/alarm/service.py", line 139, i$
2014-10-20 16:33:07.854 30437 TRACE ceilometer.alarm.service 'value':
True}])
2014-10-20 16:33:07.854 30437 TRACE ceilometer.alarm.service File
"/usr/lib/python2.7/dist-packages/ceilometerclient/v2/alarms.py", line 61, $
2014-10-20 16:33:07.854 30437 TRACE ceilometer.alarm.service return
self._list(options.build_url(self._path(), q))
2014-10-20 16:33:07.854 30437 TRACE ceilometer.alarm.service File
"/usr/lib/python2.7/dist-packages/ceilometerclient/common/base.py", line 57$
2014-10-20 16:33:07.854 30437 TRACE ceilometer.alarm.service resp, body
= self.api.json_request('GET', url)
2014-10-20 16:33:07.854 30437 TRACE ceilometer.alarm.service File
"/usr/lib/python2.7/dist-packages/ceilometerclient/common/http.py", line 18$
2014-10-20 16:33:07.854 30437 TRACE ceilometer.alarm.service resp,
body_iter = self._http_request(url, method, **kwargs)
2014-10-20 16:33:07.854 30437 TRACE ceilometer.alarm.service File
"/usr/lib/python2.7/dist-packages/ceilometerclient/common/http.py", line 15$
2014-10-20 16:33:07.854 30437 TRACE ceilometer.alarm.service raise
exc.CommunicationError(message=message)
2014-10-20 16:33:07.854 30437 TRACE ceilometer.alarm.service
CommunicationError: Error communicating with http://193.168.4.121:8777
[Errno 111]$
2014-10-20 16:33:07.854 30437 TRACE ceilometer.alarm.service
How do I fix it?
On Mon, Oct 20, 2014 at 4:02 PM, david jhon wrote:
> Hi all,
>
> I am working with Ceilometer, Havana-All-in-one on Ubuntu 12.04.
> Initially, ceilometer configuration installed four ceilometer services:
>
> ceilometer-agent-central
> ceilometer-agent-compute
> ceilometer-api
> ceilometer-collector
>
> but later I came to know that there should be two other services running
> as well: ceilometer-alarm evaluator, ceilometer-alarm-notifier, I installed
> these services as given on the link:
> http://www.brucemartins.com/2014/03/openstack-havana-ceilometer-alarm.html
>
> I created alarm at a resource by using this command: ceilometer -k
> alarm-threshold-create --name tester_cpu_high --description 'overheating?'
> --meter-name cpu_util --threshold 3.0 --comparison-operator gt --statistic
> avg --period 10 --query resource_id=e0bbdad3-ebdb-4acd-8fb5-cd2e10bb10f4
>
> but whenever I check the status of alarm, it shows me 'insufficient data'
> status.
>
> I tested it by running different applications on my instance but they made
> no change in alarm_status.
>
> Here is the log from /var/log/ceilometer/ceilometer-agent-compute.log:
>
> 2014-10-20 15:37:13.957 23126 WARNING ceilometer.transformer.conversions
> [-] dropping sample with no predecessor: 2014-10-20 15:37:14.023 23126 WARNING ceilometer.transformer.conversions
> [-] dropping sample with no predecessor:
> /var/log/ceilometer/ceilometer-api.log :
>
> 2014-10-20 15:37:10.652 23136 INFO keystoneclient.middleware.auth_token
> [-] Starting keystone auth_token middleware
> 2014-10-20 15:37:10.653 23136 INFO keystoneclient.middleware.auth_token
> [-] Using /tmp/keystone-signing-bGIm6r as cache directory for signing c$
> 2014-10-20 15:37:13.039 23136 INFO keystoneclient.middleware.auth_token
> [-] Starting keystone auth_token middleware
> 2014-10-20 15:37:13.039 23136 INFO keystoneclient.middleware.auth_token
> [-] Using /tmp/keystone-signing-y7L_NW as cache directory for signing c
>
> Please tell me which step is missing or what exact procedure should be
> followed in order to monitor a meter for a resource.
>
> Moreover, what steps should be taken in order to add new meter. How would
> I debug ceilometer source code in /usr/lib/python2.7/ceilometer/* if I
> follow the following link:
> http://docs.openstack.org/developer/ceilometer/contributing/plugins.html
>
> Thank you!
>
>
> Regards,
> Jhon David
>
>
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Ceilometer] Ceilometer-Alarm-Not Working
Hi all, I am working with Ceilometer, Havana-All-in-one on Ubuntu 12.04. Initially, ceilometer configuration installed four ceilometer services: ceilometer-agent-central ceilometer-agent-compute ceilometer-api ceilometer-collector but later I came to know that there should be two other services running as well: ceilometer-alarm evaluator, ceilometer-alarm-notifier, I installed these services as given on the link: http://www.brucemartins.com/2014/03/openstack-havana-ceilometer-alarm.html I created alarm at a resource by using this command: ceilometer -k alarm-threshold-create --name tester_cpu_high --description 'overheating?' --meter-name cpu_util --threshold 3.0 --comparison-operator gt --statistic avg --period 10 --query resource_id=e0bbdad3-ebdb-4acd-8fb5-cd2e10bb10f4 but whenever I check the status of alarm, it shows me 'insufficient data' status. I tested it by running different applications on my instance but they made no change in alarm_status. Here is the log from /var/log/ceilometer/ceilometer-agent-compute.log: 2014-10-20 15:37:13.957 23126 WARNING ceilometer.transformer.conversions [-] dropping sample with no predecessor: http://docs.openstack.org/developer/ceilometer/contributing/plugins.html Thank you! Regards, Jhon David ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
