43 Commits

Author SHA1 Message Date
Dan Prince
ffd071417f Keystone network isolation fixes
This patch adds explicit nested stack parameters to
help manage use of the Keystone Admin API vs. the
Keystone Public API.

We also add a new output parameter specifically for the Keystone admin
API VIP. This can be useful when configuring keystone endpoints
with network isolation.

Change-Id: I2bd3e61570151e2faeee14ee09b03ad0b3208cc1
2015-09-05 07:29:13 -04:00
Jenkins
d982240bde Merge "NFS backend for Cinder" 2015-07-24 14:09:57 +00:00
marios
be0d3f3520 Adds the NeutronTunnelIdRanges and NeutronVniRanges parameters
This adds the NeutronTunnelIdRanges and NeutronVniRanges parameters
which govern the GRE or VXLAN tunnel IDs (respectively) that are to
be made available for overcloud tenant networks.

These both default to "1:1000," to retain the current behaviour.
They are propagated to the hiera data for puppet deploys and there
is a separate change to support passing these into the config via
the neutron tripleo-image-element at

https://review.openstack.org/#/c/199592/

Change-Id: I967a8cae218a31e888abc438e9de5756ae627adb
Related-Bug: https://bugzilla.redhat.com/show_bug.cgi?id=1240631
2015-07-13 15:32:28 +03:00
Jiri Stransky
c8c11a09f0 NFS backend for Cinder
Adds support for NFS backend for Cinder, but remains disabled by
default.

Change-Id: I9ebef072ed115efe980fa4904ea80f02384522af
2015-07-07 13:25:29 +02:00
Jenkins
7852f5da56 Merge "Make puppet-applying *Post resources depend on hieradata" 2015-06-24 17:00:17 +00:00
Steven Hardy
1f37302f6b Allow control of hostname formatting
Currently, we use the heat default server names, which results in some
fairly unreadable hostnames due to the level of nesting in the templates.

e.g ov-sszdbj5rdne-0-bhseh65edxv6-Controller-zoqc6tlypbdp

Instead, we allow the user to specify a format string per role, defaulted
to a string which formats the name e.g <stackname>-controller-<index>

e.g overcloud-controller-0

Optionally additional hostname components (not replaced by heat) could be
added, such that deployment time customization of hostnames via firstboot
scripts (e.g cloud-init) may be possible.

Should anyone wish to maintain the old heat-generated names, they can pass
an empty string via these parameters, which heat will treat as if no "name"
property was provided to OS::Nova::Server.

Change-Id: I1730caa0c2256f970da22ab21fa3aa1549b3f90b
2015-06-17 10:23:09 +12:00
Steven Hardy
ec3137dc6e Make puppet-applying *Post resources depend on hieradata
When you do a stack-update which affects, e.g ControllerDeployment
such that some value in hieradata is updated (for example changing
the "Debug" parameter to True), we only write the hieradata file and
don't reapply the manifests.

So we introduce a dependency on the deploy_stdout values from all
hieradata applying configs, such that the manifests will be re-applied
on update if the data is changed.

This requires https://review.openstack.org/#/c/190282/ so that
99-refresh-completed will return the derived config ID as part of the
deploy_stdout payload.

Closes-Bug: #1463092
Change-Id: I1175248c3236d0c42e37d062afce550efce8aadc
2015-06-16 04:12:09 -04:00
Steve Baker
fa477ef380 Config & deployments to update overcloud packages
This change adds config and deployment resources to trigger package
updates on nodes. The deployments are triggered by doing a stack-update
and setting one of the parameters to a unique value.

The intent is that rolling update will be controlled by setting
breakpoints on all of the UpdateDeployment resources inside the
role resource groups.

Change-Id: I56bbf944ecd6cbdbf116021b8a53f9f9111c134f
2015-06-08 16:07:26 +02:00
Giulio Fidente
607311e02b Wire Neutron VLAN ranges param as array to puppet
Turns NeutronNetworkVLANRanges into a list and makes it consumable by
neutron::plugins::ml2::network_vlan_ranges as an array. Previously
usage of vlans was impossible due to puppet-neutron failing to
join() network_vlan_ranges.

Also fixes wiring of network_vlan_ranges on computes and adds a
sample environment file to test use of vlans for tenant networks.

