Re: [openstack-dev] [jacket] Introduction to jacket, a new project

[Shinobu Kinjo]

Kevin,

Quick question.
Does one OpenStack infrastructure have to be dedicated for one Jacket instance?

Cheers,
Shinobu


On Thu, Mar 24, 2016 at 8:24 PM, Kevin.ZhangSen  wrote:
> Hi Ghanshyam,
>
> Thank you for your sugesstions, and I agree with your opinion that the
> service outside OpenStack is better. In fact I am considering what API
> Jacket will offer. It is better to offer the OpenStack API directly. But
> there will be a question how to modify as little code as possible to keep
> the same API compatibility with OpenStack after OpenStack updates the API
> version. I think this will be an interesting question, but we can try to let
> Jacket offer the OpenStack API.
>
> The reply about other query is below. If there are any questions, please
> tell me. Thank you again.
>
> Best Regards,
> Kevin (Sen Zhang)
>
> At 2016-03-24 11:58:47, "GHANSHYAM MANN"  wrote:
>>Hi Kevin,
>>
>>Its always nice idea as jacket has but not sure how feasible and
>>valuable it would be. For doing API translation and gateway, there are
>>many available and one I remember is Aviator (based on ruby gem) [1],
>>not sure how active it is now.
>>
>>As your idea is more about consuming all differences between different
>>cloud, few query-
>>
>> 1. Different clouds have very much different API model and feature
>>they provides, how  worth it is to provide missing/different features
>>at jacket layer? its then kind of another layer of cloud layer you
>>will end up.
> Kevin: We will provide the commonly used functions to let the users manage
> the different clouds just like one kind of cloud, for example VMs
> management(create/destroy/start/stop/restart/rebuild...) and volume
> management(create/delete/backup/snapshot). About network, there is a
> solution to use neutron to offer network function through the overlay
> virtual network based on the provider clouds’ virtual network. This will be
> another project, not in Jacket.
>> 2. To support that idea through OpenStack standard API, you need to
>>inserting jacket driver all over the components which end up having
>>another layer gets inserted there. Maintainability of that is another
>>issue for each OpenStack components.
> Kevin: I agree with you. Jacket offer OpenStack will be better.
>>IMO, outside layer (from OpenStack ) which can do all these would be
>>nice something which can redirect API services at top level top and do
>>what all conversion, consume difference etc.
>>
>>[1] https://github.com/aviator/aviator
>>
>>Regards
>>Ghanshyam Mann
>>
>>
>>On Wed, Mar 16, 2016 at 9:58 PM, zs  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.
>>> 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"  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:
 

Re: [openstack-dev] [jacket] Introduction to jacket, a new project

[Kevin.ZhangSen]

Hi Ghanshyam,

Thank you for your sugesstions, and I agree with your opinion that the service 
outside OpenStack is better. In fact I am considering what API Jacket will 
offer. It is better to offer the OpenStack API directly. But there will be a 
question how to modify as little code as possible to keep the same API 
compatibility with OpenStack after OpenStack updates the API version. I think 
this will be an interesting question, but we can try to let Jacket offer the 
OpenStack API.



The reply about other query is below. If there are any questions, please tell 
me. Thank you again.


Best Regards,
Kevin (Sen Zhang)


At 2016-03-24 11:58:47, "GHANSHYAM MANN"  wrote:
>Hi Kevin,
>
>Its always nice idea as jacket has but not sure how feasible and
>valuable it would be. For doing API translation and gateway, there are
>many available and one I remember is Aviator (based on ruby gem) [1],
>not sure how active it is now.
>
>As your idea is more about consuming all differences between different
>cloud, few query-
>
> 1. Different clouds have very much different API model and feature
>they provides, how  worth it is to provide missing/different features
>at jacket layer? its then kind of another layer of cloud layer you
>will end up.
Kevin: We will provide the commonly used functions to let the users manage the 
different clouds just like one kind of cloud, for example VMs 
management(create/destroy/start/stop/restart/rebuild...) and volume 
management(create/delete/backup/snapshot). About network, there is a solution 
to use neutron to offer network function through the overlay virtual network 
based on the provider clouds’ virtual network. This will be another project, 
not in Jacket.
> 2. To support that idea through OpenStack standard API, you need to
>inserting jacket driver all over the components which end up having
>another layer gets inserted there. Maintainability of that is another
>issue for each OpenStack components.
Kevin: I agree with you. Jacket offer OpenStack will be better.
>IMO, outside layer (from OpenStack ) which can do all these would be
>nice something which can redirect API services at top level top and do
>what all conversion, consume difference etc.
>
>[1] https://github.com/aviator/aviator
>
>Regards
>Ghanshyam Mann
>
>
>On Wed, Mar 16, 2016 at 9:58 PM, zs  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.
>> 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"  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: 

