Misleading order of items in “Next scheduled events” in new Frontend

[domini...@conrad.de]

Dear schedulix,

we are currently testing 2.11 after upgrading from 2.9

The new frontend looks great.

One point from user perspective.

I have a job, which will be executed every day at 00 AM and 03 AM.

With our current API implementation we create for every schedule a new "Master Schedule"

When I looked at the "Next Scheduled Events" table below, I wondered why only the 3:00 AM trigger was shown.

After switching the pages i found this change:

For me it looks like, that the order of this table is based on the name of the triggers.

Would it be better to set the order based on the Start column?

Best regards

Dominik

[Ronald Jeninga]

Hi Dominik,

it's good to hear you like the new GUI so far.

It is released as an alpha or experimental release, which means that flaws or even bugs are likely.

The issue you refer to is one of a list of issues I've found myself already.

Yes, it is very counter intuitive to have to scroll down that far in order to find the trigger dates of the next schedule.

(Since I myself found it so illogical, I spend some time searching a bug before I found out I was chasing ghosts).

Anyway, we've fixed that very issue, but ...

schedulix-fe is a repository hosted at gitlab (https://gitlab.com/schedulix/schedulix-fe) .

It requires a bit of environment to do the development and I'm afraid that the documentation at that point is pretty rudimentary to put it friendly.

So what I do is to take the results of a build and load that into my Zope server.

Then I create an export (a zexp file). That can be loaded into some other Zope server and you'll have a working environment.

The issue is that this export is a binary file and something like 30mb in size, which is why I gzip it.

The resulting file is a blob of about 7MB in size which I check in into github.

Now large blobs aren't exactly what git likes most. On any change it'll have to store an entire copy of the file, not just some diff information.

And this blows up the size of the repository  enormously.

The only thing I can do is to reduce the number of check-ins to a minimum.

We'll have to work on a better solution in the future, but at the moment I don't see a better alternative.

This week we'll be in Munich at a fair dedicated to workload automation systems (HOT-2024).

Next week we'll do a review of the GUI with respect to design and usability.

I expect that we'll return home with quite a list of issues.

The next check-in will probably be towards end of August.

Please don't feel discouraged and report every flaw you find.

Even if the update cycles are longer than usual, they will get fixed.

And we can't fix issues we don't know of.

Best regards,

Ronald

[Ronald Jeninga]

Hi Dominik,

as I pointed out it isn't a good idea to check-in a large binary file into the schedulix github repository after every change of schedulix-fe in gitlab.

And apart from the huge amount of disk space that would be spoiled, I also would have to create new rpms, which is a lot of work.

(Not to create a single set of rpms, but to create them for multiple RHEL releases over and over again).

It should be considered that the new GUI is experimental and a lot of small (and larger) fixes will follow in the upcoming time.

But a possible other solution to this issue came to mind.

I've placed a file schedulix-fe.zexp.gz on our server for download.

If you download it, gunzip it and import it into your Zope5 instance (after renaming or removing the old schedulix-fe folder), you'll be up-to-date.

And if I replace that file every one or two weeks I can spend the rest of my time to do more important things (like fixing flaws in schedulix-fe).

Hence no spill of disk space, no spill of time, and every now and then (or after fixes in schedulix itself) I'll do a check-in in github and create new rpms.

Would that work for you?

Best regards,

Ronald

PS. Other users are heartily invited to tell me their point of view too