Date   
Re: Incubation proposal: HuaweiCloud CPI

Guillaume Berche
 

Hi Jun and Marco,

If the huawei team plans to provide differentiated features beyond what the openstack CPI provides, it seems useful that the openstack CPI team provides some feedback on whether the openstack CPI could support some custom extensions (in order to avoid having the huawei cpi being a complete fork of the openstack cpi), such as in the form of plugins.

In the short term, I share it is hard for users new to the CF community to understand that bosh can be used on public infrastructure through use of standard apis such as openstack, and that a dedicated bosh cpi is'nt necessary for each public cloud. I worry that as a result some misleaded customers ask for a dedicated public cloud cpi whereas this might not be the optimal solution for them nor to the community overall, and challenges are elsewhere. Cultural diversity may make it hard for some engineering and marketing teams to educate users into this vision, and it's tempting to fork the standard-based openstack cpi to quickly respond to initial customer request, even if this does not provide any differentiated features that doc contribs could address.

I believe the CF foundation page listed supported infrastructure providers [1], bosh-docs [2] and cf-docs [3] could help educate users new to the community to discover public clouds that supporting bosh and cloudfoundry through the openstack standard and were proven to provide 1st class support in bosh and CF (beyond the basic CPI contract as I mentioned in my previous email). I may follow up a dedicated thread (to the CFF and CPI docs teams) on this if this can help Huawei get the same level of public user visibility through the use of the openstack CPI than other public cloud vendors have with a dedicated CPI.

>   Different vendors have the right to choose different strategies.
>    We would like to choose the API or config item that really suitable for our customer.
>    Those APIs are not related to OpenStack, so we still want to create our new HuaweiCloud CPI in PMC.

This is fine. I just wanted to bring to your attention the effort required to meet expected quality standards, and maintain them overtime. In particular, I understand cpis are expected to provide user facing documentation such as [4] [5] which I did not yet see mentioned in your incubation proposal (nor your responses to my email in this thread).

Similarly, incubator projects are expected to provide public backlogs that give insight to the community about planned future work. Can you please share such backlog with the community ?

> I would like to create a new group named "huawei" in slack channel

That would be great. You can actually create one yourself by just pressing the + button, see screenshot below. I'll be happy to share our experience/challenges using the openstack cpi on Huawei-powered Orange Flexible Engine cloud.

> As I understand each vendor does't have different features for bosh. The only difference between each Bosh CPI
> is that they have different APIs. So it would be better to create a new CPI that like the other CPI does.

I believe this is inaccurate: bosh supports differentiates features by each CPI in the following forms:
a) custom cloud properties [6] associated to AZ, networks, disk types, vm types, declare in cloud-config [6] and referenced within bosh manifests [7]
b) specifically vm_extensions [8] allows to specify arbitrary IaaS specific configuration associated to a VM such as security groups or load balancers pool membership

This enables clouds to expose some differentiated features to their users without extensions to bosh. 

> Huawei has made a lot of private extensions to the OpenStack API in order to fulfill
>  Huawei Cloud’s IaaS needs. These private extensions are unique to Huawei Cloud’s application scenarios and
> do not apply to OpenStack platform, and therefore will not be accepted by the OpenStack community.

@Marco, can you please comment on whether the openstack cpi team would support the Huawei team into designing support for extensions in the openstack CPI, such extensions would use custom huawei APIs ?



image.png

Regards,

Guillaume.


On Fri, Aug 31, 2018 at 12:27 PM jun zhong <jun.zhongjun2@...> wrote:
Hi Guillaume,

 There are another points we have considered:
 1、Huawei has made a lot of private extensions to the OpenStack API in order to fulfill
 Huawei Cloud’s IaaS needs. These private extensions are unique to Huawei Cloud’s application scenarios and
 do not apply to OpenStack platform, and therefore will not be accepted by the OpenStack community.
 Even if some of them are not used now, It's also worth to think about it in frontThis is
 why Huawei Cloud needs its own CPI stead of using OpenStack CPI. It is also useful for HuaweiCloud in the furture.
 
 2、As I understand each vendor does't have different features for bosh. The only difference between each Bosh CPI
 is that they have different APIs. So it would be better to create a new CPI that like the other CPI does.

Thanks 
JUN

jun zhong <jun.zhongjun2@...> 于2018年8月30日周四 下午9:32写道:
Hi Guillaume,


Thanks for giving us so many suggestions.

1b- extend the openstack cpi with additional vm_properties support that leverage Huawei custom APIs and products.

--  Different vendors have the right to choose different strategies.
    We would like to choose the API or config item that really suitable for our customer.
    Those APIs are not related to OpenStack, so we still want to create our new HuaweiCloud CPI in PMC.


2- build a community of huawei cloud Bosh and CF users which can share experience, best practices, and provide feedback
 and improvements to the Huawei and CF Foundation teams. For example, create a "huawei" slack channel on the cloudfoundry slack [8][9].
 Our team would be happy to share our experiences with running CF on Orange Flexible Engine, such as glance quota diagnostics [15], or VRRP issues across VPCs [16].

-- I would like to create a new group named "huawei" in slack channel

3- provide 1st class support to Huawei cloud on bosh director, 
e.g. validate integration of Huawei Object Store Service [10] as a bosh director blobstore backend, and BBR backend [12]. Contribute docs and operators into bosh-deployment similarly to other Iaas [11], [12], as well as terraform configs into bbl [13]. Validate integration of Huawei RDS as a bosh director db backend [14]. We should suggest to avoid fragmentation of terraform providers among huawei powered clouds [20] [21] [22] [23] and their associated diverging github repos [24] [25], and rather try to unify them into a single provider with configureable endpoint.
4- provide 1st class support to Huawei cloud on cloudfoundry application runtime, e.g. validate integration of Huawei Object Store Service [10] as a CC blobstore backend and contribute associated bosh operators into cf-deployment [15] or best in bbl, along with terraform configs (when differing from openstack apis)

-- Is this a necessary request for new CPI? I saw some of the CPI doesn't support it now, such as: azure CPI


Re: Incubation proposal: HuaweiCloud CPI

jun zhong
 

Hi Guillaume,

 There are another points we have considered:
 1、Huawei has made a lot of private extensions to the OpenStack API in order to fulfill
 Huawei Cloud’s IaaS needs. These private extensions are unique to Huawei Cloud’s application scenarios and
 do not apply to OpenStack platform, and therefore will not be accepted by the OpenStack community.
 Even if some of them are not used now, It's also worth to think about it in frontThis is
 why Huawei Cloud needs its own CPI stead of using OpenStack CPI. It is also useful for HuaweiCloud in the furture.
 
 2、As I understand each vendor does't have different features for bosh. The only difference between each Bosh CPI
 is that they have different APIs. So it would be better to create a new CPI that like the other CPI does.

Thanks 
JUN

jun zhong <jun.zhongjun2@...> 于2018年8月30日周四 下午9:32写道:

Hi Guillaume,


Thanks for giving us so many suggestions.

1b- extend the openstack cpi with additional vm_properties support that leverage Huawei custom APIs and products.

--  Different vendors have the right to choose different strategies.
    We would like to choose the API or config item that really suitable for our customer.
    Those APIs are not related to OpenStack, so we still want to create our new HuaweiCloud CPI in PMC.


2- build a community of huawei cloud Bosh and CF users which can share experience, best practices, and provide feedback
 and improvements to the Huawei and CF Foundation teams. For example, create a "huawei" slack channel on the cloudfoundry slack [8][9].
 Our team would be happy to share our experiences with running CF on Orange Flexible Engine, such as glance quota diagnostics [15], or VRRP issues across VPCs [16].

-- I would like to create a new group named "huawei" in slack channel

3- provide 1st class support to Huawei cloud on bosh director, 
e.g. validate integration of Huawei Object Store Service [10] as a bosh director blobstore backend, and BBR backend [12]. Contribute docs and operators into bosh-deployment similarly to other Iaas [11], [12], as well as terraform configs into bbl [13]. Validate integration of Huawei RDS as a bosh director db backend [14]. We should suggest to avoid fragmentation of terraform providers among huawei powered clouds [20] [21] [22] [23] and their associated diverging github repos [24] [25], and rather try to unify them into a single provider with configureable endpoint.
4- provide 1st class support to Huawei cloud on cloudfoundry application runtime, e.g. validate integration of Huawei Object Store Service [10] as a CC blobstore backend and contribute associated bosh operators into cf-deployment [15] or best in bbl, along with terraform configs (when differing from openstack apis)

-- Is this a necessary request for new CPI? I saw some of the CPI doesn't support it now, such as: azure CPI


Guillaume Berche <bercheg@...> 于2018年8月30日周四 上午12:16写道:

Hi Jun,

Thanks for your additional precisions. 

