Update git submodules
authorAlexandru Avadanii <Alexandru.Avadanii@enea.com>
Wed, 31 Jan 2018 23:28:17 +0000 (00:28 +0100)
committerGerrit Code Review <gerrit@opnfv.org>
Mon, 5 Feb 2018 13:16:07 +0000 (13:16 +0000)
* Update docs/submodules/fuel from branch 'master'
  - [baremetal] Rename all to drop baremetal prefix

    A few things differ between baremetal and virtual nodes:
    - provisioning method;
    - network setup;

    Since now we support completely dynamic network config based on PDF +
    IDF, as well as dynamic provisioning of VMs on jumpserver (as virtual
    cluster nodes), respectively MaaS-driven baremetal provisioning, let's
    drop the 'baremetal-' prefix from cluster model names and prepare for
    unified scenarios.

    Note that some limitations still apply, e.g. virtual nodes are spawned
    only on jumpserver (localhost) for now.

    JIRA: FUEL-310

    Change-Id: If20077ac37c6f15961468abc58db7e16f2c29260
Signed-off-by: Alexandru Avadanii <Alexandru.Avadanii@enea.com>
  - [virtual] PDF-based network defs for cluster nodes

    Decouple virtual cluster nodes (ctl, gtw etc.) from opnfv_fn_* vars
    in favor of parsing PDF/IDF.
    This is the first step towards unifying baremetal and virtual network
    definition templates, as well as allowing virtual nodes to run on a
    remote hypervisor (and eventually with a different arch).

    opnfv_fn_* vars will still be used for infra VMs spawned on FN (cfg01
    and optionally mas01).

    Adopt new 'net_map.j2' from Pharos submodule for new templates (virt),
    as well as old ones (baremetal).

    JIRA: FUEL-322

    Change-Id: I150c2416566bbe42ea11cd00f12a8a7bf96776c2
Signed-off-by: Alexandru Avadanii <Alexandru.Avadanii@enea.com>
  - [virtual] Parameterize cluster model based on PDF

    - 10.1.0.0/24 (internal):
      * 10.1.0.101    -> opnfv_openstack_compute_node01_tenant_address
      * 10.1.0.124    -> opnfv_openstack_gateway_node01_tenant_address

    - 172.16.10.0/24 (mgmt):
      * 172.16.10.11  -> opnfv_openstack_control_node01_address
      * 172.16.10.100 -> opnfv_infra_config_address
      * 172.16.10.101 -> opnfv_openstack_compute_node01_control_address
      * 172.16.10.111 -> opnfv_opendaylight_server_node01_single_address
      * 172.16.10.124 -> opnfv_openstack_gateway_node01_address

    - 10.16.0.0/24 (public):
      * 10.16.0.11    -> opnfv_openstack_control_node01_external_address
      * 10.16.0.101   -> opnfv_openstack_compute_node01_external_address
      * 10.16.0.124   -> opnfv_openstack_gateway_node01_external_address

    To re-use DPDK config baremetal template, move:
    - cluster.baremetal-mcp-pike-ovs-dpdk-ha.infra.config_pdf
    + cluster.all-mcp-arch-common.infra.config_dpdk_pdf

    Drop unused 'ceilometer_graphite_publisher_host' (172.16.10.107).

    JIRA: FUEL-322

    Change-Id: I3aef3415bd696a7ae5b566af12af4733a50c2135
Signed-off-by: Alexandru Avadanii <Alexandru.Avadanii@enea.com>
  - [virtual] Change IP addrs to align with baremetal

    To be able to re-use pod_config.yaml parameters generated based on
    PDF for both baremetal and virtual scenarios without forking it,
    we first need to align the IP addresses used in virtual deployments.
    Currently hard set values will be parameterized in an ulterior
    change.

    - 10.1.0.0/24 (internal):
      * 105 -> 101 (cmp01); 106 -> 102 (cmp02);
      * 110 -> 124 (gtw01);

    - 172.16.10.0/24 (mgmt):
      * 101 ->  11 (ctl01);
      * 105 -> 101 (cmp01); 106 -> 102 (cmp02);
      * 110 -> 124 (gtw01);

    - 10.16.0.0/24 (public):
      * 101 ->  11 (ctl01);
      * 105 -> 101 (cmp01); 106 -> 102 (cmp02);
      * 110 -> 124 (gtw01);

    JIRA: FUEL-322

    Change-Id: I5d5def4e92c3462f1a34f73dde65ef7a262a5d62
Signed-off-by: Alexandru Avadanii <Alexandru.Avadanii@enea.com>
  - [virtual] Split 'pxebr' from 'mcpcontrol' net

    - add new virsh managed network 'pxebr' (to mimic baremetal behavior
      on virtual PODs, this will be the equivalent of PXE/admin network);
    - connect 'pxebr' to 3rd interface for cfg01, mas01 for all deploys
      (used to be baremetal-specific), replacing 'internal';
    - keep 'mcpcontrol' connected only to 'cfg01' (+ 'mas01' if present)
      for initial infrastructure bring-up (1st interface);
    - switch all virtual cluster nodes to 'pxebr' (1st interface);
    - use 'pxebr' for all Salt cluster nodes traffic, 'mcpcontrol' only
      for mas01<=>cfg01 Salt traffic;
    - convert <user-data.template> to jinja2 and expand it based on PDF
      instead of using `envsubst`;
    - split <user-data.sh.j2> into two versions, one for each network
      used for Salt traffic;
    - ci/deploy.sh: Read scenario data before template parsing for
      cluster domain variable, needed in virsh network def;
    - leave docs diagram refresh to later after all possible deploy types
      have settled;
    - limit keyserver proxy usage to nodes where the configured http proxy
      matches the first nameserver (true for all MaaS-provisioned nodes),
      so we can re-use the same pillar for FN VMs and baremetal nodes;
    - add PXE/admin IP on cfg01's 3rd interface and switch other vnodes
      `salt_master_host` to point to it;

    JIRA: FUEL-322

    Change-Id: Ie4f7aedddf2ef81046f1127b377d88dce79f0fda
