From: shuttleworth <mark.shuttleworth@canonical.com>
Date: Wed, 15 Jun 2016 04:32:20 +0000 (+0200)
Subject: Add Juju-2.x support
X-Git-Url: https://osm.etsi.org/gitweb/?a=commitdiff_plain;h=e840ba8ddc12baf36279af11ea88e52672c3bd14;p=osm%2FFeatures.git

Add Juju-2.x support

Change-Id: Ie27afcba7b3ec97a9d8e6af576f6bca186a50907
---

diff --git a/Release1/juju-2.x.md b/Release1/juju-2.x.md
new file mode 100644
index 0000000..028166d
--- /dev/null
+++ b/Release1/juju-2.x.md
@@ -0,0 +1,58 @@
+# Juju 2.x #
+
+## Proposer ##
+Mark Shuttleworth
+Marco Ceppi
+
+## Type ##
+**Feature**
+
+## Target MDG/TF ##
+**(Optional)**
+
+VNF Configuration, DevOps
+
+## Description ##
+OSM R0 uses Juju 1.x for modelling VNFs. Also, OSM itself will be charmed,
+making it much easier to deploy and operate both for evaluation and
+production.
+
+In Juju 2.x we gain a number of valuable capabilities:
+
+ - **Multi-model controller**. A single instance of Juju can manage multiple
+   models. This means that RIFT.io will be able to stand up multiple
+   independent scenarios using a single Juju instance, rather than
+   needing separate Juju controllers per scenario. This will reduce
+   the footprint of OSM and improve the operations story for production
+   users.
+ - **Workload status**. VNF charms can provide a clear status which RIFT
+   will be able to interpret and present to the user. VNF vendors will
+   find it easier to express the status of their VNFs in a complex
+   topology.
+ - **LXD containers**. The "local" provider, which is used for devops
+   iteration, moves to LXD which is a full hypervisor and offers much
+   faster and more flexible local deployment operations. VNF endors will
+   have a far more efficient test and dev experience providing OSM VNFDs.
+ - **Multi-user controller**. A single Juju controller can track multiple
+   users, who have independent access to particular models managed by that
+   controller. For OSM to enter production usage we need to be able to
+   offer audit and ops access at each level of the stack, and Juju 2.x
+   enables this in a PCI-DSS compliant fashion.
+ - **Resources**. A charm can now specify a set of resources that will be
+   delivered to the charm at runtime. Common examples would be the charm's
+   preferred JVM, or a docker image. Juju 2.x mediates access to these
+   resources for efficiency, the net result is a greatly improved VNFD
+   experience for VNF vendors.
+
+Juju 2.0 is currently in late beta, APIs are finalised, with a final release
+expected in July, so integration work can commence without having to wait.
+
+The work involved in this change should come about naturally - initial Juju
+1.x integration with RIFT was straightforward and Juju 2.x presents a cleaner
+API, so we do not anticipate challenges on this front. The Canonical team is
+happy to help the RIFT team with this update as part of our joint work on OSM.
+
+## Demo or definition of done ##
+This change would be somewhat invisible to end-users. It will substantially
+improve the experience of VNF vendors because Juju 2.x charms have access
+to important new capabilities.
\ No newline at end of file