If I understand you correctly:
- both huaweicloud.com and huawei powered clouds such as Orange Flexible Engines (or others such as DeutchTelecom cloud and Telefonica Cloud, powered by Huawei FusionSphere [0] ...) implement the subset of the openstack APIs required by the openstack CPI. Users of these clouds can use the openstack cpi and have to provision the prerequisite openstack objects as documented into [1], which include network, subnet, router, router_interface objects (which can be automatically provisioned using terraform using templates shared in [2]). 
- in addition, huaweicloud.com (and FusionSphere ?) supports a simplified networking model which include the VPC [3] and subnet concepts [4]

The huaweicloud cpi mostly uses the native openstack APIs in huaweicloud, except for networking where it uses the huawei specific simplified networking model: this brings the benefit of a simplier CPI configuration for operators, especially the ones familiar with the huaweicloud console: it makes them easier to map concepts visible in the console to cpi configuration fields. I understand The huaweicloud cpi does not currently bring any other features for bosh w.r.t. the openstack cpi.

If my understanding is correct, then it might make sense to instead contribute documentation refinements to the openstack cpi [5] and [2] as to guide huaweicloud console users into steps to configure the openstack CPI (such as step by step guide to provision and configure the associated VPC, possibly illustrated with terraform configs). 

My team at Orange went through the mapping huaweicloud console concepts to openstack ones in order to configure the terraform provider and bosh-director cloud-config, and indeed felt clarifying documentation would help.

Besides, I wonder if Huawei team is considering the following other contributions which I believe will bring great benefits to the Huawei customers and the overall community, in summary "bring Huawei cloud 1st class support in bosh and cloudfoundry":

1- validate the full openstack cpi coverage on huawei cloud, including latest features such as LBaaS support, or other vm-extensions. This may make sense to contribute computing and engineering resources to the Bosh stack cpi team and add Huawei cloud to the CF Foundation  CI pipelines, see related [7]
1b- extend the openstack cpi with additional vm_properties support that leverage Huawei custom APIs and products. It would be great to see work with the openstack CPI team to design support for openstack extensions in the openstack CPI in a similar fashion as the openstack validator custom extensions, that would avoid a complete fork of the openstack cpi.
2- build a community of huawei cloud Bosh and CF users which can share experience, best practices, and provide feedback and improvements to the Huawei and CF Foundation teams. For example, create a "huawei" slack channel on the cloudfoundry slack [8][9]. Our team would be happy to share our experiences with running CF on Orange Flexible Engine, such as glance quota diagnostics [15], or VRRP issues across VPCs [16].
3- provide 1st class support to Huawei cloud on bosh director, e.g. validate integration of Huawei Object Store Service [10] as a bosh director blobstore backend, and BBR backend [12]. Contribute docs and operators into bosh-deployment similarly to other Iaas [11], [12], as well as terraform configs into bbl [13]. Validate integration of Huawei RDS as a bosh director db backend [14]. We should suggest to avoid fragmentation of terraform providers among huawei powered clouds [20] [21] [22] [23] and their associated diverging github repos [24] [25], and rather try to unify them into a single provider with configureable endpoint.
4- provide 1st class support to Huawei cloud on cloudfoundry application runtime, e.g. validate integration of Huawei Object Store Service [10] as a CC blobstore backend and contribute associated bosh operators into cf-deployment [15] or best in bbl, along with terraform configs (when differing from openstack apis)

I look forward to learning more about Huawei plans to bring 1st class support to bosh and cloudfoundry.

Thanks in advance for Huawei contribs to the Cf community, and for reading through this way too long email :-)



Guillaume.

On Sat, Aug 25, 2018 at 4:04 AM jun zhong <jun.zhongjun2@...> wrote:
Hi  Guillaume,

Add a little additional description. The original OpenStack network model is network, subnet, and router. The simplified network simplified model is vpc, subnet in Huawei Public Cloud console.
so we add the new property named 'subnet_id', and the Port is not required in Huawei Public Cloud network API.
Is this clear to you?

Thanks
JUN

2018-08-25 9:25 GMT+08:00 jun zhong <jun.zhongjun2@...>:
Hi Guillaume,

All I said that network model APIs changes or how to choose CPI are about Huawei Public Cloud itself, not Huawei cloud powered Orange Flexible Engine.

Thanks
JUN

2018-08-25 0:13 GMT+08:00 Guillaume Berche <bercheg@...>:
Hi Jun,

Thanks for your response.

> If you are familiar with OpenStack, you can still choose to use openstack CPI.
> If you are familiar with Huawei cloud console, we recommend using HuaweiCloud CPI.

I'm not sure to understand how familiarity with cloud console relates to which CPI flavor to choose.

Can you please clarify what additional features would usage of huaweicloud CPI would provide w.r.t. straight usage of openstack CPI to access Huawei Public Cloud itself or Huawei cloud powered Orange Flexible Engine?

Thanks in advance,

Guillaume.


On Fri, Aug 24, 2018 at 11:43 AM jun zhong <jun.zhongjun2@...> wrote:
Hi  MarcoGuillaume,

@Marco, Thanks for your arrangement.

@Guillaume

Yeah, The OpenStack CPI is work on Huawei cloud powered Orange Flexible Engine, but the
HuaweiCloud CPI is work on Huawei Public Cloud itself[1]. There are differences between the HuaweiCloud
console and OpenStack API models, some users are not aware of the relationship between them,
and it is difficult for people who are familiar with the console.

If you are familiar with OpenStack, you can still choose to use openstack CPI.
If you are familiar with Huawei cloud console, we recommend using HuaweiCloud CPI.

We changed the part of code about network mode in huaweicloud CPI [1],
we use our own network mode APIs instead of openstack newtork mode APIs,
and the Port is not required for HuaweiCloud, the new property is 'subnet_id', and so on.


Thanks
JUN


2018-08-21 23:43 GMT+08:00 Marco Voelz <marco.voelz@...>:

Dear JUN,

 

Thanks for the proposal. I'm asking everyone for feedback until August 31st: Make yourself heard, start discussions and make sure to ask the questions you have until that deadline. If there are no outstanding major discussion points, we will proceed with voting for incubation in the week after that.

 

Warm regards

Marco

 

From: <cf-bosh@...> on behalf of jun zhong <jun.zhongjun2@...>
Reply-To: "cf-bosh@..." <cf-bosh@...>
Date: Tuesday, 21. August 2018 at 11:20
To: "cf-bosh@..." <cf-bosh@...>
Subject: [cf-bosh] Incubation proposal: HuaweiCloud CPI

 

Hi all,

We want to propose the HuaweiCloud CPI for incubation in the BOSH PMC.
https://lists.cloudfoundry.org/g/cf-bosh/message/2532?p=,,,20,0,0,0::Created,,Huaweicloud,20,2,0,23810700 

The HuaweiCloud Bosh CPI [1] and configuration items for bosh [6] and cf [7] is ready now.  The Bosh HuaweiCloud CPI is used in our internal product.

 

We also add CI testing (CF HuaweiCloud Validator[3] [4] and BOSH Acceptance Tests (BATS)[2] ) to check if Huaweicloud CPI is ready to run BOSH and install

Cloud Foundry. The CI result will be displayed in each Huaweicloud CPI PR [5].

 

 




The project would follow a distributed committer model.

Project Lead:
Edward Lee
Initial Committers:
- ZhongJun (Huawei)
-Tommylikehu ( Huawei )

- LiuSheng  ( Huawei )

We are looking forward to your questions and comments.

Thanks,
JUN

Image removed by sender.

 




Re: Incubation proposal: HuaweiCloud CPI

jun zhong
 

Hi Guillaume,


Thanks for giving us so many suggestions.

1b- extend the openstack cpi with additional vm_properties support that leverage Huawei custom APIs and products.

--  Different vendors have the right to choose different strategies.
    We would like to choose the API or config item that really suitable for our customer.
    Those APIs are not related to OpenStack, so we still want to create our new HuaweiCloud CPI in PMC.


2- build a community of huawei cloud Bosh and CF users which can share experience, best practices, and provide feedback
 and improvements to the Huawei and CF Foundation teams. For example, create a "huawei" slack channel on the cloudfoundry slack [8][9].
 Our team would be happy to share our experiences with running CF on Orange Flexible Engine, such as glance quota diagnostics [15], or VRRP issues across VPCs [16].

-- I would like to create a new group named "huawei" in slack channel

3- provide 1st class support to Huawei cloud on bosh director, 
e.g. validate integration of Huawei Object Store Service [10] as a bosh director blobstore backend, and BBR backend [12]. Contribute docs and operators into bosh-deployment similarly to other Iaas [11], [12], as well as terraform configs into bbl [13]. Validate integration of Huawei RDS as a bosh director db backend [14]. We should suggest to avoid fragmentation of terraform providers among huawei powered clouds [20] [21] [22] [23] and their associated diverging github repos [24] [25], and rather try to unify them into a single provider with configureable endpoint.
4- provide 1st class support to Huawei cloud on cloudfoundry application runtime, e.g. validate integration of Huawei Object Store Service [10] as a CC blobstore backend and contribute associated bosh operators into cf-deployment [15] or best in bbl, along with terraform configs (when differing from openstack apis)

-- Is this a necessary request for new CPI? I saw some of the CPI doesn't support it now, such as: azure CPI