Change-Id: I8725cdb9591dd8d0b7125fdacbefdc9138703266
2015-06-05 09:27:42 -04:00
Dan Prince
d413eb63f3 Wire ServiceNetMap as a top level parameter
This patch makes ServiceNetMap a top level parameter.

This is helpful to tools like Tuskar which don't support Heat
environments that contain both a resource_registry and default_parameters.

ServiceNetMap will in fact be utilized at the top level in some of
the VIP related patches that follow.

Change-Id: I375063dacf5f3fc68e6df93e11c3e88f48aa3c3a
2015-06-03 08:58:12 -04:00
Dan Prince
e38f7cae7d Switch net-config templates to use OS::stack_id
This patch removes the custom config_id outputs and replaces
it with OS::stack_id which allows us to just call get_resource
in the parent stack.

The motivation for this change is we'll be adding more os-net-config
templates and it would be nice to take advantage of this newer
template feature.

Change-Id: I6fcb26024b94420779b86766e16d8a24210c4f8e
2015-05-26 08:50:45 -04:00
Dan Prince
b87fe75b87 Add isolated network ports to compute roles
This patch updates the compute roles so that
they can optionally make use of isolated network
ports on the tenant, storage, and internal_api networks.

 -Multiple networks are created based upon settings in the heat
  resource registry. These nets will either use the noop network (the
  control plane pass-thru default) or create a custom Neutron port on
  each of the configured networks.

 -The ipaddress/subnet of each network is passed passed into the
  NetworkConfig resource which drives os-net-config. This allows the
  deployer to define a custom network template for static IPs, etc
  on each of the networks.

 -The ipaddress is exposed as an output parameter. By exposing
  the individual addresses as outputs we allow Heat to construct
  collections of ports for various services.

Change-Id: Ib07b4b7256ede7fb47ecc4eb5abe64b9144b9aa1
2015-05-26 08:50:44 -04:00
Dan Prince
b56c2f01bd Overcloud: bump HOT version to 2015-04-30
This patch bumps the HOT version for the overcloud
to Kilo 2015-04-30. We should have already done this
since we are making use of OS::stack_id (a kilo feature)
in some of the nested stacks. Also, this will give us access to
the new repeat function as well.

Change-Id: Ic534e5aeb03bd53296dc4d98c2ac5971464d7fe4
2015-05-20 11:37:46 -07:00
Giulio Fidente
04027e783f Remove hardcoded references to .novalocal in hostnames
Remove references to the .novalocal domain part in the hosts file.

Change-Id: Idf14907adaf2f35440b6f28870fe18434eadd1be
Depends-On: Iadfdf4120c4d1c9b6976321753957fd4eecf301c
2015-04-28 05:38:11 -04:00
Jenkins
645b447b86 Merge "Make all default values match overcloud defaults" 2015-04-27 14:21:00 +00:00
Dan Sneddon
476a1b347d Separate the network configuration per flavor.
This change allows a different network config for each family of hosts. For
instance, the controller may have a different network configuration than a
block storage node. This change adds a declaration for each family in the
overcloud-resource-registry.yaml & overcloud-resource-registry-puppet.yaml.

Change-Id: I083df7ebbb535f97d8ddec2ac0e06281c55986cd
2015-04-24 16:51:41 -07:00
Steven Hardy
723db1317c Enable passing optional first-boot user-data
Currently all the OS::Nova::Server resource created don't pass any
user-data.  It's possible to pass user-data as well as using heat
SoftwareConfig/SoftwareDeployment resources, and this can be useful
when you have simple "first boot" tasks which are possible either via
cloud-init, or via simple run-once scripts.

