awestin1's profile - activity

2019-04-24 06:12:40 -0600 received badge  Student (source)
2018-01-29 20:23:34 -0600 commented question Gnocchi - Keystone Unable to Validate Token

It turns out there were actually a few issues. Since this question has been closed. I posted the answer on a separate question here: (

2017-11-09 01:52:54 -0600 received badge  Famous Question (source)
2017-11-01 06:59:04 -0600 received badge  Notable Question (source)
2017-10-30 03:06:32 -0600 received badge  Popular Question (source)
2017-10-26 23:52:41 -0600 asked a question Gnocchi - Keystone Unable to Validate Token

I am trying to set up Ceilometer with Gnocchi running Ocata RDO on RHEL7. Gnocchi has been installed and configured. However, after starting the Gnocchi api and metricd, I keep getting an error when attempting to test Gnicchi. When I run gnocchi metric list, I get the following error:

[~]# gnocchi metric list
{"message": "The server is currently unavailable. Please try again at a later time.<br /><br />\n\n\n", "code": "503 Service Unavailable", "title": "Service Unavailable"} (HTTP 503)

At the same time, I get the following error from /etc/var/log/gnocchi/gnocchi.log:

2017-10-27 00:32:27.241 3231 WARNING keystonemiddleware.auth_token [-] Identity response: {"error": {"message": "The request you have made requires authentication.", "code": 401, "title": "Unauthorized"}}
2017-10-27 00:32:27.242 3231 CRITICAL keystonemiddleware.auth_token [-] Unable to validate token: Identity server rejected authorization necessary to fetch token data

I also get the following from stderr on gnocchi-api:

[~]# gnocchi-api -p 8041 -b
Option "verbose" from group "DEFAULT" is deprecated for removal.  Its value may be silently ignored in the future.
STARTING test server
Available at http://gcp-openstack:8041/
DANGER! For testing only, do not use in production
******************************************************************************** - - [26/Oct/2017 23:32:21] "GET /v1/metric HTTP/1.1" 503 170

The [keystone_authtoken] section in my /etc/gnocchi/gnocchi.conf is as follows:

auth_type = password
auth_url = http://controller:5000/v3
project_domain_name = Default
user_domain_name = Default
project_name = service
username = gnocchi
password = P@ssw0rd
interface = internalURL
region_name = RegionOne

Does anyone have any suggestions for troubleshooting this issue? I have already sourced admin-openrc before running the Gnocchi client. So, I am not sure why I am receiving this message. My admin-openrc is as follows:

[~]# cat admin-openrc 
export OS_USER_DOMAIN_NAME=Default
export OS_PROJECT_NAME=admin
export OS_USERNAME=admin
export OS_PASSWORD=admin_P@ssw0rd
export OS_AUTH_URL=http://controller:35357/v3
export OS_AUTH_TYPE=password

Are there any other environment variables I am supposed to be setting?

Update: I also see the following in the gnocchi.log when starting gnocchi-api:

2017-10-31 13:25:09.843 96717 WARNING keystonemiddleware._common.config [-] The option "__file__" in conf is not known to auth_token
2017-10-31 13:25:09.843 96717 WARNING keystonemiddleware._common.config [-] The option "configkey" in conf is not known to auth_token
2017-10-31 13:25:09.844 96717 WARNING keystonemiddleware._common.config [-] The option "here" in conf is not known to auth_token
2017-10-31 13:25:09.847 96717 WARNING keystonemiddleware.auth_token [-] AuthToken middleware is set with keystone_authtoken.service_token_roles_required set to False. This is backwards compatible but deprecated behaviour. Please set this to True.
2017-10-31 13:25:09.852 96717 WARNING keystonemiddleware.auth_token [-] Configuring auth_uri to point to the public identity endpoint is required; clients may not be able to authenticate against an admin endpoint
2017-06-21 17:36:34 -0600 received badge  Notable Question (source)
2017-05-22 13:10:47 -0600 commented question No ports have port_id starting with Network Adapter

Did you ever figure this out? I'm having the same issue.

2017-05-14 08:21:09 -0600 received badge  Popular Question (source)
2017-05-12 16:08:08 -0600 answered a question Configuring Open vSwitch/Neutron Agent on Hyper-V to Use Existing Provider VLANs

Looks like the vswitch_name directive needed to be updated in nova.conf on the compute node with the name of the desired VMswitch! Instances are now being launched on the correct VMswitch.

2017-05-09 16:34:18 -0600 commented question Instances not getting an ip addresses

What hypervisor are you using? What neutron agent are you using? Are you using Open vSwitch on the compute node or something else?

2017-05-09 16:32:28 -0600 commented question I can't create image and launch instance

What is the error you are getting?

2017-05-09 16:05:49 -0600 asked a question Configuring Open vSwitch/Neutron Agent on Hyper-V to Use Existing Provider VLANs

We have recently stood up an OpenStack (Ocata) controller and a Hyper-V compute node with Cloudbase Nova agent installed as well as Open vSwitch 2.6.1 neutron agent (installed via the Cloudbase Open vSwitch installer).

Prior to standing up OpenStack in the past few weeks, we have had quite a number of customers hosted and managed manually on our network each with their own dedicated VLAN on our network. I am attempting to create provider networks for each customer where each network is configured to use each customers' existing, corresponding VLAN. For example:

  • Customer A is on VLAN 150
  • Customer B is on VLAN 200
  • Customer C is on VLAN 250
  • etc.

We want to create tenants in OpenStack for each customer, and then create a network for each customer's VLAN and assign it to the corresponding customer and allow customers to launch their own VMs on their dedicated VLANs on our network (with IPs from their subnet pool assigned to the VM automatically).

We have only configured ONE interface that we want to use with Open vSwitch on which OpenStack should be adding VMs. However, for some reason when OpenStack spins up a VM, we look at the Hyper-V settings for the VM and the network adapter is assigned to the wrong Hyper-V VMSwitch and the VLAN is not enabled or assigned.

Per the info below, the bridge br-back_end was created in OVS on the compute node. Port "Ethernet 2 Farm Nic" was added to the bridge. This is the physical interface where Customer A needs to be able to communicate on VLAN 150. Back-end zone is the virtual switch in Hyper-V that uses "Ethernet 2 Farm Nic".

We launched a VM for Customer A (which should be on VLAN 150). Per the info included below, when OpenStack launched the VM, interface/port "8e0a75d9-14a3-48d2-8526-cfdee2dc3cd8" was created automatically on the br-int OVS bridge. However, when looking at the settings for the instance in Hyper-V, it shows the instance is using "8e0a75d9-14a3-48d2-8526-cfdee2dc3cd8" on the Web zone VMSwitch. VLAN is not enabled in the adapter settings for the instance in Hyper-V and the VM (with DHCP turned on) is not picking up an IP address. (Screenshot of the Hyper-V adapter settings for the instance.)

Does anyone know why the Web zone VMSwitch is being assigned to the instance in Hyper-V and VLAN is not enabled for the adapter (with no VLAN assigned)? Per below, we need to be on VLAN 150 on the Ethernet 2 Farm Nic physical interface. The Back-end zone VMswitch uses the Ethernet 2 Farm Nic physical interface. The Web zone VMswitch uses some other physical interface that we do not want this VM to use. So, I'm not sure why the adapter for the instance is being attached to the Web zone VMswitch...

Does anyone have any ideas? Any thoughts or guidance would be GREATLY appreciated.

Here is our ovs-vsctl show output from the Hyper-V compute node:

PS C:\Windows ...