Guillaume Berche <bercheg@...> 于2018年8月30日周四 上午12:16写道:


Hi Jun,

Thanks for your additional precisions. 

If I understand you correctly:
- both huaweicloud.com and huawei powered clouds such as Orange Flexible Engines (or others such as DeutchTelecom cloud and Telefonica Cloud, powered by Huawei FusionSphere [0] ...) implement the subset of the openstack APIs required by the openstack CPI. Users of these clouds can use the openstack cpi and have to provision the prerequisite openstack objects as documented into [1], which include network, subnet, router, router_interface objects (which can be automatically provisioned using terraform using templates shared in [2]). 
- in addition, huaweicloud.com (and FusionSphere ?) supports a simplified networking model which include the VPC [3] and subnet concepts [4]

The huaweicloud cpi mostly uses the native openstack APIs in huaweicloud, except for networking where it uses the huawei specific simplified networking model: this brings the benefit of a simplier CPI configuration for operators, especially the ones familiar with the huaweicloud console: it makes them easier to map concepts visible in the console to cpi configuration fields. I understand The huaweicloud cpi does not currently bring any other features for bosh w.r.t. the openstack cpi.

If my understanding is correct, then it might make sense to instead contribute documentation refinements to the openstack cpi [5] and [2] as to guide huaweicloud console users into steps to configure the openstack CPI (such as step by step guide to provision and configure the associated VPC, possibly illustrated with terraform configs). 

My team at Orange went through the mapping huaweicloud console concepts to openstack ones in order to configure the terraform provider and bosh-director cloud-config, and indeed felt clarifying documentation would help.

Besides, I wonder if Huawei team is considering the following other contributions which I believe will bring great benefits to the Huawei customers and the overall community, in summary "bring Huawei cloud 1st class support in bosh and cloudfoundry":

1- validate the full openstack cpi coverage on huawei cloud, including latest features such as LBaaS support, or other vm-extensions. This may make sense to contribute computing and engineering resources to the Bosh stack cpi team and add Huawei cloud to the CF Foundation  CI pipelines, see related [7]
1b- extend the openstack cpi with additional vm_properties support that leverage Huawei custom APIs and products. It would be great to see work with the openstack CPI team to design support for openstack extensions in the openstack CPI in a similar fashion as the openstack validator custom extensions, that would avoid a complete fork of the openstack cpi.
2- build a community of huawei cloud Bosh and CF users which can share experience, best practices, and provide feedback and improvements to the Huawei and CF Foundation teams. For example, create a "huawei" slack channel on the cloudfoundry slack [8][9]. Our team would be happy to share our experiences with running CF on Orange Flexible Engine, such as glance quota diagnostics [15], or VRRP issues across VPCs [16].
3- provide 1st class support to Huawei cloud on bosh director, e.g. validate integration of Huawei Object Store Service [10] as a bosh director blobstore backend, and BBR backend [12]. Contribute docs and operators into bosh-deployment similarly to other Iaas [11], [12], as well as terraform configs into bbl [13]. Validate integration of Huawei RDS as a bosh director db backend [14]. We should suggest to avoid fragmentation of terraform providers among huawei powered clouds [20] [21] [22] [23] and their associated diverging github repos [24] [25], and rather try to unify them into a single provider with configureable endpoint.
4- provide 1st class support to Huawei cloud on cloudfoundry application runtime, e.g. validate integration of Huawei Object Store Service [10] as a CC blobstore backend and contribute associated bosh operators into cf-deployment [15] or best in bbl, along with terraform configs (when differing from openstack apis)

I look forward to learning more about Huawei plans to bring 1st class support to bosh and cloudfoundry.

Thanks in advance for Huawei contribs to the Cf community, and for reading through this way too long email :-)



Guillaume.

On Sat, Aug 25, 2018 at 4:04 AM jun zhong <jun.zhongjun2@...> wrote:
Hi  Guillaume,

Add a little additional description. The original OpenStack network model is network, subnet, and router. The simplified network simplified model is vpc, subnet in Huawei Public Cloud console.
so we add the new property named 'subnet_id', and the Port is not required in Huawei Public Cloud network API.
Is this clear to you?

Thanks
JUN

2018-08-25 9:25 GMT+08:00 jun zhong <jun.zhongjun2@...>:
Hi Guillaume,

All I said that network model APIs changes or how to choose CPI are about Huawei Public Cloud itself, not Huawei cloud powered Orange Flexible Engine.

Thanks
JUN

2018-08-25 0:13 GMT+08:00 Guillaume Berche <bercheg@...>:
Hi Jun,

Thanks for your response.

> If you are familiar with OpenStack, you can still choose to use openstack CPI.
> If you are familiar with Huawei cloud console, we recommend using HuaweiCloud CPI.

I'm not sure to understand how familiarity with cloud console relates to which CPI flavor to choose.

Can you please clarify what additional features would usage of huaweicloud CPI would provide w.r.t. straight usage of openstack CPI to access Huawei Public Cloud itself or Huawei cloud powered Orange Flexible Engine?

Thanks in advance,

Guillaume.


On Fri, Aug 24, 2018 at 11:43 AM jun zhong <jun.zhongjun2@...> wrote:
Hi  MarcoGuillaume,

@Marco, Thanks for your arrangement.

@Guillaume

Yeah, The OpenStack CPI is work on Huawei cloud powered Orange Flexible Engine, but the
HuaweiCloud CPI is work on Huawei Public Cloud itself[1]. There are differences between the HuaweiCloud
console and OpenStack API models, some users are not aware of the relationship between them,
and it is difficult for people who are familiar with the console.

If you are familiar with OpenStack, you can still choose to use openstack CPI.
If you are familiar with Huawei cloud console, we recommend using HuaweiCloud CPI.

We changed the part of code about network mode in huaweicloud CPI [1],
we use our own network mode APIs instead of openstack newtork mode APIs,
and the Port is not required for HuaweiCloud, the new property is 'subnet_id', and so on.


Thanks
JUN


2018-08-21 23:43 GMT+08:00 Marco Voelz <marco.voelz@...>:

Dear JUN,

 

Thanks for the proposal. I'm asking everyone for feedback until August 31st: Make yourself heard, start discussions and make sure to ask the questions you have until that deadline. If there are no outstanding major discussion points, we will proceed with voting for incubation in the week after that.

 

Warm regards

Marco

 

From: <cf-bosh@...> on behalf of jun zhong <jun.zhongjun2@...>
Reply-To: "cf-bosh@..." <cf-bosh@...>
Date: Tuesday, 21. August 2018 at 11:20
To: "cf-bosh@..." <cf-bosh@...>
Subject: [cf-bosh] Incubation proposal: HuaweiCloud CPI

 

Hi all,

We want to propose the HuaweiCloud CPI for incubation in the BOSH PMC.
https://lists.cloudfoundry.org/g/cf-bosh/message/2532?p=,,,20,0,0,0::Created,,Huaweicloud,20,2,0,23810700 

The HuaweiCloud Bosh CPI [1] and configuration items for bosh [6] and cf [7] is ready now.  The Bosh HuaweiCloud CPI is used in our internal product.

 

We also add CI testing (CF HuaweiCloud Validator[3] [4] and BOSH Acceptance Tests (BATS)[2] ) to check if Huaweicloud CPI is ready to run BOSH and install

Cloud Foundry. The CI result will be displayed in each Huaweicloud CPI PR [5].

 

 




The project would follow a distributed committer model.

Project Lead:
Edward Lee
Initial Committers:
- ZhongJun (Huawei)
-Tommylikehu ( Huawei )

- LiuSheng  ( Huawei )

We are looking forward to your questions and comments.

Thanks,
JUN

Image removed by sender.

 




Re: Incubation proposal: HuaweiCloud CPI

Guillaume Berche
 


Hi Jun,

Thanks for your additional precisions. 

If I understand you correctly:
- both huaweicloud.com and huawei powered clouds such as Orange Flexible Engines (or others such as DeutchTelecom cloud and Telefonica Cloud, powered by Huawei FusionSphere [0] ...) implement the subset of the openstack APIs required by the openstack CPI. Users of these clouds can use the openstack cpi and have to provision the prerequisite openstack objects as documented into [1], which include network, subnet, router, router_interface objects (which can be automatically provisioned using terraform using templates shared in [2]). 
- in addition, huaweicloud.com (and FusionSphere ?) supports a simplified networking model which include the VPC [3] and subnet concepts [4]

The huaweicloud cpi mostly uses the native openstack APIs in huaweicloud, except for networking where it uses the huawei specific simplified networking model: this brings the benefit of a simplier CPI configuration for operators, especially the ones familiar with the huaweicloud console: it makes them easier to map concepts visible in the console to cpi configuration fields. I understand The huaweicloud cpi does not currently bring any other features for bosh w.r.t. the openstack cpi.

If my understanding is correct, then it might make sense to instead contribute documentation refinements to the openstack cpi [5] and [2] as to guide huaweicloud console users into steps to configure the openstack CPI (such as step by step guide to provision and configure the associated VPC, possibly illustrated with terraform configs). 