This enables passing such data by implementing a new provider resource
OS::TripleO::NodeUserData, which defaults to passing an empty mime
archive (thus it's a no-op).  An example of non no-op usage is also
provided.

Change-Id: Id0caba69768630e3a10439ba1fc2547a609c0cfe
2015-04-24 10:18:31 +01:00
Jeff Peeler
95889dd4ee Make all default values match overcloud defaults
It's very confusing for them to be different, especially in the case of
comparing Tuskar vs non-Tuskar deployments where the parameters are read
from different files.

Note: NeutronPhysicalBridge is named differently in the overcloud
template (HypervisorNeutronPhysicalBridge). This is the only parameter
checked that isn't named exactly the same, hopefully there aren't any
others.

(Checked controller, compute, ceph, cinder, and swift for both puppet
and non-puppet templates)

Change-Id: I48ce1eb40d2d080c589ce619c50eddff17efe882
2015-04-09 12:02:29 -04:00
Jenkins
76a8a88486 Merge "Ensure all Rabbit params are propagated to interested nodes." 2015-04-01 08:49:39 +00:00
Giulio Fidente
fed9d001cc Add support for Neutron l3_ha option in puppet templates
With this change we wire the NeutronL3HA parameter to the puppet
class, where needed.

Change-Id: I37b3850f71885a93859b5e51925df379616fc6ab
2015-03-19 15:23:00 +00:00
Giulio Fidente
21eed9350a Ensure all Rabbit params are propagated to interested nodes.
Change-Id: I1bb8ee15d361638d77c5df7f8c03561c34f4c88f
2015-03-19 10:46:02 -04:00
Yanis Guenane
abcfd88ee3 Add support for Ceph as a Cinder and Nova backend
This commit aims to add support for Ceph as a cinder and a nova backend.

  * Allows creation of Ceph pools from heat (Default: volumes, vms)
  * Creates the proper ceph user and inject the keys
  * Applies the proper configuration in cinder.conf and nova.conf
  * Enable the backend out of the box

Co-Authored-By: Giulio Fidente <gfidente@redhat.com>

Change-Id: Ic17d7a665de81a8bab5e34035abe90eda4bc889f
2015-03-18 12:42:51 -04:00
Dan Prince
2698bb4573 Compute: consolidated nested stack
In I250dc1a8c02626cf7d1a5d2ce92706504ec0c7de we split
out just the Controller software config in an effort
to provide hooks for alternate implementations (puppet).

This sort of worked but caused quirky ordering issues
with signal handling. It also causes problems for Tuskar
which would prefer to think of these nested stacks and
not have us split out just the software configs like this.

This patch moves all the compute related stuff for
our two implementations:

compute.yaml: is used by os-apply-config (uses the
tripleo-image-elements)
compute-puppet.yaml: uses stackforge puppet-* modules for
configuration

By duplicating the entire compute in this manner we make
it much easier to create dependencies and implement proper
signal handling. The only (temporary) downside is the duplication
of parameters most of which will eventually go away when we move
using the global parameters via Heat environment files instead.

Change-Id: I49175d1843520abc80fefe9528442e5dda151f5d
2015-01-27 09:07:18 -05:00
Giulio Fidente
4f4d8e3d16 Add parameter to manage usage of Neutron l3_ha option
This change will allow for the enablement of Neutron routers HA
via the new NeutronL3HA parameter.

Change-Id: Ia5f7c0b4e89159456482e840c50d166ec5f25d4c
Implements: blueprint tripleo-icehouse-ha-production-configuration
2015-01-09 19:24:53 +01:00
Jenkins
7cdb8ca6b4 Merge "Don't store Ceilo DB credentials on compute node" 2015-01-08 08:22:55 +00:00
Dan Prince
6812f6f644 Puppet: overcloud compute config
This patch provides an alternate implementation of
the OS::TripleO::Compute::SoftwareConfig which uses Puppet
to drive the configuration. Using this it is possible
to create a fully functional overcloud compute instance
which has the compute node configured via Puppet
stackforge modules.  This includes all the Nova, Neutron,
and Ceilometer configuration required to make things work.

In order to test this you'll want to build your images
with these elements:

 os-net-config
 heat-config-puppet
 puppet-modules
 hiera

None of the OpenStack specific TripleO elements
should be used with this approach (the nova/neutron/ceilometer
elements were NOT used to build the compute image).

Also, rather than use neutron-openvswitch-agent to configure
low level networking it is recommended that os-net-config
by configured directly via heat modeling rather than
parameter passing to init-neutron-ovs. This allows us to
configure the physical network while avoiding the coupling to
the neutron-openvswitch-element that our standard
parameter driven networking currently uses. (We still need
to move init-neutron-ovs so that it isn't coupled and/or deprecate
its use entirely because the heat drive stuff is more flexible.)

Packages may optionally be pre-installed via DIB using the
-p option (-p openstack-neutron,openstack-nova).

Change-Id: Ic36be25d70f0a94ca07ffda6e0005669b81c1ac7
2015-01-05 13:53:24 -05:00
Jenkins
733339df91 Merge "Don't store Neutron DB credentials on compute node" 2014-12-23 17:30:45 +00:00
Jenkins
26c80ee53d Merge "Don't store Nova DB credentials on compute nodes" 2014-12-23 17:30:28 +00:00
Dan Prince
9df1991a80 Compute: drive NW configuration via software conf
This example extends the compute software configuration
so that heat metadata is used to model the os-net-config
YAML (ultimately JSON) directly. The existing
os-net-config element already supports this format.

Configuring the physical network layer in this manner
would supplant the ever growing list of Heat parameters
that we have and is something that could be automatically
generated via tuskar.

The default is to use net-config-noop.yaml which
will pass no config metadata into the os-net-config
element which will essentially disable it in favor
of using parameters w/ init-neutron-ovs.

Change-Id: I30f325b1751caaef5624537e63ee27c2e418d5c8
2014-12-19 21:24:56 -05:00
Jenkins
741df33386 Merge "Set default network interfaces to nic1" 2014-12-19 14:01:22 +00:00
Jenkins
f0ba1a6324 Merge "Remove default flavor from every template" 2014-12-09 21:34:15 +00:00
Dan Prince
84c7b32c41 Don't store Ceilo DB credentials on compute node
This patch removes all references to the Ceilometer DSN parameter
in the overcloud compute templates. These credentials
are not required in order to run the required Ceilometer
service/agents.

Change-Id: I421ce4fca87ac87dd65ab8bbb20e7ea9be8d9c5d
2014-12-08 08:35:23 -05:00
Dan Prince
2c403d89fa Don't store Neutron DB credentials on compute node
This patch removes all references to the Neutron DSN parameter
in the overcloud compute templates. These credentials
are not required in order to run the required Neutron
services.

Change-Id: I0691f43bd2ce85bec0d68ab979136414f0610c61
2014-12-08 08:35:21 -05:00
Dan Prince
dfec68afbe Don't store Nova DB credentials on compute nodes
Remove NovaDSN from overcloud compute.

When using the Conductor the Nova compute service
does not need access to the database. This patch
removes all references to the Nova DSN in the overcloud
compute templates.

Change-Id: If75f480489b84002dd061c183dbee3572a8b63f1
2014-12-08 08:34:42 -05:00
Dan Prince
cb62cd9838 Add missing Neutron DVR params to without-mergepy
This patch adds the missing parameters to
overcloud-without-mergepy.yaml.

These parameters were adding to overcloud-source.yaml
in I422c65e7d941593083d52ad7fdf0dfd1d2fb3155. Due to
the concurrent review window they never made it
into the new overcloud-without-mergepy.yaml
implementation.

Change-Id: If54dc111aec852f906c9e7ac1bf56f9dcaf678ea
2014-12-05 20:48:33 -05:00
Dan Prince
8dd57aa961 Set default network interfaces to nic1
Now that we are using os-net-config we can make use of
the nic naming abstraction layer where the actual physical
nic name is mapped automatically.

This change removes all the eth0 references and replaces
them with nic1 which should make it more likely
that these default values would actually work on
some distributions.

It also removes the single instance of eth2 in the
undercloud-bm-nova-deploy.yaml template and replaces
it with nic1 as well. Underclouds aren't a special case
in this regard (I run my bare metal undercloud on em1)
so there is no good reason to default to the second nic.

Change-Id: I3ea92a502bc4b8789f74913f232ac8bc6b843008
2014-12-05 15:16:12 -05:00
Dan Prince
d1b7e15806 Remove LiveUpdate params
The params were added in I2997d23c584055c40034827e9beb58e6542ea11c
as a means to pass undercloud image data to overcloud instances
so they could perform an update via takeovernode). We've
never actually made use of them via takeovernode... furthermore
these params are a bit stale in that they haven't been applied
to other instance types (storage, etc.).

