Bob Gobeille wrote: >>> >>> If you run e-mail notification as an agent, presumably it will have a >>> dependency on another agent (the one you want to be notified about). >>> Is that right? If so, what if the other agent fails? In this case, >>> dependent jobs are not run. >> Ugg, good catch, this is a design flaw, will try to address it. The >> issue is that the scheduler only knows what's next, not when a job (in >> total) is done. So there is no way today, for the scheduler to indicate >> when all of the processing is done for a particular upload. Some items >> are set in the jobqueue table, jq_endtime and setting the jq_end_bits. >> So the Email agent could check those. >> >> This agent is uncovering issues with how FOSSology deals with failed >> jobs. > > > For this discussion it helps to keep the terms straight. There are > "jobs" and "jobqueue entries". A job queue entry is just a single > task. One Job can have multiple jobqueue entries. So let me make sure I have the table relationship correct. Job to jobqueue is a one to many relationship (1 job many jobqueues). Correct? > So a license job, has 7 tasks (jobqueue entries), where each task > is just another part of the license pipeline. It is the jobqueue that > has dependencies. Job was supposed to be on top, with 1-n jobqueue > entries under it. This hierarchy was butchered when we added > dependencies on jobqueue entries.
> So a jobqueue entry typically depends on another task in a different > job (as opposed to being dependent on the job) Huh, really? So if I have 4 'jobs' for the request (I'm watching an upload as I type this...) - Unpack - License - Default Meta Agents - Meta Analysis Each composed of sub-jobs, you are saying that the license sub-job sqlagent can have a dependency on let's say Meta-Analysis sub-job pkgmetagetta? Holy dependencies! Ah, I see what you are saying... it's not that bad, but we use the dependency between jobs to order them.... > Now a typical upload may queue up 3 or more jobs, instead of the > logically one job. We could make this a single job. This would make > it easier to tell when the whole job is done. I haven't really > thought this through though. It would be good if we could simplify this without affecting performance. I think the user just wants to know when the thing is done. Maybe a research type might want to see the sub-steps involved, but I think most just care about Done. I don't want email notification to drag in a ton of things we 'could' do. I thought release 1.1.0 was going to be rather quick with buckets and email notification as the major functionality changes. Has something changed? What I'm trying to say is that I'm OK with something that works that doesn't cause a change in the way jobs are now. I think I can make it work. > > >>> The users table does have an email address but that doesn't mean that >>> email notification is desired. So are you saying that you will add a >>> field to indicate if email notifications should be sent by default >>> (but potentially overridden during upload time)? >> >> Yes, I would add a checkbox for email notification and and area to list >> other e-mail addresses that want to be notified by email. > > Why not just keep the comma separated list, like we have now? To me it seems strange from a UI perspective to mix 'others' with the user email addresses. It seems sorta spam like as well. 'Just put your comma separated email address in here and we'll be happy to send them out'. Hmm, just looked at the code, the fields are only 60 characters long... some email address can be long. Using my work address as a poor sample, 60 characters is long enough for 2-3 addresses. I guess I can live with it either way... but I would make the fields 128 or 512 characters long so a decent list could be supplied. > >>> What tests are you including? >> >> Huh? I'm not sure what you are asking. I plan to write tests for this >> agent/function. Plus, all of the user pages need tests written for >> them. Either Mary or I can code those. > > I meant, what conditions are you going to test? For example, killing > a jq_pk manually, cross site scripting in the email address, ... Hmm, I usually don't put that in a design doc. At least not at that detail. That sorta detail would be in a test plan. I do plan to study the ica slides for test cases. Very naughty, but enlightening. All of the user screens could use this type of nasty testing. > > >>> Can other users subscribe to an upload so they are notified on any new >>> analysis? Is there any user desire for this? >>> >> I actually don't think this is a good idea even if users wanted it. I >> don't think this is a good idea as it is intrusive. Maybe I'm analyzing >> something that is sensitive and few folks are supposed to know about >> it. Why should any user that has a login to FOSSology be allowed to >> sign up to see the results? >> >> I could see signing up being OK, if we had a concept of 'Groups' or >> something like that, but we don't. So for now, I'm not inclined to look >> into this. > > > For example, let's say we start processing fedora and notifying > package maintainers. > I'm not saying that this is a requirement, I just think you want to > make sure you don't close any doors. OK, I'll keep an open mind. I'm not sure how one would 'sign up' (from a UI perspective.... ) something to think about. > > What reply-to are you using in the email? What subject? I'm mocking the e-mail up now. > I think your design should list the files and tables you are going to > change along with what is going to change logically. I did, but I guess I wasn't clear enough. Please see the design doc to see if it now has enough detail. > > Bob -- Mark Donohoe ALPS/OSTT, Cupertino CA. fossology.org _______________________________________________ fossology mailing list [email protected] http://fossology.org/mailman/listinfo/fossology
