On Fri, 15 May 2009 18:12:11 -0400, Michael DeHaan mdehaan@redhat.com wrote:
It's been a good week as I've managed to gut TONS of code all over cobbler in the last several days, making it infinitely easier to add new fields. We're not there yet, but it's getting quite close, and this is the only thing I'm working on in Cobbler until it's done.
50 files changed, 2955 insertions(+), 5603 deletions(-)
I have the "FIELDS" behavior pretty well as I would like in item_*.py right now. There are a few hints the webapp needs missing that I need to add next week.
The new fields structures didn't conform to /generic_edit/list/etc/ so forth in the Wiki, so I'll probably be having to overhaul that a small
bit.
I admit I completely do not understand the "do_multi" code and so forth in the web app -- it's missing comments and risks being a casuality if I can't figure it out. AFAIK, this handles some of the batch options but is not generalized as there aren't templates for that sort of thing.
I also have to go back through the code and re-add the "is valid" checker code, that looks for inconsistencies between multiple fields on the same object, right now that was a bit of a casuality of the field cleanup.
I also suspect I might have broke minor options to the CLI like "delete interface", "clobber", and "in place" ... delete-interface being rather important, the others, if lost in the architecture shuffle, not so important.
I think as we go on further, cobbler will have a much better web app, and we'll need obscure CLI options (for things like editing a small part of a hash) a bit less.
Anyway, the web UI is /rather/ torn up at the moment, though I noted that if the actual web app doesn't point to the generic listing templates, no one is going to test them, so it was better to force them to point to the templates, and fix what was there, rather than still point to any of the old pages.
This should ensure we are using all of the newness, and none of the oldness.
Perhaps after all of these gets done, snippets and ksfiles can be similarly edited behind the scenes so they work as collections, even if they do not actually have CLI functions for manipulating them and really aren't collections. (after all, settings is kind of a pseudo-collection). In which case, snippet editing and kickstart file editing could also be handled by the common templates.
From Peter's original work, several fields are going away -- we won't have width and height info. I imagine each field will have a CSS class field to assign to it (optional) and that is about it. Keeps things simple. I also need to go back through the fields and add two things -- the name of the HTML element to use for it, and for radio buttons, a list of valid choices. We may also add back in the concept of a field grouping, when done, which would affect both CLI sorting and color coding of like fields in the WUI, for instance, keeping power options color coded differently than virt options.
Anyway, stay tuned... I suspect by the end of next week it should be mostly reassembled and back together in a rather nice state.
For those with outstanding patches, you are not forgotten -- I'll look at these once all of this gets applied. This will take precedence since until it's done, nothing really works and there is no base to test patches against :)
I see you've taken the get_fields() stuff out of remote.py and made it local to django/views.py, like so:
def get_fields(what): if what == "distro": f = item_distro.FIELDS if what == "profile": f = item_profile.FIELDS if what == "system": f = item_system.FIELDS if what == "repo": f = item_repo.FIELDS if what == "image": f = item_image.FIELDS if what == "network": f = item_network.FIELDS
However, we're not currently importing any of these. Should we? Doesn't that imply that cobbler-web will require cobbler? The good thing about keeping this in remote was that cobbler-web could be run from an entirely different machine than the main cobbler server, now we'll either have to bundle those files with the cobbler-web package or require the cobbler rpm be installed.