Hey John-Paul, If you're looking to hack on the chef recipes on the admin node, then this is an easy way to do it:
1. Make your changes in /opt/dell/chef/cookbooks/nova/recipes/api.rb 2. Upload your changes to the chef server: a. cd /opt/dell/chef/cookbooks b. knife cookbook upload nova -o . 3. Wait for the next chef-client run, or run chef-client yourself on the target node Hope this helps! Chris Dell From: crowbar-bounces On Behalf Of John-Paul Robinson Sent: Monday, April 07, 2014 11:33 AM To: crowbar Subject: Re: [Crowbar] changing the keystone endpoints to use FQDN for publicURL instead of IP Thanks for the insights Adam. We have Crowbar 1.5. I think that puts us in betty release territory so this is our api.rb: https://github.com/crowbar/barclamp-nova/blob/release/betty/master/chef/cookbooks/nova/recipes/api.rb I checked on the helpers.rb code in roxy and it looks useful. I don't think I'll be able to use it directly in our version of crowbar because I don't think our deploy has information about host names. The example does clarify that all I'd really need to do is set the preferred host name statically. While it would be a dirty fix, I think I could get away with setting my host name statically on line 125 in our api.rb: https://github.com/crowbar/barclamp-nova/blob/release/betty/master/chef/cookbooks/nova/recipes/api.rb#L125 I don't mind this approach, at least as a first step. My issue really boils down to where to make changes when there are chef recipes to update: Do I: * edit the api.rb in the barclamp-nova under /opt/dell/barclamps/nova/chef/cookbooks/nova/recipes/api.rb and then install this updated barclamp -- if so how do I install the new barclamp? * edit the api.rb in the chef configuration under /opt/dell/chef/cookbooks/nova/recipes/api.rb and install the new recipie -- if so how do I best install the new recipe? * do something else? I'm confused on how I go from code update -> barclamp -> chef server. Is it possible to non-destructively (from the perspective of the nodes that have been provisioned by a barclamp) redeploy a barclamp after changing something like the cookbooks it contains? Thanks for any pointers. ~jpr On 04/04/2014 11:41 AM, Adam Spiers wrote: John-Paul Robinson ([email protected]<mailto:[email protected]>) wrote: Hi, I'm trying to enable nova client access to my controller deployed by crowbar from nodes that are not on the public/float network. In our environment the public/float network is a private address range that sits behind an additional firewall. I'd like to change the public URLs advertised by keystone to use FQDNs instead of IPs. I'm able to add a new FQDN-based endpoint directly using the keystone admin URL. However, it appears this is all managed by Chef since the new entry is removed within 15 minutes. Indeed there is a nova barclamp and installed nova cookbook on the admin node. It looks like the nova api.rb recipe is responsible for setting this value in the "register nova endpoint" section: endpoint_publicURL "http://#{public_api_ip}:8774/v2/$(tenant_id)s"<http://#{public_api_ip}:8774/v2/$(tenant_id)s> The public_api_ip comes from earlier in the recipe and is set from (likely) the Crowbar install parameters: public_api_ip = Chef::Recipe::Barclamp::Inventory.get_network_by_type(api, "public").address I'd like to change public_api_ip to my preferred FQDN of the controller. I'm assuming there is no variable that I can draw from to get this FQDN and am fine with starting off hard coding the value in the above variable definition (ugly but effective). What I don't fully grok yet, is where to make this change. I'm assuming it would be best to make it in Chef recipe housed in the nova barclamp and then update the barclamp in some way, which would update the registered nova cookbook with Chef, which would then change keystone on the controller. How do I do that? Which release are you using? In roxy (as used by SUSE Cloud 3), we already expose this as an option, and in fact the code handles several related issues: - if there is a preferred public name, it gets used - if not, the IP is used by default, although ... - if SSL is in use, the host's FQDN is used instead (so certificate validation works) - https protocol is used if SSL enabled - if keystone is running inside a Pacemaker cluster then HAproxy is automatically configured, a floating IP is set up for its frontend, together with an associated hostname in DNS which the other barclamps can then consume e.g. see https://github.com/crowbar/barclamp-nova/blob/release/roxy/master/chef/cookbooks/nova/recipes/api.rb#L59 This is achieved via shared helpers so that all barclamps consume endpoints in a consistent DRY manner: https://github.com/crowbar/barclamp-crowbar/blob/release/roxy/master/chef/cookbooks/utils/libraries/helpers.rb#L12 Sorry for beating this issue to death, but this is just a place where the Crowbar docs don't really (or appear to) help out much. Right :-/ But these are the kind of common use cases where we want to do the hard work so you don't have to ;-) _______________________________________________ Crowbar mailing list [email protected]<mailto:[email protected]> https://lists.us.dell.com/mailman/listinfo/crowbar For more information: http://crowbar.github.com/
_______________________________________________ Crowbar mailing list [email protected] https://lists.us.dell.com/mailman/listinfo/crowbar For more information: http://crowbar.github.com/