My team at Orange went through the mapping huaweicloud console concepts to openstack ones in order to configure the terraform provider and bosh-director cloud-config, and indeed felt clarifying documentation would help.

Besides, I wonder if Huawei team is considering the following other contributions which I believe will bring great benefits to the Huawei customers and the overall community, in summary "bring Huawei cloud 1st class support in bosh and cloudfoundry":

1- validate the full openstack cpi coverage on huawei cloud, including latest features such as LBaaS support, or other vm-extensions. This may make sense to contribute computing and engineering resources to the Bosh stack cpi team and add Huawei cloud to the CF Foundation  CI pipelines, see related [7]
1b- extend the openstack cpi with additional vm_properties support that leverage Huawei custom APIs and products. It would be great to see work with the openstack CPI team to design support for openstack extensions in the openstack CPI in a similar fashion as the openstack validator custom extensions, that would avoid a complete fork of the openstack cpi.
2- build a community of huawei cloud Bosh and CF users which can share experience, best practices, and provide feedback and improvements to the Huawei and CF Foundation teams. For example, create a "huawei" slack channel on the cloudfoundry slack [8][9]. Our team would be happy to share our experiences with running CF on Orange Flexible Engine, such as glance quota diagnostics [15], or VRRP issues across VPCs [16].
3- provide 1st class support to Huawei cloud on bosh director, e.g. validate integration of Huawei Object Store Service [10] as a bosh director blobstore backend, and BBR backend [12]. Contribute docs and operators into bosh-deployment similarly to other Iaas [11], [12], as well as terraform configs into bbl [13]. Validate integration of Huawei RDS as a bosh director db backend [14]. We should suggest to avoid fragmentation of terraform providers among huawei powered clouds [20] [21] [22] [23] and their associated diverging github repos [24] [25], and rather try to unify them into a single provider with configureable endpoint.
4- provide 1st class support to Huawei cloud on cloudfoundry application runtime, e.g. validate integration of Huawei Object Store Service [10] as a CC blobstore backend and contribute associated bosh operators into cf-deployment [15] or best in bbl, along with terraform configs (when differing from openstack apis)

I look forward to learning more about Huawei plans to bring 1st class support to bosh and cloudfoundry.

Thanks in advance for Huawei contribs to the Cf community, and for reading through this way too long email :-)



Guillaume.

On Sat, Aug 25, 2018 at 4:04 AM jun zhong <jun.zhongjun2@...> wrote:
Hi  Guillaume,

Add a little additional description. The original OpenStack network model is network, subnet, and router. The simplified network simplified model is vpc, subnet in Huawei Public Cloud console.
so we add the new property named 'subnet_id', and the Port is not required in Huawei Public Cloud network API.
Is this clear to you?

Thanks
JUN

2018-08-25 9:25 GMT+08:00 jun zhong <jun.zhongjun2@...>:
Hi Guillaume,

All I said that network model APIs changes or how to choose CPI are about Huawei Public Cloud itself, not Huawei cloud powered Orange Flexible Engine.

Thanks
JUN

2018-08-25 0:13 GMT+08:00 Guillaume Berche <bercheg@...>:
Hi Jun,

Thanks for your response.

> If you are familiar with OpenStack, you can still choose to use openstack CPI.
> If you are familiar with Huawei cloud console, we recommend using HuaweiCloud CPI.

I'm not sure to understand how familiarity with cloud console relates to which CPI flavor to choose.

Can you please clarify what additional features would usage of huaweicloud CPI would provide w.r.t. straight usage of openstack CPI to access Huawei Public Cloud itself or Huawei cloud powered Orange Flexible Engine?

Thanks in advance,

Guillaume.


On Fri, Aug 24, 2018 at 11:43 AM jun zhong <jun.zhongjun2@...> wrote:
Hi  MarcoGuillaume,

@Marco, Thanks for your arrangement.

@Guillaume

Yeah, The OpenStack CPI is work on Huawei cloud powered Orange Flexible Engine, but the
HuaweiCloud CPI is work on Huawei Public Cloud itself[1]. There are differences between the HuaweiCloud
console and OpenStack API models, some users are not aware of the relationship between them,
and it is difficult for people who are familiar with the console.

If you are familiar with OpenStack, you can still choose to use openstack CPI.
If you are familiar with Huawei cloud console, we recommend using HuaweiCloud CPI.

We changed the part of code about network mode in huaweicloud CPI [1],
we use our own network mode APIs instead of openstack newtork mode APIs,
and the Port is not required for HuaweiCloud, the new property is 'subnet_id', and so on.


Thanks
JUN


2018-08-21 23:43 GMT+08:00 Marco Voelz <marco.voelz@...>:

Dear JUN,

 

Thanks for the proposal. I'm asking everyone for feedback until August 31st: Make yourself heard, start discussions and make sure to ask the questions you have until that deadline. If there are no outstanding major discussion points, we will proceed with voting for incubation in the week after that.

 

Warm regards

Marco

 

From: <cf-bosh@...> on behalf of jun zhong <jun.zhongjun2@...>
Reply-To: "cf-bosh@..." <cf-bosh@...>
Date: Tuesday, 21. August 2018 at 11:20
To: "cf-bosh@..." <cf-bosh@...>
Subject: [cf-bosh] Incubation proposal: HuaweiCloud CPI

 

Hi all,

We want to propose the HuaweiCloud CPI for incubation in the BOSH PMC.
https://lists.cloudfoundry.org/g/cf-bosh/message/2532?p=,,,20,0,0,0::Created,,Huaweicloud,20,2,0,23810700 

The HuaweiCloud Bosh CPI [1] and configuration items for bosh [6] and cf [7] is ready now.  The Bosh HuaweiCloud CPI is used in our internal product.

 

We also add CI testing (CF HuaweiCloud Validator[3] [4] and BOSH Acceptance Tests (BATS)[2] ) to check if Huaweicloud CPI is ready to run BOSH and install

Cloud Foundry. The CI result will be displayed in each Huaweicloud CPI PR [5].

 

 




The project would follow a distributed committer model.

Project Lead:
Edward Lee
Initial Committers:
- ZhongJun (Huawei)
-Tommylikehu ( Huawei )

- LiuSheng  ( Huawei )

We are looking forward to your questions and comments.

Thanks,
JUN

Image removed by sender.

 




Re: Incubation proposal: HuaweiCloud CPI

jun zhong
 

Hi  Guillaume,

Add a little additional description. The original OpenStack network model is network, subnet, and router. The simplified network simplified model is vpc, subnet in Huawei Public Cloud console.
so we add the new property named 'subnet_id', and the Port is not required in Huawei Public Cloud network API.
Is this clear to you?

Thanks
JUN

2018-08-25 9:25 GMT+08:00 jun zhong <jun.zhongjun2@...>:

Hi Guillaume,

All I said that network model APIs changes or how to choose CPI are about Huawei Public Cloud itself, not Huawei cloud powered Orange Flexible Engine.

Thanks
JUN

2018-08-25 0:13 GMT+08:00 Guillaume Berche <bercheg@...>:
Hi Jun,

Thanks for your response.

> If you are familiar with OpenStack, you can still choose to use openstack CPI.
> If you are familiar with Huawei cloud console, we recommend using HuaweiCloud CPI.

I'm not sure to understand how familiarity with cloud console relates to which CPI flavor to choose.

Can you please clarify what additional features would usage of huaweicloud CPI would provide w.r.t. straight usage of openstack CPI to access Huawei Public Cloud itself or Huawei cloud powered Orange Flexible Engine?

Thanks in advance,

Guillaume.


On Fri, Aug 24, 2018 at 11:43 AM jun zhong <jun.zhongjun2@...> wrote:
Hi  MarcoGuillaume,

@Marco, Thanks for your arrangement.

@Guillaume

Yeah, The OpenStack CPI is work on Huawei cloud powered Orange Flexible Engine, but the
HuaweiCloud CPI is work on Huawei Public Cloud itself[1]. There are differences between the HuaweiCloud
console and OpenStack API models, some users are not aware of the relationship between them,
and it is difficult for people who are familiar with the console.

If you are familiar with OpenStack, you can still choose to use openstack CPI.
If you are familiar with Huawei cloud console, we recommend using HuaweiCloud CPI.

We changed the part of code about network mode in huaweicloud CPI [1],
we use our own network mode APIs instead of openstack newtork mode APIs,
and the Port is not required for HuaweiCloud, the new property is 'subnet_id', and so on.


Thanks
JUN


2018-08-21 23:43 GMT+08:00 Marco Voelz <marco.voelz@...>:

Dear JUN,

 

Thanks for the proposal. I'm asking everyone for feedback until August 31st: Make yourself heard, start discussions and make sure to ask the questions you have until that deadline. If there are no outstanding major discussion points, we will proceed with voting for incubation in the week after that.

 

Warm regards

Marco

 

