@dsj the import languages take time to process, therefore it conflicts with the topic environment creation process. That’s why trs are not imported to those environments. We have a backlog item to look into this process again. But until then you would need manually import the required trs files into topic environment
The curl: (6) Could not resolve host: kubernetes.default.svc error is there because the way secrets are trying to be fetched at startup, since running via docker, there is no Kubernetes involved you get this error. Eventhough the error is there you can ignore and continue.
You need to login as a enduser. IFSSYS is not a enduser.As for the error “ifs-file-storage | java.net.UnknownHostException: ifs-virus-scanner. You can ignore this also. This can be an issue if you are specifically developing File Storage functionality. But again, there is a workaround for it.
We have not planned to provide blob support for Remote customers. But will take this feedback
@chanaka-shanil In your above comments, it was mentioned FS Will be available in 23R1. Is it released now? This will be with 23R1 GA. When was the SMB protocol invented and witch century are we in at them moment? You like to state that you utilize the newest technology why not create a solution with the newest technology and let the customer decide what kind of storage to use for the remote solution to? We have chosen SMB based on input we have got and most customer could use this without much change to their existing infrastructure. Also keeping in mind that this needs to be support on air gapped installations. But this doesn’t mean we will only support SMB going forward. Based on input we can add other storage backends. The idea with the file storage is that it acts as an abstraction to the consumers of it. So, the consumer doesn’t need to care about the internal details of what it takes to store or retrieve a file from storage. In the case of DOCMAN, it only knows that files ar
HI Geir,The clone process at the moment does not clone the actual files in the File Storage. But this is something we are planning to add in the future.
In 22R2 most errors (formatting, business rules) will return a HTTP 500 error.This was changed in 23R1 GA. Now some client side errors (wrong request format, incorrect URL) will result in an HTTP 4XX error. We have described this in detail in the 23R1 documentation: OData Provider Overview - Technical Documentation For IFS CloudHowever, errors thrown from the DB via Error_SYS.App_General are still raised as HTTP 500. This is because App_General has been used in different scenarios, so we cannot generally say that such errors are 4XX series errors since they might not be.
Sorry for the very late reply. Yes, this is released now with GA. Documentation can be found here: https://docs.ifs.com/techdocs/23r1/070_remote_deploy/400_installation_options/120_file_storage_for_remote/
@Nishanth can you describe the pod. kubectl describe pod ifs-file-storage -n <namespace>
This is an issue we noticed probably due to how the underlying storage works in this Azure setup. We actually did a change so this should be fixed with 23R1 SU1. @kjro Can you check the ifs-file-storage container version used in your setup
@Nishanth can you check if the deployment can reach file share, I suspect that the share is not reachable, also try using the IP Address instead of the host
Just want to clarify something, the reason why this got fixed was that we found other issues with the storage of metadata, so that got removed. This also fixed the issue with this Storage setup.The idea here is that the Azure SMB share would abstract underlying physical storage, so from the File Storage’s perspective this would be just another SMB share. So in a way, we are not directly supporting this setup, but since this works similar to a SMB share and is transparent to us, it works.
@kjro It’s totally removed from the storage.
@Mathias Dahl explanation is correct. This fix was done to get around a few character encoding issues which was found in the FS for Remote and Cloud. The FS internally keeps track of the files with encoded names so any files prior to this change will continue to work without issue.The file names are base64 encoded, so you can use base64 decode to get the file name, but as said, the actual file name is an implementation detail.
Already have an account? Login
No account yet? Create an account
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.
Sorry, we're still checking this file's contents to make sure it's safe to download. Please try again in a few minutes.
Sorry, our virus scanner detected that this file isn't safe to download.