search

rcbops / opencenter

http://www.rackspace.com/cloud/private/openstack_software/
Other
9 stars 12 forks source link

[DE77]: Opencenter binds Keystone Admin Endpoint to Wrong IP #487

Closed seancarlisle closed 11 years ago

seancarlisle commented 11 years ago

Unfortunately I don't have documentation for this as I was an observer over a join.me connection. They entered relevant information for creating a new Nova cluster and the chef server was successfully created as well as the controller. When they tried to upload images, Opencenter changed the controller to red. After investigating, we discovered all services were throwing 400 errors. Further investigation revealed that when Opencenter had deployed the controller, it had bound keystone to an IP from a different interface which the customer had not specified in the create Nova cluster form. All other endpoints were bound to the correct IP address.

mancdaz commented 11 years ago

@seancarlisle

Are you able to get any information from their environment? Specifically, osops-network values (management, nova, public), and the ip/interface to which keystone was bound?

seancarlisle commented 11 years ago

@mancdaz

I spoke with the user earlier today to get the information you're requesting. Their specifications for IP ranges are as follows:

public: 192.168.2.0/24 NAT Exclusion CIDR: 172.16.1.0/24 management network address: 172.16.2.0/24 vm network CIDR: 172.16.3.0/24 internal network CIDR: 172.16.4.0/24

So I slightly amend my statement. It appears keystone was bound on 172.16.2.0/24, so that I believe is the correct range. However, all other service endpoints were bound to the 192.168.2.0/24 range. Shouldn't they have been bound to 172.16.2.0/24 as well?

mancdaz commented 11 years ago

@seancarlisle

The keystone api is slightly different to all the other services, as it has an admin-api on port 35357 and a public api on port 5000 (so basically 2 different services). The keystone cookbook is currently configured to bind the admin-api onto the 'nova' network, and the public api onto the 'public' network:

https://github.com/rcbops-cookbooks/keystone/blob/master/attributes/default.rb#L73-L81

All other API services by default get bound to the public network. For example cinder-api:

https://github.com/rcbops-cookbooks/cinder/blob/master/attributes/default.rb#L26-L29

So no, I'd expect to see this split in where services get bound (indeed I'd suggest that actually 172.16.2.0/24 is your 'nova', or internal, network rather than the management network, based on what you've said about where keystone got bound and the attributes in the cookbook)

Because the cookbooks use the keystone admin-api to do a lot of the keystone setup work, the nodes need to be able to access that network to hit the API when running the cookbooks/recipes.

mancdaz commented 11 years ago

Hi @seancarlisle

I'm going to close this as technically this isn't a bug. If you feel like this behaviour is incorrect, re-open and we can discuss.

Cheers Darren