Topics

Use cases and Blueprints

Srini
 

Hi,

 

In last Akraino developer conference and break-out session, some clarity started to emerge. But.. several questions remain on the granularity of blueprint. My intention of this email is to start the conversation by asking some high level questions.

 

For every use case, there would be set of deployments.

For each deployment, there would be blueprints.

For a given deployment, intention is to have small number of blueprints.

 

For instance, in case of 5G use case, the deployments can be as follows:

 

-        Core network cloud deployment

-        Multi-server edge cloud deployment

-        Single server edge cloud deployment

-        Two server edge cloud deployment

-        Headless edge deployment

-        Service Orchestration deployment

-        Regional Cloud controller deployment

-        Regional orchestration deployment

 

One blueprint in each of above deployments is expected to satisfy 5G use case.

For each deployment, intention is to have as minimum number of blueprints to choose from.

 

For example, for Multi-Server edge cloud deployment, following blueprints are one possibility:

 

-        Openstack-x86HW-Ubuntu-NoSDNCtrl-v1

-        K8S-x86HW-Ubuntu-OVN-SRIOVCtrl-v1

 

There are few questions raised and we are wondering whether there is a need to have modularity in the blue prints.

 

1.      A given Edge Cloud may not have all uniform servers. Some servers may be legacy, some may be with latest processor ). In future, they may be added with some add-on accelerators or there could be compute nodes with next generation processors. Also, compute nodes could be from different OEMs.  Every time there is new node introduced or enhanced with new add-on accelerators, would it be considered as a new blueprint or is that considered as new version of existing blueprint?  New version?

2.      Is OS version expected to be common across all servers? If there is a flexibility, adding a new OS version considered as new blueprint or a new version of existing blueprint? New version?

3.      Any support for new site level orchestrator requires new blueprint.  Yes?

4.      Any support for new SDN controller requires new blueprint. Yes?

5.      Any support for new fabric switches requires new blueprint. Yes?

6.      Any addition of additional SW packages to NFVI requires new blueprint. Yes?

7.      If there is a version change in Openstack (say moving from Newton to Pike), SDN Controller or K8S, does it require new blueprint or a new version of the blueprint?  New version?

 

Just few questions for discussions J

 

Thanks

Srini

 

 

Andrew Wilkinson
 

>>Responses below – this gets to the key definition what a “Blueprint” is and how it can be tailored and evolve.

 

From: main@... <main@...> On Behalf Of Srini
Sent: Wednesday, September 05, 2018 1:31 PM
To: main@...
Subject: [akraino] Use cases and Blueprints

 

Hi,

 

In last Akraino developer conference and break-out session, some clarity started to emerge. But.. several questions remain on the granularity of blueprint. My intention of this email is to start the conversation by asking some high level questions.

 

For every use case, there would be set of deployments.

For each deployment, there would be blueprints.

For a given deployment, intention is to have small number of blueprints.

 

For instance, in case of 5G use case, the deployments can be as follows:

 

  • Core network cloud deployment
  • Multi-server edge cloud deployment
  • Single server edge cloud deployment
  • Two server edge cloud deployment
  • Headless edge deployment
  • Service Orchestration deployment
  • Regional Cloud controller deployment
  • Regional orchestration deployment

 

 

One blueprint in each of above deployments is expected to satisfy 5G use case.

For each deployment, intention is to have as minimum number of blueprints to choose from.

 

 

>>Yes but they have to be appropriate for the organization deploying them. My small set may be different to your small set.

>>They have to be customizable to be relevant to a wide audience

 

For example, for Multi-Server edge cloud deployment, following blueprints are one possibility:

 

  • Openstack-x86HW-Ubuntu-NoSDNCtrl-v1
  • K8S-x86HW-Ubuntu-OVN-SRIOVCtrl-v1

 

There are few questions raised and we are wondering whether there is a need to have modularity in the blue prints.

 

  1. A given Edge Cloud may not have all uniform servers. Some servers may be legacy, some may be with latest processor ). In future, they may be added with some add-on accelerators or there could be compute nodes with next generation processors. Also, compute nodes could be from different OEMs.  Every time there is new node introduced or enhanced with new add-on accelerators, would it be considered as a new blueprint or is that considered as new version of existing blueprint?  New version?

 

 

>>One proposal that I’ve started to sketch in the charter doc is the concept of a Blueprint Specification that accompanies a more generic Blueprint

>>The Specification would precisely and declaratively define the HW and SW in a POD and the LCM approach to a deployment of the POD described by that Blueprint + Blueprint Specification.

>>The Blueprint Specification would need to be layered (e.g., HW, networking, virtualization layers etc etc) and would allow one to do exactly what you described above (Openstack-x86HW-Ubuntu-

 

NoSDNCtrl-v1 OR K8S-x86HW-Ubuntu-OVN-SRIOVCtrl-v1 etc in the same Blueprint)

 

>>Subsequent releases of Akraino for a given Blueprint would add options that could be chosen to form the Blueprint’s Specification

>>The individual functions/plugins/HW in a precise Blueprint’s Specification would be selected from the Blueprint Specification Template.

>>The Blueprint Specification Template would contain all the options supported for a given Blueprint at a given Akraino release.

 

  1. Is OS version expected to be common across all servers? If there is a flexibility, adding a new OS version considered as new blueprint or a new version of existing blueprint? New version?

 

>>We have to support different OS versions and distros in different PODs for sure but should one POD support a mix in the (single) POD?

>>Technically it could but I feel it’ll make the definition and management extremely complex

>>But in forming the definition of a blueprint we should consider it for future as we may then want to structure that definition to support in future multiple options of the same component.

 

  1. Any support for new site level orchestrator requires new blueprint.  Yes?

 

  1. Any support for new SDN controller requires new blueprint. Yes?

 

 

>>I don’t think so if an SDN controller is a plugin option within the Blueprint’s Specification. If not then yes.

>>I could deploy openstack in a Network Cloud Blueprint by selecting different controllers from the set of controller options (e.g. neutron without a controller, ODL or TitaniumFabric controller etc – assuming all were available and tested in a given Akraino release of the ‘Network Cloud’ Blueprint)

 

  1. Any support for new fabric switches requires new blueprint. Yes?

 

>>I wouldn’t assume so by default

>>Let’s say for example a blueprint + spec require L2 only between deployed HW and used only MAC learning – changing the fabric switches out doesn’t have to change the deployment of the POD if the two switches have the same capability.

>>The key question is is the switch fabric managed by the LCM and deployment tools of the Blueprint? If so then you’d need to at least have an option for the different switches in the Blueprint Specification (or have a different Blueprint)

 

  1. Any addition of additional SW packages to NFVI requires new blueprint. Yes?

 

>>Again don’t think so – this will explode the number of Blueprints

>>A different selection of functionalities from those support in a given the Blueprint Specification Template for a given Akraino release would allow one to deploy different SW within the same Blueprint

>>BUT the same question arises about mixing in the same POD deployed by a given Blueprint + Specification as you raised for the OS mixing

>>Think we need more discussion here

 

  1. If there is a version change in Openstack (say moving from Newton to Pike), SDN Controller or K8S, does it require new blueprint or a new version of the blueprint?  New version?

>>I’d see this as a change to the blueprint specification not the blueprint itself – i.e. one selects a different OS SW “plugin’ from the template

 

Just few questions for discussions J

 

Thanks

Srini

 

 

bob monkman
 

Thanks Andrew, Srini,

 

              We will certainly need something like the concept of a Blueprint Specification to address variants of a common general blueprint where a certain OS, CPU Arch, SDN Controller, Vswitch is utilized.

Regards,

Bob

 

Robert (Bob) Monkman

Director, Networking Software Strategy & Ecosystem Programs

Arm

150 Rose Orchard Way

San Jose, Ca 95134

M: +1.510.676.5490

Skype: robert.monkman

 

From: main@... <main@...> On Behalf Of Andrew Wilkinson
Sent: Wednesday, September 5, 2018 3:00 PM
To: main@...
Subject: Re: [akraino] Use cases and Blueprints

 

>>Responses below – this gets to the key definition what a “Blueprint” is and how it can be tailored and evolve.

 

From: main@... <main@...> On Behalf Of Srini
Sent: Wednesday, September 05, 2018 1:31 PM
To: main@...
Subject: [akraino] Use cases and Blueprints

 

Hi,

 

In last Akraino developer conference and break-out session, some clarity started to emerge. But.. several questions remain on the granularity of blueprint. My intention of this email is to start the conversation by asking some high level questions.

 

For every use case, there would be set of deployments.

For each deployment, there would be blueprints.

For a given deployment, intention is to have small number of blueprints.

 

For instance, in case of 5G use case, the deployments can be as follows:

 

  • Core network cloud deployment
  • Multi-server edge cloud deployment
  • Single server edge cloud deployment
  • Two server edge cloud deployment
  • Headless edge deployment
  • Service Orchestration deployment
  • Regional Cloud controller deployment
  • Regional orchestration deployment

 

 

One blueprint in each of above deployments is expected to satisfy 5G use case.

For each deployment, intention is to have as minimum number of blueprints to choose from.

 

 

>>Yes but they have to be appropriate for the organization deploying them. My small set may be different to your small set.

>>They have to be customizable to be relevant to a wide audience

 

For example, for Multi-Server edge cloud deployment, following blueprints are one possibility:

 

  • Openstack-x86HW-Ubuntu-NoSDNCtrl-v1
  • K8S-x86HW-Ubuntu-OVN-SRIOVCtrl-v1

 

There are few questions raised and we are wondering whether there is a need to have modularity in the blue prints.

 

  1. A given Edge Cloud may not have all uniform servers. Some servers may be legacy, some may be with latest processor ). In future, they may be added with some add-on accelerators or there could be compute nodes with next generation processors. Also, compute nodes could be from different OEMs.  Every time there is new node introduced or enhanced with new add-on accelerators, would it be considered as a new blueprint or is that considered as new version of existing blueprint?  New version?

 

 

>>One proposal that I’ve started to sketch in the charter doc is the concept of a Blueprint Specification that accompanies a more generic Blueprint

>>The Specification would precisely and declaratively define the HW and SW in a POD and the LCM approach to a deployment of the POD described by that Blueprint + Blueprint Specification.

>>The Blueprint Specification would need to be layered (e.g., HW, networking, virtualization layers etc etc) and would allow one to do exactly what you described above (Openstack-x86HW-Ubuntu-

 

NoSDNCtrl-v1 OR K8S-x86HW-Ubuntu-OVN-SRIOVCtrl-v1 etc in the same Blueprint)

 

>>Subsequent releases of Akraino for a given Blueprint would add options that could be chosen to form the Blueprint’s Specification

>>The individual functions/plugins/HW in a precise Blueprint’s Specification would be selected from the Blueprint Specification Template.

>>The Blueprint Specification Template would contain all the options supported for a given Blueprint at a given Akraino release.

 

  1. Is OS version expected to be common across all servers? If there is a flexibility, adding a new OS version considered as new blueprint or a new version of existing blueprint? New version?

 

>>We have to support different OS versions and distros in different PODs for sure but should one POD support a mix in the (single) POD?

>>Technically it could but I feel it’ll make the definition and management extremely complex

>>But in forming the definition of a blueprint we should consider it for future as we may then want to structure that definition to support in future multiple options of the same component.

 

  1. Any support for new site level orchestrator requires new blueprint.  Yes?

 

  1. Any support for new SDN controller requires new blueprint. Yes?

 

 

>>I don’t think so if an SDN controller is a plugin option within the Blueprint’s Specification. If not then yes.

