Keith, thanks for the initial feedback. Some comments and lots of questions in-line.
On 03/18/2014 09:34 PM, Keith Hudgins wrote: > If you want to modify the existing cookbooks as they are, option A > would be the best. Especially if you want to add your own recipes to > the chef server over and above what it ships with. > By endorsing option A I assume you mean, don't try to maintain a history connection with the cookbooks installed via Crowbar. Instead treat them as a pristine site state into which you merge code from the community repository according to local site requirements and convetions. Is that a fair interpretation? > However... > > please note that, by default, your Crowbar client nodes will look > directly to the crowbar server for its package repository. So if you > want to install anything else, you'll need to either open up your > client nodes to an external repo, or shove 'em into your admin node. > As a first step, I'm not as interested in add new packages to the nodes (that's coming) but more interested in how tune/update the behavior of an install service, eg. switch OpenStack to using HTTPS instead of HTTP. On the topic of the repo, however, poking around reveals there is an Ubuntu repo space under /tftpboot on the admin node and all the clients consume repo information from its state. Is it possible to treat this as a normal ubuntu repo mirror. That is, sync it from some upstream mirrors and then use it as the foundation for further local installs? Or would it be better to open the clients to an external repo and skip the need to modify/maintain the /tftpboot/ubuntu* tree? What are the hazards in adding too or updating the Ubuntu OS bits? I'm assuming they are subtle. > What I'd recommend over and above all of these options is to dig into > the barclamps and understand how they're written and what to do with > them. Clone an individual barclamp from its github repo and work on > it. Then, you can package up the barclamp and import it into your > admin node using the tools already there. It's a bit more work (and > you'll want to set up a crowbar build node) but the docs are pretty > clear, and that'll get you involved in the overall development effort. > Fair enough, however, there are many things that remain unclear about this path. I've poked around the crowbar docs again, while they do exists, they have a steep curve. Maybe I'm making more sense of them on this round. As I understand it, building the deviso as a devloper forks all the barclamps into your github account. This then becomes the way that you hook up a development environment for further barclamp modification. The chef cookbook changes would come along by way of updating the barclamps that contain them. If this is the case, I'd expect to find some evidence of Chef cookbook "grabs" of specific versions from the Chef community portal and that the might exist as merges in the barclamp history. Listing the cookbooks in the Chef server shows them to all be "tagged" with their Community portal version number, so I assume this is well known information. Casual browsing of some barclamps on github doesn't reveal this history immediately. Am I not looking hard enough? In general, the assumption for the engage-with-crowbar approach seems to be "build an an iso and deploy" but what happens after day 1? What do you do to tune the crowbar-provisioned environment? If I have a dev space of the crowbar iso, how do I integrate improvements into the already running servers. Can I upload new barclamps into crowbar and deploy them non-destructively to my running nodes? What's the feed forward path into the environment via Crowbar for modifications to a barclamp that may purely be contained within the boundaries of a Chef cookbook. When I've asked previously, the suggestion appeared to be "tweak the internal chef state", hence my original proposal to hook into chef below. Complicating this further, we have a Crowbar 1.5 environment, which I don't think is fully reconstructable due to some proprietary bits that remained before the 1.6 release. I know there isn't an defined upgrade path in crowbar. I'm not asking for one. I'm wondering if its possible, through some effort, to create a site specific upgrade experience (updating crowbar, chef, os, openstack, etc in coordinated bits). A lot of questions for one thread, but I hope they help sketch out my landscape a little better and maybe elicit some best-practices feedback. Thanks for the initial comments. Hope you can clarify a bit further on the main point of hooking into the Chef "backend" vs. feeding in barclamp changes via Crowbar. ~jpr > > On Tue, Mar 18, 2014 at 4:44 PM, John-Paul Robinson <j...@uab.edu > <mailto:j...@uab.edu>> wrote: > > Hi, > > I'd like to more actively control the innards of our Crowbar > provisioned > OpenStack plus Ceph fabric via it's Crowbar-provisioned Chef harness. > > My outline for doing this is: > > 1) clone the basic chef-repo from github > 2) connect this git repo with a user account on our crowbar-chef > server > 3) incorporate the cookbooks installed on our chef server into the > chef-repo > 4) modify cookbooks and knife upload them to our chef-server to apply > them to our fabric > > Step 3 appears to have several approaches: > > a) use knife list and knife cookbook download to copy all the > cookbooks > on the running chef server to the cookbooks dir of the new chef-repo, > check them into git, work on them, the knife cookbook upload the > changed > cookbooks to have them go into effect. This makes the repo start from > the existing state of the chef server. Improvements to cookbooks are > connected with upstream versions and > integration/improvements/"backports" all lie in our hands. > > b) use knife list to get cookbook versions and then knife cookbook > site > install <cookbook> <version-in-our-chef-server> to integrate the > community repo's "pristine" cookbook into our new chef-repo. This has > the advantage of the in-build vendor branch model. However, I've > noticed that even at the same cookbook version numbers, there are > differences between the cookbook in our chef-server and the pristine > upstream cookbook in the community portal. This suggests we have a > second stage of knife cookbook download that adds and commits the > existing crowbar-deployed chef cookbooks on top of the foundation from > the community portal. After all this, we can start to upload cookbook > changes and we have a "connection" with the community portal's > releases > via the vendor branch model of site install for future enhancements. > > c) use knife list to get cookbook versions then git clone the > individual > cookbooks of correct version directly from the git hub repos. > This has > the advantage of full history information from upstream in our > chef-repo > development environment. It also seems like the easiest (only?) > way to > readily push improvements features upstream. We'd still need to > configure some sort of merge-with-existing-crowbar-cookbooks > process and > then have an integration workflow merge upstream and local changes. > > Am I on the right track here? > > Option c appeals to me from the "dev" perspective but are there > practical considerations that suggest b or a as better solutions? > > Is there already a way to do this that I just haven't read about yet? > > And finally, why, when the versions of a cookbook in the > crowbar-deployed chef-server match an upstream release from the > community portal, are there differences in the code bases. Is there a > way to see where/why these difference originated? > > Thanks, > > ~jpr > > _______________________________________________ > 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/ > > > > > -- > -- > Keith Hudgins - Cloud Engineering Solutions > Enstratius - The Enterprise Cloud Management Solution, now a part of Dell > P: 612-746-3091 | C: 678-512-2959 > www.enstratius.com <http://www.enstratius.com/> | @keithudgins
_______________________________________________ Crowbar mailing list Crowbar@dell.com https://lists.us.dell.com/mailman/listinfo/crowbar For more information: http://crowbar.github.com/
