Thank you for more explanation. It's not necessary for you to agree with me at all honestly -; I just wanted to clarify difference of concepts between both components.
Cheers, Shinobu On Thu, Mar 17, 2016 at 3:43 PM, Kevin.ZhangSen <okay22m...@163.com> wrote: > Hi Shinobu, > > Thanks for your questions. My reply is behind your questions. :) > > Best Regards, > Kevin (Sen Zhang) > > > At 2016-03-17 12:43:14, "Shinobu Kinjo" <shinobu...@gmail.com> wrote: >>Thank you for your explanation in detail. >> >>On Thu, Mar 17, 2016 at 12:57 PM, zs <okay22m...@163.com> wrote: >>> Hi Shinobu, >>> >>> There are some differences between clouds, the major task of jacket is >>> how >>> to shield the differences. So that jacket will not be an API gateway, it >>> has >>> the objects management and function processing, for example : >>> 1. Unified resource uuid allocation: When users call jacket resource >>> create >>> API, jacket will allocate the uuid for the resource according to jacket's >>> uuid format, then jacket will associate it with the unique identification >>> in >>> provider cloud, because of the different unique identification and the >>> different behaviour in clouds. >> >>The Jacket will absorb the difference between clouds, won't it? > Kevin: Yes, it will. >>> e.g. a) AWS can't support to create a volume from an AMI image and >>> boot a virtual machine from a boot volume, so that when users create a >>> volume from an image, jacket will just create a volume record in >>> database, >>> after the virtual machine is created in AWS, jacket will get the boot >>> volume's uuid in AWS and write the relations into the mapping table in >>> database. >>> b) Creating a volume's snapshot, AWS will return a job id, >>> and >>> users will get the snapshot's id after the job startes. Jacket will >>> return >>> the snapshot's id in jacket, then jacket will query the snapshot's id in >>> AWS >>> and write the relations into the mapping table in database. >>> >> >>Then will the Tricircle make use of mapped uuid to manage whatever >>created resource, If both components will interact each other? > Kevin: Sorry, I don't agree with you. Jacket will record the resources' > status. For example, in case of creating snapshot in AWS, Jacket will query > the job's status periodically, before Jacket get the real snapshot id in > AWS. At this time users query the snapshot's status, Jacket will return > 'Pending' defined by Jacket. But Tricircle is developed with stateless > design, they are conflicting. If we do that like you say, I think there will > be a bottleneck for Tricircle to manage a more large scale VMs, and then we > still need a stateless layer just like the current Tricircle solution. So my > opinion is to simplify each layer's function, let each layer do their job. > :) >>> 2. Fake volume management: Some clouds have not the complete volume >>> management, for example, VMware vCloud Director have no the boot volume >>> object, and it can't support volume's backup and snapshot, so that jacket >>> will implement these functions for this kind of clouds. >>> >> >>Reading your explanation, at the initial stage of the Jacket, it seems >>to focus on management of the Cinder resource, but it aims to: > Kevin: Not exactly. We need solve the account management, unified flavor, > unified image and how to take over the legacy resources in the provider > clouds. Jacket's wiki has the description about these: > https://wiki.openstack.org/wiki/Jacket :) >> > There will be more differences of clouds' behaviour and function. >> Jacket's >> > target is to shield these differences and let users feel that >>they are using >> > just one cloud. >> >>Cheers, >>Shinobu >> >>> Thanks. >>> >>> Best Regards, >>> Kevin (Sen Zhang) >>> >>> >>> At 2016-03-17 05:47:35, "Shinobu Kinjo" <shinobu...@gmail.com> wrote: >>>>On Wed, Mar 16, 2016 at 9:58 PM, zs <okay22m...@163.com> wrote: >>>>> Hi Gordon, >>>>> >>>>> Thank you for your suggestion. >>>>> >>>>> I think jacket is different from tricircle. Because tricircle focuses >>>>> on >>>>> OpenStack deployment across multiple sites, but jacket focuses on how >>>>> to >>>>> manage the different clouds just like one cloud. There are some >>>>> differences: >>>>> 1. Account management and API model: Tricircle faces multiply OpenStack >>>>> instances which can share one Keystone and have the same API model, but >>>>> jacket will face the different clouds which have the respective service >>>>> and >>>>> different API model. For example, VMware vCloud Director has no volume >>>>> management like OpenStack and AWS, jacket will offer a fake volume >>>>> management for this kind of cloud. >>>> >>>>The Jacket will be kind of API gateway for different cloud systems, won't >>>> it? >>>> >>>>> 2. Image management: One image just can run in one cloud, jacket need >>>>> consider how to solve this problem. >>>>> 3. Flavor management: Different clouds have different flavors which can >>>>> not >>>>> be operated by users. Jacket will face this problem but there will be >>>>> no >>>>> this problem in tricircle. >>>>> 4. Legacy resources adoption: Because of the different API modles, it >>>>> will >>>>> be a huge challenge for jacket. >>>>> >>>>> I think it is maybe a good solution that jacket works to unify the API >>>>> model >>>>> for different clouds, and then using tricircle to offer the management >>>>> of >>>>> a >>>>> large scale VMs. >>>>> >>>>> Best Regards, >>>>> Kevin (Sen Zhang) >>>>> >>>>> >>>>> At 2016-03-16 19:51:33, "gordon chung" <g...@live.ca> wrote: >>>>>> >>>>>> >>>>>>On 16/03/2016 4:03 AM, zs wrote: >>>>>>> Hi all, >>>>>>> >>>>>>> There is a new project "jacket" to manage multiply clouds. The jacket >>>>>>> wiki is: https://wiki.openstack.org/wiki/Jacket >>>>>>> Please review it and give your comments. Thanks. >>>>>>> >>>>>>> Best Regards, >>>>>>> >>>>>>> Kevin (Sen Zhang) >>>>>>> >>>>>>> >>>>>> >>>>>>i don't know exact details of either project, but i suggest you >>>>>>collaborate with tricircle project[1] because it seems you are >>>>>>addressing the same user story (and in a very similar fashion). not >>>>>> sure >>>>>>if it's a user story for OpenStack itself, but no point duplicating >>>>>> efforts. >>>>>> >>>>>>[1] https://wiki.openstack.org/wiki/Tricircle >>>>>> >>>>>>cheers, >>>>>> >>>>>>-- >>>>>>gord >>>>>> >>>>>>__________________________________________________________________________ >>>>>>OpenStack Development Mailing List (not for usage questions) >>>>>>Unsubscribe: >>>>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >>>>>>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> __________________________________________________________________________ >>>>> OpenStack Development Mailing List (not for usage questions) >>>>> Unsubscribe: >>>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>>> >>>> >>>> >>>> >>>>-- >>>>Email: >>>>shin...@linux.com >>>>GitHub: >>>>shinobu-x >>>>Blog: >>>>Life with Distributed Computational System based on OpenSource >>>> >>>>__________________________________________________________________________ >>>>OpenStack Development Mailing List (not for usage questions) >>>>Unsubscribe: >>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >>>>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >>> >>> >>> >>> >>> >>> >>> __________________________________________________________________________ >>> OpenStack Development Mailing List (not for usage questions) >>> Unsubscribe: >>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >> >> >> >>-- >>Email: >>shin...@linux.com >>GitHub: >>shinobu-x >>Blog: >>Life with Distributed Computational System based on OpenSource >> >>__________________________________________________________________________ >>OpenStack Development Mailing List (not for usage questions) >>Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Email: shin...@linux.com GitHub: shinobu-x Blog: Life with Distributed Computational System based on OpenSource __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev