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.
VP Open Ecosystem Team
Admin: Sophie Johnson
+1 (908) 541-3590
Futurewei Technologies, Inc.
Fixed Network Solution CC
400 Crossing Blvd
Bridgewater, NJ 08807
From: main@... [mailto:main@...]
On Behalf Of Srini
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:
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