>>I could deploy openstack in a Network Cloud Blueprint by selecting different controllers from the set of controller options (e.g. neutron without a controller, ODL or TitaniumFabric controller etc – assuming all were available and tested in a given Akraino release of the ‘Network Cloud’ Blueprint)

 

  1. Any support for new fabric switches requires new blueprint. Yes?

 

>>I wouldn’t assume so by default

>>Let’s say for example a blueprint + spec require L2 only between deployed HW and used only MAC learning – changing the fabric switches out doesn’t have to change the deployment of the POD if the two switches have the same capability.

>>The key question is is the switch fabric managed by the LCM and deployment tools of the Blueprint? If so then you’d need to at least have an option for the different switches in the Blueprint Specification (or have a different Blueprint)

 

  1. Any addition of additional SW packages to NFVI requires new blueprint. Yes?

 

>>Again don’t think so – this will explode the number of Blueprints

>>A different selection of functionalities from those support in a given the Blueprint Specification Template for a given Akraino release would allow one to deploy different SW within the same Blueprint

>>BUT the same question arises about mixing in the same POD deployed by a given Blueprint + Specification as you raised for the OS mixing

>>Think we need more discussion here

 

  1. If there is a version change in Openstack (say moving from Newton to Pike), SDN Controller or K8S, does it require new blueprint or a new version of the blueprint?  New version?

>>I’d see this as a change to the blueprint specification not the blueprint itself – i.e. one selects a different OS SW “plugin’ from the template

 

Just few questions for discussions J

 

Thanks

Srini

 

 

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

Reith, Lothar
 

Hi,

 

I like to comment on the example “5G use case”, suggesting multiple deployments (thus multiple blueprints) depending on number of servers etc.

 

I must say I don’t love the implied idea of LCM/ 5G capacity management process having to switch between blueprints when adding a server.

 

I rather would like to see one blueprint for the 5G use case for 5G Core Network “Cloud” deployment  where the blueprint specification contains constraints regarding the “Cloud”-type, for example a constraint restricting the “Cloud” to the case where the “Cloud” is a single server edge cloud.

 

So in essence, this contribution is proposing to consider the unification of the example with 8 deployments (and “Blueprints”) into a single Blueprint, in order to avoid “Blueprint fragmentation with partially overlapping fragments” from the outset.

 

Lothar

 

Von: main@... [mailto:main@...] Im Auftrag von Andrew Wilkinson
Gesendet: Donnerstag, 6. September 2018 00:00
An: main@...
Betreff: Re: [akraino] Use cases and Blueprints

 

>>Responses below – this gets to the key definition what a “Blueprint” is and how it can be tailored and evolve.

 

From: main@... <main@...> On Behalf Of Srini
Sent: Wednesday, September 05, 2018 1:31 PM
To: main@...
Subject: [akraino] Use cases and Blueprints

 

Hi,

 

In last Akraino developer conference and break-out session, some clarity started to emerge. But.. several questions remain on the granularity of blueprint. My intention of this email is to start the conversation by asking some high level questions.

 

For every use case, there would be set of deployments.

For each deployment, there would be blueprints.

For a given deployment, intention is to have small number of blueprints.

 

For instance, in case of 5G use case, the deployments can be as follows:

 

-        Core network cloud deployment

-        Multi-server edge cloud deployment

-        Single server edge cloud deployment

-        Two server edge cloud deployment

-        Headless edge deployment

-        Service Orchestration deployment

-        Regional Cloud controller deployment

-        Regional orchestration deployment

 

 

One blueprint in each of above deployments is expected to satisfy 5G use case.

For each deployment, intention is to have as minimum number of blueprints to choose from.

 

 

>>Yes but they have to be appropriate for the organization deploying them. My small set may be different to your small set.

>>They have to be customizable to be relevant to a wide audience

 

For example, for Multi-Server edge cloud deployment, following blueprints are one possibility:

 

-        Openstack-x86HW-Ubuntu-NoSDNCtrl-v1

-        K8S-x86HW-Ubuntu-OVN-SRIOVCtrl-v1

 

There are few questions raised and we are wondering whether there is a need to have modularity in the blue prints.

 

  1. A given Edge Cloud may not have all uniform servers. Some servers may be legacy, some may be with latest processor ). In future, they may be added with some add-on accelerators or there could be compute nodes with next generation processors. Also, compute nodes could be from different OEMs.  Every time there is new node introduced or enhanced with new add-on accelerators, would it be considered as a new blueprint or is that considered as new version of existing blueprint?  New version?

 

 

>>One proposal that I’ve started to sketch in the charter doc is the concept of a Blueprint Specification that accompanies a more generic Blueprint

>>The Specification would precisely and declaratively define the HW and SW in a POD and the LCM approach to a deployment of the POD described by that Blueprint + Blueprint Specification.

>>The Blueprint Specification would need to be layered (e.g., HW, networking, virtualization layers etc etc) and would allow one to do exactly what you described above (Openstack-x86HW-Ubuntu-

 

NoSDNCtrl-v1 OR K8S-x86HW-Ubuntu-OVN-SRIOVCtrl-v1 etc in the same Blueprint)

 

>>Subsequent releases of Akraino for a given Blueprint would add options that could be chosen to form the Blueprint’s Specification

>>The individual functions/plugins/HW in a precise Blueprint’s Specification would be selected from the Blueprint Specification Template.

>>The Blueprint Specification Template would contain all the options supported for a given Blueprint at a given Akraino release.

 

  1. Is OS version expected to be common across all servers? If there is a flexibility, adding a new OS version considered as new blueprint or a new version of existing blueprint? New version?

 

>>We have to support different OS versions and distros in different PODs for sure but should one POD support a mix in the (single) POD?

>>Technically it could but I feel it’ll make the definition and management extremely complex

