+++ /dev/null
-# Explicit Port Ordering Support for VDUs #
-
-## Proposer ##
-- Rajesh Velandy (RIFT.io)
-
-
-## Type ##
-**Feature**
-
-## Target MDG/TF ##
-SO
-
-## Description ##
-
-Implement the ability to specify ordering of interfaces (both external and internal) so that the VM
-is orchestrated with those ordering preserved.
-
-## Demo or definition of done ##
-Create a descriptor with the ordering specified for a demo VNF and observe that the VNF interfaces
-are coming up in the order specified.
\ No newline at end of file
+++ /dev/null
-# Enhancement of NBI API to collect VNF metrics
-
-## Proposers
-- Vijay R S (Tata Elxsi)
-
-## Type
-
-**Feature**
-
-## Target MDG/TF
-
-NBI
-
-## Description
-
-Present API implementation for NS metric collection in NBI(Feature 7270) only fetch NFVI metrics,
-not the VNF metrics.
-
-NFVI metrics listed as,
- cpu_utilization
- average_memory_utilization
- disk_read_ops
- disk_write_ops
- disk_read_bytes
- disk_write_bytes
- packets_dropped_<nic number>
- packets_received
- packets_sent
-
-Improvising the NBI to fetch both VNF and NFVI metrics from Prometheus as part of the same API.
-
-This can be done by making NBI fetch VNFRs collection from mongodb and get the VNF metric names
-with that NBI can query Prometheus to get the VNF metrics.
-
-## Demo or definition of done
-
-Working NBI API which will fetch metrics of both NFVI and VNFs.
\ No newline at end of file
+++ /dev/null
-# RO migration to Python3
-
-## Proposers
-
-- Alfonso Tierno (Telefonica)
-- Gerardo Garcia (Telefonica)
-- Francisco Javier Ramon (Telefonica)
-
-## Type
-
-Feature
-
-## Target MDG/TF
-
-RO, 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
-
-- RO will run on python3. RO client will also run on python3.
-- A new debian package will be produced "python3-osm-ro", totally based on Python3,
- with no dependences on Python2 or Python2 libraries.
-- The new debian package will be used by the RO Dockerfile in Devops stage3.
-
+++ /dev/null
-# Add support for parameter "ip_address” in newviminstace specification #
-
-## Proposer ##
-Vanessa Little (TDC,VMware)
-
-## Type ##
-**Feature**
-
-## Target MDG/TF ##
-RO
-
-## Description ##
-Add support for parameter "ip_address” in newviminstace specification to assign
-IP address to VM if explictly stated
-
-
-## Demo or definition of done ##
-Definition of Done: Create a VM with IP address specified on the interface
-identified in the VNFD
\ No newline at end of file
--- /dev/null
+# Explicit Port Ordering Support for VDUs #
+
+## Proposer ##
+- Rajesh Velandy (RIFT.io)
+
+
+## Type ##
+**Feature**
+
+## Target MDG/TF ##
+SO
+
+## Description ##
+
+Implement the ability to specify ordering of interfaces (both external and internal) so that the VM
+is orchestrated with those ordering preserved.
+
+## Demo or definition of done ##
+Create a descriptor with the ordering specified for a demo VNF and observe that the VNF interfaces
+are coming up in the order specified.
\ No newline at end of file
+++ /dev/null
-# RBAC for the platform #
-
-## Proposer ##
-- Gerardo Garcia (Telefonica)
-- Alfonso Tierno (Telefonica)
-- Francisco Javier Ramon (Telefonica)
-
-## Type ##
-**Feature**
-
-## Target MDG/TF ##
-SO
-
-## Description ##
-The NFV Orchestrator requires a significant set of capabilities and privileges
-to perform all its required tasks: VNF onboarding, NS design & onboarding, NS
-deployment, day-2 operation, NS shutdown, or addition of new datacenters/VIMs,
-among others. However, not all of those tasks are expected to be performed by
-the same user in the organization, since each of those stages may have
-different implications in terms of service continuity, validation, license
-consumption, access to credentials, etc.
-
-Thus, for real operation, the system should allow the definition of different
-roles, defined by admin user, with different sets of privileges. All users
-should be mapped, at least, to one of these roles.
-
-As a minimum, it is expected that the system should be able to enforce these
-privileges:
-1. Allowed to onboard a VNF
-2. Allowed to onboard a NS
-3. Allowed to deploy a NS
-4. Allowed to operate an existing NS (call to primitives, receive monitoring
-data, etc.), except NS scaling.
-5. Allowed to scale a NS.
-6. Allowed to terminate a NS.
-7. Allowed to customize the system and configure the roles.
-
-By default, the admin/root role should have been assigned all the privileges
-above.
-
-## Demo or definition of done ##
-- Successful creation by an admin user of the role TECHNOLOGY with privileges
-#1, #2, #3, with an user (tech) on it.
-- Successful creation by an admin user of the role OPERATIONS with privileges
-#3, #4, #5, #6, with an user (op) on it.
-- Check that tech and op are allowed to run operations of the kind authorized
-in their role.
-- Check that tech and op are not allowed to run operations not authorized in
-their role.
-- Check that users with the admin role support all the types of operations
-above (from #1 to #7).
\ No newline at end of file
+++ /dev/null
-# Secure Key Management
-
-## Proposer ##
-Michael Marchetti
-
-## Type ##
-**Feature**
-
-## Target MDG/TF ##
-SO,RO,VCA
-
-## Description ##
-
-Please refer to this presentation:
-https://docbox.etsi.org/OSG/OSM/05-CONTRIBUTIONS/2017
-//OSM(17)000023_ssh_key_management_in_osm_release_1.pptx
-
-This feature relates to the usage of proxy charms and allowing a proxy charm (charm container)
-ssh access to a VNF virtual machine. As outlined in the presentation, the proxy charm container
-needs a private key that matches the injected public key in the VNF virtual machine.
-
-This feature highlights some questions:
-- should the private key be injected into the container or be self generated?
-- how does the associated public key get injected into the VNF VM?
-- all aspects of the key methodology should be transparent to the user
- (user should not have to manually add keys to the system).
-
-It is expected that interactions between SO, RO and VCA will be necessary in order order to
-orchestratrate the keys between the proxy charm and VNF.
-
-Also of concern is accessibility to the ssh private key. Some consideration should be made for who
-has access to the private key. When a user runs "juju config 'application'" inside the VCA or via
-REST, should the private keys be visible?
-
-## Demo or definition of done ##
-
-A test case involves a VNF VM with a proxy charm, utilzing the sshproxy charm. The proxy charm
-is invoked on configuration changes and performs an ssh remote session to the VNF VM. The
-private/public key between the proxy charm container and the VNF VM would have be automatically
-deployed allowing this ssh remote session (without passwords) to commence.
+++ /dev/null
-# Support VMware Integrated Openstack as a VIM #
-
-## Proposer ##
-Vanessa Little (TDC,VMware)
-
-## Type ##
-**Feature**
-
-## Target MDG/TF ##
-RO
-
-## Description ##
-Regression test the current generic openstack library against VMware Integrated Openstack version 2.0 (kilo) (which is included in the current release of vCloud NFV 1.5)
-
-If tests are successful a separate openstack connector should not be required to connect to VMware Integrated Openstack as a VIM. However, the results of the regression tests will determine the detailed requirements and feature roadmpa for Relase 4
-
-## Demo or definition of done ##
-Definition of Done: Network services can be successfully deployed in VMware Integrated Openstack with the same connector, Network Service and VNFD descriptors as generic openstack builds that are based on Openstack Kilo.
\ No newline at end of file
+++ /dev/null
-# OSM on kubernetes
-
-## Proposer ##
-Michael Marchetti (Sandvine)
-
-## Type ##
-**Feature**
-
-## Target MDG/TF ##
-all MDG's
-
-## Description ##
-The OSM installer currently asssumes it will be installed on a host (or VM). The MDG
-components/services are deployed in separate lxc containers. A Release4 directive is to simplify
-the install process. Moving to docker containers will help with this strategy as the MDG images
-that are built and tested in the CI pipeline can be installed directly without having to go through
-a long term install process. Subsequently, the docker OSM components now need to be orchestrated
-with one another (UI<->SO<->RO, etc), and utilizing kubernetes will simplify this.
\ No newline at end of file
+++ /dev/null
-# Adding relations support for multi-charm VNFs #
-
-## Proposer ##
-Adam Israel
-
-## Type ##
-**Feature**
-
-## Target MDG/TF ##
-IM, LCM, N2VC
-
-## Description ##
-To be added
\ No newline at end of file
--- /dev/null
+# Add support for parameter "ip_address” in newviminstace specification #
+
+## Proposer ##
+Vanessa Little (TDC,VMware)
+
+## Type ##
+**Feature**
+
+## Target MDG/TF ##
+RO
+
+## Description ##
+Add support for parameter "ip_address” in newviminstace specification to assign
+IP address to VM if explictly stated
+
+
+## Demo or definition of done ##
+Definition of Done: Create a VM with IP address specified on the interface
+identified in the VNFD
\ No newline at end of file
--- /dev/null
+# Support VMware Integrated Openstack as a VIM #
+
+## Proposer ##
+Vanessa Little (TDC,VMware)
+
+## Type ##
+**Feature**
+
+## Target MDG/TF ##
+RO
+
+## Description ##
+Regression test the current generic openstack library against VMware Integrated Openstack version 2.0 (kilo) (which is included in the current release of vCloud NFV 1.5)
+
+If tests are successful a separate openstack connector should not be required to connect to VMware Integrated Openstack as a VIM. However, the results of the regression tests will determine the detailed requirements and feature roadmpa for Relase 4
+
+## Demo or definition of done ##
+Definition of Done: Network services can be successfully deployed in VMware Integrated Openstack with the same connector, Network Service and VNFD descriptors as generic openstack builds that are based on Openstack Kilo.
\ No newline at end of file
+++ /dev/null
-# Full exposure of internal RO runtime data to common OSM database
-
-## Proposer
-
-- Gerardo Garcia (Telefonica)
-- Alfonso Tierno (Telefonica)
-- Francisco Javier Ramon (Telefonica)
-
-## Type
-
-**Feature**
-
-## Target MDG/TF
-
-RO, LCM
-
-## Description
-
-Currently all runtime information related to resources is keep in an internal
-database in RO, which is partially replicated in the common database, involving
-a translation of models and storage mechanisms. This is inefficient for several
-reasons:
-
-- RO-related information stored in the common database is not authoritative,
-but a copy of the real authoritative info (information is duplicated).
-- Therefore, there is no 100% guarantee that the info in the common databases
-is kept in sync with the actual authoritative database.
-- There is a translation in place, to adapt the information to the different
-database paradigms (relational vs. noSQL) and map to to system-level IDs and
-objects.
-- Almost all changes at IM trigger a specific development to change the
-relational RO database and to make the appropriate translations. This usually
-requieres extensions in RO´s northbound interface capabilities too.
-- Maintaining this duplicate mechanism makes RO development and evolution
-artificially complex with no obvious advantages.
-
-Hence this feature requests the direct use of common OSM services by RO
-(particularly, the common database) so that information is always up to date
-and RO's maintenance is largely simplified, being current legacy RO's NBI and
-translation mechanisms no longer needed.
-
-## Demo or definition of done
-
-Check that all information of state in RO is always available in the common
-NoSQL databes, and that internal RO's MySQL database can be safely removed.
+++ /dev/null
-# Instantiation in VIMs with more than one physnet
-
-## Proposer
-
-- Gerardo Garcia (Telefonica)
-- Alfonso Tierno (Telefonica)
-- Francisco Javier Ramon (Telefonica)
-
-## Type
-
-**Feature**
-
-## Target MDG/TF
-
-RO, CLI (optional)
-
-## Description
-
-In environments where some physical redundancy is required in terms of
-networking, it is common the use of schemas with more than one switch upstream,
-dividing the physical medium in groups of physical interfaces depending of the
-upstream switch they are attached. In order to facilitate a sensible management
-of these physical interfaces belonging to different "redundancy groups" by the
-VIM, there is the possibility to classify them into the so-called 'physnets',
-so that the VIM can leverage on that physical redundacy if needed.
-
-While this feature should not create a fundamental change in OSM operation or
-the way its modelling works, and it is a fact that OSM can work with these
-environments, it is also true that it works today with some limitations when
-SDN Assist is in place. Thus, in a VIM with multiple physnets, only one can be
-registered today when configuring a VIM target in OSM, leading to potential
-underuse of resources (usually, by one half). Furthermore, when those physnets
-obbey to some kind of physical active-active scheme, OSM cannot leverage on
-this information to make NS/NSI deployments more reliable.
-
-This feature intends to solve the limitations described above.
-
-## Demo or definition of done
-
-With a VIM with multiple physnets, check that it is possible:
-
-- Register the VIM with all its physnets when defining a VIM target in OSM with
-SDN Assist.
-- Deploy a large NS requiring SDN Assist in such a VIM so that no interfaces
-are excluded because of the physnet they belong.
--- /dev/null
+# RBAC for the platform #
+
+## Proposer ##
+- Gerardo Garcia (Telefonica)
+- Alfonso Tierno (Telefonica)
+- Francisco Javier Ramon (Telefonica)
+
+## Type ##
+**Feature**
+
+## Target MDG/TF ##
+SO
+
+## Description ##
+The NFV Orchestrator requires a significant set of capabilities and privileges
+to perform all its required tasks: VNF onboarding, NS design & onboarding, NS
+deployment, day-2 operation, NS shutdown, or addition of new datacenters/VIMs,
+among others. However, not all of those tasks are expected to be performed by
+the same user in the organization, since each of those stages may have
+different implications in terms of service continuity, validation, license
+consumption, access to credentials, etc.
+
+Thus, for real operation, the system should allow the definition of different
+roles, defined by admin user, with different sets of privileges. All users
+should be mapped, at least, to one of these roles.
+
+As a minimum, it is expected that the system should be able to enforce these
+privileges:
+1. Allowed to onboard a VNF
+2. Allowed to onboard a NS
+3. Allowed to deploy a NS
+4. Allowed to operate an existing NS (call to primitives, receive monitoring
+data, etc.), except NS scaling.
+5. Allowed to scale a NS.
+6. Allowed to terminate a NS.
+7. Allowed to customize the system and configure the roles.
+
+By default, the admin/root role should have been assigned all the privileges
+above.
+
+## Demo or definition of done ##
+- Successful creation by an admin user of the role TECHNOLOGY with privileges
+#1, #2, #3, with an user (tech) on it.
+- Successful creation by an admin user of the role OPERATIONS with privileges
+#3, #4, #5, #6, with an user (op) on it.
+- Check that tech and op are allowed to run operations of the kind authorized
+in their role.
+- Check that tech and op are not allowed to run operations not authorized in
+their role.
+- Check that users with the admin role support all the types of operations
+above (from #1 to #7).
\ No newline at end of file
--- /dev/null
+# Secure Key Management
+
+## Proposer ##
+Michael Marchetti
+
+## Type ##
+**Feature**
+
+## Target MDG/TF ##
+SO,RO,VCA
+
+## Description ##
+
+Please refer to this presentation:
+https://docbox.etsi.org/OSG/OSM/05-CONTRIBUTIONS/2017
+//OSM(17)000023_ssh_key_management_in_osm_release_1.pptx
+
+This feature relates to the usage of proxy charms and allowing a proxy charm (charm container)
+ssh access to a VNF virtual machine. As outlined in the presentation, the proxy charm container
+needs a private key that matches the injected public key in the VNF virtual machine.
+
+This feature highlights some questions:
+- should the private key be injected into the container or be self generated?
+- how does the associated public key get injected into the VNF VM?
+- all aspects of the key methodology should be transparent to the user
+ (user should not have to manually add keys to the system).
+
+It is expected that interactions between SO, RO and VCA will be necessary in order order to
+orchestratrate the keys between the proxy charm and VNF.
+
+Also of concern is accessibility to the ssh private key. Some consideration should be made for who
+has access to the private key. When a user runs "juju config 'application'" inside the VCA or via
+REST, should the private keys be visible?
+
+## Demo or definition of done ##
+
+A test case involves a VNF VM with a proxy charm, utilzing the sshproxy charm. The proxy charm
+is invoked on configuration changes and performs an ssh remote session to the VNF VM. The
+private/public key between the proxy charm container and the VNF VM would have be automatically
+deployed allowing this ssh remote session (without passwords) to commence.
+++ /dev/null
-# Install OSM to OpenStack using Ansible #
-
-## Proposer(s) ##
-
-Antonio Marsico (BT)
-
-## Type ##
-
-Feature
-
-## Target MDG/TF ##
-
-Devops, Other
-
-## Description ##
-
-Installing OSM on top of an OpenStack infrastructure may be cumbersome. Networks, Security groups, Flavors and Images are a few example of what you need to setup before being ready to install OSM on OpenStack.
-
-This feature proposes the automatic installation of OSM on top of an OpenStack infrastructure. It is based on Ansible, a well-known automation tool. The Ansible playbook performs the following operations:
-
-* Create an external network and its subnet
-* Download the Ubuntu 18.04 image and upload it
-* Create a security group to allow SSH and HTTP access to an instance
-* Create a VM flavour compatible to OSM
-* Deploy an Ubuntu 18.04 instance
-* Install OSM when the instance becomes available
-
-All these tasks are performed only if required. This is a feature of Ansible. For instance, if the Ubuntu 18.04 image is already present, the task is skipped.
-
-## Demo or definition of done ##
-
-It is an open question to the community if it worth adding this as an option to the `install_osm.sh` installer or leave it as a standalone feature.
-
-If the standard invocation of Ansible is used, the following procedure is required.
-
-### Playbook execution
-
-In order to execute the playbook, it is required an OpenStack openrc file. It can be downloaded from the OpenStack web interface Horizon.
-
-After that, it can be loaded with the following command:
-
-`$ . openrc`
-
-Then, all the credentials are loaded in the bash environment. Now it is possible to execute the playbook to configure OpenStack and install OSM:
-
-`$ ansible-playbook site.yml`
\ No newline at end of file
+++ /dev/null
-# Juniper Contrail SDN Controller support #
-
-## Proposer ##
-Adam Israel (Canonical)
-Arno van Huyssteen (Canonical)
-David Garcia (Canonical)
-Eduardo Sousa (Canonical)
-
-## Type ##
-**Feature**
-
-## Target MDG/TF ##
-RO
-
-## Description ##
-OSM currently supports FloodLight, ONOS and ODL; these are the most used in
-the open source world. While there is a benefit in having this compatibility
-in OSM, there is a recurring need to support commercial SDN controllers, since
-those will be by far more prevalent in real carrier deployments.
-
-The objective of this proposal is to bring to OSM one of the more widely used
-SDN Controllers in the market. While Juniper Contrail provides a wide array of
-features, the scope of this proposal will be to cover SDN Assist use cases.
-
-## Demo or definition of done ##
-* Being able to add Juniper Contrail as a SDN Controller.
-* Being able to use Juniper Contrail for SDN Assist use cases.
--- /dev/null
+# Enhancement of NBI API to collect VNF metrics
+
+## Proposers
+- Vijay R S (Tata Elxsi)
+
+## Type
+
+**Feature**
+
+## Target MDG/TF
+
+NBI
+
+## Description
+
+Present API implementation for NS metric collection in NBI(Feature 7270) only fetch NFVI metrics,
+not the VNF metrics.
+
+NFVI metrics listed as,
+ cpu_utilization
+ average_memory_utilization
+ disk_read_ops
+ disk_write_ops
+ disk_read_bytes
+ disk_write_bytes
+ packets_dropped_<nic number>
+ packets_received
+ packets_sent
+
+Improvising the NBI to fetch both VNF and NFVI metrics from Prometheus as part of the same API.
+
+This can be done by making NBI fetch VNFRs collection from mongodb and get the VNF metric names
+with that NBI can query Prometheus to get the VNF metrics.
+
+## Demo or definition of done
+
+Working NBI API which will fetch metrics of both NFVI and VNFs.
\ No newline at end of file
--- /dev/null
+# OSM on kubernetes
+
+## Proposer ##
+Michael Marchetti (Sandvine)
+
+## Type ##
+**Feature**
+
+## Target MDG/TF ##
+all MDG's
+
+## Description ##
+The OSM installer currently asssumes it will be installed on a host (or VM). The MDG
+components/services are deployed in separate lxc containers. A Release4 directive is to simplify
+the install process. Moving to docker containers will help with this strategy as the MDG images
+that are built and tested in the CI pipeline can be installed directly without having to go through
+a long term install process. Subsequently, the docker OSM components now need to be orchestrated
+with one another (UI<->SO<->RO, etc), and utilizing kubernetes will simplify this.
\ No newline at end of file
--- /dev/null
+# RO migration to Python3
+
+## Proposers
+
+- Alfonso Tierno (Telefonica)
+- Gerardo Garcia (Telefonica)
+- Francisco Javier Ramon (Telefonica)
+
+## Type
+
+Feature
+
+## Target MDG/TF
+
+RO, 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
+
+- RO will run on python3. RO client will also run on python3.
+- A new debian package will be produced "python3-osm-ro", totally based on Python3,
+ with no dependences on Python2 or Python2 libraries.
+- The new debian package will be used by the RO Dockerfile in Devops stage3.
+
+++ /dev/null
-# HA Proxy Charms #
-
-## Proposer ##
-
-- Tytus Kurek (Canonical)
-- David Garcia (Canonical)
-- Dominik Fleischmann (Canonical)
-
-## Type ##
-
-**Feature**
-
-## Target MDG/TF ##
-
-IM, N2VC, LCM
-
-## Description ##
-
-Some features (8681 and 7657) are assuring that an HA VCA will be available
-to OSM. Nontheless to achieve full High Availability in Charm Workloads the Charms
-must also be designed to achieve that.
-
-For this, an additional value will have to be added to the descriptor to state the
-number of units of each Charm that should be created. This will require modifications
-in IM and LCM.
-
-Furthermore, N2VC will have to be modified to recognize the leader unit of each charm
-when executing actions.
-
-Finally to assure that future charms can be written with high availability in mind an
-example proxy charm will be provided.
-
-## Demo or definition of done ##
-
-Once this feature is done it will be possible to deploy several units of proxy charms in
-a LXD Cluster to assure redundancy and high availability between them. This way if one of
-the cluster node fails it won't affect the operations of the workloads. The charms will
-have to be written with high availability support.
--- /dev/null
+# Adding relations support for multi-charm VNFs #
+
+## Proposer ##
+Adam Israel
+
+## Type ##
+**Feature**
+
+## Target MDG/TF ##
+IM, LCM, N2VC
+
+## Description ##
+To be added
\ No newline at end of file
--- /dev/null
+# Install OSM to OpenStack using Ansible #
+
+## Proposer(s) ##
+
+Antonio Marsico (BT)
+
+## Type ##
+
+Feature
+
+## Target MDG/TF ##
+
+Devops, Other
+
+## Description ##
+
+Installing OSM on top of an OpenStack infrastructure may be cumbersome. Networks, Security groups, Flavors and Images are a few example of what you need to setup before being ready to install OSM on OpenStack.
+
+This feature proposes the automatic installation of OSM on top of an OpenStack infrastructure. It is based on Ansible, a well-known automation tool. The Ansible playbook performs the following operations:
+
+* Create an external network and its subnet
+* Download the Ubuntu 18.04 image and upload it
+* Create a security group to allow SSH and HTTP access to an instance
+* Create a VM flavour compatible to OSM
+* Deploy an Ubuntu 18.04 instance
+* Install OSM when the instance becomes available
+
+All these tasks are performed only if required. This is a feature of Ansible. For instance, if the Ubuntu 18.04 image is already present, the task is skipped.
+
+## Demo or definition of done ##
+
+It is an open question to the community if it worth adding this as an option to the `install_osm.sh` installer or leave it as a standalone feature.
+
+If the standard invocation of Ansible is used, the following procedure is required.
+
+### Playbook execution
+
+In order to execute the playbook, it is required an OpenStack openrc file. It can be downloaded from the OpenStack web interface Horizon.
+
+After that, it can be loaded with the following command:
+
+`$ . openrc`
+
+Then, all the credentials are loaded in the bash environment. Now it is possible to execute the playbook to configure OpenStack and install OSM:
+
+`$ ansible-playbook site.yml`
\ No newline at end of file
--- /dev/null
+# Full exposure of internal RO runtime data to common OSM database
+
+## Proposer
+
+- Gerardo Garcia (Telefonica)
+- Alfonso Tierno (Telefonica)
+- Francisco Javier Ramon (Telefonica)
+
+## Type
+
+**Feature**
+
+## Target MDG/TF
+
+RO, LCM
+
+## Description
+
+Currently all runtime information related to resources is keep in an internal
+database in RO, which is partially replicated in the common database, involving
+a translation of models and storage mechanisms. This is inefficient for several
+reasons:
+
+- RO-related information stored in the common database is not authoritative,
+but a copy of the real authoritative info (information is duplicated).
+- Therefore, there is no 100% guarantee that the info in the common databases
+is kept in sync with the actual authoritative database.
+- There is a translation in place, to adapt the information to the different
+database paradigms (relational vs. noSQL) and map to to system-level IDs and
+objects.
+- Almost all changes at IM trigger a specific development to change the
+relational RO database and to make the appropriate translations. This usually
+requieres extensions in RO´s northbound interface capabilities too.
+- Maintaining this duplicate mechanism makes RO development and evolution
+artificially complex with no obvious advantages.
+
+Hence this feature requests the direct use of common OSM services by RO
+(particularly, the common database) so that information is always up to date
+and RO's maintenance is largely simplified, being current legacy RO's NBI and
+translation mechanisms no longer needed.
+
+## Demo or definition of done
+
+Check that all information of state in RO is always available in the common
+NoSQL databes, and that internal RO's MySQL database can be safely removed.
--- /dev/null
+# Instantiation in VIMs with more than one physnet
+
+## Proposer
+
+- Gerardo Garcia (Telefonica)
+- Alfonso Tierno (Telefonica)
+- Francisco Javier Ramon (Telefonica)
+
+## Type
+
+**Feature**
+
+## Target MDG/TF
+
+RO, CLI (optional)
+
+## Description
+
+In environments where some physical redundancy is required in terms of
+networking, it is common the use of schemas with more than one switch upstream,
+dividing the physical medium in groups of physical interfaces depending of the
+upstream switch they are attached. In order to facilitate a sensible management
+of these physical interfaces belonging to different "redundancy groups" by the
+VIM, there is the possibility to classify them into the so-called 'physnets',
+so that the VIM can leverage on that physical redundacy if needed.
+
+While this feature should not create a fundamental change in OSM operation or
+the way its modelling works, and it is a fact that OSM can work with these
+environments, it is also true that it works today with some limitations when
+SDN Assist is in place. Thus, in a VIM with multiple physnets, only one can be
+registered today when configuring a VIM target in OSM, leading to potential
+underuse of resources (usually, by one half). Furthermore, when those physnets
+obbey to some kind of physical active-active scheme, OSM cannot leverage on
+this information to make NS/NSI deployments more reliable.
+
+This feature intends to solve the limitations described above.
+
+## Demo or definition of done
+
+With a VIM with multiple physnets, check that it is possible:
+
+- Register the VIM with all its physnets when defining a VIM target in OSM with
+SDN Assist.
+- Deploy a large NS requiring SDN Assist in such a VIM so that no interfaces
+are excluded because of the physnet they belong.
--- /dev/null
+# Juniper Contrail SDN Controller support #
+
+## Proposer ##
+Adam Israel (Canonical)
+Arno van Huyssteen (Canonical)
+David Garcia (Canonical)
+Eduardo Sousa (Canonical)
+
+## Type ##
+**Feature**
+
+## Target MDG/TF ##
+RO
+
+## Description ##
+OSM currently supports FloodLight, ONOS and ODL; these are the most used in
+the open source world. While there is a benefit in having this compatibility
+in OSM, there is a recurring need to support commercial SDN controllers, since
+those will be by far more prevalent in real carrier deployments.
+
+The objective of this proposal is to bring to OSM one of the more widely used
+SDN Controllers in the market. While Juniper Contrail provides a wide array of
+features, the scope of this proposal will be to cover SDN Assist use cases.
+
+## Demo or definition of done ##
+* Being able to add Juniper Contrail as a SDN Controller.
+* Being able to use Juniper Contrail for SDN Assist use cases.
--- /dev/null
+# Installing OSM to Kubernetes using Charms #
+
+## Proposer(s) ##
+
+Adam Israel (Canonical)
+David Garcia (Canonical)
+Dominik Fleischmann (Canonical)
+
+## Type ##
+
+Feature
+
+## Target MDG/TF ##
+
+Devops, Other
+
+## Description ##
+
+We propose to extend the current installer to support installing OSM on top of Kubernetes using Juju and charms.
+
+This would be implemented as a new, optional switch to the installer. The user would be able to use the current '-c' switch to specify that they want the charmed version of OSM to be installed, rather than the default Docker Swarm.
+
+OSM charms are an open source collection of charms, under the Apache 2.0 license, that deploy OSM on top of Juju and Kubernetes.
+
+Each charm uses the Docker image produced by the community, so the user is getting the same OSM code, delivered via an alternative method that is designed to be modeled and operated at scale.
+
+Additionally, we'd like to move these charms under OSM governance, into a new git repository called osm-charms. This repository will contain the charms, interfaces, and assorted scripts related to building, testing, and publishing said charms.
+
+This is similar to how charms live upstream in OpenStack:
+https://opendev.org/openstack?q=charm&tab=&sort=recentupdate
+
+Lastly, we'll work with the devops community to integrate charms into Jenkins, allowing it to run through stages 1-4 the same as the Docker Swarm and Kubernetes installer options.
+
+This will allow the charmed installation of OSM to undergo the same rigorous testing as other installer methods do in order to ensure the same quality.
+
+We will then work with the upstream community to improve and extend the current testing, i.e., adding Robot tests and exercising use-cases of interest to commercial users of OSM.
+
+
+## Demo or definition of done ##
+
+As part of the installation of OSM, the user can pass the -c switch to `install_osm.sh` to override the default behavior.
+
+A user running the command 'install_osm.sh -c charmed' would install a single-instance version of OSM on top of microk8s via charms.
+
+Additional optional switches would be supported, including:
+
+--ha: install in High Availability mode
+--k8s_endpoint: Specify the endpoint of an existing Kubernetes to use instead of microk8s
+--bundle: Specify a custom bundle.yaml to use to deploy OSM via charms
+--microstack: Install and configure microstack alongside OSM
--- /dev/null
+# HA Proxy Charms #
+
+## Proposer ##
+
+- Tytus Kurek (Canonical)
+- David Garcia (Canonical)
+- Dominik Fleischmann (Canonical)
+
+## Type ##
+
+**Feature**
+
+## Target MDG/TF ##
+
+IM, N2VC, LCM
+
+## Description ##
+
+Some features (8681 and 7657) are assuring that an HA VCA will be available
+to OSM. Nontheless to achieve full High Availability in Charm Workloads the Charms
+must also be designed to achieve that.
+
+For this, an additional value will have to be added to the descriptor to state the
+number of units of each Charm that should be created. This will require modifications
+in IM and LCM.
+
+Furthermore, N2VC will have to be modified to recognize the leader unit of each charm
+when executing actions.
+
+Finally to assure that future charms can be written with high availability in mind an
+example proxy charm will be provided.
+
+## Demo or definition of done ##
+
+Once this feature is done it will be possible to deploy several units of proxy charms in
+a LXD Cluster to assure redundancy and high availability between them. This way if one of
+the cluster node fails it won't affect the operations of the workloads. The charms will
+have to be written with high availability support.
+++ /dev/null
-# Installing OSM to Kubernetes using Charms #
-
-## Proposer(s) ##
-
-Adam Israel (Canonical)
-David Garcia (Canonical)
-Dominik Fleischmann (Canonical)
-
-## Type ##
-
-Feature
-
-## Target MDG/TF ##
-
-Devops, Other
-
-## Description ##
-
-We propose to extend the current installer to support installing OSM on top of Kubernetes using Juju and charms.
-
-This would be implemented as a new, optional switch to the installer. The user would be able to use the current '-c' switch to specify that they want the charmed version of OSM to be installed, rather than the default Docker Swarm.
-
-OSM charms are an open source collection of charms, under the Apache 2.0 license, that deploy OSM on top of Juju and Kubernetes.
-
-Each charm uses the Docker image produced by the community, so the user is getting the same OSM code, delivered via an alternative method that is designed to be modeled and operated at scale.
-
-Additionally, we'd like to move these charms under OSM governance, into a new git repository called osm-charms. This repository will contain the charms, interfaces, and assorted scripts related to building, testing, and publishing said charms.
-
-This is similar to how charms live upstream in OpenStack:
-https://opendev.org/openstack?q=charm&tab=&sort=recentupdate
-
-Lastly, we'll work with the devops community to integrate charms into Jenkins, allowing it to run through stages 1-4 the same as the Docker Swarm and Kubernetes installer options.
-
-This will allow the charmed installation of OSM to undergo the same rigorous testing as other installer methods do in order to ensure the same quality.
-
-We will then work with the upstream community to improve and extend the current testing, i.e., adding Robot tests and exercising use-cases of interest to commercial users of OSM.
-
-
-## Demo or definition of done ##
-
-As part of the installation of OSM, the user can pass the -c switch to `install_osm.sh` to override the default behavior.
-
-A user running the command 'install_osm.sh -c charmed' would install a single-instance version of OSM on top of microk8s via charms.
-
-Additional optional switches would be supported, including:
-
---ha: install in High Availability mode
---k8s_endpoint: Specify the endpoint of an existing Kubernetes to use instead of microk8s
---bundle: Specify a custom bundle.yaml to use to deploy OSM via charms
---microstack: Install and configure microstack alongside OSM
projects / osm / Features.git / commitdiff