Date   
Re: Azure Storage?

Mike Lloyd <klloyd@...>
 

I think midterm is okay - so long as it's on the roadmap and committed I can be happy. Recently there was an issue I had where the BOSH director was return HTTP 500 for every operation, after some investigation it turned out to be the local disk space was full. I was able to resolve it, but as I (and others) run BOSH on Azure, the ability to use the target cloud's blob store would be immensely useful. Otherwise it's monitoring for disk space and resizing disks or leveraging Minio/off-cloud solution. As a primarily Azure-based operator, not having parity on blob storage adds a small engineering overhead which may not necessarily exist in AWS and GCP.

Respectfully,

Mike.


On Tue, Oct 2, 2018 at 11:54 AM Morgan Fine <mfine@...> wrote:
Hey Mike,

We do have a roadmap item to enable Azure Blob Storage support for the BOSH director. That being said, it's looking like it's a midterm roadmap goal in the next few months based on our current priorities. 

Is there a specific reason you're asking? Any additional context is always useful to help with prioritization decisions later on.

Thanks,
Morgan

Re: Azure Storage?

Morgan Fine
 

Hey Mike,

We do have a roadmap item to enable Azure Blob Storage support for the BOSH director. That being said, it's looking like it's a midterm roadmap goal in the next few months based on our current priorities. 

Is there a specific reason you're asking? Any additional context is always useful to help with prioritization decisions later on.

Thanks,
Morgan

Re: [cf-dev] BOSH PMC refactoring part 2 – moving CPIs out of incubation

Marco Voelz
 

Der friends of BOSH,

 

We have moved the below CPIs from the cloudfoundry-incubator to the cloudfoundry github organization. The new releases will soon arrive on bosh.io after adapting its configuration [1].

 

For now, bosh.io/releases will still contain both, the releases for cloudfoundry-incubator as well as the releases in cloudfoundry. After a grace period of four weeks, ending November 1st, we will remove the cloudfoundry-incubator based releases from the bosh.io/releases listing for those CPIs [2]. Until then, please adapt any references to bosh.io/releases for the 5 CPIs below.

 

Reach out to me directly or reply to this mail if you have any comments or this grace period won't work for you.

 

Warm regards

Marco

 

[1] https://github.com/bosh-io/releases/pull/58

[2] https://github.com/bosh-io/releases/pull/59

 

From: <cf-dev@...> on behalf of Marco Voelz <marco.voelz@...>
Reply-To: "cf-dev@..." <cf-dev@...>
Date: Thursday, 23. August 2018 at 11:17
To: "cf-bosh@..." <cf-bosh@...>
Cc: "Discussions about Cloud Foundry projects and the system overall." <cf-dev@...>
Subject: [CAUTION] [cf-dev] 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.

 

 

Azure Storage?

klloyd@...
 

BOSH Team,

 

Currently the BOSH director supports WebDAV, GCS, and S3 for its Blobstore Providers. Are there plans to add support for Azure Blob Storage?

 

Thanks,

 

Mike Lloyd

Pivotal

Re: BOSH Stemcell Support Policy

theo@...
 

++1

We would also like a formal way to track CVE's and which specific patch they affect and are fixed in. This would allow us to more easily demonstrate the value we get from BOSH and regular updates.

Thanks,

Theo

PM for Cloud Foundry team within a large bank

Re: BOSH Stemcell Support Policy

Damzog Jochen (CI/OSC1)
 

+1 !!

 

It would be great if you included a formal way to track which CVE s are covered by a given patch version for each stemcell line so it can easily (automatically) be tracked.

 

Mit freundlichen Grüßen / Best regards

Jochen Damzog

Service Integration and Brokering (CI/OSC1)
Robert Bosch GmbH | Postfach 30 02 20 | 70442 Stuttgart | GERMANY
| www.bosch.com
Tel. +49 711 811-18977 | Mobil +49 173 8673114 | Fax +49 711 811 |
Jochen.Damzog@...

Sitz: Stuttgart, Registergericht: Amtsgericht Stuttgart, HRB 14000;
Aufsichtsratsvorsitzender: Franz Fehrenbach; Geschäftsführung: Dr. Volkmar Denner,
Prof. Dr. Stefan Asenkerschbaumer, Dr. Michael Bolle, Dr. Rolf Bulander, Dr. Stefan Hartung, Dr. Markus Heyn,
Dr. Dirk Hoheisel, Christoph Kübel, Uwe Raschke, Peter Tyroller


Von: cf-bosh@... <cf-bosh@...> Im Auftrag von Morgan Fine
Gesendet: Freitag, 28. September 2018 19:58
An: cf-dev@...; cf-bosh@...
Betreff: [cf-bosh] BOSH Stemcell Support Policy

 