I propose we remove them entirely and start with a fresh plan for
how these would get used (perhaps a blueprint).  As is these don't
appear to have ever been fully wired up to do anything removing
them should have no effect on end users.

Change-Id: I96f91fb0d67e7fe203d3767c8ab89ce82adbe331
2014-12-01 10:05:44 -05:00
Steve Kowalik
6f16c96383 Remove default flavor from every template
With the push to using the new setup-flavors provided by
os-cloud-config, the default flavor will no longer be called
'baremetal', and Heat will always validate the default even if it
is overridden. To that end, remove the default flavor from every
flavor definition. Just to be certain, also add a custom_constraint
to every flavor definition that was missing it.

Change-Id: I24251e73be4e86738857f73b89499f592c4908de
2014-11-27 13:07:10 +11:00
Dan Prince
eaa52183af Split out Nova software config
This is a step towards supporting pluggable software configurations
in the heat templates. By moving compute-config out of compute.yaml
we make it possible to define alternate implementations by
changing the OS::TripleO::Compute::SoftwareConfig value in the
overcloud-resource-registry.yaml heat environment file.

Co-Authored-By: Steve Hardy <shardy@redhat.com>

Change-Id: I250dc1a8c02626cf7d1a5d2ce92706504ec0c7de
2014-11-14 11:56:22 -05:00
Jenkins
897c8b8aa9 Merge "Use parameter constraints for image, key and flavor" 2014-10-31 15:42:22 +00:00
Steven Hardy
928cd735f3 Use parameter constraints for image, key and flavor
If you don't have (or provide) the wrong image, KeyName,
or flavor, we fail at some later point (not always early,
depending on what's wrong).

Since Icehouse, Heat has had a "custom constraints" method
of dynamically validating parameter values, by comparing the
value provided with a list from the underlying service.

Despite the name, there's nothing "custom" about the constraints,
these ones are included in Heat by default (though they are pluggable,
which is where the name comes from..)

See the docs for more info:
http://docs.openstack.org/developer/heat/template_guide/hot_spec.html#custom-constraint

Note, I've not considered network validation here, this could
possibly be added in a subsequent patch.

These constraints are evaluated via any of the following:
- heat template-validate -f <template>
- heat stack-preview <arguments given to create>
- heat stack-create <arguments, fails fast before creating anything>
- heat stack-update <arguments, fails fast before updating anything>

Change-Id: I3a6374ce5421575cdde893c62aa97c750a07acd8
2014-10-23 18:42:50 +01:00
Peter Belanyi
24f40d5312 Add converted version of block and object storage
This patch extends the previous 'Don't use merge.py for overcloud'
commit with the cinder-storage.yaml and swift-storage.yaml templates.

Requirements for this to deploy:

1. Block and object storage images have to be built
(overcloud-cinder-volume and overcloud-swift-storage)

2. The images have to be loaded by devtest_overcloud.sh
OVERCLOUD_CINDER_ID=$(load-image -d $TRIPLEO_ROOT/overcloud-cinder-volume.qcow2)
OVERCLOUD_SWIFT_ID=$(load-image -d $TRIPLEO_ROOT/overcloud-swift-storage.qcow2)

Change-Id: I45f9d9f051970a83e26c0fd924d7c98276958113
2014-10-21 13:39:09 +02:00
Tomas Sedovic
bcdcc28cb6 Compute and controller templates without merge.py
This provides three templates: overcloud-without-mergepy.yaml,
compute.yaml and controller.yaml. These can be used in combination with
overcloud-resource-registry.yaml to deploy the overcloud on their own --
without having to do any pre-processing (via merge.py).

To test these you have to add the resource registry environment (in
addition to the existing `-e` option) and use the new overcloud template
in the Heat call in devtest_overcloud.sh (line 374):

    heat $HEAT_OP -e $TRIPLEO_ROOT/overcloud-env.json \
        -e "$TRIPLEO_ROOT/tripleo-heat-templates/overcloud-resource-registry.yaml" \
        -t 360 \
        -f $TRIPLEO_ROOT/tripleo-heat-templates/overcloud-without-mergepy.yaml \
        -P "ExtraConfig=${OVERCLOUD_EXTRA_CONFIG}" \
        $STACKNAME

The existing overcloud Heat environment
($TRIPLE_ROOT/overcloud-env.json) should keep on working.  Scaling is
now being controlled by the `ControllerCount` and `ComputeCount`
template parameters, though.

NOTE: the changes here depend on a fairly recent Heat build (commit
e5f285f6cb from ~7th September, 2014). In other words, this requires
Juno Heat.

Also, passing more than one environment file to Heat requires
python-heatclient version 0.2.11.

Change-Id: I687a00c7dc164ba044f9f2dfca96a02401427855
2014-10-20 14:12:41 +02:00