6513 2008-10-30 13:26 globus-deploy-gar shouldn't put undeploy.xml in $GL/etc/gpt/packages 2008-12-19 09:37:26 1 1 1 Unclassified Java WS Core globus_wsrf_core 4.0.7 Macintosh All RESOLVED FIXED 4.0.x P3 normal 4.2.2 1 bacon@mcs.anl.gov trhowe@uchicago.edu gridshib-dev@globus.org jwscore-dev@globus.org bacon@mcs.anl.gov 2008-10-30 13:26:18 From gt-dev: Deploying a GAR into $GLOBUS_LOCATION currently creates a file under $GLOBUS_LOCATION/etc/gpt/packages/<gar_name> called "undeploy.xml". I am currently working on accepting in some patches for GPT (bug 6229) that change the filesystem layout of GPT metadata, and these files are a bit of a sore point. However, there are some real issues I have with them independently of the GPT changes, and it seems like a good time to address those. 1) etc/gpt/packages is a place for GPT metadata. I can see why it was chosen as a location for these undeploy files, because it relates to the packages themselves. But I think they'd be better under share, since they don't really have anything to do with GPT. 2) These files are almost never included in the filelist of the package. That means they don't make it into binary distributions. There are only four packages, all of them part of RFT, that correctly include them in the filelist. If it weren't for that, actually, I wouldn't even be bumping into them as part of the fixes for bug 6229, but there you go. 3) The GAR name and GPT package names are frequently not the same. That's mildly irritating to me, but I have no pressing reason why that should be cleaned up. So, my suggestions? 1) Move the undeploy.xml to share/<gar_name>/undeploy.xml instead 2) Add it to the relevant packages filelists 3) If you feel like improving aesthetics at the same time, consider renaming your GAR to be the same as your GPT package name. At the very least it will lower the namespace pollution of our directory structure, if you feel like you need a benefit besides just making me happy. My main concern for all this right now is just HEAD, which is where I'm testing the changes. Arguably we will want to have this happen in 4.2 branch right now, unless someone can see how this represents an interface change. My suspicion is that the undeploy.xml that result from our source installations are not well-known or used, particularly seeing as how nobody has ever complained that they are missing from binary distributions. trscavo@gmail.com 2008-10-30 13:51:03 (In reply to comment #0) > > 1) Move the undeploy.xml to share/<gar_name>/undeploy.xml instead Deploying a GAR already utilizes share/<gar_name> so I wonder if this is the best location. Admittedly, I can't see why it would matter, but putting undeploy.xml in a directory with a whole bunch of other unrelated stuff just doesn't seem right. Would it be better to put undeploy.xml in a directory of its own? Just a thought... bacon@mcs.anl.gov 2008-10-30 13:55:28 If share/<gar_name>/undeploy is better, then that's fine by me. I also wouldn't mind if it would up with the rest of the "administrative" side of a package's contents and went into $GL/etc/<package_name> instead. Admittedly, given the lack of correlation between gar names and package names right now, that would also result in an explosion of subdirectories of etc/, which I find undesirable also. My main quibble is with it being in a GPT-specific directory. I'm happy to entertain alternatives for its "proper" home. Whether that's $GL/share/undeploy/<gar_name> or $GL/share/<gar_name>/undeploy or something else, I don't have too much of an agenda about that. trscavo@gmail.com 2008-10-30 13:59:46 (In reply to comment #2) > > $GL/share/undeploy/<gar_name> or $GL/share/<gar_name>/undeploy FWIW, I prefer the former over the latter. trhowe@uchicago.edu 2008-11-13 11:24:36 The undeploy information is now deployed to $GLOBUS_LOCATION/share/undeploy/$gar.id trscavo@gmail.com 2008-11-13 13:06:23 What is the Target Milestone for this patch? Thanks. trscavo@gmail.com 2008-11-22 08:59:16 Where was this patch committed? HEAD? globus_4_2_branch? I'm getting buildbot errors re filelists on alternate nights that suggest the patch has been committed to HEAD but not to globus_4_2_branch (or vice versa, I can't really tell which). Thanks. trscavo@gmail.com 2008-11-22 12:20:07 (In reply to comment #0) > > My main concern for all this right now is just HEAD, which is where I'm testing > the changes. Arguably we will want to have this happen in 4.2 branch right > now, unless someone can see how this represents an interface change. This explains what was reported in Comment #6. This issue is being tracked in Bug 6549. ranantha@mcs.anl.gov 2008-12-16 12:39:32 Reopening this bug - it doesn't have a target milestone nor is there information on where things were committed. I agree with Charles that the changes should be committed to both trunk and 4.2 branch (the undeploy is rarely used) and the milestone should be the next 4.2.x release. Reassigning to Tom Howe, since he worked on this. trhowe@uchicago.edu 2008-12-18 14:05:14 This has been committed to globus_4_2_branch trhowe@uchicago.edu 2008-12-18 14:23:55 This has been committed to globus_4_2_branch trhowe@uchicago.edu 2008-12-18 15:00:56 This has been committed to globus_4_2_branch and globus_4_0_branch vwelch@uiuc.edu 2008-12-19 09:37:26 (In reply to comment #10) > This has been committed to globus_4_2_branch Working for GridShib now.