On Wed, Apr 6, 2011 at 10:16 PM, Garrett Holmstrom gholms@fedoraproject.org wrote:
On 4/6/2011 11:49, brett lentz wrote:
On Wed, Apr 6, 2011 at 11:00 AM, Scott Hensonshenson@redhat.com wrote:
On Wed, 06 Apr 2011 13:20:50 -0400, Bill Peckbpeck@redhat.com wrote: I also am weary of what dependencies we have. I'm slightly loathed to require all of Django just to get cobbler up and running. On the other hand, I'm loathed to require a separate stack for cobbler and cobbler-web (assuming we used sqlalchemy + pure wsgi for cobbler).
I'm not familiar with how Django is broken up and whether you'll be able to rope in just the deps you need, or whether you'll end up pulling in all of Django.
Overall, I don't see this as a huge problem so long as the dependencies are packaged, the package manager handles this stuff. To me, worrying about dependency bloat at this stage sounds to me like premature optimization. As long as you're not roping in non-Django deps, I don't see the problem staying within the scope of the chosen framework.
The problem with dependency bloat is that there are more things in the stack below Cobbler that can go awry as things get updated or ported to more distros. On the other hand, if having cobbler and cobbler-web use separate web stacks makes things too difficult to maintain then adding more external dependencies may be the better option. I can't really give much of an opinion with regard to the web UI because of how little I have used it.
IMO, any supported interface into the backend needs to be a first class citizen. In other words, if the CLI can do it, the WebUI needs to be able to do it as well. Otherwise, what's the point of having it?
If the WebUI involves maintenance costs that are too expensive to keep up, dropping it is a valid option to consider, but it's an option I'd be sad to see selected.
Personally, I think the WebUI has a lot of potential. It's a good start, but there's so much more it can be built to do.
The distinct use-cases for a Cobbler WebUI that I can think of are:
1. A read-only "dashboard" to show to management. This could be considered a "server inventory" of sorts, complete with pretty graphs to show provisioning trends and reports that show a variety of "views" into what's provisioned and how it's all configured. I liken this to scratch an itch that I'd almost call "Smolt for Enterprises".
Currently, the WebUI doesn't really provide very much of this sort of functionality. But imagine if it did...
2. An alternative to the CLI. Some people just like WebUIs and prefer to click a web page rather than use a CLI. That's fine; there's nothing inherently wrong with that preference. So, the WebUI can allow people to provision systems via WebUI.
This is probably the use case the current WebUI seems closest to filling.
3. Yet Another Configuration Management Tool (or Helper). We've got mgmt_classes and ksmeta and cobbler-ext-nodes. Cobbler can do many tasks that overlap and complement config management tools like Puppet, Chef, etc. etc. The WebUI can be used as a focal point for delegation of CM responsibilities throughout an organization. Most IT organizations tend to divide into tiers that are allowed escalating levels of control over the environment. If Cobbler's ability to maintained fine-grained permissions is expanded, the WebUI could become the primary interface through which the "lower" tiers of an IT organization are allowed to toggle switches and flip bits that assign roles and configurations to systems.
Currently, the permissions modules aren't _really_ built for this, and the WebUI needs a lot of usability enhancements before it can do this job, but the basic foundation for this already exists and is waiting to be built upon.
---Brett.