summaryrefslogtreecommitdiffstats
path: root/deploy/mac_generator.sh
blob: ed5dacd30a02fbd7d4e626311d5d69377aad6379 (plain) 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

#!/bin/bash
##############################################################################
# Copyright (c) 2016 HUAWEI TECHNOLOGIES CO.,LTD and others.
#
# All rights reserved. This program and the accompanying materials
# are made available under the terms of the Apache License, Version 2.0
# which accompanies this distribution, and is available at
# http://www.apache.org/licenses/LICENSE-2.0
##############################################################################
function mac_address_part() {
    hex_number=$(printf '%02x' $RANDOM)
    number_length=${#hex_number}
    number_start=$(expr $number_length - 2)
    echo ${hex_number:$number_start:2}
}

function mac_address() {
    echo "'00:00:$(mac_address_part):$(mac_address_part):$(mac_address_part):$(mac_address_part)'"
}

machines=''
for i in `seq $1`; do
  mac=$(mac_address)

  if [[ -z $machines ]]; then
    machines="${mac}"
  else
    machines="${machines} ${mac}"
  fi
done
echo ${machines}
1) Load Balancer configuration 2) Core Services (Database/Rabbit/NTP/etc.) 3) Early Openstack Service setup (Ringbuilder, etc.) 4) General OpenStack Services 5) Service activation (Pacemaker) Batch Upgrade Steps ------------------- Each service template may optionally define a `upgrade_batch_tasks` key, which is a list of ansible tasks to be performed during the upgrade process. Similar to the step_config, we allow a series of steps for the per-service upgrade sequence, defined as ansible tasks with a tag e.g "step1" for the first step, "step2" for the second, etc. Note that each step is performed in batches, then we move on to the next step which is also performed in batches (we don't perform all steps on one node, then move on to the next one which means you can sequence rolling upgrades of dependent services via the step value). The tasks performed at each step is service specific, but note that all batch upgrade steps are performed before the `upgrade_tasks` described below. This means that all services that support rolling upgrades can be upgraded without downtime during `upgrade_batch_tasks`, then any remaining services are stopped and upgraded during `upgrade_tasks` The default batch size is 1, but this can be overridden for each role via the `upgrade_batch_size` option in roles_data.yaml Upgrade Steps ------------- Each service template may optionally define a `upgrade_tasks` key, which is a list of ansible tasks to be performed during the upgrade process. Similar to the step_config, we allow a series of steps for the per-service upgrade sequence, defined as ansible tasks with a tag e.g "step1" for the first step, "step2" for the second, etc. Steps/tages correlate to the following: 1) Quiesce the control-plane, e.g disable LoadBalancer, stop pacemaker cluster 2) Stop all control-plane services, ready for upgrade 3) Perform a package update, (either specific packages or the whole system) 4) Start services needed for migration tasks (e.g DB) 5) Perform any migration tasks, e.g DB sync commands 6) Start control-plane services 7) Any additional online migration tasks (e.g data migrations) Nova Server Metadata Settings ----------------------------- One can use the hook of type `OS::TripleO::ServiceServerMetadataHook` to pass entries to the nova instances' metadata. It is, however, disabled by default. In order to overwrite it one needs to define it in the resource registry. An implementation of this hook needs to conform to the following: * It needs to define an input called `RoleData` of json type. This gets as input the contents of the `role_data` for each role's ServiceChain. * This needs to define an output called `metadata` which will be given to the Nova Server resource as the instance's metadata.