>>But in forming the definition of a blueprint we should consider it for future as we may then want to structure that definition to support in future multiple options of the same component.

 

  1. Any support for new site level orchestrator requires new blueprint.  Yes?

 

  1. Any support for new SDN controller requires new blueprint. Yes?

 

 

>>I don’t think so if an SDN controller is a plugin option within the Blueprint’s Specification. If not then yes.

>>I could deploy openstack in a Network Cloud Blueprint by selecting different controllers from the set of controller options (e.g. neutron without a controller, ODL or TitaniumFabric controller etc – assuming all were available and tested in a given Akraino release of the ‘Network Cloud’ Blueprint)

 

  1. Any support for new fabric switches requires new blueprint. Yes?

 

>>I wouldn’t assume so by default

>>Let’s say for example a blueprint + spec require L2 only between deployed HW and used only MAC learning – changing the fabric switches out doesn’t have to change the deployment of the POD if the two switches have the same capability.

>>The key question is is the switch fabric managed by the LCM and deployment tools of the Blueprint? If so then you’d need to at least have an option for the different switches in the Blueprint Specification (or have a different Blueprint)

 

  1. Any addition of additional SW packages to NFVI requires new blueprint. Yes?

 

>>Again don’t think so – this will explode the number of Blueprints

>>A different selection of functionalities from those support in a given the Blueprint Specification Template for a given Akraino release would allow one to deploy different SW within the same Blueprint

>>BUT the same question arises about mixing in the same POD deployed by a given Blueprint + Specification as you raised for the OS mixing

>>Think we need more discussion here

 

  1. If there is a version change in Openstack (say moving from Newton to Pike), SDN Controller or K8S, does it require new blueprint or a new version of the blueprint?  New version?

>>I’d see this as a change to the blueprint specification not the blueprint itself – i.e. one selects a different OS SW “plugin’ from the template

 

Just few questions for discussions J

 

Thanks

Srini

 

 

Andrew Wilkinson
 

The approach of a Specification within a given Blueprint to fully define a POD aims to allow the example you mentioned i.e. the addition of a server without changing the blueprint.

 

One way or another though the POD is different and needs to be captured somehow.

 

Let’s discuss in the working group later

 

Andrew

 

From: main@... <main@...> On Behalf Of Reith, Lothar
Sent: Thursday, September 06, 2018 2:06 AM
To: main@...
Subject: Re: [akraino] Use cases and Blueprints

 

Hi,

 

I like to comment on the example “5G use case”, suggesting multiple deployments (thus multiple blueprints) depending on number of servers etc.

 

I must say I don’t love the implied idea of LCM/ 5G capacity management process having to switch between blueprints when adding a server.

 

I rather would like to see one blueprint for the 5G use case for 5G Core Network “Cloud” deployment  where the blueprint specification contains constraints regarding the “Cloud”-type, for example a constraint restricting the “Cloud” to the case where the “Cloud” is a single server edge cloud.

 

So in essence, this contribution is proposing to consider the unification of the example with 8 deployments (and “Blueprints”) into a single Blueprint, in order to avoid “Blueprint fragmentation with partially overlapping fragments” from the outset.

 

Lothar

 

Von: main@... [mailto:main@...] Im Auftrag von Andrew Wilkinson
Gesendet: Donnerstag, 6. September 2018 00:00
An: main@...
Betreff: Re: [akraino] Use cases and Blueprints

 

>>Responses below – this gets to the key definition what a “Blueprint” is and how it can be tailored and evolve.

 

From: main@... <main@...> On Behalf Of Srini
Sent: Wednesday, September 05, 2018 1:31 PM
To: main@...
Subject: [akraino] Use cases and Blueprints

 

Hi,

 

In last Akraino developer conference and break-out session, some clarity started to emerge. But.. several questions remain on the granularity of blueprint. My intention of this email is to start the conversation by asking some high level questions.

 

For every use case, there would be set of deployments.

For each deployment, there would be blueprints.

For a given deployment, intention is to have small number of blueprints.

 

For instance, in case of 5G use case, the deployments can be as follows:

 

  • Core network cloud deployment
  • Multi-server edge cloud deployment
  • Single server edge cloud deployment
  • Two server edge cloud deployment
  • Headless edge deployment
  • Service Orchestration deployment
  • Regional Cloud controller deployment
  • Regional orchestration deployment

 

 

One blueprint in each of above deployments is expected to satisfy 5G use case.

For each deployment, intention is to have as minimum number of blueprints to choose from.

 

 

>>Yes but they have to be appropriate for the organization deploying them. My small set may be different to your small set.

>>They have to be customizable to be relevant to a wide audience

 

For example, for Multi-Server edge cloud deployment, following blueprints are one possibility:

 

  • Openstack-x86HW-Ubuntu-NoSDNCtrl-v1
  • K8S-x86HW-Ubuntu-OVN-SRIOVCtrl-v1

 

There are few questions raised and we are wondering whether there is a need to have modularity in the blue prints.

 

  1. A given Edge Cloud may not have all uniform servers. Some servers may be legacy, some may be with latest processor ). In future, they may be added with some add-on accelerators or there could be compute nodes with next generation processors. Also, compute nodes could be from different OEMs.  Every time there is new node introduced or enhanced with new add-on accelerators, would it be considered as a new blueprint or is that considered as new version of existing blueprint?  New version?

 

 

>>One proposal that I’ve started to sketch in the charter doc is the concept of a Blueprint Specification that accompanies a more generic Blueprint

>>The Specification would precisely and declaratively define the HW and SW in a POD and the LCM approach to a deployment of the POD described by that Blueprint + Blueprint Specification.

>>The Blueprint Specification would need to be layered (e.g., HW, networking, virtualization layers etc etc) and would allow one to do exactly what you described above (Openstack-x86HW-Ubuntu-

 

NoSDNCtrl-v1 OR K8S-x86HW-Ubuntu-OVN-SRIOVCtrl-v1 etc in the same Blueprint)

 

