I've added a new link "Tasks" right below settings that shows all tasks.
From this page you can see all the background tasks (currently all run as soon as they are fired, so the idea of a "scheduled" state will soon go away in favor of just "running").
Since we have this, the next steps are to add links to a reposync button to the Web app (easy, of course) and also make sync and the power actions run in the background.
For actions that run in the background, ideally there should be some brief notification to the user (i.e. "simple global 'flash' notification DIV trick") to show that there is a background task and to link to the status page so folks can view the log for that task from the web app.
I'm doing that next.
This will make our web application *much* more functional, so I'm excited about this one.
Currently task ID's are integers -- I'm going to change this so they are named after the time and are human readable, making the logfile directories easier to understand. We'll add a logrotate rule that does cleanup after a reasonable interval. Currently tasks disappear from the cobblerd after either cobblerd is restarted or 24 hours, whichever comes first. I'm not sure the 24 hour number is a good one, I should probably make it a week or two. We could also link to all logfiles in /var/log/cobbler/tasks even if there isn't a task record for them, but I think that might be overkill. Not sure.
Comments welcome.
We're going to keep this simple for starters until we can get more things using the task bits.
(It might also be nice if we could have the webapp flash notification area also post if any tasks have changed status, perhaps in some sort of AJAXY or simulated-AJAXY sort of way, but that can be done later)
--Michael
On Mon, Jul 6, 2009 at 3:09 PM, Michael DeHaanmdehaan@redhat.com wrote: ...
(It might also be nice if we could have the webapp flash notification area also post if any tasks have changed status, perhaps in some sort of AJAXY or simulated-AJAXY sort of way, but that can be done later)
Something like this updating with xmlhttprequest would be very eyecandy-rific http://jsgrowl.com. The ZenOSS monitoring system uses jsgrowl or something visually identical via ajax to complain about connection failures or whatnot gracefully.
It would be up to you as to which js library to use but jquery seems very solid imo.
On Mon, 6 Jul 2009 16:03:07 -0700, Jeff Schroeder jeffschroed@gmail.com wrote:
On Mon, Jul 6, 2009 at 3:09 PM, Michael DeHaanmdehaan@redhat.com wrote: ...
(It might also be nice if we could have the webapp flash notification area also post if any tasks have changed status, perhaps in some sort of AJAXY or simulated-AJAXY sort of way, but that can be done later)
Something like this updating with xmlhttprequest would be very eyecandy-rific http://jsgrowl.com. The ZenOSS monitoring system uses jsgrowl or something visually identical via ajax to complain about connection failures or whatnot gracefully.
It would be up to you as to which js library to use but jquery seems very solid imo.
DO WANT!!!
Seriously, that is very smooth, and would be a cool addition. You could use it to popup errors from the log too, or when other events happen like another user on the system does something (adds/deletes/edits something).
On Mon, 06 Jul 2009 21:05:37 -0500, James Cammarata jimi@sngx.net wrote:
On Mon, 6 Jul 2009 16:03:07 -0700, Jeff Schroeder jeffschroed@gmail.com wrote:
On Mon, Jul 6, 2009 at 3:09 PM, Michael DeHaanmdehaan@redhat.com
wrote:
...
(It might also be nice if we could have the webapp flash notification area also post if any tasks have changed status, perhaps in some sort
of
AJAXY or simulated-AJAXY sort of way, but that can be done later)
Something like this updating with xmlhttprequest would be very eyecandy-rific http://jsgrowl.com. The ZenOSS monitoring system uses jsgrowl or something visually identical via ajax to complain about connection failures or whatnot gracefully.
It would be up to you as to which js library to use but jquery seems very solid imo.
DO WANT!!!
Seriously, that is very smooth, and would be a cool addition. You could use it to popup errors from the log too, or when other events happen like another user on the system does something (adds/deletes/edits something).
I have preliminary support for this working on my personal repo, no commits to github yet though. Basically it just pops up a message when you load the index page, but it's working :)
On 07/06/2009 10:05 PM, James Cammarata wrote:
On Mon, 6 Jul 2009 16:03:07 -0700, Jeff Schroederjeffschroed@gmail.com wrote:
On Mon, Jul 6, 2009 at 3:09 PM, Michael DeHaanmdehaan@redhat.com wrote: ...
(It might also be nice if we could have the webapp flash notification area also post if any tasks have changed status, perhaps in some sort of AJAXY or simulated-AJAXY sort of way, but that can be done later)
Something like this updating with xmlhttprequest would be very eyecandy-rific http://jsgrowl.com. The ZenOSS monitoring system uses jsgrowl or something visually identical via ajax to complain about connection failures or whatnot gracefully.
It would be up to you as to which js library to use but jquery seems very solid imo.
DO WANT!!!
Seriously, that is very smooth, and would be a cool addition. You could use it to popup errors from the log too, or when other events happen like another user on the system does something (adds/deletes/edits something).
I agree it's slick.
I think there is currently some annoying legal problem with the compressor that jQuery uses to make it "fast", so we would have to run the uncompressed one though if we shipped it with Cobbler though ... grr! I'm not sure how slow that would be, but it would be worth trying just to get the stylepoints.
(FWIW, the way apps typically do the flash stuff is just a session variable making a DIV show up)
--Michael
On Tue, Jul 7, 2009 at 9:01 AM, Michael DeHaanmdehaan@redhat.com wrote: ...
I think there is currently some annoying legal problem with the compressor that jQuery uses to make it "fast", so we would have to run the uncompressed one though if we shipped it with Cobbler though ... grr! I'm not sure how slow that would be, but it would be worth trying just to get the stylepoints.
(FWIW, the way apps typically do the flash stuff is just a session variable making a DIV show up)
Legal problems? Seriously? Can you provide a link or some background on this? Google isn't showing much from a cursory glance. If there are legal problems however, just use the yui minimizer[1]. If there were legal problems yahoo would have taken it down a very long time ago.
[1] http://developer.yahoo.com/yui/compressor/
On 07/07/2009 12:09 PM, Jeff Schroeder wrote:
On Tue, Jul 7, 2009 at 9:01 AM, Michael DeHaanmdehaan@redhat.com wrote: ...
I think there is currently some annoying legal problem with the compressor that jQuery uses to make it "fast", so we would have to run the uncompressed one though if we shipped it with Cobbler though ... grr! I'm not sure how slow that would be, but it would be worth trying just to get the stylepoints.
(FWIW, the way apps typically do the flash stuff is just a session variable making a DIV show up)
Legal problems? Seriously? Can you provide a link or some background on this? Google isn't showing much from a cursory glance. If there are legal problems however, just use the yui minimizer[1]. If there were legal problems yahoo would have taken it down a very long time ago.
I'll follow up on this with Toshio and others and let you know.
The problem was, IIRC, that the program to compress things was not permissible in Fedora.
However that appears to imply BSD, so let me see what the hold-up was.
--Michael
On 07/07/2009 12:13 PM, Michael DeHaan wrote:
On 07/07/2009 12:09 PM, Jeff Schroeder wrote:
On Tue, Jul 7, 2009 at 9:01 AM, Michael DeHaanmdehaan@redhat.com wrote: ...
I think there is currently some annoying legal problem with the compressor that jQuery uses to make it "fast", so we would have to run the uncompressed one though if we shipped it with Cobbler though ... grr! I'm not sure how slow that would be, but it would be worth trying just to get the stylepoints.
(FWIW, the way apps typically do the flash stuff is just a session variable making a DIV show up)
Legal problems? Seriously? Can you provide a link or some background on this? Google isn't showing much from a cursory glance. If there are legal problems however, just use the yui minimizer[1]. If there were legal problems yahoo would have taken it down a very long time ago.
I'll follow up on this with Toshio and others and let you know.
The problem was, IIRC, that the program to compress things was not permissible in Fedora.
However that appears to imply BSD, so let me see what the hold-up was.
--Michael
cobbler-devel mailing list cobbler-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/cobbler-devel
It seems rhino prefered Sun's JRE but may now work. Apparently "dojo shrinksafe" is also good.
These tools aren't packaged for Fedora yet -- but should be -- in which case it seems we can include compressed versions now provided we include links to the sources (and such) for GPL compliance reasons.
Once Fedora has packaging guidelines we'll need to use the versions that ship with Fedora, leaving us somewhat subject to changing API interfaces and such.
(Ah the niceness of just being able to say you are upstream...though we have to work with what we have)
So, given all that, it looks like we can include jQuery compressed verisons and not do a lot of stuff ourselves. Which is, of course, awesome.
--Michael
On Tue, 07 Jul 2009 12:21:59 -0400, Michael DeHaan mdehaan@redhat.com wrote:
On 07/07/2009 12:13 PM, Michael DeHaan wrote:
On 07/07/2009 12:09 PM, Jeff Schroeder wrote:
On Tue, Jul 7, 2009 at 9:01 AM, Michael DeHaanmdehaan@redhat.com wrote: ...
I think there is currently some annoying legal problem with the compressor that jQuery uses to make it "fast", so we would have to run the uncompressed one though if we shipped it with Cobbler though ... grr! I'm not sure how slow that would be, but it would be worth trying just to get the stylepoints.
(FWIW, the way apps typically do the flash stuff is just a session variable making a DIV show up)
Legal problems? Seriously? Can you provide a link or some background on this? Google isn't showing much from a cursory glance. If there are legal problems however, just use the yui minimizer[1]. If there were legal problems yahoo would have taken it down a very long time ago.
I'll follow up on this with Toshio and others and let you know.
The problem was, IIRC, that the program to compress things was not permissible in Fedora.
However that appears to imply BSD, so let me see what the hold-up was.
--Michael
cobbler-devel mailing list cobbler-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/cobbler-devel
It seems rhino prefered Sun's JRE but may now work. Apparently "dojo shrinksafe" is also good.
These tools aren't packaged for Fedora yet -- but should be -- in which case it seems we can include compressed versions now provided we include links to the sources (and such) for GPL compliance reasons.
Once Fedora has packaging guidelines we'll need to use the versions that ship with Fedora, leaving us somewhat subject to changing API interfaces and such.
(Ah the niceness of just being able to say you are upstream...though we have to work with what we have)
So, given all that, it looks like we can include jQuery compressed verisons and not do a lot of stuff ourselves. Which is, of course, awesome.
--Michael
Looking at the minimized version, it just looked like javascript with all whitespace stripped. If there are legal ramifications for that...
On 07/07/2009 12:50 PM, James Cammarata wrote:
On Tue, 07 Jul 2009 12:21:59 -0400, Michael DeHaanmdehaan@redhat.com wrote:
On 07/07/2009 12:13 PM, Michael DeHaan wrote:
On 07/07/2009 12:09 PM, Jeff Schroeder wrote:
On Tue, Jul 7, 2009 at 9:01 AM, Michael DeHaanmdehaan@redhat.com wrote: ...
I think there is currently some annoying legal problem with the compressor that jQuery uses to make it "fast", so we would have to run the uncompressed one though if we shipped it with Cobbler though ... grr! I'm not sure how slow that would be, but it would be worth trying just to get the stylepoints.
(FWIW, the way apps typically do the flash stuff is just a session variable making a DIV show up)
Legal problems? Seriously? Can you provide a link or some background on this? Google isn't showing much from a cursory glance. If there are legal problems however, just use the yui minimizer[1]. If there were legal problems yahoo would have taken it down a very long time ago.
I'll follow up on this with Toshio and others and let you know.
The problem was, IIRC, that the program to compress things was not permissible in Fedora.
However that appears to imply BSD, so let me see what the hold-up was.
--Michael
cobbler-devel mailing list cobbler-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/cobbler-devel
It seems rhino prefered Sun's JRE but may now work. Apparently "dojo shrinksafe" is also good.
These tools aren't packaged for Fedora yet -- but should be -- in which case it seems we can include compressed versions now provided we include links to the sources (and such) for GPL compliance reasons.
Once Fedora has packaging guidelines we'll need to use the versions that ship with Fedora, leaving us somewhat subject to changing API interfaces and such.
(Ah the niceness of just being able to say you are upstream...though we have to work with what we have)
So, given all that, it looks like we can include jQuery compressed verisons and not do a lot of stuff ourselves. Which is, of course, awesome.
--Michael
Looking at the minimized version, it just looked like javascript with all whitespace stripped. If there are legal ramifications for that...
That's good.
The issue was, I believe, the ability for Fedora to be recreated and rebuilt with 100% free components, and there were some issues around where Rhino would run. I'm being told that no longer applies.
Personally I agree with you here, I'm only 99.95% pure on that issue :)
Regardless we need to make sure that inclusion of such, even before guidelines, doesn't mean we're doing something that is not acceptable to Fedora, since being in yum is important... and those are the conditions we work with.
It sounds like they no longer are, so we are free to do what we want now, and may only have to make minor changes when guidelines for proper web library packaging come about (which, I guess, were delayed by said requirements).
--Michael
On 07/07/2009 12:50 PM, James Cammarata wrote:
On Tue, 07 Jul 2009 12:21:59 -0400, Michael DeHaanmdehaan@redhat.com wrote:
On 07/07/2009 12:13 PM, Michael DeHaan wrote:
On 07/07/2009 12:09 PM, Jeff Schroeder wrote:
On Tue, Jul 7, 2009 at 9:01 AM, Michael DeHaanmdehaan@redhat.com wrote: ...
I think there is currently some annoying legal problem with the compressor that jQuery uses to make it "fast", so we would have to run the uncompressed one though if we shipped it with Cobbler though ... grr! I'm not sure how slow that would be, but it would be worth trying just to get the stylepoints.
(FWIW, the way apps typically do the flash stuff is just a session variable making a DIV show up)
Legal problems? Seriously? Can you provide a link or some background on this? Google isn't showing much from a cursory glance. If there are legal problems however, just use the yui minimizer[1]. If there were legal problems yahoo would have taken it down a very long time ago.
I'll follow up on this with Toshio and others and let you know.
The problem was, IIRC, that the program to compress things was not permissible in Fedora.
However that appears to imply BSD, so let me see what the hold-up was.
--Michael
cobbler-devel mailing list cobbler-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/cobbler-devel
It seems rhino prefered Sun's JRE but may now work. Apparently "dojo shrinksafe" is also good.
These tools aren't packaged for Fedora yet -- but should be -- in which case it seems we can include compressed versions now provided we include links to the sources (and such) for GPL compliance reasons.
Once Fedora has packaging guidelines we'll need to use the versions that ship with Fedora, leaving us somewhat subject to changing API interfaces and such.
(Ah the niceness of just being able to say you are upstream...though we have to work with what we have)
So, given all that, it looks like we can include jQuery compressed verisons and not do a lot of stuff ourselves. Which is, of course, awesome.
--Michael
Looking at the minimized version, it just looked like javascript with all whitespace stripped. If there are legal ramifications for that...
Also, was your (not committed yet) version using jQuery? If so, can you commit it?
I want to start playing with this (and would right start now) but would not want to cause conflicts with what you already had.
--Michael
On Tue, 07 Jul 2009 14:13:18 -0400, Michael DeHaan mdehaan@redhat.com wrote:
On 07/07/2009 12:50 PM, James Cammarata wrote:
On Tue, 07 Jul 2009 12:21:59 -0400, Michael DeHaanmdehaan@redhat.com wrote:
On 07/07/2009 12:13 PM, Michael DeHaan wrote:
On 07/07/2009 12:09 PM, Jeff Schroeder wrote:
On Tue, Jul 7, 2009 at 9:01 AM, Michael DeHaanmdehaan@redhat.com wrote: ...
I think there is currently some annoying legal problem with the compressor that jQuery uses to make it "fast", so we would have to run the uncompressed one though if we shipped it with Cobbler though ... grr! I'm not sure how slow that would be, but it would be worth trying just to get the stylepoints.
(FWIW, the way apps typically do the flash stuff is just a session variable making a DIV show up)
Legal problems? Seriously? Can you provide a link or some background on this? Google isn't showing much from a cursory glance. If there
are
legal problems however, just use the yui minimizer[1]. If there were legal problems yahoo would have taken it down a very long time ago.
I'll follow up on this with Toshio and others and let you know.
The problem was, IIRC, that the program to compress things was not permissible in Fedora.
However that appears to imply BSD, so let me see what the hold-up was.
--Michael
------------------------------------------------------------------------
cobbler-devel mailing list cobbler-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/cobbler-devel
It seems rhino prefered Sun's JRE but may now work. Apparently "dojo shrinksafe" is also good.
These tools aren't packaged for Fedora yet -- but should be -- in which case it seems we can include compressed versions now provided we
include
links to the sources (and such) for GPL compliance reasons.
Once Fedora has packaging guidelines we'll need to use the versions
that
ship with Fedora, leaving us somewhat subject to changing API
interfaces
and such.
(Ah the niceness of just being able to say you are upstream...though we have to work with what we have)
So, given all that, it looks like we can include jQuery compressed verisons and not do a lot of stuff ourselves. Which is, of course, awesome.
--Michael
Looking at the minimized version, it just looked like javascript with
all
whitespace stripped. If there are legal ramifications for that...
Also, was your (not committed yet) version using jQuery? If so, can you commit it?
I want to start playing with this (and would right start now) but would not want to cause conflicts with what you already had.
--Michael
No, I hadn't since it was a silly little example working right now. I can commit it tonight when I get home though.
On 07/07/2009 02:20 PM, James Cammarata wrote:
On Tue, 07 Jul 2009 14:13:18 -0400, Michael DeHaanmdehaan@redhat.com wrote:
On 07/07/2009 12:50 PM, James Cammarata wrote:
On Tue, 07 Jul 2009 12:21:59 -0400, Michael DeHaanmdehaan@redhat.com wrote:
On 07/07/2009 12:13 PM, Michael DeHaan wrote:
On 07/07/2009 12:09 PM, Jeff Schroeder wrote:
On Tue, Jul 7, 2009 at 9:01 AM, Michael DeHaanmdehaan@redhat.com wrote: ...
> I think there is currently some annoying legal problem with the > compressor > that jQuery uses to make it "fast", so we would have to run the > uncompressed > one though if we shipped it with Cobbler though ... grr! I'm not > sure > how > slow that would be, but it would be worth trying just to get the > stylepoints. > > (FWIW, the way apps typically do the flash stuff is just a session > variable > making a DIV show up) > > > Legal problems? Seriously? Can you provide a link or some background on this? Google isn't showing much from a cursory glance. If there
are
legal problems however, just use the yui minimizer[1]. If there were legal problems yahoo would have taken it down a very long time ago.
I'll follow up on this with Toshio and others and let you know.
The problem was, IIRC, that the program to compress things was not permissible in Fedora.
However that appears to imply BSD, so let me see what the hold-up was.
--Michael
cobbler-devel mailing list cobbler-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/cobbler-devel
It seems rhino prefered Sun's JRE but may now work. Apparently "dojo shrinksafe" is also good.
These tools aren't packaged for Fedora yet -- but should be -- in which case it seems we can include compressed versions now provided we
include
links to the sources (and such) for GPL compliance reasons.
Once Fedora has packaging guidelines we'll need to use the versions
that
ship with Fedora, leaving us somewhat subject to changing API
interfaces
and such.
(Ah the niceness of just being able to say you are upstream...though we have to work with what we have)
So, given all that, it looks like we can include jQuery compressed verisons and not do a lot of stuff ourselves. Which is, of course, awesome.
--Michael
Looking at the minimized version, it just looked like javascript with
all
whitespace stripped. If there are legal ramifications for that...
Also, was your (not committed yet) version using jQuery? If so, can you commit it?
I want to start playing with this (and would right start now) but would not want to cause conflicts with what you already had.
--Michael
No, I hadn't since it was a silly little example working right now. I can commit it tonight when I get home though.
Ok, I want to play with this so if I get anything /non-sucking/ I might check it in, if not, tis ok.
I will probably try to get it all packaged (for us, not Fedora) and spend most of my time seeing that this works.
--Michael
Ok, I want to play with this so if I get anything /non-sucking/ I might check it in, if not, tis ok.
I will probably try to get it all packaged (for us, not Fedora) and spend most of my time seeing that this works.
--Michael
Yeah basically I've got it reading the files, sourcing the .js/.css files, and it pops up an alert with onload() and that's about it. We'll need to create a timer to check for alerts periodically, and come up with some way of storing alerts we've already gotten in a cookie or in the session so it doesn't constantly popup the same alerts. That shouldn't be too difficult though.
On 07/07/2009 02:32 PM, James Cammarata wrote:
Ok, I want to play with this so if I get anything /non-sucking/ I might check it in, if not, tis ok.
I will probably try to get it all packaged (for us, not Fedora) and spend most of my time seeing that this works.
--Michael
Yeah basically I've got it reading the files, sourcing the .js/.css files, and it pops up an alert with onload() and that's about it. We'll need to create a timer to check for alerts periodically, and come up with some way of storing alerts we've already gotten in a cookie or in the session so it doesn't constantly popup the same alerts. That shouldn't be too difficult though.
Ok, think I'm very close to having that.
I think a XMLRPC call on a timer to say "get alerts since ___" would work perfectly. (Would not need auth, so pretty simple, I think)
Maybe even we could say something like (in remote.py)
get_changes_from_hash(old_task_info) -> (new_task_info, array_of_alerts)
I'll see what I can get done.
If that happens, we can also make another system in the daemon for notifications, both global and to the user, to also be checked on the same timer.
Things like getting notifications when systems finish installing would be /slick/.
I'm excited about this.
--Michael
On Tue, Jul 7, 2009 at 11:41 AM, Michael DeHaanmdehaan@redhat.com wrote: ...
Things like getting notifications when systems finish installing would be /slick/.
Like a nice pretty templatized build report in your inbox? Oh wait...
The speed at which you two prototype things is scary.
cobbler-devel@lists.fedorahosted.org