Release1/juju-2.x.md

   1 # Juju 2.x #
   2
   3 ## Proposer ##
   4 Mark Shuttleworth
   5 Marco Ceppi
   6
   7 ## Type ##
   8 **Feature**
   9
  10 ## Target MDG/TF ##
  11 **(Optional)**
  12
  13 VNF Configuration, DevOps
  14
  15 ## Description ##
  16 OSM R0 uses Juju 1.x for modelling VNFs. Also, OSM itself will be charmed,
  17 making it much easier to deploy and operate both for evaluation and
  18 production.
  19
  20 In Juju 2.x we gain a number of valuable capabilities:
  21
  22  - **Multi-model controller**. A single instance of Juju can manage multiple
  23    models. This means that RIFT.io will be able to stand up multiple
  24    independent scenarios using a single Juju instance, rather than
  25    needing separate Juju controllers per scenario. This will reduce
  26    the footprint of OSM and improve the operations story for production
  27    users.
  28  - **Workload status**. VNF charms can provide a clear status which RIFT
  29    will be able to interpret and present to the user. VNF vendors will
  30    find it easier to express the status of their VNFs in a complex
  31    topology.
  32  - **LXD containers**. The "local" provider, which is used for devops
  33    iteration, moves to LXD which is a full hypervisor and offers much
  34    faster and more flexible local deployment operations. VNF endors will
  35    have a far more efficient test and dev experience providing OSM VNFDs.
  36  - **Multi-user controller**. A single Juju controller can track multiple
  37    users, who have independent access to particular models managed by that
  38    controller. For OSM to enter production usage we need to be able to
  39    offer audit and ops access at each level of the stack, and Juju 2.x
  40    enables this in a PCI-DSS compliant fashion.
  41  - **Resources**. A charm can now specify a set of resources that will be
  42    delivered to the charm at runtime. Common examples would be the charm's
  43    preferred JVM, or a docker image. Juju 2.x mediates access to these
  44    resources for efficiency, the net result is a greatly improved VNFD
  45    experience for VNF vendors.
  46
  47 Juju 2.0 is currently in late beta, APIs are finalised, with a final release
  48 expected in July, so integration work can commence without having to wait.
  49
  50 The work involved in this change should come about naturally - initial Juju
  51 1.x integration with RIFT was straightforward and Juju 2.x presents a cleaner
  52 API, so we do not anticipate challenges on this front. The Canonical team is
  53 happy to help the RIFT team with this update as part of our joint work on OSM.
  54
  55 ## Demo or definition of done ##
  56 This change would be somewhat invisible to end-users. It will substantially
  57 improve the experience of VNF vendors because Juju 2.x charms have access
  58 to important new capabilities.