Re: [openstack-dev] [jacket] Introduction to jacket, a new project

[GHANSHYAM MANN]

Hi Kevin,

Its always nice idea as jacket has but not sure how feasible and
valuable it would be. For doing API translation and gateway, there are
many available and one I remember is Aviator (based on ruby gem) [1],
not sure how active it is now.

As your idea is more about consuming all differences between different
cloud, few query-

 1. Different clouds have very much different API model and feature
they provides, how  worth it is to provide missing/different features
at jacket layer? its then kind of another layer of cloud layer you
will end up.

 2. To support that idea through OpenStack standard API, you need to
inserting jacket driver all over the components which end up having
another layer gets inserted there. Maintainability of that is another
issue for each OpenStack components.

IMO, outside layer (from OpenStack ) which can do all these would be
nice something which can redirect API services at top level top and do
what all conversion, consume difference etc.

[1] https://github.com/aviator/aviator

Regards
Ghanshyam Mann


On Wed, Mar 16, 2016 at 9:58 PM, zs  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.
> 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"  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
>

__
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

Re: [openstack-dev] [jacket] Introduction to jacket, a new project

[Kevin.ZhangSen]

Thanks for Joe's explanation. :)


Best Regards,
Kevin (Sen Zhang)




在 2016-03-17 09:58:38，"joehuang" <joehu...@huawei.com> 写道：


Agree with Kevin,

 

Currently Tricircle mainly focuses on the API gateway and networking automation 
across multiple OpenStack instances. The hybrid cloud PoC is built based on 
Tricircle in Tokyo Summit: 
https://www.openstack.org/summit/tokyo-2015/videos/presentation/huawei-openstack-enabled-hybrid-cloud

 

Where Tricircle manages multiple small OpenStack instances, and different 
OpenStack instance using “jacket” to integrate AWS/vCloud. The jacket provide a 
way of abstract of hybrid cloud.

 

Best Regards

Chaoyi Huang ( Joe Huang )

 

From: zs [mailto:okay22m...@163.com]
Sent: Wednesday, March 16, 2016 8:59 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [jacket] Introduction to jacket, a new project

 

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.
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

Re: [openstack-dev] [jacket] Introduction to jacket, a new project

[Kevin.ZhangSen]

Hi Phuong,

I will mail you when the works starts. Thanks. :)

Best Regards,
Kevin (Sen Zhang)







在 2016-03-18 11:07:13，"phuon...@vn.fujitsu.com" <phuon...@vn.fujitsu.com> 写道：


Hi Kevin,

 

I am interesting in Jacket too, so I would like to contribute once the work 
starts.

 

Thanks,

Phuong.

 

From: Janki Chhatbar [mailto:jankihchhat...@gmail.com]
Sent: Wednesday, March 16, 2016 8:21 PM
To: zs
Subject: Re: [openstack-dev] [jacket] Introduction to jacket, a new project

 

Hi Kevin

 

I read the wiki and quite liked it. Good going. I would ‎like to contribute to 
it once the work starts

 Do let me know about it.





Thanks

Janki

 

Sent from my BlackBerry 10 smartphone.

|

From: zs

Sent: Wednesday, 16 March 2016 18:30

To: OpenStack Development Mailing List (not for usage questions)

Reply To: OpenStack Development Mailing List (not for usage questions)

Subject: Re: [openstack-dev] [jacket] Introduction to jacket, a new project

|

 

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.
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

Re: [openstack-dev] [jacket] Introduction to jacket, a new project

[zs]

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 uniqueidentification and the different 
behaviourin clouds.
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.

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.

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.
Thanks.

Best Regards,
Kevin (Sen Zhang)


At 2016-03-17 05:47:35, "Shinobu Kinjo"  wrote:
>On Wed, Mar 16, 2016 at 9:58 PM, zs  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"  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

Re: [openstack-dev] [jacket] Introduction to jacket, a new project

[Shinobu Kinjo]

Thank you for your explanation in detail.

On Thu, Mar 17, 2016 at 12:57 PM, zs  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?

> 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?

> 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:

