Community
Participate
Working Groups
This is a feature request that I would like to discuss. Currently our JSDL wizard (In fact it is a job description wizard!) produces only JSDLs. Nevertheless we also have JDL and RSL implementations of the IGridJobDescription interface. Therefore I would like to have the possibility to create also JDLs and RSLs from the wizard. I think this requires only very few additions, but here Kasia may have valuable comments. I know that we always want to focus on JSDL and we definitely do so. Nevertheless I also think making this "hidden" functionality visible would be a good idea and would definitely attract more gLite and Globus users. And on the other hand we always claim to have a unique UI for all middlewares. But with the job description wizard we only support JSDL up to now. Nevertheless it is general enough with the provided fields that it should be not problem to also generate JDLs and RSLs from it. Any objections? Any comments? So from me of course a clear +1 for my proposal :)
(In reply to comment #0) > the job description wizard we only support JSDL up to now. Nevertheless it is > general enough with the provided fields that it should be not problem to also > generate JDLs and RSLs from it. Maybe this general information is apropriate for creating JDL and RSL. But we cannot focus only on JDL and RSL. There are many possible job description languages and we should support all of them or JSDL only. And maybe some languages requires more information or different information for creating basic job description. For me the only way for supporting other languages is using extension point. Of course we cannot have reference from eu.geclipse.ui to eu.geclipse.glite or eu.geclipse.globus and hardcoding JDL and RSL skeleton in JSDL wizard is not a good style. Therefore if we decide to support other job description I strongly suggest to use wizard like JobSubmissionWizard. First page would be for selection of job description type and the next pages would be provided by middleware specific plug-ins. > Any objections? Any comments? So from me of course a clear +1 for my proposal > :) For me it is -0. But if we decide for supporting other job description languages then from me of course a clear +1 for my proposal of using extention point wizard :) I see some issues. 1. If we will have JDL or RSL wizard, we should have also fully functional JSD or RSL editor. And they both are in preliminary state as we wanted to only show that support for other job description is possible. If we switch from "it is possible" to "we support it" it can have consequences. 2. We will finish with discussion similar to that about JobSubmissionWizard middleware selection page. E.g. should it be possible to create RSL description for GRIA project? Also, if some users are working with JSDL only, then they could be annoyed with addidional wizard page on which they always choose "JSDL job description"
> Maybe this general information is apropriate for creating JDL and RSL. But we > cannot focus only on JDL and RSL. There are many possible job description > languages and we should support all of them or JSDL only. And maybe some > languages requires more information or different information for creating basic > job description. Yes, definitely you're right here. Nevertheless I am talking about a quick solution here, not necessarily a fully featured one. But of course we can discuss about opening the wizard for any kind of job description. > For me the only way for supporting other languages is using extension point. Of > course we cannot have reference from eu.geclipse.ui to eu.geclipse.glite or > eu.geclipse.globus and hardcoding JDL and RSL skeleton in JSDL wizard is not a > good style. Yepp, definitely. And in fact we already have such an extension point, namely the grid element creator one. A simple outline of how such a mechanism could be implemented very quickly is: 1) Define a GenericJobDescription in the eu.geclipse.core.model.impl that simply holds a set of fields corresponding to the values that can be specified in the wizard and the corresponding setters/getters. Note that this is only used for generating other descriptions and not for any kind of job submission! 2) Change the element creators for the JSDL, JDL and RSL job description in order to enable creation of the corresponding description files out of the GenericJobDescription. That's it. Concerning the extension point it would maybe be one hour of work for me to set up a wizard page that queries available job description implementations that furthermore support generation from a GenericJobDescription. > Therefore if we decide to support other job description I strongly suggest to > use wizard like JobSubmissionWizard. First page would be for selection of job > description type and the next pages would be provided by middleware specific > plug-ins. No, the wizard should stay as it is, except for the first page that allows a selection of the description type. Description types then would have to declare if they can create descriptions out of the provided GenericJobDescription or not. Only those that are able to do so appear in the list of available descriptions. > > Any objections? Any comments? So from me of course a clear +1 for my proposal > > :) > > For me it is -0. Well, that is not that bad ;-) > But if we decide for supporting other job description languages then from me of > course a clear +1 for my proposal of using extention point wizard :) So -1 from me for adapting the wizard to all supported descriptions but +1 for me leaving the wizard as it is but for generating other descriptions out of the already available information. > 1. If we will have JDL or RSL wizard, we should have also fully functional JSD > or RSL editor. And they both are in preliminary state as we wanted to only show > that support for other job description is possible. If we switch from "it is > possible" to "we support it" it can have consequences. I don't agree. The JDL and RSL editors will not be touched! We are just talking about a very easy and fast way of creating other job descriptions than JSDL, not about editing them. > 2. We will finish with discussion similar to that about JobSubmissionWizard > middleware selection page. E.g. should it be possible to create RSL description > for GRIA project? Yes, I see your point. Nevertheless here we are only talking about creating some kind of file, not about a process like job submission. And the file can also be created by hand: New File -> myfile.jdl[.rsl]. Nobody prevents the user from doing this in any kind of project. We should not talk about bringing too much magic into g-Eclipse. > Also, if some users are working with JSDL only, then they > could be annoyed with addidional wizard page on which they always choose "JSDL > job description" Here I fully agree. Nevertheless providing more functionality always makes things more complicated. So we have to decide if this is really worth introducing a new wizard page. For me it is and it just introduces a well know g-Eclipse pattern to the description wizard (we already have this pattern in many other places). Nevertheless a new first wizard page may only be one solution. Maybe someone else has a better idea? Another solution (which I personally do not like, but nevertheless it is a solution) would be to have this page as last page of the wizard since the generation of the description file is also the last step. If the user finishes early a JSDL is generated by default.
Hi all , here is my contribution to this bug (In reply to comment #2) > the job description wizard we only support JSDL up to now. Nevertheless it is > general enough with the provided fields that it should be not problem to also > generate JDLs and RSLs from it. How do we create JDL or RSL files...?? 1) Will we need to create new JDL/RSL models to accomplish this as is the case of JSDL. 2) If we are not following the above, then i presume the information entered in the JDL/RSL wizard fields will be used to create a JSDL documents which will subsequently be translate automatically to JDL/RSL..... Therefore i don't see the reason for separate wizards, since the translation functionality is already there. > > > 1. If we will have JDL or RSL wizard, we should have also fully functional JSD > > or RSL editor. And they both are in preliminary state as we wanted to only show > > that support for other job description is possible. If we switch from "it is > > possible" to "we support it" it can have consequences. > > I don't agree. The JDL and RSL editors will not be touched! We are just talking > about a very easy and fast way of creating other job descriptions than JSDL, > not about editing them. The idea of generating JDL or RSL description files will indeed make our tool more valuable to gLite or Globus users who are already using the aforementioned description languages but we have to take under consideration the following: 1) Currently we are providing a fully functional JSDL editor which allows a user to modify the requirements of it's job by changing the JSDL file. By extending the Job Description wizard so as to enable users to create JDL or RSL description files, i agree with Pawel that we will have to create the respective JDL and RSL editors. Since there is no way of translating JDL/RSL to JSDL (for altering job requirements) it is necessary to implement such editors in order to keep our products interactiveness to a high level. > Also, if some users are working with JSDL only, then they > could be annoyed with addidional wizard page on which they always choose "JSDL > job description" I also agree here.
So here my few comments to the feature request. (It is a request and not a bug!!) 1. We decided to have JSDL as our favorite Job Description language. And the reason for that decision was the "support for standards". I did NOT see any comment who wants to change that! 2. JSDL is/should somehow be the "generalized" description for different middlewares. It is only the future who will decide if that is the case. But with a good and reliable support for JSDL in g-Eclipse we can contribute to the success of JSDL. 3. Unfortunately, there is no middleware supporting the standard in an appropriate way. Only first prototype implementations are done. So obviously, no middleware is supporting the features of JSDL fully, but the middleware dependent job descriptions often support more "high sophisticated" features. As g-Eclipse we have to be careful not to concentrate on these features, but on the essential core of job descriptions. 4. A wizard is not an editor! I see the wizards as tools to create the basic skeleton of something. The class editor provides an essential structure of a new class, but not the functionality. Keep this in mind during this discussion! 5. Can we provide support for the creation of other Job Description files (JDL, RSL? I'm quite sure, that we have it already! We can transform an existing JSDL to a JDL already! (Do we need more, when we talk about the wizard?) 6. Are we sure, that we have the 80% of the standard elements of a Job Description already included in the wizard? with 80% I mean it from the user point of view. Does a user need to change the create job decription in less than 20% already? I would invest the time in a "study/survey" of this feature than in extension mechanisms for the wizard!! The solution is not technical!!! 7. Concerning the editors: Well a support for all of them is a nice to have. But we go for JSDL. The first prototypes exists, and if someone wants it, a company (i.e. Innoopract) can provide it or the requesting community (i.e. EGEE) develop it (I'm not sure if I want a contribution from that community! :-)) My conclusion: 1. We are supporting the Job description wizard as it is and the internal model of the Job Description is JSDL!!! 2. During the creation of the job description, the user has to enter the name anyhow. I changed the name in 99% of the cases. And entered always "jsdl" as extension. But no one hinders me in typing "jdl" as extension. 3. Depending on the extensin the user entered, we can create the JSDL/JDL/RSL/... file from the JSDL model just by the XSLT transformation. If the extension is not "valid", we make a JSDL formated file as standard. I see this as possible, low cost approach! Editors for JDL and RSL exist already and opening the files would start the corresponding editors. so my vote: o) my proposal: +1 (what else can I say) oo) the feature request from Mathias which was "new job description creation support": +1 (if realised as above) -1 (if realized with a big effort) ooo) support for other job description editors as for the JSDL editor: -2 Anyhow: The main question is: Does the JSDL wizard (job description wizard) in it current state make the users happy already? Is it as easy to create the "hello world" job as it is to create a "helloworld" class? What are the cases not covered by the current job description wizard? Do we need support for these "additional" cases? Or can this be managed with the JSDL editor?
> 1. We decided to have JSDL as our favorite Job Description language. And the > reason for that decision was the "support for standards". I did NOT see any > comment who wants to change that! Definitely JSDL will stay our standard job description!!! > 5. Can we provide support for the creation of other Job Description files (JDL, > RSL? I'm quite sure, that we have it already! We can transform an existing JSDL > to a JDL already! (Do we need more, when we talk about the wizard?) My approach would be a bit different from a translation which is a high sophisticated feature. I would rather let the wizard output a set of parameters as a dedicated class (i.e. JobDescriptionParameters) containing setter and getter methods for all fields that can be specified by the editor. Then all available job description creators are asked if they can create a job description from this dedicated class. It is then the creators responsibility to translate the provided parameters into the native job description format. With this approach the wizard would be easily extensible for any other job description type and we would not rely on rather complicated translations. > 6. Are we sure, that we have the 80% of the standard elements of a Job > Description already included in the wizard? with 80% I mean it from the user > point of view. Does a user need to change the create job decription in less than > 20% already? I would invest the time in a "study/survey" of this feature than in > extension mechanisms for the wizard!! The solution is not technical!!! Good point, but this should be topic of another discussion. > 7. Concerning the editors: Well a support for all of them is a nice to have. But > we go for JSDL. The first prototypes exists, and if someone wants it, a company > (i.e. Innoopract) can provide it or the requesting community (i.e. EGEE) develop > it (I'm not sure if I want a contribution from that community! :-)) I fully agree, no need for editor improvements concerning JDL and/or RSL. > 1. We are supporting the Job description wizard as it is and the internal model > of the Job Description is JSDL!!! Well, of the job description YES. The JobDescriptionParameters outlined above would not be a job description but only a helper/container class for creating job descriptions. > 2. During the creation of the job description, the user has to enter the name > anyhow. I changed the name in 99% of the cases. And entered always "jsdl" as > extension. But no one hinders me in typing "jdl" as extension. That would be the easiest approach. But it would somehow hide the possibility to create other job description from the user and it would not give any hint to the user which job description can really be created. So I would go for a somehow more advanced feature. I like the approach to make use of the first wizard page to specified the job description type. We could simply extend this wizard page by some kind of control letting the user choose from a list of job description type. The simplest control I can think of would be a Combo letting the user specify the type of the description. I think of something like we all know from file dialogs were you can specify filters for the files ("*.jsdl (JSDL Job Description)", ".jdl (gLite native Job Description)", ".rsl (Globus native Job Description)"). The list is then build of all job description creators that can create job descriptions from a JobDescriptionParameters object, a pattern we already have in various places and which is really easy to implement. > oo) the feature request from Mathias which was "new job description creation > support": +1 (if realised as above) > -1 (if realized with a big effort) So to make a long discussion short: I would start next Monday with an implementation. If I am not successful with implementing this stuff until our weekly meeting on Tuesday we see this as "bug effort". If I am able to come up with a good solution I think we can all be happy about this new feature :) > Anyhow: The main question is: > Does the JSDL wizard (job description wizard) in it current state make the users > happy already? > Is it as easy to create the "hello world" job as it is to create a "helloworld" > class? > What are the cases not covered by the current job description wizard? > Do we need support for these "additional" cases? Or can this be managed with the > JSDL editor? Harald, maybe you should create a new bugzilla item for these questions ;-)
(In reply to comment #5) > > 1. We decided to have JSDL as our favorite Job Description language. And the > > reason for that decision was the "support for standards". I did NOT see any > > comment who wants to change that! > > Definitely JSDL will stay our standard job description!!! Something came to my mind. What makes JSDL our standard job description? Isn't it just the most supported language? > My approach would be a bit different from a translation which is a high > sophisticated feature. I would rather let the wizard output a set of parameters > as a dedicated class (i.e. JobDescriptionParameters) containing setter and > getter methods for all fields that can be specified by the editor. Then all > available job description creators are asked if they can create a job > description from this dedicated class. It is then the creators responsibility > to translate the provided parameters into the native job description format. What about others? I mean, what about job description languages which cannot be created from JobDescritionParamaters? They need another wizard? So, we will have situation that some job description has their own wizard and some are using general wizard? Very confusing to users. So maybe other way? All job description creators should be able to create description from JobDescriptionParameters? E.g. JDL "[]" or RSL "()" are valid and can be created from any set of parameters. Of course it is also not good solution and also confusing for users. And another problem. Lets assume that at some point we can provide more detailed JobDescriptionParameters. How all the job creator will be able to get new fields? It is necessary to reimplement them? For me JobDescriptionParameters using getters and setters is not a good idea. Much better is to use something like properties. e.g. if(jobDescParams.isDefined("defaultQueue")){ q=jobDescParams.getParam("defaultQueue") } else{ q=myDefault; } Of course it is also not fully transparent because some constants must be defined. Some constant could come from JSDL, but e.e PBS job description need queue name which is not defined in JSDL. Another problem. JSDLJobDescriptionWizard is extended with application specific wizard page. This part is for JSDL only, as it is partially defined as predefined JSDL filled with some application specific values. It would be very hard to use this application defined parameters e.g. in RSL. This is really JSDL Wizard and was created with JSDL in mind. We should not treat it as general. > I fully agree, no need for editor improvements concerning JDL and/or RSL. Lets say we have working RSL and JDL generation. If users will be able to create them and edit, of cource we should expect a lot of bugs or feature requests. (E.g. "JDL wizard is nice, but it should ask about VO parameter because it is obligatory n JDL", "RSL editor does not highlight rsl_substitution keyword") I am not tryig to say that we should improve JDL and RSL editors, but if we are trying to do one simple step to satisfy JDL or RSL users it is only the beginning of users requests. My summary after some rethinking; 1. Changing JSDLJobDescriptionWizard to general one: -1 (or even less) 2. Supporting JDL or RSL with their own wizards: -0 (maybe could be nice but with very low priority and with tiny effort)
+2 for Harald's proposal. Let us keep things simple and focus in missing functionality in other areas (read: workflows, parametric jobs,...) than in fine tuning a wizard... Using the XSLT conversion at the end if the user choose ".jdl" as filename is for me the simplest, easiest and most error proof approach. (Do we have something similar for RSL?) And changing that single letter in the filename is the same number of clicks/keys as adding another extra wizard page at the beginning, which is annoying for users which just want to generate the default. Note that if we follow the JobDescriptionParameters approach, we will end up with two _different_ ways of generating a JDL which is BAD BAD BAD :-) My +0.02 cents ;-)
As promised here is a short technical description of the now implemented feature: 1) The JSDL wizard was changed to contain a new Combo in its first page that let the user choose from a list of available job description types to which the JSDL can be transformed. 2) This list is created from the eu.geclipse.core.gridElementCreator extension point. For reference see eu.geclipse.core.Extensions#getRegisteredElementCreatorConfigurations. This method is queried with JSDLJobDescription.class as source and IGridJobDescription.class as target. That means all element creators are returned that can create any type of job description out of a JSDLJobDescription. 3) The JDLJobDescriptionCreator was changed to be able to create a JDLJobDescription our of a JSDLJobDescription. This is done with the well known XSLT transformation. 4) In addition a new transformation action was added to the GridProjectView's context menu that allows to query the element creators for a selected job description for available transformations to other job descriptions. This replaces the old JSDL2JDL action that brought some hidden gLite dependency into the core. Hope that's fine for all. Can we mark this as fixed? Any further objections?
Fine for me, +1 to close it
Hi all, +1 from me also to CLOSE the bug.
+1 also from me to close this bug
Seems to be fixed
Closing this one.