From: <cf-bosh@...g> on behalf of jun zhong <jun.zhongjun2@...>
Reply-To: "cf-bosh@...g" <cf-bosh@...g>
Date: Tuesday, 21. August 2018 at 11:20
To: "cf-bosh@...g" <cf-bosh@...g>
Subject: [cf-bosh] Incubation proposal: HuaweiCloud CPI

 

Hi all,

We want to propose the HuaweiCloud CPI for incubation in the BOSH PMC.
https://lists.cloudfoundry.org/g/cf-bosh/message/2532?p=,,,20,0,0,0::Created,,Huaweicloud,20,2,0,23810700 

The HuaweiCloud Bosh CPI [1] and configuration items for bosh [6] and cf [7] is ready now.  The Bosh HuaweiCloud CPI is used in our internal product.

 

We also add CI testing (CF HuaweiCloud Validator[3] [4] and BOSH Acceptance Tests (BATS)[2] ) to check if Huaweicloud CPI is ready to run BOSH and install

Cloud Foundry. The CI result will be displayed in each Huaweicloud CPI PR [5].

 

 




The project would follow a distributed committer model.

Project Lead:
Edward Lee
Initial Committers:
- ZhongJun (Huawei)
-Tommylikehu ( Huawei )

- LiuSheng  ( Huawei )

We are looking forward to your questions and comments.

Thanks,
JUN

Image removed by sender.

 




Re: Incubation proposal: HuaweiCloud CPI

jun zhong
 

Hi Guillaume,

All I said that network model APIs changes or how to choose CPI are about Huawei Public Cloud itself, not Huawei cloud powered Orange Flexible Engine.

Thanks
JUN

2018-08-25 0:13 GMT+08:00 Guillaume Berche <bercheg@...>:

Hi Jun,

Thanks for your response.

> If you are familiar with OpenStack, you can still choose to use openstack CPI.
> If you are familiar with Huawei cloud console, we recommend using HuaweiCloud CPI.

I'm not sure to understand how familiarity with cloud console relates to which CPI flavor to choose.

Can you please clarify what additional features would usage of huaweicloud CPI would provide w.r.t. straight usage of openstack CPI to access Huawei Public Cloud itself or Huawei cloud powered Orange Flexible Engine?

Thanks in advance,

Guillaume.


On Fri, Aug 24, 2018 at 11:43 AM jun zhong <jun.zhongjun2@...> wrote:
Hi  MarcoGuillaume,

@Marco, Thanks for your arrangement.

@Guillaume

Yeah, The OpenStack CPI is work on Huawei cloud powered Orange Flexible Engine, but the
HuaweiCloud CPI is work on Huawei Public Cloud itself[1]. There are differences between the HuaweiCloud
console and OpenStack API models, some users are not aware of the relationship between them,
and it is difficult for people who are familiar with the console.

If you are familiar with OpenStack, you can still choose to use openstack CPI.
If you are familiar with Huawei cloud console, we recommend using HuaweiCloud CPI.

We changed the part of code about network mode in huaweicloud CPI [1],
we use our own network mode APIs instead of openstack newtork mode APIs,
and the Port is not required for HuaweiCloud, the new property is 'subnet_id', and so on.


Thanks
JUN


2018-08-21 23:43 GMT+08:00 Marco Voelz <marco.voelz@...>:

Dear JUN,

 

Thanks for the proposal. I'm asking everyone for feedback until August 31st: Make yourself heard, start discussions and make sure to ask the questions you have until that deadline. If there are no outstanding major discussion points, we will proceed with voting for incubation in the week after that.

 

Warm regards

Marco

 

From: <cf-bosh@....org> on behalf of jun zhong <jun.zhongjun2@...>
Reply-To: "cf-bosh@....org" <cf-bosh@....org>
Date: Tuesday, 21. August 2018 at 11:20
To: "cf-bosh@....org" <cf-bosh@....org>
Subject: [cf-bosh] Incubation proposal: HuaweiCloud CPI

 

Hi all,

We want to propose the HuaweiCloud CPI for incubation in the BOSH PMC.
https://lists.cloudfoundry.org/g/cf-bosh/message/2532?p=,,,20,0,0,0::Created,,Huaweicloud,20,2,0,23810700 

The HuaweiCloud Bosh CPI [1] and configuration items for bosh [6] and cf [7] is ready now.  The Bosh HuaweiCloud CPI is used in our internal product.

 

We also add CI testing (CF HuaweiCloud Validator[3] [4] and BOSH Acceptance Tests (BATS)[2] ) to check if Huaweicloud CPI is ready to run BOSH and install

Cloud Foundry. The CI result will be displayed in each Huaweicloud CPI PR [5].

 

 




The project would follow a distributed committer model.

Project Lead:
Edward Lee
Initial Committers:
- ZhongJun (Huawei)
-Tommylikehu ( Huawei )

- LiuSheng  ( Huawei )

We are looking forward to your questions and comments.

Thanks,
JUN

Image removed by sender.

 



Re: Incubation proposal: HuaweiCloud CPI

Guillaume Berche
 

Hi Jun,

Thanks for your response.

> If you are familiar with OpenStack, you can still choose to use openstack CPI.
> If you are familiar with Huawei cloud console, we recommend using HuaweiCloud CPI.

I'm not sure to understand how familiarity with cloud console relates to which CPI flavor to choose.

Can you please clarify what additional features would usage of huaweicloud CPI would provide w.r.t. straight usage of openstack CPI to access Huawei Public Cloud itself or Huawei cloud powered Orange Flexible Engine?

Thanks in advance,

Guillaume.


On Fri, Aug 24, 2018 at 11:43 AM jun zhong <jun.zhongjun2@...> wrote:
Hi  MarcoGuillaume,

@Marco, Thanks for your arrangement.

@Guillaume

Yeah, The OpenStack CPI is work on Huawei cloud powered Orange Flexible Engine, but the
HuaweiCloud CPI is work on Huawei Public Cloud itself[1]. There are differences between the HuaweiCloud
console and OpenStack API models, some users are not aware of the relationship between them,
and it is difficult for people who are familiar with the console.

If you are familiar with OpenStack, you can still choose to use openstack CPI.
If you are familiar with Huawei cloud console, we recommend using HuaweiCloud CPI.

We changed the part of code about network mode in huaweicloud CPI [1],
we use our own network mode APIs instead of openstack newtork mode APIs,
and the Port is not required for HuaweiCloud, the new property is 'subnet_id', and so on.


Thanks
JUN


2018-08-21 23:43 GMT+08:00 Marco Voelz <marco.voelz@...>:

Dear JUN,

 

Thanks for the proposal. I'm asking everyone for feedback until August 31st: Make yourself heard, start discussions and make sure to ask the questions you have until that deadline. If there are no outstanding major discussion points, we will proceed with voting for incubation in the week after that.

 

Warm regards

Marco

 

From: <cf-bosh@...> on behalf of jun zhong <jun.zhongjun2@...>
Reply-To: "cf-bosh@..." <cf-bosh@...>
Date: Tuesday, 21. August 2018 at 11:20
To: "cf-bosh@..." <cf-bosh@...>
Subject: [cf-bosh] Incubation proposal: HuaweiCloud CPI

 

Hi all,

We want to propose the HuaweiCloud CPI for incubation in the BOSH PMC.
https://lists.cloudfoundry.org/g/cf-bosh/message/2532?p=,,,20,0,0,0::Created,,Huaweicloud,20,2,0,23810700 

The HuaweiCloud Bosh CPI [1] and configuration items for bosh [6] and cf [7] is ready now.  The Bosh HuaweiCloud CPI is used in our internal product.

 

We also add CI testing (CF HuaweiCloud Validator[3] [4] and BOSH Acceptance Tests (BATS)[2] ) to check if Huaweicloud CPI is ready to run BOSH and install

Cloud Foundry. The CI result will be displayed in each Huaweicloud CPI PR [5].

 

 




The project would follow a distributed committer model.

Project Lead:
Edward Lee
Initial Committers:
- ZhongJun (Huawei)
-Tommylikehu ( Huawei )

- LiuSheng  ( Huawei )

We are looking forward to your questions and comments.

Thanks,
JUN

Image removed by sender.

 


Re: Incubation proposal: HuaweiCloud CPI

jun zhong
 

Hi  MarcoGuillaume,

@Marco, Thanks for your arrangement.

@Guillaume

Yeah, The OpenStack CPI is work on Huawei cloud powered Orange Flexible Engine, but the
HuaweiCloud CPI is work on Huawei Public Cloud itself[1]. There are differences between the HuaweiCloud
console and OpenStack API models, some users are not aware of the relationship between them,
and it is difficult for people who are familiar with the console.

If you are familiar with OpenStack, you can still choose to use openstack CPI.
If you are familiar with Huawei cloud console, we recommend using HuaweiCloud CPI.

We changed the part of code about network mode in huaweicloud CPI [1],
we use our own network mode APIs instead of openstack newtork mode APIs,
and the Port is not required for HuaweiCloud, the new property is 'subnet_id', and so on.


Thanks
JUN


2018-08-21 23:43 GMT+08:00 Marco Voelz <marco.voelz@...>:

