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

[1]https://github.com/cloudfoundry/bosh-deployment/blob/master/azure

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

[0] https://support.huawei.com/enterprise/en/cloud-computing/fusionsphere-openstack-pid-21100528

[1] https://bosh.io/docs/init-openstack/

[2] https://github.com/cloudfoundry-incubator/bosh-openstack-environment-templates/blob/master/bosh-init-tf/network.tf

[3] https://support.huaweicloud.com/en-us/productdesc-vpc/en-us_topic_0013748729.html

[4] https://support.huaweicloud.com/en-us/productdesc-vpc/en-us_topic_0030969424.html

[5] https://github.com/cloudfoundry/docs-bosh/blob/master/content/init-openstack.md

[6] https://bosh.io/docs/openstack-cpi/#resource-pools

[7] https://github.com/cloudfoundry-incubator/bosh-openstack-cpi-release/issues/103

[8] https://cloudfoundry.slack.com/

[9] http://slack.cloudfoundry.org/

[10] http://www.huaweicloud.com/en-us/product/obs.html

[11] https://github.com/cloudfoundry/bosh-deployment/blob/master/aws/s3-blobstore.yml 

[12] https://github.com/cloudfoundry/bosh-deployment/blob/master/aws/s3-bbr.yml

[13] https://github.com/cloudfoundry/bosh-bootloader/tree/master/plan-patches

[14] https://bosh.io/docs/director-configure-db/#external

[15] https://github.com/orange-cloudfoundry/paas-templates/issues/101

[16] https://github.com/orange-cloudfoundry/paas-templates/issues/42

[17] https://github.com/huaweicloud/huaweicloud-service-broker

[20] https://www.terraform.io/docs/providers/huaweicloud/index.html

[21] https://www.terraform.io/docs/providers/flexibleengine/index.html

[22] https://www.terraform.io/docs/providers/telefonicaopencloud/index.html

[23] https://www.terraform.io/docs/providers/opentelekomcloud/index.html

[24] https://github.com/huawei-clouds?utf8=%E2%9C%93&q=terraform&type=&language=

[25] https://github.com/terraform-providers/terraform-provider-opentelekomcloud

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  Marco,  Guillaume,

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

[1] https://www.huaweicloud.com/

[2] https://github.com/zhongjun2/bosh-huaweicloud-cpi-release/pull/8/files

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 31^st: 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].

 

 

[1] https://github.com/zhongjun2/bosh-huaweicloud-cpi-release/

[2] https://github.com/liu-sheng/openlab-zuul-jobs/blob/master/playbooks/bosh-acceptance-test-huaweicloud/run.yaml

[3] https://github.com/liu-sheng/openlab-zuul-jobs/blob/master/playbooks/bosh-huaweicloud-cpi-release-acceptance-test/run.yaml

[4] https://github.com/zhongjun2/cf-huaweicloud-validator

[5] https://github.com/zhongjun2/bosh-huaweicloud-cpi-release/pull/3

[6] https://github.com/zhongjun2/bosh-deployment

[7] https://github.com/zhongjun2/cf-deployment

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