docs/specs/multicloud-container-plugin.rst

   1 .. This work is licensed under a Creative Commons Attribution 4.0 International License.
   2 .. http://creativecommons.org/licenses/by/4.0
   3
   4 ===================================================
   5 Container based network service/function deployment
   6 ===================================================
   7 https://wiki.onap.org/pages/viewpage.action?pageId=16007890
   8
   9 This proposal is to implement PoC in Beijing release(R-2) in order to
  10 get experience/feedback for future progress.
  11
  12
  13 Problem Description
  14 ===================
  15 The current ONAP supports only VM based cloud infrastructure for VNF.
  16 On the other hand, in the industry container technology is getting more
  17 momentum.  Increasing VNF density on each node and latency
  18 requirements are driving container based VNFs.  This project enhances
  19 ONAP to support VNFs as containers in addition to VNFs as VMs.
  20
  21 It is beneficial to support for multiple container orchestration technologies
  22 as cloud infrastructure:
  23
  24 * Allow VNFs to run within container technology and also allow closed
  25   feedback loop same to VM based VIM. e.g. openstack.
  26 * Support for co-existence of VNF VMs and VNF containers
  27 * Add container orchestration technology in addition to the
  28   traditional VM-based VIM or environment managed by ONAP.
  29 * Support for uniform network connectivity among VMs and containers.
  30
  31 NOTE: This is different from OOM project `OOM`_. their scope is to
  32 deploy ONAP itself on k8s. Our scope is to deploy/manage VNFs on
  33 container/container orchestration engine(coe). The first target is
  34 k8s. Other CoE will also be addressed if someone steps up to support it.
  35
  36
  37 Proposed Change
  38 ===============
  39
  40 Scope for Beijing release(R-2)
  41 ------------------------------
  42 Basic principle
  43
  44 * First baby step is to support containers in a Kubernetes cluster via a
  45   Multicloud SBI /K8S Plugin
  46   (other COE's(Container Orchestration Engine) are out of Beijing scope.
  47   They are future scope.)
  48 * Minimal implementation with zero impact on MVP of Multicloud Beijing work
  49
  50 Use Cases
  51
  52 * Sample VNFs(vFW and vDNS)
  53   (vCPE use case is post Beijing release)
  54   Both vFW and vDNS are targeted. Since custom TOSCA node definitions
  55   are used (please refer to tosca section below), new TOSCA templates
  56   are needed for them. (In future, post-Beijing, this will be revised
  57   to share common TOSCA template.)
  58
  59 Post Beijing Release
  60 --------------------
  61 In Beijing release, several design aspects are compromised to re-use
  62 the existing component/work flow with zero impact primarily because
  63 the long term solution is not ready to use. It's acceptable this effort
  64 in Beijing release is PoC or experimental to demonstrate functionality
  65 and to get experience for post-Beijing design/architecture.
  66 For example, the use of CSAR/new tosca node definitions are to re-use
  67 the existing code(i.e. Amsteldam release). After Beijing release, those
  68 will be revised for long term solution along with related topics. e.g.
  69 model driven API, modeling based on Beijing experience. Once we
  70 figured out what multicloud COE API should look like and what adapters
  71 in other projects(SO, APP-C) are needed(or not needed) in long term,
  72 the inter-project discussion (mainly with SO, APP-C) will start in
  73 Casablanca cycle.
  74
  75 integration scenario
  76 --------------------
  77 * Register/unregister k8s cluster instances which are already deployed.
  78   dynamic deployment of k8s is out of scope. It is assumed that admin knows
  79   all the necessary parameters.
  80 * onboard VNFD/NSD to use container
  81 * Instantiate / de-instantiate containerized VNFs through K8S Plugin
  82   over K8S cluster
  83 * Vnf configuration with sample VNFs(vFW, vDNS) with the existing configuration
  84   interface. (no change to the existing configuration interface)
  85
  86
  87 Northbound API Design
  88 =====================
  89
  90 REST API Impact and Base URL
  91 ----------------------------
  92
  93 Similar to other plugins(e.g. openstack plugin), k8s plugin has
  94 its own API endpoint and base URL so that it doesn't affect other
  95 multicloud northbound API.
  96
  97 Base URL for kubernets plugin:
  98
  99 https://msb.onap.org:80/api/multicloud/v0/
 100
 101 NOTE: Each multicloud plugin has its own API endpoint(ip address).
 102 So the plugin is distinguished by endpoint IP address with MSB.
 103 "multicloud-kubernetes" name space for MSB is used.
 104 NOTE: each COE support has its own API end point and name space.
 105 their name spaces will be "multicloud-<coe name>". With model driven
 106 API, we will have API agnostic to COE. in that case the name space
 107 "multicloud-coe" will be used.
 108
 109 cloud-id
 110 --------
 111 In ONAP, cloud-id is the format of <cloudOwner>_<cloudRegion>
 112 Since k8s doesn't have notion of region, cloud admin will assign
 113 unique string it as cloudRegion and it will be used as a part of cloud-id.
 114
 115 APIs for VNF Lifecycle Management
 116 ---------------------------------
 117
 118 * PATH: /<cloud-id>/proxy/<resources>
 119 * METHOD: All methods
 120
 121 Northbound components, e.g. APP-C, use these APIs for lifecycle management of
 122 VNF resources within the Kubernetes cluster, e.g. pods. In essence, these APIs
 123 provide simple proxy (or passthrough) functions with authorization adjustment
 124 to Kubernetes API Server so that the relevant lifecycle management operations
 125 are actually achieved by Kubernetes cluster itself. In another word, these API
 126 requests are proxied to "{kubernetes api prefix}/<resources>" within Kubernetes
 127 cluster without any changes to http/https request body.
 128 the API end point is stored in AA&I and the API consumer will get it from
 129 AA&I.
 130
 131 For details of Kubernetes API, please refer to
 132 https://kubernetes.io/docs/reference/api-overview/
 133
 134 NOTE: kubernetes doesn't have concept of region and tenant at this moment.
 135 So region and tenant_id isn't in path.
 136 NOTE: VF-C is ETSI NFV orchestrater.(NFV-O) In Beijing release, this isn't
 137 addressed because container is out of scope of ETSI NFV at the time of
 138 writing. Post-Beijing, this will be given consideration. First target
 139 is APP-C as it's easier.
 140
 141 API for VNF Deployment
 142 ----------------------
 143
 144 * PATH: /<cloud-id>/package
 145 * METHOD: POST
 146   media type of Content-Type and/or filename of Contest-Disposition are used
 147   to specify package type.
 148
 149   As private media type, application/onap-multicloud-<coe name>-<type> is used.
 150   More concretely for Beijing release the following media types are used.
 151   * Content-Type: application/onap-multicloud-kubernetes-csar
 152   * Content-Type: application/onap-multicloud-kubernetes-helm
 153   As supplement, filename is also used to guess media type. As http header type
 154   Contest-Disposition is used to pass filename.
 155   * Content-Disposition: attachment; filename="fname.tgz"
 156   first media type is tried and then filename is tried. If both are present
 157   media type is used.
 158
 159 This API provides northbound components, e.g. SO, with the function of
 160 deploying containerized VNF package into Kubernetes cluster. The VNF package
 161 is delivered as payload of HTTP request body in the API call. The VNF package
 162 could be a CSAR or Helm Charts.
 163
 164 CSAR deployment package will include a yaml deployment file and other
 165 artifacts.
 166 This approach would work for simple VNFs consisting of single PODs.
 167
 168 For VNFs comprising of multiple PODs which are dependent on each other, Helm
 169 based approach would be used. The VNF package would be described as a Helm
 170 package consisting of a set of Helm charts and k8s yamls for each constituent
 171 service that is part of the VNF.
 172
 173 There would be no change required in the Northboud API from MultiCloud for
 174 either CSAR package or Helm package or any other package in the future. SO
 175 calls this MultiVIM Northbound API and sends the k8s package (e.g. csar, or
 176 tgz) as payload. k8s Plugin will distinguish package types based on its suffix
 177 and interact with k8s cluster appropriately:
 178
 179 * For CSAR: k8s yaml file will be extracted from CSAR. k8s REST API server
 180   will be called to create k8s resources (e.g. pods), which is equivalent to
 181   "kubectl create -f <file.yaml>". The TOSCA file in CSAR is expected to
 182   include onap.multicloud.container.kubernetes.proxy.nodes.resources_yaml
 183   node which is explained below. In another word, Kubernetes yaml is stored as
 184   artifact in CSAR. it is extracted and then it is fed to k8s API.
 185
 186 * For TGZ: call Tiller API (gRPC-based) and pass through the Helm package
 187
 188 The Kubernetes API Server (RESTful) or Helm Tiller Server (gRPC) URLs are
 189 configured for k8s Plugin when the Kubernetes cluster is created and Helm
 190 is installed.
 191
 192 With this single API for package, when we need to add new package
 193 support in the future, no extra code in SO is needed.
 194
 195 swagger.json
 196 ------------
 197
 198 * PATH: swagger.json
 199   swagger.json for kubernetes API definitions
 200 * METHOD: GET
 201
 202 returns swagger.json definitions of k8s API similar to other multicloud plugins
 203
 204 Internal APIs for Implementations
 205 ---------------------------------
 206
 207 Some internal APIs may be needed by the implementation details of above
 208 northbound APIs. For example, when implementing VNF Deployment API above,
 209 we may need internal APIs to assist calling Helm Tiller Server or Kubernetes
 210 API Server, e.g. similar to "kubectl create -f xxx.yaml".
 211
 212 The internal API, if needed, will be handled in implementation, which is out
 213 of scope of this section of the document.
 214
 215 Test plan
 216 ---------
 217
 218 In this section test play is discussed. In Beijing cycle, test is minimal
 219 or stretched goal because the effort in Beijing is PoC/experimental
 220 to get experience. the following class of test would be planned as
 221 stretched goal.
 222
 223 * Unit Test
 224
 225   * API input/output
 226 * functional test
 227
 228   * communication to backend(K8S API server, helm tiller server)
 229 * CSIT as end-to-end test
 230
 231
 232 Register/Unregister Kubernetes Cluster Instance
 233 ===============================================
 234
 235 This is done via A&AI ESR `ESR`_ to follow the way of the existing
 236 multicloud.  some attributes, e.g. region id, don't make sense for
 237 k8s. In that case predefined value, e.g. 'default', are used.
 238 The info for basic authentication, i.e. the pair of (username, password),
 239 against kuberenetes API is registered and stored in A&AI.
 240
 241 NOTE: ESR will call registry API when register a new VIM(k8s). we need to
 242 make sure that we have this API in this plugin and give them response.
 243
 244 NOTE: HPA(kubernetes cluster features/capabilities) is out of scope
 245 for Beijing Assumption K8s cluster instance is already
 246 pre-build/deployed Dynamic instantiation is out of scope(for Beijing)
 247
 248 attributes for A&AI ESR
 249 -----------------------
 250
 251 This subsection describes how attributes for VIM registration are specified.
 252 For actual definitions, please refer to `ESR`_
 253 Some attributes doesn't apply to kubernetes so that such attributes will
 254 be left unspecified if it's optional or define pre-defined constants if
 255 it's mandatory.
 256
 257 URI /api/aai-esr-server/v1/vims
 258 Operation Type  POST
 259
 260 Request Body:
 261
 262 ::
 263
 264   ------------------ ---------- ------- ----------------------------------------
 265   Attribute          Qualifier  Content Description
 266   ================== ========== ======= ========================================
 267   cloudOwner         M          String  any string as cloud owner
 268   ------------------ ---------- ------- ----------------------------------------
 269   cloudRegionId      M          String  e.g. "kubernetes-<N>" as it doesn't apply
 270                                         to k8s. Cloud admin assigns unique id.
 271   ------------------ ---------- ------- ----------------------------------------
 272   cloudType          M          String  "kubernetes". new type
 273   ------------------ ---------- ------- ----------------------------------------
 274   cloudRegionVersion M          String  kubernetes version. "v1.9", "v1.8" ...
 275   ------------------ ---------- ------- ----------------------------------------
 276   ownerDefinedType   O          String  None. (not specified)
 277   ------------------ ---------- ------- ----------------------------------------
 278   cloudZone          O          String  None. (not speicfied)
 279                                         as kubernetes doesn't have notion of
 280                                         zone.
 281   ------------------ ---------- ------- ----------------------------------------
 282   complexName        O          String  None. (not specified)
 283                                         as kubernetes doesn't have notion of
 284                                         complex.
 285   ------------------ ---------- ------- ----------------------------------------
 286   cloudExtraInfo     O          String  json string(dictionary) for necessary
 287                                         info. For now "{}" empty dictionary.
 288                                         For helm support, URL for tiller server
 289                                         is stored.
 290   ------------------ ---------- ------- ----------------------------------------
 291   vimAuthInfos       M          [Obj]   Auth information of Cloud
 292                                         list of authInfoItem which is described
 293                                         below.
 294   ================== ========== ======= ========================================
 295
 296 There are several constraints/assumptions on cloudOwner and
 297 cloudRegionId. `cloud-region`_ . For k8s, cloudRegionId is (ab)used to
 298 specify k8s cluster instance. ONAP admin has to assign unique id for
 299 cloudRegionId as id for k8s cluster instance.
 300
 301 NOTE: complexName: this will be revised post-Beijing. "complex" is used to
 302 specify (latitude, longitude) of a data center location for the purpose of
 303 homing optimization. If those values can be obtained somehow, this should
 304 be populated.
 305
 306 authInfoItem
 307
 308 Basic authentication is used for k8s api server.
 309
 310 ::
 311
 312   -------------- --------- ------- -------------------------------------------
 313   Attribute      Qualifier Content Description
 314   ============== ========= ======= ===========================================
 315   cloudDomain    M         String  "kubernetes" as this doesn't apply.
 316   -------------- --------- ------- -------------------------------------------
 317   userName       M         String  User name
 318   -------------- --------- ------- -------------------------------------------
 319   password       M         String  Password
 320   -------------- --------- ------- -------------------------------------------
 321   authUrl        M         String  URL for kubernetes API server
 322   -------------- --------- ------- -------------------------------------------
 323   sslCacert      O         String  ca file content if enabled ssl on
 324                                   kubernetes API server
 325   -------------- --------- ------- -------------------------------------------
 326   sslInsecure    O         Boolean Whether to verify VIM's certificate
 327   ============== ========= ======= ===========================================
 328
 329 NOTE: For some issues `issue23`_, ESR should provide authenticating by
 330 bearer token for Kubernetes cluster if possible beside basic authentication.
 331 Those extra value will be stored in cloudExtraInfo. This is stretched goal.
 332
 333
 334 On boarding/packaging/instantiation
 335 ===================================
 336
 337 We shouldn't change the current existing work flow.
 338 In short term: Use additional node type/capability types etc.
 339 In longer term way: Follow ONAP community directoin. At the moment, work
 340 with TOSCA community to add additional node type to express k8s.
 341
 342 NOTE: this packaging is temporally work around until ONAP modelling
 343 and multicloud model driven API are available. Post Beijing release
 344 packaging will be revised to follow ONAP modeling and multicloud model
 345 driven API.
 346
 347 Packaging and on-boarding
 348 -------------------------
 349
 350 Reuse CASR so that the existing work flow doesn't need change. For
 351 Beijing CSAR is used with its own TOSCA node definition. In longer
 352 term, once multicloud project has model driven API, it will be followed
 353 to align with modeling and SO.
 354
 355 TOSCA node definitions
 356 -----------------------
 357
 358 Introduce new nodes to wrap k8s ingredients(k8s yaml, helm etc.) These
 359 TOSCA node definitions are short term work around to re-use the existing
 360 component/workflow until model driven API is defined/implemented.
 361 For Beijing, human will write this TOSCA by hands for PoC. Post Beijing,
 362 packaging needs to be revised to align with modeling and SO. Also SDC,
 363 VNF-SDK need to be addressed for creation.
 364
 365 * onap.multicloud.nodes.kubernetes.proxy
 366
 367   * node definitions
 368
 369     ::
 370
 371       data_types:
 372         onap.multicloud.container.kubernetes.proxy.nodes.resources_yaml:
 373         properties:
 374           name:
 375             type: string
 376             description: >
 377               Name of application
 378           path:
 379             type: string
 380             description: >
 381               Paths to kubernetes yaml file
 382
 383 For VNFs that are packages as Helm package there would be only one
 384 TOSCA node in the TOSCA template which would have reference to the
 385 Helm package.
 386
 387 * onap.multicloud.nodes.kubernetes.helm
 388
 389   * node definitions
 390
 391     ::
 392
 393       data_types:
 394         onap.multicloud.container.kubernetes.helm.nodes.helm_package:
 395         properties:
 396           name:
 397             type: string
 398             description: >
 399               Name of application
 400           path:
 401             type: string
 402             description: >
 403               Paths to Helm package file
 404
 405 This TOSCA node definitions wrap kubernetes yaml file or helm chart.
 406 cloudify.nodes.Kubernetes isn't reused in order to avoid definition conflict.
 407
 408 Instantiation
 409 -------------
 410
 411 SO ARIA adaptor can be used. (with twist to have SO to talk to
 412 multicloud k8s plugin instead of ARIA) Instantiation so that SO
 413 can talk to multicloud k8s plugin.
 414 NOTE: This is temporally work around for Beijing release. Post Beijing, this
 415 needs to be revised.
 416
 417 work flow
 418 ---------
 419
 420 With Amsteldam Release, SO has ARIA adaptor which talks to ARIA orchestrator.
 421 https://wiki.onap.org/download/attachments/16002054/Model%20Driven%20Service%20Orchestration%20-%20SO%20State%20of%20the%20Union.pptx
 422
 423 The work flow looks like follows::
 424
 425              user request to instantiate VNF
 426                            |
 427             +--------------|-------+
 428             | SO           |       |
 429             |              V       |
 430             | +------------------+ |
 431             | | SO: ARIA adaptor | |
 432             | +------------+-----+ |
 433             +--------------|-------+
 434                            | CASR is sent
 435                            |
 436             +--------------|---------+
 437             | ARIA         |         |
 438             |              V         |
 439             | +--------------------+ |
 440             | | multicloud  plugin | |   template as TOSCA artifact is
 441             | +------------+-------+ |   extracted and build requests to
 442             +--------------|---------+   multicloud
 443                            |
 444                            |
 445             +--------------|-------+
 446             | multicloud   |       |
 447             |              V       |
 448             | +------------------+ |
 449             | | openstack plugin | |
 450             | +------------+-----+ |
 451             +--------------|-------+
 452                            | openstack request
 453                            |
 454                            V
 455             +----------------------+
 456             | openstack            |
 457             +----------------------+
 458
 459
 460 This will be twisted by configuration so that SO can talks to
 461 multicloud k8s plugin::
 462
 463              user request to instantiate VNF
 464                            |
 465             +--------------|-------+
 466             | SO           |       |
 467             |              V       |
 468             | +------------------+ |
 469             | | SO: ARIA adaptor | |  configuration is twisted to call
 470             | +------------+-----+ |  multicloud k8s API
 471             +--------------|-------+
 472                            | CSAR or TGZ
 473                            |
 474             +--------------|-------+
 475             | multicloud   |       |
 476             |              V       |
 477             | +------------------+ |  handle CSAR or TGZ (Helm Charts) file
 478             | | k8s plugin       | |  e.g. extract k8s yaml from CSAR, and
 479             | +------------+-----+ |  pass through requests to k8s/Helm API
 480             +--------------|-------+
 481                            | k8s/Helm request
 482                            |
 483                            V
 484             +----------------------+
 485             | k8s/Helm API server  |
 486             +----------------------+
 487
 488
 489 NOTE: In this work flow. only the northbound deployment API endpoint is needed
 490 for VNF deployment. LCM APIs are only needed for lifecycle management. Other
 491 internal APIs, e.g. k8s YAML API may be needed only for internal
 492 implementation.
 493
 494 SO ARIA multicloud plugin needs to be twisted to call k8s plugin.
 495
 496 The strategy is to keep the existing design of ONAP or to follow
 497 agreed design.
 498 The key point of The interaction between SO and multicloud is
 499
 500 * SO decomposes VNFD/NSD into single atomic resource
 501   (e.g. VNF-C corresponding to single VM or single container/pod)
 502   and send requests to create each resources via deployment API.
 503 * multicloud accepts each request for single atomic resource and
 504   create single resource(e.g. VM or container/pod)
 505 * multicloud doesn't do resource decomposition. The decomposition is task
 506   of SO.
 507
 508 API work flow example and k8s API
 509 ---------------------------------
 510 * register k8s cluster to A&AI ESR
 511   <cloud-id> is obtained
 512 * ONAP north bound components generates a TOSCA template targeted for k8s.
 513 * SO calls Multicloud deployment API and passes the entire BluePrint(as CSAR or
 514   TGZ) to k8s plugin, e.g.:
 515   POST https://msb.onap.org:80/api/multicloud/v0/<cloud-id>/package
 516 * k8s plugin handles the CSAR or TGZ accordingly and talks to k8s API Server
 517   or Helm Tiller Server to deploy containerized VNF
 518   POST <k8s api server>://api/v1/namespaces/{namespace}/pods
 519   to create pods. then <pod id> is obtained
 520 * DELETE https://msb.onap.org:80/api/multicloud/v0/<cloud-id>/proxy/api/v1/namespaces/{namespace}/pods/<pod id>
 521   to destroy pod
 522 * to execute script inside pod, the following URL can be used.
 523   POST /api/v1/namespaces/{namespace}/pods/{name}/exec
 524
 525
 526 Affected Projects and impact
 527 ============================
 528
 529 A&AI and ESR
 530 ------------
 531 new type to represent k8s/container for cloud infrastructure will
 532 be introduced as work around. Post Beijing official value will be
 533 discussed for inclusion.
 534
 535 OOF
 536 ---
 537 Policy matching is done by OOF.
 538 For Beijing. Enhancement to policy is stretched goal.
 539 Decomposing service design(NSD, VNFD) from VNF package is done by SO
 540 with OOF(homing)
 541
 542 SO
 543 --
 544 ARIA adaptor is re-used with config tweak to avoid modification
 545
 546 multicloud
 547 ----------
 548 new k8s plugin will be introduced. The details are discussed in this
 549 documentation you're reading right now.
 550
 551
 552 Kubernetes cluster authentication
 553 =================================
 554 For details of k8s authentication, please refer to
 555 https://kubernetes.io/docs/admin/authentication
 556
 557 Because Kubernetes cluster installation is not mentioned, we should
 558 treat all users as normal users when authenticate to
 559 Kubernetes VIM. There are several ways to authenticate Kubernetes
 560 cluster. For Beijing release, basic authentication will be supported.
 561 username and password are stored in ESR.
 562
 563
 564 References
 565 ==========
 566 Past presentations/proposals
 567 ----------------------------
 568 .. _Munish proposal: https://schd.ws/hosted_files/onapbeijing2017/dd/Management%20of%20Cloud%20Native%20VNFs%20with%20ONAP%20PA5.pptx
 569 .. _Isaku proposal: https://schd.ws/hosted_files/onapbeijing2017/9d/onap-kubernetes-arch-design-proposal.pdf
 570 .. _Bin Hu proposal: https://wiki.onap.org/download/attachments/16007890/ONAP-SantaClara-BinHu-final.pdf?version=1&modificationDate=1513558701000&api=v2
 571
 572 ONAP components
 573 ---------------
 574 .. _ESR: Extenral System Register https://wiki.onap.org/pages/viewpage.action?pageId=11930343#A&AI:ExternalSystemOperationAPIDefinition-VIM
 575 .. _AAI: Active and Available Inventory https://wiki.onap.org/display/DW/Active+and+Available+Inventory+Project
 576 .. _OOM: ONAP Operations Manager https://wiki.onap.org/display/DW/ONAP+Operations+Manager+Project
 577 .. _ONAPREST: RESTful API Design Specification https://wiki.onap.org/display/DW/RESTful+API+Design+Specification
 578
 579 kubernetes
 580 ----------
 581 .. _kubernetes-python-client: Kubernetes python client https://github.com/kubernetes-client/python
 582
 583 .. _issue23: https://github.com/kubernetes/kubeadm/issues/23
 584
 585 misc
 586 ----
 587 .. _cloud-region: How to add a new cloud region and some thoughts https://wiki.onap.org/download/attachments/25429038/HowToAddNewCloudRegionAndThoughts.pdf
 588
 589
 590 Contributors
 591 ============
 592 * Isaku Yamahata <isaku.yamahata@intel.com> <isaku.yamahata@gmail.com>
 593 * Bin Hu <bh526r@att.com>
 594 * Munish Agarwal <munish.agarwal@ericsson.com>
 595 * Phuoc Hoang <phuoc.hc@dcn.ssu.ac.kr>
 596
 597
 598 APPENDIX
 599 ========
 600 This section is informative. This is out of Beijing scope and will be
 601 revised after Beijing.
 602 The purpose of this appendix is to help readers to understand this
 603 proposal by giving future direction and considerations.
 604 At some point, this appendix will be separated out into its own document
 605 for long-term right design.
 606
 607 Model driven API and kubernetes model
 608 -------------------------------------
 609 Currently the discussion on model driver API is on going. Once it's usable,
 610 it will be followed and the above experimental API/code will be revised.
 611
 612 The eventual work flow looks like as follows::
 613
 614              user request to instantiate VNF/NS
 615                            |
 616                            V
 617             +----------------------+         +-----+
 618             | SO                   |-------->| OOF | <--- policy to use
 619             |                      |<--------|     |      CoE instead of VM
 620             |                      |         +-----+      from A&AI
 621             | +------------------+ |
 622             | | SO: adaptor for  | | SO decomposes VNFD/NSD into atomic
 623             | | multicloud model | | resources(VDUs for VNF-C) with asking OOF
 624             | | driven API       | | for placement. then SO builds up
 625             | +------------+-----+ | requests to multicoud for instantiation.
 626             +--------------|-------+
 627                            |
 628                            |
 629             +--------------|-------+
 630             | multicloud   |       | So multicloud accepts request for single
 631             |              V       | resource of VDU which corresponds to
 632             | +------------------+ | VNF-C. which is mapped to single
 633             | | model driven API | | container/pod. multicloud doesn't
 634             | +------------+-----+ | decompose VDU into multiple containers.
 635             |              |       | CoE doesn't change such work flow.
 636             |              V       |
 637             | +------------------+ |
 638             | | k8s plugin       | | convert request(VDU of VNF-C) into
 639             | +------------+-----+ | kubernetes
 640             +--------------|-------+
 641                            | k8s request
 642                            |
 643                            V
 644             +----------------------+
 645             | kubernetes           |
 646             +----------------------+
 647
 648
 649 Modeling/TOSCA to kubernetes conversion
 650 ---------------------------------------
 651 In this section, conversion from TOSCA to kubernetes is discussed
 652 so that reader can get idea for future direction.
 653
 654 Once ONAP information/data model is usable, similar conversion is possible.
 655 The followings are only examples. More node definitions would be considered
 656 as necessary::
 657
 658   TOSCA node definition        k8s resource
 659   ============================ ================================
 660   tosca.nodes.Compute          (bare)single pod
 661                                vcpu, memory -> k8s resource
 662   ---------------------------- --------------------------------
 663   tosca.nodes.nfv.VDU.Compute  (bare)single pod
 664
 665
 666 Hello world example
 667 -------------------
 668 This is just to show idea.
 669 This example is very early phase and there are hard-coded values.
 670
 671
 672 * TOSCA hello world
 673   ::
 674
 675     topology_template:
 676       node_templates:
 677         my_server:
 678           type: tosca.nodes.Compute
 679           capabilities:
 680             # Host container properties
 681             host:
 682              properties:
 683                num_cpus: 2
 684                disk_size: 10 GB
 685                mem_size: 512 MB
 686             # Guest Operating System properties
 687             os:
 688               properties:
 689                 # host Operating System image properties
 690                 architecture: x86_64
 691                 type: Linux
 692                 distribution: RHEL
 693                 version: 6.5
 694
 695
 696 * converted k8s yaml
 697   ::
 698
 699     $ PYTHONPATH=. python -m tosca_translator.shell -d --debug --template-file tosca_translator/tests/data/tosca_helloworld.yaml
 700     api_version: apps/v1beta1
 701     kind: Deployment
 702     metadata:
 703       labels: {name: my_server}
 704     spec:
 705       replicas: 1
 706       template:
 707         metadata:
 708           labels: {name: my_server}
 709         spec:
 710           containers:
 711           - image: ubuntu
 712             name: my_server
 713             resources:
 714               limits: {cpu: 2, ephemeral-storage: 10 GB, memory: 512 MB}
 715             requests: {cpu: 2, ephemeral-storage: 10 GB, memory: 512 MB}