[openstack-dev] [Neutron][LBaaS] Object Model discussion

Eugene Nikanorov enikanorov at mirantis.com
Thu Feb 27 12:00:07 UTC 2014


>
> I see IP address sharing as user intent, not an implementation detail.
> Same backend could be not only the only obstacle here.
>
> The backend is not exposed anyhow by the API, by the way.
>
> When you create root object with flavor - you really can't control to
> which driver it will be scheduled.
>
> So even if there is driver that is somehow (how?) will allow same IP on
> different backends, user just will not be able to create 2 vips that share
> IP address.
>
>
>
> Eugene, is your point that the logical model addresses the capability for
> IP sharing but that it can't be scheduled correctly?
>
That's one of concerns, correct.

   That is just not so simple. If you create vip and the pool - this or
> that way it is ready configuration that needs to be deployed, so driver
> chooses the backend. Then you need to add objects to this configuration, by
> say, adding a vip with the same IP on different port.
>
> I don't understand the issue described here.
>
Again, it's about working with proper provider when creating/updating the
resource.
User has no control of it, other then referencing provider in indirect way,
say by working with the object that is attached to the root object.


>
> Currently there is no way you can specify this through the API.
>
> You can specify same IP address and another tcp port, but that call will
> just fail.
>
> Correct, as I have described, the current implementation allocates a
> neutron-port on the first VIP hence the second VIP will fail.
>
> This is an implementation detail, we can discuss how to address. In the
> logical model I have removed the reference to the neutron port and noted
> this for further discussion.
>
Well, it may be implementation detail, or it may be a part of logical
model. Port is logical abstraction, i don't see why it should be necessary
a detail here. Anyway, I'd like to see suggestions on how to address that.
So far all the way do address it will introduce these 'impl detail' that
we're trying to get rid of.

 API will not let user to control drivers, that's one of the reasons why
> it's not possible from design standpoint.
>
>  I do not see how this relates to controlling drivers. It is the driver
> implementation, the user should not need to control it.
>
That was about scheduling. User will not have control over what backend
technology newly created resource will use, neither provider/driver, nor
particular physical backend.


>
> Youcef, can we chat over IRC? I think we could clarify lot more than over
> ML.
>
>
>
> Thanks,
>
> Eugene.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140227/9b3c4eb9/attachment.html>


More information about the OpenStack-dev mailing list