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 (j...@uab.edu) 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" >> >> 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 > Crowbar@dell.com > https://lists.us.dell.com/mailman/listinfo/crowbar > For more information: http://crowbar.github.com/
_______________________________________________ Crowbar mailing list Crowbar@dell.com https://lists.us.dell.com/mailman/listinfo/crowbar For more information: http://crowbar.github.com/