Hi CF Community,

 

The BOSH team is working to formalize a policy for Linux stemcell support. Up until now, the team has not had a policy on which stemcell lines are officially supported. We'll also be working to make this information available on bosh.io

 

Please find the details in the attached document.

 

 

Best,

Morgan Fine

CF BOSH 

Re: BOSH Stemcell Support Policy

Bin Xia
 

That’s great. For us, Azure CPI team, the official support policy for BOSH stemcell is very important and useful.

Here are some questions. Looking forward to your guidance.

  1. Azure CPI has some logic to be compatible with some very old stemcell. If they are not supported any more, it’s safe for us to remove these logic. Correct?
  2. Does the policy ask CPI pipeline or bosh-cpi-certification to test all supported versions?
  3. What’s the support policy for Ubuntu Trusty? After April 2019, will Trusty still be supported officially?
  4. What’s the support policy for CentOS7? CentOS7 is an official BOSH stemcell, but CentOS7 can’t be deployed in cf-deployment. Correct?
  5. Is there a plan to publish support policy for Windows stemcell?

 

From: cf-bosh@... <cf-bosh@...> On Behalf Of Morgan Fine
Sent: Saturday, September 29, 2018 1:58 AM
To: cf-dev@...; cf-bosh@...
Subject: [cf-bosh] BOSH Stemcell Support Policy

 

Hi CF Community,

 

The BOSH team is working to formalize a policy for Linux stemcell support. Up until now, the team has not had a policy on which stemcell lines are officially supported. We'll also be working to make this information available on bosh.io

 

Please find the details in the attached document.

 

 

Best,

Morgan Fine

CF BOSH 

BOSH Stemcell Support Policy

Morgan Fine
 

Hi CF Community,

The BOSH team is working to formalize a policy for Linux stemcell support. Up until now, the team has not had a policy on which stemcell lines are officially supported. We'll also be working to make this information available on bosh.io

Please find the details in the attached document.


Best,
Morgan Fine
CF BOSH 

Re: Incubation proposal: HuaweiCloud CPI

jun zhong
 

Thanks  Marco  for bring us this good news! 

JUN
Thanks



Marco Voelz <marco.voelz@...> 于2018年9月20日周四 下午4:14写道:

Hi everyone,


The BOSH PMC voted unanimously in favor of incubating the huaweicloud CPI project. Welcome to Jun and the team!

Warm regards
Marco


From: cf-bosh@... <cf-bosh@...> on behalf of jun zhong <jun.zhongjun2@...>
Sent: Friday, September 7, 2018 8:44:13 AM
To: cf-bosh@...
Subject: Re: [cf-bosh] Incubation proposal: HuaweiCloud CPI
 
Hi Marco,


Thanks for giving your opinion. It sounds reasonable for me.

I added a backlog [1] which list the priorities for the near future in github issues, and linking it in the project's README. We use label to track the planned future work, such as: enhancement, low priority, medium priority, high priority, etc.





Thanks
JUN

Marco Voelz <marco.voelz@...> 于2018年9月6日周四 下午11:55写道:

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?


Warm regards
Marco


From: cf-bosh@... <cf-bosh@...> on behalf of jun zhong <jun.zhongjun2@...>
Sent: Wednesday, September 5, 2018 9:57 AM
To: cf-bosh@...
Subject: Re: [cf-bosh] Incubation proposal: HuaweiCloud CPI
 