Dear JUN,

 

Thanks for the proposal. I'm asking everyone for feedback until August 31st: Make yourself heard, start discussions and make sure to ask the questions you have until that deadline. If there are no outstanding major discussion points, we will proceed with voting for incubation in the week after that.

 

Warm regards

Marco

 

From: <cf-bosh@....org> on behalf of jun zhong <jun.zhongjun2@...>
Reply-To: "cf-bosh@....org" <cf-bosh@....org>
Date: Tuesday, 21. August 2018 at 11:20
To: "cf-bosh@....org" <cf-bosh@....org>
Subject: [cf-bosh] Incubation proposal: HuaweiCloud CPI

 

Hi all,

We want to propose the HuaweiCloud CPI for incubation in the BOSH PMC.
https://lists.cloudfoundry.org/g/cf-bosh/message/2532?p=,,,20,0,0,0::Created,,Huaweicloud,20,2,0,23810700 

The HuaweiCloud Bosh CPI [1] and configuration items for bosh [6] and cf [7] is ready now.  The Bosh HuaweiCloud CPI is used in our internal product.

 

We also add CI testing (CF HuaweiCloud Validator[3] [4] and BOSH Acceptance Tests (BATS)[2] ) to check if Huaweicloud CPI is ready to run BOSH and install

Cloud Foundry. The CI result will be displayed in each Huaweicloud CPI PR [5].

 

 




The project would follow a distributed committer model.

Project Lead:
Edward Lee
Initial Committers:
- ZhongJun (Huawei)
-Tommylikehu ( Huawei )

- LiuSheng  ( Huawei )

We are looking forward to your questions and comments.

Thanks,
JUN

Image removed by sender.

 


Re: BOSH PMC refactoring part 2 – moving CPIs out of incubation

dhiraj mutreja
 


On Thu, Aug 23, 2018 at 2:17 AM Marco Voelz <marco.voelz@...> wrote:

Dear friends of BOSH,
 
The BOSH project management committee (PMC) proposes to promote the most mature and widely used CPIs from incubation to full project status. Specifically, we want to promote these CPIs
  • AWS CPI [1]
  • OpenStack CPI [2]
  • VSphere CPI [3]
  • Google CPI [4]
  • Azure CPI [5]

Promoting the projects has some impact on their users, depending on how you consume the CPIs
  • We will move the repositories from the cloudfoundry-incubator to the cloudfoundry organization in github. Github takes care of redirecting from the old repository location to the new one, so all links and references to the old repositories should still work. 
  • References on bosh.io currently include the github organization name [6]. In the past, there have been issues with people consuming outdated releases from bosh.io after they had been renamed or moved – we might need a similar mechanism of redirecting that github provides to avoid that.

Please reach out to by replying to this mail or contacting me personally if you have questions, concerns, or comments.

Warm regards
Marco

PS: cross-posted on cf-developers for greater reach and potential experiences about previous promotions from incubator to full project.


Re: BOSH PMC refactoring part 2 – moving CPIs out of incubation

Dr Nic Williams
 

Thanks Marco


From: cf-bosh@... <cf-bosh@...> on behalf of Marco Voelz <marco.voelz@...>
Sent: Thursday, August 23, 2018 7:17:33 PM
To: cf-bosh@...
Cc: Discussions about Cloud Foundry projects and the system overall.
Subject: [cf-bosh] BOSH PMC refactoring part 2 – moving CPIs out of incubation
 

Dear friends of BOSH,
 
The BOSH project management committee (PMC) proposes to promote the most mature and widely used CPIs from incubation to full project status. Specifically, we want to promote these CPIs
  • AWS CPI [1]
  • OpenStack CPI [2]
  • VSphere CPI [3]
  • Google CPI [4]
  • Azure CPI [5]

Promoting the projects has some impact on their users, depending on how you consume the CPIs
  • We will move the repositories from the cloudfoundry-incubator to the cloudfoundry organization in github. Github takes care of redirecting from the old repository location to the new one, so all links and references to the old repositories should still work. 
  • References on bosh.io currently include the github organization name [6]. In the past, there have been issues with people consuming outdated releases from bosh.io after they had been renamed or moved – we might need a similar mechanism of redirecting that github provides to avoid that.

Please reach out to by replying to this mail or contacting me personally if you have questions, concerns, or comments.

Warm regards
Marco

PS: cross-posted on cf-developers for greater reach and potential experiences about previous promotions from incubator to full project.


BOSH PMC refactoring part 2 – moving CPIs out of incubation

Marco Voelz
 

Dear friends of BOSH,
 
The BOSH project management committee (PMC) proposes to promote the most mature and widely used CPIs from incubation to full project status. Specifically, we want to promote these CPIs
  • AWS CPI [1]
  • OpenStack CPI [2]
  • VSphere CPI [3]
  • Google CPI [4]
  • Azure CPI [5]

Promoting the projects has some impact on their users, depending on how you consume the CPIs
  • We will move the repositories from the cloudfoundry-incubator to the cloudfoundry organization in github. Github takes care of redirecting from the old repository location to the new one, so all links and references to the old repositories should still work. 
  • References on bosh.io currently include the github organization name [6]. In the past, there have been issues with people consuming outdated releases from bosh.io after they had been renamed or moved – we might need a similar mechanism of redirecting that github provides to avoid that.

Please reach out to by replying to this mail or contacting me personally if you have questions, concerns, or comments.

Warm regards
Marco

PS: cross-posted on cf-developers for greater reach and potential experiences about previous promotions from incubator to full project.


Re: Incubation proposal: HuaweiCloud CPI

Marco Voelz
 

Dear JUN,

 

Thanks for the proposal. I'm asking everyone for feedback until August 31st: Make yourself heard, start discussions and make sure to ask the questions you have until that deadline. If there are no outstanding major discussion points, we will proceed with voting for incubation in the week after that.

 

Warm regards

Marco

 

From: <cf-bosh@...> on behalf of jun zhong <jun.zhongjun2@...>
Reply-To: "cf-bosh@..." <cf-bosh@...>
Date: Tuesday, 21. August 2018 at 11:20
To: "cf-bosh@..." <cf-bosh@...>
Subject: [cf-bosh] Incubation proposal: HuaweiCloud CPI

 

Hi all,

We want to propose the HuaweiCloud CPI for incubation in the BOSH PMC.
https://lists.cloudfoundry.org/g/cf-bosh/message/2532?p=,,,20,0,0,0::Created,,Huaweicloud,20,2,0,23810700 

The HuaweiCloud Bosh CPI [1] and configuration items for bosh [6] and cf [7] is ready now.  The Bosh HuaweiCloud CPI is used in our internal product.

 

We also add CI testing (CF HuaweiCloud Validator[3] [4] and BOSH Acceptance Tests (BATS)[2] ) to check if Huaweicloud CPI is ready to run BOSH and install

Cloud Foundry. The CI result will be displayed in each Huaweicloud CPI PR [5].

 

 




The project would follow a distributed committer model.

Project Lead:
Edward Lee
Initial Committers:
- ZhongJun (Huawei)
-Tommylikehu ( Huawei )

- LiuSheng  ( Huawei )

We are looking forward to your questions and comments.

Thanks,
JUN

 

Re: Incubation proposal: HuaweiCloud CPI

Guillaume Berche
 

Hi Jun,

It's great to see Huawei team contributing to the CloudFoundry community!

I work for Orange which has been running CloudFoundry on various openstack distributions using the openstack CPI for many years, including on the Huawei cloud powered Orange Flexible Engine [1] for the last 4 months. This occasionally required us to contribute fixes to the openstack-cpi or its fog dependency library [4].

The huaweicloud cpi's readme [2] mentions that enhancements (w.r.t. openstack CPI) lies in "Network: fully supporting huaweicloud network resources, including vpc, subnet, nic and so on."

I wonder where the associated documentation can be found: is there user-facing huawei specific properties that are exposed to cpi users ? I so far could only spot the example manifest into cf-deployment [3] and bosh-deployment [3b] forks but without apparent new properties w.r.t. openstack cpi reference doc [6]. I therefore wonder whether the huawei cpi is indeed offering support for new features, or rather accommodating for subtle openstack api incompatibilites which could potentially be handled through either better huawei cloud openstack api conformance, or contributions to the openstack cpi to make it more flexible to API response variations (like we did in [4]). Huawei usa contributor was offering to help with openstack testing in [7] which could potentially help.

