DSXchange

Hi,

In an effort to facilitate standardized automated releases I have the developer create a deployment package via the Information Server Manager tool; because it would be a huge pain to have them script all of this out. I then want the .pkg file versioned so we can import the package programatically to another environment (i.e. dev>qa>prod). The versioning of the packages is for deployment only. We actually version the individual jobs for coding purposes.

When I run the following command which imports the package from the repository in the same environment (dev>dev) but a different project, it works fine:
$ISTOOL deploy package -dom myserver:myport -u myname -p 'mypassword' -v -pkg mypackage -ds '-repl myserver/myproject'

However, when I changed to a file flag so I can import from the actual file rather than the repository (thereby simulating what will happen when deploying to another environment) I get a missing manifest error. I see nowhere in the UI or command line tool where I can add a manifest file. The deploy package help command clearly says I should be able to import from the file but it just will not work for me:
$ISTOOL deploy package -dom myserver:myport -u myname -p 'mypassword' -v -f mypackage.pkg -ds '-repl myserver/myproject'

I am running this from within the directory on the server where the .pkg file is located. I have seem similar posts but they were either different enough or never solved.

Thanks in advance!

-Jesse

Oh well, apparently I stumped everyone.

Apparently.

I'm just going to have to guess, not having any way to test this but what if you use the full path to the package file? Does that make any difference? I agree it shouldn't but I'd be curious if it changes the error at all.

Worst case contact your official support provider, if you haven't already. Perhaps that's a known issue in your version.

Yeah, I've tried several variations of the file location. Worst case - I have the admins contacting IBM. -Thanks

Although I have not tried it, but I see the following lines in the documentation

You must first define the package in the InfoSphere Information Server Manager, including specifying the assets that it contains and the build and deploy paths.

and

The specified file name must be relative to the deploy directory in the target system.

I hope the support guys have a detailed explanation on what's wrong.

Seems like the blurb in the second italicized statement is the issue, yes?

I thought that could be a winner but I got the same error when trying. I will be sure IBM takes it into account though -Thanks

I'm seeing the same issue, i.e. ERROR: failed to retrieve manifests from deployment package file. I'm using InfoSphere / DataStage 8.5. I"ve opened the .pkg files using 7-zip and they have a manifest file that doesn't seem to be corrupted, i.e. it looks like well formed xml. Furthermore, the .pkg files import properly using the GUI tool in Information Server Manager but fail when using the istool deploy package with a -localfile switch. This is not a path issue as there is a distinct error when the path is wrong. In addition, there is another interesting nuance. I created a test .pkg file with one simple DataStage job in it. This file works as expected with istool. However, my production job, which has many datastage jobs fails. They're both in the same path on the server. I've opened a support request with IBM.

I have been deploying using istool for the past 1 year without any issue and yesterday I started getting this error. It keeps throwing the error after few attempts the same package from the same location will get deployed.

I have looked at the information on the following links but it does not help. My configuration complies with the resolution recommendation on the link.

http://www-01.ibm.com/support/docview.w ... wg21634404

http://www-01.ibm.com/support/docview.w ... wg21646096

I am stumped. Has anyone found the cause and solution for this issue.

Thanks
Denzil

UPDATE RESOLVED
This issue got resolved for me as it was caused by some sysadmin changes to the samba share. I was deploying from packages located on the samba share and the sysadmin had done changes to that share.