Signed-off-by: Alexandru Avadanii <Alexandru.Avadanii@enea.com>
  - [FN VM] Reboot VMs on jump, wait for all online

    - apply `linux` state on cfg01 first, so PXE/admin IP is added and
      FN VM minions are available;
    - add barrier and wait for all FN VMs to register with cfg01;
    - use batch-mode execution while applying `linux.network` on FN VMs;
    - retry all states executed via <salt.sh> on FN VMs;

    JIRA: FUEL-310

    Change-Id: I72e1c565370072500df1d486fe76e6315f583c75
Signed-off-by: Alexandru Avadanii <Alexandru.Avadanii@enea.com>
  - [PDF] Switch to generate_config, unify templates

    - move bash template handling (previously expanded via `envsubst`)
      to lib.sh;
    - move j2 template handling to lib.sh;
    - move virsh network templates to 'mcp/scripts/virsh_net' subdir;
    - switch virsh network templates from `envsubst` expansion to j2 and
      leverage generate_config.py, similar to PDF Fuel installer adapter;
    - add relevant runtime env vars (e.g. SALT_MASTER, MAAS_IP) on the fly
      to PDF, to consume them in templates like params coming from PDF;
    - parameterize virsh network definitions based on PDF (mgmt, public);

    JIRA: FUEL-322

    Change-Id: Ib94e78fc4f25797b9354a0552e884104da5d0003
Signed-off-by: Alexandru Avadanii <Alexandru.Avadanii@enea.com>
  - deploy.sh: Move notify() to globals.sh

    Extend `notify` to 4 variants:

    - notify_i = inline (no newline) colored output;
    - notify   = `notify_i` + trailing '\n';
    - notify_n = `notify` + extra '\n' before and after;
    - notify_e = `notify` + stderr output + exit;

    This allows us to remove '\n' and cleanup the code a bit.
    While at it, fix some 'NOTE' messages going to stderr instead of
    stdout.

    Change-Id: I682e3344ae9e307c4a68ab31c7766bc91b12ee58
Signed-off-by: Alexandru Avadanii <Alexandru.Avadanii@enea.com>
  - deploy.sh: Make PDF, IDF mandatory for all deploys

    - hard requiremenet of PDF/IDF configuration for all deployments;
    - expand j2 templates for virtual deploys too;

    Since until now we used the same model for *all* virtual PODs, one
    of the PDF/IDF sets for existing vPODs (e.g. ericsson-virtual3) can
    be re-used practically on any host, without defining new vPODs.

    JIRA: FUEL-322

    Change-Id: Iac6aab91b6958d0e5e175ed142da6aafadc6fac6
Signed-off-by: Alexandru Avadanii <Alexandru.Avadanii@enea.com>
  - [vPDF] Use local-virtual1, unify pkg requirements

    Until PDF/IDF land in Pharos for all our virtual PODs, use a common
    vPDF we already provide as an example to mimic the old hardcoded
    behavior while leveraging PDF/IDF parameterization.

    As a consequence, python requirements previously only needed for
    baremetal should now also be installed for virtual deploys too.

    JIRA: FUEL-322

    Change-Id: Ied1c907275285a9086450a15491ae516a0db1be2
Signed-off-by: Alexandru Avadanii <Alexandru.Avadanii@enea.com>
  - [vPDF] Add experimental vPOD lab config

    JIRA: FUEL-322

    Change-Id: I1482badbbbf66b4855faf6daf486520fc71e09b0
Signed-off-by: Alexandru Avadanii <Alexandru.Avadanii@enea.com>
  - [baremetal] Retire example pod_config.yaml

    It is easier to just generate the `pod_config.yaml` file than to
    maintain it, so let's remove it.

    While at it, link sample PDF/IDF inside pharos git submodule, so we
    don't have to pass a different lab-config URI to use the sample.

    To generate pod_config.yml for the sample PDF/IDF:
    $ ./ci/deploy.sh -l local -p pod1 -s os-odl-nofeature-ha -d
    $ cat mcp/deploy/images/pod_config.yml

    JIRA: FUEL-322

    Change-Id: If5898f92ef54bebc31d57f9632959e9093a89250
Signed-off-by: Alexandru Avadanii <Alexandru.Avadanii@enea.com>
  - [PDF] pod1: Refresh PDF, IDF examples

    Sync latest changes from pharos git repo for our sample PDF/IDF:
    - move net_config from PDF to IDF;
    - minor cleanup;

    JIRA: FUEL-322

    Change-Id: If6865ac61a4942a1dd5daf7081fd8faa67e0e7bf
Signed-off-by: Alexandru Avadanii <Alexandru.Avadanii@enea.com>
docs/submodules/fuel

index cbc651f..6acecf3 160000 (submodule)
@@ -1 +1 @@
-Subproject commit cbc651f281c280fab346b044a2a41083f3ff9468
+Subproject commit 6acecf3b104a072c60d071364344b9ff04994168