I decided to try out a VM version of ERPNext on the Google Cloud Service. So, they just happen to have a ready to go version to deploy there that was setup by Bitnami. I created a test account and deployed the ready-to-go ERPNext V8.0.46
I configured all of the sales reps and employees and then tried to upload the same customer list I used on my local Debian server box. I even broke the list down so that no more than 300 at a time would try to upload at a time. I also made sure I downloaded a fresh template right from the system I am using on Google Cloud. I pasted in all the data, checked it for correct alignment and tried to do the import.
When I selected the file in the import/export setup screen and clicked on the “Import” button nothing appeared to happen. Has anyone else tried this?
Is there a way to run the imports from the command line? If so, can anyone tell me where in the system I need to be to run it and the command syntax I need to use. It appears that I have command line access to the system so I could try that if I knew how to do it.
Otherwise, I am looking for anyone that has used the Google Cloud Service and loaded the pre-made version that migh also have some idea how to get the import function to work.
Here is the error trace I get from the cloud server.
Title
frappe.limits.update_space_usage
Error
{‘retry’: 0, ‘log’: <function log at 0x7fa622ec87d0>, ‘site’: u’erpnext’, ‘event’: u’hourly’, ‘method_name’: u’frappe.limits.update_space_usage’, ‘method’: <function update_space_usage at 0x7fa62857a140>, ‘user’: u’Administrator’, ‘kwargs’: {}, ‘async’: True, ‘job_name’: u’frappe.limits.update_space_usage’}
Traceback (most recent call last):
File “/opt/bitnami/apps/erpnext/htdocs/frappe-bench/apps/frappe/frappe/utils/background_jobs.py”, line 65, in execute_job
method(**kwargs)
File “/opt/bitnami/apps/erpnext/htdocs/frappe-bench/apps/frappe/frappe/limits.py”, line 217, in update_space_usage
update_limits({ ‘space_usage’: usage })
File “/opt/bitnami/apps/erpnext/htdocs/frappe-bench/apps/frappe/frappe/limits.py”, line 157, in update_limits
update_site_config(“limits”, limits, validate=False)
File “/opt/bitnami/apps/erpnext/htdocs/frappe-bench/apps/frappe/frappe/installer.py”, line 294, in update_site_config
with open(site_config_path, “w”) as f:
IOError: [Errno 13] Permission denied: u’./erpnext/site_config.json’
This exact same error and exact same trace appears over twenty times in the ERPNext error logs over the past 2 days and I get it when I try to import as well, except in the case of import, nothing happens. At least all of the other times it did not appear to affect the rest of what I was doing.
Thanks in advance for any help some one might be able to provide
Thank you for the pointer, but I have given up on getting the Bitnami image to work. It had too many problems and slow response from the Bitnami group.
I moved on to just loading a pre-made Debian 8 image on Google Cloud and then used the easy install script to start up a real working system that doesn’t have any of the Bitnmai image problems. Maybe one day in the future (if I have time to kill) I will go back and try to figure it out again, but for now there are much easier ways to get to the same solution and Bitnami is NOT one of them.
Yes, the permission snags indicate environment setup issues that relate to the environment you are connecting from and what ERPNext environment you wish to run - once that is resolved then only ‘bench update’ issues may need to be resolved.
For example here’s a common complaint
I wonder what bench commands are available of say some restricted set!?
I kept the Bitnami instance around in my Google Cloud Platform in case I ever wanted to play there again. So last night I went back to check out the permission issues. Yup, There were issues with permissions. So I changed them and got the error to stop. However, It didn’t resolve the main problem.
You still cannot get data into the system. Import functions do not work, and some of the data you try to enter by hand will still lock up the system. I may just kill off this instance so I don’t waste any more time on it. Why in the world would they put their VM image into the Google menu without having resolved even the silly permission issues, much less the data issues? I’m back to being DONE with Bitnami.
Thanks for the pointer to a solution. I have already deleted my Bitnami instance of ERPNext because I could not get any answers back when I was working on it. If they really get it fixed and republish it, I may try again at another time. The real point is that it should have been a working stack, yet it had been in it’s current state for a few months with no response to questions about it and no communications about ever going back to work on it.
That is just not the way to promote the ERPNext project or their own services. So to be honest, I lost my trust in BItnami. Once you reach that point it is hard to muster the effort to go try again.
Fair point. Frappe have an interesting case here as they are the majority developers still on ERPNext so want to support folk wanting to try ERPNext. But equally, they much prefer you use their hosted service which is not expensive as thsi is how they make a profit and run the company. Perhaps your question should be directed to the Foundation, to see if its something they want to pick up and run with ?
I think Frappe do an excellent job under the circumstances with limited resources, but trying to deal with yet another moving target such as Bitnami hosting is not easy.
That is exactly why I sidelined the Bitnami stuff and went directly to the Google Cloud Platform with a my own instance of a VM image. In my case I have several custom pieces that need to go into my implementation and that is just not supported on the ERPNext servers so I must self-host. You can see what I eventually did here:
