On Tue, 12 Feb 2013 23:50:25 -0700 Clint Savage <herlo1@xxxxxxxxx> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > I'd like to throw my ideas into the ring. I've spent a bunch of time > thinking about this from a slightly different perspective, one of > flexibility and usefulness to the Formula contributor. > > I've taken the time to put together a github repository with some code > (the code is just a prototype and should not be considered yet) and a > fairly thought out README file. You can read this at > https://github.com/herlo/formulas/blob/master/README.rst at your > leisure. > > So far, I agree with pretty much everything put forward with a few > exceptions. Here is my take on this... > > - - Delivery and Development - > > Using git is definitely a must! It should be used to develop formulas > and submit them for approval. This works well with the github fork and > pull request model. Take an 'approved' formula and improve upon it. Or > make a new one, it doesn't matter. The value is gained in a pull > request, code review and approval. This definitely helps speed > development of formulas. Sure. I'm not sure we want to host all the formulas at github though. I guess thats something to think about. > A GUI is definitely a must as well. Integrating with Anaconda is a > great idea, but may take a bit longer than desired to get in place. A > simple GUI that can be searched is a definite must. But how do you > test new formulas using the GUI? Just something to consider here. Yep. I want a command line version as well. Testing gui's can be tricky, I think our only option there is to use a peer review type setup where a formula maintainer reviews someone elses formula and provides feedback. With a command line tool we could run automated testing to some degree as well as script some checking/linting on the playbooks themselves. > - - Flexibility is Key - > > Being flexible is important, both to those who create as well as those > who will use formulas. If we stick to one configuration management > system, we lose some flexibility and choice. It seems ansible is the > choice most want, but what is the harm in having alternates available? I think the harm is confusion, spreading of resources and difficulty in testing/qa/infrastructure. If we have a base set of templates for say ansible, and someone makes a formula in puppet, that could very well behave differently. > Limiting the choices here limits what a formulas developer could > create because even though it seems like it, all CM systems are not > created equal. Well, in the same way limiting Fedora to rpms is limiting. ;) Sure, we could ship debs too, but... > - - Contributor and End User Friendly - > > At the risk of becoming the straw man (please be gentle), I suggest we > consider an approach that allows for any number of backends. In other > words, I would like to develop formula in the CM system I choose, or > at least have a choice between a number of them. Well, I suppose if you really really had to use cfengine for a formula you could write a small ansible wrapper that installed cfengine and ran it's commands. However, I am not sure this really has that many advantages. > This suggestion is not without its challenges. For one, there's the > consideration of the presentation and the user. How would the user > know which backend it's using. Hopefully they wouldn't, nor would they > care. It may require installing yet another package to work. I'm not > sure how this would work yet, but think it's worth considering. Well, or collection of packages. I don't think this is the big hurdle... > Additionally, there would have to be considerations made in the > repository for how to determine which backend said formula is using. > This problem could be easily overcome in many ways, however, simply > using a configuration value in the manifest Pete suggested below would > be simple enough. Sure. I don't think thats the problem though. I think QA, impossible documentation requirements, differing behavior, lack of area knowledge in all the various possibly CM's, dependency on many more tools/stacks are all the problems. I don't like the idea we would have: "Hey, contributor, you want to contribute a formula! great! So, first look at all the docs of ansible, puppet, cfengine, chef, salt, bcfg2, cdist, juju, and pick which one you want write your formula in" > If the end user is the most important thing, we'd need to make a way > to filter for the installed backend(s), or inform them of a need for > additional packages. Maybe requiring them to use yum or package kit to > install said packages. > > In terms of contributors, we want more, right? So let's consider a way > that makes it easier for them to contribute something simple to use in > their own way. Let's be flexible about it and make it easy to > contribute. If they want to use puppet instead of ansible, or salt > instead or bcfg2 for that matter, let's figure out a way to make that > possible and make it easy on our end users to boot. I think this might lead to lots of confusion... > It seems logical to me that we could use a limited set of CM engines > to accomplish this goal. Maybe we should consider some criteria for > what CM tool(s) would be useful with formulas. I think we should look at picking one. ;) kevin
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ formulas-devel mailing list formulas-devel@xxxxxxxxxxxxxxxxxxxxxx https://lists.fedorahosted.org/mailman/listinfo/formulas-devel