Hi Guillaume,

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 [2] 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 [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.

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


-- 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 [2] 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 [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?


-- Added a new user facing documentation for HuaweiCloud CPI in bosh docs[1]. 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?




Thanks
JUN

Guillaume Berche <bercheg@...> 于2018年9月4日周二 上午12:13写道:
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

Marco Voelz
 

Hi everyone,


The BOSH PMC voted unanimously in favor of incubating the huaweicloud CPI project. Welcome to Jun and the team!

Warm regards
Marco


From: cf-bosh@... <cf-bosh@...> on behalf of jun zhong <jun.zhongjun2@...>
Sent: Friday, September 7, 2018 8:44:13 AM
To: cf-bosh@...
Subject: Re: [cf-bosh] Incubation proposal: HuaweiCloud CPI
 
Hi Marco,


Thanks for giving your opinion. It sounds reasonable for me.

I added a backlog [1] which list the priorities for the near future in github issues, and linking it in the project's README. We use label to track the planned future work, such as: enhancement, low priority, medium priority, high priority, etc.





Thanks
JUN

Marco Voelz <marco.voelz@...> 于2018年9月6日周四 下午11:55写道:

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?


Warm regards
Marco


From: cf-bosh@... <cf-bosh@...> on behalf of jun zhong <jun.zhongjun2@...>
Sent: Wednesday, September 5, 2018 9:57 AM
To: cf-bosh@...
Subject: Re: [cf-bosh] Incubation proposal: HuaweiCloud CPI
 
Hi Guillaume,

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 [2] 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 [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.

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


-- 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 [2] 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 [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?


-- Added a new user facing documentation for HuaweiCloud CPI in bosh docs[1]. 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?




Thanks
JUN

Guillaume Berche <bercheg@...> 于2018年9月4日周二 上午12:13写道:
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 ?





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: Cloud Foundry Community Awards

Swarna Podila
 

Just a reminder -- the deadline is tomorrow; so please nominate today!  Nominate your peers for a Stealth-Ops or Helping Hands award or an end user story for the Coolest User Story award!

-- Swarna Podila
Senior
 Director
, Community
 | Cloud Foundry Foundation


On Wed, Sep 5, 2018 at 1:50 PM Swarna Podila <spodila@...> wrote:
Folks,
We are bringing the Community Awards to Cloud Foundry Summit EU (Basel, Switzerland)!  We need your help; please take a minute to nominate your peer(s) today!  Nominations close on September 15, 2018.

More info at: https://www.cloudfoundry.org/blog/nominate-the-cloud-foundry-community-for-awards-deadline-915/
Nomination form: https://docs.google.com/forms/d/e/1FAIpQLSfVNtvu43XQJF43vH-BbeYw1EjI3re5OOsgCC3guIojNN4DpA/viewform?usp=sf_link

Thank you,
Swarna.

Re: Incubation proposal: HuaweiCloud CPI

jun zhong
 

Hi Marco,


Thanks for giving your opinion. It sounds reasonable for me.

I added a backlog [1] which list the priorities for the near future in github issues, and linking it in the project's README. We use label to track the planned future work, such as: enhancement, low priority, medium priority, high priority, etc.




Thanks
JUN

Marco Voelz <marco.voelz@...> 于2018年9月6日周四 下午11:55写道:

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?


Warm regards
Marco


From: cf-bosh@... <cf-bosh@...> on behalf of jun zhong <jun.zhongjun2@...>
Sent: Wednesday, September 5, 2018 9:57 AM
To: cf-bosh@...
Subject: Re: [cf-bosh] Incubation proposal: HuaweiCloud CPI
 
Hi Guillaume,

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 [2] 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 [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.

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


-- 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 [2] 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 [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?


-- Added a new user facing documentation for HuaweiCloud CPI in bosh docs[1]. 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?




Thanks
JUN

Guillaume Berche <bercheg@...> 于2018年9月4日周二 上午12:13写道:
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 ?





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

Marco Voelz
 

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?


Warm regards
Marco


From: cf-bosh@... <cf-bosh@...> on behalf of jun zhong <jun.zhongjun2@...>
Sent: Wednesday, September 5, 2018 9:57 AM
To: cf-bosh@...
Subject: Re: [cf-bosh] Incubation proposal: HuaweiCloud CPI
 
Hi Guillaume,

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 [2] 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 [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.

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


-- 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 [2] 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 [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?


-- Added a new user facing documentation for HuaweiCloud CPI in bosh docs[1]. 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?




Thanks
JUN

Guillaume Berche <bercheg@...> 于2018年9月4日周二 上午12:13写道:
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


Cloud Foundry Community Awards

Swarna Podila
 

Folks,
We are bringing the Community Awards to Cloud Foundry Summit EU (Basel, Switzerland)!  We need your help; please take a minute to nominate your peer(s) today!  Nominations close on September 15, 2018.

More info at: https://www.cloudfoundry.org/blog/nominate-the-cloud-foundry-community-for-awards-deadline-915/
Nomination form: https://docs.google.com/forms/d/e/1FAIpQLSfVNtvu43XQJF43vH-BbeYw1EjI3re5OOsgCC3guIojNN4DpA/viewform?usp=sf_link

Thank you,
Swarna.

Re: Incubation proposal: HuaweiCloud CPI

jun zhong
 

Hi Guillaume,

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 [2] 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 [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.

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


-- 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 [2] 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 [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?


-- Added a new user facing documentation for HuaweiCloud CPI in bosh docs[1]. 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?




Thanks
JUN

Guillaume Berche <bercheg@...> 于2018年9月4日周二 上午12:13写道:

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,

Thank you for your attention and listed many good suggestions.
I created a channel named huaweicloud in cloudfoundry community slack. Could we discuss it in this channel? Thanks

JUN
Thanks


On 09/04/2018 00:13, Guillaume Berche wrote:
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

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.