Hello, Carlos
Thanks for your reply. :-) As your said, the SOURCE is surely important when offering both user own private Image Repository and the public Image Repository shared by all. SOURCE is an exciting option. :-) I should do some experiments on how to use the SOURCE and send back here the results. :-) Thanks a lot. :-) Best regards, Joey On 星期三 18:55, Carlos Martín Sánchez 写到: Hi, You are right about the steps made by the ruby OCA and OpenNebula daemon. And indeed, it makes no sense to specify only a SOURE attribute *if it is a file path*. But you can still take advantage of the SOURCE if you use an http:// url. This can be used to bypass the local Image Repository and store some of the Image files remotely. Anyway, this isn't the typical scenario, and maybe it still makes sense to remove the SOURCE option from the Suntone wizard. Best regards, Carlos. -- Carlos Martín, MSc Project Major Contributor OpenNebula - The Open Source Toolkit for Cloud Computing www.OpenNebula.org [1] | cmar...@opennebula.org [2] On Wed, Apr 27, 2011 at 2:41 AM, wrote: Hello, When creating an image by sunstone-server, I find that the SOURCE makes no sense. So I go to the source code both in Ruby and opennebula, the SOURCE is only valid when using the PATH or SIZE(with FSTYPE). In my opinion, the whole image creation consists of four steps: 1. Sunstone-server sends "one.image.allocate" by using Ruby to opennebula. The opennebula receives the calls and checks if the SOURCE exists in parameters of the image template. If it does not exists, opennebula assign a string to the SOURCE with the SHA1 digesting of "uid:name", otherwise do nothing to the SOURCE. Then, inserts a image record into the DB. 2. Then sunstone-server sends "one.image.info [5]" to opennebula to retrieve the initialized infomation by step 1, mainly the value of SOURCE. 3. Suntone-server starts to judge the branches by PATH, SOURCE, SIZE, FSTYPE and TYPE. When there only exists the SOURCE, it will do nothing. (For example, if the PATH exists and SOURCE not exists, it will do copy the PATH file to the SOURCE file path, and etc.) 4. If former steps have no errors, sunstone-server sends "one.image.enable" to opennebula, it just update the record in DB and do nothing about the SOURCE. Otherwise, it sends "one.image.delete" to opennebula and delete the record in DB. So, if just specify the SOURCE to create an image, the operation make no sense. So, I think the SOURCE input should be removed in web pages of sunstone-server . If I have mistakes, please send me the error correction. Thanks. :-) _______________________________________________ Users mailing list Users@lists.opennebula.org [6] http://lists.opennebula.org/listinfo.cgi/users-opennebula.org [7] Links: ------ [1] http://www.opennebula.org/ [2] mailto:cmar...@opennebula.org [3] http://junjie.ma [4] http://cs2c.com.cn [5] http://one.image.info [6] mailto:Users@lists.opennebula.org [7] http://lists.opennebula.org/listinfo.cgi/users-opennebula.org
_______________________________________________ Users mailing list Users@lists.opennebula.org http://lists.opennebula.org/listinfo.cgi/users-opennebula.org