>>Subsequent releases of Akraino for a given Blueprint would add options that could be chosen to form the Blueprint’s Specification

>>The individual functions/plugins/HW in a precise Blueprint’s Specification would be selected from the Blueprint Specification Template.

>>The Blueprint Specification Template would contain all the options supported for a given Blueprint at a given Akraino release.

 

  1. Is OS version expected to be common across all servers? If there is a flexibility, adding a new OS version considered as new blueprint or a new version of existing blueprint? New version?

 

>>We have to support different OS versions and distros in different PODs for sure but should one POD support a mix in the (single) POD?

>>Technically it could but I feel it’ll make the definition and management extremely complex

>>But in forming the definition of a blueprint we should consider it for future as we may then want to structure that definition to support in future multiple options of the same component.

 

  1. Any support for new site level orchestrator requires new blueprint.  Yes?

 

  1. Any support for new SDN controller requires new blueprint. Yes?

 

 

>>I don’t think so if an SDN controller is a plugin option within the Blueprint’s Specification. If not then yes.

>>I could deploy openstack in a Network Cloud Blueprint by selecting different controllers from the set of controller options (e.g. neutron without a controller, ODL or TitaniumFabric controller etc – assuming all were available and tested in a given Akraino release of the ‘Network Cloud’ Blueprint)

 

  1. Any support for new fabric switches requires new blueprint. Yes?

 

>>I wouldn’t assume so by default

>>Let’s say for example a blueprint + spec require L2 only between deployed HW and used only MAC learning – changing the fabric switches out doesn’t have to change the deployment of the POD if the two switches have the same capability.

>>The key question is is the switch fabric managed by the LCM and deployment tools of the Blueprint? If so then you’d need to at least have an option for the different switches in the Blueprint Specification (or have a different Blueprint)

 

  1. Any addition of additional SW packages to NFVI requires new blueprint. Yes?

 

>>Again don’t think so – this will explode the number of Blueprints

>>A different selection of functionalities from those support in a given the Blueprint Specification Template for a given Akraino release would allow one to deploy different SW within the same Blueprint

>>BUT the same question arises about mixing in the same POD deployed by a given Blueprint + Specification as you raised for the OS mixing

>>Think we need more discussion here

 

  1. If there is a version change in Openstack (say moving from Newton to Pike), SDN Controller or K8S, does it require new blueprint or a new version of the blueprint?  New version?

>>I’d see this as a change to the blueprint specification not the blueprint itself – i.e. one selects a different OS SW “plugin’ from the template

 

Just few questions for discussions J

 

Thanks

Srini

 

 

Andrew Wilkinson
 

Hi All,

 

Please find attached the material discussed today for your reference.

 

Andrew

 

 

 

From: main@... <main@...> On Behalf Of Andrew Wilkinson
Sent: Thursday, September 06, 2018 6:53 AM
To: main@...
Subject: Re: [akraino] Use cases and Blueprints

 

The approach of a Specification within a given Blueprint to fully define a POD aims to allow the example you mentioned i.e. the addition of a server without changing the blueprint.

 

One way or another though the POD is different and needs to be captured somehow.

 

Let’s discuss in the working group later

 

Andrew

 

From: main@... <main@...> On Behalf Of Reith, Lothar
Sent: Thursday, September 06, 2018 2:06 AM
To: main@...
Subject: Re: [akraino] Use cases and Blueprints

 

Hi,

 

I like to comment on the example “5G use case”, suggesting multiple deployments (thus multiple blueprints) depending on number of servers etc.

 

I must say I don’t love the implied idea of LCM/ 5G capacity management process having to switch between blueprints when adding a server.

 

I rather would like to see one blueprint for the 5G use case for 5G Core Network “Cloud” deployment  where the blueprint specification contains constraints regarding the “Cloud”-type, for example a constraint restricting the “Cloud” to the case where the “Cloud” is a single server edge cloud.

 

So in essence, this contribution is proposing to consider the unification of the example with 8 deployments (and “Blueprints”) into a single Blueprint, in order to avoid “Blueprint fragmentation with partially overlapping fragments” from the outset.

 

Lothar

 

Von: main@... [mailto:main@...] Im Auftrag von Andrew Wilkinson
Gesendet: Donnerstag, 6. September 2018 00:00
An: main@...
Betreff: Re: [akraino] Use cases and Blueprints

 

>>Responses below – this gets to the key definition what a “Blueprint” is and how it can be tailored and evolve.

 

From: main@... <main@...> On Behalf Of Srini
Sent: Wednesday, September 05, 2018 1:31 PM
To: main@...
Subject: [akraino] Use cases and Blueprints

 

Hi,

 

In last Akraino developer conference and break-out session, some clarity started to emerge. But.. several questions remain on the granularity of blueprint. My intention of this email is to start the conversation by asking some high level questions.

 

For every use case, there would be set of deployments.

For each deployment, there would be blueprints.

For a given deployment, intention is to have small number of blueprints.

 

For instance, in case of 5G use case, the deployments can be as follows:

 

  • Core network cloud deployment
  • Multi-server edge cloud deployment
  • Single server edge cloud deployment
  • Two server edge cloud deployment
  • Headless edge deployment
  • Service Orchestration deployment
  • Regional Cloud controller deployment
  • Regional orchestration deployment

 

 

One blueprint in each of above deployments is expected to satisfy 5G use case.

For each deployment, intention is to have as minimum number of blueprints to choose from.

 

 

>>Yes but they have to be appropriate for the organization deploying them. My small set may be different to your small set.

>>They have to be customizable to be relevant to a wide audience

 

For example, for Multi-Server edge cloud deployment, following blueprints are one possibility:

 

  • Openstack-x86HW-Ubuntu-NoSDNCtrl-v1
  • K8S-x86HW-Ubuntu-OVN-SRIOVCtrl-v1

 

