From: garciadeblas Date: Thu, 12 Nov 2020 14:20:57 +0000 (+0000) Subject: Clean-up of gerrit: move completed features to right release folder X-Git-Url: https://osm.etsi.org/gitweb/?a=commitdiff_plain;h=refs%2Fchanges%2F71%2F9971%2F2;p=osm%2FFeatures.git Clean-up of gerrit: move completed features to right release folder Change-Id: Ib0cea472073f6eb083764cfc55622c0970f4e048 Signed-off-by: garciadeblas --- diff --git a/Release3/Affinity_and_anti-affinity_rules_for_VNF_deployment.md b/Release3/Affinity_and_anti-affinity_rules_for_VNF_deployment.md deleted file mode 100644 index 1ad8038..0000000 --- a/Release3/Affinity_and_anti-affinity_rules_for_VNF_deployment.md +++ /dev/null @@ -1,30 +0,0 @@ -# Affinity and anti-affinity rules for VNF deployment # - -## Proposer ## -- Gerardo Garcia (Telefonica) -- Alfonso Tierno (Telefonica) -- Francisco Javier Ramon (Telefonica) - -## Type ## -**Feature** - -## Target MDG/TF ## -SO, RO - -## Description ## -OSM should provide means to specify that different VDUs of the same VNF should -be deployed in different availability zones of the same datacenter. This -behaviour is often required by VNFs that implement active-standby resiliency -strategies. - -Current OSM’s IM might need to be extended to support this feature. - -## Demo or definition of done ## -- Add a datacenter to OSM specifying more than one availability zone. -- Add a second datacenter with only one zone. -- Onboard a VNF with 2 VDUs, with a VNFD that mandates that these VDUs must be -deployed in different availability zones. -- Onboard an NS which includes the VNF above. -- Instantiate the NS in the datacenter with 2 availability zones and check that -the VDUs are deployed as expected. -- Instantiate the NS in the datacenter with one zone and check that it fails. \ No newline at end of file diff --git a/Release3/Support_of_multi-VDU_VNFs.md b/Release3/Support_of_multi-VDU_VNFs.md deleted file mode 100644 index 38c92d8..0000000 --- a/Release3/Support_of_multi-VDU_VNFs.md +++ /dev/null @@ -1,32 +0,0 @@ -# Support of multi-VDU VNFs # - -## Proposer ## -- Gerardo Garcia (Telefonica) -- Alfonso Tierno (Telefonica) -- Francisco Javier Ramon (Telefonica) - -## Type ## -**Feature** - -## Target MDG/TF ## -SO, VCA - -## Description ## -Many common use cases involve VNFs that are composed of several types of VDUs -that need to be scaled and operated independently but still belong to the same -VNF and, hence, need to be completely described in the VNF Package, not at NS -level. - -Some common examples are composite VNFs -such as IMS or EPC- or simple but -decomposed VNFs, such as a vRouter with control and data plane that are -intended to run in separate VMs. - -## Demo or definition of done ## -- A VNF Package of a VNF composed of more than one type of VDUs (e.g. 2 types -of VNUs: user and data plane) is successfully onboarded in the system. The set -of primitives available is unified at VNF level. -- The VNF is properly deployed, with the VMs interconnected as specified in the -descriptor and the VNF as a whole can be operated with VNF primitives. - -**This feature might obsolete feature #655 _partially_: -https://osm.etsi.org/gerrit/#/c/655/** \ No newline at end of file diff --git a/Release3/vca-async-api.md b/Release3/vca-async-api.md deleted file mode 100644 index a310d2d..0000000 --- a/Release3/vca-async-api.md +++ /dev/null @@ -1,81 +0,0 @@ -# Juju Asyncronous API # - -## Proposer ## -- Adam Israel - -## Type ## -**Feature** - -## Target MDG/TF ## -SO - -## Description ## - -As of R2, the SO is using the older syncronous Juju API. This can lead the SO -to appear "frozen" while it blocks waiting for a Juju operation to complete. - -To address this issue, we would like the SO to convert to using -[libjuju](https://github.com/juju/python-libjuju) python library. It offers -the following benefits: -- Asynchronous, using the asyncio and async/await features of python 3.5+ -- Websocket-level bindings are programmatically generated (indirectly) from the -Juju golang code, ensuring full api coverage -- Provides an OO layer which encapsulates much of the websocket api and -provides familiar nouns and verbs (e.g. Model.deploy(), Application.add_unit(), -etc.) - -## Demo or definition of done ## -Demos of using libjuju can be found in the -[quickstart](https://github.com/juju/python-libjuju#quickstart) and in the -[examples](https://github.com/juju/python-libjuju/tree/master/examples) folder. - -Here is a simple implementation that deploys a charm: -```python -#!/usr/bin/python3.5 - -import asyncio -import logging - -from juju import loop -from juju.model import Model - - -async def deploy(): - # Create a Model instance. We need to connect our Model to a Juju api - # server before we can use it. - model = Model() - - # Connect to the currently active Juju model - await model.connect_current() - - # Deploy a single unit of the ubuntu charm, using revision 0 from the - # stable channel of the Charm Store. - ubuntu_app = await model.deploy( - 'ubuntu-0', - application_name='ubuntu', - series='xenial', - channel='stable', - ) - - # Disconnect from the api server and cleanup. - model.disconnect() - - -def main(): - # Set logging level to debug so we can see verbose output from the - # juju library. - logging.basicConfig(level=logging.DEBUG) - - # Quiet logging from the websocket library. If you want to see - # everything sent over the wire, set this to DEBUG. - ws_logger = logging.getLogger('websockets.protocol') - ws_logger.setLevel(logging.INFO) - - # Run the deploy coroutine in an asyncio event loop, using a helper - # that abstracts loop creation and teardown. - loop.run(deploy()) - - -if __name__ == '__main__': - main() -``` diff --git a/Release3/vca-metrics-collection.md b/Release3/vca-metrics-collection.md deleted file mode 100644 index b3e12ea..0000000 --- a/Release3/vca-metrics-collection.md +++ /dev/null @@ -1,28 +0,0 @@ -# Metrics Collection # - -## Proposer ## -- Adam Israel - -## Type ## -**Feature** - -## Target MDG/TF ## -VCA, DevOps, SO - -## Description ## -Operators prefer to make data-driven decisions. To aid this, I propose that we -begin collecting operational metrics from VNFs that make them available, via -push (collectd, statsd) or pull ([prometheus](https://prometheus.io/), etc). - -This metric data should be collected to a central data store. Once collected, -reports can be generated for the operator to view, and operational rules can be -defined with regard to notifications, auto-scaling and auto-healing. - - -## Demo or definition of done ## -- Selection of supported collection method(s) -- Creation of an OSM VNF METRICS charm layer to aid metrics collection -- The option to install metric collection during the installation process. -- Exposing a metrics dashboard (if supported by the supported collection - method(s), or the definition of of one or more reports to view relevant - metrics dtaa. diff --git a/Release4/K8_Support.md b/Release4/K8_Support.md deleted file mode 100644 index 4c7e662..0000000 --- a/Release4/K8_Support.md +++ /dev/null @@ -1,71 +0,0 @@ -# OSM Kubernetes Support # - -## Proposer ## -- Prithiv Mohan (Intel) - -## Type ## -** Feature ** - -## Target MDG/TF ## -SO, RO, VCA, IM - -## Supported VIMs ## - -1. OpenStack -2. VMWare -3. AWS - -## Description ## - -Enable a container-based VNF deployment model via OSM that allows for the coexistence of container -and VM deployment models to coexist within a network service. Kubernetes should be enabled as the -container orchestration engine, but it must be done in a plugin manner that permits other container -orchestration engines to be added in the future. - -The Kubernetes pods can be created either on a baremetal node or inside a VM. Either case, the -Resource Orchestrator(RO) is responsible only for the resource allocation. - -For the VM based Kubernetes deployment, the VM image could have the kubelet node agent already -installed. In this case, RO creates a VM and VCA takes care of the configuration and the LCM of the -pods. If the image used by the RO to provide a VM has no kubelet installation, the VCA module will -handle the installation, configuration of the kubernetes. The Resource Orchestrator will not involve -in the installation of any kind of Kubernetes package. - -The options for baremetal provisioning includes OpenStack Ironic, Canonical Metal as a Service(MaaS) -but not limited to that. An additional or extended plugin is required in the Resource Orchestrator -for the baremetal provisioning of the resources for the Kubernetes. - -The proposed workflow below assumes Ironic/MaaS as the options for baremetal provisioning: - - i. User creating a descriptor with VNFD updates that indicate the deployment model for the - VNF (container on bare metal, container in VM, or VM deployment. - ii. SO passes the request to RO. - iii. RO receives the request. - iv a. In case of a Kubernetes deployment inside the VM, RO creates a VM with/without kubelet - installed in it based on the type of the image. - b. Alternatively, in the case of a Kubernetes baremetal deployment, RO communicates with - the MaaS/Ironic plugin. The plugin talks to the MaaS and/or Ironic to create the - Kubernetes pods. - v. VCA does the installation and/or configuration of the VM for Kubernetes. - -Changes in the descriptor in the IM repo is required. Expected these show up fairly seamlessly in -the UI due to the model driven nature of the platform. - -There is an option on the preparation of the baremetal nodes or VMs for supporting Kubernetes. These -could be prepared beforehand, or Kubernetes could be configured on them once they have been -allocated. - -The installation of Kubernetes and the configuration of the Kubernetes Controller will not be handled -by the OSM as it is out of scope for OSM. The configuration could be handled by Juju with the charms. - -## Demo or definition of done ## - -* Creation of Kubernetes Pods is successful -* Usual lifecycle operations on a NS that includes VM-based and container-in-VM based VNFs. -* Supports multiple VIM environments. - -Links: - -1. https://kubernetes.io/ -2. https://kubernetes.io/docs/getting-started-guides/ubuntu/installation/ -3. https://www.ubuntu.com/kubernetes diff --git a/Release5/Affinity_and_anti-affinity_rules_for_VNF_deployment.md b/Release5/Affinity_and_anti-affinity_rules_for_VNF_deployment.md new file mode 100644 index 0000000..1ad8038 --- /dev/null +++ b/Release5/Affinity_and_anti-affinity_rules_for_VNF_deployment.md @@ -0,0 +1,30 @@ +# Affinity and anti-affinity rules for VNF deployment # + +## Proposer ## +- Gerardo Garcia (Telefonica) +- Alfonso Tierno (Telefonica) +- Francisco Javier Ramon (Telefonica) + +## Type ## +**Feature** + +## Target MDG/TF ## +SO, RO + +## Description ## +OSM should provide means to specify that different VDUs of the same VNF should +be deployed in different availability zones of the same datacenter. This +behaviour is often required by VNFs that implement active-standby resiliency +strategies. + +Current OSM’s IM might need to be extended to support this feature. + +## Demo or definition of done ## +- Add a datacenter to OSM specifying more than one availability zone. +- Add a second datacenter with only one zone. +- Onboard a VNF with 2 VDUs, with a VNFD that mandates that these VDUs must be +deployed in different availability zones. +- Onboard an NS which includes the VNF above. +- Instantiate the NS in the datacenter with 2 availability zones and check that +the VDUs are deployed as expected. +- Instantiate the NS in the datacenter with one zone and check that it fails. \ No newline at end of file diff --git a/Release5/Support_of_multi-VDU_VNFs.md b/Release5/Support_of_multi-VDU_VNFs.md new file mode 100644 index 0000000..38c92d8 --- /dev/null +++ b/Release5/Support_of_multi-VDU_VNFs.md @@ -0,0 +1,32 @@ +# Support of multi-VDU VNFs # + +## Proposer ## +- Gerardo Garcia (Telefonica) +- Alfonso Tierno (Telefonica) +- Francisco Javier Ramon (Telefonica) + +## Type ## +**Feature** + +## Target MDG/TF ## +SO, VCA + +## Description ## +Many common use cases involve VNFs that are composed of several types of VDUs +that need to be scaled and operated independently but still belong to the same +VNF and, hence, need to be completely described in the VNF Package, not at NS +level. + +Some common examples are composite VNFs -such as IMS or EPC- or simple but +decomposed VNFs, such as a vRouter with control and data plane that are +intended to run in separate VMs. + +## Demo or definition of done ## +- A VNF Package of a VNF composed of more than one type of VDUs (e.g. 2 types +of VNUs: user and data plane) is successfully onboarded in the system. The set +of primitives available is unified at VNF level. +- The VNF is properly deployed, with the VMs interconnected as specified in the +descriptor and the VNF as a whole can be operated with VNF primitives. + +**This feature might obsolete feature #655 _partially_: +https://osm.etsi.org/gerrit/#/c/655/** \ No newline at end of file diff --git a/Release5/Support_of_multi-segment_VIM-managed_networks.md b/Release5/Support_of_multi-segment_VIM-managed_networks.md deleted file mode 100644 index 93839d7..0000000 --- a/Release5/Support_of_multi-segment_VIM-managed_networks.md +++ /dev/null @@ -1,44 +0,0 @@ -# Support of multi-segment VIM-managed networks # - -## Proposer ## -- Gerardo Garcia (Telefonica) -- Alfonso Tierno (Telefonica) -- Francisco Javier Ramon (Telefonica) - -## Type ## -**Feature** - -## Target MDG/TF ## -RO - -## Description ## -A VIM, with the help of an SDN controller, can allow the creation of -multi-segment networks that enables seamless connectivity between legacy VLAN -domains (e.g. external networks aka provider networks), SR-IOV or Passthrough -interfaces, and VIRTIO interfaces. - -This can be done, for instance, by deploying a VXLAN gateway on the physical -switches, which must support VXLAN encapsulation and HWVTEP functionality. The -gateway would be created by the SDN controller, which is controlled by the VIM. -In the case of Openstack, network configuration is performed using neutron’s -multi-segment networks and the L2GW service plugin. - -This feature will modify the way networks are created in a VIM, assuming that -the VIM supports multi-segment networks. There are three cases: -1. Networks where only VIRTIO interfaces are connected -2. Networks where only dataplane interfaces (SR-IOV or passthrough) are -connected -3. Networks where a mix of VIRTIO and dataplane interfaces are connected - -In case 1, it is foreseen that the network is created as a single-segment -network. In cases 2 and 3, it is foreseen that the network will be created as -multi-segment network. The reason is that VLAN identifiers are a scarce -resource, while VXLAN Network Identifiers are not. Allocating a VLAN for case 1 -could imply running out of VLANs very quickly, since networks for case 1 are -typical for cloud application workloads. - -In cases 2 and 3, it is foreseen that it would be possible to connect, a -posteriori, new elements to the already created multi-segment networks. - -## Demo or definition of done ## -To be added. diff --git a/Release5/detection_of_vim_events_not_directly_related_to_VDU_infra_metrics.md b/Release5/detection_of_vim_events_not_directly_related_to_VDU_infra_metrics.md deleted file mode 100644 index a83a1a2..0000000 --- a/Release5/detection_of_vim_events_not_directly_related_to_VDU_infra_metrics.md +++ /dev/null @@ -1,28 +0,0 @@ -# Detection of VIM events not directly related to VDU infra metrics # - -## Proposer ## -- Gianpietro Lavado (Whitestack) - -## Type ## -**Feature** - -## Target MDG/TF ## -MON - -## Description ## - -Detection of VIM events not directly related to VDU infra metrics (broken VMs, -links/networks down, etc.) - -OSM should be able to detect the following VIM events: -1. VM state change (shutdown, pause, not present, etc.) -2. Network changes (deletion, disconnection, etc.) -3. Volume changes (detachments, deletion, etc.) -4. VIM status (API connectivity) - -## Demo or definition of done ## -The following events should make MON throw a log related to the NS, and event in bus. -- A VM is powered down at the VIM interface. -- A network is disconnected from a VDU. -- A volume is detached from a VDU. -- The VIM API is not available. diff --git a/Release5/vca-metrics-collection.md b/Release5/vca-metrics-collection.md new file mode 100644 index 0000000..b3e12ea --- /dev/null +++ b/Release5/vca-metrics-collection.md @@ -0,0 +1,28 @@ +# Metrics Collection # + +## Proposer ## +- Adam Israel + +## Type ## +**Feature** + +## Target MDG/TF ## +VCA, DevOps, SO + +## Description ## +Operators prefer to make data-driven decisions. To aid this, I propose that we +begin collecting operational metrics from VNFs that make them available, via +push (collectd, statsd) or pull ([prometheus](https://prometheus.io/), etc). + +This metric data should be collected to a central data store. Once collected, +reports can be generated for the operator to view, and operational rules can be +defined with regard to notifications, auto-scaling and auto-healing. + + +## Demo or definition of done ## +- Selection of supported collection method(s) +- Creation of an OSM VNF METRICS charm layer to aid metrics collection +- The option to install metric collection during the installation process. +- Exposing a metrics dashboard (if supported by the supported collection + method(s), or the definition of of one or more reports to view relevant + metrics dtaa. diff --git a/Release6/Ability to provide real-time feedback.md b/Release6/Ability to provide real-time feedback.md deleted file mode 100644 index 3b9dd50..0000000 --- a/Release6/Ability to provide real-time feedback.md +++ /dev/null @@ -1,53 +0,0 @@ -# Ability to provide real-time feedback in CLI and GUI upon request - -## Proposer - -- Gerardo Garcia (Telefonica) -- Alfonso Tierno (Telefonica) -- Francisco Javier Ramon (Telefonica) - -## Type - -**Feature** - -## Target MDG/TF - -IM-NBI, LCM, CLI, LW-GUI (optional) - -## Description - -Currently, OSM's CLI (and OSM's GUI to some extent) follow a similar behaviour -to OSM's NBI, returning control to the user immediately after a request has -been made, although OSM is still being processed by OSM behind the scenes, so -the user needs to poll the system to learn (i.e. running commands) when the -request has been completely processed. While this behaviour is reasonable as -regular practice, it still presents some limitations in terms of usability: - -- It makes more complicated to follow the progress of a given operation or -whether it is stuck at any step, particularly when the requested operation is -complex (e.g. instantiate a large NS). -- It makes even more complicated to relate the processes during the operation -with other asynchronous events (e.g. error messages) that may happen during the -operation and explain better its progress and/or results. - -The current proposal is adding an option `--wait` to selected CLI commands so -that they do not return the control immediately, but keep it until the -operation is completed, reporting meanwhile the progress in the operation and, -if appropriate, relevant events that may facilitate diagnosis/troubleshooting. - -As a minimum, the commands for NS instantiation and NST instantiation should -support this option. Likewise, LW-GUI might support the same mode for -equivalent operations. - -## Demo or definition of done - -Possibility to use the `--wait` option for an NS/NSI creation that keeps -control and reports the progress of the operation in terms of: - -- VMs/VDUs created, VLs created and bar of progress (e.g. "VM 7/24: 'CTRL_1' -VDU of 'Router_7' VNF created"). -- Stage of instantiation where the process is (e.g. "starting NS day-1", -"Starting 'Router_2' day-1", etc. ). -- Timely report any other relevant event that might occur in the middle of the -operation. - diff --git a/Release6/Support_of_multi-segment_VIM-managed_networks.md b/Release6/Support_of_multi-segment_VIM-managed_networks.md new file mode 100644 index 0000000..93839d7 --- /dev/null +++ b/Release6/Support_of_multi-segment_VIM-managed_networks.md @@ -0,0 +1,44 @@ +# Support of multi-segment VIM-managed networks # + +## Proposer ## +- Gerardo Garcia (Telefonica) +- Alfonso Tierno (Telefonica) +- Francisco Javier Ramon (Telefonica) + +## Type ## +**Feature** + +## Target MDG/TF ## +RO + +## Description ## +A VIM, with the help of an SDN controller, can allow the creation of +multi-segment networks that enables seamless connectivity between legacy VLAN +domains (e.g. external networks aka provider networks), SR-IOV or Passthrough +interfaces, and VIRTIO interfaces. + +This can be done, for instance, by deploying a VXLAN gateway on the physical +switches, which must support VXLAN encapsulation and HWVTEP functionality. The +gateway would be created by the SDN controller, which is controlled by the VIM. +In the case of Openstack, network configuration is performed using neutron’s +multi-segment networks and the L2GW service plugin. + +This feature will modify the way networks are created in a VIM, assuming that +the VIM supports multi-segment networks. There are three cases: +1. Networks where only VIRTIO interfaces are connected +2. Networks where only dataplane interfaces (SR-IOV or passthrough) are +connected +3. Networks where a mix of VIRTIO and dataplane interfaces are connected + +In case 1, it is foreseen that the network is created as a single-segment +network. In cases 2 and 3, it is foreseen that the network will be created as +multi-segment network. The reason is that VLAN identifiers are a scarce +resource, while VXLAN Network Identifiers are not. Allocating a VLAN for case 1 +could imply running out of VLANs very quickly, since networks for case 1 are +typical for cloud application workloads. + +In cases 2 and 3, it is foreseen that it would be possible to connect, a +posteriori, new elements to the already created multi-segment networks. + +## Demo or definition of done ## +To be added. diff --git a/Release6/detection_of_vim_events_not_directly_related_to_VDU_infra_metrics.md b/Release6/detection_of_vim_events_not_directly_related_to_VDU_infra_metrics.md new file mode 100644 index 0000000..a83a1a2 --- /dev/null +++ b/Release6/detection_of_vim_events_not_directly_related_to_VDU_infra_metrics.md @@ -0,0 +1,28 @@ +# Detection of VIM events not directly related to VDU infra metrics # + +## Proposer ## +- Gianpietro Lavado (Whitestack) + +## Type ## +**Feature** + +## Target MDG/TF ## +MON + +## Description ## + +Detection of VIM events not directly related to VDU infra metrics (broken VMs, +links/networks down, etc.) + +OSM should be able to detect the following VIM events: +1. VM state change (shutdown, pause, not present, etc.) +2. Network changes (deletion, disconnection, etc.) +3. Volume changes (detachments, deletion, etc.) +4. VIM status (API connectivity) + +## Demo or definition of done ## +The following events should make MON throw a log related to the NS, and event in bus. +- A VM is powered down at the VIM interface. +- A network is disconnected from a VDU. +- A volume is detached from a VDU. +- The VIM API is not available. diff --git a/Release6/interoperability_with_azure_public_clouds.md b/Release6/interoperability_with_azure_public_clouds.md deleted file mode 100644 index e8dae30..0000000 --- a/Release6/interoperability_with_azure_public_clouds.md +++ /dev/null @@ -1,30 +0,0 @@ -# Interoperability with Azure public clouds # - -## Proposer ## -- Alfonso Tierno (Telefonica) -- Gerardo Garcia (Telefonica) -- Francisco Javier Ramon (Telefonica) - -## Type ## - -**Feature** - -## Target MDG/TF ## - -RO - -## Description ## - -Currently OSM can deploy VNFs in VIMs of the following types: VMware, -Openstack, Openvim and AWS. -With this feature the public cloud portfolio will be extended to Azure. -This will ease the adoption and testing of OSM. Azure public clouds -could be part of multi-site deployments in production. - -In practice, this feature would require interacting with Azure, in a -similar way as it is done with AWS. - -## Demo or definition of done ## - -Deploy a NSD example with at lease one VM and one private network at public -cloud Azure diff --git a/Release6/vca-async-api.md b/Release6/vca-async-api.md new file mode 100644 index 0000000..a310d2d --- /dev/null +++ b/Release6/vca-async-api.md @@ -0,0 +1,81 @@ +# Juju Asyncronous API # + +## Proposer ## +- Adam Israel + +## Type ## +**Feature** + +## Target MDG/TF ## +SO + +## Description ## + +As of R2, the SO is using the older syncronous Juju API. This can lead the SO +to appear "frozen" while it blocks waiting for a Juju operation to complete. + +To address this issue, we would like the SO to convert to using +[libjuju](https://github.com/juju/python-libjuju) python library. It offers +the following benefits: +- Asynchronous, using the asyncio and async/await features of python 3.5+ +- Websocket-level bindings are programmatically generated (indirectly) from the +Juju golang code, ensuring full api coverage +- Provides an OO layer which encapsulates much of the websocket api and +provides familiar nouns and verbs (e.g. Model.deploy(), Application.add_unit(), +etc.) + +## Demo or definition of done ## +Demos of using libjuju can be found in the +[quickstart](https://github.com/juju/python-libjuju#quickstart) and in the +[examples](https://github.com/juju/python-libjuju/tree/master/examples) folder. + +Here is a simple implementation that deploys a charm: +```python +#!/usr/bin/python3.5 + +import asyncio +import logging + +from juju import loop +from juju.model import Model + + +async def deploy(): + # Create a Model instance. We need to connect our Model to a Juju api + # server before we can use it. + model = Model() + + # Connect to the currently active Juju model + await model.connect_current() + + # Deploy a single unit of the ubuntu charm, using revision 0 from the + # stable channel of the Charm Store. + ubuntu_app = await model.deploy( + 'ubuntu-0', + application_name='ubuntu', + series='xenial', + channel='stable', + ) + + # Disconnect from the api server and cleanup. + model.disconnect() + + +def main(): + # Set logging level to debug so we can see verbose output from the + # juju library. + logging.basicConfig(level=logging.DEBUG) + + # Quiet logging from the websocket library. If you want to see + # everything sent over the wire, set this to DEBUG. + ws_logger = logging.getLogger('websockets.protocol') + ws_logger.setLevel(logging.INFO) + + # Run the deploy coroutine in an asyncio event loop, using a helper + # that abstracts loop creation and teardown. + loop.run(deploy()) + + +if __name__ == '__main__': + main() +``` diff --git a/Release7/Ability to provide real-time feedback.md b/Release7/Ability to provide real-time feedback.md new file mode 100644 index 0000000..3b9dd50 --- /dev/null +++ b/Release7/Ability to provide real-time feedback.md @@ -0,0 +1,53 @@ +# Ability to provide real-time feedback in CLI and GUI upon request + +## Proposer + +- Gerardo Garcia (Telefonica) +- Alfonso Tierno (Telefonica) +- Francisco Javier Ramon (Telefonica) + +## Type + +**Feature** + +## Target MDG/TF + +IM-NBI, LCM, CLI, LW-GUI (optional) + +## Description + +Currently, OSM's CLI (and OSM's GUI to some extent) follow a similar behaviour +to OSM's NBI, returning control to the user immediately after a request has +been made, although OSM is still being processed by OSM behind the scenes, so +the user needs to poll the system to learn (i.e. running commands) when the +request has been completely processed. While this behaviour is reasonable as +regular practice, it still presents some limitations in terms of usability: + +- It makes more complicated to follow the progress of a given operation or +whether it is stuck at any step, particularly when the requested operation is +complex (e.g. instantiate a large NS). +- It makes even more complicated to relate the processes during the operation +with other asynchronous events (e.g. error messages) that may happen during the +operation and explain better its progress and/or results. + +The current proposal is adding an option `--wait` to selected CLI commands so +that they do not return the control immediately, but keep it until the +operation is completed, reporting meanwhile the progress in the operation and, +if appropriate, relevant events that may facilitate diagnosis/troubleshooting. + +As a minimum, the commands for NS instantiation and NST instantiation should +support this option. Likewise, LW-GUI might support the same mode for +equivalent operations. + +## Demo or definition of done + +Possibility to use the `--wait` option for an NS/NSI creation that keeps +control and reports the progress of the operation in terms of: + +- VMs/VDUs created, VLs created and bar of progress (e.g. "VM 7/24: 'CTRL_1' +VDU of 'Router_7' VNF created"). +- Stage of instantiation where the process is (e.g. "starting NS day-1", +"Starting 'Router_2' day-1", etc. ). +- Timely report any other relevant event that might occur in the middle of the +operation. + diff --git a/Release7/K8_Support.md b/Release7/K8_Support.md new file mode 100644 index 0000000..4c7e662 --- /dev/null +++ b/Release7/K8_Support.md @@ -0,0 +1,71 @@ +# OSM Kubernetes Support # + +## Proposer ## +- Prithiv Mohan (Intel) + +## Type ## +** Feature ** + +## Target MDG/TF ## +SO, RO, VCA, IM + +## Supported VIMs ## + +1. OpenStack +2. VMWare +3. AWS + +## Description ## + +Enable a container-based VNF deployment model via OSM that allows for the coexistence of container +and VM deployment models to coexist within a network service. Kubernetes should be enabled as the +container orchestration engine, but it must be done in a plugin manner that permits other container +orchestration engines to be added in the future. + +The Kubernetes pods can be created either on a baremetal node or inside a VM. Either case, the +Resource Orchestrator(RO) is responsible only for the resource allocation. + +For the VM based Kubernetes deployment, the VM image could have the kubelet node agent already +installed. In this case, RO creates a VM and VCA takes care of the configuration and the LCM of the +pods. If the image used by the RO to provide a VM has no kubelet installation, the VCA module will +handle the installation, configuration of the kubernetes. The Resource Orchestrator will not involve +in the installation of any kind of Kubernetes package. + +The options for baremetal provisioning includes OpenStack Ironic, Canonical Metal as a Service(MaaS) +but not limited to that. An additional or extended plugin is required in the Resource Orchestrator +for the baremetal provisioning of the resources for the Kubernetes. + +The proposed workflow below assumes Ironic/MaaS as the options for baremetal provisioning: + + i. User creating a descriptor with VNFD updates that indicate the deployment model for the + VNF (container on bare metal, container in VM, or VM deployment. + ii. SO passes the request to RO. + iii. RO receives the request. + iv a. In case of a Kubernetes deployment inside the VM, RO creates a VM with/without kubelet + installed in it based on the type of the image. + b. Alternatively, in the case of a Kubernetes baremetal deployment, RO communicates with + the MaaS/Ironic plugin. The plugin talks to the MaaS and/or Ironic to create the + Kubernetes pods. + v. VCA does the installation and/or configuration of the VM for Kubernetes. + +Changes in the descriptor in the IM repo is required. Expected these show up fairly seamlessly in +the UI due to the model driven nature of the platform. + +There is an option on the preparation of the baremetal nodes or VMs for supporting Kubernetes. These +could be prepared beforehand, or Kubernetes could be configured on them once they have been +allocated. + +The installation of Kubernetes and the configuration of the Kubernetes Controller will not be handled +by the OSM as it is out of scope for OSM. The configuration could be handled by Juju with the charms. + +## Demo or definition of done ## + +* Creation of Kubernetes Pods is successful +* Usual lifecycle operations on a NS that includes VM-based and container-in-VM based VNFs. +* Supports multiple VIM environments. + +Links: + +1. https://kubernetes.io/ +2. https://kubernetes.io/docs/getting-started-guides/ubuntu/installation/ +3. https://www.ubuntu.com/kubernetes diff --git a/Release7/Support_of_multiple_VCA_instances_and_a_platform-independent_API_in_N2VC.md b/Release7/Support_of_multiple_VCA_instances_and_a_platform-independent_API_in_N2VC.md new file mode 100644 index 0000000..0f83787 --- /dev/null +++ b/Release7/Support_of_multiple_VCA_instances_and_a_platform-independent_API_in_N2VC.md @@ -0,0 +1,66 @@ +# Support of multiple VCA instances and a platform-independent API in N2VC + +## Proposers + +- Gerardo Garcia (Telefonica) +- Alfonso Tierno (Telefonica) +- Francisco Javier Ramon (Telefonica) +- Adam Israel (Canonical) +- José Antonio Quiles (Indra) + +## Type + +Feature + +## Target MDG/TF + +N2VC, LCM + +## Description + +Currently, OSM assumes that management networks of all the VNF instances are remotely accessible +by OSM from outside the datacenter, either directly or via floating IPs, so that VCA can drive +successfully its operations with the VNFs. While this way of work has many advantages in telco +clouds it might be somewhat rigid in hybrid deployments where e.g. public clouds are involved. In +fact, this imposes some networking conditions to OSM so that VCA can access to all the +management networks of each target VIM. + +In addition, the current N2VC library is platform-dependent. Most of the API calls are juju-specific +instead of providing a higher level interface. + +While this shouldn't be an issue from the point of view of the actual behaviour of the OSM platform +as a whole, it has three main drawbacks: + +- Architecturally speaking, it breaks the general principles of abstraction and layering, percolating + terminology and way of thinking northbound. +- It complicates the implementation of features in LCM, since LCM needs to understand all the internals + of each call and figure out the actual state of N2VC and VCA internals. +- It locks the workflow in LCM, which cannot be modified without changing N2VC. As a result, almost + every new feature impacting N2VC (support of native charms, secure key management, support of + relations, NS primitives) forces to change in the workflow in LCM, as current workflows are entirely + VCA-oriented (rather than LCM-oriented) due to the aforementioned problem in layering. + +This feature is intended to re-define the N2VC API to restore the layering, make it truly +platform-independent (agnostic of the VCA terminology), and able to support multiple VCA instances. +It will require the implementation of a generic class in N2VC, defining those API calls and the +expected behaviour. + +The main premises of the new N2VC API would be the following: + +- **High-level abstraction API.** The current platform-dependent objects managed by N2VC (machines, + charms, models, applications) will be replaced by a new set of generic platform-independent objects + (execution environment, configuration SW, namespaces). +- Keep a decoupling among the elements to be configured, the configuration SW and the execution + environment, so that the workflows in current VCA can be reproduced. +- **API calls should be defined in such a way that allows to do things in parallel.** For instance, it + is not necessary to wait for the RO to finish the instantiation to before makeing VCA to create the + execution environments, or vice-versa. +- **Layering and isolation.** LCM workflow (sequence of N2VC calls) could change in the future and it + should not impact N2VC or vice-versa. +- **Transparency in progress of operation and states.** N2VC should be able to update directly the Mongo + records associated to the operation in progress. + +## Demo or definition of done + +All DEVOPS tests using VNF/NS packages with charms should work in the same way as they are working today. + diff --git a/Release7/interoperability_with_azure_public_clouds.md b/Release7/interoperability_with_azure_public_clouds.md new file mode 100644 index 0000000..e8dae30 --- /dev/null +++ b/Release7/interoperability_with_azure_public_clouds.md @@ -0,0 +1,30 @@ +# Interoperability with Azure public clouds # + +## Proposer ## +- Alfonso Tierno (Telefonica) +- Gerardo Garcia (Telefonica) +- Francisco Javier Ramon (Telefonica) + +## Type ## + +**Feature** + +## Target MDG/TF ## + +RO + +## Description ## + +Currently OSM can deploy VNFs in VIMs of the following types: VMware, +Openstack, Openvim and AWS. +With this feature the public cloud portfolio will be extended to Azure. +This will ease the adoption and testing of OSM. Azure public clouds +could be part of multi-site deployments in production. + +In practice, this feature would require interacting with Azure, in a +similar way as it is done with AWS. + +## Demo or definition of done ## + +Deploy a NSD example with at lease one VM and one private network at public +cloud Azure diff --git a/Release7/osmclient_migration_to_Python3.md b/Release7/osmclient_migration_to_Python3.md new file mode 100644 index 0000000..78b1074 --- /dev/null +++ b/Release7/osmclient_migration_to_Python3.md @@ -0,0 +1,26 @@ +# Osmclient migration to Python3 + +## Proposers + +- Gerardo Garcia (Telefonica) +- Alfonso Tierno (Telefonica) +- Francisco Javier Ramon (Telefonica) + +## Type + +Feature + +## Target MDG/TF + +Devops + +## Description + +Python 2 End of Life is expected for January 1st 2020. We need to address +the migration to Python3 before that date. + +## Demo or definition of done + +- A new debian package will be produced: python3-osmclient +- The new debian package will be used by the osmclient Dockerfile in Devops stage3. + diff --git a/Release7/osmclient_package_tool.md b/Release7/osmclient_package_tool.md new file mode 100644 index 0000000..9567886 --- /dev/null +++ b/Release7/osmclient_package_tool.md @@ -0,0 +1,30 @@ +# osmclient package creation and validation tool + +## Proposers + +- Felipe Vicens (ATOS) +- Gerardo Garcia (Telefonica) +- Francisco Javier Ramon (Telefonica) + +## Type + +Feature + +## Target MDG/TF + +Devops/osmclient + +## Description + +The creation of the package in OSM currently is made via a DevOps package tool located in DevOps repository. +This feature aims the migration of the bash script to the osmclient in order to have it integrated with +the osm command-line tool. Additionally, this feature proposes the syntax validation of the descriptors as well as +the generation of the tar.gz + +## Demo or definition of done + +The execution of the following commands using the OSM client to create, validate or build descriptors + +- 'osm package-create': Creates an OSM package for nsd, vnfd and nst +- 'osm package-validate': Syntax validation of OSM descriptors +- 'osm package-build': Generate .tar.gz files of nsd and vnfd diff --git a/Support_of_multiple_VCA_instances_and_a_platform-independent_API_in_N2VC.md b/Support_of_multiple_VCA_instances_and_a_platform-independent_API_in_N2VC.md deleted file mode 100644 index 0f83787..0000000 --- a/Support_of_multiple_VCA_instances_and_a_platform-independent_API_in_N2VC.md +++ /dev/null @@ -1,66 +0,0 @@ -# Support of multiple VCA instances and a platform-independent API in N2VC - -## Proposers - -- Gerardo Garcia (Telefonica) -- Alfonso Tierno (Telefonica) -- Francisco Javier Ramon (Telefonica) -- Adam Israel (Canonical) -- José Antonio Quiles (Indra) - -## Type - -Feature - -## Target MDG/TF - -N2VC, LCM - -## Description - -Currently, OSM assumes that management networks of all the VNF instances are remotely accessible -by OSM from outside the datacenter, either directly or via floating IPs, so that VCA can drive -successfully its operations with the VNFs. While this way of work has many advantages in telco -clouds it might be somewhat rigid in hybrid deployments where e.g. public clouds are involved. In -fact, this imposes some networking conditions to OSM so that VCA can access to all the -management networks of each target VIM. - -In addition, the current N2VC library is platform-dependent. Most of the API calls are juju-specific -instead of providing a higher level interface. - -While this shouldn't be an issue from the point of view of the actual behaviour of the OSM platform -as a whole, it has three main drawbacks: - -- Architecturally speaking, it breaks the general principles of abstraction and layering, percolating - terminology and way of thinking northbound. -- It complicates the implementation of features in LCM, since LCM needs to understand all the internals - of each call and figure out the actual state of N2VC and VCA internals. -- It locks the workflow in LCM, which cannot be modified without changing N2VC. As a result, almost - every new feature impacting N2VC (support of native charms, secure key management, support of - relations, NS primitives) forces to change in the workflow in LCM, as current workflows are entirely - VCA-oriented (rather than LCM-oriented) due to the aforementioned problem in layering. - -This feature is intended to re-define the N2VC API to restore the layering, make it truly -platform-independent (agnostic of the VCA terminology), and able to support multiple VCA instances. -It will require the implementation of a generic class in N2VC, defining those API calls and the -expected behaviour. - -The main premises of the new N2VC API would be the following: - -- **High-level abstraction API.** The current platform-dependent objects managed by N2VC (machines, - charms, models, applications) will be replaced by a new set of generic platform-independent objects - (execution environment, configuration SW, namespaces). -- Keep a decoupling among the elements to be configured, the configuration SW and the execution - environment, so that the workflows in current VCA can be reproduced. -- **API calls should be defined in such a way that allows to do things in parallel.** For instance, it - is not necessary to wait for the RO to finish the instantiation to before makeing VCA to create the - execution environments, or vice-versa. -- **Layering and isolation.** LCM workflow (sequence of N2VC calls) could change in the future and it - should not impact N2VC or vice-versa. -- **Transparency in progress of operation and states.** N2VC should be able to update directly the Mongo - records associated to the operation in progress. - -## Demo or definition of done - -All DEVOPS tests using VNF/NS packages with charms should work in the same way as they are working today. - diff --git a/osmclient_migration_to_Python3.md b/osmclient_migration_to_Python3.md deleted file mode 100644 index 78b1074..0000000 --- a/osmclient_migration_to_Python3.md +++ /dev/null @@ -1,26 +0,0 @@ -# Osmclient migration to Python3 - -## Proposers - -- Gerardo Garcia (Telefonica) -- Alfonso Tierno (Telefonica) -- Francisco Javier Ramon (Telefonica) - -## Type - -Feature - -## Target MDG/TF - -Devops - -## Description - -Python 2 End of Life is expected for January 1st 2020. We need to address -the migration to Python3 before that date. - -## Demo or definition of done - -- A new debian package will be produced: python3-osmclient -- The new debian package will be used by the osmclient Dockerfile in Devops stage3. - diff --git a/osmclient_package_tool.md b/osmclient_package_tool.md deleted file mode 100644 index 9567886..0000000 --- a/osmclient_package_tool.md +++ /dev/null @@ -1,30 +0,0 @@ -# osmclient package creation and validation tool - -## Proposers - -- Felipe Vicens (ATOS) -- Gerardo Garcia (Telefonica) -- Francisco Javier Ramon (Telefonica) - -## Type - -Feature - -## Target MDG/TF - -Devops/osmclient - -## Description - -The creation of the package in OSM currently is made via a DevOps package tool located in DevOps repository. -This feature aims the migration of the bash script to the osmclient in order to have it integrated with -the osm command-line tool. Additionally, this feature proposes the syntax validation of the descriptors as well as -the generation of the tar.gz - -## Demo or definition of done - -The execution of the following commands using the OSM client to create, validate or build descriptors - -- 'osm package-create': Creates an OSM package for nsd, vnfd and nst -- 'osm package-validate': Syntax validation of OSM descriptors -- 'osm package-build': Generate .tar.gz files of nsd and vnfd