Looking at the huaweicloud cpi's code, I'm concerned to see the proposed repos (openstack CPI, openstack validator, being completely forked without apparent convergence with the openstack CPI work, and worry about maintenance of this effort in the future, and feature parity with openstack-cpi.

I wonder whether the Huawei team has yet reached out to the openstack CPI team (e.g.on slack [8]) to discuss support for extensions in the cpi that potential Huawei differentiated features (beyond openstack standard) could leverage (in a similar fashion that the openstack  validator supports extensions [5]).

Thanks in advance,

Guillaume.

[4] https://github.com/fog/fog-openstack/issues/359

On Tue, Aug 21, 2018 at 11:20 AM jun zhong <jun.zhongjun2@...> wrote:
Hi all,

We want to propose the HuaweiCloud CPI for incubation in the BOSH PMC.
https://lists.cloudfoundry.org/g/cf-bosh/message/2532?p=,,,20,0,0,0::Created,,Huaweicloud,20,2,0,23810700 

The HuaweiCloud Bosh CPI [1] and configuration items for bosh [6] and cf [7] is ready now.  The Bosh HuaweiCloud CPI is used in our internal product.

We also add CI testing (CF HuaweiCloud Validator[3] [4] and BOSH Acceptance Tests (BATS)[2] ) to check if Huaweicloud CPI is ready to run BOSH and install
Cloud Foundry. The CI result will be displayed in each Huaweicloud CPI PR [5].





The project would follow a distributed committer model.

Project Lead: Edward Lee
Initial Committers:
- ZhongJun (Huawei)
-Tommylikehu ( Huawei )
- LiuSheng  ( Huawei )

We are looking forward to your questions and comments.

Thanks,
JUN

Incubation proposal: HuaweiCloud CPI

jun zhong
 

Hi all,

We want to propose the HuaweiCloud CPI for incubation in the BOSH PMC.
https://lists.cloudfoundry.org/g/cf-bosh/message/2532?p=,,,20,0,0,0::Created,,Huaweicloud,20,2,0,23810700 

The HuaweiCloud Bosh CPI [1] and configuration items for bosh [6] and cf [7] is ready now.  The Bosh HuaweiCloud CPI is used in our internal product.

We also add CI testing (CF HuaweiCloud Validator[3] [4] and BOSH Acceptance Tests (BATS)[2] ) to check if Huaweicloud CPI is ready to run BOSH and install
Cloud Foundry. The CI result will be displayed in each Huaweicloud CPI PR [5].





The project would follow a distributed committer model.

Project Lead: Edward Lee
Initial Committers:
- ZhongJun (Huawei)
-Tommylikehu ( Huawei )
- LiuSheng  ( Huawei )

We are looking forward to your questions and comments.

Thanks,
JUN

Re: [cf-dev] [cf-bosh] Incubation proposal: CF Containerization

vlad.iovanov@...
 

Thank you for the great news Marco!

 

Cheers,

Vlad

 

From: cf-dev@... <cf-dev@...> On Behalf Of Marco Voelz
Sent: Wednesday, August 15, 2018 12:10 PM
To: CF BOSH Mailing List <cf-bosh@...>
Cc: Discussions about Cloud Foundry projects and the system overall. <cf-dev@...>; cschum@...
Subject: Re: [cf-dev] [cf-bosh] Incubation proposal: CF Containerization

 

Hi everyone,

 

The BOSH PMC voted unanimously in favor of incubating the CF Containerization project. Welcome to Vlad and the team!

 

Warm regards

Marco

 


From: Voelz, Marco
Sent: Monday, August 13, 2018 1:52 PM
To: CF BOSH Mailing List
Cc: Discussions about Cloud Foundry projects and the system overall.
Subject: Re: [cf-bosh] Incubation proposal: CF Containerization

 

Hi everyone,

 

Thanks for the comments, discussions and suggestions everyone! The deadline for raising major concerns before we go on with the usual incubation process ended on August 10th. I don't see any ongoing discussions that would prevent us moving forward, so I'll call for a vote within the PMC and we will then proceed.

 

Warm regards

Marco

 


From: cf-bosh@... <cf-bosh@...> on behalf of Dmitriy Kalinin <dkalinin@...>
Sent: Friday, July 13, 2018 12:02:27 AM
To: CF BOSH Mailing List
Cc: Discussions about Cloud Foundry projects and the system overall.
Subject: Re: [cf-bosh] Incubation proposal: CF Containerization

 

Thank you for submitting this proposal. Let's shoot for collecting and resolving most of the comments in the next month by Aug 10th and voting at that time to incubate it in BOSH PMC.

 

On Tue, Jul 3, 2018 at 2:25 AM, Cornelius Schumacher <cschum@...> wrote:

Hi all,

We would like to propose the CF Containerization effort for incubation in the
BOSH PMC.

The full proposal can be found here:
https://docs.google.com/document/d/1_IvFf-cCR4_Hxg-L7Z_R51EKhZfBqlprrs5NgC2iO2w/edit

As a first step towards this, we are proposing the Fissile code base as a
starting point, with the goal of transforming it in the direction of the above
proposal. Fissile is a tool that allows developers to convert existing BOSH
releases to docker images and deploy them to Kubernetes. Fissile is currently
used in SUSE CAP (https://www.suse.com/products/cloud-application-platform)
and IBM Cloud Foundry Enterprise Environment (https://console.bluemix.net/
docs/cloud-foundry/
).

Fissile is fully open  source and can currently be found on GitHub at
https://github.com/SUSE/fissile

The project would follow a distributed committer model.

Project Lead: Vlad Iovanov
Initial Committers:
- Jan Dubois (SUSE)
- Mark Yen (SUSE)
- Mario Manno (SUSE)
- Enrique Encalada (IBM)
- Matthias Diester (IBM)
- Gong (Grace) Zhang (IBM)

SAP is also currently evaluating additional staffing.

We are looking forward to your questions and comments.

Best Regards,
Cornelius

--
Cornelius Schumacher <cschum@...>


 

Re: Incubation proposal: CF Containerization

Marco Voelz
 

Hi everyone,


The BOSH PMC voted unanimously in favor of incubating the CF Containerization project. Welcome to Vlad and the team!


Warm regards

Marco




From: Voelz, Marco
Sent: Monday, August 13, 2018 1:52 PM
To: CF BOSH Mailing List
Cc: Discussions about Cloud Foundry projects and the system overall.
Subject: Re: [cf-bosh] Incubation proposal: CF Containerization
 

Hi everyone,


Thanks for the comments, discussions and suggestions everyone! The deadline for raising major concerns before we go on with the usual incubation process ended on August 10th. I don't see any ongoing discussions that would prevent us moving forward, so I'll call for a vote within the PMC and we will then proceed.


Warm regards

Marco



From: cf-bosh@... <cf-bosh@...> on behalf of Dmitriy Kalinin <dkalinin@...>
Sent: Friday, July 13, 2018 12:02:27 AM
To: CF BOSH Mailing List
Cc: Discussions about Cloud Foundry projects and the system overall.
Subject: Re: [cf-bosh] Incubation proposal: CF Containerization
 
Thank you for submitting this proposal. Let's shoot for collecting and resolving most of the comments in the next month by Aug 10th and voting at that time to incubate it in BOSH PMC.

On Tue, Jul 3, 2018 at 2:25 AM, Cornelius Schumacher <cschum@...> wrote:
Hi all,

We would like to propose the CF Containerization effort for incubation in the
BOSH PMC.

The full proposal can be found here:
https://docs.google.com/document/d/1_IvFf-cCR4_Hxg-L7Z_R51EKhZfBqlprrs5NgC2iO2w/edit

As a first step towards this, we are proposing the Fissile code base as a
starting point, with the goal of transforming it in the direction of the above
proposal. Fissile is a tool that allows developers to convert existing BOSH
releases to docker images and deploy them to Kubernetes. Fissile is currently
used in SUSE CAP (https://www.suse.com/products/cloud-application-platform)
and IBM Cloud Foundry Enterprise Environment (https://console.bluemix.net/
docs/cloud-foundry/
).

Fissile is fully open  source and can currently be found on GitHub at
https://github.com/SUSE/fissile

The project would follow a distributed committer model.

Project Lead: Vlad Iovanov
Initial Committers:
- Jan Dubois (SUSE)
- Mark Yen (SUSE)
- Mario Manno (SUSE)
- Enrique Encalada (IBM)
- Matthias Diester (IBM)
- Gong (Grace) Zhang (IBM)

SAP is also currently evaluating additional staffing.

We are looking forward to your questions and comments.

Best Regards,
Cornelius

--
Cornelius Schumacher <cschum@...>




Re: Incubation proposal: CF Containerization

Marco Voelz
 

Hi everyone,


Thanks for the comments, discussions and suggestions everyone! The deadline for raising major concerns before we go on with the usual incubation process ended on August 10th. I don't see any ongoing discussions that would prevent us moving forward, so I'll call for a vote within the PMC and we will then proceed.


Warm regards

Marco



From: cf-bosh@... <cf-bosh@...> on behalf of Dmitriy Kalinin <dkalinin@...>
Sent: Friday, July 13, 2018 12:02:27 AM
To: CF BOSH Mailing List
Cc: Discussions about Cloud Foundry projects and the system overall.
Subject: Re: [cf-bosh] Incubation proposal: CF Containerization
 
Thank you for submitting this proposal. Let's shoot for collecting and resolving most of the comments in the next month by Aug 10th and voting at that time to incubate it in BOSH PMC.

On Tue, Jul 3, 2018 at 2:25 AM, Cornelius Schumacher <cschum@...> wrote:
Hi all,

We would like to propose the CF Containerization effort for incubation in the
BOSH PMC.

The full proposal can be found here:
https://docs.google.com/document/d/1_IvFf-cCR4_Hxg-L7Z_R51EKhZfBqlprrs5NgC2iO2w/edit

As a first step towards this, we are proposing the Fissile code base as a
starting point, with the goal of transforming it in the direction of the above
proposal. Fissile is a tool that allows developers to convert existing BOSH
releases to docker images and deploy them to Kubernetes. Fissile is currently
used in SUSE CAP (https://www.suse.com/products/cloud-application-platform)
and IBM Cloud Foundry Enterprise Environment (https://console.bluemix.net/
docs/cloud-foundry/
).

Fissile is fully open  source and can currently be found on GitHub at
https://github.com/SUSE/fissile

The project would follow a distributed committer model.

Project Lead: Vlad Iovanov
Initial Committers:
- Jan Dubois (SUSE)
- Mark Yen (SUSE)
- Mario Manno (SUSE)
- Enrique Encalada (IBM)
- Matthias Diester (IBM)
- Gong (Grace) Zhang (IBM)

SAP is also currently evaluating additional staffing.

We are looking forward to your questions and comments.

Best Regards,
Cornelius

--
Cornelius Schumacher <cschum@...>




Re: BOSH PMC refactoring – Call for Nominations

Marco Voelz
 

That’s a change we have on the list for the next refactoring. We tried to keep the scope small for this one ;)

Warm regards
Marco

On 9. Aug 2018, at 16:29, Chip Childers <cchilders@...> wrote:

I think it's also time to talk about graduating some (all) of the incubating CPI's to "active" status. WDYT?

On Thu, Aug 9, 2018 at 6:10 AM Marco Voelz <marco.voelz@...> wrote:

Dear friends of BOSH,

 

Within the BOSH project management committee (PMC) we want to ensure that our project structure reflects how our platform is currently built and managed. Consequently, we propose the following changes:

 

Archiving the BOSH CPIs project — This project has been inactive for a while. Most CPIs are currently maintained by the owners of the various IaaS they relate to. The rest of the work is performed by the BOSH Core project. We need to reassess our project structure with the stakeholders of the various CPIs. This will likely result in the creation of a few new projects.

 

Splitting the BOSH Core project in two —  The BOSH core team is currently divided between San Francisco, USA and Toronto, Canada. Until recently, a single Product Manager was overseeing both halves of the team. This PM was also the BOSH Core project lead. We propose to replace the current BOSH Core project by the BOSH Core San Francisco and BOSH Core Toronto projects. Since these projects are a continuation of the existing BOSH Core project, there is no need for a formal project proposal or incubation period.

 

New BOSH Core Project Management — Dmitriy Kalinin is rotating into a role internal to Pivotal. As such, nominations are now open for that roll. Pivotal would like to nominate the following individuals to fill the positions of project leads:

* Morgan Fine from Pivotal as project lead for the BOSH Core San Francisco project

* Frédéric Desbiens from Pivotal as project lead for the BOSH Core Toronto project

 

If any Cloud Foundry Foundation member participating in a BOSH PMC project wishes to nominate someone else, please do so by contacting me directly. Nominations will close by August, 16th. After the nomination window, we will hold votes of the BOSH PMC to officialize the changes to our project structure and select the new project leads.

 

Warm regards

Marco

 

For reference, the role of project lead is defined in the Development Operations Policy, available here: https://www.cloudfoundry.org/wp-content/uploads/2017/01/CFF_Development_Operations_Policy.pdf

 

Relevant extract from the policy:

“If a Project Lead is removed, or decides to step down for any reason, any Foundation member can nominate a replacement to the out-going Project Lead. If consensus is not reached among the Project Members on the selection of a new Project Lead, the PMC Chair shall call for a Governance by Contribution vote within that PMC. Alternately, if the Project exists within a PMC that has delegated Project decisions to the individual Projects, the PMC Lead of such PMC, not the PMC Chair, shall call for a Governance by Contribution vote within that Project.”

--
Chip Childers
CTO, Cloud Foundry Foundation
1.267.250.0815

Re: BOSH PMC refactoring – Call for Nominations

Chip Childers
 

I think it's also time to talk about graduating some (all) of the incubating CPI's to "active" status. WDYT?


On Thu, Aug 9, 2018 at 6:10 AM Marco Voelz <marco.voelz@...> wrote:

Dear friends of BOSH,

 

Within the BOSH project management committee (PMC) we want to ensure that our project structure reflects how our platform is currently built and managed. Consequently, we propose the following changes:

 

Archiving the BOSH CPIs project — This project has been inactive for a while. Most CPIs are currently maintained by the owners of the various IaaS they relate to. The rest of the work is performed by the BOSH Core project. We need to reassess our project structure with the stakeholders of the various CPIs. This will likely result in the creation of a few new projects.

 

Splitting the BOSH Core project in two —  The BOSH core team is currently divided between San Francisco, USA and Toronto, Canada. Until recently, a single Product Manager was overseeing both halves of the team. This PM was also the BOSH Core project lead. We propose to replace the current BOSH Core project by the BOSH Core San Francisco and BOSH Core Toronto projects. Since these projects are a continuation of the existing BOSH Core project, there is no need for a formal project proposal or incubation period.

 

New BOSH Core Project Management — Dmitriy Kalinin is rotating into a role internal to Pivotal. As such, nominations are now open for that roll. Pivotal would like to nominate the following individuals to fill the positions of project leads:

* Morgan Fine from Pivotal as project lead for the BOSH Core San Francisco project

* Frédéric Desbiens from Pivotal as project lead for the BOSH Core Toronto project

 

If any Cloud Foundry Foundation member participating in a BOSH PMC project wishes to nominate someone else, please do so by contacting me directly. Nominations will close by August, 16th. After the nomination window, we will hold votes of the BOSH PMC to officialize the changes to our project structure and select the new project leads.

 

Warm regards

Marco

 

For reference, the role of project lead is defined in the Development Operations Policy, available here: https://www.cloudfoundry.org/wp-content/uploads/2017/01/CFF_Development_Operations_Policy.pdf

 

Relevant extract from the policy:

“If a Project Lead is removed, or decides to step down for any reason, any Foundation member can nominate a replacement to the out-going Project Lead. If consensus is not reached among the Project Members on the selection of a new Project Lead, the PMC Chair shall call for a Governance by Contribution vote within that PMC. Alternately, if the Project exists within a PMC that has delegated Project decisions to the individual Projects, the PMC Lead of such PMC, not the PMC Chair, shall call for a Governance by Contribution vote within that Project.”

--
Chip Childers
CTO, Cloud Foundry Foundation
1.267.250.0815

BOSH PMC refactoring – Call for Nominations

Marco Voelz
 

Dear friends of BOSH,

 

Within the BOSH project management committee (PMC) we want to ensure that our project structure reflects how our platform is currently built and managed. Consequently, we propose the following changes:

 

Archiving the BOSH CPIs project — This project has been inactive for a while. Most CPIs are currently maintained by the owners of the various IaaS they relate to. The rest of the work is performed by the BOSH Core project. We need to reassess our project structure with the stakeholders of the various CPIs. This will likely result in the creation of a few new projects.

 

Splitting the BOSH Core project in two —  The BOSH core team is currently divided between San Francisco, USA and Toronto, Canada. Until recently, a single Product Manager was overseeing both halves of the team. This PM was also the BOSH Core project lead. We propose to replace the current BOSH Core project by the BOSH Core San Francisco and BOSH Core Toronto projects. Since these projects are a continuation of the existing BOSH Core project, there is no need for a formal project proposal or incubation period.

 

New BOSH Core Project Management — Dmitriy Kalinin is rotating into a role internal to Pivotal. As such, nominations are now open for that roll. Pivotal would like to nominate the following individuals to fill the positions of project leads:

* Morgan Fine from Pivotal as project lead for the BOSH Core San Francisco project

* Frédéric Desbiens from Pivotal as project lead for the BOSH Core Toronto project

 

If any Cloud Foundry Foundation member participating in a BOSH PMC project wishes to nominate someone else, please do so by contacting me directly. Nominations will close by August, 16th. After the nomination window, we will hold votes of the BOSH PMC to officialize the changes to our project structure and select the new project leads.

 

Warm regards

Marco

 

For reference, the role of project lead is defined in the Development Operations Policy, available here: https://www.cloudfoundry.org/wp-content/uploads/2017/01/CFF_Development_Operations_Policy.pdf

 

Relevant extract from the policy:

“If a Project Lead is removed, or decides to step down for any reason, any Foundation member can nominate a replacement to the out-going Project Lead. If consensus is not reached among the Project Members on the selection of a new Project Lead, the PMC Chair shall call for a Governance by Contribution vote within that PMC. Alternately, if the Project exists within a PMC that has delegated Project decisions to the individual Projects, the PMC Lead of such PMC, not the PMC Chair, shall call for a Governance by Contribution vote within that Project.”