There are few questions raised and we are wondering whether there is a need to have modularity in the blue prints.

 

  1. A given Edge Cloud may not have all uniform servers. Some servers may be legacy, some may be with latest processor ). In future, they may be added with some add-on accelerators or there could be compute nodes with next generation processors. Also, compute nodes could be from different OEMs.  Every time there is new node introduced or enhanced with new add-on accelerators, would it be considered as a new blueprint or is that considered as new version of existing blueprint?  New version?

 

 

>>One proposal that I’ve started to sketch in the charter doc is the concept of a Blueprint Specification that accompanies a more generic Blueprint

>>The Specification would precisely and declaratively define the HW and SW in a POD and the LCM approach to a deployment of the POD described by that Blueprint + Blueprint Specification.

>>The Blueprint Specification would need to be layered (e.g., HW, networking, virtualization layers etc etc) and would allow one to do exactly what you described above (Openstack-x86HW-Ubuntu-

 

NoSDNCtrl-v1 OR K8S-x86HW-Ubuntu-OVN-SRIOVCtrl-v1 etc in the same Blueprint)

 

>>Subsequent releases of Akraino for a given Blueprint would add options that could be chosen to form the Blueprint’s Specification

>>The individual functions/plugins/HW in a precise Blueprint’s Specification would be selected from the Blueprint Specification Template.

>>The Blueprint Specification Template would contain all the options supported for a given Blueprint at a given Akraino release.

 

  1. Is OS version expected to be common across all servers? If there is a flexibility, adding a new OS version considered as new blueprint or a new version of existing blueprint? New version?

 

>>We have to support different OS versions and distros in different PODs for sure but should one POD support a mix in the (single) POD?

>>Technically it could but I feel it’ll make the definition and management extremely complex

>>But in forming the definition of a blueprint we should consider it for future as we may then want to structure that definition to support in future multiple options of the same component.

 

  1. Any support for new site level orchestrator requires new blueprint.  Yes?

 

  1. Any support for new SDN controller requires new blueprint. Yes?

 

 

>>I don’t think so if an SDN controller is a plugin option within the Blueprint’s Specification. If not then yes.

>>I could deploy openstack in a Network Cloud Blueprint by selecting different controllers from the set of controller options (e.g. neutron without a controller, ODL or TitaniumFabric controller etc – assuming all were available and tested in a given Akraino release of the ‘Network Cloud’ Blueprint)

 

  1. Any support for new fabric switches requires new blueprint. Yes?

 

>>I wouldn’t assume so by default

>>Let’s say for example a blueprint + spec require L2 only between deployed HW and used only MAC learning – changing the fabric switches out doesn’t have to change the deployment of the POD if the two switches have the same capability.

>>The key question is is the switch fabric managed by the LCM and deployment tools of the Blueprint? If so then you’d need to at least have an option for the different switches in the Blueprint Specification (or have a different Blueprint)

 

  1. Any addition of additional SW packages to NFVI requires new blueprint. Yes?

 

>>Again don’t think so – this will explode the number of Blueprints

>>A different selection of functionalities from those support in a given the Blueprint Specification Template for a given Akraino release would allow one to deploy different SW within the same Blueprint

>>BUT the same question arises about mixing in the same POD deployed by a given Blueprint + Specification as you raised for the OS mixing

>>Think we need more discussion here

 

  1. If there is a version change in Openstack (say moving from Newton to Pike), SDN Controller or K8S, does it require new blueprint or a new version of the blueprint?  New version?

>>I’d see this as a change to the blueprint specification not the blueprint itself – i.e. one selects a different OS SW “plugin’ from the template

 

Just few questions for discussions J

 

Thanks

Srini

 

 

Margaret Chiosi <margaret.chiosi1@...>
 

I wasn’t thinking that we would have all these blueprints – so maybe we should update the draft definitions doc on scope of a blueprint. I thought the use case determined the scope. But then a scope of a use case needs to be defined.

 

Thank You,

Margaret Chiosi

VP Open Ecosystem Team

 

Admin: Sophie Johnson

Sophie.johnson1@...

+1 (908) 541-3590

 

Futurewei Technologies, Inc.

Fixed Network Solution CC

400 Crossing Blvd

Bridgewater, NJ 08807

(cell) +1-732-216-5507

 

 

From: main@... [mailto:main@...] On Behalf Of Srini
Sent: Wednesday, September 05, 2018 4:31 PM
To: main@...
Subject: [akraino] Use cases and Blueprints

 

Hi,

 

In last Akraino developer conference and break-out session, some clarity started to emerge. But.. several questions remain on the granularity of blueprint. My intention of this email is to start the conversation by asking some high level questions.

 

For every use case, there would be set of deployments.

For each deployment, there would be blueprints.

For a given deployment, intention is to have small number of blueprints.

 

For instance, in case of 5G use case, the deployments can be as follows:

 

-          Core network cloud deployment

-          Multi-server edge cloud deployment

-          Single server edge cloud deployment

-          Two server edge cloud deployment

-          Headless edge deployment

-          Service Orchestration deployment

-          Regional Cloud controller deployment

-          Regional orchestration deployment

 

One blueprint in each of above deployments is expected to satisfy 5G use case.

For each deployment, intention is to have as minimum number of blueprints to choose from.

 

For example, for Multi-Server edge cloud deployment, following blueprints are one possibility:

 

-          Openstack-x86HW-Ubuntu-NoSDNCtrl-v1

-          K8S-x86HW-Ubuntu-OVN-SRIOVCtrl-v1

 

There are few questions raised and we are wondering whether there is a need to have modularity in the blue prints.

 

1.       A given Edge Cloud may not have all uniform servers. Some servers may be legacy, some may be with latest processor ). In future, they may be added with some add-on accelerators or there could be compute nodes with next generation processors. Also, compute nodes could be from different OEMs.  Every time there is new node introduced or enhanced with new add-on accelerators, would it be considered as a new blueprint or is that considered as new version of existing blueprint?  New version?

