Re: Incubation proposal: HuaweiCloud CPI
Dear Guillaume, dear Jun,
I've been following your lively discussion so far with great interest. Let me jump into the question related to extending the OpenStack CPI vs creating your own CPI.
In this particular case, I think the differences between Huaweicloud and OpenStack are already pretty substantial: The authentication and network API is so different that even changes in fog-openstack (the library that we use to talk to the OpenStack API) were necessary. This is much more than just changes in terms of cloud_properties. If it would be for those differences alone it would probably be a very different discussion. If I understood Jun correctly, the differences between OpenStack and Huaweicloud might even grow bigger because they want the freedom to introduce API endpoints and features which OpenStack doesn't have.
So, in my opinion, the approach to create a new CPI to talk to a different API seems like a reasonable choice.
I understand Guillaume's concern that Orange is currently using the OpenStack CPI and probably wonder if they would be forced to switch to the Huaweicloud CPI at some point in the future. This seems to be a broader discussion around the scope and direction of Huaweicloud and the FusionSphere product. Regardless of our decision to incubate this CPI or not, it seems like something that is best discussed with your vendor's representatives.
Jun, for understanding the priorities for the near future it would indeed be helpful to see a backlog, a list of issues, or similar. You are free to choose a tool that you think works best for the team. If you'd like to organize with github issues or an etherpad or something different, that is your choice. Linking it in the project's README is good practice, such that interested parties can easily find it. This increases people's trust that the CPI is a long-term investment that gets actively worked on.
Does this sound reasonable?
From: cf-bosh@... <cf-bosh@...> on behalf of jun zhong <jun.zhongjun2@...>
Sent: Wednesday, September 5, 2018 9:57 AM
Subject: Re: [cf-bosh] Incubation proposal: HuaweiCloud CPI
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.
-- What is the standard apis, different vendors have different strategies, the more suitable apis is the standard apis for specified vendor. There already have many CPIs that not follow the standard apis such as openstack. It works very well. Why marketing teams have to "educate users into this vision". The specified vendor have its own CPI, and lead their own customers ask for a dedicated public cloud cpi, it is a more suitable way for the specified vendor public cloud, right? The specified vendor will maintain their own CPI, it own't affect other. The HuaweiCloud CPI will support the feature that openstack don't support it, such as: AK/SK(access_key_id and access_secret_id) certification  in the future. It won't be the part of the OpenStack. Sorry, I didn't see any realy problem.
I believe the CF foundation page listed supported infrastructure providers , bosh-docs  and cf-docs  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.
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 ?
I believe this is inaccurate: bosh supports differentiates features by each CPI in the following forms:
a) custom cloud properties  associated to AZ, networks, disk types, vm types, declare in cloud-config  and referenced within bosh manifests 
b) specifically vm_extensions  allows to specify arbitrary IaaS specific configuration associated to a VM such as security groups or load balancers pool membership
-- The HuaweiCloud CPI is not belong to OpenStack CPI, the HuaweiCloud cpi isn't being a complete fork of the openstack cpi, it have its own APIs and cloud properties. Why we have to support the Huawei team into designing support for extensions in the openstack CPI. According to this logic, other bosh CPIs can be used as a plugin in OpenStack CPI.
-- For example, for user that use bosh CPI to create a cloudfoundry enviroment, they only care about how to config the cloud properties file. Such as alicloud, most of the cloud properties associated to AZ, networks, disk types, vm types are the same with openstack CPI, The different cloud property is vswitch_id and access_key_id when they want to create a new bosh director. It like the huaweicloud CPI does, we have the different cloud property named 'subnet_id'. The HuaweiCloud CPI also will support AK/SK(access_key_id and access_secret_id) certification  in the future. There are small different cloud properties between OpenStack CPI and other CPI. If we could support the Huawei team into designing support for extensions in the openstack CPI, then other CPI cloud also do that.
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   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?
-- Added a new user facing documentation for HuaweiCloud CPI in bosh docs. Is the planned future work necessary for new CPI. We cloud use the issuse or pr in github repo or etherpad to track the plans in the feature?
Guillaume Berche <bercheg@...> 于2018年9月4日周二 上午12:13写道：