Chris, This looks very helpful. I'll follow that approach and report back.
Thanks! ~jpr On 04/08/2014 07:43 AM, christopher_dearb...@dell.com wrote: > > 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 (j...@uab.edu <mailto: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" > <http://#%7Bpublic_api_ip%7D:8774/v2/$%28tenant_id%29s> > > > > 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 <mailto: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/
