Date
1 - 1 of 1
FW: [tsc-private] Akraino Blueprint Technical Charter
|
Resending to main@... as requested by moderator. So some may already seen this - apologies if so.
toggle quoted message
Show quoted text
There is also very interesting suggestion from Frank of a higher level classification i.e. 'Order' to define the target use case (there of course there could be one or more 'Families' of solutions to support that use case). Again I would like to stress this isn't suggesting or encouraging sprawl to the project - it is quite valid to start with one instance of Family, Genus and Species for a give use case e.g. to support 5G VNF edge deployments - my target is enable a flexible framework to add within the Akraino blueprint framework as time and new releases occur even if we only start with one or two possibilities initially. Andrew -----Original Message-----
From: Andrew Wilkinson <andrew.wilkinson@...> Sent: Thursday, September 13, 2018 4:02 PM To: tsc-voting@... Subject: Re: [tsc-private] Akraino Blueprint Technical Charter As we may be discussing this in multiple forums/email lists so apologies if this is a repeat for some on the this list but sending again to make sure all see it. I think there are fundamentally 3 levels involved in the inception of new family of PODs to the deployment of an actual physical Akraino POD at an actual site. 3. The lowest is exact and defined by a set of yaml files that build the actual POD deployed to a site. This is down to the number of compute, type of compute, SW versions, names of servers etc etc. If I say change from 3 to 4 compute in a POD this level changes as one or more of the yaml files changes Then the first two levels would be 1. The Blueprint level as the highest level. This is for example a 'Network Cloud' blueprint or the 'StarlingX' blueprint or whatever is approved/offered to the community. Within this characterization the are a number of immutable characteristics that make it that blueprint that blueprint and fundamentally differen to other blueprints e.g. (not i.e.!) use of airship, installation of OpenStack etc. 2. The Blueprint Specification. This allows variation of major components of the blueprint e.g. the use of say Dell over HP compute, the use of Ubuntu over say Centos etc etc. It's important to note there could be just one specification or a number depending on a given blueprint. I gave these names in keeping with the opensource community's love of animal themes and borrowed from the Linnaeus biological taxonomy structure : Blueprint Family (1) , Genus (2) and Species (3) We should review this as a proposal at the next blueprint session. Andrew -----Original Message----- From: tsc-voting@... <tsc-voting@...> On Behalf Of Takeshi Kuwahara Sent: Wednesday, September 12, 2018 7:49 AM To: tsc-voting@... Subject: Re: [tsc-private] Akraino Blueprint Technical Charter Dear team, A blueprint specification template should support various use cases and requirements. On the other hand, it is not always easy to list up all the possible use cases and requirements to be supported by a blueprint when it's proposed. Also, it is necessary to energize the community by providing a mechanism that is easy to accept various proposals. Therefore, the community needs to be able to update existing blueprint specification templates when necessary. Major triggers of such update are: A) Major/minor version update of a software component included in a given blueprint specification template. Example: Ubuntu 18.04.1 -> 18.04.2 B) Newer generation of a hardware component included in a given blueprint specification template. Example: Dell R740 -> R750 C) Proposal of new use cases and requirements/test cases which could be solved by updating an existing blueprint specification template through feature updates and/or template options updates. Example: Lower latency Network Cloud Software updates (A) can be verified and incorporated as the update to the existing blueprint spec template through an appropriate CI/CD mechanism. Hardware renewal (B) can also be done in the same way if anyone can contribute to bring those to CI/CD labs. New proposals (C) can be handled in the following way: 1) Contributor who are going to propose it needs to explain clear use case(s) and its requirements (i.e. POD and test cases). 2) If the community has an existing blueprint specification template (here assume BPT-A 1.0) which can solve some use cases and requirements that is not too far from the proposed ones, then the community can treat the proposal as potential update of the existing blueprint spec template (BPT-A 1.1 or 2.0, depending of versioning policy). If not, the community should consider to make another blueprint spec template (BPT-B 1.0). The point is that we should not make too many numbers of blueprint spec templates for the sake of the community maintenance and market value. Therefore, new proposal needs to be compared to the existing ones and only when it’s not close at all to any, we can consider making new blueprint spec templates. Thanks, - Takeshi On 2018/09/04 23:53, Tina Tsou wrote: Dear team,-- --- Takeshi KUWAHARA <kuwahara.takeshi@...> Network Technology Labs, NTT |
|
|