> 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"  wrote:
>>On Wed, Mar 16, 2016 at 9:58 PM, zs  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"  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
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> 

Re: [openstack-dev] [jacket] Introduction to jacket, a new project

[Janki Chhatbar]

  Hi KevinI read the wiki and quite liked it. Good going. I would ‎like to contribute to it once the work starts Do let me know about it.ThanksJankiSent from my BlackBerry 10 smartphone.From: zsSent: Wednesday, 16 March 2016 18:30To: OpenStack Development Mailing List (not for usage questions)Reply To: OpenStack Development Mailing List (not for usage questions)Subject: Re: [openstack-dev] [jacket] Introduction to jacket, a new projectHi 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.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"  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

Re: [openstack-dev] [jacket] Introduction to jacket, a new project

[gordon chung]

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

Re: [openstack-dev] [jacket] Introduction to jacket, a new project

[Kevin.ZhangSen]

Hi Janki,


I am very glad you like it. I will mail you when the work starts.  :)


Best Regards,
Kevin (Sen Zhang)




At 2016-03-16 21:20:52, "Janki Chhatbar" <jankihchhat...@gmail.com> wrote:

Hi Kevin


I read the wiki and quite liked it. Good going. I would ‎like to contribute to 
it once the work starts
 Do let me know about it.


Thanks
Janki


Sent from my BlackBerry 10 smartphone.
|
From: zs
Sent: Wednesday, 16 March 2016 18:30
To: OpenStack Development Mailing List (not for usage questions)
Reply To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [jacket] Introduction to jacket, a new project
|


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.
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

Re: [openstack-dev] [jacket] Introduction to jacket, a new project

[Kevin.ZhangSen]

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"  wrote:
>Thank you for your explanation in detail.
>
>On Thu, Mar 17, 2016 at 12:57 PM, zs  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"  wrote:
>>>On Wed, Mar 16, 2016 at 9:58 PM, zs  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

Re: [openstack-dev] [jacket] Introduction to jacket, a new project

[zs]

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.
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"  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

Re: [openstack-dev] [jacket] Introduction to jacket, a new project

[Shinobu Kinjo]

On Wed, Mar 16, 2016 at 9:58 PM, zs  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"  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

Re: [openstack-dev] [jacket] Introduction to jacket, a new project

[Shinobu Kinjo]

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  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"  wrote:
>>Thank you for your explanation in detail.
>>
>>On Thu, Mar 17, 2016 at 12:57 PM, zs  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"  wrote:
On Wed, Mar 16, 2016 at 9:58 PM, zs  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
> 

Re: [openstack-dev] [jacket] Introduction to jacket, a new project

[joehuang]

Agree with Kevin,

Currently Tricircle mainly focuses on the API gateway and networking automation 
across multiple OpenStack instances. The hybrid cloud PoC is built based on 
Tricircle in Tokyo Summit: 
https://www.openstack.org/summit/tokyo-2015/videos/presentation/huawei-openstack-enabled-hybrid-cloud

Where Tricircle manages multiple small OpenStack instances, and different 
OpenStack instance using "jacket" to integrate AWS/vCloud. The jacket provide a 
way of abstract of hybrid cloud.

Best Regards
Chaoyi Huang ( Joe Huang )

From: zs [mailto:okay22m...@163.com]
Sent: Wednesday, March 16, 2016 8:59 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [jacket] Introduction to jacket, a new project

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.
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<mailto: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<mailto: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

Re: [openstack-dev] [jacket] Introduction to jacket, a new project

[phuon...@vn.fujitsu.com]

Hi Kevin,

I am interesting in Jacket too, so I would like to contribute once the work 
starts.

Thanks,
Phuong.

From: Janki Chhatbar [mailto:jankihchhat...@gmail.com]
Sent: Wednesday, March 16, 2016 8:21 PM
To: zs
Subject: Re: [openstack-dev] [jacket] Introduction to jacket, a new project

Hi Kevin

I read the wiki and quite liked it. Good going. I would ‎like to contribute to 
it once the work starts
 Do let me know about it.


Thanks
Janki

Sent from my BlackBerry 10 smartphone.
From: zs
Sent: Wednesday, 16 March 2016 18:30
To: OpenStack Development Mailing List (not for usage questions)
Reply To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [jacket] Introduction to jacket, a new project


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.
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<mailto: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<mailto: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

[openstack-dev] [jacket] Introduction to jacket, a new project

[zs]

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)
__
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