Moving vip in separate resource or making it more clear.

[Sergey Kraynev]

Currently, when I want create FloatingIP, I should specify port_id.
Unfortunately OS::Neutron::Pool has parameter vip without port_id attribute specified.
And I am forced to use such hack in template :

port_id:
      { 'Fn::Select': ['port_id', {'Fn::GetAtt': [TestPool, vip]}]}

I think, that it is not good way for fixing current problem.
Also neutron team has some plans connected with changing vip resource.
As I know, they want add ability to connect one vip with different LoadBalancers.

So I offer move vip to separate resource or changing current Pool resource, so that it will be more clear for using.

Also I will be glad to hear other solutions for problem.

----------------------------------------------------------------------
Adding some more details on this from description of the bug filed today(that is marked as duplicate)
----------------------------------------------------------------------

LBaaS implementation seems to be broken and not consistent with the Neutron v2.0 API. There is no exposed VIP resource in the current LBaaS implementation mapping to neutron resource.

Assuming that OS::Neutron::LoadBalancer will be changed to OS::Neutron::VIP

- Mandatory 'protocol' property has to be added.
- some other properties like 'session_persistence','connection_limit' to be added

For detail neutron api specification, please check..

http://docs.openstack.org/api/openstack-network/2.0/content/lbaas_ext_ops_vip.html

[Thomas Herve (therve)]

I would wait for https://blueprints.launchpad.net/neutron/+spec/lbaas-multiple-vips-per-pool to land before introducing a VIP resource, so that we have a better idea of what's needed (and if the model changed a bit in the mean time).

That would allow us to add a vips property to the Pool resource, which would be a list of VIP ids, and deprecate the vip property.

In the mean time, we can possibly improve the description of the vip attribute to include the various members.

[Clint Byrum (clint-fewbar)]

Not entirely clear to me that there is a bug here, but it doesn't seem super urgent so marking Medium.

[Steve Baker (steve-stevebaker)]

If the resource is renamed but otherwise remains mostly compatible then a mapping can be added to heat/etc/heat/environment.d/default.yaml so the old name continues to work.

[Steve Baker (steve-stevebaker)]

Please elaborate when a single solution can be proposed

[Steve Baker (steve-stevebaker)]

This looks old enough to mark as invalid for now. If it is still needed is looks like it might be a big enough feature to need a blueprint spec.