1. Cf-Bosh
  2. Messages

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 ?


[1] https://www.cloudfoundry.org/thefoundry/#providers 
[2] https://bosh.io/docs/quick-start/
[3] https://github.com/cloudfoundry/docs-deploying-cf
[4] https://bosh.io/docs/init-openstack/

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


Join {cf-bosh@lists.cloudfoundry.org to automatically receive all group messages.