2.       Is OS version expected to be common across all servers? If there is a flexibility, adding a new OS version considered as new blueprint or a new version of existing blueprint? New version?

3.       Any support for new site level orchestrator requires new blueprint.  Yes?

4.       Any support for new SDN controller requires new blueprint. Yes?

5.       Any support for new fabric switches requires new blueprint. Yes?

6.       Any addition of additional SW packages to NFVI requires new blueprint. Yes?

7.       If there is a version change in Openstack (say moving from Newton to Pike), SDN Controller or K8S, does it require new blueprint or a new version of the blueprint?  New version?

 

Just few questions for discussions J

 

Thanks

Srini

 

 

Margaret Chiosi <margaret.chiosi1@...>
 

I thought in email folks were ok with the following types of blueprint:
1. Architecture
2. components (Physical/virtual) supporting a specific 'use case'
3. Test

Andrew Wilkinson
 

 

I wouldn’t see a Test definition (3) as a ‘blueprint’.

 

Nor would I see specific functional components (2) developed by the Akraino community as ‘blueprints’ either.

 

I think using the term blueprint for everything tends to make the term too broad. The term blueprint in common parlance is taken to mean the definition of how to build something (e.g. a building – a house or a shed etc). I could of course be expanded to encompass more (like a test blueprint) but would suggest we keep Akraino blueprints to be more specific and not include  functionality or test schedules.

 

Rather I propose a blueprint be used to classify a set of options that cab result in distinct POD deployments. The term ‘Network Clod blueprint’ would be used as such.

 

Andrew

From: main@... <main@...> On Behalf Of Margaret Chiosi
Sent: Thursday, September 13, 2018 4:22 PM
To: main@...
Subject: Re: [Akraino Main] Use cases and Blueprints

 

I thought in email folks were ok with the following types of blueprint:
1. Architecture
2. components (Physical/virtual) supporting a specific 'use case'
3. Test

fzdarsky@...
 

On Thu, Sep 13, 2018 at 5:39 PM Andrew Wilkinson
<andrew.wilkinson@...> wrote:



I wouldn’t see a Test definition (3) as a ‘blueprint’.



Nor would I see specific functional components (2) developed by the Akraino community as ‘blueprints’ either.



I think using the term blueprint for everything tends to make the term too broad. The term blueprint in common parlance is taken to mean the definition of how to build something (e.g. a building – a house or a shed etc). I could of course be expanded to encompass more (like a test blueprint) but would suggest we keep Akraino blueprints to be more specific and not include functionality or test schedules.
I tend to agree. The term "blueprint" in Akraino is already confusing
enough, even without using it also in the OpenStack Blueprint kind of
sense ;)




Rather I propose a blueprint be used to classify a set of options that cab result in distinct POD deployments. The term ‘Network Clod blueprint’ would be used as such.



Andrew

From: main@... <main@...> On Behalf Of Margaret Chiosi
Sent: Thursday, September 13, 2018 4:22 PM
To: main@...
Subject: Re: [Akraino Main] Use cases and Blueprints



I thought in email folks were ok with the following types of blueprint:
1. Architecture
2. components (Physical/virtual) supporting a specific 'use case'
3. Test



--
Frank Zdarsky | NFV&SDN Technology Strategy, Office of the CTO | Red Hat
e: fzdarsky@... | irc: fzdarsky@freenode | m: +49 175 82 11 64 4

Margaret Chiosi <margaret.chiosi1@...>
 

I will be surprised if we can come up with one functional set of components we all agree on based on my OPNFV/ONAP experience.

But we can try.

 

Thank You,

Margaret Chiosi

VP Open Ecosystem Team

 

Admin: Sophie Johnson

Sophie.johnson1@...

+1 (908) 541-3590

 

Futurewei Technologies, Inc.

Fixed Network Solution CC

400 Crossing Blvd

Bridgewater, NJ 08807

(cell) +1-732-216-5507

 

 

From: Andrew Wilkinson [mailto:andrew.wilkinson@...]
Sent: Thursday, September 13, 2018 11:40 AM
To: Margaret Chiosi (A) <margaret.chiosi1@...>; main@...
Subject: RE: [Akraino Main] Use cases and Blueprints

 

 

I wouldn’t see a Test definition (3) as a ‘blueprint’.

 

Nor would I see specific functional components (2) developed by the Akraino community as ‘blueprints’ either.

 

I think using the term blueprint for everything tends to make the term too broad. The term blueprint in common parlance is taken to mean the definition of how to build something (e.g. a building – a house or a shed etc). I could of course be expanded to encompass more (like a test blueprint) but would suggest we keep Akraino blueprints to be more specific and not include  functionality or test schedules.

 

Rather I propose a blueprint be used to classify a set of options that cab result in distinct POD deployments. The term ‘Network Clod blueprint’ would be used as such.

 

Andrew

From: main@... <main@...> On Behalf Of Margaret Chiosi
Sent: Thursday, September 13, 2018 4:22 PM
To: main@...
Subject: Re: [Akraino Main] Use cases and Blueprints

 

I thought in email folks were ok with the following types of blueprint:
1. Architecture
2. components (Physical/virtual) supporting a specific 'use case'
3. Test

Margaret Chiosi <margaret.chiosi1@...>
 

Actually I would have thought integration meant ‘testing’ and functional meant architecture J

But as long as we define the different blueprints and the definition of them.

 

Thank You,

Margaret Chiosi

VP Open Ecosystem Team

 

Admin: Sophie Johnson

Sophie.johnson1@...

+1 (908) 541-3590

 

Futurewei Technologies, Inc.

Fixed Network Solution CC

400 Crossing Blvd

Bridgewater, NJ 08807

(cell) +1-732-216-5507

 

 

From: Seiler, Glenn [mailto:glenn.seiler@...]
Sent: Thursday, September 13, 2018 2:43 PM
To: Margaret Chiosi (A) <margaret.chiosi1@...>; main@...
Subject: RE: [Akraino Main] Use cases and Blueprints

 

