Duplicate image names cause AWS::ELasticLoadBalancing::LoadBalancer failures

[Martin Paulo]

If a user creates an image that matches the name of the image used by the AWS::ElasticLoadBalancing::LoadBalancer resource type, heat can no longer launch AWS::ElasticLoadBalancing::LoadBalancer instances.

The internal template uses the image name rather than a unique id. So, for example, Juno uses "F20-x86_64-cfntools".

If another user creates an image with this name (even if private), then anyone trying to launch a template with the AWS::ElasticLoadBalancing::LoadBalancer resource type will be met by the message:
"Create Failed

Resource Create Failed: Stackvalidationfailed: Property Error : Lb Instance: Imageid Multiple Physical Resources Were Found With Name (F20-X86 64-Cfntools)."

I know its unlikely that a user will create an image of this name, but it seems somewhat brittle to me.

I note that at the moment both Kilo and the master branch are using "Fedora-Cloud-Base-20141203-21.x86_64", which is a well known name (https://dl.fedoraproject.org/pub/fedora/linux/releases/21/Cloud/Images/x86_64/), so the chances of a user replicating this name have increased dramatically... Um: perhaps dramatically is an overstatement :)

[Steve Baker (steve-stevebaker)]

This image name is currently hard-coded in the template resource. It needs to be exposed in a heat.conf option, or even better the whole template moved out to /etc/heat so that operators can have even more control over the vm which implements the load balancer.

[Martin Paulo (martin-paulo)]

At the moment the default choices mean that anyone who accepts them is
exposed to this defect. Putting the image name/id into the heat.conf file
would allow operators to easily update the image used whenever a security
upgrade required it.

Putting the entire template into /etc/heat is a nice separation of concerns
to me - but if operators opt to go with the defaults it would still be nice
to be able to change the image name/id independently of the location of the
default template.

My 2c worth

On 20 July 2015 at 08:34, Steve Baker <email address hidden> wrote:

> This image name is currently hard-coded in the template resource. It
> needs to be exposed in a heat.conf option, or even better the whole
> template moved out to /etc/heat so that operators can have even more
> control over the vm which implements the load balancer.
>
> ** Changed in: heat
> Status: New => Triaged
>
> ** Changed in: heat
> Importance: Undecided => Medium
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1475153
>
> Title:
> Duplicate image names cause AWS::ELasticLoadBalancing::LoadBalancer
> failures
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/heat/+bug/1475153/+subscriptions
>

--
=================================================================

Martin Paulo, BSc.
Software Developer

Tel : [phone] (Home)
Tel : [phone] (Mobile)
Site: http://www.thepaulofamily.net

"Nobody goes there any more. It's too crowded" - Yogi Berra.

[Pavlo Shchelokovskyy (pshchelo)]

short term what we could do is to add yet another "magical" parameter to be used with AWS LoadBalancer and to specify the image to use (similar to what's done with KeyName, flavors etc here https://github.com/openstack/heat/blob/master/heat/engine/resources/aws/lb/loadbalancer.py#L38). The problem is we are limited by the AWS resource API for this particular resource, so we can not add any other properties directly to the AWS LB resource itself.

[Pavlo Shchelokovskyy (pshchelo)]

there is also an idea to build a "gold" AWS LB image (with all dependencies installed), put it in tarballs.o.o with some specific name and use it by default in the default inner template of AWS LB implementation.

[Martin Paulo (martin-paulo)]

My thoughts so far:

The reported problem is that a user can create an image of the same name
and hence break the AWS load balancer resource type.
The ideal fix would be to replace the image name with a specific image id.
Given that the image id is not known until it is loaded into glance this
means that the image id needs to be placed into a configuration file.

Hence the simple fix would be to leave it all as is, but to allow the image
name used to be overridden if an image id is placed in the configuration
file.

And of course to update the installation documentation with notes as to why
installers should upload the image *and* register its id. As an aside, the
first time I tried to use the AWS load balancer resource type, the cloud
operators didn't have an image with the required name in glance. Adding
this step to the installation documentation might cause operators not to
miss this important step :)

The problem with creating gold images is that someone needs to maintain
that image and produce a new release every time a security/bug fix is
needed. By using a well known base image, as is done now, then that job is
handed over to the operators. And they have complete control of the
process.

My 2c worth. Thanks for taking the time to look at this.

Martin

On 20 July 2015 at 19:14, Pavlo Shchelokovskyy <email address hidden>
wrote:

> there is also an idea to build a "gold" AWS LB image (with all
> dependencies installed), put it in tarballs.o.o with some specific name
> and use it by default in the default inner template of AWS LB
> implementation.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1475153
>
> Title:
> Duplicate image names cause AWS::ELasticLoadBalancing::LoadBalancer
> failures
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/heat/+bug/1475153/+subscriptions
>

--
=================================================================

Martin Paulo, BSc.
Software Developer

Tel : [phone] (Home)
Tel : [phone] (Mobile)
Site: http://www.thepaulofamily.net

"Nobody goes there any more. It's too crowded" - Yogi Berra.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/204514

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/204514
Committed: https://git.openstack.org/cgit/openstack/heat/commit/?id=4d60e7fe23e473261a0d7fa6e455483d17240481
Submitter: Jenkins
Branch: master

commit 4d60e7fe23e473261a0d7fa6e455483d17240481
Author: Oleksii Chuprykov <email address hidden>
Date: Wed Jul 22 12:24:20 2015 +0300

    Add LbImageId magic param to aws loadbalancer nested template

    Allow user specify image name in nested template to avoid possible
    failures because of duplicate image names.

    Change-Id: I3d358db13fd4038e254d6f941eccba50d036b010
    Closes-Bug: #1475153