I have the roadmap page here where I'm trying to list all the cool things I know of that are going on for the devel branch and who is working on them currently.
https://fedorahosted.org/cobbler/wiki/TheRoadmap
If I've left something off you might be working on, let me know on this list.
I hope this also gives folks and idea of all that's pouring into 1.8. This looks to be a very exciting release -- lots of big, long running features -- not just small stuff. I am excited.
1.6 was mainly a performance release (though also contained a lot of nice mini-features, and the new s390 PXE simulator), but I think this one will be bigger and better.
--Michael
I have had suse working for the import for quite some time. There is a few kinks I want to fix before releasing though. I also need to rebase as its been a while.
Corey On Apr 7, 2009, at 8:48 AM, Michael DeHaan wrote:
I have the roadmap page here where I'm trying to list all the cool things I know of that are going on for the devel branch and who is working on them currently.
https://fedorahosted.org/cobbler/wiki/TheRoadmap
If I've left something off you might be working on, let me know on this list.
I hope this also gives folks and idea of all that's pouring into 1.8. This looks to be a very exciting release -- lots of big, long running features -- not just small stuff. I am excited.
1.6 was mainly a performance release (though also contained a lot of nice mini-features, and the new s390 PXE simulator), but I think this one will be bigger and better.
--Michael _______________________________________________ cobbler-devel mailing list cobbler-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/cobbler-devel
Corey Osman wrote:
I have had suse working for the import for quite some time. There is a few kinks I want to fix before releasing though. I also need to rebase as its been a while.
Great! Do you have a github tree we can merge? Partially working is ok... you can fix the rest later.
import code shouldn't be too hard to rebase as not much of that has shifted around.
Thanks!
--Michael
Corey On Apr 7, 2009, at 8:48 AM, Michael DeHaan wrote:
I have the roadmap page here where I'm trying to list all the cool things I know of that are going on for the devel branch and who is working on them currently.
https://fedorahosted.org/cobbler/wiki/TheRoadmap
If I've left something off you might be working on, let me know on this list.
I hope this also gives folks and idea of all that's pouring into 1.8. This looks to be a very exciting release -- lots of big, long running features -- not just small stuff. I am excited.
1.6 was mainly a performance release (though also contained a lot of nice mini-features, and the new s390 PXE simulator), but I think this one will be bigger and better.
--Michael _______________________________________________ cobbler-devel mailing list cobbler-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/cobbler-devel
cobbler-devel mailing list cobbler-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/cobbler-devel
Michael,
I do have a git hub, but I am not sure how to move the git repo I cloned from the cobbler dev branch. If I just copied everything over wouldn't it bring all the ".git" files over as well which would mess with my own repo? Do I need to write a copy script that says "ignore all .git files"?
corey On Apr 7, 2009, at 11:07 AM, Michael DeHaan wrote:
Corey Osman wrote:
I have had suse working for the import for quite some time. There is a few kinks I want to fix before releasing though. I also need to rebase as its been a while.
Great! Do you have a github tree we can merge? Partially working is ok... you can fix the rest later.
import code shouldn't be too hard to rebase as not much of that has shifted around.
Thanks!
--Michael
Corey On Apr 7, 2009, at 8:48 AM, Michael DeHaan wrote:
I have the roadmap page here where I'm trying to list all the cool things I know of that are going on for the devel branch and who is working on them currently.
https://fedorahosted.org/cobbler/wiki/TheRoadmap
If I've left something off you might be working on, let me know on this list.
I hope this also gives folks and idea of all that's pouring into 1.8. This looks to be a very exciting release -- lots of big, long running features -- not just small stuff. I am excited.
1.6 was mainly a performance release (though also contained a lot of nice mini-features, and the new s390 PXE simulator), but I think this one will be bigger and better.
--Michael _______________________________________________ cobbler-devel mailing list cobbler-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/cobbler-devel
cobbler-devel mailing list cobbler-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/cobbler-devel
cobbler-devel mailing list cobbler-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/cobbler-devel
Corey Osman wrote:
Michael,
I do have a git hub, but I am not sure how to move the git repo I cloned from the cobbler dev branch. If I just copied everything over wouldn't it bring all the ".git" files over as well which would mess with my own repo? Do I need to write a copy script that says "ignore all .git files"?
You want to push your local git repo to your github.
Git will not transfer files that have not been added to git with "git add".
--Michael
corey On Apr 7, 2009, at 11:07 AM, Michael DeHaan wrote:
Corey Osman wrote:
I have had suse working for the import for quite some time. There is a few kinks I want to fix before releasing though. I also need to rebase as its been a while.
Great! Do you have a github tree we can merge? Partially working is ok... you can fix the rest later.
import code shouldn't be too hard to rebase as not much of that has shifted around.
Thanks!
--Michael
Corey On Apr 7, 2009, at 8:48 AM, Michael DeHaan wrote:
I have the roadmap page here where I'm trying to list all the cool things I know of that are going on for the devel branch and who is working on them currently.
https://fedorahosted.org/cobbler/wiki/TheRoadmap
If I've left something off you might be working on, let me know on this list.
I hope this also gives folks and idea of all that's pouring into 1.8. This looks to be a very exciting release -- lots of big, long running features -- not just small stuff. I am excited.
1.6 was mainly a performance release (though also contained a lot of nice mini-features, and the new s390 PXE simulator), but I think this one will be bigger and better.
--Michael _______________________________________________ cobbler-devel mailing list cobbler-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/cobbler-devel
cobbler-devel mailing list cobbler-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/cobbler-devel
cobbler-devel mailing list cobbler-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/cobbler-devel
cobbler-devel mailing list cobbler-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/cobbler-devel
I have the roadmap page here where I'm trying to list all the cool things I know of that are going on for the devel branch and who is working on them currently.
https://fedorahosted.org/cobbler/wiki/TheRoadmap
If I've left something off you might be working on, let me know on this list.
I hope this also gives folks and idea of all that's pouring into 1.8. This looks to be a very exciting release -- lots of big, long running features -- not just small stuff. I am excited.
1.6 was mainly a performance release (though also contained a lot of nice mini-features, and the new s390 PXE simulator), but I think this one will be bigger and better.
I see that django is also on the roadmap. Is there already an idea django will be used? There is some overlap with the UI preferences saving. For example is it worth spending time on the current webui to display customized tables?
Regards, Peter
This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.
I see that django is also on the roadmap. Is there already an idea django will be used? There is some overlap with the UI preferences saving. For example is it worth spending time on the current webui to display customized tables?
Regards, Peter
Peter, I've already begun work on porting the existing webui to django. This shouldn't stop you from contributing code though, as I'm basically creating a duplicate web interface for the time being. I plan on bringing all of the functionality over to the new one, until we're ready to cut over. If the customized tables code is javascript/css, bringing it over is extremely painless.
I see that django is also on the roadmap. Is there already an idea
django
will be used? There is some overlap with the UI preferences saving. For example is it worth spending time on the current webui to display customized tables?
Regards, Peter
Peter, I've already begun work on porting the existing webui to django. This shouldn't stop you from contributing code though, as I'm basically creating a duplicate web interface for the time being. I plan on bringing all of the functionality over to the new one, until we're ready to cut over. If the customized tables code is javascript/css, bringing it over is extremely painless.
I was thinking about using cheetah to create the customized tables. The configuration is available in the python hashes.
Can you explain how Django is going to be used or maybe provide your current work. For example is the CobblerWeb.py still used?
Peter
This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.
Vreman, Peter - Acision wrote:
I see that django is also on the roadmap. Is there already an idea
django
will be used? There is some overlap with the UI preferences saving. For example is it worth spending time on the current webui to display customized tables?
Regards, Peter
Peter, I've already begun work on porting the existing webui to django. This shouldn't stop you from contributing code though, as I'm basically creating a duplicate web interface for the time being. I plan on bringing all of the functionality over to the new one, until we're ready to cut over. If the customized tables code is javascript/css, bringing it over is extremely painless.
I was thinking about using cheetah to create the customized tables. The configuration is available in the python hashes.
Can you explain how Django is going to be used or maybe provide your current work. For example is the CobblerWeb.py still used?
Peter
This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.
cobbler-devel mailing list cobbler-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/cobbler-devel
The idea with Django is we need to move off of our custom "web framework" type infrastructure and stop relying on something as low level and non-standard as raw mod_python.
I think it's ok for you to go ahead and do what you are doing in Cobbler Web and we can easily port those ideas to the Django version as we get to them.
In the long term CobblerWeb will not be used, but nearly all of the code that is there is going to be ported. I think ideally we get the Django stuff a nice push (merging into devel very shortly) and we can get the init scripts and packaging done for it to where it will be easy to just add things to the Django bits.
Part of what I'd like to see for this, too, is a system that makes it much easier for people adding new fields to the web app. Right now it's a bit of core, which means some features in the CLI /aren't/ in the web app.
This /might/ mean a way of defining what the fields are, what HTML element to use, and what their tooltips are, and their orders are, in the item classes. This may also make the port easier.
I'm not entirely sure what that would mean for the network interface editor. Currently it's "very special" and could use some refactoring. I don't think this should end up being a straight port as there is obvious room for some eventual UI improvements.
When doing this we /do/ want to make sure all features get carried over though, so we are definitely not wanting to lose any of the nice work already done.
Getting the Django version moving ahead ASAP should enable this to be done easier.
--Michael
The idea with Django is we need to move off of our custom "web framework" type infrastructure and stop relying on something as low level and non-standard as raw mod_python.
I think it's ok for you to go ahead and do what you are doing in Cobbler Web and we can easily port those ideas to the Django version as we get to them.
In the long term CobblerWeb will not be used, but nearly all of the code that is there is going to be ported. I think ideally we get the Django stuff a nice push (merging into devel very shortly) and we can get the init scripts and packaging done for it to where it will be easy to just add things to the Django bits.
Part of what I'd like to see for this, too, is a system that makes it much easier for people adding new fields to the web app. Right now it's a bit of core, which means some features in the CLI /aren't/ in the web app.
This /might/ mean a way of defining what the fields are, what HTML element to use, and what their tooltips are, and their orders are, in the item classes. This may also make the port easier.
I'm not entirely sure what that would mean for the network interface editor. Currently it's "very special" and could use some refactoring. I don't think this should end up being a straight port as there is obvious room for some eventual UI improvements.
When doing this we /do/ want to make sure all features get carried over though, so we are definitely not wanting to lose any of the nice work already done.
Getting the Django version moving ahead ASAP should enable this to be done easier.
Thanks for the explanation.
I'll continue with the UI preferences using the current CobblerWeb. The core functionality is in the remote XMLRPC and can be reused.
I was also thinking that adding more information about the item fields is required. For example the header, default width of a column, output format, url format, action-function (e.g. for add/delete/rename).
Peter
This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.
Vreman, Peter - Acision wrote:
The idea with Django is we need to move off of our custom "web framework" type infrastructure and stop relying on something as low level and non-standard as raw mod_python.
I think it's ok for you to go ahead and do what you are doing in Cobbler Web and we can easily port those ideas to the Django version as we get to them.
In the long term CobblerWeb will not be used, but nearly all of the code that is there is going to be ported. I think ideally we get the Django stuff a nice push (merging into devel very shortly) and we can get the init scripts and packaging done for it to where it will be easy to just add things to the Django bits.
Part of what I'd like to see for this, too, is a system that makes it much easier for people adding new fields to the web app. Right now it's a bit of core, which means some features in the CLI /aren't/ in the web app.
This /might/ mean a way of defining what the fields are, what HTML element to use, and what their tooltips are, and their orders are, in the item classes. This may also make the port easier.
I'm not entirely sure what that would mean for the network interface editor. Currently it's "very special" and could use some refactoring. I don't think this should end up being a straight port as there is obvious room for some eventual UI improvements.
When doing this we /do/ want to make sure all features get carried over though, so we are definitely not wanting to lose any of the nice work already done.
Getting the Django version moving ahead ASAP should enable this to be done easier.
Thanks for the explanation.
I'll continue with the UI preferences using the current CobblerWeb. The core functionality is in the remote XMLRPC and can be reused.
I was also thinking that adding more information about the item fields is required. For example the header, default width of a column, output format, url format, action-function (e.g. for add/delete/rename).
Peter
This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.
cobbler-devel mailing list cobbler-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/cobbler-devel
How about a method on each object that returns a list:
def get_web_elements_format
return
[ fieldname, fieldtype (text, select, etc) fieldwidth, tooltip, ], [], [..]
We'd also need to do something clever to populate the fields... though that would make dual maintaince of the CLI and templates mostly go away.
For 2.0 (i.e. not now) we could also add a method that adds the CLI options for any command, moving the code out of the CLI modules just a bit... though I think folks have much less problem adding things to those so it's less important.
Right now CobblerWeb is just kind of weird.
--Michael
How about a method on each object that returns a list:
def get_web_elements_format
return
[ fieldname, fieldtype (text, select, etc) fieldwidth, tooltip, ], [], [..]
We'd also need to do something clever to populate the fields... though that would make dual maintaince of the CLI and templates mostly go away.
For 2.0 (i.e. not now) we could also add a method that adds the CLI options for any command, moving the code out of the CLI modules just a bit... though I think folks have much less problem adding things to those so it's less important.
Right now CobblerWeb is just kind of weird.
I think we can make it better common with the CLI reporting feature.
Def get_field_info() [fieldname] [fieldheader] [fieldtype] [width] { in characters } [tooltip]
Regards, Peter
This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.
Vreman, Peter - Acision wrote:
How about a method on each object that returns a list:
def get_web_elements_format
return
[ fieldname, fieldtype (text, select, etc) fieldwidth, tooltip, ], [], [..]
We'd also need to do something clever to populate the fields... though that would make dual maintaince of the CLI and templates mostly go away.
For 2.0 (i.e. not now) we could also add a method that adds the CLI options for any command, moving the code out of the CLI modules just a bit... though I think folks have much less problem adding things to those so it's less important.
Right now CobblerWeb is just kind of weird.
I think we can make it better common with the CLI reporting feature.
Def get_field_info() [fieldname] [fieldheader] [fieldtype] [width] { in characters } [tooltip]
Score.
Add "default value" too.
What's "field header"?
I think the web app could just list them in order and the CLI would sort the keys.
Technically, just to make sure we are on the same page:
get_field_info() return { "kernel_options" : { "field_type" : "dict", "width" : 255, "tooltip" : "kernel options, space delimited" } "foo" : ...
}
I think that would be just about perfect.
--Michael
Regards, Peter
This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.
cobbler-devel mailing list cobbler-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/cobbler-devel
I think we can make it better common with the CLI reporting feature.
Def get_field_info() [fieldname] [fieldheader] [fieldtype] [width] { in characters } [tooltip]
Score.
Add "default value" too.
What's "field header"?
I think the web app could just list them in order and the CLI would sort the keys.
Technically, just to make sure we are on the same page:
get_field_info() return { "kernel_options" : { "field_type" : "dict", "width" : 255, "tooltip" : "kernel options, space delimited" } "foo" : ...
}
I think that would be just about perfect.
Yes, this is also what I have I mind.
The field header is the column name in the Table and Report and in the current WebUI before the fields in the edit mode.
In the above example: "header" : "Kernel Options"
Peter
This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.
Here is a really trivial RFE for you. Don't display empty fields that aren't set to <<inherit>>. When you have a lot of network cards in a box and most of them only have the mac addresses in cobbler, it makes a report unweildy. If it only displayed non-null fields it would be much easier to read.
Jeff Schroeder wrote:
Here is a really trivial RFE for you. Don't display empty fields that aren't set to <<inherit>>. When you have a lot of network cards in a box and most of them only have the mac addresses in cobbler, it makes a report unweildy. If it only displayed non-null fields it would be much easier to read.
I like this idea a lot, though it should probably have an option for --show-all-fields or something.
In general, we need to generalize [sic] the reporting code so the more fancy action_report.py stuff and the printable() stuff in item*.py uses the same code.
Right now it is /slightly/ duplicated.
--Michael
Jeff Schroeder wrote:
Here is a really trivial RFE for you. Don't display empty fields that aren't set to <<inherit>>. When you have a lot of network cards in a box and most of them only have the mac addresses in cobbler, it makes a report unweildy. If it only displayed non-null fields it would be much easier to read.
Since this is an RFE, also file this at http://fedorahosted.org/cobbler please :)
List is good for conversation and getting things done -- Trac is good for remembering those ideas later when we want to knock off a few more RFEs.
Thanks!
Vreman, Peter - Acision wrote:
I think we can make it better common with the CLI reporting feature.
Def get_field_info() [fieldname] [fieldheader] [fieldtype] [width] { in characters } [tooltip]
Score.
Add "default value" too.
What's "field header"?
I think the web app could just list them in order and the CLI would sort the keys.
Technically, just to make sure we are on the same page:
get_field_info() return { "kernel_options" : { "field_type" : "dict", "width" : 255, "tooltip" : "kernel options, space delimited" } "foo" : ...
}
I think that would be just about perfect.
Yes, this is also what I have I mind.
The field header is the column name in the Table and Report and in the current WebUI before the fields in the edit mode.
In the above example: "header" : "Kernel Options"
++
Peter
This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.
cobbler-devel mailing list cobbler-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/cobbler-devel
Thanks for the explanation.
I'll continue with the UI preferences using the current CobblerWeb. The core functionality is in the remote XMLRPC and can be reused.
I was also thinking that adding more information about the item fields is required. For example the header, default width of a column, output format, url format, action-function (e.g. for add/delete/rename).
Peter
I think adding settings to control output format is a Bad Thing. You should not have your code care about the output format. Any customization to the user interface should be controlled via CSS.
As for adding methods to the objects to tell the display code what fields are available (and type, list of options, etc), is a Good Thing, and what mpdehaan outlined is exactly what I was going to propose.
James Cammarata wrote:
Thanks for the explanation.
I'll continue with the UI preferences using the current CobblerWeb. The core functionality is in the remote XMLRPC and can be reused.
I was also thinking that adding more information about the item fields is required. For example the header, default width of a column, output format, url format, action-function (e.g. for add/delete/rename).
Peter
I think adding settings to control output format is a Bad Thing. You should not have your code care about the output format. Any customization to the user interface should be controlled via CSS.
Replace "width" with "css_class" then? I like it a lot.
As for adding methods to the objects to tell the display code what fields are available (and type, list of options, etc), is a Good Thing, and what mpdehaan outlined is exactly what I was going to propose.
Michael DeHaan wrote:
James Cammarata wrote:
Thanks for the explanation.
I'll continue with the UI preferences using the current CobblerWeb. The core functionality is in the remote XMLRPC and can be reused.
I was also thinking that adding more information about the item fields is required. For example the header, default width of a column, output format, url format, action-function (e.g. for add/delete/rename).
Peter
I think adding settings to control output format is a Bad Thing. You should not have your code care about the output format. Any customization to the user interface should be controlled via CSS.
Replace "width" with "css_class" then? I like it a lot.
As for adding methods to the objects to tell the display code what fields are available (and type, list of options, etc), is a Good Thing, and what mpdehaan outlined is exactly what I was going to propose.
cobbler-devel mailing list cobbler-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/cobbler-devel
Additional, we can further automate this by including what writer each field uses and also what the CLI option is named.
If a field is "kernel_options" in terms of implementation, it might be --kopts, and the setter is "set_kernel_options".
That way we can build the CLI, as well as the code to apply the CLI changes (and the webapp) mostly programatically.
Minor snags will be hit when dealing with network interfaces, I'd suspect, we'll see.
cobbler-devel@lists.fedorahosted.org