Open Stack

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 <okay22many at 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.kj at gmail.com> wrote:
>>Thank you for your explanation in detail.
>>
>>On Thu, Mar 17, 2016 at 12:57 PM, zs <okay22many at 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.kj at gmail.com> wrote:
>>>>On Wed, Mar 16, 2016 at 9:58 PM, zs <okay22many at 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" <gord at 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-request at 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-request at lists.openstack.org?subject:unsubscribe
>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>>
>>>>
>>>>
>>>>
>>>>--
>>>>Email:
>>>>shinobu at 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-request at 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-request at lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>>
>>
>>--
>>Email:
>>shinobu at 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-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Email:
shinobu at linux.com
GitHub:
shinobu-x
Blog:
Life with Distributed Computational System based on OpenSource