Summer of Code

I hate to see that a countryman blames somebody else of it's problems. I have seen that too many times; there are people that loves to complain about lack of opportunities here... and no matter what, they will always find a new thing to complain about. Too much complaining, we need to work harder!

Well, SoC's final deadline is a few days away, I really enjoyed this time :). Let's talk about the status now:

Right now SCIRE's job subsystem is capable of create, distribute, run and monitor a job created, both for a single and for multiple clients. All this is also reflect on the UI code. Finally, all the code can be tested directly from the UI and everything seems to work (No bugs doesn't mean it's right, just that is doesn't have visible bugs). The latest patch implements the monitoring UI, and gives pretty usefull information about the job.

What is missing? Once a job is completed it could be marked as finished, failed or cancelled. If the job is non-recurring, there's no problem as all this just becames historical information. But for recurring jobs is a different story as it need to be re-schedule, isn't it?. For successfully finished jobs si pretty straight forward to assume that they should be rescheduled automatically. But for failed? or cancelled?. I'm very lean towards the user-should-choose option; after all, he knows better what to do for every situation, as it may depend on the job. So the best decision is not to let somebody else do the decision :). But you also need a good default, so I'll do this as follow: if a job has been marked as failed, re-schedule it automatically, but if is has been marked as cancelled, don't do it. This implies that the job creation template should include an option to modify this behavior. Also, the re-scheduling mechanism is not that hard to implement, the problem lies on who should execute it. The observer pattern should come to the rescue. Isn't it wonderfull when you figure out something while writing a post? I should blog more often :)

Finally I've finished my semester!, although technically I have to take one more exam, it's due Sunday and not that hard anyway. So I can *finally* dedicate to my soc project 24/7. Here is the status report I've sent to the gentoo-soc mailing list:

Project description

SCIRE (Systems Configuration, Installation, and Replication Enviroment) "aims to create a widely extensible common portal for administrative tasks for multiple Linux client machines". The job subsystem deals with the creation, preprocessing, scheduling, distribution and execution of specific tasks for the client machines.

Project status

The Definition column refers to the specific way to do each step, and I've learned all this time that specific things cannot be forseen so, although in the proposal there is a specification, it isn't set in stone until it's feasible do code it and to code it efficently.

The main focus of the project up to today was on the scheduling and distribution steps. The former is finished and the latter has been halted until the creation step reflects the advances on the other ones. The preprocessing step will be the la it isn't essencial nor blocking of the rest.

On my soc proposal I splitted the project so the backend code would be written on the first half and the UI code on the other half, but my mentor suggested me to do them on parallel.

I'm a little bit behind my schedule, but now I have a lot more time to work on the project, so I'm confidence about finishing the project.

Timeline

9-15 July = Finishing updating the UI to reflect the latest changes

16-22 July = Finishing the distribution code

23-29 July = Work on the creation UI code

30-5 August = Finishing the Execution code

6-12 August = Finishing the creation code (both backend and UI)

13-18 August = Work on Preprocessing code.

Just a quick post. I've been working on the client and server code of SCIRE to include the new job model, is going well and today there was a interesting chat with my mentor and all the team at #gentoo-scire. This week's code delivery will be delayed a little bit, I want to include the latest modification suggested on IRC. Once I have everything set up I will do a more detailed post.

On the other hand, it's getting harder to balance the Summer of Code with the University, so far so good but I have to be very organized with my time :). Tomorrow I will give a lightning talk about plan 9 (an operating system from Bell labs that was designed to make Unix obsolete.) I'm not an expert on it... but I think is very interesting and I'm sure this will be the first time my teacher will hear about Plan 9... so It's going to be fun

Over and out

A week and a half has been since the Summer of Code officially began. I'm feeling more and more part of this and I'm as excited as when I was elected a month or so ago. But... we need to get down to business :)

All this time I've been working on two fronts. One is the database; basically defining how to create the relationships between jobs, its metadata and the target clients; the scheduling schema is going to use a crontab-like string as is by far the best way to do it and also is a well known syntax for the users. The database modifications weren't taken lightly as everything is going to be based on the database so they were very well talked with codeman and agaffney. If everything goes as it should *wink* the database schema shouldn't be modified from now on.

On the other side I've been working on the client and server side of the app. I've been using pychecker to review the code. It's easy to make mistakes if you are used to use a compiler to check your code :). On the server side I've added support to command-line arguments. I'm trying to check the client-server connection before doing any other work, and for some reason the SSL authentication is throwing me an error if the server and the client are on different machines; but if they run on the same they work... weird. Once that is over I'll focus on fix all the functions I broke with the modification to the database.

On a side note I finally have everything ready to work, the kvm virtual machines are working flawlessly and with the extra Gigabyte of RAM I just bought there's not a single delay while working with several virtual machines. Great!