I may have missed some threads, but I thought we were discussing

1)      Integration Blueprints (architecture)

2)      Functional Blueprints  (components)

 

I agree with some of the other comments that we risk spreading or diluting the definition of Blueprint to broadly and it can be very confusing.

I support the idea that blueprints are pretty specific, not just defining components that are integrated, but how they are intended to be used and deployed.

I’m not sure this would apply to an individual component (or functional) blueprint.

 

-glenn

 

From: main@... [mailto:main@...] On Behalf Of Margaret Chiosi
Sent: Thursday, September 13, 2018 8:22 AM
To: main@...
Subject: Re: [Akraino Main] Use cases and Blueprints

 

I thought in email folks were ok with the following types of blueprint:
1. Architecture
2. components (Physical/virtual) supporting a specific 'use case'
3. Test

Glenn Seiler
 

I may have missed some threads, but I thought we were discussing

1)      Integration Blueprints (architecture)

2)      Functional Blueprints  (components)

 

I agree with some of the other comments that we risk spreading or diluting the definition of Blueprint to broadly and it can be very confusing.

I support the idea that blueprints are pretty specific, not just defining components that are integrated, but how they are intended to be used and deployed.

I’m not sure this would apply to an individual component (or functional) blueprint.

 

-glenn

 

From: main@... [mailto:main@...] On Behalf Of Margaret Chiosi
Sent: Thursday, September 13, 2018 8:22 AM
To: main@...
Subject: Re: [Akraino Main] Use cases and Blueprints

 

I thought in email folks were ok with the following types of blueprint:
1. Architecture
2. components (Physical/virtual) supporting a specific 'use case'
3. Test

KATHIRVEL, KANDAN
 

We (TSC) are putting together a draft with all the terminologies this community to use and a process around it. As we promised in the yesterday’s community call, we will review the draft on next Thursday 11 ET @ community call. The intent is to baseline the version by this month end with TSC approval.

I encourage everyone in the community to join next community call to participate in the discussion.

-Kandan

 

 

From: <main@...> on behalf of Glenn Seiler <Glenn.seiler@...>
Date: Friday, September 14, 2018 at 11:41 AM
To: Margaret Chiosi <margaret.chiosi1@...>, "main@..." <main@...>
Subject: Re: [Akraino Main] Use cases and Blueprints

 

I may have missed some threads, but I thought we were discussing

  1. Integration Blueprints (architecture)
  2. Functional Blueprints  (components)

 

I agree with some of the other comments that we risk spreading or diluting the definition of Blueprint to broadly and it can be very confusing.

I support the idea that blueprints are pretty specific, not just defining components that are integrated, but how they are intended to be used and deployed.

I’m not sure this would apply to an individual component (or functional) blueprint.

 

-glenn

 

From: main@... [mailto:main@...] On Behalf Of Margaret Chiosi
Sent: Thursday, September 13, 2018 8:22 AM
To: main@...
Subject: Re: [Akraino Main] Use cases and Blueprints

 

I thought in email folks were ok with the following types of blueprint:
1. Architecture
2. components (Physical/virtual) supporting a specific 'use case'
3. Test

Wenjing Chu
 

Looks like the main@ list is rejecting new topics now. I guess the intention is moving all these to:

technical-discuss@...

or

tsc@...

 

Right now, these new groups have very few subscribers. You will need to go to https://lists.akraino.org to sign up. It appears NOT automatic.

 

In any case, my intended email thread was: (Apologies for skirting rules here – since the new groups aren’t adequately up running with subscribers yet.)

 

 

For folks going to ONS-EU Amsterdam Sept 25-27.

 

I have created a new Unconference session: “Edge Stack Discussion for Cloud Edge and IoT”.

It’s a good opportunity to bring together people from several open source projects working in the edge space during ONS. I’d love to see you all join this session.

 

Add your names to:

https://wiki.lfnetworking.org/display/LN/Open+Networking+Summit+Europe+2018+-+Unconference+Topic+Proposals

 

Regards

Wenjing

 

 

From: main@... [mailto:main@...] On Behalf Of KATHIRVEL, KANDAN
Sent: Friday, September 14, 2018 10:43 AM
To: Glenn Seiler <Glenn.seiler@...>; Margaret Chiosi (A) <margaret.chiosi1@...>; main@...
Subject: Re: [Akraino Main] Use cases and Blueprints

 

We (TSC) are putting together a draft with all the terminologies this community to use and a process around it. As we promised in the yesterday’s community call, we will review the draft on next Thursday 11 ET @ community call. The intent is to baseline the version by this month end with TSC approval.

I encourage everyone in the community to join next community call to participate in the discussion.

-Kandan

 

 

From: <main@...> on behalf of Glenn Seiler <Glenn.seiler@...>
Date: Friday, September 14, 2018 at 11:41 AM
To: Margaret Chiosi <margaret.chiosi1@...>, "main@..." <main@...>
Subject: Re: [Akraino Main] Use cases and Blueprints

 

I may have missed some threads, but I thought we were discussing

1)     Integration Blueprints (architecture)

2)     Functional Blueprints  (components)

 

I agree with some of the other comments that we risk spreading or diluting the definition of Blueprint to broadly and it can be very confusing.

I support the idea that blueprints are pretty specific, not just defining components that are integrated, but how they are intended to be used and deployed.

I’m not sure this would apply to an individual component (or functional) blueprint.

 

-glenn

 

From: main@... [mailto:main@...] On Behalf Of Margaret Chiosi
Sent: Thursday, September 13, 2018 8:22 AM
To: main@...
Subject: Re: [Akraino Main] Use cases and Blueprints

 

I thought in email folks were ok with the following types of blueprint:
1. Architecture
2. components (Physical/virtual) supporting a specific 'use case'
3. Test